超越Vibe Coding——借助 AI 打造 Web 应用

本章将视角从“通过提示快速做原型”转向“在 AI 协助下开发完整的 Web 应用”。Web 应用通常包含三个部分：前端（常用框架如 React、Angular 或 Vue）、后端（API、数据库、服务器），以及把一切连接起来的“胶合层”。Vibe coding（氛围式编码）可以加速上述每一层。

我将带你走完整个由 AI 结对程序员辅助的端到端工作流，涵盖：

• 搭建项目与脚手架
• 编写前端 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，包含相关脚本（比如同时启动前后端）。
• 通过在 React 开发服务器中配置代理，或提供如何设置 CORS 的说明，完成前后端的通信设置。

几分钟内，你就能得到一个全栈应用的骨架。即使 AI 不能把所有步骤全自动完成，它也会给出代码和补充说明（例如“把这个代理配置加到你的 React package.json”），从而省下大量枯燥的初始化时间，让你立刻聚焦在功能开发上。

如果你没有使用 AI IDE，也可以像平常一样一步步借助 ChatGPT 或其他助手。例如：

• “我想创建一个新的 React 应用，应该运行哪些命令？”
  AI 会引导你完成步骤，或推荐 Vite、Next.js 等更新的替代方案。
• “现在设置一个带 /api/to-dos 路由的 Express 服务器。”
  它会生成 Express 服务器代码，你只需拷贝到文件里即可。
• “开发阶段如何把我的 React 应用连到这个 API？”
  它可能建议配置代理，或告知如何直接调用完整的 API URL（若不使用代理）。

这样，连“基础管道”的搭建也变成了对话式过程，而不再是四处翻文档。正如前面章节所说，“按意图编程”意味着你告诉 AI 你要的结果，它来推导步骤。项目初始化正是这种方式的完美用例。

在这个阶段，明确你的架构决策非常重要。AI 会遵循你的指令，但高层架构与关键模式仍需要人来拍板：你要用单一仓库（monorepo）还是前后端分仓？采用 REST 还是 GraphQL？使用哪种数据库？

一旦想清楚这些，你就可以据此指导 AI：

• “顺带为 SQLite 数据库设置一个基础的 Prisma schema。”
  或
• “把 REST 换成 GraphQL 服务器。”

AI 也许不能 100% 完美执行复杂搭建，但能完成大部分工作，你再据此打磨。

许多资深开发者会把这些步骤固化到项目模板或样板生成器里；而 AI 提供了更灵活的路径：你可以用自然语言随时定制。如果你的项目稍有不同（比如需要三层服务而非常见的两层，或者你想预配置特定库如 Tailwind CSS），只需告诉 AI 把它们一并纳入即可。

借助 AI 的前端开发范式

在脚手架就绪之后，Web 应用的大部分工作都落在前端开发上。本节将探讨如何利用一位 AI 结对程序员来协助你的前端编码。

依据描述实现组件

你可以通过描述功能与外观来让 AI 生成组件，例如：

创建一个名为 TodoList 的 React 组件，接收一组待办事项并进行展示。每个条目应显示标题，并带有一个复选框用于标记完成。

AI 会产出函数式组件代码，并按需设置 props 与状态：

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

AI 往往会相应地输出 <template>、<script> 与 <style> 部分。作为开发者，你可以跳过样板代码，直接拿到需要的结构，并在必要时微调。若你的提示暗含需求，AI 通常还会附带基础校验或状态处理。

此阶段要确保一致性。如果你分别独立生成多个组件，可能需要稍作调整以让它们协同工作。比如 TodoList 期望的 props 形状要与其使用方一致。你可以在一次提示中同时生成相关组件（让 AI 了解全貌），或先自行接好再让 AI 修复不匹配之处。

样式与布局

CSS 与样式常常繁琐。描述你想要的效果，把具体细节交给 AI：

