AI 辅助工程中的"信任但要验证"模式

为何验证而非生成将成为下一个开发瓶颈

内容提要： 盲目信任 AI 生成的代码存在安全隐患。 对 AI 生成的代码必须进行人工审查，并建立明确的团队规范。 请注意，验证（而非生成）已成为新的开发瓶颈，最终责任始终由人类工程师承担。

AI 编程助手就像一位高速成长的新手开发者—— 速度惊人 ，语法和风格通常正确，但容易犯错 ，只有经验丰富的眼睛或严格测试才能发现。因此在软件工程中采用 AI 需要秉持"信任但要验证"的严谨态度，下文我们将详细解析。

“信任但要验证”：一种与 AI 协作编程的务实之道

资深软件工程师对让 AI 代写代码持合理怀疑态度是情有可原的。虽然 Cursor、Copilot 和 Cline 等工具能在数秒内生成可运行的代码，但经验丰富的开发者明白， 编写代码只是成功的一半——另一半在于验证代码是否真正实现了预期功能。这一原则可概括为 "信任但要验证"。在 AI 辅助编程的语境下，这意味着你可以信任 AI 结对编程伙伴协助产出代码，但在依赖其输出前必须严格审查和测试。本文将探讨为何 "信任但要验证" 是 AI 辅助工程的关键模式，以及如何实践应用。我们将结合最新研究和行业洞见，为最持怀疑态度的开发者提供实用指导。

AI 代码生成的承诺与风险

AI 编程工具的优势确实令人印象深刻。现代代码生成模型产出代码的速度远超人类手动输入 ，生成的代码通常语法正确且（多数情况下）默认遵循最佳实践规范 。这意味着常规样板代码或成熟模式能在数秒内完成。通过 AI 处理繁琐工作，理论上开发者可以专注于更高层次的设计和复杂问题解决。

然而，速度与流畅性伴随着一个警示： 你只能得到你所要求的 。如果提示存在歧义或 AI 训练数据存在空白，生成的代码可能表面正确实则存在深层缺陷。AI 并不真正理解你特定项目的架构、不变量或安全模型 ——它只是匹配最可能的代码模式，其中可能包含过时或不安全的实践。关键在于，AI 缺乏人类开发者对边界条件的直觉，以及察觉微妙 bug 的"嗅觉"。换言之，AI 可能产生零日漏洞 ——这些漏洞如此隐蔽，开发者将面临"零天"修复时间，因为他们根本未意识到漏洞已被引入。

除安全性外，其他风险还包括质量和性能方面的反模式 （例如在大型数据集上无意中编写了 O(n²)循环）或违反架构原则 。AI 的关注点在于让代码运行起来，而非考虑其在您特定上下文中的长期可维护性。它可能会引入与您技术栈冲突的依赖项，或生成一种"技术上"解决了问题但实现方式脆弱的方案。 可维护性也可能受损 ——AI 生成的代码读起来会感觉完全出自他人之手（事实正是如此！），导致日后难以理解。简而言之，AI 就像一个高产但对项目未来毫无责任的初级程序员 ：它不会留下来修复错误或解释设计决策。您需要自行验证其产出是否符合团队标准。

"信任但要验证"的思维模式

鉴于这些潜在缺陷，资深工程师应如何对待 AI 辅助？"信任但要验证" 体现了所需保持的平衡心态。实践中，这意味着利用 AI 的速度和生成能力，但在任务完成前始终让人工判断和额外检查来把关其输出 。这是有意识地决定将 AI 建议视为有用的草稿——而非最终解决方案 。

这一理念与其他领域的做法不谋而合。以网络安全为例，"信任但要验证"已发展为零信任架构(ZTA)——该模式下任何组件即使通过初始认证也不会获得默认信任。正如采用零信任的网络会持续验证和监控设备（假设任何组件都可能被入侵），开发者使用 AI 时也应持续质疑并测试 AI 生成的代码 。本质上，"盲目信任就是漏洞"。你可以信任 AI 模型快速生成代码草稿，但在验证之前不能假定其正确性或安全性 。现代安全漏洞事件告诉我们，初始信任必须通过持续验证和反复确认来维系——这一经验同样适用于与 AI 编程伙伴的合作。

