这期是 5 支里跟你最对路的一支。Fiona 管的恰恰是「多个 agent 替人干活、人来验证和把关」这件事的产品工程化——这正是你 Holdwell 的多-Agent PRD 工厂、app_incubator 造 App 链路天天在啃的题。下面按项目对。
Holdwell ERP（多-Agent PRD 工厂）
1 ·「把『什么是好』写成框架塞进 repo，让 Claude 对照验证」直接解你「产出可验证」的痛点
- 怎么做的：Fiona 说去年都还没有 Claude Code Reviews、人工 review 是最大瓶颈；他们的破法不是堆人，而是「越能把『什么是好』的框架自动化地检查出来越好——你给 Claude 一个框架去对照验证，它做得非常好」，具体动作是「把 spec 也提交进 repo，并让 spec 和代码经常同步更新」（例：给内容设计加了一套评分标准 scale）。→ 详细
- 你可以怎么做：你的痛点是「碰撞协议纪律靠自觉、agent 产出缺可观测/可验证」。把碰撞与评审每个环节的「过/不过」判据写成一份机器可读的 checklist（spec）放进仓库，让评审 agent 拿这份 spec 去逐条打分、输出「哪条没过 + 证据」——而不是靠人读 PRD 主观判断。这把「软门」变成「Claude 能对照的硬门」，可验证的证据就是那份对照打分记录。
2 ·「bad vs sad」两档框架——给你的碰撞与真人评审加一个"严重度分层"
- 怎么做的：面对很多不同产品界面、一堆原始指标时「很难判断这个数字到底算好还是不好」，所以她自创高层框架：bad = 不可恢复的严重错误；sad = 可恢复的痛点；关键洞察是「sad 一个个堆起来，整体往往演变成 bad」；而且让每个团队自己针对负责的界面去定义 bad/sad（高 agency）。→ 详细
- 你可以怎么做：你三驾马车的碰撞意见和真人评审的回炉意见往往一锅炖、看不出轻重。给评审产物加一层 bad/sad 标记：bad = 阻断上线的硬伤（实体口径冲突、跨线定义打架），sad = 体验/一致性小瑕疵。规则是「bad 必须清零才放行，sad 累积到阈值也升级为 bad」——这给你「意见回炉的闭环」一条清晰、可自动判定的红线。
3 · routines = 你那个「把『该做什么』前移到 agent」的现成形态
- 怎么做的：routines 的本质是「以前我顶多自己生成几个 prompt；现在像是有个 agent 帮我生成那些 prompt 和 PR」——她设一个 routine「盯着反馈渠道、发现 bug 就把能顺手搞定的打磨修复做掉」，醒来就有可 review 的 PR。抽象层级在「同步敲 prompt → 异步起多个 prompt → routine 替我派生 agent」一路上移。→ 详细
- 你可以怎么做：你一直想「把该做什么前移到 agent」。别再让自己手写每个环节的启动 prompt——做一个「碰撞协议调度 routine」：它读上一环节产物、自动判断下一步该唤起哪个角色（该起独立初稿、该互看碰撞、还是该合成定稿）、生成那个角色的输入、把结果摆到你面前等验证。你的角色就从「写 prompt 派活」上移到「看 routine 派生的结果、做 go/no-go」。
app_incubator（7-Agent 造 App）
4 ·「监控+测试 > 花更多时间评审」+「为 agent 闭环」
- 怎么做的：Lenny 提炼的核心收获是「把控质量最好的工具是监控和测试，而不是花更多时间做评审」，因为速度快到根本盯不过来；它呼应「为 agent 闭环」——让 agent 知道成功长什么样，于是「我们自己来修」。投入重点放在 eval/测试/监控上。→ 详细
- 你可以怎么做：你的「设计稿即工程强制契约」其实就是一种「成功长什么样」的定义。把它再往前推一步——给造 App 链路配一组自动 eval：Chrome MCP 截图后对照 Figma 设计稿自动比对（间距/层级/激活态），不符就让 agent 自己改。这样首屏/激活体验的把关从「你人肉看」变成「agent 闭环自修」。
5 ·「revisit 当初没成的尝试」——模型升级后旧失败可能已变能力
- 怎么做的：「我之前想自动化某件事、Claude 当时还不够格；到下一个模型，诶，现在就够用了——所以要时常回头重试当初没成的尝试」；配套 Lenny 的高频建议「做一些当下几乎能跑、卡在能力边缘的东西，模型一追上你就遥遥领先」。→ 详细
- 你可以怎么做：给 app_incubator 和 Holdwell 各建一个「当前模型还做不好的尝试」清单（哪一步 agent 还经常翻车），每次大模型更新就重跑一遍。你单兵作战、精力稀缺，这份清单让你不必凭记忆，新能力一到位就能第一时间把卡点变成自动化。
Personal Thinking（这本第二大脑）
6 ·「明确授权砍掉不再为你服务的流程」+「JIT 即时规划」治你的摄入 SOP 与信噪比
- 怎么做的：团队文化里很重要的一条是「明确授权大家砍掉不再服务你的流程」；她刚加入时引入「六个月路线图文档」，三个月后发现「我们还在参照它吗？变化太大了」，于是把自己引进的东西亲手改掉；现在用「JIT 月度规划」——连文档都没有，一张小表 + 每周核对，极度聚焦。→ 详细
- 你可以怎么做：你这本第二大脑的痛点是「摄入 SOP 重、信噪比」。拿这条当季度自查：挑一个你做起来最发怵/最手工的环节（比如每支视频都要人工提炼原子笔记），先问「它还有存在意义吗、能不能更自动化」。规划上也别给副业铺六个月大计划——一张「本月就推这几件」的小表 + 每周一次「还作数吗」核对，正好对上你「精力是元约束」。
xiaohongshu_momorain（一个人的增长团队）
7 ·「指标会过期，别戴眼罩盲追」+「卖家数量 vs 超级卖家」
- 怎么做的：Marketplace 早期紧盯「卖家数量」，但某地区卖家少、人们却在找到想要的东西（真正目标），原因是有一批「超级卖家」；差点因为「卖家数量」这个指标误判扩张。结论：「不管什么指标，永远盯着点、别盲目追随一个『曾经合理』的指标，连指标本身都可能要换」。→ 详细
- 你可以怎么做：你那张「带红线的指标盘」空着没在跑。先别纠结追哪个虚荣数（粉丝数=你的「卖家数量」陷阱）。先把盘搭起来跑数，再像她那样问「这个数真的导向我的目标吗」——你的目标是「决策型生活记录者」的影响力，那真正的「超级卖家信号」可能是收藏/保存率、单篇带来的私信咨询，而非涨粉。
8 ·「分享一件真改变你生活的用例」是最低门槛的内容钩子
- 怎么做的：要在 AI 鸿沟上撕开口子，她的办法是「从一件你真正觉得给你生活带来有意义改变的事说起」；Lenny 举例自己用 Claude 帮儿子填夏令营表格、发推后一堆人「我都没想到能这么用」。她自己也承认开口「有点尴尬」，但「最后总能玩得很开心」。→ 详细
- 你可以怎么做：你做家居号、又是重度 AI 用户，但「PM 思维/AI 这张牌没打」。一条低成本选题：把你用 AI 解决某个具体家居/生活决策的真实过程拍出来（比如让 Claude 横向比价/做选购市场分析，正如视频里餐厅老板做菜单定价那样）——既是你独有的「不公平优势」，又天然是「我都没想到能这么用」的钩子。
投资视角（StockHelp / 你本人的价值投资）
9 ·「潜在需求」是一种可迁移的选股/看赛道镜头
- 怎么做的：Anthropic 总能早押大机会，关键是紧盯「latent demand（潜在需求）」——「看人们为了把某件事跑通而绞尽脑汁、各种折腾的地方」，那里往往藏着可以做成顺滑体验的大机会（编程、知识工作 Cowork、小企业都是这么来的）。→ 详细
- 你可以怎么做：作为价值投资者，把这条当一面镜子看你 watchlist 里的公司——它是在满足一个「用户正各种折腾、绕路硬凑」的潜在需求，还是在卷一个已饱和的存量市场？前者是更可能扩张天花板的「卓越生意」特征。Fiona 那句「token maxing 本质上跟代码行数一样是动作不是结果」也提醒你：看一家 AI 公司别被「烧了多少 token/发了多少功能」迷惑，盯它有没有导向真实结果（留存、付费、ROI）。
更深三角度
- 该反着用：Fiona 资源极厚——免费无限 token、几百号工程师、Anthropic 自己人当首批用户做极快反馈。你是单兵 + 精力稀缺。所以她「跑一个接全公司仓库/Slack/指标的远程会话」你学不动，但内核可反向缩小：你也给自己跑一个接住你全部项目仓库的会话，每周一次「回头看看」——把她的「管 500 人全局视野」缩成「管你 6 个副业的全局视野」，对抗你最大的敌人「失焦」。
- 和你现在做法冲突：你的 PRD 工厂偏好「重流程、多环节、碰撞评审」求稳；她反复在喊「砍掉不再服务你的流程」「六个月规划太长、改 JIT」「零失误说明你太慢」。这是真张力——不替你下结论，但值得你诚实问一句：你那套六步碰撞重流程，有没有哪一步其实早就没人参照了、只是惯性还在跑？
- 对你的镜子：她从「管 500 人」主动跳回「IC 工程师、亲手修第一个 bug、让 Claude 当入职搭子」，理由是「不每天活在产品里就会和手感脱节」。你是 8 人 PM 之一、又在自建一堆 app——这面镜子在问你：你是更多时间在「写文档/搭流程/管 agent」，还是真的在亲手用自己造的东西？ 你的「不公平优势」恰恰来自后者。
One Human Company 新号（2026-07 回填）
1. 「瓶颈从写转向验证」是你 B 支柱的顶层叙事，也是一篇 C 类选题
- 怎么做的：Anthropic 工程师平均每季度交付代码量是之前的 8 倍（"平、平、平，然后砰地冲上月球"），Fiona 说瓶颈因此从"写"转到"验证"；她的解法是把"什么是好"写成机器可读的框架进 repo 让 Claude 对照打分，再配"bad/sad"两档分层——bad 清零才放行、sad 攒够也升级成 bad。
- 你可以怎么做：候选标题《Claude Code 的 PM 说"代码 8 倍了，瓶颈在验证"，一人公司的我把验证外包给了另一个 AI 员工》——在 drizzle tech 实测：给流水线里某个产出环节写一份 bad/sad 判据 checklist，让评审 Agent 对照打分，记录它拦下了几个真问题、放过了几个、误报几次，给判断"AI 验证 AI 到底能信几分"。可抄物是那份 bad/sad 判据模板。闸门自检：没有拦截/误报的实测记录就只是转述 Fiona，不成立——带数据发，能过。
2. routines 派活 = 一人公司老板的每日管理动作（B 支柱最独占的素材）
- 怎么做的：Fiona 的抽象层级一路上移——"同步敲 prompt → 异步起多个 prompt → routine 替我派生 agent"：设一个 routine 盯反馈渠道、发现 bug 顺手修掉，她醒来就有可 review 的 PR。
- 你可以怎么做：你的 9+1 流水线迟早也要从"你手动派活"升到"routine 自动派活"。这个升级过程本身就是连续几篇 B 类内容：《我把自己从 AI 公司的派活岗上裁掉了》——写清 routine 怎么设、翻了什么车（自动派的活哪次跑偏）、你保留了哪个不可自动化的拍板位。这类"老板管理动作自动化"的第一手记录，全网做的人极少，是你 B 支柱 25% 里最独占的一块。
- 对你的镜子：Fiona 说"零失误说明你太慢"、敢砍不再服务自己的流程。你 Phase 0 攒存稿也一样——别把发号仪式感拖成六个月路线图，用她的 JIT 小表：本月就推这几篇，每周核对一次"还作数吗"。
所以呢
- 可迁移思维模型 ①【耐用】「框架化『什么是好』+ 让 agent 对照验证」：与其人肉守门，不如把判据写成机器可读的 spec/checklist 进库，让 agent 去打分。这是你「碰撞纪律靠自觉」的通用解，也是评审产出能自证「可验证」的路子。
- 可迁移思维模型 ②【耐用】「bad/sad 严重度分层 + sad 累积升级为 bad」：任何评审/质量体系都该有这层分层——bad 清零才放行，sad 攒够也阻断。简单、可自动判定、给软门一条硬红线。
- 可迁移思维模型 ③【会过期】「时常重试当初没成的 agent 尝试」：因为模型在指数级进步，旧失败常已变新能力。这条的「会过期」在于它依赖「模型还在飞速变」这个前提；但在未来一两年，它对你这种精力稀缺的单兵格外划算。
- 这更新了你的什么判断：你可能一直把「多 Agent 工厂」的重心放在「流程设计得多严密」。Fiona 的整支访谈把重心挪到了验证（怎么搭一套验证机制确认产物真是你想要的）+ 砍流程（敢杀掉不再服务你的环节）——前者是瓶颈新所在，后者是单兵省精力的真杠杆。
- 这周一个赌注：挑你 Holdwell PRD 工厂里一个最关键的关卡，把它的「过/不过」判据写成一份机器可读的 checklist 进仓库，让一个评审 agent 拿它对一份真实 PRD 跑一遍、输出「哪条没过+证据」——这就是你「agent 产出可验证」缺的那份证据的最小版本。