AI Native 时代：程序员何去何从

Saltysth

193人浏览 · 2026-06-06 16:39:00

Saltysth · 2026-06-06 16:39:00 发布

引言

最近读了一篇阿里技术关于 AI Native 组织的文章。开头一个数据让我印象深刻：几位深度使用 AI 的工程师，写代码时间从 30% 降到 5%，和 Agent 对话从 5% 升到 60%。纯编码效率提升 10 倍，但端到端交付效率只提升 2-3 倍。

更有意思的是节奏。一个工程师上午 10 点上线功能、中午做 A/B 测试、下午 3 点根据数据下线、5 点上线更好的版本——同一天。这是过去 6 周的迭代量。

这让我开始想一个问题：当 AI 能写 90% 的代码时，我们的价值在哪里？

这篇文章不聊 AI 能做什么，而是基于那篇文章和自己的思考，聊聊程序员在 AI Native 时代怎么生存、怎么转型，以及不得不面对的现实困境。

从 Org Chart 到 Execution Graph

要理解程序员角色的变化，得先理解组织本身在发生什么变化。

文章提到一个有意思的历史视角：组织的演化持续了两千年，核心都在解决同一件事——信息怎么路由。罗马军团的嵌套结构、普鲁士的总参谋部、美国铁路的组织架构图，本质上都在围绕一个约束做妥协：人的管理跨度。

一个人能直接管的下属在 3 到 8 之间，这个数字不是文化决定的，是人这个生物的硬限制。所以所有组织的金字塔结构都是在这个限制上做的妥协。

但当 AI 成为新的协作主体，这个前提开始失效。AI 的特点正好和人相反：人有沟通衰减，AI 没有；人需要激励，AI 不需要；人会疲劳和有情绪，AI 没有；人有 context switching 成本，AI 极小。

真正跑通 AI Native 的团队，工作呈现出两层结构。Harness 层是极度结构化的——代码、测试、流水线、文档，所有信息都被做成 AI 友好的形态，这一层 AI 主导。Hive Mind 层是极度松散的——对话、试错、idea 涌现，这一层人主导。

这个两层结构揭示了一个范式转换：当 AI 真的能行动、能调用工具、能修改系统时，公司就不再能被一张 org chart 准确描述，它变成了一张 execution graph——一个把人、agents、数据、权限、工具、审批关系当作同等节点的活的网络。

核心问题变了。从"谁拥有这件事"变成"意图从哪里进入系统？怎么被翻译成行动？什么约束让这个行动是安全的？"

从写代码到管理思维

在这个范式转换下，程序员的角色必须重新定义。

传统的程序员工作重心在项目的中后端：需求来了，写代码，修 bug，上线。但在 AI Native 时代，这个重心必须"向左"移动——向项目初期移动。

不是说你不写代码了，而是时间分配变了。文章中那位工程师就是例子：写代码 30%→5%，和 Agent 对话 5%→60%。

文章提出了一个关键角色：Architect——设计教 AI 怎么工作的人。

Architect 不是写代码的人，也不是堆功能的人，而是为整个 Execution Graph 设计架构的人。定义能力边界、设计 SOP、建立测试基础设施、定义"什么叫好"。

换句话说，Architect 是把组织的隐性知识——那些"大家知道但没人写下来"的约定、经验、规则——翻译成 AI 能够理解和执行的形态。

从"怎么做"到"做什么"，从"写代码"到"让 AI 能干活"——这是技能升级的核心方向。设计能力变得比编码能力更重要。你能否把一个复杂的工作分解成 AI 可以执行的步骤？你能否设计出让 AI 不会犯错的流程？你能否建立让 AI 能够自我验证的测试体系？这些才是 AI Native 时代程序员的核心竞争力。

转型的不对称性

“思维比能力更重要”——这个观点一直是对的，但 AI 直接替代了编码的能力，这让程序员的转型变得格外艰难。

程序员转型的难度极高。转向产品侧需要业务全面认知和产品思维，很多程序员整个职业生涯都无法完成。转向架构侧需要架构思维和系统设计，需要大量实践积累。

下面用PM举个例子。
但 PM 转型相对容易。他们本身就了解产品、熟悉业务，不需要翻译成编程语言，理解更迅速。想要拥有"编码能力"，只需要了解 AI 的使用方式和约束手段——靠着 token 资源，可以极其迅速地培养出来。

关键差异在于：程序员的"护城河"（编码能力）被 AI 直接填平，但 PM 的"护城河"（业务理解、产品思维）AI 无法直接替代。转型的门槛：程序员要爬一座山，PM 只需要过一条河。

