← Home NO.25
第 25 期 · AGENT 工程 · 收录于 2026 年 8 月 15 日
运营AI原生工程组织
双人对谈 · 本期速读电台 00:00 / 40:04
TL;DR · 三句话
- 一瓶颈已经转移，旧流程会"悄无声息地不再奏效"（quietly stops working）——当编码（写代码）不再是瓶颈，从规划、评审到组织形态的所有团队规范（team norms，团队内部约定俗成的做事规矩）都得拿出成长型心态（growth mindset，相信能力可以持续成长、旧办法该被新办法替代的心态）重写一遍。 这不是行业第一次换瓶颈：21 世纪初"云"还不存在、一次只能合并 6 个 PR 时，瓶颈是构建队列；云和持续构建来了瓶颈就移走了。如今在 Claude Code 团队，"编码真的已经不是慢的那部分了"，所以上下游流程都得改。 → 详细
- 二Fiona Fung 的核心打法是"Claude 化一切 + 验证左移 + 明确授权砍掉老流程"：Claude Code 几乎每个 commit 都由 Claude 共同署名（co-authored by Claude，提交记录里把 Claude 列为共同作者），团队"用 Claude 构建 Claude、用 Claude Code 构建 Claude Code"，每个 manager（经理/带人主管）都先做一段 IC（individual contributor，一线动手写代码的工程师），代码取代文档成为唯一真相来源（source of truth，团队默认以谁为准的那份权威信息）。 → 详细
- 三成效信号清晰可见——上手时间（onboarding ramp-up，新人从入职到能干活所需时间）下降、对队友的占用成本下降、Claude 辅助提交上升；但她反复强调"比吞吐量更重要的是产品质量"，留给观众的作业是：挑出你最"吵"（noisiest）、成本最高的那个工作流，反复自问"它还在发挥它该有的作用吗"。 → 详细
- 讲者 Fiona Fung，负责 Anthropic 旗下 Claude Code 和 Cowork 两条线的工程与产品（"I lead engineering and product for Cloud Code and Co-work"）；加入 Anthropic 前曾在 Meta 和 Microsoft 组建并带过团队。本场是 Code with Claude 大会的单人分享，定位是分享带这两个团队学到的经验，"希望你们能找到一两个对自己有帮助的小点子（a couple of tidbits）"。 → 详细
- 全场围绕五个话题：① 瓶颈已经转移（the bottlenecks have moved）；② 哪些团队规范因此"得重写了"；③ 这些规范怎么落地推行（how we rolled it out）；④ 有哪些信号让她"有信心走向是对的"；⑤ 留一道话题给观众带回团队讨论。 → 详细
- 贯穿全场的座右铭，幻灯片小标题写着 "以前对你管用的，现在可能不再管用了"（what served you prior may no longer）。她认为真正帮到自己的就是这块"肌肉"：始终保持成长型心态——"我们的变化速度只会越来越快（our rate of change is just increasing）"，所以要时不时回头问：你定下的规范、流程，"它还在发挥它原本的作用吗（is it still serving its purpose）？" → 详细
- 过去很多年里，工程带宽（engineering bandwidth，工程师能投入的时间精力，是稀缺产能）是一种很昂贵的东西。她点破：我们做软件工程的方式，"几乎所有事情都是围绕着保护这个资源在转"——想做大量规划，是为了"在动手之前就高度确信自己做的是对的东西"；想做严格评审，也是因为"工程带宽是制约因素时，围绕它有一大堆动作"。 → 详细
- 她请观众"跟我坐上时光机往回走，一直回到二十一世纪初"。那时她刚加入 Microsoft 做 Visual Studio，"根本没有'云'这个概念"——"现在听起来很疯狂，对吧？现在云已经无处不在了"。当年构建 Visual Studio 的方式是：就一间服务器机房，每个人都得轮值一周 on-call（值班待命）；整个构建流程是个队列，"我们一次最多只能合并六个 PR"（PR = pull request，一次代码改动的合并请求），而且"任何时候只要有一个测试挂了，你就得去 debug 到底是哪个 PR 导致的失败"。"在那时候，那确实是个很大的瓶颈。"后来有了云、有了持续构建（continuous build，代码一改就自动构建、不必排队），那个瓶颈也转移了——所以 AI 带来的只是"又一次转变"。 → 详细
- 把镜头拉回当下：在 Claude Code 团队，"编码真的已经不是慢的那部分了（coding is really the slow part anymore）"。正因如此，"上游和下游的那些流程，都得稍微做点改变"——核心追问是 "当编码不再是瓶颈时，会发生什么变化（when coding is no longer the bottleneck, what changes）？" → 详细
- 旧瓶颈具体是写代码、写测试、重构（refactoring，不改功能、整理优化代码结构）。亲身故事：刚加入想边熟悉边修 bug，试 TDD（测试驱动开发：先写测试、再写实现）——"先写测试感觉就像吃西兰花一样"（她澄清自己其实很爱吃西兰花，只是拿它当例子），因为"它并不总是整个过程里最享受的那部分"，她"老是手痒，急着想去搭产品"。有了 Claude 后再修第一个 bug，完整步骤是先写测试、验证它确实失败（"这样我才能确认这个测试真的在测某个东西"）、再做修复，做完测试已现成。结果让她大为惊讶——TDD"竟然变得有意思多了、舒服多了，把测试驱动开发里那种'税负'给抹掉了（took the tax out of test-driven development）"，"那对我来说是个很大的顿悟（a big aha）"。 → 详细 → 详细
- 重构同理。以前团队"时不时得做大重构或软件架构清理"，但"永远在纠结：什么时候才能挤出时间？我们明知它非常重要，但它总得以牺牲做产品的时间为代价"。结论——"感谢这些模型，有了 Claude，重构也不再是瓶颈了"。 → 详细
- 当上述旧瓶颈被抹平，新瓶颈随之浮现。第一个是 验证（verification，确认代码到底对不对）——她直说"这是个大问题（a big one）"，原因是 "带宽一下子涨了太多，我们必须更加关注：它对不对？" 加上"角色边界开始模糊、越来越多的人在提交改动时，我们也想确保每个人都对自己的改动是正确的有信心"。 → 详细
- 其他新焦点："谁来评审（who reviews）？这是个非常热门的话题"，以及 "它要怎么维护（how is it maintained）？" 她解释——"因为同样地，现在吞吐量大了太多，你还得去考虑维护的成本（cost of maintenance）"。 → 详细
- 金句：这些旧流程是 "悄无声息地不再奏效（quietly stops working）"。她特别喜欢这个说法，并补了一层因果反思："每当——但愿是这样——有人定下一个流程，那都是为了解决某个问题。但我们经常忘了去复盘、去问：'等等，这些流程现在还有必要吗？或者说它还在发挥它原本的作用吗？'" → 详细
- 鉴于这些转变，她列出一整张**"必须重写的团队规范"清单**：代码评审（code review）、上手（onboarding）、规划（planning）、招聘（hiring）、组织形态（org shape，团队怎么分组、层级多深）。其中"今天上午 Cat 在演讲里也重点讲了 Claude Code review"，她评价那是个"非常棒的工具"。 → 详细
- 代码归属权（code ownership） 被重新拷问：现在 Claude Code 几乎所有提交都由 Claude 共同署名（co-authored by Claude）——"过去这几个月里，我印象中就没见过哪个提交不是这样的（I don't think I've ever saw a commit that wasn't）"。组织形态：她们"真的很想让所有人都更敏捷、组织更扁平"，但有个反直觉安排——每个 manager 一开始都先做 IC；知识分享（knowledge sharing） 也变了，她抛出悬念："当文档也许不再是你的事实来源时，会发生什么？" → 详细 → 详细
- 新原则一句话概括："在技术争论里，代码说了算"，配套金句 "构建很便宜，争论很贵（building is cheap, arguing is expensive）"。案例：她上手时想做代码重构，和 Boris 在方案上有过几次争论（a couple of debates of approach）；"要是搁在以前"她会说"嘿 Boris，咱们去会议室白板上画出来吧"，但她转念"多亏有了 Claude，我其实可以直接生成出来"——于是 当场生成三个不同版本的 PR，因为"我想看的不只是代码怎么实现，还有对同事们的影响（impact to the colleagues）"。 → 详细 → 详细
- 原型设计（prototyping） 是另一例。多年前一场争论分两派：一派认为原型"让你快速行动、搭出大致骨架、对产品有直观感觉"；另一派担心"你做代码原型是偷工减料（cutting corners）"，怕"勉强能跑的原型让你产生执念、舍不得扔，硬着头皮想发布——可它压根不是为规模化构建的（not built to scale）"。她的结论：有了 Claude，原型既是"很好的起步方式"，又能 "把一个原型更快地扩展到生产环境（scale out a prototype to production a lot faster）"——两派顾虑同时被化解。 → 详细
- 减掉的：深度设计文档。她说"我以前待过的团队，可能你们也一样，会写设计文档（design docs），那种特别深入的规划和设计文档"；而现在 "我们大部分讨论其实都发生在 PR 或者原型里"，原因是"工程产能现在提上来了、写代码不再是瓶颈"。 → 详细
- 加倍投入的：验证。她强调这是"我想确保我和我们团队持续做得更好的一点，因为现在产能这么充裕，怎么验证质量就变得更加重要"。她给这套做法起名 "左移"（shift left，把质量把关动作尽量往开发流程的更前端、更靠近源头的位置挪）。 → 详细
- 金句逻辑（把因果讲完整）："有什么比你自己撞上 bug 更糟呢？对我来说真的很难受的是，当我听到客户、开发者、还有你们大家撞上某段代码的问题时，我总会想：'唉，要是我们能先发现就好了。'"紧接着反转："但其实有什么比我先撞上这个 bug 更好呢？那就是我们提前部署好自动化，在更靠近源头的地方就把它抓住（automation in place actually catch it closer to the source）。" 所以团队"一直在琢磨：怎么不断往左移、把更多东西自动化"。 → 详细
- 旧问题——"嘿，这块儿最后是谁动过的？谁是这部分代码的 owner（负责人）？"——她现在的建议是深挖问题的根源："如果你发现自己在问这个问题，就去深挖一下……你到底想搞清楚什么？你是在找谁引入了某个回退（regression，原本好的功能被改坏了），还是在找某个人来回答一个问题？还是你想补充一些 context（背景信息）？"而很可能 "Claude 其实就能帮上你这个忙"。 → 详细
- 她举了自己设的一个 routine（例行任务，指让 Claude 按固定流程自动跑的活） 作为例子：每天早上"就着早晨那杯咖啡"，让这个 routine "把所有反馈渠道里的反馈都过一遍……帮我把所有反馈汇总到一起，帮我识别出共性的主题（identify themes）"。 → 详细
- "你是怎么跟上 code review 的节奏的？"——上线 Claude Code 的 code review 功能前，这是她"经常被问到的问题"。她说 Claude Code review "绝对是真正帮到我们的一个工具，让我们能跟上写代码的产能"。Claude 真正擅长的地方：代码风格和 lint（代码格式/规范检查）、"那些明显的 bug"；还有——"如果你有一份 spec（规格说明，对功能该怎么做的书面定义），我鼓励你把 spec 也提交进代码库（check into your code base），因为 Claude 特别擅长检查代码有没有偏离 spec（spec drift，代码逐渐跑偏、与当初的规格说明不一致）"。 → 详细
- 但她紧接着强调 "仍然非常重要的一点是，还是要有人在回路里（human in the loop，关键环节始终保留人来把关）"。哪些地方即便在 code review 里"依然非常需要人"？法务审查（legal reviews）、任何涉及风险容忍度（risk tolerance）的东西，"尤其是当你看信任边界（trust boundaries，系统里区分可信/不可信的那条分界线）的时候"。核心原则是 "信任但要验证（trust but verify）"，以及"人在哪些地方能贡献那些不可或缺的专业判断"。 → 详细
- 案例"Mr. Peanut（花生先生）"：去年十二月她想给 CLI 里的 Claude 加点节日气氛，"野心还挺大，我想把 Claude 变成一个雪人（a snowman）"。她写了个示例请设计师 review，结果设计师给了"特别棒的反馈"："不，这一点都不像雪人。你这是把 Claude 变成了 Mr. Peanut（花生先生）。"（她解释 Mr. Peanut 是美国一个罐装花生品牌的吉祥物。）她当场认了："我的天，你说得太对了。我还以为是个雪人，可你说得没错，这就是颗花生。"结论：在产品这件事上，同样要把人的专业判断保留在回路里。 → 详细
- 怎么练产品直觉（她在旧金山讲完后"有很多工程师跑来问"）：第一步是 dog fooding（吃自家狗粮，自己天天用自己做的产品；Anthropic 内部叫 ant food）。"尤其对管理者来说，真的要确保自己花时间去用你正在做的、你团队正在做的产品"——每次加入新团队，亲自用产品"就是我最先做的几件事之一"，因为 "这样你才会真正打心底里感受到你的产品（feeling your product in your bones）"，会一直追问"我当初做这个产品时，想解决的到底是什么问题？想为用户创造什么样的体验？"团队成员看到她亲自用产品常会说"看到你用我们的产品太棒了，因为这说明你是真的在乎（you really care）"。 → 详细
- 产品直觉还来自 "不断迭代、发布，然后走出去跟客户聊（going out to speak to customers）"。她个人特别热衷和小企业打交道——"我觉得小企业是构成我们社区的命脉（the lifeblood that forms our community）"，Anthropic"刚刚发布了面向小企业的 Claude"。她有很多开餐厅的朋友"工作起来真的特别拼"，于是亲自带他们上手 Cowork，"因为我想看看，在企业客户之外，小企业用户实际是怎么完成上手的"，结果收到"特别宝贵的反馈"——"看到在上手流程里有那么多本可以做得更好的地方，真的很让人清醒（really humbling）"。警示金句：如果不 dog food，"过一阵子你可能会发现自己做的产品决策全都只是基于一些指标、仪表盘或者 PowerPoint（metrics or dashboards or PowerPoints）"——所以"一定要用自己的产品，用、用、再用"。 → 详细
- 她强调"这点很有意思，因为我发现它适用于所有角色"。设计师方向：以前 Claude Code 团队的设计师想做打磨或 UX 修正（polish or UX fixes），都得"画出标注稿（red line），然后交接给工程"，可这"总是要等，因为工程那边永远是：我得做这个产品、我得修这个 bug，哪有时间做打磨"。现在设计师会用 Claude 自己做很多这类打磨，"把那个迭代闭环收得快多了（closes that iterative loop a lot faster）"。反过来对工程师：她自嘲"作为工程师，我写东西往往特别啰嗦（very verbose）……往往会陷进太多细节里（go too much into the weeds）"，而 "Claude 在内容设计上是个特别好的搭档（a really great content design partner）"。总结：对所有角色，Claude 都在你不那么擅长的那些地方增强着你（augmenting all the areas where you may not be strong）。 → 详细 → 详细
- 这是她口中"也许是个有点'辣'（spicy）的话题"的讲管理者那一页，也是她刚加入 Claude Code 最先改的一件事之一：她跟招聘团队合作推动让 每个 manager 一开始都先做一段时间的 IC。动机是"我太相信亲自用产品这件事了"，而 "在 Claude Code，我们用 Claude 来构建 Claude，我们用 Claude Code 来构建 Claude Code"。 → 详细
- 她说这招"效果特别好"，因为它让管理者 "在还没背上'支持下属'这份责任之前，先有时间真正撸起袖子、扎进代码库里，亲身体会在这个团队里当一名工程师是什么感觉"。她还补一句对管理者的邀请：现在是个好时机去 "把一些动手编码的时间（maker hours，能专心写代码/造东西的整块时间）拿回来，重新回到代码库里，因为现在上手要比过去轻松得多了"。 → 详细
- 她补充经历佐证：早在来 Anthropic 之前，她就常在 manager 和 IC 之间来回切换，"每次切回去做 IC，都真的帮我充实了工程上的工具箱（engineering toolbox）"。只是"那个重新上手的过程总会让人有那么一点点犹豫……如果你有阵子没干这个了，它确实会让人发怵（daunting）"——但上手 Claude 时的体验"特别不一样"，这正好引出下一节。 → 详细
- 上手 Claude 时，"代码就是我们的真相来源（the code is our source of truth）"。她现在仍会"去跟团队里所有工程师碰面"，但"现在我们更多聊的是大家心里最关心的事（what's on top of minds）"；而以前她"总会去做那种技术深挖（tech deep dive，对某块系统做深入的技术讲解/钻研）"，现在她"第一次的技术深挖其实是直接跟 Claude 一起做的"，因为"Claude 特别擅长回答我所有的这些问题"。 → 详细
- 具体到修第一个 bug 前，她会先问 Claude："嘿，在我扎进这个 bug 之前，你能先教我一点这块涉及的范围（surface area，这块功能牵涉到的代码面/影响范围），还有这个 bug 周边那些区域的情况吗？" → 详细
- 她给所有团队的建议："不管你的真相来源是什么，哪怕是一份 spec，你都可以把它转成一个 skill，然后 check in 到代码库里（把它做成一个 Claude 技能、提交进代码仓库）。只要能做到，就把你的真相来源放进代码库，因为这样你才能真正让它保持最新。"原因她也讲透了："写代码的时候，带宽要大得多。这也意味着，任何不在这个更新循环里的文档（any documentation that isn't part of the update loop），都更容易变得过时。" → 详细
- 落地的总原则是两条腿走路。必须作为一个团队对齐（自上而下）的是 Claude Code 团队的几条原则，她们管它叫 "强制函数"（forcing function，一种强制大家必须照做、从而把行为掰过来的机制）。她笑称那张列原则的幻灯片"其实已经过时了，我都不该列出来"——因为现状已经是"每个 engineer、每个队友都在用 Claude Code，现在其实也都在用 Cowork"。这几条原则在第十五节逐条展开。 → 详细
- 同时她"想给自下而上（bottoms up）的空间留出余地，因为每个团队关注的点不一样，可能各自有不同的工具链（tool chain）"。留给自下而上的自由包括："Claude 在团队 triage（问题分诊，把涌进来的 bug/任务按轻重缓急分类处理）、各种规划仪式、站会（stand-up，每日简短同步会）里怎么用，或者哪些工作流先被 Claude 化，这些很大程度上都是自下而上决定的"。她总结这个平衡："在团队文化里什么重要这件事上要对齐，并且随着情况变化不断更新这些东西，但同时给每个小组（pod，小型自治团队）留出适配的空间。" → 详细
- 第一：尽量让组织保持敏捷、保持扁平——具体做法是"让管理者也去支持一部分具体工作，同时也真正深入代码库，直接对产品的某些部分负责（directly responsible for parts of the product）"。 → 详细
- 第二：Claude 化（Claude-ify）——"如果 Claude 能做，那就该让 Claude 做（if Claude can do it, Claude should）"，"这永远是我们在问自己的问题"。配套观察："今天早上你们听了关于模型的演讲，模型在以惊人的速度进步"——"有时候你会发现，哪怕两三个月前 Claude 还做不好某件事，现在随着一次模型更新，它其实已经做得非常好了"。这正是为什么要"永远重新审视、永远保持成长型心态，因为模型也在飞快地进步"。 → 详细
- 第三：明确授权大家去砍掉老的流程（explicit permission to kill old processes）。理由是 "人是不会主动去删流程的，流程往往只会越堆越多（people don't delete processes on their own, they tend to pile up）"。反例非常具体：她以前待过一个团队"有一大堆不同的 SLA（service-level agreement，服务等级协议，对响应/处理时限的硬性承诺）——P0 bug（最高优先级故障）有个 SLA，事故响应有个 SLA"，多到"连 engineer 都来找我说：'一天就只有 24 小时，我到底该先做哪个 SLA？'"她当时就意识到"我们真的该好好审计一下（audit），这些 SLA 是不是都还有必要"。补一句：哪怕是她们自己定下的团队原则和流程，"过了几个月之后……我们总是给自己留出这种权限，随时去批判、随时重新审视"。 → 详细
- 上手时间（onboarding ramp-up time）下降。具体口径是 "一个 engineer 从入职到提交第一个 PR 要花多长时间（time it takes for the engineer to land their first PR）"；这个时间、以及 "他对其他队友造成的占用成本（costs to other team members）" 都在持续下降——"很多时候，一个新人加入团队来问我问题，我会说：'这是个好问题，我们应该去问 Claude。'"她还点出对管理者的副作用：以前重回代码库时"我会觉得很不好意思……我得去问某个 engineer，这会占用他一天里的时间，因为他们都太忙了。但现在多亏了 Claude，我不觉得我在浪费任何人的时间了"。 → 详细
- PR 周期时间（cycle time，一个 PR 从发起到合并/上线走完全程所花的时间） 应该下降，"但这个指标挺有意思的"。她的关键提醒："你不能只看端到端的总时间，而要把它拆开，看看一个 PR 里到底有哪些不同的环节（funnels / chunks）"——因为 "如果你的 PR 周期时间没下降，不一定说明你没在用 AI，也可能是你队列里别的环节被堵住了，正是因为吞吐量上来了。比如说，你的 build 和 CI（continuous integration，持续集成：每次改代码都自动构建并跑测试的系统）系统跟得上吗？" 健康做法是把周期时间"拆成各个环节，看看其中哪些是你能改进或者自动化的"。 → 详细
- Claude 辅助提交（Claude-assisted commits）上升："过去这几个月里，我几乎没见过哪个 commit 不是 Claude 辅助完成的。"但她跳出来强调 "比纯粹的吞吐量更重要的是——不管你和你的团队在试图解决什么……想办法去衡量它（find some way to measure that）。因为除了吞吐量之外，我们希望也在做出有意义的改变，让产品更好、或者提升质量"。 → 详细
- 给作业前她特意"非常坦诚地说：我自己也还有很多问题没想明白"，分享了几个仍在摸索的问题。①"你还需要把 iOS 和 Android 拆成两个独立的组织吗？"——"这算是比较传统的组织方式"，但现在 Claude 让"engineer 能灵活地跨不同移动平台来回切换（flex across different mobile platforms）"，于是在想"真的还需要两个独立的移动团队吗？" → 详细
- ②"完全自动化的 review 你要推到多远（how far do you push fully automated reviews）？"——要在"够快"和"不丢掉重要的东西"之间把握平衡。③角色边界正在变模糊，"怎么确保每个人都保持高产？这就是为什么我们现在在重点研究验证（verification）"，要确保"每个做出改动的人都对自己的改动有信心"。她还提到团队 "其实刚刚发布了 Claude design"，正思考怎么改进团队里各个职能（all the functions）的工作流。 → 详细
- 行动号召："挑出你最'吵'的那个工作流（pick your noisiest workflow）"——"也可以只是某个你不太喜欢、或者对团队来说成本特别高的工作流或团队会议"，然后问自己 "它还在发挥它该有的作用吗？"，或者"如果它成本真的很高，这是不是 Claude 也许能帮你处理的事情？"，关键是 "一步一步来，慢慢做（do this one step at a time）"。 → 详细
- 配套反例画面很传神：她在另一个团队待过，"我们有个每周开的、成本特别高的会，我注意到所有人都低头盯着自己的笔记本，除了轮到自己汇报状态时抬一下头，汇报完又埋回笔记本里"。她的算账方式："你数一数这屋里坐了多少人，这是个成本极高的房间（a very expensive room）。"她希望大家带这道题回团队讨论，并很想听这些内容是否引起共鸣。最后以"非常感谢大家听我的分享……很荣幸"收尾，全场鼓掌。 → 详细 （本场为单人演讲，无 Q&A / 闪电问答环节。） 收尾金句留作团队讨论："Pick your noisiest workflow… and always ask yourself, is it still serving its purpose?"——挑出最"吵"的工作流，反复自问它是否还在发挥原本的作用；成本太高的，看看 Claude 能否帮忙，一步一步来。 → 详细 讲者：Fiona Fung，Anthropic — 负责 Claude Code 和 Cowork 的工程与产品（本场演讲未提供个人联系方式）。
🎯 于你何益 为你定制 · 非通用结论
这期相关度高。Fiona 讲的是"当编码不再是瓶颈，一个工程组织该怎么重写它的所有规矩"——这恰好是你两件最核心的事正在经历的：一是 Holdwell 那座多-Agent PRD 工厂（一群 agent 替代人写代码/写 PRD，瓶颈被推到了别处），二是你本人作为单兵同时扛多线（你就是个"一人工程组织"，AI 把你的产能放大后，真正卡你的不再是动手，而是别的环节）。她全场反复敲的那句"以前对你管用的，现在可能不再管用了——它还在发挥它原本的作用吗？"，几乎就是替你这套知识库的摄入 SOP 和你那些半自动流程量身写的。下面按你的项目分。
给 Holdwell 工厂（一个组织怎么运营）
1. 瓶颈一移走，旧流程会"悄无声息地不再奏效"——要主动审计，而不是等它出事
- 怎么做的：Fiona 的核心洞察是旧流程"quietly stops working（悄无声息地不再奏效）"——它不报错、不崩，只是默默地不再值得做了。她补了一层因果："每当有人定下一个流程，那都是为了解决某个问题。但我们经常忘了去复盘：'等等，这些流程现在还有必要吗？'"她的反例极具体：以前团队里堆了"一大堆不同的 SLA——P0 bug 一个、事故响应一个"，多到工程师跑来问她"一天就 24 小时，我到底该先做哪个 SLA？"，她才意识到"该好好审计一下了"。
- 你可以怎么做：你的工厂 2026-06 刚把旧的一整套重流程退役、换成三驾马车 + 碰撞协议——那正是 Fiona 说的一次审计。但别以为审一次就完：碰撞协议的六个环节，同样是在"当下模型能力"的假设下设计的。拿 Fiona 的镜子定期照一遍：哪个环节是为"保护稀缺人力/补当下模型短板"才设的、模型再进一步后就不再是它原本的作用？别等跑出一堆"走了流程但没产生价值"的证据才动,主动列一张"可能已经悄悄失效的环节"清单,逐个问"它还在发挥它原本的作用吗"。
2. 瓶颈不是消失,是转移到"验证 / 评审 / 维护"——把质量把关"左移"
- 怎么做的：她明说编码不再是瓶颈后,新瓶颈是三个:验证(它对不对?)、谁来评审、怎么维护。验证她称为"a big one(大问题)",因为"带宽一下涨太多,角色边界开始模糊,越来越多人在提交改动"。她给的解法叫**"左移"(shift left)**——把质量把关尽量往源头挪,并配了一句很扎心的反转:"有什么比你自己撞上 bug 更糟?是听到客户撞上。但有什么比你先撞上更好?是提前部署好自动化,在更靠近源头的地方就把它抓住。"
- 你可以怎么做：你工厂当前最痛的就是"碰撞协议纪律是否真执行、agent 产出的可观测/可验证"——这正是"验证瓶颈"的同一张脸。把"左移"翻译成你的活:别把质量检查全堆在流程末端的真人评审当一道终审闸,而是在每个环节交接处(澄清→独立初稿、初稿→碰撞、碰撞→合成定稿…)插一个轻量自动校验(比如 agent 自动核对本环节产出有没有偏离上游澄清结论)。这就引出下一条——
3. 把"真相来源"做成能 check-in 的东西,否则它必然过时——直击你的跨线对齐地基
- 怎么做的：她最硬的一条建议:"不管你的真相来源是什么,哪怕是一份 spec,你都可以把它转成一个 skill、check in 到代码库里。"理由讲透了:"写代码的时候带宽大得多,这意味着任何不在这个更新循环里的文档,都更容易变得过时。"对应到评审,她还说"如果你有一份 spec,我鼓励你把它提交进代码库,因为 Claude 特别擅长检查代码有没有偏离 spec(spec drift)"。
- 你可以怎么做：你的痛点列表里写着"跨线对齐"——六条强耦合产品线的"真相来源"(共享实体、术语、跨线约定)正是这条建议要治的地方。Fiona 在告诉你:一份没被纳入日常更新循环的实体定义,等于没有,因为它会比代码/PRD 漂移得更快。所以别把共享定义当一份静态字典写完就放着,把它做成 agent 每跑一个工单都会读、并能反向校验"这个 PRD 有没有引用了字典里不存在的实体"的活物。先填一个最小可用版本(覆盖最高频的几个核心实体),让它进流程的强制校验链——比一次性写全但没人维护的大字典有用得多。
4. 砍流程要"明确授权",因为人只会往上堆、不会主动删——你刚退役一整套旧机制,这条帮你守住
- 怎么做的：她优先抓的第三件事是**"明确授权大家去砍掉老流程(explicit permission to kill old processes)",因为"人是不会主动删流程的,流程只会越堆越多"。注意她的措辞:不是"建议大家精简",而是给一个明确的、制度化的"准许你删"的口子**——连她们自己定的团队原则,"过几个月也总给自己留出这种权限,随时去批判、随时重新审视"。
- 你可以怎么做：你 2026-06 刚做过一次大处决——把整套旧流程退役、换成三驾马车碰撞协议,证明你砍得动。但那是一次性壮举,不是制度,新流程照样会往上堆。借她这招:在工厂治理里立一条明文规则——每个环节的 owner 有权且被要求定期标记"这一步可以砍/可以并",并设一个固定的复盘点(比如每月一次)集中处决。把"删流程"从一件需要勇气的事,变成一件被制度要求做的事。
给本人 / 你的精力(单兵怎么类比这套打法)
5. "管理者先做 IC、亲手用产品"= 你别只当流程设计师,定期回去亲手跑一遍
- 怎么做的：她最先改的一件事是让每个 manager 先做一段 IC(一线写代码),动机是"我太信亲自用产品了——在 Claude Code,我们用 Claude 构建 Claude、用 Claude Code 构建 Claude Code"。她说唯有亲手用,才会"打心底里感受到你的产品(feeling your product in your bones)";不然"过一阵子你会发现自己做的产品决策全都只基于指标、仪表盘或 PowerPoint"。她还说现在正是把"动手时间(maker hours)拿回来"的好时机,因为上手比过去轻松多了。
- 你可以怎么做：你的元约束是精力稀缺,所以你天然倾向于站在"设计 agent 链路/写 SOP"的高层,把脏活交给 agent。Fiona 在警告你:全交出去、自己只看 dashboard,你会逐渐丧失"打心底里的判断力"——而判断力恰恰是你 2021 年写下的操作系统第一条("判断力 > 努力")。给自己定一条:每隔一段时间,亲手从头到尾跑一个真实需求穿过你的工厂(不靠任何快捷),或亲手用一次 StockHelp 看板做一个真实买卖决策。这不是浪费时间,这是你"在骨子里感受自己产品"的唯一渠道。
6. 别再问"这是谁改的",要深挖你到底想知道什么 + 用 routine 自动汇总
- 怎么做的：对"这块最后是谁动过的?"这类问题,她的建议是深挖根源:"你到底想搞清楚什么?是找谁引入了回退,还是找人答个问题,还是想补点背景?"很可能 Claude 就能帮你。她还举了自己设的一个 routine:每天早上"就着那杯咖啡",让它"把所有反馈渠道的反馈过一遍、汇总、识别出共性主题"。
- 你可以怎么做：你同时扛 6 个项目,最大的隐性成本是"上下文反复重建"——每次切回某个项目都要重新想"我上次到哪了、最近有什么新输入"。照搬她的 routine:给你最在乎的一两条线(比如这本知识库的摄入、或 xiaohongshu 选题)设一个每日/每周自动汇总的 routine,开机第一件事让它替你把分散的新信息归并成几个主题。把"重建上下文"这件高频高耗的活左移、自动化掉。
给 Chief of Staff(治理 / 守门)
7. "强制函数" + "自上而下对齐价值、自下而上留适配空间"——正好是你宪法外脑的形态
- 怎么做的：落地她用两条腿:自上而下必须对齐的几条团队原则,她们称为**"强制函数(forcing function)"**——一种强制大家照做、把行为掰过来的机制;自下而上则给每个 pod 留空间("Claude 在 triage、规划、站会里怎么用,哪些工作流先被 Claude 化,很大程度自下而上决定")。她的总结:"在什么重要这件事上对齐、并随情况不断更新,同时给每个小组留出适配的空间。"
- 你可以怎么做：你的 CoS 本质就是把你写过的原则放回你眼前、做跨域守门——这跟 Fiona 的"强制函数"是同一个机理:光把价值观写下来不够,得有个机制在决策时刻强制它现身。她的"自上而下对齐 + 自下而上适配"给你 CoS 的痛点("跨域守门、软教练质量")一个结构:哪些是宪法级、跨所有项目都不可破的红线(对齐、强制),哪些是各项目自己拿主意的(放权、不越界替它下结论)。把这条分界明文化,正好对应你 CONSTITUTION 里"软教练不替你决定、只把张力摆到你面前"的诉求。
给 app_incubator(把"该做什么"前移到 agent)
8. 验证左移 + 自动化"靠近源头抓 bug"= 你想做的"把该做什么前移给 agent"
- 怎么做的：贯穿全场的"shift left(左移)"——把质量把关从下游挪到尽量靠源头;以及她优先抓的"Claude 能做的就让 Claude 做,把人解放出来攻硬骨头"。她还反复说现在最该投的是验证:产能充裕之后,"怎么验证质量"比"产出多少"重要得多。
- 你可以怎么做：你 app_incubator 的明确目标就是"把'该做什么'前移到 agent"、解决"激活/首屏体验"。Fiona 的"左移"给你一个更锋利的版本:不只是把任务前移,更要把验证前移——让 7-Agent 链路在生成设计稿/首屏的同时,自带一个 agent 去校验"这个首屏有没有偏离当初的产品意图/契约"。你那条"设计稿即工程强制契约"恰好是她说的"把 spec check in、让 Claude 检查 spec drift"的完美载体:契约是真相来源,让一个 agent 持续盯着实现有没有漂离契约。
顺带·投资视角(StockHelp / 你本人的价值投资)
- 怎么做的：整场是一堂"如何提升一个组织的运营质量与人效"的公开课——衡量信号她给了三个:上手时间↓、PR 周期时间↓(且要拆成各环节看,别只看端到端)、AI 辅助提交↑;但她跳出来强调"比纯吞吐量更重要的是质量,想办法去衡量你真正想改变的东西"。
- 对你的投资有什么用：作为找"卓越生意"的价值投资者,这给你一把看科技/软件公司运营质量的镜子。当你研究一家公司时,可以多问一句:它的工程组织在"AI 把编码变便宜"这件事上,是还在用旧瓶颈的成本结构(人力堆在写代码上),还是已经把人力重配到"验证、品味、攻硬骨头"上了?谁先完成这次"瓶颈转移",谁的单位人效(护城河的一种)就更强。⚠️ 诚实闸门:这只是一个定性观察镜头,不是可量化的选股因子,别试图硬塞进 StockHelp 看板的比率里——它属于你读财报/电话会时脑子里多挂的一个问题,不属于 Phase 1 那块数据面板。
更深三角度
该反着用：Fiona 是在资源极其充裕的前沿实验室里说话——满编工程团队、专职设计师、随时能拉 Boris 争论、模型还是自家的。你是精力稀缺的单兵 + 多副业。所以她"为了享受 maker hours 而把动手时间拿回来"对你要反过来:你的稀缺不是"想动手没机会",而是"动手的诱惑太多、聚焦不够"。对你而言"砍流程/砍工作流"的真正意义,不是腾出时间写更多代码,而是腾出时间思考"该不该做"(你操作系统里的"判断力先于做多快")。她的"砍",目的地是"造得更多";你的"砍",目的地应该是"造得更少但更准"。
和你现在做法冲突：她说**"代码取代文档成为唯一真相来源""任何不在更新循环里的文档都会过时"——这跟你正在精心搭建的这本第二大脑(以文档/原子笔记为核心)直接顶上了。你押注"主题骨架→原子笔记"这套人写、人读的文档体系能长期保值;她押注"会过时的文档不如能 check-in、被自动更新的真相来源"。这个张力值得你坐下来想清楚(我不替你下结论):你知识库里哪些是该被做成"活的、能被 AI 重读和校验的源"(比如 entities 字典、各 skill 的契约),哪些确实适合留作人脑慢思考的静态笔记**(比如思维模型、读书顿悟)?两者混在一个目录里、用同一种更新纪律,可能正是你"摄入 SOP、信噪比"痛点的根因之一。
对你的镜子：Fiona 那个"成本极高的房间"——所有人低头盯笔记本、只在轮到自己汇报时抬头——照出的不是某个会,而是你那些"还在跑、但你已经不确定它在解决什么问题"的半自动流程和目录。你不缺新流程、新 skill、新主题,你缺的是一个定期把它们拖出来问"它还在发挥它原本的作用吗"的习惯。她这堂课对你最大的价值,不是某个具体做法,而是把这句话焊进你的脑子。
One Human Company 新号（2026-07 回填）
1 · C 类候选：「Anthropic 高管说'Claude 能做的就该让 Claude 做'，我把一人公司的活全清点了一遍」
- 怎么做的：Fiona（Anthropic 负责 Claude Code/Cowork 的工程产品负责人）优先抓的三件事之二就是 Claude 化——「如果 Claude 能做，那就该让 Claude 做，这永远是我们在问自己的问题」，且因为模型进步快，「两三个月前 Claude 做不好的事，一次更新后就行了」，要定期重审。第三件是「明确授权砍老流程」，因为「人不会主动删流程，流程只会越堆越多」。
- 你可以怎么做：候选标题——《Anthropic 说"AI 能做的就该 AI 做"，我把公司里我还亲手干的活列了张清单》。你的一人公司是这句话的极限试验场：清点你在 drizzle tech 里仍亲手做的每件事，逐项问"是 Claude 真做不了，还是我没授权自己砍"，晒清单和一个月后的变化。可抄物现成：那张两列清点表（我还在做 / 为什么还是我）。闸门自检：清单和取舍理由全是你的实操，成立。
2 · 办号镜子：「dogfood 才有产品直觉」正是 build-in-public 的底层逻辑
- 怎么做的：Fiona 最先改的一件事是让每个 manager 先做一段 IC，理由是「唯有亲手用，才会打心底里感受到你的产品」，否则「产品决策全都只基于指标、仪表盘或 PowerPoint」。她还举了自己每天早上就着咖啡跑的 routine：自动汇总所有反馈渠道、识别共性主题。
- 你可以怎么做：这句话就是你新号"验证派"定位的护城河解释——你能写 C 类"大佬说 X 我试了"，恰恰因为你在 drizzle tech 里天天 dogfood；一旦你开始靠转述而不是亲测出内容，号的独占性就没了。经营动作：把她的晨间 routine 抄成你的内容雷达——每天让 agent 把关注博主的新观点汇总成"今天值得我试什么"的候选清单，喂 C 类选题池。这直接服务 Phase 0 攒 ≥4 篇 C 类存稿的硬指标。
3 · B 类素材：AI 产能上来后，你自己就是那个新瓶颈
- 怎么做的：她的核心判断——编码不再是瓶颈后，瓶颈转移到验证、评审、维护三处；她给的成效指标也提醒「PR 周期没降不一定是没用 AI，可能是吞吐量上来后别的环节堵住了」。
- 你可以怎么做：写一篇 B 类《我的 AI 员工一周出活 N 件，卡住公司的原来是我自己》——统计 drizzle tech 一周里 agent 等你验收/拍板的时长 vs 它们干活的时长，这个"老板才是瓶颈"的账没人替你算得出来。自检：数据是你的排队实录，过闸门。
所以呢
可迁移思维模型:
- 【耐用】"瓶颈会转移,旧规范会悄无声息地失效"——这是个跨技术周期都成立的元规律(她自己用云时代→AI 时代两次换瓶颈做了佐证)。值得当成你审视任何系统(工厂、知识库、副业、甚至一门生意)的固定提问:此刻真正的瓶颈在哪?我现有的流程是不是还在保护一个已经不稀缺的资源?
- 【耐用】"砍流程要明确授权,因为熵只增不减"——人和组织默认往上堆、从不删,这是人性常数,不会过期。
- 【会过期】"编码不再是瓶颈,把人重配到验证/品味"这个具体结论——它绑定在"模型刚好强到能写大部分代码、但还不够强到能替代品味/验证"这个当下的能力快照上。她自己都说"两三个月前 Claude 还做不好的事,一次更新后就行了"。所以"哪些该留人"这条线会持续移动,别把今天的分工当永久真理。
判断更新:你之前可能默认"把活尽量交给 agent、自己站在高层设计"就是杠杆最大化。这期提醒你修正一条:当产能变便宜,稀缺性和你的注意力都应该往"验证"和"判断该造什么"上迁移,而不是往"造得更多"上迁移。对你这个把判断力奉为第一原则的人,这其实是把你的价值观,翻译成了 AI 时代的具体动作。
这周一个赌注:照 Fiona 的作业,挑你最"吵"的那一个工作流下注。建议就锁定 Holdwell 工厂的**"碰撞协议纪律是否真执行":这周只做一件最小的事——给一个**环节交接(比如 PRD 定稿→真人评审)加一个 agent 自动校验"产出有没有偏离跨线共享的实体定义",哪怕共享定义此刻只有 3 个核心实体。它一箭三雕:给纪律补了强制点、给跨线对齐的地基填了第一块、并把"验证左移"从理念变成了你工厂里第一个能跑的实例。一步一步来(do this one step at a time)——她原话。