是否进行氛围编程

Birgitta 是 Thoughtworks 的杰出工程师（Distinguished Engineer）和 AI 辅助交付专家。她拥有超过 20 年的软件开发、架构师和技术领导者经验。

本文是”探索生成式 AI（Exploring Gen AI）“系列的一部分。该系列记录了 Thoughtworks 技术专家探索将生成式 AI（gen ai）技术用于软件开发的过程。

2025 年 9 月 23 日

关于 AI 生成的代码应该被审查到什么程度的讨论往往感觉非常二元化。氛围编程（vibe coding，即让 AI 生成代码而不看代码）是好还是坏？答案当然都不是，因为”这要看情况”。

那么要看什么情况呢？

当我使用 AI 进行编码时，我发现自己不断地进行小风险评估：是否信任 AI、信任多少，以及我需要投入多少工作来验证结果。随着使用 AI 的经验越来越多，这些评估变得更加敏锐和直观。

风险评估通常是三个因素的组合：

• 概率（Probability）
• 影响（Impact）
• 可检测性（Detectability）

反思这三个维度有助于我决定是否应该使用 AI、是否应该审查代码，以及我以什么详细程度进行审查。这也有助于我思考当我想利用 AI 的速度时，可以采取哪些缓解措施来降低它做错事的风险。

1. 概率：AI 出错的可能性有多大？

以下是一些帮助你确定概率维度的因素。

了解你的工具

AI 编码助手是所使用的模型、工具中发生的提示编排（prompt orchestration），以及助手与代码库和开发环境的集成水平的函数。作为开发者，我们并不完全了解幕后发生了什么，尤其是当我们使用专有工具时。因此，对工具质量的评估是了解其宣称的功能和我们自己之前使用经验的结合。

用例是否对 AI 友好？

技术栈在训练数据中是否普遍？你希望 AI 创建的解决方案有多复杂？AI 应该解决的问题有多大？

你也可以更一般地考虑你是否在处理需要高水平”正确性”的用例。例如，根据设计精确构建屏幕，还是起草一个粗略的原型屏幕。

注意可用上下文

概率不仅关乎模型和工具，还关乎可用的上下文（context）。上下文是你提供的提示，以及 Agent 通过工具调用等可以访问的所有其他信息。

• AI 助手是否有足够的代码库（codebase）访问权限来做出好的决策？它能看到文件、结构、领域逻辑吗？如果没有，它生成无用内容的可能性就会上升。

• 你的工具的代码搜索策略有多有效？有些工具索引整个代码库，有些在文件上进行即时的类似 grep 的搜索，有些借助**抽象语法树（AST）**构建图。了解你选择的工具使用什么策略会有所帮助，尽管最终只有使用该工具的经验才能告诉你该策略的实际效果。

grep

• 代码库是否对 AI 友好，即它的结构是否让 AI 易于使用？它是模块化的，有清晰的边界和接口吗？还是一个大泥球（big ball of mud），很快就会填满上下文窗口？

• 现有代码库是否树立了好的榜样？还是一堆 hack 和反模式（anti-patterns）的混乱？如果是后者，如果你不明确告诉它什么是好的例子，AI 生成更多同样内容的可能性就会上升。

2. 影响：如果 AI 出错而你没有注意到，后果是什么？

这个考虑主要关乎用例。你是在做 spike 还是生产代码？你在为你正在开发的服务待命（on call）吗？它是业务关键型的，还是只是内部工具？

一些合理的健全性检查：

• 如果你今晚待命，你会发布这个吗？
• 这段代码是否有高影响半径，例如它是否被许多其他组件或消费者使用？

3. 可检测性：当 AI 出错时你会注意到吗？

这关乎反馈循环（feedback loops）。你有好的测试吗？你使用的是类型化语言吗？你的堆栈是否让失败显而易见？你信任工具的变更跟踪和差异（diffs）吗？

这也归结于你对代码库的熟悉程度。如果你熟悉技术栈和用例，你更有可能发现可疑之处。

这个维度严重依赖传统工程技能：测试覆盖率、系统知识、代码审查实践。它影响即使 AI 为你进行更改时你能有多大的信心。

传统技能与新技能的结合

你可能已经注意到，这些评估问题中的许多需要”传统”工程技能，其他的则需要新技能。

结合三者：审查力度的滑动尺度

当你结合这三个维度时，它们可以指导你的监督级别。让我们以极端情况为例来说明这个想法：

• 低概率 + 低影响 + 高可检测性：氛围编程没问题！只要事情有效且我实现了目标，我根本不审查代码。

• 高概率 + 高影响 + 低可检测性：建议进行高级别审查。假设 AI 可能出错并为此做好覆盖。

当然，大多数情况介于两者之间。

示例：遗留系统逆向工程

我们最近为客户做了一个遗留迁移项目，第一步是用 AI 的帮助创建现有功能的详细描述。

• 获得错误描述的概率：中等

  • 工具：我们必须使用的模型经常无法很好地遵循指令
  • 可用上下文：我们无法访问所有代码，后端代码不可用
  • 缓解措施：我们多次运行提示以抽查结果的差异，并通过分析反编译的后端二进制文件提高了信心水平

• 获得错误描述的影响：中等

  • 业务用例：一方面，该系统被该组织的数千个外部业务合作伙伴使用，因此重建错误会对声誉和收入构成业务风险
  • 复杂性：另一方面，应用程序的复杂性相对较低，所以我们预计修复错误会很容易
  • 计划的缓解措施：新应用的分阶段推出

• 获得错误描述的可检测性：中等

  • 安全网：没有现有的测试套件可以进行交叉检查
  • SME 可用性：我们计划引入主题专家（SMEs）进行审查，并创建功能对等比较测试

如果没有这样的结构化评估，很容易审查不足或审查过度。相反，我们校准了方法并计划了缓解措施。

结束语

这种微观风险评估会成为第二天性。你使用 AI 越多，你就越能对这些问題建立直觉。你开始感觉到哪些更改可以信任，哪些需要更仔细的检查。

目标不是用清单拖慢自己，而是培养直观的习惯，帮助你在利用 AI 能力的同时降低其 downside 风险的界限之间导航。

---

最新文章（3 月 4 日）： Humans and Agents in Software Engineering Loops

上一篇文章： 与 AI 合作，扔掉代码

下一篇文章： 将 AI 锚定到参考应用