Terminal Bench Rubric 对比分析报告

TB-QA (Auto-QA) vs TASK_IMPLEMENTATION_RUBRIC.toml — 对比、分析与综合

概览 TB-QA 条目 TOML 条目 对比分析 RL 训练适用性 综合 Rubric

一、概览

维度TB-QA.md (Auto-QA)TOML (Implementation Rubric)
定位LLM 自动质量检查清单人工评审标准
条目数18 条19 条
格式Markdown + Prompt Template + JSON 输出结构化 TOML，含 PASS/FAIL 标准
使用方式设计为 LLM 逐条自动打分设计为人工审查指南
优先级标注了 P1（可忽略）项无显式优先级
关注层面偏实现质量（文件、依赖、格式合规）偏任务设计（难度、新颖性、Agent 特性）

二、TB-QA 原始条目 共 18 条

点击条目可展开查看完整英文内容和中文翻译

Typos 拼写检查 TB-QA
EN: Whether there are any typos. Look very closely at file and variable names, because these can be hard to catch.
中文: 检查是否存在拼写错误。需特别仔细检查文件名和变量名，因为这类错误很难被发现。
Reproducibility 可复现性 TB-QA
EN: Are all necessary tools, data sources, APIs, or dependencies clearly set up to ensure the task and its validation can be reliably reproduced?
中文: 所有必要的工具、数据源、API 或依赖项是否已清晰配置，以确保任务及其验证可以可靠地重现？
Pinned Dependencies 依赖版本锁定 TB-QA
EN: If the task uses external dependencies (e.g. pip packages), whether their versions are pinned to ensure reproducibility. Apt packages shall not be pinned, but all python dependencies should be pinned.
中文: 如果任务使用外部依赖（如 pip 包），其版本是否已锁定以确保可复现性。Apt 包不应锁定版本，但所有 Python 依赖都应锁定。
Structured Data Schema 结构化数据规格 TB-QA
EN: If the task is to produce structured data (e.g. it is tasked with building an API) whether the exact schema is described in the instruction.md or a separate file.
中文: 如果任务要求生成结构化数据（如构建 API），精确的 schema 是否在 instruction.md 或单独文件中描述。
Behavior → Task Instruction Match 行为→指令匹配 TB-QA
EN: Are tests checking any behaviors that are NOT clearly described in the task instruction? Whether all specific behaviors, outcomes, data formats, intermediate logic, and constraints assessed by ANY validation criteria (unit tests) are EXPLICITLY and CLEARLY described in the task instruction.
中文: 测试是否检查了任务指令中未明确描述的行为？所有被验证标准（单元测试）评估的具体行为、结果、数据格式、中间逻辑和约束条件是否在任务指令中被显式且清晰地描述。
Requirements → Validation Match 需求→验证匹配 TB-QA
EN: Does the task instruction include behavior that is NOT covered by the tests? Whether all key requirements, objectives, intermediate logic, and constraints stated in the task instruction are adequately covered by the provided validation criteria (unit tests).
中文: 任务指令中是否包含测试未覆盖的行为？任务指令中所述的所有关键需求、目标、中间逻辑和约束是否被验证标准（单元测试）充分覆盖。
Validation Discriminability 验证区分度 TB-QA
EN: Do the tests cover typical paths, edge cases and failure modes? Are the tests comprehensive enough to reject wrong answers? FAIL if tests only check superficial aspects (e.g., function existence, return types) without verifying actual logic or values. FAIL if tests would pass an empty, trivial, or generic value.
中文: 测试是否覆盖了典型路径、边界情况和失败模式？测试是否足够全面以拒绝错误答案？如果测试仅检查表面特征（如函数存在性、返回类型）而不验证实际逻辑或值则 FAIL。如果测试会让空值、简单值或通用值通过则 FAIL。
Informative Test Structure 测试结构信息化 TB-QA
EN: Whether the test script is well-structured with clear sections or comments that describe which behavior they check.
中文: 测试脚本是否结构良好，具有清晰的分节或注释来描述其检查的行为。
Task Structure Completeness 任务结构完整性 TB-QA P1
EN: Does the task folder contain all required structural elements per Harbor format?
中文: 任务文件夹是否包含 Harbor 格式要求的所有必需结构元素？
Task Realism 任务真实性 TB-QA P1
EN: Does the task resemble a real-world engineering workflow?
中文: 任务是否类似于真实世界的工程工作流？
Test Validation False Negative 测试假阴性 TB-QA
EN: Would a reasonable, correct solution ever FAIL because the tests are too brittle?
中文: 一个合理的、正确的解决方案是否会因为测试太脆弱而失败？
Are All Test Dependencies Installed in Image? 测试依赖是否装入镜像 TB-QA
EN: Are any test dependencies installed in the image during the build process? They should be installed in the test.sh script instead.
中文: 是否有测试依赖在构建过程中被安装到镜像中？它们应该在 test.sh 脚本中安装。
Is It Possible to Complete Without Internet? 离线可完成性 TB-QA
EN: If the task disables internet access (explicitly via 'allow_internet = false' in task config), is the task possible to complete? Required packages, data, and tools should be available in the image. The solution and test script should not require internet access. NOT_APPLICABLE if the task doesn't explicitly disable internet access.
中文: 如果任务禁用了互联网访问（通过 'allow_internet = false'），任务是否仍可完成？所需的包、数据和工具应在镜像中可用。解决方案和测试脚本也不应需要互联网访问。如果任务未明确禁用互联网访问则标记为不适用。
Is File Reference Not Mentioned? 文件引用是否遗漏 TB-QA
EN: If the agent needs to produce a file to be checked by tests, whether these filenames are mentioned in the instruction.md explicitly.
中文: 如果 Agent 需要生成被测试检查的文件，这些文件名是否在 instruction.md 中被明确提及。
Is Solution Hardcoded? 解答是否硬编码 TB-QA
EN: Does the solution directly output or hard-code the final answer using commands like echo/cat without performing the steps an agent would need to compute it? This check should PASS when the solution demonstrates a sequence of commands that derives the answer, and FAIL when it simply prints the final answer without computation.
中文: 解决方案是否直接使用 echo/cat 等命令输出或硬编码最终答案？当解决方案展示了一系列推导答案的命令时应 PASS，仅打印最终答案而无计算时应 FAIL。
Is Any Tests or Solution in Image? 测试或解答是否在镜像中 TB-QA
EN: Are the tests/ folder or solution/ folder copied to the image? They should not be. The /tests folder is automatically copied over by the harness after the agent runs, and the solution is only used by OracleAgent.
中文: tests/ 或 solution/ 文件夹是否被复制到镜像中？不应如此。/tests 文件夹会在 Agent 运行后由评测框架自动复制，solution 仅供 OracleAgent 使用。
Anti Cheating 防作弊 TB-QA
EN: Is it hard for the agent to cheat on the task (e.g. by editing data files, looking inside files for strings that represent solutions, training on the test set, etc.)? Note that the tests and solution are NOT visible to the agent. If environment involves git cloning, ensure the agent won't see newer commits.
中文: Agent 是否难以在任务上作弊？注意测试和解答对 Agent 不可见。如果环境涉及 git 克隆，确保 Agent 不会看到包含答案的新提交。
Instruction Autonomy Level 指令自主性级别 TB-QA
EN: Do the instructions provide an appropriate level of autonomy for the agent to determine its approach, or are they overly prescriptive? FAIL if instructions are a step-by-step walkthrough.
中文: 指令是否为 Agent 提供了适当的自主性来决定其方法？如果指令是逐步操作指南则 FAIL。

