一份关于 Harness Engineering（驾驭工程） 的完整工作流拆解

---

一、先说一个反直觉的真相 🧭

用过 Vibe Coding 的人，大概率都经历过同一个剧本：

前期项目推进得飞快，爽到飞起；越往后，代码越乱，慢慢堆成一座「屎山」；再改，越改越差，最后整个项目崩盘。

这时候大多数人会下结论：「是不是 AI 还不够强？」

但真正的问题，根本不在 AI 强不强。

问题在于一个认知误区——很多人以为 Vibe Coding 就是：

🚫 把这个活丢给 AI，然后自己去喝咖啡 ☕

如果你真这么干，AI 这匹「千里马」🐎 会立刻变成「脱缰野马」，跑得越快，撞得越惨。

Vibe Coding 的本质，不是「放马」，而是「驭马」。

你真正要做的，是构建一整套工程流程去驾驭 AI。这就是今天要讲的——

Harness Engineering（驾驭工程） 🎯

前端工程化用 Vite 兜底，AI 协作则用 Harness Engineering 兜底。

---

二、马具的第一根缰绳：Git，你的「时间机器」⏳

驾驭 AI 之前，你手里得先有一根随时能拉回头的缰绳。这根缰绳就是 Git。

理解 Git 的关键，是理解一个指针——HEAD：

概念	作用
HEAD 指针 🎯	指向你当前所在的分支、所在的版本

有了它，你就能在「历史长河」里自由穿梭，随时回退到任意版本：

# 回退到历史的任意版本
git reset --hard    # 丢弃目前的修改，直奔那个版本 → 仓库干净，重新写 Prompt
git reset --soft    # 不丢工作区修改，回退后进入「暂存区」→ 局部修改 text/title 还在

两句话记住区别：

• 🔨 --hard：一刀切，回到干净的那个版本，适合「写崩了，重来」。
• 🧈 --soft：温柔回退，工作区的成果还在，只是退回暂存区，适合「方向错了，但不想白写」。

还有两个日常操作，专门用来「反悔」：

git restore --staged <file>   # 把文件从「暂存区」撤下来（file 如 readme.md）
git checkout <file>           # 丢掉「工作区」的修改

💡 一句话心法：--hard 是「重新写 Prompt」，--soft 是「局部微调」。AI 生成得再快，你的缰绳也得随时在手。

---

三、核心框架：开发前 9 步，走完三个阶段 🗺️

规划就是一切。真正的 Vibe Coding，开发前要先走完 9 个步骤，分成三个阶段：

📐 定图纸  →  🏗️ 打地基  →  📏 立规矩
  (画清楚)      (打牢实)       (钉进墙)

---

📐 阶段一：定图纸（先别碰代码）

Step 1｜先「导需求」，再写代码 💬

像跟朋友聊天一样，把下面这些一股脑全倒给 AI：

• 痛点：足够痛、没解决、有市场
• 目标用户、使用场景、理想中的核心功能

不用追求严谨和信息量，这一阶段的唯一目标，是「把需求定下来」。

Step 2｜把需求整理成 PRD，你来验收 ✅

让 AI 输出一份结构化文档，至少包含：

• 📋 功能列表
• 🔀 用户流程
• 📄 页面清单

并且，每个功能都要补一句「边界」——到底做到什么程度才算完成？

❌ 错误示范：「登录成功」
✅ 正确示范：「登录失败提示什么？登录成功以后跳转到哪——首页？还是登录前的页面？」

没有验收标准，AI 就会写得越来越发散。这份文档就是 PRD.md。

Step 3｜提前定好视觉和页面框架 🎨

找 2–3 个参考网站，或让 AI 生成几种风格方案，提前敲定：

• 网页布局、页面有哪些内容
• 简约风还是豪华风？

目的只有一个：别让 AI 一边写逻辑，一边又把 UI 推倒重来。 这份文档就是 DESIGN.md。

---

🏗️ 阶段二：打地基

Step 4｜明确项目边界与非功能需求 🧱

先把这些「灵魂拷问」答清楚：

• 本地跑，还是线上公开？
• 用户量多少？
• 有没有用户数据、支付？
• 性能和成本有没有上限？

⚠️ 安全、性能、可用性、成本——这四个非功能需求不写清楚，后面一定会返工。

Step 5｜锁定技术栈，越可验证越好 🔧

适合的才是最好的，一个典型组合：

React + TypeScript + Tailwind CSS

Step 6｜让 AI 出轻量架构草案 🗂️

让 AI 先画出骨架，回答三个问题：

• 目录结构怎么分层？
• 核心模块有哪些？
• 数据模型长什么样？有哪些组件？

---

📏 阶段三：立规矩

Step 7｜把一切固化成文档 📚

现在的 Agent / LLM 交互，都会吃一个「文档」。把前面所有的成果，写到项目根目录：

文档	含义
PRD.md	产品需求文档
ARCH.md	系统架构文档
DESIGN.md	设计规范文档
PROJECT.md	当前项目文档

🔒 这些文档是 AI 的全局上下文，也是 Vibe Coding 的永久约束——它会被一直带着，跑偏了也拉得回来。

Step 8｜定开发规范 + 建参考资料文件夹 📁

• 代码规范
• 错误处理
• API 接口、RESTful 规范

💡 可以给一个「样本参考」，让 AI 有样学样。

Step 9｜搞好 Git 与质量闸门 ⚖️

把第二节讲的 Git 缰绳接进来，形成一道质量闸门：每一次 AI 的产出，都能被验证、被回退、被验收。

---

四、开发中的 5 个关键点 🔑

📌 原笔记到这里就中断了（只留了一个标题「开发中 5 个关键点」）。以下 5 点是我顺着前面的逻辑补全的、最贴合这套工作流的实践心法：

① 小步快跑，频繁提交 🏃
每次改动要小到「可验证、可回退」。AI 一次别生成一整个功能，一个组件一个提交。

② 先要方案，再要代码 💡
让 AI 先聊思路、再动手。方案对了，代码基本错不到哪去。

③ 文档是「活」的，不是「一次性的」🔄
代码每推进一块，PROJECT.md 就同步更新一次。文档一旦失真，缰绳就松了。

④ 一次只做一件事 🎯
一个 Prompt 只解决一个问题，防止 AI 发散、互相污染。

⑤ 用质量闸门持续验收 ✅
PR review、测试、lint 别等最后一次性补，每一步都过一遍闸门，屎山就堆不起来。

---

五、收个尾 🎁

把这套流程压缩成一句话：

Vibe Coding 省的是「写代码」的力，不是「做工程」的力。

AI 是千里马 🐎，跑得飞快，但方向、边界、验收标准这些「马具」，永远得由你来配。

定图纸 → 打地基 → 立规矩，九步走完再上马，AI 才能既跑得快、又跑得稳。