打个比方很有帮助：AI 编程助手是副驾驶，而非自动驾驶 。正如微软 Copilot 官方文档强调的，“这些工具是作为助手存在…而非替代你的工作”。人类飞行员（开发者）必须始终保持对控制权的警觉。同样地，GitHub CEO 也强调他们特意将其命名为“Copilot”—— 它并非设计为单飞 。处于工作流中的人类仍需对最终结果负责。

同行观点： 在采用 AI 的软件团队中，人们日益认识到 AI 输出代码需要接受与人写代码同等（或更高）标准的严格审查 。例如，The New Stack 建议企业"尽可能早地在软件开发生命周期中设置适当防护措施，使开发人员能够检查 AI 生成代码的质量"。这些防护措施包括从开发伊始就整合代码审查、测试和策略检查等环节。不应将 AI 代码视为绕过流程的捷径，而应像对待其他代码贡献一样：让其通过标准的质量保障流程（鉴于 AI 的已知特性，甚至需要加强该流程）。通过左移验证环节 ——尽早且频繁地集成验证——团队可以避免在开发周期后期遭遇棘手问题。

本质上，“信任但要验证”的思维模式意味着将 AI 视为生产力助推器 ，但绝不对其输出结果掉以轻心。资深工程师可能已经在潜意识里这样做了：当新开发人员提交代码时，你会审查；当 Stack Overflow 提供代码片段时，你会测试。对待 AI 也应如此。如果说有什么区别的话， 经验丰富工程师的怀疑本能在这里反而成为优势 ——这种健康的怀疑会推动验证过程，从而发现 AI 的错误。

为何验证环节不容妥协

AI 模型基于海量代码和文本训练而成，但它们远非完美无缺。其输出结果可能看似完美——格式规范的代码配上合理的逻辑——实则暗藏细微错误。 这些输出往往给人以正确无误的错觉，正因如此才更需要保持怀疑态度。

以下是使用 AI 生成代码时常见的故障模式和风险：

• 虚构的 API 或软件包： 大型语言模型有时会编造根本不存在的函数、类甚至整个代码库。例如，AI 可能会建议使用一个并不存在的 fast_sort()方法，或导入虚构的软件包。这些 "幻觉产物" 在运行或编译代码时会被立即发现——如果找不到对应方法或模块，系统就会报错。从这个角度看，明显的幻觉产物是 AI 错误中危害最小的一类。真正的危险往往更加隐蔽。

• 微妙的逻辑错误： 更隐蔽的是那些确实能够编译运行，但会产生错误行为的错误。AI 可能会让数组索引差一位、使用次优算法或遗漏边界情况。这些问题不会立即触发错误，甚至可能通过基础测试。换言之， 看似正确的代码仍可能存在错误 ，只有通过全面测试或分析才能发现。

• 安全性与可靠性问题：AI 生成的代码可能无意间引入安全漏洞或性能问题。它可能遗漏输入验证、使用已弃用或不安全的函数，或产生无法稳健处理故障的代码。微软研究人员在考察 22 种编码辅助工具时发现，这些工具不仅存在功能正确性问题， 更显示出在可靠性、安全性和可维护性方面 "普遍存在缺陷"，这揭示了当前训练机制中存在根本性盲区。生成的代码可能在理想路径下运行正常，但在真实场景中容易失效。

• 过时或错误的假设：AI 的知识存在截止日期，它可能推荐几年前适用但现已过时的解决方案。它可能使用已变更的库 API，或不再推荐的做法。AI 知识质量的改进通常会考虑库/模式的流行度，这意味着不太主流的解决方案可能持续受到截止日期问题影响。工具可能尝试通过 RAG 或在上下文窗口中注入相关文档来规避截止问题，但这些方法仍不完美。如果未经核实就盲目信任，你可能将过时技术植入代码库。