留给传统程序员的方向基本只有两个：向左侧转型，在项目初期（需求/设计阶段）建立不可替代性；或者加速向架构侧努力，这是 AI 难以替代的领域，但门槛极高。

AI 的责任困境

会计永远不会被 AI 替代，因为 AI 没法替你坐牢。这个段子揭示了一个深刻的现实：AI Native 组织面临的核心矛盾是能力向 AI 转移，但责任仍在人。

当 AI 成为执行主体，但责任仍在人身上时，会出现什么情况？Agent 有能力做决策，甚至自主决策，但 Agent 无法承担后果，后果仍由人承担。

如果一个 Agent 造成了重大损失，比如安全漏洞、客户数据泄露，责任如何分配？是设计 Agent 的 Architect？是部署 Agent 的管理者？是监督 Agent 的 oversight 团队？还是没人能被问责，因为"这是 AI 的决定"？

即使 AI 写了 100% 的代码，出了问题，承担责任的人还是你。所以每个 Agent 都需要有明确的人类 owner，重大决策仍需人拍板，需要建立完整的审计轨迹，需要 Kill Switch——任何时候，人都能接管。

Code Review 的抄作业效应

还有一个更现实的问题：你能保证每一行 AI 的代码都是按照你的预期编写的吗？

如果 AI 辅助编码，原先的组内评审 1-2 小时，很快会膨胀成数个小时的折磨。

学生时代抄过作业的人应该有体会。抄的作业，即使当时认真看了、分析了、认为记住了，过不了多久，你还是不会。原因在于思考的深度不够，记忆与场景的联系不够。

假设现在过去了半年，我问你一个问题："这个需求的这行代码为什么这么写？"你能给出一个大概的答案吗？

问问自己，能不能立马回答这个问题。我相信绝大多数使用 AI 编程的程序员没法做到这一点。

Review 不是一个效率问题，一直是一个责任问题。当 AI 生成大量代码后，你真的理解每一行代码的作用吗？当出问题时，你能说出"为什么这行代码要这样写"吗？如果答案是"不能"，那你就是在为无法理解的代码承担责任。

蒸馏焦虑

文章中提到一个内部自嘲：“把自己蒸馏完，就在组织里没位置了。”

蒸馏这个词太准确了。员工每写一份 SOP、每教 AI 一个流程，确实是在把知识"导出"到组织资产里。它感觉是合作行为，但结构上接近一种替代关系。你在帮助 AI 更好地工作，你的知识被转移到了系统。你是 Architect，设计工作流程，但设计完成后，执行不需要你了。公司有了可复用的资产，也有了可替代的版本。

预见到蒸馏的员工，会采取什么行动？知识藏匿，关键知识不外传，保持不可替代性，但 Harness 工作无法完成，转型失败。先行动者离开，最优秀的人先走，他们外部选择最多，剩下的是 risk-averse 的 followers。消极对抗，表面配合，实际保留核心能力，但 AI 永远无法真正接管。主动转型，成为 Architect，转向更高价值的工作，但前提是组织有真实的"接住"机制。

原文对此非常坦诚："我不假装有完美方案。"提到的一些方向——明确 AI 红利分享方式、建立真实的"接住"机制、改变评价系统——这些都只是思路，没有一家公司有完整方案。

更复杂的是培养断裂。旧路径清晰，新路径断裂。入门级岗位可能消失，整个行业不招 day 1，三五年后 senior 池开始枯竭——这是产业级灾难。

AI Native 转型最难的部分不是技术，是处理"被转型"的人。组织里的人不是 capability units，他们有 ego、有焦虑、有家庭、有身份。AI Native 不是把人当 capability 调度——是给 capability 之外的部分留出位置。但这个位置到底在哪里？目前没有人有答案。

几个生存建议

聊了这么多问题和困境，最后落到具体的生存建议。

从"自己做"到"让 AI 能做"。这是最核心的思维转变。你不再是"做这件事的人"，你是"设计让这件事能被完成的人"。

时间分配会变化。写代码 30%→5%，和 Agent 对话 5%→60%。这不是个例，这是 AI Native 程序员的新常态。你的沟通对象从人变成了人和 AI 的混合体。

技能转变。你能否把一个复杂的工作分解成 AI 可以执行的步骤？你能否设计出让 AI 不会犯错的流程？你能否建立让 AI 能够自我验证的测试体系？这些才是核心能力。

协作转变。AI 不是工具，是新的协作主体。但它是特殊的——可以被无限复制、同小时既 brilliant 又 brittle、compliance-blind by default、fast enough to fail at scale。管 agent 不是管软件、也不是管人，需要第三套治理框架。

责任转变。即使 AI 写了 100% 的代码，出了问题，承担责任的人还是你。这是 AI Native 时代程序员必须接受的现实。