最近 Anthropic 工程副总裁 Fiona Fung 在一个演讲里说了一句话，大意是：流程很少会自己消失，我们倾向于层层叠加更多流程。她讲的是 Claude Code 团队在 AI 辅助开发之后，被迫重写几乎所有工程规范的经历。
她说这句话的背景很具体。她负责的 Claude Code 团队经历了一个根本性的变化：AI 已经把代码生成成本压到了接近零，编码几乎不再是慢的那个环节了。但当她和团队复盘时发现，大部分工程流程仍然建立在”工程带宽很贵”这个旧前提上：从六个月路线图到逐行代码审查，从”谁写的这段代码”到管理者与代码的分离，这些做法的共同假设是工程带宽稀缺。
她管这种现象叫流程”悄悄地不再奏效了”。这些流程在设计时都有合理的理由。环境变了以后，它们不自动失效，而是继续运行，继续消耗团队的认知资源。更隐蔽的是，很少有人主动在问：这个流程现在还在发挥当初的作用吗？
问题是，当瓶颈发生这种量级的迁移时，那些围绕旧瓶颈建立的制度并不会自动跟着消失。它们会继续运行，继续消耗时间，继续制造一种”我们在做正确的事”的错觉。它们只是不再产生价值了。
Fiona Fung 在演讲里举了一个例子。她加入 Claude Code 团队后发现团队有站会。团队变大以后，站会升级成了电子表格，每人每周填进度。再后来她想，“等等，这为什么不直接写成一个 Claude 脚本？”于是站会变成了一个自动化的 skill。再后来她看着那个电子表格问了一句：“这个东西还有意义吗？”然后就把它删了。
这个过程花了几个月。而且每一步都是合理的：站会在团队小的时候有用，电子表格在团队中等的时候有用。问题不在于任何一个时间点的决策错误，问题在于没有人负责在制度完成使命之后让它退役。
2021 年发表在 Nature 上的一项研究发现，人类在解决问题时系统性地忽略”减法”方案。研究者让参与者改进一个乐高结构、一篇文章的段落顺序、或者一道菜谱，绝大多数人默认选择了添加元素，即使删除一个元素就能达到同等甚至更好的效果。更关键的是，即使给出金钱激励，这个偏好也没有消失。不是人们不愿意删，而是人们根本想不起来”删”是一个选项。
经济学家 Mancur Olson 在 1982 年提出了一个相关的概念，叫”制度硬化症”。他的核心发现是：二战的战败国在战后反而增长更快，因为战争摧毁了它们积累的官僚层级和利益集团。战胜国保留了完整的制度层，这些制度继续为各自的利益服务，但整体的经济增长因此变得更慢。
软件工程团队的制度层不会像国家那样剧烈地被摧毁，但 AI 带来的成本结构变化在某种意义上扮演了类似的”重置事件”的角色。它创造了一个窗口，在这个窗口里，旧的制度逻辑已经不再成立，但制度本身还在运行。窗口不会一直开着。Fiona 在演讲里讲过一个 50 人的大评审会，她发现所有人都只在轮到自己的时候抬头说几句，其他时间都在看笔记本。她问了一句”为什么要开这个会”，全场安静，然后这个会就被取消了。她总结说，制度不会自己去死，“我们需要明确授权去杀掉旧流程”。
如果代码不再是瓶颈，那么一切以”代码很贵、工程带宽很稀缺”为前提的制度都需要重新审视。有几类是特别典型的。
第一是规划制度。六个月路线图、重型设计文档、每个改动前先写 spec，这些做法的前提假设是一致的：编码是昂贵的，一旦投入编码就必须确保方向正确。当代码生成成本降到接近零的时候，原型本身就是最便宜的论证方式。Fiona 的团队现在的做法是”有想法了，先去实现原型”，技术辩论的方式也从白板讨论变成了”生成三个不同实现的 PR，看哪个对上下游影响最小”。她管现在做规划的方式叫 JIT 规划，不是不规划，是推迟到信息分辨率足够高的时候再规划。
第二是代码审查制度。传统的逐行审查在设计之初有两个功能：发现错误和知识传递。AI 同时削弱了这两个功能的必要性。AI 可以比人更快地发现模式性错误，比如 null dereference、死锁、资源泄露，而知识传递在”代码随时可以被 AI 重新生成”的环境里，最重要的不是代码的细节而是意图的细节。前微软和 Amazon 工程高管 Ayman Shoukry 提出的替代方案是两层审查：人类审查意图，包括技术方案、业务逻辑、设计决策；AI 审查实现，包括风格、安全性、边界情况。这不是把 code review AI 化，是把 code review 这件工作重新拆解了一遍。
在 Anthropic 内部，Boris Cherny 在接受 PCMag 采访时确认了类似的实践：每个 PR 都会经过 Claude Code 的审查作为第一道检查，“它发现的 bug 的细节程度让我震惊，我没想到它能做到这么好”，但最终仍然需要人工确认。Fiona 的补充是，人类被保留的环节是”信任但要验证”中那部分无法被规则化的东西：安全边界、法务审查、产品判断力。
第三是代码所有权制度。“谁写的这段代码”在传统工程语境里是一个合理问题，出问题你要找到最熟悉这块代码的人。当几乎所有 PR 都有 AI 参与编写时，这个问题本身的意义变模糊了。Fiona 的团队不再直接问”谁写的”，而是追问：你真正想回答的是什么问题？想找出回归责任人？想找一个专家来回答客户问题？想了解一段逻辑的上下文？不同的追问对应不同的解决方案，而大多数情况下这个解决方案可以用 Claude 自动化。
第四是管理者角色本身的定义。Fiona 在 Anthropic 推行了一个在她看来最有争议的做法：所有管理者必须先以 IC 身份加入团队，写代码，建立信任，然后再承担管理职责。她的招聘团队一开始认为这根本招不到人，但 Fiona 的逻辑是硬的：在 AI 时代，管理者重新具备了写代码的能力。过去管理者很难保持手感，因为内部工具链变得太快，一年写一个 PR 已经是极限。现在有了 Claude，上下文切换成本被大幅降低了。“我已经不记得 git 命令了，”她说，“每次都让 Claude 帮我搞定。”
如果减法比加法更难被想起，那么仅靠”意识到应该 unlearn”是不够的。需要有一些机制来对抗默认的叠加倾向。
Fiona 的做法是三条团队原则。第一，每个团队成员，包括跨职能合作伙伴，必须使用 Claude Code，这确保所有人都有第一手的体感来判断什么流程已经不再必要。第二，“能 Claudify 的都 Claudify”，先问”这能不能自动化”再决定要不要人来做。第三，“明确授权杀掉旧流程”。第三条最容易被忽略。她说，制度很少会自己消失，我们倾向于层层叠加更多制度。没有明确授权，工程师看到冗余流程时会想”这是别人定的，我没资格动”。授权把”杀流程”从越权变成了职责。
具体来说，有几个实用的启发式可以用。
第一个来自 Fiona 自己：找出你们团队里最嘈杂、成本最高、你自己最不情愿做的那个工作流，然后问一句”它还在发挥当初设定的作用吗？“这不是一个技术问题，是一个组织问题。50 个人的大评审会之所以被取消，不是因为有人找到了更好的替代方案，而是因为有人问出了那个问题。
第二个来自组织变革研究：设置一条减法规则。荷兰一个激进管理研究团队 Corporate Rebels 走访过一家公司，这家公司有一条硬规定：每次有人想引入一条新政策，必须先废除至少一条现存政策。这不是在优化特定流程，这是在建立一个对抗制度熵增的元机制。Nature 那项研究也证实，仅仅是”请考虑减法方案”这样一个轻量提醒，就能显著改变人们提出的方案类型。
第三个启发是时间维度的。Fiona 说她和团队每隔几个月会重新审视一次团队原则：“这个原则还有当初的效果吗？还在发挥我们设立它时想要的作用吗？”这句话的重要之处不在于频率，“几个月”不是一个硬数字，而在于它把审视本身变成了一个制度化的动作，而不是一次性的清理。模型能力在持续提升，约束也在持续迁移，昨天的优化可能是今天的浪费。
最后还有一个反直觉的点：unlearn 不是回到”没有流程”的状态。它是一个持续的、需要判断力的活动。流程本身不是敌人，没有经过定期检视的流程才是。这就像代码重构，不是因为代码脏了才重构，而是因为系统的上下文变了。Vadim Kravcenko 写过一句话：“我们每个 sprint 都在重构代码；组织层面也应该得到同样的待遇。”
回到开头的那句话。Fiona Fung 反复在演讲里说的：“过去让你成功的，未必还能继续让你成功。”这不是鸡汤，是一个工程判断。AI 改变了软件开发最底层的成本假设，那些在旧假设下成立的流程、规范、角色定义和组织结构，不会因为假设变了就自动更新。它们需要被主动识别、评估、废除。说”主动”不是修辞需要，而是因为默认方向永远是积累，不是清理。
MIT 的 Zeynep Ton 教授观察到：“在大组织里，人们很清楚，他们会因为增加了什么而被注意到，不会因为减少了什么而被注意到。”对于那些正在带团队、正在推 AI 工具落地的工程管理者来说，这句话意味着 unlearn 不仅是一种能力，更是一种管理责任。你得说出来：删掉旧流程是可以的，是被鼓励的，是工作的一部分。否则没有人会替你做这件事。