ARTICLE · 1124116
AI 时代开发工程师:从写代码到定义与校验
现在让 AI 写一段能跑的代码，已经不是什么难事。于是焦虑来了：那还需要我吗？我的判断是——需要，而且比以前更需要。但你要干的活，换了。
先把话说准：AI 拿走的是"把代码敲出来"这一段。它拿不走的是——这段代码到底要解决什么问题、做到什么程度算合格、出了问题谁兜着。这三件事从来就不是打字打出来的，是判断出来的。
这个变化有个很有意思的对照。布鲁克斯在 1986 年那篇著名的《没有银弹》里区分过两种复杂性：本质复杂性——问题本身就难，绕不开；偶然复杂性——实现过程中附带的麻烦，比如语法、样板代码、环境配置。他的判断是：工具能消灭的，主要是后者。
四十年后看，这话对得惊人。AI 消灭掉的，恰恰是偶然复杂性那些部分。而本质复杂性——要做什么、边界在哪、什么情况算异常——一点没少，还因为产出变快显得更突出了。
所以开发工程师的价值不是在减少，是在迁移：从"把代码写出来"迁移到"把要写的东西定义清楚，再把它校验到位"。
按前面两篇的思路，你的工作流也该重画一遍，而不是给每个环节加个 AI 插件。重画之后大概是这四步：
图 1 · 开发工作流重构后的四步（人守两头）
注意两头是红的：定义和校验都在人手里。中间那步交给 AI，才能真的提速。很多团队反过来——定义含糊、让 AI 生成、然后人花大量时间去猜"它写的到底对不对"，结果省下的时间全赔进去了。
这里要接上上一篇那个说法：今天我们该标准化的，不是人的动作，而是智能体的验收标准。放到开发身上就是——你得先说清楚"什么样算合格"，AI 的产出才能被放心使用。
图 2 · 三类活，人的位置不一样
这件事其实不新。Kent Beck 在《解析极限编程》（1999）里推测试先行，本质就是先把"完成"定义清楚，再动手。只不过当时"先写测试"是为了约束自己，今天"先写验收标准"是为了约束智能体——对象变了，道理一模一样。
如果你不写生产代码，这套逻辑换个皮照样成立——因为"定义 + 校验"是所有产出型工作的通用结构。
图 3 · 三层主体，同一套结构
还是那句话：重要的是做事的思维，不是陷入细节。别纠结"哪个模型写代码更强"——那是细节，而且每个月都在变。你得先有"标准"，AI 的产出才有被使用的前提。
四篇下来，第一期的骨架越来越清楚了：思路 → 流程 → 管理 → 岗位。落到开发这个岗位上，一句话就能说完：你的产出从"代码"变成了"可验证的定义 + 可兜底的判断"。
这反而是好消息。打字这件事本来就不该是一个工程师最贵的部分；现在它便宜了，你终于可以把时间花在真正值钱的地方——把问题想清楚，把标准立起来，把结果兜住。
相关话题：AI 落地 · 流程重构 · 智能体协同 · AI 时代的岗位方向 · 组织重构