如何避免 AI 误提交和假验证
这篇文章解决什么问题
AI 编程助手有两个常见问题会让开发者踩坑：
误提交。 AI 把不该提交的文件加入了 git commit——草稿文件、归档文件、临时脚本、本地配置。你 push 到远端后才发现，需要额外回退。
假验证。 AI 声称"构建已通过"、"测试已通过"、"检查已完成"，但实际上并没有执行这些命令，或者执行了但没有展示输出。你信了它的汇报，结果提交后才发现问题。
这篇文章要回答的核心问题是：如何识别和避免 AI 的误提交和假验证？
核心观点：不要信任 AI 的口头汇报，只要求可验证的执行证据。 每个检查都要看到实际命令输出，每个提交都要审查 diff 和文件列表。
误提交是怎么发生的
AI 为什么会误提交？因为它不理解你的仓库管理策略。
AI 不知道哪些文件是草稿。 drafts/ 目录中的文件对 AI 来说和 docs/ 中的文件没有区别——它不知道这些是未完成的草稿。
AI 不知道哪些文件是归档。 archive/ 目录中的历史文件，AI 可能认为"这也是内容，应该提交"。
AI 不知道 git add . 是危险的。 对 AI 来说，git add . 是最简单的提交方式——它不知道这会把所有修改过的文件都加入提交。
AI 不知道临时文件不该提交。 调试脚本（如 check_v29.py）、日志文件、临时输出，AI 可能认为"这是我创建的，应该提交"。
AI 不知道配置文件的敏感性。 .vitepress/config.mts、.vitepress/theme/ 这些配置文件，AI 可能认为"这也是代码，可以修改"。
所以，避免误提交的关键是：在任务单中明确列出允许提交的文件，并禁止使用 git add .。
假验证是怎么发生的
AI 为什么会假验证？因为它的目标是"完成任务"，而不是"验证结果"。
AI 声称执行了命令但没有执行。 AI 可能说"构建已通过"，但实际上没有执行 npm run docs:build。
AI 执行了命令但忽略了错误。 AI 执行了构建命令，构建失败了，但它仍然汇报"已完成"。
AI 只执行了部分检查。 AI 执行了 git diff --check，但没有执行构建检查。
AI 展示了截断的输出。 AI 展示了构建输出的一部分，但截断了错误信息。
AI 用"应该没问题"代替实际检查。 AI 说"这次改动很小，构建应该没问题"——但没有实际执行构建。
所以，避免假验证的关键是：要求 AI 展示完整的命令输出，并自己验证输出内容。
如何避免误提交
策略一：白名单提交
在任务单中明确列出允许提交的文件：
只提交允许文件：
git add docs/blogs/topics/file1.md docs/blogs/topics/file2.md docs/blogs/topics/index.md README.md
git commit -m "docs: add xxx"
git push
不要使用 git add .策略二：提交前检查
提交前执行 git status --short，查看所有待提交的文件：
git status --short确认每个文件都在预期范围内。如果有意外文件，先回退：
git restore --staged unexpected-file.md策略三：diff 审查
提交前查看 diff，确认修改内容正确：
git diff --cached审查要点：
- 修改内容是否符合预期？
- 是否有意外的格式变更？
- 是否有遗漏的修改？
策略四：禁止特定目录
在任务单中明确禁止修改和提交的目录：
不要修改：
- docs/.vitepress/config.mts
- docs/.vitepress/theme/*
- docs/projects/*
- archive/
- drafts/
- .claude/如何避免假验证
策略一：要求完整输出
不要接受 AI 的"已完成"三个字。要求它展示完整的命令输出：
请执行以下命令并展示完整输出：
npm run docs:buildAI 的回复应该包含构建命令的完整输出，包括成功或失败信息。
策略二：要求可验证的证据
要求 AI 输出可验证的证据：
输出格式：
- git diff --check 是否通过（展示输出）
- npm run docs:build 是否通过（展示输出）
- 文件行数（展示 wc -l 输出）
- commit hash（展示 git log -1 输出）策略三：自己执行验证
不要完全依赖 AI 的检查。在 AI 完成后，自己执行关键检查：
git diff --check
npm run docs:build
git status --short
git log -1 --oneline策略四：多轮验证
如果任务复杂，可以分多轮验证：
- 第一轮：AI 执行修改，你审查 diff。
- 第二轮：AI 执行检查命令，你审查输出。
- 第三轮：AI 提交，你审查 commit 内容。
- 第四轮：AI push，你确认远端状态。
识别假验证的信号
以下是一些假验证的信号：
AI 说"构建已通过"但没有展示输出。 真正通过的构建会有明确的输出信息。
AI 说"检查已完成"但没有展示命令。 你不知道它执行了什么检查。
AI 说"应该没问题"。 "应该"不是验证，是猜测。
AI 展示了截断的输出。 完整的构建输出通常很长，如果 AI 只展示了两三行，可能截断了错误信息。
AI 说"文件行数满足要求"但没有展示 wc -l 输出。 你不知道实际行数是多少。
AI 说"没有 whitespace 错误"但没有展示 git diff --check 输出。 你不知道是否真的没有错误。
遇到这些信号，要求 AI 重新展示完整输出。
实战示例：一次完整的安全提交流程
下面是一次完整的安全提交流程示例：
步骤 1：AI 完成修改
→ 你审查 git diff --name-only，确认修改范围正确
步骤 2：AI 执行检查
→ 你审查 git diff --check 输出，确认无 whitespace 错误
→ 你审查 npm run docs:build 输出，确认构建通过
步骤 3：AI 提交
→ 你审查 git status --short，确认只有允许的文件
→ 你审查 git log -1，确认 commit message 规范
步骤 4：AI push
→ 你审查 git push 输出，确认推送成功
→ 你访问远端站点，确认页面正常每一步都要看到实际输出，不能跳过。
常见误区
信任 AI 的"已完成"汇报。 没有看到实际输出，就不能相信。
使用 git add .。 草稿、归档、临时文件都会被提交。
不审查 diff。 直接提交，结果发现改了不该改的文件。
不执行构建检查。 "这次改动很小，应该没问题"——但 AI 的修改可能引入意外问题。
只看 AI 的汇报，不看实际输出。 AI 可能截断输出或忽略错误。
不做多轮验证。 复杂任务应该分多轮验证，而不是一次性信任。
不访问远端站点确认。 push 成功不代表页面正常，需要实际访问确认。
不检查 commit 内容。 commit message 可能不规范，或者包含了意外文件。
对个人项目的启发
项目 A（RAG 工单系统）：
RAG 工单系统的每次代码修改都应该遵循安全提交流程。特别是 AI 生成的代码，需要执行测试、检查格式、审查 diff 后才能提交。可以在 CI/CD 中增加自动检查，但本地的人工审查仍然不能省略。
项目 B（多 Agent 运营中台 Copilot）：
多 Agent 系统的提交更需要谨慎。一个 Agent 的代码修改可能影响其他 Agent 的行为。每次提交前需要检查：Agent 间依赖是否受影响、工具权限是否被修改、状态管理是否被改动。建议每个 Agent 的修改都有独立的审查流程。
面试表达
我不会跳过 AI 产出的审查环节。在面试中，我会这样表达：
AI 编程助手有两个常见问题：误提交和假验证。误提交是因为 AI 不理解仓库管理策略，可能把草稿、归档、临时文件加入提交。假验证是因为 AI 的目标是"完成任务"而不是"验证结果"，可能声称检查通过但实际没有执行。
我的应对策略是：白名单提交（只列出允许提交的文件）、禁止 git add .、要求 AI 展示完整命令输出、自己执行关键验证。在生产级项目中，AI 的代码产出需要像人类开发者的 PR 一样审查——审查 diff、执行测试、检查构建、确认远端状态。这不是不信任 AI，而是工程流程的基本要求。
后续 TODO
- 补充自动化验证脚本，把检查流程脚本化。
- 补充 Claude Code 与 GitHub Actions 的集成，实现提交前自动检查。
- 补充误提交后的回退操作指南。
- 补充假验证的更多识别信号和应对策略。