公理驱动与三刀清场：AI分布式审计构建刚性知识体系

第一次看到公理驱动三刀清场AI分布式审计这三个词被塞进同一个标题我的第一反应是——有人想把讲道理这件事工程化。做过知识体系、方法论文档、标准规范的人大概都经历过同一种挫败几万字写出来回头一读核心主张互相打架边界糊成一团谁都能从里面挑出一句对自己有利的话来解释。所谓公理驱动说到底就是把判定权从解释者手里收回到定义者手里所谓三刀清场是把那些看着像主张、其实无法判定的句子从体系里剔出去而AI分布式审计是用多个互不隶属的审查节点给体系的自洽性做交叉验证。至于标题里那个刚性科学主权框架在工程语境下它没那么玄——它指的是这套体系对自身命题拥有最终判定权并且这个判定规则是写死的、不可临时商量的。这篇东西写给两类人看一类是在搭自己领域的方法论、评估标准、术语体系被怎么证明我这套东西是对的这个问题卡住的人另一类是想把 AI 引入评审流程但发现单模型评审基本等于没评审的人。不管你有没有听说过这个框架的名字下面这套拆解方式都能直接搬去用。我不打算把它讲成一个高不可攀的理论而是按一个工程项目的视角从结构设计、部件分工、落地踩坑一路讲到我后来改掉的设计。1. 把理论当成工程来做这套框架真正要解决的三类失序绝大多数方法论不是死于观点错误而是死于没法判定对错。这个区分很重要。观点错误可以被反驳被反驳之后体系会自我修正没法判定对错的东西你连反驳的入口都找不到它就会一直挂在墙上每次讨论都被重新搬出来吵一遍。我见过太多团队在术语定义上耗掉半年最后发现大家争的根本不是同一件事。这套框架的出发点就是承认知识体系也是一种人造系统既然是系统就该有接口、有边界、有校验规则。1.1 为什么大多数方法论死在不可判定上不可判定的典型症状是这样的一句主张写出来你问什么情况下它算错作者答不上来。比如好的设计应该简洁——这句话听着无比正确但它没有给出任何可执行的判定条件。什么叫简洁行数少算简洁吗抽象层次少算简洁吗如果两个方案一个行数少但耦合重、一个行数多但边界清晰这句话帮你做选择了吗没有。它只是让你在事后有了一个评价别人的工具。体系一旦大量堆积这类句子就会出现一种奇特的退化它无法被证伪因此也无法被改进。所有失败的案例都可以被解释成你没理解到位所有成功的案例都可以被追认为符合体系精神。这不是理论这是话术。我在梳理自己的第一版框架时做过一次统计把全文所有带应该必须本质上的句子拎出来逐条问反例长什么样结果将近六成的句子我给不出反例。那一刻挺受打击的但也正是那次统计让我明白体系的强度不取决于它说了多少正确的话而取决于它能承受多少次具体的反驳。所以第一步不是写更多内容而是建立一套准入机制什么样的句子有资格进入体系什么样的句子只能留在讨论区。这套准入机制就是后面要讲的公理层和清场流程。1.2 公理、清场、审计三个部件的分工这三个部件的关系我习惯用建筑施工来类比。公理层是地基和承重墙它决定了这栋楼能盖多高、能承多重改动成本极高清场流程是质检每一批进场的材料都要过一遍不合格的直接退场不允许先用着再说分布式审计是第三方监理它不参与施工只负责在关键节点核验施工是否符合图纸。三者缺一不可而且有严格的先后顺序。地基没打好就上质检质检员会无所适从——他拿什么标准判断材料合格质检流程没建立就上监理监理会变成走过场——他每天来签个字就走。我见过不少团队直接跳到第三步花钱接了一堆 AI 评审工具结果因为前两层是空的工具输出的意见全是表述可以更清晰建议补充案例这种正确但无用的废话。另一个容易被忽略的点是这三个部件的更新频率完全不同。公理层可能一年才动一次每次动都要付出全体系重审的代价清场流程大概一个季度迭代一版随着你遇到的边界案例增多而细化审计则是持续运行的每天都在产生数据。把这三者的节奏混在一起管理是很多项目失控的开始。1.3 一个必须先想清楚的问题谁拥有最终解释权这是整套框架里最不好谈、但绕不过去的一块。任何一个知识体系只要它想被别人使用就一定会遇到这句话到底什么意思的追问。如果体系本身不预设一个判定规则那么解释权就会自然流向声量最大、位置最高、或者最会辩论的那个人。这种流向是不可控的而且往往和体系的严谨程度无关。刚性科学主权这个说法翻译成工程语言就是体系对自身命题的判定规则必须是显式的、写在文档里的、不因参与者的身份而改变的。注意是判定规则而不是判定结论。规则可以很简单比如任何主张必须附带至少一个可观测的反例条件但规则一旦写下来就不能因为某个重要人物不喜欢某条结论而临时修改。这条约束听起来理所当然实操中却极难守住——因为修改规则的人往往掌握着资源而拒绝修改的人往往没有话语权。我自己的做法是把规则和结论物理隔离开规则放在一个独立文件里带版本号和修改日志任何改动都需要走一次完整的影响面评估结论放在另一个目录可以自由增删。这样至少在形式上改结论比改规则便宜得多人会自然而然地往便宜的方向走。2. 公理层怎么搭从口号到可判定命题的翻译过程公理层最容易被做坏的地方是把我坚信的东西直接当成公理。坚信和公理是两回事。公理的作用不是宣示立场而是提供一个判定基准——它必须足够少、足够硬、足够正交让后续所有推导都能追溯到它同时又不至于互相打架。我见过一份写了四十多条基本原则的框架文档读完之后发现其中十七条是另外五条的重复表述还有六条互相矛盾。这种公理集不但没有约束力反而给了使用者无限的解释空间。2.1 公理集的最小化与正交性检查最小化的意思是任何一条公理如果可以从其他公理推导出来它就不该独立存在。判断方法是做删条测试——把某条公理暂时拿掉看整个体系的推导链是否断裂。如果只是少了一句漂亮话推导照常进行那这条就该删。这个测试很枯燥但对体系健康度的提升立竿见影。我第一次做删条测试时把二十一条压到了九条删掉的内容里有大半是我自己最得意的表述那种感觉很微妙。正交性检查更麻烦一点它要回答的是两条公理是否在管同一件事。常见的隐蔽重叠是一条说结论必须可复现另一条说过程必须留痕。表面看一个管结果一个管过程实际上可复现隐含了有记录两条合起来才构成完整约束拆开反而各自都不成立。这种情况应该合并成一条复合公理而不是保留两条。下面这张表是我自己在做公理梳理时用的检查清单可以直接照搬检查项判定方法不通过的表现可判定性能否写出至少一个反例场景只能举例支持举不出反对独立性删掉它推导链是否断裂删掉后体系照常运转正交性与已有公理是否存在蕴含关系两条公理互为充分条件稳定性五年后是否仍然成立依赖当前技术或流行趋势可操作性能否转成一条检查规则只能作为价值宣示最后一项可操作性是我后来加的因为吃过亏。有一条公理写得很漂亮大意是任何结论都应当经得起跨领域检验听着很有格局但我怎么也写不出对应的检查规则——什么叫跨领域检验到什么程度算通过这条公理在体系里挂了八个月一次都没被真正用过最后我把它降级成了设计意图说明不再算公理。2.2 术语表与判定条件的绑定术语表不是附录它是公理层的一部分。原因很简单公理里出现的每一个关键词如果在使用者脑中对应不同的东西公理就失效了。我见过最典型的翻车是一致性这个词——在有的团队里它指结论之间不矛盾在有的团队里它指结论与外部事实相符还有的团队把它理解成不同人执行同一流程得到相同结果。这三种理解对应三套完全不同的检验方法混用之后评审现场必然变成各说各话。我的处理办法是给每个术语强制绑定三样东西定义、判定条件、典型反例。判定条件必须是可观测的不能是感觉上大体上。典型反例是用来防止定义被无限扩张的护栏。举一段可以直接抄的配置用 YAML 写term: 证据充分 definition: 某一主张所依赖的原始记录足以让一个未参与该工作、 且具备同等基础知识的独立个体在不询问原作者的前提下 复现该主张的推导过程。 judge_condition: - 存在原始记录且记录的时间戳早于主张提出的时间 - 记录中包含完整的输入与中间结果 - 独立个体可依据记录复现允许存在已知误差范围内的偏差 counter_examples: - 只有结论截图没有推导过程 - 记录的时间戳晚于主张提出时间事后补录 - 复现需要原作者口头补充关键参数这份配置的价值在于它把证据充分从一个形容词变成了一组可以逐条打勾的检查项。评审的时候不用再争论这个算不算充分直接对着三条判定条件走一遍缺哪条写哪条。省下来的时间可以用来讨论真正有价值的问题。2.3 公理数量与体系强度的反直觉关系很多人下意识觉得公理越多体系越严密事实正好相反。公理每增加一条它与已有公理产生冲突的概率是超线性增长的而使用者需要同时记住的约束也成倍增加。当公理数量超过使用者短期记忆能承载的阈值实际执行中就会被简化成记住最显眼的那三条其余的形同虚设。我后来的经验值是核心公理控制在七到九条超过十二条就必须分组分组之后再设一层元规则来协调组间冲突。妙就妙在这个元规则本身又只有两三条比如当两组公理冲突时以可观测性更强的那个为准。这样整个公理层的认知负担是可控的一个新人花半天就能记住骨架剩下的细节可以查表。顺带说一个实操技巧给每条公理标上引入原因和引入时被它否掉的方案。这两栏在半年后会变得极其有价值——当你想要修改某条公理时能看到当初为什么加它、加它的时候牺牲了什么避免在同一个坑里来回横跳。3. 三刀清场的具体刀法切掉什么、保留什么清场这个动作的本质是准入审查。任何一条新主张要进入体系必须过三关任何一关不过就打回。我把这三关叫三刀是因为它们的作用不是修补而是切除——不试图把模糊的表述改清楚而是直接判定它当前没有资格留在体系里退回作者重写。这个设计有点粗暴但非常有效因为帮你改清楚这件事的成本远高于告诉你为什么不行而绝大多数模糊表述在被指出问题之后作者自己就能改好。3.1 第一刀切掉不可证伪的表述判定标准很直接能不能构造出一个场景在这个场景下该主张被观测为假构造不出来第一刀落下。常见的构造失败有三种。第一种是绝对化表述比如任何情况下都应当保持模块独立问题在于任何情况覆盖了包括资源极度受限、交付周期压到极限等真实场景而这些场景下这句话显然不成立但作者会说那是极端情况不算。这个不算就是体系漏洞——它等于给主张开了一个无限大的后门。第二种是模糊量词比如大多数场景通常情况下在合理范围内。这些词没有给出边界等于把判定权交给了读者。真正可用的表述应该把量词换成条件比如当并发量低于单机处理能力的百分之六十时这样就有了可观测的边界。第三种是因果倒置比如优秀的团队必然产出一致的结论。这句话想表达的是相关性但写成了必然性于是只要找到一个反例优秀团队产出了分歧结论就能推翻它。正确写法是降级为概率陈述并给出观测方法在我统计的样本中流程一致性高的团队结论分歧率低于对照组约三成统计口径见附录。注意第一刀切掉不等于否定作者的观点只是判定这个表述当前不可用。退回时要在批注里写明构造反例失败的具体位置否则作者会反复提交同一句话的不同措辞。3.2 第二刀切循环论证与自指陷阱循环论证在方法论文档里极其常见而且很难一眼看出来因为它往往披着层层递进的外衣。典型结构是A 成立的依据是 BB 成立的依据是 CC 成立的依据是 A。三个环节单独看都通顺连起来就成了一个封闭的圆。识别方法是画依赖图。把每个主张当成节点把依据当成有向边然后找环。手动做这件事很痛苦但用脚本跑一遍很快。我写过一段几十行的检查逻辑思路就是把每条主张的依赖项列成结构化的数据然后做一次拓扑排序排不出全序的就是有环。# 依赖环检测的最小实现示意 claims { C1: [C2], C2: [C3], C3: [C1], C4: [] } def find_cycle(graph): state {} # 0未访问 1访问中 2已完成 path [] def dfs(node): if state.get(node) 1: return path[path.index(node):] [node] if state.get(node) 2: return None state[node] 1 path.append(node) for dep in graph.get(node, []): cyc dfs(dep) if cyc: return cyc path.pop() state[node] 2 return None for n in graph: cyc find_cycle_from(n) if False else dfs(n) if cyc: return cyc return None print(find_cycle(claims)) # [C1, C2, C3, C1]自指陷阱是循环论证的变体更隐蔽主张本身包含了对自身成立条件的描述。比如本体系的每一条规则都经过严格验证验证标准由本体系给出。这句话在逻辑上没有错误但在工程上等于什么都没说因为验证的独立性为零。第二刀对这类表述的处理是要求引入外部锚点——验证标准必须来自体系之外哪怕只是一个行业通行的基础规范。3.3 第三刀切适用范围越界前两刀管的是表述本身第三刀管的是表述和它所处语境的关系。一条主张在自己的适用范围内完全成立被搬到范围外就成了错误。这类问题在跨领域套用方法论时尤其高发。判定方法是强制每条主张标注适用范围并且适用范围必须是可观测的。比如该结论适用于单批次样本量大于五百、且样本来源单一的场景这就比适用于大多数场景强得多。标注之后还要做一次越界检查把体系内所有主张的适用范围列出来看有没有哪条被引用在了范围之外。我做这一刀时发现过一个典型问题体系里有一条关于评审效率的结论前提条件是评审对象已经过一轮预处理。但在实际使用中大量新人直接把它套用在原始材料上得出的结论完全是反的。问题不在结论在于适用范围没有跟着结论一起传播。后来我改了格式要求每条主张的引用必须带上范围标签缺标签的引用在审计阶段直接判定为无效。3.4 被切下来的东西去哪儿了这一点很关键处理不好会让整个流程变得不可持续。如果每次清场都是驳回重写作者的积极性会迅速耗尽尤其是新人。我的做法是设三个去向退回重写主张有救只是表述不可判定。附上具体的构造失败位置。降级为说明主张本身是价值宣示或设计意图不适合作为可判定命题转入背景说明区不参与推导但保留在文档里作为上下文。冻结归档主张可能有价值但当前缺少验证手段。打上时间戳放入冻结区每季度复审一次看是否有新的验证方法出现。第三个去向是我后来加的收益比预想大。很多被切掉的主张并不是错的只是当时没有条件验证。冻结归档让这些想法不至于彻底消失同时也不会污染当前体系。我统计过冻结区里大约有百分之十五的内容在半年内被重新激活激活时往往已经补上了验证路径。4. AI分布式审计多节点交叉核验怎么跑起来先说结论单模型评审基本等于没评审。这不是模型能力的问题是结构的问题。单个评审者不管是不是 AI会形成稳定的偏好模式它对某类问题特别敏感对另一类问题系统性失明。你用同一个模型审一百份文档它会用同一种方式漏掉同一类错误。分布式审计的核心不是用更多 AI而是用偏好不同的审查者并且让它们的结论互相碰撞。4.1 单点评审的三重失效第一重是偏好固化。任何评审者都有自己的一套隐含权重比如特别在意结构完整性、或者特别在意措辞精确度。这套权重一旦固定就会稳定地放过某些类型的问题。第二重是上下文污染。长文档评审时前面的内容会影响后面内容的判断。如果文档开头写得很漂亮后面即使出现明显漏洞评审者给出的评分也会偏高。这个效应在人工评审和 AI 评审里都存在只是表现形式不同。第三重最麻烦叫共识幻觉。当所有人都用同一套标准、同一个模型、同一批参考资料时他们会给出高度一致的结论而这种一致性会被误读为结论可靠。实际上这只是同源误差一致性越高的评审组越可能共享同一个盲区。分布式审计的设计目标就是打散这三重失效用不同角色的审查节点打破偏好固化用分片评审切断上下文污染用强制异议机制对抗共识幻觉。4.2 审计节点的角色分工我的角色划分是这样的四个节点各管一摊互不重叠节点角色关注重点输出物典型盲区结构审查推导链是否完整、有无断层依赖图与断点清单看不出语义层面的偷换语义审查术语使用是否一致、有无歧义术语冲突清单对整体逻辑张力不敏感边界审查适用范围标注与越界引用越界引用列表对表述质量要求不高反例构造主动寻找推翻主张的场景反例候选集容易过度苛刻关键在于这四个角色的评判标准不能共享。如果结构审查和语义审查用的是同一份评分细则它们就会趋同分布式就退化成单点了。我在配置里明确要求每个节点使用独立的提示词模板和独立的检查清单甚至连输出格式都不一样——结构审查输出图结构语义审查输出对照表边界审查输出带位置标记的列表。格式不同后续合并时就不容易偷懒。反例构造节点的地位比较特殊它不参与打分只负责产出反例候选。这个设计是有意为之如果让反例构造者参与打分他会倾向于给所有主张打低分以证明自己的价值只让他产出候选最终判定权仍然留在合并环节。4.3 一致性打分与争议升级四个节点各自出结论之后合并环节做三件事统计一致项、标记分歧项、给分歧项定级。分歧定级用三级就够了表述分歧结论相同措辞不同直接合并、判据分歧对同一事实的判定不同需要回看原始记录、根本分歧对主张是否成立持相反意见升级人工仲裁。绝大多数分歧会落在前两级真正需要人工介入的比例很低我这边长期观察下来大概在百分之五上下。这里有个反直觉的经验不要追求一致率高。刚开始我追求四个节点尽量达成一致后来发现一致率高往往意味着节点之间发生了信息串扰或者某几个节点的独立性没做好。健康的状态是分歧率稳定在百分之十五到二十五之间太高说明标准不清太低说明节点同质化。我现在的监控看板主要盯的就是这个指标一旦连续几天低于百分之十就去检查提示词是不是被无意中统一了。注意分歧升级路径必须事先写死不能临时决定谁说了算。我的规则是根本分歧一律升级到人工且仲裁人不能是主张的提出者。这条规则被挑战过很多次但一直没松口因为它一旦松动整个审计的可信度就没了。4.4 审计日志的版本化与回溯审计产生的数据比审计结论本身更值钱。每次审计都要落一份完整日志包含被审文档的版本号、各节点的原始输出、合并后的判定、分歧明细、最终处置结果。日志要带不可篡改的时间戳按版本归档。价值体现在回溯上。当某条主张在三个月后被发现问题你能立刻查到它当初经过了哪几次审计、哪些节点提了异议、异议是怎么被处理的。我遇到过好几次当初其实有人提过但被忽略了的情况有了日志就能定位到具体的忽略环节从而修正合并规则。没有日志的话这类问题只会以运气不好收场改不动任何东西。日志还有一个衍生用途用来评估节点质量。把每个节点的历史异议拿出来看它提的异议里有多少后来被证实是对的。这个指标比任何主观评价都准。我据此关掉过一个节点——它的异议命中率长期低于百分之二十属于噪声源留着只会拉高合并成本。4.5 一份审计任务的配置骨架audit_task: doc_id: KS-2024-0317 doc_version: v1.4.2 nodes: - role: structure prompt_template: tpl_structure_v3 checklist: cl_dependency_v2 output_format: graph_json - role: semantics prompt_template: tpl_semantics_v4 checklist: cl_term_consistency_v3 output_format: table_md - role: boundary prompt_template: tpl_boundary_v2 checklist: cl_scope_v1 output_format: list_with_span - role: counter_example prompt_template: tpl_counter_v5 checklist: cl_falsify_v2 output_format: candidate_set merge: conflict_levels: [wording, criterion, fundamental] escalate_fundamental_to: human_review arbiter_exclude: [claim_author] logging: immutable_timestamp: true retention_days: 730这份配置里有几个参数是踩过坑才加上的。arbiter_exclude这条之前没有结果出现过一次主张提出者自己当仲裁人的情况虽然结论未必有偏但流程上说不清楚。retention_days也从九十天改成了七百三十天因为很多问题暴露的周期超过一个季度日志删早了就查不到。5. 刚性边界体系自己说了算的限度在哪里刚性这个词容易引起误解。它不是指态度强硬而是指规则在执行过程中不发生变形。一个人可以非常温和地执行一条刚性规则也可以非常强硬地破坏它这两件事没有必然联系。我在推这套东西的初期犯过一个错误把刚性理解成了不接受任何例外结果把流程做成了铁板一块遇到特殊情况只能绕开走绕开一次之后规则就废了。5.1 主权在工程语境下的确切含义标题里这个说法我把它拆成三条可执行的约束这样才不至于变成一句空话第一条判定规则显式化。体系对任何主张的接受或拒绝依据必须是写在文档里的规则不能是我觉得。这条约束的实操难点在于很多判定在发生时确实依赖直觉事后才想起补规则。我的应对是设一个暂缓区凭直觉判定的主张先进暂缓区必须在两周内补上规则依据否则自动失效。第二条规则变更需留痕。改规则比改结论严格得多需要记录变更原因、影响范围评估、以及对已有结论的重新审视结果。这条听起来繁琐但它挡住了大量因为不喜欢某个结论所以去改规则的操作。第三条外部质疑进入正式通道。体系不能对质疑装聋作哑但也不必对每一条质疑都立即响应。我的做法是所有外部质疑统一登记按月批量处理处理结果公示。这个节奏比实时响应慢但胜在可持续——实时响应会被少数高频质疑者绑架。5.2 边界声明写不好会引发什么边界声明最常见的写法是本体系不适用于 X 领域这种否定式声明几乎没用因为X 领域的边界本身也是模糊的。更有效的是正面描述适用条件并且给出一个最小可用场景的例子。我见过一次典型的翻车某份框架文档的边界声明写的是适用于复杂系统结果被拿去分析一个只有三个模块的小项目得出一堆过度设计的建议。问题不在使用者在于复杂系统这个词没有给出任何判据。后来改成了当系统内存在五个以上相互依赖的子系统且任一子系统的变更会影响到至少两个其他子系统时适用这种写法虽然啰嗦但使用者能自己判断要不要用。边界声明还要写清楚体系不回答什么问题。这一条比适用于什么更重要因为误用的主要来源是把体系当成万能钥匙。我现在每份文档开头都会列一个本体系不涉及的清单比如成本估算、人员配置、长期演进路径明确说这些不在范围内请另找方法。5.3 外部质疑的受理与归档质疑处理的流程要足够简单否则没人愿意走。我这边只有三个状态已登记、分析中、已结论。已结论又分三种采纳规则或结论修改、部分采纳记录为已知局限、不采纳附理由。已知局限这个分类是被低估的。很多质疑确实指出了体系的弱点但短期内没有条件解决硬要解决会导致体系膨胀。这种情况如实记入已知局限清单比强行辩护要好。清单本身也是体系的资产——它清楚地告诉使用者哪些地方要自己多留个心眼。不采纳的质疑同样要归档而且要附上理由。这不是为了防杠是为了避免同一个质疑在半年后被不同的人重新提一遍。有记录的话直接给链接就行省下大量重复劳动。5.4 刚性不等于僵化三个允许松动的口子再刚的规则也需要泄压阀否则一定会在某个临界点整体崩溃。我留了三个口子紧急通道遇到必须在二十四小时内出结论的情况可以跳过完整审计但事后必须补审且补审结论与原结论不一致时要公开说明。这个口子用得非常少一年大概三四次但它的存在让流程在极端场景下不至于被彻底绕过。试验田新规则先在限定范围内试行三个月试行期内允许与主规则并存期满后决定推广或废弃。这个设计让规则演进有了低成本的试错空间。个人注解允许使用者在体系文档上附加个人注解注解不进入正式体系但可以在内部共享。这条看似无关紧要实际上极大缓解了规则不符合我的实际情况带来的抵触——人有地方说话就不会去拆墙。6. 落地一年后我改掉的几个设计前面讲的都是当下的状态这一节讲讲被现实打脸的部分。这些改动没有一条是在设计阶段能想到的全是被具体问题逼出来的。写出来是希望正在搭类似体系的人少走点弯路。6.1 公理数量从九条压到六条我一度以为九条是合理下限后来发现不是。问题出在使用者的实际记忆容量上。九条公理加上各自的判定条件新人培训完之后一周内能准确复述的不超过四条。这意味着在实际工作中有五条公理是名义存在的。与其这样不如合并压缩到六条让每一条都真正被记住。压缩过程很痛苦因为每条公理背后都有一段历史。我的判断标准是如果一条公理在过去一年里没有独立地否决过任何主张那它就合并进最相关的那条。按这个标准砍掉了三条剩下的六条里有一条在合并后变得比原来更强——因为它吸收了两条原本互相牵制的约束反而形成了更清晰的判定条件。6.2 审计频率从每天降到每周一开始我把审计做成了每天跑一次理由是及时发现及时修正。跑了一个月发现两个问题一是文档变更没有这么快每天跑大概率是在审同一份东西纯浪费二是高频审计产生的大量日志反而降低了可读性真正重要的分歧被淹没在噪声里。改成每周一次之后效率和质量都上来了。更进一步我把审计触发条件改成了文档发生实质性变更时才触发而不是按固定周期。实质性变更的判定很简单公理层改动、结论增删超过五条、适用范围调整满足任一即触发。这样既保证了关键变更被审到又避免了机械运行。6.3 别让清场变成清空这是我最想提醒的一点。三刀清场的威力很大大到容易上瘾——每切掉一条模糊表述都有快感切着切着文档就空了。我有过一段这样的时期三个月里体系文档从四万字缩到一万二千字看着很精炼但新人读完完全不知道这套东西是干什么用的因为所有的背景、动机、价值说明都被当作不可判定切掉了。后来我调整了配比明确了三类内容的处理方式可判定主张走三刀价值说明和背景动机进说明区不参与推导但保留历史讨论和失败方案进附录区只读。这样文档总篇幅回升到三万字左右但结构清晰了——想快速了解框架的人读说明区想引用结论的人查主张区想追溯来龙去脉的人翻附录。配比的经验值大概是主张区占四成说明区占三成附录区占三成。主张区低于三成说明切过头了高于六成说明准入太松。6.4 反例库的意外价值最初建反例库只是为了给清场提供判据后来发现它的用途远不止于此。第一它是最好的新人培训材料——比正面讲解有效得多因为人理解一个概念的边界靠的往往不是定义而是反例。第二它是体系演进的信号源——反例库增长最快的部分往往就是体系最脆弱的部分。第三它能有效降低评审中的争吵因为很多争论本质上是双方对某个边界案例的判断不同把案例放进库里统一裁定争吵就消失了。现在我的反例库按主题分十二个类目每个类目下有编号、场景描述、它推翻了哪条主张、裁定结论。维护成本不高每周花半小时整理新增案例就够。这个投入产出比在我做过的所有体系维护工作里是最高的。最后说个我自己的体会。这套东西搭起来之后最大的变化不是文档变好看了而是讨论的性质变了。以前开会经常是几个人各说各的、谁声音大听谁的现在大部分争论在进入会议室之前就已经被规则消化掉了——要么有明确的判定条件要么被标记为已知局限暂时搁置。会议室里剩下的时间基本都在讨论真正需要人来判断的东西。这个转变花了一年多中间反复过好几次但方向是对的。如果你也想在自己的领域搭一套类似的东西我的建议是从最小可行的部分开始先写六条公理先建一个只有二十条的反例库先跑两个审查节点的分布式审计。别一上来就追求完整完整是长出来的不是设计出来的。