图6-1. 迭代原型优化过程：初始提示词(prompt)生成基础原型，开发者反馈驱动连续改进，通过AI协作创建日益精细的解决方案。

大多数AI原型工具会保留你的请求历史或上下文，这非常有用。这意味着AI会记住你应用的目的和之前的指令，所以你不必每次都重新解释所有内容。这种上下文持久性(context persistence)是vibe-coding环境的标志：与AI的对话成为开发日志。

以下是典型的迭代优化可能的过程：

步骤1：初始生成

你提供提示词或输入来创建原型：

生成一个基础的费用跟踪应用，包含一个添加费用的表单和一个列出费用的表格。

步骤2：审查并运行代码

你获得生成的代码并运行它。也许它能工作，但你注意到一些可以改进的地方。例如，UI是功能性的但很简陋，或者表格不能对费用进行排序。

步骤3：优化你的提示词

你回到AI那里并提供额外的指令。例如：

让费用列表可以按金额或日期排序。

AI可能会修改代码以包含排序逻辑或使用可排序表格的库：

添加一些颜色样式，也许使用一个现代的CSS框架。

AI可以集成一个CSS库（如Tailwind或Bootstrap）或只是添加自定义样式使其看起来更好：

验证表单，这样就不能在没有名称和金额的情况下添加费用。

AI可能会添加简单的前端验证。

每一个这样的提示词都会修改原型。因为AI理解上下文（像Cursor这样的工具和持续的聊天工具会保持代码状态），它通常可以在正确的位置应用更改——例如，在表单中插入验证代码或重写表格渲染以包含可排序的列。

步骤4：冲洗并重复

在每次优化之后，你检查结果。如果AI引入了新问题或没有完全按照你的意图做，你通过提示词进行澄清或修复：

排序是反向的——请默认按升序排序。
新的配色方案很好，但请将标题改为深蓝色而不是黑色。

每个迭代周期都相当快——通常只需要几秒钟的处理——这意味着你可以在一个小时内完成十几次迭代。与手动编码和检查所有这些更改相比，AI方法可以显著更快。这对于广泛的更改尤其如此，比如重新设计样式或添加功能。

重要的是，与AI迭代需要清晰的沟通。这就是你的提示词工程(prompt engineering)技能发挥作用的地方。你对想要的更改越明确和清晰，AI就越有可能正确执行。例如，说”让它看起来更好”是模糊的。一个更具体的提示词给助手一个具体的方向：

应用浅色主题，带有蓝色标题，并增加字体大小以提高可读性。

如果你使用像Vercel v0或Lovable这样的工具，你甚至可能使用其界面指向UI的某个部分并说，“将这个改为X。”

让我们看一个开发者和AI编码助手之间的简短对话迭代过程：

生成一个待办事项列表的React组件。它应该显示一个任务列表和一个添加新任务的文本输入框。

AI生成一个React组件，包含任务的状态(state)并渲染一个列表、一个输入框和一个添加任务的按钮：

很好。现在让每个任务可编辑，并添加一个复选框来标记完成。

AI更新代码，为每个任务渲染一个复选框和编辑功能，并相应地修改状态。开发者运行应用并发现编辑可以工作，但没有删除按钮：

为每个任务添加一个删除按钮。

AI在代码中添加删除功能：

布局有点拥挤。添加一些基本的CSS来间隔列表项并使字体稍大一些。

AI输出CSS样式，可能作为组件中的<style>或单独的CSS片段：

看起来好多了！

这种来回交流可以持续，直到原型符合愿景。最后，开发者获得了一个可工作的待办事项列表应用原型，具有创建、编辑、完成和删除功能——所有这些都是通过自然语言请求和快速的AI代码输出构建的。

在整个过程中，请记住开发者始终是决定发生什么的导演。AI 可能会提出一种实现功能的方式，但你来决定这是否符合你的需求。有时 AI 的实现是正确的，但不是你所期望的(也许它使用了与你想象中不同的 UI 方法)。你可以接受它(如果它不影响原型目标)，或者指示 AI 改用你偏好的方法。

将原型演进到生产环境

原型旨在作为概念验证和学习什么有效的工具。一旦它达到了这个目的——比如，你已经与用户验证了设计或证明了某个功能是可行的——下一步通常是将其转化为生产应用程序。这种转变是一个关键时刻。AI 仍然可以提供帮助，但人类开发者必须打磨原型的粗糙边缘。本节将探讨从原型转向生产代码时的一些关键考虑因素。

首先，仔细审查架构和代码结构。原型在底层可能很混乱。也许你所有的代码最终都放在一个文件中，或者为了速度而绕过了某些最佳实践。现在是引入适当结构的时候了。例如，如果原型是单页脚本，你可能会将其分成多个模块；对于 Web UI，你可能会引入适当的组件结构；对于后端，你可能会建立正式的模型-视图-控制器(MVC)架构模式。

虽然 AI 编写了原型的大部分内容，但你作为开发者最了解架构目标。你甚至可能启动一个全新的项目，将原型用作参考或脚手架，可能会重用一些原型代码，但通常将其视为一次性代码。其他人可能会逐步将原型代码库重构成型，让 AI 建议重构或生成测试以确保在清理过程中不会出现问题。

接下来，添加错误处理和边缘情况。原型代码通常专注于理想场景，但如果 API 调用失败怎么办？如果输入为空怎么办？系统地检查每个功能并考虑潜在的故障模式。

AI 可以帮助你头脑风暴边缘情况，给出如下提示：

这个功能有哪些潜在的错误情况以及如何处理它们？

助手可能会列出一些场景(网络错误、错误输入、并发问题)，你可以为这些场景实现处理(或请求 AI 帮助实现)。确保代码的健壮性是使其为生产做好准备的一部分。

你的原型代码可能没有优化，因此检查任何低效或可能带来安全问题的部分。例如，也许原型中的 AI 使用了一种简单的算法，在小型测试数据集上有效，但在真实数据上会很慢。识别这些地方并优化它们。(我将在第8章介绍常见的 AI 生成代码缺陷。)

一种策略是对原型运行性能测试或使用分析器来查看瓶颈，然后请 AI 帮助优化该函数。一定要审查安全功能，如身份验证和数据处理——AI 原型使用没有适当参数化的 SQL 查询(存在 SQL 注入攻击风险)或包含敏感信息的情况并不少见。这些问题必须修复。2021年的一项研究发现，大约40% 的 AI 生成代码存在潜在漏洞。因此，生产化的一部分就是保持警惕。手动对代码运行静态分析和/或安全测试，或提示 AI “扫描此代码以查找安全问题”。

原型通常缺少文档，在你正式化代码时需要添加：对每个模块进行清晰的人工审查的解释将帮助未来的团队成员，以及在几个月后重新访问代码时帮助你自己。一旦你清理了代码，你可能会提示 AI 工具基于描述系统如何工作的代码生成 Markdown API 文档或 README。第1章讨论了 AI 如何生成代码解释；这是利用这一点的绝佳时机。

彻底测试你的原型至关重要，正如你在第5章中学到的。你可能为核心逻辑编写单元测试，为主要流程编写集成测试等。你可以通过要求 AI 生成测试用例来加速这一过程：

为待办事项列表组件编写 Jest 测试，覆盖添加、编辑、完成和删除任务的功能。

然后运行并调整它生成的测试。拥有一个良好的测试套件能让你在重构原型代码时更有信心。

有时你可能会决定完全替换代码的某些部分——比如原型使用了某个快速而粗糙的库或不适合长期使用的临时方案。AI 也可以加速这个过程。假设你的原型代码使用本地数组存储数据,但现在你需要适当的数据库集成。你的提示词可能是这样的:

集成 SQLite 数据库来存储任务,替代内存数组。

AI 可以为这个集成提供起点,然后你再进行优化。

在进行这些更改时,明智的做法是将思维模式从”快速原型模式”切换到更严谨的工程方法。AI 现在是你提升代码质量的助手——它不再只是快速输出功能。这种动态关系有些不同:由于稳定性和质量现在是你的首要任务,你可能会更批判性地评估 AI 的每个建议。正如我在第 4 章中提到的,资深开发者可以从 AI 中获得巨大收益,因为他们知道该接受什么、该修复什么。在这个阶段,你将大量运用这种资深思维:你对最终系统有清晰的愿景,因此你让 AI 负责特定的改进或实现。

为了使讨论更具体,让我们考虑一个简短的例子。想象一个独立开发者 Jane,她想构建一个小型 Web 应用,将 CSV 文件中的数据转换为图表。她使用 AI 助手在一个周末就完成了快速原型:一个基础的 Node.js 脚本和 API,加上一个简单的前端来上传 CSV 并使用 JavaScript 图表库渲染图表。

她向几个潜在用户演示了这个原型并获得了积极反馈,因此 Jane 决定将其转变为真正的产品(一个 Web 服务)。以下是她如何完成这个转变:

强化后端: 原型的 Node.js API 没有身份验证(任何人都可以上传数据)。对于生产环境,她需要用户账户和认证。她使用 AI 集成身份验证系统(可能基于 JWT)。AI 提供了框架,但她仔细审查以确保密码被正确哈希且令牌是安全的。她还为上传端点添加了输入验证(AI 没有做到这一点),结合了 AI 建议的代码和她自己的调整。
重构前端: 最初的前端是一个单独的 HTML 文件,其中的 script 标签指向依赖项的 CDN。Jane 决定重构为结构化的 React 应用以提高可维护性。她首先要求 AI 通过使用构建系统和 npm 而不是 script 标签来重构项目,使其更适合生产环境。然后她让 AI 帮助将它们集成为 React 组件。例如,它将原型中的图表渲染代码转换为 <Chart> 组件。Jane 使用 AI 来加快编写这些组件的速度,但她确保状态管理和组件层次结构遵循最佳实践(这是原型没有深入考虑的)。
测试和检查性能: Jane 为关键函数(CSV 解析、数据转换)编写单元测试。当她不确定边界情况时,她询问 AI:; CSV 解析应该测试哪些边界情况?; 它建议了空字段和不规则列等场景,她将这些纳入测试中。她还注意到原型将整个 CSV 文件加载到内存中;对于大文件,这可能会崩溃。她修改代码以流式处理,并使用 AI 来复查她的流逻辑。现在应用可以更可靠地处理更大的文件。
完善 UI: 原型 UI 是实用主义的。对于她的产品,Jane 在用户体验上花了更多时间。她让 AI 推荐响应式布局,也许还集成一个 CSS 框架。AI 添加了 Bootstrap,然后她用它来改善外观(表单、按钮、布局)。之后她手动微调了一些 CSS。这个完善阶段不太涉及大量编码,更多的是设计选择,但 AI 仍然通过为标准 UI 模式(如导航栏和加载旋转器)提供快速代码来提供帮助。

经过这些努力，曾经粗糙的原型已经成为一个更加简洁、更加安全、更具可扩展性的应用程序，可以供真实用户使用了。Jane部署了它，感到很有信心，因为她添加了测试并审查了AI生成的代码。从原型到生产的这个过程可能花了她几周时间，而从头开始编写整个产品则需要更长的时间。AI加速了最初的原型开发，并在过渡过程中继续提供帮助，但Jane的人工监督和重构对于达到生产质量是不可或缺的。

应对AI原型开发中的挑战

虽然AI驱动的原型开发功能强大，但也并非没有挑战。作为开发者，你应该意识到这些挑战并知道如何缓解它们。两个特别值得关注的领域是范围蔓延(scope creep)和集成。

因为使用AI添加功能非常容易，你可能会忍不住不断添加”再多一个东西”到原型中，这种现象被称为范围蔓延。这可能导致一个不断膨胀的原型，试图成为最终产品。记住原型的目的：专注于你想要回答的关键问题或要展示的核心体验。如果你发现自己在实现登录系统、支付处理等功能，问问自己这在原型阶段是否真的需要。最好将这些功能模拟出来(AI可以生成一个虚假的登录流程，不是真实的，只是为了模拟)。保持原型的专注性将节省你的时间，并使其更容易在后期丢弃或重做。

保持专注

写下你的原型目标(“演示用户可以上传CSV并获得图表以测试可行性”)，并将其作为北极星。使用AI快速达到这个目标，抵制完美化原型的诱惑。

其次，还有集成到真实系统的问题。原型通常使用模拟数据或简化的子系统。如果你的AI原型使用虚拟数据或本地文件，将其与生产环境中的真实数据库或服务集成可能并不简单。在原型开发时要注意采取了哪些捷径。例如，也许原型邮件实际上并没有发送，只是记录到控制台。在生产环境中，你需要一个真实的邮件服务。AI可以帮助稍后集成这些，但最好记录下来：在原型开发时维护一个”如果我们继续推进需要解决的事项”列表。这样你就不会忘记哪些部分是临时的。如果在团队中工作，要清楚地沟通这些。例如，你可以在代码中留下注释：// TODO: 在此集成真实邮件服务。许多AI工具在生成简化解决方案时实际上会自己包含这样的TODO注释，这很有帮助。

通过预见这些挑战，你可以有效地使用AI原型开发而不会落入其陷阱。当有思虑地使用时，结果是一个在创纪录的时间内开发出的稳健原型，准备好转化为最终产品或在提取了它提供的经验教训后搁置。

总结和后续步骤

在本章中，你看到了AI辅助的vibe coding如何为原型开发过程加速。通过让AI处理代码生成的繁重工作，开发者可以以前所未有的速度从概念转向工作模型。我介绍了用于UI生成的Vercel v0、用于全栈原型的Lovable，以及像Cursor和Windsurf这样的AI增强IDE——每个都支持快速原型开发的不同方面。我还强调了AI原型开发的迭代性质：在快速循环中生成、测试和改进，用自然语言提示指导变更。

虽然AI驱动的原型开发可以在几小时内产生一个功能性演示，我们也讨论了向生产环境过渡的关键。信息很明确：原型不是最终产品。它是第一稿。人类开发者必须重构和加固代码，AI在这个过程中继续提供帮助(建议改进、生成测试等)。使用这些技术的个人和团队的案例研究突显了真实的生产力提升——原型在几天而不是几周内构建完成，实现更快的用户反馈和业务决策。

到目前为止，你应该理解vibe coding如何使原型开发感觉更像是与助手进行头脑风暴，而不是艰难地编写样板代码。这是一种根本不同的感觉：更加对话化、更加高层次，而且快得多。然而，你也看到了即使在快速原型中保持代码质量意识的重要性——当然，在将其发展到原型阶段之外时更是如此。

在[第7章]中，我将把重点从快速原型设计转向在AI辅助下进行全面的Web应用开发。虽然原型设计是在探索可能性，但全面的开发需要系统化的方法来处理架构、实现和部署。

第7章.使用AI构建Web应用

本章将重点从快速原型设计转向使用AI辅助开发完整的Web应用。Web应用通常包括前端（通常使用React、Angular或Vue等框架编写）、后端（APIs、数据库、服务器）以及连接所有组件的粘合代码。Vibe编码可以加速这些层的开发。

我将引导您完成使用AI结对编程构建Web应用的端到端工作流程，包括：

设置项目及其脚手架
编写前端UI代码
实现后端逻辑
集成数据库
测试和验证整个技术栈

在此过程中，我将重点介绍前端的AI开发模式（例如，让AI根据描述生成React或Vue组件）和后端的开发模式（通过自然语言提示编写路由、业务逻辑和数据库查询）。我还将介绍如何在全栈项目中优化人类与AI之间的协作，确保双方都能发挥各自的优势。在本章结束时，您应该能够清楚地了解如何使用AI不仅处理独立的编码任务，还能高效地管理整个Web开发工作流程。

设置项目：使用AI搭建脚手架

每个Web应用都从某些脚手架开始——构建工具、文件结构、依赖项等的初始设置。AI可以自动创建大量样板代码。现代Web框架通常配备命令行界面（CLI）工具，可以生成基础项目，但您可能仍需要配置某些内容或集成其他库。AI助手可以通过引导您使用这些CLI工具或按需设置自定义项目结构来提供帮助。

