企业官网建设流程全解析

• 人工智能
• 大模型
• 模型评测
• Agent 评测

InferenceX 是一个持续在 GPU 集群上基准测试 vLLM、SGLang 等开源推理框架的开源推理基准测试平台。它的数字之所以被各大 Token 工厂采信，背后藏着一个常被忽视的资产——仓库规则文件 AGENTS.md 中的行为测试清单。本文完整解读这套「AI 基准测试哲学」：哪 9 类测试被明令禁止、写测试前要问哪 4 个问题、以及让测试真正可信的分层证据体系。

一、为什么 AI 基准项目的测试特别容易「失守」🧪

基准测试仓库里躺着大量 YAML 配置、Shell 脚本和硬件清单。这类项目的测试很容易从「验证行为」滑向「验证文件」：检查某个配置里有没有某个字符串、断言某张镜像标签、数一数某个目录里有几条 recipe……

这类测试跑起来绿得很快，却在真正重要的时刻集体失灵——重构改了变量名、镜像打了个新 tag、recipe 多了一条，测试就红了；而真实的性能回归，它们一个都抓不到。

InferenceX 的应对方式非常直接：它把一条规则写进 AGENTS.md，作为对每一个新增、修改、评审的测试强制生效的铁律：

一条测试必须用具体输入驱动真实实现，并断言它计算、返回、写入或抛出的东西。任何检查代码、仓库或配置文件、而非运行行为的测试，不是测试，必须删除。（When in doubt, delete the test.）

这条「宁缺毋滥」的哲学，正是所有做 AI 基准、性能测试、硬件评测的团队都值得抄作业的地方。

二、9 类禁止测试：一张可以直接对照自查的清单 ⚠️

AGENTS.md 用编号列出了 9 类「见到就删」的测试。下面整理成对照表，你可以直接拿它自查现有代码库：

这套清单的锋利之处在于：它不是风格建议，而是删除指令——「Never write, and always delete on sight」。

三、新增测试前的 4 个灵魂拷问 🎯

通过 9 类黑名单还不够。AGENTS.md 要求评审者对每个待合并的测试连问 4 个问题，答不上来就删：

1. 它运行了真实实现的哪一行？该实现里的什么 bug 会让断言失败？
2. 如果把代码用相同行为重写一遍，它还能通过吗？不能 → 说明它测的是结构，必须删。
3. 有人新增一条 recipe、升一个镜像 tag、改一句注释，它会不会挂？会 → 说明它钉死了配置或源码，必须删。
4. 已有测试是否已覆盖这条分支？是 → 扩展旧测试，丢弃新测试。

最狠的一句收尾是：「删除一个没通过拷问的测试，不需要替代品。不要为了保住测试数量而保留它。」测试数量在 InferenceX 里不是质量指标，能捕获真实回归的断言才是。

四、好的测试长什么样：一个正面范本 ✅

规则的另一面是「保留下来的测试必须长这样」（AGENTS.md）：

• 向真实函数/CLI/脚本喂小而受控的输入，断言计算输出、写出的产物、退出码或异常；
• 期望值独立手工推演，绝不从被测实现反推；
• 覆盖别的测试没覆盖的分支、边界、畸形输入或失败路径；
• 只 mock 外部协作者（网络、Slurm、时钟、GPU），永不 mock 被测行为；
• 行为回归时它会失败，无害重构时它不会失败。

仓库里有个教科书级例子：inferencex-e2e/infx/tests/matrix/test_revision.py。它在一个临时 Git 仓库里提交两版配置，然后故意把工作区源码全部改成抛异常，再断言历史快照生成只用「提交时的源码」、且符号链接被正确解引用——这正是「驱动真实实现 + 独立期望值 + 覆盖回归路径」的完整示范。

五、行为测试之外：三层验证如何托住整个基准结果 📈

单元测试只能守住「这一次改动」，而基准数字要经得起跨版本、跨集群的较真。InferenceX 在测试之上还搭了两层，全部写在 inferencex-e2e/docs/testing.md：

第 1 层：分层检查，先窄后宽。原则是「用能证伪本次改动的最窄检查，只有当改动跨越更多层时才放大」——本地矩阵生成 → 冒烟运行 → 全量 sweep + eval，每一层能证明什么、不能证明什么，文档里都有明确表格。

第 2 层：证据标准。文档明确写道：「“CI is green”、没有 run 链接的截图、或只有收集器成功但没有真实作业的证据，都不算数。」证据必须精确到 commit SHA、命令、run ID 和工件名，让另一个评审者可以无猜测复现。

第 3 层：评审清单 + 独立复核。CODEOWNER 评审要填写 inferencex-e2e/docs/PR_REVIEW_CHECKLIST.md，勾选项从「evals 是否通过」到「投机解码 draft 是否按发布精度运行」逐项核验；而 CI 会独立重新验证这些声明——「勾选项不靠信任采信」。性能类改动还必须向 inferencex-e2e/perf-changelog.yaml 追加审计条目，历史字节不可改写，让每一次性能变化都有账可查。

六、给你的 AI 基准项目的 5 条借鉴要点 🚀

1. 把测试写成行为契约：禁止一切「读文件断言字符串」式测试，grep 不是测试。
2. 建一份 9 类黑名单 + 4 问清单，写进仓库规则文件，作为新增/评审测试的强制门槛。
3. 不为测试数量辩护：没通过拷问的测试直接删，不需要替代。
4. 给证据分层：快检查、冒烟、全量运行各自能证明什么，写成明文表格，杜绝「CI 绿了」式口头证据。
5. 让机器复核人的清单：人工 sign-off 之后，再跑一道独立的自动验证，声明与证据对不上就告警。

延伸阅读 📚

• 行为测试铁律原文：AGENTS.md（Test quality 章节）
• 分层检查与证据标准：inferencex-e2e/docs/testing.md
• CODEOWNER 评审清单：inferencex-e2e/docs/PR_REVIEW_CHECKLIST.md
• PR 评审与合并流程：CONTRIBUTING.md
• 行为测试正面范本：inferencex-e2e/infx/tests/matrix/test_revision.py
• 全部文档入口与任务路由：inferencex-e2e/docs/index.md

• 人工智能
• 大模型
• 模型评测
• Agent 评测