这一期相关度很高，而且是罕见的正面撞上：他讲的「把一个通用 agent 装进一家具体企业」，几乎就是你在 ERP 里做的事；他讲的「客户诉求就是待造的产品功能」，正是你每天在需求收口时要做的那个判断。
Holdwell ERP 产品线 + 多-Agent PRD 工厂
① 「什么时候把活交回人类」不是异常处理，是配脑子的四件套之一
- 怎么做的：Decagon 配 agent 脑子时，坐下来问客户四件事——用户问 X 该怎么答、品牌用什么口吻、agent 能代表用户执行哪些操作、「哪些用户意图你其实是希望 agent 直接 handoff 给人工的」。这四件是并列的：交回人类的规则和语气、权限一起，在第一次配置时就谈定，不是上线后出事再补的兜底。他们敢这么早谈，因为这本来就是「培训一个新员工」的一部分——你不会等新人捅了娄子才告诉他「这种情况要找主管」。
- 你可以怎么做：你那套三驾马车 PRD 工厂里最容易被跳过的正是这一层——每个角色的输入输出、碰撞环节你都定义了，但「这个 agent 在什么条件下必须停下来找你」多半是隐含的。挑你跑得最多的那个角色（比如出独立初稿那个），在它的 agent 定义里加三行：必须交回人类的意图清单（涉及跨线字段定义、涉及既有实体改动、需求方口径互相打架）、交回时必须带的东西（它查到了什么、卡在哪个岔路口、它建议的两个选项）、交回后谁接。写死在 agent 定义（
.Codex/agents/*.toml）里，而不是靠你每次盯着看——这比再加一轮碰撞值钱，它把「碰撞协议纪律靠自觉」的一半变成了 agent 自己的停止条件。
② 「一个客户诉求 = 一个还没被造出来的产品功能」——这就是需求收口的判据
- 怎么做的：他说这点重要到「真希望给它单独做了一页幻灯片」：FDE 和产品工程完全等同，同样的招聘标准、同一条汇报线、常常同一支团队。理由只有一句——「当我跟《财富》前 20 强客户聊、他们说出一个痛点时，那往往就是一个需要被造出来、需要被排进优先级的产品功能。」配套动作是：不记录需求，而是判断「A 提了这个，两周后 B 一定也会提」，然后赶在 B、C、D、E 开口前一起解掉。
- 你可以怎么做：给需求收口加一个只有两问的分诊闸门，放在写 PRD 之前。第一问「这个诉求会不会在两周后从另一个业务方嘴里再冒出来一次？」第二问「如果会，我现在打算做的东西能不能直接给到他？」两问都「是」→ 它是产品能力，进主线排期；第一问「否」→ 老实做成一次性定制，但在需求台账里打上「一次性」标记并记下日期，同类标记攒到第三个，就说明这其实是个没被识别出来的能力。这个判据便宜、可执行、不需要你先想清楚架构，而且天然帮你把「某个客户的特殊玩法」和「平台该有的能力」分开——正是你需求收口时最难下的那一刀。
③ 「一旦有事非得工程师亲自动手，就该反推回产品」+ 定制变自助
- 怎么做的：Decagon 的信条是「agent 应该完全靠自然语言就能配置出来」，由此推出：只要出现某件事非得工程师亲自动手，它就该被反推回产品里去。疤是集成——早期一个个手写，写到第 25 个受不了了，干脆做成自助，于是原本要写代码的活儿客户自己就能配。口号：定制变自助。
- 你可以怎么做：把「工程师」换成「你本人」，这条立刻变成元约束级的工具——只要某个环节非得你亲自上手，它就该被反推回你的体系里去。接下来两周，每次你手工介入 PRD 工厂（补一段背景、纠一次口径、手动串一次上下游），只记一行「我补了什么」。两周后看这张表：出现三次以上的那一类，就是下一个该做进模板、沉进共享定义、或写死进 agent 定义的东西。六条产品线共用的实体定义，最好的沉淀顺序不是「先想全再填」，而是按「我这个月被迫手工解释了几次」排序。
app_incubator（7-Agent 造 App 链路）
把「该做什么」前移，他给了两个可抄的动作
- 怎么做的：一是在第一次对话就把「成功长什么样」收窄并落成白纸黑字——冲哪个指标、走哪个渠道（电话/邮件/短信/WhatsApp）、痛点是什么、理想结果是什么，写下来防止过程中理解偏差。二是他把这归因给 AI：「现在前期得花大量力气在需求梳理上，先把『到底要造什么』对齐了再动手」。
- 你可以怎么做：你的痛点写着「把『该做什么』前移到 agent」，那前移的载体就别再是一段自由发挥的 brief，而是一张成功收窄表，放在设计稿契约之前跑：这个 App 上线两周后我看哪一个数字？用户第一次打开要在几秒内完成哪一件事？做不到什么就算失败？让链路里第一个 agent 强制产出这张表并要你签字，签完才允许往下走。
「几个月才见到价值」正对你的激活/首屏痛点
- 怎么做的：客户会 kitchen sink 式地砸需求，而 Decagon「可以做得任意复杂」，所以他们主动收——先用最快速度证明价值，别搞成几个月才见价值的周期，跑出来了再扩。
- 你可以怎么做：造 App 时把「第一次打开到第一次爽」当成一期唯一目标。功能进不进首版只问一句：它是在缩短证明价值的时间，还是在延长它？
onehuman_company（一人公司 build-in-public）
- 怎么做的：本片最有传播力的两句都不是抽象道理，而是带疤的：「AI 写代码这么强了，稀缺的技能反而是克制」（诱惑原话是「客户催得紧，我干脆丢给 Codex 或 Claude Code 让它直接写出来算了」），以及「手写到第 25 个集成才受不了」。他还给了拒绝走捷径的成本理由——一次性拼出来的东西会变成「一堆 prompt 加补丁的黑盒」，太脆了。
- 你可以怎么做：两句都能变成验证体选题，且都能过弹药库闸门（删掉你的判断和实测就不成立）。其一，「大佬说 AI 时代最稀缺的是克制，我用 drizzle tech 试了两周」——把上面那张「我手工补了什么」的表当证据，讲清哪几次你忍住没让 agent 一把梭、当天慢了多久、两周后省回来多少。其二，「我的第 25 个一次性定制」——把台账里打了「一次性」标记的拉出来，讲同一类东西重复到第几次才值得做成能力。两篇都自带「可抄物」（两问分诊闸门、手工介入记录表），标题封面都能前置。
Personal Thinking（这本第二大脑）
- 怎么做的：Decagon 从 50 到 500 人后，重心从「拼」转向「设计这套系统」——对跨交付的知识共享变得非常严格，一定要让一线的人把信息回流到平台，「服务了客户 A，就把这份改进带给客户 B」，每次接触都在复利。
- 你可以怎么做：你的一线就是每一期总结报告。一篇总结如果只停在自己的文件夹里，它就是一次性定制。 给摄入 SOP 加一条硬动作：每期归档时必须往对应主题的地图里回填至少一条，且必须写清它和已有哪条笔记冲突或补强——只有产生了「和旧知识的接口」，这次输入才算回流到平台，而不是又存了一份。
StockHelp / 你的价值投资视角
- 怎么做的：这场演讲无意中给了两个判断软件公司是不是「卓越生意」的具体镜头：一是 land and expand 是否真的在发生——Hertz 先来卸复杂客服工单，落地后靠已打通的后台集成，扩到「合约该续约时主动联系客户」这种带营收的场景；二是定制工作有没有被产品化——手写第 25 个集成后改成自助，是毛利率和可扩展性的分水岭。
- 你可以怎么做：给软件类标的加两个定性问题：老客户第二年买的东西是不是比第一年多？（扩张）交付里还有多少靠人肉定制？（毛利能否随规模改善）。这两问不进第一阶段的数字面板，但该进你的能力圈笔记——它们比市盈率分位更早告诉你这门生意会不会越做越轻。
更深三角度
该反着用：他有 500 人和一大排跨行业客户，所以「解 A 时顺手解掉 B、C、D、E」杠杆巨大，甚至值得把一个岗位拆成两条专门赛道。你是一个人，服务的是公司内部有限的几个业务方——未来客户数量少得多，「提前平台化」的期望收益也就低得多。所以正确的借鉴是反过来：默认做一次性，用重复次数触发平台化（前面说的第三次），而不是默认平台化。同理，两条赛道你没法拆成两个人，只能拆成两顶帽子或两个时段——上午只做「配脑子」（调 agent、调提示），下午只做「把诉求做回体系」（改模板、改关卡），别在同一小时里来回切。
和你现在做法冲突：两处张力，不替你下结论。第一，他说 AI 写代码变强之后稀缺技能是克制、别一有诉求就丢给 Claude Code 写完了事；而你的打法恰恰是重仓多-Agent 直接产出。产出速度是你的优势，但「快到来不及问该不该做」和你自己写下的「问『该不该做』先于『做多快』」是同一个坑的两面——这一期等于有人拿着 500 人的账单在旁边提醒你。第二，他把 forward deployed 和产品工程合并成同一批人、同一条汇报线，理由是界线已经模糊到不存在；而你的体系是把 8 个角色分得很清、靠阶段和评审串起来。他那套成立是因为同一个人脑子里同时装着客户痛点和产品排期，信息不用传递；你那套的代价正是信息要在角色之间传，而每次传递都在掉信息。要不要在某两个角色之间做一次「合并试验」，你自己判断。
对你的镜子：你体系里最容易被跳过的那一层——「什么时候该把活交回人类」——之所以一直没写，多半不是因为 agent 足够可靠，而是因为你还没有被迫定义「什么算失败」。Decagon 敢在第一次配置就把交回规则谈定，是因为同一场对话里他们已经把「对你来说成功是什么样子」收窄成了白纸黑字。先有成功的定义，才有交回的条件；反过来，这层写不出来，通常说明上一层还是空的。
所以呢
可迁移的思维模型
- 【耐用】定制变自助——「只要某件事非得某个稀缺的人亲自动手，它就该被反推回系统里」。在 ERP、在第二大脑、在你一个人的公司里都成立，因为它本质是「稀缺资源该被系统吃掉」，而你的稀缺资源是精力，不会变。
- 【耐用】一个诉求＝一个待造功能，判据是「会不会有第二个人问」。比任何优先级评分卡都便宜，且和你「杠杆 > 工时」的操作系统同源。
- 【会过期】agent builder / agent software engineer 的两条赛道分工。它完全建立在「今天 UI 配得动一部分、配不动的要工程师上」这个边界上——边界一年内就会移动。别当组织真理，只当当下的一张地图。
判断更新：你以前可能觉得「什么时候交回人类」是可靠性问题、等 agent 更强就自然消失。这一期的反例是：在一家把 agent 卖给《财富》前 20 强的公司里，它反而是最先被谈定的配置项之一——因为它压根不是技术兜底，而是责任边界。这件事不会随模型变强而消失，只会变得更贵。
这周一个赌注：只押一件——挑你跑得最多的那个 agent，给它写上「必须交回人类」的三行规则（触发条件 / 交回时必须带什么 / 交回给谁），同时开一张「我这周手工补了什么」的记录表。一周后用这张表决定下一个该被做进模板的是什么。两件事在同一个逻辑上：先让系统知道自己什么时候不行，你才有资格谈规模化。