为待办列表组件设定样式：列表使用纵向 flex 布局，增加条目间距，已完成项的文字设为灰色并加删除线。
对登录表单组件进行样式设置：使其在页面居中，输入框更大并带圆角边框。

助手可以输出 CSS-in-JS、原生 CSS，或内联样式，具体取决于上下文。如果你使用 Tailwind CSS，也可让它输出相应的类名（不过要注意，并非所有模型都完全熟悉 Tailwind）。

关键在于：你可以在不手动微调每一个 CSS 数值的前提下迭代设计，把精力放在更高层次的抽象上——描述“看起来要怎样”，而不是逐个写边距与颜色。

集成 API 与状态管理

Web 前端通常需要从后端拉取数据，并用 Redux、Context 或组件内部状态进行管理。AI 能帮助你编写这些集成代码，例如：

在 TodoList 组件挂载时，从 /api/to-dos 拉取待办列表，并存入状态。
在 TodoList 中实现一个函数：当复选框被切换时，向 /api/to-dos/{id}/complete 发送 POST 请求，然后据此更新状态。

AI 可以在 React 中生成 useEffect 钩子以进行数据获取，或在 Vue 中使用 mounted()。它也会用 fetch 或 Axios 等方式来示例化 HTTP 调用。你需要确认接口路径与载荷格式是否与后端相符（如果你已经实现了后端或有相应规格说明）。

即便后端尚未完成，你也可能正同时借助 AI 构建它——我们很快会谈到这点。由于前后端都可以相对独立地通过规格化描述来生成，你可以在 AI 的帮助下并行推进，只要维护好它们之间的接口契约。

在 AI 指导下处理复杂性

如果你的前端逻辑较复杂（例如动态表单校验、条件渲染、复杂交互），可以在 AI 的协助下分步实现。良好的做法是把问题拆解：

新增一个特性：当用户勾选待办项的“完成”复选框时，该条目先淡出（CSS 过渡），1 秒后再从列表中移除。
AI 可能会给出在勾选时添加 CSS 类并使用定时器移除项的实现，以及所需的淡出样式。
表单有一个可选的“备注”字段。仅当勾选“添加备注”复选框时显示该文本域。
AI 会修改组件状态与 JSX 以条件渲染备注区域。

这些都可以通过迭代式提示完成。本质上，你描述期望的交互与体验，AI 生成对应代码。每次增量修改后都要进行测试，确保行为符合预期。

框架特定建议

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

• React：AI 可能会使用 useState、useEffect 等 Hooks。务必检查其是否遵循最佳实践（例如 useEffect 的依赖数组是否正确）。
• Vue：AI 可能输出 Options API 或 Composition API 风格，取决于它参考的示例。若你有偏好（如“使用 Vue 3 Composition API”），请在提示中明确说明。
• Angular：AI 可以生成组件，但 Angular 的学习曲线更陡。通常可以先用 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', ...) 的形式。如果你说明在用支持 JSON 的 Express，它还可能补上必要的中间件（若尚未配置）：
app.use(express.json())

随着后端变大，你可以让 AI 做重构：

• “把 Express 路由重构到独立的路由模块中。”
  它可能会把路由拆到单独文件，这对可维护性是好做法。

数据库集成

原型阶段你可以用内存数据；要做更完整的应用，就需要数据库。假设你选择 MongoDB 或 PostgreSQL，你可以这样提示：

• “把 MongoDB 集成到 Express，并使用 Mongoose。创建一个包含 title（字符串）、completed（布尔）的 to-do 模型。把 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 标记完成时，若所有待办都已完成，记录一条日志 ‘All done!’。”
  它会把逻辑插入到对应的处理器中。

你用自然语言描述需求，AI 按此修改代码。不过你仍需测试以确保行为符合预期。

使用框架或脚手架

许多后端不仅仅是裸 Express（Node 生态中有 NestJS，Python 有 Django 等）。AI 也能配合这些框架，但复杂任务可能需要进一步拆解：

