V053：从 Git 回退到 AI 工程治理：Vibe Coding 的 Harness 工作流与质量阀门

从 Git 回退到 AI 工程治理：Vibe Coding 的 Harness 工作流与质量阀门

在传统开发中，Git 常被理解为"提交代码、拉分支、出了问题再回退"的工具。

进入 Vibe Coding 后，它的角色变得更重要：AI 能让实现速度显著提高，也会让错误的假设、混乱的结构和失控的改动以同样快的速度累积。真正的问题不再只是"会不会写 Prompt"，而是：

text 复制代码

当 AI 一次改动偏离目标时，
团队有没有可审查、可验证、可回退的工程护栏？

第四十五天的学习把 Git 的 HEAD、reset、暂存区恢复操作，与 Vibe Coding 的九步工作流放在了一起。二者看似一个是版本控制命令，一个是项目推进方法，核心却相同：让快速尝试保持可控。

本文只聚焦这条主线：如何用 Git 提供回退能力，用 Harness（工程驾驭体系）约束 AI 的工作上下文，并在每个阶段设置质量阀门。

一、AI 写得快，不代表项目推进得稳

Vibe Coding 的误区是把它理解为：

text 复制代码

把需求丢给 AI
  ↓
等待代码生成
  ↓
项目自然完成

真实项目更接近：

text 复制代码

模糊需求
  ↓
AI 根据不完整上下文补全大量假设
  ↓
快速得到"看起来可运行"的代码
  ↓
继续叠加功能、继续局部修补
  ↓
结构与需求逐渐脱节

AI 本身不负责维护长期一致性。它能根据当前输入生成合理代码，却不会天然知道：

这个需求的边界是否已经确认；
某个页面风格是否早已定稿；
当前改动会不会破坏既有数据模型；
上一次可用版本是什么；
这次修改失败后应该退回哪一个稳定点。

因此，Vibe Coding 的关键不是"把开发交给 AI"，而是建立一套 Harness Engineering：用需求、设计、架构、规范、版本记录和验证机制，把 AI 的高速产出约束在可控轨道上。

AI 是执行能力的放大器；Harness 才是让放大器不失控的工程系统。

二、Git 的第一性作用：给尝试建立可回退边界

2.1 HEAD：你现在站在哪个版本

Git 中的 HEAD 可以理解为"当前工作位置"的指针：它指向当前检出的分支和提交。

text 复制代码

A ── B ── C  ← main, HEAD

这张图最重要的不是术语，而是回答一个工程问题：

text 复制代码

如果刚才的改动不对，我能明确回到哪里？

没有清晰提交边界时，开发者只能在混杂的工作区里手工判断哪些改动该保留；有了提交，稳定状态就是可命名、可比较、可恢复的检查点。

2.2 `git reset --soft`：回退提交，保留成果

bash 复制代码

git reset --soft <commit>

它将 HEAD 移到指定提交，但保留后续修改在暂存区。

适合场景：

text 复制代码

刚刚的提交粒度不合理
提交信息写错
多个小改动想重新整理成更清晰的一次提交

它表达的是：撤销版本历史的表达方式，但不丢弃已完成工作。

2.3 `git reset --hard`：回到已知稳定状态

bash 复制代码

git reset --hard <commit>

它会让提交历史、暂存区和工作区都回到指定版本，未提交修改会被丢弃。

适合场景：

text 复制代码

AI 的一轮改造整体走偏
实验性重构验证失败
明确不需要保留当前工作区修改

它不是日常"撤销按钮"，而是强力止损工具。执行前必须确认：要丢弃的修改是否已经无价值，是否存在未提交但仍需保留的内容。

2.4 暂存区与工作区：把撤销粒度拆开

Git 并不只有"保留"与"全部丢弃"。

bash 复制代码

# 取消暂存：文件留在工作区，仍可继续修改
git restore --staged readme.md

# 丢弃工作区修改：恢复为暂存区 / HEAD 中的版本
git restore readme.md

可以把三层状态理解为：