• 许可与供应链风险： 对待 AI 建议应如对待第三方代码——本质上它们就是如此。你不会未经检查许可证或来源就直接将网上随意找到的代码复制粘贴到生产环境；同理，AI 生成的代码可能无意中复现了他人的版权实现。还存在新兴的 "包幻觉" 威胁。若开发者盲目尝试安装此类包，恶意攻击者可能预判此行为并发布同名包含恶意软件的包。这种所谓的 "污水注册" 攻击利用了开发者对 AI 建议的不设防信任。核心原则是：使用前务必验证依赖项和代码引用是否真实可靠。

鉴于这些风险， 盲目接受 AI 输出无异于自找麻烦—— 如果你只是在构建个人软件或准备上线前会复查的 MVP 产品，问题或许不大。否则务必谨慎行事。每个资深工程师都经历过"那一行代码"导致系统崩溃，或"那个未检查的错误"引发安全漏洞的故事。AI 能快速生成大量代码，但速度不能成为跳过验证的借口 。事实上，更高的产出速度使得严格审查变得更加重要——否则你只是在加速制造漏洞和技术债务。如果我们不验证 AI 输出，就可能直接加速坠入维护噩梦。

因此问题就变成了：如何在保持生产力提升的同时，将验证环节融入 AI 辅助的工作流程？要回答这个问题，我们需要理解为何验证会成为瓶颈，并探索提高验证效率的策略。

生成容易，验证困难

非开发人员常以为编程主要是敲代码。讽刺的是，资深工程师都明白编程的本质在于阅读、思考和调试 ——实际敲键盘写代码只占工作的一小部分。AI 工具极大强化了代码输出环节，眨眼间就能生成数十行代码。但这并不会自动让开发效率提升 10 倍或 100 倍，因为瓶颈转移到了理解和验证这些输出上。这正是阿姆达尔定律的经典案例：如果流程的另一环节（验证）仍是缓慢的主导因素，那么单纯加速代码生成环节收效甚微。

AI 可以为你生成大量新代码，但你仍需停下来确保这些代码确实有效且合乎逻辑 。如果代码生成速度提升 100 倍，但代码审查和测试速度保持不变，你的整体效率提升就会受限——现在工作流程的瓶颈变成了验证正确性的速度。

要形象化理解，可以将创作过程视为两种交织的模式： 生成与评估 。这种二元性在许多创意领域都很常见。画家挥毫落笔后，会退后审视效果；作家草拟段落之后，会修改以求清晰。AI 编程也不例外——只不过如今 AI 承担了大部分生成工作，而人类负责评估 。问题在于， 代码评估对认知能力要求极高 。它不像发现图像中的明显缺陷或快速浏览视频那样直观。代码可能具有复杂的逻辑性，微妙的错误可能隐藏在完全正常的语法背后。验证代码通常意味着在脑海中模拟其执行过程、编写测试用例或阅读文档——这些都需要高度专注和专业能力。

事实上，验证正确性有时可能比亲自编写代码更耗时 ，特别是当 AI 生成的代码量很大时。你需要通读可能陌生的代码，理解其功能，并对照需求进行检查。如果出现问题，还必须诊断错误是出在提示词、AI 逻辑还是上下文假设中。这种努力就是让代码"自动生成"所付出的代价。

这并不意味着 AI 助手没有用处——而是意味着我们需要明智地使用它们， 同时意识到验证已成为新的劳动密集型环节 。我们的目标应该是利用 AI 擅长的领域（快速生成、样板文件、重复模式），同时将验证成本控制在可管理范围内。下一节我们将具体讨论实现这一目标的实用方法。

将验证融入您的工作流程

在开发工作流程中采用人工智能需要进行一些实际调整。团队究竟该如何 "验证"AI 生成的代码 ？事实证明，许多最佳实践都是优秀团队已有做法的延伸——只是在 AI 语境下需要额外强调：

1. 人工代码审查与结对编程

对于即将投入生产的 AI 编写代码，绝不能跳过同行评审。 高级工程师（或除提示 AI 的工程师之外的任何工程师）应当用细齿梳彻底审查 AI 的代码贡献 ，然后才能将代码部署到生产环境。这意味着需要像对待初级开发人员或实习生编写的代码那样对待 AI 的输出——对其正确性、风格和集成问题进行额外审查。事实上， 同行评审本就是最佳实践，因此务必坚持执行 ，而在涉及 AI 时更应加倍重视。

