证据优先：从“我认为”到“我证明”——大模型工程的第一性原理（第1期）

证据优先：从“我认为”到“我证明”——大模型工程的第一性原理（第1期）

专栏：《大模型落地之道：智能体生态卷》
作者：Valhalla Matrix治理实验室
文章类型：原创技术实践与方法论总结
适用读者：技术负责人、架构师、AI 产品负责人、研发管理者

摘要

大模型能够生成代码，并不意味着生成的代码可信。真正的工程风险，往往不是语法错误，而是模型在缺乏证据时，自信地补全不存在的接口、参数和算法步骤。

本文提出“证据优先（Evidence-First）”原则，并将其与 fail-closed 机制结合，讨论企业级 AI Agent 如何固定能力边界、减少模型幻觉、提升研发过程的可追溯性。文章同时给出一套从论文证据抽取、方法图构建、实现计划生成，到代码验证和发布门禁的实践路径。

关键词： 大模型、AI Agent、证据优先、Fail-Closed、企业智能体、能力边界、工程治理、提示工程

一、从一次“自信的翻车”说起

在一次论文复现任务中，我们让一个 Agent 根据论文内容生成算法实现骨架。

模型很快给出了结构完整、命名规范、能够运行的代码，甚至还补充了若干看似合理的 API 和配置项。初步测试全部通过，但经过第二轮语义核对后发现：其中几个方法并不存在于原论文，部分参数也没有对应的证据来源。

模型并不是有意造假。问题在于，它被要求“尽量完整”，却没有被强制要求回答：

这个结论的证据在哪里？

于是，缺失信息被模型的语言生成能力填补成了“看起来合理”的实现。

这类问题比普通 Bug 更危险，因为它通常具备三个特征：

• 代码可以通过语法检查；
• 示例输入下可能得到正常输出；
• 错误会在后续设计、测试和发布环节继续传播。

因此，大模型工程首先需要解决的，不是如何让模型生成更多代码，而是如何让系统在证据不足时停止扩展结论。

二、什么是证据优先？

传统的模型使用方式通常是：

输入文本
->
模型总结
->
生成计划
->
生成代码

证据优先的流程则强调：

获取来源
->
建立可定位的证据索引
->
构建方法图
->
生成实现计划
->
生成代码骨架
->
测试、评审和发布门禁

它遵循一条核心原则：

先有证据，再有计划；先有计划，再谈实现；实现之后，还必须能够复现。

在企业级应用中，模型可以负责提取、归纳和压缩信息，但不应在没有证据时替证据下结论。

一个完整的论文复现链路，可以抽象为：

intake 论文元数据与来源确认
normalize 章节、公式、表格、指标结构化
method graph 方法、数据、训练和评估关系建模
code plan 将方法节点映射到实现任务
scaffold 生成可运行代码骨架
validation 测试、基准、人工复核
release 满足门禁后才允许交付

任何一个关键节点缺少证据，都应保留“未确认”状态，而不是自动填入一个默认答案。

三、为什么关键路径必须采用 Fail-Closed？

fail-open 的逻辑是：没有证据时先放行，出了问题再补救。

fail-closed 的逻辑是：没有证据时先拒绝，补齐证据后再放行。

对于论文阅读、代码草拟等低风险探索任务，允许模型提出假设是有价值的；但对于以下场景，默认策略应更加严格：

• 修改生产配置；
• 调用敏感业务 API；
• 访问内部数据；
• 生成对外发布的代码；
• 执行不可逆操作；
• 给出安全、合规或性能结论。

一个简单的发布门禁可以写成：

证据是否存在？
否 -> 标记为缺失 -> 拒绝放行 -> 转人工复核
是 -> 是否完成关联验证？
否 -> 保持待确认
是 -> 进入下一阶段

Fail-Closed 并不意味着所有步骤都要阻塞，而是要把严格门禁放在真正高风险的边界上。

四、模型“脑补”能力会怎样传播？

