← Home NO.115

第 115 期 · AGENT 工程 · 收录于 2026 年 8 月 15 日

评测驱动的心理健康Agent

SonderMind · AI Engineer

视频 21:02 原文约 1.8 万字预计阅读 12 分钟来源视频 ↗ 中英对照全文

双人对谈 · 本期速读电台 00:00 / 27:42

TL;DR · 三句话

一在心理健康 AI 里「凭感觉」（vibes）不算数——什么叫「回应得对」，由持证的临床团队定义，不由工程师、更不由模型自己定。 通用大模型本来就不是为心理健康照护造的，这个缺口已经酿成过真实的悲剧。→ 详细
二一道 eval（评测）关卡救不了系统，一个学习闭环可以。 真实对话被完整记录 → 临床医生在标注队列里用一份小量表写下「这里本应该发生什么」→ 脚本把标注转成结构化 eval → 进 CI（持续集成），从此每一次 prompt / 模型 / 护栏改动都要过这道分。修好的不是一句话，是整个自伤类别。→ 详细
三目标不是「触发得更多」，而是「触发得更准」。 过度校准（把安全阈值调得过于敏感）本身就是一种伤害——不恰当地把护栏甩到一个正脆弱的人脸上，"感觉常常就像被当面摔上一扇门"，会把真正需要帮助的人挡在外面。→ 详细

SonderMind 是谁，为什么非做这件事不可

SonderMind 是一家心理健康服务公司，把有需要的人和全美的治疗师、精神科医生匹配起来，已服务超过 100 万人，合作方包括 Headspace、Aetna、Anthem；只盯可及性和疗效，"让人更快好起来"就是北极星。→ 详细
动机：心理健康支持是今天 AI 最主要的使用场景之一，但通用 LLM 并不是为心理健康照护设计的，这已经酿成过极其惨痛的事件。需求侧的数字印证了缺口——美国心理学会（APA）近期调查发现，77% 的心理学家表示自己的来访者正在以某种形式用 AI 获取心理健康支持。→ 详细

Sonder 是个什么产品

一个有临床依据的 AI 教练：对话式、也支持语音，帮用户梳理生活、追踪目标，7×24 在线，还能带着做有循证依据的"着陆练习（grounding，把注意力拉回当下的一类小练习）"。定位克制——服务还没准备好走进咨询室、或正处在两次咨询之间的人；当真人才是正确的下一步时，它充当一扇"前门"，把人引导进 SonderMind 的治疗师网络。→ 详细

架构：输入护栏 / Sonder Core / 输出护栏的「三明治」

说明：讲者口播里用的词是"输入 guardrail（护栏）/ Sonder Core / 输出 guardrail + evaluator（评估器）"，全片没有出现 Supervisor / Executor / Evaluator 或 Ethics Engine 这些名字。功能上它就是一套"入口判官—执行者—出口评估者"的分工，下面按讲者的原词讲。

两片护栏把核心夹在中间：输入护栏检查用户刚发进来的消息，判断在 Sonder Core 回应之前要不要介入；输出护栏看 AI 的回复以及整段对话的走向——是整段，不只是当前这一句——一旦临床安全上有风险就介入、把对话拉回正轨。→ 详细
完整架构图里还有 Sonder Core 自身的记忆与个性化模块，以及分析和告警平台（出岔子第一时间知道）。Akele 给这张图下的判语是："每一个架构决策，都是以安全为首要目标做出的。"→ 详细
设计前提是"为未知做设计"：它就是一个空白输入框，人们想放什么都可以，而心理健康本身是"一片极其辽阔又崎岖的地带"。输入不可穷举，所以模块化是刚需——改核心不用碰安全逻辑，改安全逻辑也不用动核心，才能一边持续迭代 Sonder Core、一边一点不牺牲用户安全。→ 详细

为什么护栏要拆成独立的 LLM-as-judge 调用

第二条硬经验：把护栏做成独立的 LLM-as-judge（让另一个大模型专门当裁判）调用，而不是把安全规则写进主 prompt。这样更难被绕过——更难被 prompt 工程手段攻破、更难越狱，也更难靠一轮一轮对话慢慢带偏。代价是延迟和成本（每轮多出独立的模型调用），取舍理由是"这个场景的敏感程度，值得把这些环节单独拆出来做"。→ 详细
模块化的第二个红利才是这整场演讲的枢纽：评估变得直接、好做。独立部件才能单独喂用例、单独打分、单独回归；反过来，Dave 后面点名的反模式就是"把一条安全规则埋在一大段啰嗦的 prompt 里，结果变得很难单独拎出来做测试"——测不了，就谈不上信任。→ 详细
而信任正是目的本身。Akele 反复用同一句话定义它："在我们需要它们发挥作用的时候，它们真的会按预期发挥作用。"→ 详细

