القائمة
询问 SPONGE benchmark 新建 或 调整 时 使用 - comparison validation performance 分类 - benchmark 目录 组织 - benchmark 测试 编写 - utils 复用 - pixi task 接入
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
询问 SPONGE 构建、编译、环境配置、构建排错时使用。 适用于 pixi 环境选择、CMake 配置、多后端编译、格式化、打包。
询问 SPONGE 代码风格、命名规范、格式化工具时使用。 适用于 C++、Python、CMake 的编码规范和格式化流程。
询问 SPONGE 输入文件（mdin.spg.toml）的参数配置时使用。 适用于模拟参数设置、模块配置、输入输出文件指定等。
询问 pixi 用法时使用。 适用于环境管理、依赖安装、任务运行、shell 交互、清理环境等。
询问为 SPONGE 安装、链接、修复或检查 skills 时使用。 适用于 AI 助手的本地或全局 skills 配置。
询问使用 SPONGE 的 PRIPS 对接机器学习/神经网络势场时使用。 适用于 Python plugin 编写、环境准备、力回填。
| name | sponge-benchmark-creator |
| description | 询问 SPONGE benchmark 新建 或 调整 时 使用 - comparison validation performance 分类 - benchmark 目录 组织 - benchmark 测试 编写 - utils 复用 - pixi task 接入 |
本技能适配 SPONGE 版本号：2.0.0-beta.1
用于新建或调整 benchmarks/ 下的测试时，目标是让 benchmark 分类清楚、结构统一、可复用、可维护。
comparison
用于和外部程序对比结果，例如 AMBER、GROMACS、LAMMPS、PySCF。validation
用于验证 SPONGE 自身功能正确性、物理合理性、回归稳定性。performance
用于验证长程稳定性、采样能力、复杂流程，或者真正的性能表现。时间尺度也要匹配分类：
validation 应尽量短，适合开发时频繁跑。performance 可以长，适合专项验证。performance，不要硬塞进 validation。benchmarks/<category>/<suite>/tests/benchmarks/<category>/<suite>/statics/<case_name>/reference/ 子目录outputs/statics/优先把“同一类能力”的 case 放进已有 suite。
统一优先使用：
benchmarks/utils.py] 中的 Outputer.prepare_output_casebenchmarks/utils.py] 中的 Runner.run_spongebenchmarks/utils.py] 中的 Extractorbenchmarks/validation/utils.py] 中已有的 validation 公共解析避免重复造轮子：
utils.py 里再包一层通用 run_spongemdout 解析suite 下的 tests/utils.py 只应放该 suite 专属逻辑，例如：
mdin 生成新增 benchmark 默认用 pytest。若需兼容常见中文编码环境，优先使用 python -X utf8 -m pytest 的调用方式。
优先复用已有 fixture：
statics_pathoutputs_pathmpi_np常见骨架：
case_dir = Outputer.prepare_output_case(
statics_path=statics_path,
outputs_path=outputs_path,
case_name=case_name,
mpi_np=mpi_np,
run_name=run_name,
)
Runner.run_sponge(case_dir, timeout=timeout, mpi_np=mpi_np)
不要只验证“程序能跑完”，要验证有意义的指标。
comparison
应比较 energy、force、pressure、stress 等，并给出明确容差。
如果是单点能/单点力测试，不要打开 constrain 或 settle/shake 一类约束；这类测试应比较未约束体系的原始势能与力。validation
应验证功能行为，例如约束、生效范围、统计分布、边界条件、插件 hook。performance
应验证功能行为，例如能量漂移、覆盖度、采样结果、长时间稳定性等。阈值要显式写出，不要埋魔法数字。具体验证指标需要合适，不一定局限于上述列举指标。
涉及时间序列统计（如 density、temperature、pressure）时，默认排除 step = 0 的初始化帧，除非测试目标就是验证初始化输出。
step = 0 常包含初始化路径或未充分平衡状态，直接纳入均值/区间断言会引入偏差。step 列，再按 step != 0 过滤后做统计断言。step = 0，在测试代码里显式说明原因，不要隐式依赖。测试结束前尽量用 Outputer.print_table(...) 输出摘要，至少包含：
PASS / FAIL保证失败时能快速定位问题。
test_<behavior>case_name、目录名、run_name 保持一致或可追踪新增或调整 benchmark 后，至少检查以下内容：
pixi.toml 中的 taskstep = 0新增 benchmark 要做到：