这期是近期相关度最高的一期之一——不是"AI 很重要"那种泛泛相关，而是你正在做的那件事，被两个已经做完并发布的人从头讲了一遍：一个 PM（Nan）和一个工程师（Jacob），从一份 memo 讲到上线，中间踩的坑几乎逐条对上你 PRD 工厂现在卡住的地方。所以这段写满。
一、Holdwell 的多-Agent PRD 工厂
1）那份 memo 的五件套，就是"一个 PM 怎么把 agent 立项写清楚"的现成模板
- 怎么做的：Nan 在还没有任何技术方案的时候，先写下的只有一个抽象流程——触发事件 → 相应的上下文 → 一套指令 → 在一连串动作上循环 → 给出某种结果。整份 memo 的中心论点就一句话："计算机能替我们干很多活，那就把所有我们不想干的活都甩给计算机。"注意两件事：第一，五件套里没有一个字是关于模型、框架、接口的；第二，他们刻意没写完备的 spec——"我们进这件事的时候，并不觉得自己清楚该造什么，只是说这儿有几个实验、几个可以试的方向，那就动手做吧"。而第一个真实用例，是从一句真实抱怨里捡来的：有人说"我在销售电话里手写了笔记，能不能整段丢进去，把该做的工单抽出来"，Nan 的判断标准只有三条——我知道它有价值、有人直接提过、我们自己工作流里也有这个痛点。
- 你可以怎么做：你的 PRD 工厂现在有三驾马车加碰撞协议的完整流程，入口是 PM 一问一答的澄清，但**「怎么把一次任务交代清楚」还没有定式**——一个 PM 想让这台机器干活，第一步该写什么，仍靠临场发挥。把这五件套做成你的立项单页：这次的触发事件是什么（谁在哪句话之后按下开关）／它该自己去哪儿捞上下文／我给它的指令只有一句是什么／它要循环的动作是哪几个／什么样的产出算完事。刻意把它压在一页以内，先别写角色分工和阶段流转——那些是造机器的人的事，不是用机器的人的事。下一个真实需求进来时用这张单页写一遍，看看你能不能像 Nan 一样，只凭"有人直接提过 + 我自己也疼"就立项。
2）跨线对齐的解法可能不是"把词典编全"，而是"给它一把铲子"
- 怎么做的：这是全片最反直觉、也是 Jacob 唯一亲口称为"原则"的一条："你要尽可能少给它指令。给它能加载上下文的工具，而不是直接把上下文喂给它。"他们不是没试过喂——最早想把 Linear 里所有能做的动作全给模型，结果直接撞上上下文爆掉和幻觉；又试过把数据接口的字段说明书整个丢进去让它自己写查询，"效果也不理想"。最后落到的方案是：给 agent 一个加载 skill 的工具，它按请求自己判断需要哪几个、自己加载，每个 skill 自带配套动作和使用说明。Nan 的补充是这套只有原生 agent 吃得下——"你可以有上百个这样的东西"。Jacob 解释为什么喂多了反而更差：一是它可能根本不需要，二是它会过度强调某些对当前任务其实不重要的点。
- 你可以怎么做：你六条产品线强耦合、跨线联动频繁，跨线对齐的默认解法很容易变成"把共享实体和口径一条条写全再喂给各个角色"——这条路正是 Linear 试过并放弃的那条。换个方向试一次：这周别急着编大而全的实体词典，改成给写 PRD 的那个角色一个"去查实体"的动作——哪怕最原始，就是一个能在现有 PRD 和 ERP 知识库里做全文检索的脚本。然后拿 3 个真实需求跑一遍，看它自己捞回来的定义，和你手写的那份比，差在哪。差的那部分，才是真正值得你手写沉淀下来的东西（而且量会比你以为的小很多）。另外把"skill 里装的不是功能是主张"这句抄下来对照检查你那几份 agent 定义：如果一份定义只是把步骤复述一遍、里面没有一条"我们认为该怎么做"的判断，它就不该单独存在。
3）"agent 产出可验证"缺的不是一次成功演示，是两条腿的评测 + 一条保修范围线
- 怎么做的：Linear 的评测是刻意混着来的——客观那半是确定性检查（"用户说了 in progress，就得保证它每次都把状态设成 in progress"），主观那半用一个模型当裁判去打分（描述结构好不好？该进标题的信息提没提对？）。但更值钱的是三条限制：① 数据集从吐槽里长——"有人说'它这次的反应很奇怪'或者'很蠢，我跟你说说为什么'，最后这条本身就变成了一个 eval"；② 裁判本身要人来核，Jacob 承认这很手工，"也正因为这个原因我们其实用得比较少"；③ 别到处堆——"评测最有价值的地方，是在那些'一致性很重要'的地方去保证一致性。但对 agent 来说，一致性并不总是重要的……不然全是假信号"。发布那条线则是另一把尺：Nan 说有 UI 的功能可以定义成"把所有你原本没打算让它发生的事都消灭掉"，agent 没这个边界，所以改成先定几个核心招牌用例、把这几个做到扎实，其余接受波动——他管这叫"在保修范围内"。Jacob 那句更适合贴在你显示器上："这东西留在内部可以打磨到天荒地老都完美不了。"
- 你可以怎么做：你的工厂缺的正是这套东西的最小版本。第一步只做三件事：① 建一份"翻车台账"——每次你骂 PRD 工厂产出的那一刻，别只是重跑，把"我输入了什么／它给了什么／本来该是什么"三列记下来，这就是你评测数据集的第一批种子，也是"产出可验证"的第一份证据；② 把台账拆成两半，能一眼判死的（该挂的模块挂没挂对、必填字段有没有缺）做成确定性检查，判不死的（需求描述写得清不清楚）先手工看，别急着上模型裁判，Jacob 已经替你验过这条路又贵又要人核；③ 明确写下你的保修范围——PRD 工厂主推的是哪 2-3 条路径，只有这几条必须稳，其余明说"允许波动"。你的评审关口之所以守不牢，很可能是因为它想守住的范围太大了；范围一缩到两三条，关口才有可能真的卡住。
二、app_incubator（7-Agent 造 App 链路）
1）"把该做什么前移到 agent"的答案是：入口不在聊天框里
- 怎么做的：Nan 给所有要做 agent 的公司的建议就一条——先把用户真正想完成的工作流拆开看清楚，"没有人往桌前一坐，一次就把一整天的活儿一把梭做完"，然后找哪里是天然的切入点。他专门点破了那个最容易做错的一步："最显而易见的做法是做个应用内聊天框，然后大家一指——哦，这就是那个 agent。其实那只是跟 agent 交互的一种方式而已……但入口并不在那儿。"真正的入口"在你 Slack 里正在进行的那场讨论里，在你的会议纪要里，在你写项目进展、正在做调研的那一刻"。不这么做的下场他也说得很直白："我干嘛不直接用 Claude 或者 ChatGPT 来干这事，而要用你那个原生 agent？"
- 你可以怎么做：你的造 App 链路现在的入口，本质上还是"你打开一个会话、开始交代"。按 Nan 的框架重新拆一遍：你决定做一个 App 的那一刻，人在哪儿？——大概率是在刷 Mobbin、在看某个竞品、在记一条产品想法、在 Figma 里改稿。那几个才是上车口。挑一个最高频的做一次真实的钩子（比如：想法库里新增一条想法时，自动触发一次"这条值不值得做 + 最小版本长什么样"的评估，产出直接回写到那条想法下面），而不是等你想起来去开一个新会话。这也正好是"把该做什么前移到 agent"这个痛点的具体形态：前移的不是判断，是触发点。
2）"设计稿即工程强制契约"和 Linear 把主张编码进 skill 是同一件事的两个说法
- 怎么做的：Linear 明确放弃了"只提供一个 MCP 接口、你爱用什么客户端连都行"的路线。Nan 的理由是："有一个原生 agent，才能让我们把自己对'什么才是好的产品管理'的观点灌进去。"具体形态就是 skill 里写的不是"怎么建工单"，而是"优先级该怎么定、描述该怎么写"。Peter 的复述更直接：只给一堆工具让人随便用，"他们可能就跑偏了"；agent 带着 skill 和指令，等于把价值观和产品流程注入进去了。
- 你可以怎么做：你已经在做对的事（设计稿是强制契约，不是参考图），但可以更进一步——检查你那 7 个角色里，有几个是"执行者"，有几个是"带主张的守门人"。如果一个角色只是把上一步的产物翻译成下一步的格式，它就是 MCP 式的工具；只有当它里面写着"我们认为首屏该有什么、什么情况下必须打回"，它才是 Linear 意义上的 skill。你的激活/首屏体验痛点，大概率不是缺一个执行角色，而是缺一个对"好的首屏长什么样"有明确主张、并且有权打回的角色。
三、onehuman_company（一人公司 build-in-public）
1）这一整期就是一颗"大佬说 X 我试了"的验证体子弹
- 怎么做的：Jacob 的原则句短得可以直接当标题——"指令给得越少越好。给它能自己去加载上下文的工具，而不是直接把上下文喂给它。"配套还有 Nan 的开场句"你要是给它堆太多提示词，多半反而会把效果搞砸"。这两句都足够反直觉、足够有争议（大部分人正在往反方向卷提示词长度），而且可验证。
- 你可以怎么做：这条能过你的弹药库闸门——删掉你的判断和实测就不成立。做法：拿你 PRD 工厂或造 App 链路里同一个真实任务，跑两版——A 版是你现在那份长提示词，B 版砍到只剩目标 + 一个"去查资料"的动作，其余全删。记录三件事：产出质量差多少、token 花费差多少、你要人工返工几次。标题就叫"Linear 的人说'指令给得越少越好'，我把提示词砍掉 80% 试了一周"。这是典型的 C 类选题，且天然带"可抄物"（那份砍完的提示词本身就是可抄物）。
2）"AI 员工管理成本账"这根支柱，本期给了两笔现成的账目
- 怎么做的：第一笔是降配的正确顺序——Jacob 说他们先把最大的模型怼上去，直到确认这条路真的走得通；然后搭好评测、对"什么算成功"有清晰判据；这时候才开始往下压模型规格，因为已经有框架保证压下来之后依然达标。理想状态是"能干成这活的最小模型，就用那个"。第二笔是结构性省钱：早期他们做了一个很小的路由模型，80% 的用例被路由到一个专门用于建工单的子提示词，其余才交给挂着所有工具的大模型。第三笔是警告："一旦跑这种长时间运行的 agent，成本上的取舍是绕不开的。"
- 你可以怎么做：你的成本账支柱一直缺"方法"而不缺"数字"。把这三笔写成一期方法论 + 实测：先证明可行 → 再建评测 → 最后才降配——重点讲为什么顺序不能反（没有评测就降配，等于闭着眼睛砍成本，省下来的钱会以返工的形式加倍还回去）。然后拿你自己的 agent 链路做一次"80/20 路由"实测：统计你最近 50 次调用里，有多大比例其实只干一件很窄的事？把那件事单独拆出来配小模型，算出省了多少。这一期同时喂饱了成本账支柱和验证体配额。
四、Personal Thinking（这本第二大脑）
- 怎么做的：两条都跟你的信噪比痛点直接相关。一条是 Jacob 的恐惧——模型产 markdown 太在行、写得特别长，"有时候我干脆不看了"，"我特别怕的就是，最后越来越多 agent 生成的 markdown 文件堆进仓库里，而我一个都不看"；Nan 的回应是关键："常有人说这是使用者水平问题，你自己该去读、该告诉它别产垃圾——话没错，但这又回到那个核心问题：默认值是什么？"另一条是那个上报机制：agent 遇到自己没有工具做的事，会主动把这件事报回来，后台自动查重、有则补充无则新建，于是团队那边有"一条源源不断的工单流进来，全都是关于我们还做不到什么的"。
- 你可以怎么做：第一条是把"默认值"这把尺架到你的摄入流水线上——不是靠你每次记得说"写短点"，而是让摘要模板本身就产出短的（你的密度梯度规范已经是这个思路，可以再往前一步：给每份总结加一条"三个月后我还会重读吗"的自检）。第二条更有意思也更好落地：给你的摄入流程加一个"我干不了"的出口——每次转写/拆书跑完，让它单独输出一行"这次有什么我该做却做不到的"（原文没字幕、锚点对不上、某个领域背景不够），自动追加到摄入日志。你现在的入库流水记的全是"做成了什么"，缺的正是这条能力缺口台账——它比成功记录更能告诉你下一个该修的是什么。
五、Chief of Staff apps（软教练质量）
- 怎么做的：Nan 说他们所有评测的焦点，其实不在"答得对不对"，而在**"你有没有听懂用户其实想完成某个任务？还是说你太积极了，跑去做了一堆用户根本没要、又贵又烦人的事？"**最典型的场景是"该不该插话"：Slack 里你正在跟 agent 对话、你追问了一句，它觉得自己能答，内部会走一整套流程判断"我该不该插一句"。他给这类东西起的名字是"使用手感层面的时刻"。另有一个反面案例：有用户管 agent 叫"老兄"，agent 回"我不回复你了，因为你对我不够正式"——Jacob 说这类事得"一点点调进一个非常非常窄的区间里"。
- 你可以怎么做：你的决策外脑最大的失败模式不是"给的建议不对"，而是在你只想说句话的时候给你上了一课。把"该不该插话"直接立成它的第一条质量标准：什么时候只回一句"记下了"，什么时候才拉出宪法原则来对照。判断依据可以很土——你有没有在问句里带疑问词、你说的是决定还是抱怨。这比继续优化"建议本身的质量"回报高得多，因为软教练一旦让人烦，后面再准的建议也没机会被听见。
六、StockHelp / 你的价值投资视角
- 怎么做的：本期埋了一个对软件公司护城河的判断。Peter 问 Linear 创始人 Karri 会不会心疼那些精心设计的界面被 agent 绕过，Nan 说"老实说，不会，我觉得他一点都不介意"——因为客服同事跟 Linear 打交道的全部界面就是 Intercom 插件里那几个控件，"但这非常有价值，因为这是其他所有人开展工作的输入流"。真正的分野在另一句：他们明确放弃了"只提供一个接口、你爱用什么客户端连都行"的路线，因为那样就没法把自己对"什么才是好的产品管理"的主张灌进去。
- 你可以怎么做：给你的选股看板加一个 AI 时代的定性问题——这家软件公司的价值，是在它的界面上，还是在它的"底账 + 对流程的主张"上？如果一家公司被剥掉界面（用户全部改用外部 AI 客户端通过接口访问）就不剩什么，它的护城河在被侵蚀；如果剥掉界面之后，它仍然是全公司工作的输入流和以它为准的那份底账，并且它的主张还能被 agent 执行，那它反而在变强。这不是一条能进你 Phase 1 数据面板的指标，但适合作为你研究一家 SaaS 时的一条固定提问，写进你的能力圈笔记。