假设模型虚构了一个论文中不存在的接口，后续链路可能发生如下变化：

不存在的接口
->
错误的方法图
->
错误的实现计划
->
带有伪能力的代码骨架
->
针对伪能力编写的测试
->
错误的评估结果
->
错误的发布决策

最危险的地方在于，后续测试可能只是验证“代码是否按照自己的假设运行”，而不是验证“代码是否忠实实现了原始方法”。

所以，测试通过不一定说明论文复现正确。还需要增加语义一致性检查：

• 每个核心方法是否能定位到论文章节、公式或表格；
• 每个关键参数是否有来源；
• 代码中的数据流是否与方法描述一致；
• 实验指标是否使用了论文定义的口径；
• 未在论文中出现的扩展是否被明确标注为工程假设。

这也是“证据链”比“代码能运行”更重要的原因。

五、证据应该具备什么特征？

证据不是越多越好，而是越容易复核越有价值。

一条合格的证据至少应具备以下属性：

1. 可定位

能够追溯到明确的章节、页码、公式、表格、代码行或版本提交。

2. 可验证

第三方可以根据原始材料重新检查，而不必相信某个 Agent 的解释。

3. 可关联

证据与实现任务之间存在清晰映射，例如：

公式 3 -> 损失函数实现
表 2 -> 评估指标配置
第 4 节 -> 数据预处理流程

4. 可版本化

记录文档版本、代码版本、模型版本和数据版本，避免来源内容发生变化后无法回溯。

5. 能表达未知

如果原始材料没有说明某个参数或边界条件，应记录为“未说明”，而不是由模型自行补齐。

可以采用如下结构保存证据：

{
"claim": "模型使用某种损失函数",
"source": "paper.pdf",
"location": "section_3.2, equation_4",
"evidence": "原文或公式摘要",
"confidence": "confirmed",
"linked_tasks": ["implement_loss", "add_loss_test"]
}

其中 confidence 不应只是模型主观打分，而应结合来源类型、定位信息和人工复核状态。

六、Prompt-First 不是不能用，但必须明确边界

证据优先并不意味着完全拒绝提示词和大模型总结。

模型非常适合完成以下工作：

• 将长文本压缩为结构化摘要；
• 提取候选方法、参数和指标；
• 发现章节之间的关联；
• 生成待核对的问题清单；
• 根据已确认的方法生成代码草稿。

真正需要限制的是：

不能让模型用语言流畅性替代来源证据。

更稳妥的职责划分是：

一句话概括：

模型负责提高处理效率，证据负责约束最终结论。

七、企业 Agent 的能力边界：从“能做什么”到“允许做什么”

个人助手可以在低风险场景中“试试看”，企业 Agent 则必须回答：

在什么条件下，允许它做什么？

一个企业 Agent 可能具备读取文档、查询数据库、调用业务 API、修改配置、触发部署和发送通知等能力。如果这些能力没有明确边界，模型可能：

• 调用未授权接口；
• 访问与任务无关的数据；
• 修改超出范围的配置；
• 在错误时间触发部署；
• 使用过高权限完成简单任务。

建议为每项动态能力建立能力卡，至少包含：

能力名称
允许的调用方
所需权限
可访问的数据范围
前置证据
参数约束
失败处理
审计字段
人工确认条件

例如，Agent 要执行部署操作时，不仅要判断“模型是否能生成部署命令”，还要检查：

• 目标环境是否明确；
• 变更是否经过审批；
• 镜像和依赖是否已扫描；
• 回滚方案是否存在；
• 当前账号是否具备最小必要权限。

能力治理的重点不是限制模型“会什么”，而是限制系统“允许它在什么条件下做什么”。

八、证据优先也是安全治理机制

1. 防止模型生成错误的安全实现

模型可能补写不存在的认证方式、错误的权限检查或不安全的默认配置。代码结构看起来完整，并不能证明安全边界正确。

