这一期的相关度高到有点扎心——你在 Holdwell 造的那座三驾马车 PRD 工厂，和 Eno 讲的"软件工厂"是同一个东西的两个尺寸；而他花了大半场在讲的那个瓶颈，正好就是你自己现在最挂心的那条：agent 产出缺少可观测、可验证的证据。
Holdwell 的 PRD 工厂
① 你造的就是一座"软件工厂"，只是信号入口和仪表还没接上
- 怎么做的：Eno 说每个组织都隐含地跑在同一条流水线上——外部信号（客户对话、bug 报告、Slack 里的一句抱怨、高管拍板）流进来 → 有人分诊、排优先级、变成计划 → 计划变成对事实源的改动 → 改动过验证关卡 → 上线 → 上线的东西又产生新信号。他的核心指控是："在大多数组织里，这个闭环的可观测性做得非常差。"人人都在跑它，却没人知道信号在哪一段丢了、计划在哪一段变形。
- 你可以怎么做：你的阶段链条对应的是这条流水线的中段（计划 → 改动 → 验证），但最前面那段"信号流入"你基本没建：ERP 那边的客户会话、工单、群里的抱怨，现在是靠你人肉记住再喂进去的。这周可以只做一件小事——给工厂开一个固定的"信号入口"文件（哪怕就是一个 inbox 清单），让每次开工前的原料是被记录过的，而不是脑子里的。六条产品线的跨线对齐每次都要现场从头对一遍，多半也是因为原料从来没被沉淀过一次。
② agent 产出难验证＝你的"确定性验证回路"太少，这是自主性的真实上限
- 怎么做的：这是全片最硬的一句——"这类长时间运行的高级 agent harness，输出质量跟你能验证它工作的程度是直接成正比的。所以一旦你把大规模验证的能力引进来，你就把越来越高的自主性引进了这个组织。" 他把"agent 就绪度"直接定义成代码库里有多少条只有"过/不过"两种结果的确定性验证回路（linter、类型检查、安全扫描、端到端测试）；回路越密，agent 能独立跑越久、能啃越难的活。他还给了个训练侧的解释：模型后训练靠的是稠密奖励，这些验证信号就是奖励的来源，是它在长任务上不跑偏的依据。
- 你可以怎么做：你的质量把关现在多半是评审意见式的——三驾马车碰撞一轮、真人评审再给评语。按 Eno 的标准，那不算验证回路，因为它没有"过/不过"。把把关拆成两类：能写成脚本判定的（PRD 里必填字段是否齐、每条需求有没有对应验收标准、实体名前后叫法是否一致、跨线影响是否列了），一律降级成机器判定、不过就不许进下一阶段；剩下真需要人判断的，才留给碰撞和真人评审。你的 agent 产出之所以难验证，本质是把关一开始就不是"可执行"的形态。先挑一条最痛的，把它写成能跑的检查，这就是你的第一条回路。
③ 30–40% 一键能修，60% 卡在人的工作流上——别指望前者的经验能套到后者
- 怎么做的：Factory 有工具扫描代码库缺哪些验证回路，大约 30% 到 40% 属于唾手可得——点一下 Droid 说"把这些都修了"，它进去就修好；剩下 60% 涉及工作流的改变。摩擦点他说得很直白："人有时候受不了这些自动化系统那种……'吹毛求疵'的程度。" 所以真问题是"怎么才能在不打断这些人日常开发节奏的前提下，引入这些更严苛的验证策略"。
- 你可以怎么做：你的碰撞协议要真被执行、真人评审意见要真回炉，卡的正是那 60%。先接受一个事实：另外 7 位 PM 不会因为工厂好用就改工作方式，只会因为它不添麻烦才顺手用。 推广时别从"全流程走一遍"开始，从只在一个环节插一道机器关卡开始（比如提交真人评审前必须过字段完整性检查），跑两周，把"拦下了多少次返工"记成数——这就是你要的可观测证据。
④ 交样板，不交包干——而且样板不能太超前
- 怎么做的：Factory 明确不接咨询迁移的活，哪怕能赚不少钱，理由是"我不觉得靠它能把生意做到极大的规模"。他们的交付是先在几个地方做出样板，再让客户自己的团队推广到全公司。配的是 Epcot 类比：Disney 想造一座"未来之城"当全世界的样板，最后虽然变成了主题公园，但后来确实有城市照着他那套集中式交通的想法建了起来。但样板做得太超前就废了——"那是个主题公园，跟真实世界完全不是一回事，我看不出它跟我们今天干活方式有什么关系"。
- 你可以怎么做：这直接对上你"agent 产出缺可观测证据"和"跨线对齐"两条。别拿三驾马车 + 碰撞协议的全套流程去说服团队，那是主题公园；挑一个小到不吓人、但完整跑通的需求做成样板——从信号进来到 PRD 出来到真人评审过关，全流程留痕，然后让别人自己来抄。你要的是那句"哇这也太酷了，把它搬到我这块来"，不是一次汇报式的 demo。
app_incubator
① missions 的形状：人只在规划阶段出现，其余全靠"完成标准"驱动
- 怎么做的：Factory 的 missions 是"一套极其精细的 harness，专门围绕处理那些极难、但可被验证的知识工作"。运转方式是——除了规划阶段几乎不需要人介入：你进去说"我有一个边界很清楚的任务，我知道'解决'的标准是什么"，然后"一路推动推理这个杠杆，直到任务完成"。人的全部输入被压缩进了两件事：任务边界 + 完成标准。 由此他给出那句判据："只要你能把任何问题重新表述成一组用来验证它的系统，那这个问题今天就能用 AI 解决。"
- 你可以怎么做：你在 app_incubator 里的目标——"把该做什么前移到 agent"——按这个框架其实要反过来看：前移的不是"该做什么"，而是"做完了算什么"。给七个角色里的每一环补一份可判定的完成标准（这一步产出必须包含哪些文件、哪些字段、能不能通过一次自动检查），比继续优化角色提示词收益大得多。你那条"设计稿即工程强制契约"已经是这个思路的雏形了——它其实就是一个 validator，把它扩展到链路的其他环节。
② 约束越多，反而越自主——先自动化那些边界最收敛的东西
- 怎么做的：两个反直觉的观察。一是Factory 有些客户的代码库比 Factory 自己还自主，"因为他们的运行方式受到的约束更多"。二是他们内部那个叫 legal droid 的法务工作流已经基本 100% 自主维护，反倒是自家核心 harness 闭不了环——终端界面里的闪烁这类视觉问题还没有校验器能验，"要造出能验证这类硬骨头问题的系统，本身就是一项工程任务"。
- 你可以怎么做：别从"首屏体验/激活"这种最主观的部分开始追求自动化——那是你的 flickering，验不了。先把最枯燥、边界最死的环节整个交出去（脚手架生成、路由与状态命名规范、埋点清单、文案键值对齐），把它做到近乎 100% 无人值守。这既省你精力，又能积累"这条链路真的能自己跑"的信心。
Personal Thinking（这本第二大脑）
- 怎么做的：Eno 的软件工厂闭环，最后一环是"上线并被监控的软件会产生新的信号"，而他说这个闭环在大多数组织里几乎没装仪表。
- 你可以怎么做：你的摄入流水线也是同一条——视频/书流进来 → 总结 → 原子笔记 → 主题地图 → 影响你的判断和项目 → 再决定下一批看什么。但最后那一环（笔记到底改变了什么决定）没有任何仪表，所以信噪比只能靠感觉。轻量的做法：在速览面板上加一行"本月哪条笔记真的改了一个做法"，只记一条也行。信号回流没接上，摄入就永远只是摄入。
onehuman_company（一人公司账号）
- 怎么做的：Factory 敢把自家难看的数据摊开讲——自己只有 15% 到 20% 在自主运行、自主率 80% 出头（"在被人打断之前，AI 完成的动作与人完成的动作之比"），而且自家核心产品闭不了环、有些客户比自己还自主。这种"给出定义 + 报出真实数字 + 承认自己没做到的部分"，正是 build-in-public 最有说服力的形态。
- 你可以怎么做：这是一条现成的验证体选题——"大佬说 agent 就绪度＝验证回路密度，我拿 drizzle tech 实测"：定义你自己的两个数字（哪几条链路在自主跑、被你打断前 agent 完成了几步），公开报出来，再老实说哪一环你至今闭不了环（多半是审美判断）。可抄物很明确：那两个指标的定义方式 + 一张"我的验证回路清单"。过弹药库闸门也没问题——删掉你的实测数字这篇就不成立了。
StockHelp（关联偏弱，但有一条真能用）
- 怎么做的：Eno 提到有金融机构用这套东西优化股票研究——给不同股票建模、分析、比较，搭出一套能反向传播、甚至据此交易的系统。更值得拿走的是那句方法论：把问题重述成"一组用来验证它的系统"，问题就能被自动解掉。
- 你可以怎么做：你的看板到 Phase 2 要出信号，卡点从来不是技术，是**"该不该买"你还没写成可判定的东西**。按这个框架，先别写信号逻辑，先写判据清单：市盈率处于五年分位的哪一档、公允价折价多少、这门生意在不在你的能力圈（用一份你自己列的白名单来判定）、安全边际够不够。判据写成能跑的检查，信号自然就长出来了；判据还是模糊的，加多少指标都没用。
该反着用
Eno 的语境是四万五千人、上万个代码库、必须"一键自动装配"，所以他讲的是把整条流水线全面仪表化。你是一个人扛正职加几个副业，精力是你最稀缺的东西——照抄"全面建设"就是给自己挖坑。正确的借鉴是把他的结论倒过来用：他因为规模太大所以必须处处装验证，你因为精力太少所以只能装一处，那就必须挑准最痛的那一处。他的"built, not bought"要的是组织真金白银的投入；你的版本应该是"只建一条，跑通了再建第二条"。同理，他要 deployed engineer 进客户那儿去教一整套成熟度模型，你根本没有"客户"——你的团队是同事，教的成本远高于做一个好用到别人自己来抄的样板。
和你现在做法冲突
你的 PRD 工厂走的是多角色互审的路线——三驾马车独立初稿、互看碰撞、真人评审层层把关。Eno 的判断和这条路线是有张力的：输出质量正比于"可验证程度"，而不是"被审视的次数"。碰撞轮次再多，它给出的仍然是意见，不是"过/不过"；按他的框架，再加一轮互审不会提高自主性，只会增加一次需要人参与的中断——而中断恰恰是他那个"自主率"指标的分母。这里有个你迟早要回答的问题：碰撞和评审里的检查项，有多少比例其实可以降级成脚本判定？降级之后，你还会不会觉得"质量把控变弱了"？ 这个我不替你下结论——因为你做的是 PRD 不是代码，PRD 的很多质量确实难以机器判定，Eno 自己也承认视觉类问题他们至今验不了。但你至少该知道自己现在站在哪一边。
对你的镜子
Eno 有一句话是直接对着你说的："一家公司的工程师，从直接操作软件，变成直接维护和管理一套造软件的系统。这种抽象层级上的跃迁其实非常难……哪怕是非常有思考力的软件工程师，在做这个转变时都会经历一段学习曲线。" 你已经不在写 PRD 了，你在维护一台写 PRD 的机器——但你评价自己那一天干得好不好，用的可能还是"今天写出了多少东西"的旧尺子。旧尺子会让你在该去修机器的时候，忍不住自己动手把活干了。顺带一提，他列出的"最适合干这活的人"里，第二类就是想快速变得非常技术的产品经理——这条赛道你已经站在上面了。
所以呢
可迁移思维模型
- 【耐用】可验证性是自主性的上限——你能把多少事情定义成"过/不过"，就能放手多少。想提高任何一套自动化的产出质量，先别调它，先造能判它对错的东西。
- 【耐用】把问题重述成"一组用来验证它的系统"——这是一个通用的解题动作，对 PRD、对造 App、对选股都成立。解不动的问题，往往不是能力不够，是"完成"还没被定义清楚。
- 【耐用】稠密奖励——频繁的小反馈优于一次性的大验收。这条对带 agent 成立，对你自己做副业同样成立：把长周期项目切成能频繁自我判定的小段，你才不会跑偏。
- 【耐用】约束越多越自主——边界收敛的东西最先能全自动。挑自动化对象时，优先选最枯燥、最有规矩的那块，而不是最想省事的那块。
- 【耐用】样板要跑得通但不能像主题公园——推广一件新东西，做一个刚好够先进、又够贴近现实的样例，比讲一百页方法论管用。
- 【会过期】30–40% 一键可修 / 60% 卡在工作流的具体比例、Factory 自身 15–20% 与 80% 出头这两个数字、missions 这种产品形态、以及"每个 SDLC 环节都是十亿美元生意"的市场判断——这些是 2026 年这个时点的快照，一年后大概率都不一样了。
判断更新
你原本大概会把"agent 产出难验证"归为执行力问题（没顾上做）。这一期给的是另一个诊断：它是形态问题——你的把关从设计之初就不是可执行的形态，所以再有执行力也落不了地。同样地，"多-Agent 工厂产出质量不稳"这个感受，答案不在于换更强的模型或写更长的提示词，而在于你能验证的比例太低。
这周一个赌注
从你的 PRD 工厂里挑一条最常出错的检查（我猜是"每条需求有没有对应的验收标准"，或者"实体名前后叫法一致不一致"），把它写成一个真能跑、不过就拦住的脚本，接在流程某一步的出口上。只做一条，不要做一套。跑一周，记两个数：拦下了几次、你有几次想绕过它。第一个数就是你要的可观测证据，第二个数会告诉你那 60% 的人性摩擦长什么样。