例如，假设您想使用React作为前端、Express作为后端来启动一个新的应用项目。在AI出现之前，这项任务的工作流程可能如下所示：

运行CLI工具或Vite来设置React项目。
初始化Express应用（可能使用npm init并安装Express）。
为开发设置代理或配置跨域资源共享（CORS），以便React前端可以与Express后端通信。
可能集成像MongoDB这样的数据库，或设置SQLite文件以供简单使用。

使用像Cursor或Cline这样的AI编码环境，您可以一次性描述您想要的设置：

设置一个新项目，包含React前端（使用Vite）和Express后端。后端应为待办事项列表提供REST API，并使用内存数组作为起点。配置前端以在开发环境中代理API请求到后端。

高级AI IDE可以接受此指令并执行以下操作：

创建两个目录（frontend和backend）。
运行npm create vite@latest（如果它有shell访问权限）或模板化一个基础React应用。
在后端初始化一个基础Express服务器文件，包含类似/api/to-dos的端点（返回一些示例数据）。
在每个目录中包含一个package.json文件，其中包含相关脚本（如start both）。
通过在React开发服务器中配置代理或提供实现CORS头的说明，设置前端和后端之间的通信。

几分钟内，您就会拥有一个全栈Web应用的骨架。即使AI没有自动完成所有操作，它也可能会为您提供代码和完成设置所需的说明（例如，“将此代理设置添加到您的React package.json文件中”）。这节省了大量无意义的设置时间，让您可以立即专注于功能开发。

如果您没有使用AI IDE，您仍然可以逐步使用ChatGPT或其他助手；例如：

我想创建一个新的React应用。我应该运行什么命令？

AI 可以引导你完成各个步骤，或推荐像 Vite 或 Next.js 这样的新选择：

现在设置一个带有 /api/to-dos 路由的 Express 服务器。

它可以生成 Express 服务器的代码，你可以复制到文件中：

在开发过程中，我如何将 React 应用连接到这个 API？

它可能会建议代理配置，或告诉你如何调用 API（如果不使用代理，会包括完整的 URL）。

这样，即使是设置基本架构也变成了一次对话，而不是在文档中寻找答案。如前面章节所述，意图编程意味着你告诉 AI 想要什么结果，它会找出实现步骤。设置项目是这种方式的完美场景。

在这个阶段，明确你的架构决策很重要。AI 会跟随你的引导。架构和高层决策需要人来做，所以你要自己决定技术栈和主要模式：你想要单体仓库还是前后端分离的仓库？使用 REST 还是 GraphQL？使用哪个数据库？

一旦你有了这些想法，就可以相应地指导 AI：

同时为 SQLite 数据库设置一个基本的 Prisma schema。

或者：

使用 GraphQL 服务器而不是 REST。

AI 可能无法完美执行复杂的设置，但它会完成大部分工作，你可以在此基础上进行优化。

许多有经验的开发者将这些步骤整合到项目模板中，或使用样板代码生成器，但 AI 提供了更灵活的方法：你可以使用自然语言即时定制。这意味着如果你的项目有些特殊（也许需要三个服务而不是常见的两层架构，或者想预配置像 Tailwind CSS 这样的特定库），只需要求 AI 包含你想要的内容即可。

使用 AI 进行前端开发模式

一旦脚手架准备就绪，开发 Web 应用的前端是工作的主要部分。本节探讨如何利用 AI 结对编程助手来编写前端代码。

从描述实现组件

你可以通过描述组件的功能和外观来要求 AI 创建组件；例如：

创建一个名为 TodoList 的 React 组件，它接收一个待办事项列表并显示它们。每个项目应显示其标题和一个复选框来标记完成状态。

AI 应该生成函数式组件的代码，根据需要包含 props 和 state：

创建一个 Vue 组件用于登录表单，包含用户名和密码输入框，并在提交时发出包含表单数据的事件。

AI 可能会相应地输出 <template>、<script> 和 <style> 部分。作为开发者，你跳过了编写样板代码，直接得到需要的结构。之后很容易根据需要进行调整。AI 通常甚至会包含基本的验证或状态处理，如果你的提示暗示需要它们的话。

在这个阶段确保一致性很重要。如果你孤立地生成多个组件，可能需要调整它们以协同工作。例如，如果 TodoList 期望项目是某种 prop 形式，确保使用 TodoList 的任何组件都提供该形式。你可以在一个提示中生成所有组件（这样 AI 就知道所有内容），或者自己连接它们并要求 AI 修复任何不匹配。

样式和布局

CSS 和样式可能很繁琐。描述你想要的外观，让 AI 处理 CSS 细节：

为待办事项列表组件添加样式：使用 flex 列布局，添加一些间距，将已完成项目的文本颜色改为灰色并加上删除线。
对于登录表单组件，将其在页面上居中，并使输入框更大且带有圆角边框。

助手可以输出 CSS-in-JS、纯 CSS 或内联样式，具体取决于上下文。如果你使用像 Tailwind CSS 这样的框架，甚至可以要求它输出适当的类（尽管请记住，并非所有模型都完全了解 Tailwind）。

重点是：你可以在设计上迭代，而无需手动调整 CSS 值。这让你的注意力保持在更高的抽象层次上—指定什么看起来好，而不是编写每个 margin 和 color。

集成 API 和状态管理

Web 前端通常需要从后端获取数据，并使用 Redux、context 或简单的组件状态来管理状态(state)。AI 可以帮助编写这些集成部分；例如：

添加代码，在 TodoList 组件挂载时从 /api/to-dos 获取待办事项列表，并存储到状态中。
在 TodoList 中实现一个函数，当复选框被切换时，向 /api/to-dos/{id}/complete 发送 POST 请求，然后相应地更新状态。

AI 可以生成 React 中的 useEffect 钩子(hook)来执行获取操作，或生成 Vue 中的 mounted() 钩子。它还可以生成 HTTP 调用的存根（使用 fetch 或 Axios 等）。你需要确认 API 端点和负载与后端的预期匹配（如果你已经构建了后端或有相关规范）。

如果你还没有构建后端，你可能同时在使用 AI 创建它——我们很快就会讲到这一点。但你可以在 AI 的辅助下并行开发前端和后端，因为只要你跟踪它们之间的接口，每一部分都可以相对独立地指定和生成。

使用 AI 指导处理复杂性

如果你的前端有复杂的逻辑，例如动态表单验证规则、条件渲染或复杂的用户交互，你可以在 AI 的帮助下逐步实现这些功能。一个好的做法是将问题分解：

添加一个功能：当用户勾选待办事项的”完成”复选框时，淡出该列表项（CSS 过渡），然后在 1 秒后将其从列表中移除。

AI 可能会生成代码，在勾选时添加一个 CSS 类，并使用超时来移除该项，包括淡出所需的 CSS：

表单有一个可选的”备注”字段。仅当勾选了”添加备注”复选框时才显示备注文本区域。

AI 可以修改组件状态和 JSX 以条件渲染备注字段。

这些都可以是迭代式的提示。本质上，你描述 UX 行为，AI 编写代码。在每次添加后始终进行测试，以确保其按预期运行。

框架特定提示

不同的框架有不同的习惯用法：

在 React 中，AI 可能使用钩子（如 useState、useEffect）。仔细检查它是否遵循最佳实践（例如，useEffect 中的依赖项数组(dependencies)是否正确）。
在 Vue 中，AI 可能会根据它所见过的内容输出选项式 API 风格或组合式 API 风格。如果你偏好其中一种，应该明确指定（例如，“使用 Vue 3 组合式 API”）。
在 Angular 中，AI 可以生成组件，但 Angular 的学习曲线更陡峭。AI 可能能够根据请求生成模板、TypeScript 类和基本的服务注入，但你可能需要做更多手动工作或使用 Angular CLI 构建结构，然后要求 AI 填充特定部分（如表单验证逻辑）。

使用 AI 进行后端/API 开发的模式

现在让我们转向后端。使用 AI 构建 Web 应用程序的服务器端遵循类似的范式：你描述你想要的端点、数据模型和逻辑，AI 生成代码。常见的后端组件包括路由处理器、业务逻辑、数据库交互和验证。AI 可以帮助处理所有这些。

实现 API 端点

假设你正在为待办事项应用构建一个 RESTful API。你可能会有这些端点：GET /to-dos、POST /to-dos、PUT /to-dos/:id、DELETE /to-dos/:id。你可以逐个端点进行开发：

在 Express 应用中，添加一个 GET /api/to-dos 路由，返回待办事项列表（暂时使用内存中的数组即可）。
添加一个 POST /api/to-dos 路由，接受 JSON 主体并将新待办事项添加到列表中。返回带有 ID 的新待办事项。

AI 会相应地编写 Express 路由处理程序，可能会使用类似 app.get('/api/to-dos', ...) 的代码。如果你指定使用 Express 和 JSON，它可能会包含必要的中间件（如果尚未存在）：

app.use(express.json())

随着后端的增长，你可以要求 AI 进行重构：

将 Express 路由重构到单独的路由器模块中。

它可能会将路由拆分到单独的文件中，这是保持可维护性的良好实践。

数据库集成

你可能会在原型中使用内存数据，但对于更完整的应用，你需要一个数据库。假设你选择 MongoDB 或 PostgreSQL。你可以这样提示：

使用 Mongoose 将 MongoDB 集成到 Express 应用中。创建一个包含以下字段的待办事项模型：title（字符串）、completed（布尔值）。修改 GET/POST 路由以使用数据库而不是内存数组。

AI 可能会输出 Mongoose 模型定义，并调整路由处理程序以查询数据库（例如 GET 使用 Todo.find()，POST 使用 Todo.create()）。同样，对于 SQL，你可以要求它设置一个对象关系映射(ORM)，如 Prisma 或 Sequelize。请记住，你可能需要提供配置详细信息（如连接字符串）。AI 可能不知道你的数据库 URI；你需要自行填入。但它会处理通用代码。

业务逻辑和验证

如果你的后端有特定规则（例如，用户无法删除标记为重要的待办事项，或者列表标题必须唯一），你可以通过 AI 编码这些规则：

为 POST /api/to-dos 路由添加验证：如果标题为空或超过 100 个字符，则拒绝并返回 400 状态。

AI 会包含检查并发送适当的响应。

添加逻辑：当待办事项标记为完成时（通过 PUT /api/to-dos/:id），如果所有待办事项都已完成，记录消息”全部完成！”

它可以在 PUT 处理程序中插入该逻辑。

你用简单的语言描述这些需求，AI 会相应地修改代码。你仍然需要测试代码是否符合预期。

使用框架或样板

许多 Web 后端使用框架，而不仅仅是原始的 Express（如 Node 的 NestJS 或 Python 的 Django）。AI 也可以处理这些框架，尽管你可能需要将更复杂的任务进一步分解：

对于 Django（Python），你可以这样提示：

创建一个包含字段 X 的 Django 待办事项模型，以及相应的列表和创建视图。
AI 可能会输出模型代码和通用视图，或者如果它了解上下文的话，会输出 DRF（Django REST Framework）序列化器/视图集。

[内容]

数据库查询

当在你的代码中集成数据库时,你可能需要比简单CRUD更复杂的查询。假设你想获取所有项目及其任务和分配给每个任务的用户——这需要跨Project、Task、User表进行连接。你可以这样提示:

编写一个SQL查询,检索项目及其任务和每个任务的分配用户名。

AI可以为你生成一个SQL连接查询。

或者如果你使用ORM:

使用Sequelize,获取所有项目及其关联的任务和每个任务的用户。

你可以期待代码会包含类似这样的内容来加载相关数据:

include: [Task, { model: User, as: 'assignedUser' }]

检查AI生成的查询

数据库操作需要仔细验证,以确保AI生成的代码与你的实际模式(schema)一致并保持数据完整性。除非你在提示中明确提供这些信息,否则AI无法自动知道你的具体表名、字段名或关系。即使模型具有对话记忆,你也应该在每个复杂的数据库相关提示中包含模式详细信息以确保准确性。这种明确的方法可以防止AI生成的查询引用通用字段名(如user_id)而你的模式实际使用userId或customer_ref的常见问题。

性能考虑通常需要人工监督。虽然AI模型理解主键和连接等基本数据库概念，但它们可能不会自动建议性能优化，例如在频繁查询的字段上添加索引或考虑查询执行计划。请审查生成的查询的效率，特别是对于将频繁运行或针对大型数据集的操作。

数据一致性规则(data consistency rules)代表另一个需要明确说明的关键领域。在实现删除操作时，请清楚定义您期望的级联行为(cascading behavior)。例如，在删除Project记录时，您必须决定数据库是否应该通过级联删除(cascading deletes)自动删除关联的Task记录，或者您的应用程序逻辑是否应该处理此清理。向AI清楚地传达这些业务规则：

当删除项目时，配置数据库级联删除所有相关任务。

或者：

当删除项目时，首先检查现有任务，如果存在任何任务则阻止删除。

当给出明确的方向时，AI可以有效地实现任一方法。对于级联删除，它可能生成带有ON DELETE CASCADE的外键约束。对于应用程序级别的处理，它可以生成在允许删除之前查询相关记录的代码。关键在于明确说明您的数据完整性要求，而不是假设AI会为您的特定领域推断出适当的行为。

全栈集成：前端与后端的结合

现在您已经在AI的帮助下构建了前端和后端，下一个挑战是将它们集成到一个无缝的Web应用程序中。这涉及确保从前端正确调用API端点(API endpoints)，数据正确流动，以及整个系统是连贯的。

对齐前端和后端契约

这至关重要：前端期望以某种形式接收数据，因此后端发送的内容应该与该期望相匹配。如果您让AI独立地在每一端工作，可能会出现小的不匹配（也许后端返回{ success: true, data: [...] }，但前端期望直接接收数组）。为了避免这种情况，您可以在编写两端代码时明确指示AI使用响应格式。或者，一旦两者都完成，测试端到端调用：例如，打开Web应用程序并查看列表是否加载。如果没有，请对照服务器日志检查浏览器控制台。

我经常使用AI来调整一端以匹配另一端：

如果后端返回的JSON键名与前端期望的略有不同，并且您注意到一个错误，您可以对AI（在任一端）说：

修改代码以在JSON中使用’tasks’（复数）而不是’taskList’（单数）。
如果前端将表单数据作为表单编码发送，但后端期望JSON，您可以要求AI进行转换，可能通过在前端使用JSON.stringify或在后端添加body-parser。

与AI的实时协作

在集成阶段，能够掌握整个项目上下文的AI增强IDE（如Cline或Cursor）会特别有帮助。你可以在基于IDE的工具中并排打开前端和后端文件，然后提示：

确保前端从 /api/to-dos 的fetch与Express路由的预期请求/响应匹配。修复任何差异。

AI可能会协调内容（比如在前端缺少时添加 await response.json()，或调整JSON结构）。

状态管理和同步

在全栈应用中，考虑在前端实现加载状态和错误处理以应对失败的API调用，从而获得专业的结果。你可以使用以下提示：

添加加载指示器：当React组件正在获取任务时，显示”加载中…“文本，直到数据加载完成。

或者：

处理错误：如果API调用失败（非200响应），在UI上显示错误消息。

它会添加 isLoading 状态和条件渲染，或在 fetch 周围实现 try/catch 来捕获错误并显示消息。这种改进使你的应用感觉更加健壮。

WebSockets和高级集成

如果你的应用需要实时更新（比如使用WebSockets或SSE），你可以这样提示：

使用Socket.io设置WebSocket。当服务器上创建新任务时，将其广播给所有连接的客户端。修改前端以监听新任务并将它们实时添加到列表中。

这很复杂，但AI可能会生成服务器端Socket.io设置（如添加 io.on('connection', ...) 并在创建新任务时发出事件），以及客户端代码来连接并监听该事件。你需要仔细集成这些，但令人惊讶的是，这些描述可以产生可工作的实时代码。如果一开始不能完美运行，通过迭代提示和测试可以实现目标。