涉及身份认证、权限控制、数据访问和密钥管理的实现，必须回到真实接口、官方文档、代码调用链和安全测试中核对。

2. 防止过度授权

每一次能力授权，都应能回答：

这个权限服务于哪个任务？
证据来源是什么？
为什么不能使用更低权限？
权限何时失效？

3. 让审计记录“为什么允许”

高质量审计不应只记录已经发生的操作，也应记录放行依据：

请求主体
能力名称
证据版本
审批状态
参数摘要
执行结果
失败原因

这样才能在出现问题时回溯“当时依据了什么”，而不仅是回放日志。

九、如何在团队中落地证据优先？

第一步：识别关键路径

优先识别生产变更、敏感数据访问、模型发布、依赖升级、权限申请和不可逆操作。

第二步：定义最低证据要求

为不同操作指定必需证据，例如：

第三步：设置自动化门禁

门禁应优先检查结构化条件，而不是只让另一个模型阅读自然语言说明：

证据字段是否齐全？
来源是否可访问？
版本是否一致？
测试是否通过？
权限是否满足最小范围？
回滚信息是否存在？

第四步：为低风险任务保留快速通道

探索性问答、草稿生成、非生产代码建议可以允许模型提出假设，但必须明确标注：

已确认事实
待验证推断
工程假设
尚无证据

第五步：持续复盘误拦和漏拦

定期检查：

• 哪些门禁误拦了正常任务；
• 哪些低风险流程不必要地增加了成本；
• 哪些操作在证据不足时被错误放行；
• 证据要求是否需要调整；
• 审计信息是否足以支持复盘。

十、一个可执行的最小实践方案

如果团队准备从零开始，不必一次性建设完整治理平台，可以先实现一个最小闭环：

用户需求
->
Agent 提取候选结论
->
检索系统返回原始证据
->
规则校验来源和定位
->
Agent 生成带引用的计划
->
代码生成
->
自动测试与人工评审
->
满足门禁后交付

最小版本至少应具备三项能力：

可以将 Agent 的输出统一分为四种状态：

confirmed 已有可复核证据
inferred 基于证据的推断
assumed 工程假设
unknown 当前没有足够证据

这比让模型只输出一个看似确定的自然语言答案，更适合进入企业研发流程。

十一、常见误区

误区一：有测试通过，就说明实现正确

测试可能只覆盖了代码自身的假设，并未验证它是否忠实对应原始需求或论文方法。

误区二：来源是公开的，就不需要版本管理

公开网页、论文和仓库都会更新。没有提交号、文档版本和时间信息，就无法稳定复现当时的判断。

误区三：所有流程都采用严格阻断

过度门禁会显著降低探索效率。应根据风险和可逆性设计分级策略。

误区四：把模型的置信语气当作证据强度

“显然”“完整实现”“已经支持”等表达，不会自动增加事实可信度。证据必须来自可定位、可验证的来源。

十二、总结：大模型时代，工程判断必须回答“凭什么”

证据优先不是一种单独的模型技巧，而是一套工程纪律：

先定位证据
再形成结论
再制定计划
再生成实现
最后通过验证和门禁交付

它的核心价值，不是让模型永远不犯错，而是让错误更早暴露、更容易定位，并且不会在缺乏依据时被系统默认放行。

对于企业智能体而言，最关键的问题不是：

模型能不能完成这件事？

而是：

它凭什么认为自己能完成？
系统凭什么允许它执行？
执行结果如何被复核和追溯？

当 AI 开始参与代码生成、数据访问、配置修改和生产发布时，“看起来合理”已经远远不够。

用证据定义能力，用验证决定放行，用审计保证长期可控。

延伸阅读方向

• 企业级 AI Agent 的动态能力边界与权限治理
• Agent 上线前的安全评估与可验证保障
• 论文到代码的可复现工程流程
• 大模型生成代码的测试、审计与发布门禁

**版权声明：**本文为原创技术文章。转载或引用时请保留作者及原文出处信息，并确保内容未被断章取义。