审阅者应当询问：

• 这段代码真的符合要求吗？

• 这段代码是否符合我们的代码库风格？能否更简洁？

• 它是否会引入任何细微的错误或漏洞？

鉴于 AI 有时会引入奇怪的逻辑或过度设计的解决方案，人工判断对于发现自动化检查可能遗漏的危险信号至关重要。

许多团队发现与 AI 结对编程非常有效：开发者将 AI 视为合作伙伴，实时对话并审查其生成的每段代码。例如，你可以要求 AI 编写一个函数，然后立即与 AI 一起逐行检查代码——让它解释每个部分，或添加注释说明其实现思路。

这种方法迫使你和 AI 都必须阐明推理过程 ，从而可能暴露缺陷。你甚至可以用诸如" 这段代码是否符合安全最佳实践？"或" 你能想到哪些可能导致失败的边界情况？"等问题来激活 AI 的自检模式。（虽然 AI 的自我审查并不完美，但有时能发现疏漏，或至少提供对代码功能的另一种描述。）

矛盾的是，引入 AI 可能要求团队具备更多集体专业知识而非更少，才能有效审核 AI 的工作。新手团队可能过度信任 AI；而经验丰富的成员会带着理性的怀疑态度对待它，从而避免灾难性错误。

在团队层面，建议制定针对 AI 生成代码的明确审查规范 。例如，审查者可以要求提供原始提示词或对话记录（以理解上下文），或要求作者标注 AI 生成与人工编写的代码部分。部分机构会在提交信息或拉取请求中采用 "AI 标注"（如通过标签或注释标明 AI 参与），以便审查者重点关注。虽然所有代码都应严格审查，但经验表明当审查者知晓某段代码由机器生成时，往往会表现得格外谨慎 。核心原则是： 将 AI 视为需要人类队友二次核对的贡献者 。

2. 测试、测试、再测试

如果说“代码即真理”，那么测试就是法官。 自动化测试是 AI 编码不可或缺的伙伴。 当前 AI 模型除了模式匹配外，无法保证内在的逻辑正确性，因此全面的测试是我们验证功能行为并捕获回归或逻辑错误的方式。这包括：针对细粒度逻辑的单元测试、确保 AI 代码与系统其他部分协同工作的集成测试，以及面向用户场景的端到端测试。

一个问题是，除非明确提示（即便如此，它可能也只生成简单的测试），AI 通常不会主动编写测试。因此开发者必须坚持要求测试。许多专家建议，即使使用 AI 也要采用测试优先或测试并行的方法 ：要么预先编写测试（以便立即验证 AI 生成的实现），要么在 AI 生成代码时就让它帮忙生成测试。例如，从 AI 获取代码片段后，你可以提示："现在为这个函数生成测试，覆盖边界情况 X、Y、Z。" 即使不完全信任 AI 生成的测试质量，这也是一个可以检查和完善的起点。这有两个目的：(a)通过测试执行验证代码到一定程度，(b)帮助揭示 AI 的假设。如果 AI 未能针对特定边界情况生成测试，可能它没有考虑到这点——这正是你需要关注的提示。

关键在于， 对于 AI 首次生成的测试，不仅要执行，还需人工审核 。AI 可能会生成总能通过的测试（例如断言某些在其实现中必然为真的内容，形成实质上的同义反复测试）。必须确保测试真正验证了有意义且正确的行为，而非仅仅反映代码逻辑。一旦建立起可靠的测试套件，它也将成为未来 AI 贡献的安全网——如果 AI 的修改破坏了某些功能，测试应该能在持续集成中立即发现问题。

自动化测试同样适用于安全性和性能验证环节。在持续集成流程中集成静态分析工具和安全扫描工具 ，可有效识别常见漏洞或不良实践。与所有代码一样，AI 生成的代码也需要通过代码检查器、静态应用安全测试(SAST)工具、依赖项检查器等质量关卡。

