在 AI 时代，代码质量仍然重要吗？这取决于一件事
问任何一位资深软件工程师一个问题，你几乎肯定会得到他们最喜欢的两个字答案：「看情况。」
在 AI 编码工具和「vibe coding」的时代，关于代码质量是否仍然重要的辩论在社交媒体上达到了白热化。在 AI Engineer 频道的一次演讲中，Max Kanat-Alexander（Capital One）超越了「是或否」的二元争论，提供了一个具体框架，说明何时工程严谨性至关重要——何时你可以把它扔出窗外。
基础：代码为什么存在
在决定代码质量是否重要之前，我们必须确立软件工程实践真正试图实现什么。根据 Kanat-Alexander 的说法，你想用一段软件完成的任何事情——无论是对齐模型、扩展系统还是推动采用——都归结为两个因素：
- 理解系统。
- 基于该理解执行。
调试器、可观测性工具、评估和测试不是凭空存在的；它们的存在完全是为了提高我们对系统的理解以及我们据此行动的能力。对软件工程师来说，这归结为两个关键问题：
- 系统的实际、具体行为是什么？（不只是文档声称它做什么。）
- 我如何正确且安全地修改该行为？
虽然一个简单的「Hello World」程序很容易完整掌握，但现实世界系统——比如庞大的开源 Chromium 代码库——本质上有无限可能的交互。没有人能把 Chromium 的整个行为装进脑子里。相反，我们依赖理解特定组件，比如 URL 解析器。
这就是代码存在的原因：为了结构。过去，工程师谈论「可读性」和「可测试性」等概念，听起来像纯粹的人类关切。底层始终最重要的是可识别、可理解的结构。
修改风险的恶性循环
结构在你需要修改系统时最重要。每次修改都带有两种风险：
- 引入即时问题： 这不仅是一个 bug——它可能是错过的截止日期、预算超支，或因理解系统困难而导致的用户行为错位。
- 使未来更改更难： 通过降低结构质量，你使系统下次更难理解。
风险 #2 直接反馈到风险 #1，形成一个复合的、非线性的循环。随着时间推移，巨型代码库可以达到一种状态，其中每一次更改都会触发组织摩擦、时间线延迟或生产事故。
大分野：持久软件 vs 一次性软件
虽然人们在争论未来的 AI 模型最终是否会有无限能力解开巨大复杂性，但 AI 现在已经在做另一件事：让一次性软件变得普遍 10 万倍。
历史上，工程师把大部分时间花在构建和维护持久软件上——那些存活多年、服务成千上万或数百万用户、如果失败会带来灾难性商业后果的系统。持久软件不会消失；事实上，AI 工具可能会导致更多持久软件被构建。
然而，AI 代理也允许我们快速启动这样的软件：
- 失败的后果最小或不存在。
- 很少人（且没有其他生产系统）依赖它。
- 替换成本接近零（可以在几小时内重建）。
- 维护成本基本上为零。
不喜欢你的操作系统计算器？让代理构建一个定制的。计划孩子的生日派对？启动一个一次性派对规划应用，周一就扔掉。在一次性软件的世界里，代码质量完全不重要，因为未来修改的复合风险根本不存在。
| 评估因素 | 一次性软件 | 持久软件 |
|---|---|---|
| 失败后果 | 最小到无 | 高 / 业务关键 |
| 依赖 | 孤立；由一人或少数人使用 | 被成千上万/数百万或其他系统依赖 |
| 替换成本 | 接近零（可在几小时/几天内替换） | 极高 |
| 维护成本 | 不重要或几乎免费 | 巨大的持续投资 |
| 所需工程严谨性 | 无 | 最大 |
现代工程的两个新学科
因为一次性和持久性存在于一个光谱上，现代软件团队有两个战略杠杆可以拉动。
1. 为一次性进行工程设计
与其对一切应用沉重流程，组织可以架构环境，有意使软件可以安全扔掉：
- 隔离环境： 创建只访问单个用户数据的沙箱，零访问客户数据或 PII。
- 强制独立： 阻止来自其他生产系统的入站 API 调用，这样没有东西能意外依赖一次性工具。
- 持久冗余： 保留一个可靠但「笨重」的遗留系统作为备份，同时让员工为自己的工作流「vibe code」快速定制前端。如果他们的定制前端坏了，他们就回退到持久系统。
- 严格范围限制： 让工具高度聚焦于单个用户或单个事件。
2. 降低严谨性的成本
有经验的工程师知道，「临时」原型有变成永久生产系统的习惯。如果你误判了一个项目在光谱上的位置——或后来改变了主意——你希望从一次性到持久的过渡尽可能无痛。你通过使工程严谨性变得便宜且毫不费力来实现这一点：
- 无情的标准化： 标准化语言、框架和 RPC 协议不是官僚主义；它是消除可能性。更少的框架意味着更少的 linter、安全补丁和你必须维护的定制代理工具。
- 工作流内工具： 构建在后台自动运行的质量检查。当工具快速、可靠、假阳性低、且不需要开发者任何有意识努力时，它感觉是免费的——意味着你甚至可以将其应用于一次性项目。
- 无摩擦测试基础设施： 不要要求每个开发者都是测试专家。投资于使测试从一开始就快速且确定性的基础设施——例如，使用编码代理自动生成并维护服务的内存假版本。
- 从第一天起最大严格性： 从第一天起就把所有 lint 规则和严格性设置调到最大。这消除了无尽的团队辩论，并防止在百万行代码库上追溯启用 linter 的噩梦。
结论
那么，代码质量仍然重要吗？Kanat-Alexander 留给我们三个清晰的答案：
- 对于一次性软件？ 不。
- 对于持久软件？ 是。
- 严谨性必须昂贵吗？ 不。