• Django（Python） ：你可以提示“为 to-do 创建模型（字段 X），并创建对应的列表与创建视图”。AI 可能给出模型代码与通用视图，或在知道上下文时给出 DRF（Django REST Framework）的序列化器／视图集。
• Ruby on Rails：你可以让它帮助生成模型与控制器（当然 Rails 自带脚手架已经很强了），AI 还能补充校验或调整路由。

模型对不同技术栈的熟练度差异

不同 AI 模型对各语言与技术栈的熟练度有差异，这与训练数据中技术的普及度相关。像 JavaScript、Python、Java 这类流行语言，通常支持更好，因为开源仓库、文档与教程更丰富。尽管模型“见过”的语言都能写，但效果会显著不同。

评估模型是否熟练掌握你的栈，最可靠的方法是实践：

• 先用目标语言做基础任务测试，再逐步提高复杂度。
• 观察其是否能写出符合惯用法（idiomatic）的代码、是否无需你过多解释就能识别常见框架与库、是否能提出契合生态的设计模式。
• 熟练度高时，它的建议更贴合上下文；熟练度不足时，容易给出通用或过时的模式。

不少 AI 提供商会发布模型能力文档，但很少有细到语言级的基准。最稳妥的方式是用你真实的技术栈做小实验。例如在 Rails 中，测试它是否懂 ActiveRecord 的习惯用法、能否生成合适的 RSpec 测试。对较新的框架或小众语言，要预期结果更不稳定，并准备在提示中提供更多上下文信息以弥补潜在空白。

编排多步骤操作

有些端点涉及多步骤：比如先在一张表创建记录，再在另一张表建关联，或者调用外部 API。你可以把步骤列清楚，让 AI 起草：

• “当新用户注册（POST /api/users）时，创建用户记录，并通过 SendGrid API 发送欢迎邮件。”
  AI 会写出保存用户（可能使用 ORM）的代码，并构造向 SendGrid 发起 HTTP 请求的逻辑；你需要填入 API Key 或微调内容，但大部分样板已就位。
• “实现转账交易（POST /api/transfer）：从账户 A 扣款并给账户 B 加款，确保原子性（要么全部成功，要么全部回滚）。”
  如果你用的 ORM／数据库支持事务，AI 可能会使用相应特性（如 SQL 事务块或 ORM 的事务方法）。对这类代码要格外谨慎审查——事务逻辑很容易出错。但 AI 往往知道一些常见陷阱并加入检查。比如在处理转账端点时，AI 可能写出这样的结构：

async function transferMoney(fromAccountId, toAccountId, amount) {
  const session = await db.startSession();
  
  try {
    await session.startTransaction();
    
    // 从源账户扣款
    const sourceAccount = await Account.findByIdAndUpdate(
      fromAccountId,
      { $inc: { balance: -amount } },
      { session, new: true }
    );
    
    if (sourceAccount.balance < 0) {
      throw new Error('Insufficient funds');
    }
    
    // 给目标账户加款
    await Account.findByIdAndUpdate(
      toAccountId,
      { $inc: { balance: amount } },
      { session }
    );
    
    await session.commitTransaction();
    return { success: true };

  } catch (error) {
    await session.abortTransaction();
    throw error;
  } finally {
    session.endSession();
  }
}

这里把两次数据库操作包在同一事务中，包含“余额不足”的校验，并在任何错误时正确回滚。虽然你仍需补充边界情况与日志，但这一原子化操作的基本骨架是正确的。

API 文档与测试

在构建 API 时，你也可以让 AI 生成文档。例如：“为 /api/to-dos 端点写一份简要文档。”它可能给出：

• GET /api/to-dos —— 返回待办列表
• POST /api/to-dos —— 新建待办。请求体 JSON：{ title: string }。返回创建的待办
• ……

