作者注：从验收标准、数据隔离到独立复核，用 5 个步骤设计 AI 深度任务的外部验证，避免模型自评造成的虚假完成。
模型回复“任务已完成，结果准确”，却经不起复现，这是许多 AI 使用者在处理深度任务时遇到的难题。本文将介绍 一套可独立运行的外部验证设计方法，帮助你把“模型说做好了”变成“证据表明做好了”。
Claude 开发者 Felix Rieseberg 在 2026 年 10 月发表的实践指南中明确建议：不要让模型自己给自己打分，并坚持使用外部验证。他认为，最理想的形式是模型能够自行运行、并立即获得反馈的工具。InfoQ 于 2026 年 11 月 4 日发布了这篇文章的中文译文。
这不是一篇劝你“多检查一遍”的提醒。原文给出了方向，本文在此基础上进一步整理出可落地的设计步骤，涵盖验证手段的选择、常见失效模式和多模型复核方式。
核心价值：读完本文，你将能为自己的 AI 深度任务写出一份验证契约，让模型在可判定的反馈中迭代，而不是在自我评价中结束。
AI 深度任务外部验证核心要点
外部验证的关键，不是增加一个检查环节，而是让判断依据独立于模型自身的推理过程。
| 要点 | 说明 | 价值 |
|---|---|---|
| 先定标准 | 开工前写清通过条件，并尽量做到可判定 | 避免模型事后重新解释目标 |
| 数据隔离 | 用模型没有见过的数据或场景检验结论 | 区分真实发现与事后拟合 |
| 工具优先 | 优先使用能运行、能立即反馈的验证器 | 让模型自主迭代，减少人工盯守 |
| 证据留存 | 保存运行结果、日志和复现步骤 | 让人能够审查结论，而不只是相信结论 |
| 独立复核 | 用不同方法和不同立场挑战结果 | 发现单一验证器遗漏的问题 |
为什么 AI 深度任务需要外部验证
Rieseberg 所说的“深度”，是指采用领域顶尖专家使用的工具、技术和知识，深入底层数据，而不是停留在任务表面。任务越深入，人越难凭直觉判断结果是否正确。一份措辞专业的流失分析，读起来可能很有说服力，但这并不能证明其中的因果判断成立。
他还提到一个常见现象：要求模型表现得像专家时，它往往只是换了一套词汇，工作方法并没有真正改变。自我评估很难发现这类问题，因为评价者和生产者共享同一套假设。如果推理一开始就有偏差，模型的打分也可能沿着相同的偏差展开。
大胆的目标会让验证变得更加重要。原文建议设定看似不合理的目标，比如把网站加载时间从 10 秒压缩到 200 毫秒，并要求模型继续尝试。这类目标之所以可用，是因为 200 毫秒可以被测量。如果目标既激进又无法验证，得到的很可能只是一份更自信的报告。
AI 深度任务外部验证快速上手：5 步设计法
下面的方法不依赖特定模型或框架，你可以先选一个正在进行的任务来套用。如果暂时无法全部实现，建议优先完成前三步。
第 1 步：把任务目标改写为外部验证标准
“分析得全面”“代码质量高”都无法直接判定，需要改写成可以通过或失败的条件。比如，把“修好崩溃”改写为“按原始复现步骤运行不再崩溃，并且相关测试全部通过”。标准必须在模型开工前写好，否则模型可能在完成后才调整成功的定义。
你可以先把下面这份验证契约写好，再交给模型执行：
| 字段 | 需要写清什么 | 示例 |
|---|---|---|
| 最终目标 | 真正想要的业务或工程结果 | 应用保持稳定，不再出现同类崩溃 |
| 原始材料 | 模型应直接使用的一手数据 | 崩溃报告、版本与 Git 提交的对应关系 |
| 验证器 | 由什么工具或数据判定结果 | 复现脚本、自动化测试、留出数据 |
| 通过条件 | 明确的阈值或判定规则 | 三个目标系统上均无法再复现崩溃 |
| 禁止事项 | 模型不得改动的内容 | 不得删除测试，不得修改留出数据 |
| 提交证据 | 需要附带的运行结果 | 命令、日志、失败记录和最终结果 |
| 停止条件 | 何时结束或交给人处理 | 达到迭代上限后提交阻塞原因 |
第 2 步：切断结论与验证数据的联系
模型用同一份数据提出假设并证明假设，这并不是外部验证。原文的用户流失示例提供了很好的做法：让模型从日志中寻找最早的流失信号，再用它没见过的数据证明该信号确实具有预测能力。实践中可以把数据按时间切分，早期数据用于探索，后期数据用于检验。
留出数据最好由独立脚本或人员保管，模型只能获得运行结果，而不能直接读取明细。若一次次根据结果调整方案，留出数据也会逐渐被“学会”。因此，重要结论最好再留一份只在最终验收时使用的数据。
第 3 步：优先选择模型能自行运行的外部验证工具
验证器越接近真实结果，反馈越快，模型就越能独立迭代。下表按照常见任务整理了几种外部验证手段，选择时不必追求单一的“最强方案”，而应按风险组合使用。
| 验证手段 | 能证明什么 | 反馈速度 | 主要局限 |
|---|---|---|---|
| 自动化测试与复现脚本 | 指定行为符合预期 | 快 | 只覆盖已写明的场景 |
| 性能测量工具 | 指标是否达到阈值 | 快 | 环境差异可能影响结果 |
| 留出数据回测 | 结论是否具有预测能力 | 中 | 历史规律不一定持续 |
| 红队式方法审查 | 假设和证据链是否薄弱 | 中 | 判断质量依赖审查方法 |
| 影子运行 | 方案在真实流程中是否有效 | 慢 | 周期长，组织成本较高 |
| 领域专家抽检 | 结果是否符合专业判断 | 慢 | 难以大规模覆盖 |
第 4 步：把外部验证接入模型的工作循环
验证工具只有放进模型的工作环境，才能产生持续迭代的效果。原文的崩溃修复案例很有代表性：作者先让 Claude 能方便地获取崩溃报告，知道每个版本对应哪次 Git 提交，还能使用 Windows、macOS 和 Linux 电脑。具备这些条件后，模型才能独立复现问题并验证修复。
这也说明，外部验证常常需要调整工作流程，而不只是修改提示词。你需要开放必要的数据和工具，比如通过 MCP 连接器接入数据源，同时把权限控制在任务范围内。循环设计至少要包含三项内容：
- 失败反馈：返回具体的错误日志和未通过项，而不是只有“失败”两个字。
- 迭代上限：限定重试次数和总预算，防止模型陷入无效循环。
- 受保护对象：将测试、验证脚本和留出数据设为只读，防止模型通过修改标准来“通过”。
第 5 步：用独立复核与并行运行完成外部验证
单一验证器通过，并不代表结论可靠。原文提到可以引入专门挑错的“红队”，比如做空投资者和法务会计师，但重点不是模仿他们的口吻，而是使用他们真正的研究方法。例如，要求模型追溯每个关键数字的原始出处，或者主动寻找能够推翻结论的数据。
对于流程类改动，还可以采用并行运行的方式。原文建议先用历史数据证明新的复盘机制本可以更早发现问题，再让它与现有流程并行运行一个季度。这样既能检验真实效果，也不必一开始就承担完全替换旧流程的风险。
接入建议：如果需要让不同模型分别承担执行和复核工作，可以通过 API易 统一调用。API易 提供本文涉及模型的 API 调用，兼容 OpenAI 与 Anthropic 接口格式，接入时一般只需按文档配置
base_url、api_key和model。文档地址：https://docs.apiyi.com
AI 深度任务外部验证的常见失效模式
外部验证也可能流于形式。下面这些问题在设计阶段就应当考虑，否则验证结果只会带来一种虚假的安全感。
| 失效模式 | 典型表现 | 应对方法 |
|---|---|---|
| 修改标准 | 删除失败用例或放宽断言 | 验证器只读，并审查相关改动 |
| 验证集过拟合 | 指标持续上升，新数据上却失效 | 保留一份最终验收数据 |
| 循环论证 | 用模型生成的数据验证模型的结论 | 回到原始日志和一手材料 |
| 只验形式 | 格式正确，但内容错误 | 增加业务规则和抽样核对 |
| 角色扮演 | 对话很像专家，成果却没有改善 | 要求执行具体方法并提交证据 |
其中，“第二个模型复核”需要特别说明。它比自评更好，因为可以暴露一部分盲点，但仍然属于基于判断的复核，不能代替测试或真实数据。复核时最好只提供任务标准、原始材料和最终产出，不提供前序对话，以减少原有推理对判断的影响。
不同 AI 深度任务的外部验证设计示例
以下示例可以作为设计起点，具体阈值需要根据业务情况确定。
| 任务 | 只靠自评的做法 | 外部验证设计 |
|---|---|---|
| 修复应用崩溃 | 模型解释修复原理后宣布完成 | 跨系统复现，确认修复后不再出现 |
| 寻找流失信号 | 模型给出一份合理的归因报告 | 用未参与探索的数据检验预测能力 |
| 检验流失原因 | 模型沿用“新用户引导有问题”的判断 | 从原始数据寻找支持和反对的证据 |
| 优化加载速度 | 模型列出优化项并估算收益 | 在固定环境中测量，与目标阈值比较 |
| 重构业务复盘 | 模型论证新方案更加先进 | 历史回测后，与现有流程并行一个季度 |
判断任务是否值得这样设计，可以参考一个简单的标准：错误的代价是否高于验证的成本。如果只是改写一封邮件，读一遍可能就足够了。但如果结果会影响线上系统或资源配置，就应当设计外部验证。
常见问题 FAQ
Q1：什么是 AI 深度任务的外部验证？
它是指用独立于模型自身判断的依据来检验结果，比如自动化测试、性能测量、留出数据回测和专家审查。核心要求是，判断标准不能由产出结果的模型临时决定。
Q2：外部验证和模型自检有什么区别？
模型自检可以快速发现明显的遗漏，但生产者和评价者共享相同的假设。外部验证引入了独立的证据来源，更适合判断结果是否真实有效。两者可以配合使用，但自检不能作为最终验收依据。
Q3：模型越来越强，外部验证还有必要吗？
Rieseberg 认为，随着模型变聪明，这个问题最终可能得到解决，但他明确建议，至少在 2026 年 10 月仍应坚持外部验证。这是阶段性的实践判断。在模型自评的可靠性得到验证之前，高风险任务仍应保留独立检验。
Q4：哪些场景最需要外部验证？
主要包括以下几类任务：
– **工程修复**：崩溃修复、性能优化和数据迁移。
– **数据研究**：流失分析、因果判断和预测信号发现。
– **长期运行的智能体流程**：需要模型在较少人工介入的情况下持续工作的任务。
Q5：如何通过 API 搭建多模型交叉复核？
可以通过 API易 统一接入，其接口兼容 OpenAI 与 Anthropic 格式：
1. 按照 API易 文档 https://docs.apiyi.com 配置接口地址和 API Key。
2. 在价格页 https://docs.apiyi.com/models 核对可用模型及其费用。
3. 为执行和复核分别配置不同的 `model`，复核请求不携带执行阶段的对话。
4. 将复核意见与测试结果分开记录，以测试和数据证据作为优先依据。
Q6：外部验证循环的成本如何估算？
总成本通常取决于迭代次数、上下文长度、输出长度和复核模型的数量。建议先在小样本上跑几轮，记录每轮实际用量，再结合迭代上限估算预算。本文不列具体单价，模型价格、计费口径、输入输出单价和缓存价格均以 API易 价格页 https://docs.apiyi.com/models 的实际数据为准。
Q7：外部验证有哪些限制？
测试只能覆盖已定义的场景，回测无法保证历史规律继续成立，影子运行的周期也比较长。验证通过只能说明结果在限定条件下得到了支持，并不等于绝对正确。涉及法律、财务和重大业务决策时，最终判断仍应由相关责任人完成。
AI 深度任务外部验证核心要点 Key Takeaways
- 核心原则：不要把模型自评当作验收依据，判断必须来自独立证据。
- 标准前置：开工前写好通过条件，防止事后重新定义成功。
- 数据隔离：用模型没见过的数据检验其发现，避免循环论证。
- 工具优先：能运行、能立即反馈的验证器最有利于自主迭代。
- 环境配套：模型需要获得数据、工具和运行环境，才能完成自我修正。
- 复核分层：第二模型用于发现盲点，不能替代测试和真实数据。
- 灵活接入：可通过 API易 统一调用多个模型，降低交叉复核的接入成本。
总结
设计 AI 深度任务的外部验证时，可以记住以下三点：
- 先把目标变成可判定的标准：没有通过条件，就无法判断任务是否真正完成。
- 让证据独立于模型的推理：隔离数据、保护验证器，并保留完整的运行记录。
- 按风险组合验证手段：工具提供快速反馈，复核发现盲点，并行运行检验真实效果。
下一步可以挑选一个手头的深度任务，先写一份验证契约，再让模型开始工作。这样做不只能减少错误，也让你敢于提出更有挑战性的目标，因为无论目标多大胆，结果都有办法接受检验。
如需搭建多模型执行与复核流程，可以通过 API易 进行调用测试，接入方式见 https://docs.apiyi.com，模型价格和计费口径以 https://docs.apiyi.com/models 的实际数据为准。
📚 参考资料
- 如何把目标定得更大胆：写给 AI 使用者的实践指南：InfoQ 中文译文
- 链接：
infoq.cn/article/F1ms7x7KI1p7UfocCywh -
说明： 包含高度、深度、广度三个方向的实践方法
-
How to be more ambitious: A tutorial for humans with models：Felix Rieseberg 原文
- 链接：
felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models -
说明： 外部验证建议及崩溃修复、用户流失等案例的原始出处
-
API易 文档中心：接口接入说明
- 链接：
docs.apiyi.com -
说明： 用于查询 OpenAI 与 Anthropic 兼容格式的接入配置
-
API易 模型与价格页：模型及计费信息
- 链接：
docs.apiyi.com/models - 说明： 模型价格、计费口径和缓存价格均以此页面为准
作者：API易 技术团队
技术交流：欢迎在 API易 网站首页联系我们，更多资料可访问 docs.apiyi.com 文档中心