示例：使用AI的全栈流程

为了说明，让我们想象你正在构建一个简单的联系人管理器Web应用：

你搭建一个React前端和一个Node/Express后端，就像本章前面所做的那样。
首先，对于前端，提示创建一个 ContactList 和一个 ContactForm 组件。然后提示添加API调用：

在ContactList中，在挂载时从/api/contacts获取联系人。

在ContactForm中，在提交时，使用表单数据向/api/contacts发送 POST 请求，然后在成功时更新联系人列表。
对于后端，你可能想使用内存数组或首先集成数据库。然后提示创建Express路由 GET /api/contacts（返回列表）和 POST /api/contacts（将联系人添加到数据库或内存）。
尝试通过UI添加联系人。如果它出现在列表中，很好。如果没有，调试。也许 POST 路由没有正确返回新联系人，或者表单代码没有刷新列表。识别差距并提示AI修复：

添加联系人后，后端应在响应中返回新的联系人对象，前端应将其添加到列表中而无需完全重新加载。

这可能导致AI调整后端响应和前端状态逻辑来推送新联系人（可能使用React状态更新）。
类似地实现编辑和删除功能，每次都让AI处理常规部分，并将你的输入集中在功能应该做什么上。

手动完成所有这些对于初级开发人员来说可能需要一到两周的工作，但使用AI代码开发者，考虑到大量模板代码和连接是自动化的，可以在一两天内完成。

在全栈开发中优化AI-人类协作

在处理整个技术栈时,与AI助手建立高效的协作节奏非常有用。以下是优化协作的一些策略:

使用AI生成样板代码;自己编写自定义逻辑

识别哪些代码部分是常规的,哪些是独特的核心逻辑。让AI生成CRUD API或标准组件——但如果有特别棘手的逻辑片段,比如专有算法或更容易直接实现的特定业务规则,手动完成这部分,然后要求AI审查或测试它。可以把它看作是将重复性任务委托给AI,而你处理新颖的任务。

使用AI逐项处理待办事项

在开发过程中,跟踪任务(如要添加的功能和要修复的bug)。然后逐一向AI解释每个任务,让它提出解决方案。例如,假设你有一条备注写着”在用户注册时实现密码哈希”。尝试这样的提示:

在保存用户之前,在 POST /api/register 路由中使用bcrypt添加密码哈希。

这种有针对性的系统化方法有助于确保你不会忘记任何事情。

提示AI在过程中改进代码质量

在实现功能后,你可以提示:“重构此代码以提高可读性”或”优化此函数”。AI通常可以使代码更清晰或提出性能改进建议,就像助手在你的监督下进行第二遍润色。确保验证任何更改仍然能通过测试。

使用AI进行交叉检查

如果你对设计方法不确定,可以询问AI:

使用数组在内存中存储联系人可以吗,还是应该使用数据库?各有什么优缺点?

虽然你可能知道答案(使用数据库实现持久化),但这就像与同事交流想法。有时AI可能会提到你没有想到的考虑因素:

如果有多个服务器实例,内存存储不会在它们之间同步。

使用AI与团队协调

如果你在团队中工作,不是每个人都可能直接使用AI。在这种情况下,确保要求AI记录你所做的工作。同时,向团队传达你的方法也很重要:“我使用AI快速生成了这些控制器。我已经检查过了,但请留意任何不寻常的模式。”鼓励代码审查文化,让每个人像审查其他代码一样审查AI编写的代码,以发现任何问题。

采用AI的实际团队(如Snyk的团队)报告称,它可以提高生产力,但他们也强调要保持人工参与验证。在GitHub 2024年的一项调查中,97%的开发者报告在工作中以某种方式使用AI编码工具。

测试和验证AI生成的Web应用程序

在借助AI构建web应用程序后,要进行彻底测试,以确保一切按预期工作,并捕获你或AI可能引入的问题。以下是在这种AI辅助环境中进行测试的方法:

单元测试(Unit tests)

后端逻辑的单元测试

对于后端逻辑，为关键函数（如计算函数或验证输入的函数)编写单元测试。如果函数是由 AI 编写的，为其编写测试可以揭示任何隐藏的 bug。你甚至可以让 AI 生成这些测试，如前所述。但要谨慎：AI 生成的测试有时过于简单或假设某种实现，因此你可能需要引导它测试边缘情况：

为密码强度函数编写测试，包括边缘情况，如空密码、超长密码、包含特殊字符的密码等。

集成测试

使用 Supertest（用于 Node）或直接 HTTP 调用等工具测试 API 端点。检查每个端点是否返回预期结果。AI 可以帮助你构建这些测试的框架：

使用 Jest 和 Supertest 为 /api/to-dos 端点编写集成测试。

它可能会生成启动应用、调用端点并对响应进行断言的测试。

前端测试

Web UI 测试可以使用 Jest（用于组件逻辑）和 Cypress 或 Playwright 等工具进行端到端 UI 测试。你当然可以让 AI 生成 Cypress 测试场景：

编写一个 Cypress 测试，加载应用，通过表单添加一个新的待办事项，并检查它是否出现在列表中。

你会得到一个测试脚本，可以运行它。这非常强大——通过利用 AI 来编写用户交互脚本，你可以快速获得端到端的测试覆盖。

手动测试

无论你运行什么自动化测试，始终要进行一些手动探索性测试。亲自在 Web 应用中点击（或者如果你在团队中工作，让 QA 来做）。AI 可能无法预料到每个真实世界的场景：例如，也许使用浏览器的后退按钮会破坏某些状态，或者特定的操作序列会导致故障。当你发现 bug 时，修复它们或请 AI 帮助修复。手动测试对于 UI/UX 判断也很重要——应用使用起来感觉好吗？有没有任何不流畅的流程？AI 不知道如何判断这些主观的 UX 问题，因此人工反馈是关键。

代码审查

如果你与他人合作，让他们审查 AI 生成的代码。新的视角可以发现你可能忽略的问题——他们可能会发现安全疏漏，或者只是建议一种更符合惯例的编写方式。使用 AI 的团队通常会维持正常的代码审查流程，只是更加关注审查 AI 可能无意中引入的细微 bug 或安全问题。

安全审计

第 8 章将深入探讨安全性，但即使在开发阶段，也值得扫描你的代码以查找已知的漏洞模式。你可以运行自动化工具，如 linter 和静态应用安全测试（SAST）工具，或者你可以提示 AI：

审查 Express 应用代码，列出任何潜在的安全漏洞或最佳实践违规。

AI 可能会标记一些令人惊讶的事情，比如”你没有在这里清理用户输入”或”你应该正确设置 CORS”。将其用作加固应用的检查清单。

使用 AI 的一个有趣效果是，你可能会编写原本不会编写的测试，因为 AI 使创建它们变得如此容易。这实际上可以最终导致更加健壮的代码。如果你在生成功能后立即采用生成测试的做法（本质上是 AI 辅助的测试驱动开发，或至少是事后测试），你可以确保快速开发不会影响质量。可以这样想：既然 AI 为你节省了编写代码的时间，那就把节省下来的一些时间投入到编写和运行测试中。

如果用户不小心，AI 可能会建议不安全的代码。例如，如果没有明确提示避免这种情况，早期的 AI 版本可能会生成容易受到注入攻击的 SQL 查询。通过测试和审查，你可以捕获这些问题。一项研究发现，使用 AI 辅助的开发人员往往对其代码的安全性过于自信，即使它比手动编写的代码更差。

永远不要仅仅因为是 AI 编写的代码就跳过验证。假设它可能有 bug，就像任何人工编写的代码一样。

成功的 AI 构建 Web 项目示例

让我们重点介绍几个例子（从各种报告中汇总的综合案例），其中AI辅助在交付真实Web应用程序方面发挥了重要作用。

独立开发者的电商网站: 一位独立开发者想要创建一个小型电商Web应用来销售定制T恤，但时间有限。他通过IDE扩展使用GPT来构建整个技术栈。他提示AI生成一个带有产品列表、购物车和结账页面的React前端，以及一个带有产品和订单端点的Node.js后端。他使用Stripe进行支付，通过让AI帮助处理Stripe的API来完成集成。在晚上工作两周后，他拥有了一个可运行的网站。; 这位开发者表示，AI可能完成了70%的编码工作，特别是重复性的UI部分和表单处理，而他则专注于正确配置Stripe并微调UI以符合品牌形象。最终，客户可以浏览产品、将它们添加到购物车并进行购买——所有这些都在一个主要通过vibe编码构建的系统中实现。这也突出表明，只要模型能够参考文档或你提供文档，外部服务集成（如Stripe）在AI指导下是可行的。
公司内部仪表板: 一位具有一定编码技能的产品经理使用AI配对程序员为她的团队创建了一个内部分析仪表板。通常情况下，她必须等待工程资源，但使用Replit的Ghostwriter或GitHub Copilot等工具在Web项目中，她成功地自己构建了一个基本的Web应用。AI帮助设置了一个简单的Flask后端来查询他们的数据库（使用安全的只读凭证）和一个Vue.js前端来显示图表（使用图表库）。她描述了每个图表应该显示什么（“随时间变化的总注册数”、“按地区划分的活跃用户”），AI编写了SQL查询和图表代码。; 整个过程花费了几周的修改和测试时间，但最终她交付了一个可运行的仪表板。代码质量并未达到企业级标准，但由于是内部使用，这已经足够了。更重要的是，她在短时间内为团队提供了一个工具。这个例子说明了AI工具如何使非专业程序员能够生产有用的Web应用，解决了可能会一直搁置在待办事项列表中的任务。这是我将在第10章讨论的”程序员解绑”的一个例子，该章节完全关于个人现在如何更容易地创建个人或团队特定的软件。
创业公司最小可行产品(MVP): 一家小型创业公司（只有两位联合创始人：一位负责商务，一位负责技术）需要一个MVP Web应用程序来向投资者展示。技术联合创始人广泛使用vibe编码在创纪录的时间内构建了一个MVP。使用AI助手，他使用Next.js构建了一个现代Web应用的脚手架，用于SSR React前端和一个简单的Node API。他利用AI实现了诸如社交登录（AI编写了OAuth流程）、图片上传（AI与云存储API集成）等功能，以及产品本身内部基于AI的功能。他们甚至使用AI帮助从API集成了一个NLP模型。在几个月内，一位开发者完成了通常需要一个小团队四到六个月才能完成的工作。结果是一个有些粗糙但可运行的产品，他们可以进行演示，甚至可以让测试用户加入平台。; 当联合创始人后来雇用更多开发人员来完善产品时，新开发人员发现AI编写的代码大部分是可理解的，尽管他们确实为了可扩展性而重构了大部分代码。这强调了AI可以让你快速到达第一阶段，但随着进入下一阶段，你可能需要在质量上进行投资。

这些故事虽然是轶事性质的，但与行业中的新兴模式相符。特别是在Web开发中，通常涉及将许多组件连接在一起，生产力提升是非常明显的。微软和其他机构报告的研究发现，使用AI的开发者比没有使用AI的开发者能够更快地完成任务。

然而，也出现了一些警示性案例。例如，开发者可能会部署一个带有安全漏洞的AI生成的Web应用，因为他们并不完全理解代码。这种风险强化了为什么测试和审查至关重要。

总之，使用AI辅助构建Web应用程序正在成为一种主流方法。它并不会消除对熟练开发人员的需求；相反，它增强了他们的能力。开发人员仍然需要规划架构、确保正确性并处理代码中复杂或新颖的方面，而AI则处理将所有内容粘合在一起的重复样板代码(boilerplate code)。我们所演示的端到端工作流程——从脚手架搭建到前端到后端再到测试——证明了Web开发的几乎每一步都可以通过AI加速，只要你在整个过程中运用人类的判断和专业知识。

总结与下一步行动

在本章中，你已经看到了氛围编码(vibe coding)如何扩展到全栈Web应用程序开发。通过将AI视为一个随时可用的结对编程伙伴，你可以并行处理前端和后端任务，从自然语言描述生成组件和API，并迭代地将原型应用优化至生产质量。成功的关键包括清晰地传达你的意图（以便AI知道你在每一步想要什么）、仔细验证（以捕获AI输出中的问题），以及不仅利用AI生成代码，还可以用于头脑风暴模式设计和编写测试等事情。

本章还探讨了开发人员如何有效地成为全栈工程师，通过AI增强能力，在他们不太熟悉的领域建议代码来弥合知识差距。这大大减少了常见功能的开发时间，并在某种程度上实现了开发的民主化，使人们能够在没有大型团队的情况下创建定制化的Web解决方案（我将在第10章重新讨论这个主题）。

AI并不能取代对需求的理解或确保质量；它加速了执行过程。

现在你的Web应用程序已经启动并运行，下一个关注点是确保它是安全、可靠和可维护的。第8章深入探讨了AI生成代码库中的安全性和可靠性挑战，识别可能出现的常见漏洞，如何审计和修复它们，以及最佳实践（如我们在这里已经开始应用的测试和审查）以确保使用AI快速开发不会破坏系统。本质上，我们将从构建转向加固——确保你的氛围编码软件能够经受住现实世界的条件和威胁。

第三部分信任与自主性

第8章安全性、可维护性和可靠性

本章直面氛围编码和AI辅助工程的一个关键方面——确保你使用AI辅助生成的代码是安全、可靠和可维护的。如果生成的软件充满漏洞或容易崩溃，那么速度和生产力就毫无意义。

首先，我将审视AI生成代码中出现的常见安全陷阱，从注入漏洞(injection vulnerabilities)到密钥泄露(secrets leakage)。你将学习审计和审查AI编写代码中此类问题的技术，有效地充当AI结对编程伙伴的安全防护网。

接下来，我将讨论围绕AI生成代码构建有效的测试和QA框架，以便尽早捕获错误和可靠性问题。性能考虑也将被涵盖。AI可能会编写正确的代码，但它并不总是最高效的代码，因此我将概述如何识别和优化性能瓶颈。我还将探讨确保可维护性的策略，例如强制执行一致的样式或重构AI代码，因为AI建议有时可能不一致或过于冗长。

我将向你展示如何使你的代码审查实践适应AI辅助工作流程，强调在审查部分或全部由机器生成的代码时，人类审查者应该关注什么。最后，我将总结自信地部署AI辅助项目的最佳实践，从持续集成管道(continuous integration pipelines)到生产环境监控。在本章结束时，你将拥有一套工具包方法来保持AI加速开发的安全和健壮性。

AI生成代码中的常见安全漏洞

AI编码助手虽然强大，但如果没有得到适当的引导，可能会无意中引入安全问题。它们从大量公共代码中学习——其中既包括好的实践也包括坏的实践——如果提示或上下文没有将它们引导开，可能会重现不安全的模式。了解这些常见陷阱至关重要，以便你能够发现并修复它们。这可以包括使用手动和自动化手段来检测潜在的安全问题（见图8-1）。

图8-1. AI引入的安全漏洞：AI生成的代码可能包含微妙的安全缺陷，需要仔细审查和自动化安全扫描来识别和修复。

在 AI 生成的代码中观察到的一些典型安全问题包括：

硬编码的秘密或凭据

有时 AI 会在代码中输出 API 密钥、密码或令牌，特别是当类似的示例出现在其训练数据中时。例如，如果你让它集成 AWS，它可能会将一个虚拟的 AWS 密钥直接放在代码中。如果保留这些内容会很危险——如果代码被分享，可能会泄露敏感信息。始终确保通过环境变量或配置文件正确管理秘密。如果 AI 建议类似 api_key = "ABC123SECRET" 的内容，请将其视为一个标记——真正的密钥不应该出现在源代码中。

SQL 注入漏洞

如果让你的 AI 模型生成 SQL 查询或 ORM 使用，请检查它是否没有通过直接拼接用户输入来构造查询。例如，一个不安全的模式是：

sql = "SELECT * FROM users WHERE name = '" + username + "'";

