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-###（如有）

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

For [problem/setting], modify [baseline] by [mechanism] so that [expected property] improves because [assumption].

如果无法写出这句话，请返回 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：具体到足以规划的诊断或实验系列
• 工作树 .agent/worktree-status.md：实现分支的用途、关联主张、关联实验和退出条件

对于证据使用 planned，对于失败模式使用 inferred，直到观察到相应结果为止。

最终检查

定稿前，请确认：

• 问题、基线和方法均已明确
• 核心机制与可选工程实现可区分
• 假设和不变量均已说明
• 每个新增组件都有对应的消融实验或诊断
• 实现交接足够具体，可供编码
• 实验交接足够具体，可供 experiment-design-planner 使用
• 论文方法章节衔接不会超出计划证据所能支持的范围
• 存在项目记忆时已完成更新