这既方便快速查阅，也便于与你的前端同事共享（若你在团队合作）。此外，你还能让 AI 为端点编写测试，用 Node 生态的 Jest 或 Mocha，或用 Python 的 PyTest。比如：“为 to-dos API 生成测试（一个测试列表接口、一个测试创建接口、一个测试校验错误）”，AI 会产出可运行的测试代码，接下来你只需执行并验证即可。

数据库设计与集成

在设计数据库模式时，人对业务领域的理解至关重要，但 AI 可以协助把这些设计转化为代码（如迁移脚本或 ORM 模型）。另外，如果你对自己的模式拿不准，也可以和 AI 一起头脑风暴。

举例来说，假设你的应用将从待办清单扩展为完整的项目管理工具。你需要设计多张表：Projects、Tasks、Users 等。你可以询问：“一个包含用户、项目和任务的简易项目管理应用需要哪些数据模型？请包含它们之间的关系。”AI 可能会给出类似这样的回答：

• User（id、name、email 等）
• Project（id、name、owner_id，引用 User）
• Task（id、description、project_id、assigned_to（User）、status 等）

这未必完全符合你的想法，但能提供一个起点。你确认或微调这些设计思路，然后再实现它们。

使用 ORM

如果你使用 Prisma、Entity Framework 或 SQLAlchemy 等 ORM，可以让 AI 生成模型类或模式定义：

使用 Sequelize（Node 端），为 User、Project、Task 定义模型及其关联：User 一对多 Project，Project 属于 User；Project 一对多 Task，Task 属于 Project；Task 可分配给某个 User（多对一）。

AI 随后会写出定义这些 Sequelize 模型与关联关系的 JS/TS 代码，你即可将其集成到代码库中。若它比较熟悉，还可能顺带建议外键或级联规则。

如果你不使用 ORM、而是编写原生 SQL 迁移，也可以让 AI 起草迁移脚本：

编写一个 SQL 脚本，创建 users、projects、tasks 三张表，并设置合适的外键。
AI 会输出一份 SQL DDL 脚本，供你审阅并执行。

数据库查询

在将数据库集成进代码时，你可能需要比简单 CRUD 更复杂的查询。比如你想获取所有项目，以及各自的任务和每个任务被分配到的用户——这需要在 Project、Task、User 之间做关联查询。你可以提示：

写一条 SQL 查询语句，检索项目及其任务，以及每个任务所分配用户的姓名。
AI 会生成一条包含连接（JOIN）的 SQL 查询。

如果你使用 ORM：

使用 Sequelize，获取所有项目，并加载关联的任务以及每个任务对应的用户。
你可以期待类似这样的关联加载代码：include: [Task, { model: User, as: 'assignedUser' }]

校验 AI 生成的查询

数据库操作需要仔细核对，确保 AI 生成的代码与你的实际模式一致并维护数据完整性。除非你在提示中明确提供信息，否则 AI 无法自动知晓你的具体表名、字段名或关系。即便模型具备对话记忆，涉及复杂数据库的提示也应显式包含模式细节，以避免出现将你的 userId 字段误写为通用的 user_id 之类的问题。

性能方面通常需要人工把关。虽然 AI 理解主键、连接等基础概念，但它未必会主动提出性能优化建议，例如：为高频查询字段添加索引、或参考执行计划来优化查询。对高频或大数据量操作尤其要审查效率。

数据一致性规则同样需要明确说明。实现删除操作时，要清晰定义你的级联行为。例如，删除 Project 记录时，是让数据库自动删除关联的 Task（级联删除），还是由应用逻辑来处理清理？请把这些业务规则明确告诉 AI：

当删除项目时，配置数据库级联删除所有关联的任务。
或
删除项目前，先检查是否存在关联任务；若存在则阻止删除。

只要指令清晰，AI 都能有效实现上述任一方案。对于级联删除，它可能会生成带 ON DELETE CASCADE 的外键约束；对于应用层处理，它会给出在允许删除前先查询关联记录的代码。关键在于：明确陈述你的数据完整性要求，而不是假设 AI 会自动推断出最适合你业务领域的行为。

