check-then-go：让 AI 先检查再动手

当 AI Agent 「好心办坏事」

你有没有遇到过这种情况：让 AI Agent 帮你改个样式，它二话不说直接动手，结果改错了文件；让它修个 bug，它跳过了确认环节，一把梭哈改了五个文件，出问题后连回滚的余地都没有。

更离谱的是，你让它改 README.md，它默认去改了 SKILL.md，等你发现的时候已经提交了。

这些翻车现场的本质都指向同一个问题：AI Agent 缺乏一套「先确认、再执行」的交互规范。

check-then-go 是什么

check-then-go 是一个为 AI Agent 设计的通用交互流程规范。它定义了一个 15 步的状态机，强制 Agent 在执行任何有副作用的操作前，必须完成需求确认、方案对比和用户授权。

简单来说：不是不让你干，是让你先说清楚要干什么。

核心流程

整个流程分为五个阶段：

需求确认 → 方案设计 → 方案细化 → 执行 → 验收
                                      ↑      │
                                      └── 失败重试（最多 3 次，全败则回滚）

每个阶段的关键要求：

需求确认 — Agent 必须先复述用户需求，逐条确认，禁止跳步。

方案设计 — 给出 2-3 个方案，标注工作量、风险和复杂度，由用户选择。

方案细化 — Agent 反诘实施细节，用户回答后，给出完整方案（改哪些文件、改什么内容、预期效果）。

执行 — 用户明确说「可以执行」后，Agent 先 git commit 建检查点，再动手。一次只做一个逻辑操作，逐步确认。

验收 — 用户确认结果。失败则回到方案设计重新来，最多 3 次。3 次全败则自动回滚到检查点。

实战示例

场景：用户说「手机版页面无法上下滑动」。

错误做法：

Agent 直接找到 CSS 文件，改了一行 overflow: hidden 为 overflow: auto，然后告诉用户「已修复」。

没有确认、没有检查点、没有方案对比。如果改出别的问题，无据可查。

正确做法（check-then-go）：

用户：手机版页面无法上下滑动

Agent：我理解你的需求是：手机端页面滚动失效，需要排查并修复。
       目前初步判断可能是 CSS overflow 属性的问题。
       方案一：修改 overflow 属性（工作量小，风险低）
       方案二：检查是否有 JS 事件阻止了滚动（工作量中，风险低）
       你倾向哪个方案？

用户：先试方案一。

Agent：好的，我现在先提交一个 git 检查点，然后修改 CSS。
       [git commit：修改前检查点]
       已完成修改，请验收。

仅多花了半分钟确认，但全程可控、可回溯。

四条执行纪律

这套规范背后是四条贯穿始终的纪律：

1. 先解释再动手 — 做什么、为什么、影响范围，说清楚再执行
2. 一次一步 — 每次只做一个逻辑操作，完成后等待确认
3. 最简方案优先 — 先试最简单的解法，不行再加码
4. 所见即所得 — 不接受静默修正，用户输入是什么就是什么

如果你也在用 AI Agent 做开发、写文档、管理项目，不妨试试这套规范。完整定义和脚本工具在 GitHub 仓库 中，欢迎拿来用。