工程师价值没有消失：它上移了

AI 把"写代码"变便宜了，但没有把工程师变便宜。稀缺性只是从写代码，转移到了定义问题、识别边界、验证结果。

这个网站的主题不是"AI 编程"。这个词太窄，也太容易被理解成"会写 prompt"。

更准确的主题是：

AI 时代的工程交付方法论：从会用 AI，到会组织 AI 解决问题。

我的核心竞争力也不是"我会让 AI 写代码"，而是：

我能把模糊需求变成可执行规格，把 AI 黑盒变成一条可验证、可复用、可交付的工程流水线。

这不是一句口号。这一章先摆行业数据，再用一个具体反例说明问题出在哪，最后给出全站的方法论地图。

一、先看数据：生成能力过剩，交付质量成了新瓶颈

"AI 正在写越来越多的代码"已经不是预测，而是财报数字。Google 在 2024 年第三季度财报电话会上披露：公司内部超过四分之一的新代码由 AI 生成，再经工程师审查后合入。生成侧的产能问题，实质上已经解决了。

但同期的三份独立研究，共同指向了硬币的另一面：

• DORA 2024 年度报告（Google Cloud 的 DevOps 研究项目，样本约 39,000 名从业者）发现：AI 采用度每提升 25%，交付吞吐量反而下降约 1.5%，交付稳定性下降约 7.2%。写得更快，交付得没有更快，稳定性还变差了。
• GitClear 对数亿行代码变更的纵向分析发现：AI 辅助编程普及后，复制粘贴式的重复代码占比显著上升，而代表重构和代码复用的"代码移动"操作显著下降——代码库正在以更快的速度变得更难维护。
• METR 2025 年的随机对照实验发现：资深开源开发者在自己维护的仓库上使用 AI 工具，实际耗时增加 19%，而他们自估快了 20%。体感提速和实测结果之间隔着 40 个百分点的错觉。

这三份研究口径不同、方法不同，但结论互相印证：代码生产成本趋零，但工程质量的成本一分没降——它只是从"写"转移到了"审"和"验"。 谁能承接这部分转移出来的成本，谁就承接了转移出来的价值。这就是本站全部内容的出发点。

二、反例：一句"写个GMV 清洗迁移链路"为什么会出事故

假设需求只有一句话：

把旧的生态店铺 GMV 清洗逻辑迁移为 Java 链路。

你把它丢给 AI，它很快会生成 Controller、Service、Repository、事务注解、表结构，甚至还有注释。代码看起来很完整，本地也能跑。

但上线后可能出现这些问题：

• 同一平台与日期范围被两个任务重复触发，产生不可解释的重复写入；
• 预览参数失效，排查动作意外删除或写入正式数据；
• 平台特例散落在总控逻辑里，新增或调整平台要修改多处；
• 某个平台失败后，系统仍刷新了“完整”汇总；
• 目标表没有白名单约束，参数错误可能把结果写入非预期表。

关键是理解为什么 AI 会这样写。这不是能力缺陷——模型在代码基准上的分数逐年逼近人类专家。真正的机制是：

在你没说清的每一个地方，AI 都会按训练数据里最常见的写法替你做默认假设。

训练语料里大多数"GMV 清洗服务"是教程和 demo：单平台、固定日期、无失败恢复、无结果核对。所以它默认只有一个平台、默认不会重跑、默认源数据永远完整。这些假设在 demo 里全部成立，在生产环境里全部致命。

换句话说：模型再强，也解决不了"你没给它的信息"。 这个洞会一直存在，而填这个洞恰恰是工程师的工作。

三、原则：稀缺性上移到了三个位置

沿着上面的机制推下去，AI 时代工程师的价值不是消失了，而是集中到了三件 AI 做不了、或做了你也不敢信的事上：

1. 定义问题——把"帮我写个GMV 清洗迁移链路"这种业务意图，翻译成幂等策略、并发边界、失败回滚、权限模型都明确的工程规格。AI 无法替你决定"重复请求应该返回原范围结果还是报错"，因为这是业务取舍，不是技术推断。

2. 组织上下文——你的系统是分布式的、有历史表结构、有旧接口要兼容，这些信息在你的代码库和你的脑子里，不在模型的训练数据里。把它们组织成模型可消费的输入（项目约束文档、规格、检索），决定了模型发挥的上限。

3. 验证结果——AI 最擅长生成"看起来对"的代码。把"看起来对"逼成"真的对"，需要能真实失败的测试、独立上下文的审查和回归闭环。生成可以外包给模型，信任不能外包。

这个判断不是我一个人的。整个行业的工具演化正在收敛到同一方向：GitHub 在 2025 年开源 Spec Kit，把"先写规格再生成代码"做成官方工作流；AWS 推出的 Kiro 直接把 spec-driven development 做成 IDE 的核心交互；"context engineering"（上下文工程）在 2025 年取代 "prompt engineering" 成为业内通用词——大家都发现了同一件事：瓶颈不在模型，在喂给模型的东西和检验模型产出的方式。