不是「触发得更多」，是「触发得更准」

大多数通用 LLM 过于保守——Akele 当场让"误触发过护栏"的观众举手，举了一大片。但这里的人是在脆弱的时刻来的：不恰当地把护栏甩到对方脸上，"感觉常常就像被当面摔上一扇门"，会让人更孤立、更觉得求助反而更难。所以指标不是触发率，是触发的正确率。→ 详细
三个有代表性的合成用例把"准"落成三档处置：① 危险正在发生、用户相信自己此刻不安全 → 推出本地求助资源并主动退出对话（她此刻需要的是真人和一个安全的地方）；② 困扰来自过去的事、不在急性危机中 → 推出资源，但只要用户愿意就继续陪着聊；③ 只是关系上的困扰、无任何不安全迹象 → 用户根本察觉不到护栏存在，消息直接透传给 Core。→ 详细
这三档的分界线不是工程师拍的，是和临床团队一起校准出来的——在"用户安全在临床上究竟意味着什么"这件事上，细微差别极其重要。→ 详细

字面不等于信息：为什么正则、长 prompt、通用审核 API 都接不住

Dave Revere 的开场比喻：当爹之后他掌握了一项没写进简历的硬核技能——翻译"我没事"。一种是真的还好、只是不想说话；另一种是确实有事、而且得往下深挖。"字面并不等于真正的信息"，这就是他要讲的工程问题。→ 详细
他抛给全场的题目，是一位临床医生根据真实来访经验提供的场景：一句用日常动作（收拾箱子）间接试探"自己不在了会是什么样"的话。字面上完全可能只是有人准备搬家，但临床医生一读就知道是风险信号。三条常见解法都接不住——用正则表达式穷举自伤相关词、把 prompt 写得极啰嗦并把安全规则埋进大段文字、或直接挂一个通用内容审核 API：它们抓的都是"词"，而这里的信号"不是某一个词，而是言外之意，是上下文，是那句句子底下的句子"。这位医生"比我们更早地了解，我们的系统将会遇到什么样的人"。→ 详细
全片的转折句也在这一段："一道简单的 eval 关卡并不能让系统变安全，但一个学习闭环可以。"→ 详细

临床反馈闭环：从一条标注，到 CI 里的一道门

第一步 trace（把对话完整追踪记录下来）：这类对话被完整捕捉，"把那一刻捕捉住"，好让临床医生进去标注、写下这种情况下本应该发生什么。Dave 把关键动作说得很直白：在这种临床边缘案例里，"判断'什么才叫正确'的不是我们的系统，而是一位持证的专业人士"。→ 详细
第二步：标注队列 + 一份很小的评分量表（rubric）。字段不多，但每个都在干重活——「期望观察」＝这条 eval 的断言（到底要断言什么才算通过）；「轮次索引」让工程师能把对话重放到护栏本应触发的那一刻，精确到第几轮该响，而不是笼统说"这段对话不对"；**「备注」**帮工程师判断这个场景该归到哪一类。→ 详细
第三步：一个标注提取脚本——自动做分诊，把所有被标记的 trace 生成一份报告供团队讨论；同一个脚本还把这些标注转成结构化（typed）eval（对话输入、期望结果、期望观察、分类元数据），统一规范进团队的 eval schema。人写下的是判断，机器拿到的是可执行的用例。→ 详细
第四步：提交进 CI——"临床医生的专业判断就活在了 CI 流水线里"，此后每一次 prompt 改动、每一次更换模型、每一次护栏调整，都必须拿去跟临床医生教的标准跑一遍评分。收益的量级 Dave 说得很清楚：真正的胜利不在于那一句被修好了，而在于整个自伤类别的表现都被抬高了一个台阶——一条标注升级的是一整类判断，不是一个 case。→ 详细

过度校准（over-calibration）这个坑，与三个设计选择

