最近看招聘信息时，我反复看到一个词：AI Native 思维。
一开始我把它理解成“更熟练地使用 AI，尽可能的让AI生成代码”：会写 Prompt，会让模型生成代码，会用 Coding Agent 修 Bug。但看完 OpenAI 团队用 Codex 开发 Sora Android 的复盘后，我意识到，这个理解仍然停留在“AI 辅助”阶段。
AI Native 真正改变的，不是写代码的速度，而是工作的基本分工。
四名工程师、28 天，以及一种新的研发方式
2025 年 10 月 8 日到 11 月 5 日，OpenAI 的一个精简团队把 Sora Android 从内部原型推进到全球发布：内部版本研发用了 18 天，10 天后正式上线。团队只有四名工程师，每个人都在使用 Codex，整个项目大约消耗了 50 亿 Token。OpenAI 估计，最终约 85% 的代码由 Codex 编写。OpenAI：How we used Codex to build Sora for Android in 28 days
这并不是“四个人各自开一个代码补全工具”。他们的工作方式发生了更深的变化：
- 人负责架构、模块边界、依赖注入、导航和关键基础设施；
- 团队先实现少量具有代表性的完整功能，给 Agent 提供可模仿的工程范式；
- 非简单任务先让 Agent 阅读代码、解释数据流、形成计划，再开始修改；
- 多个 Codex 会话并行负责播放、搜索、错误处理、测试和重构；
- 工程师把更多时间用于澄清、评审、体验和集成，而不是逐行敲代码。
他们甚至试过一句话让 Codex “照着 iOS 版本构建 Android 应用”，结果虽然能工作，产品体验和工程质量却不理想。真正有效的方式，是由人先建立结构、提供范例、定义不变量，再让 Agent 在清晰的边界内完成大量实现。
这件事给我的触动是：Codex 不再只是工程师手里的工具，而是进入了团队的生产流程。
我理解的 AI Native
我现在更愿意这样定义它：
AI Native 思维，就是默认把 AI 当成一个能力很强、速度很快、边际成本较低，但并不完全可靠的执行单元，并围绕它重新设计工作，而不是给原有流程外挂一个聊天机器人。
它的分工可以概括为：
人负责目标、边界、判断和结果；AI 负责搜索、分析、生成和执行；测试与评测负责裁决。
这里真正重要的关键词不是 Prompt，而是：
任务重构、上下文工程、工具编排、评测闭环、结果所有权。
Prompt 只是给 AI 下达指令的一种界面。AI Native 关注的是另一组问题：任务怎样拆分，AI 能看到什么，能调用什么，怎样得到反馈，失败后如何恢复，以及谁对最终结果负责。
从“会问 AI”到“重新设计价值链”
可以把使用 AI 的成熟度粗略分成四层。
第一层：会问 AI
帮我写一个 FastAPI 接口。
模型给出代码，使用者却无法解释设计，也不知道如何判断结果是否正确。这一层获得的是生成速度，还没有获得可靠的交付能力。
第二层：AI 辅助开发
让 AI 解释代码、补全函数、修复 Bug、生成测试，工程师自己逐段检查和拼装。效率已经有所提升，但工作流的中心仍然是“我来执行，AI 给建议”。
第三层：AI Native 工程师
先定义需求、约束和验收标准，再把一段完整工作委派给 Agent。Agent 可以探索仓库、修改多个文件、运行测试、读取失败日志并继续迭代；工程师负责提供方向、评审关键决策、处理高风险动作并验收结果。
OpenAI 将这种变化描述为：Agent 逐渐成为“第一遍实现者”，工程师则转向规格澄清、架构判断、性能与安全审查，以及长期质量维护。Building an AI-Native Engineering Team
第四层：重新设计业务流程
较低层次的问题是：
怎样用 AI 更快地开发一套招聘系统？
更高层次的问题是：
当 Agent 已经能读简历、检索资料、调用内部系统、生成评价并保留证据，招聘流程还需要原来那些表格、会议和人工流转吗？
这才是 AI Native 最有价值的部分：不是把原流程中的某个动作加速 30%，而是重新审视整个价值链中，哪些步骤仍然有存在的必要。
AI Native 的五项核心能力
1. 从“我该怎么做”切换到“任务应该怎样分配”
传统思维首先考虑实现步骤：我要学什么、写哪些代码、按什么顺序完成。
AI Native 思维首先考虑任务结构：
- 最终要交付什么结果？
- 哪些决策依赖业务判断，必须由人负责？
- 哪些探索和执行可以委派给 AI？
- AI 需要哪些代码、文档、工具和权限？
- 哪些动作可自动执行，哪些必须人工批准？
- 用什么证据判断任务已经完成？
这本质上是一种组织智能的能力：不是亲手完成所有动作，而是把人、模型、工具和验证机制组织成一个能交付结果的系统。
2. 把模糊想法转化为可执行规格
当代码生成成本下降，“把需求说清楚”的价值反而上升。
一个适合交给 Agent 的任务，至少应该包含：
目标：最终要改变什么范围：允许读取、修改哪些模块约束：哪些接口、行为和依赖不能改变场景：正常路径、边界条件和异常路径验收：需要通过哪些测试、检查或人工体验交付：需要提供哪些 diff、日志和风险说明例如，“给用户接口增加校验”很难稳定执行；下面的规格则可以直接进入研发闭环：
为 POST /users 增加邮箱格式校验。
- 只修改 users 模块及其测试；- 保持现有响应结构不变；- 非法邮箱返回 400 和错误码 INVALID_EMAIL；- 补充合法、缺失、非法三类测试；- 完成后运行 users 模块测试和静态检查；- 输出修改文件、验证结果与未覆盖风险。比“神奇 Prompt”更重要的，是需求分析、接口设计、约束表达和验收标准。
3. 为 AI 配置环境，而不只是和它聊天
Agent 的产出质量，不只由模型决定，还取决于它所在的执行环境。一个可工作的环境至少包含四类要素：
| 要素 | 作用 | 工程中的例子 |
|---|---|---|
| Context | 告诉 AI 项目是什么、怎样工作 | 代码、架构文档、业务规则、示例实现、AGENTS.md |
| Tools | 让 AI 从“建议”走向“行动” | 文件系统、搜索、Shell、数据库、浏览器、内部 API |
| Memory | 保存任务进度和长期约束 | 会话历史、计划文件、决策记录、压缩摘要 |
| Feedback | 让 AI 根据真实结果纠偏 | 编译错误、测试结果、Lint、日志、评测指标、人工评审 |
现代 Coding Agent 之所以比普通聊天模型更能完成任务，不只是因为模型更强，而是它能进入这样的循环：
理解目标 → 探索环境 → 制定计划 → 执行动作 ↑ ↓ └── 根据测试、日志和评审继续纠偏 ──┘AI Native 工程师不是苦练一句万能 Prompt，而是在搭建一套 AI 可以闭环工作的环境。
4. 从确定性测试扩展到概率性评测
传统程序常常可以用精确断言判断：
固定输入 → 固定输出 → 断言相等但 LLM 的输出具有概率性，同一个目标可能由不同路径完成。评价 Agent 时，不能只问“这一次看起来对不对”，还需要统计一组任务上的整体表现与失败分布。
因此，一套成熟的评测至少要关注：
- 任务成功率：最终目标是否完成；
- 功能正确性：测试、构建和静态检查是否通过；
- 轨迹质量：是否无效探索、重复调用或绕过约束；
- 回归风险：原有功能是否被破坏；
- 成本与延迟：用了多少 Token、工具调用和时间；
- 安全性：是否越权、泄露信息或执行高风险动作；
- 可审查性：是否给出 diff、日志、来源和未验证风险。
Agent 越自主，评测越重要。因为生成速度越快，未经验证的错误同样会更快进入系统。
5. 对结果负责，而不是只对代码负责
传统工程师容易认为：“我亲手写的，才有把握。”
低质量的 AI 使用者则可能认为：“这是 AI 写的，出问题不怪我。”
AI Native 工程师应该持有第三种态度：
代码可以不是我逐行敲的，但系统行为必须经过我的理解和验证，最终结果由我负责。
因此，未来更稀缺的能力并不是快速生成一万行代码，而是：
- 定义什么叫正确；
- 识别错误和遗漏；
- 判断局部修改的系统影响；
- 设计可靠的验证手段；
- 在信息不完整时做出取舍；
- 知道什么时候应该停止自动化并由人接管。
一个可复用的 AI Native 研发闭环
把前面的能力组合起来，一项研发任务可以按下面的闭环推进：
- 定义结果：明确业务目标、范围、约束和完成标准。
- 准备上下文：提供入口文件、相关文档、范例和项目规范。
- 让 Agent 先探索和计划：先校正它对系统的理解，再批准实施方案。
- 分阶段执行：把大任务切成可验证的小增量，限制权限与修改范围。
- 自动获得反馈：让 Agent 主动运行测试、构建、Lint 和安全检查。
- 人工评审关键决策：检查架构、业务语义、安全、体验和长期维护成本。
- 交付证据：保留 diff、测试日志、风险清单和回滚方式。
- 沉淀环境：把本次纠偏转化为规范、测试或示例，让下一次执行更可靠。
最后一步尤其重要。只在对话里告诉 Agent “以后不要这样”，经验会随着会话结束而消失；把经验写进测试、规则和项目文档，才真正提升了系统能力。
AI Native 不等于 Vibe Coding
最容易出现的误区是：
AI 写得越多，我就越 AI Native。
事实并非如此。
DORA 2025 把 AI 描述为组织能力的“放大器”：它会同时放大已有的优势与缺陷，真正的收益取决于底层工程系统，而不只是工具本身。
METR 在 2025 年初对 16 名熟悉大型开源仓库的资深开发者做随机对照实验，观察到允许使用当时的 AI 工具后，任务完成时间平均增加了 19%。METR 明确提醒，这只是特定人群、仓库和早期工具条件下的快照，不能外推成“AI 会拖慢所有开发者”。2026 年的后续数据出现了加速迹象，但研究团队认为选择偏差较大，暂时无法可靠估算加速幅度。
这些研究至少说明一件事：用了 AI，不等于生产率自然提高。
真正的 AI Native 不是：
- 同时开五个 Agent，却没有任务边界；
- 复制大量代码，项目能启动就算完成；
- 遇到问题只会继续追加 Prompt；
- 不理解系统结构，也没有验证结果；
- 把评审、风险和责任一起外包给模型。
它恰恰意味着：
更少地手工执行，更严格地定义、验证和控制。
怎样开始培养这种思维
不需要先搭一套宏大的 Agent 平台。最有效的起点，是选一个真实、低风险、可验证的小任务，完整走一遍闭环。
第一阶段：从“提问”升级为“委派”
挑一个一小时左右能完成的任务，不再问“这段代码怎么写”，而是写清目标、范围、约束和验收标准，让 Agent 负责探索、修改和验证。你只处理关键决策。
第二阶段：把口头纠偏变成工程资产
每当 Agent 犯错，追问它缺了什么：是上下文、工具、权限边界，还是可执行的验收标准？然后把答案沉淀到项目规范、测试、示例或自动检查中。
第三阶段：记录真实收益，而不是依赖体感
至少记录四个指标：总耗时、人工介入次数、一次通过率、回归问题数。AI 让“输入代码的时间”减少，并不代表端到端交付时间一定减少。
第四阶段：重新审视流程
当单点任务已经稳定，再问：哪些等待、交接、汇总和重复确认可以被移除？这一步才会从“更快做事”走向“重新设计工作”。
写在最后
我曾经把 AI Native 理解为用AI写更多的代码就是AI Native。实际上我一直停留在“我来问，AI来做“这个层次。在这个关系里，我仍然是唯一的执行者，AI 只是一个更聪明的搜索框。
AI Native 带来的变化，是把 AI 当成一个真正进入工作流的执行单元：给它目标和环境，让它行动；用测试和评测约束它；在人类更擅长的地方做判断，并对最后的结果负责。
这并不会让工程师变得不重要。恰恰相反，当“生成”越来越便宜，定义问题、设计系统、判断质量和承担责任会变得更加重要。
未来衡量一个工程师的方式，可能不再只是他亲手写了多少代码，而是他能否组织人、AI 与工具，在不确定性中持续交付可靠结果。