一条命令停在执行的门口。可能是装一个依赖，也可能是删一批数据。系统要在这一刻给出结果：放行、拦下，或者交给人看一眼。
顺着直觉走的一步，是把这一问交给模型。模型读得懂命令在说什么，读懂了自然就能判。
可读懂和担责不是一回事。装依赖判错了，重跑一次；删数据判错了，没有重跑。
判断的对象从来不是这句话什么意思，是错了以后谁付代价。
赶着上线的时候，误拦比漏放更招人烦，因为它是当下唯一看得见的损失。漏放要等很久才显形，显形的时候，已经没人记得是哪次判定放过去的。
决策不是分类，是代价怎么分
分类任务问这是什么，决策任务问错了会怎样。两句话只差几个字，落到系统里是两套完全不同的东西。
分类可以算准确率，因为把一张猫认成狗和把一张狗认成猫，损失差不多。命令判决不行。漏放一条危险命令，损失不可逆；误拦一条普通命令，多一次人工确认。这两类错不能相加，一平均，唯一要紧的信息就没了。
一个准确率数字报出来，听的人会以为系统整体可信。真实情况是，这个数字把危险命令和大量正常命令混在一起算平均。前者在样本里只占一小撮，全判错了，准确率照样好看。
准确率在这里不是算得不够细，是问错了问题。
这不是新问题。权限系统早先遇到过同一道题，难点从来不是判不出身份，是判错之后要不要留痕、要不要有人签字、能不能事后翻出来。决策智能把这道题挪到了执行层，题面换成了命令和工具调用，性质没换。
所以第一步不是选模型，是把代价分层：哪一类错绝对不能发生，哪一类错了只是多一次人工确认。分完这一层，才谈得上判。
先把确定性划走
规则层先跑，输出三类结果：确定放行、确定拦下、说不清。
只有说不清那一类进模型。这就是两级判决，规则一级，模型一级，各管各的。
这么分的好处不在快。规则给的是确定答案，模型给的是概率；把确定性的事交给概率模型，等于给自己加一层本来不需要的不确定。模型还得多算一次，多一次等待，多一个事后要解释的地方。
优先级必须写死。必须人工确认的规则要排在自动放行白名单前面，否则一条宽泛的放行规则会抢在前面把危险命令放走。这类漏放排查起来很费劲：规则都在，日志也全，只是顺序反了。
还有一条边界不能让模型碰：判定为必须人工的，不许被模型改写成自动。这是硬闸门的语义，不是可以调节的开关。模型给出再高的置信度，也只是说不清那一类里的一个分数。
长命令截断、编码差异、组合命令里的第二部分，都归规则层的预处理。把整段日志原样喂给模型去猜，既费时，又给了一堆无关上下文。
模型只负责规则说不清的那一小段。
判决口只能有一个
多个调用方各写一套判定，最先出问题的不是准确率，是一致性。一边更新了规则，另一边还握着旧快照；同一个动作，从两个入口进去得到两个结果。这类漂移不会报错，只会让人慢慢不再相信判定。
收成一个进程、一个端口、一份返回结构。返回里带齐判定结果、命中依据、置信度、规则层给出的原始判定，以及这条输入是否可判。调用侧只留一层薄适配，把统一结果翻成各自原本的契约，不重写判定逻辑。
单端口还省下一件事：超时、限流、降级各写一份就够，不必每个调用方各自实现一遍，也就不会出现这头收紧、那头放行的情形。
整套判定放在本机，是这条路径的前提。规则、权重、账本都在本地，判决不依赖远端服务的可用性，命令和上下文也不必送到别处去。远端一断，执行链不该跟着失去判断力。
规则表和配置文件按修改时间热读，改完不必重启进程。热读要有保护：读到一份坏配置时沿用上一份可用的，而不是让整套判定跟着一起停。
没匹配上要有明确标记，不能默认当放行。不可判定的输入单独记一类，交给上游决定是转人工还是重试。少了这个标记，规则表的空隙会变成一条谁也没写过的放行规则。
判决口的价值不在它多聪明，在所有调用方看到的是同一句话。
边界比主路径更要紧
主路径跑顺了只算一半。要问的是失败时往哪边倒。
规则求值抛异常，默认收紧，拦下来再说，同时给一个明确的回滚开关，能退回旧行为。收紧会让人烦，但比静默放行好处理：前者看得见，后者要等出事才知道。
判决口超时是另一回事。执行链不能跟着一次判定停摆，放行就成了还能走的那条路。这一处是敞开的，写方案时得明写，不能藏在主路径的光鲜里。
把边界说清楚，比宣称全覆盖有用。
规则上线前要做静态体检。查三样：正则之间有没有互相冲突，确认类规则和放行类规则的优先级有没有排反，命中原因和标签表是不是一一对应。这三样都能在提交前查出来，不必等线上出事。
再配一份回放语料，危险命令和正常命令各一组，改一次规则跑一次。回放比从日志里抽样便宜得多，也稳定得多，样本不会随时间漂移，改坏了当场就能看见。
一条新规则的风险，不在它写得对不对，在它有没有把旧规则悄悄盖掉。
账本和拒绝理由
每次判定记一条：输入摘要、判了什么、依据哪条、走的是规则还是模型、模型给的分数、流量标记。自测流量和真实流量分开打标，否则回放产生的数据会把真实分布带偏，后面拿这批数据做评测，结论全是歪的。
流量标记还有一个用处。改完规则之后，能单独看真实流量那一栏有没有变化，不被自测请求淹掉。
账本不是留给审计看的摆设，是唯一能回答当初为什么这么判的地方。出事之后靠回忆，最后一定是各说各话。
拒绝也不是一句不允许就完。上游要拿到能用的理由：命中了哪一类规则，可以改成什么动作，以及不要拿同样参数重试。理由按标签映射，不要把裸正则甩给上游；正则会改，标签不会。
更值钱的一步是把理由送回计划层。执行前那一段计划如果知道某类动作会被拦，可以自己绕开，而不是在同一处连撞几次，每次都等一句拒绝。反馈回到计划，比反馈回到单条命令省事。
拒绝的质量，决定这套系统是拦了一次，还是教了一次。
评测按段看，不按一个数
留出集要干净。训练用过的样本一条都不能进评测，概念验证阶段攒的数据和正式训练数据也要分开。这两处一旦混了，分数会好看得没有道理。
评测分三段报：规则段、模型段、整体。危险命令的漏放数和正常命令的误伤数分开列，不合并成一个数。模型只在它负责的说不清那一段被评价，把规则段判对的样本算进模型成绩，是自欺。
留出集再分两块。一块纯净，看方法本身的上界；一块按真实分布分段，看落地之后还剩多少。两块差得远，说明问题不在模型，在输入分布和规则覆盖。
换不换模型，就看这一段分数。规则层修几条正则、把优先级排对，当天就能验证；换一个大模型要重跑整套评测，收益未必对得起这一趟。
评测口径定错了，后面所有调优都朝错的方向走。
调优的边际在哪里
判决口的往返时间远小于一次模型推理，把这点耗时摊到整个任务周期里，几乎看不见。在这个量级上继续压延迟、做量化、加并发，不改变系统性质，只是把本来就不卡的地方修得更细。
把没收益的方向说清楚，比列一长串可做的事情有用。工程时间有限，停掉那些不改变结果的调优，才留得下给边界和反馈的余量。
真正还有余量的方向不在模型参数上。
一处是计划级预检。执行前把整段计划过一遍，标出哪些动作一定会撞闸门，比逐条命令停下来问一次要省，也更早让上游知道该改什么。
一处是拒绝理由的结构化。把一次拦截变成一次改写，让上游拿到能动手的信息，而不是一条死胡同。
一处是规则工程。规则当代码管：版本化、静态冲突检测、回放语料、提交前体检。规则条数一多，冲突就是必然的，这一处也就越值钱。
还有一处是采样治理。只留决策样本，能力类样本停采，历史数据冻结标注。不同口径采来的样本混进同一份训练集，后面再怎么调都理不清。数据先干净，模型才有得谈。
从把模型调准转向把决策边界写清，是这条路径上最实在的一次换向。模型是这套系统里最容易被换掉的一层，边界不是。
开头那条命令还停在门口。它不需要一个更懂它的模型，需要的是代价由谁承担写清楚，依据能一条条翻出来，判错的时候往哪边倒提前定好。
本地决策智能的实现路径，起点不在模型那一侧。先把确定性划走，剩下的那一段，才轮到判断。