Theo 谈一次性 AI 代码与重要软件的验证

工程师应该阅读多少 AI 生成的代码？我的激进回答是，很多人阅读了生成代码中比例过高的一部分。更重要的是，他们可能还没有生成足够多用于实验和验证的代码。这并不意味着关键生产代码可以不经过审阅。

可以把软件放在一条重要性光谱上：一端是只有一个访问者的小型个人项目，另一端是心脏起搏器固件。故障造成的后果可能天差地别。我认为网上争论常常出错，是因为人们假定自己在光谱上的位置适用于所有人。

为了讨论，假设你发布的每一行代码都极其重要，错误可能危及生命。在这种情况下，我同意每一行上线代码都需要仔细的人工审阅。我的观点针对的是围绕它额外创建的代码，而不是削弱审阅。

代码即使永远不进入产品，也可以有用。你可以编写独立工具、实验或测试，调查一个假设或检查重要行为。如果编写程序变得更便宜，以前不划算的许多调查就成为可能。

我用虚构数字说明过去的工作方式：假设我每天阅读 1,000 行、编写 200 行、合并 100 行。编写代码成本较高，准备进入生产的代码需要审阅。这些数字只是示例，不是测量结果，也不是推荐的生产力目标。

现在假设阅读量相近，但生成了 2,000 行、合并了 500 行。生成量和阅读量之间的差距看起来吓人，直到你追问其余代码的用途：其中很多可能只用于测试想法，之后就丢弃，并不会提交审阅或合并。

过去，为一个一次性问题写大量代码很难证明值得。我可能需要给产品添加分析功能，再写 SQL 回答用户问题，而这需要时间。生成成本下降后，为具体问题临时编写程序变得更可行。

以金融 ERP 系统为例，错误可能造成重大损失。我的建议不是把未经审阅的输出合并进去，而是保留与系统风险相匹配的审查，并考虑围绕重要代码生成额外检查、调试器和实验。

我用夸张比例说明一个观点：一行生产代码周围可能有数百或数千行验证代码。验证工作可以远大于被检查的代码。但这些数字只是修辞，不是安全标准；行数本身无法证明测试质量或覆盖范围。

如果现有测试框架本身很重要，我建议在另一层开展实验：用工具检查运行结果、日志或假设，而不替换已验证的流程。生成的检查器也可能出错，因此其结果在支持重要决定之前，需要解释和独立验证。

一位观众说，自己把大部分生成代码用于测试框架和防护措施，再把结果提供给智能体。我说的就是这类用法。无论生产代码和测试是否由人手写或审阅，额外的实验层都可能帮助探索过去成本过高的可能性。

假设一名从事安全关键系统的工程师过去一天编写并验证 100 行代码、阅读 200 行。我不是要求这位工程师停止检查重要工作。这些数字是假设：重点是在保留既定验证流程的同时，考虑额外的调查方式。

在我的例子里，这位工程师可能编写并验证 80 行、阅读 400 行，再生成 800 行保留在产品之外的探索代码。一次性代码可以探查假设并测试那 80 行。它是否有用取决于检查是否可靠、是否适当隔离，而不是生成数量。

我曾写出大量 JavaScript，在 Windows 电脑上整理大约一百个文件。手工编写这么多代码很难说划算。我的意思是，程序可以是为一个任务使用的一次性工具，而不必成为需要长期维护的功能。

生成代码仍可能很差，重要系统中的未经验证代码也可能造成伤害。在这一点上，我同意批评者。我认为更便宜的生成提供了另一种调查和验证方式，但它不会自动让输出可信，也不会消除运行风险。

我自己的例子包括定制 lint 规则、一次性调试器、React 代码的插桩和负载测试实验。这些工具让我能提出过去可能不会花时间实现的问题。它们的结果是需要检查的证据，并不是系统正确的保证。

我区分了降低关键代码的成本，与在其周围创建更多低成本代码。我主张的是后者。阅读代码需要时间和认真对待；目标不是加快不安全修改进入生产，而是寻找更多改善重要代码的方法。

我画了一个重要性漏斗。顶部是一次性实验；往下依次是希望能正常工作的东西、业务关键系统，最后是故障可能危及生命的软件。这些只是示意分类，同一位工程师一天的工作也可能跨越多个层级。

过去，编写一次性代码可能和编写需要精心维护的代码花费同样多的精力。我认为这种成本抑制了探索。借助生成，从事关键固件工作的工程师可以继续严格保护核心边界，同时在边界之外开展更多实验。

在我的项目中，不同部分值得投入不同程度的注意力。我喜欢一种建议：让智能体逐文件总结大型 diff，再调查其中异常之处。摘要能帮助浏览变更，但也可能遗漏或误述细节；需要多少直接审阅，取决于后果和团队流程。

在 Lakebed 中，我阅读所有函数签名和 API 定义，因为它们的质量会影响未来维护。我还让多个智能体生成小应用，看看它们能否使用新 API。如果实验暴露出困惑，我就可以在发布前改进接口。

安全关键工作的现有测试、框架和封装也可能需要仔细审阅。在此基础上，智能体可以尝试几个一次性假设、编写额外测试，或做一个实验性移植来比较实现。即使实验永远不会合并，也可能回答有用的问题。

我理解人们的抵触，因为最响亮的 AI 编程案例有时是不经充分检查就向用户发布粗糙输出。我也不喜欢这样。但糟糕的例子并不会消除一次性实验支持负责任工程流程的潜在价值。

我也会在把代码交给团队前使用 AI 审阅，常常让多个智能体检查。这能提供有用反馈，但模型审阅可能漏掉缺陷，也可能共同犯同样的错误；它是独立验证的补充，而不是保证。

最后，我希望大家更有创造性地思考代码能做什么。把一些程序当作回答一个问题或检验一个假设的一次性工具，同时对重要的代码和证据保持适当审阅。目标是更好的验证，而不是为发布不安全输出找借口。