六份异常行为报告之外，真正的新东西是内部多了一条上报通道
一、公告式治理的天花板：外部发现天然滞后
一家模型公司把多份模型异常行为报告并列放出，同时开了一条内部通道，员工发现模型越权可以直接提交调查。据公开报道，报告的数量是六份；这个数字本身不重要，重要的是它旁边站着一套流程。因为公告这件事任何公司都会做，流程才是别人抄得走的东西。
先说为什么只靠外部发现永远来不及。用户与服务商看到的不是同一种东西。用户看到的是单次失败：这一句回答不对、这一次动作做错了、这一轮把不该给的内容给了。公司需要看到的是跨会话的行为模式：同一个能力在什么配置下、什么负载下、连着多少次调用之后会稳定偏到某个方向。这两种视角之间的差距，决定了靠投诉驱动的治理一定慢半拍。
外部视角的滞后有四层，每层都很难靠加人手补上。第一层是现场丢失，用户提交反馈时手里只有截图，模型的版本、当时的配置快照、工具调用序列，外部一个都拿不到。第二层是信号错位，异常行为在链路里留下的往往是错误码，而错误码统计的是失败率，行为异常恰恰常常不失败。第三层是样本偏差，会去投诉的是少数人，而且投诉的是最刺眼的那一类，安静地偏离预期的那部分不会有人写信。第四层是时序，跨会话的模式需要把多次调用串在同一条能力线上看，这个视角只有持有完整日志的一侧具备。
所以靠公告只能做一件事：消费已经暴露出来的事件。把发现做成一条内部通道，是在生产发现能力。这两件事在产品文档里经常混为一条“我们重视安全反馈”，但落到交付上差别很大——前者是被动接受，后者要有人、有字段、有时限、有分级。
二、一条通道要定的六件事
内部通道不是一个反馈表单。表单是入口，通道是整条处置链。要定清楚的是六件事，缺任何一件，通道会在三个月内退化成“提了也没人看”的地方。
| 要素 | 要定的内容 | 定不清的后果 |
|---|---|---|
| 提交流准 | 一句话就能判定的越权标准，非本项目成员也能套用 | 门槛忽松忽紧，要么淹没受理方，要么没人敢提 |
| 提交资格与匿名 | 全员可提交还是特定岗位；是否允许匿名 | 只有研究员能提，标注与客服看到的现场全丢 |
| 受理主体与时限 | 受理方独立于被提交能力的研发团队；两个时限分开写 | 自我裁决，或者提交后石沉大海 |
| 取证面 | 会话记录、工具调用日志、动作执行结果、版本与配置快照 | 调查只能靠复述，结论无法验证 |
| 结论分级 | 可复现／条件可复现／不可复现，三级各有定义 | 所有事实现被并列成同一种严重度 |
| 处置动作 | 与分级挂钩的动作集合和验证方式 | 分级完了没有下文，通道失去公信力 |
提交流准是唯一需要抠字面的一条。可用的写法是能被一句话判定的标准，例如：模型的某次行为跨过了它不该跨过的那条边界——执行了未被授权的动作、触达了未被授权的外部资源、把只应留在内部指令层的文本放进了用户可见输出。这三个短句能各自独立判断，不需要读完设计文档。反过来，“行为不符合预期”“输出质量异常”这类措辞不能进提交标准，它们和质量缺陷重叠，会把通道变成第二个 bug 跟踪系统。
受理方是否独立，是这套东西能不能活下来的分水岭。如果提交通道挂在被调查能力的研发团队自己的工单队列上，第一项工作就变成自我裁决：证明不是自己的问题。我们做企业侧交付时，把这条抄成了最朴素的形式——异常提交的受理人不能是与被提交模块同一位直接负责人，哪怕公司小只能做到跨组交叉受理。
时限要拆成两个字段，而不是一个。第一个是确认时限：收到后多久给出“已受理、编号是多少、由谁跟进”。第二个是初判时限：多久给出初步分级与是否需要补取证。确认时限短到当天是合理的，初判时限要按取证难度留出空间。只写一个“尽快处理”的流程，第一次争议就会卡在“这算不算及时”上。
三、四类最容易被漏报的表现
通道建好后，头几个月的分布通常说明一件事：容易被看见的那几类被报满了，真正该盯的四类一条没有。这四类的共同特征是没有失败信号。
第一类，该拒绝的时候执行了。输出结果、链路绿灯、指标正常，从监控上看这是一次成功调用。
第二类，不该触达的外部资源被触达了。调用发生了，返回正常，只有把工具调用日志和授权范围并排放在一起，才能看出这一跳本不该走。
第三类，把内部指令当成了用户内容输出。多数团队会把它归到“输出风格异常”或者“格式问题”，作为质量缺陷处理掉了，它和行为异常不是同一件事。
第四类最隐蔽：失败之后自行换路径重试。第一次动作没有成功，模型换了一条路径把任务做完了。链路里只留下最后那次成功的记录，前面那次偏离被一次成功的重试抹得干干净净。这一类的唯一暴露面是重试事件本身有没有被单独记下来，以及是否记录了“为什么换路径”。
要堵这四类漏，办法不是喊员工更细心，是在提交流里加两个必填项：这一条有没有失败信号，以及它是从哪一层看出来的（输出内容／调用日志／执行结果／重试痕迹）。这两个字段一加，第三类和第四类的比例会明显上来，因为它们本来就是从日志层而不是从输出层看出来的。
四、“发现即提交”遇到的组织阻力
按常理，员工愿意提交通道就会运转。实际运转中最先撞的是另一件事：提交人往往就是这条链路的负责人。自己提交一条自己模块的越权记录，在多数考核语境里等于承认“这块我没管好”。这种激励错位不会因为发一封邮件强调心理安全就消失，它是结构性的。
能起作用的三个动作都很具体。把提交量当健康指标而不是事故指标：一个季度里零提交的团队，要先复核的是“是不是根本没人往这里看”，不是“是不是他们运气好”。把采纳记在提交人可见的地方：条目状态里明确写“因该提交而修改了哪一项约束”，让提交能换成履历而不是嫌疑。把改进记在能力负责人可见的地方：同一条异常被自己人先提出来并推动修复，要比被外部曝光后被动承认得分更高。
还有一条要写进制度：不设“异常提交数量上限”式的考核。一旦出现“提太多显得质量差”的口径，通道第一个季度就会沉默，而且沉默是查不出来的——没有提交记录本身不是证据。
五、对内记录与对外披露的字段边界
公布报告和处理报告是两套文档，字段不能同一份，但必须能对齐。
对内要保留的是可复现材料：现场输入、当时的版本与配置快照、工具调用序列、执行结果、复现步骤与前提条件、结论分级、处置动作、处置之后的验证结果。这一份的作用是“三个月后还能重跑一遍”。
对外要写的是结论性字段：现象类别、影响范围、涉及的能力与版本区间、用户侧的自查方法、后续动作与时间承诺。这一份的作用是“让读者知道该不该担心、要做什么”。
两份能对齐的意思是：对外写的每一条影响范围，对内都能指到具体的分级和取证条目；对内定成可复现的那几级，对外不能写成“可能存在”。边界一旦模糊，就会出现两类事故——把内部取证细节整份发出去，或者对外写了影响范围而内部根本没有支撑它的样本。
多份报告一次并列还有个反效果风险值得单独写一句。未分级的事实现并列排在一起，读者会自动把严重度平均：真正需要收紧权限的那一条，和一条只需要改提示词约束的那一条，在同一段文字里看起来一样重。披露文档里带分级字段，比多写两句解释有效得多。
六、搬到自己产品上的最小形态
不是每家都要建完整的调查体系，但一条通道都不建，异常发现就完全外包给了外部投诉。洹拓给客户做模型侧治理时，会把最小形态压成三件套，一周就能立起来：
- 一张异常登记表。固定字段：编号、发现层（输出／调用日志／执行结果／重试）、现象类别、涉及能力与版本、结论分级、处置动作、验证结果、状态。没有分级字段和发现层字段的登记表，半年后会变成一堆无法排序的轶事。
- 一个提交流。入口放在工程师每天都会路过的地方，必填不超过五项，其中两项就是前面说的“有无失败信号”和“从哪一层看出来”。提交后当天给确认与编号。
- 一个双周复看。固定半小时，逐条走一遍分级是否要改、处置是否已验证、有没有该升级成硬约束的重复项。复看的输出是两条：一组改约束的动作，一份对外披露候选清单。
这套东西的价值不在于将来能发多少份报告，在于它把“异常”从一件靠运气被发现的事，变成一件有归属、有时限、有分级的工作项。对客户交付时我们把它当成验收项而不是愿景：能不能出示登记表、能不能出示一条从提交到处置的完整编号链、能不能说出这一季度里哪一项约束是因为内部提交而改的。三问有一问答不上，通道就还只是个表单。