这容易受到注入攻击。如果你没有特别告诉 AI 使用参数化查询，它可能会产生这样的代码。始终使用预处理语句或参数绑定。许多 AI 助手如果记得最佳实践（如在 SQL 中为用户输入使用 ? 或占位符），会这样做，但不能保证。你需要验证，如果需要，要求 AI 修复：

修改此查询以使用参数来防止 SQL 注入。

Web 应用中的跨站脚本攻击（XSS）

在生成 Web 代码时，AI 工具并不总是自动转义输出中的用户输入。例如，你的 AI 可能生成一个直接将 {{comment.text}} 插入 HTML 而不转义的模板片段，这可能允许在评论中放置的恶意脚本运行。如果使用框架，AI 通常默认会转义，但如果它们处理原始 HTML 构造，要小心。实现输出编码或清理例程。你可以提示 AI：

为用户输入添加清理以防止 XSS。

许多现代框架都有内置机制，因此确保 AI 使用它们，比如在文档对象模型（DOM）操作中使用 innerText 而不是 innerHTML。

不当的身份验证和授权

AI 可以编写身份验证流程，但可能会出现细微的错误：例如，在没有足够强秘密的情况下生成 JSON Web Token (JWT)，或者没有正确检查密码哈希。

授权也是如此：AI 可能不会自动强制执行某个操作（如删除资源）仅限于拥有该资源的用户。这些逻辑问题很难自动捕获——它们需要思考安全模型。在编写此类代码时，请明确指定：

确保只有资源的所有者可以删除它。添加用户 ID 检查。

然后测试这些条件。AI 很容易遗漏检查，因为除非被告知，否则它不会真正”理解”上下文。

不安全的默认值或配置

除非提示，否则 AI 可能会选择便利性而不是安全性。示例包括：

使用 HTTP 而不是 HTTPS 进行 API 调用（如果未指定 TLS）
不验证 SSL 证书（互联网上的一些代码示例在请求中使用 verify=false，AI 可能会复制）
无限制地为所有源和方法广泛启用 CORS（可能会使应用程序对任何跨源请求开放）
选择过时的加密技术（如用于哈希的 MD5 或 SHA1，它们很弱，而不是用于密码的 SHA-256/Bcrypt/Argon2）

这些问题通常很微妙，这就是为什么审核配置文件和初始化代码很好的原因之一。如果 AI 设置了类似 app.UseCors(allowAll) 的内容或选择了旧的加密算法，你应该发现并纠正它。

错误处理泄露敏感信息

AI 生成的错误处理可能会打印或返回堆栈跟踪。例如，Node.js API 可能会捕获错误并执行 res.send(err.toString())，这可能会泄露内部详细信息。确保向用户发送的错误消息经过清理，并正确处理日志。根据需要进行调整，以避免向攻击者提供完整错误消息或文件路径等线索。

依赖项管理和更新

如果AI向你的项目中添加了依赖项（如库），请确保它们是最新的且来自可靠来源。AI可能会选择一个在其训练数据中很流行的库，但该库可能已不再维护或存在已知漏洞。例如，如果它建议使用某个包的旧版本，你应该将其升级到最新的稳定版本。在生成代码后运行 npm audit 或类似命令也是明智的做法。或者询问AI：

这个库是否仍在维护且安全？

它可能不完全知道，但可以告诉你是否存在已知的弃用情况。

2023年一项针对GitHub Copilot在真实项目中的大规模分析显示，根据不同编程语言，高达25%–33%的生成代码包含潜在的安全弱点，包括高严重性的CWE（Common Weakness Enumeration，通用弱点枚举），如命令注入、代码注入和跨站脚本攻击。这些发现强调了Copilot反映了其训练数据中存在的不安全模式，而不是故意产生有缺陷的代码。一致的建议是什么？开发人员必须保持警惕：手动审查AI生成的代码，使用具有安全意识的工具，并保持严格的代码规范。特别是在”氛围编程”(vibe coding)期间，AI生成内容的速度和范围要求更高的警惕性。更短时间内生成更多代码意味着需要审计的攻击面更大。

让我们看一个简短的例子。

不当的身份验证和授权

想象一下，你要求AI在Express应用中创建一个登录路由。它可能会生成如下代码：

// 不安全的示例
app.post('/login', async (req, res) => {
  const { username, password } = req.body;
  const user = await Users.findOne({ username: username });
  if (!user) return res.status(401).send("No such user");
  if (user.password === password) { // 明文密码比较
    res.send("Login successful!");
  } else {
    res.status(401).send("Incorrect password");
  }
});

这里存在哪些问题？

它直接比较密码，这意味着密码以明文形式存储在数据库中——这是一个大忌。
它发送非常通用的响应，这可能适合安全性要求，但也可能无意中暴露敏感信息。

将身份验证错误消息视为一个关键示例。一个适当安全的系统应该在登录失败时返回一个通用消息，如”凭据无效”(Invalid credentials)，无论是用户名还是密码不正确。然而，AI生成的代码可能会产生更具体的错误，如”用户名未找到”(Username not found)或”该用户密码不正确”(Incorrect password for this user)。

这些具体的消息会造成安全漏洞，因为它们向潜在攻击者确认了他们掌握的哪部分信息是正确的。如果攻击者收到”密码不正确”作为错误消息，他们现在知道他们已经发现了系统中的一个有效用户名。这使他们能够通过重复尝试建立合法用户名列表，然后集中精力破解这些已确认账户的密码。这种技术被称为用户枚举(user enumeration)，它将猜测游戏转变为更有针对性的攻击。AI倾向于提供有用、具体的错误消息，除非你明确指示它为安全敏感操作保持适当的模糊响应，否则会无意中帮助恶意行为者。

虽然代码中没有显示，但这里也没有包含速率限制或其他保护措施。

一个安全的实现应该包含几个关键保障措施：

首先也是最重要的，密码绝不应以明文形式存储。相反，系统应该存储经过加密哈希的密码，并使用安全的比较函数来验证登录尝试。
这个比较过程必须采用恒定时间算法来防止时序攻击(timing attacks)，攻击者通过分析响应时间来推断密码正确性的信息。许多注重安全的库专门提供这些恒定时间比较函数来解决此漏洞。

此外，认证系统应该实施速率限制或节流机制（throttling mechanisms），以防止暴力破解攻击。失败的登录尝试应该被记录用于安全监控，让管理员能够检测和响应可疑模式。这些措施协同工作，创建一个纵深防御方法，即使某一层安全被攻破，也能保护用户凭证。

你可以要求 AI 帮助修复这个问题：

改进登录路由，使用 bcrypt 对密码进行哈希和比较，并确保数据库中的密码已被哈希。

它可能会输出：

const bcrypt = require('bcrypt');

app.post('/login', async (req, res) => {
  const { username, password } = req.body;
  const user = await Users.findOne({ username });
  if (!user) {
    return res.status(401).send("Invalid credentials");
  }
  const match = await bcrypt.compare(password, user.passwordHash);
  if (!match) {
    return res.status(401).send("Invalid credentials");
  }
  res.send("Login successful!");
});

这样更好：它使用 bcrypt 与哈希密码进行比较（假设变量 user.passwordHash 存储了该密码）。在创建用户时，你还需要确保使用 bcrypt.hash 对他们的密码进行哈希。

在稍加指导下，AI 可以做正确的事情，但它最初的简单输出很可能是不安全的。这强调了一个模式：审查和优化。

包管理问题

另一个常见的漏洞类别是包管理。AI 有时会虚构一个库或记错名称，这个问题被称为包幻觉（package hallucination）。这样的包可能不存在，但理论上攻击者可以用常见的幻觉包名发布包含恶意代码的软件包。如果你在没有确认包既存在又正确的情况下安装这样的包，可能会带来严重的风险。如果你不确定某个特定的包，可以尝试快速的网络搜索或直接检查 npm/PyPI。

此外，AI 可能会无意中生成与训练数据中的授权代码片段完全相同的代码。这更多是知识产权问题而非安全问题，但值得仔细关注。例如，GitHub Copilot 包含一个重复检测功能，可以标记生成的代码何时与公共仓库非常匹配，帮助开发人员避免潜在的许可冲突。类似的工具正在出现，以解决 AI 生成代码来源的这一特定挑战。第 9 章将更详细地探讨许可和知识产权考虑事项，为应对这些复杂问题提供全面指导。

总之，主要信息保持不变——是的，我意识到我在整本书中强调这一点，以至于你可能在睡梦中都能背诵它——那就是 AI 输出需要与你审查初级开发人员代码相同的仔细审查。重复是有意的，因为这个原则几乎支撑着安全有效的 AI 辅助开发的各个方面。无论你是在原型设计、构建后端还是实现安全功能，这种思维模型都提供了正确的信任和验证平衡，使 AI 成为强大的盟友而非风险捷径。它可以快速编写大量代码，但你需要向其灌输安全最佳实践并仔细检查漏洞。小说家弗兰克·赫伯特在《沙丘神帝》（Putnam, 1981）中经常被引用的一句话这样说：“它们增加了我们不经思考就能做的事情的数量。我们不经思考做的事情——那才是真正的危险。”

使用 AI 可能会让你对常规代码的思考变少，你应该有意识地思考如何应用安全审查的思维模式。这对于捕捉那些”我们不经思考就能做的事情”至关重要。

安全审计

鉴于上述漏洞类型，我们如何有效地审计和保护 AI 生成的代码？本节将介绍你可以使用的几种技术和工具。

利用自动化安全扫描器

静态分析工具(SAST)可以扫描您的代码以查找已知的漏洞模式，例如：

ESLint + 安全插件可以检测JavaScript和Node代码中的不安全函数或未经清理的输入。
Bandit Python工具可以标记生产环境中assert的使用、弱加密、硬编码的密钥等问题。
GitHub CodeQL允许您在代码库中运行查询，以查找SQL注入、XSS和其他常见模式。
Semgrep为许多语言提供规则，包括社区维护的JavaScript、Python、Java、Go等规则，可以立即发现主要问题。

您可以将这些工具集成到CI/CD或开发流水线中。在AI生成的代码上运行它们——虽然无法捕获所有问题，但可能会标记出明显的错误（例如，明文密码检查、未清理的SQL、不安全的加密）。这是一个可靠的安全网。

使用独立的AI作为审查者

两种不同的方法可以利用AI对生成的代码进行安全审查，每种方法都有独特的优势。第一种方法涉及使用生成代码的同一AI模型，要求它切换视角并审计自己的输出。生成代码后，您可以使用如下提示词：

审查此代码的安全漏洞并解释您发现的任何问题。

这种方法通常会产生令人惊讶的有效结果，因为模型可以识别常见的安全问题，例如明文密码存储、缺少输入验证或潜在的SQL注入漏洞。

第二种方法使用不同的AI模型作为独立审查者。例如，如果您使用ChatGPT生成代码，您可能会将该代码粘贴到Claude或Gemini中进行安全分析。这种跨模型审查可以提供不同的视角，并捕获原始模型可能忽略的问题，就像不同的安全工具或人工审查者带来不同的专业知识和关注领域一样。不同的模型可能使用不同的重点或数据集进行训练，可能会捕获不同类别的漏洞。

这两种技术都可以作为有价值的额外安全审查层，补充但永远不会取代适当的安全测试和人类专业知识。虽然AI审查者偶尔会标记误报或遗漏细微的漏洞，但它们擅长快速捕获常见的安全反模式(antipattern)。将此过程视为专门针对安全考虑的自动化结对编程。关键在于将这些AI生成的安全审查视为安全评估过程的另一个输入，而不是作为最终的安全许可。

使用安全检查清单执行人工代码审查

如果您在团队中工作，请使用检查清单来审查代码的安全性。AI通常会生成在预期情况下”有效”的代码，但未经加固以处理恶意情况。对于AI生成的代码，请务必考虑：

认证流程(Authentication flow)：是否可靠？
数据进入系统的任何位置：我们是否在验证输入？
数据离开系统的任何位置：我们是否在清理输出？我们是否在保护敏感数据？
外部API的使用：我们是否在处理失败？我们是否暴露了密钥？
数据库访问：我们是否安全地使用ORM？我们是否使用参数化查询？
低级代码中的内存管理：如果AI正在编写C/C++或Rust，是否存在溢出？是否存在任何误用？

渗透测试和模糊测试

使用动态方法。对于模糊测试(fuzz testing)，向你的函数或端点输入随机或特制的输入，看看它们是否会崩溃或出现异常行为。AI可以帮助生成模糊测试用例，或者你可以使用现有的模糊测试工具，例如Google的OSS Fuzz。

针对AI生成的Web应用运行渗透测试(penetration testing)工具，如OWASP的ZAP，可以自动扫描XSS和SQL注入等漏洞。例如，ZAP可能会尝试注入脚本并使其被反射，从而检测到某个输入未被清理。

如果你正在构建API，可以使用Postman等工具或自定义脚本尝试发送格式错误的数据，观察系统的行为：它是抛出500错误还是优雅地处理错误？

添加安全聚焦的单元测试

对于关键代码片段，编写断言安全属性的测试。例如，你可以测试登录速率限制器在X次错误尝试后是否触发，或者某些输入（如"<script>alert(1)</script>"）在响应中是否被转义。要测试未授权用户无法访问受保护资源，可以模拟授权和未授权调用，并确保应用程序行为正确。

你可以要求AI帮助生成这些测试：

编写测试以确保未授权用户在访问/deleteUser端点时收到403响应。

然后运行测试。

提供更新以弥补训练截止日期

AI模型存在一个直接影响安全性的基本限制：它们的知识在特定时间点冻结。当模型完成训练时，它无法了解之后发现的漏洞、随后发布的安全补丁或新出现的最佳实践。这种知识截止(knowledge cutoff)在AI所知与当前安全标准之间造成了关键差距。

考虑一个在2023年训练的模型在2025年生成代码。在这些间隔年份中，已经发现、修补和记录了大量安全漏洞。新的攻击向量已经出现，框架已经添加了安全功能，最佳实践也在不断演进。然而，除非你在提示中明确提供更新信息，否则AI仍然不知道这些发展。

这种限制在快速演进的安全标准和漏洞数据库中变得尤为严重。例如，OWASP Top 10会定期更新以反映不断变化的威胁形势。如果你提示AI”编写一个安全的文件上传函数”，它可能会基于其训练数据实现合理的保护措施——可能包括文件类型验证、大小限制和Web根目录外的存储。然而，它可能会遗漏最近发现的攻击向量或未能实现新推荐的缓解措施。

解决方案是主动用当前安全信息补充AI的知识。在请求安全敏感代码时，在提示中包含当前最佳实践的引用。例如，与其简单地要求安全代码，不如这样提示：

编写一个文件上传函数，解决2025 OWASP Top 10中的安全问题，特别关注注入攻击和服务器端请求伪造。

这种方法使AI的响应基于当前安全标准，而不是可能过时的训练数据。

同样，特定框架的安全功能通常在AI的训练截止日期之后出现。例如，Express.js应用程序从Helmet中间件设置安全头中受益匪浅。在Helmet成为标准实践之前训练的AI可能会生成不包含这一关键安全层的Express应用程序。通过在提示中明确提及当前的安全工具和实践，你可以帮助AI生成符合当代安全标准而非历史标准的代码。

优化日志记录实践

确保代码（AI 和人工编写的）具有良好的日志记录，特别是在关键操作或潜在故障点周围。这有助于在生产环境中调试问题。如果 AI 编写的部分日志记录很少，请考虑添加更多。例如，如果有一个 AI 生成的 catch 块只是吞掉了错误，将其修改为记录错误（可能还包括一些上下文信息）以便查看。此外，清理日志以确保它们不包含敏感信息。

使用具有安全重点的更新模型或工具