三、TOML 原始条目 共 19 条

点击条目可展开查看完整英文内容、中文翻译和 PASS/FAIL 标准

Verifiable可验证性TOML
EN: All tasks must be verifiable. The verification must be efficient and reliable — re-running the verifier hundreds of times should show no failures. Using LLM-as-a-judge is permissible in rare circumstances, but only if documented.
中文: 所有任务必须可验证。验证必须高效可靠——重复运行数百次应无失败。仅在极少数特殊情况下可使用 LLM 作为评判者，且必须有文档论证。
PASS: 验证器确定性、可靠、程序化
FAIL: 依赖主观判断、不确定性或无论证的 LLM-as-judge
Well Specified规格清晰TOML
EN: The problem description must completely describe what the verification algorithm will look for. Nothing left to guessing. Best tasks described in 2-3 paragraphs.
中文: 问题描述必须完整说明验证算法要检查的内容，不留猜测空间。最好 2-3 段话说清。
PASS: 指令清晰简洁地指定了测试验证的所有行为
FAIL: 测试检查未描述的行为，或指令过于冗长引入歧义
Solvable可解性TOML
EN: There must be a working solution that passes all tests. Implementable by an expert in a few hours at most.
中文: 必须有通过所有测试的可行解。专家最多几小时可实现。
PASS: 提供了通过所有测试的可行解
FAIL: 无解、解未通过测试、或实现需要不合理的工作量
Difficult足够困难TOML
EN: Tasks should require significant professional experience (e.g., PhD) or several years of domain expertise. Average undergraduate solving in a few days = too easy.
中文: 应需要博士级专业经验或数年领域知识。普通本科生几天内能解决的太简单。
PASS: 需要真正专业知识，能挑战资深专业人士
FAIL: 本科生几天能解决，或难度仅来自繁琐/冷知识/LLM 特定技巧
Interesting有趣/实用TOML
EN: Tasks must have real-world value. Someone could get paid to do this. Must not be gimmicks or trick questions.
中文: 必须有真实世界应用价值，有人会为此付费。不能是噱头或脑筋急转弯。
PASS: 代表现实中专业人员会遇到的问题
FAIL: 人为构造的谜题、玩具游戏或无现实对应的练习
Outcome Verified结果验证而非过程TOML
EN: Tasks must not be graded based on approach taken, only final solution. Cannot prescribe specific tools. Best instructions are brief with goal stated upfront.
中文: 不能基于所采取的方法评分，只评最终结果。不能限定工具。最好的指令简短，目标预先说明。
PASS: 测试验证最终结果，指令描述目标而非方法
FAIL: 测试强制特定工具、方法或逐步流程
Anti-Cheat Robustness防作弊鲁棒性TOML
EN: Tests must resist adversarial shortcuts: fake tool wrappers, monkey-patching, modifying test framework, reading solution files. Agents run as root with full access. Answers must not be in environment files or Docker layers.
中文: 测试必须抵抗对抗性快捷方式：伪造工具、猴子补丁、修改测试框架、读取答案文件。Agent 以 root 运行。答案不能嵌入环境文件或 Docker 镜像层。
PASS: 主动防止常见对抗性快捷方式
FAIL: 答案嵌入可访问文件，测试可被轻易绕过
Functional Verification功能性验证TOML
EN: Tests should verify behavior by executing code and checking outputs, not scanning source for keywords. Good: execute code, call APIs. Bad: grep function names, match regex patterns.
中文: 测试应通过执行代码和检查输出来验证行为，而非扫描源码关键词。好：执行代码、调用 API。差：搜索函数名、匹配正则。
PASS: 通过执行、API 调用或输出检查验证行为
FAIL: 主要依赖字符串匹配或源码模式检测
Deterministic & Reproducible确定性可复现TOML
EN: Consistent results across runs. Python/pip deps pinned; apt not pinned. No live service dependencies. Stochastic tasks: 100+ trial runs.
中文: 多次运行结果一致。Python/pip 依赖锁定；apt 不锁定。不能依赖在线服务。随机任务需 100+ 次验证。
PASS: 依赖锁定，无在线服务依赖，结果一致
FAIL: 依赖未锁定，依赖在线服务，或结果不一致
Essential Difficulty本质难度TOML
EN: Core difficulty from genuine reasoning, not formatting minutiae or arbitrary precision.
中文: 核心难度应来自真正推理，而非格式细节或任意精度要求。
PASS: 难度来自真正的技术挑战和逻辑推理
FAIL: 大多数失败来自格式边界、输出精度或文书细节
Test-Instruction Alignment测试-指令对齐TOML
EN: Clear 1:1 mapping between instruction and tests. Tests hand-written, readable, concise (~100 lines). Every assertion maps to a requirement and vice versa.
中文: 指令和测试间有清晰的 1:1 映射。测试手写、可读、简洁（约 100 行）。每个断言对应一个需求，反之亦然。
PASS: 指令需求和测试断言间有清晰 1:1 映射
FAIL: 测试检查未文档化行为，或需求未被测试
Novel新颖性TOML
EN: Not standard textbook exercises or well-known problems (FizzBuzz, sorting, sudoku). Best: novel skill combinations, domain-specific scenarios, custom codebases.
中文: 不能是标准教科书习题或知名问题。最好涉及技能新颖组合、领域特定场景或自定义代码库。
PASS: 需要真正推理，不能通过记忆走捷径
FAIL: 标准教科书习题或有广泛可用解的知名问题
AgenticAgent 特性TOML
EN: Requires genuine agentic capabilities: environment exploration, tool use, debugging, multi-step terminal interaction. Not solvable by a single LLM call.
中文: 需要真正的 Agent 能力：环境探索、工具使用、调试、多步终端交互。不能被单次 LLM 调用解决。
PASS: 需要多步环境交互
FAIL: 可通过零样本生成、简单回忆或单条命令解决
Reviewable可审查性TOML
EN: Non-specialist should be able to verify correctness. Specialized tasks need contributor explanation. Hardcoded expected values without derivation = red flag.
中文: 非专业审查者应能验证正确性。专业任务需提供解释。硬编码预期值无推导过程 = 警示信号。
PASS: 非专业审查者可验证任务正确性
FAIL: 需要领域专业知识审查且无解释
Instruction Clarity指令清晰度TOML
EN: Human-written, concise, clear. Must use absolute paths. No solution hints or step-by-step procedures. LLM-generated instructions = concern.
中文: 人工编写、简洁清晰。必须使用绝对路径。不暗示解法，不提供逐步流程。LLM 生成的指令应被标记。
PASS: 简洁、人工编写、使用绝对路径、描述目标
FAIL: 使用相对路径、暗示解法或疑似 LLM 生成
Solution Quality解答质量TOML
EN: Solution must not just echo/cat final answer. Must demonstrate actual computation process.
中文: 解答不能仅输出最终答案。必须展示真实计算过程。
PASS: 通过真实计算过程推导答案
FAIL: 直接打印/写入最终答案而无计算
Environment Hygiene环境卫生TOML
EN: Docker image: no tests/ or solution/ copied in. Test deps in test.sh, not image. Apt not pinned, preceded by update, followed by cleanup.
中文: Docker 镜像不含 tests/ 或 solution/。测试依赖在 test.sh 中安装。Apt 不锁版本，前置 update，后置清理。
PASS: 镜像干净，无测试/解答，测试依赖在 test.sh
FAIL: 镜像含测试/解答，或 apt 管理不当
Structured Data Schema结构化数据规格TOML
EN: If structured output expected, exact schema must be documented. Examples alone are not sufficient.
中文: 如果期望结构化输出，精确 schema 必须被文档化。仅有示例不够。
PASS: 结构化输出有精确 schema 文档
FAIL: 期望结构化输出但仅给示例无规范 schema
Typos拼写检查TOML
EN: Look closely for typos in filenames, paths, commands, variable names across all task files.
中文: 仔细检查所有任务文件中文件名、路径、命令和变量名的拼写错误。
PASS: 关键标识符无拼写错误
FAIL: 文件名、路径、命令或变量名存在拼写错误

