过去一年里，"用 AI 写代码"这件事在团队内部悄悄分化成了两个物种：有人把 AI 当成更聪明的自动补全，Tab 按得飞起，但工作流和三年前没有本质区别；也有人已经不怎么亲手写代码了，每天的工作是写规格、喂上下文、评审 agent 的产出。两种人都自称"在用 AI 辅助开发"，但他们的效率差距已经不是百分之几十，而是数量级。
后者践行的，就是最近硅谷讨论得越来越多的 AI Native 开发。这篇文章想聊清楚三件事：它到底是什么，为什么值得认真对待，以及——最重要的——怎么落地。文中会融合我自己近一年的一些实践和理解，也包括几个我认为被严重低估的"人的问题"。
一、什么是 AI Native 开发
一个简明的定义
AI Native 开发不是"用 AI 辅助写代码"，而是开发流程从第一天起就围绕"AI 是主要实现者"来设计。
传统模式里，AI 是插件：人写代码，AI 补全、答疑、润色，AI 不存在时流程照常运转，只是慢一点。AI Native 模式里，分工倒置了——人类负责定义与判断，AI 负责实现与迭代：人产出的是需求定义、架构决策、验收标准和评审意见；代码、测试、重构、文档由 agent 生成。开发者的角色从"写代码的人"变成了任务定义者、监督者和最终验证者。
Andrej Karpathy 把这叫做 Agentic Engineering，他给出的定义是：工程师拥有规格、评审和架构，指挥 agent 在受控环境中写、测、交付，每个结果都要过评审和自动化测试才算完成。他还有一句被反复引用的话："Vibe coding 抬高任何人能建造的下限，agentic engineering 抬高团队可信任的上限。"这句话精准划出了"随便用用 AI"和"AI Native 开发"的边界：前者是放养，后者是建制。
两个判别标准
怎么判断你的开发流程算不算 AI Native？我自己的体会是，它和判断一个产品是不是 AI Native 完全同构，核心就两条：
第一，成长性测试：大模型变强，你的开发能力是否跟着自动变强？
如果你的工作流深度依赖某个模型的特定癖好，模型一升级，提示词要重写、流程要重调，那 AI 对你来说是"工具"而非"基座"。真正的 AI Native 工作流建立在模型的通用能力上——理解力、推理力、代码力——模型换代时你什么都不用改，产出质量自动水涨船高。你的工程资产（规格模板、上下文文档、评审清单）与模型能力解耦，享受整个行业的进步红利。
第二，剥离测试：把工作流里的大模型抽掉，是效率打折，还是几乎无法推进？
如果剥离 AI 后你只是回到手写时代，慢一些但一切照旧，那 AI 在你的流程里还是增强件。如果剥离之后整个流程直接停摆——没人写实现、没人补测试、文档断更——说明 AI 已经是你开发链路的结构性组成，这才是 AI Native 的形态。
这两条标准在产品侧已经被投资人用了很久（抽掉 AI 产品还成不成立、模型变强你是开心还是难过），平移到开发流程上同样锋利。它们的价值在于防止自我感动：不是"我用了很多 AI"就算数，而是看 AI 在你的工程体系里是不是承重墙。
背景：三年三次认知升级
理解 AI Native 开发，值得知道硅谷对"工程师该如何与 AI 协作"的认知演进：
- Prompt Engineering（2022–2024）：相信写好一条提示词就能交付结果。
- Context Engineering（2025）：Shopify CEO Tobi Lütke 和 Karpathy 先后定调——真正的功夫是"为任务提供让模型有可能解决它的全部上下文"。Anthropic 随后发布工程博客把它确立为标准框架。业内一个广为流传的估计是：约八成的 agent 失败不是模型不行，而是上下文缺失或损坏。
- Harness Engineering（2026 起）：焦点再往外扩一圈，从"模型看到什么"到"agent 运行的整个环境"——沙箱、权限、工具、数据层、评测回路。一个流行的公式是：Agent = Model（大脑）+ Harness（运行约束底座）。
这条链的本质，是工程师的杠杆点逐层上移：写指令 → 组织信息 → 设计运行环境。AI Native 开发就是这条演进链落在日常工程实践里的样子。
二、价值在哪
1. 个人杠杆的数量级变化。 Sam Altman 预言的"一人十亿美元公司"在宏观层面尚待验证，但微观层面已经发生：一个工程师同时指挥多个 agent 实例并行开发，正在从奇观变成日常。杠杆的来源不是打字更快，而是你的判断力被复制成了并发。
2. 工程资产的重心迁移。 传统团队的核心资产是代码库和写代码的人；AI Native 团队的核心资产变成规格库、上下文文档、评测与评审回路——代码本身反而是从这些资产再生成的产物。这意味着资产更稳定：代码会因模型换代而过时，好的规格和上下文只会升值。
3. 能力边界的扩展。 当实现成本趋近于零，"要不要做"取代"能不能做"成为主要问题。前端可以碰后端，后端可以碰 infra，个人能覆盖的技术栈宽度被大幅拉开——瓶颈从"手艺"回到了"见识和判断"。
三、怎么落地
1. 先完成角色转换：从实现者到"任务定义者 + 监督者 + 最终验证者"
这是最难也最本质的一步。具体说，你的日常产出从代码变成四样东西：任务拆解（把模糊需求切成 agent 可执行的颗粒）、验收标准（什么叫"做完了"，先于实现定义清楚）、上下文供给（背景、约束、相关代码、历史决策）、评审判断（这个产出能不能进主干）。
一个心智上的校准：把 AI 当成一个极其聪明、执行力爆表，但没有常识、没有跨会话记忆、对指令字面服从的下属。你对这样的下属会怎么布置任务、怎么验收，就怎么对 AI。
2. 规格驱动开发（Spec-Driven Development）
先写清规格，再让 AI 实现，避免"边想边写"导致的架构漂移。业界的成熟做法可以参考 GitHub Spec Kit 的四阶段流程：/specify（定义需求）→ /plan（技术方案）→ /tasks（任务拆分）→ implement（实现），每个阶段人类审核通过后才进入下一阶段。更激进的流派（如 Tessl）甚至主张"规格即源码"：规格才是被维护的资产，代码是从规格再生成的产物。
我的实践经验是：规格不需要一开始就写得完美，但验收标准必须在实现之前写下来。这一条就能过滤掉大部分"agent 跑得很欢、方向完全是错的"的事故。
3. 把上下文工程当成正经事
给 agent 的上下文，就是你给新员工的入职材料。几件值得做的事：
- 维护一份高质量的项目级上下文文件（如 CLAUDE.md）：架构约定、代码规范、禁区、常用命令；
- 为大任务准备专门的上下文包，而不是指望 agent 自己在几十万行代码里考古；
- 上下文不是越多越好——填充要"恰到好处"，无关信息会稀释模型的注意力；
- 复盘失败的 agent 任务时，先问"是不是我给的上下文有问题"，再问"是不是模型不行"。多数时候答案是前者。
4. 架构设计与测试验证：Copilot 模式最高效
有一种流行的说法认为架构和评审必须 100% 留给人。我的实践体会略有不同：架构设计、测试验证这些"高判断力"环节同样可以用 AI 辅助，只是协作模式要从 autopilot 退回 copilot。
所谓 copilot 模式：AI 负责产出候选方案、穷举边界情况、扮演反方质疑你的设计，人负责拍板。比如架构设计时，让 AI 出三套方案并互相攻击，你来做取舍；测试环节让 AI 生成测试矩阵和边界用例，你来确认哪些风险真正值得覆盖。这些环节的瓶颈从来不是"产出草稿的速度"，而是判断质量——AI 把穷举和草稿的成本打到接近零，人的判断力被放大而不是被绕过。
自主性应该是一根滑杆而不是一个开关：低风险、易验证的任务（样板代码、文档、测试补全）可以给 agent 更多自主权；高风险、难逆转的决策（架构、数据迁移、对外接口）收紧到 copilot 模式。判断一个工程师是否成熟的标志，就是他调节这根滑杆的手感。
5. 守住评审回路，警惕认知债务
最后一条是护栏。MIT Media Lab 2025 年的研究提出了"认知债务"的概念：你交付的软件和你真正理解的软件之间的差距，是债。重度依赖 AI 而不保持理解，大脑参与度和记忆留存都会下降，效应在停用工具后仍会持续。落到工程上就是：系统能跑，但没人能完整解释它，改起来又慢又危险。
所以 AI Native 开发坚持"评审和最终验证留在人手里"不是保守，而是偿债纪律：每一行进主干的代码，都要有人能讲清楚它为什么是对的。
四、人的部分：两个容易被低估的真相
工具层面的落地聊完了，但这一年我更深的体会在人身上。
与 AI 协作是一项技能，也是一门艺术
很多人默认"AI 能力强 = 我用 AI 的效率就高"，这是误解。与 AI 协作本身就是一项技能，甚至是一门沟通、领导和管理的艺术——它同样需要刻意练习。
你观察带团队的高手就知道，管理效能约等于"任务定义的清晰度 × 反馈回路的质量"。对 AI 完全同理：能不能把模糊意图翻译成清晰任务，能不能给出有区分度的验收标准，能不能在 agent 跑偏时快速定位是上下文问题、拆解问题还是验收标准问题——这些都是可训练、可复盘的能力。
而且这个技能有复利：与 AI 并肩作战的时间越长，默契越高，效率越高。所谓"默契"，落到实处就是你沉淀下来的东西——项目上下文文件、提示词模板、评审清单、对"什么任务适合委派、委派多大颗粒度"的手感。这些资产会随时间增值，也是从"会用 AI"到"AI Native"之间真正的分水岭。我的建议是建立自己的复盘习惯：每周挑两三个 agent 任务（一成一败）拆解原因，手感就是这么练出来的。
不要用 AI 的杠杆，掩盖自己的停滞
这是我最想说的一条。
如果 AI 帮你提效一百倍，你应该琢磨的是怎么输出一百倍的价值。而一百倍的价值不可能来自一百倍的代码行数——它只能来自写代码之外的高级能力：系统设计、领域建模、需求洞察、技术品味、对"什么值得做"的判断。省下来的时间，应该被再投资到这些能力的生长上。
反过来，如果只是简单地把手头的工作转包给 AI，然后盯着显示器发呆——看上去产出提升了，实际上自身没有任何成长——这在职业上是一种慢性自杀。因为你在用自己的停滞，对冲整个行业的加速。AI 时代的工程师产出公式已经变了：
产出 = 判断质量 × AI 杠杆倍数
杠杆倍数人人都在涨，区分度全部落在判断质量上。判断质量不增长，杠杆越高，只是越快地制造平庸，甚至制造认知债务。工具在进化，人也必须进化——这不是鸡汤，是这个时代工程师的生存方程。
结语
AI Native 开发说到底不是一套工具用法，而是一次角色重定义：工程师的核心产出，从代码变成了规格、上下文、运行环境和评审判断。代码交给 agent，判断留给自己，成长押注在更高处。
判别标准很简单：模型变强时你的能力是否自动上涨，剥离模型后你的流程是否还能站立。落地路径也清晰：角色转换、规格驱动、上下文工程、copilot 模式分层、守住评审回路。而最终的护城河，不在模型手里，不在工具手里，在你自己的判断力和持续成长里。
参考资料
- Andrej Karpathy, Software Is Changing (Again), YC AI Startup School 演讲, 2025.6
- Andrej Karpathy 关于 vibe coding（2025.2）与 agentic engineering（Sequoia AI Ascent, 2026）的公开表述
- Anthropic, Effective Context Engineering for AI Agents, 2025.9 — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic, Claude Code: Best practices for agentic coding, 2025.4 — https://code.claude.com/docs/en/best-practices
- GitHub Spec Kit — https://github.com/github/spec-kit
- Vibe Coding vs. Agentic Coding: Fundamentals and Practical Implications, arXiv:2505.19443 — https://arxiv.org/abs/2505.19443
- CRV, AI-Native vs AI-Enabled: A Founder's Guide, 2026