AI 写的代码，你真的看懂了吗？Sphinx 在 Git push 前加一道理解检查
AI 编码助手把实现速度推高了，代码审查却未必同步变深。diff 看起来合理、测试也通过，不代表提交者能解释关键状态变化和失败路径。开源项目 Sphinx 选择在 Git 推送前暂停一次：它针对本次变更提出关于行为、边界条件或不变量的问题，答错会解释并给出新的情境题，答过后才放行。这是一种理解练习，不是证明代码安全或作者身份的认证。
Sphinx 的主页和仓库 README 将它描述为面向 Agent 辅助开发的 Git hook。触发检查后，独立的 reviewer 模型读取已提交变更，并通过只读 Git 工具查看相关代码；它不读取生成代码时的对话上下文。问题因此更接近“这段逻辑在故障时会怎样”，而不是让你背文件名。仓库当前采用 MIT 许可证，项目文档列出的运行环境包括 Node.js 22.19 或更新版本、Git，以及 macOS、Linux 或 WSL；原生 Windows 暂不支持。
检查发生在推送路径上
快速开始先安装 npm 包并安装 Git hooks：
npm install -g sphinx-understand sphinx install
随后进入目标仓库初始化项目策略：
cd your-repo sphinx init
README 也展示了非交互式用法，例如 sphinx install --yes --preset claude-economy --agents claude，以及 sphinx init --yes --branches main。第一次安装会配置用户级 core.hooksPath，因此影响这台机器上的多个仓库；已有 hooks 会先运行。初始化生成 .sphinxconfig、.sphinxignore 和 .sphinxcontext.md，若文件已存在则不会覆盖。应先检查忽略规则，避免不希望发送的路径进入模型请求。
当向受保护分支推送时，Git 会等待检查完成。用户可以在本地问答界面预测变更行为；答错后系统解释并追问相关概念。检查可暂停或跳过，项目文档说明单次等待最长可达 25 分钟。深度、分支和触发事件可通过仓库配置调整。sphinx doctor 用于检查集成配置：
sphinx doctor
把它当训练，不要当安全闸
这套设计适合代码由 Agent 快速生成、团队希望开发者练习理解关键逻辑的场景。例如在合并涉及重试、幂等或异步任务的改动前，问题可以迫使提交者解释失败窗口，而不是只确认“测试绿了”。不过它有现实成本：推送会被阻塞，编码 Agent 的 shell 超时可能早于 Sphinx 的等待上限；测试前应先在个人分支体验，避免把远程 CI 或自动化推送意外卡住。
隐私边界也要认真看。README 明确说明 reviewer 服务会收到变更代码及相关文件、回答和 .sphinxcontext.md；默认排除 .env、私钥和常见凭据文件，但路径忽略规则不能识别粘贴在普通源文件中的秘密。敏感仓库应在首次检查前完善 .sphinxignore，并审查所选模型服务及其数据政策。没有默认模型调用上限，文档给出的典型检查约为 5–8 次请求，回答还会增加调用；接入按量付费的 provider 时应设置预算限制。
更重要的是，Git hook 不是不可绕过的安全控制：本机用户或 Agent 仍可绕开 hooks，也可能向外求助；模型提出的问题本身可能有误。把 Sphinx 视为促使团队停下来理解代码的练习机制，而不是代码质量、测试、权限控制或安全审计的替代品。先在非关键仓库试跑，观察问题是否贴合项目，再决定是否纳入日常推送流程。