一个 AI 项目宣称自己支持长上下文、能写代码、能识别复杂图片这已经很常见。真正稀缺的是另一件事页面上的每个 AI 声明旁边都挂着一个公开探针public probe你点进去就能复跑跑完能得出通过还是失败。这个想法听起来不像新功能但做过 AI 测试和模型落地的人都知道它解决的是最麻烦的信任问题AI 能力不能光靠截图和 README它需要可验证的证据链。这个概念最适合三类人看一是想选型模型的开发者想绕过宣传页直接知道某个能力是否可用二是做 AI 应用和 Agent 的工程团队需要给功能设计回归测试三是自己写模型或工具的人想用一套更体面的方式展示成果。最值得关注的不是“又做一个榜单”而是它把“声明—证据—复跑”串成了一条可审计链路。下面按我的理解拆成设计原则、页面结构、探针类型、复跑排错和落地边界。1. 先搞清楚“AI 声明 公开探针 可复跑”到底在解决什么1.1 为什么需要给 AI 声明配证据现在很多大模型项目介绍页都会写“支持超长上下文”“代码能力强”“可以做多步推理”。这些描述没有太多限制条件用户看到的第一反应是“那我来试试”。试过之后才发现所谓“支持”往往由很多隐含条件决定上下文是支持了但中间内容一多就开始丢代码能力是强但只对某类语言和某个 prompt 风格有效推理能力强但对没有明确约束的任务经常答非所问。如果每个声明都配一个公开探针情况会不一样。比如你声称模型支持 100 万 token 上下文那就给出一个固定测试文件输入放到特定位置要求模型回答一个只能靠中间位置信息才能答对的问题。别人不需要自己准备复杂数据只需要执行你给的一条命令。这样能不能复现、什么时候失败、失败在哪一步都会变得清楚。这其实就是把“信任”从感觉变成流程。声明是假设探针是实验结果是证据。没有证据链的 AI 能力描述本质上只是广告文案。很多项目不是故意夸大而是发布者自己也没在极端条件下测过。公开探针能逼着发布者把测试条件说清楚。1.2 这种页面和普通 Benchmarks 的区别普通 Benchmark 通常是一套固定测试集给模型打分然后和别的模型排名。公开探针的定位不太一样。它的粒度更小直接绑定到具体声明。比如某个页面说“本模型可以调用天气 API 并返回结构化结果”那它的探针只需要覆盖这个场景模拟一个天气 API让模型走完整调用链路检查最后的 JSON 是否符合预期。不需要和别的模型横向对比只关心“这个声明能不能复跑”。另一个区别是成本。很多 Benchmark 动辄需要几百条样本、几十个小时的推理普通用户很难复现。public probe 要尽量短小能在普通开发机上跑完。哪怕只是验证一个功能点也比一个不可复现的大分数更有用。所以我理解这种页面的价值在于它把“AI 能力展示”从抽象描述变成具体的工程文件输入、命令、期望结果、实际输出、判定结果。页面本身可以是静态网页背后有一个探针目录和一个结果目录。谁想验证谁就自己 rerun。2. 设计一份可复跑探针的三个核心原则2.1 探针必须有明确的通过标准设计探针最容易犯的错是只写“输出一段回答”就完事。输出存在不代表能力达标。比如验证模型是否具备总结能力如果期望结果是“30 字以内”判定标准里就必须包含长度、是否包含关键实体、是否出现明显错误。如果期望结果是一条 JSON就必须校验字段名、字段类型、值是否在允许范围内。公开探针不是闲聊样本。每一份探针都应该回答三个问题给模型什么输入希望模型输出什么为什么这个输出能证明某个声明。最常见的形式是 expected.json里面记录通过条件。可以用精确匹配也可以用规则匹配规则匹配时要把匹配函数放在探针脚本里不要放在个人电脑里。如果某个能力确实不好量化比如“回答更自然”不要硬做一个看起来很科学的探针。可以改成更窄的问题比如“能否在给定风格示例后按相同格式输出”。声明窄一点没关系至少验证方式是可复现的。最怕的是声明很宽、判据很模糊最后所有结论都取决于 reviewer 心情。2.2 探针要让大多数普通机器能跑public probe 一个核心特征是“你可以 rerun”这要求运行门槛不能太高。如果一个探针需要 8 张 A100 显卡才能启动那它本质上是给有资源的人准备的不能叫公开可复跑。我一般建议把探针分成几档最小探针用 CPU 或小显存能跑标准探针用一张消费级显卡能跑完整探针才进入大规模资源。这也意味着设计探针时要控制输入长度和模型负载。测试长上下文不必每次都读完整本小说可以用一个中等长度的输入文件再加一段非常长的程序化样本。测试视频理解也不用准备长视频可以选几秒钟的片段明确记录关键帧出现的时间。探针的价值在于定位问题不在于追求最复杂的场景。2.3 探针必须保留完整运行记录一个探针跑出结果如果记录里只有“true”或“false”后面很难排查。真正有用的结果至少要包含声明 ID、探针 ID、模型版本、运行时间、运行命令、关键参数、输入摘要、输出摘要、判定依据。这样一旦结果变化能看出是模型版本变了还是随机性导致还是环境不同。我在实际维护探针时倾向把所有记录存成 JSON 文件按探针 ID 和时间戳命名。页面只负责读取最新结果做一个可读的展示。另一个关键点是不要只保存成功记录。失败记录同样有价值。如果你把失败日志删掉后来的人就无法判断“这个结果是否真的可靠”。3. 从零搭一个“声明—探针—结果”页面3.1 先梳理项目的声明清单要搭这样的页面我建议先做减法。不要一上来把所有能力都铺开先选 5 到 10 条最核心的声明。比如一个做 AI 编程助手的项目最值得验证的可能是能否根据 issue 描述生成可编译的修复补丁能否在给定测试代码后输出通过测试的代码能否正确处理缺失依赖等情况。每一条声明都对应一个 claim_id然后写清楚声明原文、验证范围、运行成本、复跑入口。先跑通单条再扩展成整个页面。声明清单既是对外展示的目录也是内部开发的测试来源。以后每次发布新版本先跑一遍这些探针比看产品演示更可靠。3.2 探针文件与运行脚本的组织方式探针应该和页面代码放在同一个仓库里这样别人可以 fork 后直接跑。目录结构可以参考下面这样probes/ long-context/ README.md input.txt probe.py expected.json code-fix/ README.md bug_repo/ probe.py expected.json commands/ run_probe.sh results/ long-context-latest.json code-fix-latest.json scripts/ generate_page.py每个 probe 目录里的 README 写清楚三件事这个探针验证的是什么声明、运行命令是什么、通过标准是什么。probe.py 是核心执行脚本负责加载模型、输入数据和 expected.json最终输出一个字典结构。commands/run_probe.sh 只是一个统一入口便于别人按相同方式运行。一个最小化的运行脚本可以是#!/usr/bin/env bash set -euo pipefail PROBE_ID${1:-long-context} MODEL_ID${MODEL_ID:-demo-model} python probes/$PROBE_ID/probe.py \ --model $MODEL_ID \ --input probes/$PROBE_ID/input.txt \ --expected probes/$PROBE_ID/expected.json \ --output results/$PROBE_ID-latest.json这里不指定具体模型接口因为不同项目差异很大。关键是保持结构统一每个探针都接收输入文件、期望文件、输出路径最后生成一个可读取的结果文件。有了这个约定写页面生成脚本就很简单。3.3 生成结果页面而不是人工截图结果页面不需要做得很复杂重点是把最新结果和复跑命令展示清楚。可以由一个脚本读 results 目录里的 JSON生成静态 HTML。这样每次跑完探针再运行一次页面生成命令就能更新结果。结果 JSON 可以做成这样{ claim_id: long-context-100k, probe_id: long-context-retrieval, model_version: demo-model-1.0, command: bash commands/run_probe.sh long-context, passed: true, observed: 在 98000 token 位置插入的目标信息被正确回答, duration_seconds: 42.5, starter: standard }页面上的每个声明旁边显示 passed、failed 或 uncertain再附一条 command。用户想复跑直接把 command 复制到本地执行。这里最容易被忽略的是页面不要只展示成功结果也要展示最近一次失败历史。因为对于读者来说知道某个探针在什么条件下失败往往比知道它通过更有说服力。4. 四类常见 AI 声明分别怎么设计探针4.1 文本类声明用可控样本把“好像能”变成“能”文本类声明最多比如“摘要能力好”“支持长文本”“不容易产生幻觉”。设计探针时我建议用可控样本不要用开放的互联网文章。因为你需要知道正确答案是什么才能判断模型输出是不是靠谱。比如验证摘要能力可以准备一份几百字的小材料提炼出 5 个必须出现的关键实体再要求模型只输出 3 句话。判定时检查关键实体是否出现、总字数是否满足、是否有新增内容。验证长上下文可以在长文本开头、中间、结尾分别放置需要记忆的信息再让模型回答三个定位问题。如果模型只记住开头和结尾说明中间段的注意力表达没有宣传中那么好。这些探针的运行成本都不高。不需要标答生成只需要你自己先读一遍样本确定正确答案。公开探针里最关键的就是“正确答案要尽量客观”。如果答案来源只存在于评估者脑子里别人就无法独立复判。4.2 代码与工具调用用最小仓库判断可用性代码类声明比文本类更容易设置判定标准。因为代码是可以运行、可以测试的。比如声明“能根据测试失败信息修复 bug”可以准备一个最小仓库里面有一个 bug、一个失败测试、一份 README。探针让模型生成补丁然后执行测试命令最终结果就是测试通过或失败。需要提醒的是代码探针不能只跑一次成功就下结论。要固定模型版本、种子、temperature还要设置超时时间。有的模型第一次能修好第二次会生成一个更复杂的方案结果反而跑不过。所以探针里最好规定模型只能生成单个补丁文件不能自由改动项目结构。这样既减少随机性也方便发现问题。工具调用类声明类似。比如模型声称能调用计算器可以准备一个模拟服务让模型按指定格式发出请求。探针要检查请求格式、参数是否合法、是否处理了异常返回。如果只是让模型“说一说调用过程”说明不了工具调用能力。真正要验证的是它在真实请求链路上能否完成动作。4.3 多模态与 Agent既要看结果也要看过程多模态探针要特别关注输入格式和预期输出的结构化程度。比如声明“能识别表格截图”就可以生成一张固定样式的表格图片包含姓名、金额、日期等字段要求模型输出 JSON。判定时不仅检查字段值还检查类型和格式。比如日期必须是 YYYY-MM-DD金额必须是数字不能带“元”字。Agent 类探针更复杂因为它多了一个工具调用过程。我的建议是同时记录最终状态和调用过程。最终状态代表任务是否完成调用过程决定这个结果是合理路径还是碰运气。可以搭一个本地 mock 工具服务模型的每次工具请求都由探针记录再校验工具顺序和参数。设计这类探针时不要把所有 Agent 行为都压到一个测试里。比如“能查天气”和“能订会议室”是两个不同能力拆成两个探针。这样如果失败能快速定位是自然语言理解的问题还是工具参数解析的问题还是最终结果生成的问题。5. 复跑时怎么判断结果怎么排查问题5.1 先给结果分三类通过、失败、存疑探针跑完不一定是非黑即白。我一般会把结果分成三类passed、failed、uncertain。passed 表示输出完全满足 expected 里的判定条件。failed 表示输出偏离了预期可以明确判定没达成。uncertain 表示探针本身有问题比如输出格式被解析程序误解、输入文件损坏、模型接口超时、依赖版本不匹配。uncertain 很关键。如果脚本把超时当成“模型能力失败”结论没有意义。所以探针脚本要能区分“模型回答错误”和“运行环境异常”。分类机制只需要在探针脚本里增加几个异常分支。超时返回 timeout依赖缺失返回 environment_errorJSON 解析失败返回 parse_error。这些都是探针自身的问题不应该归到模型能力里。页面展示时最好把 uncertain 单独标注否则很容易误导读者。5.2 按这个顺序排查不要一上来改算法如果同一个探针在别人机器上跑不通先别急着调 prompt 或换模型。我建议按固定顺序排查先看现象是启动失败、输出为空、卡住还是结果不稳定。再看命令路径是否写对模型版本参数是否一致。再看输入文件编码、长度、格式是否完整有没有被截断。再看环境Python、CUDA、依赖库、模型权重路径、权限。再看参数temperature、seed、max_tokens、超时时间。最后才看探针逻辑判定规则是否太严格期望值是否写错。这个顺序的好处是成本从低到高。很多复跑失败不是模型问题而是输入路径写错或依赖没装好。我见过最典型的例子是探针明明要求传入 100K token 的输入文件但 runner 脚本把路径指向了一个只有几行的测试文件结果输出看起来没问题实际上完全没测到目标能力。5.3 批量复跑不能只看“能跑”当探针数量多起来以后批量复跑是必然选择。但批量任务不能只看最终“几条通过”。要额外考虑三件事。第一排队和超时。每个探针执行时间不同统一用超时时间保护防止一个卡死的探针拖垮整个批次。第二失败重试。有些模型接口偶发超时重试机制是必要的但重试必须记录次数否则你没法判断结果是否可信。第三输出命名。批量跑完以后结果文件要能对应到具体声明和模型版本不能大家都叫 result.json。另一个经验是不要一上来就开最大并发。AI 模型调用往往受显存、内存和接口限流影响。先跑一条确认日志、输出目录都正常再把并发调高。如果只是学习默认配置通常够用如果要做持续集成就要把日志、输出目录、任务队列提前设计好。6. 这类页面的边界以及对 AI 工程实践的启示6.1 不是所有 AI 声明都能被一条探针证明公开探针很有价值但不能神化。很多 AI 能力尤其是“更懂用户”“回答更自然”“更安全”这类宽泛声明很难用一条探针证明。你可以缩小范围比如验证“面对诱导问题时不输出明确步骤”这可以设计成安全探针但“更安全”三个字不可能靠一条探针完全覆盖。另外探针通过并不等于能力全部达成。它只是证明在某个输入、某个模型版本、某个参数配置下模型满足了一组可见条件。别人复跑后如果结果一致信任度会提升但无法证明所有场景都可用。所以这个页面的措辞也很重要建议用“该声明最近一次验证通过”而不是“该功能百分之百可用”。6.2 我建议团队怎么落地如果团队想在自己的 AI 项目里引入这套机制我建议分四步走。第一步先挑 3 到 5 个最核心且最容易验证的声明写成探针。不要贪多。第二步把探针纳入模型发布流程每次更新模型权重或 prompt 版本时都跑一遍。第三步把结果输出成 JSON生成页面。一开始甚至不需要漂亮的界面能展示命令和结果就行。第四步等探针稳定之后再考虑接 CI、定时复跑、多模型对比。真正让这个页面可信的不是页面上的“通过”标签而是你随时能自己再跑一遍。哪怕你 fork 下来后改了模型版本只要探针文件还在你就能得到自己的结果。这种机制对选型、排错、内部回归都很有用也更像是一种长期可维护的工程实践而不是一次性的 Demo。我个人的建议是先不要急着把所有声明都 “探针化”从最让你心里没底的声明开始。任何一个 AI 项目总有一条你自己都觉得“好像能但没验证过”的能力。把它做成 public probe让别人和你自己都能复跑这个动作本身就比多写几页功能介绍更有说服力。