不是 AI 不够强是你没给它戴上“缰绳”前言那个让人又爱又恨的 Vibe Coding如果你用过 Vibe Coding一定经历过这样的心路历程第一周哇AI 太强了一天出一个功能一周搭完 MVP感觉自己要起飞了第二周咦改一个地方怎么崩了三个地方第三周这代码我看不懂AI 也看不懂了要不……重开吧这不是你一个人的问题。Andrej Karpathy 提出 Vibe Coding 时描绘的场景很美好——你负责“氛围”AI 负责“代码”。但现实是项目推进越快代码堆得越乱最后变成一座谁也动不了的屎山。问题出在哪不在于 AI 强不强而在于你没有构建一套工程流程去驾驭 AI。说白了Vibe Coding 不是把活直接丢给 AI 然后去喝咖啡而是需要一套Harness Engineering驾驭工程——给 AI 戴上缰绳让它按你的规矩干活。今天这篇文章就把我踩过无数坑后沉淀下来的Vibe Coding 标准工作流——九步 Harness 法全盘托出。全程可落地读完就能用。第一阶段定图纸第 1-3 步核心思想先想清楚要盖什么样的房子再让 AI 动手搬砖。很多人的 Vibe Coding 姿势是打开对话框直接说“帮我做个电商 App”。然后 AI 开始疯狂输出代码你开始疯狂复制粘贴。三天后你发现购物车和订单对不上支付跳转莫名其妙用户登录跟没登一样。问题的根源需求不清晰AI 全靠猜。第 1 步导需求——像和朋友聊天一样先别写代码先去聊需求。打开 Claude、ChatGPT 或任何你喜欢的 AI像跟朋友聊天一样把你的想法全倒出来这个产品的痛点是什么足够痛没解决有市场目标用户是谁使用场景是什么样的核心功能有哪些不用追求严谨不用结构化信息量越大越好。这个阶段的目的就一个让 AI 理解你要做什么。Vibe Coding 的第一步不是写代码是写“故事”——把产品故事讲清楚AI 才能帮你把代码写明白。第 2 步定 PRD——验收标准是灵魂聊完需求后让 AI 整理成一份结构化的PRD 文档。这份文档要包含功能列表用户流程页面清单最关键的一点每个功能都要写清楚“做到什么程度算完成”。举个例子不要说“登录功能”要说场景验收标准登录成功跳转到首页或登录前页面账号不存在提示“该账号未注册”密码错误提示“密码错误还剩 X 次机会”网络异常提示“网络连接失败请稍后重试”没有验收标准AI 就会越写越发散。今天加个动画明天改个配色后天重构一遍逻辑——全是无效劳动。把这个文档存为PRD.md放在项目根目录。第 3 步定视觉和页面框架这一步是为了不让 AI 一边写功能逻辑一边把 UI 推翻重来。找 2-3 个参考网站或者让 AI 生成几种风格方案把下面这些事情定死整体风格简约风豪华风毛玻璃极简页面布局导航在顶部还是侧边色彩体系主色、辅色、背景色页面清单到底有哪些页面每个页面大概长什么样有参考网站的话直接把链接丢给 AI让它学习风格。没有的话让 AI 出 3 套方案你来选。存为DESIGN.md。有人会说“设计不重要先把功能跑起来。” 但我的经验是设计不确定AI 每改一次功能就会顺手改一次 UI每次改完你都觉得不对劲来回拉扯十几次时间全耗在这了。第二阶段打地基第 4-6 步核心思想地基不牢上面盖多高都得塌。第 4 步明确项目边界和非功能需求这四个非功能性需求不写清楚后面一定会返工安全有没有用户数据要不要加密要不要鉴权性能页面加载速度要求多少API 响应时间上限可用性要不要做错误边界要不要降级方案成本API 调用有没有预算上限要不要做缓存还要明确本地跑还是线上公开用户量预估多少有没有支付功能这些问题看起来“不重要”但 AI 不知道答案时就会随便猜——猜对了是运气猜错了就是灾难。第 5 步锁定技术栈——越可验证越好“适合的就是最好的。” 但对于 Vibe Coding还有一个原则越主流越好越可验证越好。为什么因为主流技术栈的语料多AI 生成的代码质量更高、bug 更少。推荐组合前端React TypeScript TailwindCSS后端Node.js Express / Next.js数据库PostgreSQL / SQLiteAI 工具Claude / Cursor / Copilot把这些写进CLAUDE.md或项目根目录的规则文件作为 AI 的硬约束。 技术选型不是选“最好的”是选“AI 最擅长的”。第 6 步让 AI 出轻量架构草案不需要画复杂的 UML 图但下面这些东西要有目录架构怎么分层/components、/pages、/services、/utils……核心模块有哪些模块模块之间怎么通信数据模型主要的数据结构长什么样组件清单有哪些公共组件哪些页面组件这个草案不用完美但要有。有了骨架AI 填肉的时候才不会乱长。第三阶段立规矩第 7-9 步核心思想把规则固化下来让 AI 每次干活都有“操作手册”。第 7 步固化成文档——AI 的永久上下文现在把前面所有的产出物写成项目根目录的几个文档。这些都是 AI 的全局上下文每次对话都会加载项目根目录/ ├── PRD.md # 产品需求文档 ├── DESIGN.md # 设计文档 ├── ARCH.md # 系统架构文档 ├── PROJECT.md # 当前项目阶段和进度 └── CLAUDE.md # 技术栈和开发规范为什么要固化因为 AI 的上下文窗口有限你不可能每次对话都把全部背景复述一遍。把这些文档放在根目录AI 每次都能读到Vibe Coding 就有了永久约束。Harness Engineering 的核心就是把模型放进可验证的工程轨道——这些文档就是轨道。第 8 步定开发规范和参考资料给 AI 立规矩告诉它代码该怎么写代码规范用函数组件还是类组件用const还是let命名规范是什么注释要不要写怎么写错误处理规范API 调用失败怎么处理要不要统一的错误边界错误信息怎么展示API 接口规范RESTful 还是 GraphQLURL 命名规则请求/响应格式可以给 AI 一个样本参考让它照着写。比如给一段“标准写法”的代码说“所有代码都按这个风格来”。第 9 步搞好 Git 和质量阀门最后一步把版本控制和代码质量管起来。在 Vibe Coding 中AI 经常一口气生成几百行甚至上千行代码。这时候理解 Git 三棵树工作区 → 暂存区 → 版本库的工作原理就是你驾驭 AI 代码的刹车和油门。先来一张核心概念图后面的命令都围着它转工作区Working Directory你电脑文件夹里看到的实际文件AI 最新吐出来的代码就在这里。暂存区Staging Area / Index准备提交的“待办清单”git add就把代码加进来了。版本库Repository已经提交的、有 commit ID 的历史版本HEAD 指针指向当前所在分支的最新版本。场景一AI 改崩了想完全“时光倒流”——git reset --hard什么时候用AI 一顿输出猛如虎结果页面直接白屏报错或者生成了完全跑不通的逻辑。你想放弃当前所有修改干干净净地回到某个历史版本重新写 Prompt 再试一次。# 回到指定版本丢弃工作区和暂存区的所有改动 git reset --hard commit-hash执行效果工作区、暂存区、版本库 HEAD 三位一体全部跳转到目标版本。仓库瞬间变得像刚 clone 下来一样干净。场景二AI 写得好但想合并提交或改 commit 信息——git reset --soft什么时候用AI 完成了“登录 注册”两个功能但你觉得它俩属于同一个需求没必要分成两次提交或者你发现上次的 commit 信息写错了。你想保留 AI 刚刚生成的全部代码只把 HEAD 指针回退一下。# 回退 commit但保留工作区的所有修改且这些修改直接进入暂存区 git reset --soft HEAD~1 # 回退到上一个版本执行效果代码改动原封不动保留在工作区而且全部自动变成“已暂存”状态绿色。你可以直接重新git commit -m 新的提交信息完美重写提交记录。场景三AI 改的文件太多想分批提交——git restore --staged什么时候用AI 一次性改了 20 个文件并全帮你git add了。但你想把 “API 接口” 和 “UI 组件” 分开提交方便 review。# 把暂存区的某个文件移回工作区取消暂存 git restore --staged file执行效果文件从“暂存区”撤回到“工作区”但文件内容本身丝毫不变。你可以用git add重新挑选想先提交的文件实现精细化的代码管理。场景四AI 在本地生成了垃圾测试文件想直接丢掉——git checkout --/git restore什么时候用AI 为了调试生成了几个临时日志文件或者你手动改了一堆乱七八糟的代码试错觉得没救了。这些文件还没有git add你只想通通扔掉回到上一次 commit 时的干净状态。# 丢弃工作区中某个文件的所有未暂存修改危险操作 git checkout -- file # 老语法依然通用 git restore file # Git 2.23 的新语法更语义化执行效果工作区的指定文件“啪”一下恢复成最近一次 commit 的模样。注意这个操作不可逆一旦执行AI 生成的这部分未提交代码就真的消失了执行前请三思金句Vibe Coding 的每一次“试错”都值得被记录——commit 是你的安全网reset --hard是重启键restore是手术刀。质量阀门在 AI 生成代码后、合并之前设置几个必过检查代码能否跑起来——本地运行无报错功能是否符合 PRD——对照验收标准过一遍有没有破坏已有功能——跑一下核心流程代码风格是否一致——用 ESLint/Prettier 自动检查宁可慢一点也不要让烂代码进主分支。一旦进去AI 下次改代码时就会基于烂代码继续“发挥”雪球越滚越大。总结Harness 九步法一览阶段步骤产出物核心目的定图纸① 导需求需求对话记录让 AI 理解产品故事② 定 PRDPRD.md明确验收标准③ 定视觉DESIGN.md锁定 UI 方向打地基④ 定边界非功能需求清单避免后期返工⑤ 锁技术栈CLAUDE.md约束 AI 技术选择⑥ 出架构架构草案给代码搭骨架立规矩⑦ 固文档全套项目文档永久上下文约束⑧ 定规范代码规范 样本统一代码风格⑨ Git 质量门Git 工作流 检查清单守住代码质量底线这 9 步做完你再让 AI 写代码它就是在“轨道”上跑而不是在“荒野”里狂奔。写在最后有人说 Vibe Coding 是“让 AI 帮你写代码”但真正的 Vibe Coding 是“让 AI 在你的规则里帮你写代码”。Harness Engineering 说到底就一句话模型决定写什么代码Harness 约束它在什么时候、在哪里、以什么方式写代码。你不需要成为 prompt 大师但你需要成为工程规则的设计师。这 9 步看起来多但每一步都是在为后面的效率买单。前期省掉的规划时间后期会用 10 倍的调试时间补回来——这个账我替你算过了。