闭环建起来之后，Dave 立刻抛出下一个工程难题：如果真要做"以人为中心节点"的系统，就不能只意味着触发得更多。他用自己的生活举例——儿子快搬出去住了，天天念叨着收拾箱子——"我可不希望有一套学会了惊慌的系统。慌张这件事，我自己来就够了。"玩笑背后是硬道理：过度校准会挡住真正需要照护的人拿到照护。→ 详细
围绕校准，他们做了三个设计选择。其一，"什么算好"由临床团队定义——原话是"凭感觉（vibes）在这里不算数，持证专家做出的、可问责的专业判断才算"。关键词是"可问责"：判卷权有明确归属，出了偏差知道去问谁、改哪张量表。→ 详细
其二，打过标签的场景问的都是能判真假的具体问题，而不是"这条回复好不好"：预期的观察项有没有被触发？触发的类别对不对？时机是不是落在对话里正确的那个点上？输出端的 evaluator 有没有认出问题的类型？其三，这些场景直接变成 eval、成为发版的准入门槛——不是"上线前跑一次看看"，是过不了就不发。→ 详细
观众问答里还有更硬的一手佐证：他们第一天就不得不把前沿模型内置的护栏关掉——"因为通用 LLM 是过度校准的……我们一跑自己的数据集，它就会把所有东西全都过滤掉"，这才是他们从零自建整套护栏的直接原因。→ 详细

不追求 benchmark 满分，追求"接住真正要紧的东西"

设计哲学很反直觉：并不追求把 benchmark（基准测试）刷到满分，因为刷分反而会让注意力"从这些 benchmark 本该保护的那个人身上飘走"，何况有些边界情况本身就真的存在歧义。替代的靶子是从真实数据里的真实失败模式出发造 benchmark——"误报（false positive）重要，漏报（false negative）重要，类别重要，时机也重要"。配套是对建造者的问责："我们不能只是嘴上承诺安全"，安全系统必须被自己的领域专家评审和测试过。→ 详细

开源数据集：共享一条基线

他们把数据集开源了：200 个输入端 + 100 个输出端护栏场景，每条都经过临床评审、对照真实对话模式校准，单轮多轮都有。并明确声明它不替代你自己去搭学习闭环——"在你爬学习曲线的这段时间里，可能真的有正在受苦的人在等着这套系统"。→ 详细

收尾：让安全来定义能力

结语把整件事拉回人的尺度：这是他们所知最严谨的方式，去做一件其实非常古老的事——在一个人最低谷时陪着他，让他知道自己并不孤单；"这就是我希望我儿子将来能用上的那种 AI"。致谢里特别点名了临床医生 Caroline Collie，也谢了台下正在把"让安全来定义能力"做进系统里的人。→ 详细

本片末尾有现场问答。提问的是一位同样在做医疗健康领域 AI 陪伴产品的开发者，一口气问了两题，都很实操。

Q1：你们背后用什么模型驱动？更要命的是——Anthropic、OpenAI 在 API 背后、在模型训练里就内置了它们自己的护栏，用户说的内容哪怕过了我自己那层护栏，模型本身还是可能拒答。你们是怎么绕开的？ → 详细

Akele 的回答：他们基本上第一天就不得不把模型内置的护栏关掉——"因为通用 LLM 是过度校准的，所以我们才自己造了一套 guardrail"。原因就是提问者说的那个现象："我们一跑自己的数据集，它就会把所有东西全都过滤掉。"（注：她没有点名具体用了哪家模型，这一半的问题实际没答。）→ 详细

Q2：误报和漏报之间你们怎么取舍？宁可多误报少漏报，还是反过来？ → 详细

Akele 的回答：过度校准其实是一种出于善意的选择——前沿模型厂商是这样，他们自己这边也是。他们要做的是把那个余量（margin）明显收窄、让判断更准确；但方向上确实仍然偏向过度校准这一侧。（跟正文立场自洽：追求"更准"，但准不了时仍选更保守那一边。）→ 详细

主持人叫停时台下还举着一片手，问答只放出了这一位。→ 详细

两位讲者没有在台上留个人联系方式（邮箱 / 社交账号都没给）。片中只提到两个触点：

最后一页幻灯片上的二维码，指向他们开源的护栏数据集（200 个输入端场景 + 100 个输出端场景），并邀请用过的人反馈想法。→ 详细
两人演讲后留在现场答疑（"Akele 和我待会儿都在场，欢迎来找我们提问"）。→ 详细
讲者：Akele Reed、Dave Revere，均供职于 SonderMind；片中特别致谢的临床医生是 Caroline Collie。→ 详细

🎯 于你何益为你定制 · 非通用结论

