2026-10-23 每日思考

今天 GitHub 上同时出现两个项目让我停了很久：Claude-Red 把渗透测试方法论编译成 Claude 技能，book-to-skill 把技术书编译成 Claude Code 技能。它们用同一套机制，一个教模型怎么攻，一个教模型怎么查。而我自己正在做的 AI 代码审查工具，本质上就是这条光谱上的第三格——教模型怎么"看出问题"。

这让我重新审视自己 MVP 的一个设计假设。我最初把审查工具的核心定义为"检测能力"：能不能发现 SQL 注入、能不能识别 N+1 查询、能不能标出未释放的资源。但今天 ArXiv 那篇 EpiSEM-Bench 点醒了我：它测的不是 Agent 会不会判断错，而是当证据缺失时 Agent 会不会默认放行。这恰恰是代码审查工具最真实的失效模式——不是误报，而是漏报，而且漏报往往发生在"上下文没给全"的时候：跨文件的调用链没读到、配置在另一个仓库、运行时行为无法从静态代码推断。

我的工具现在大概率也在犯这个错。给它一个函数，它能挑出明显的 eval；但给它一个只截取了 200 行的 diff，它很可能对缺失的上下文保持沉默，然后给出一个"看起来通过"的结论。这种沉默比误报危险得多，因为用户会把"没报问题"当成"没问题"。

所以我想在下一版里加一个反直觉的功能：让工具主动报告"我没法判断的部分"。具体做法是，对每个检测项维护一个"证据充分性"评分——比如检测越权访问时，如果拿不到路由中间件和权限模型的定义，就显式输出"此项证据不足，建议人工确认"，而不是静默跳过。这会把一部分"通过率"变成"待定率"，短期看指标变难看，但长期看，一个知道自己不知道的审查工具，才配被放进 CI。

再往深一层想，Claude-Red 和 book-to-skill 的火爆说明技能包正在成为新的分发单元，那么代码审查工具的未来形态可能也不是一个独立 SaaS，而是一组可以被装进任何 Agent 的审查技能。这既是机会也是威胁：机会在于分发成本骤降，威胁在于"审查能力"会像 prompt 一样被商品化，护城河只剩两样——检测规则的深度，和对"证据不足"的诚实。前者可以追赶，后者是价值观，追不回来。

给同行的建议：如果你也在做 Agent 类工具，今天就去做一件事——在你的评测集里加一类"故意缺失关键上下文"的样本，看你的系统是报错、是瞎猜、还是沉默。沉默是最坏的那个答案。

预测：半年内会出现专门评测"Agent 在信息不完整时的保守性"的基准，并成为企业采购 Agent 工具的必查项。EpiSEM-Bench 只是开了个头。