本站的方法论，就是把这三件事串成一条流水线。

四、地图：覆盖全生命周期的一套规程

本站的规程覆盖系统的完整生命周期——不止于"代码交付"，一直到运行期的排查与业务解答：

阶段	解决的问题	关键产物
① 认知	价值上移到了哪里	判断框架：三层角色、两道分水岭
② 需求	AI 动手前，人先审需求	八维体检表、待确认清单、EARS 行为规格
③ 设计	让 AI 在正确的结构里工作	四层上下文、结构决策 ADR、机器强制的边界
④ 执行	把 AI 当执行团队	决策权分层、工作单、编排链路
⑤ 验证	生成不等于交付	四道闸门、能真实失败的测试、缺陷库
⑥ 运行与解答	交付后系统必须自己会说话	知识层：业务自助查询、AI 辅助排障
⑦ 实证	证明方法能放大、能跨领域	系统级案例复盘、Harness 实录

整套规程有一份可直接喂给 AI 的浓缩版：总规程——复制进你的项目规则文件即可执行，这是"标准化经验"的最终形态。

关于例子的约定：本站用“生态店铺 GMV 清洗迁移”作为贯穿例，用异构数据同步平台作为系统级交叉验证。方法论用领域无关的不变量表达，事实边界以项目证据页为准。

适用边界也要说在前面：这套规程针对有存量系统、有质量要求的业务工程——有并发、有资金、有历史包袱、出了缺陷要担责的那种。一次性脚本和原型验证不适用，直接让 AI 放开写就好。方法论的重量必须和风险成正比，执行篇会展开成具体的任务分级。

五、模板：判断一个 AI 需求是否能开工

在让 AI 写代码前，先问自己：

【需求是否清楚】
- 业务目标是什么？
- 成功状态是什么？
- 谁来验收？

【边界是否清楚】
- 正常路径是什么？
- 重复、并发、失败、超时怎么处理？
- 权限和数据边界是什么？

【上下文是否清楚】
- 单体还是分布式？
- 技术栈和项目规范是什么？
- 是否有历史表结构、旧接口、兼容性要求？

【交付是否可验证】
- 有哪些测试用例？
- 如何证明没有重复数据？
- 如何证明失败可回滚？

如果这些答不上来，AI 不是不能开工，而是会替你猜——按第二节说的机制，猜训练数据里最常见的那个答案。

六、例子：GMV 清洗迁移链路的正确打开方式

不要这样问：

把旧的生态店铺 GMV 清洗逻辑迁移为 Java 链路。

应该先把问题变成：

我要把九个平台的旧 GMV 清洗逻辑迁移到 Spring Boot 链路。
总控只负责编排，平台销售、退款与日期特例保留在各自执行器。
save=false 只预览，不删除、不写入、不刷新汇总；save=true 仅允许白名单目标表。
continueOnError 决定单平台失败后继续还是停止，但任一失败都不能刷新完整汇总。
结果必须返回平台级行数、耗时和失败原因，并覆盖未知平台、无效日期、预览、部分失败和全量成功测试。
最终通过同平台、同日期范围的新旧结果对照确认口径，未完成核对前不宣称生产一致。

两段话的差别，就是普通 AI 使用者和 AI-native 工程师的差别：前者把翻译成本留给运气，后者把它做成了自己的工作。

七、本章小结

• 生成侧产能已经过剩（Google：25%+ 新代码由 AI 生成），但交付质量成了新瓶颈（DORA：稳定性下降；GitClear：重复代码上升；METR：体感提速是错觉）。
• AI 的核心风险不是写错，而是在你没说清的地方按训练分布替你做默认假设——模型再强也解决不了你没给它的信息。
• 稀缺性上移到三个位置：定义问题、组织上下文、验证结果；行业工具演化（Spec Kit、Kiro、context engineering）正在收敛到同一判断。
• 这套方法论适用于有质量要求的业务工程，不适用于原型和一次性脚本——流程重量必须和风险成正比。

下一章 需求体检，开始把一句模糊需求拆成可执行规格。

---

参考资料

• Alphabet 2024 Q3 财报电话会——Google 内部超过 25% 的新代码由 AI 生成、经工程师审查后合入。
• DORA, Accelerate State of DevOps Report 2024——AI 采用度每提升 25%，交付吞吐量约降 1.5%、交付稳定性约降 7.2%。
• GitClear, AI Copilot Code Quality 研究——AI 辅助普及后重复代码上升、重构性代码移动下降。
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025）——随机对照实验：实测慢 19%，自估快 20%。
• GitHub, Spec Kit——规格驱动开发的官方开源工作流。