一些 AI 编码工具旨在将代码生成与内置安全扫描相结合。Snyk 是一个典型例子：它使用混合方法，结合 LLM 生成的建议和基于规则的污点分析(taint analysis)。根据 Snyk 的说法，当您请求代码时（即使来自 OpenAI、Anthropic 或 Hugging Face 等 LLM 库），Snyk Code 会跟踪潜在的不安全数据流，并在不受信任的输入到达敏感接收点之前标记它们。实际上，这意味着如果 AI 建议一个数据库查询，Snyk 会确保它是参数化的，从而防止 SQL 注入——即使您自己忘记这样做。这类工具特别有用，因为它致力于避免通过 AI 生成的建议引入不安全的代码。

关注上下文中的警告

如果您使用的是 IDE，通常会看到警告或波浪线来突出显示可疑代码。具有 IntelliSense 功能的现代 IDE 有时可以捕获，例如，看起来可疑的 SQL 字符串拼接。不要仅仅因为是 AI 编写的就忽略这些警告和标记——要解决这个问题。AI 在生成代码时并没有这些实时警告的帮助。

放慢速度

在使用 AI 快速生成大量代码后，当需要审计时切换思路并放慢速度。当您可以快速生成功能时，很容易想要追逐下一个功能，但要安排时间进行彻底审查。可以将其视为”AI 加速开发，人工加速安全”。Snyk 的最佳实践建议直接在 IDE 中扫描 AI 代码，并警告不要让 AI 的速度超过您的安全检查。换句话说，将安全扫描集成到您的开发循环中，这样您就可以在代码编写后立即捕获漏洞。

总之，当您审计 AI 生成的代码时，您将使用许多在传统开发中使用的相同工具——静态分析、动态测试、代码审查——但您可能会更频繁地应用它们，因为代码生成得更快。将每个 AI 输出都视为需要检查的内容。

为 AI 生成系统构建有效的测试框架

虽然安全性构成可靠性的一个支柱，但更广泛的概念涵盖了软件系统的基本可靠性。可靠性，在软件架构术语中，解决了关于系统故障及其后果的关键问题。您的系统需要故障安全吗？它在可能影响人类生命或安全的方面是否至关重要？如果系统故障，是否会给您的组织造成重大财务损失？这些考虑因素决定了开发和测试实践所需的严格程度。

在使用 AI 辅助构建软件时，这些可靠性要求保持不变。使用 AI 辅助生成的银行应用程序，在交易准确性和数据完整性方面的要求与完全由人类编写的应用程序相同。医疗保健系统必须满足相同的患者安全标准，无论其代码如何产生。AI 参与代码生成并不会降低这些基本的可靠性要求。

这一现实强调了为什么全面测试在 AI 辅助开发中变得更加关键。强大的测试框架可以确保您的代码正确执行预期功能，并在项目演进过程中保持这种正确性。虽然测试 AI 生成的代码遵循与测试人工编写代码相同的基本原则，但 AI 开发过程中会出现某些值得特别关注的细微差别和机会。

以下部分探讨如何利用 AI 不仅生成代码，还创建强大的测试套件来验证可靠性、维护系统稳定性，并提供信心确保您的软件在关键时刻能够正确运行。

首先，尽早并经常采用自动化测试。当开发缓慢时，很容易跳过编写测试，因为您想要推进功能。讽刺的是，当开发速度很快时（使用 AI），同样很容易跳过测试，因为新功能不断涌现。但是当代码快速生成时，这正是您最需要测试来捕获回归或集成问题的时候。因此，在 AI 帮助实现功能后，养成立即为其编写测试的习惯（甚至使用 AI 编写这些测试）。这既验证了功能，也在您稍后更改时保护它。

2022 年的一项研究发现，使用 AI 助手的开发人员对他们编写的代码的安全性更有信心，即使客观上它不如那些没有 AI 辅助的开发人员编写的代码安全。您需要用实际测试来抵消这种过度自信。

正如我在第 4 章中提到的，您可以使用 AI 不仅生成代码，还生成一套测试。这样，AI 可以帮助检查自己。就像让它同时进行实现和初步验证。例如，在编写新模块后，您可以询问：

为此模块编写单元测试，覆盖边缘情况。

如果它们通过了，很好。如果失败了，要么有错误，要么测试期望的是其他内容。根据情况调查并修复代码或测试。

要注意 AI 可能会错误地假设某些输出或行为；像对待代码一样，将其测试视为建议，而不是绝对真理。您可能需要调整测试的期望以匹配预期行为——但即使是这个过程也是有价值的，因为它迫使您清楚地定义预期行为。

将您的测试套件整合到 CI 管道中，在每次提交时运行。这样，每当添加或更改 AI 生成的代码时，所有测试都会自动运行。如果出现问题，您将及早发现。有时 AI 可能会引入细微的破坏性变更（例如稍微更改函数签名或输出格式），强大的测试套件会检测到这一点。在 CI 中也包括安全扫描（如 npm audit 或静态分析），以便标记任何新引入的风险模式。可以尝试的测试类型包括：

基于属性的测试和模糊测试

基于属性的测试（使用 Python 的 Hypothesis 或 JavaScript 的 fast-check 等工具）是另一种有价值的技术。与编写具有特定输入和预期输出的单个测试用例不同，您定义代码应始终满足的高级属性。然后框架生成各种输入来检查这些属性是否成立。

以排序为例。与其断言 sort([3, 1, 2]) === [1, 2, 3]，您可以定义属性：

输出应该是有序的
它应该包含与输入相同的元素

然后工具生成数十或数百个输入数组来测试这些条件——并找到您可能手动想不到的边缘情况。

这对于 AI 生成的代码特别有用。如果您的 AI 编写了一个规范化电子邮件地址的函数（例如通过将域名小写），属性测试可能会检查输出是否是幂等的——这意味着运行函数两次与运行一次的结果相同。如果边缘情况违反了该不变量，测试框架将生成一个反例来帮助您诊断错误。

负载和性能测试

AI 可能编写未优化的代码。在负载下测试您的系统是个好主意。这是性能方面的可靠性。使用 JMeter、Locust 或 k6 等工具模拟大量请求或大量数据，看看系统是否能够支撑。如果不能，识别瓶颈。

性能测试

例如，AI可能会写一个简单的O(n^2)算法，在100个项目上运行良好，但在10,000个项目时会崩溃。如果没有性能测试，你可能直到生产环境才会注意到这一点。因此，如果适用，请纳入一些性能场景。对关键操作使用不断增加的输入规模进行计时，或使用性能分析工具查看CPU时间或内存在繁重任务中的消耗情况。

错误处理

故意制造错误以确保系统能够优雅地响应，例如：

对于API，关闭数据库并查看API是返回友好的错误还是崩溃。如果崩溃，添加代码（或要求AI添加代码）来处理数据库连接错误。
对于前端，模拟后端返回500错误并确保UI显示错误消息，而不是空白页面或无限旋转图标。

AI在编写代码时可能不会自行考虑这些故障模式，因此你必须测试它们然后进行优化。测试这些场景将通过促使你添加适当的回退逻辑、重试机制或用户反馈来提高可靠性。

监控和日志: 纳入日志记录，并可能在测试中使用日志进行验证。例如，如果某个操作应该触发审计日志条目，请对此进行测试。AI可以生成日志行；验证它们是否按预期输出。; 此外，考虑设置监控（如模拟服务在生产环境中将如何被监控的内存模拟）。例如，你可以跟踪测试运行期间是否记录了任何未捕获的异常。如果有，将其视为测试失败；这意味着存在某些未正确处理的情况。
可维护性: 可维护性测试，如确保代码风格和标准，是很重要的。使用代码检查工具(linters)和格式化工具(formatters)来保持代码一致性，因为AI可能会从不同的提示中产生略有不同的风格。格式化工具如Prettier或Black（用于Python）可以统一风格。为了获得更多的逻辑一致性并捕获可能需要重构的过于复杂的AI生成代码，考虑添加强制执行诸如函数复杂度限制等规则的代码检查规则。（有关更多信息，请参见[“确保AI加速代码库的可维护性”]。）

一旦你的测试就位，你就可以更自信地重构AI代码。也许AI产生了一个可行但笨拙的解决方案；你可以改进它并依靠测试来确保你没有破坏其行为。你甚至可以要求AI重构其自己的代码：

在保持通过当前测试的同时，为了清晰起见重构这个函数。

如果你的测试很好，你可以检查重构是否没有破坏任何东西。

理解AI系统中的非确定性(nondeterminism)需要区分两种根本不同的场景。当AI在生产系统的运行时运行时，例如聊天机器人响应客户查询或推荐引擎个性化内容时，即使输入相同，输出也可能不同。这种可变性源于模型温度设置、随机种子或不断演化的模型状态等因素。测试此类系统需要专门的方法来考虑可接受的变化范围，而不是期望精确匹配。

然而，AI辅助代码生成呈现了一个完全不同的范式。一旦AI生成代码并且该代码被提交到你的仓库，它就会像任何人工编写的代码一样具有确定性。计算税率的函数将在每次相同输入时产生相同的输出，无论最初是人类还是AI编写的。这种确定性对系统可靠性至关重要，并使传统的测试方法完全适用于AI生成的代码。

当集成多个AI生成的组件时，会出现更微妙的挑战。考虑一个来自电商系统的具体例子。你可能会提示AI生成一个订单处理模块，指示它处理国际订单。另外，你要求AI为同一系统创建一个运费计算服务。订单处理模块遵循美国惯例，将日期格式化为”12/25/2024”表示12月25日。与此同时，运费服务可能受到其生成过程中欧洲示例的影响，期望日期格式为”25/12/2024”。这两个组件在独立运行时都完美工作，通过了各自的单元测试。

不匹配只在集成测试期间才显露出来，当订单处理器将日期传递给运费计算器时。运费服务将”12/01/2024”解释为1月12日而不是12月1日，可能会基于完全错误的月份来计算运输时间。这种假设不匹配在AI生成的组件中特别常见，因为AI在独立生成每个部分时可能会借鉴不同的示例或约定。全面的集成测试能够检验组件之间的实际数据流，这对于在生产故障之前捕获这些微妙的不兼容性至关重要。

AI辅助项目的QA(质量保证)过程可能需要更多创造性，因为AI可能引入不寻常的边缘情况(edge cases)。例如，AI可能输出一个你没有明确考虑的功能—如果是这样，也要测试它。如果它添加了隐藏行为，要么删除它，要么正确地测试它。

最后，如果可能的话，在类似于生产环境的环境中测试你的应用程序，使用真实的数据负载。有时性能问题只会在更大的数据量或更高的并发情况下出现。使用这些测试结果来精确定位低效率之处。

性能优化

虽然AI经常编写正确的代码，但它可能不总是编写最优的代码。LLMs(大语言模型)本身不会进行性能分析；它们通常复现训练数据中常见的内容。因此，要对潜在的性能问题保持警惕，特别是在关键路径或大规模使用中。

你甚至可以与AI聊天以获得关于性能优化的提示：

这段代码的复杂度是多少？可以改进吗？
这个函数很慢—有什么加快速度的想法吗？

它可能不总是正确的，但有时可以给出有用的建议，或者至少确认你的想法。

话虽如此，不要过度优化，也不要过早优化或在不需要的地方优化。有时AI解决方案是完全可以的，如果数据量很小或操作不频繁的话。使用你的性能分析(profiling)数据来关注真正的瓶颈，优化真正需要优化的部分。氛围编码(vibe coding)的优势在于，你没有花费大量时间从头手工编写代码，所以你可以让一些非关键部分保持简单且不超级优化，只要它们不影响用户体验或成本。这种方法与敏捷实践一致：先让它工作，然后让它快速(如果需要的话)。

以下是一些在确保AI增强项目高效运行时需要覆盖的领域：

复杂度分析

当AI生成算法时，花点时间考虑它的复杂度。有时它会在存在更高效算法的情况下使用暴力解决方案。例如，它可能会对列表进行双重排序，因为它没有想起单步方法，导致O(n log n × 2)而O(n log n)就可以(大写字母O代表内存使用)。或者它可能使用嵌套循环，使操作变成O(n²)，而存在已知的O(n)方法。如果你发现这样的情况，要求改进：

我们能优化这个以避免嵌套循环吗？也许使用集合进行查找。

如果你提示方法，AI通常会给出更好的解决方案。如果没有，你可能需要手动实现那部分。

要识别慢速函数，运行性能分析器(profiler)或使用代表性或最坏情况数据测量关键代码路径的执行时间。如果某些东西太慢，你可以尝试手动优化或在AI协助下优化：

优化这个函数，它目前是一个瓶颈；尝试降低其复杂度。

AI 可能会重构代码以提升性能。使用测试来确保代码仍然正常工作。

对于关键算法，编写一个小型基准测试工具。如果 AI 给你一段代码来计算某些内容，请将其与另一种方法进行测试对比，或至少测量它如何随输入大小扩展。如果需要，你可以决定用更高效的方式重写。

内存使用、泄漏和保留

AI 生成的解决方案可能使用超过必要的内存：例如将整个文件读入内存而不是流式处理，从而持有大型数据结构。如果你的用例涉及大数据，请检查系统的内存使用情况，并在需要时通过流式处理或分块来优化。例如，如果你需要处理数百万条记录，你会想要重构 AI 生成的函数 loadAllRecords() 来分批处理或从数据库流式处理。

还要检查 AI 生成的代码是否释放了资源。在 Java 或 C# 等语言中，可能打开了文件或数据库连接但没有关闭。在前端单页应用中，可能事件监听器没有被移除，导致泄漏。工具可以提供帮助(如前端的 Chrome 开发工具的内存检查器或 C++ 泄漏检测的 Valgrind)，但通常只需阅读代码就有帮助。识别这些问题并修复它们。如果你看到打开的文件句柄没有关闭，在 finally 块中添加关闭操作。

并发与并行

如果你使用支持线程或异步的语言，寻找 AI 代码可能是单线程但可以并行的地方。AI 可能不会在适当的地方自动使用 async/await，也可能不知道将繁重的 CPU 任务卸载到工作线程。识别这些机会。例如，对于 Node 或 Python 中的 I/O 密集型任务，确保异步使用以便系统不会阻塞。对于 CPU 密集型任务，AI 在代码方面可能帮助不大，但你可能决定用性能更高的语言实现或卸载到后台作业。

缓存

AI 并不总是自动添加的一个常见性能优化是缓存昂贵操作的结果。查看你的代码：它是否重复计算某些内容？如果是，实现缓存(内存中或使用像 Redis 这样的外部缓存)。你可以提示 AI：

为此函数添加缓存以避免冗余计算。

它可能实现简单的记忆化或建议使用缓存库。

数据库查询优化

如果你的应用程序使用数据库，检查 AI 创建的查询。它们是否正确使用了索引？也许 AI 写了 SELECT * 而只需要几列。或者它获取大量数据在代码中过滤，造成性能瓶颈，如 N + 1 查询问题。这些低效需要通过将更多工作推送到数据库或利用适当的索引来优化。

例如，如果生成的代码在循环中重复调用 findOne，导致多次数据库往返，你可以将其重构为使用 WHERE id IN (...) 的单个批量查询。同样，如果 AI 在迁移中省略了对频繁查询字段的索引创建，添加这些索引对于维持可接受的性能变得至关重要。AI 通常生成功能正确但次优的数据库交互，需要人类专业知识来识别和解决。

举例说明，让我们看一个例子。假设 AI 为你编写了一个函数来合并两个排序数组，只是简单地连接并排序结果：(O(n log n))—尽管有一个已知的线性算法可以用来合并两个排序列表(如归并排序的合并步骤，O(n))。在代码审查中，你意识到这对于大数组可能是瓶颈，所以你提示 AI 实现线性合并：

优化 mergeSortedArrays 函数以在线性时间内执行合并，不使用内置排序。

AI 识别出这是经典的归并算法并编写它。解决方案通过了你的测试，所以恭喜：你在不牺牲正确性的情况下获得了性能提升。

AI 辅助开发并没有消除性能调优的需求；它只是改变了你进行调优的时机。你通常会首先获得正确的解决方案(这非常有价值)，然后将注意力转向测量和优化目标部分。当你确实需要优化某些东西时，AI 可以提供帮助，只要你引导它了解你的需求。

