从"AI写代码我喝咖啡"到 Harness Engineering：Vibe Coding 不翻车的工程化生存指南

🎢 从"AI写代码我喝咖啡"到 Harness Engineering：Vibe Coding 不翻车的工程化生存指南

** TL;DR ：Vibe Coding 不是把键盘塞给 AI 然后自己去泡咖啡，而是你要搭建一套工程化流程**去驾驭 AI。否则，前期有多爽，后期屎山就有多高。

一、那个"甜蜜陷阱"：为什么 Vibe Coding 项目总是"先甜后苦"？

想象这样一个场景：

周一早上，你打开 Claude，丢过去一句："帮我做一个任务管理工具，要好看，要支持拖拽，要有暗黑模式。" 五分钟后，AI 哐哐哐生成了一个像模像样的项目。你看着屏幕上流畅的动画和整洁的代码，内心 OS 是："这就是未来吗？我可以去喝咖啡了。"

周三，你让 AI 加个用户登录。它加了。

周五，你让 AI 加个支付功能。它加了，但登录模块突然坏了。

第二周，你想优化一下首页加载速度，AI 一顿操作后，支付按钮不见了。

第三周，你看着满屏的"临时方案"和"TODO"，陷入了沉思。代码像意大利面条一样纠缠在一起，改一行崩三行。最后，你默默新建了一个文件夹：project_final_v2_really_final。

问题出在哪？ 不是 AI 不够强，而是你把 Vibe Coding 理解成了"外包给 AI"。

真相是 ：AI 是个超级能干的实习生，但它需要方向、边界和约束。没有这些，它就像一辆没有刹车的跑车------起步飞快，但撞上墙的时候也很猛。

这就是 Harness Engineering（驾驭工程化） 要解决的问题。前端开发有 Vite 做工程化，Vibe Coding 也需要自己的"脚手架"。

二、Harness Engineering：给 AI 套上"缰绳"

Harness Engineering 的核心思想就一句话：

你不是在替代自己写代码，而是在构建一套放大你判断力的系统。

AI 负责"写"，你负责"定标准、审边界、控质量"。这套流程分三个阶段，共九步。咱们一个个聊。

三、阶段一：定图纸------别急着敲代码，先当产品经理

步骤 1：像跟朋友聊天一样"导需求"

很多人一上来就说："给我做个电商网站。" 这太粗糙了。

正确的姿势是：把 AI 当成一个聪明但不懂你业务的朋友，把痛点讲清楚。痛点要足够痛、目前没解决、有市场价值。再讲讲目标用户是谁、在什么场景下用、你理想中的核心功能长啥样。

不用追求一次性完美，先把想法"倒"出来。AI 会帮你梳理、补充、甚至发现你没想到的坑。

步骤 2：把需求变成 PRD，并且写上"验收标准"

聊完之后，让 AI 输出一份结构化的 PRD.md，包含功能列表、用户流程、页面清单。

最关键的一步 ：每个功能后面必须跟一句------"做到什么程度算完成？"

比如：

❌ 错误示范："登录功能"
✅ 正确示范："登录功能：支持邮箱+密码登录；登录失败时提示'账号或密码错误'（不暴露具体是哪个错）；登录成功后跳转至用户之前访问的页面，若无则跳转首页；3次失败触发验证码。"

没有验收标准，AI 就会越来越发散。 今天它觉得登录页放左边好看，明天觉得放右边更酷，后天干脆给你加了个指纹解锁------因为你没告诉它"到此为止"。

步骤 3：提前锁定视觉和页面框架

在写逻辑之前，先定好 DESIGN.md。找 2-3 个参考网站，或者让 AI 生成几种风格方案。确定：

整体布局（侧边栏？顶部导航？）
风格倾向（极简风？数据密集型？）
配色和字体基调

为什么这一步不能省？ 因为如果你让 AI 一边写功能一边想 UI，它大概率会在第 10 个功能时"顿悟"："啊，我觉得之前的布局不合理，全部重写吧！"------然后你的代码就裂开了。

四、阶段二：打地基------技术决策要"早"且"狠"

步骤 4：明确项目的"四大约束"

在写第一行代码前，先回答这几个问题：

部署：本地跑？还是线上公开？
规模：用户量多少？要不要考虑并发？
数据：有没有敏感用户数据？要不要支付？
成本：性能和成本有没有上限？

把安全、性能、可用性、成本这四个非功能需求写清楚。否则，AI 默认会给你写一个"宇宙级通用方案"------本地小工具它给你上微服务，个人博客它给你加 Redis 集群。不是它坏，是它不知道你的边界在哪。

步骤 5：锁定技术栈------"适合"比"先进"重要

技术栈选择原则：越可验证越好。

不要追新，要求稳。比如：

前端：React 18 + TypeScript + Tailwind CSS
后端：Node.js + PostgreSQL
AI 交互：Claude 3.5 Sonnet

选定后，写进 claude.md（或类似的 AI 上下文文件），让 AI 知道"咱们家就用这套，别给我整花活"。

步骤 6：让 AI 出轻量架构草案

不要一上来就搞"领域驱动设计六边形架构"。让 AI 输出一个轻量的目录结构、核心模块划分、数据模型草稿。

比如：

bash 复制代码

src/
  components/    # 通用组件
  pages/         # 页面
  hooks/         # 业务逻辑
  utils/         # 工具函数
  types/         # 全局类型

重点是"先跑起来"，不是"先完美"。 架构可以演进，但一开始要有基本的分层意识，不然所有代码都会堆在 App.tsx 里。

五、阶段三：立规矩------文档是 AI 的"宪法"

步骤 7：把一切都固化成文档

