QCon London 演讲：AI 时代代码正变为只写且可丢弃

Phillip Mortimer 在 QCon London 的演讲“软件工程中的复杂性与创造力”上给出了一个相当激进的判断：人工智能使所有代码都趋向于“只写且不可读的”。这不是对某类项目的描述，而是一个覆盖全部代码的普遍性表述。

他借用了 Eric S Raymond 的定义来锚定“只写代码”的含义：那些深奥、复杂或结构混乱、除作者外几乎无人能修改或理解、甚至作者自己也未必完全理解的代码。按这个定义，只写代码的问题不只是“别人看不懂”，而是连作者本人都可能失去对代码的完整把握。

Mortimer 还指出，某些语言从设计上就是“只写的”，以牺牲可读性换取极大的表达力与性能，他举的例子是 APL 与正则表达式。这类语言体现的是极致密度带来的复杂性——密度本身不是缺陷，但它把理解成本推高到了需要外部手段来补偿的程度。

需要区分的是：这是 Mortimer 的判断性表述，来源并未提供支持“所有代码都趋向只写”这一普遍性结论的实证数据。把它当作一个值得认真对待的工程假设，比当作已被验证的行业事实更稳妥。

面对只写代码，Mortimer 给出的第一条原则是让测试定义行为。当写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例，测试因此成为代码的文档。他描述的理解路径是查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。

第二条原则是代码可丢弃。Mortimer 认为只写代码难以调试，通常从头重写比修改已有代码更容易，因此建议保留测试、丢弃代码、重新实现。

这两条原则在逻辑上是咬合的：如果测试承载了行为定义，那么代码就退化为一种可替换的实现载体；既然行为由测试锁定，重写就不必以理解旧代码为前提。换句话说，测试从“验证工具”升格为“规格与文档”，而代码从“资产”降格为“耗材”。

这里有一个值得注意的推论（推断）：这套方法把可维护性的重心从代码可读性转移到了测试完备性上。来源没有讨论测试本身是否也会变得难以维护，也没有给出测试覆盖率或重写频率的任何数字。

Mortimer 对人工审查的否定相当直接：由于数量庞大，让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。

他的替代方案是编写非常详细的测试并自动化代码审查。在演讲后的 InfoQ 采访中，他把自动化代码审查描述为相对简单直接的事：可以将编码智能体 harness 作为 CI action 调用，并赋予其资深开发者审查代码时所关注的技能；代码审查智能体可以发布评论、请求修改，甚至批准 PR。

他还提到一个反直觉的观察：让模型审查自身输出能提供非常有价值的审查意见，在代码部署前找到缺陷。他的解释是，不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查，并认为这种对抗性审查过程正在更广泛的智能体系统中成为通用技术，而不仅仅用于代码审查。

这些关于效果的说法来自 Mortimer 的个人经验与观察，属于来源转述的主张，来源未说明样本量、缺陷类型或误报率。采访中提到的“相对简单直接”是就实现方式而言，并不等于效果已被量化验证。

Mortimer 把自动化的边界从“审查”推到了“修复”。他提出的做法是让 AI 编码智能体监听可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。

他还描述了另一类常驻代码库的智能体：“去污（De-slopify）”类智能体可以定期运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。

此外，代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。

把这三者放在一起看，Mortimer 构想的是一条从告警到 PR、从 PR 到代码库清理的自动化闭环。但来源未说明自我修复智能体在生产环境中的实际落地情况与风险控制，也未给出“去污”智能体的任何验证结果。自动发起修复 PR 与自动批准 PR 之间的权限边界，来源同样没有交代。

Mortimer 主张将意图与实现解耦。他的论据是 AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性——如果意图用自然语言表达，实现语言的选择就不再是绑定开发者的因素。

由此他重新定义了开发者的角色：软件开发者如今的角色是创造力。他对创造力的描述是迭代式的，是在较长时间内逐步改进的过程；任何人都可以进行创造，关键是要开始动手。

在组织层面，他认为有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰，并称企业界广受推崇的头脑风暴实际上比个人独立思考产生的好点子更少。他提到自己倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段。

他还强调约束对创造性工作的重要性：约束消除了空白画布的无限可能性，迫使人在有界空间内探索。他以其在文档智能初创公司 Accelex 早期的经历为例——受制于时间和资源，这迫使他为从表格中读取数据的问题寻找创新性的解决方案。

这些关于创造力条件的主张属于 Mortimer 的个人观点与经验，来源未提供可验证的行业数据，Accelex 案例的具体时间、规模与结果也未说明。

Mortimer 的总结是：AI 已经解决了实现问题，剩下的就是创造力，我们都是全栈开发者，你所需要的只是一个有创意的想法，现在是用软件构建的最好时代。

把这套主张连起来看，它的结构是清晰的：AI 让代码不可读（前提）→ 测试定义行为、代码可丢弃（方法）→ 人工审查不可行、自动化审查与自我修复接管（组织安排）→ 开发者专注创造力（角色重定义）。每一环都指向下一环，内部逻辑自洽。

但自洽不等于已被验证。来源明确列出若干未决之处：AI 生成代码在真实项目中的占比、人工审查瓶颈的具体阈值、自我修复智能体的成功率，均无任何数字；这些做法在何种规模、何种技术栈或何种组织条件下适用，来源未说明；也没有失败案例或反例。

因此更准确的读法是：这是一位实践者在会议上提出的工程主张与方向判断，而不是一份经过第三方验证的结论。它对“AI 时代如何组织软件生产”提出了一个值得检验的假设，但检验本身尚未发生。