确保 AI 加速代码库的可维护性

代码库的可维护性描述了随着时间推移，修改、扩展和理解代码的难易程度。一些人担心AI生成的代码可能会混乱或不一致,特别是当多个建议具有不同的风格或模式时。本节介绍了几种实践方法,可以用来解决这些问题,并保持你的vibe-coded项目的整洁性和可维护性。

在提示时

当你准备提示词时,需要记住以下几点:

使用一致的编码标准

使用linters和formatters来强制执行一致的风格。如前所述,AI有时可能在不同的输出中使用不同的命名约定或格式。在代码生成后对所有代码运行formatter(如JS的Prettier、Python的Black、Go的gofmt等)可以确保代码符合统一的风格。这使得阅读代码变得更容易(无需在切换风格时产生认知负担)。此外,为你的项目定义命名约定并坚持使用它们。如果AI在一个地方输出get_user_data,在另一个地方输出fetchUserData,那么请决定你更喜欢哪种约定(snake_case还是camelCase等),并重构为一种风格。

使用架构模式来鼓励模块化并避免蔓延

通过提示AI编写模块化代码来鼓励关注点分离。例如,与其要求它编写一个实现所有功能的巨大文件,不如将工作分解为多个任务:

创建一个UserService类来处理用户逻辑。
创建一个单独的模块来发送电子邮件。

这会产生一个逻辑上分离的代码库。当每个模块都有明确的职责时,维护起来会更容易。你可以引导架构:

将数据库访问代码放在与API路由代码分离的文件或类中。

因为使用AI添加功能非常容易,所以防止功能蔓延(feature creep)和代码膨胀至关重要。如果没有严格的架构思维,你的代码库可能会退化为软件架构师所说的大泥球:这是一种反模式(antipattern),代码缺乏清晰的结构或边界。这种风险在AI辅助下会加剧,因为传统上与添加功能相关的阻力消失了,可能会加速架构的衰退。

为了应对这一点,将你的AI辅助开发建立在经过验证的架构模式和原则之上。在指导AI时,明确引用你的项目遵循的模式:

按照项目中使用的repository/service模式添加这个新功能。
使用我们领域层中建立的六边形架构(hexagonal architecture)来实现这个功能。

这种具体性有助于在功能快速积累时保持一致性。

对于寻求更深入架构基础的开发人员,几本基础文献提供了重要指导:

Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides(“四人帮”)的Design Patterns: Elements of Reusable Object-Oriented Software(Addison-Wesley, 1994)仍然是可重用设计解决方案的权威目录。
Mark Richards和Neal Ford的Fundamentals of Software Architecture: An Engineering Approach全面涵盖了跨技术栈的架构模式和原则。
Eric Evans的Domain-Driven Design: Tackling Complexity in the Heart of Software(Addison-Wesley, 2003)提供了将软件设计与业务领域对齐的关键技术—当AI生成必须反映复杂业务逻辑的代码时尤其有价值。

这些资源使你能够有效地引导AI工具,确保生成的代码遵循合理的架构原则,而不是增加技术债务。请记住:AI擅长实现模式,但无法确定哪些模式适合你的特定场景。这种架构判断从根本上仍然是人类的工作。

处理代码输出

一旦AI响应并生成代码,可以使用以下可维护性技术:

持续重构

不要犹豫在需要时重构AI生成的代码

不要犹豫在需要时重构AI生成的代码。有时第一次生成是正确的,但结构并不理想:例如,AI可能会写一个非常长的函数,或在两个地方重复其逻辑。一个常见的挑战是无意中重复的代码:AI可能没有意识到两个函数做类似的事情而创建了两者。如果你注意到类似的代码块,重构为一个。像代码检查器(linter)这样的工具可以检测重复(有专门用于检测过于相似代码的检查器)。运行这些工具可以突出显示需要”DRY化”(不要重复自己)的地方。

要让AI帮助重构,你可以这样提示:

重构这段代码以消除重复并提高清晰度。

它可能会创建辅助函数或简化某些逻辑。重构后始终要测试。

测试

本章已经介绍了测试,所以我只想指出,良好的测试套件使维护更容易。当你或其他人将来修改代码时(可能再次使用AI),你的测试将捕获更改是否破坏了任何东西,这样你就可以放心地重构或更改实现。测试将”它做什么”与”它如何做”解耦,使你能够灵活地维护或改进”如何做”而不改变”做什么”。

避免过度复杂或过度依赖AI特定的构造

有时AI可能会使用一个巧妙的技巧或其他开发者可能不知道的不太常见的函数。虽然这本身并不坏,但要考虑可维护性:如果普通开发者会对代码感到困惑,也许应该简化它。例如,如果AI使用了一些正则表达式魔法或过于简洁的列表推导式,将其重写为更明确的循环以提高清晰度(或至少添加注释)。

同样,试图提供帮助的AI可能会过度设计解决方案,比如添加不需要的层次。例如,也许直接的方法就可以,但AI引入了一个没有发挥作用的抽象。删除它以保持简单明了。更简单的代码通常更容易维护。

构建弹性和回退机制

考虑失败情况下的回退策略(fallback)。例如,如果AI编写的组件调用外部API,而该API宕机或返回意外数据,我们是否有回退机制(比如使用缓存数据或默认响应)?实现这样的弹性模式(断路器、带退避的重试等)可以使系统更加健壮。除非被要求,否则AI可能不会自己做这些。确保系统能够优雅地处理部分失败。如果可能的话,一个微服务的宕机不应该导致整个应用程序崩溃。使用超时和回退逻辑。

后续工作

一旦你对代码满意,还有一些实践可以帮助保持其可维护性:

提供全面的文档和注释

确保代码得到适当的文档化。除非被提示,否则AI通常只写最少的注释。你可以通过提示请求文档字符串或注释:

添加注释来解释此代码中每个部分的目的。
为此函数编写文档字符串。

这些可以节省未来读者的时间。AI通常可以生成相当好的解释,但有时会误解微妙的要点,所以要检查准确性。

还要考虑为项目维护高级文档(如README或设计文档),描述其架构、主要组件等。你可以主要自己编写,但如果需要,AI可以通过总结代码库来提供帮助。

如果你遇到一些怪癖,比如”AI总是奇怪地命名这个参数”,在你的开发笔记中为其他人提及它。这是新协作环境的一部分。如果只有你使用AI生成的代码,一些怪癖是可以的——但如果其他人加入项目,他们可能会想,“为什么这个东西这样命名?”也许只是标准化这些名称。

在可维护性方面,还有一个方面是知道哪些代码是AI生成的,哪些是人工编写的。严格来说不需要标记,但一些团队可能会注释,“在2025-05-01使用GPT-4的帮助生成”,以便追溯。理想情况下,在你的PR描述中标记任何你不确定的内容:“使用ChatGPT帮助编写此函数;它似乎可以工作,但请仔细检查错误处理逻辑。”: 这不是一种普遍的做法。它在代码审查(code review)期间可能有帮助，但如果人类已经审查过代码，现在它只是代码，你可能不需要它。如果你确实保留了任何记录或提示词(prompt)，可以在复杂代码的注释中链接它们：“此算法基于提示词X通过GPT-4派生；推导过程见文档。”审查者不需要在审查强度方面区别对待(你应该仔细审查所有代码),但这可以帮助理解上下文。例如,如果代码有某种风格不匹配或奇怪的习惯用法,知道它来自AI可能会提示审查者这不是刻意的作者选择,而是AI的产物。
代码审查和团队规范: 如果你在团队中工作,让所有团队成员审查代码—即使是一个人和AI共同编写的。他们可能会发现不合适的模式或违反团队规范的东西。随着时间的推移,你会逐渐掌握如何提示AI以匹配你团队的风格(可能在系统提示词(system prompt)或初始指南中包含具体要求)。如果多个开发者使用AI,确保每个人都知道期望的风格模式,以便他们可以相应地提示(如”用函数式风格编写”或”使用async/await,不要用回调”)。有关AI代码审查的一些技巧,请参见下一节。
跟踪技术债务: 如果在开发过程中,你接受了一个你知道不理想的AI解决方案,请在注释或项目待办事项中将其作为技术债务(technical debt)进行跟踪:“TODO:该解决方案有效但是O(n²);如果数据增长,需要优化”,或”TODO:为简单起见使用了全局变量;稍后改进此处。“如果你要求,AI甚至可以自己插入TODO注释:; 如果有任何需要未来改进的地方,请添加待办注释。; 只要最终解决这些待办事项即可。
从AI模式中学习: 如果AI引入了你不熟悉的设计模式或库,花时间深入了解它,而不是忽略它。理解特定的缓存方法或它使用的库将帮助你在未来自信地维护或修改该部分。如果太过晦涩,你可能会决定删除它,转而使用你熟悉的东西—但有时AI可以让你惊喜地发现你不知道的有用库或模式。如果这是一个你和团队可以学习的知名解决方案,这甚至可以提高可维护性。

实际上,可维护性归结为应用与以往相同的良好软件工程原则—只是将它们应用于部分由AI编写的代码。幸运的是,由于AI减少了繁重的工作,你可能有更多时间专注于清理代码和编写文档,这反而提高了可维护性。

一些公司报告在用AI生成代码的初期爆发之后,他们投入时间进行”加固冲刺(hardening sprint)“来重构和记录所有代码。考虑在生成密集型冲刺和清理冲刺之间交替作为一种潜在策略。

代码审查策略

如[第4章]所述,代码审查在传统开发中是一个关键过程,在AI辅助开发中仍然如此。本节讨论当审查的代码块是机器建议的时需要考虑的一些细微差别。因为AI可以如此快速地生成代码,担心代码审查会成为瓶颈是合理的—但不要让这种担心妨碍审查过程。为审查分配适当的时间至关重要。不要基于”我们快速编写,就快速合并”的假设而草率行事。如果可以的话,更频繁地提交较小的更改以使审查更容易(无论如何这通常是一个好做法)。频繁的、较小的拉取请求(PR)比一个巨大的PR更容易彻底审查。如果你提前规划,AI也可以帮助将任务分解为较小的PR。

不要仅仅因为”AI编写了它并且测试通过”就假设代码是正确的。批判性地思考并尝试推理逻辑。如果可能,在提供的测试之外用额外的用例进行心理测试或测试,因为测试可能无法涵盖所有情况。你还可以运行代码,甚至通过用棘手的输入运行代码片段来试验,看看它是否按预期运行。

代码审查也可以是重要的学习时刻。如果AI引入了一个实际上很好的新颖解决方案,审查者在验证其正确性的同时可能会学到新东西。同样,如果AI/人类组合做了一些次优的事情,审查者可以解释更好的方法。随着时间的推移,这个反馈循环可以改善团队使用AI的方式(比如帮助每个人了解应该避免哪些事情或以不同方式提问)。从某种意义上说,代码审查有助于闭合人类学习循环,因为人类作者应该学习和理解AI编写的任何对他们来说是新的东西。

当您审查代码时，首要任务应该是确保它满足需求和预期设计。这段代码是否实现了功能/缺陷修复应该做的事情？它是否涵盖了规范中提到的任何边界情况？如果提示词有偏差，AI 可能会解决一个稍微不同的问题：也许它处理了一个不需要的情况，或者遗漏了某个情况。这很正常，但要注意开发人员不要只是接受仅部分解决问题的 AI 输出。例如，AI 可能会生成格式化日期的代码，但假设某个特定时区，这可能与需求一致，也可能不一致。

如果代码中有不明显的地方，请要求作者解释它是如何工作的或为什么这样做。如果他们难以解释或求助于”AI 这样做的，我认为是对的”，这是一个危险信号。团队应该理解代码库中的所有内容。鼓励作者与 AI 或文档再次确认，并提供适当的解释，可能作为代码中的注释。

同时注意本章前面讨论的安全性和性能漏洞，如果违反了任何已知的最佳实践，请指出来——比如输出没有转义（在 Web 开发中）或在代码中发现凭证。

如果您看到代码可以工作但可以更简单或更符合团队风格，请要求更改或重构(refactoring)：

AI 为不同的用户角色创建了 3 个独立的函数，它们大部分是重复的。我们能否将它们合并为一个带有角色参数的函数？

然后代码作者可以这样做（可能在 AI 的帮助下）。如果 AI 建议没有使用团队的一致风格或标准库，也要提出来：

我们通常使用 requests 库进行 HTTP 调用，但这段代码使用的是 http.client。让我们坚持使用 requests 以保持一致性。

然后作者可以提示 AI 使用首选库重写。

如果 AI 编写了非常复杂的东西，比如一个棘手的算法，可以考虑与另一位审查者或团队讨论，进行更深入的审查。

您可能想尝试一些使用 AI 辅助代码审查的新兴工具——比如 GitHub’s Copilot for Pull Requests，它可以生成摘要并标记潜在的错误和其他问题。这样的工具可能会突出显示诸如”这段代码片段与模块 X 中的代码相似但略有不同”（指出可能的重复）。这些提示可以补充人工审查，但不应取代它。

最后，在审查时要尊重和建设性，即使代码由于 AI 而存在缺陷。避免因可能是 AI 产物而责备开发人员：虽然他们仍然对自己的代码负责，但要认识到上下文。AI 是一个工具，作者和审查者都在使用它。目标是改进代码和分享知识，而不是指责。例如：“这部分似乎有安全问题——可能是 AI 建议的疏忽；让我们修复它。”

最终，在氛围编码(vibe coding)中的代码审查是我们充分发挥人机合作中人类智能一方的方式。这是监督和专业知识发挥作用的地方，以捕获 AI 可能遗漏的内容并保持高质量标准。这也是团队知识共享的时刻，因为在审查中讨论代码可以传播对领域和如何最好地使用 AI 的理解。

代码审查还形式化了 Grant Gross 在 CIO 中提出的”开发人员作为编辑者”的概念：审查者是编辑者，确保代码经过润色并适合生产。这与氛围编码(vibe coding)的概念完美契合，其中氛围（AI 建议）存在，但人类判断对其进行完善。

可靠部署的最佳实践

一旦您知道代码是安全的、经过测试的和可维护的，您需要将其部署并在生产环境中保持可靠运行。

虽然 AI 辅助开发不会改变软件部署的核心原则，但它确实引入了关于部署速度和运营复杂性的考虑因素。对于那些寻求部署基础全面覆盖的人，Gene Kim、Jez Humble、Patrick Debois、John Willis 和 Nicole Forsgren 的《DevOps 手册》(The DevOps Handbook)（IT Revolution Press，2016）提供了权威指南，涵盖从持续集成(continuous integration)和部署管道(deployment pipelines)到监控(monitoring)、安全性和组织转型的所有内容。当 AI 加速您生成可部署代码的能力时，这些基础知识变得更加关键，因为这些原则确保您的部署实践能够随着您增加的开发速度而扩展。

部署之前和期间

在准备部署时，请考虑以下最佳实践：

自动化您的 CI/CD 管道(pipeline)

使用 CI/CD 流水线自动化部署

鉴于 AI 开发的快速步伐，建立一个强大的持续集成/持续部署(Continuous Integration/Continuous Deployment, CI/CD)流水线非常有价值。每次提交(无论是否包含 AI 生成的代码)都应该通过自动化流水线进行构建、测试和潜在部署。这减少了人为错误,并确保所有部署步骤(测试、代码检查、安全扫描)都能一致执行。如果 AI 代码引入了导致构建失败或测试不通过的问题,CI 会立即捕获。此外,自动化 CI/CD 流水线允许快速迭代,因此你可以修补任何 AI 引入的问题并快速部署修复。

基础设施即代码

使用基础设施即代码(Infrastructure as Code, IaC)(Terraform、CloudFormation 等)来定义你的部署环境。虽然这与 AI 编码没有直接关系,但它是可靠部署的一部分。你甚至可以使用 AI 来帮助编写 Terraform 脚本,但要像对待其他 AI 代码一样谨慎对待和测试这些脚本,包括在将其应用到生产环境之前可能需要在沙箱中测试它们。一个有价值的起点是 Yevgeniy Brikman 所著的《Terraform: Up & Running》(O’Reilly, 2022),该书全面介绍了使用 Terraform 进行 IaC 的原则和实践。

