摘要
Vibe Coding越写越乱？问题不在AI，而是缺工程化流程。本文提出Harness Engineering理念，拆解定图纸、打地基、立规矩三阶段九步前置法，配合Git质量阀门，让AI代码始终可控。
一、越写越乱，问题出在哪里
Vibe Coding有一个典型的体验曲线：前30分钟高潮迭起，一个功能接一个功能地往外蹦，你甚至觉得"这AI太强了，写代码比我快十倍"；到了第2个小时，代码开始出现重复逻辑，组件之间耦合越来越深；第3个小时，你发现改一个按钮颜色，三个页面崩了，你甚至说不清这几个组件之间到底是谁在调用谁。
项目推进特别快，但越往后代码越乱，慢慢变成屎山。越改越差，最后整个项目崩盘。
很多人把锅甩给AI------"模型不够强""上下文不够长""幻觉太多"。但真正的问题不在于AI强不强，而在于：你把整个活直接丢给AI，然后就去喝咖啡了。Vibe Coding不是"AI替我干活"，而是"我构建一套工程流程去驾驭AI"。
这就是本文要讨论的核心概念：Harness Engineering（驾驭工程）。前端工程化用Vite，AI工程化用Harness。
二、Harness Engineering：不是管AI，是管流程
Harness这个词的本义是"马具"------缰绳、马鞍、马镫。一匹野马跑得再快，没有马具你骑不上去；一套马具，能让最温顺的马变成可控的交通工具。
Vibe Coding中的Harness Engineering，就是给AI这匹野马配一套马具。它不解决"AI能不能写出好代码"的问题，而是解决"AI写出的代码能不能持续被维护"的问题。
具体来说，Harness Engineering包含三层约束：
| 层级 | 约束内容 | 载体 |
|---|---|---|
| 需求层 | 功能边界、验收标准、不做的事 | PRD.md |
| 架构层 | 技术栈、目录结构、核心模块、数据模型 | ARCH.md |
| 规范层 | 代码风格、错误处理、API规范、参考样本 | 规范文档 + references/ |
这三层约束像三堵墙，把AI的发挥空间框在一个可控的范围内。AI在墙内可以自由发挥，但一旦想越界，文档就是它无法绕过的上下文。
三、定图纸：先别写代码，先把话说清楚
Vibe Coding最忌讳的行为是：打开编辑器，第一句话就是"帮我写一个XXX"。你连需求都没说清楚，AI只能靠猜，猜错了就返工，返工两轮代码就开始乱。
第一阶段"定图纸"有三个步骤。
3.1 导出需求：像聊天一样把想法倒出来
先别写代码，先和AI聊天。把痛点、目标用户、使用场景、理想中的核心功能，全部讲给AI。
注意，这一步不需要追求严谨。你要的是信息量，不是结构。就像和朋友吐槽一个痛点，把脑子里所有相关的东西都倒出来就行。AI擅长从混乱的信息中提取核心需求，这是它的强项，不要浪费。
这一步的产出不是文档，而是一段足够长的对话------AI会在这段对话中逐渐理解你想做什么。
3.2 PRD文档：把需求变成可验收的边界
让AI基于前面的对话，输出一份结构化的PRD文档。这份文档至少包含：
- 功能列表：每个功能是什么，用户如何使用
- 用户流程：用户从进入到完成任务，经过哪些步骤
- 页面清单：一共需要哪些页面，每个页面承载什么功能
最关键的一步是：每个功能补上验收标准。什么叫"登录功能完成"？不是"可以登录"四个字，而是：
- 登录成功后跳转到哪个页面？是首页还是登录前的页面？
- 登录失败后提示什么？密码错误和账号不存在是否区分？
- 密码输错三次后是否锁定账号？锁定多久？
- 是否支持记住密码？有效期多长？
没有验收标准，AI会写得越来越发散。今天往这个方向扩展一点，明天往那个方向扩展一点，三个月后你甚至不知道这个功能最初的设计意图是什么。
3.3 视觉与页面框架：提前锁定风格，避免UI反复重来
找2-3个参考网站，或者让AI生成几种风格方案。决定网页的布局、配色、字体、组件风格，然后输出一份 DESIGN.md。
这一步的目的是：不让AI一边写功能逻辑，一边把UI推导重来。如果风格不确定，AI在不同session中会生成不同风格的UI，第三次改版时整个页面就像拼接出来的。把风格定死，后续所有生成都围绕同一套视觉语言执行。
四、打地基：非功能需求和技术栈，越早决定越省钱
很多项目的崩溃不是功能没做对，而是地基没打好。第二阶段"打地基"同样是三个步骤。
4.1 明确非功能需求：四大维度必须写清楚
非功能需求，就是那些"用户看不到但系统必须满足"的要求。四个维度：
- 安全：是否需要登录？用邮箱还是手机号？是否有支付功能？用户数据如何保护？
- 性能：首屏加载时间上限？同时在线用户量？是否需要懒加载或分页？
- 可用性：本地运行还是线上公开？支持哪些浏览器？是否需要离线功能？
- 成本：API调用是否有预算上限？是否需要自建后端还是用BaaS？
这四个维度如果不写清楚，后面一定会返工。比如，你第三天才想起来"这个项目要上线"，那所有用 localStorage 存数据的地方都需要改成后端API，返工成本极高。
4.2 锁定技术栈：适合的就是最好的
选技术栈有一个原则：越可验证越好。不要被"这个框架很酷"绑架，而是选你或团队最熟悉的。React + TypeScript + TailwindCSS 是Vibe Coding的经典组合------React生态成熟，TypeScript提供类型约束让AI少犯错，TailwindCSS的原子类让样式生成高度可控。
技术栈决定后，写成 claude.md（或项目根目录下的规则文件），AI在每次对话中都会读取这份约束。
4.3 轻量架构草案：不要过度设计，但要有一张地图
让AI基于PRD和技术栈，输出一份轻量架构草案：
- 目录结构如何分层（components / pages / hooks / utils / services）
- 核心模块有哪些，各自负责什么
- 数据模型长什么样（用户、订单、商品等核心实体的字段定义）
- 有哪些组件，组件之间的父子关系
这份草案不需要完美，但必须有一张"地图"。有了地图，后续每次让AI生成代码时，你都知道这个新代码该放在哪个目录下，该和哪些模块交互。
五、立规矩：把约束固化成AI无法绕过的上下文
前两个阶段定义了"做什么"和"用什么做"，第三个阶段要解决"怎么做"和"做到什么标准"。
5.1 固化文档：项目根目录下的永久上下文
把PRD、设计、架构、当前状态整理成项目根目录下的几个文档：
bash
项目根目录/
├── PRD.md # 产品需求文档（功能清单 + 验收标准）
├── ARCH.md # 系统架构文档（目录结构 + 核心模块 + 数据模型）
├── DESIGN.md # 设计文档（视觉风格 + 组件规范）
├── Project.md # 当前项目阶段（已完成、进行中、待开发）
└── references/ # 参考资料文件夹（API文档、参考网站截图等）这些文档构成了Vibe Coding的全局上下文。每次新开一个对话，AI会读取这些文档，理解项目的全貌，而不是从零开始猜测。这就是"永久约束"的含义------文档在，约束就在，不受session切换影响。
5.2 定开发规范：让AI写出风格一致的代码
开发规范至少要覆盖：
- 代码风格：命名规范（camelCase / PascalCase）、缩进、注释风格
- 错误处理：try-catch的统一模式、错误提示的用户界面
- API接口规范：RESTful命名、请求/响应格式、错误码定义
- 组件规范：函数组件还是类组件、props类型定义、文件命名
给一个样本参考文件比写一百条规则更有效------AI更擅长模仿而非遵循指令。在 references/ 下放一个"标准代码示例"，AI会主动模仿这个文件的风格。
5.3 Git质量阀门：让每一次提交都可追溯
Git在Vibe Coding中扮演的角色不只是"版本管理"，而是质量阀门。
Git的三个关键操作在不同场景下的用法：
| 操作 | 场景 | 效果 |
|---|---|---|
git reset --hard |
AI生成了一堆乱代码，想全部丢弃 | 直接回到上一个干净版本，工作区清空 |
git reset --soft |
AI改了一些东西，但你想保留修改内容手动调整 | 回到指定版本，修改保留在暂存区 |
git checkout -- <file> |
某个文件被AI改坏了，恢复这个文件 | 丢弃单个文件的工作区修改 |
这三种操作构成了一套"后悔药"机制：--hard 是全部回退，--soft 是保留修改回退，checkout 是单文件回退。Vibe Coding的核心原则是：永远在可回退的状态下让AI生成代码 。如果AI生成的内容有问题，用 git reset --hard 回到上一个干净的commit，然后重新给出更精确的prompt，而不是在烂代码上修修补补。
实际操作流程：
csharp
# 开始一个功能前，先提交当前状态
git add . && git commit -m "feat: 完成用户列表页"
# 让AI生成代码
# ... AI生成了一堆代码 ...
# 如果结果满意，提交
git add . && git commit -m "feat: 添加用户详情页"
# 如果结果不满意，全部回退
git reset --hard HEAD
# 重新给AI更精确的prompt六、为什么一定要"前置"
九步前置法有一个共同特征：它们都在写第一行代码之前完成。这不是巧合，而是Vibe Coding的核心洞察。
AI的强项是"在给定约束下快速生成"，弱项是"在缺乏约束时自我约束"。当你没有给AI划定边界，它就会凭自己的"理解"去发挥，而每次理解的偏差累积起来，就是代码质量的熵增。
前置的本质是：把不确定性消灭在代码产生之前。PRD消灭需求的不确定性，DESIGN消灭视觉的不确定性，ARCH消灭结构的不确定性，规范消灭风格的不确定性。当不确定性被消灭后，AI生成的每一行代码都在一个确定的框架内运行，自然就不会跑偏。
对比两种模式：
| 维度 | 无前置模式 | 前置模式 |
|---|---|---|
| 启动速度 | 快（打开就写） | 慢（先写文档） |
| 前1小时产出 | 极高 | 较低 |
| 第3小时状态 | 代码开始混乱 | 稳定输出 |
| 第3天状态 | 项目接近崩盘 | 架构清晰，迭代顺畅 |
| 返工成本 | 极高 | 极低 |
前置模式在前期投入更多时间，但换来了后期的高稳定性。Vibe Coding不是百米冲刺，而是马拉松------你不是在比谁第一行代码写得快，而是在比谁的代码能在第30天仍然可维护。
七、总结
Vibe Coding的终极问题不是"AI能不能写出好代码"，而是"你知不知道要AI写什么"。Harness Engineering的本质，是在AI动手之前，你先想清楚：做什么、怎么做、做到什么程度算完。
记住这个流程：定图纸 （需求→PRD→设计）→ 打地基 （非功能需求→技术栈→架构）→ 立规矩（固化文档→开发规范→Git阀门）。九个步骤，三份文档，一个Git仓库------这就是Vibe Coding的工程化基石。
当你下次打开编辑器准备Vibe Coding时，先问自己一句：我的PRD写好了吗？如果没有，关掉编辑器，打开文档，先和AI聊清楚需求。这半小时的"延迟"，会在后续的三十个小时里成倍返还。