这一期表面上讲心理健康 AI，实际上从头到尾在回答一个你正卡着的问题：一套多 agent 系统，谁来判卷、判卷标准写在哪、这个标准怎么变成挡得住人的门。 他们的答案不是"再加一个评审 agent"，而是"把领域专家的判断变成机器能执行的用例，塞进流水线当准入门槛"。这套动作跟你的 PRD 工厂、造 App 链路几乎是同构的，所以这段写厚。

Codex Holdwell ERP work（多-Agent PRD 工厂）

一、判卷权必须归业务方，且"什么算好"要有名有姓地写下来

怎么做的：他们把"什么算好"的定义权明确交给临床团队，原话是"凭感觉（vibes）在这里不算数，持证专家做出的、可问责的专业判断才算"。写 prompt 的工程师不定义正确，模型自己更不定义；在临床边缘案例里，判断对错的是那位持证医生。而且注意"可问责"三个字——标准有归属，出了偏差知道去问谁、改哪一份量表。
你可以怎么做：你的 PRD 工厂里三驾马车全在生产，碰撞环节（补强/修正/第 3 案）本质上还是 agent 自己判自己的卷——这在他们的框架里就是"vibes"；真正的判卷权在真人评审那一环。挑你最常被打回的那 1-2 类问题，给它指定一个真人业主（比如"异常流完整性"归某位业务负责人，"数据口径"归某位数仓同学），把这个人过去打回你 PRD 的那些理由，逐条写成一句"本应该出现什么"。判卷标准不是靠补一段更长的 prompt 产生的，是靠有人认领产生的。

二、把红线从主 prompt 里搬出来，做成能单独测的独立模块

怎么做的：他们坚持把护栏做成独立的 LLM-as-judge 调用，而不是写进主 prompt。两个理由：一是更难被绕过（更难被 prompt 工程攻破、更难越狱、更难靠多轮对话慢慢带偏）；二是能单独测——Dave 点名的反模式就是"把一条安全规则埋在一大段啰嗦的文字里，结果变得很难单独拎出来做测试"。代价是延迟和成本，他们认了。
你可以怎么做：ERP 的规则天天在变——税则、平台政策、退换货口径、各站点合规要求。这些如果硬编码在 PRD-writer 的系统 prompt 里，每变一次你就得动主 prompt，还没法验证改动有没有破坏别的东西。照他们的做法：把红线抽出来放进独立的规则文件（一条规则一段，带"违反时应观察到什么"），再配一个只干检查这一件事的 checker agent。规则变了只改文件，主 prompt 一个字不动——这正是你要的"随规则演进"，而不是"每次都重写宪法"。

三、一条打回 → 一条结构化用例 → 一道门：这就是"评审意见回炉"该有的闭环

怎么做的：他们的闭环是四步——对话被完整 trace 记录 → 临床医生在标注队列里用一份很小的量表标注（三个字段：期望观察＝这条 eval 的断言、轮次索引＝能把对话重放到本该触发的那一刻、备注＝帮工程师归类）→ 一个提取脚本把标注批量转成结构化 eval、统一进 eval schema，顺便生成一份分诊报告供讨论 → 提交后"临床医生的专业判断就活在了 CI 里"，此后每一次 prompt 改动、每一次换模型、每一次护栏调整都要过这道分。收益的量级他说得很清楚：修好的不是"收拾箱子"那一句，而是整个自伤类别被抬高了一个台阶。
你可以怎么做：你的痛点是"真人评审意见回炉难闭环""agent 产出缺可验证证据"——这两条其实是同一件事：门卡的是"有没有产出文档"，而不是"有没有过用例"，所以意见改完这一版就丢了。 照搬他们的三字段：真人评审每指出一次"这版 PRD 漏了 XX"，除了改这一版，再花两分钟登记成一条用例（输入＝需求背景那几句 / 期望观察＝"输出里必须出现退款异常分支" / 归类＝异常流）。攒到十几条，写个小脚本把它们统一成一份用例文件，然后把流程某一道关的通过条件从"文档已产出"改成"这批用例跑过且全绿"。这样一轮跑完你手里有的不是感想，是"第 N 版跑过 12/15 条、第 N+1 版跑过 15/15"——这就是回炉的闭环。

四、共享实体定义沉不下来时，从"吵过架的词"倒推最省力

怎么做的：他们不追求把 benchmark 刷满分，而是"从真实数据里的真实失败模式出发"造 benchmark——靶子来自真实翻车，不来自想象中的完备清单。
你可以怎么做：六条产品线共用的实体定义迟迟沉不下来，多半是因为你在试图"先把实体定义全"。反过来：翻最近 5 次跨线对齐吵架的记录，看每次到底是哪个词大家理解不一致（"订单"在仓储和财务眼里是不是一回事？"可用库存"含不含在途？），只补这几个词。先补吵过架的，比先补齐全的，落地快一个数量级。

