Vibe Coding Git 开工基线：干净起点与可恢复检查点

Vibe Coding 最容易跳过的一步，是在第一条 Prompt 之前确认“从哪里开始”。Agent 能读到文件并不表示它看到的是团队以为的版本：分支可能落后，索引里可能有半个修复，未跟踪文件可能是用户草稿，submodule 也可能指向未登记提交。若起点不明确，后面即使测试通过，也无法回答新 diff 属于谁、失败后该回到哪里。

这里的“干净起点”首先指已知且获准的状态，其次才是 git status 没有输出。共享工作目录已经有修改时，不应为了符合形式而自动 stash、commit、restore 或 clean；应按脏工作树安全改码保护现场，或者暂停并由所有者决定隔离方式。本文处理的是新任务怎样建立可重现基线与恢复锚点，而不是教 Agent 在未知脏树上继续叠补丁。

开工前冻结五类事实

先只读采集，不做同步或清理：

repository: 规范化仓库身份与工作目录
ref: 当前分支或 detached HEAD 状态
head: 完整对象 ID；新仓库则显式写 unborn
index/worktree: staged、unstaged、untracked、rename、submodule 摘要
environment: Git 版本、关键运行时与锁文件摘要

git status --short --branch 用来观察分支和三层变化，git rev-parse --verify HEAD 用来解析当前提交；它们是事实探针，不会证明远端最新，也不会说明改动归属。需要远端信息时，先判断网络访问是否获准，再把“最后一次 fetch 时间”和“远端跟踪引用”写进记录，不能把本地 main 的名字当作当前上游事实。

同时读取仓库内的规则、构建入口和任务涉及路径。陌生仓库冷启动负责建立地图；Git 基线只回答版本现场。若依赖安装会改锁文件、生成器会重写产物，先列出预期写集。不能重现的本地数据库、未登记环境变量或缺失 LFS 对象都属于开工阻断，而不是等 Agent 写完再解释。

把起点分成绿、黄、红三类

绿色起点满足：目标分支和基准提交明确；index、工作树及未跟踪集合为空；依赖与生成步骤可说明；任务范围和验证命令已确认。黄色起点存在已知差异，但每项有所有者、内容摘要和禁止动作，当前任务只读或在批准路径叠加。红色起点包括来源不明的修改、正在进行的 merge/rebase、缺失对象、无法解释的 submodule 指针或任务要求与仓库规则冲突。

黄色不是自动失败，红色也不是让 AI “修到绿色”的授权。红色时只报告现场与最小澄清问题。若用户确实要在共享脏树继续，转入 hunk 级归属流程；若可以使用隔离目录或新任务分支，也要遵守仓库政策，不能擅自创建。一个诚实的 BLOCKED_UNKNOWN_BASELINE 比从错误分支快速生成十个文件更有价值。

检查点必须同时回答“回哪”和“怎么验”

基线提交本身是第一个恢复锚点，但只对当时的干净树有效。进入依赖升级、批量重命名、冲突解决或迁移等高风险步骤前，再建立任务检查点：记录当前对象 ID、完整状态、已完成验收声明、补丁或提交的内容摘要、未跟踪文件处理方式，以及恢复后必须运行的验证。

优先让已经形成独立行为并通过门禁的工作成为原子提交。尚未达到提交边界的半成品，不应偷偷和用户修改打成 “checkpoint commit”；可在仓库外的受控位置保存允许路径补丁和摘要，并明确它不是 Git 备份。秘密、ignored 缓存、数据库内容和外部副作用不能因打包方便被带入检查点。

检查点记录可以很短：

checkpoint: TASK-42/C2
base: 31f9...c0
state: clean
claims: [AC-1, AC-2]
nextRisk: regenerate-api-client
restoreTarget: 31f9...c0
verify: [pnpm test -- api-client, git diff --exit-code]
forbidden: [push, deploy, delete-user-work]

不要只写“需要时 reset 回去”。恢复动作本身可能覆盖当前工作，应先在隔离位置使目标对象可达，比较 tree 与预期，再由获准的人决定怎样切换。需要找回本地引用或撤销共享提交时，使用Revert 与 Reflog 恢复流程分类，不能把所有事故都归结为 reset --hard。

用一次小演练证明检查点不是装饰

在真正高风险编辑前做低成本演练：从记录的基线重建一个隔离副本，应用任务补丁或检出检查点，核对文件摘要并运行一条快速验证。若恢复依赖作者机器上的绝对路径、聊天历史或未登记生成物，检查点不完整。演练也要确认不会碰远端、数据库和云资源；代码恢复不等于副作用回滚。

每完成一个阶段，再比较新状态与上一检查点：新增了哪些文件、哪项证据过期、恢复目标是否仍可达。提交候选前再用选择性暂存与 Diff 自审收窄内容；发生冲突则进入合并语义对账，不要让检查点成为“反正能恢复，所以可以盲改”的借口。

好的起点不是视觉上空白，而是任何参与者都能指出当前对象、已有变化、允许写集和第一条恢复路线。Vibe Coding 可以从此快速推进，因为每一步都知道自己离哪个可靠状态多远，也能在失败时先保护现场，再有证据地返回。