别让你的 AI 项目沦为屎山——Vibe Coding 驾驭术全公开
一句话总纲：Vibe Coding 的本质，不是让 AI 替你写代码，而是把你的工程化思考，变成 AI 必须遵守的物理边界。
开篇：一个你迟早会遇到的场景
项目一开始用 AI 写得风生水起，三五天就把核心功能跑通了。你信心满满继续堆料，可越往后代码越乱，修一个 bug 带出三个新问题，最后整个项目像一座摇摇欲坠的纸牌屋，轻轻一碰就全线崩溃。
很多人把锅甩给 AI：“肯定是模型还不够强”。但真正的问题从来不在 AI 是否足够聪明——而在于你根本没有建立一套驾驭 AI 的工程流程。
前端工程化有 Vite、Webpack 来管事，AI 开发同样需要一套工程化神经中枢。这套中枢，就叫 Harness Engineering（驾驭工程）。
这篇文章会给你两样东西：一套可落地的完整工作流，和一套复习时能立刻抓住重点的记忆骨架。每个阶段结尾都有「记忆锚点」，全文结尾有自测清单。你可以先通读，之后复习只看锚点和清单。
第一章：AI 项目为什么会变成屎山？
在讲流程之前，先挖病根。知其所以然，才能记住怎么做。
三大底层成因
AI 项目快速沦为屎山，本质是三个问题没解决：
1. 上下文漂移
对话轮次越多，AI 对最初需求的记忆越模糊，实现方式逐渐走样。你在第 3 轮说“用户要能登录”，到第 30 轮 AI 已经把它实现成了一个带 OAuth、带验证码、带双因素认证的怪物——而你只是想要一个简单的账号密码框。
2. 实现不一致
没有统一规范约束，同一个功能在不同模块能写出三种完全不同的写法。今天用 fetch，明天用 axios，后天又冒出个 XMLHttpRequest。维护成本指数级上升。
3. 边界缺失
没有明确的验收标准和非功能约束，AI 自动脑补“最优解”，最后往往是最脱离实际的解。你说“做个搜索功能”，AI 给你上了 Elasticsearch；你说“存点数据”，AI 给你设计了分布式数据库。
三大成因与工作流的闭环对应
| 底层成因 | 对应解决阶段 | 解决手段 |
|---|---|---|
| 边界缺失 | 定图纸 | PRD 写死验收标准、Design 锁死视觉 |
| 方向偏差 | 打地基 | 非功能需求 + 技术栈 + 架构草案 |
| 上下文漂移 + 实现不一致 | 立规矩 | 全局文档 + 开发规范 + Git 闸门 |
整套 9 步工作流，不是为了走流程而走流程，而是精准打击这三个病根。记住这张对应表，你就记住了整篇文章的逻辑。
把 Harness Engineering 讲透
前端工程化解决的是「多人协作代码不一致、构建流程混乱、质量不可控」的问题。
Harness Engineering（驾驭工程） 解决的是「人机协作上下文漂移、输出质量不稳定、项目不可维护」的问题。
前者规范人与人的协作，后者规范人与 AI 的协作。本质都是用工程化手段抵消熵增——AI 开发的熵增速度比传统开发快 10 倍，所以工程化的优先级也更高。
记忆锚点（第一章）：屎山三病根 = 上下文漂移 + 实现不一致 + 边界缺失。Harness Engineering = 用工程化抵消 AI 开发的熵增。
第二章：全局总览——四阶段工作流
先看全貌，再拆细节。
┌─────────────────────────────────────────────┐
│ 第一阶段：定图纸 │
│ 1. 聊需求 → 2. 写 PRD → 3. 定视觉 │
├─────────────────────────────────────────────┤
│ 第二阶段：打地基 │
│ 4. 非功能需求 → 5. 锁技术栈 → 6. 架构草案 │
├─────────────────────────────────────────────┤
│ 第三阶段：立规矩 │
│ 7. 固化文档 → 8. 开发规范 → 9. Git 闸门 │
├─────────────────────────────────────────────┤
│ 开发迭代：五律持续护航 │
│ 单功能迭代 / 测试先行 / 原子提交 / │
│ 持续审查 / 文档同步 │
└─────────────────────────────────────────────┘
主线记忆口诀：
定图纸想清楚做什么 → 打地基定清楚在什么约束下做 → 立规矩把约束固化成 AI 永远看得见的文档 → 开发中每次只做一点，做完就验，验完就提交。
下面逐阶段展开。每个步骤我都会给你：一句话重点 + 反面教材 vs 正确做法 + 产出物。
第三章：第一阶段·定图纸
本阶段核心目标：把模糊的想法，变成可衡量、可验收的明确标准。所有歧义，都消灭在写代码之前。
第 1 步：先聊需求，像吐槽一样把痛点倒干净
别一上来就写“帮我写一个电商网站”。你要做的第一件事，是像跟朋友吐槽一样，把痛点、目标用户、使用场景、理想中的核心功能全部倒给 AI。
原则：不用追求严谨，要追求信息量。
| 反面教材 | 正确做法 |
|---|---|
| “帮我写个博客系统” | “我是独立开发者，想做一个面向技术人的极简博客工具，支持 Markdown 写作、本地存储、一键导出；痛点是现有博客平台太重，本地笔记软件又不好发布……” |
进阶技巧：做一个「需求调研 Skill」
你可以建一个专门的 Skill：给它一批竞品链接、应用商店评论、社区吐槽帖，让它自动爬取并汇总 Top 5 用户痛点、高频吐槽点、未被满足的需求，再把结果喂给主模型。这样你的需求不是拍脑袋想的，是基于真实用户反馈的。
痛点必须满足三个条件：足够痛、没被解决、有市场。
第 2 步：输出 PRD，你来验收
把上一步的聊天记录喂给 AI，要求输出结构化的 PRD.md。
PRD.md 核心模块（可直接套用）：
1. 产品定位
2. 目标用户
3. 核心痛点
4. 功能清单（含优先级 + 验收标准）
5. 用户主流程
其中最重要的是「验收标准」。
什么叫验收标准？不是“用户能登录”这种废话，而要说清楚每个边界：
登录成功 → 跳转到登录前访问的页面（若无则跳首页），右上角显示用户头像； 登录失败 → 停留在登录页，表单上方显示红色错误“账号或密码错误”，保留用户已填的账号； 连续失败 5 次 → 账号冻结 15 分钟，显示倒计时。
| 反面教材 | 正确做法 |
|---|---|
| “用户能登录” | 写清成功跳转、失败提示、保留字段、锁定规则 |
没有验收标准，AI 会写得越来越发散。 这是 PRD 里唯一不能偷懒的部分。
第 3 步：提前锁定视觉与页面框架
如果你一边写功能逻辑，一边让 AI 自由发挥 UI，最后一定得到一套拼凑感极强的视觉碎片。
解决办法：提前定稿 Design.md。找 2-3 个参考网站，或让 AI 生成几套风格方案，你拍板确定：
- 布局系统（单栏？双栏？卡片网格？）
- 色调与字体系统
- 关键页面线框图（首页、列表页、详情页、空状态页）
- 动效原则（无动效 / 微交互 / 强动效）
目的：不让 AI 一边写功能，一边把 UI 推倒重来。
记忆锚点（第一阶段）：聊透 → 写死验收 → 锁死视觉。产出物：对话记录、
PRD.md、Design.md。
第四章：第二阶段·打地基
本阶段核心目标：锁定所有不可变的边界条件。技术选型、性能要求、成本约束，先定死再动手。
第 4 步：明确非功能需求，写死边界
必须在文档中显式回答四大非功能需求：
| 维度 | 要回答的问题 |
|---|---|
| 安全 | 数据传输是否加密？是否涉及身份认证？有无敏感信息存储？ |
| 性能 | 核心接口响应时间上限？首屏加载时间？并发数预估？ |
| 可用性 | 可接受的宕机时间？是否需要离线能力？ |
| 成本 | 服务器、第三方 API、数据库的预算上限？ |
| 反面教材 | 正确做法 |
|---|---|
| 什么都不提，让 AI 自由发挥 | “纯前端静态部署，首屏加载 < 2s，服务器月成本 < 10 元，不涉及用户敏感数据” |
不写清楚，AI 会默认“按最自由的方式发挥”，结果要么给你一个需要 128G 内存才能跑的项目，要么把用户数据明文存在前端 localStorage 里。
第 5 步：锁定技术栈，越可验证越好
“适合的才是最好的”。你用得熟、社区生态成熟、AI 训练数据充足的技术栈，就是最优解。
推荐组合：React + TypeScript + TailwindCSS
- React：组件化生态成熟
- TypeScript：给 AI 产出加上类型铁幕，杜绝
undefined is not a function - TailwindCSS：把样式约束在原子化 class 中，不让 AI 写飞掉的内联样式
把这些写入 CONTEXT.md（原文的 claude.md 建议改为不绑定特定模型的 CONTEXT.md，普适性更强）。
第 6 步：让 AI 出轻量架构草案
让 AI 基于 PRD 和技术栈，产出 ARCH.md。
ARCH.md 核心模块（可直接套用）：
1. 技术栈说明
2. 目录结构与职责
3. 核心模块依赖关系
4. 数据流方案
5. 组件划分原则
关键点：这份草案不用完美，它的意义在于让 AI 之后的每次代码生成都往同一个盒子里填，而不是每次都重新发明盒子。
记忆锚点（第二阶段）：边界 → 技术 → 架构。产出物：边界文档、
CONTEXT.md、ARCH.md。
第五章：第三阶段·立规矩
本阶段核心目标：把所有规则固化成文档。让 AI 的每一次生成，都在同一个框架内跳舞。
第 7 步：固化全局上下文文档
当前大模型最怕上下文窗口污染和记忆丢失。必须把前面的智慧固化到项目根目录：
/project-root
├── PRD.md # 产品需求文档
├── ARCH.md # 系统架构文档
├── Design.md # 设计规范文档
├── Project.md # 当前项目阶段文档
├── CONTEXT.md # 全局技术栈与代码规范
└── reference/ # 参考资料文件夹
Project.md 核心模块：当前版本号 → 本次迭代目标 → 已完成功能 → 已知问题 → 下一步计划。
为什么写文档不是形式主义？——文档锚定效应
大模型对话有强烈的首因效应：对话开头注入的结构化文档，会成为整个生成过程的「锚点」，后续输出都会围绕这个基准波动；而零散的口头需求，会随着对话轮次增加被快速稀释。这就是为什么聊到后面 AI 会“失忆”——不是它记不住，是基准没了。
「喂文档」的具体实操方式（分场景）：
| 场景 | 方案 |
|---|---|
| 短对话 / 单次生成 | 对话开头直接粘贴核心文档关键内容 |
| 长周期项目 | 用 Cursor、Claude Projects 等工具，把项目文件夹作为工作区，AI 自动读取根目录文档 |
| 通用铁则 | 每次新开对话，第一句话永远是：“先读取根目录下的 PRD.md、ARCH.md、Design.md，严格按照文档要求开发，不要超出功能边界” |
第 8 步：定开发规范与参考资料夹
在 reference/ 文件夹里放三类东西：
- 代码规范样本：错误处理模式、API 请求封装风格、React 自定义 Hook 写法。给 AI 一份“标准答案”，它模仿得远比空口描述好。
- RESTful / API 接口规范：URL 命名规则、请求响应格式、状态码约定、分页格式。
- 外部库使用范例：依赖小众库时，放一个最小可运行 demo，AI 会基于它扩展，而不是凭空幻觉 API。
第 9 步：搞好 Git 和质量闸门
Git 回退：先把安全带系好
git log --oneline # 查看简洁提交历史
git reset --hard <commit> # 彻底回到干净版本，重写提示词
git reset --soft <commit> # 保留改动，回到暂存区之前
git reset --staged <file> # 取消暂存，修改仍在工作区
git checkout -- <file> # 丢弃工作区改动，用暂存区版本覆盖
两个易混淆命令的澄清：
git reset --staged <file>：取消暂存，文件从暂存区撤回到工作区，修改仍保留，只是不纳入本次提交。git checkout -- <file>：丢弃改动，用暂存区版本直接覆盖工作区，修改被彻底清除。
踩坑提醒：
不要等代码烂到没法收拾才想起回退。只要连续 2 次 AI 生成的结果都偏离预期，立刻
git reset --hard回到上一个健康版本，重写提示词。 90% 的情况都是上下文已经歪了，越修补窟窿越大。
进阶用法：用 Git 做 Prompt AB 测试
同一个功能，用两种不同的提示词生成两个版本，分别 commit，然后对比效果选最优。相当于用 Git 做提示词实验的版本管理。
质量闸门定义：
- 提交前必须通过 lint 检查和类型检查（
tsc --noEmit） - 必须可运行
- Commit Message 格式固定（如
feat: add login form validation）
记忆锚点（第三阶段）：文档即上下文 → 规范即样本 → Git 即保险。产出物：根目录五大文档、
reference/文件夹、质量闸门。
第六章：开发中五律
本阶段核心目标：每次只做一点，做完就验，验完就提交，不让坏味道发酵。
| # | 名称 | 一句话动作 | 价值 |
|---|---|---|---|
| 1 | 单功能迭代 | 一次只让 AI 做一个可验证的功能点 | 杜绝隐式耦合 |
| 2 | 测试先行 | 把测试用例写进 Prompt | 用预期输出约束生成，结果可直接验证 |
| 3 | 原子提交 | 每完成一个小增量就 Commit | 把回退粒度拉满，每次交互都可撤回 |
| 4 | 持续审查 | 定期让 AI 审查代码 + 重构 | 不让坏味道发酵 |
| 5 | 文档同步 | 代码改到哪，文档更到哪 | 不让上下文过期 |
逐条展开：
1. 单功能迭代（One-Feature-at-a-Time）
| 反面教材 | 正确做法 |
|---|---|
| “帮我把用户中心和订单系统一起做了” | “先实现用户信息展示组件，数据可以写死，能独立跑通就行” |
一个功能点 = 一个分支 = 一次 Commit。
2. 测试先行（Test-First as Prompt）
把测试用例写在 Prompt 里：“实现函数 validateEmail，要求：输入 "test@.com" 返回 false，输入 "a@b.c" 返回 true，空字符串返回 false……” AI 会因为有具体期望输出而写得更精准，你也能立即验证。
3. 原子化 Commit（Atomic Git Discipline）
每完成一个微小且可验证的增量就提交。原子化 Commit 配合 git reset，让回退粒度精确到单次 AI 交互，而不是整片功能。
4. 持续重构与 AI 代码审查（Refactor & Review Loop）
定期让 AI 以“代码审查员”身份读取近期 Commit，给出重构建议，然后立即执行重构并提交。
5. 文档与代码同步（Docs-as-Code）
任何架构、接口、业务规则的改变，都必须同步更新到对应 .md 文件并随代码一起提交。文档一旦过时，AI 下一次生成的代码就会基于错误上下文彻底跑偏。
（图片提示词：一双手在键盘上敲击，屏幕被分成五个面板，分别显示功能点清单、测试用例、Git 提交记录、代码审查注释和文档更新，面板内包含真实代码片段，科技感 HUD 界面，蓝色调）
记忆锚点（五律）：一点一做 → 先写测试 → 频繁提交 → 定期审查 → 文档同步。
第七章：一个完整案例贯穿全文
用一个极简项目——本地番茄钟工具——把 9 步串一遍。
| 步骤 | 番茄钟项目对应产出 |
|---|---|
| 1. 聊需求 | 痛点：“加班总忘记休息，现有番茄钟广告多、功能杂，只想安安静静计时” |
| 2. 写 PRD | 明确“番茄默认 25 分钟可修改、到点弹窗提醒、统计今日专注时长”，写清每个状态的验收标准 |
| 3. 定视觉 | Design 定调“极简风、单页面、无多余元素” |
| 4. 非功能需求 | “纯前端、无后端、首屏 < 1s、零成本部署” |
| 5. 锁技术栈 | React + TypeScript + TailwindCSS，写入 CONTEXT.md |
| 6. 架构草案 | ARCH.md：components/Timer、components/Stats、hooks/useTimer、utils/storage |
| 7. 固化文档 | 根目录五大文档齐全 |
| 8. 开发规范 | reference/ 放入 Hook 写法和 localStorage 封装范例 |
| 9. Git 闸门 | 初始化仓库，定义提交规范，每个功能点一次 Commit |
| 开发五律 | 先做 Timer 组件 → 写测试用例 → 提交 → 审查 → 更新文档 → 再做 Stats 组件 |
抽象流程一旦具象，立刻就能记住。
第八章：回应一个常见质疑
“写这么多文档，会不会反而拖慢速度？”
Vibe Coding 的效率，从来不是“写得快”，而是“少返工”。
前期多花 1 小时写文档，后期少花 10 小时改屎山。快而不对，等于白费；慢但稳，反而最快。
第九章：不同规模项目的适配方案
不是所有项目都要严格走完 9 步。按规模裁剪：
| 项目规模 | 适配方案 |
|---|---|
| 迷你项目（1 周内小工具） | PRD 精简成要点，架构不用太复杂，但**「原子化 Commit」和「单功能迭代」必须保留** |
| 中型项目（长期迭代的独立产品） | 严格执行 9 步流程，文档越全越好 |
| 多人协作项目 | 在基础流程上再加一层「文档评审」和「代码 Review」机制 |
结语：给 AI 套上缰绳，它才是千里马
Vibe Coding 从来不是让 AI 替代你的思考，而是把你工程化的思考，转化为 AI 可以永远遵循的物理边界。
那几份根目录下的 .md 文件，看似静态文本，实则是你驯服野马的缰绳；每一次 git reset 不是失败，而是对方向偏差的即时纠正。
下次打开终端准备开始新项目时，别急着敲下“帮我写一个……”。先把这 9 个步骤走一遍。你会发现，AI 还是那个 AI，但它产出的代码，突然就有了灵魂和秩序。
驾驭 AI，而非被 AI 驾驭。这才是 Vibe Coding 真正的内核。
本文所述工作流已在多个从 0 到 1 的独立开发项目中实测验证。如果你有更好的 Harness 实践，欢迎在评论区交流碰撞。
