企业官网建设流程全解析

• 文档
• 教程
• Vibe Coding
• 示例工程

导读：本文基于 vibe-vibe 开源教程收录的《我们在 FAANG 是怎么做 Vibe Coding 的》一文（原文入口），还原大型科技公司一线团队把 AI 辅助开发引入生产环境的完整流程：设计文档 → 设计审查 → 子系统拆解 → 冲刺规划 → TDD 驱动开发 → 代码审查 → 暂存验证。读完后，你将理解"AI 真正放大的是一套严谨流程，而不是取代这套流程"这句话的含义，并能在自己的项目里复刻这套可落地的工程纪律。

"AI 辅助开发只能拿来做玩具项目，进不了生产环境"——这是流传甚广的一种说法。但来自 FAANG 一线工程师的实践经验表明，这个判断并不成立。关键在于：团队并没有因为引入 AI 就放弃流程，恰恰相反，AI 是在一套已经足够严谨的工程流程中才发挥出最大价值。

本文将以该文章的工作流骨架为主线，结合本仓库中真实存在的测试用例、API 实现与工程文档，逐环节拆解这套"生产级 Vibe Coding"方法论。

一、一切从技术设计文档开始：先回答"为什么值得做"

在 FAANG 团队的实践中，一切仍然从技术设计文档开始，而且这是前期投入最多的地方。

整个过程分为两个阶段：

1. 提案（Proposal）：先说明这件事为什么值得做。这个阶段回答的是"方向"问题——功能与业务目标是否对齐、投入产出是否合理。
2. 系统设计（System Design）：只有在相关干系人认可方向之后，才进入正式的架构设计，补齐架构、边界、依赖关系，以及与其他团队的集成方案。

这一原则与本仓库教程第三章"PRD 文档驱动开发"一脉相承。在 PRD 模板 中可以看到，一份合格的文档至少需要覆盖：需求背景与目标（项目概述、核心痛点、用户故事）、需求范围（In-Scope / Out-of-Scope）、需求列表与优先级，再到方案概述（业务流程图、信息架构图）和细节方案。

其中有两个细节直接决定 AI 后续的产出质量：

• Out-of-Scope 必须写清楚：教程在 从 PRD 到代码 中指出，AI 不会"脑补"——如果不写"不要登录注册、不要云同步"，AI 会按训练数据中的"完整版待办清单"默认实现一堆多余功能。边界本身就是一种约束信号。
• 优先级必须标注：用 P0/P1/P2 标明功能优先级，防止 AI 把次要功能做得过度复杂。

关键认知：AI 严格按文档字面意思理解，每个字段都会影响它生成的代码。文档质量直接决定代码质量。

二、设计审查：在写代码之前暴露问题

设计文档完成后，团队不会直接进入开发，而是先过设计审查（Design Review）。

这个阶段的目标是尽可能早地暴露问题，让资深工程师把设计里的薄弱点挑出来——接口划分是否合理、边界是否清晰、与其他团队的依赖是否可控。过程可能并不轻松，但越早把问题摊开，后面的返工成本就越低。

这与本仓库教程倡导的"方案先行"实践完全一致。在 从 PRD 到代码 中，作者给出了一个可直接复用的工作方法：让 AI 先输出技术方案，确认后再写代码。

请先给出这个功能的技术实现方案，包括数据结构、接口定义、主要步骤。我确认后你再写代码。

对比直接让 AI 写代码，"方案先行"的价值在于：方向性错误在方案阶段就能被发现，而不是在写完全部代码后才发现要返工。设计审查就是把这个理念制度化——不是等 AI 写出代码再纠错，而是在动手之前就把设计拆开审视。

三、子系统文档：把接口、职责与交付边界写清楚

设计通过后，开发才算正式启动。接下来的几周，团队会继续把文档往下拆，为各个子系统分别补齐说明——把接口、职责划分和交付边界写清楚。

在大团队中，这意味着每个开发团队都有一份自己负责的子系统文档；在小团队或单人项目中，它的作用同样重要：子系统文档就是你交给 AI 的"契约"。

以本仓库的 demo 为例。在 demo-01-todo 的 API 路由实现 中可以看到清晰的分层：

• R - Read：GET /api/todos，支持category（分类）与status（active/completed）过滤；
• C - Create：POST /api/todos，接收title、category、dueDate，通过createTodoSchema.safeParse(body)做输入校验，非法请求返回 400，成功返回 201。

接口的职责边界一旦在文档中定义清楚，AI 生成的实现就无须猜测"这个参数应该叫什么、返回什么状态码"——测试文件本身就是一份可执行的接口规格说明。

