Codex 写 Commit，你敢全自动？我把三级自动化都跑了一遍，这几条红线别碰

元日。思旧念远

508人浏览 · 2026-08-12 15:03:17

元日。思旧念远 · 2026-08-12 15:03:17 发布

Codex 写 Commit，你敢全自动？我把三级自动化都跑了一遍，这几条红线别碰

最近 Codex 自动写 Commit 的话题在开发者圈子里吵翻了。有人吹"以后 git 不用自己动手了"，有人骂"AI 提交的代码出 bug 算谁的"。我把从"半自动生成提交信息"到"改代码+提交+开 PR 一条龙"的三级自动化全跑了一遍，结论先放这：全自动是大趋势，但谁让你在生产分支上 --full-auto，谁就是在给你埋雷。

一、先说清楚：Codex 的"写 Commit"到底到了什么水平

现在的 AI 写 Commit 已经不是"根据 diff 猜个标题"这么简单了，分两条线：

云端 Agent（ChatGPT 里的 Codex）

基于 codex-1 模型（o3 的软件工程特化版）跑的独立沙箱环境，预加载你的仓库，能读文件、改代码、执行测试和 linter，跑完自己 commit，还能直接 push 分支、开 PR。整个过程有终端日志和测试输出做"证据链"，你可以在合并前逐条核对。

开源 Codex CLI（本地终端）

npm install -g @openai/codex
# 或
brew install codex

CLI 是 git 感知的：能分析暂存区 diff、理解提交历史、识别分支上下文，然后按 Conventional Commits 规范把改动分组成多个原子提交，而不是一锅端。

一句话总结：它现在缺的不是"会不会写"，而是**“该不该让它放手写”**。这才是这个热点的真正争议点。

二、三级自动化，我全部实测过

Level 1：半自动 —— 生成，但必须人工确认

日常开发最稳的一档。AI 负责产出，你负责判断：

git add .
codex exec "Review all uncommitted changes and create meaningful commits:
1. Group related changes
2. Write clear commit messages
3. Follow conventional commits format
4. Create separate commits for different concerns"

它输出类似这样的东西：

feat(api): 添加用户登录接口的速率限制

- 在 LoginController 中集成 RateLimiter 中间件
- 配置 Redis 作为限流存储后端
- 添加每分钟最多 5 次登录尝试的限制
- 修复了之前限流配置未生效的问题

注意最后一条——“修复了之前限流配置未生效的问题”，这是我从代码注释里写的，它真能提取出来。这已经比大部分人类写的 commit 强了。

但是，我也翻过车：它把"修复空指针"写成了"添加空指针"，方向完全搞反，差点误导同事。所以 Level 1 的底线是：提交前扫一眼，30 秒的事。

Level 2：提交信息全自动 —— git hook 接管

不想每次手动敲命令？用 prepare-commit-msg hook 把生成动作自动化，你只管 git commit：

#!/bin/bash
# .git/hooks/prepare-commit-msg
COMMIT_MSG_FILE=$1
COMMIT_SOURCE=$2

# merge/revert 跳过
if [ "$COMMIT_SOURCE" = "merge" ] || [ "$COMMIT_SOURCE" = "revert" ]; then
  exit 0
fi

BRANCH=$(git rev-parse --abbrev-ref HEAD)
CHANGED_FILES=$(git status --porcelain | head -n 5 | awk '{print $2}')

codex exec --full-auto \
  "请为 Git 提交生成一条符合 Conventional Commits 规范的中文消息。
  当前分支: $BRANCH，改动文件: $CHANGED_FILES。
  要求: 第一行不超过 72 字符，包含 feat/fix/chore 前缀。"

# 写入提交信息文件
echo "$COMMIT_MSG" > "$COMMIT_MSG_FILE"

效果：敲下 git commit，等几秒，符合规范的中文提交信息自动生成。团队里新人提交信息从此不再五花八门，代码 review 的质量肉眼可见地涨。

小坑：这类工具大多只分析暂存区。忘了 git add 的话，它只能看到空荡荡的 diff，生成出来的信息约等于废话。

Level 3：全自动 —— 改代码 + 提交 + 开 PR 一条龙

这才是真正刺激的档位：

codex exec --dangerously-bypass-approvals-and-sandbox \
  "Create feature branch, implement auth, commit, and create PR"

或者云端 Codex 直接在沙箱里跑完整个任务，commit、push、开 PR 全自动，你最后只需要在 GitHub 上点 Merge。有人已经把整套 workflow 写成了脚本：develop_feature "user-notifications" "Real-time notification system with WebSocket"，一条命令从建分支到提 PR。

