push 之前先考试：Show HN 上的 Sphinx 逼你证明读懂了 AI 写的代码

10 月 18 日，一个 Git 钩子在 Hacker News 的 Show HN 板块拿下了 200 多分。它叫 Sphinx，作者的自我介绍只有一句话：接进你现有的 coding agent 工作流，每次 push 到生产环境之前，弹出问卷检查你是否理解即将推送的代码。

这年头拦 push 的东西太多了：lint、单测、pre-commit、CI。但 Sphinx 拦的不是代码，而是写代码的人——更准确地说，是那个没写代码的人。AI 写完，你点点头，git push origin main。Sphinx 在 main 分支前面举起一只手：等等，先证明你读懂了。

它的机制很干净。安装只要两行：npm install -g sphinx-understand，然后 sphinx install。它不读你的聊天记录——官网原话是 "A reviewer that never saw your chat reads the diff"，只读 diff 出题。它也不当 reviewer，而是当考官，考题只有一个母题：这个改动失败时会发生什么？

demo 里给了一个教科书级的例子：webhook 处理函数先存 event ID，再调 charge()。Sphinx 问：Stripe 超时，同一事件重发一次，会发生什么？你说：跑两次，客户被收两次钱。它说：不对——重试时发现已存的 ID，直接回 200，不扣费。但这个 ID 是在 charge 成功之前就存下的。如果 charge() 本身失败了，下一次重试会干什么？你得一路答到想明白"失败的 charge 意味着客户永远不会被扣费"，钩子才放行。考的不是语法，是幂等性的心智模型。追问到答对为止。

顺带一提它的标语："You can outsource your thinking, but not your understanding."——落款孙子。评论区立刻有人考据：这话不是孙子说的，是 AI 研究员 Yacine Mahdid 的原话，被 Karpathy 拿去放在 Sequoia AI Ascent 大会演讲的中央。真假孙子不重要，重要的是这句话恰好点出了整个工具的立场：思考可以外包，理解不行。

设计上还有几个克制的细节。token 消耗极小，可以用你自己的 agent，也能接 OpenRouter 或任意 OpenAI-compatible endpoint；支持 Codex、Claude Code、Cursor、OpenCode、Pi，纯 Git 也行。你的回答不会回流给 coding agent——这很关键，等于切断了作弊链：agent 不能替你考试，.env 和密钥也不会被打开。真赶时间？sphinx yolo 直接放行，但每一次跳过都会被记进日志。作弊留痕，这一招把"要不要诚实"从道德问题变成了一个审计问题。

评论区最有价值的一条来自 fwlr：门禁放错了地方。"把它从'push 到生产环境之前'改成'请求人类注意力之前'，这东西会真正起飞。"他的意思是，守在生产环境门前，防的是一类事故；但放在"submit PR""update PR"按钮那里，防的是一类浪费——让同事去 review 一段你自己都没读懂的 diff，是在浪费另一个人的时间。

这条评论点破了 Sphinx 的定位尴尬。它自称守的是生产环境的门，但它真正想守的是理解力的门。生产环境门前已经有一整套成熟防线（CI、灰度、回滚），不缺这一个钩子；而"人类注意力"恰恰是当下最稀缺、也最没有防线的资源。reddmachine 也从另一个方向补了一刀：选择题格式会让人靠猜，猜对不等于懂。

但整条评论区最有分量的一句话，来自作者本人。chacha-bong 写道："Lol I built this and immediately got frustrated with it and stopped using it. I think I don't like being questioned by someone who I expect to work like magic."

造完就被问烦了，弃用了。一个花钱请来"像魔法一样工作"的 agent，回头拷问你懂不懂它变出来的戏法——这种心理落差，原理上受欢迎、实践中招人烦。这正是 Sphinx 最值得写的一笔：它不是死于技术，是死于人性。它精准戳中了 vibe coding 时代的集体焦虑——theParadox42 的高赞评论说，"有时最有效的办法就是把目标描述清楚，然后逼 AI 撞到做对为止；这个过程耗掉我大量精力，我却没学到任何有用的东西"——然后它开出的药方，又被同一个人性拒绝了。

这也不是第一个类似的想法。jeffreysmith 在评论区说，六个月前他们做过 PEAK（Proof of Effort And Knowledge），自带 TUI 和一整套反作弊机制（包括故意放无效问题），面向的是 OSS 贡献和企业这种半对抗场景。maximg68 做了个"Quiz me on the PR"的 skill，sailorganymede 的 vibecheck.dev 直接把关卡放在 PR 合并层。大家不约而同地撞向同一个问题，说明这确实是个真问题；但也都撞向同一堵墙：自愿的理解税，没人想交。

Sphinx 的聪明之处在于它重新定义了 review 的对象：传统 review 假设代码是人写的，review 是找 bug；agent 时代代码是 AI 写的，review 的第一步是确认"人还跟得上"。评论区有人说得好："Learning is the bottleneck for shipping code." 以前打字是瓶颈，现在理解是瓶颈。

但 Sphinx 的遭遇（至少是作者本人的弃用）也说明了一件事：理解税不能靠"考试"来收。考试防君子不防小人——dawnerd 分享了亲身经历：他们团队要求手写 PR 描述，结果 dev 们照样让 AI 全代劳，"还会跟你争辩说写 PR 太费时间"。真想收这笔税，可能得像 fwlr 说的换个收税点；或者像 PEAK 那样，干脆承认这是半对抗场景，把反作弊当正经功能做。

AI 写代码之后，人类 review 的瓶颈从"看不看"变成了"看不看得懂"。Sphinx 给这个时代留下的，不是一个好用的钩子，而是一个诚实的问题：当代码快得不需要你写了，你还愿意为"看懂"付多少钱？作者用弃用投了票。你呢——下一次 push 之前，敢不敢让它考你一次？