冲突台账：把裁决写进文档，而不是写进代码

文档里两条结论打架时，不许偷偷改掉一个，也不许谁嗓门大谁赢。把矛盾原样登记进冲突台账，写清冲突双方、现象与候选方案，等人类拍板，再把裁决集中落到一张表上。

一、一份会自我贬低的文档

文档 ID REQ-DEV-AUTOBOT，版本 v4，读者明确写的是 AI 编码助手，人类是验收方。权威源顺序是代码加实测产物大于本文档大于三份说明文档，还写明行号会漂移。

四条强制规则：台账优先于正文；发现冲突不自己裁决；禁止为过闸调参；冻结条目解冻必须有新证据加人类确认，不能靠一句我觉得。

二、C-001：被推翻的是推理链，不是数据

v1 主张送达率上界约 0.17 到 0.29 来自平台每段只保留约 60 字。断点在于统计口径，打分函数是连续值，被丢弃的句子普遍拿 0.1 到 0.3 而非 0，这个口径天然看不见尾部整段归零的结构事实。

播出段与丢弃段差 4.3 倍。若真是平台容量上界，两组应同样低。被推翻的是归因对象，不是参数数值。

三、为什么不许自己裁决

C-002 是最好的例子。平台每段约 100 字究竟是识别只转这么多，还是报告展示截断，两者落地的动作完全相反，一个要动提示词压答案，一个一个字都不该改。

这不是技术选择，是价值排序。转向决定了后续几轮工作往哪走，不该由执行的人单独决定。

代价也真实：取证路径被证伪（40 份快照约 200 万字，命中候选人转写零），C-002 至今挂着待定。慢了，但没人在错误方向闷头跑三个会话。

四、裁决表：把权威集中到一张纸

裁决记录开篇写着本表是权威，凡与旧字样冲突的一律以本表为准。不改旧字样，只新开一张表并标优先级，比逐一改历史更省事也更诚实。

• C-003：阈值 0.6 不动，先出三场以上新口径分布再定，并标注该阈值由分布确定而非人为设定。
• C-004：空转话术只记账单列指标，不拦不重试。
• C-005：文本级留痕，用文本包含判定每句是否播出，比例近似禁止作为正式口径。
• C-010：同一申请编号对应多个场次，所有数字必须写成值加场次目录名。
• C-012：岗位池已耗尽是伪命题，平台 84 个岗位，池里只有 6 个。限制复用是错误方向。

五、文档自己也会咬人

文档一致性那一类共六条，目前只落地三条。凭据声明与代码不符、产物清单只列六个文件、三条待办里两条已过期、脚本清单缺口且两套编排未区分。

这类冲突的危害不是让人做错事，而是让人去做已经做完的事、或者不信已经做对的事。两者都很贵。

还有一条专门记录文档自己犯过的错，并且要求以后再动那个位置必须先在修订记录里追加一笔并复核原裁决。

六、把历史留下来

项目一直没有版本控制，直接首提会把多轮改动吞进初始提交，分不清基线前后。裁决是先补历史改动清单再建仓，于是新增了一节清单，现记到二十九条。

填写规则是只记改了什么加为什么，不贴大段代码，没把握的标待核。表里明明白白留着一条待核，写的是更早的改动未逐一回溯。

C-012 那条更正尤其值得记：拉取脚本在登录态失效时静默返回零行，两次完全不同的失败被读成了同一个结论。

七、已知与未知

已知：台账优先、不自裁、不许为过闸调参、数字带锚点、裁决集中成表，这五条都已固化并被验证好用。

未知：取证路径证伪后 C-002 至今没有答案；文档漂移只被管理没有被消灭，六条里还有三条待定；最根本的一条是，这个机制的前提是有人愿意拍板，否则台账会退化成堆积待办的停车场。

八、带走的判断

• 把矛盾登记下来，而不是消掉它。 偷偷改掉一个，会让下一次的人少看见一次选择。
• 发现冲突不要自己裁决。 你以为的技术选择，往往是一次价值排序。
• 权威要集中到一张纸上。 旧字样不删，新开一张表声明以它为准，更省事也更诚实。
• 对数字要带锚点。 同一个编号下面是好几个场次，数字互不相同。
• 记录自己犯过的错，并且记录这个位置容易错。 把结论改对只完成了一半。
• 可信度不来自无所不知，来自清楚地标出不知道的边界。

autobot/docs/REQUIREMENTS-DEV.md §0 权威顺序与 v2/v3/v4 必读 · §1.1 四条强制规则 · §1.2 冲突台账 C-001~C-012 · §1.2.1 裁决记录表 · §3.4 DOC 六条 · §6 历史改动清单；AGENTS.md 必读文档与当前状态节。