메뉴
询问 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 要做到：