五、过度校准的镜子：评审检查加太多，也会挡住本该过的需求

怎么做的：Dave 的"我可不希望有一套学会了惊慌的系统"——过度校准会挡住真正需要照护的人拿到照护。他们同时统计误报和漏报、类别和时机四个维度，而不是只盯"有没有漏掉危险"。
你可以怎么做：给你的评审也记误报——被某条检查拦下、但事后证明本来就该放行的需求。若某条检查长期只贡献"改了也没变好"的意见，就降级或删掉。一套只会拦、拦完还得你手工放行的评审，最终结果是所有人绕开它。

app_incubator（7-Agent 造 App）

一、"设计稿即工程契约"的下一步是"契约得有裁判"

怎么做的：他们那份量表的核心字段叫期望观察——它同时就是这条 eval 的断言。也就是说，专家写下的不是"这里要小心一点"，而是"这里应该观察到 X 发生"，一句能判真假的话。
你可以怎么做：你的设计契约现在多半还是描述性的（"层级清晰""留白充分"）——那种句子任何 agent 都能自称做到了。把它压缩成 3-5 条能机器判定的断言：正文字号 ≥ 16px、点击区 ≥ 44pt、正文与背景对比度过 WCAG AA、暗色模式下同样过。做成一个独立的 checker agent，出图后自动跑，不过就打回。契约的价值不在写得多细，在能不能被自动否决。

二、激活/首屏这个痛点，靶子应该来自你自己卡住的那几个瞬间

怎么做的：他们造 benchmark 的原则是从真实失败模式出发，并明确说刷满分反而会让注意力从"benchmark 本该保护的那个人"身上飘走。
你可以怎么做：与其套一份通用可用性清单，不如把你自己（或第一批用户）每次试用卡住的那 5 个瞬间记下来，一字一句写成 5 条必过用例（"冷启动后 3 秒内必须出现可点的第一步""空状态必须给出一个具体动作而不是一句欢迎语"）。首屏就是你的"输入护栏"——它决定了人会不会在第一分钟就被摔上一扇门。

onehuman_company（一人公司 build-in-public）

一、这期能直接变成一篇"验证体"选题，而且弹药是现成的

怎么做的：SonderMind 把 200 个输入端 + 100 个输出端护栏场景开源了，理由是"共享一条基线有价值——在你爬学习曲线的这段时间里，可能真的有人在等着"。整场演讲的主张可以压成一句能上标题的话：凭感觉不算数，判卷权得交出去。
你可以怎么做：选题《大佬说"评测驱动开发"，我拿自己的 PRD 工厂实测了一版》——把你踩过的 10 条 PRD 失败样本做成用例集，公开跑分：改造前过几条、改造后过几条、多花了几小时、翻了什么车。过弹药库闸门检查：删掉你的实测数据和判断，这篇就不成立，所以能发。而且它天然带"可抄物"——那三字段的用例模板，读者复制就能用。

Personal Thinking（第二大脑）

一、"一条标注抬升一整个类别"这套动作，可以直接搬到你的摄入 SOP 上

怎么做的：他们的关键不是修好一个 case，而是让一条标注升级整个类别的判断；靠的是把人的判断结构化成可复用的用例，而不是留在评论区里。
你可以怎么做：你每次读完一期总结，心里都会冒出"这篇漏了我最想要的东西"——现在这个判断是散的，读完就没了。把它写成对总结模板的一条检查项（比如"架构类内容必须交代各部件之间的数据流向""每个数字必须带出处轮次"）。攒十条，就是你的模板用例集；下一期跑完对着扫一遍。信噪比不是靠少收内容提高的，是靠把"什么算一篇好总结"写下来提高的。

该反着用

他们的闭环中心坐着一整支持证临床团队，还有 Caroline Collie 这样一位专职的领域专家——判卷权能"交出去"，是因为有人可交。你是一个人扛正职加多个副业，没有第二个专家坐在那儿等你派活。所以正确的借鉴是反过来：把"过去的你"当成那个专家。你评审时的判断、被业务方打回的记录、自己试用产品时皱眉的那一刻，就是你唯一的标注源——而且必须当天记，因为一周后你只会记得"当时觉得哪儿不对"，记不得为什么。他们靠人力堆闭环，你只能靠资产化闭环：每条判断只值一次，写成用例才开始复利。