text 复制代码

HEAD：上一次确认过的版本
  ↓ git add
暂存区：准备提交的候选改动
  ↓ 修改文件
工作区：正在实验、尚未确认的改动

这正好对应 AI 协作中的三种状态：

text 复制代码

已验证的基线
待审查的改动
正在尝试的生成结果

不要把所有 AI 输出都直接视为"应该提交的成果"。先观察、测试、审查，再决定是否进入暂存区，才是安全的默认流程。

三、从"提示词"升级为"项目 Harness"

一次 Prompt 只能表达当前任务；项目需要长期记住的约束更多。

学习笔记将 Vibe Coding 的前置工作概括为三阶段：定图纸、打地基、立规矩。

text 复制代码

第一阶段：定图纸
需求 → PRD → 视觉与页面框架

第二阶段：打地基
非功能约束 → 技术栈 → 轻量架构

第三阶段：立规矩
上下文文档 → 开发规范与参考 → Git 与质量阀门

3.1 定图纸：先确认"做什么"和"不做什么"

开发开始前，先把自然语言想法变成可验收的定义。

产物	解决的问题
需求说明	用户是谁、痛点是什么、核心功能是什么
PRD	功能清单、用户流程、页面清单、验收标准
DESIGN	布局、视觉方向、参考产品、交互边界

关键是把"登录功能"这类笼统描述展开：

text 复制代码

登录失败显示什么？
登录成功跳到首页还是回到原页面？
未登录访问受限页面怎么办？
什么状态才算这个功能完成？

没有边界，AI 就只能猜；AI 每多猜一次，后续返工概率就多一层。

3.2 打地基：不要只描述功能，也要描述约束

功能需求说明"要做什么"，非功能需求说明"在什么条件下做"。

text 复制代码

部署在本地还是公开线上？
是否保存用户数据？
性能、成本、可用性有什么上限？
是否有支付、权限、安全与隐私要求？

技术栈也应该尽早锁定：

text 复制代码

React + TypeScript + Tailwind CSS

其目的不是追求"最潮"，而是缩小 AI 的自由发挥空间：目录结构、组件范式、类型策略、样式方式明确后，生成内容才更容易拼进同一个系统。

3.3 立规矩：让每轮 AI 都拿到同一份项目事实

把核心约束固化在项目根目录的文档中，例如：

text 复制代码

PRD.md      产品需求与验收边界
DESIGN.md   页面结构与视觉规则
ARCH.md     目录、模块、数据模型与依赖方向
PROJECT.md  当前阶段、已完成事项与下一步
CLAUDE.md   面向 Agent 的开发规范与命令约束

这些文件不是"写给以后看的文档负担"，而是 AI Agent 的稳定上下文。

每次新会话、换模型或任务切换时，模型都需要重新理解项目；稳定文档能减少口头重复，避免"昨天定了、今天忘了"的上下文漂移。

四、九步工作流：从想法到可控交付

可以把学习笔记的流程压缩为下面这条线：

text 复制代码

1. 描述痛点、用户、场景与目标
2. 整理并验收 PRD
3. 确认视觉与页面框架
4. 明确安全、性能、成本、可用性等边界
5. 锁定可验证的技术栈
6. 产出轻量架构草案
7. 固化需求、设计、架构与项目状态
8. 建立代码、错误、API 等开发规范
9. 使用 Git 提交点与验证门槛推进迭代

这套流程并不要求每个小 Demo 都写成厚重文档。它的核心是按项目复杂度保留必要的"决策痕迹"。

项目规模	最小 Harness
单页练习	目标、功能边界、启动命令、一次可回退提交
小型前端项目	PRD、组件结构、数据流、关键验收点
多人 / 多 Agent 项目	PRD、DESIGN、ARCH、规范、任务状态、测试与发布门槛

文档的价值不是形式完整，而是让下一次决策不必从猜测开始。

五、把 Git 变成 AI 协作的质量阀门

Git 只有在与验证流程结合时，才真正成为质量阀门。