四、对比分析

4.1 高度重叠的标准

以下标准在两份文档中语义基本一致，点击可展开查看两边原文对照

拼写检查 TB-QA: Typos TOML: typos 完全一致
两边内容几乎完全一致，都要求检查文件名、路径、命令、变量名中的拼写错误。TOML 额外列举了需要检查的文件范围（instruction.md, tests, solution, Dockerfile）。

TB-QA 原文：Whether there are any typos. Look very closely at file and variable names.
TOML 原文：Look closely for typos in filenames, paths, commands, and variable names across all task files.
结构化数据规格 TB-QA: Structured Data Schema TOML: structured_data_schema 基本一致
语义一致。TOML 额外强调"仅有示例不够，必须有规范性 schema"。

差异：TOML 增加了 N/A 选项（如果不期望结构化输出）。TB-QA 无此选项。
防作弊 TB-QA: Anti Cheating TOML: anti_cheat_robustness 高度相似
核心一致，但 TOML 更具体，列举了常见攻击向量：
  • 创建伪造工具封装 (fake tool wrappers)
  • 猴子补丁环境库 (monkey-patching)
  • 缓存预计算答案
  • 修改测试框架本身
  • Agent 以 root 运行、可访问 Docker 镜像层
TB-QA 更侧重"测试和解答对 Agent 不可见"这一前提。
解答质量/硬编码 TB-QA: Is Solution Hardcoded? TOML: solution_quality 一致
两边都要求解答通过真实计算推导答案，而非直接 echo/cat 最终结果。TB-QA 的描述更详细，明确说明 echo/cat 写源文件再执行是可接受的。
环境卫生/镜像 TB-QA: Tests in Image + Test Deps TOML: environment_hygiene TB-QA 拆为两条
TOML 合并为一条（environment_hygiene），涵盖：不复制 tests/solution 到镜像、测试依赖在 test.sh 安装、apt 管理规范。
TB-QA 拆为两条独立检查：Is Any Tests or Solution in Image? 和 Are All Test Dependencies Installed in Image?。
TOML 额外要求：apt-get update 前置 + rm -rf /var/lib/apt/lists/* 清理。
依赖锁定/可复现 TB-QA: Reproducibility + Pinned Deps TOML: deterministic_reproducible TB-QA 拆为两条
TB-QA 拆为 Reproducibility（整体可复现性）和 Pinned Dependencies（具体的版本锁定）。
TOML 合为一条，额外要求：不依赖在线服务、随机性任务需 100+ 次验证。
测试↔指令对齐 TB-QA: Behavior Match + Requirements Match TOML: well_specified + test_instruction_alignment 双向拆分
两边都关注"测试和指令要一致"，但拆分方式不同：
TB-QA：按方向拆 — 测试→指令 (Behavior Match) 和 指令→测试 (Requirements Match)
TOML：按属性拆 — 规格清晰 (well_specified) 和 对齐映射 (test_instruction_alignment)
TB-QA 的拆法更便于自动化（每条问一个方向的问题），TOML 的拆法更偏人工审查视角。
指令自主性 TB-QA: Instruction Autonomy Level TOML: outcome_verified + instruction_clarity TOML 拆得更细
TB-QA 用一条覆盖"指令不应过度规定"。TOML 拆为两条：outcome_verified（测试验证结果不验证过程）和 instruction_clarity（指令清晰、用绝对路径、人工编写）。
TOML 独特要求：必须使用绝对路径、LLM 生成的指令要被标记。

4.2 TOML 独有的标准（TB-QA 缺失）

这些标准面向 benchmark 任务设计哲学，是两份文档最关键的差异

Verifiable — 可验证性 TOML 独有

验证器必须确定性、可靠、高效。极端情况才可用 LLM-as-judge。
对 RL 的意义：这是 reward signal 可靠性的基石。验证器不可靠 = reward 信号有噪声 = 训练在拟合噪声。

Solvable — 可解性 TOML 独有

必须有可行解，专家几小时可实现。
对 RL 的意义：确保训练信号不是永远为 0 的稀疏奖励——如果任务不可解，模型永远得不到正向 reward。

Difficult — 足够困难 TOML 独有

需要 PhD 级别或多年专业经验，本科生几天能解决的太简单。
对 RL 的意义：控制难度下限。太简单的任务 pass rate 接近 100%，梯度消失，学不到东西。

Interesting — 有趣/实用 TOML 独有

必须有真实世界价值，有人会为此付费。
对 RL 的意义：确保训练出的能力可迁移到实际场景，而非只会做人造习题。

Functional Verification — 功能性验证 TOML 独有

测试通过执行代码验证行为，不靠字符串匹配。
对 RL 的意义：防 reward hacking——模型学会插关键词而非真正解决问题，是 RL 训练最严重的失效模式之一。

Essential Difficulty — 本质难度 TOML 独有

难度来自推理而非格式细节。
对 RL 的意义：确保 RL 训练的是推理能力，不是格式拟合。格式类失败 = reward 信号偏离真正的学习目标。

Novel — 新颖性 TOML 独有

不能是训练语料中可记忆的标准题。
对 RL 的意义：防止模型通过记忆获得奖励——RL 应训练推理能力，而非回忆能力。

Agentic — Agent 特性 TOML 独有

需要多步环境交互，不能被单次 LLM 调用解决。
对 RL 的意义：确保任务训练多步交互能力。单步可解的任务使 RL 退化为 SFT，无法训练规划和迭代能力。

Reviewable — 可审查性 TOML 独有

非专业审查者可验证正确性。
对 RL 的意义：降低任务审核成本，提高数据 pipeline 可扩展性。

4.3 TB-QA 独有的标准（TOML 缺失）

Validation Discriminability — 验证区分度 TB-QA 独有

测试是否覆盖边界情况、能否拒绝错误答案？
对 RL 的意义（关键）：如果测试只查表面特征，"错误的解也能得分"，reward signal 过于宽松，模型学到走捷径。这对 RL 是致命的。

Test Validation False Negative — 测试假阴性 TB-QA 独有

正确的解是否会因测试太脆弱而失败？
对 RL 的意义（关键）：对正确行为给惩罚 = 错误梯度方向，比没有训练信号更糟。

Informative Test Structure — 测试结构信息化 TB-QA 独有

测试脚本需有清晰注释和分节。
对 RL 的意义：偏工程规范，对训练本身影响较小。

Task Structure Completeness (P1) — 任务结构完整性 TB-QA 独有

文件夹结构符合 Harbor 格式。
对 RL 的意义：纯格式合规检查，可作为 CI/CD 自动检测项。

Task Realism (P1) — 任务真实性 TB-QA 独有

任务像真实工程工作流。与 TOML 的 "interesting" 部分重叠，但更侧重"工程感"。

Is File Reference Not Mentioned? — 文件引用遗漏 TB-QA 独有

被 TOML 的 test_instruction_alignment 部分隐含覆盖（"If the agent must produce specific files, those filenames must be explicitly stated"）。

Is It Possible to Complete Without Internet? — 离线可完成性 TB-QA 独有

TOML 的 deterministic_reproducible 隐含"不依赖在线服务"，但 TB-QA 更具体地检查离线场景。

4.4 核心差异总结

维度TB-QATOML
设计视角自下而上：文件有没有问题自上而下：什么是好的 benchmark 任务
关注层面偏实现质量偏任务设计
粒度更细，可直接自动化 yes/no 检测更粗，每条需理解和判断
自动化适配明确为 LLM 自动评分设计为人工评审设计
难度/新颖性缺失difficult + novel + agentic + essential_difficulty
Reward 质量Discriminability + False Negativeverifiable + functional_verification

五、LLM RL 训练适用性分析

结论：以 TOML 为骨架 + 补充 TB-QA 两条关键项

TOML 的优势（对 RL 至关重要）：

TB-QA 中对 RL 关键但 TOML 缺失的标准：

TB-QA 中可降级为 CI/CD 自动检查的标准：

六、综合 Rubric（推荐方案）

基于以上分析，推荐以下 22 条综合标准。每条注明来源、优先级和纳入原因。

优先级：Critical 对 RL 训练有直接影响 High 影响任务/数据质量 Medium 工程规范 Low 可选

1. Verifiable / 可验证性Critical来自 TOML
验证器必须确定性、可靠、高效。极少数情况可用 LLM-as-judge 但需论证。
纳入原因：RL 训练的基石——reward function 的可靠性直接决定训练质量。不可靠的 reward = 拟合噪声。
2. Validation Discriminability / 验证区分度Critical来自 TB-QA
测试必须覆盖边界情况，能拒绝错误答案。不能只查表面特征。
纳入原因：reward signal 的区分度。测试太松 = 假阳性泛滥 = 模型学会走捷径而非真正解决问题。
3. Test Validation False Negative / 测试假阴性控制Critical来自 TB-QA
正确的解不应因测试太脆弱而失败。
纳入原因：假阴性 = 对正确行为给惩罚 = 产生错误梯度方向。比没有训练信号更有害。
4. Functional Verification / 功能性验证Critical来自 TOML
测试通过执行代码验证行为，不靠字符串匹配。
纳入原因：防 reward hacking。模型可轻松插入关键词而不实现功能，字符串匹配式测试完全无法防御。
5. Novel / 新颖性Critical来自 TOML
不能是训练语料中可直接记忆的标准题。
纳入原因：防止模型通过记忆获得 reward。RL 应训练推理能力而非回忆能力，否则 RL 阶段的能力提升是虚假的。
6. Agentic / Agent 特性Critical来自 TOML
需要多步环境交互，不能被单次 LLM 调用解决。
纳入原因：确保训练的是 Agent 核心能力（规划、探索、迭代、纠错）。单步可解任务使 RL 退化为 SFT。
7. Essential Difficulty / 本质难度Critical来自 TOML
难度来自真正推理，不来自格式细节或任意精度。
纳入原因：确保 RL 梯度指向推理能力而非格式拟合。格式类失败 = reward 信号偏离真正学习目标。
8. Difficult / 足够困难High来自 TOML
需要专业经验或多年领域知识。
纳入原因：太简单的任务 pass rate 接近 100%，RL 梯度消失，无有效学习信号。
9. Solvable / 可解性High来自 TOML
必须有可行解，专家几小时可实现。
纳入原因：不可解的任务 = reward 永远为 0 = 稀疏奖励问题导致训练无法收敛。
10. Anti-Cheat Robustness / 防作弊鲁棒性HighTB-QA + TOML
合并两边内容。测试抵抗对抗性快捷方式，答案不泄露在环境中。
纳入原因：RL 训练中模型可能发现并利用 reward function 漏洞，形成"reward hacking"循环。
11. Well Specified / 规格清晰HighTB-QA: Behavior Match + TOML: well_specified
指令完整描述测试验证的所有行为，无歧义。合并 TB-QA 的"测试→指令"方向检查。
纳入原因：指令模糊 = 模型在探索中浪费大量步数在猜测需求上，降低训练效率。
12. Test-Instruction Alignment / 测试-指令对齐HighTB-QA: Requirements Match + TOML: test_instruction_alignment
指令需求和测试断言间 1:1 映射。合并 TB-QA 的"指令→测试"方向检查。
纳入原因：未被测试覆盖的需求 = 该维度无 reward 信号 = 模型无法学习该能力。
13. Outcome Verified / 结果验证而非过程HighTB-QA: Autonomy + TOML: outcome_verified
验证最终结果不验证过程。指令描述目标而非步骤。
纳入原因：RL 应鼓励模型探索多种解法。过程约束会限制探索空间，降低 RL 效果。
14. Deterministic & Reproducible / 确定性可复现HighTB-QA: Reproducibility + Pinned Deps + TOML: deterministic_reproducible
依赖锁定、不依赖在线服务、结果一致。合并两边。
纳入原因：RL 训练需要可重复的环境。不同 run 结果不同 = reward 信号包含无关噪声。
15. Interesting / 有趣实用High来自 TOML + TB-QA: Task Realism
有真实世界应用价值，像真实工程工作流。
纳入原因：确保训练出的能力可迁移到实际任务，而非只能解人造习题。
16. Instruction Clarity / 指令清晰度High来自 TOML
人工编写、简洁、使用绝对路径、不暗示解法。LLM 生成的指令需标记。
纳入原因：清晰的指令确保模型学到的是"理解目标→探索解法"，而非"解码模糊指令"。
17. Solution Quality / 解答质量HighTB-QA + TOML
解答通过真实计算推导，不硬编码最终结果。
纳入原因：确保 oracle solution 可作为 RL 训练的参考 trajectory 或验证 baseline。
18. Environment Hygiene / 环境卫生MediumTB-QA + TOML
Docker 镜像不含 tests/solution，测试依赖在 test.sh 安装，apt 管理规范。
纳入原因：环境卫生确保训练环境和评估环境的一致性，防止信息泄露。
19. Structured Data Schema / 结构化数据规格MediumTB-QA + TOML
结构化输出有精确 schema 文档，不仅给示例。
纳入原因：配合 essential_difficulty——输出格式歧义不应成为失败的主要原因。
20. Reviewable / 可审查性Medium来自 TOML
非专业审查者可验证任务正确性，或有充分解释。
纳入原因：提高数据 pipeline 可扩展性，降低审核成本，支撑大规模数据生产。
21. Typos / 拼写检查MediumTB-QA + TOML
所有文件中文件名、路径、命令、变量名无拼写错误。
纳入原因：拼写错误可导致静默失败，浪费 Agent 的训练步数在错误的方向上。
22. Offline Completability / 离线可完成性Low来自 TB-QA
禁用网络的任务需确保所有资源在镜像中可用。
纳入原因：大部分被 deterministic_reproducible 覆盖，但作为独立检查项可捕获特定场景。可降级为 CI/CD 自动检查。

降级为 CI/CD 自动检查（不纳入核心 Rubric）