全栈集成：让前后端“结为连理”

在借助 AI 完成前端与后端的构建之后，下一个挑战就是把它们整合成一个无缝的 Web 应用。这意味着要确保前端能正确调用 API 端点、数据流动顺畅，并让整个系统保持一致与连贯。

对齐前后端的接口契约

这一点至关重要：前端期望接收的数据结构必须与后端返回的结构一致。若让 AI 各自独立地开发两端，容易出现细微的不匹配（比如后端返回 { success: true, data: [...] }，而前端却期望直接得到数组）。为避免此类问题，你可以在同时编写两端代码时明确指示 AI 所采用的响应格式。或者在两端完成后做一次端到端测试：打开应用看列表是否能加载；若失败，则对照浏览器控制台与服务器日志排查。

我经常让 AI 帮我把一侧调整为匹配另一侧：

• 如果后端返回的 JSON 键名与前端期望不一致，你可以在任一侧对 AI 说：
  “把 JSON 中的键从单数 taskList 改为复数 tasks。”
• 如果前端以表单编码（application/x-www-form-urlencoded）提交，而后端期望 JSON，你可以让 AI 做转换：前端用 JSON.stringify，或在后端添加（或启用）解析 JSON 的中间件（如 express.json() 或 body-parser）。

与 AI 的实时协同

像 Cline、Cursor 这类能持有整个项目上下文的 AI 增强型 IDE 在集成阶段尤其有用。你可以在 IDE 中并排打开前端与后端文件，然后提示：

“确保前端从 /api/to-dos 的请求与 Express 路由的请求／响应契合，并修复任何不一致之处。”
AI 可能会据此做统一，比如在前端补上 await response.json()，或调整 JSON 结构。

状态管理与同步

在全栈应用中，为了更专业的用户体验，应在前端加入加载状态与错误处理。例如：

• “添加加载指示：当 React 组件正在获取任务时，显示 ‘Loading...’，数据加载完成后再隐藏。”
• “处理错误：如果 API 调用失败（非 200 响应），在 UI 上显示错误信息。”

AI 会添加 isLoading 状态和条件渲染，或在 fetch 周围加入 try/catch 捕获错误并显示消息。这类“打磨”能让应用显得更稳健。

WebSockets 与高级集成

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

“使用 Socket.io 设置一个 WebSocket：当服务器创建新任务时，向所有已连接客户端广播。修改前端以监听该事件，并把新任务实时加入列表。”
尽管这很复杂，AI 往往能生成服务端的 Socket.io 设置（如 io.on('connection', ...) 并在创建新任务时 emit 事件），以及前端用于连接并监听事件的代码。你需要仔细整合，但令人惊讶的是，这些描述往往能变成可运行的实时代码。如果一开始不够完美，通过迭代提示与测试通常能把它打磨好。

示例：借助 AI 的全栈流程

以一个简易的联系人管理应用为例：

1. 像前文那样，搭好 React 前端与 Node/Express 后端的脚手架。

2. 在前端，先提示生成 ContactList 与 ContactForm 组件，再提示添加 API 调用：

   • 在 ContactList 中，组件挂载时从 /api/contacts 拉取联系人。
   • 在 ContactForm 中，提交时向 /api/contacts 发送 POST 请求，并在成功后更新联系人列表。

3. 在后端，你可以先用内存数组，或先接入数据库；然后提示生成 Express 路由：GET /api/contacts（返回列表）与 POST /api/contacts（将联系人写入数据库或内存）。

4. 尝试通过 UI 新增联系人：如果能出现在列表中，太好了；若没有，则调试。可能是 POST 路由没有正确返回新建对象，或表单代码没有刷新列表。找到缺口后再提示 AI 修复：

   “新增联系人后，后端应在响应中返回新建的联系人对象；前端应无需整页刷新，直接将其追加到列表。”
   这样 AI 就会同时调整后端响应与前端状态更新逻辑（比如用 React 的状态更新把新项 push 进来）。

