去年冬天整理一套内部技术规范写到第三百页的时候我停下来喘了口气回头一翻才发现问题大了前面章节里说的“可靠”指的是复现误差在阈值内后面章节里说的“可靠”变成了“团队觉得没问题”某条结论在特定输入规模下测出来的数据被人直接搬到完全不同的规模上当作通用规律评审会上争得最凶的地方往往不是结论对不对而是“我们到底在争什么”。这三件事看起来是三个毛病根子上是一个病体系没有骨架全靠经验往上堆堆到一定高度就没人说得清哪块砖承重、哪块砖是装饰。Kucius Science Theory Framework下文统一简称 KSTF就是在这种需求下长出来的东西——它用公理驱动打地基拿三刀清场做裁剪把AI分布式审计当外部校准器最后收在一个刚性科学主权框架里。说人话就是它是一套教你如何把零散经验、口头共识、行业惯例压缩成一份经得起追问、经得起复现、也经得起换人接手的方法论。这套东西最适合三类人写规范和技术标准的人、维护评测基准和知识库的人、以及任何需要让“我们的体系”在别人面前站得住的岗位。新手可以照着流程走一遍老手可以直接拿它的判定表去体检自己现有的文档。1. KSTF 的整体设计与选型逻辑1.1 从“经验堆叠”转向“公理收敛”的那道坎大部分体系崩掉不是因为内容错而是因为不可追溯。你问一条规则为什么这么定回答是“一直都是这么定的”你问两个条款冲突了听谁的回答是“看情况”。这种体系有个共同特征它的正确性依赖于某几个具体的人还在不在岗。人一走体系就变成一堆没人敢动的祖传代码。公理驱动的核心动作只有一个把所有结论的合法性收敛到一组数量极少、彼此独立、能被单独拿出来检验的底层假设上。类比一下盖楼公理就是地基桩桩的数量有限、位置明确、每根都能单独做承载力检测上面的墙、梁、管线再怎么复杂受力最终都得回到那几根桩上。如果一栋楼有八十根桩还互相重叠那它其实等于没有地基——因为出问题时你根本不知道该查哪一根。我做这套设计时定的第一条硬规矩是任何一条规则必须能在三步之内指回某条公理或者指回某条已经被证明的定理。指不回去的不进主体进附录。这条规矩看着简单执行起来会逼你面对大量“其实一直没人证明过但大家都在用”的内容。这才是真正有价值的部分。1.2 三刀清场为什么必须排在公理之后有人会问能不能先裁剪再立公理效率不是更高不行顺序反了会出大问题。三刀清场是裁剪动作不是创造动作它需要一个裁剪基线而基线只能来自公理层。你先砍后立砍的时候凭的是当下的直觉等公理立起来你会发现砍掉的里面有一部分其实是必要支撑被砍掉的必要支撑又不会有第二次机会回来。举个我实际遇到的场景。某团队做知识条目治理第一轮直接按“这条有没有人用”砍掉了三成条目砍完发现评测流程跑不通了——被砍的条目里有一批是边界条件说明平时没人主动查但一旦出现异常输入全靠它定位。后来他们重做先立三条公理输入必须可枚举、输出必须可判定、异常必须有归属再按公理去裁那批边界条目不但没被砍还被提升成了核心条目。所以 KSTF 的执行顺序是固定的立公理 → 三刀裁剪 → 分布式审计 → 冻结发版。这个顺序不能调换调换了就不是 KSTF 了。1.3 把审计交给 AI 的真实动机我猜很多人看到“AI 分布式审计”第一反应是“用 AI 审自己的东西能靠谱吗”。这个疑问很对但动机得说清楚用 AI 不是为了让它判断对错是为了获得低成本、高并发、全程留痕的第二意见。传统评审的瓶颈在人力。一份两百页的规范找三个专家通读排期两周评审会上两小时最后留下的记录是会议纪要里几句话。三个月后有人质疑某条款你连当时谁投了反对票都查不到。AI 审计体解决的是这个环节它可以对每一条目独立出一份结构化意见带时间戳、带上下文指纹、带具体反例而且可以重复跑、可以换模型跑、可以做盲审。关键在于“分布式”三个字。单个 AI 给的意见本质上是单点采样方差极大。分布式审计要求多个相互隔离的审计体分别作业最后做一致性检验——一致的部分大概率稳分歧的部分自动浮出水面变成争议条目。这套机制的价值不在于 AI 有多聪明而在于它能把“哪里可能有坑”标出来让人力只花在这些地方。1.4 刚性科学主权到底在管什么责任“刚性”和“主权”这两个词听着有点重落到操作上其实很具体就三条第一术语唯一。同一个概念在整个体系里只能有一个名字、一个定义不允许出现同义词、简写变体、口语替代。这条看着琐碎实际是争议的最大来源。我见过一个项目“准确率”这个词在四份文档里有四种算法口径最后所有跨部门对齐会议都在吵这个。第二判定唯一。给定同样的输入和同样的规则版本任何人执行都应该得到同样的输出。做不到说明规则里藏着未参数化的自由裁量。第三版本可追溯。任何一次修改都要留变更单写清改了什么、为什么改、影响哪些条目、谁批的。体系对自身边界拥有定义权同时必须接受外部复现检验——这两件事不矛盾前者是“我说了算”后者是“我说了算的东西你得能自己验一遍”。2. 公理层怎么写才立得住2.1 一条合格公理要过的四个硬指标我在实操中总结出四条检验标准任何一条不过就别往公理层放。指标具体要求不合格的典型写法可陈述单句主体条件断言不含歧义连词“系统应当尽量保持稳定”可操作能指出至少一个可观测量与它的对应关系“设计要符合行业最佳实践”可否定能说清什么观测结果会让它失效“数据质量很重要”独立去掉它其余公理推不出它把定理硬塞进公理层第三条最容易被忽略但它恰恰是区分“公理”和“口号”的分水岭。一条不能被否定的陈述不是知识是态度。比如“输出必须可复现”这条是可否定的——你只要找到一次相同输入产生不同输出的情况它就失效了。而“输出应当合理”你永远找不到反例因为它压根没给判定标准这种就必须打回。第四条独立性实操里的做法是画一张推导矩阵行是公理列是公理格子填“第 i 条能否推出第 j 条”。如果某格填了“能”那 j 就不是公理降级成定理。这个矩阵做一遍通常会砍掉三到四成你原本以为是公理的东西。2.2 公理数量为什么要压到七条以内这不是玄学是成本算出来的。公理之间要做两两独立性检验检验对数等于组合数 C(n,2)n5检验对数是 10n7检验对数是 21n10检验对数是 45n12检验对数是 66每对检验不是扫一眼就完事要构造至少三个边界用例去验证“A 推不出 B 且 B 推不出 A”工作量随对数线性增长。更麻烦的是审计环节审计体要对每条公理单独出意见公理数量翻倍审计调用量翻倍争议裁决的会议时间翻倍。所以我把上限定在七条。超过七条九成情况说明你把定理写成了公理。处理办法不是硬删是先做推导矩阵把能推出来的挪到定理层并给它挂上“由 AX-02 与 AX-05 推出”这样的溯源标签。挪完之后如果还超说明这个体系想管的事情太多了该拆分。2.3 公理到定理的溯源链怎么挂每条定理必须带三样东西编号、依赖的公理列表、验证方式。我用的格式是这样的TH-014 输入枚举完整时输出判定误差不超过 ε 依赖AX-01输入可枚举、AX-03判定阈值可参数化 验证对 5 类典型输入做全枚举比对判定结果与人工标注 边界输入维度 ≤ 8单维度取值域 ≤ 64 状态已验证2024-Q3样本 1200 条这个格式的价值在于任何时候有人质疑 TH-014你不需要重新论证整条链只需要检查它依赖的两条公理有没有被动过以及验证样本还成不成立。溯源链把“重新论证”的成本从整条链降到了单个节点。一个反面案例某团队的公理层做得挺漂亮但定理层只写了结论没写依赖结果半年后有人改了其中一条公理的参数阈值下游十几条定理悄悄失效直到线上出问题才发现。这就是溯源链断了的代价。2.4 中文表述里最容易埋雷的几类词写公理最怕的不是写错是写得“看起来对”。中文里有几类词出现即意味着这条公理废了程度副词尽量、适当、合理、必要情况下。这些词没有对应观测量等于把判定权下放给了执行者的心情。隐含主体应当保证质量。谁保证保证到什么程度算保证并列模糊支持 A 和 B 或 C。到底是可以只支持一个还是必须全支持时间模糊及时响应。几分钟算及时处理办法很笨但有效每写一条逼自己补一句“如果这条不成立我会观察到什么”。写不出这句说明它还不是公理。我实际操作时会把这句话直接写进公理的备注栏作为后续审计的输入审计体拿到这句话才知道该往哪儿找反例。3. 三刀清场的执行细节与判定标准3.1 第一刀可验证性裁剪第一刀要解决的问题是这条内容属于哪个可信层级。执行时不删除任何东西只做分流输出三个桶。桶位判定条件后续处理事实层能给出具体验证路径与判定阈值保留在主体挂验证方式假设层有解释力但当前无法验证移入假设区标注“待验证”噪层既不可验证也解释不了任何现象移入附录标注“无判定标准”这里有个操作要点分流依据是“能不能给出验证路径”不是“我觉得对不对”。很多人在这一步会不自觉地把自认为荒谬的内容直接扔进噪层这是错的。判断标准要外部化不能依赖个人偏好。实际跑下来一个两百条的规则集第一刀通常分流成事实层 40% 左右假设层 45% 左右噪层 15% 左右。假设层占大头是正常的因为大部分行业经验确实没法立刻验证但它们有解释力不该被砍。假设层的存在是这个框架和“一刀切”最大的区别。3.2 第二刀冗余裁剪与合并证明第二刀处理的是“两条规则说的其实是一回事”。判定方法不是看文字像不像是看在所有可观测场景下结论是否一致。具体做法取两条候选规则 R1 和 R2构造一个输入空间分别用两条规则判定记录所有分歧点。分歧点为空则判定等价可以合并分歧点非空但都在某个可参数化的边界内则判定“局部等价”合并后保留边界说明分歧点广泛存在则不合并。合并时必须留一份合并证明内容包含合并前后的编号映射、等价性验证的输入样本范围、合并后新条目的边界条件。这份证明不是形式主义它的作用是——将来有人想拆回去或者想恢复某条被合并的规则能查到原始依据。我踩过的一个坑早期做合并时只写了“R7 与 R12 等价合并为 R7”没写样本范围。后来发现它们只在低维输入下等价高维下 R12 的判定更严格。因为没留证明新来的人直接按合并后的 R7 执行高维场景全错。这让我后来把“合并证明”设成了强制项没有证明的合并一律回退。3.3 第三刀边界裁剪与外推禁令第三刀是整套流程里最容易被跳过、也最容易出事故的一刀。它要求每条规则必须显式写出三样东西定义域、值域、失效条件。定义域就是这条规则在什么输入条件下成立要具体到可判定。不能写“适用于常规场景”要写“输入维度 1 到 8单维度取值域不超过 64样本量不低于 200”。值域是输出的可能范围与量纲。失效条件是“什么情况一出现这条规则立刻作废”。配一条外推禁令超出定义域的输入不得套用本规则结论必须走降级路径或者转人工。这条禁令看着保守但它挡住了绝大多数“在 A 场景测出来就拿到 B 场景用”的事故。参数化怎么写才算合格举个例子对比不合格该阈值适用于数据量较大的情况。 合格该阈值适用于单批次样本量 N ∈ [200, 5000]N 200 时阈值下修 15%N 5000 时按 √N 比例缩放缩放系数上限 3.0。后一种写法可以直接写进代码前一种只能靠人猜。判断标准很简单这段描述能不能被一个没参与讨论的人在没有你的情况下照着重跑一遍。能就是合格边界不能就是废话。3.4 三刀误伤与补偿机制三刀砍下去一定会误伤这是必然的关键是有没有补偿通道。KSTF 设了两条第一条是降级不删除。被裁掉的内容不销毁进假设区或附录保留原始编号和裁撤理由。这样将来条件成熟比如有了新的验证手段可以原路恢复不用重写。第二条是影子区机制。对于争议大、暂时无法定性的条目单独放影子区标注“不参与主体判定但保留观察”。影子区的条目每季度复审一次要么升级要么出区。我个人的经验是真正需要彻底删除的条目占比不到 3%。绝大部分被裁的内容只是位置放错了不是内容错了。把“删除”改成“移位”团队的抵触会小很多流程也更容易推下去。4. AI 分布式审计的工程化落地4.1 审计体怎么设计才算真独立“分布式”这三个字如果做假了整套机制就退化成自我确认。最常见的假独立是同一个模型、同一个提示词、跑四次当成四个审计体。这不叫分布式这叫重复采样四次结果高度相关一致性再高也没有信息量。真独立至少要满足三隔离隔离维度做法目的模型族隔离至少两个不同来源的模型避免同源训练数据带来的同向偏差上下文隔离每个审计体独立会话不给其他审计体结论防止锚定效应角色隔离形式审查、反方攻击、复现审查、外部视角让不同审计体关注不同失效模式四种角色的分工我实践下来是这样形式审查看术语一致性、编号连续性、引用完整性属于机械检查反方攻击专门找反例任务是“想尽办法证明这条是错的”复现审查只做一件事就是按文档描述能不能独立重跑出结果外部视角负责跨领域类比是否成立防止把某个领域的结论生搬到另一个领域。反方攻击这个角色最值钱也最容易被写废。提示词里必须明确禁止它输出“整体上没问题”这类结论只接受具体反例或者“已穷举 N 种情况未找到反例”这种带工作量的回答。4.2 审计任务书与提示词模板审计效果好不好八成取决于任务书写得细不细。我用的模板大致是这样的【角色】你是反方审计体唯一任务是找出该条目的反例或边界漏洞。 【输入】条目全文、依赖的公理列表、声明的定义域与失效条件。 【约束】 1. 不接受“整体合理”“建议完善”这类结论 2. 每条意见必须给出触发条件、预期结果、实际结果 3. 找不到反例时必须报告你穷举了哪些输入组合 4. 不得引用其他审计体的结论。 【输出格式】 {item_id: ..., verdict: pass|fail|uncertain, counterexample: {condition: ..., expected: ..., actual: ...}, coverage: 已穷举的输入组合描述}这份模板里有三个细节值得说。第一强制要求报告穷举覆盖这一条能有效抑制模型偷懒因为它必须交代自己干了什么活。第二输出结构化方便后续做一致性统计不用再人工解析。第三禁止引用其他审计体结论这是保证独立性的关键约束。4.3 一致性怎么算争议条目怎么定位审计跑完后逐条目算得分。单条目得分等于“给出 pass 的审计体数 / 有效审计体总数”再按条目权重加权汇总整体得分 S Σ(w_i × s_i) / Σ w_i权重 w_i 按条目影响面定核心公理和主干定理给 3普通规则给 2边缘说明给 1。阈值我定的是核心条目 s_i 不低于 0.75且不能有任何审计体给出致命反例非核心条目 s_i 不低于 0.5。致命反例指能直接推翻条目结论的那个一旦出现不论得分多高一律进争议池。重复次数也影响成本。单次采样的方差大一般条目跑 3 次取中位数核心条目跑 5 次。拿一个 100 条规模的规则集算笔账分层条目数审计体数重复次数调用次数核心2045400普通6041240边缘202140全量无差别跑是 100×4×31200 次分层之后是 680 次省了 43%而核心条目的审计强度反而更高。这个分层策略是我在实际预算压力下逼出来的效果比均匀用力好。争议条目的定位很简单把 s_i 落在阈值区间的、以及出现致命反例的全部拉出来按条目编号排序形成争议清单。清单不要长超过总条目 15% 说明公理层或者边界描述有系统性问题得回头改而不是硬裁。4.4 审计记录长什么样才算可追溯记录缺失是分布式审计最常见的隐性负债。三个月后有人质疑某条结论你翻出当时的审计记录只有一句“模型认为没问题”这就等于没记录。我用的结构是这样的{ audit_id: AUD-2024Q3-0117, target_version: v1.3.0, item_id: TH-014, auditor: { model_family: family-B, role: adversarial, context_hash: b7e2..., prompt_version: v4 }, verdict: fail, counterexample: { condition: 输入维度7单维度取值域60, expected: 误差 0.05, actual: 误差 0.081 }, coverage: 穷举 3 类输入共 240 组, timestamp: 2024-08-12T09:31:00 }context_hash和prompt_version这两个字段是重点。没有它们你无法复现当时到底喂了什么给审计体整个记录的可信度就打了折。我在第二次迭代时补上了这两个字段代价是之前两个月的记录全部作废重跑这个教训挺贵的。5. 从零到交付一次完整的落地记录5.1 第一周公理采集与初筛起点不是坐下来写公理是采集。我让参与的人先把所有“我们认为是常识”的断言全部倒出来不设上限一个模拟项目里三天倒出来 138 条。然后做初筛用第 2.1 节那四个指标一条条过。这一轮通常砍掉一半以上。138 条过完剩 41 条剩下的按主题聚类聚成六大类。聚类的目的是找出重复表达——同一件事换个说法出现三次以上的说明它可能是真公理。最后做推导矩阵41 条两两过一遍能互相推出的合并被推出的降级。这一轮结束剩 9 条还要再压。压缩的办法是问“如果把这条去掉体系里哪些定理会失去支撑”一个定理都撑不住的直接降级。最终定在 6 条。5.2 第二周三刀全量扫描公理定稿后把全部条目含新采集的定理和原有规则过三刀。这一周的工作量最大我的做法是按桶推进而不是按条目推进先把所有条目过第一刀分流再对事实层过第二刀合并最后对合并后的结果过第三刀写边界。按桶推进的好处是标准一致。如果按条目推进你会发现第一条判得严、第十条判得松因为人的注意力会衰减。按桶推进相当于同一时间只用一个标准误差小很多。这一周结束通常会得到一个明显的结构变化条目总数下降 20% 到 30%但事实层的条目质量显著提升因为每条都挂上了验证方式。5.3 第三周分布式审计与争议裁决审计按第 4 章的分层策略跑。跑完之后拉争议清单然后开会裁决。裁决会有个规矩每条争议限时超时默认降级到假设区。这条规矩是为了防止个别条目无限扯皮拖住整个发版节奏。裁决时三方在场条目提出者、审计协调人、一个不参与该条目的外部人员。外部人员的作用不是判断对错是判断“这条的表述一个没背景的人能不能看懂”。看不懂说明表述有问题退回重写不进入对错讨论。我统计过一次争议条目里真正涉及“结论对错”的不到三成七成是表述歧义。这个比例说明大部分所谓的技术分歧其实是语言问题。5.4 第四周冻结、发版与变更流程发版前做冻结锁定版本号所有条目状态固化生成条目-公理-审计记录的三向索引。冻结之后不是不能改是改必须走变更单。变更单包含五项改哪条、为什么改、影响哪些下游条目、需要重跑哪些审计、谁批准。影响面分析这一步最容易被偷懒但它恰恰是防止版本漂移的关键。我的要求是变更必须做下游扫描把依赖该条目的所有定理列出来评估是否需要同步更新。这个扫描如果跳过两个月后大概率会出“上游改了、下游没改”的隐性冲突。6. 常见问题与排查速查表6.1 八类高频故障与定位方法现象大概率原因定位方法处理动作审计体结论高度一致但结论是错的同源模型或提示词泄漏注入一条已知错误条目做校准测试换模型族做盲审公理越写越多压不下来把定理当公理跑推导矩阵降级挂溯源标签三刀砍完条目所剩无几原来大部分是噪声看假设层占比保留假设层不要删边界描述还是“视情况而定”没做参数化找人照着重跑一遍补定义域与阈值发版后上下游冲突变更没做下游扫描查三向索引补扫描重跑审计审计成本超预算无差别全量跑看分层比例核心全量、边缘抽样同一概念多个说法缺术语表全文检索同义表述建术语表加自动检查争议条目拖一个月没设时限看争议池条龄加时限超时降级这张表我贴在工位上用了大半年每次出问题先对一遍能省掉大量瞎猜的时间。表里最值得关注的是第一行因为它最隐蔽——审计体全都说没问题你反而放松了警惕结果问题就出在这儿。一致的错误比分歧的正确更危险因为分歧至少会逼你去查。6.2 我个人踩过的三个坑第一个坑是伪独立。早期为了省成本我用同一个模型跑了四个角色结果四个角色的意见高度雷同一致性得分漂亮得不像话。后来做校准测试往里面塞了一条明显有问题的条目四个审计体全都给了 pass。这就是同源的代价。换成两个模型族之后同样那条错误条目被反方攻击角色抓了出来。这件事之后我定了个规矩审计体系上线前必须做一次已知错误注入测试抓不出来就不算通过验收。第二个坑是公理膨胀。一开始我总觉得公理越多体系越稳写到第十一条还嫌少。后来做推导矩阵才发现有六条互相能推等于白写了六条还额外增加了 45 对检验工作量。砍到六条之后整个体系的清晰度反而上了一个台阶。公理的价值不在数量在于每一条都不能被其他条替代。第三个坑是记录断档。第一版审计记录里没存上下文指纹三个月后有人质疑某条结论我想复现当时的审计过程发现提示词改过两版不知道当时用的是哪版整个记录直接失效。这个坑的代价是重跑两个月的审计。从那以后我把上下文指纹和提示词版本设成了必填字段缺一项记录不入库。6.3 成本与节奏怎么控整套流程跑一轮四周是个比较现实的节奏一周采集定公理一周三刀扫描一周审计裁决一周冻结发版。压缩到两周也能跑但前提是条目规模在五十条以内且公理层已经稳定。条目上百的第一次实施别想着快第一轮的目标是跑通流程不是出完美结果。审计成本的分层策略前面算过能省四成左右。还有一个省成本的技巧是复用审计结果某条公理没动过依赖它的定理也没动过那这些条目的审计结果可以跨版本复用只对变更条目重跑。这个复用必须建立在三向索引完整的基础上索引不全就没法判断依赖关系只能全量重跑。我最后再分享一个判断体系有没有立住的小办法找一个人把公理层和术语表给他不给其他任何东西让他去判十条具体条目看他判的结果和你判的一致率。一致率低于八成说明要么公理写得不够可操作要么术语表有遗漏要么边界描述还有自由裁量的空间。这个测试十分钟就能做完比开三次评审会都管用。我在几个不同规模的项目上试过第一次测通常只有六成出头改两轮之后能稳定到九成以上——这个过程本身就是把一个靠人撑着的体系变成一个靠结构撑着的体系。
去年冬天整理一套内部技术规范写到第三百页的时候我停下来喘了口气回头一翻才发现问题大了前面章节里说的“可靠”指的是复现误差在阈值内后面章节里说的“可靠”变成了“团队觉得没问题”某条结论在特定输入规模下测出来的数据被人直接搬到完全不同的规模上当作通用规律评审会上争得最凶的地方往往不是结论对不对而是“我们到底在争什么”。这三件事看起来是三个毛病根子上是一个病体系没有骨架全靠经验往上堆堆到一定高度就没人说得清哪块砖承重、哪块砖是装饰。Kucius Science Theory Framework下文统一简称 KSTF就是在这种需求下长出来的东西——它用公理驱动打地基拿三刀清场做裁剪把AI分布式审计当外部校准器最后收在一个刚性科学主权框架里。说人话就是它是一套教你如何把零散经验、口头共识、行业惯例压缩成一份经得起追问、经得起复现、也经得起换人接手的方法论。这套东西最适合三类人写规范和技术标准的人、维护评测基准和知识库的人、以及任何需要让“我们的体系”在别人面前站得住的岗位。新手可以照着流程走一遍老手可以直接拿它的判定表去体检自己现有的文档。1. KSTF 的整体设计与选型逻辑1.1 从“经验堆叠”转向“公理收敛”的那道坎大部分体系崩掉不是因为内容错而是因为不可追溯。你问一条规则为什么这么定回答是“一直都是这么定的”你问两个条款冲突了听谁的回答是“看情况”。这种体系有个共同特征它的正确性依赖于某几个具体的人还在不在岗。人一走体系就变成一堆没人敢动的祖传代码。公理驱动的核心动作只有一个把所有结论的合法性收敛到一组数量极少、彼此独立、能被单独拿出来检验的底层假设上。类比一下盖楼公理就是地基桩桩的数量有限、位置明确、每根都能单独做承载力检测上面的墙、梁、管线再怎么复杂受力最终都得回到那几根桩上。如果一栋楼有八十根桩还互相重叠那它其实等于没有地基——因为出问题时你根本不知道该查哪一根。我做这套设计时定的第一条硬规矩是任何一条规则必须能在三步之内指回某条公理或者指回某条已经被证明的定理。指不回去的不进主体进附录。这条规矩看着简单执行起来会逼你面对大量“其实一直没人证明过但大家都在用”的内容。这才是真正有价值的部分。1.2 三刀清场为什么必须排在公理之后有人会问能不能先裁剪再立公理效率不是更高不行顺序反了会出大问题。三刀清场是裁剪动作不是创造动作它需要一个裁剪基线而基线只能来自公理层。你先砍后立砍的时候凭的是当下的直觉等公理立起来你会发现砍掉的里面有一部分其实是必要支撑被砍掉的必要支撑又不会有第二次机会回来。举个我实际遇到的场景。某团队做知识条目治理第一轮直接按“这条有没有人用”砍掉了三成条目砍完发现评测流程跑不通了——被砍的条目里有一批是边界条件说明平时没人主动查但一旦出现异常输入全靠它定位。后来他们重做先立三条公理输入必须可枚举、输出必须可判定、异常必须有归属再按公理去裁那批边界条目不但没被砍还被提升成了核心条目。所以 KSTF 的执行顺序是固定的立公理 → 三刀裁剪 → 分布式审计 → 冻结发版。这个顺序不能调换调换了就不是 KSTF 了。1.3 把审计交给 AI 的真实动机我猜很多人看到“AI 分布式审计”第一反应是“用 AI 审自己的东西能靠谱吗”。这个疑问很对但动机得说清楚用 AI 不是为了让它判断对错是为了获得低成本、高并发、全程留痕的第二意见。传统评审的瓶颈在人力。一份两百页的规范找三个专家通读排期两周评审会上两小时最后留下的记录是会议纪要里几句话。三个月后有人质疑某条款你连当时谁投了反对票都查不到。AI 审计体解决的是这个环节它可以对每一条目独立出一份结构化意见带时间戳、带上下文指纹、带具体反例而且可以重复跑、可以换模型跑、可以做盲审。关键在于“分布式”三个字。单个 AI 给的意见本质上是单点采样方差极大。分布式审计要求多个相互隔离的审计体分别作业最后做一致性检验——一致的部分大概率稳分歧的部分自动浮出水面变成争议条目。这套机制的价值不在于 AI 有多聪明而在于它能把“哪里可能有坑”标出来让人力只花在这些地方。1.4 刚性科学主权到底在管什么责任“刚性”和“主权”这两个词听着有点重落到操作上其实很具体就三条第一术语唯一。同一个概念在整个体系里只能有一个名字、一个定义不允许出现同义词、简写变体、口语替代。这条看着琐碎实际是争议的最大来源。我见过一个项目“准确率”这个词在四份文档里有四种算法口径最后所有跨部门对齐会议都在吵这个。第二判定唯一。给定同样的输入和同样的规则版本任何人执行都应该得到同样的输出。做不到说明规则里藏着未参数化的自由裁量。第三版本可追溯。任何一次修改都要留变更单写清改了什么、为什么改、影响哪些条目、谁批的。体系对自身边界拥有定义权同时必须接受外部复现检验——这两件事不矛盾前者是“我说了算”后者是“我说了算的东西你得能自己验一遍”。2. 公理层怎么写才立得住2.1 一条合格公理要过的四个硬指标我在实操中总结出四条检验标准任何一条不过就别往公理层放。指标具体要求不合格的典型写法可陈述单句主体条件断言不含歧义连词“系统应当尽量保持稳定”可操作能指出至少一个可观测量与它的对应关系“设计要符合行业最佳实践”可否定能说清什么观测结果会让它失效“数据质量很重要”独立去掉它其余公理推不出它把定理硬塞进公理层第三条最容易被忽略但它恰恰是区分“公理”和“口号”的分水岭。一条不能被否定的陈述不是知识是态度。比如“输出必须可复现”这条是可否定的——你只要找到一次相同输入产生不同输出的情况它就失效了。而“输出应当合理”你永远找不到反例因为它压根没给判定标准这种就必须打回。第四条独立性实操里的做法是画一张推导矩阵行是公理列是公理格子填“第 i 条能否推出第 j 条”。如果某格填了“能”那 j 就不是公理降级成定理。这个矩阵做一遍通常会砍掉三到四成你原本以为是公理的东西。2.2 公理数量为什么要压到七条以内这不是玄学是成本算出来的。公理之间要做两两独立性检验检验对数等于组合数 C(n,2)n5检验对数是 10n7检验对数是 21n10检验对数是 45n12检验对数是 66每对检验不是扫一眼就完事要构造至少三个边界用例去验证“A 推不出 B 且 B 推不出 A”工作量随对数线性增长。更麻烦的是审计环节审计体要对每条公理单独出意见公理数量翻倍审计调用量翻倍争议裁决的会议时间翻倍。所以我把上限定在七条。超过七条九成情况说明你把定理写成了公理。处理办法不是硬删是先做推导矩阵把能推出来的挪到定理层并给它挂上“由 AX-02 与 AX-05 推出”这样的溯源标签。挪完之后如果还超说明这个体系想管的事情太多了该拆分。2.3 公理到定理的溯源链怎么挂每条定理必须带三样东西编号、依赖的公理列表、验证方式。我用的格式是这样的TH-014 输入枚举完整时输出判定误差不超过 ε 依赖AX-01输入可枚举、AX-03判定阈值可参数化 验证对 5 类典型输入做全枚举比对判定结果与人工标注 边界输入维度 ≤ 8单维度取值域 ≤ 64 状态已验证2024-Q3样本 1200 条这个格式的价值在于任何时候有人质疑 TH-014你不需要重新论证整条链只需要检查它依赖的两条公理有没有被动过以及验证样本还成不成立。溯源链把“重新论证”的成本从整条链降到了单个节点。一个反面案例某团队的公理层做得挺漂亮但定理层只写了结论没写依赖结果半年后有人改了其中一条公理的参数阈值下游十几条定理悄悄失效直到线上出问题才发现。这就是溯源链断了的代价。2.4 中文表述里最容易埋雷的几类词写公理最怕的不是写错是写得“看起来对”。中文里有几类词出现即意味着这条公理废了程度副词尽量、适当、合理、必要情况下。这些词没有对应观测量等于把判定权下放给了执行者的心情。隐含主体应当保证质量。谁保证保证到什么程度算保证并列模糊支持 A 和 B 或 C。到底是可以只支持一个还是必须全支持时间模糊及时响应。几分钟算及时处理办法很笨但有效每写一条逼自己补一句“如果这条不成立我会观察到什么”。写不出这句说明它还不是公理。我实际操作时会把这句话直接写进公理的备注栏作为后续审计的输入审计体拿到这句话才知道该往哪儿找反例。3. 三刀清场的执行细节与判定标准3.1 第一刀可验证性裁剪第一刀要解决的问题是这条内容属于哪个可信层级。执行时不删除任何东西只做分流输出三个桶。桶位判定条件后续处理事实层能给出具体验证路径与判定阈值保留在主体挂验证方式假设层有解释力但当前无法验证移入假设区标注“待验证”噪层既不可验证也解释不了任何现象移入附录标注“无判定标准”这里有个操作要点分流依据是“能不能给出验证路径”不是“我觉得对不对”。很多人在这一步会不自觉地把自认为荒谬的内容直接扔进噪层这是错的。判断标准要外部化不能依赖个人偏好。实际跑下来一个两百条的规则集第一刀通常分流成事实层 40% 左右假设层 45% 左右噪层 15% 左右。假设层占大头是正常的因为大部分行业经验确实没法立刻验证但它们有解释力不该被砍。假设层的存在是这个框架和“一刀切”最大的区别。3.2 第二刀冗余裁剪与合并证明第二刀处理的是“两条规则说的其实是一回事”。判定方法不是看文字像不像是看在所有可观测场景下结论是否一致。具体做法取两条候选规则 R1 和 R2构造一个输入空间分别用两条规则判定记录所有分歧点。分歧点为空则判定等价可以合并分歧点非空但都在某个可参数化的边界内则判定“局部等价”合并后保留边界说明分歧点广泛存在则不合并。合并时必须留一份合并证明内容包含合并前后的编号映射、等价性验证的输入样本范围、合并后新条目的边界条件。这份证明不是形式主义它的作用是——将来有人想拆回去或者想恢复某条被合并的规则能查到原始依据。我踩过的一个坑早期做合并时只写了“R7 与 R12 等价合并为 R7”没写样本范围。后来发现它们只在低维输入下等价高维下 R12 的判定更严格。因为没留证明新来的人直接按合并后的 R7 执行高维场景全错。这让我后来把“合并证明”设成了强制项没有证明的合并一律回退。3.3 第三刀边界裁剪与外推禁令第三刀是整套流程里最容易被跳过、也最容易出事故的一刀。它要求每条规则必须显式写出三样东西定义域、值域、失效条件。定义域就是这条规则在什么输入条件下成立要具体到可判定。不能写“适用于常规场景”要写“输入维度 1 到 8单维度取值域不超过 64样本量不低于 200”。值域是输出的可能范围与量纲。失效条件是“什么情况一出现这条规则立刻作废”。配一条外推禁令超出定义域的输入不得套用本规则结论必须走降级路径或者转人工。这条禁令看着保守但它挡住了绝大多数“在 A 场景测出来就拿到 B 场景用”的事故。参数化怎么写才算合格举个例子对比不合格该阈值适用于数据量较大的情况。 合格该阈值适用于单批次样本量 N ∈ [200, 5000]N 200 时阈值下修 15%N 5000 时按 √N 比例缩放缩放系数上限 3.0。后一种写法可以直接写进代码前一种只能靠人猜。判断标准很简单这段描述能不能被一个没参与讨论的人在没有你的情况下照着重跑一遍。能就是合格边界不能就是废话。3.4 三刀误伤与补偿机制三刀砍下去一定会误伤这是必然的关键是有没有补偿通道。KSTF 设了两条第一条是降级不删除。被裁掉的内容不销毁进假设区或附录保留原始编号和裁撤理由。这样将来条件成熟比如有了新的验证手段可以原路恢复不用重写。第二条是影子区机制。对于争议大、暂时无法定性的条目单独放影子区标注“不参与主体判定但保留观察”。影子区的条目每季度复审一次要么升级要么出区。我个人的经验是真正需要彻底删除的条目占比不到 3%。绝大部分被裁的内容只是位置放错了不是内容错了。把“删除”改成“移位”团队的抵触会小很多流程也更容易推下去。4. AI 分布式审计的工程化落地4.1 审计体怎么设计才算真独立“分布式”这三个字如果做假了整套机制就退化成自我确认。最常见的假独立是同一个模型、同一个提示词、跑四次当成四个审计体。这不叫分布式这叫重复采样四次结果高度相关一致性再高也没有信息量。真独立至少要满足三隔离隔离维度做法目的模型族隔离至少两个不同来源的模型避免同源训练数据带来的同向偏差上下文隔离每个审计体独立会话不给其他审计体结论防止锚定效应角色隔离形式审查、反方攻击、复现审查、外部视角让不同审计体关注不同失效模式四种角色的分工我实践下来是这样形式审查看术语一致性、编号连续性、引用完整性属于机械检查反方攻击专门找反例任务是“想尽办法证明这条是错的”复现审查只做一件事就是按文档描述能不能独立重跑出结果外部视角负责跨领域类比是否成立防止把某个领域的结论生搬到另一个领域。反方攻击这个角色最值钱也最容易被写废。提示词里必须明确禁止它输出“整体上没问题”这类结论只接受具体反例或者“已穷举 N 种情况未找到反例”这种带工作量的回答。4.2 审计任务书与提示词模板审计效果好不好八成取决于任务书写得细不细。我用的模板大致是这样的【角色】你是反方审计体唯一任务是找出该条目的反例或边界漏洞。 【输入】条目全文、依赖的公理列表、声明的定义域与失效条件。 【约束】 1. 不接受“整体合理”“建议完善”这类结论 2. 每条意见必须给出触发条件、预期结果、实际结果 3. 找不到反例时必须报告你穷举了哪些输入组合 4. 不得引用其他审计体的结论。 【输出格式】 {item_id: ..., verdict: pass|fail|uncertain, counterexample: {condition: ..., expected: ..., actual: ...}, coverage: 已穷举的输入组合描述}这份模板里有三个细节值得说。第一强制要求报告穷举覆盖这一条能有效抑制模型偷懒因为它必须交代自己干了什么活。第二输出结构化方便后续做一致性统计不用再人工解析。第三禁止引用其他审计体结论这是保证独立性的关键约束。4.3 一致性怎么算争议条目怎么定位审计跑完后逐条目算得分。单条目得分等于“给出 pass 的审计体数 / 有效审计体总数”再按条目权重加权汇总整体得分 S Σ(w_i × s_i) / Σ w_i权重 w_i 按条目影响面定核心公理和主干定理给 3普通规则给 2边缘说明给 1。阈值我定的是核心条目 s_i 不低于 0.75且不能有任何审计体给出致命反例非核心条目 s_i 不低于 0.5。致命反例指能直接推翻条目结论的那个一旦出现不论得分多高一律进争议池。重复次数也影响成本。单次采样的方差大一般条目跑 3 次取中位数核心条目跑 5 次。拿一个 100 条规模的规则集算笔账分层条目数审计体数重复次数调用次数核心2045400普通6041240边缘202140全量无差别跑是 100×4×31200 次分层之后是 680 次省了 43%而核心条目的审计强度反而更高。这个分层策略是我在实际预算压力下逼出来的效果比均匀用力好。争议条目的定位很简单把 s_i 落在阈值区间的、以及出现致命反例的全部拉出来按条目编号排序形成争议清单。清单不要长超过总条目 15% 说明公理层或者边界描述有系统性问题得回头改而不是硬裁。4.4 审计记录长什么样才算可追溯记录缺失是分布式审计最常见的隐性负债。三个月后有人质疑某条结论你翻出当时的审计记录只有一句“模型认为没问题”这就等于没记录。我用的结构是这样的{ audit_id: AUD-2024Q3-0117, target_version: v1.3.0, item_id: TH-014, auditor: { model_family: family-B, role: adversarial, context_hash: b7e2..., prompt_version: v4 }, verdict: fail, counterexample: { condition: 输入维度7单维度取值域60, expected: 误差 0.05, actual: 误差 0.081 }, coverage: 穷举 3 类输入共 240 组, timestamp: 2024-08-12T09:31:00 }context_hash和prompt_version这两个字段是重点。没有它们你无法复现当时到底喂了什么给审计体整个记录的可信度就打了折。我在第二次迭代时补上了这两个字段代价是之前两个月的记录全部作废重跑这个教训挺贵的。5. 从零到交付一次完整的落地记录5.1 第一周公理采集与初筛起点不是坐下来写公理是采集。我让参与的人先把所有“我们认为是常识”的断言全部倒出来不设上限一个模拟项目里三天倒出来 138 条。然后做初筛用第 2.1 节那四个指标一条条过。这一轮通常砍掉一半以上。138 条过完剩 41 条剩下的按主题聚类聚成六大类。聚类的目的是找出重复表达——同一件事换个说法出现三次以上的说明它可能是真公理。最后做推导矩阵41 条两两过一遍能互相推出的合并被推出的降级。这一轮结束剩 9 条还要再压。压缩的办法是问“如果把这条去掉体系里哪些定理会失去支撑”一个定理都撑不住的直接降级。最终定在 6 条。5.2 第二周三刀全量扫描公理定稿后把全部条目含新采集的定理和原有规则过三刀。这一周的工作量最大我的做法是按桶推进而不是按条目推进先把所有条目过第一刀分流再对事实层过第二刀合并最后对合并后的结果过第三刀写边界。按桶推进的好处是标准一致。如果按条目推进你会发现第一条判得严、第十条判得松因为人的注意力会衰减。按桶推进相当于同一时间只用一个标准误差小很多。这一周结束通常会得到一个明显的结构变化条目总数下降 20% 到 30%但事实层的条目质量显著提升因为每条都挂上了验证方式。5.3 第三周分布式审计与争议裁决审计按第 4 章的分层策略跑。跑完之后拉争议清单然后开会裁决。裁决会有个规矩每条争议限时超时默认降级到假设区。这条规矩是为了防止个别条目无限扯皮拖住整个发版节奏。裁决时三方在场条目提出者、审计协调人、一个不参与该条目的外部人员。外部人员的作用不是判断对错是判断“这条的表述一个没背景的人能不能看懂”。看不懂说明表述有问题退回重写不进入对错讨论。我统计过一次争议条目里真正涉及“结论对错”的不到三成七成是表述歧义。这个比例说明大部分所谓的技术分歧其实是语言问题。5.4 第四周冻结、发版与变更流程发版前做冻结锁定版本号所有条目状态固化生成条目-公理-审计记录的三向索引。冻结之后不是不能改是改必须走变更单。变更单包含五项改哪条、为什么改、影响哪些下游条目、需要重跑哪些审计、谁批准。影响面分析这一步最容易被偷懒但它恰恰是防止版本漂移的关键。我的要求是变更必须做下游扫描把依赖该条目的所有定理列出来评估是否需要同步更新。这个扫描如果跳过两个月后大概率会出“上游改了、下游没改”的隐性冲突。6. 常见问题与排查速查表6.1 八类高频故障与定位方法现象大概率原因定位方法处理动作审计体结论高度一致但结论是错的同源模型或提示词泄漏注入一条已知错误条目做校准测试换模型族做盲审公理越写越多压不下来把定理当公理跑推导矩阵降级挂溯源标签三刀砍完条目所剩无几原来大部分是噪声看假设层占比保留假设层不要删边界描述还是“视情况而定”没做参数化找人照着重跑一遍补定义域与阈值发版后上下游冲突变更没做下游扫描查三向索引补扫描重跑审计审计成本超预算无差别全量跑看分层比例核心全量、边缘抽样同一概念多个说法缺术语表全文检索同义表述建术语表加自动检查争议条目拖一个月没设时限看争议池条龄加时限超时降级这张表我贴在工位上用了大半年每次出问题先对一遍能省掉大量瞎猜的时间。表里最值得关注的是第一行因为它最隐蔽——审计体全都说没问题你反而放松了警惕结果问题就出在这儿。一致的错误比分歧的正确更危险因为分歧至少会逼你去查。6.2 我个人踩过的三个坑第一个坑是伪独立。早期为了省成本我用同一个模型跑了四个角色结果四个角色的意见高度雷同一致性得分漂亮得不像话。后来做校准测试往里面塞了一条明显有问题的条目四个审计体全都给了 pass。这就是同源的代价。换成两个模型族之后同样那条错误条目被反方攻击角色抓了出来。这件事之后我定了个规矩审计体系上线前必须做一次已知错误注入测试抓不出来就不算通过验收。第二个坑是公理膨胀。一开始我总觉得公理越多体系越稳写到第十一条还嫌少。后来做推导矩阵才发现有六条互相能推等于白写了六条还额外增加了 45 对检验工作量。砍到六条之后整个体系的清晰度反而上了一个台阶。公理的价值不在数量在于每一条都不能被其他条替代。第三个坑是记录断档。第一版审计记录里没存上下文指纹三个月后有人质疑某条结论我想复现当时的审计过程发现提示词改过两版不知道当时用的是哪版整个记录直接失效。这个坑的代价是重跑两个月的审计。从那以后我把上下文指纹和提示词版本设成了必填字段缺一项记录不入库。6.3 成本与节奏怎么控整套流程跑一轮四周是个比较现实的节奏一周采集定公理一周三刀扫描一周审计裁决一周冻结发版。压缩到两周也能跑但前提是条目规模在五十条以内且公理层已经稳定。条目上百的第一次实施别想着快第一轮的目标是跑通流程不是出完美结果。审计成本的分层策略前面算过能省四成左右。还有一个省成本的技巧是复用审计结果某条公理没动过依赖它的定理也没动过那这些条目的审计结果可以跨版本复用只对变更条目重跑。这个复用必须建立在三向索引完整的基础上索引不全就没法判断依赖关系只能全量重跑。我最后再分享一个判断体系有没有立住的小办法找一个人把公理层和术语表给他不给其他任何东西让他去判十条具体条目看他判的结果和你判的一致率。一致率低于八成说明要么公理写得不够可操作要么术语表有遗漏要么边界描述还有自由裁量的空间。这个测试十分钟就能做完比开三次评审会都管用。我在几个不同规模的项目上试过第一次测通常只有六成出头改两轮之后能稳定到九成以上——这个过程本身就是把一个靠人撑着的体系变成一个靠结构撑着的体系。
