做研究评审和方案把关这些年见过太多“看起来很美”的东西栽在同一个地方结论先行前提后补。一份方案读完逻辑通顺、数据漂亮、引用齐全可你追问三句——你这个词到底指什么、这一步凭什么推得出来、这条证据是谁在什么条件下拿到的——对方就开始绕。绕到最后往往抛出一句“这是行业共识”或者“大家都这么做”。这种事出一次是偶然出十次就是结构性问题评审流程里根本没有给“前提”留位置所有火力都集中在“结论好不好看”上。我被这类问题折磨了很长一段时间后来索性动手搭了一套自己的东西内部代号就叫 KSTF全称是 Kucius Science Theory Framework中文习惯叫某公理驱动型科学理论框架。它干的事说白了就三件用一组公理把“不能再问的前提”钉死用三刀清场把概念、逻辑、证据里的水分榨干用AI 分布式审计把“一个人拍板”换成“多角色独立打分再聚合”。标题里那个“刚性”和“主权”我不打算做玄学解读落到操作层面就两句话规则不可临时协商以及一个体系必须对自己用的每个词、每条证据有自主裁定能力而不是伸手向外借权威。这篇东西适合三类人看做研究方法论和质量体系的、做知识工程和技术文档治理的、以及正在用大模型做辅助评审与事实核查的。哪怕你只是偶尔要给别人把关一份材料里面那三刀的执行顺序也够用。下面我按设计思路、公理层、清场层、审计层、踩坑记录的顺序讲能抄的地方我都给出结构、参数和代码。1. 体系整体设计与选型思路1.1 为什么选“公理驱动”而不是“结论驱动”绝大多数评审流程是结论驱动的先看对方要证明什么再看支撑它的材料够不够厚。这个路径有个致命缺陷——它默认“材料多 可信度高”。但材料是可以堆的一个人写三千字论证一个错误前提读起来比三百字说清一件对事更有分量。评审者一旦进入“找漏洞”的模式注意力会被最显眼的表述问题吸走反而放过最深的那层前提。公理驱动的思路反过来先不管你想证明什么先把你依赖的、不再往下追问的前提列出来逐条过筛确认它们站得住再往下谈结论。这跟盖楼先验地基是一个道理只不过大部分人验地基的方式是“看着挺结实”。我这套框架强制要求把地基画成图纸每条公理单独成条、单独编号、单独给出适用范围和失效条件。这个选择带来的直接好处是争议位置前移。以前吵架吵在结论谁也说服不了谁因为双方前提就不一样现在吵架吵在公理而公理数量有限、写得很短吵起来成本低得多。更实际的一点是当公理集明确之后很多看似水火不容的观点会突然发现“其实我们只是在第三条公理上不同”讨论立刻从情绪化变成可定位的分歧点。代价也要说清楚前期成本高。写十条公理可能比直接写结论多花三倍时间而且写公理这个过程非常反人性因为它逼你承认“我确实没法证明这个我只是选择相信它”。我在某实验室做内部分享时A 同学的第一反应是“这不就是把我心虚的地方公开处刑吗”。确实是。但不公开处刑这些心虚的地方就会在半年后以另一种方式找上门。1.2 三层结构公理层、清场层、审计层整个框架是三层漏斗上一层不过下一层就不准入。这个“不准入”是刚性的也是标题里“刚性”二字唯一的实际含义不是态度强硬是流程上不允许跳过。层级主要职责输入输出不通过的处置公理层锁定不可再问的前提原始主张与依赖假设编号公理集与失效条件退回补写禁止进入下一层清场层剔除模糊概念、断链推理、无源证据公理集 论证正文清场报告与修订稿标记未过刀位置限制发布范围审计层多角色独立复核与投票清场后的完整材料审计结论与分歧清单分歧未收敛则挂起不允许单方裁定三层之间靠一份结构化的“移交单”连接移交单里必须写明本轮公理版本号、三刀各自的通过状态、未解决的分歧条目编号。我坚持要这个移交单是因为吃过亏——早期版本里三层是口头衔接的结果清场层改了两条公理审计层还在拿旧版本评审最后结论和前提对不上返工两周。这里有个容易被忽略的设计细节清场层是有权驳回公理层的。如果第一刀发现某条公理本身用词含混公理层必须回去重写不能以“公理就是不能改”为理由硬顶。我刚做的时候把公理层放在最高位结果出现过一条公理里塞了三个不同含义的词下面所有论证都建在这团浆糊上。后来加了这条反向通道整个体系的返工率反而下降了。1.3 和几类常见方案的横向对比我不认为这套东西是唯一解所以把它和几种常见做法摆在一起对比方便你判断要不要抄。方案类型前提处理评审主体主要短板适用场景传统同行评审依赖评审人经验前提多隐含2 到 3 位专家方差极大隐性前提无人追成熟领域的小幅增量工作清单式检查表不处理前提只查条目完备性一人或多人按表打勾打勾能力强不等于判断力强合规性、格式性审查纯大模型单轮评审完全不显式处理单个模型单次生成容易被表述风格带偏一致性差初稿快速自查辩论式多智能体部分显式靠对抗暴露攻守双方智能体容易演变成话术对抗跑题争议大的开放性命题本框架 KSTF公理集显式编号并版本化多角色分布式审计前期成本高需要维护公理库需要长期复用、结论影响面大的工作看表能看出来KSTF 真正独特的地方不在“多智能体”也不在“公理”而在把两件事串成了一条有准入闸门的流水线。市面上很多方案是片段式的有公理但没有清场有清场但没有独立审计有审计但没有版本衔接。片段能解决局部问题但接不起来就会出现“新流程套旧习惯”最后还是回到拍脑袋。2. 公理层把“不可再问的前提”写清楚2.1 四条准入标准可检验、独立、最小、可反驳公理不是口号写得太随意会让整层失效。我给每条公理设了四条硬性门槛缺一条就打回。第一是可检验。这条公理必须能对应到某种可观察的操作或判断上。比如“数据采集过程对环境变化敏感”这种写法就不合格因为它无法检验改成“在温度波动超过正负两度的环境中采集的数据需单独标注批次”就合格了因为你能拿它去对照实际记录。第二是独立。两条公理不能互相推导出来。我见过有人在公理集里同时写了“所有样本必须可追溯”和“样本记录必须包含采集者信息”第二条其实是第一条的下位展开放在公理层是冗余应该下沉到规则层。冗余的公理会让后续清场时反复引用同一条看起来证据充分实际上是同源信息重复计数。第三是最小。能合并的合并能删的删。公理集超过十五六条之后人的注意力就无法维持了评审时基本是扫一眼过。我一般控制在八到十二条超过就说明有些东西本该是推论却被提到了公理层。第四是可反驳。这条最容易被跳过。每条公理都要写清楚“如果出现什么情况这条公理就该被推翻或收窄”。写不出失效条件的公理本质上是一条信仰声明它会让整个体系失去自我修正能力。我在维护公理库时有个习惯失效条件写得越具体的公理后续被修订的次数越少因为边界清楚不容易被误用。注意不要把“业界普遍接受”当成可检验。普遍接受是社会学事实不是逻辑前提。它可以作为选这条公理的理由但不能替代检验方式。2.2 公理的写法模板与两个正反例模板我用的是五段式每段一句话写完就是一条完整公理。这套模板是从技术需求文档的写法里挪过来的改了三版才稳定。编号AX-03 陈述单一来源的证据在跨批次比较中其可信度按批次数量衰减。 适用范围涉及两个及以上批次的横向对比场景。 检验方式检查对比材料是否标注各批次的采集条件差异。 失效条件若各批次采集条件经核验完全一致本条不适用。反面例子长这样我早期写的一条现在看简直灾难编号AX-07 陈述高质量的数据才能支撑可靠的结论。问题一目了然什么叫高质量什么叫可靠检验方式呢失效条件呢这条公理看起来无懈可击实际上什么都没约束住因为它允许任何人把任何东西解释成“高质量”。更糟的是它会让评审者产生一种“我们已经确立了质量原则”的错觉从而跳过真正的检查。正面例子应该长成这样编号AX-07 陈述某条结论所依赖的数据若其采集口径在论证中未明确说明则该结论只允许在原始场景内使用不得外推。 适用范围所有含外推性表述的结论。 检验方式逐条检查结论段是否含外推词并回溯其数据口径说明位置。 失效条件论证中已单独设立口径章节且经第二方复核。对比一下就明白差别在哪反面例子是态度正面例子是开关。态度不可执行开关可以。2.3 公理集的版本化与自动校验公理集一旦超过十条靠人脑记版本必然出事。我把它存成结构化文件每条公理一个条目带版本号、生效日期、变更记录。下面是我现在用的简化结构YAML 写起来比 JSON 顺手注释也好加。axioms: - id: AX-03 version: 2 statement: 单一来源的证据在跨批次比较中其可信度按批次数量衰减。 scope: 跨批次横向对比 check: 检查对比材料是否标注各批次采集条件差异 invalidate: 各批次采集条件经核验完全一致时不适用 changed_at: 第 2 轮修订 supersedes: 1 - id: AX-07 version: 1 statement: 数据采集口径未明确说明时结论不得外推。 scope: 含外推表述的结论 check: 结论段外推词回溯口径说明 invalidate: 已设独立口径章节且经第二方复核 changed_at: 初版有了结构化文件就能做自动校验。我写了个小脚本每次提交材料前跑一遍主要查三件事必填字段是否齐全、编号是否重复、被引用但已废弃的版本有没有残留。这脚本不到五十行但拦下过好几次“引用了旧版公理却不自知”的事故。import yaml, sys REQUIRED [id, version, statement, scope, check, invalidate] def load(path): with open(path, encodingutf-8) as f: return yaml.safe_load(f)[axioms] def validate(axioms): errors, seen [], {} for a in axioms: for k in REQUIRED: if not a.get(k): errors.append(f{a.get(id,?)} 缺字段 {k}) aid a.get(id) if aid in seen: errors.append(f编号重复{aid}) seen[aid] a.get(version) return errors if __name__ __main__: errs validate(load(sys.argv[1])) print(\n.join(errs) if errs else 公理集校验通过) sys.exit(1 if errs else 0)这段代码的价值不在技术含量在于把“记得检查”变成“不检查就过不去”。人是会偷懒的流程必须比人更固执。我后来还加了一条如果某条公理的changed_at显示是最近一轮改的脚本会额外打印提醒因为刚改过的公理最容易被下游材料引用错版本。3. 三刀清场概念刀、逻辑刀、证据刀“三刀清场”这个名字有点江湖气但它对应的是三个非常具体的动作顺序不能换。换顺序的后果我吃过先砍证据再砍概念会发现砍掉的证据里有几条其实是因为概念没定义清楚才显得不相关白砍一遍。3.1 第一刀 概念刀把每个词削到只剩一个意思概念刀只干一件事让材料里每一个承担论证功能的词只有一个可操作的含义。注意限定语——“承担论证功能的词”不是所有词。你不需要给“的”“了”下定义那是自找麻烦。具体做法是三步。第一步扫出所有抽象名词和评价性形容词列成清单。第二步对每个词问一句换一个人读会不会理解成另一个意思如果会就必须给操作化定义。第三步检查同一个词在全文中是否始终同义一旦发现中途变义要么拆成两个词要么统一。最典型的翻车词是“显著”“有效”“稳定”“合理”这一类。某团队给我看的一份材料里“效果显著”出现了十四次我逐条追问得到的答案分别是比上一版好、比竞品好、通过了内部测试、用户反馈不错、看上去不错。五种含义混在一个词里这时候任何结论都不可信因为“显著”已经变成了一个情绪词。操作化定义怎么写我给的标准是给判定条件不给形容词。比如“响应及时”不合格“从请求发出到返回结果的间隔不超过两秒”才合格。再比如“覆盖全面”不合格“覆盖了清单中列出的全部十二类场景每类至少两个实例”才合格。实操心得概念刀阶段最有效的动作不是自己改而是让别人复述。我通常请一位没读过这份材料的人只看定义部分然后口头复述他理解的意思。复述偏了说明定义没写到位比我反复推敲快得多。这一步还有一个副产品很多争论会自动消失。因为争论双方发现彼此用的其实是同一个词的两个不同含义一旦拆开各说各的都不算错只是适用范围不同。这种“假争论”在实际评审里占比高得吓人我粗略估计能到三成以上。3.2 第二刀 逻辑刀砍断链和隐含前提逻辑刀针对的是推理过程。它要抓两类问题一是链条断了还硬接二是藏了没说的前提。断链的典型形态是跳步。材料里写“因为 A所以 C”你问 B 在哪对方说“这不明摆着吗”。明摆着的东西恰恰最该写下来因为不同人眼里的“明摆着”不一样。我的做法是强制补全每一处“因为所以”都要能展开成至少两级中间那级如果写不出来说明这步推理是凭感觉的。隐含前提更隐蔽。举个我实际遇到的例子一份材料论证“方案甲优于方案乙”通篇没提成本但结论里用了“整体更优”。这里的隐含前提是“成本不构成关键约束”。这个前提可能成立也可能不成立但它必须被写出来接受检验否则结论的适用范围就是模糊的。我处理这类问题的办法是列出“结论成立所需的全部条件”然后逐条标已论证、已假设、未考虑。第三类必须清零第二类必须显式声明。反例搜索是逻辑刀里性价比最高的动作。不要急着证明自己对先花二十分钟认真找三个能推翻自己的情形。找得到说明结论需要收窄找不到你对结论的信心才是有依据的。我给自己定的规矩是找不到反例不许停至少要尝试三个不同角度——边界值、极端场景、时间跨度拉长。这三个角度几乎每次都能挖出点东西。逻辑刀还有个检查项是循环论证。它的变体比想象中多最隐蔽的一种是“用结论的同义改写作为论据”。识别方法很简单把论据和结论都改写成最朴素的说法如果两句话变成一个意思那就是循环。这招我在审阅一份自我评价材料时用过改完之后发现七条论据里有四条是结论的换皮。3.3 第三刀 证据刀分级、溯源、可复现证据刀砍三样无源结论、弱源强用、不可复现。先做分级。我用的是四级制简单够用。等级定义使用限制E1可复现的原始记录含采集条件可直接支撑核心结论E2有明确来源但复现条件不全支撑辅助结论核心结论需搭配 E1E3二手转述、汇总性描述仅用于背景说明不得支撑结论E4无来源、来源不可查、来源与内容不匹配一律剔除分级之后要查“弱源强用”。这是最常见的证据问题拿 E3 级别的材料去支撑一个 E1 级别的断言。比如用一句“业内普遍认为”去支撑一个定量结论这在形式上完整实质上空心。溯源要查到什么程度我的标准是能回答三个问题这条证据是谁在什么条件下记录的、原始记录还在不在、如果有人质疑我能不能在三十分钟内把原始记录调出来。第三个问题最狠它直接把“我记得好像是这样”全部筛掉了。可复现性这块要区分两种情形。一种是实验型材料要求给出完整参数和步骤别人照着做能得到同量级结果另一种是观察型材料做不到完全复现那就要求给出观察条件和记录方式让别人能判断结论的适用边界。这两种要求不能混用用实验型的标准去卡观察型材料会把合理的材料全毙掉反过来则会让一堆不可靠的东西蒙混过关。注意证据刀不是越多越好。我见过有人为了过刀把能找到的材料全堆上去结果核心证据被淹没评审反而看不出重点。我的做法是每条核心结论只挂两到三条最强证据其余放附录正文里明确写“支撑强度E1 两条”。3.4 三刀的执行顺序与判定口径顺序固定为概念、逻辑、证据理由是下游依赖上游概念不清则逻辑无从判断逻辑不通则证据不知该证明什么。这个顺序在实操中救过我一次——某份材料证据极其扎实但核心概念中途变义如果先看证据我会给出“材料充分”的结论实际上是南辕北辙。判定口径我用三档避免模糊过刀该刀负责的问题全部清零可进入下一刀。带条件过刀存在不影响核心结论的残留问题标注位置后可进入下一刀但发布时必须附带说明。未过刀存在影响核心结论的问题退回修订不得进入下一刀。三档的划分标准要提前定死不能临场商量。我吃过这个亏第一次跑流程时大家对“带条件”的理解不一致有人觉得概念含混算带条件有人觉得必须清零结果同一份材料两个人给出相反判定。后来我把每一档都配了具体例子写进流程文档争议才消掉。跑完三刀会得到一份清场报告格式我固定为刀次、问题条目编号、位置、问题类型、判定、处置建议。这份报告是审计层的输入之一也是后续追溯的依据。别嫌麻烦等到三个月后有人问“当初这条结论为什么允许外推”你翻出报告就能答翻不出来就只能靠回忆。4. AI 分布式审计把单点评审拆成多角色投票4.1 角色分工攻方、守方、裁判、记录员单模型评审最大的问题是立场单一。你让它“找问题”它会找你让它“评估质量”它会给你一段四平八稳的评语看起来专业实际上什么都没说。这是因为单次生成里模型同时在扮演提问者、回答者和评判者三个角色的目标冲突最后妥协成一个和稀泥的输出。分布式审计的核心思路是把这三个角色拆开让它们在不同的上下文里独立工作最后再聚合。我目前用的四角色配置攻方任务只有一个找出材料中最可能被推翻的地方必须给出具体的推翻路径不允许说“建议进一步完善”这种空话。守方任务是针对攻方提出的每一条判断材料自身是否已经提供了回应有就指出位置没有就承认缺口。裁判拿到攻守双方的完整记录逐条判定该条争议是否成立并给出成立强度。记录员不做判断只负责把全过程结构化存档包括每轮的输入版本号、角色、输出摘要。关键在独立性。攻方和守方必须是两次独立调用互相看不到对方的输出。如果让守方看到攻方的结论再回应那就变成了对话对话会趋同——后说话的一方天然倾向于附和或温和反驳这是我在早期版本里观察到的稳定现象。分开跑再聚合双方的观点差异才保得住。裁判这一环也不能省。我试过直接拿攻守双方的结论做多数投票效果很差因为攻方总会提出一些形式上成立但实质上无关紧要的问题投票会把它们当成真实缺陷。裁判的作用就是把这些“形式缺陷”过滤掉只留下影响结论的条目。4.2 审计协议与投票聚合的实现协议本身不复杂难的是把每一步的输入输出卡死不让模型自由发挥。我的做法是给每个角色一份固定模板模板里只留填空位不给开放式空间。import json, random ROLES { attacker: 只输出材料中可被推翻的具体位置与推翻路径每条不超过两句。, defender: 只判断材料是否已回应给定争议输出 已回应/未回应 与位置。, judge: 只判定争议是否成立输出 成立/不成立 与强度 1-3。, } def run_role(role, material, extraNone): prompt f【角色】{role}\n【要求】{ROLES[role]}\n【材料】{material} if extra: prompt f\n【待判定条目】{extra} return call_model(prompt, temperature0.2) def aggregate(judgements, threshold2): # judgements: [{id: D1, valid: True, strength: 3}, ...] hits {} for j in judgements: if j[valid] and j[strength] threshold: hits[j[id]] hits.get(j[id], 0) 1 total len(judgements) return {k: v / total for k, v in hits.items()}聚合时有几个参数值得说。temperature我压到 0.2因为审计要的是稳定复现不是创意。threshold设 2 而不是 1是为了过滤掉强度极弱的争议——强度 1 的条目通常是表述层面的小毛病放进最终报告会稀释重点。轮次上我跑三轮每轮换一批随机种子三轮里同一争议被判定成立的次数达到两轮以上才计入最终清单。为什么不跑更多轮我实测过五轮和七轮边际收益很低因为第三轮之后新增的争议条目基本是同一批问题的不同说法。三轮是个性价比拐点再往上就是浪费调用。聚合结果我不用简单的多数票而是用“成立比例 强度加权”。原因是有些争议虽然只有一轮被判成立但强度是 3这种必须保留反过来三轮都判成立但强度全是 1 的多半是表述问题可以降级处理。4.3 防共谋漂移多样性约束与盲评分布式审计有个反直觉的风险角色越多结论越趋同。原因是模型之间存在系统性偏好比如都倾向于认为“数据量不足”是个合理批评都倾向于放过“表述略显冗长”这种无伤大雅的问题。跑多了你会发现报告里翻来覆去就是那几条跟材料本身关系不大。对抗这个现象我用三招。第一招是提示词差异化不同角色用不同的措辞风格甚至不同的语言组织方式避免它们被同一套模板带进同一个思维惯性。攻方的提示词我写得比较冲要求“假定这份材料有硬伤把它找出来”守方的提示词写得保守要求“只在材料确有明确依据时才判定已回应”。语气差异会带来判断倾向的差异这个效果比改内容更明显。第二招是盲评。裁判在判定时不看这条争议是攻方第几轮提出的也不看守方的回应语气只拿争议原文和材料原文做比对。信息越少判断越干净。第三招是引入异质模型。如果条件允许攻方和裁判用不同来源的模型差异会明显放大。同源模型容易在同一个地方犯同样的错换一个来源错误模式不重叠交叉验证才有意义。这一招的代价是工程上麻烦一些但如果你的结论影响面大值得。注意多样性不是越多越好。我试过四个来源混跑结果聚合时口径对不齐判定标准不一致反而增加了人工复核量。两到三个来源是比较舒服的区间。4.4 审计日志与可追溯性审计层最容易变质的地方是“过程不可查”。跑完之后只留下一份结论谁也不知道某条争议为什么被判成立。这种情况下一旦结论被质疑整个审计过程就等于白做因为你没法证明它是怎么来的。所以记录员这个角色是必需的而且它记录的东西要足够细。我要求日志包含材料版本号与公理版本号、每轮的随机种子、每个角色的原始输出全文、聚合前后的中间结果、最终清单里每条的来源轮次。日志用 JSON Lines 存一行一条方便追加和检索。{round:1,role:attacker,seed:17,material_ver:v3,axiom_ver:2,items:[{id:D1,pos:第4节第2段,claim:该结论外推超出数据口径},{id:D2,pos:第6节表1,claim:样本量不足以支撑分组比较}]} {round:1,role:defender,seed:17,material_ver:v3,results:[{id:D1,status:未回应},{id:D2,status:已回应,pos:附录B}]} {round:1,role:judge,seed:17,material_ver:v3,results:[{id:D1,valid:true,strength:3},{id:D2,valid:false,strength:1}]}日志的另一个价值是复盘。我每隔一段时间会翻旧日志看哪些类型的争议反复出现。翻了十几次之后发现一个规律概念类争议集中在少数几个高频词上证据类争议集中在“样本代表性”这一项。这个发现直接推动我把这两个检查项写进了公理层和第一刀的标准动作里。日志不只是存档它是改进流程的原料。5. 常见问题与排查技巧实录5.1 典型问题速查表跑这套流程一年多问题基本集中在下面几类我整理成表遇到时按图索骥比重新想快。现象可能原因排查动作处置公理集越写越多超过二十条把推论和规则混进了公理层逐条问“这条能否由别的公理推出”能推出的下沉为规则重复的合并三刀跑完材料没怎么变判定口径太松或清场变成了走过场抽查五条判定看是否都有具体位置重设判定档位加入第二人复核审计报告每条都是“建议完善”攻方提示词太温和缺乏具体性约束检查提示词是否要求给出推翻路径换成强制具体的模板禁用模糊措辞多轮审计结论高度重复角色同质化或随机种子没换对比不同轮次的原始输出相似度加多样性约束换模型来源争议条目无法收敛缺少裁判环节或裁判标准不一致看是否有裁判参与的记录补裁判并把判定标准写进模板结论和公理版本对不上移交单缺失或没填版本号核对移交单与公理库版本强制移交单必填纳入自动校验表格里最值得展开的是第二行。“三刀跑完材料没怎么变”是这套流程最危险的信号因为它意味着流程在空转而空转比不跑更糟——它会给人一种“已经严格审查过”的错觉。我判断空转的标准很朴素如果一轮清场下来问题条目少于五条我基本会假定是自己没看进去而不是材料真的干净。5.2 三个踩过的坑坑一公理膨胀。刚搭框架时特别兴奋什么都想立成公理两个月攒了三十多条。结果是没人记得全评审时随手引几条看着相关的公理集形同虚设。后来痛下决心砍到十一条删除的标准是“这条如果不存在会有什么实际判断出错”。答不上来的全删。砍完之后引用率反而上去了因为大家记得住了。坑二清场过度。有一段时间我陷入了“找问题”的快感任何材料经我手都能挑出二十条毛病其中大部分是表述层面的。结果是提交方疲于应付琐碎修改真正重要的问题被淹没在长清单里。后来我给自己加了一条硬约束清场报告里影响核心结论的条目不得超过五条超了就说明我没抓住重点得重新排优先级。这个约束逼着我做取舍质量反而提升。坑三审计同质化。早期我用同一个模型跑攻守双方只改提示词。跑了几十份材料后发现攻方提的问题和守方的回应高度对应像是同一个人在自问自答。后来换成两个不同来源的模型攻方立刻提出了几条之前从没出现过的问题——其中一条直接指出了材料里一处证据与结论不匹配的地方那是人工复核漏掉的。这件事让我彻底放弃了“同源多角色”的省事做法。这三个坑有个共同点都是在流程跑顺之后出现的。流程不顺的时候问题很明显跑顺了之后问题变得隐蔽因为它披着“规范”的外衣。我现在的习惯是每隔一段时间故意质疑一次流程本身这套东西是不是已经变成了形式质疑的过程不舒服但比糊弄过去强。5.3 参数与节奏上的经验值调参这块没有普适最优只有相对稳的区间。下面几个数是我反复试出来的可以当起点。公理数量控制在八到十二条少于八条往往覆盖不住核心前提多于十二条维护成本陡增。三刀的判定档位固定三档不要临时加第四档档位一多就没人记得清边界。审计轮次三轮每轮换种子两轮以上判成立才计入清单。裁判的强度阈值设 2强度 1 的条目降级为建议而不计入缺陷清单。聚合时攻方和裁判最好来自不同模型来源同源的话差异会被系统性抹平。节奏上我建议把清场和审计错开不要同一天跑完。原因是清场之后人对材料已经有了一套理解紧接着做审计会带着这套理解去看独立性打折。隔一天再跑视角切换更彻底我实测隔天跑出的争议条目质量明显高一些。这个细节听起来玄但你试几次就知道差别在哪。最后分享一个我自己一直在用的小动作每份材料审完之后我会在日志末尾加一句“如果只能改一处改哪里”。这句话逼着我做优先级排序而不是把所有问题平铺给提交方。一年下来回看这些句子发现它们指向的位置高度集中——几乎全在前提层。这大概也印证了这套框架最初的那个判断多数问题的根子不在结论在你没写出来的那句话上。
做研究评审和方案把关这些年见过太多“看起来很美”的东西栽在同一个地方结论先行前提后补。一份方案读完逻辑通顺、数据漂亮、引用齐全可你追问三句——你这个词到底指什么、这一步凭什么推得出来、这条证据是谁在什么条件下拿到的——对方就开始绕。绕到最后往往抛出一句“这是行业共识”或者“大家都这么做”。这种事出一次是偶然出十次就是结构性问题评审流程里根本没有给“前提”留位置所有火力都集中在“结论好不好看”上。我被这类问题折磨了很长一段时间后来索性动手搭了一套自己的东西内部代号就叫 KSTF全称是 Kucius Science Theory Framework中文习惯叫某公理驱动型科学理论框架。它干的事说白了就三件用一组公理把“不能再问的前提”钉死用三刀清场把概念、逻辑、证据里的水分榨干用AI 分布式审计把“一个人拍板”换成“多角色独立打分再聚合”。标题里那个“刚性”和“主权”我不打算做玄学解读落到操作层面就两句话规则不可临时协商以及一个体系必须对自己用的每个词、每条证据有自主裁定能力而不是伸手向外借权威。这篇东西适合三类人看做研究方法论和质量体系的、做知识工程和技术文档治理的、以及正在用大模型做辅助评审与事实核查的。哪怕你只是偶尔要给别人把关一份材料里面那三刀的执行顺序也够用。下面我按设计思路、公理层、清场层、审计层、踩坑记录的顺序讲能抄的地方我都给出结构、参数和代码。1. 体系整体设计与选型思路1.1 为什么选“公理驱动”而不是“结论驱动”绝大多数评审流程是结论驱动的先看对方要证明什么再看支撑它的材料够不够厚。这个路径有个致命缺陷——它默认“材料多 可信度高”。但材料是可以堆的一个人写三千字论证一个错误前提读起来比三百字说清一件对事更有分量。评审者一旦进入“找漏洞”的模式注意力会被最显眼的表述问题吸走反而放过最深的那层前提。公理驱动的思路反过来先不管你想证明什么先把你依赖的、不再往下追问的前提列出来逐条过筛确认它们站得住再往下谈结论。这跟盖楼先验地基是一个道理只不过大部分人验地基的方式是“看着挺结实”。我这套框架强制要求把地基画成图纸每条公理单独成条、单独编号、单独给出适用范围和失效条件。这个选择带来的直接好处是争议位置前移。以前吵架吵在结论谁也说服不了谁因为双方前提就不一样现在吵架吵在公理而公理数量有限、写得很短吵起来成本低得多。更实际的一点是当公理集明确之后很多看似水火不容的观点会突然发现“其实我们只是在第三条公理上不同”讨论立刻从情绪化变成可定位的分歧点。代价也要说清楚前期成本高。写十条公理可能比直接写结论多花三倍时间而且写公理这个过程非常反人性因为它逼你承认“我确实没法证明这个我只是选择相信它”。我在某实验室做内部分享时A 同学的第一反应是“这不就是把我心虚的地方公开处刑吗”。确实是。但不公开处刑这些心虚的地方就会在半年后以另一种方式找上门。1.2 三层结构公理层、清场层、审计层整个框架是三层漏斗上一层不过下一层就不准入。这个“不准入”是刚性的也是标题里“刚性”二字唯一的实际含义不是态度强硬是流程上不允许跳过。层级主要职责输入输出不通过的处置公理层锁定不可再问的前提原始主张与依赖假设编号公理集与失效条件退回补写禁止进入下一层清场层剔除模糊概念、断链推理、无源证据公理集 论证正文清场报告与修订稿标记未过刀位置限制发布范围审计层多角色独立复核与投票清场后的完整材料审计结论与分歧清单分歧未收敛则挂起不允许单方裁定三层之间靠一份结构化的“移交单”连接移交单里必须写明本轮公理版本号、三刀各自的通过状态、未解决的分歧条目编号。我坚持要这个移交单是因为吃过亏——早期版本里三层是口头衔接的结果清场层改了两条公理审计层还在拿旧版本评审最后结论和前提对不上返工两周。这里有个容易被忽略的设计细节清场层是有权驳回公理层的。如果第一刀发现某条公理本身用词含混公理层必须回去重写不能以“公理就是不能改”为理由硬顶。我刚做的时候把公理层放在最高位结果出现过一条公理里塞了三个不同含义的词下面所有论证都建在这团浆糊上。后来加了这条反向通道整个体系的返工率反而下降了。1.3 和几类常见方案的横向对比我不认为这套东西是唯一解所以把它和几种常见做法摆在一起对比方便你判断要不要抄。方案类型前提处理评审主体主要短板适用场景传统同行评审依赖评审人经验前提多隐含2 到 3 位专家方差极大隐性前提无人追成熟领域的小幅增量工作清单式检查表不处理前提只查条目完备性一人或多人按表打勾打勾能力强不等于判断力强合规性、格式性审查纯大模型单轮评审完全不显式处理单个模型单次生成容易被表述风格带偏一致性差初稿快速自查辩论式多智能体部分显式靠对抗暴露攻守双方智能体容易演变成话术对抗跑题争议大的开放性命题本框架 KSTF公理集显式编号并版本化多角色分布式审计前期成本高需要维护公理库需要长期复用、结论影响面大的工作看表能看出来KSTF 真正独特的地方不在“多智能体”也不在“公理”而在把两件事串成了一条有准入闸门的流水线。市面上很多方案是片段式的有公理但没有清场有清场但没有独立审计有审计但没有版本衔接。片段能解决局部问题但接不起来就会出现“新流程套旧习惯”最后还是回到拍脑袋。2. 公理层把“不可再问的前提”写清楚2.1 四条准入标准可检验、独立、最小、可反驳公理不是口号写得太随意会让整层失效。我给每条公理设了四条硬性门槛缺一条就打回。第一是可检验。这条公理必须能对应到某种可观察的操作或判断上。比如“数据采集过程对环境变化敏感”这种写法就不合格因为它无法检验改成“在温度波动超过正负两度的环境中采集的数据需单独标注批次”就合格了因为你能拿它去对照实际记录。第二是独立。两条公理不能互相推导出来。我见过有人在公理集里同时写了“所有样本必须可追溯”和“样本记录必须包含采集者信息”第二条其实是第一条的下位展开放在公理层是冗余应该下沉到规则层。冗余的公理会让后续清场时反复引用同一条看起来证据充分实际上是同源信息重复计数。第三是最小。能合并的合并能删的删。公理集超过十五六条之后人的注意力就无法维持了评审时基本是扫一眼过。我一般控制在八到十二条超过就说明有些东西本该是推论却被提到了公理层。第四是可反驳。这条最容易被跳过。每条公理都要写清楚“如果出现什么情况这条公理就该被推翻或收窄”。写不出失效条件的公理本质上是一条信仰声明它会让整个体系失去自我修正能力。我在维护公理库时有个习惯失效条件写得越具体的公理后续被修订的次数越少因为边界清楚不容易被误用。注意不要把“业界普遍接受”当成可检验。普遍接受是社会学事实不是逻辑前提。它可以作为选这条公理的理由但不能替代检验方式。2.2 公理的写法模板与两个正反例模板我用的是五段式每段一句话写完就是一条完整公理。这套模板是从技术需求文档的写法里挪过来的改了三版才稳定。编号AX-03 陈述单一来源的证据在跨批次比较中其可信度按批次数量衰减。 适用范围涉及两个及以上批次的横向对比场景。 检验方式检查对比材料是否标注各批次的采集条件差异。 失效条件若各批次采集条件经核验完全一致本条不适用。反面例子长这样我早期写的一条现在看简直灾难编号AX-07 陈述高质量的数据才能支撑可靠的结论。问题一目了然什么叫高质量什么叫可靠检验方式呢失效条件呢这条公理看起来无懈可击实际上什么都没约束住因为它允许任何人把任何东西解释成“高质量”。更糟的是它会让评审者产生一种“我们已经确立了质量原则”的错觉从而跳过真正的检查。正面例子应该长成这样编号AX-07 陈述某条结论所依赖的数据若其采集口径在论证中未明确说明则该结论只允许在原始场景内使用不得外推。 适用范围所有含外推性表述的结论。 检验方式逐条检查结论段是否含外推词并回溯其数据口径说明位置。 失效条件论证中已单独设立口径章节且经第二方复核。对比一下就明白差别在哪反面例子是态度正面例子是开关。态度不可执行开关可以。2.3 公理集的版本化与自动校验公理集一旦超过十条靠人脑记版本必然出事。我把它存成结构化文件每条公理一个条目带版本号、生效日期、变更记录。下面是我现在用的简化结构YAML 写起来比 JSON 顺手注释也好加。axioms: - id: AX-03 version: 2 statement: 单一来源的证据在跨批次比较中其可信度按批次数量衰减。 scope: 跨批次横向对比 check: 检查对比材料是否标注各批次采集条件差异 invalidate: 各批次采集条件经核验完全一致时不适用 changed_at: 第 2 轮修订 supersedes: 1 - id: AX-07 version: 1 statement: 数据采集口径未明确说明时结论不得外推。 scope: 含外推表述的结论 check: 结论段外推词回溯口径说明 invalidate: 已设独立口径章节且经第二方复核 changed_at: 初版有了结构化文件就能做自动校验。我写了个小脚本每次提交材料前跑一遍主要查三件事必填字段是否齐全、编号是否重复、被引用但已废弃的版本有没有残留。这脚本不到五十行但拦下过好几次“引用了旧版公理却不自知”的事故。import yaml, sys REQUIRED [id, version, statement, scope, check, invalidate] def load(path): with open(path, encodingutf-8) as f: return yaml.safe_load(f)[axioms] def validate(axioms): errors, seen [], {} for a in axioms: for k in REQUIRED: if not a.get(k): errors.append(f{a.get(id,?)} 缺字段 {k}) aid a.get(id) if aid in seen: errors.append(f编号重复{aid}) seen[aid] a.get(version) return errors if __name__ __main__: errs validate(load(sys.argv[1])) print(\n.join(errs) if errs else 公理集校验通过) sys.exit(1 if errs else 0)这段代码的价值不在技术含量在于把“记得检查”变成“不检查就过不去”。人是会偷懒的流程必须比人更固执。我后来还加了一条如果某条公理的changed_at显示是最近一轮改的脚本会额外打印提醒因为刚改过的公理最容易被下游材料引用错版本。3. 三刀清场概念刀、逻辑刀、证据刀“三刀清场”这个名字有点江湖气但它对应的是三个非常具体的动作顺序不能换。换顺序的后果我吃过先砍证据再砍概念会发现砍掉的证据里有几条其实是因为概念没定义清楚才显得不相关白砍一遍。3.1 第一刀 概念刀把每个词削到只剩一个意思概念刀只干一件事让材料里每一个承担论证功能的词只有一个可操作的含义。注意限定语——“承担论证功能的词”不是所有词。你不需要给“的”“了”下定义那是自找麻烦。具体做法是三步。第一步扫出所有抽象名词和评价性形容词列成清单。第二步对每个词问一句换一个人读会不会理解成另一个意思如果会就必须给操作化定义。第三步检查同一个词在全文中是否始终同义一旦发现中途变义要么拆成两个词要么统一。最典型的翻车词是“显著”“有效”“稳定”“合理”这一类。某团队给我看的一份材料里“效果显著”出现了十四次我逐条追问得到的答案分别是比上一版好、比竞品好、通过了内部测试、用户反馈不错、看上去不错。五种含义混在一个词里这时候任何结论都不可信因为“显著”已经变成了一个情绪词。操作化定义怎么写我给的标准是给判定条件不给形容词。比如“响应及时”不合格“从请求发出到返回结果的间隔不超过两秒”才合格。再比如“覆盖全面”不合格“覆盖了清单中列出的全部十二类场景每类至少两个实例”才合格。实操心得概念刀阶段最有效的动作不是自己改而是让别人复述。我通常请一位没读过这份材料的人只看定义部分然后口头复述他理解的意思。复述偏了说明定义没写到位比我反复推敲快得多。这一步还有一个副产品很多争论会自动消失。因为争论双方发现彼此用的其实是同一个词的两个不同含义一旦拆开各说各的都不算错只是适用范围不同。这种“假争论”在实际评审里占比高得吓人我粗略估计能到三成以上。3.2 第二刀 逻辑刀砍断链和隐含前提逻辑刀针对的是推理过程。它要抓两类问题一是链条断了还硬接二是藏了没说的前提。断链的典型形态是跳步。材料里写“因为 A所以 C”你问 B 在哪对方说“这不明摆着吗”。明摆着的东西恰恰最该写下来因为不同人眼里的“明摆着”不一样。我的做法是强制补全每一处“因为所以”都要能展开成至少两级中间那级如果写不出来说明这步推理是凭感觉的。隐含前提更隐蔽。举个我实际遇到的例子一份材料论证“方案甲优于方案乙”通篇没提成本但结论里用了“整体更优”。这里的隐含前提是“成本不构成关键约束”。这个前提可能成立也可能不成立但它必须被写出来接受检验否则结论的适用范围就是模糊的。我处理这类问题的办法是列出“结论成立所需的全部条件”然后逐条标已论证、已假设、未考虑。第三类必须清零第二类必须显式声明。反例搜索是逻辑刀里性价比最高的动作。不要急着证明自己对先花二十分钟认真找三个能推翻自己的情形。找得到说明结论需要收窄找不到你对结论的信心才是有依据的。我给自己定的规矩是找不到反例不许停至少要尝试三个不同角度——边界值、极端场景、时间跨度拉长。这三个角度几乎每次都能挖出点东西。逻辑刀还有个检查项是循环论证。它的变体比想象中多最隐蔽的一种是“用结论的同义改写作为论据”。识别方法很简单把论据和结论都改写成最朴素的说法如果两句话变成一个意思那就是循环。这招我在审阅一份自我评价材料时用过改完之后发现七条论据里有四条是结论的换皮。3.3 第三刀 证据刀分级、溯源、可复现证据刀砍三样无源结论、弱源强用、不可复现。先做分级。我用的是四级制简单够用。等级定义使用限制E1可复现的原始记录含采集条件可直接支撑核心结论E2有明确来源但复现条件不全支撑辅助结论核心结论需搭配 E1E3二手转述、汇总性描述仅用于背景说明不得支撑结论E4无来源、来源不可查、来源与内容不匹配一律剔除分级之后要查“弱源强用”。这是最常见的证据问题拿 E3 级别的材料去支撑一个 E1 级别的断言。比如用一句“业内普遍认为”去支撑一个定量结论这在形式上完整实质上空心。溯源要查到什么程度我的标准是能回答三个问题这条证据是谁在什么条件下记录的、原始记录还在不在、如果有人质疑我能不能在三十分钟内把原始记录调出来。第三个问题最狠它直接把“我记得好像是这样”全部筛掉了。可复现性这块要区分两种情形。一种是实验型材料要求给出完整参数和步骤别人照着做能得到同量级结果另一种是观察型材料做不到完全复现那就要求给出观察条件和记录方式让别人能判断结论的适用边界。这两种要求不能混用用实验型的标准去卡观察型材料会把合理的材料全毙掉反过来则会让一堆不可靠的东西蒙混过关。注意证据刀不是越多越好。我见过有人为了过刀把能找到的材料全堆上去结果核心证据被淹没评审反而看不出重点。我的做法是每条核心结论只挂两到三条最强证据其余放附录正文里明确写“支撑强度E1 两条”。3.4 三刀的执行顺序与判定口径顺序固定为概念、逻辑、证据理由是下游依赖上游概念不清则逻辑无从判断逻辑不通则证据不知该证明什么。这个顺序在实操中救过我一次——某份材料证据极其扎实但核心概念中途变义如果先看证据我会给出“材料充分”的结论实际上是南辕北辙。判定口径我用三档避免模糊过刀该刀负责的问题全部清零可进入下一刀。带条件过刀存在不影响核心结论的残留问题标注位置后可进入下一刀但发布时必须附带说明。未过刀存在影响核心结论的问题退回修订不得进入下一刀。三档的划分标准要提前定死不能临场商量。我吃过这个亏第一次跑流程时大家对“带条件”的理解不一致有人觉得概念含混算带条件有人觉得必须清零结果同一份材料两个人给出相反判定。后来我把每一档都配了具体例子写进流程文档争议才消掉。跑完三刀会得到一份清场报告格式我固定为刀次、问题条目编号、位置、问题类型、判定、处置建议。这份报告是审计层的输入之一也是后续追溯的依据。别嫌麻烦等到三个月后有人问“当初这条结论为什么允许外推”你翻出报告就能答翻不出来就只能靠回忆。4. AI 分布式审计把单点评审拆成多角色投票4.1 角色分工攻方、守方、裁判、记录员单模型评审最大的问题是立场单一。你让它“找问题”它会找你让它“评估质量”它会给你一段四平八稳的评语看起来专业实际上什么都没说。这是因为单次生成里模型同时在扮演提问者、回答者和评判者三个角色的目标冲突最后妥协成一个和稀泥的输出。分布式审计的核心思路是把这三个角色拆开让它们在不同的上下文里独立工作最后再聚合。我目前用的四角色配置攻方任务只有一个找出材料中最可能被推翻的地方必须给出具体的推翻路径不允许说“建议进一步完善”这种空话。守方任务是针对攻方提出的每一条判断材料自身是否已经提供了回应有就指出位置没有就承认缺口。裁判拿到攻守双方的完整记录逐条判定该条争议是否成立并给出成立强度。记录员不做判断只负责把全过程结构化存档包括每轮的输入版本号、角色、输出摘要。关键在独立性。攻方和守方必须是两次独立调用互相看不到对方的输出。如果让守方看到攻方的结论再回应那就变成了对话对话会趋同——后说话的一方天然倾向于附和或温和反驳这是我在早期版本里观察到的稳定现象。分开跑再聚合双方的观点差异才保得住。裁判这一环也不能省。我试过直接拿攻守双方的结论做多数投票效果很差因为攻方总会提出一些形式上成立但实质上无关紧要的问题投票会把它们当成真实缺陷。裁判的作用就是把这些“形式缺陷”过滤掉只留下影响结论的条目。4.2 审计协议与投票聚合的实现协议本身不复杂难的是把每一步的输入输出卡死不让模型自由发挥。我的做法是给每个角色一份固定模板模板里只留填空位不给开放式空间。import json, random ROLES { attacker: 只输出材料中可被推翻的具体位置与推翻路径每条不超过两句。, defender: 只判断材料是否已回应给定争议输出 已回应/未回应 与位置。, judge: 只判定争议是否成立输出 成立/不成立 与强度 1-3。, } def run_role(role, material, extraNone): prompt f【角色】{role}\n【要求】{ROLES[role]}\n【材料】{material} if extra: prompt f\n【待判定条目】{extra} return call_model(prompt, temperature0.2) def aggregate(judgements, threshold2): # judgements: [{id: D1, valid: True, strength: 3}, ...] hits {} for j in judgements: if j[valid] and j[strength] threshold: hits[j[id]] hits.get(j[id], 0) 1 total len(judgements) return {k: v / total for k, v in hits.items()}聚合时有几个参数值得说。temperature我压到 0.2因为审计要的是稳定复现不是创意。threshold设 2 而不是 1是为了过滤掉强度极弱的争议——强度 1 的条目通常是表述层面的小毛病放进最终报告会稀释重点。轮次上我跑三轮每轮换一批随机种子三轮里同一争议被判定成立的次数达到两轮以上才计入最终清单。为什么不跑更多轮我实测过五轮和七轮边际收益很低因为第三轮之后新增的争议条目基本是同一批问题的不同说法。三轮是个性价比拐点再往上就是浪费调用。聚合结果我不用简单的多数票而是用“成立比例 强度加权”。原因是有些争议虽然只有一轮被判成立但强度是 3这种必须保留反过来三轮都判成立但强度全是 1 的多半是表述问题可以降级处理。4.3 防共谋漂移多样性约束与盲评分布式审计有个反直觉的风险角色越多结论越趋同。原因是模型之间存在系统性偏好比如都倾向于认为“数据量不足”是个合理批评都倾向于放过“表述略显冗长”这种无伤大雅的问题。跑多了你会发现报告里翻来覆去就是那几条跟材料本身关系不大。对抗这个现象我用三招。第一招是提示词差异化不同角色用不同的措辞风格甚至不同的语言组织方式避免它们被同一套模板带进同一个思维惯性。攻方的提示词我写得比较冲要求“假定这份材料有硬伤把它找出来”守方的提示词写得保守要求“只在材料确有明确依据时才判定已回应”。语气差异会带来判断倾向的差异这个效果比改内容更明显。第二招是盲评。裁判在判定时不看这条争议是攻方第几轮提出的也不看守方的回应语气只拿争议原文和材料原文做比对。信息越少判断越干净。第三招是引入异质模型。如果条件允许攻方和裁判用不同来源的模型差异会明显放大。同源模型容易在同一个地方犯同样的错换一个来源错误模式不重叠交叉验证才有意义。这一招的代价是工程上麻烦一些但如果你的结论影响面大值得。注意多样性不是越多越好。我试过四个来源混跑结果聚合时口径对不齐判定标准不一致反而增加了人工复核量。两到三个来源是比较舒服的区间。4.4 审计日志与可追溯性审计层最容易变质的地方是“过程不可查”。跑完之后只留下一份结论谁也不知道某条争议为什么被判成立。这种情况下一旦结论被质疑整个审计过程就等于白做因为你没法证明它是怎么来的。所以记录员这个角色是必需的而且它记录的东西要足够细。我要求日志包含材料版本号与公理版本号、每轮的随机种子、每个角色的原始输出全文、聚合前后的中间结果、最终清单里每条的来源轮次。日志用 JSON Lines 存一行一条方便追加和检索。{round:1,role:attacker,seed:17,material_ver:v3,axiom_ver:2,items:[{id:D1,pos:第4节第2段,claim:该结论外推超出数据口径},{id:D2,pos:第6节表1,claim:样本量不足以支撑分组比较}]} {round:1,role:defender,seed:17,material_ver:v3,results:[{id:D1,status:未回应},{id:D2,status:已回应,pos:附录B}]} {round:1,role:judge,seed:17,material_ver:v3,results:[{id:D1,valid:true,strength:3},{id:D2,valid:false,strength:1}]}日志的另一个价值是复盘。我每隔一段时间会翻旧日志看哪些类型的争议反复出现。翻了十几次之后发现一个规律概念类争议集中在少数几个高频词上证据类争议集中在“样本代表性”这一项。这个发现直接推动我把这两个检查项写进了公理层和第一刀的标准动作里。日志不只是存档它是改进流程的原料。5. 常见问题与排查技巧实录5.1 典型问题速查表跑这套流程一年多问题基本集中在下面几类我整理成表遇到时按图索骥比重新想快。现象可能原因排查动作处置公理集越写越多超过二十条把推论和规则混进了公理层逐条问“这条能否由别的公理推出”能推出的下沉为规则重复的合并三刀跑完材料没怎么变判定口径太松或清场变成了走过场抽查五条判定看是否都有具体位置重设判定档位加入第二人复核审计报告每条都是“建议完善”攻方提示词太温和缺乏具体性约束检查提示词是否要求给出推翻路径换成强制具体的模板禁用模糊措辞多轮审计结论高度重复角色同质化或随机种子没换对比不同轮次的原始输出相似度加多样性约束换模型来源争议条目无法收敛缺少裁判环节或裁判标准不一致看是否有裁判参与的记录补裁判并把判定标准写进模板结论和公理版本对不上移交单缺失或没填版本号核对移交单与公理库版本强制移交单必填纳入自动校验表格里最值得展开的是第二行。“三刀跑完材料没怎么变”是这套流程最危险的信号因为它意味着流程在空转而空转比不跑更糟——它会给人一种“已经严格审查过”的错觉。我判断空转的标准很朴素如果一轮清场下来问题条目少于五条我基本会假定是自己没看进去而不是材料真的干净。5.2 三个踩过的坑坑一公理膨胀。刚搭框架时特别兴奋什么都想立成公理两个月攒了三十多条。结果是没人记得全评审时随手引几条看着相关的公理集形同虚设。后来痛下决心砍到十一条删除的标准是“这条如果不存在会有什么实际判断出错”。答不上来的全删。砍完之后引用率反而上去了因为大家记得住了。坑二清场过度。有一段时间我陷入了“找问题”的快感任何材料经我手都能挑出二十条毛病其中大部分是表述层面的。结果是提交方疲于应付琐碎修改真正重要的问题被淹没在长清单里。后来我给自己加了一条硬约束清场报告里影响核心结论的条目不得超过五条超了就说明我没抓住重点得重新排优先级。这个约束逼着我做取舍质量反而提升。坑三审计同质化。早期我用同一个模型跑攻守双方只改提示词。跑了几十份材料后发现攻方提的问题和守方的回应高度对应像是同一个人在自问自答。后来换成两个不同来源的模型攻方立刻提出了几条之前从没出现过的问题——其中一条直接指出了材料里一处证据与结论不匹配的地方那是人工复核漏掉的。这件事让我彻底放弃了“同源多角色”的省事做法。这三个坑有个共同点都是在流程跑顺之后出现的。流程不顺的时候问题很明显跑顺了之后问题变得隐蔽因为它披着“规范”的外衣。我现在的习惯是每隔一段时间故意质疑一次流程本身这套东西是不是已经变成了形式质疑的过程不舒服但比糊弄过去强。5.3 参数与节奏上的经验值调参这块没有普适最优只有相对稳的区间。下面几个数是我反复试出来的可以当起点。公理数量控制在八到十二条少于八条往往覆盖不住核心前提多于十二条维护成本陡增。三刀的判定档位固定三档不要临时加第四档档位一多就没人记得清边界。审计轮次三轮每轮换种子两轮以上判成立才计入清单。裁判的强度阈值设 2强度 1 的条目降级为建议而不计入缺陷清单。聚合时攻方和裁判最好来自不同模型来源同源的话差异会被系统性抹平。节奏上我建议把清场和审计错开不要同一天跑完。原因是清场之后人对材料已经有了一套理解紧接着做审计会带着这套理解去看独立性打折。隔一天再跑视角切换更彻底我实测隔天跑出的争议条目质量明显高一些。这个细节听起来玄但你试几次就知道差别在哪。最后分享一个我自己一直在用的小动作每份材料审完之后我会在日志末尾加一句“如果只能改一处改哪里”。这句话逼着我做优先级排序而不是把所有问题平铺给提交方。一年下来回看这些句子发现它们指向的位置高度集中——几乎全在前提层。这大概也印证了这套框架最初的那个判断多数问题的根子不在结论在你没写出来的那句话上。