5. 用同样方式实现编辑与删除等功能——把常规部分交给 AI，你只需聚焦描述功能行为。

手工完成上述流程，对初级开发者可能要一两周；而在 AI 协作者的帮助下，凭借大量样板与连接代码的自动化，通常一两天即可完成。

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

• 把样板交给 AI，定制逻辑你亲自写
  识别哪些是机械性代码、哪些是独特核心逻辑。让 AI 生成 CRUD API 或标准组件；而困难的、专有的算法或特定业务规则由你手写，再让 AI 做评审或补测试。把重复性劳动交给 AI，你负责创新部分。

• 逐条用 AI 消化你的待办清单
  开发时维护一份任务列表（待实现功能与待修复缺陷）。逐条向 AI 说明，让它给出方案。比如记有一条“在用户注册时实现密码哈希”，可以提示：

  “在 POST /api/register 路由中，在保存用户之前使用 bcrypt 做密码哈希。”
  这种逐项、系统化的方法能避免遗漏。

• 让 AI 边做边提质
  功能跑通后，可以提示“重构这段代码以提升可读性”或“优化这个函数”。AI 往往能在你监督下把代码变得更清爽或更高效。但要确保变更仍能通过你的测试。

• 用 AI 进行交叉核对
  对设计拿不准时，把它当作同事来讨论：

  “在内存数组里存联系人可以吗，还是应该用数据库？各自的优缺点是什么？”
  虽然你多半知道答案（要持久化就用数据库），但 AI 可能提醒你一些容易忽视的点：
  “如果存在多个服务实例，内存存储无法在实例间同步。”

• 用 AI 协调团队协作
  若团队中不是每个人都直接使用 AI，请让 AI 生成你所做改动的文档，并主动向团队说明你的做法：“我用 AI 快速生成了这些控制器；我已检查，但请在评审时留意非常规写法。”鼓励将 AI 生成的代码像普通代码一样进行评审，以发现潜在问题。

已有的真实团队（如 Snyk）报告称引入 AI 能提升生产力，但也强调必须保持“人类在环”以做校验。GitHub 在 2024 年的一项调查中显示，97% 的开发者在工作中以某种方式使用了 AI 编码工具。

AI 生成的 Web 应用的测试与验证

在借助 AI 构建完 Web 应用后，一定要进行充分测试，以确保一切按预期工作，并及时发现你或 AI 可能引入的问题。以下是在 AI 协助环境下开展测试的方法：

单元测试（Unit tests）
针对后端的关键函数（例如计算逻辑或输入校验）编写单元测试。即便函数由 AI 编写，测试也能揭示隐藏缺陷。你也可以让 AI 生成这些测试，但要谨慎：AI 生成的测试有时过于浅显，或默认了某种实现，因此需要你引导其覆盖边界情况，例如：

为密码强度函数编写测试，包括空密码、超长密码、包含特殊字符等边界案例。

集成测试（Integration tests）
使用 Supertest（Node 场景）或直接发起 HTTP 调用来测试 API 端点，检查每个端点是否返回预期结果。你可以请 AI 搭好脚手架：

使用 Jest 和 Supertest 为 /api/to-dos 端点编写集成测试。
AI 可能会生成启动应用、访问端点并对响应断言的测试用例。

前端测试（Frontend tests）
Web UI 测试可用 Jest（覆盖组件逻辑）以及 Cypress 或 Playwright 做端到端（E2E）测试。你完全可以让 AI 产出一个 Cypress 测试场景：

编写一个 Cypress 测试：加载应用，通过表单新增一条待办，并检查其是否出现在列表中。
你会得到一份可运行的测试脚本。借助 AI 来脚本化用户交互，可以迅速获得端到端覆盖。