另一处该反着用的是"独立判官"的成本取舍：他们为了安全愿意每轮多付几次模型调用的延迟和钱。你的场景（PRD、设计稿）不是实时对话，多花几十秒没人察觉——所以这笔取舍对你比对他们更划算，别下意识地觉得"再加一次调用太重"。

和你现在做法冲突

你的元约束是"精力最稀缺、杠杆 > 工时"，你的习惯是找到高杠杆动作、快速推进。而这套做法前期全是慢功夫：记录、标注、写脚本、维护用例格式，短期只减速不加速，杠杆要到十几条用例攒起来之后才显形。他们能付这份税，是因为代价是人的安危；你的 PRD 写错了，代价通常只是返一轮工。

所以真正的张力是：你到底愿不愿意为一个"不出事"的领域付这份税？ 这个不替你下结论。但有个折中值得考虑：别全面铺，只在一个环节上试——挑评审检查里最常出错的那一条，只给它建 5 条用例，跑一个月，看返工次数有没有掉。用最小成本回答"这份税值不值"，而不是靠想象。

另一处小冲突：你信"判断力 > 努力"。这期讲的却是"判断力必须离开你的脑子、变成文件和门，才算数"。这两者不矛盾，但后者对你是个不太舒服的加码——好的判断如果只活在你脑子里，在多 agent 系统里就等于不存在。

对你的镜子

你一直担心 PRD 工厂"agent 产出拿不出可验证的证据"。这期照出来的是：闭环缺的从来不是那张流程图，是一个"谁说了算"的人，和一份机器能执行的判卷标准。 你的工厂里三驾马车都在生产，真正的判卷散落在真人评审的意见里；而判卷标准如果只活在意见和经验里、没活在文件和门里，它就不存在——不存在的标准，当然也就产不出证据。

第二面镜子来自"过度校准"：Dave 说他不想要一套"学会了惊慌的系统"。你正同时推 ERP 工厂、造 App 链路、两个内容号、投资看板——一个把所有告警都调到最敏感的人，最终会对所有告警脱敏。 在你身上，"更多护栏"和"更少精力"是同一个账。

所以呢

可迁移思维模型

【耐用】"凭感觉不算数"——判卷权归领域专家，标准要有名有姓地写下来。 这条在 AI 出现之前就成立（代码审查、临床指南、审计），AI 之后只会更重要，因为生成的东西多了，判卷成了瓶颈。
【耐用】过度校准本身就是失败模式。 只统计漏报的系统一定会把误报做爆，安全和可用是同一枚硬币的两面。这条也能对到你的价值投资：一套只为"绝不踩雷"设计的选股规则，会把好生意连着一起筛掉——安全边际是留出来的，不是把闸门焊死。
【耐用】一条标注抬升一整个类别。 单个问题修好只值一次，变成一条用例才复利。判断哪件事值得做，就看它是"修一个"还是"抬一类"。
【会过期】具体做法层的两条：护栏必须做成独立的模型调用（模型自带的评估与遵循能力在快速变强，这个成本取舍两年后可能不成立）；必须关掉厂商内置护栏（各家策略一直在动，且不同行业的可用性差别很大——这是 2026 年这个时点的做法，不是永恒真理）。

判断更新

把"评测 / eval"从你脑子里的"上线前跑一次的检查"，换成"每次改动都必须过的门"。而且判断一道门好不好，不看跑分多高——他们明说了不追求满分——看它是不是真的挡下过东西。一道从没拦下过任何东西的门，等于没有门。

这周一个赌注

从 Holdwell PRD 工厂里挑一条你最常被业务方打回的失败模式（比如"漏了异常流""数据口径没对齐"），照三字段（输入 / 期望观察 / 归类）写 5 条用例，塞进评审那一步当硬门槛。一周后只看一个数：这 5 条有没有真的拦下过一版。拦下过，就再加 5 条；一次没拦下，说明你挑错了失败模式，换一条重来——这个失败本身也很便宜。

诚实说明：这期跟 StockHelp 和小红书家居号没有真实关联（唯一沾边的是上面那条"过度校准"对选股规则的类比，已就地写进思维模型，不单独硬掰成一节）。

接着读

NO.114 · Agent 工程 Decagon配置Agent的脑子 Sunny Rekhi · 9 分钟 NO.113 · 产品伪装成交付的产品战略 Vinoo Ganesh · 19 分钟