AI 编程审查清单：提交前必须检查的 10 件事
这篇文章解决什么问题
AI 编程助手（Claude Code、Copilot、Cursor 等）可以快速生成代码和文档，但"快速"不等于"正确"。AI 可能：
- 修改了不该动的文件。
- 生成了格式错误的 Markdown。
- 引入了构建问题。
- 把草稿文件加入提交。
- 声称完成了检查但实际没有执行。
- 生成的内容包含禁止表述。
- 文件行数不满足要求。
- diff 中包含 whitespace 错误。
如果你不做审查就直接提交，这些问题会直接进入远端仓库，影响线上站点。
这篇文章要回答的核心问题是：AI 编程助手产出的修改，在提交前应该审查什么？
核心观点：AI 的输出需要像人类开发者的 PR 一样审查。 提交前的审查清单不是可选的，而是必需的。
审查清单总览
| 序号 | 检查项 | 检查方式 | 失败后果 |
|---|---|---|---|
| 1 | 修改范围是否正确 | git diff --name-only | 误动不该动的文件 |
| 2 | 是否有 whitespace 错误 | git diff --check | 提交后代码格式问题 |
| 3 | 构建是否通过 | npm run docs:build | 线上站点构建失败 |
| 4 | 文件行数是否满足 | wc -l | 内容不够充实 |
| 5 | 禁止内容是否存在 | grep 关键词 | 包含不该有的表述 |
| 6 | 必要章节是否齐全 | grep 章节标题 | 文章结构不完整 |
| 7 | 表格格式是否正确 | 目视检查 | Markdown 渲染异常 |
| 8 | 只提交允许文件 | git status --short | 草稿/归档被误提交 |
| 9 | commit message 是否规范 | git log -1 | 提交历史不清晰 |
| 10 | 远端推送是否成功 | git push | 本地完成但远端没有 |
下面逐一展开。
检查项 1：修改范围是否正确
执行 git diff --name-only 查看哪些文件被修改了。
审查要点：
- 是否只有预期的文件被修改？
- 是否有意外的文件出现在 diff 中？
- 配置文件（config.mts）是否被修改？
- 主题文件（theme/）是否被修改？
- 项目页面（projects/）是否被修改？
如果发现意外修改，不要提交。先回退意外修改，再重新提交预期文件。
检查项 2：是否有 whitespace 错误
执行 git diff --check 检查 whitespace 错误。
常见的 whitespace 错误：
- 行尾有多余空格。
- 使用了 tab 而不是空格（或反过来）。
- 文件末尾缺少换行符。
这些错误看起来小，但会影响代码格式一致性，也可能导致 lint 失败。
检查项 3：构建是否通过
执行项目的构建命令，确认没有错误：
- VitePress 站点：
npm run docs:build - Python 项目：
python -m py_compile或pytest - Node.js 项目：
npm run build或npm test
AI 可能声称"构建已通过"，但你必须看到实际的构建输出才能相信。要求 AI 把构建输出完整展示出来。
检查项 4：文件行数是否满足
对于新创建的文章或文档，检查行数是否满足要求：
wc -l docs/blogs/topics/new-file.mdAI 有时会生成过短的内容，不满足"不少于 180 行"之类的要求。如果行数不够，要求 AI 补充内容。
检查项 5：禁止内容是否存在
根据写作要求，grep 检查禁止内容：
grep -n "待补充" docs/blogs/topics/new-file.md
grep -n "Chain-of-Thought" docs/blogs/topics/new-file.md
grep -n "CoT" docs/blogs/topics/new-file.mdAI 有时会忽略禁止事项，生成包含"待补充"、特定术语的内容。这些需要在提交前清除。
检查项 6：必要章节是否齐全
对于博客专题，检查必要章节是否存在：
grep -n "这篇文章解决什么问题" docs/blogs/topics/new-file.md
grep -n "面试表达" docs/blogs/topics/new-file.md
grep -n "后续 TODO" docs/blogs/topics/new-file.md如果缺少必要章节，要求 AI 补充。
检查项 7：表格格式是否正确
Markdown 表格需要正确的格式才能正确渲染：
| 列1 | 列2 | 列3 |
|---|---|---|
| 数据 | 数据 | 数据 |常见的格式问题：
- 缺少表头分隔行（
|---|---|---|）。 - 列数不一致（表头 3 列，数据行 4 列）。
- 纯文本表格（没有
|分隔符）。
AI 有时会生成纯文本表格，需要手动修复为标准 Markdown 表格。
检查项 8：只提交允许文件
执行 git status --short 查看所有待提交的文件：
git status --short审查要点：
- 是否有草稿文件（drafts/）？
- 是否有归档文件（archive/）？
- 是否有临时脚本（如 check_xxx.py）？
- 是否有 Claude 配置文件（.claude/）？
- 是否只有任务单中列出的文件？
永远不要使用 git add .。 手动列出每个要提交的文件。
检查项 9：commit message 是否规范
提交后检查 commit message：
git log -1 --onelinecommit message 应该：
- 以
docs:、fix:、feat:等前缀开头。 - 简洁描述这次修改做了什么。
- 不要包含无关信息。
检查项 10：远端推送是否成功
执行 git push 后，确认推送成功：
git push检查输出是否包含 -> origin/master 或类似的推送确认。如果推送失败，可能是权限问题或远端有冲突。
审查流程
把上面的 10 个检查项串成一个流程：
AI 完成修改
↓
检查项 1：git diff --name-only（修改范围）
↓
检查项 2：git diff --check（whitespace）
↓
检查项 3：npm run docs:build（构建）
↓
检查项 4：wc -l（文件行数）
↓
检查项 5：grep 禁止内容
↓
检查项 6：grep 必要章节
↓
检查项 7：目视检查表格格式
↓
检查项 8：git status --short（提交范围）
↓
检查项 9：git commit（commit message）
↓
检查项 10：git push（远端推送）每一步都要看到实际输出，不能只听 AI 汇报。
常见误区
相信 AI 的"已完成"汇报。 没有看到实际检查命令的输出，就不能相信 AI 说的"已完成"。
跳过构建检查。 "这次改动很小，应该没问题"——但 AI 的修改可能引入意外问题。
使用 git add .。 草稿、归档、临时文件都会被提交。
不审查 diff。 直接提交，结果发现改了不该改的文件。
不检查文件行数。 AI 生成的内容可能过短，不满足要求。
不检查禁止内容。 AI 可能忽略禁止事项，生成包含"待补充"的内容。
不检查表格格式。 纯文本表格在 Markdown 中无法正确渲染。
不要求 AI 执行检查命令。 AI 说"构建通过"但你没看到构建输出。
对个人项目的启发
项目 A（RAG 工单系统）：
RAG 工单系统的每次代码修改都应该经过审查清单。比如修改了检索模块，需要检查：修改范围是否只涉及检索相关文件、测试是否通过、是否有 whitespace 错误、commit message 是否规范。可以把审查清单集成到 CI/CD 中，自动执行检查。
项目 B（多 Agent 运营中台 Copilot）：
多 Agent 系统的修改审查更复杂。一个 Agent 的修改可能影响另一个 Agent 的行为。审查清单需要增加：Agent 间依赖是否受影响、工具权限是否被修改、状态管理是否被改动。每个 Agent 的修改都应该有独立的审查流程。
面试表达
我不会跳过 AI 产出的审查环节。在面试中，我会这样表达：
AI 编程助手的产出需要像人类开发者的 PR 一样审查。我有一个 10 项的审查清单：修改范围、whitespace、构建、文件行数、禁止内容、必要章节、表格格式、提交范围、commit message、远端推送。每一步都要看到实际的命令输出，不能只听 AI 汇报。
在生产级项目中，AI 的代码产出更需要严格审查。我会要求 AI 执行测试和构建，审查它的 diff，检查是否引入了安全问题、性能问题或兼容性问题。AI 是高效的工具，但不是可靠的审批者——最终的审查责任在人。
后续 TODO
- 补充自动化审查脚本示例，把 10 个检查项自动化。
- 补充 Claude Code 与 GitHub Actions CI 的集成，实现自动审查。
- 补充审查清单在 Python 项目中的应用示例。
- 补充审查清单在多 Agent 项目中的扩展检查项。