THESIS / 核心主张
会调用工具不是差异，能把工具放入责任明确、边界清晰、结果可验证的系统才是差异。
OPERATING STEPS / 执行动作
把原则变成可以检查的动作。
- 让 AI 承担检索、比较、实现和反例生成
- 由人冻结业务口径、接口契约和风险取舍
- 把一次提示升级为持续生效的工作环境
- 把输出质量与业务结果关联
OUTPUTS / 交付物
每个阶段都要留下可复用的产物。
APPLIED CASE / 项目映射
这条方法如何落到真实项目？
在 GMV 迁移中，AI 可辅助扫描文档、调用链和 SQL；平台口径、迁移范围与验收仍由负责人裁决。
FULL CHAPTER / 完整正文
从结论摘要，继续读到判断依据和执行细节。
正文保留 site-v3 的完整论证结构，并将贯穿示例改写为生态店铺 GMV 清洗迁移；原作者身份、原演示案例和未经证实的个人成果不进入本站。
从程序员到 AI-native 工程交付者
分水岭不是会不会调用 AI，而是能不能把 AI 组织进真实交付流程——并把过程沉淀成可复用的资产。
上一章用行业数据论证了价值上移的方向。这一章回答一个更个人的问题：上移之后，工程师这个角色具体变成了什么？
一、三层角色，两道分水岭
传统程序员
接需求 → 理解业务 → 设计方案 → 手写代码 → 自测联调 → 修 bug。这个模式没有过时，但其中"手写代码"环节的稀缺性被 AI 大幅压缩了。只靠编码速度建立竞争力的人，处境会持续变差——这是第一道分水岭，行业已经过了。
AI 使用者
让 AI 写接口、生成 SQL、改 bug、写测试、总结文档。比不用强，但不构成壁垒，原因值得说透：
AI 使用者的技能是会话级的，没有积累。 每次对话从零开始，好的产出依赖当次的运气和手感；换一个人、换一个会话，结果不可复制。这类能力的学习曲线只有几周，新手很快追平——不能积累的能力，就不能构成壁垒。
AI-native 工程交付者
工作方式的差异在每个环节都有对应：先审需求而不是先写 prompt；先定规格而不是先生成代码；先组织上下文而不是反复解释项目；把 AI 拆成角色执行而不是一个聊天框打到底；用测试、review、缺陷库验证产物。
但真正的分水岭在最后一步：把每次交付的经验固化成规则文件、规格模板、工作单、Skill、Hook 和缺陷库。 这些是留在项目里的组织资产——下一个任务、下一个人、下一个模型都能直接继承。AI 使用者产出代码，AI-native 交付者产出能持续产出代码的系统。这是第二道分水岭，也是本站方法论各章产物的共同去向。
二、能力模型
| 能力层级 | 传统开发 | AI 使用者 | AI-native 交付者 |
|---|---|---|---|
| 需求理解 | 被动接收 | 让 AI 总结需求 | 八维体检，识别 AI 的默认假设 |
| 问题定义 | 按描述实现 | 把描述丢给 AI | 翻译成 EARS 规格，歧义清零 |
| 架构设计 | 依赖个人经验 | 让 AI 给方案 | 按不可逆性排序：AI 提案，人拍板 |
| 上下文管理 | 靠自己记忆 | 临时粘贴代码 | 四层架构：规则、ADR、检索、注入 |
| 编码实现 | 手写为主 | AI 生成代码 | 工作单 + 多 Agent 编排 |
| 测试验证 | 自测联调 | 让 AI 写测试 | 验证闭环：先红后绿、变异抽查 |
| 交付复盘 | 修完就结束 | 生成总结 | 经验入缺陷库，回流成防线 |
第三列的每一项都不是技巧，而是有产物的动作——产物就是上一节说的组织资产。
三、工作重心的迁移，行业怎么看
工程师的时间正在从"查 API、写样板、搭接口"迁向"判断需求完整性、判断方案适配性、判断 AI 是否漏了边界、判断测试是否覆盖风险"。两个行业观察佐证这个方向：
- Karpathy 在 2025 年的 Software 3.0 演讲里给出了同样的结构：自然语言成了新的编程界面，但生成与验证的不对称是新瓶颈——生成是秒级的，人类验证跟不上，所以工程的核心变成了设计快速可靠的验证环（"keep the AI on a leash"）。本站的验证篇就是这个判断的落地。
- DORA 2024 的核心结论之一：AI 放大的是组织既有的工程能力——基础扎实的团队被 AI 加速，基础混乱的团队被 AI 加速地混乱。AI 不提供工程纪律，只放大工程纪律的有无。
这也解释了为什么"AI-native"不是更轻松的角色，而是要求更高的角色：它要求更懂业务、更懂系统、更懂风险——因为低杠杆的部分被拿走了，剩下的全是高杠杆判断。
顺带定位一个行业词：这类"深入业务现场、端到端组织技术交付"的角色，在 AI 公司里被称为 FDE（Forward Deployed Engineer，前沿部署工程师）——2024 年以来 AI 应用落地的稀缺岗位。AI-native 工程交付者可以理解为 FDE 能力模型在企业工程团队里的通用版。
四、以GMV 清洗迁移链路为例
普通 AI 使用者：
帮我迁移生态店铺 GMV 清洗链路。
AI-native 交付者在同一时刻做的事：
我要交付的是GMV 清洗与汇总能力，不只是一个接口。
先过体检：幂等语义？并发策略？事务边界？权限归属？验收用例？
→ 产出规格，然后才轮到 AI 动手。
前者把 AI 当代码生成器，后者把 AI 放进交付流程。具体差多少，生态店铺 GMV 清洗迁移案例有完整对照。
五、这套角色怎么对外表达
一句话版本：
我的价值不是让 AI 写几段代码，而是把 AI 的不确定输出，组织成可验证、可复用、可交付的工程结果。
面试场景下的 30 秒版、2 分钟版、被追问"是不是 AI 写的"怎么答，见面试表达专页。
六、本章小结
- 两道分水岭：手写代码的稀缺性消失（已发生）；会话级技能与组织资产的分野（正在发生）。
- AI 使用者不构成壁垒，因为会话级能力无积累、可速成；壁垒在于产出"能持续产出代码的系统"。
- 行业双重印证：Karpathy 指出生成-验证不对称是新瓶颈；DORA 指出 AI 只放大工程纪律的有无。
- AI-native 交付者是要求更高的角色——低杠杆工作被拿走后，剩下的全是高杠杆判断。
下一章进入方法论的第一个动作：需求体检。
参考资料
- Andrej Karpathy, Software Is Changing (Again)——Software 3.0 演讲（2025）：自然语言编程界面与生成-验证不对称。
- DORA, Accelerate State of DevOps Report 2024——AI 放大组织既有工程实践的效果，而非替代工程实践。