现在的 AI Agent（比如 Cursor、Claude Code）都会读取项目根目录的上下文文件。把前面的成果写成几个核心文档，放在项目根目录：

文档	作用
`PRD.md`	产品需求，功能边界
`DESIGN.md`	视觉和交互规范
`ARCH.md`	系统架构，目录结构
`Project.md`	当前项目状态，已完成/进行中/待办

这些文档是 AI 的全局上下文 ，也是 Vibe Coding 的永久约束。AI 每次生成代码前都会读它们，确保不跑偏。

步骤 8：定开发规范和参考资料

给 AI 定规矩，比给人定规矩还重要：

代码规范：怎么命名？用函数组件还是类组件？
错误处理：API 报错怎么显示？要不要全局捕获？
API 规范：RESTful 还是 GraphQL？给几个样本接口做参考

小技巧 ：在项目中建一个 references/ 文件夹，放几个你认可的代码样本。AI 会模仿这些样本的风格，而不是自由发挥。

步骤 9：Git + 质量阀门------你的"时光机"和"安检门"

Vibe Coding 必须配 Git，而且要用得比传统开发更勤快。

六、Git 在 Vibe Coding 中的实战心法

AI 生成代码就像开盲盒，有时惊喜，有时惊吓。Git 是你的时光机，让你随时能"回到过去"。

🔧 `git reset --hard`：时光倒流，彻底重来

bash 复制代码

git reset --hard <commit-hash>

作用：HEAD 指针直接跳转到指定版本，工作区和暂存区的所有修改全部丢弃。

适用场景：AI 刚才那波操作把项目搞崩了，你想完全回到上一个稳定状态，重新写 Prompt。

⚠️ 注意 ：这是危险操作，未提交的修改会永久丢失。就像按了"格式化"按钮，干净利落，但不可撤销。

🧸 `git reset --soft`：温柔回退，保留成果

bash 复制代码

git reset --soft <commit-hash>

作用：HEAD 指针回退到指定版本，但保留暂存区和工作区的内容 。被回退的那几次提交的改动，会保留在暂存区里。

适用场景：AI 提交了 5 次代码，但逻辑有点乱。你想把这 5 次合并成 1 次更干净的提交，同时保留所有改动。

📌 科学小贴士 ：--soft 回退后，改动是在暂存区 （Index），而不是"进入暂存区之前"。你可以用 git status 看到它们已经被 staged，可以直接 git commit 重新组织，或者用 git restore --staged 把它们挪回工作区慢慢挑。

🛡️ 两道安全网

bash 复制代码

# 把文件从暂存区移回工作区（后悔药：我刚才不该 add）
git restore --staged readme.md

# 丢弃工作区的修改（危险药：这行代码我不要了）
git checkout -- readme.md
# 或者新版 Git 的写法
git restore readme.md

Vibe Coding 的 Git 建议：

每完成一个功能就 commit ，哪怕功能很小。AI 生成 50 行代码，你测完没问题，马上 git add && git commit -m "feat: AI生成登录表单"。
用分支做实验：让 AI 在新分支上"疯狂输出"，主分支保持干净。成功了再合并，失败了直接删分支。
Commit 信息写清楚：别全是"update"、"fix"，否则一周后你根本分不清哪个版本是"能用的"。

七、开发中的五个关键点（实战避坑指南）

虽然原文没展开，但根据血泪经验，这五个点你必须刻进 DNA：

1️⃣ 小步快跑，频繁验证

不要让 AI 一次写 500 行代码。把它切成 50 行一块的小任务，每完成一块就运行测试。AI 的上下文有限，小块代码质量远高于大块。

2️⃣ 保持上下文新鲜

AI 的"记忆力"（上下文窗口）有限。当你发现 AI 开始"失忆"（比如重复问同一个问题，或者忽略之前的规范），主动把相关文档贴给它，或者开启新会话。

3️⃣ 代码审查，人不退场

AI 写的代码，你必须看懂关键逻辑。不要当甩手掌柜。至少要看懂：这个函数输入什么、输出什么、有没有副作用。

4️⃣ 及时重构，拒绝"破窗效应"

看到烂代码，当场让 AI 重构。今天你觉得"先这样吧，能跑就行"，明天 AI 就会在这个烂基础上继续堆烂代码。Vibe Coding 的屎山，一天就能堆起来。

5️⃣ 把 Prompt 当代码来管理

你写给 AI 的 Prompt 也是项目资产。把常用 Prompt 保存在 prompts/ 文件夹里，版本化管理。好的 Prompt 复用率极高，别每次都从零开始编。

八、总结：Vibe Coding 的正确姿势

Vibe Coding 不是魔法，也不是外包。它是一种人机协作的新范式：

AI 是引擎，提供动力；
你是方向盘，决定方向；
Harness Engineering 是车架，保证你们不会散架。

记住这个公式：

好的 Vibe Coding = 清晰的需求（PRD）+ 明确的边界（规范）+ 频繁的验证（Git）+ 持续的审查（人）

前期多花 30 分钟写文档、定规范，后期能省下 30 个小时的重构时间。毕竟，"AI 写的代码能跑"和"AI 写的代码能维护"之间，隔着一个工程师的自觉。

最后，送大家一句话：

用 AI 写代码，你可以很快；但用工程化驾驭 AI，你才能走得又稳又快。

如果这篇文章对你有启发，欢迎点赞收藏，也欢迎在评论区分享你的 Vibe Coding 翻车/成功经验。咱们一起，把 AI 这头"野马"驯成"千里马"。 🐎

从"AI写代码我喝咖啡"到 Harness Engineering：Vibe Coding 不翻车的工程化生存指南