Show HN 周日出现一个 240 分的小工具：Sphinx。一句话介绍——它是一个 Git 钩子，在代码 push 到远程之前拦住你，要求你回答一个关于这段 diff 实际行为的问题，答对了才放行。项目的口号很抓人：「你可以把思考外包给 AI，但不能把理解外包。」在智能体写代码的时代，这句话戳中的正是很多团队的新痛点：代码量暴涨，理解度欠账。
它到底怎么工作
Sphinx 的流程只有三步，安装后注册为 Git 钩子，在你配置的保护分支上触发：
- 你 push。你或你的编码智能体执行推送，Git 在保护分支上暂停。
- Sphinx 提问。它读取 diff，就「这个变更出问题时会怎样」现场生成一个场景问题。
- 你回答。答错：Sphinx 解释原因，让你基于新场景再试；答对：push 继续执行。
官方把它形容成一个「从未看过你与 AI 聊天记录」的代码审查者——它只基于 diff 提问，不关心代码是谁写的、怎么来的。这个定位很聪明：审查对象是即将合入的变更本身，不是写代码的过程。
它给出的示例问题极能说明提问风格。场景是：Webhook handler 在调用 charge() 之前保存了 event ID，Stripe 超时后重发同一事件，retry 时会发生什么？第一反应错误答案「客户被扣款两次」被纠正：retry 会找到已保存的 ID 并返回 200 而不再扣款。但 Sphinx 追问：这个 ID 是在扣款成功前保存的，如果 charge() 失败，下一次 retry 会怎样？这时才轮到正确答案浮出水面——retry 会跳过扣款，导致客户永远不会被计费。确认理解后，终端打出「Understood. Pushing to origin/main.」
注意这个例子的设计感：问题不是考记忆力，而是逼回答者把「正常路径」和「失败路径」都走一遍。这种失败场景追问恰恰是 AI 生成代码最容易埋雷的地方——智能体写的快乐路径通常很漂亮，异常路径经常想当然。
安装与生态兼容性
安装路径是标准的 npm 全局安装：
npm install -g sphinx-understand
sphinx install环境要求 Node 22.19 以上，支持 macOS、Linux 与 WSL。sphinx install 会自动连接 Git 和你的编码智能体，并询问用哪个模型执行审查。兼容面写得很明确：官方支持 Codex、Claude Code、Cursor、OpenCode、Pi，以及普通 Git 工作流。模型来源也留了充分自由——可以复用你现有的编码智能体、OpenRouter，或任何 OpenAI 兼容端点。
价格与许可证：免费，MIT 协议，官方标注 FOSS。仓库在 GitHub 的 parthh01/sphinx，npm 包名 sphinx-understand，文档在仓库 README。
隐私与 token 经济：两个容易被忽略的设计
同类工具最常见的担忧是「我的 diff 和回答会不会喂给某个云端服务」。Sphinx 在这两个点上做了明确承诺：
- 回答永远不会发送回编码智能体。问答发生在钩子进程与你之间，不回流到 agent 会话。
- 不读取
.env文件或密钥。diff 抓取有范围约束，不会把环境变量文件卷进上下文。 - 以极少的 token 运行。设计目标就是轻量：一次 push 一道题，不做全量代码审查，token 消耗与一次普通对话相当。
对数据敏感的组织，把审查模型指向自建或内网的 OpenAI 兼容端点，就能把整个数据流圈在自有基础设施内——这个开放性是闭源审查工具给不了的。
紧急出口：sphinx yolo 与审计留痕
任何拦截机制都会遇到「我现在必须推」的时刻。Sphinx 的出口是 sphinx yolo：强制放行当前 push。关键是它没有把绕过做成静默操作——所有跳过记录都会被日志留存。这意味着事后可以审计「谁在什么 commit 上跳过了理解力检查」，把绕过从暗处拉到明处。一个团队如果 yolo 率持续走高，那本身就是个信号：要么题目质量有问题，要么这个仓库不适合这套流程。
分析：它填补了什么空位
AI 辅助编码普及后，团队的代码风险结构变了。过去的主要风险是「写错」——现在测试、类型检查、审查机器人都在管这个。新的风险是「看不懂」：智能体十分钟生成三百行，reviewer 点个 approve，三个月后出事故，原作者（包括人类和智能体）都说不清当时为什么这么写。传统的 code review bot 评的是代码质量，CI 跑的是正确性，没有一个机制检查「按下合并按钮的人是否理解自己在合并什么」。Sphinx 把这道检查做进了 Git 流程里，位置选得很准。
它的局限也同样明显。第一，出题质量完全取决于所选模型，弱模型的问题会流于表面，强模型才问得出 Stripe 那种连环追问。第二，它只覆盖保护分支，功能分支上的提交不受约束。第三，理解力是场问答游戏，熟练工可以学会「怎么答对」而非「怎么理解」，钩子防不住形式主义。第四，对真正的单人项目，这套流程是纯摩擦。
所以它的正确打开方式是团队级工具：智能体生成代码占比高、人员流动大、事故复盘里反复出现「说不清当时为什么」的团队，值得在核心仓库试运行——用两周统计放行率、答错率和 yolo 率，三个数字会告诉你它到底是在造护栏还是在造堵车。
结语
Sphinx 本身很小：一个钩子、一道题、一条放行线。但它把「理解不能外包」这个原则变成了可执行的工程动作，而且在隐私、模型自由度和审计留痕三个细节上都做了正确选择。在满世界都在用 AI 加速写代码的 2026 年，一个逼你慢三十秒的工具，可能比又一个自动补全更有长期价值。