algorithm-design-planner

用途

Algorithm Design Planner 用于把一个经过验证的机器学习/人工智能研究想法，转换为具体、可实现、可消融、可评估且便于在论文中解释的方法设计。

适用场景包括：

想法已通过早期验证，需要一个真正的算法；
方法、损失、架构、推理流程或训练配方尚不明确；
用户在编码前需要一份方法设计文档；
项目需要明确假设、失败模式、消融实验与实现边界；
早期结果提示应修改算法，而非仅重跑实验；
论文方法章节难以撰写，因为方法本身不够精确。

该技能不用于启动实验。当设计足够具体、可测试后，应搭配 experiment-design-planner 使用。

配套技能

当设计改变主张、假设、风险、行动或工作树用途时，搭配 research-project-memory；
若想法本身可能不值得推进，在其之前使用 research-idea-validator；
当最接近的已有方法不清晰时，搭配 literature-review-sprint；
当方法已产生可测试假设与消融方案后，搭配 experiment-design-planner；
仅在实现与实验设计就绪后使用 run-experiment；
把最终设计转化为论文文字时，搭配 conference-writing-adapter。

技能目录结构

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── ablation-implications.md
    ├── design-rubric.md
    ├── failure-mode-map.md
    ├── implementation-handoff.md
    ├── method-spec-template.md
    └── paper-method-bridge.md

渐进式加载

始终阅读 references/design-rubric.md 与 references/method-spec-template.md。

当假设、边界情况或负面结果重要时，阅读 references/failure-mode-map.md。

当方法包含组件、损失、目标、调度、架构或推理改动时，阅读 references/ablation-implications.md。

在产出编码任务或工作树计划前，阅读 references/implementation-handoff.md。

当设计需要转化为论文方法章节时，阅读 references/paper-method-bridge.md。

若新颖性依赖当前方法或基线，用网络搜索或用户提供的论文进行核实。

核心原则

先设计机制，再设计实验。
分离问题、方法、主张与证据计划。
用能检验核心想法的最小方法。
明确陈述假设与不变量。
识别相对于最近基线的真正新意。
每个方法组件都应有理由、消融与失败模式。
避免加入无法证明合理、无法公平调参或无法向审稿人解释的旋钮。
产出一份实现交接文档，防止编码阶段隐藏的设计决策被私自做出。

步骤 1 - 恢复上下文

收集：已验证的想法或项目方向；research-idea-validator 的当前结论（如有）；目标论文主张；目标模型/任务/领域；最近的基线或先前方法；可用代码库与实现约束；已知实验或负面结果；项目记忆 ID（如 CLM-###、RSK-### 或 ACT-###，如有）。

若想法仍然模糊，将其改写为：

对于[问题/设定]，通过[机制]修改[基线]，使[期望属性]因[假设]而改善。

若无法写出这句话，则回退到 research-idea-validator 或 literature-review-sprint。

步骤 2 - 选择设计模式

对设计进行分类：

method：新算法、训练配方或推理流程；
objective：新损失、正则化、约束、奖励或优化准则；
architecture：新模块、表示、层、路由、记忆或参数化；
theory：由假设、定理、界或原理推导的形式化方法；
system：流水线、基础设施、调度、检索、数据或工具设计；
revision：负面或模糊结果后的方法更新。

使用一个主模式，可选若干次模式。

步骤 3 - 构建方法规格

阅读 references/design-rubric.md 与 references/method-spec-template.md。

定义：问题表述；输入与输出；被修改的基线；核心机制；训练目标或损失（如有）；推理或采样流程（如有）；架构或模块改动（如有）；假设与不变量；超参数与调度；计算成本；期望行为；相对基线保持不变的部分。

酌情使用数学、伪代码或结构化条目。不要把重要设计决策藏在散文里。

步骤 4 - 检查新颖性与最小性

自问：与最近基线的不可约差异是什么？哪部分是主张所必需的？哪部分是便利、工程或调参？首个实现能否测试更小版本？审稿人是否可能称其为微小改动？

若新想法依赖多项改动，则把核心设计与可选扩展分开。

步骤 5 - 映射失败模式

阅读 references/failure-mode-map.md。列出：可能为假的假设；方法应失败的数据或任务区间；优化或稳定性风险；指标不匹配风险；计算风险；可解释收益的混淆因素；提示应修改、搁置或终止设计的信号。

负面结果应映射到决策，而非模糊的担忧。

步骤 6 - 推导消融与诊断

阅读 references/ablation-implications.md。对每个方法组件定义：其存在原因；移除后会发生什么；检验其机制的诊断方法；必须扫描的超参数或调度；能区分机制与调参/算力的基线或对照。

该输出应直接输入 experiment-design-planner。

步骤 7 - 准备实现交接

阅读 references/implementation-handoff.md。产出：可能改动的文件/模块；公共接口或配置名；最小原型计划；单元/冒烟测试；日志需求；工作树或分支用途；退出条件（合并、继续、搁置或终止）；编码阶段不应私自决定的风险。

若不存在代码库，则定义最小脚手架或原型边界，而非完整工程计划。

步骤 8 - 桥接论文方法章节

在有用时阅读 references/paper-method-bridge.md。产出：方法名称（如需）；方法章节提纲；算法框内容；所需公式或定义；应陈述的假设；向审稿人解释机制为何有效；在证据出现前应避免的主张。

步骤 9 - 撰写设计文档

若保存到项目且未给出路径，使用：

docs/designs/algorithm_design_YYYY-MM-DD_<short-name>.md

使用如下结构：

# Algorithm Design: [Name]

## Design Context
## Target Claim
## Design Decision
## Problem Formulation
## Method Specification
## Assumptions and Invariants
## Relation to Baseline and Prior Work
## Failure Modes
## Ablations and Diagnostics
## Implementation Handoff
## Experiment Handoff
## Paper Method Bridge
## Project Memory Writeback

步骤 10 - 写回项目记忆

若项目使用 research-project-memory，则更新：

memory/decision-log.md：持久的设计选择及原因；
memory/claim-board.md：已计划、修改、弱化或删除的方法主张；
memory/risk-board.md：机制、实现、基线、调参、算力与评估风险；
memory/action-board.md：实现、消融、诊断、文献或实验设计行动；
memory/evidence-board.md：在足够具体时记录计划的诊断或实验家族；
worktree .agent/worktree-status.md：实现分支的用途、关联主张、关联实验与退出条件。

在证据被观测前使用 planned，失败模式使用 inferred。

最终检查

定稿前确认：问题、基线与方法明确；核心机制可与可选工程区分；假设与不变量已陈述；每个新组件都有消融或诊断；实现交接足够具体可编码；实验交接足够具体可供 experiment-design-planner 使用；论文方法桥接不超出计划证据地过度主张；存在项目记忆时已更新。