5.1 一次任务，一个可描述的提交

不推荐：

text 复制代码

fix
update
AI 改了一堆

5.2 推荐的 AI 改动闭环

text 复制代码

确认任务边界
  ↓
记录当前基线（git status / git log）
  ↓
让 AI 完成最小范围改动
  ↓
检查 diff
  ↓
运行构建、测试或手动验收
  ↓
只暂存本任务相关文件
  ↓
提交为一个可回退检查点

这里的关键不是命令数量，而是顺序：先看差异，再验证，再提交。

5.3 不要让提交掩盖未确认改动

当工作区本来就有无关修改时，直接执行：

bash 复制代码

git add .

很容易把实验文件、临时配置甚至密钥一起带入提交。

更安全的做法是按文件明确暂存：

bash 复制代码

git add src/components/TodoList.jsx

这让"提交什么"成为一次主动决策，而不是目录扫描的副作用。

六、常见失控模式与纠偏

6.1 先写再问：需求靠代码试出来

表现：AI 直接开始搭页面，几轮之后才发现核心流程、边界和视觉方向都不对。

纠偏：先写最小 PRD，至少包括用户、场景、核心功能、非目标和验收标准。

6.2 一次让 AI "全项目重构"

表现：大量文件同时修改，难以审查，也很难定位回归来源。

纠偏：把任务切为可验证的小步，每步都有独立 diff 和提交点。

6.3 只保存对话，不固化项目事实

表现：换一个 Agent、开一个新会话，之前的技术决策和约束全部丢失。

纠偏：把长期有效的信息沉淀为 PRD、设计、架构和规范文件。

6.4 把 `reset --hard` 当作常规撤销

表现：为快速回退而丢失尚未确认但有价值的工作区修改。

纠偏：先区分要撤销的是提交、暂存，还是工作区；可保留成果时优先使用 --soft 或 git restore --staged。

七、结语：速度需要轨道

Vibe Coding 的价值是真实的：它让原型、页面、脚手架和局部功能以前所未有的速度出现。

但速度本身不会生成质量。质量来自一套可重复的工程闭环：

text 复制代码

清晰需求
+ 固定上下文
+ 明确架构与规范
+ 小步验证
+ Git 可回退提交
= 可控的 AI 辅助开发

Git 让你能从错误实验中回来；Harness 让你更少走进错误实验。

两者结合，才是从"AI 帮我写代码"走向"我用工程系统驾驭 AI"的分界线。

V053： 从 Git 回退到 AI 工程治理：Vibe Coding 的 Harness 工作流与质量阀门

从 Git 回退到 AI 工程治理：Vibe Coding 的 Harness 工作流与质量阀门

一、AI 写得快，不代表项目推进得稳

二、Git 的第一性作用：给尝试建立可回退边界

2.1 HEAD：你现在站在哪个版本

2.2 git reset --soft：回退提交，保留成果

2.3 git reset --hard：回到已知稳定状态

2.4 暂存区与工作区：把撤销粒度拆开

三、从"提示词"升级为"项目 Harness"

3.1 定图纸：先确认"做什么"和"不做什么"

3.2 打地基：不要只描述功能，也要描述约束

3.3 立规矩：让每轮 AI 都拿到同一份项目事实

四、九步工作流：从想法到可控交付

五、把 Git 变成 AI 协作的质量阀门

5.1 一次任务，一个可描述的提交

5.2 推荐的 AI 改动闭环

5.3 不要让提交掩盖未确认改动

六、常见失控模式与纠偏

6.1 先写再问：需求靠代码试出来

6.2 一次让 AI "全项目重构"

6.3 只保存对话，不固化项目事实

6.4 把 reset --hard 当作常规撤销

七、结语：速度需要轨道

V053：从 Git 回退到 AI 工程治理：Vibe Coding 的 Harness 工作流与质量阀门

2.2 `git reset --soft`：回退提交，保留成果

2.3 `git reset --hard`：回到已知稳定状态

6.4 把 `reset --hard` 当作常规撤销