一名兼写小说的软件工程师，最近在个人博客《Reflections on Software Engineering in the Age of AI》里提了一个不太舒服的判断：AI 编程工具正在改变软件开发的核心劳动。

过去，工程师要定义需求、研究方案、写代码、补测试和文档，再提交 PR。现在，很多环节被压缩成三件事：写提示、审 AI 代码、合并变更。

这件事有意思的地方，不是“AI 会不会取代程序员”。作者也承认，Claude、Codex 这类工具已经能生成相当可用的代码，也适合做技术概览查询。

真正的问题是：当开发者越来越少亲手穿过问题本身，软件行业还能不能培养出下一代真正懂系统的人。

开发流程变短了，人的位置也变了

原文最有价值的部分，是把旧流程和 AI 流程放在一起看。

旧流程里，工程师的大部分创造发生在脑中。拆需求，选方案，判断依赖，写测试，补文档，和同事讨论 PR。每一步都慢，但每一步都在训练判断力。

AI 介入后，创造过程更多发生在模型内部。工程师拿到的，不再是一块待雕的木头，而是一份已经成形、但不知道哪里埋雷的稿子。

环节旧流程AI 介入后的常见变化风险
需求定义写清功能边界、异常情况、验收方式转成提示词隐含约束容易丢
研究与设计比较库、算法、外部服务和维护成本让模型给方案方案像样，但未必懂业务上下文
编码亲自实现，边写边修正理解生成后人工改人更像校对者
测试根据风险补测试、补边界要求模型生成测试测试可能覆盖了“看起来对”的路径
文档解释为什么这样做生成说明文档流畅，但可能掩盖真实取舍
PR 审查同事审设计、实现和可维护性审 AI 产物并背书审查压力上移到资深工程师

作者用了一个很准的类比：历史小说家被出版社要求编辑一批廉价学生稿。产量可能上去了，但编辑不是创造。

这个类比放到软件里也成立。工程师面对 AI 代码时，常常是在找漏洞、补上下文、改笨拙实现，而不是沉入问题本身。效率提高了，心流被换成了审稿劳动。

我不太买账的是那种单线条叙事：只要代码更多，工程能力就更强。软件开发不是打字比赛。很多关键能力，恰恰是在慢慢写、慢慢错、慢慢调的过程中长出来的。

高级工程师不会消失，但验证成本会上升

AI 目前最不缺的是语法和套路。它真正难完整掌握的，是系统里的隐性知识。

一段代码是否违反法律要求，某个外部接口是 10 毫秒返回还是 10 分钟阻塞，一个新功能会不会撞上团队三周后的计划，安全函数和上月写的敏感数据处理逻辑是否冲突。这些判断，不在单个文件里。

它们藏在组织记忆、线上事故、历史债务、业务规则和团队路线图里。

所以，GitHub Copilot、Anthropic Claude Code、OpenAI Codex 这类工具在企业里的真实位置，更像速度很快的初中级开发者。它们可以补全、起草、改写、生成样板代码，但很难独立承担复杂系统责任。

这对资深工程师不是轻松，反而可能更累。

过去，资深工程师审的是同事写出来的代码。至少可以追问设计过程，知道对方为什么这么做。现在，他们还要审模型给出的“看似合理”的产物，并为它进入系统承担责任。

复杂性不会因为生成更快而消失。它只会转移到验证环节。

对技术管理者来说，这里有一个现实约束：不能只看“交付更快”。还要看审查是否被挤爆、事故归因是否变难、核心模块是否出现没人真正理解的代码。

比较稳妥的做法，是给 AI 使用划边界：

  • 样板代码、一次性脚本、技术概览，可以放宽使用。
  • 涉及权限、安全、计费、数据合规、性能瓶颈的代码，必须有人写设计说明。
  • AI 生成代码进入 PR 时，要标明生成范围、人工修改点和测试依据。
  • 资深工程师不要只审 diff，还要审需求边界和失败路径。

这不是保守。是给速度装刹车。

真正危险的，是学习链条被压扁

受冲击最大的，未必是今天的资深工程师。更可能是正在入行的人。

短期看，少数资深工程师配合 AI 工具，确实能更快交付原型、修普通 bug、写样板代码。2024 年以来，GitHub、JetBrains、Cursor 等工具都在把 AI 补全推向代理式开发，开发者很难完全回到纯手写时代。

但如果企业因此压缩初级岗位，几年后会出现一个更难补的洞：谁来经历笨办法、坏设计、线上事故和漫长调试，最终成长为能管理 AI 的高级工程师？

作者提到美国海军为了保留建造航母的工艺，会持续维持相关建造能力。这个参照不完美，但点出了一个朴素常识：手艺不是课件传下来的，是在真实项目里磨出来的。

软件行业也一样。高级工程师不是从“会审 AI 代码”开始的，而是从亲手写坏代码、修坏代码、背锅、复盘、再设计中长出来的。

这对两类读者最直接。

读者该调整什么不该做什么
软件工程师把 AI 当加速器，同时保留亲手设计、调试和写测试的训练不要只做提示词转发和表面审稿
技术管理者规定 AI 使用边界，保留初级工程师接触核心代码的机会不要把“少招新人”当成纯降本
技术创作者观察知识工作从创作转向编辑后的能力退化不要只写“效率革命”或“人类失业”两种老套叙事

接下来最该观察的，不是 AI 还能把代码写快多少。

更该看三件事：团队是否还让新人做真实难题；PR 审查是否变成流水线盖章；AI 代码是否有设计说明、测试证据和责任人。

如果这些都没有，生成速度越快，积累的未必是生产力，也可能是数字垃圾。

作者最后把 AI 生成内容比作廉价塑料制品。够用、便宜、可替换，也容易堆满世界。这个比喻有情绪，但提醒有效。

软件行业最怕的不是机器写代码，而是人慢慢失去判断代码的资格。