人工智能在代码工程领域的严重错位。

引言：我们究竟在优化什么？

本文受陶哲轩于 2026 年 9 月 11 日在博客刊载的数学界声明《A Severe Misalignment of AI in Mathematics》启发。声明提醒我们：解决问题是通往理解的一种手段，而不是理解本身。^[1] 本文将这一问题延伸到软件工程，是独立的观点文章，不是对该声明的翻译。

当我们用“关闭了多少 Issue”“生成了多少代码”“通过了多少测试”来衡量 AI 的工程价值时，一个问题值得追问：这些指标究竟在衡量工程能力，还是仅仅在衡量工程留下的某些可见产物？

以 SWE-bench 为例，它把真实代码仓库和 GitHub Issue 交给模型，要求模型修改代码以解决问题。^[2] 这比传统编程题更接近实际工作，但从一个局部任务的表现，仍不能直接推导出对整个软件生命周期的胜任。

代码本身并不是软件工程的终极目标。 软件工程真正需要交付的，是一个能够在现实约束下持续运行、持续演进，并且能够被理解、修改和负责的系统。

当 AI 优化的是“尽快完成当前任务”，而组织需要的是“让系统在未来数年仍然可以安全演进”时，两者之间便可能出现严重错位。

生成了代码、通过了测试、解决了 Issue，只是工程能力的代理指标，而不是软件工程最终要实现的目标。

通过测试，不等于完成了工程

一道编程题通常有明确的输入、输出和判定标准。但真实工程问题很少如此清晰。

例如，实现一个账户余额扣减功能，模型可以生成数据库更新语句、事务代码和单元测试。所有测试都可能通过，代码也可能看起来简洁规范。

然而，工程师真正需要回答的问题还包括：并发扣减时是否可能超卖？请求超时重试时是否满足幂等性？消息重复投递时如何处理？数据库主从切换会不会破坏一致性？下游已经成功、上游却认为失败时如何对账？

还有历史数据迁移、灰度发布、回滚策略，以及谁来监控这套机制。这些问题往往不会完整写进 Issue，也不会全部出现在测试用例里。

测试提供的，是在当前已表达的假设和覆盖场景下，代码表现符合预期的证据。它无法仅凭自身保证需求和假设正确，也无法穷尽未来生产环境中可能发生的情况。

因此，一个补丁通过全部测试，并不意味着它已经经受了现实世界的完整检验。软件工程面对的，是一个开放的、不断变化的环境。

完成被表达出来的任务，与发现尚未被表达的问题，是两种不同的能力。

如果评估只奖励测试通过率，就可能低估后一种能力。而发现缺失约束、澄清需求和识别未知风险，恰恰是高级工程判断的重要组成部分。

Issue 是工程能力的代理，不是工程的目的

Issue、需求单和缺陷单，不只是待清空的任务列表，也可以是团队理解系统、改善设计和训练成员的载体。

一名工程师修复一个看似简单的 Bug，往往需要阅读历史代码、理解调用链、查阅日志、复现问题、询问业务背景，并在这个过程中建立对系统的整体认识。

最终提交的十几行代码，可能只是数小时乃至数天思考后留下的痕迹。只观察最终补丁，很容易得出一个过于简单的结论：既然 AI 可以迅速生成相同的十几行代码，那么前面的理解过程就没有价值。

但解决 Issue，还可能承担这些不容易量化的功能：

• 更新团队对系统的共同理解，暴露架构中长期存在的问题。
• 训练工程师定位故障和判断风险的能力。
• 将隐性的业务规则重新沉淀到代码、测试和文档中。
• 建立“谁理解这部分系统、谁能够为它负责”的组织关系。

如果补丁增加了，而组织对系统的理解没有增加，任务列表变短未必意味着工程能力变强。

这不是说每个重复任务都必须由人亲手完成。真正需要保留的，不是手工劳动本身，而是借助任务形成理解、判断和责任的过程。

代码生成速度，可能超过验证速度

AI 带来的一个重要变化，是降低了生成代码的边际成本。但阅读代码、验证需求、判断架构、分析安全风险和承担生产责任的成本，不会因此自动以同样幅度下降。

