核心论点：Vibe Coding 项目的成败，不取决于 AI 模型有多强，而在于你是否建立了一套工程流程去驾驭 AI。这套方法论，我称之为 Harness Engineering（驾驭工程）。
一、问题：为什么 Vibe Coding 项目总是"前快后崩"？
Vibe Coding 的典型曲线是这样的：前期项目推进极快，几天就能搭出一个像模像样的原型；但越往后，代码越乱，变更成本越来越高，最终整个项目变成一座"屎山"，越改越差，直至崩盘。
问题出在哪里？
不是 AI 不够强。问题在于一个普遍的误解——很多人以为 Vibe Coding 就是把活直接丢给 AI，然后自己去喝咖啡。
真正的问题是你缺了一套驾驭 AI 的工程流程。就像一个建筑工地，你有了全世界最好的工人（AI），但没有图纸、没有施工标准、没有质量检查，盖出来的楼一定会塌。
二、解法：Harness Engineering 三层金字塔
┌─────────────────┐
│ Harness │
│ Engineering │
│ 驾驭AI的工程流程 │
└────────┬────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ 开发前 │ │ 开发中 │ │ 质量闸门 │
│ 规划即一切 │ │ 5个关键点 │ │ Git 守门 │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ 定图纸 │ │ 小步迭代 │ │ 版本回退 │
│ 打地基 │ │ 上下文管理 │ │ 变更追踪 │
│ 立规矩 │ │ 验收闭环 │ │ 代码审查 │
└───────────┘ └───────────┘ └───────────┘
整个 Harness Engineering 体系由三大支柱构成：开发前的 9 步规划（定图纸→打地基→立规矩）、开发中的 5 个关键点、以及以 Git 为核心的质量闸门。下面逐层展开。
三、第一支柱：开发前的 9 个步骤——"规划就是一切"
这是金字塔最厚实的底座。规划阶段投入的时间，会在开发阶段十倍返还。
阶段一：定图纸（需求与设计定型）
在写第一行代码之前，先把"要做什么"彻底定下来。
第 1 步：导需求——像跟朋友聊天一样
不要一上来就写代码。先跟 Claude 聊天，把你脑子里的想法全部倒出来：
- 痛点：这个问题够不够痛？是不是还没被解决？有没有真实市场？
- 目标用户：谁会用它？什么场景下用？
- 核心功能：你理想中它应该能做什么？
这一步不追求严谨，追求的是信息量和覆盖度。你的目标是把脑中模糊的想法变成 AI 能理解的语言。
第 2 步：输出 PRD 文档，你来验收
让 AI 把上一步的聊天内容整理成结构化的 PRD 文档（产品需求文档），至少包含：
- 功能列表
- 用户流程
- 页面清单
- 每个功能的验收标准（边界定义）
最后一条最关键。举个例子——
❌ 不合格的写法：「用户能登录。」
✅ 合格的写法：「登录成功后跳转到首页（若用户从某个需登录页面被拦截，则跳回原页面）；登录失败时，提示具体的错误原因（密码错误 / 账号不存在 / 网络异常），错误提示展示在输入框下方，红色文字。」
没有验收标准，AI 会越写越发散。 它会在一个功能上不断"优化"而不知道什么时候停，最终代码膨胀失控。
第 3 步：提前定好视觉和页面框架
在逻辑代码之前，先把 UI 风格确定下来。方法有两种：
- 找 2-3 个参考网站，告诉 AI "照这个感觉来"
- 让 AI 生成几种不同风格的方案，你来选
这一步要敲定的事：页面布局、内容分区、整体风格（简约风 / 豪华风 / 科技风）。
为什么这一步必须在写功能之前做？ 因为如果你不提前锁定 UI 方向，AI 会在写功能逻辑的同时不断地把 UI 推倒重来——每一次重来都是一次返工，而且是连锁反应式的返工。
阶段二：打地基（约束与架构定型）
图纸有了，现在要确定"在什么条件下盖、用什么材料盖"。
第 4 步：明确项目边界和非功能需求
这些问题是 AI 不会主动问你的，但你不说清楚一定会返工：
| 维度 | 要明确的问题 |
|---|---|
| 部署方式 | 纯本地跑？还是线上公开服务？ |
| 用户规模 | 几个人用？还是几千人并发？ |
| 数据合规 | 有没有用户数据？是否需要隐私合规？ |
| 性能上限 | 页面加载时间有硬性要求吗？ |
| 成本约束 | 能用付费 API 吗？预算上限是多少？ |
安全、性能、可用性、成本——这四个非功能性需求不写清楚，后面一定会返工，而且是结构性的大返工。
第 5 步：锁定技术栈，越可验证越好
选技术栈的原则不是"最先进"，而是"最适合 + 最可验证"。
- 适合：团队熟悉、社区活跃、生态成熟。比如
React + TypeScript + TailwindCSS就是一个经过大量项目验证的稳健组合。 - 可验证：选了就能快速跑起来看效果，而不是配环境就要三天。
将技术栈写入 claude.md，让它成为 AI 的全局约束——AI 不会在你没授权的情况下引入新的依赖或框架。
第 6 步：让 AI 出轻量架构草案
不要一上来就画 UML 类图。让 AI 输出一份轻量架构草案，覆盖四个维度：
- 目录结构怎么分层（如
components/、hooks/、services/、utils/） - 核心模块有哪些（认证模块、数据模块、UI 组件库）
- 数据模型长什么样（关键实体和它们之间的关系）
- 有哪些核心组件（页面级组件、可复用组件）
这一步的目标不是出一份完美的架构文档，而是让 AI 和你对"系统长什么样"形成共识。
阶段三：立规矩（规则与文档固化）
前两个阶段产出了大量决策，如果不固化下来，AI 下一次对话就会忘掉 80%。
第 7 步：固化成文档——AI 的"永久约束"
把所有决策写成项目根目录下的 Markdown 文件，这些文件是 AI 的全局上下文：
项目根目录/
├── PRD.md # 产品需求文档（做什么、验收标准）
├── ARCH.md # 系统架构文档（怎么做、分层设计）
├── Design.md # 设计规范文档（视觉风格、组件规范）
├── Project.md # 当前项目阶段文档（进度、下一步）
└── claude.md # 项目级 AI 指令（技术栈、约束）
每当 AI 开始一轮新对话或新任务，这些文件会作为系统提示加载，形成对 Vibe Coding 的永久约束。AI 不会跑偏，因为约束就在它的上下文里。
第 8 步：定开发规范 + 建参考资料文件夹
好的代码不是靠"AI 自觉"写出来的，是靠规则约束出来的。至少要覆盖：
- 代码规范：命名约定、文件组织、注释原则
- 错误处理：统一的错误处理模式，不能让 AI 每个地方都即兴发挥
- API 接口规范：RESTful 规范、请求/响应格式、错误码约定
- 参考资料：给 AI 一个样本参考（比如一个好的组件实现），让它照着这个标准写
给 AI 一个"标准答案"作为参照物，比给它一百条规则更有效。
第 9 步：搞好 Git 和质量闸门
Git 不仅仅是一个备份工具，它是质量的最后一道闸门。核心操作：
| 操作 | 场景 | 含义 |
|---|---|---|
git reset --hard | 代码彻底跑偏 | 丢弃所有修改，回到历史干净节点，重新写 prompt |
git reset --soft | 部分修改有问题 | 回退版本但保留工作区修改，局部调整后重新提交 |
git restore --staged | 暂存区放错了 | 将文件从暂存区移除，但保留工作区修改 |
git checkout -- <file> | 某个文件改坏了 | 丢弃单个文件的工作区修改 |
配合细致的原子化 commit，你可以在任何一步踩坑时无损回退，而不是带着一堆半成品代码硬着头皮往前走。
四、第二支柱：开发中的 5 个关键点
（原文此部分未展开，以下为核心要点补充）
- 小步迭代，每次只改一件事：一次 prompt 只让 AI 完成一个明确的功能点。改多了你审不过来，AI 也容易失控。
- 上下文管理：每次新对话都重新加载 PRD.md、ARCH.md 等上下文文件，确保 AI 始终在"规矩"内工作。
- 验收闭环：AI 每完成一步，立刻对照 PRD 中的验收标准检查。不通过就立刻修正，不要让偏差累积。
- 提交纪律：每完成一个验收通过的功能点，立刻 commit。小步提交 = 小步回退的能力。
- 渐进式重构：功能跑通后再让 AI 做一轮"代码整理"，消除重复、改善命名、提取公共逻辑——但不要在功能没跑通之前做这件事。
五、总结：一张图说清楚 Harness Engineering
你（决策者）
│
├── 定图纸 ──→ 需求 → PRD → 视觉框架
│
├── 打地基 ──→ 非功能需求 → 技术栈 → 架构草案
│
├── 立规矩 ──→ 文档固化 → 开发规范 → Git 闸门
│
└── 驾驭 AI 开发 ──→ 小步迭代 → 即时验收 → 原子提交
核心认知升级：Vibe Coding 不是你给 AI 当 PM，而是你当总工，AI 当工人。总工不画图纸、不定标准、不检查质量，再好的工人也盖不出好楼。
Harness Engineering 的本质就是——把"驾驭 AI"这件事本身，变成一套可复制、可验证的工程流程。
