research-refine-pipeline

研究方法细化流程：端到端方法与实验规划

每次评审前，请遵循 可选评审者： 通过规范的辅助解析器解析调用 → .aris/reviewer.json → Claude Code 默认设置（Codex MCP）， 并通过 reviewer_route.py 保留此轮的级别、新上下文、源文件／图像输入和确定性门控。 下方的 Codex 示例／固定配置仅适用于 backend=codex；其他路由使用各自的首次调用／回复约定。保存路由和实际返回的身份； 无法使用的选项标记为 REVIEW_UNAVAILABLE。根据实际的类别／完成状态／范围判定是否接受。 将调用中的评审者／模型／effort 覆盖参数传递给包含评审者的子流程。生成工作进程不变。

细化并具体化：$ARGUMENTS

概述

当用户不希望止步于细化方法时，使用此技能。目标是产出一套连贯的材料，包括：

• 以问题为锚点、简洁优雅的最终方案
• 解释方法为何聚焦的评审历史
• 与论文主张相对应的详细实验路线图
• 简明的流程摘要，说明接下来要运行什么

此技能组合了两个现有工作流：

1. research-refine：细化方法
2. experiment-plan：基于主张制定验证计划

仅在需要时阅读以下同级技能，了解各阶段的具体细节：

• ../research-refine/SKILL.md
• ../experiment-plan/SKILL.md

核心规则

不要在尚不稳定的方法上规划大规模实验套件。先稳定论文主张，再将稳定的主张转化为实验。

默认输出

• refine-logs/FINAL_PROPOSAL.md
• refine-logs/REVIEW_SUMMARY.md
• refine-logs/REFINEMENT_REPORT.md
• refine-logs/EXPERIMENT_PLAN.md
• refine-logs/EXPERIMENT_TRACKER.md
• refine-logs/PIPELINE_SUMMARY.md

工作流

阶段 0：评估起点

• 提取问题、初步方案、约束、资源和目标投稿场所。
• 检查 refine-logs/FINAL_PROPOSAL.md 是否已存在，以及是否仍符合当前请求。
• 如果方案缺失、已过时，或与当前请求存在实质差异，则运行完整的 research-refine 阶段。
• 如果方案已经完善且与当前请求一致，则复用方案并直接进入实验规划。
• 如有疑问，优先重新运行 research-refine，而不是为错误的方法规划实验。

阶段 1：方法细化

运行 research-refine 工作流，并保持其 V3 理念不变：

• 保留问题锚点
• 优先采用足够满足需求的最小机制
• 保持一个主导贡献
• 仅在有助于论文时进行现代化改进

仅当以下内容均已明确时，才结束此阶段：

• 最终方法主张
• 主导贡献
• 有意舍弃的复杂性
• 关键主张和必须运行的消融实验
• 尚存风险（如有）

如果结论仍为 REVISE，只有在剩余弱点已清楚记录的情况下，才继续进行实验规划。

阶段 2：规划门控

进入实验阶段前，简要完成门控检查：

• 最终方法主张是什么？
• 主导贡献是什么？
• 有意舍弃了哪些复杂性？
• 哪些评审者的顾虑仍需通过验证来解决？
• 前沿基础组件是核心、可选，还是不存在？

如果这些问题的答案不够明确，应先完善最终方案。

阶段 3：实验规划

基于以下材料运行 experiment-plan 工作流：

• refine-logs/FINAL_PROPOSAL.md
• refine-logs/REVIEW_SUMMARY.md
• refine-logs/REFINEMENT_REPORT.md

确保实验计划涵盖：

• 主要锚点结果
• 新颖性隔离
• 简化或删除检查
• 前沿必要性检查（如适用）
• 运行顺序、预算和决策门控

阶段 4：整合摘要

编写 refine-logs/PIPELINE_SUMMARY.md：

# Pipeline Summary

**Problem**: [problem]
**Final Method Thesis**: [one sentence]
**Final Verdict**: [READY / REVISE / RETHINK]
**Date**: [today]

## Final Deliverables
- Proposal: `refine-logs/FINAL_PROPOSAL.md`
- Review summary: `refine-logs/REVIEW_SUMMARY.md`
- Experiment plan: `refine-logs/EXPERIMENT_PLAN.md`
- Experiment tracker: `refine-logs/EXPERIMENT_TRACKER.md`

## Contribution Snapshot
- Dominant contribution:
- Optional supporting contribution:
- Explicitly rejected complexity:

## Must-Prove Claims
- [Claim 1]
- [Claim 2]

## First Runs to Launch
1. [Run]
2. [Run]
3. [Run]

## Main Risks
- [Risk]:
- [Mitigation]:

## Next Action
- Proceed to `/run-experiment`

阶段 5：向用户提供简要摘要

Pipeline complete.

Method output:
- refine-logs/FINAL_PROPOSAL.md

Experiment output:
- refine-logs/EXPERIMENT_PLAN.md
- refine-logs/EXPERIMENT_TRACKER.md

Pipeline summary:
- refine-logs/PIPELINE_SUMMARY.md

Best next step:
- /run-experiment

输出协议

所有输出文件均遵循以下共享协议：

• 输出版本控制协议 — 先写入带时间戳的文件，再复制到固定名称的文件
• 输出清单协议 — 将每个输出记录到 MANIFEST.md
• 输出语言协议 — 遵循项目的语言设置

关键规则

• 大文件处理：如果 Write 工具因文件过大而失败，请立即改用 Bash（cat << 'EOF' > file）分块写入。不要征求用户许可——直接静默执行。

• 不要让实验计划覆盖问题锚点。

• 除非确实缺少必要的验证环节，否则在方法优化后不要扩大论文叙述范围。

• 在 FINAL_PROPOSAL.md、EXPERIMENT_PLAN.md 和 PIPELINE_SUMMARY.md 中保持相同的论点。

• 论文的核心叙述要简洁。

• 如果方法刻意设计得简单，应在实验计划中说明为何保持简单，而不是添加新组件。

• 如果方法使用现代 LLM / VLM / Diffusion / RL 基元，应明确测试其必要性。

• 如果方法不需要前沿基元，应明确说明，并避免强行加入。

• 如果用户只需要一个阶段，优先使用分阶段技能；若需要完整流程，则使用此技能。

与其他技能配合使用

/research-refine-pipeline -> one-shot method + experiment planning
/research-refine   -> method refinement only
/experiment-plan   -> experiment planning only
/run-experiment    -> execution