spike-design：实现前的方案审核

目的：在写代码前把方案摊开给用户审核，防止过度设计和跑偏。本 skill 只产出方案，不修改文件。

步骤

1. 澄清目标与边界
   • 已有需求或设计文档时（无论来自哪个工具或谁写的），先读它：其中已有的目标、非目标、约束直接采用并注明出处（文件:行号）；本步只就缺口提问，不重复已回答的问题；文档与代码或现状冲突的，列入“需要你决定的问题”，不自行改写。
   • 写清：要解决的问题、验收标准、非目标（明确不做什么）。
   • 先判断任务类型：是设计新东西，还是接入已有系统。接入类任务里，外部系统（第三方服务、其他团队的仓库、已部署的平台）的能力和接口视为固定约束：
     • 默认非目标：修改外部系统的代码或部署。确需修改时单列为“外部依赖缺口”，由用户决定，不写进推荐方案。
     • 不重新设计外部系统已经定好的架构，只回答“怎么用它现有的接口把本仓库接起来”。
   • 某类数据或判定由外部系统或其他位置作为真源时，方案必须写明：本仓库只消费结果，不在本地另建副本或默认值。这一条写进“约束”，供后续偏离检查对照。
   • 用户已经给出方向时，不再从零提出备选方案，改为评估用户的方案（见第 4 步）。
2. 约束清单（先于方案） 列出会决定方案形态的约束；代码和文档查不到的，作为问题问用户，不自行假定：
   • 调用频率：热路径上能否每次请求都调用外部服务。
   • 时效：权限、配置、数据变更允许多久后生效；外部系统能否主动推送，还是只能拉取。
   • 谁能改什么：哪些系统可以改，哪些只能配置，哪些完全不能动。
   • 运行环境：语言或框架版本、网络连通方向（对方能否回调我方）。
3. 复用检查（先于设计）
   • 本仓库：搜索同类实现，优先沿用已有模式、模块和数据结构。
   • 外部系统：列出要用到的现有接口、调用身份和返回内容，标明每条结论的来源。
   • 列出“可复用的现有代码/能力”和“必须新增的代码”。
   • 可选：设计新东西时，询问用户是否调研业内成熟实现或标准做法（开源项目、官方文档、规范）。用户同意才执行，结论标明来源；用户不需要就跳过。
4. 方案
   • 用户没给方向：给出 2–3 个方案，每个写思路、涉及模块、主要风险，推荐一个并说明理由。
   • 用户已给方向：只评估该方案，指出必须修正的点和原因，不另起炉灶。
   • 方案越简单越好，不推荐“以后可能用到”的设计。
   • 结构骨架：用骨架表达推荐方案的结构，作为实现和审查时对照的依据。
     • 新增的模块或文件：位置和一句话职责。
     • 核心类型（跨模块传递或承载核心数据的）：关键字段；核心接口：签名。其余类型不写。
     • 骨架中每个新增抽象都必须出现在抽象与依赖预算表中。
   • 关键流程：只写重难点（事务、并发、外部调用、复杂状态流转等），最多 3–5 处，普通流程不写。每处写：
     • 输入：来源和形态。
     • 关键步骤：每一步的状态变化，以及失败时数据和流程停在哪里。
     • 输出：结果去向。

5. 抽象与依赖预算（强制）

   • 抽象：对推荐方案中每一个新增的接口、抽象类、基类、注册表、配置项、缓存、定时任务、通用层，逐条列出：
     • 名称与位置
     • 当前实现数量（只有一个实现的接口默认打回，除非有明确理由）
     • 为什么现在就需要（不接受“以后可能”）
     • 不加它的替代写法
   • 依赖：对每一个新引入的第三方库、基础组件（缓存、消息队列、新服务、中间件等）和工具，逐条列出：
     • 名称与版本
     • 用途
     • 为什么项目现有依赖或原生能力不能满足
     • 引入成本：维护、许可、运行资源、部署变化

   没有理由的抽象和依赖直接删除。预算默认为 0。

6. 项目约束检查
   • 读取项目说明文件（如 CLAUDE.md、AGENTS.md、CONTRIBUTING.md、README），逐条核对其中的架构、模块边界、接口、数据与迁移约定；方案违反的写明条款位置。
   • 失败了会怎样：只提出问题，降级、中断或重试由用户决定。
   • 在什么规模下会出问题。
   • 数据与流程是否闭环：会不会留下游离数据，流程能否结束。
   • 不顺手重构与本次任务无关的模块。
7. 切片计划
   • 把实现拆成可独立审查的切片，每片预计不超过约 300 行改动，并标注切片之间的依赖。
   • 每片写明完成标准（可验证的行为或测试）。
   • 每片列出决策条目并编号（如 S1-1、S1-2）。只写决策，不写实现细节：数据和判定的来源、对应的骨架部分、对外接口和契约、数据模型、外部调用、用户可感知的行为和分支、失败处理策略（降级、重试或中断）、新增的配置和依赖、范围边界。实现和审查都按这些编号对照。
   • 需要先在真实环境核验的前提，放进最前面的核验切片，不写代码。

8. 输出并停止 输出前自检矛盾：方案内部、方案与项目文档、方案与用户已提出的要求之间有冲突的，列入“需要你决定的问题”，不自行取舍。

   按下面的结构输出，然后等待用户确认：

   ## 目标与验收
   ## 非目标（明确不做）
   ## 约束（已确认 / 待你确认）
   ## 可复用的现有代码与外部能力
   ## 方案（对比或对用户方案的评估）
   ## 结构骨架
   ## 关键流程
   ## 抽象与依赖预算表
   ## 切片计划
   ## 需要你决定的问题

   • 关于外部系统行为的每条结论标注来源：已实测、读代码（附文件:行号）、推断。“推断”不能作为方案前提，要么核验，要么列为待确认。
   • 用户确认前，不进入编码。

实现时（方案确认后）

• 实现某个决策条目所需的机械代码（组装、字段、转换、日志、针对方案内行为的测试等）可以直接写，不需要逐条写进方案。
• 代码一旦引入方案没有的决策，就是自行发挥，不允许直接写：新的业务规则、新的数据来源或本地副本、预算外的抽象或依赖、新的配置、范围变化、自定的失败处理策略。遇到这类情况先停下，按“修改方案时”的规则补进方案并经用户确认，再写代码。
• 每个切片完成时，按决策条目列出对应的实现位置；没有实现的条目单独列出。
• 某个切片的结构明显偏离骨架时，不在偏离的代码上继续打补丁。先查原因（方案不清、约束冲突或骨架有误），修正方案后重做该切片；已写的代码是否丢弃由用户决定。

修改方案时

• 只更新方案，不写代码。
• 开头先列“与上一版的差异”（新增、删除、推翻了哪条结论及原因），再给完整方案。
• 每一版都保留结构骨架、关键流程、抽象与依赖预算表和切片计划，不因修改而丢掉。
• 同一结论被用户纠正两次以上时，停下来复述你对约束的理解并请用户确认，再继续出方案。