提交前安全检查清单

很多任务真正出问题，不是在“改代码”那一步，而是在“准备提交”的最后五分钟。

因为这时候最容易出现几类情况：

• 任务做完了，但改多了
• 功能改对了，但把无关文件带上了
• 页面修好了，但构建没看
• 日志删了，但敏感信息还留在文件里
• 提交说明写得太虚，后面根本看不懂

所以提交前必须有一张清单。

不是为了形式，而是为了把最后一道最容易漏的关卡补上。

前置教程：团队里怎么约定 Codex 使用边界
如果你还没有建立“哪些动作必须人工确认”的意识，先看前置教程。

依据来源：OpenAI Codex 官方手册中关于 diff、review、command execution、approvals、workflow 的说明。

本篇目标

学完后，你应该能做到：

1. 知道提交前至少要检查哪些东西。
2. 知道哪些问题必须先停下来，不要急着提交。
3. 知道如何让 Codex 按清单自查。
4. 知道用户自己最后还要看哪几眼。
5. 知道什么时候“先不提交”反而更专业。

先记一个原则

Codex 可以帮你改、帮你查、帮你总结
但最后准备进入仓库时，用户必须看最终结果

这不是不信任 Codex，而是提交这一步天然更正式，必须更谨慎。

提交前最少检查 6 件事

1. 改动范围对不对

先确认：

• 改动是不是只落在当前任务相关文件里
• 有没有顺手带出无关文件
• 有没有把历史问题和当前任务混在一起

这是第一关，也是最重要的一关。

如果范围已经跑偏，后面检查再多也没有意义。

2. diff 能不能看懂

不是只看“有没有变化”，而是看：

• 这些变化是不是和任务目标一致
• 有没有莫名其妙的格式化
• 有没有无关重命名
• 有没有不该删掉的内容

如果你自己都看不懂这个 diff，就不要急着提交。

3. 有没有敏感信息

提交前必须过一遍：

• .env
• token
• 密钥
• Cookie
• 内网地址
• 用户隐私数据

特别是配置、日志、示例代码、截图说明这几类内容，最容易不小心带进去。

4. 最小必要检查做了没有

不是所有项目都要跑完整测试，但至少要弄清楚：

• 有没有做最小必要检查
• 如果没做，原因是什么
• 当前结果是不是还需要人工补查

你不一定每次都要追求最重的验证，但不能对检查状态含糊。

5. 提交说明是不是讲得清楚

一个差的提交说明通常像这样：

fix
update
修改一下

这种提交过几天再看，基本没有信息量。

更稳的提交说明至少要回答：

1. 这次改了什么。
2. 为什么改。
3. 范围大概在哪。

6. 有没有还没确认的风险点

例如：

• 页面本地看起来对，但没在移动端看
• 构建通过了，但没确认某条边界流程
• 改动很小，但涉及公共组件
• Bug 消失了，但根因判断还不够稳

这种时候，最专业的做法往往不是硬提交，而是把风险写出来。

一张真正能用的提交前清单

以后每次准备提交前，你都可以直接让 Codex 按这张清单自查：

请先不要提交 Git。

请按下面清单完成提交前检查：

1. 检查当前改动涉及哪些文件。
2. 判断这些文件是否都属于本次任务范围。
3. 查看 diff，并用中文说明每个主要改动和任务目标的关系。
4. 检查是否存在无关改动、顺手修复或历史问题混入。
5. 检查是否包含 .env、token、密钥、Cookie、用户隐私信息或其他敏感内容。
6. 说明本次任务已经做了哪些最小必要检查，哪些还没做。
7. 如果存在风险或未确认项，请单独列出。
8. 最后判断：现在是否适合提交。

请按下面格式回复：

## 改动范围
- 修改文件：
- 是否超出范围：

## Diff 说明
- 主要改动：
- 是否有无关变化：

## 安全检查
- 是否发现敏感信息：
- 是否发现高风险改动：

## 检查状态
- 已完成检查：
- 未完成检查及原因：

## 提交判断
- 是否建议现在提交：
- 提交前还需要我确认什么：

这段建议你长期保存。

用户自己最后一定要看的 4 个点

哪怕 Codex 已经帮你总结了，你自己最后也至少要看下面 4 个点：

1. 文件列表
2. 关键 diff
3. 检查结论
4. 风险提示

原因很简单：

提交是把结果正式留下来
这一步值得用户自己最后看一眼

哪些情况不要提交

下面这些情况，建议直接停：

• 改动范围明显超出任务
• 还有没解释清楚的无关变化
• 检查失败且原因未分清
• 包含敏感信息
• 提交说明还很空
• 你自己看 diff 时已经觉得“不太对劲”

“先不提交”不是拖延，而是控制风险。

如果 Codex 说“可以提交”，你也别省掉最后确认

你可以把 Codex 的判断理解成：

它帮你把大部分检查做完了
但最后确认权还在你手里

所以更稳的节奏是：

1. 让 Codex 自查。
2. 你自己快速过一遍关键 diff。
3. 没问题再允许提交。

怎么避免把多个任务挤进同一个提交

这个问题非常常见。

尤其是你连续让 Codex 干了几轮之后，很容易变成：

• 第一轮修样式
• 第二轮改文案
• 第三轮顺手补 README

最后全混在一个提交里。

更好的做法是：

一轮任务结束
先做提交前检查
确认这一轮能否单独成一个提交
不行就先拆开整理

不要等改了很多轮之后再一次性收口。

什么时候可以让 Codex 直接帮你起提交说明

可以，但前提是：

1. 改动范围已经清楚。
2. 你已经看过 diff。
3. 任务边界没有跑偏。

这时可以这样说：

请基于当前实际 diff，给我写 3 个简洁的中文提交说明候选。

要求：
1. 不要夸大范围。
2. 不要写空话。
3. 用“做了什么”为主，不要写营销式描述。

这样生成的提交说明会更靠谱。

你可以长期复用的一句提醒

以后只要准备提交，先在心里过一遍这句话：

范围对不对
diff 清不清楚
敏感信息有没有
检查做到哪一步
还有没有没说清楚的风险

这五句其实就是提交前安全检查的核心。

完成标志

做到这里，如果你已经形成下面这些习惯，就说明本篇已经起作用了：

1. 提交前先看范围，不是先想“快点提交”。
2. 会看 diff 是否和任务目标一致。
3. 会检查敏感信息有没有混进去。
4. 会确认最小必要检查做到哪一步。
5. 风险没讲清楚时，知道先停，不急着提交。

下一步建议

安全边界这一组到这里已经有比较完整的基础闭环了。下一波我建议继续补“排障手册”里的高频问题，比如：

• Codex 登录失败怎么判断是网络问题还是账号问题
• Git unsafe repository 怎么处理
• 模型接口超时、401、404 分别怎么判断