本期没有固定的 lightning round；收尾以两个「尖锐话题」代替——激进未来观（木头桌子 / 无键鼠，见主题 15）和 agent 优先的产品与品牌（一切皆 API endpoint，见主题 16）。最后 Peter 以「那我这就去开几个 agent 跑起来了」收场。→ 详细
这期几乎是为你的两条 agent 生产线量身讲的：agent 自我验证、eval 什么时候建、multi-agent 怎么编排，全是你正在踩的坑。逐项对：
他怎么做的：Jared 的自查机制朴素到近乎简陋——不搞评审框架，而是让 agent 给自己建一套 sanity check（数据召回/工具使用/回复长度各一批示例），跑完产出一个 markdown 文件，agent 读它、对比新旧输出、自己判断要不要改。验证被做成了 agent 循环里的一个工具，而不是循环外等人来执行的流程。同时 Devin 的哲学是「把任务拆成可验证、可测试的小块」——每个子 agent 写完必须运行、截图、自查，「验证过」是产物的一部分，不是附加步骤。
你可以怎么做：你的碰撞协议痛点恰恰是「纪律是写在 agent 定义里的规矩，agent 可以路过不停」。照搬他的做法：每个环节落成一个可机读的产物文件（比如碰撞环节出一份 collision_report.md：补强/修正/第 3 案三件是否交齐 + 证据行），下一环节的第一步就是「读上一环节的报告文件，不存在或缺件就停下打回」——把协议从「要求」变成「工具调用 + 文件存在性检查」，强制点就有了。真人评审回炉同理：让 agent 把每条意见的归属与处理落成报告，人只看报告，不看原文。
别只顺着听，还要反着用：Jared 说「最强团队没有 eval 集直接上生产」「别卡在 eval 上」——注意他的语境是探索期的新产品（他自己的助理项目也是先搭 harness 后建 eval）。你的 PRD 工厂已过探索期、正卡在「agent 产出缺可观测/可验证」，处在他说的「最后一公里」——此时该反过来加验证，而不是引用他来偷懒。他真正的顺序论对你有用：先让链路跑通出活（80%），再把验证做厚（最后一公里花一年）——别在澄清环节就想把 100% 的验证都设计完美。
他怎么做的：他警告最大错误是把「极其具体的 prompt 指令」当资产——模型半年就追上来；行业已从「巨大 DAG、prompt 连 prompt」走出来；新关键是 tool engineering：给对工具，prompt/skill 降级为「什么场景用什么工具」的小抄。fanout 的两个理由也值得抄：并行提速 + 每个 agent 的 context 很小、专注一件事（「agent 专注干一件事时表现好得多，人也一样」）。
你可以怎么做：拿这三问体检你的 7-Agent 链：① 链里哪些环节是在补「模型当时不够聪明」的洞（步骤指令、格式管教）？这些按「会贬值」处理，定期删；哪些是真正的契约（设计稿即工程强制契约、MCP 工具封装）？这些是资产，往厚里投。② 每个 agent 拿到的是「工具 + 原则」还是「三千字步骤书」？往前者迁移。③ 你想「把该做什么前移到 agent」——Jared 的 manager-agent 模式就是答案：一个主 agent 决定派活、要求每个子 agent 交回「截图/自查报告」再汇总，人只做抽查（那位 CTO「只看 Devin 录的视频就 push」就是终态画面）。
冲突点，值得诚实面对：你的「设计稿即强制契约」本质是「push 模型到指定方向」，与「let the model cook」有张力。判据用他自己的话拆：契约锁结果（长什么样、过什么验收）没问题；契约锁过程（第几步干什么）才是逆重力。检查你的契约里有多少其实是过程锁。
他怎么做的：他正做一个「OpenClaw 风格」助理：有心跳、主动通知你，而不是等你来问。加上 automations 思路（Datadog 告警自动触发 agent），本质是：触发权从人移到系统。
你可以怎么做：你的 CoS 现在是「你想起来才去对话」的被动外脑。给它一个心跳：定时（每周思考日前夜、每月）自动跑一次「宪法 vs 本周实况」的对照，主动把违背原则的信号推给你——比如「本周三个副业都动了，违反聚焦元约束」。守门人只有主动敲门才算守门。
「工程师带来品味和高层决策，其余交给 agent；人不该是瓶颈」+「9 小时不间断」「GPU 闲着就是亏钱」——这就是你「杠杆 > 工时」的 agent 时代版本。镜子照的是：你现在派活给 agent 后，自己还常做「盯进度」这种瓶颈动作吗？CTO 通勤派活、到岗只抽查的画面，是单兵多线者的理想日常。另一句照向 momorain/drizzle：「最后 10% 亲自看产出，否则就是把 slop 撒得到处都是」——量产内容线的底线。
（StockHelp、小红书号与本期无直接关联，略。）
怎么做的：Jared（Cognition）的自查机制朴素到近乎简陋——不搞评审框架，让 agent 给自己建一套 sanity check，跑完产出一个 markdown 文件，agent 读它、对比新旧输出、自己判断要不要改；Devin 的子 agent 写完代码必须运行、截图、自查，"验证过"是产物的一部分。他自己的助理项目"几乎没在 eval 上花时间——让 Devin 建 eval、让 Devin 自己看结果自己迭代"。
你可以怎么做：一篇现成的 C 类——《Cognition 的人说"让 agent 自查工作只要一个 markdown 文件"，我在 drizzle tech 试了两周》：给造 App 链路的交付节点加"agent 产出自查报告 + 下游开工前强制读报告、见 FAIL 即停"的闭环，交被打回的真实案例数、返工率变化、多花的 token 账。这同时是 B 支柱"AI 员工绩效"最独占的素材：自查报告就是 AI 员工的周报。闸门自检：机制是公开的，你的打回案例和账单才是骨头。可抄物：自查报告 markdown 模板。
怎么做的：他的开局警告——"别逆着重力构建"：极其具体的 prompt 指令是临时拐杖，模型半年就追上来，"它们不会成为你公司的护城河"；给对工具 + 原则，让模型自己发挥。判据可拆成：契约锁结果（长什么样、过什么验收）是资产，契约锁过程（第几步干什么）是逆重力。
你可以怎么做：一篇 B 支柱审计贴——《我按"别逆重力"审计了 10 个 AI 员工的岗位说明书：删掉的比留下的多》：把每份说明书按"结果锁 / 过程锁"分类，删掉过程锁跑一周，交哪里翻车了哪里反而更好的实录。可抄物：结果锁 vs 过程锁分类卡。这也是你所有 SOP 的保鲜机制——说明书里的"步骤书"每季度都该贬值重审。
怎么做的：他的节奏账："done is better than perfect——做到 80% 可能一小时，最后一公里才难、可能要花一年；但很多人因为想把 100% 全规划好，反而连 80% 都到不了。" 反直觉配料："信不信由你，一些最强的团队就是没有 eval 集直接上生产。"
你可以怎么做：这是第一个 App 的 A 类复盘现成的叙事骨架——按"80% 用了几小时 / 最后一公里卡在哪、花了几倍时间"两段记账，数字反差本身就是钩子；"最后 10% 必须亲自看，否则就是把 slop 撒得到处都是"（Peter 语）顺手就是你内容线和产品线共用的质量底线，可以写成 D 类立场句："一人公司的护城河不在前 80%，全在你亲手守的最后 10%。"
所以呢：本周就做一件事——挑 PRD 工厂里最痛的那一个环节（比如碰撞），把它改造成「agent 产出 markdown 自查报告 + 下游环节开头强制读报告、见 FAIL 即停」的闭环，跑一次真实需求拿到第一份可核查证据；跑通后同样的模子复制到其余环节和 app_incubator 的交付节点。