“越修越糟”：如何规避 AI 生成代码的隐藏风险
如今构建应用已经不再需要精通高级编程语言。AI 打破了编程的门槛，让写代码变得像用大白话描述你想要什么一样简单。
至少表面上看起来是这样。
但编程不只是写语法，还涉及系统架构、理解用户实际会如何使用平台，以及确保采取正确的措施来限制安全漏洞。
我与 Quint 的 CEO Gabriela Moreira 聊了聊：用 AI 工具写代码的人，如何更好地理解相关风险，并尽早建立检查和流程，避免产生难以维护的代码和灾难性 bug。
受访者：
Gabriela Moreira
采访者：
采访者：
Owain Williams
没有人类监督，AI 写出的代码能直接用于生产环境吗？如果不能，AI 生成的 bug 与人为错误有何不同？
监督肯定是必需的，因为 AI 的存在是为了服务人类，所以人类需要告诉 AI 做什么，并评估它的产出。
那么，哪种评估方式最合适？两个极端的例子是：逐行阅读它的代码，或者直接上线然后在生产环境中监控问题。其实这两种方式早就被用来审查可能含有人为错误的代码了。
AI 带来的主要差异在于：可能出错的代码数量激增，而且人类对生成内容的各个环节存在认知上的脱节。在这样的规模和认知脱节之下，代码审查和监控都变得更加困难。
哪些核心业务系统最容易受 AI 编码缺陷的影响？
那些难以测试的系统，比如并发和分布式系统，或者任何非确定性程度很高、需要考虑的路径太多的系统。
AI 本质上是一种生成工具，其效果完全取决于我们判断生成结果是否正确的能力。如果我拥有完善的测试或可靠的验证机制，采用 AI 方案的顾虑就会小得多。反之，如果系统难以测试或验证，盲点会非常多，缺陷容易潜藏其中。
在未进行形式化验证的情况下部署 AI 生成的代码，存在哪些隐藏的运行和安全隐患？
世上没有魔法般的完美方案，结合多种策略才是明智之举。
或许在 2026 年，评估风险的最佳视角是考量这种不对称性：防御方必须保护代码的每个部分，而攻击方只需发现一个漏洞就能造成巨大破坏。
AI 公司在将类似 Mythos 的模型仅提供给参与安全自保计划的企业时，显然已经考虑到了这种不对称性，以防止模型落入潜在攻击者手中。
形式化验证或许是我们已知的对抗这种不对称性的最强工具，但该领域仍面临诸多挑战，使得对全部代码表面进行验证变得不切实际，未验证的组件中仍可能存在漏洞。世上没有魔法般的完美方案，结合多种策略才是明智之举。
为什么在流程早期捕获设计层面的 bug 如此重要？
我非常担心那种主要依赖 Markdown 文件、且无法编译或执行的设计过程。
在 AI 编写代码之前，对这个问题的回答截然不同：因为如果在开发数月后才发现问题，重写代码不仅成本极高且容易出错。我认为这个论点如今已不再有力。
因此，新的答案变得很简单：在尚能进行推理的设计范围内，你发现这类问题的概率要远大于在 AI 撰写数千行代码、而 bug 潜藏其中某处之后才去发现它。
在手动编写代码时，你可能在输入过程中意识到“等等，我们没考虑过这种场景！”但当 AI 为你编写代码时，这种及时察觉的可能性大大降低，因此更加谨慎的设计变得至关重要。
开发者习惯在编译和执行代码的不同版本时，推理可能出现的各种情况和 Bug。因此，对于那些主要依靠 Markdown 文件进行、且这些文件既无法编译执行也无法以阅读之外方式交互的设计过程，我深感担忧。
开发团队可以设置哪些简单的检查、工具和安全网，以在 AI 代码进入生产环境前对其进行验证？
首先，测试是必需的！但这里的测试必须是真正有助于建立信任的，而非那些由 AI 生成、做出任意断言且需要不断更新的测试。
我倾向于从测试所验证的行为类型以及它能防止哪类回归的角度来思考测试。如果测试质量的控制变得困难，形式化模型可以帮助解决这一问题，它既可以生成测试场景，也可以验证现有测试是否强制约束了有趣的行为。
此外，变异测试（mutation testing）在衡量测试质量方面非常有用，它通过统计测试能捕获多少种不同的回归来评估测试效果。
您建议保持多高程度的人工监督，以在开发速度、代码质量和可靠性之间取得平衡？
这很大程度上取决于具体上下文和风险。我能给出的最佳建议是：采取能让你以足够的信心发布产品、并让你敢于修改软件而不担心破坏现有功能的方法。
最坏的情况是被黑客攻击或泄露他人数据。次坏的情况是软件出现了许多问题，但你尝试修复任何一项时，反而导致问题变得更加严重，从而使系统陷入僵局。
我认为，AI 生成的代码很容易陷入这种境地。有趣的是，我认为摆脱这种局面的方法与我们处理难以维护的遗留代码（legacy code）的过程非常相似：首先添加足够的测试，以确信你的监督是充分的，然后再进行修改。