事实上，部分 AI 工具现已默认集成扫描功能。例如亚马逊的 CodeWhisperer 不仅能建议代码，还能通过内置扫描标记生成代码中潜在的安全问题（如注入漏洞或弱加密算法）。这种"AI 生成代码后立即进行问题评估"的趋势前景广阔。但即便没有集成的高级工具，您也可以在生成后手动运行静态分析。如果 AI 添加了新库或调用，请通过漏洞扫描器进行检查：是否引入了含有已知 CVE 的依赖项？代码在 linter 或类型检查器中是否触发警告？这些自动化检查构成了额外的"AI 验证器"层，能捕捉人工审查可能遗漏的问题。

最后，对于 AI 生成的关键代码段，考虑采用模糊测试或基于属性的测试 。由于 AI 可能引入异常边界情况行为，模糊测试（输入随机或意外数据观察是否崩溃）能发现确定性思维可能遗漏的问题。如果 AI 编写了复杂解析函数，可用随机输入语料库进行测试，确保其不会崩溃或行为异常。

3. 建立人工智能使用准则与防护机制

在组织层面，明智的做法是制定关于开发人员应如何使用 AI 以及哪些验证步骤是强制性的指导方针。许多公司应考虑建立内部的 AI 代码行为准则 。例如，可以规定所有 AI 生成的代码必须至少经过一次人工审查和一次自动化测试通过后才能进入生产环境 。或者指导开发人员优先将 AI 用于某些安全任务（如生成样板代码或测试用例），而对于其他任务（如安全关键代码）则需经过额外审查才能使用。

建议在开发生命周期早期就实施这些治理措施。这意味着在设计和规划阶段，工程师需要记录计划使用 AI 的场景，并识别出应限制 AI 使用的高风险领域。部分团队会开展包含 AI 风险评估的设计评审 ，例如："我们使用 AI 搭建了这个组件框架——以下是已识别的潜在缺陷及对应的验证计划。" 通过从一开始就强调验证环节，能让团队形成共识：AI 是需要管理和校验的工具，而非绝对可靠的预言机 。

总之，将“验证”融入工作流意味着在 AI 参与的每个开发阶段都增加额外检查 。设计时要考虑验证环节，编码时与 AI 保持紧密反馈循环（而非一次性代码转储），用人类专业知识进行审查，执行全面自动化测试，并随着经验积累持续监控和改进这些防护措施。在代码审查或测试套件中发现 AI 错误，总比它在生产环境中爆发要好。正如那句老话（现在有了现代版诠释）： 防患于未然胜过亡羊补牢。

验证挑战：瓶颈问题

如果这些验证听起来工作量很大——没错，确实如此。这就引出了一个关键问题： 验证 AI 输出是否会抵消最初使用 AI 带来的生产力提升？ 怀疑论者常指出，如果必须细致审查和测试 AI 的所有产出，那还不如自己动手编写。这个观点很合理，也反映了当前 AI 辅助开发的瓶颈 。

技术专家巴拉吉·斯里尼瓦桑最近用简洁的方式阐述了这一点："AI 提示可以规模化，因为提示本质上就是打字。但 AI 验证无法规模化，因为验证 AI 输出涉及的内容远不止打字这么简单。"

换句话说，向 AI 索要代码轻而易举且能无限复制——你只需付出最小努力就能批量生成数十条建议或解决方案。但验证这些方案是否存在细微的正确性问题本质上困难得多 。你往往需要真正阅读并理解代码（可能是几十甚至上百行）、运行它、可能需要调试、考虑边界情况——所有这些都需要时间和专业知识。正如 Srinivasan 所指出的："对于任何微妙的问题，你都需要深度阅读代码或文本——这意味着你必须足够了解该领域才能纠正 AI"。繁重的工作（语义理解、逻辑推理、领域知识）仍然主要落在人类这边。这种不对称性解释了为何 AI 擅长生成你可以直观判断正确性的 UI 或简单脚本，但对于复杂逻辑则棘手得多 ——你不可能仅扫视一段新颖的算法代码就确认其 100%正确；必须通过思维推演或测试来逐步验证。

这引发了一种情况： 验证可能成为开发过程中的限速步骤 。试想 AI 生成代码的速度是人类 10 倍，但人类却要花费同等时间审查修改——最终的速度提升可能微乎其微（如果 AI 引入大量问题甚至可能得不偿失）。正如一位评论者指出的，本质上 “如果我们只提升（写代码）速度，却不减少（审查时间）...整体编码速度仍无法提高”，因为编码中阅读和思考的时间与打字时间相当（甚至更多）。

