Vibe Coding 破局之道：用工程化流程驾驭 AI，告别代码"屎山"

干货笔记详细在这

核心论点：Vibe Coding 项目的成败，不取决于 AI 模型有多强，而在于你是否建立了一套工程流程去驾驭 AI。这套方法论，我称之为 Harness Engineering（驾驭工程）。

一、问题：为什么 Vibe Coding 项目总是"前快后崩"？

Vibe Coding 的典型曲线是这样的：前期项目推进极快，几天就能搭出一个像模像样的原型；但越往后，代码越乱，变更成本越来越高，最终整个项目变成一座"屎山"，越改越差，直至崩盘。

问题出在哪里？

不是 AI 不够强。问题在于一个普遍的误解------很多人以为 Vibe Coding 就是把活直接丢给 AI，然后自己去喝咖啡。

真正的问题是你缺了一套驾驭 AI 的工程流程。就像一个建筑工地，你有了全世界最好的工人（AI），但没有图纸、没有施工标准、没有质量检查，盖出来的楼一定会塌。

二、解法：Harness Engineering 三层金字塔

markdown 复制代码

                    ┌─────────────────┐
                    │  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 的全局上下文：

bash 复制代码

项目根目录/
├── 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

markdown 复制代码

你（决策者）
    │
    ├── 定图纸 ──→ 需求 → PRD → 视觉框架
    │
    ├── 打地基 ──→ 非功能需求 → 技术栈 → 架构草案
    │
    ├── 立规矩 ──→ 文档固化 → 开发规范 → Git 闸门
    │
    └── 驾驭 AI 开发 ──→ 小步迭代 → 即时验收 → 原子提交

核心认知升级：Vibe Coding 不是你给 AI 当 PM，而是你当总工，AI 当工人。总工不画图纸、不定标准、不检查质量，再好的工人也盖不出好楼。

Harness Engineering 的本质就是------把"驾驭 AI"这件事本身，变成一套可复制、可验证的工程流程。