这期看起来是讲代码评审，其实正面撞上了你手里最大的那个卡点：你有三驾马车碰撞出 PRD 的流水线、有真人评审那道关，但评审意见回炉还没有一个真正说了算的闭环——所有东西都得人过一遍，等于所有东西都堵在那儿。Claire 这套「六维度打分 + 分数阈值分流」提供的正是缺的那一块：关卡的价值不在于它能拦住多少，而在于它敢放过多少。 所以这段会写得比平时厚。
一、Holdwell 的多-Agent PRD 工厂（本期最强命中）
① 把「评审环节的意见」改造成「六个维度的打分」——你缺的回炉闭环就长这样
- 怎么做的：她的关卡不是一份让人逐条读的检查清单，而是六个可以算分的维度：改动面多大、爆炸半径多大、容不容易回滚、有没有碰数据安全（碰了有没有覆盖到）、有没有动运维、以及「验证缺口」——测试全不全、CI 跑完没有、能不能用几种方式交叉验证。六项加总跑一段脚本得出一个数，然后这个数直接决定路由：低于 24 分自动放行，25–64 分和 65 分以上一律必须人批。她特别强调这些阈值不是她定的，是 AI 给的初版，她只做打磨。
- 你可以怎么做：你碰撞环节和真人评审现在的输出大概率都是「意见」，而意见没法自动分流——这就是回炉闭环缺失的根因。把评审关注的几个面改成 0–20 分的打分项（比如「跨线影响面」「验收条件可测性」「是否触及已有实体定义」「是否改动线上流程/权限」「证据缺口：有没有可验证的验收样例」），加总出一个「需求风险分」。然后定三档：低分＝这条需求可以直接进排期，不必上评审会；中分＝只走异步单人复核；高分＝才值得开完整的三驾马车碰撞＋真人评审。 本周就能做的最小动作：先跑影子模式——只打分、不改流程，拿最近 10 份 PRD 打一遍，看分数排序和「实际被打回的那几份」吻不吻合。吻合了再上分流，这一步同时也是你一直缺的agent 产出可验证的证据（一张分数 vs 实际打回的对照表，比任何汇报都硬）。
② 「阻断项」和「风险分」是两套逻辑，绝不能混在一个分里
- 怎么做的：实测里那个纯文档 PR 拿了很低的风险分，照样没被自动批准——因为它有 merge 冲突。她说这也是 agent 评分时必须检查的一项，并在结论里单独写清「批准的阻塞原因＝这条 PR 有 merge 冲突」。也就是说：低风险 ≠ 自动放行，分数低只是通过了第一关，还要过一遍硬阻断清单。
- 你可以怎么做：你的评审里一定也有几条「不管这需求多小、缺了就是不能过」的东西——比如没写清受影响的下游产品线、没有验收条件、动了共享的字段/实体定义却没同步。把这几条从打分项里摘出来单列成阻断清单，让 agent 的输出固定长成两段：「风险分：XX（低）」＋「阻断项：无 / 有，原因是……」。这一步能救掉你最容易翻的那种车——一个看起来无害的小需求，因为动了共享定义而悄悄溜过关卡。
③ 「diff 大小不作为风险依据」——规模不等于风险，这条直接反你的直觉
- 怎么做的：她的 skill 里写死了一句
diff 的大小不作为风险依据。改 3 行还是 300 行，本身不加分。真正决定风险的是碰了哪里（他们的仓库规则：文档＝低风险、功能逻辑＝中风险、认证和计费＝高风险）、能不能撤回、以及验证够不够。演示里那个拒批的 PR 之所以是中风险，不是因为它有 35 处改动，而是因为它动了服务端 API 的行为。
- 你可以怎么做：你现在（和大多数团队一样）很可能是按需求大小决定评审强度——大需求开大会，小需求随手过。她这条建议你反过来：按「碰了哪条产品线」定强度。给 ERP 写一份和她那三行等价的领域风险表，例如**「文案/字段说明＝低风险；业务流程逻辑＝中风险；库存扣减、对账结算、税费、权限＝高风险」，写进评审 agent 的指令里。这张表就十几行字，但它是你整套流水线里最能沉淀领域经验的地方**——而且它是活的，每翻一次车就往里加一行。
④ 给内部的评审 agent 也跑评测集——这是你「agent 产出可观测/可验证」的正解
- 怎么做的：她自己没做，但明确点名 Intercom 的加分动作：每次 review 跑完，结果都记进一个内部 eval 平台，由工程师去看「这次 agent 判对了吗？判错了吗？我们对这套打分机制满意吗？」 她的原则句是：「跟你用 evals 去改进面向客户的 AI 产品是一个道理，你也会想用 evals 来改进面向内部的 AI bot，尤其是那些碰到代码这类要害东西的。」
- 你可以怎么做：你那条流水线最大的软肋是没人知道它到底判得准不准。做法很轻：建一张表，每次流水线出一份 PRD 就记三列——agent 给的分 / 人最后是不是打回了 / 打回的真实原因。攒到 20–30 行，你就同时拿到了三样东西：阈值该定在几分（看分数和打回率的拐点）、哪个维度是废的（从来不影响结论的那个删掉）、以及可以拿去汇报的闭环证据。这比继续往流水线里加环节、加评审轮次划算得多。
二、app_incubator（7-Agent 造 App）
① 「配置」这件事可以整个外包给浏览器操作
- 怎么做的：她说真正惊艳的不是 AI 写代码，而是让 Codex 用 Chrome 的 browser use 自己去点完 Slack bot 和 GitHub app 的配置流程——勾权限、走向导，她只负责按几下按钮、过双因子认证、核对结果（唯一卡壳是「它点保存那一步有点费劲」）。她把这条单拎出来当通用心得：「写代码我没问题，但我真不想去点配置」的时候，browser use 是个超好用的偏方。
- 你可以怎么做：你的造 App 链路已经接了 Chrome，但大概率还是用在「看效果/截图」上。把它往前挪一格，用在开工前的接线上——建仓库、配 CI、开第三方服务的 key、配推送和支付后台，这些正是每起一个新 App 都要重来一遍、又最消磨热情的活。做成一个「新项目开箱」的 skill，让它照着一份清单自己点，你只管两步：登录和最后核对。这条能直接砍掉你启动一个新想法的心理成本。
② 触发规则要先降噪：等前置条件全绿了才让下游 agent 出手
- 怎么做的：她专门在 PR 规则里做了限制——「你肯定不想每来一个 PR、在 checks 还没跑完的时候就触发它」，所以 agent 只在所有检查完成后的那个事件上触发，而且内部还有一条「只审查最新的改动」的逻辑，不重复审已经看过的东西。
- 你可以怎么做：你的多 agent 链路里，最贵的浪费就是下游 agent 在上游还没定稿时就开跑（设计稿还在改，工程 agent 已经在按旧稿产出）。给每个交接点加一个「绿灯条件」——设计稿标记为定稿、契约文件校验通过，才允许下游触发；再加一条「只处理自上次以来变化的部分」。这两条加起来，比给 agent 换更强的模型省钱得多。
③ agent 的最小组件清单，可以当你的减法参照
- 怎么做的：她的整个 bot 就是：一个 channel + 一份指令 + 一个 skill + 两个工具（读 PR 的一切信息 / 把判定写回去）+ 一个 Slack 通知器。指令全文「四五段话、几个要点，连滚动条都不用拖」，而且是 AI 写的、她只做了打磨。原话：「你完全不需要过度设计这个东西，而且它跑得非常非常好。」
- 你可以怎么做：拿这套当尺子量一遍你的七个 agent——每个 agent 问一句：它有几个工具？指令有几页？ 凡是指令超过两页、工具超过三个的，八成是把「本该写进契约的东西」写进了提示词。她的结构值得抄的地方是**「读 / 判 / 写」三件事分成一 skill 二工具**：读的工具只读、写的工具只写，判断逻辑留在 skill 里——这样改判断规则时不用碰任何代码。
三、Chief of Staff（你的决策外脑）
「可逆性」和「爆炸半径」应该是你决策分诊的前两问
- 怎么做的：她那六个维度里最有迁移价值的两个是**「爆炸半径」（出事了波及多远）和「是不是容易回滚」**（她的例子：一次大规模数据迁移，撤回起来就麻烦得多）。这两条决定了同样大小的改动，风险差一个量级。她的分流逻辑更狠：低于阈值的，系统直接放行，根本不惊动人。
- 你可以怎么做：你的外脑现在偏「守门」（提醒你别违背原则），但守门也需要分级——不然它对每件事都同样郑重，你很快就会忽略它。给它加一道入口分诊：任何决定先答两问——「这事出错的波及面有多大？」「一个月后能不能撤回？」 两问都轻的，直接自己拍板，不许它展开劝告；有一问重的，才启动完整的原则比对和跨域检查。这正是你「判断力 > 努力」那条操作系统的机器版：把郑重程度留给真正不可逆的事。
四、One Human Company（build-in-public 那个号）
① 这期本身就是一篇标准「验证体」的范本，结构可以整段抄
- 怎么做的：她的叙事骨架是——先讲痛（PR 堆着没人审、还挺无聊）→ 引两篇公开实践当依据（Intercom、Diff Vader）→ 亮出一句原始提示词（连错别字都不修）→ 展示中途怎么拨方向 → 摊开全部指令（就一页）→ 跑三个真实案例，其中一个还是失败/被卡住的 → 承认心理门槛（「我以为得花好几天，我可不想去配那个 GitHub app」）→ 最后把问题抛回去：「你会往风险打分里加哪个维度？」
- 你可以怎么做：这七段几乎可以直接做成你验证体选题的模板。最值钱的两处是「亮原始提示词」和「留一个失败案例」——它们是让读者相信你真跑过的凭据，也正好是你那道弹药库闸门要的东西（删掉我的实测就不成立）。你的版本可以是：「我拿 drizzle tech 给自己的 PRD 流水线做了一个 Merge Mommy」——把她的六维度换成你评审环节的判断标准，跑 10 份真实 PRD，把打分和实际打回的对照表贴出来。可抄物现成的：那张六维度打分表 + 三档阈值。
② 她自曝的「我怵了很久」，是这个号最缺的那种料
- 怎么做的：全片最有人味的一句不是技术，是**「这东西本来是我特别怵、特别不敢动手做的。我以为得花上好几天好几天。」** 她还交代了前史：以前真试过一次，那是在 browser use 好用之前、Eve 出来之前——当时就是做不动。
- 你可以怎么做：你那个号的四个支柱里，「AI 员工管理成本账」和「造 App 决策复盘」都偏账本和结论，缺的是这种「我拖了三个月没做，做完发现只要 30 分钟」的落差感。这就是一条现成的选题类型：「我以为要 X 天的活，实际用了 Y 分钟——以及我为什么拖了这么久」。它天然有钩子、天然带可抄物（那个让你从"几天"变"分钟"的具体工具或做法），而且只有真干过的人写得出来。
五、Personal Thinking（这本第二大脑）
你的内容雷达已经在打分了，但缺的是「打完分之后自动发生什么」
- 怎么做的：她这套机制真正的转折点不是打分，是打分之后有一条自动动作——低于阈值的东西系统自己处理掉，不进人的视野；只有中高分才升级到 Slack @ 人。她甚至为此接受了一个不完美的妥协（bot 只能打灰勾、还得人点一下），因为流程跑通比机制纯粹更重要。
- 你可以怎么做：你的内容雷达已经在给博主更新打相关度分了，但分数目前基本只是排序用，动作还是你自己一条条挑。给它补上阈值分流：低于某分的直接归档进「只存不读」，中间档只留一句话摘要不做完整转写，高分才走完整的转写＋总结＋播客那条重管线。 这正好治你摄入 SOP 的信噪比问题——你现在的瓶颈不是抓不到内容，是每条内容都被同等对待。
六、StockHelp / 投资（诚实说明）
- 本期没有任何投资、估值、商业模式相关的内容，不硬对。唯一有迁移价值的是「可逆性」这个维度本身——但它在这里是代码风险的一条打分项，跟仓位管理是两回事，展开就是牵强。这一节到此为止。
该反着用
- 她保留「人点一下」是为了合规，你没有这个约束——别照抄那个灰色的勾。 她之所以让 Merge Mommy 只打灰勾、由人 approve，是因为 repo 规则要求「必须有一次人类 review」才能对上 SOC 2 的审计要求，她甚至试过让 bot「装成人类」，结论是「不太划算」。你的副业和第二大脑没有任何合规审计要在意，所以你真正该抄的不是那一下点击，而是它背后的东西：留下一条可回溯的记录。低风险的东西该真的自动过，只要它在日志里留了痕、事后查得到就行。在没人审计你的地方保留人工确认，那不叫谨慎，那叫没舍得关掉。
- 她可以自己定风险政策，你在 8 人 PM 团队里不能。 她是创始人，一句话就把阈值和分类写进 skill 推上生产；你要在团队里推「低分自动过」，第一步不该是改流程，而该是先在自己负责的那条产品线跑影子模式——只打分不分流，攒够对照数据再谈分流。她的顺序是「先上生产再调优」，你的顺序必须是「先攒证据再动流程」，这是两种资源和授权结构的必然差别。
- 她是「先做出来再想机制」，你的元约束是精力最稀缺。 她敢一句提示词就推上生产、连打分维度和阈值都让 AI 自己拿主意，是因为这个内部工具错了也不贵（大不了多一次人工审）。你在挑「本周做什么」时得倒过来问：这件事错了贵不贵？ 便宜的就学她一次成型，贵的（比如动 Holdwell 团队的流程）必须先影子跑。
和你现在做法冲突
- 「你完全不需要过度设计」直接顶到你的流水线。 她的整套评审逻辑是一页指令 + 一个 skill + 两个工具，而且她一个字都没写、只做打磨；你那条流水线是三驾马车、独立初稿、碰撞、合成、真人评审一长串环节。这两者不是简单的对错关系，但它逼出一个必须正面回答的问题：你那几个环节里，有几个的产出是「给人读的意见」，而不是「能被判定对错的分数或结论」？ 她的经验是——能被判定的那部分，一个 skill 就够；给人读的那部分，才需要角色和格式。
- 「AI 写的代码可以比人审的更安全」冲的是你的默认假设。 大多数人（包括流水线的设计者）默认 AI 产出需要更多人工把关。Intercom 的数据是反的：AI 批准的 PR 快 5 倍，回滚率还更低。如果这条在你的场景也成立，那你给 agent 产出加的那些额外关卡，可能有一部分是在给自己的不安心买单，而不是在降低风险。这个张力我不替你下结论，但值得你在下次改版前用数据回答一次。
- 「规模不等于风险」冲的是你的排期直觉。 她写死「diff 大小不作为风险依据」。对照你的习惯：大需求开大会、小需求随手过——这套排法在 ERP 这种到处是共享定义的系统里恰恰最危险，因为最容易出事的往往是那种「就改一个字段口径」的小需求。
对你的镜子
- 你那道评审缺的可能不是规则，是「放过」这条路。 她解决的根本不是「AI 会不会审错」，而是「人审不过来」。你担心碰撞协议的纪律守不住，很可能不是因为它不够严，而是因为它对所有东西一样严——当所有需求都必须走完整的碰撞加评审，实际结果就是大家一起偷工减料。一道没有「自动放行」档位的关卡，最终会被绕过；分流才是执行力的来源。
- 「我以为要好几天，结果 30 分钟」——你手里有几件这样的事？ 她拖着没做的理由不是不会写代码，是不想去点那些配置页面。你的待办里大概率也躺着几件被「想象中的麻烦」挡住的事（指标盘一直空着没跑、agent 产出的可观测层一直没起头）。这期真正的可迁移动作是：把「我不想做的那部分」单独拎出来问一句——这部分能不能整个交出去？ 常常一交出去，整件事就从「几天」塌缩成「半小时」。
所以呢
可迁移的思维模型
- 【耐用】风险打分 + 阈值分流：把「这事要不要人来看」从每次凭感觉，变成按一个可复算的分数自动路由。适用范围远超代码——需求评审、内容摄入、决策分诊、甚至家里的采购决定。
- 【耐用】阻断项与风险分必须分离：分数低只代表「不危险」，不代表「可以过」。任何关卡都该有两段输出——风险几分 + 有没有硬阻断。
- 【耐用】规模不等于风险：决定风险的是碰了哪里、能不能撤回、验证够不够，不是改了多少。
- 【耐用】可逆性是风险的第一性维度：能一键撤回的事，可以放手让系统自己决定；撤不回来的事，再小也值得停下来。
- 【耐用】打分必须附证据（她那句 "publishes the evidence to the risk"）：没有依据的分数既不可信也不可审计，改都不知道从哪改。
- 【耐用】越内部、越碰要害的 agent，越需要评测集——直觉上人们只给面向客户的 AI 跑评测，实际反了。
- 【会过期】具体的工具选择（Eve / Chat SDK / Chrome browser use 好不好用）：这一层半年就换一轮，别把它当结论记，记住的是「配置可以外包给浏览器操作」这个动作。
- 【会过期】「bot 满足不了仓库的必须人批规则」：这是当下平台规则的限制，GitHub 明天就可能给 bot 开一个合规的批准身份；别把流程设计建立在这个限制上。
- 【会过期】24 / 25–64 / 65 这三个具体数字：她自己都说「这些阈值不是我定的」，换个仓库、换个模型就该重标。该抄的是三档分流这个结构，不是这三个数。
判断更新
- 你原本可能把「关卡缺执行点」理解成关卡不够严、缺一个强制卡口。这期给的更新是：执行点的本质是分流，不是拦截。 一道只会拦、不会放的关卡，等于没有关卡——因为它一定会被绕过。
- 你原本可能默认AI 产出需要更多人工兜底。Intercom 的数据（快 5 倍、回滚率更低）说明这至少不是必然。真正该增加的不是人工次数，而是证据密度：打分、依据、评测集。
这周的一个赌注
把你评审环节现在靠意见承载的判断改写成六个 0–20 分的打分项 + 一张三行的领域风险表（文案说明＝低 / 业务逻辑＝中 / 库存结算税费权限＝高）+ 一张单独的硬阻断清单，然后只跑影子模式：拿最近 10 份 PRD 打一遍分，把「agent 给的分 / 人实际有没有打回 / 打回的真实原因」记成三列。
一周之内做得完，而且做完之后你手里第一次同时有了三样东西：阈值该定在几分的依据、哪个维度是废的、以及那份你一直缺的可验证证据。 别急着上分流——先让分数和现实对上账，这是她那套东西在你的场景里唯一负责任的抄法。