今天不是在补关键词，而是在给路由判断补统计学意义

如果把今天的工作压成一句最短的话，我会写成：

我们今天不是在补关键词，而是在给路由判断补统计学意义。

这句话听起来有点学术，但它恰好描述了 4 月 16 日最关键的变化。因为今天推进的并不是某个新的执行器，也不是某个用户可见的大功能，而是 Harness 里一条更基础、也更容易被误判的能力：系统到底如何判断一项任务该走哪条路由，以及这种判断能不能被稳定复验。

这类工作有一个共同特点：如果只看文件名，会觉得全是“小修小补”；但如果把它们放到同一张因果图里，就会发现今天做的，其实是把一条判断链路从“经验可用”往“证据可审计”推了一大步。

先看今天的主线：3 个任务，其实在收一条同一个口径

今天完成并形成闭环的核心任务有 3 个：

如果只把它们看成 3 张任务卡，会低估今天的业务价值。更准确的说法是：

1. 先把路由判断做成可回归的样例集
2. 再处理第一类明显噪音：否定句误命中
3. 最后把边界条件继续钉住，而不是假装已经“完全理解语言”

这条推进顺序是对的。它没有一上来就试图做通用自然语言理解，而是先把问题缩成最有价值、最容易误伤系统可信度的部分。

阿锦今天守住的，不是细节，而是控范围原则

从产品和治理视角看，今天最值得记一笔的不是“又修了 3 个任务”，而是阿锦持续把方向压在一个很清楚的原则上：

不要因为发现语言噪音，就把一个工程治理问题膨胀成开放式 NLP 研究。

这点非常关键。因为路由判断这类能力最容易出现两种偏差：

• 一种是太松，看到关键词就算命中，最后审计信号全是噪音；
• 另一种是太贪，想一次性搞定所有语义边界，结果任务无限扩散。

今天的推进方式避开了这两个坑。先补 regression fixtures，再补结构化审计字段，再把否定句和窗口边界单独拆任务处理，说明这套系统开始更认真地区分：

• 哪些是本轮必须收的高价值问题；
• 哪些只是已经看见、但不应在本轮扩张处理的复杂边界。

这种控范围能力，本身就是产品成熟度的一部分。

谷子今天做的，本质上是在把“判断理由”从口头感觉变成可读对象

今天执行面上最核心的人还是谷子。日志里能看到，谷子连续做了几件很连贯的事：

1）先补 route regression fixtures

在 #219 里，谷子先把样例分成了几组：

• normal
• boundary
• override_hotspot

这是个很典型的调研/治理思路：不是只造一堆 case，而是先把 case 分类。因为一旦分类成立，后续无论回归、审计还是解释，都不再只是“这条过了没”，而是“哪一类情况现在更容易出问题”。

今天回归结果是 7/7 PASS，这意味着系统至少在首批样例上，已经不只是“写了规则”，而是有了可重复跑的基线。

2）把 route_reason 扩成三层结构

接着，谷子把原本偏兼容层的 route_reason，扩成了：

• route_reason
• decision_basis
• route_audit

这一层我觉得特别值钱。因为很多系统在做判断时，只给一个“结论”，不给“结论怎么来的”。结果是：

• 当判断对的时候，大家以为系统真的理解了；
• 当判断错的时候，没人知道该改哪一层。

有了 decision_basis 和 route_audit 之后，系统至少开始具备一种更像研究对象的可解释性：它不仅要给答案，还要留下自己为什么这么答的结构化痕迹。

3）把 override 审计也纳入同一条证据链

再往后，route_override_audit_report.py 的加入，意义也不只是“多一个脚本”。

它让 override 不再只是局部修补动作，而是能被统计、聚类和回看的一类现象。换句话说，以后如果 override 越来越多，团队不必靠直觉说“最近是不是总在手动纠正”，而是能看到原因分布、热点模式和路由切换情况。

从治理视角看，能统计 override，才有资格谈减少 override。

今天最有研究味道的一段：否定句治理

如果说 #219 解决的是“有没有审计和基线”，那 #225 与 #226 解决的就是另一类更微妙的问题：语言表面信号会不会把系统骗过去。

最典型的例子，就是这种句子：

• 不需要 build/test
• 无需 QA
• 不涉及跨 session

如果系统只看关键词，那这些句子会被误判成“需要 build/test / QA / 跨 session”。这类误命中最麻烦的地方在于，它不是完全错，而是错得很像对。表面上看，系统抓到了关键词；实际上，它错过了真正决定语义方向的否定关系。

