原文链接：Running an AI‑native engineering org
Claude Code 团队最近发了一篇《Running an AI‑native engineering org》，表面看是讲工程管理，好像和普通内容创作者、运营、产品经理、创业者隔得有点远。
但如果只把它当成技术团队的内部文档，反而错失了它真正想传达的信号。
这篇文章的价值，远不止告诉你怎么用 Claude Code 写代码。它在揭示一个更大的变动：
当 AI 把执行成本打到地板价之后，需要被重新推敲的绝不只是工具，而是整个工作方式。
过去，组织流程几乎都建立在一个潜在假设上——“执行很贵”。
写代码贵，所以得提前规划路线图；
研发资源贵，所以要反复打磨需求文档；
改动成本高，所以要开评审会、排期、控制变更；
信息传递低效，所以会议、周报、对口人成了维持协作的必需品。
这些流程在某个时代是合理的，是资源约束下的最优解。
但问题在于：当 AI 让大量执行动作大幅提速之后，那些旧流程并不会自动消失。它们像一套没人敢动的规矩，继续吃掉团队的时间和注意力。
在 Claude Code 团队内部，写代码、补测试、重构，已经很少再是最慢的环节。瓶颈悄悄移到了别处：验证、代码审查、安全、专业判断，以及团队在更快执行速度下如何保持协作质量。
这个变化不仅对工程团队致命重要。产品、运营、内容、设计、创业者，甚至所有正在用 AI 提升效率的人，都在经历类似的事：
- AI 可以写初稿，但替代不了你对选题价值的判断；
- AI 可以生成方案，但承担不了商业结果；
- AI 可以做原型，但分不清用户是真需要还是客套；
- AI 可以整理资料，但无法替你建立洞察。
所以，AI 原生工作的核心，不是“多装几个 AI 工具”，而是重新厘清一个问题：
哪些工作交给 AI？哪些流程直接砍掉？哪些判断必须由人来扛？
一、过去的流程，建立在“执行很贵”上
要理解 AI 原生团队，得先看清传统团队为什么长成现在这样。
以前做软件，工程产能属于稀缺资源。一个功能从想法到上线，要经历产品写需求、设计师出方案、工程师排期开发、测试验证、多人评审，然后才能发布。
因为写代码慢、改代码更慢，团队自然趋向于“先想清楚再动手”。于是前置流程层层加码：路线图要提前铺排、需求文档能写多详细就多详细、评审会一轮接一轮、排期求稳、上线控风险。
这些流程背后的逻辑很朴实：既然执行成本高，那就尽量别返工。
但 AI 改的，正好是这个成本结构。
当 AI 能帮着快速写代码、补测试、重构、修 bug，执行本身就不再那么昂贵。如果团队还死死抱着那套“为节省执行成本而设计”的流程不放，就会出现严重的错配——拖慢团队的不再是没人写代码，而是我们还在用旧方式规划、审查和协作。
Claude Code 团队也踩过这个坑。他们曾制定过一份六个月路线图，结果因为 Claude Code 带来的工作方式变化太快，三个月就过时了。不是团队不会规划，而是环境变化的速度已经甩开了传统规划方式的承载力。
当执行速度飙起来，过度规划反倒可能变成新的浪费。
二、规划方式变了：从长期路线图到 JIT planning
Claude Code 团队提了一个关键转变：规划方式从长期路线图，转向 just‑in‑time planning（刚好及时的规划）。
不是不规划，而是不再试图提前把未来几个月所有事都想透。在 AI 加速的环境里，很多判断只有在原型做出来、用户真实用上、反馈涌现之后，才会真正清晰。
以前的流程：先写完整方案 → 开会评审 → 排期开发 → 上线验证。
现在更合理的方式可能是：先做一个原型 → 让内部用户或小范围用户试用 → 根据反馈快速调整 → 再决定值不值得继续投入。
这不只是工程团队的事。产品经理同样可以用这套逻辑：以前写 PRD，恨不得业务逻辑、页面流程、异常状态全塞满，然后等研发排期；现在可以用 AI 先搭一个可交互原型，让大家先看到东西，再讨论值不值得做。
内容创作者也可以这样：过去为一个大专题策划十篇文章大纲、设计一整套封面，还不如先丢出一篇，或者先做选题测试，看看用户有没有真兴趣。
创业者更应该如此：以前做产品，可能要找外包、招研发，花几个月才见到第一版；现在 AI 让个人和小团队能更快拼出 MVP，但这恰恰意味着，你更不该一上来就追求“大而全”。
AI 时代最危险的努力，就是用更快的执行速度，去完成一个还没被验证的错误方向。
所以，JIT planning 的本质不是“少做计划”，而是把计划从“假设驱动”推进到“反馈驱动”。
它背后的哲学是：别在纸面上追求完美，先让事情进入真实场景。
三、协作方式变了：从“问人”到“问 AI”
第二个变化，是上下文获取的方式被重塑了。
过去，工程师碰到问题，第一反应是去找写这段代码的人——只有他知道当时为什么这么写、什么不能动。
可当越来越多代码由 AI 辅助完成，“谁写的”就不再是核心问题。更关键的是：你到底想知道什么？
是想定位谁引入了一个 bug？找到能回答客户问题的专家？理解某个技术决策的背景？还是知道某类反馈最近有没有集中出现？
这些问题未必都要先找人来问。很多时候，可以先让 AI 从代码、文档、评论、客户反馈、会议记录里帮你把上下文理出来。
放在非工程团队也是一样。很多组织的低效，不是缺信息，而是信息太散：客户反馈飘在群聊里，项目进展散在会议纪要里，内容复盘锁在表格里，历史方案丢在文档里，关键经验藏在某个人的脑子里。
过去解决这个问题，靠会议、周报、文档沉淀、找负责人打听；但在 AI 原生的工作方式里，AI 可以成为一个新的上下文入口——每天自动总结客户反馈、自动整理项目风险、从历史文档翻出类似案例、把会议内容整理成决策与待办、帮新人快速弄懂项目背景，让团队不用每次都从零解释一遍。
这个变化的核心是： AI 不光是生产内容的工具，它还能成为组织记忆的调用方式。
对个人来说也一样。你是内容创作者，AI 不该只用来写稿，还可以帮忙整理选题库、复盘历史爆款、分析用户评论、总结账号风格；你是运营，AI 不该只用来写活动文案，还能帮忙梳理用户反馈、分析活动数据、沉淀 SOP、发现流程卡点；你是产品经理，AI 不该只用来写 PRD，还可以帮你理解历史需求、整理竞品信息、总结用户访谈、快速形成原型方向。
真正成熟的 AI 使用方式，不是问它“帮我写一段”，而是问：我现在要做判断，需要哪些上下文？这些上下文能不能让 AI 先帮我理出来？
四、审查方式变了：人只审关键判断，AI 管底线
当 AI 能快速量产内容、代码和方案，一个扎心的问题就冒出来了：产出多了，谁来保证质量？
Claude Code 团队的答案不是“全交给 AI”，也不是“所有东西还得人来审”，而是重新划分地盘：AI 处理规则明确、重复性强、低风险的那部分，比如代码风格、lint、基础 bug、补测试、PR 反馈请求；人则必须出现在真正需要专业判断的地方——安全边界、法律风险、产品体验、设计品味、架构取舍、用户信任问题。这些地方不是光看规则过不过，而是要判断后果、权衡责任、理解上下文。
这个划分对所有岗位都管用。内容团队，AI 可以改错别字、写摘要、生成标题、整理资料，但选题立场、事实核查、品牌风险、表达分寸，还得人把关；运营团队，AI 可以生成活动方案、用户分层建议、复盘初稿，但预算投入、用户承诺、资源协调、关键策略，仍要人拍板；设计团队，AI 可以快速探索风格、生成参考、扩展素材，但最终的品牌气质、审美统一、用户感受，设计师不能撒手；创业者，AI 可以帮你做产品原型、落地页、销售话术，但商业判断、用户理解、定价策略、服务承诺，仍然不能全托给模型。
AI 原生团队不是取消人工审查，而是让审查更聚焦——过去人可能要检到底层细节，未来人应该把精力投入到真正高价值、高风险、高判断密度的位置。
一句话说透： AI 负责提高下限，人负责守住上限。
五、团队角色变了：岗位边界正在重新划分
Claude Code 团队还观察到一个非常重要的现象：角色开始模糊。
过去分工很清晰：工程师写代码，产品经理做规划，设计师做设计，运营做执行，内容人员写内容。但 AI 开始冲破这些能力边界。在 Claude Code 团队，PM 大量写代码，非传统程序员能介入更多工程工作，工程师也开始承担内容和设计这类过去不归他们的任务。
趋势很明确：未来岗位不会消失，但岗位之间的墙会变薄。
不是每个产品经理都要变成专业工程师，但产品经理需要更强的原型能力；不是每个运营都要变成程序员，但运营需要能搭建自动化流程；不是每个内容创作者都要变成设计师，但需要具备更强的视觉表达和分发系统能力；不是每个设计师都要完整开发，但可以用 AI 更快把想法变成可演示方案。
过去，一个人的价值可能来自“我能完成某类任务”；未来，一个人的价值会越来越收束到“我能定义问题，并调动 AI 把问题推进到可验证状态”。
这也是为什么 Anthropic 在文章中说，他们更看重两类人：一类是有产品感的创造型 builder，好奇、动手、愿意把想法变成产品，并且真在意它是不是解决了问题；另一类是有深层系统能力的专家，知道底层结构、边界条件和风险在哪，能在关键处做出高质量判断。
单纯的原生吞吐量，已经没那么重要了，因为大量执行工作，模型已经能扛一部分。
对每一个普通工作者而言，这个信号再现实不过：
如果你的价值只建立在“我比别人更快完成重复任务”，AI 会慢慢把你的长板削短。
但如果你的价值建立在“我更懂用户、更懂业务、更懂审美、更懂系统、更懂判断”，AI 反而会放大你的能力。
未来真正吃香的人，未必是最会操作某个工具的人，而是能把专业判断、问题意识和 AI 执行能力焊在一起的人。
六、组织方式变了：AI‑native 不是口号，而是工作流重构
很多公司谈 AI 转型，容易停在表面：买几个 AI 工具，组织几场培训，鼓励大家“多用 AI”，然后就觉得自己进入 AI 时代了。
但 Claude Code 团队的经验说明，AI‑native 不是工具采购，而是工作流重构。他们有几条原则很值得琢磨。
原则一：深度 dogfood 自己的产品。
团队成员必须高频使用 Claude Code 和 Claude Cowork，不是把 AI 当成外部附属品，而是嵌入日常工作流。每个人都在反复问：“这件事能不能让 Claude 帮我做得更快、更好？”
这对任何团队都适用。如果只是要求员工“多用 AI”，却没让 AI 进入真实业务流程，最后 AI 很容易变成可有可无的辅助。
真正有价值的使用，是让 AI 参与具体工作：参与选题、参与复盘、参与客户反馈整理、参与会议纪要、参与需求分析、参与原型制作、参与内容生产、参与数据解释。
原则二：尽量保持团队扁平。
工作流变化快的时候，层级太重会拖慢反馈。Claude Code 团队强调管理者也要先作为 IC（个人贡献者）去理解真实工作流，真正知道一线工作怎么发生。
AI 转型最怕管理层只看汇报，却不亲自理解工具如何改变一线。最后就会出现上面喊 AI 化，下面还是老一套流程，只是多了一张“使用 AI”的表格。
原则三：允许杀掉不再有效的流程。
这是我认为最重要的一条。很多流程当初确实有价值，但存在久了就变成组织惯性，没人再问它为什么存在，也没人敢取消它。
AI 原生团队必须不断追问：这个会议还必要吗？这个文档还必要吗？这个审批还必要吗？这个周报还必要吗？这个流程到底还在解决问题，还是只因为“过去一直这样做”？
AI 的价值不只是让旧流程跑得更快，而是让我们重新审视：有些流程，根本不应该被自动化，而应该被取消。
很多人一提到 AI，第一反应是“怎么用 AI 提高效率”，但更高级的问题是：这件低效的事，还值不值得继续存在？
七、怎么判断 AI‑native 是不是真有效？
如果一个团队说自己很 AI‑native，怎么区分是实打实变了，还是跟在热点后面跑？
Claude Code 团队给出了几个工程指标，比如新人上手时间有没有缩短、PR cycle time 有没有下降、Claude‑assisted commits 有没有上升。
但文章里还有一个更重要的提醒：不要把吞吐量误认为成功。
AI 最容易制造一种虚假的成就感：今天写了十篇文章，生成了五十个方案，做了三个原型，看起来高效到飞起。可问题是：这些产出真的解决问题了吗？
对内容创作者来说，不是一天写了多少篇，而是选题命中率、阅读完成率、转化率有没有提升；
对运营来说，不是产出了多少活动方案，而是活动上线速度、用户参与率、复盘效率有没有改善；
对产品团队来说，不是做了多少原型，而是验证周期有没有缩短、用户反馈有没有更快进入迭代；
对创业者来说，不是搭了多少页面、写了多少话术，而是有没有找到真实用户、真实需求、真实付费；
对个人工作者来说，不是用了多少 AI 工具，而是你的时间有没有从低价值重复劳动里解放出来，转移到更重要的判断、创造和决策上。
所以衡量 AI‑native，一个很简单的标准：它有没有让你更快接近真实问题？
如果只是让你更快产出更多东西，却没有更快拿到反馈、更快验证方向、更快形成判断，那它很可能只是“AI 加速的忙碌”。
八、普通人怎么开始？
读完这些，普通人不需要马上搭一个庞大复杂的 AI 工作系统。
最好的开始方式，是找一个最痛的工作流入手。问问自己：
- 我最讨厌的重复工作是什么？
- 我每周最耗时间但价值不高的事情是什么？
- 我最容易拖延的工作是什么？
- 我最需要别人反复解释上下文的地方是什么？
- 我有没有一些会议、文档、表格，其实早就没必要了？
然后继续问三个问题：
第一，这个流程现在还在解决问题吗？如果答案是否定的，不要自动化它，直接考虑取消。
第二，如果它仍有价值，AI 能不能扛掉其中 60% 的重复部分？比如整理、归纳、初稿、检查、汇总、生成候选方案。
第三，人应该保留在哪些关键判断节点？比如方向选择、事实核查、风险判断、审美把关、用户洞察、商业决策。
对内容创作者，可以从选题库、文章初稿、标题测试、评论分析、热点拆解开始；
对运营，可以从活动复盘、用户反馈整理、日报周报、SOP 生成开始；
对产品经理，可以从需求整理、竞品分析、原型说明、用户访谈总结开始；
对创业者，可以从落地页、MVP、销售话术、用户反馈收集开始；
对管理者，可以从会议、汇报、审批、跨部门协作这些最重的流程开始。
真正的 AI‑native，不是一天之内把工作方式全推倒重来，而是持续改造一个又一个具体流程。
AI 原生工作的本质，是重新分配人和 AI 的位置
Anthropic 这篇文章，表面讲的是 Claude Code 团队如何运转 AI 原生工程组织，但它给我们的启发远不止工程管理。
它说清楚了：当 AI 让执行速度大幅提高之后，工作的瓶颈会转移。
过去，瓶颈是“谁来做”；现在，瓶颈越来越变成“做什么、为什么做、怎么验证、谁来判断”。
过去，组织流程围绕执行成本设计；现在，组织流程需要围绕反馈速度、判断质量和风险控制重新设计。
过去，一个人的价值来自完成任务；现在，一个人的价值越来越来自定义问题、调用 AI、判断结果，并对最终结果负责。
所以，AI 原生不是多用几个 AI 工具，也不是让 AI 替代所有人。
它真正要求我们做的是：
把低价值、重复性、规则明确的工作交给 AI；
把人的注意力放回判断、创造、取舍、审美、责任和战略上；
同时，勇敢删掉那些已经不再服务目标的旧流程。
AI 让我们跑得更快，但更关键的是——我们是否知道自己为什么要跑，以及要往哪里跑。
在云栈社区，我们同样在记录和实践这场工作流的深度变革，欢迎一起探索、交流。
发表于 昨天 20:47
|
查看: 5|
回复: 0
