第一百七十二章 解释层
周六下午，卫越发来消息：「下午三点，还是腾讯会议？」
「可以，」陆衍回。
他把手上的文档先保存，然后打开腾讯会议链接，等三点到来。
豆包在旁边——现在它的界面一直开着，像一个总在那里、但不总开口的人。
三点整，卫越的画面亮起来。背后还是那个窗子，上午的光换成了偏西的斜光，他那边的书架上多了几本新书，摆得有点随意，像是临时搁上去的。
「M-07跑完的结果我看了，」卫越说，「第五条很有意思——日期在前，文件在后，这种类型的矛盾最难被人工发现。」
「对，」陆衍说，「因为人工看的时候是按顺序翻文件，两个日期分散在两本不同档案里，很难在大脑里同步比对。工具能做到，是因为它不按顺序看，它看的是关系。」
「但，」卫越停了一下，「你上次发的那条消息——解释层。我一直在想这个怎么做。」
「豆包，」陆衍说，不是在问谁，就是开口说出这两个字。
豆包的界面上出现了一行字：「我有三个方向，不一定都可行。」
卫越侧了一下头，「说。」
豆包把三个方向逐条列出来：
方向一：规则引用。工具在发现矛盾的时候，同步标注这条矛盾的依据来自哪个具体条款。比如「ISO 13485：2016 第7.5.1条要求，文件版本应在使用前完成审核，引用版本须为当时有效版本」——把条款原文或条款编号附在每条发现旁边。
方向二：时序可视化。用图形展示涉及矛盾的几份文件在时间轴上的位置——这份发布，这份引用，这份修订，三个时间点并列在一条轴上，用户一眼看出哪里不连续，哪里有跳跃。
方向三：自然语言说明。用一句话解释这条矛盾为什么是问题：比如「供应商评估报告（2021年9月22日）引用了规格书V2，但V2直到2021年10月1日才正式发布，这意味着评估报告使用了尚未存在的版本作为依据。」
陆衍把这三条看完，没有立刻说话。
卫越已经开口：「第一条，工程上最好做。规则库我们本来就在维护，每种监管框架对应它的条款索引，这个可以直接关联，不需要任何额外的推理——工具发现这类矛盾，是因为约束规则在那里，只要在输出时把规则来源带出来就行。」
「但，」陆衍说，「用户拿到「ISO 13485：2016 第7.5.1条」这串字，他会怎么做？」
卫越想了一下，「查文件？」
「尽调团队里不一定有人懂ISO 13485，」陆衍说，「他们是并购律师，是财务顾问，他们拿到这个条款编号，要先找到文件，再找到这一条，然后理解它说的是什么，然后再理解为什么发现的那条矛盾和这个有关——这个路径太长了。」
「但如果他们拿到第三条，」他说，「「供应商评估报告引用了尚未发布的规格书版本」——这句话他们不需要查任何东西就能判断这是不是一个问题。」
卫越沉默了一会儿。
「第三条，」卫越说，「推理量大。每条矛盾要生成对应的自然语言说明，不同类型的矛盾说法不一样，版本时序是一类，签字日期是一类，引用关系是一类——每一类都要写不同的模板，而且模板要足够准确，不能误导用户。」
「模板，」陆衍重复了一下，「所以不是完全推理，是模板加填槽。」
「是，」卫越说，「但槽的种类如果很多，维护成本会高。如果后面接入新的监管框架，模板要跟着扩展。」
豆包出现了一行新字：「可以两层。」
两个人都看向那行字。
「底层，」豆包继续写，「用规则引用——每条发现背后的约束逻辑是确定的，规则库维护的是这部分。这一层是工程层，不暴露给终端用户。」
「表层，」它写，「用自然语言说明——从规则引用加上具体文件信息，生成一句给用户看的说明。这一层的输入是「违反了哪条规则」加「涉及文件的具体数据（日期、版本号、文件编号）」，输出模板是固定格式，槽位用具体数据填充。」
「比如，」它补了一个例子：「规则：7.5.1条，要求引用版本须为当时有效版本。文件数据：规格书V2发布日期2021年10月1日，内审引用日期2021年9月22日。生成说明：「内审记录（2021年9月22日）引用了规格书V2，但V2直到2021年10月1日才发布，引用发生在版本生效前。」
「这样的话，」豆包写，「模板数量等于矛盾类型数量，不是矛盾实例数量。每增加一种矛盾类型，维护一个模板；同一类型的所有发现，共用同一个模板，槽位自动填充。」
陆衍把这段看完，沉默了一会儿。
「这个可以，」他说，「但有一个问题——生成出来的那句话，准不准确。」
「工具本身的发现如果是对的，」卫越说，「说明就是准确的——因为说明只是把发现翻译成自然语言，没有引入新的推理。」
「如果工具发现是误报呢？」陆衍说，「M-07里第四条，工具发现了版本窗口期矛盾，但有备忘录解释了这个窗口期。工具如果同时生成了一句「认证申请使用了废止版本V2，而V3已于2021年8月生效」——用户拿到这句话，可能直接当结论处理，不再去核实有没有备忘录。」
卫越皱了一下眉。
「所以，」陆衍说，「自然语言说明不是「结论」，是「发现」——每条说明要让用户知道，这是工具发现的一个可能问题，不是已经确认的问题，需要人工核实才能定性。」
豆包的界面上出现一行：「在每条说明前面加一个前缀：「发现一个可能的时序矛盾，建议核实：」」
卫越看了一下这行字，「这可以，工程上加这个前缀不难，但语气要统一——每条都是「发现一个可能的……」，不会让用户觉得到底是有问题还是没有问题？」
「是的，」陆衍说，「比不说更好——工具说「可能」，用户知道要自己判断；工具说「是问题」，用户会跳过判断。我们做的事情是帮用户找到该问的问题，不是帮用户给出答案。」
卫越安静了一会儿，「这和你一开始说的「完整性，不是答案」是一回事。」
「对，」陆衍说。
两个人停了一会儿，各自看着自己面前的屏幕。
「那，」卫越说，「这件事我来做——解释层框架。底层规则库里加一个「矛盾类型」字段，每种类型对应一个模板；工具在发现矛盾时，根据类型找模板，把文件数据填进去，生成自然语言说明；输出时，说明和原始发现并排——用户先看说明，如果想知道依据，可以展开看规则引用。」
「展开可见，默认不显示，」陆衍说，「绝大多数用户不需要看原始条款，但需要的时候得能找到。」
「对，」卫越说，「这个折叠展开逻辑好做，前端的事。」
「矛盾类型，」陆衍问，「你现在能数出几种？」
「我想一下，」卫越把笔拿出来，在纸上写，「版本时序类——发布日期和引用日期不一致；签字日期类——签字人在文件生效前签字，或者文件里引用了签字时不存在的内容；评估依据类——评估报告引用的标准或版本在评估日期时尚未生效；版本一致性类——同一批文件里，对同一文件的版本标注不一致……」他停了一下，「四种。可能还有，但四种先够了。」
「够，」陆衍说，「先做四种，跑一次冯树的新文件包，看说明生成出来用户是不是能读懂。」
「好，」卫越说，「下周我把框架加进去——不是完整的，但主干的逻辑要跑通。」
陆衍点了一下头，「可以，先跑通，用真实文件测一遍，再迭代。」
视频通话结束之后，陆衍把笔记本打开，在新的一页写了几行：
「解释层设计—— 底层：规则引用（条款+依据，工程层，不暴露） 表层：自然语言说明（模板+填槽，暴露给用户） 原则：发现，不是结论；可能，不是确认。 矛盾类型（初稿）：版本时序、签字日期、评估依据、版本一致性，共四类。 下一步：卫越下周加进框架，冯树的新文件包来了就测。」
他把本子合上，推去桌边。
窗外已经是傍晚，楼之间的光开始变色，由白转橙。
豆包的界面上有一行话，他没有特别去看，但余光里扫到了：
「今天把要做的事想清楚了。」
他把电脑盖上，去倒了一杯水，站在窗边喝了一口。
有时候下一步是很具体的——下周，卫越，框架，四种类型，冯树的文件包。
具体到这个程度，就可以等了。