效率确实夸张——非交互模式下重复性工作能快一个数量级。但代价也全在这了，往下看。

三、全自动的代价：我踩过的坑（全是真事故）

坑 1：Commit 信息与内容不符

“修复空指针"写成"添加空指针”。AI 偶尔会把语义方向搞反，而且它写得越自信，越没人怀疑——这是最危险的。全自动模式下这条信息会直接进历史，以后 git blame 查到的是错的注释。

坑 2：敏感文件被带进提交

--full-auto 模式下 AI 执行 git add . 时，不总是尊重 .gitignore。.env、密钥、内网地址一旦进历史，删掉也没用——Git 历史是删不干净的，等于把钥匙交给了所有看过仓库的人。这在开源仓库是直接社死级别的事故。

坑 3：提交粒度失控

全自动最容易出现的场景：一次 commit 里塞了 3 个无关功能 + 1 个重构 + 顺手改的格式。reviewer 看到这种 commit 直接血压拉满，回滚也变成噩梦。

坑 4：测试没跑就提交

Level 3 下如果项目没有可靠的测试基座，AI 说"我测过了"可能只是"我跑了一下不报错"。它确实会迭代到测试通过，但测试写得好不好，决定了它验证的是不是空气。测试缺失的项目，全自动提交 = 全自动埋雷。

坑 5：责任归属

这是团队里最现实的问题。git blame 显示的是你的名字。AI 提交的代码上线出 bug，复盘会上锅不会落在模型头上。全自动省下的时间，会在修事故时加倍还回来。

坑 6：GPG 签名与审计

全自动模式下提交没有你的 GPG 签名，或者更糟——脚本里配置了签名密钥，等于把你的身份凭证交给了每次都可能被 prompt injection 的 AI 执行环境。合规审计和供应链安全两个维度都是硬伤。

四、我的分级自动化策略（可直接抄）

场景	推荐级别	原因
个人玩具项目 / 一次性脚本	Level 3	仓库没别人看，翻车成本≈0，随便折腾
个人开源项目	Level 2	历史是你的名片，信息要规范但不必过度防御
团队日常开发分支	Level 1~2	提交信息统一、review 轻松，合并前必须人工
团队生产分支 / main	禁止全自动	强制 PR + 人审，CI 全绿才允许合并
CI / 定时任务脚本化	Level 3（隔离环境）	只在一次性容器里跑，产物进 PR 供人审

Codex 自动写 Commit 三级自动化策略

红线清单（违背任何一条，后果自负）

生产分支永远不碰 --full-auto，这条没有讨论余地；
全自动模式下，本地仓库不配置任何真实密钥，凭据走环境变量注入；
提交前强制过一遍 secret 扫描（gitleaks 之类），别信"AI 会自己注意"；
项目必须有一套能跑的真测试，AI 提交前强制跑完才能放行；
全自动只发生在隔离沙箱/CI 容器里，你本地仓库永远保留 Level 1~2 的人工确认权。

五、落地配置清单（直接抄）

1. AGENTS.md —— 给 AI 立规矩

Codex 官方明确支持用仓库里的 AGENTS.md 约束行为，相当于给 AI 的"员工手册"：

# AGENTS.md

## 开发流程
- 所有改动必须通过测试才能提交: `npm test`
- 提交信息遵循 Conventional Commits 规范
- 禁止提交: *.env、*.key、node_modules/

## 安全红线
- 任何涉及凭据、密钥的操作，先向用户确认
- 生产分支的改动只生成 PR，禁止直接 push

2. pre-commit 兜底（团队强制）

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: end-of-file-fixer
      - id: trailing-whitespace

3. CI 校验（GitHub Actions 片段）

- name: Secret Scan
  run: gitleaks detect --source . --report-format json --report-path report.json
- name: Run Tests
  run: npm test && npm run lint

这套组合拳打下来：AI 负责速度和规范，CI 负责安全底线，人负责最终判断。

结尾：别让工具替你思考

我的立场很明确：Level 1~2 是现在的甜区，Level 3 是明天的必然，但今天直接上全自动的，要么项目不重要，要么早晚出事。 AI 写 Commit 解放的是体力劳动——把 diff 翻译成规范文字、把改动拆成原子提交——但"这段代码该不该上线""这个密钥能不能进仓库"这种判断，永远是人的责任。

与其焦虑"AI 会不会抢我饭碗"，不如先把工具链的边界划清楚。自动化做得多快不是本事，自动化之后你还能兜住多少，才是本事。

📌 评论区聊聊：你现在的仓库用到了第几级？有没有被 AI 提交坑过的经历？