AI 写代码已经过了"能不能写对"的阶段。现在消耗团队精力的，是智能体提上来的 PR 里那一堆细碎但确定的毛病：// TODO: handle this 这种没打算留下的注释、从聊天记录抄来的硬编码 API key、WIP 与 fix stuff 这类会话压缩后的提交信息，以及看起来是绿的、其实 head commit 上已经红了的 CI。
这类问题不值得每次都占用人类评审的注意力，可一旦放过，就真的进了 main。Codex Guard（Akimiya-z/codex-guard）就是冲着这一段来的：它不判断你的架构、不评论你的命名，只在一个地方把门——给 AI 生成的 pull request 自动把关的质量门禁。详情页给它的定位很直白，star 138、npm 包 codex-guard 当前 1.16.0、MIT 许可、最近一次提交在 9 天前。
智能体提的 PR，毛病高度集中在四类
- 注释里留着
// TODO: handle this，本来就没打算留下； - 从聊天记录里抄来的硬编码 API key 和连接字符串；
WIP、fix stuff、more changes这种提交记录——一团乱麻的会话压扁之后的样子；- 看着挺绿，其实 head commit 上 CI 是挂的。
关键在于：这四类全都是确定性的。你不需要一个语言模型去"理解"这行代码，只需要一条规则、一次正则、一次 status 查询就能判定。用 LLM 去审这些问题，既慢又贵还主观；确定性的检查则快、免费、还能当成没有争议的门禁。Codex Guard 选的正是后者——把"无聊但确定"的活接过来，把人的注意力让给真正需要判断的地方。
四类检查，各自的边界在哪
门禁一共四类检查，每一类都刻意收窄了范围，这一点比"检查得很全"更重要。
🧹 TODO 扫描只查新增行上的 TODO / FIXME / XXX / HACK / WIP。它不会翻旧账，不会拿仓库里历史遗留的注释来烦你——你只对本 PR 带进来的东西负责。
🔐 密钥扫描覆盖的面相当宽：AWS（access key + secret key）、GitHub、Google、OpenAI、Anthropic、Slack、Stripe、npm、SendGrid、Telegram、Azure 连接字符串、JWT、硬编码凭据、连接字符串。报告里会把值打码，所以即便命中了也不会在评论里二次泄露。但要记住它是正则扫描，不是语义理解——它能廉价地抓住明显的错误，替代不了真正的密钥扫描器（README 自己建议配合 gitleaks 或 zizmor）。
💬 提交规范检查不符合 conventional commits 的标题，以及空标题。
🧪 CI 状态看 PR head commit 上失败的 status check 或 check run。
最后一条的读取方式最值得琢磨：它同时读 commit status 和 check run，逐页跟进到 3,000 条的结果安全上限，把每个"已完成且结论非成功"的检查都当失败；检查仍在进行时给中性结果，不提前亮绿灯；某个 CI API 不可用就声明"可见性不完整"，两个都不可用则按失败处理（fail closed）。方向一致：宁可中立，绝不误报绿灯。
只拦"看起来像智能体"的 PR
默认情况下，人类写的 PR 永远不会被它拖慢。判定智能体的信号有三类：
- 标签匹配
codex-generated、agentic、ai-generated； - 分支以
codex/、copilot/、claude-auto、gh-codex/开头； - 标题里含
Generated by Codex、Generated by Claude、Generated by Copilot。
这些都可以配。真正需要覆盖全部 PR 的场景，把 gate-agents-only 设为 false 即可。反过来，某个 PR 如果人类已经审过并接受，给它打上 codex-guard-ignore 标签就会直接放行、不跑任何检查。
覆盖率：分清"未发现"和"未扫描"
这是整个设计里最诚实的一处。GitHub 有时会省略二进制或超大文件的文本补丁——文件在那儿，但它拿不到内容。早期版本在这种情况下只会说"没发现问题"，而这和"真的干净"是两回事：现在它明确区分两者，每份报告都给出实际检查过补丁的合格变更文件数量，输出项叫 content-scan-coverage（形如 12/13），配合 unscanned-file-count，补丁缺失时产出一条中性、不阻塞的覆盖率警告并列出路径。同一条警告也会在 GitHub pull-request files API 触及其文档所述的 3,000 文件上限时出现——处理很朴素：拆小 PR，或接受这条不阻塞的警告。
一处细节值得单独记一笔：升级已有工作流后，若报告总说"CI 可见性不完整"并返回中立结果，多半是权限没给全。模板的 permissions 是 contents: read、statuses: read、pull-requests: write、checks: write；旧工作流常只加 checks: write，它确实含 check run 的读取权限，但读不到 commit status——缺的正是 statuses: read。
让门禁"阻塞"，别把它配哑了
跑过几个有代表性的 PR、把策略调顺之后，才轮到决定拦截力度。三档预设给了清晰路径：Observe 只报告不阻塞，Balanced 阻塞密钥、提交卫生、红灯 CI，Strict 阻塞所有默认发现项；想自定义组合就走 fail-on。
这里藏着一个容易踩空的点：fail-on 接受逗号分隔的阻塞性检查 todos,secrets,commits,ci，留空等于沿用旧行为，可一旦指定子集，未列出的检查就不再阻塞。写 fail-on: todos,secrets 想"只强拦这两项"时，commits 与 ci 就顺带被放行了——表面上像"某些检查突然不管用了"。要全部阻塞，就把四项列全。
安全扫描档位：如实说
有一点不能美化。详情页对它的安全扫描档位是 🔵 含敏感能力，共 21 处证据，且尚无人工评估：可执行外部命令、读写/删除本地文件、读取剪贴板或密钥类环境变量、发起外部网络请求，涉及 docs.github.com、api.github.com、github.com。证据里几处很典型——src/main.js:63 读 github-token 或 GITHUB_TOKEN，src/cli.js:449 用 execFileSync('git', args, …) 执行 git，dsh/index.js:60 用 spawnSync 拉起命令。必须说清：这是能力清单，不是危险判定；做 PR 门禁，读 token、调 GitHub API、执行 git 本就是分内之事，但"它需要这些能力"和"它安全"是两句话，介意的人应自行评估，并按详情页建议先备份 ~/.dsh。
另外补一句实装信息：本站已于 11 天前在 dsh 0.2.0-rc.2 下真实安装成功（L4 · 真实安装），安装命令 dsh plugin --profile web add codex-guard；dsh 侧注册的工具名是 codex_guard，调用的正是 npx --yes codex-guard --git——和 CI 门禁用的是同一份报告。
总结
Codex Guard 的价值不在于"更聪明地评审"，而在于把四类确定性毛病——残留 TODO、泄露密钥、潦草提交、红灯 CI——从人的注意力里摘出去，交给一套快、免费、无争议的 CI 门禁；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：大量用 Codex / Claude Code / Copilot 提 PR、评审精力被琐碎问题淹没的团队；希望"跨过门禁才准进 main"、又不想为每次审查付 token 成本的工程组；已在用 GitHub Actions、想加一道零成本确定性检查的维护者。
不适合：想让它做语义级代码审查的人——它只做确定性检查，不懂你的架构与意图；不在 GitHub Actions 生态里的团队——它绑定 GitHub 的 PR / check 事件；只跑人类 PR、也不打算额外配标签与分支约定的仓库——默认只拦智能体 PR；以及介意安全扫描档位为"含敏感能力、尚无人工评估"的人，它确实要读 token、执行 git、发网络请求。
标签：Codex Guard、DeepSeek Harness、AI 代码评审
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。