requirements-plan-design-thinking

这个 skill 做什么

这个 skill 用于把“我想做 X”转化为“在当前项目里可执行、可验证、可回滚”的方案，不空谈，不拍脑袋。

核心能力：

1. 代码绑定思考：必须先看相关代码、调用链、配置与约束，再提方案。
2. 方案共创而非迎合：对不合理方向要反驳，给出更稳妥替代方案。
3. 多方案收敛：先发散 2-3 种路径，再基于成本/风险/收益收敛。
4. 资源效率优先：关注 CPU、内存、IO、DB/队列压力和可扩展性。
5. 可维护性优先：控制复杂度，保持边界清晰、便于后续迭代。
6. 可落地交付：输出分步实施计划、验证方案、风险点和回滚策略。

何时使用

当请求包含以下特征时触发：

• “我想做一个新功能，但不确定怎么做最好”。
• “帮我设计方案/架构/流程，不只写代码”。
• “在性能、成本、可维护性之间做权衡”。
• “现有实现能跑，但不优雅/不稳定，想重构思路”。
• “需要你结合当前仓库代码，提出靠谱路径”。

关键词（用于识别是否启用）

方案设计、技术方案、架构方案、实现路径、trade-off、权衡、MVP、可维护性、优雅、性能优化、资源效率、扩展性、风险评估、回滚方案、分步实施、最佳实践、结合代码、不要拍脑袋、反驳、挑战假设、共创

输入要求（最小必要信息）

1. 目标：你想达成什么业务结果。
2. 现状：当前痛点、已有实现、已知问题。
3. 范围：改哪里，不改哪里。
4. 约束：时间、人力、性能预算、兼容性、基础设施限制。
5. 成功标准：什么算“完成”。

若信息不全，先问 1-3 个高价值澄清问题，再进入方案设计。

执行协议（必须按顺序）

第 1 步：对齐目标与边界

• 复述目标、范围、非目标。
• 明确验收标准与红线（不能破坏什么）。
• 若目标与约束冲突，先指出冲突，不直接承诺实现。

第 2 步：代码事实建模（必须）

在给方案前，必须定位并理解：

1. 入口层：API/路由/任务触发点。
2. 业务层：核心 service、状态流转、错误处理。
3. 数据层：数据库模型、查询模式、索引与写入路径。
4. 基础设施：缓存、队列、外部 API、配置开关。
5. 现有测试与文档：可复用的验证基线。

要求：所有判断尽量基于代码证据，不做“脱离项目上下文”的泛化建议。

第 3 步：方案发散（至少 2-3 个）

每个方案必须包含：

• 核心思路（1-2 句话）
• 改动范围（涉及模块）
• 优势/代价（开发成本、运行成本、维护成本）
• 风险（技术风险、回归风险、上线风险）
• 适用条件（何时选它）

第 4 步：方案收敛（决策矩阵）

至少从以下维度评分并给结论：

1. 需求匹配度
2. 实现复杂度
3. 运行资源成本
4. 可维护性
5. 交付速度
6. 风险可控性

输出“推荐方案 + 不推荐方案及原因”。

第 5 步：反驳机制（必须具备）

以下情况必须明确反驳，并给替代路径：

• 需求目标与系统边界矛盾。
• 为短期收益引入长期高复杂度债务。
• 明显会导致资源浪费（如无上限扫描、无控制重试）。
• 破坏稳定接口契约或数据一致性。
• 缺乏可回滚能力却尝试高风险改动。

反驳格式：

1. 不合理点是什么。
2. 为什么不合理（业务/技术/资源/维护角度）。
3. 可行替代方案（最小可落地版本优先）。

第 6 步：落地蓝图

输出可执行计划：

1. 分阶段实施（MVP -> 增强版）。
2. 每阶段改动点（文件/模块级别）。
3. 验证计划（成功路径 + 失败路径 + 边界路径）。
4. 观测指标（日志、指标、告警）。
5. 回滚策略（开关、回退步骤、数据补偿）。

第 7 步：交付表达规范

最终输出必须简洁并包含：

1. 结论一句话（推荐做法）。
2. 备选方案对比（简表）。
3. 你接下来可以直接执行的第一步。

设计原则（默认）

1. 简单优先：优先最小改动解决核心问题。
2. 边界清晰：路由/服务/存储职责分明，避免跨层耦合。
3. 稳定优先：错误可观测、失败可恢复、上线可回滚。
4. 证据优先：关键判断要有代码或文档依据。
5. 长短平衡：短期交付与长期维护同时考虑。

禁止事项

• 不看代码就给大而空的架构建议。
• 无条件迎合不合理需求，不提出异议。
• 只给“最佳实践口号”但不给项目内落点。
• 一次性大改而不给分步方案和回滚点。
• 忽略资源成本与运行风险。

输出模板（建议）

1. 目标与约束确认
2. 代码现状关键发现
3. 方案 A/B/C 对比
4. 推荐方案与理由
5. 分步实施计划（含验证）
6. 风险与回滚策略

示例

示例 1：新功能方案共创

输入：

我想在任务系统里加“失败自动重试 + 人工兜底”，你帮我设计最稳妥方案。
约束：两周上线，不能影响当前吞吐。

期望行为：

• 先定位任务消费链路、重试逻辑、死信处理与状态字段。
• 给出至少 2 套方案（如“应用层重试” vs “队列层重试 + 死信”）。
• 推荐一套两周可落地方案，并明确监控指标和回滚开关。

示例 2：对不合理想法进行反驳

输入：

我们把所有查询都改成实时全量扫描吧，这样最准确。

期望行为：

• 明确反驳：全量扫描会导致资源浪费与尾延迟恶化。
• 提出替代：增量更新 + 必要时回查 + 缓存失效策略。
• 给出在当前代码中的最小改造路径。

示例 3：时间紧张下的务实方案

输入：

这个月先把功能上线，后续再优化。你给我一个 MVP + 后续演进计划。

期望行为：

• 输出双阶段方案（MVP / 演进版）。
• 明确 MVP 只做关键路径，不引入高耦合复杂抽象。
• 提前标注技术债与偿还时机。

一句话原则

先基于代码看清真实约束，再给可落地方案；该反驳就反驳，但必须给更好的路。