于是，组织可能遇到一个新的瓶颈：代码产出的速度，超过了团队验证和理解代码的速度。

原本可以通过修改一个公共抽象完成的需求，可能被分散成多个局部实现；原本应该删除的旧逻辑，可能被新的兼容层继续包裹；原本需要重新设计的数据模型，可能被更多条件分支暂时绕过。

每次改动都能通过当前测试，每个 Pull Request 单独看也合乎逻辑。但经过数百次局部最优的修改之后，系统整体可能变得更加复杂。

更快地生成补丁，不等于更低的系统总成本。

成本可能只是从编写阶段，转移到了未来的审查、调试、维护、故障恢复和重构中。这种转移在人类开发中也存在，AI 可能放大它，而不是独有地造成它。

2025 年的一项随机对照研究提供了一个值得警惕的例子：16 名熟悉成熟开源项目的开发者完成了 246 项任务。使用研究所测试的早期 2025 年 AI 工具时，任务完成时间平均增加了 19%；参与者事后却估计，AI 让自己节省了约 20% 的时间。^[3]

这是一项特定人群、任务和工具版本下的结果，不能据此推断 AI 普遍降低效率，更不能把它当成对 2026 年工具的测量。 它说明的是：主观上感觉更快，与端到端工程效率更高，可能不是一回事。^[3]

技术债务之外，还有“认知债务”

工程团队熟悉技术债务：为短期交付作出的某些取舍，会增加未来修改系统的成本。AI 辅助开发还值得我们关注另一种风险。本文把它称为“认知债务”。

所谓认知债务，是指系统仍然能够运行，代码也可能通过测试，但团队逐渐无法解释：为什么需要这个条件？这个接口隐含了什么业务约束？重试策略对应哪一种故障模型？删除兼容代码会影响哪些历史数据？

两个看似重复的实现为什么不能合并？某项设计究竟是有意为之，还是生成过程中的偶然结果？

传统技术债务至少可能有人知道“这里做了妥协”。认知债务更隐蔽的地方在于，团队甚至不知道自己遗漏了什么。

AI 可以帮助解释代码“做了什么”。但维护中更重要的问题常常是：

为什么必须这样做，而不是采用另一个看起来更简单的方案？

这个“为什么”可能来自需求讨论、历史事故、压测结果、组织分工和失败尝试。仅从当前代码的表面结构中，无法保证完整还原这些背景；有依据的设计记录和可追溯的决策过程仍然重要。

如果组织不断合并没有人真正理解、也缺少可验证设计理由的代码，最终可能得到一个功能丰富、测试齐全，却没有人能够从整体上负责的系统。

生产事故仍然需要一个能够判断、决策和承担后果的责任主体。自动生成代码，不会自动消除组织的责任。

不要切断工程师的成长链条

工程领域最宝贵的资源并不只是代码库，也包括能够理解和演进代码库的人。

初级工程师处理简单需求、修复小型 Bug、编写测试，不只是完成低价值劳动。这些工作也可以是他们学习系统的入口。

他们通过一次次小改动，学习如何阅读陌生代码、澄清需求、判断修改范围、识别异常路径、通过日志定位故障、在代码审查中解释选择，以及为上线结果承担责任。

如果简单任务全部被自动化，却没有替代性的训练机制，新人可能直接面对一个奇怪局面：他们还没有经历过从需求到设计、从实现到故障的完整过程，却已经被要求接管和审查 AI 一次生成的大规模修改。

资深工程师也可能从设计者逐渐变成输出审核员，把大量精力用于检查源源不断的补丁，而不是建立更好的抽象。

短期内，团队也许完成了更多需求；长期看，却可能消耗培养下一代高级工程师所需的训练环境。这种成本，很难直接体现在交付速度中。

这是一种需要主动管理的风险，而不是自动化必然造成的结果。 AI 同样可以成为解释器、调试伙伴和教学助手。关键在于，团队是否把学习设计进工作流，而不是默认生成答案就等于掌握能力。

真正的错位，是指标与目标的错位

