文档教程Vibe Coding示例工程【免费下载链接】vibe-vibeThe First Systematic Vibe Coding Open-Source Tutorial | From Zero to Full-Stack, Empowering Everyone to Build Products with AI | Live at: www.vibevibe.cn 首个系统化 Vibe Coding 开源教程 | 零基础到全栈实战让人人都能用 AI 开发产品 | 在线地址www.vibevibe.cn项目地址https://gitcode.com/datawhalechina/vibe-vibe点击查看免费下载导读本文基于 vibe-vibe 开源教程收录的《我们在 FAANG 是怎么做 Vibe Coding 的》一文原文入口还原大型科技公司一线团队把 AI 辅助开发引入生产环境的完整流程设计文档 → 设计审查 → 子系统拆解 → 冲刺规划 → TDD 驱动开发 → 代码审查 → 暂存验证。读完后你将理解AI 真正放大的是一套严谨流程而不是取代这套流程这句话的含义并能在自己的项目里复刻这套可落地的工程纪律。AI 辅助开发只能拿来做玩具项目进不了生产环境——这是流传甚广的一种说法。但来自 FAANG 一线工程师的实践经验表明这个判断并不成立。关键在于团队并没有因为引入 AI 就放弃流程恰恰相反AI 是在一套已经足够严谨的工程流程中才发挥出最大价值。本文将以该文章的工作流骨架为主线结合本仓库中真实存在的测试用例、API 实现与工程文档逐环节拆解这套生产级 Vibe Coding方法论。一、一切从技术设计文档开始先回答为什么值得做在 FAANG 团队的实践中一切仍然从技术设计文档开始而且这是前期投入最多的地方。整个过程分为两个阶段提案Proposal先说明这件事为什么值得做。这个阶段回答的是方向问题——功能与业务目标是否对齐、投入产出是否合理。系统设计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 - ReadGET /api/todos支持category分类与statusactive/completed过滤C - CreatePOST /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 测试金字塔决定每种测试的投入量并非所有测试都一样教程给出了经典的测试金字塔分层层级测什么速度数量单元测试纯函数、工具方法几毫秒最多集成/API 测试模块间协作、接口链路中等适量E2E 测试完整用户流程几秒到十几秒最少判断标准很简单如果这个逻辑不依赖 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?categorywork) 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) })注意测试文件中的两个细节vi.mock模拟数据库层——测试不依赖真实数据库只验证路由层的请求校验与响应行为这正是 API 测试快、稳、容易定位问题的原因状态码即契约——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 一致从main创建功能分支如feature/xxx在分支上隔离开发完成一个阶段就推送并创建Pull RequestPRReviewer 在 PR 的Files changed页面对每行 diff 做行内评论来回多轮直至双方满意通过后Merge到main并删除功能分支。PR 的价值不只是多一双眼睛它能捕获你自己看不到的盲区比如没有处理用户没有评分记录的情况这种边界Review 过程本身也是知识共享所有讨论留档可回溯。AI 可以帮你做第一轮 Self-Review检查逻辑错误、安全隐患、性能问题但最终的把关责任仍然在人——这与原文档最终把关依赖团队既有评审标准的表述完全同构。七、暂存环境验证合并之后、上线之前代码合并到main后还不会直接进入生产环境。FAANG 团队的做法是代码合并后还要先在暂存环境验证。只有暂存环境表现正常才会继续推进到生产环境。暂存环境Staging是与生产环境配置尽可能一致的预发布环境。它的核心作用是验证合并后的完整系统——包括数据库迁移、环境变量、构建产物、与其他服务的集成——在真实配置下是否正常。这一步抓住了本地开发和代码审查都覆盖不到的盲区在我电脑上能跑不等于在生产配置下能跑。本仓库的部署相关章节见 无服务器部署与 CI/CD 自动化也遵循同样的渐进思路。对于个人项目一个务实的简化版本是至少保证main分支始终处于可部署状态——大功能在分支上开发完、测试通过后再合并用户永远看到的是完整功能而不是半成品分支、PR 与团队工作流 对这一点有专门论述。八、总体效果严谨流程被 AI 放大而非取代原文档的作者给出了他所在团队的观测结果我们把 AI 纳入这套流程之后从功能提案到上线生产的周期大约缩短了 30%。对高要求团队来说这已经是非常可观的提升。需要说明的是这是作者基于其团队环境的经验数据不同团队、不同项目类型的实际收益会有差异。但值得关注的是这个数字从何而来——它不是因为让 AI 直接写代码而是因为设计文档阶段减少了方向性返工测试先行让任务边界清晰、验收标准明确AI 实现的一次通过率更高代码审查与 CI 自动化把问题拦截在合并之前而不是上线之后。换句话说AI 真正放大的是一套严谨流程而不是取代这套流程。快不等于随便——AI 压低了实现门槛也同步放大了规格不清、验证不足和质量纪律松动的代价。九、把 FAANG 工作流迁移到你的项目分层落地FAANG 的完整流程对个人项目或小团队可能显得过重但它的每一环都可以按比例缩放环节完整版大团队精简版个人/小团队设计文档提案 系统设计 子系统文档一份 PRD含 Out-of-Scope 与优先级参考 PRD 模板设计审查资深工程师评审会让 AI 先输出方案你确认后再写代码任务拆解PM/TPM 参与 backlog 规划把功能拆成离散任务逐个交给 AITDDCoding Agents 先补测试再实现核心接口先写测试再让 AI 实现Red-Green-Refactor代码审查至少两位开发者批准至少一次 PR 让 AI 做 Self-Review暂存验证完整 staging 环境合并前在干净环境跑一遍测试与构建两道自动化的防线尤其值得优先配置详见 自动化工作流Git Hooks如 Husky每次git commit前自动运行pnpm test测试失败就阻止提交——这是第一道防线把明显的问题拦截在本地CI如 GitHub Actionspush 和 PR 时在全新的干净虚拟机里安装依赖、构建、跑测试——这是第二道防线能暴露只在我电脑上能跑的环境差异。配置方式非常直接Husky 只需在.husky/pre-commit写入pnpm testGitHub Actions 则是一个简单的 workflow 文件包含actions/checkout、actions/setup-node、pnpm install、pnpm test四步。总结TL;DR回顾全文FAANG 团队 Vibe Coding 实践的核心可以浓缩为三句话设计先行先把设计文档和架构想清楚再按模块推进——PRD 的 Out-of-Scope 与优先级标注决定 AI 的产出边界测试先行先写测试再做实现——测试文件是人与 AI 之间可执行的契约一个接口至少覆盖正常、校验、权限、边界四类场景流程不放松代码审查、暂存验证、自动化防线一个都不能少——AI 放大的是严谨流程而不是取代严谨流程。AI 真正改变的不是要不要流程而是流程的每个环节可以更快、更彻底地执行。对本仓库教程的进一步延伸阅读可参见核心概念与范式演进栏目中的 Agentic Engineering有纪律的 AI 辅助开发、规范是新的源代码 等文章它们从不同角度印证了同一个判断速度必须受工程纪律约束。赞分享文档教程Vibe Coding示例工程【免费下载链接】vibe-vibeThe First Systematic Vibe Coding Open-Source Tutorial | From Zero to Full-Stack, Empowering Everyone to Build Products with AI | Live at: www.vibevibe.cn 首个系统化 Vibe Coding 开源教程 | 零基础到全栈实战让人人都能用 AI 开发产品 | 在线地址www.vibevibe.cn项目地址https://gitcode.com/datawhalechina/vibe-vibe点击查看免费下载相关推荐Vibe Coding 团队协作实战指南让 AI 编程从个人利器进化为团队生产力Vibe Coding 团队协作实战指南让 AI 编程从个人利器进化为团队生产力 团队使用 Vibe Coding 协作开发时除了沿用传统协作方法还能利用文档教程知识库人工智能Vibe Coding 团队协作实战指南统一规范、AI 工具协同与 Git 流程的完整方案Vibe Coding 团队协作实战指南统一规范、AI 工具协同与 Git 流程的完整方案 本指南来自 ai guide https://link.gitco文档教程知识库人工智能Vibe Coding 团队协作实战指南代码规范、AI 工具协同与 Git 流程完整体系Vibe Coding 团队协作实战指南代码规范、AI 工具协同与 Git 流程完整体系 多人一起用 Vibe Coding 做项目时如何让不同成员用 AI文档教程知识库人工智能上一篇PyPTO-Pro 迭代式方案设计从 SPEC 到 DESIGN.md 的 9 轮约束收敛方法论下一篇Hugo 模板函数 math.Pi 完全指南获取圆周率常量及其在模板中的工程实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考