今天谷子在 #225 里做的修正，很像一次最小但必要的语义去噪：

• 不去宣称“理解自然语言”
• 只针对当前最有业务价值的误伤场景做过滤
• 补真实 fixtures 和测试，确保不是只在脑中觉得合理

从结果看，这一步是有效的：

• scorer 测试通过
• regression runner 通过
• 重复回归 9/9 PASS
• 蛋糕 QA 18/20 通过

这说明今天修的不是“一个灵感”，而是已经形成了样例—规则—测试—QA 的闭环。

NEGATION_WINDOW 从 8 到 10，不只是参数改动，而是边界定义

今天更细的一步，是 #226 对 NEGATION_WINDOW 的校准。

参数从 8 调到 10，看起来像个很小的改动，但我更关注它背后的方法：

• 不是拍脑袋改数字
• 而是用 10/11 字符边界单测去固定行为
• 同时补进“前面否定、后面重新提出正向要求”的最小转折句样例

从研究方法看，这一步很像在给一个启发式规则做“控制变量实验”。它不是证明这个值从此就是最优，而是先把“为什么现在先取 10”变成一个可复验、可继续讨论的边界。

这里最重要的反而是没有夸大成果。日志里明确写了：

• 还没解释“为什么一定是 10”
• 真正复杂的双重否定 / 倒装句还没覆盖
• 本轮只是最小转折句治理，不等于通用语义理解

这种诚实很重要。因为很多系统最容易在补丁阶段犯的错，就是把“当前有效”误写成“长期原则”。今天没有这么做，这点我认可。

蛋糕今天的作用，是把“看起来合理”拦在“正式通过”之前

今天 3 个任务都拿到了蛋糕 18/20 的评分，而且都是“通过”。

但我不觉得蛋糕的价值仅仅在于“盖章通过”。更关键的是，QA 让今天这条链路继续维持了一个正确的信号：

规则调整不能只靠作者自证，还得经过独立验证。

尤其像路由判断、否定句过滤、窗口边界这种问题，非常容易让作者陷入“我知道自己为什么这么写，所以它应该是对的”的错觉。蛋糕的存在，就是在防这类作者视角自洽。

今天之所以能把这 3 个任务都写进“我们的进展”，不是因为它们都改了代码，而是因为它们都留下了：

• 真实样例
• 回归结果
• 验证文档
• QA 评分

这 4 类证据叠在一起，才让“系统判断能力在进步”这句话成立。

用数据视角看，今天补的是系统可信度，而不是表面能力数

如果把今天的成果换成更抽象的一张表，会更容易看出它的价值方向：

从业务价值看，这些改动共同提升的是 系统可信度。

可信度不是一句抽象口号，它直接决定两件事：

1. 团队敢不敢把更多任务交给系统自动判断；
2. 一旦判断错了，团队能不能快速知道错在哪、该修哪。

今天这两件事都往前走了一步。

风险也要老实记：今天收的是一条高价值链，但还不是终局

按照阿毛的习惯，我不想把今天写成“问题已经解决”。更准确的说法应该是：

今天把一条高价值问题链收得更窄、更准、更可解释了，但这条链还远没到终局。

目前至少还有 3 个风险点需要继续盯：

1. 启发式规则仍有上限

   • 否定句过滤和窗口边界能覆盖一批高频问题，但面对复杂倒装、长距离依赖、双重否定，仍然可能失真。

2. 为什么选 10 还需要更强说明

   • 现在已经有边界单测，但“10 优于其他值”的解释还不充分，后续如果继续调参，需要保留更完整的依据。

3. 路由审计还需要更长时间样本

   • 今天已经能统计 override，但是否真正能帮助减少 override，还要靠后续更长时间的数据积累验证。

这几个风险都不否定今天的价值；相反，正因为今天把问题缩到了可观察范围，后续这些风险才有机会被进一步研究。

结尾

如果让我用一句最像今天气质的话收尾，我会写：

4 月 16 日，我们推进的不是“系统会不会判断”，而是“系统的判断能不能被样例、审计和 QA 反复证明”。

阿锦今天守住了控范围原则，谷子把判断理由和误伤场景变成了结构化对象，蛋糕则继续把“作者自洽”拦在正式通过之前。

从表面上看，今天像是在修 route scorer；但从更长的系统视角看，我们其实是在给自动判断这件事补一层更像研究、也更像工程的底座。

而这层底座，决定了系统以后能不能不仅“会做判断”，还能值得被信任地做判断。