孙子（Sun Tzu）曾写道“Outsource your thinking, not your understanding”。斯芬克斯（Sphinx）是面向智能体辅助开发的 Git（Git）钩子，在你的智能体代码推送前，它会就代码实际行为提问。通过 npm install -g sphinx-understand 安装后，它依托现有编码智能体、OpenRouter（OpenRouter）或兼容 OpenAI（OpenAI）的接口，以极少 token 运行。执行 git push origin main 时，斯芬克斯检查 main 分支，显示 11 个文件变更、新增 5,012 行、删除 3,147 行，并给出示例：webhook 处理器在调用 charge() 前保存事件 ID，若 Stripe（Stripe）超时并重发同一事件，重试会怎样？用户回答被纠正后，才推送代码。

“外包你的思考，
但不要外包你的理解。”

——Sun Tzu

Sphinx 是一个用于 agent 辅助开发的 Git hook。在你的 agent 的代码被推送之前，它会问你一个关于这段代码实际作用的问题。

npm install -g sphinx-understand

它可以在极少的 token 上运行，接入你现有的 coding agent、OpenRouter，或任何兼容 OpenAI 的端点。

$ git push origin main

sphinx · understanding check for main

11 files changed · +5,012−3,147

Sphinx

你的 webhook handler 现在会在调用 charge() 之前保存事件 ID。Stripe 超时并再次发送同一个事件。重试时会发生什么？

你

它会运行两次，所以客户被扣款两次。

Sphinx

不完全对。重试时会找到已保存的 ID，并返回 200 而不扣款。但这个 ID 是在扣款成功之前保存的。如果 charge() 失败，下一次重试会怎么做？

你

它会跳过扣款，所以客户永远不会被收费。

✓ 已理解。正在推送到 origin/main。

这是一个示例对话。真实的问题来自你的 diff。

1. 01

   你推送。

或者由你的 agent 推送。Git 会在你保护的分支上暂停。

2. 02

   Sphinx 提问。

一个没看过你聊天记录的审查者会读 diff，并问这个改动在出问题时会发生什么。

3. 03

   你回答。

答错了，你会知道原因，然后试一个新场景。答对了，推送继续。

它支持 Codex、Claude Code、Cursor、OpenCode 和 Pi，也支持纯 Git。你的回答永远不会传给 coding agent，.env 文件和密钥也绝不会被打开。赶时间？sphinx yolo 会让推送直接通过，并且每次跳过都会被记录。

一分钟内开始。

需要 Node 22.19+（macOS、Linux 或 WSL）：

1. npm install -g sphinx-understand
2. sphinx install

然后照常推送： git push

sphinx install 会连接 Git 和你的 coding agents，并询问由哪个模型进行审查。其他内容请阅读文档。

多数评论对这款以提问迫使开发者理解 AI 生成代码的工具抱怀疑或嘲讽，认为它多此一举、治标不治本，或会被代码审查等既有流程覆盖，强制闸门只是新的工作流噪音；少数人则支持把它当作减缓盲目合并 AI 代码的“减速带”，认为对新手、团队和开源维护者有价值。分歧主轴是：用 AI 检查人是否理解 AI 代码，究竟是纠正粗心的必要补充，还是又一层本末倒置的形式主义。

认为工具多此一举，因为真正关心代码的人本就会读，不关心的人依旧不在乎

• 很多评论指出，在乎代码质量的开发者会亲自阅读并约束 AI 输出，不需要被考问；而只想拿到能跑结果的开发者根本不关心代码，被提问只是他们不想要的摩擦，因此目标用户非常模糊。还有人做过同类工具后立刻弃用，因为不喜欢被一个本该“像魔法一样”工作的 AI 反过来考问。（较多人） > 在乎这个问题的人根本不会靠它去“理解”代码，不在乎的人依旧不在乎，所以它到底给谁用？（@altmanaltman）

认为这是治标不治本的补救，且会被 AI 自身绕过或产生新的不可靠环节

• 有评论用“悬崖底部的救护车”形容它只在事后补救，无法阻止不理解代码的 AI 产物先被推上去；更反直觉的是，未来会出现替开发者与 Sphinx 交互的 AI 代理，让提问闸门被绕过。也有人提醒，用 AI 写的工具去检查 AI 写的代码，检查过程本身也可能幻觉，还把人变成持续集成流水线里的测试对象。（较多人） > 用不了多久，就会有 AI 代理替我们去和 Sphinx 交互，这恐怕行不通。（@jamienk）

认为问题抓对了，但代码审查流程本就该负责，无需额外工具

• 有评论承认“确保开发者理解 AI 代码”是正确的问题陈述，但通常代码审查已经在承担这一职责，再单独做提问闸门显得重复。（少数人） > 问题陈述是对的，但我们通常让代码审查流程来处理这件事。（@cjimesh）

认为强制闸门应改为可选，AI 拉取请求体量已让强制提问不堪重负

• 有评论分享自己做过类似的“拉取请求可视化摘要 + 提问”项目，最终决定把它做成可选功能，而不是合并前的强制闸门；因为现在 AI 拉取请求数量越来越多，即便可选都快承受不住，强制只会成为负担。他同时认同背后想让人理解 AI 代码的需求。（少数人） > 把它做成可选、而不是强制的合并闸门会更好，因为拉取请求体量已经大到连可选都快扛不住了。（@sshah03）

认为它对新手、团队和开源维护者是必要的减速带

• 支持者反驳“劣质代码坏”的嘲讽，指出粗心、盲目复制粘贴不理解的代码早已有之，不是 AI 时代才有；开发者群体每约三年翻倍，意味着半数从业者经验不足三年且很多人没学过计算机，这类提问闸门能像当年警告别复制不懂的 StackOverflow 代码一样，把人从“不知道自己不懂”里拉出来。有做过类似项目的人补充，团队里确实有人直接把工单丢给 AI、不理解就发货，文化改变虽是正解却很难，工具至少能快速踩下刹车；他自己做的 vibecheck.dev 就是在拉取请求层面阻止合并，而非在提交时提问。还有人认为它对开源维护者会非常有用，连追求“鲁莽效率”的人也承认靠逼 AI 达到结果学不到技能，因此欢迎能促进理解与成长的工具，即便不确定这是不是正解。（少数人） > 这类工具会成为新的警告声，就像五到十年前提醒我们别复制自己不懂的 StackOverflow 代码一样，是好事。（@nkmnz）

有价值的补充

• 有人把工作流变化概括为：从微管理代码，变成微管理工具和 Markdown。（@gandhiandy69）
• 项目取名 Sphinx，与成熟的 Python 文档生成器 Sphinx 撞名；有人因此调侃，做“劣质代码生成器”前也该先检查名字是否已被占用。（@linkdd）
• 面对“人用 AI 写代码、再让 AI 考人是否理解”的循环，有人反问：到底谁是谁的主人？（@man_luke）