人工探索测试（Manual tests）
无论自动化测试多完善，都要进行人工探索测试。自己动手在应用里点点点（团队中有 QA 的话也可交给 QA）。AI 不一定能预见所有真实场景：比如浏览器返回键可能破坏某些状态，或特定操作序列会触发异常。发现缺陷后，修复它们，或请 AI 协助修复。人工测试对 UI/UX 判断也很重要——应用是否好用？流程是否拧巴？这些主观体验需要人来把关。

代码评审（Code review）
如果你在团队中协作，让其他人审阅由 AI 生成的代码。新视角能发现你忽略的问题：比如安全疏漏，或建议更符合惯用法的写法。采用 AI 的团队通常仍维持正常的评审流程，只是更关注 AI 可能无意间引入的细微缺陷或安全问题。

安全审计（Security audit）
第 8 章会深入讨论安全，但在开发阶段就值得做初步扫描与加固。可以使用 Linters、SAST 等自动化工具，或直接提示 AI：

审查这份 Express 应用代码，并列出潜在的安全漏洞或不符合最佳实践的地方。
AI 可能会指出一些出乎意料的问题，比如“这里没有对用户输入做清理”“应正确设置 CORS”。把这些建议作为加固清单逐项落实。

以测促质的正反馈
使用 AI 的一个积极效应是：你可能会写出比以往更多的测试，因为创建测试变得更容易。这反而能让最终代码更健壮。若在生成功能后立即生成并运行测试（相当于 AI 辅助的 TDD，或至少是事后补测），就能确保快速开发不以质量为代价。可以这样理解：既然 AI 帮你节省了写代码的时间，那就把一部分时间投入到测试上。

保持安全与理性
如果不加提醒，AI 可能给出不安全的代码。例如早期版本可能生成易受 SQL 注入的查询。通过测试与评审，你能及时发现并修复这些问题。有研究发现，使用 AI 的开发者有时会对代码的安全性过度自信，即使这些代码的安全性可能不如手写版本。
结论：绝不要因为代码是 AI 写的就跳过验证。像审查人写的代码一样去审查它——默认它也会有缺陷，并用测试与评审来保证质量。

成功的 AI 构建 Web 项目示例

下面强调几个案例（综合自多方报道），展示 AI 在交付真实 Web 应用中发挥的重要作用。

个人开发者的电商网站
一名独立开发者想要搭建一个小型电商 Web 应用来售卖定制 T 恤，但可投入时间有限。他通过 IDE 扩展使用 GPT 搭起了整套技术栈：让 AI 生成包含商品列表、购物车与结账页面的 React 前端，以及包含商品与订单端点的 Node.js 后端。他使用 Stripe 处理支付，并通过请 AI 协助参考 Stripe 的 API 文档来完成集成。经过两个星期的晚间开发，他就拥有了一个可运行的网站。

这位开发者表示，AI 大概承担了 70% 的编码工作，尤其是重复性的 UI 与表单处理；而他本人则专注于正确配置 Stripe、并对 UI 做品牌化微调。最终，用户可以浏览商品、加入购物车并完成购买——整个系统很大程度上是通过“氛围式编码（vibe coding）”构建的。这也说明在有文档可参考（或你把文档提供给模型）的情况下，集成外部服务（如 Stripe）在 AI 的指导下是可行的。

公司内部仪表盘
一名具备一定编程能力的产品经理，使用 AI 结对程序员为团队创建了一套内部分析仪表盘。按常规她需要等待工程资源，但借助 Replit 的 Ghostwriter 或 GitHub Copilot 等工具，她自己就完成了一个基础 Web 应用。AI 帮助她搭建了用于查询数据库（使用安全的只读凭证）的简易 Flask 后端，以及用 Vue.js 展示图表（依赖某个图表库）的前端。她描述每张图的含义（如“随时间变化的总注册量”“按地区的活跃用户”），AI 则编写对应的 SQL 查询与图表代码。

