那些悄悄失效的流程
Claude Code 和 Claude Cowork 的工程总监 Fiona Fung 介绍了当“智能体式编程”成为默认工作方式后，团队流程和组织结构发生了哪些变化。
最值得关注的地方，不是团队用了多少 AI 工具，也不是工程师的编码效率提升了多少，而是它指出了一个更本质的问题：
当 AI 已经改变了工作的成本结构，很多我们习以为常的流程，其实已经悄悄失效了。
过去，工程管理的核心假设是：写代码很贵，工程产能有限。所以我们需要提前做大量规划，需要严格排期，需要层层评审，需要把需求拆得足够细，尽量减少返工。
但当 AI 让写代码、写测试、重构、生成原型的成本大幅下降后，真正昂贵的东西变了。
现在更贵的不是“把代码写出来”，而是：
这段代码是否正确？ 它是否符合业务目标？ 它是否安全？ 它未来是否可维护？ 产品判断是否成立？ 组织能不能跟上更快的试错速度？
也就是说，AI 并没有让工程管理消失，而是把工程管理的重心从“管理产出”推向了“管理判断”。
一、长期路线图正在失效
曾经，Claude Code 团队曾经制定过一份六个月路线图，但因为变化太快，到第三个月就已经过时了。
这点非常真实。
过去我们喜欢做长期 roadmap，是因为开发周期长，资源昂贵，团队必须尽早对齐方向。但在 AI 原生的研发模式下，很多事情变得可以更快验证。一个想法不一定要先写完整 PRD，不一定要排进几个月后的版本，也不一定要开很多评审会。
更合理的方式变成了：
先做原型，再让内部用户使用，然后根据反馈快速调整。
这不是不要规划，而是规划方式要变。
以前的规划像“修铁路”：路线先定死，然后按阶段施工。 现在的规划更像“导航”：方向明确，但路径需要根据实时路况不断调整。
所以，对产品和研发团队来说，未来最重要的不是把半年计划写得多漂亮，而是建立一种能力：
在不失去方向的前提下，快速试错、快速反馈、快速收敛。
这对产品经理的要求其实更高了。因为 AI 可以让原型来得更快，但也会让无效想法来得更快。如果产品判断不清楚，团队只会更快地制造混乱。
二、不再去找代码作者
过去排查问题时，我们经常会问：
“这段代码是谁写的？” “这个需求是谁做的？” “当时为什么这么设计？”
但在 AI 辅助开发成为默认方式之后，“谁写的”这个问题没有以前那么有用了。因为很多代码并不是某个人逐字写出来的，而是人和 AI 一起生成、修改、验证的结果。
文章里提到，他们的新习惯是先问：你真正想知道什么？
你是想找出是谁引入了 bug？ 还是想理解一个技术决策？ 还是想回答客户的问题？ 还是想知道某个功能为什么这样设计？
这个转变很关键。
过去我们依赖“人”保存上下文，现在应该更多依赖“系统”保存上下文。包括 PR 记录、需求背景、客户反馈、设计讨论、代码变更、测试结果，都应该尽可能结构化，让 AI 可以帮助我们检索、总结和解释。
这对团队知识管理是一个很大的提醒。
如果一个团队的上下文只存在于微信群、个人脑子、零散会议和口头沟通里，那么 AI 再强也很难真正发挥作用。AI 原生组织不是简单地买一个 AI 工具，而是要让组织的信息流变得可读取、可追溯、可复用。
三、代码审查不会消失，但重点变了
很多人会担心：AI 写代码越来越强，那是不是人就不用做 Code Review 了？
这篇文章给出的答案很务实：
不是不审，而是人类应该审真正需要人类判断的部分。
代码风格、lint、基础 bug、测试补充，这些事情 Claude 可以大量承担。但涉及法律风险、安全边界、信任机制、产品体验、设计品味、业务取舍的地方，仍然需要人类专家。
这说明未来的代码审查会分层：
AI 负责基础质量检查。 工程师负责架构和可维护性判断。 安全专家负责风险边界。 产品经理负责业务目标和用户体验。 设计师负责交互和审美判断。
这其实也提醒我们，未来团队里的“专家价值”会更加突出。
普通重复性工作会被 AI 吃掉，但真正懂业务、懂系统、懂用户、懂风险的人会更重要。因为 AI 可以给出方案，但谁来判断方案是否值得做、是否适合当前客户、是否符合长期产品方向，仍然是人的责任。
四、固定角色边界正在变模糊
有一个很有意思的点：Claude Code 团队里的 PM 现在也经常写代码，工程师也会参与内容和设计工作。
这背后不是简单的“人人都要变成程序员”，而是角色边界正在变得更灵活。
以前的分工是：
产品经理写需求。 设计师画界面。 工程师写代码。 测试负责验证。 运营负责反馈。
这种分工在稳定业务里没问题。但在 AI 原生的工作方式里，很多中间环节的成本下降了。产品经理可以直接做原型，工程师可以直接验证交互，设计师可以更快生成方案，测试可以让 AI 辅助构造用例。
这意味着未来团队更需要的是“T 型能力”：
你仍然要有自己的专业深度，但也要能跨过原来的边界，直接把想法推进到可验证状态。
对产品经理尤其如此。
AI 时代的产品经理不能只停留在写需求文档。更有价值的产品经理应该能做三件事：
第一，判断什么问题值得解决。 第二，用 AI 快速把想法变成可体验的原型。 第三，组织用户反馈、业务判断和技术实现之间的闭环。
产品经理不一定要成为专业工程师，但必须具备更强的“构建能力”。
五、真正要淘汰的，是那些不再创造价值的流程
最打动我的地方，是它不是在鼓吹“AI 能替代一切”，而是在提醒我们重新审视流程。
很多流程一开始都有价值。会议、评审、周报、排期、文档、审批，最初都是为了解决某个问题。但问题是，当环境变了，流程却很少自动消失。
于是组织里会出现很多“历史遗留流程”：
大家都参加，但没人觉得有用的会议。 大家都填写，但没人认真看的表格。 大家都走一遍，但没人知道为什么的审批。 大家都维护，但早就不再指导实际工作的路线图。
AI 原生组织的关键，不是把这些流程全部 AI 化，而是先问一句：
这个流程现在还在服务它原来的目的吗？
如果还在，就看能不能自动化。 如果不在，就应该果断删除。
这点对所有团队都有价值。因为提升效率最好的方式，有时候不是把一件低价值的事情做得更快，而是承认它已经没有必要继续存在。
我最大的感受是：AI 对组织的影响，不应该只停留在“研发用了 AI，所以写代码更快了”。
更重要的是，它会反过来要求产品、研发、测试、设计、管理方式一起变化。
如果研发速度提升了，但产品决策还是慢的，团队仍然会卡住。 如果代码生成变快了，但验证体系没有升级，质量风险会放大。 如果原型更容易做了，但用户反馈机制没有建立，团队会更快地做出错误东西。 如果 AI 可以总结上下文，但团队信息依然散落在聊天记录里，AI 也很难真正帮上忙。
所以，AI 原生不是工具问题，而是组织问题。
它要求我们重新思考：
哪些流程还有效？ 哪些流程只是惯性？ 哪些工作应该自动化？ 哪些判断必须由人负责？ 哪些角色需要重新定义？ 哪些能力会变得更重要？
不要只问“AI 能帮我做什么”，也要问“哪些流程已经不该存在”
给我的最大启发是：
AI 原生组织不是简单地把 AI 加到现有流程里，而是要重新设计流程本身。
如果一个流程本来就低效，把它 AI 化，只是让低效变得更快。 如果一个会议本来就没有价值，让 AI 自动生成会议纪要，也只是让无价值的内容更容易被保存。 如果一个需求本来就不该做，让 AI 更快写出代码，也只是更快地浪费资源。
真正有价值的做法，是从最吵、最重、最让团队痛苦的工作流开始，认真问一句：
它还值得存在吗？
这可能才是 AI 原生工程组织最重要的起点。
附录：参考资料
原文： https://claude.com/blog/running-an-ai-native-engineering-org
相关视频： https://youtu.be/igO8iyca2_g?si=RNMBWAz-dj7KYYvx