四、冲刺规划与任务拆解：让 AI 只处理"清晰的工单"

随后进入 backlog 规划。开发者会与 PM、TPM 一起把工作拆成可执行的离散任务，明确：

• 每个任务的优先级
• 任务之间的依赖关系
• 由谁负责推进

这一步在 AI 时代的重要性被进一步放大。AI 适合执行的是"边界清晰、验收标准明确"的任务；而"把模糊需求变成稳定任务"正是人的职责。任务拆得越细，AI 单次执行的正确率越高，代码审查的压力也越小。

五、软件开发：TDD 优先，让 Coding Agents 先写测试再写实现

这是 AI 价值最集中的环节，也是原文档强调最多的部分。FAANG 团队的做法是：

我们采用测试驱动开发，所以我通常会先让Coding Agents为目标功能补上测试，再让它们参与实现。这样做的好处是，任务边界更清楚，验收标准也更明确。

5.1 为什么测试先行

测试先行意味着在写实现之前，先定义"什么是正确的"。本仓库教程 为什么需要测试 给出了最朴素的定义：测试是一张"安全网"，回答的问题是——以前能用的功能，改了别的代码之后还能用吗？这被称为回归测试。

自动化测试解决的不是"手动测试太慢"的问题，而是**"每次都要完整地、不遗漏地重复"这件事，人做不到但机器做得到**。机器不会做"我只改了评分，搜索肯定没事"这种判断——它只会老老实实检查每一个点。

5.2 测试金字塔：决定每种测试的投入量

并非所有测试都一样，教程给出了经典的测试金字塔分层：

判断标准很简单：如果这个逻辑不依赖 UI 就能验证，就不要用 E2E 测试。评分计算对不对用单元测试，接口返回数据对不对用集成测试，用户能不能点按钮完成操作才用 E2E。

5.3 实战：一个接口至少要覆盖四类场景

在 API 测试与 E2E 测试 中，教程给出了一个接口测试的黄金标准——至少覆盖四类场景：正常路径、参数校验、权限控制、边界情况。

本仓库 demo-01-todo 的测试文件 就是这套思路的直接落地：

// 正常路径：返回 200 和 todo 列表 it('应该返回 200 和 todo 列表', async () => { const request = new NextRequest('http://localhost/api/todos') const response = await GET(request) expect(response.status).toBe(200) }) // 正常路径 + 参数：支持按分类过滤 it('支持按分类过滤', async () => { const request = new NextRequest('http://localhost/api/todos?category=work') const response = await GET(request) expect(response.status).toBe(200) }) // 正常路径：创建成功返回 201 it('应该创建新 todo 并返回 201', async () => { const response = await POST(request) expect(response.status).toBe(201) }) // 参数校验：标题为空返回 400 it('标题为空时应该返回 400', async () => { const response = await POST(request) expect(response.status).toBe(400) }) // 参数校验：缺少标题字段返回 400 it('缺少标题字段时应该返回 400', async () => { const response = await POST(request) expect(response.status).toBe(400) })

注意测试文件中的两个细节：

1. vi.mock模拟数据库层——测试不依赖真实数据库，只验证路由层的请求校验与响应行为，这正是 API 测试"快、稳、容易定位问题"的原因；
2. 状态码即契约——201（创建成功）、400（输入非法）、200（查询成功），这些断言与 route.ts 实现 中createTodoSchema.safeParse(body)的校验逻辑一一对应。

测试配置见 vitest.config.ts，它通过resolve.alias把@指向./src，让测试与源码共享同一套导入路径约定。

5.4 TDD 与 AI 的配合方式

TDD 的经典循环是Red → Green → Refactor：先写测试（Red，测试失败因为代码还不存在）→ 写最少的代码让测试通过（Green）→ 优化代码结构保持测试通过（Refactor）。

当 AI 加入后，这个循环变成了一种高效的协作契约（详见 自动化工作流）：

告诉 AI："这是我写好的测试文件，帮我实现对应的 API，让所有测试通过。"

测试文件成了你和 AI 之间的"契约"——你定义行为，AI 实现行为，测试验证行为。这比"先写代码再补测试"高效得多，因为验收标准在实现之前就被定义好了，AI 不需要猜你想要什么。

但也要注意分工边界：你把控测试策略，AI 执行和补充。AI 会读代码库，已经实现的逻辑它都能测到；但"还没写进代码的业务规则"（比如"重复评分应更新旧记录"）需要你主动补充到测试里。

六、代码审查与合并：至少两位开发者批准

FAANG 团队对合并有一套硬性要求：

我们的流程要求代码至少经过两位开发者批准，才能合并到main。AI 也可以参与审查辅助，但最终把关仍然依赖团队既有的评审标准。