这是否意味着 AI 辅助编码毫无意义？绝非如此，但它突显了一个现实挑战。 业界正在积极寻求降低验证负担的方法 ，以充分释放 AI 的潜力。缓解这一瓶颈的可能途径包括：

• 优化 AI 指令以最小化错误 ： 提示词工程能帮助预先获得更准确的输出。例如，明确告知 AI 约束条件（"不要使用全局变量"、"遵循我们的 API 规范"、"考虑 X 的安全影响"）有时可以避免错误。此外，像 "为每个步骤提供推理过程" 或 "列出你做出的所有假设" 这类要求可能会主动暴露潜在问题。理想情况下，未来的 AI 将能够 "预见验证工作并减少其工作量"，比如将解决方案分解为更小、可验证的模块。当前的 AI 往往直接输出大段代码；而更智能的助手可能会采用对话方式："第一步，我先编写这个小函数，快速测试。好的，看起来没问题。第二步，我们继续下一部分..." 这种迭代方法能让人类在每个步骤更容易验证，而不是事后被迫梳理 500 行代码。

• AI“自检”与评估模型 ：研究人员正在探索让一个 AI 模型批判或验证另一个模型的输出。其核心思想是将验证过程本身自动化。例如，一个模型生成代码，另一个专门训练为代码审查员的模型则检查代码中的错误或偏离规范的情况。目前已取得一些进展： 研究人员已训练出能根据输入、代码及执行结果预测生成程序正确性的 AI 验证器 。这类技术虽非万全之策，但暗示着 AI 或许也能协助验证工作 ，而不仅限于生成环节。

• 高级工具与形式化方法 ：在安全关键领域，形式化验证工具能够通过数学方法证明代码的特定属性（例如算法符合规范或程序不存在某些缺陷）。虽然对任意 AI 生成代码应用形式化方法通常极为困难，但在特定场景下不失为一种解决方案。即使是轻量级的形式化检查（如使用类型系统证明无类型错误，或对特定算法使用模型检查器）也能在无需完全人工审查的情况下发现问题。将这些方法整合到 AI 工作流程中（可能是由 AI 自身提出可供形式化工具验证的不变量）或许能减少人工工作量。我们已在 AI 辅助测试生成等领域初见端倪——例如自动为代码生成边界测试用例的工具，本质上是通过"破坏"AI 输出来验证其可靠性。

尽管采取了这些缓解措施，一个不容回避的事实依然存在： 最终责任仍在于人类开发者 。在 AI 发展到能够确保正确性之前（对于复杂软件而言，即便可能实现，也是遥远的目标），验证仍将是需要人类判断的必要步骤。具有前瞻性的团队接受这一点并为此预留时间。他们将 AI 视为加速初稿的工具，深知打磨和审查仍需付出努力。正如 Srinivasan 所言——"AI 验证与 AI 提示同等重要"，用户必须投入精力学习如何进行有效验证，而不仅仅是掌握有效提示的技巧。

验证瓶颈确实是个挑战，但意识到它的存在就相当于"打赢了半场战役"。当团队将验证视为首要问题时，就能合理分配资源（工具、培训、流程）来应对，而非措手不及。

争议与未来方向

社区中有声音认为最终目标应是实现全自动验证 ——既然 AI 能编写代码，为何不能最终开发出可以 100%准确检查代码的 AI？乐观者指出，计算机非常擅长运行测试、验证数学计算甚至扫描已知问题模式，因此大部分验证工作或许可以交由工具完成。

确实，已有像 Snyk 这样的公司正在探索如何自动治理和保护 AI 生成的软件。这些平台旨在实时实施防护措施（安全规则、质量标准）当 AI 编写代码时 ，理论上能降低缺陷漏网的风险。这是个诱人的愿景：AI 结对编程不仅能写代码，还能即时标记"嘿，我可能在这里引入了错误"，或"这段代码偏离了您的设计，需要修正吗？"——本质上是具备自我验证或至少自我觉察的辅助能力。

