Vibe Coding 开发工作流实战：从意图描述到工程化交付
Vibe Coding 这个词最早由 Andrej Karpathy 于 2025 年初提出，大意是"跟着感觉写代码"：开发者不再逐行敲代码，而是用自然语言把自己的想法、意图甚至是模糊的直觉告诉 AI，让它把代码生成出来，再由人在关键节点上把控方向、做取舍。这个概念流行至今，已经从个人实验演变为团队级的工作流范式。但很多团队在实践过程中发现，Vibe Coding 真正的难点不在"让 AI 写代码"本身，而在于怎么把自己的上下文管理好、把项目约束传达到位、把生成结果验证闭环。本文从工作流方法论、上下文管理、团队协作三个层面，拆解一套可落地的 Vibe Coding 工程实践。
一、Vibe Coding 不是摆烂编程
首先要纠正一个普遍误解：Vibe Coding 不等于"不会写代码的人瞎指挥 AI"，更不是"把迭代交给 AI，自己对着屏幕输出 vibe 开盲盒"。它本质上是一套新的协作范式：你把自己的意图、背景、约束用自然语言描述清楚，让 AI 生成代码，再由你负责验证、修正和整合。
传统开发流程里，从需求到代码要经过需求文档、技术设计、接口约定、编码实现、自测联调这么长一条链路。每一步都要有人手动转译，任何一环信息衰减，后面就全是坑。Vibe Coding 把中间的转译环节大幅压缩了：你直接用自然语言把需求讲清楚，AI 直接产出实现方案和代码，你再通过运行结果反馈修正。换句话说，传统开发的重心在"写代码"，Vibe Coding 的重心在"描述清楚要什么、判断 AI 给的到底对不对"。
这也解释了为什么很多老工程师上手 Vibe Coding 很快，反而一些新手用起来翻车频出——不是他们不会说，而是他们还没有能力判断 AI 给的代码是不是真的对。写代码考验的是语法能力和框架熟练度；描述清楚要什么考验的是结构化表达能力；判断对不对考验的是技术判断力和系统全貌把握能力。这三件事的难度完全不在一个量级。
二、五条核心原则：让循环保持清晰
Vibe Coding 的官方方法论可以概括为五条原则，它们比写一个完美的首轮提示词更重要。
第一，从目标开始。好的 Vibe Coding 会话从好的产品对话开始：这个应用给谁用？他们应该能做什么？什么让它变得有用？在让 AI 动手前，先描述你期望的结果，给 AI 一个产品目标，而不是一个孤立的任务。你不需要知道技术实现细节，先说清楚"应用跑起来之后应该是什么样子"。
第二，小切片构建。一个切片是产品中足够完整可以试用的部分。比如一个烘焙网站的第一个切片可以是：带今日特惠的首页、一个餐饮预订表单、移动端友好的布局。这足够验证想法。避免一次要求整个产品——大请求难以审查、容易被误解。第一个切片跑通后，再加下一个。
第三，管理上下文。上下文是 AI 理解你需求的信息：应用给谁用、解决什么问题、现在该包含什么、什么要留到以后、什么不该改变、风格和品牌的备注。管理上下文意味着在正确的时间给正确的信息。如果延续同一个功能，留在同一会话里让 AI 复用之前的决策；如果开始新功能或会话变得嘈杂，最好用简短摘要开新会话。
第四，审查与测试。AI 能构建，但由你决定结果是否可用。每次有意义的改动后，打开应用像目标用户那样使用它，不要只读 AI 说它改了什么。试着走完整条主路径，检查页面是否合理、移动端是否正常、有没有重要功能被破坏。
第五，用反馈改进。第一版切片是草稿，这很正常。告诉 AI 保留什么、改什么、删除什么、下一步试什么。好的反馈是具体的，保护已经工作的部分同时改进一个点。当切片跑通，循环回去构建下一个小切片。
三、上下文管理：全局 MD 文档作为"项目宪法"
Vibe Coding 翻车现场最常见的根因几乎都是同一个：AI 记不住项目规则。你在这一轮会话里告诉它"我们项目用统一的响应体"，它下一条回答的时候确实记住了；但你把对话关掉，第二天重新开一个会话，它又忘得干干净净。单个会话的上下文窗口是有限的，你不可能每次聊天都重复一遍全项目规范。
这个问题的解法是全局 MD 文档。主流工具都支持在项目里放一个规则文档，每次 AI 回答问题时自动把它作为上下文的一部分加载——相当于给 AI 立了一部"宪法"，所有行为都在这个框架里运行。不同工具支持的文件名略有差异，比如 AGENTS.md、CLAUDE.md 等，放在项目根目录即可被自动识别。
一份优秀的全局 MD 文档要短、准、可执行。网上有人把规则文档写成万字长文，结果 AI 每次对话都要读一遍，上下文浪费严重，反而影响生成质量。我的经验是控制在 150 行以内，结构包括：项目名称与定位（一句话）、技术栈（语言、框架、关键依赖、包管理工具）、目录结构（各目录职责边界、新增代码放哪里）、代码规范（分层、命名、引用方式、返回体、异常、日志约定）、常用命令（启动、测试、构建）、已知问题与约定（需要避开的坑、待重构方案）。
文档要跟着项目迭代。每完成一个比较大的迭代就检查一遍文档，过时的规则比没有规则更可怕。如果项目已经从 MySQL 迁到了 PostgreSQL 但文档里没改，AI 就会继续按 MySQL 语法生成代码，你还要花时间排查莫名其妙的报错。所以每次技术变更，第一件事就是更新全局 MD 文档。
还有一个实用技巧：在文档里明确写出"生成的代码必须符合上述规范，不要自行引入新的模式"。这句话相当于给 AI 下达一道元指令，让它在思考代码方案时优先检索文档里的约束，实测下来能明显提高规则遵守率。
四、提示词工程：让生成质量翻倍的五种写法
Vibe Coding 的提示词工程本质上是"高情商沟通加结构化表达"。有几个被验证有效的写法。
第一，具体化。指定文件、场景、偏好。"给 foo.py 写一个测试，覆盖用户未登录时的边界情况，不用 mock"比"给 foo.py 加测试"强得多。第二，给出参照。指向已有的代码模式。"看 HotDogWidget.php 理解组件模式，按同样的结构实现日历组件，只用项目已有的库"比"加一个日历组件"有效。第三，描述症状而非命令修复。"用户反映 session 超时后登录失败，检查 src/auth/ 的 token 刷新逻辑，写一个能复现问题的 failing test，再修复它"比"修复登录 bug"高效。第四，用 @ 引用文件而不是描述路径。第五，让 AI 自己获取上下文。
描述需求时可以套用四段式：背景（给谁用、解决什么问题）、功能（明确列出期望的行为）、边界（哪些情况需要特殊处理，比如输入为空、网络超时、数据异常）、风格（界面偏好、交互习惯、代码风格偏好）。你的描述越接近"代码背后的逻辑"，它生成的东西就越靠谱。
五、验证闭环：Vibe Coding 可靠性的基石
Vibe Coding 最大风险是你看不懂 AI 写了什么。常见问题包括权限错误、接口缺校验、移动端错位、依赖过多、本地能跑但线上失败。解决办法是把 Vibe Coding 变成"生成加验证"的闭环：能说明为什么改、改了哪些文件、如何验证、失败时如何回退。
验证方法包括：测试用例，比如"写 validateEmail 函数，用例：user@example.com 返回 true，invalid 返回 false"；截图对比，截图当前效果与目标设计图对比列出差异并修复；命令输出，修复后运行 npm run build 确认无报错。提供验证标准是提升质量最有效的单一动作。没有验证标准，AI 可能生成"看起来对但实际跑不通"的代码。
还有一个关键约束：AI 在自修时可能会为了"让测试变绿"而篡改测试本身。项目规则里应该明确写"禁止修改测试用例来适配代码，只能修改代码去满足测试"。在这一条约束下，AI 的行为会收敛很多。
六、从 Vibe Coding 到 Agentic Engineering
当 Vibe Coding 从个人项目走向团队协作和生产系统，就必须引入工程约束。GitHub 上热度最高的 Vibe Coding 资源（claude-code-best-practice，超过五万星）副标题就是"from vibe coding to agentic engineering"。
两者的核心区别：Vibe Coding 靠感性描述、即兴迭代、手动看效果；Agentic Engineering 靠规格文档驱动、有明确验证标准、自动化测试加 CI 流水线。进阶的关键步骤是引入规范驱动开发（Spec-Driven Development）：先写 SPEC.md，再让 AI 按规格实现，最后自动验证。这解决了纯 Vibe Coding 可维护性差的核心问题。
团队协作层面，把全局 MD 文档放进仓库进行版本管理，任何规则变更走评审流程，让 AI 的"宪法"成为团队共识。Review 时除了代码的正确性和风格，还要多一层：确认被 Review 的代码是否完全符合项目规则，以及 AI 生成过程中的决策理由。可以让开发者在提交说明里附上给 AI 的提示词摘要，这样 Review 的人不仅能看代码，还能看出需求是怎么描述的、有没有带上关键约束。
七、适合场景与风险边界
Vibe Coding 最适合的领域是"低风险、高重复、逻辑直观"的项目：原型验证、CRUD 系统、自动化脚本、数据分析、学习编程。不适合的场景：嵌入式、底层驱动、性能敏感、安全敏感领域。AI 生成的代码往往"能跑但性能一般"，它会选择最稳妥最容易读的写法，而不是针对你的场景做极端优化。安全敏感代码需要你完全掌握每一行的行为，把控制权交给 AI 等于放弃了这种掌控力。
如果一定要在"爽快 vibe"和"可靠工程"之间找平衡，推荐"混合编程"模式：主线逻辑人工设计，支线功能交给 AI。你对整个系统的架构、模块划分、核心算法逻辑亲自动手设计；具体的、模式化的、重复性的代码生成工作，比如工具函数、数据访问层、接口封装、页面模板，全部丢给 AI。
Vibe Coding 不会取代工程师，它改变的是工程师的工作重心：从写代码转向定义意图、设计系统、制定校验规则、把控产品质量。它真正的价值不是"自动写代码"，而是构建一套自然语言驱动、运行时反馈、持续迭代的人机协同开发闭环。