问题不在于机器能够生成代码。重复性实现、测试补充、接口适配、迁移脚本、文档整理和静态检查，都可以成为机器辅助的对象；适合多高的自动化程度，仍取决于风险和验证条件。

真正的问题是：我们使用什么指标指挥它们？

如果组织主要奖励代码行数、Pull Request 数量、Issue 关闭数量、首次生成速度和自动合并比例，就可能把优化这些指标，当成工程本身的成功。

真实的工程目标更接近：系统是否可靠，变更是否容易回滚，安全风险是否受控，运行成本是否合理，需求变化时能否快速而安全地调整，以及组织是否仍有能力处理未知问题。

DORA 的 2025 年报告将 AI 的主要作用概括为一种放大器：它会放大组织已有的优势和弱点；收益不只取决于工具，也取决于底层组织体系。^[4]

由此可以得到一个工程层面的推论：架构清晰、测试可靠、责任明确的团队，可以利用 AI 加速有价值的工作；需求混乱、缺少监控、没有所有权的团队，则可能更快地扩大原有问题。

代码产量是手段。系统的可靠性、可演进性与团队的判断力，才更接近目标。

如何让 AI 重新与软件工程对齐

AI 工程体系不应该只询问“模型是否完成了任务”，还应该询问“这次修改是否增加了系统和团队的长期能力”。

第一，把评估扩展到整个变更生命周期。 一个优秀的工程 Agent，不仅要生成实现，还应帮助发现需求歧义、列出关键假设、识别系统不变量、分析故障模型、评估影响范围，并提出迁移、灰度、回滚和监控方案。不是每次小改动都需要繁重流程，但流程不能漏掉与风险相匹配的验证。

第二，不要让生成与验证完全同源。 同一个模型理解需求、编写实现、生成测试并审查自己的修改时，可能形成很强的内部一致性，却共同忽略同一个错误假设。换一个模型也不自动等于验证独立；更关键的是引入不同来源的证据。

独立规范、既有测试、属性测试、静态分析、安全检查、生产观测，以及具备上下文的人类审查，可以共同构成验证体系。测试本身也需要审查，不能只统计数量。

第三，让自治程度与风险相匹配。 修改文案或低风险内部工具，可以采用相对轻量的审查；涉及资金、权限、隐私、数据迁移和核心一致性的变更，应有明确的责任人、充分验证和可执行的恢复路径。写得短，不代表风险低。

第四，把理解作为交付物。 一次修改应留下必要的设计理由、关键假设、验证结果和未解决问题，而不仅是一份代码差异。与其要求冗长文档，不如要求下一位维护者能找到可信的“为什么”。

第五，保留人的学习过程。 AI 可以减少机械劳动，但团队仍需有意识地安排代码阅读、调试、设计讨论、上线和事故复盘。让新人解释 AI 的方案、寻找反例、比较替代设计，而不是只点击接受。

这些做法不是为了放慢 AI，而是为了让它加速真正有价值的工程工作，而非仅仅加速代码流入仓库。

结语：稀缺的，从来不只是代码

人工智能在软件工程中值得警惕的错位，并不只是它会生成错误代码。明显的错误有机会通过测试、审查和告警被发现；某些错误也可能长期潜伏，不能因此轻视。

更隐蔽的风险是：组织不断接收看起来正确、能够运行、通过了现有测试的代码，却没有同步积累对系统的理解。久而久之，大家可能忘记软件工程最初试图实现的是什么。

软件工程的成果，不只是代码。它还是一个能够持续提供价值的系统，以及一群能够理解、改变并为这个系统负责的人。

衡量 AI 工程价值的标准，不应只是“单位时间内完成了多少次修改”，还应是：

每一次修改之后，我们是否拥有了一个更可靠的系统，以及对这个系统更多而不是更少的理解？

只有当 AI 增加的不只是代码产量，还包括组织的理解、判断和长期行动能力时，它才真正与软件工程的目标对齐。

AI 正在让“写代码”越来越便宜，但软件工程真正稀缺的，从来不是代码，而是对系统的理解、验证与责任。