另一方面，许多经验丰富的工程师对过度依赖自动化仍持谨慎态度。他们认为无论 AI 工具多么先进，仍需要人类智慧来正确定义问题、解读需求，并确保软件真正实现预期功能 （包括安全性、性能、合规性等所有非功能性需求）。

编程本质上是一项人类智力活动，AI（目前）尚无法取代验证复杂系统所需的深刻理解 。折中方案——也可能是我们未来的发展方向——是人机协作 ，双方各司所长。

关于信任与效率也存在争论。有人担心过多的验证要求可能会抵消 AI 带来的效率提升，甚至拖慢进度。但支持者反驳称， 目标不是将人类排除在循环之外，而是让循环更快更安全 。如果 AI 能在几分钟内完成 90%的解决方案，然后你花一小时验证和完善，这仍然比从头开始编码数小时更具优势。此外，随着 AI 技术的进步， 验证所需的工作量有望减少 。

或许未来的模型将内置更多检查机制，或者会出现行业标准的提示词库，能够可靠地为常见任务生成正确模式。早期的汽车并不可靠，需要大量维护（比如频繁更换轮胎和调试发动机）——当时的驾驶者不得不持续验证和修理自己的车辆。随着汽车工程的进步，如今我们驾驶时已不会预期车辆每次出行都故障。AI 编程可能遵循相似的发展轨迹：现阶段它还略显粗糙，需要大量人工验证，但十年后或许开箱即用的可信度会大幅提高（尽管某些验证可能永远都是审慎之举，就像现代汽车仍需仪表盘和传感器来向人类驾驶员警示问题一样）。

结论

“信任但要验证”是将 AI 融入软件开发而不失质量严谨性的有效策略。对于资深工程师和眼光独到的技术受众而言，它提供了务实接纳 AI 的路径：在 AI 能发挥作用的地方使用它，同时用全套工程最佳实践作为保障。AI 或许能完成初稿，但最终版本仍需人类审校 。

通过信任 AI 处理重复性和模板化的工作，我们释放了人类的创造力并加速了开发进程。通过验证 AI 输出的每个重要方面——正确性、安全性、性能、风格——我们确保速度的提升不会以牺牲可靠性为代价。这种平衡可以实现两全其美： 代码产出更快，同时仍满足生产环境的高标准要求 。

在实践中，稳健的"信任但要验证"方法意味着在每一步设置防护措施 ：通过设计评审预判 AI 相关问题，采用人机协同的编码实践，通过同行评审和结对编程引入资深见解，实施全面测试和静态分析，以及制定强化这些习惯的组织政策。其核心是建立一种文化——AI 作为强大工具受到欢迎，但每个人都清楚最终责任不能被转嫁给工具 。

对于刚开始运用 AI 的团队，从小规模、低风险场景入手。 先在错误影响较小且易于发现的环节使用 AI，随着验证流程的成熟逐步扩大应用范围。在团队内部分享 AI 应用的成功与失败案例——通过相互学习了解 AI 的强项与短板。久而久之，团队会形成何时依赖 AI、何时需要严格复核的直觉判断。

重要的是， 保持适度的怀疑态度 。AI 的能力正在快速提升，但炒作也随之升温。资深工程师可以提供现实的制衡，确保对新工具的热情不会压倒合理的工程判断。"信任但要验证"模式是一种风险管理：假设 AI 必定会犯一些错误，在造成危害前发现它们，随着工具证明自身价值，你将逐步建立对它的信任。通过这种方式，有助于培育一个既不恐惧 AI 也不盲目崇拜的工程环境，而是将其作为生产力倍增器负责任地使用 。

总之，AI 辅助编程的时代已经到来，随之而来的是思维方式的转变。我们信任 AI 伙伴的协助——生成代码、提供解决方案甚至优化工作。但我们也需要通过自己的审视、测试和工具来验证最终成果的可靠性。

相信 AI，但验证代码——你的系统（和用户）会为此感谢你。

顺便说一句，我很高兴地宣布我正在与 O’Reilly 合作撰写一本新的 AI 辅助工程书籍 。如果你喜欢我在这里的写作，可能会有兴趣了解一下。