整个过程历经数周的反复尝试与测试，最终她交付了可用的仪表盘。代码质量未达企业级，但由于是内部使用，也能满足需求。更重要的是，她在极短时间内为团队赋能。这个例子说明 AI 工具能让非专业的程序员产出有用的 Web 应用，打通原本可能长期积压的工作。这也是第 10 章将讨论的“程序员职能的拆解（unbundling of the programmer）”的一个例证——如今个人更容易为自己或团队打造专用软件。

初创公司的最小可行产品（MVP）
一家由两位联合创始人（业务 + 技术）组成的小型初创公司需要一个面向投资人的 MVP Web 应用。技术联合创始人广泛使用“氛围式编码”，以创纪录的速度完成了 MVP。借助 AI 助手，他用 Next.js 搭建了 SSR 的 React 前端，并配以简洁的 Node API。他还让 AI 实现了诸如社交登录（AI 编写 OAuth 流程）、图片上传（AI 集成云存储 API）以及产品内的 AI 功能。他们甚至请 AI 协助集成一个来自某 API 的 NLP 模型。几个月内，一名开发者完成了通常需要一个小团队四到六个月才能交付的工作。最终产物虽略显“拼凑”，但能够演示，甚至可以让部分内测用户入驻平台。

后来当两位创始人继续招聘开发者来打磨产品时，新成员普遍能看懂 AI 写的代码，但为了可扩展性仍对不少部分进行了重构。这也说明 AI 能很快带你进入第一阶段，但当你走向下一阶段时，需要投入精力提升质量。

这些故事虽是个案，但与业界正在浮现的模式相吻合。尤其在 Web 开发领域，需要把众多组件“连线”在一起，AI 带来的效率提升非常明显。微软等机构报告的研究表明，使用 AI 的开发者完成任务的速度显著快于未使用者。
不过也有一些警示：有人可能将 AI 生成、但存在安全漏洞的 Web 应用直接投产，因为并未完全理解代码。这再次强调测试与审查的必要性。

结论
在 AI 协助下构建 Web 应用正在成为主流做法。它并不会消除对熟练开发者的需求，而是对其进行增强：开发者仍需规划架构、保证正确性、处理复杂或新颖的逻辑；而 AI 负责大量将各部分“粘合”在一起的样板化代码。我们刚刚走过的端到端流程——从脚手架、到前端、到后端、再到测试——表明只要贯穿始终地应用人类判断与专业能力，Web 开发的几乎每一步都能被 AI 加速。

总结与下一步

在本章中，你看到了“氛围式编码”如何延展到全规模的 Web 应用开发。把 AI 当作“随叫随到的结对程序员”，你可以并行推进前后端任务，以自然语言描述生成组件与 API，并将原型应用迭代到接近生产质量。成功的关键包括：清晰表达意图（让 AI 明白你每一步想要什么）、仔细核验（捕捉 AI 输出中的问题）、以及不仅让 AI 生成代码，还要用它来头脑风暴数据模型与编写测试。

本章也探讨了：在 AI 的加持下，开发者如何有效地担当全栈工程师的角色——当你不熟悉某些领域时，AI 通过建议代码来弥补知识缺口。这大幅缩短了常见功能的开发时间，在某种程度上也让开发更加“普惠化”，使个人无需大团队就能创建定制的 Web 解决方案（这一主题将在第 10 章重访）。

AI 并不能替代对需求的理解或对质量的保障；它做的是加速执行。
当你的 Web 应用跑起来之后，下一个关注点是确保其安全、可靠、可维护。第 8 章将深入 AI 生成代码库的安全与可靠性挑战：识别常见的易漏漏洞、如何审计与修复，以及一套最佳实践（比如本章已开始应用的测试与评审），以确保“用 AI 快速前进”的同时“不把东西弄坏”。本质上，我们将从“构建”转向“加固”，让你的“氛围式编码”软件能经受真实世界的环境与威胁考验。