Sphinx 是一个旨在促进代理辅助开发的 Git hook，它通过确保开发者对所发布的代码保持深入理解来实现这一目标。当开发者或 AI 代理尝试将代码推送到受保护的分支时，Sphinx 会拦截该操作，并根据 diff 中的特定更改向用户展示一份测验。其目标是超越单纯地将代码编写“外包”给 AI，还要确保开发者理解底层的逻辑，特别是新代码如何处理故障状态或意外输入。
该工具通过分析代码 diff 并生成测试开发者理解能力的题目来运行。例如，如果更改涉及一个在调用支付函数前保存事件 ID 的 webhook 处理程序，Sphinx 可能会询问如果支付提供商超时并重试请求会发生什么。开发者必须提供正确答案才能继续推送。Sphinx 旨在以极少的 token 运行，并可以连接到 Cursor、Claude Code 或 OpenCode 等各种编码代理，或与纯 Git 配合使用。它旨在保护隐私，确保用户的回答永远不会传回编码代理，并且在处理过程中绝不会打开 .env 等敏感文件。
虽然该工具解决了日益严重的“垃圾代码”（slop）问题——即代码功能正常但开发者理解不足——但它也引发了关于其实际效用的争论。一些用户认为，保持理解最有效的方法是手动编写代码，而不是使用一道关卡来检查 AI 生成的工作。其他人指出，该工具可能会为高效的开发者制造阻碍，同时可能无法捕捉到“隐性”错误，例如残留的调试打印或变弱的断言，这些问题在测验中可能可以解释清楚，但仍存在于代码中。此外，还存在“确认疲劳”的风险，即开发者最终可能会使用代理来回答 Sphinx 的问题，从而可能完全绕过预期的学习机制。Sphinx 还包含一个“yolo”模式，用于优先考虑速度的情况，允许推送继续进行，同时记录每一个跳过的理解检查以便稍后审查。
证据： 1. Sphinx 作为 Git hook 运行，在推送完成前针对 diff 提出问题（主要）。 2. 该工具旨在与多个编码代理和兼容 OpenAI 的端点配合工作，同时保持隐私（主要）。 3. Hacker News 上的评论者讨论了将测验作为关卡的权衡，一些人认为它为高效用户制造了阻碍，而另一些人则认为这是针对 AI 辅助工作流中缺乏理解能力的必要检查（hn-50137950）。 4. 一位评论者指出，测验可能无法捕捉到存在于 diff 中但不在开发者理解范围内的 issue，例如残留的调试打印（hn-50137950）。