使用分阶段发布并制定回滚计划

在全面生产发布之前,使用分阶段发布策略(staged rollout strategies),如部署到预发布环境或金丝雀发布(canary release)。这样,你可以在影响所有用户之前捕获任何疏漏。例如,你可以将新的 AI 编码功能部署给 5% 的用户,并监控(通过指标和日志)是否有任何错误或性能问题。如果一切正常,再将其推广到 100% 的用户。

始终制定回滚计划。尽管进行了所有测试和审查,有时仍会有问题漏网。如果新版本出现问题,准备好回退到最后一个稳定版本。如果你使用 Kubernetes 等容器化策略,请保留以前的部署以便快速切换。如果是无服务器函数(serverless function),在确信新版本没有问题之前,保持旧版本处于活动状态。

设置可观测性

在生产环境中设置全面的监控,包括系统指标和应用程序日志:

使用 Sentry 等工具跟踪错误并捕获异常。如果 AI 代码在生产环境中抛出意外错误(可能是某个边缘情况未被覆盖),你将收到警报以便进行修复。
使用应用程序性能监控(Application Performance Monitoring, APM)等性能监控工具来跟踪响应时间、吞吐量和内存使用情况。这将显示新部署中是否有任何代码引入了速度减慢或内存泄漏。
监控可用性:例如,ping 服务端点以确认它们处于运行状态。如果某些东西崩溃了(可能是由于某些未测试的场景),应该触发警报,以便你能快速响应。

对安全保持警惕

确保在部署中正确处理 API 密钥等秘密信息。例如,如果你的 AI 编写的代码需要环境变量中的秘密信息,请在 CI/CD 或云配置中设置该秘密信息,这样它就不会被意外记录或暴露。使用秘密管理工具(secret management tools),如 HashiCorp Vault(HashiCorp Vault 提供秘密管理、密钥管理等功能,具有多种集成方式)或 AWS Secrets Manager(AWS Secrets Manager 允许你安全地存储和轮换数据库凭证、API 密钥和令牌等秘密信息,并可以与 GitHub 等 CI/CD 工具集成)。此外,如果你使用容器镜像,请扫描它们是否存在漏洞。

使用蓝绿部署或影子测试等技术进行测试

对于重大变更,考虑使用蓝绿部署(blue-green deployment)。这涉及设置两个相同的生产环境:“蓝色”(当前的实时版本)和”绿色”(新版本)。流量最初被引导到蓝色环境。一旦绿色环境准备就绪并经过测试,流量就会切换到它。如果绿色环境出现任何问题,流量可以快速重新路由回蓝色环境,从而最大限度地减少停机时间和风险。这种方法在将新版本设为唯一实时版本之前,在完整的生产环境中对其进行测试。

持续的最佳实践

部署后，这些策略可以帮助保持一切可靠运行：

创建运维手册: 为运维团队提供手册，描述代码中AI生成部分的任何特殊方面：“此服务使用AI模型执行X功能；如果模型输出看起来有误，请尝试重启服务或检查模型版本。”或者”功能Y严重依赖缓存来保证性能；如果出现性能问题，请检查缓存命中率。“本质上，记录任何可能不明显的运维注意事项。如果AI引入了依赖项（如使用临时文件），请注明，这样运维人员就知道要监控磁盘空间等。
在生产环境中测试: 除了在开发期间和作为发布的一部分进行测试之外，一些公司还会以安全的方式在生产环境中进行测试(TiP, Testing in Production)，例如持续运行小规模实验。例如，您可以使用功能标志为一小部分用户启用AI生成的功能，并观察错误率是否发生变化。这与金丝雀发布重叠，但您可以使用功能开关使其更加细粒度。
定期审计: 安排定期对代码库进行安全性和性能审计，特别是随着越来越多AI贡献的积累。这类似于管理技术债务：它帮助您捕获最初没问题但随着规模或上下文变化可能变得有问题的事情。还要注意”漂移”——如果AI代码正在生成SQL查询，请确保您的迁移和代码保持同步，并且部署在新代码接收流量之前正确运行迁移。
保持人工参与: 主题继续——人类应该监控自动化。AI可能帮助您编写代码，但它不会在凌晨2点修复生产事故。安排了解系统的人值班。随着时间的推移，您可能会让AI帮助排除故障，例如分析日志（这是一些新兴工具的功能），但归根结底，应该由人类来决定修复措施。
从失败中学习: 没有任何流程是100%完美的。如果错误突破了您的防御并导致事故，请进行事后分析。确定问题是否与AI使用有关（例如”我们在这里信任了AI代码，但它在场景X下失败了”），并更新您的流程和测试以防止该类问题。每次进行这种分析都会持续提高可靠性。

当然，可靠性不仅仅关乎代码；它还涉及代码周围的基础设施和运维。AI主要在代码方面提供帮助。强大的运维实践（可以部分由AI辅助）保持整个系统的可靠性。

智能识别和处理多级标题

从本质上讲，在部署方面，对待 AI 密集型项目应该与对待任何高质量软件项目一样:采用全面的测试、逐步推出、大量监控，并确保可以快速回滚。因为 AI 可以更快地创建变更，你最终可能会更频繁地部署(如果你的 CI/CD 流水线足够好，这是可以的)。频繁的小型部署实际上已知可以降低风险，相比不频繁的大型部署。原因在于每个单独的变更都更小，使得识别和修复出现的任何问题变得更容易。如果出现问题，回滚小型变更也更简单、更快。这种方法与大型、不频繁的发布形成对比，后者将众多变更捆绑在一起，使得难以确定任何问题的原因，并增加了部署失败的潜在影响。

通过遵循这些最佳实践，你可以确信即使大量代码是机器生成的，你的整个系统也会为用户可靠地运行。自动化测试、谨慎部署和监控的组合形成了闭环，可以捕获早期阶段遗漏的任何问题。因此，你可以获得 AI 开发的速度和生产力优势，而不必牺牲在生产环境中信任软件的能力。

总结和后续步骤

总之，氛围编码(vibe coding)并不能消除对工程严谨性的需求——它放大了应用这种严谨性的工程师的生产力。你的座右铭应该是古老的俄罗斯谚语:信任但要验证。信任 AI 处理繁重的工作，但用你的工具和专业知识验证一切。

安全性和可靠性是负责任开发的一个维度;伦理是另一个维度。AI 辅助编码引发了关于知识产权、偏见、对开发人员工作的影响等重要问题。第9章将深入探讨这些更广泛的影响。你如何负责任且公平地使用 AI 编码工具?你如何处理 AI 生成代码的许可问题，并确保你的模型和提示词(prompt)得到合乎伦理的使用?

第9章氛围编码的伦理影响

随着 AI 辅助开发变得越来越普遍，解决这种新范式的伦理和社会影响至关重要。本章从技术细节中退后一步，从伦理角度审视氛围编码:这些新的开发方法可能是有效的，但它们也需要负责任地实施，并使个人和整个社会受益。

我从知识产权(IP)的问题开始。谁拥有 AI 生成的代码，是否允许使用可能源自开源代码但未注明出处的 AI 输出?从那里，我考虑偏见和公平性。透明度是另一个关注点:开发人员是否应该披露代码库的哪些部分是 AI 生成的，团队如何确保代码质量和 bug 的问责制?

我概述了 AI 使用中负责任的开发实践，从建立透明度和问责制到避免在提示词中使用敏感数据，再到确保可访问性和包容性。本章以一套负责任使用 AI 工具的指南结束。

法律免责声明

以下部分涉及复杂的法律话题，特别是关于版权和知识产权法，主要从美国的角度出发。法律体系和解释在全球范围内不断演变，尤其是在人工智能方面。此信息仅供教育目的，不构成法律建议。在根据此信息做出任何决定之前，你应该咨询合格的知识产权律师，特别是如果你对自己或 AI 工具生成的代码的所有权或许可有疑虑。

知识产权考量

谁拥有 AI 生成的代码?使用它是否尊重 AI 训练所依据的源材料的许可证和版权?像 GPT 这样的 AI 模型已经在来自互联网的大量代码上进行了训练，包括具有各种许可证(MIT、GPL、Apache 等)的开源存储库。如果 AI 生成的代码片段与来自 GPL 许可项目的某些内容非常相似(或相同)，在专有代码库中使用该片段可能会无意中违反 GPL，因为 GPL 通常要求共享衍生代码。

根据开源规范和一般版权原则，几行代码的小片段可能不受版权保护，如果它们缺乏足够的原创性而无法被视为独立的创作作品，或者它们的使用可能被认为是微不足道的(de minimis)（太琐碎而不值得法律关注）。然而，任何实质性的或表达独特创意选择的内容更有可能受到版权保护。理解”开源”并不意味着”公共领域”是至关重要的。默认情况下，包括代码在内的创作作品由其作者享有专有版权。开源许可证明确授予的权限，否则会受到版权法的限制。

如果你想了解更多关于开源规范的信息，可以从以下几个地方开始：

开源促进会(The Open Source Initiative): OSI 定义和推广开源软件，维护开源定义(Open Source Definition)，并批准符合其标准的许可证。
自由软件基金会(The Free Software Foundation, FSF): FSF 倡导”自由软件”（与开源原则有很大重叠），并且是 GNU 通用公共许可证(GPL)等许可证的管理者。
项目特定文档: 各个开源项目通常包含 LICENSE 文件、README 文件和 CONTRIBUTING 指南，详细说明该特定项目的使用和贡献条款。
社区和法律资源: 像 GitHub 这样的网站提供关于开源实践的大量文档和讨论。像 Linux 基金会和法律信息网站这样的组织也提供关于开源合规性和法律方面的宝贵资源。

使用小代码片段是否与合理使用原则（在美国；许多其他司法管辖区称为”公平交易”）重叠的问题是复杂的，并且高度依赖于具体情况。合理使用允许在未经许可的情况下有限使用受版权保护的材料，用于批评、评论、新闻报道、教学、学术或研究等目的。美国法院通常考虑四个因素来确定合理使用：

使用的目的和性质（商业性与非营利性，转换性与复制性）
受版权保护作品的性质（高度创造性与事实性）
相对于整个受版权保护作品而言，使用部分的数量和实质性
使用对受版权保护作品的潜在市场或价值的影响

虽然有些人可能会认为，为了互操作性或访问不受版权保护的想法而复制非常小的功能性代码片段可能属于合理使用，特别是如果使用是转换性的，但这在代码法律中并不是一个明确解决的领域，并且没有普遍认同的行数被明确定义为”合理使用”或微不足道。最安全的做法通常是获得许可，或者理解底层想法并用你自己的方式重写代码。美国最高法院案例 Google LLC v. Oracle America, Inc. 处理了软件 API 背景下的合理使用问题，认为 Google 对 Java API 声明代码的重新实现属于合理使用，但这是一个具体而复杂的裁决，专注于 API 声明，而不是所有代码。人们普遍理解，版权保护的是想法的具体表达，而不是想法、程序或操作方法本身。

通常，使用 AI 的开发者被视为”作者”，因为 AI 是一种工具，类似于编译器或文字处理器。因此，如果代码是在工作环境中生成的，开发者的公司可能会拥有开发者使用该工具产生的代码，但需遵守 AI 工具的服务条款和底层知识产权问题。然而，AI 工具的服务条款(ToS)至关重要。大多数 ToS 授予用户对其生成的输出的权利。例如，OpenAI 的 ToS 声明：“你拥有使用 GPT-4 创建的输出，包括代码。”

然而，这个”所有权”需要仔细考虑。它通常意味着AI提供商并不声称拥有你使用他们的工具创建的内容的所有权。但这假设你拥有所提供输入内容的权利，并且这并不自动意味着输出本身有资格获得版权保护，或者它不受第三方知识产权声明的影响。如果你将自己的原创代码输入到工具中进行修改或扩展，输出很可能是你的（或你雇主的），同样取决于AI如何处理它以及它从训练数据中融入了什么。但如果你输入别人的受版权保护的代码来修复或转换，输出可能被视为该第三方代码的衍生作品。

在美国和许多其他司法管辖区，与训练数据基本相似的AI生成输出，或基于受版权保护输入的输出，是否构成衍生作品是一个正在进行的法律辩论主题，缺乏完全的清晰度。不要将不属于你的大块受版权保护的代码（或未获得适当许可）输入AI工具，因为输出可能被视为衍生作品，从而受该原始受版权保护代码的许可约束。

鉴于这些不确定性，为了安全起见，将AI生成的代码视为处于模糊许可之下，并且仅在你确信它不侵犯现有版权并且你可以遵守任何潜在的开源许可义务时才使用它。关于AI输出本身的版权状态，美国版权局已声明，完全由AI生成而没有足够人类作者身份的作品是不受版权保护的。如果人类以创造性方式显著修改或编排AI生成的材料，该人类贡献可能是可受版权保护的，但单独的AI生成元素则不能。因此，通常明智的做法是假设纯粹的AI生成输出可能不受任何人的版权保护，或者版权仅延伸到人类的创造性贡献。

这不是假设性的担忧。事实上，存在正在进行的法律辩论。一项著名的集体诉讼Doe v. GitHub, Inc.针对GitHub、Microsoft和OpenAI提起，声称GitHub Copilot生成的代码与许可的开源代码过于相似，而没有适当的署名或遵守许可条款。虽然此案中的一些索赔已被驳回或正在上诉中（截至2025年中期，该案涉及正在进行的诉讼程序，包括向第九巡回法院上诉DMCA索赔和剩余的违约索赔），但它突出了一个真正的担忧：AI可以并且有时确实会逐字复制或紧密转述其训练数据中的受版权保护代码。¹

GitHub自己的一项较早（但仍然相关并后来得到证实）研究指出，在某些情况下，Copilot的输出包括与训练数据匹配的建议，包括罕见的较长逐字片段实例。虽然大多数AI工具旨在避免直接、大量复制可识别的代码，除非特别提示或处理非常标准的算法，但风险依然存在。此外，令人担忧的不仅仅是开源代码；许多作者、艺术家和媒体公司已经提起诉讼，声称他们的完全受版权保护的私有知识产权在未经许可或补偿的情况下被用于训练大型语言模型和其他生成式AI系统。专有代码的挑战在于，与开源不同，它通常不是公开可见的，这使得最终用户更难确认AI的输出是否无意中与此类私有代码相似。

尽管如此，合乎道德和审慎的做法是将你从AI工具接受的任何代码视为你的责任。在将任何AI生成的代码整合到你的项目之前，彻底审查、测试和理解它，并确保其使用符合所有适用的许可和版权法。

如果你得到可疑输出该怎么办

如果AI输出看起来像是已知代码的逐字或近似逐字副本（特别是如果它包含独特的注释或作者名称），请谨慎对待。考虑使用抄袭检测工具运行相似性检查，或对独特字符串进行网络搜索，看看是否能找到任何可能表明复制的匹配项。

另一个要遵循的原则是如有疑问，就不要使用。要么避免使用该输出，要么确保它在兼容的许可证下，并在需要时注明出处。例如，如果 Copilot 生成了一个你从 Stack Overflow 或开源项目中认出的知名算法实现，请引用来源或用你自己的方式重写它，将 AI 的答案作为指南但不要逐字引用。

如果你怀疑输出与现有库解决方案匹配，考虑直接包含该库本身（并遵守适当的许可证）。你也可以这样提示 AI：

请提供原创实现，而不是从库中复制的实现。

然后它可能会合成一个更独特的解决方案。（无法保证它不会受到训练代码的影响，但至少它会尝试不直接复制）。

这里的伦理问题还涉及不使用 AI 故意删除署名。例如，通过 AI 从 Stack Overflow 复制代码而不注明出处以规避应该注明答案来源的政策，这是不道德的。这会侵蚀开放知识生态系统中的信任。更好的做法是在适当注明出处的情况下整合材料。根据具体情况，这可能意味着以下内容：

