Vibe Coding 越写越乱？用 Harness Engineering 给 AI 开发加上流程
摘要：Vibe Coding 的问题通常不在于 AI 不会写代码，而在于项目没有稳定的需求、设计、架构与验证边界。本文根据一组开发笔记，整理一套从 PRD、非功能需求、项目文档到 Git 质量阀门的最短流程。文中命令仅做静态说明，运行未验证。
用 AI 开发时，最常见的体验是：第一天很快，功能越堆越多；几轮修改后，代码开始重复、需求互相打架，最后不敢再改。
问题不只是提示词不够长，而是缺少一套能约束 AI 的工作流。笔记把这套做法称为 Harness Engineering（驾驭工程）：先建立图纸、地基和规则，再让 AI 在明确边界内完成小任务。
文章目录
- [Vibe Coding 越写越乱？用 Harness Engineering 给 AI 开发加上流程](#Vibe Coding 越写越乱？用 Harness Engineering 给 AI 开发加上流程)
-
- [1. 先理解：AI 需要的是边界，不只是任务](#1. 先理解：AI 需要的是边界，不只是任务)
- [2. 定图纸：把模糊想法变成可验收的 PRD](#2. 定图纸：把模糊想法变成可验收的 PRD)
- [3. 提前定设计：不要让 AI 一边写逻辑一边推翻 UI](#3. 提前定设计：不要让 AI 一边写逻辑一边推翻 UI)
- [4. 打地基：补齐非功能需求，再选技术栈](#4. 打地基：补齐非功能需求，再选技术栈)
- [5. 立规矩：把聊天上下文变成项目文件](#5. 立规矩：把聊天上下文变成项目文件)
- [6. Git + 质量阀门：让 AI 的改动可控、可回退](#6. Git + 质量阀门：让 AI 的改动可控、可回退)
- [7. 可复用的 AI 开发清单](#7. 可复用的 AI 开发清单)
- [8. 结语：让 AI 做执行者，你做流程设计者](#8. 结语：让 AI 做执行者，你做流程设计者)
1. 先理解：AI 需要的是边界，不只是任务
不要只说"帮我做一个登录功能"。这句话缺少至少四类信息：
- 谁在什么场景使用；
- 功能做到哪里算完成；
- 页面长什么样；
- 出错、性能、安全和成本怎么处理。
如果这些信息没有被保存下来，AI 会在每次新对话中根据局部上下文补全细节，项目就会逐步发散。
Harness Engineering 的核心不是限制 AI 的创造力，而是把必须一致的内容固定下来：需求、设计、架构、规范和验证方式。
2. 定图纸：把模糊想法变成可验收的 PRD
开发前先描述痛点、目标用户、使用场景和核心功能，再让 AI 协助整理为 PRD。
PRD 至少应有：
| 内容 | 要回答的问题 |
|---|---|
| 功能列表 | 系统到底做哪些事？ |
| 用户流程 | 用户从进入到完成任务经过哪些步骤？ |
| 页面清单 | 需要哪些页面或核心区块？ |
| 验收标准 | 什么状态才算功能完成？ |
重点是验收标准。
"用户可以登录"不够具体；更可执行的写法是：
text
登录失败：提示账号或密码错误，停留在当前页。
登录成功：保存登录状态，跳转到首页。
空输入：不发起请求，并提示用户补全字段。这样 AI 实现时有明确的判断标准，不会随意增加流程或遗漏异常分支。
3. 提前定设计：不要让 AI 一边写逻辑一边推翻 UI
笔记建议在编码前确定视觉方向和页面框架：可以找 2～3 个参考网站，也可以让 AI 给出多种风格草案。
这一步要确定的不是每个像素，而是：
- 页面布局和主要信息区；
- 页面需要包含哪些内容；
- 整体是简约还是信息密集；
- 核心交互的状态如何呈现。
将决定记录到 Design.md。后续改功能时，AI 就不会在实现业务逻辑的同时重做整个界面。
4. 打地基：补齐非功能需求，再选技术栈
很多返工不是"功能没写"，而是功能写完才发现运行环境、数据和成本不允许。
笔记把下面四项列为必须提前明确的非功能需求：
| 维度 | 例子 |
|---|---|
| 安全 | 是否有用户数据、权限或支付？ |
| 性能 | 预期用户量和响应要求是什么？ |
| 可用性 | 仅本地运行，还是要公开访问？ |
| 成本 | 是否有模型、存储或服务调用上限？ |
在这之后再锁定技术栈，并让 AI 输出轻量架构草案：目录分层、核心模块、数据模型和关键组件即可。小项目不需要一开始画出复杂架构图，但要明确每部分职责。
5. 立规矩：把聊天上下文变成项目文件
聊天记录不适合作为项目唯一记忆。笔记推荐把关键信息沉淀在项目根目录：
text
PRD.md # 产品需求与验收边界
Design.md # 页面与视觉约束
ARCH.md # 目录、模块与数据模型
Project.md # 当前阶段、已完成项与下一步还可以补充代码规范、错误处理约定、API 约定和参考样例。
这些文件的作用是：无论更换 AI、开启新会话还是加入协作者，大家都能从同一套"项目事实"开始，而不是依赖记忆猜测。
6. Git + 质量阀门：让 AI 的改动可控、可回退
AI 一次可能修改多个文件，所以不能只看它说"完成了"。每个小任务后都要经过质量阀门，例如：
- 查看改动是否只涉及本次任务；
- 执行项目已有的构建、测试或 Lint；
- 手动检查关键流程；
- 确认后再提交 Git。
笔记还记录了几个容易混淆的 Git 操作：
| 命令 | 用途 | 风险 |
|---|---|---|
git reset --hard |
回退并丢弃当前修改 | 未提交改动会消失 |
git reset --soft |
回退提交但保留修改 | 适合重新组织提交 |
git restore --staged 文件名 |
将文件移出暂存区 | 工作区内容保留 |
git checkout -- 文件名 |
用已有版本覆盖工作区 | 该文件未提交改动会丢失 |
执行破坏性命令前，先用 git status 确认当前改动是否需要保留。
7. 可复用的 AI 开发清单
开始让 AI 写代码前，先完成这 7 项：
- 写清用户、场景和核心功能；
- 为每个核心功能补充验收标准；
- 确定页面框架与视觉方向；
- 写清安全、性能、可用性、成本边界；
- 明确技术栈和轻量架构；
- 将 PRD、设计、架构、当前阶段保存为文件；
- 约定每次改动后的检查与 Git 提交方式。
8. 结语：让 AI 做执行者，你做流程设计者
Vibe Coding 不等于把开发完全交给 AI。更稳的分工是：人定义问题、边界与验收；AI 协助拆解和实现；测试、检查与 Git 决定改动能否进入下一步。
对于初学者，最值得练的不是一次让 AI 生成完整项目，而是拿一个小项目，先写出 PRD 和验收标准，再让 AI 一次只实现一个可以验证的功能。