这与本仓库教程 分支、PR 与团队工作流 描述的 GitHub Flow 一致：

1. 从main创建功能分支（如feature/xxx），在分支上隔离开发；
2. 完成一个阶段就推送，并创建Pull Request（PR）；
3. Reviewer 在 PR 的Files changed页面对每行 diff 做行内评论，来回多轮直至双方满意；
4. 通过后Merge到main，并删除功能分支。

PR 的价值不只是"多一双眼睛"：它能捕获你自己看不到的盲区（比如"没有处理用户没有评分记录的情况"这种边界），Review 过程本身也是知识共享，所有讨论留档可回溯。AI 可以帮你做第一轮 Self-Review（检查逻辑错误、安全隐患、性能问题），但最终的"把关"责任仍然在人——这与原文档"最终把关依赖团队既有评审标准"的表述完全同构。

七、暂存环境验证：合并之后、上线之前

代码合并到main后，还不会直接进入生产环境。FAANG 团队的做法是：

代码合并后，还要先在暂存环境验证。只有暂存环境表现正常，才会继续推进到生产环境。

暂存环境（Staging）是与生产环境配置尽可能一致的预发布环境。它的核心作用是验证"合并后的完整系统"——包括数据库迁移、环境变量、构建产物、与其他服务的集成——在真实配置下是否正常。这一步抓住了本地开发和代码审查都覆盖不到的盲区："在我电脑上能跑"不等于"在生产配置下能跑"。

本仓库的部署相关章节（见 无服务器部署与 CI/CD 自动化）也遵循同样的渐进思路。对于个人项目，一个务实的简化版本是：至少保证main分支始终处于"可部署"状态——大功能在分支上开发完、测试通过后再合并，用户永远看到的是完整功能，而不是半成品（分支、PR 与团队工作流 对这一点有专门论述）。

八、总体效果：严谨流程被 AI 放大，而非取代

原文档的作者给出了他所在团队的观测结果：

我们把 AI 纳入这套流程之后，从功能提案到上线生产的周期大约缩短了 30%。对高要求团队来说，这已经是非常可观的提升。

需要说明的是，这是作者基于其团队环境的经验数据，不同团队、不同项目类型的实际收益会有差异。但值得关注的是这个数字从何而来——它不是因为"让 AI 直接写代码"，而是因为：

• 设计文档阶段减少了方向性返工；
• 测试先行让任务边界清晰、验收标准明确，AI 实现的一次通过率更高；
• 代码审查与 CI 自动化把问题拦截在合并之前，而不是上线之后。

换句话说，AI 真正放大的是一套严谨流程，而不是取代这套流程。快不等于随便——AI 压低了实现门槛，也同步放大了规格不清、验证不足和质量纪律松动的代价。

九、把 FAANG 工作流迁移到你的项目：分层落地

FAANG 的完整流程对个人项目或小团队可能显得过重，但它的每一环都可以按比例缩放：

两道自动化的"防线"尤其值得优先配置（详见 自动化工作流）：

1. Git Hooks（如 Husky）：每次git commit前自动运行pnpm test，测试失败就阻止提交——这是第一道防线，把明显的问题拦截在本地；
2. CI（如 GitHub Actions）：push 和 PR 时在全新的干净虚拟机里安装依赖、构建、跑测试——这是第二道防线，能暴露"只在我电脑上能跑"的环境差异。

配置方式非常直接：Husky 只需在.husky/pre-commit写入pnpm test；GitHub Actions 则是一个简单的 workflow 文件，包含actions/checkout、actions/setup-node、pnpm install、pnpm test四步。

总结：TL;DR

回顾全文，FAANG 团队 Vibe Coding 实践的核心可以浓缩为三句话：

1. 设计先行：先把设计文档和架构想清楚，再按模块推进——PRD 的 Out-of-Scope 与优先级标注决定 AI 的产出边界；
2. 测试先行：先写测试，再做实现——测试文件是人与 AI 之间可执行的契约，一个接口至少覆盖正常、校验、权限、边界四类场景；
3. 流程不放松：代码审查、暂存验证、自动化防线一个都不能少——AI 放大的是严谨流程，而不是取代严谨流程。

AI 真正改变的不是"要不要流程"，而是"流程的每个环节可以更快、更彻底地执行"。对本仓库教程的进一步延伸阅读，可参见核心概念与范式演进栏目中的 Agentic Engineering：有纪律的 AI 辅助开发、规范是新的源代码 等文章，它们从不同角度印证了同一个判断：速度必须受工程纪律约束。

• 文档
• 教程
• Vibe Coding
• 示例工程