如果 AI 从某个有作者姓名的来源编写了代码注释（比如复制了一个注释中带有”John Doe 2018”的代码片段），你应该保留它或将其移至适当的署名部分并提供完整引用，而不是删除它。这尊重了原作者的署名权。
如果 AI 提供的解决方案你知道来自某个已知算法或代码片段，就像你自己查找时一样引用该来源。
如果 AI 工具创建了可以说是有创意的东西（比如独特的方法或文档文本），承认它的贡献。虽然它没有权利，但这关乎透明度（也许是对技术的认可）。

一些开源许可证（如 MIT）足够宽松，只要注明出处就可以满足许可证要求。其他许可证，如 GPL 或 AGPL，如果你包含该代码会”感染”你的整个代码库，这对于闭源项目是不可取的。

简而言之：如果你怀疑 AI 给你的东西可能导致知识产权问题，要么避免使用它，要么充分转换它以确保你遵守任何可能的许可证。

灰色地带

即使在我写这篇文章的时候，AI 工具仍在不断提出关于知识产权、版权和伦理的新问题。例如：

如果你的氛围编程(vibe coding)包括使用 AI 生成非代码资产，如文档文本、配置文件或图像，也会出现类似的知识产权问题。例如，如果你通过一个基于受版权保护图像训练的 AI 工具生成图标图像，谁拥有这个新图像？
如果 AI 编写了软件产品的重要部分，AI 训练所基于的代码的原作者是否应该获得署名？
有人能否声称你的 AI 生成代码侵犯了他们的版权，因为它看起来与他们的相似？如果非平凡长度的部分可能相同，这就是需要进行相似性检查的地方。

有一种新兴观念认为，AI 公司可能需要实施尊重许可证的过滤器，或允许团队选择不将他们的代码包含在 AI 训练数据中。这正在发展中，但实际开发者应该保守行事，不要侵犯他人权利。

法院需要时间来解决所有法律问题，但与此同时，知识诚信和尊重应该指导我们。如果 AI 使用了已发表论文中的已知算法，在注释中引用该论文。如果它使用了常见的开源辅助代码，注明该项目。这关乎对作者身份的尊重。如果你认出某些内容的来源，宁可多给出署名。这是一个促进透明度的良好实践。

请记住，在底层，AI 的知识来自成千上万公开分享代码的开发者。从伦理上讲，软件行业欠那个社区以尊重开源许可证和规范的态度。在应该署名的地方给予署名，不要在”是 AI 写的，不是我”的幌子下滥用他人的工作。

透明度和署名

透明度指的是对在开发过程和输出中使用 AI 保持开放，署名指的是当 AI 衍生代码来自可识别来源时给予适当的署名。

透明度对于问责制很重要。例如，如果AI生成的代码引入了一个bug或安全漏洞，透明地说明”这段代码是AI建议的”可能有助于你分析根本原因——也许应该重写一个模糊的提示词(prompt)。在代码注释或项目的README或文档中，你可能会笼统地提到”该项目是在ChatGPT等AI工具的帮助下构建的。“或者更具体地说：”添加了一个解析CSV的函数(在ChatGPT的帮助下生成，然后进行了修改)。“这有点像承认你使用了框架或库。

透明度也是信任的关键：利益相关者(你的团队、客户、最终用户或行业监管机构)可能想知道你的软件是如何开发和验证的。如果AI参与了代码生成，一些利益相关者可能会错误地过度信任或过度怀疑它。透明度允许就可靠性展开对话：“是的，我们使用了AI，但我们进行了彻底的测试”或”这部分很棘手——我们让AI生成了初始代码，但我们已经验证过了。”

在许多学术场合，对AI生成代码的归属也是预期的或必需的。一些开源项目由于知识产权问题限制甚至禁止AI贡献，因此在使用AI之前请查看贡献者指南。如果补丁是AI生成的，对维护者保持透明有助于他们评估它，特别是当许可是一个问题时。

事实上，一些高度监管的行业要求软件供应商出于审计目的披露任何AI使用。欧盟的AI法案要求对影响个人的自动化决策(如信用评分算法)保持透明。如果氛围编码(vibe coding)导致此类系统，告知用户”建议是自动生成的，可能反映数据中的模式”就成为法律/道德上的必要性。

同样，如果你的产品将用户数据或专有数据(如用户提供的代码示例)输入AI模型以对其进行微调并帮助编程其分析，你可能需要在隐私政策中说明用户数据可能在获得许可的情况下用于改进AI模型(一如既往，法律事务请咨询律师)。透明度在这里与隐私交叉。

承认你使用的工具和来源在总体上也是符合道德的。如果你30%的代码是由Copilot生成的，在你的文档或内部沟通中提到这一点是公平的——不是为了贬低你自己的作用，而是为了对过程保持诚实。

一些开发者可能担心承认AI提供了帮助，担心这可能会削弱他们被认知的贡献或技能，或被视为”作弊”。随着氛围编码变得更加规范化，这种污名应该会减少；最终，如果你不使用可用的AI，你可能会被视为落伍。我们需要将AI规范化为一种工具——它不比使用Stack Overflow或IDE更”作弊”。

另一方面，提供过多的免责声明可能会引起不必要的担忧。如果你告诉客户，“我们使用AI来编写这个产品的代码，”他们可能会质疑其安全性(即使这是由于误解)。你如何表述很重要。在同一时间强调质量措施：“我们利用先进的编码助手来加快开发速度，所有AI生成的代码都经过严格审查和测试，以符合我们的质量标准。”

总之，透明度和归属培养信任和社区价值。它们确保功劳归于人类创造者，并确保我们对软件的构建方式保持诚实。这类似于艺术家列出他们的工具或灵感；它不会削弱艺术；它将其置于背景中。如果像我一样，你希望氛围编码被广泛接受，那么公开使用AI以及如何减轻其风险是很重要的。

偏见与公平

正如你在本书的这一部分已经很清楚的那样，AI模型的输出反映了它们所训练的数据。如果这些数据包含偏见或排斥性模式，模型可能会产生有偏见或不公平的输出。

你可能会问：“代码怎么会有偏见？这又不像LLM在做招聘决策之类的事情。”但偏见可能以微妙的方式渗入你的编码：

代码通常反映创建者的假设。AI生成的面向用户的文本或内容可能反映其训练数据中存在的文化偏见或不敏感语言。例如，微软的Tay，一个2016年的早期聊天机器人，在推出后的几小时内就因与Twitter的互动而学会了模仿种族主义和厌女口号，这一点臭名昭著。
假设(assumption)也可能针对特定的文化规范，比如北美中产阶级的生活方式(如假设拥有汽车或普遍可以使用某些技术)。一个由于未经审查的假设导致排他性产品的典型例子是 2014年发布的苹果健康应用，它缺少经期追踪功能——这一重大疏忽很可能源于设计团队缺乏多样性和不同视角。即使在示例代码、注释或合成数据中，模型也可能总是使用 he/him 代词，从而强化性别偏见。
众所周知，代码仓库和更广泛的软件开发领域主要反映的是西方视角和英语使用者。因此，在这些仓库上训练的AI可能会忽略关键的国际化(internationalization)方面，比如对Unicode和多字节字符的正确支持(这对中文、日文、韩文、阿拉伯文、印地文以及许多其他使用非拉丁或音节文字的语言至关重要)，或者它可能默认使用以英语为中心的示例来命名类型。开发者必须提高意识并为国际化进行设计和编码，即使AI不会自发地这样做。
如果编写算法，要警惕种族、性别、年龄等变量。除非被问到，AI可能不会自发地包含它们，但如果它幻觉出某些标准，或者你在数据集上使用像Code Assistant这样的AI，请应用公平性约束(fairness constraints)；AI不会天生就知道道德或法律背景。

除了编码之外，模型还可能在其内容领域中反映数据偏见(data bias)：其训练数据中存在的历史偏见。例如，考虑一个负责为贷款审批编写信用评分算法代码的AI。在美国，信用评分系统有记录显示反映并延续了种族偏见。这些偏见源于历史上的做法，如红线政策(redlining)和其他形式的系统性歧视，这些歧视产生了持久的金融影响，特别是对黑人社区和其他边缘化群体。(参见Richard Rothstein的《法律的颜色》[经济政策研究所，2017]，了解政府政策如何隔离美国的全面历史。)

如果训练数据反映了这些历史偏见，AI可能会纳入歧视性变量，例如使用邮政编码(由于隔离的住房模式，这可能是种族人口统计的代理变量)或其他看似中立但与受保护特征相关的数据点。如果没有得到适当的指导，AI可能会生成导致银行做出不公平贷款决策的代码，从而延续历史不平等并影响真实人们的生活。类似的问题也出现在预测性警务算法等领域，其中历史逮捕数据(本身可能存在偏见)可能导致AI系统不成比例地针对某些社区。

同样，如果你使用专门的模型(比如针对医疗软件进行微调的AI代码助手)，请确保模型不会被锁定在该领域数据的偏见中。例如，从历史上看，一些医疗指南存在偏见，因为研究主要使用男性受试者，导致对其他性别的误诊或治疗效果较差。如果AI推荐医疗诊断的代码或解决方案，你需要仔细检查它是否无意中编码了那些偏见。

有一些工具正在出现，用于检测AI输出中的偏见，尽管这些工具在用于生成内容的GPT模型中更常见，AI提供商自己也试图过滤明显有偏见或有毒的输出。面向代码的AI很少自发产生仇恨言论，但它们有内容过滤器是好事。在许多AI工具中内置道德约束意味着，如果用户试图让AI创建恶意软件或歧视性算法，它会拒绝。不要试图破解这些过滤器来获得不道德的输出。

在开发过程的不同阶段，还有很多其他方法来识别和减轻偏见。这些包括：

使用多样化的示例进行测试: 如果你的AI生成面向用户的组件或处理与人类相关数据的逻辑，请使用多样化的输入进行测试。例如，如果AI生成的表单验证期望”名字”和”姓氏”，它是否允许单一名字，这在某些文化中很常见？如果不允许，那就是假设中的偏见。如果它生成示例用户名，它们是否都像”JohnDoe”？如果是这样，请考虑在示例中纳入更多多样性。
提示包容性: 你可以明确指示AI保持中立或包容：“生成使用来自不同文化的各种名字的示例。”如果它总是将用户称为”他”，你可以提示：; 在此代码注释中避免使用性别化语言；使用中性措辞或they/them代词。

负责任AI使用的黄金法则

将我们所讨论的内容汇总起来，值得明确一套负责任的vibe编码(vibe coding)实践规则：

始终保持人工监督

再次强调：绝不让AI在无人监督的情况下工作。负责任的AI辅助开发意味着你，作为开发者，要审查每一行代码并做出决策，而不是在没有人工验证的情况下部署原始的AI输出。
对你的代码负责

如果出现问题，这不是AI的错——而是开发团队的责任。保持这种心态可以避免自满。无论你是从头编写代码还是接受了AI代码，都要准备好为你的代码辩护。如果有人问你，“代码为什么这样做？”不要说，“我不知道；是Copilot做的。”这就是为什么第3章的黄金法则之一是”永远不要提交你不完全理解的代码。“这才是负责任的工程实践。
保护用户隐私并征得他们的同意

从道德角度讲，你有责任对用户和公司保守他们的机密数据。在使用AI工具时，特别是基于云的工具，要小心不要在提示词或对话中暴露敏感数据。例如，如果你正在调试用户数据库的问题，不要将实际的用户记录输入到ChatGPT中。应该使用经过脱敏或合成的数据。

现在许多工具允许用户（至少是商业用户）选择不将他们的输入数据用于训练。如果你是企业用户，请使用这些设置或对敏感代码使用本地部署的解决方案。如果你确实将任何用户数据输入到模型中，或者如果任何AI功能直接接触用户（比如应用中使用LLM的聊天机器人），请征得用户同意，并在适当时允许他们选择退出。像”此功能使用AI服务；你的输入将被发送到该服务进行处理”这样的警告是透明的，让注重隐私的用户自己决定。
遵守法律法规

关注AI相关的法律要求，这些要求在不断演变。例如，数据保护法，如欧盟的《通用数据保护条例》(GDPR)和《人工智能法案》(AI Act)认为，如果AI输出包含任何个人数据，则将其视为个人数据。在用户数据上训练模型可能需要征得这些用户的同意。监管机构可能将代码生成归类为”通用AI”，并施加透明度或风险管理义务。保持信息畅通，并与你的法律和合规专业人员密切合作，避免违反任何法规。

虽然这应该不言而喻，但不要使用AI生成恶意软件、没有道德正当理由的漏洞利用代码，或自动化不道德或非法的做法。虽然AI可能可以写出非常有效的钓鱼邮件或代码注入攻击，但将其用于此目的违反了道德、大多数国家的法律，并且可能违反AI的服务条款。专注于建设性的使用。
在组织中培养负责任的AI文化

如果你的团队采用vibe编码，鼓励关于道德的讨论，并提供相关的道德培训。考虑让开发者和代码审查者使用如图9-1所示的简短检查清单。

目录

超越氛围编程

第一版修订历史

前言

本书的目标读者

预期内容

本书使用的约定

提示

警告

O’Reilly在线学习

注意

如何联系我们

第一部分 基础

第 1 章 导言：什么是氛围编程(Vibe Coding)？

AI 编程谱系：从氛围编程到 AI 辅助工程

氛围编程方法：通过对话编码

AI辅助工程方法：与AI伙伴一起构建结构

不同的思维方式,不同的期望

在光谱上找到你的位置

超越代码行数：意图编程

提示词的崛起：从指令到描述

工作原理：迭代循环和 AI 在代码生成中的角色

生产力、可访问性和编程的变化本质

提高开发者生产力

保持开发者处于”心流状态”

降低入门门槛

改变开发者角色和技能

随着 AI 承担更多代码生成工作，人类开发者的角色正在演变

生产力与创造力

信任与正确性

失去一些底层技能

工作格局的转变

工具一瞥：新兴生态系统

VSCode + Copilot：微软的集成 AI 开发平台

VSCode + Cline: 开源自主编码Agent

Cursor：AI 驱动的代码编辑器

在专业工作流中高效使用 Cursor

Windsurf：具有完整代码库索引的 AI 驱动 IDE

AI 模型：代码生成的格局

理解模型类别

为您的任务选择合适的模型

适用于任何模型的实用技巧

主要模型

Google Gemini：多模态编码强者

Claude：推理大师

ChatGPT：多功能编码伙伴

根据需求选择合适的模型

氛围编码的优势与局限：细致的观点

氛围编码的理想用例

从零到一的产品开发

功能原型和CRUD应用

粘合代码和集成

现代框架利用

重复性代码生成

AI辅助工程应该优先的情况

识别转换点

AI 仍然困难的领域

更快的开发周期

增强的原型设计和实验

知识触手可及

一致性和标准化

可变的输出质量

提示的歧义导致代码的歧义

总结与下一步

第2章.提示的艺术：与 AI 有效沟通

图2-1. 一个聊天机器人协助编程的示意图。开发者和AI进行对话：开发者提供指令或问题（提示词），AI则用代码或答案回应。通过精心设计的提示词与AI进行有效沟通，是获得准确且有用的代码生成的关键。

提示词工程基础

特定性和清晰度：编写能够产出结果的提示词

迭代优化(Iterative Refinement)：与AI的反馈循环(Feedback Loop)

图2-2. 高级提示工程循环。

比较两个提示

图 2-3. 提示词质量影响对比：模糊的提示词产生通用或不正确的代码，而具体、结构良好的提示词能生成准确且符合上下文的解决方案。

糟糕的提示词

改进的提示词

提示技术:有效沟通的工具箱

关于风格的说明

零样本提示

单样本和少样本提示

上下文窗口

思维链提示

第一部分基础

第 1 章导言：什么是氛围编程(Vibe Coding)？

第4章超越70%：最大化人类贡献