发现渠道：Hacker News · AI
获取渠道：原站公开正文
当 Agent 写完代码，开发者可能能说出需求，却解释不了失败路径。Sphinx 把这个落差做成一个具体流程：推送到受保护分支时，独立审查模型读取已提交的改动，以场景题让人预测代码行为；它不读取生成代码时的聊天。如果回答暴露误解，系统解释后再给新场景，通过后才继续同一次推送。项目提供跳过和 yolo 选项并记录原因，问答不返回给原编程 Agent；这些是实现文档中的设计声明，本日报未安装验证。
README 用后台队列作演示：worker 已提交业务操作，却在确认消息前崩溃，队列再次投递时会不会重复执行？下一题再改变可见性超时和并发条件，检查回答者是否真的理解去重边界。这个例子是作者的示范，不是已经发生的生产事故。更有信息量的是项目自己的评测：10 月 15 日记录的最新固定源码 V19/V20 覆盖五个小型合成仓库，七道生成题的十四个判分探针有十二个符合预期；授权题曾因回答未提特定代码条件而拒绝充分解释，配置题还暴露了题目措辞与格式问题。作者明确写出，即使 560 项单元与集成测试通过，也不代表语义评测全绿。
可信度 65 · 重要性 79 · 新颖度 65
技术与主题
Agent 系统 · AI 编程 · 评测与基准 · Coding Agent · Comprehension Check · Failure Mode · Human-in-the-loop
Sphinx 项目作者
README 明确限定当前产品的保证。
jamienk
Sphinx 的 Show HN 评论。
忠实转述（非原句）：他担心这会变成另一种需要人不断确认的疲劳流程，最后人们又让 Agent 替自己答题。担忧并非否认理解的重要性，而是质疑强制门槛在真实使用中能否保持作用。
sshah03
评论者自述做过相近的问答和可视化 PR 总结设计。
忠实转述（非原句）：他也想补足对改动的理解，但选择把问答做成可选项而不是阻断关卡，因为代码量让逐项强制检查的负担很高。这是另一种产品取舍，不是对 Sphinx 效果的受控测试。
hypfer
同一讨论中区分需要维护的代码与临时工具。
忠实转述（非原句）：他把场景分开：需要关心的代码会自己读；临时用途的代码则可能只关心是否完成需求。按这种工作方式，强制测理解在前一种场景可能重复，在后一种场景可能不是目标。
编辑评读
强制回答把理解成本放到了推送之前，但仍要回答两个问题：题目是否测到了真实风险，评分是否公平。单元测试能确认 hook 和流程按设计运行，不能替审查模型证明每道题都问得正确。项目主动保留判错记录，使它比只展示成功对话更值得研究；这些仍是作者的合成评测，不能据此认定能减少生产事故。
讨论里的分歧集中在工作目标。长期维护的系统需要人掌握失败条件；一次性工具可能只需要满足可验证的需求。把所有改动都变成考试，可能造成疲劳，甚至促使人找另一个 Agent 代答。合理的下一步是观察同类改动中误判、绕过、后续修复与实际理解的变化，而不是用答题通过率单独代表团队能力。
需要留意
- v0.1 不覆盖网页合并、CI 必需检查或部署；理解问答不等于代码安全审计。