ly0o0o requirements-plan-design-thinking
这个 skill 做什么
这个 skill 用于把“我想做 X”转化为“在当前项目里可执行、可验证、可回滚”的方案，不空谈，不拍脑袋。
核心能力：
- 代码绑定思考：必须先看相关代码、调用链、配置与约束，再提方案。
- 方案共创而非迎合：对不合理方向要反驳，给出更稳妥替代方案。
- 多方案收敛：先发散 2-3 种路径，再基于成本/风险/收益收敛。
- 资源效率优先：关注 CPU、内存、IO、DB/队列压力和可扩展性。
- 可维护性优先：控制复杂度，保持边界清晰、便于后续迭代。
- 可落地交付：输出分步实施计划、验证方案、风险点和回滚策略。
何时使用
当请求包含以下特征时触发：
- “我想做一个新功能，但不确定怎么做最好”。
- “帮我设计方案/架构/流程，不只写代码”。
- “在性能、成本、可维护性之间做权衡”。
- “现有实现能跑，但不优雅/不稳定，想重构思路”。
- “需要你结合当前仓库代码，提出靠谱路径”。
关键词（用于识别是否启用）
方案设计、技术方案、架构方案、实现路径、trade-off、权衡、MVP、可维护性、优雅、性能优化、资源效率、扩展性、风险评估、回滚方案、分步实施、最佳实践、结合代码、不要拍脑袋、反驳、挑战假设、共创
输入要求（最小必要信息）
- 目标：你想达成什么业务结果。
- 现状：当前痛点、已有实现、已知问题。
- 范围：改哪里，不改哪里。
- 约束：时间、人力、性能预算、兼容性、基础设施限制。
- 成功标准：什么算“完成”。
若信息不全，先问 1-3 个高价值澄清问题，再进入方案设计。
执行协议（必须按顺序）
第 1 步：对齐目标与边界
- 复述目标、范围、非目标。
- 明确验收标准与红线（不能破坏什么）。
- 若目标与约束冲突，先指出冲突，不直接承诺实现。
第 2 步：代码事实建模（必须）
在给方案前，必须定位并理解：
- 入口层：API/路由/任务触发点。
- 业务层：核心 service、状态流转、错误处理。
- 数据层：数据库模型、查询模式、索引与写入路径。
- 基础设施：缓存、队列、外部 API、配置开关。
- 现有测试与文档：可复用的验证基线。
要求：所有判断尽量基于代码证据，不做“脱离项目上下文”的泛化建议。
第 3 步：方案发散（至少 2-3 个）
每个方案必须包含：
- 核心思路（1-2 句话）
- 改动范围（涉及模块）
- 优势/代价（开发成本、运行成本、维护成本）
- 风险（技术风险、回归风险、上线风险）
- 适用条件（何时选它）
第 4 步：方案收敛（决策矩阵）
至少从以下维度评分并给结论：
- 需求匹配度
- 实现复杂度
- 运行资源成本
- 可维护性
- 交付速度
- 风险可控性
输出“推荐方案 + 不推荐方案及原因”。
第 5 步：反驳机制（必须具备）
以下情况必须明确反驳，并给替代路径：
- 需求目标与系统边界矛盾。
- 为短期收益引入长期高复杂度债务。
- 明显会导致资源浪费（如无上限扫描、无控制重试）。
- 破坏稳定接口契约或数据一致性。
- 缺乏可回滚能力却尝试高风险改动。
反驳格式：
- 不合理点是什么。
- 为什么不合理（业务/技术/资源/维护角度）。
- 可行替代方案（最小可落地版本优先）。
第 6 步：落地蓝图
输出可执行计划：
- 分阶段实施（MVP -> 增强版）。
- 每阶段改动点（文件/模块级别）。
- 验证计划（成功路径 + 失败路径 + 边界路径）。
- 观测指标（日志、指标、告警）。
- 回滚策略（开关、回退步骤、数据补偿）。
第 7 步：交付表达规范
最终输出必须简洁并包含：
- 结论一句话（推荐做法）。
- 备选方案对比（简表）。
- 你接下来可以直接执行的第一步。
设计原则（默认）
- 简单优先：优先最小改动解决核心问题。
- 边界清晰：路由/服务/存储职责分明，避免跨层耦合。
- 稳定优先：错误可观测、失败可恢复、上线可回滚。
- 证据优先：关键判断要有代码或文档依据。
- 长短平衡：短期交付与长期维护同时考虑。
禁止事项
- 不看代码就给大而空的架构建议。
- 无条件迎合不合理需求，不提出异议。
- 只给“最佳实践口号”但不给项目内落点。
- 一次性大改而不给分步方案和回滚点。
- 忽略资源成本与运行风险。
输出模板（建议）
- 目标与约束确认
- 代码现状关键发现
- 方案 A/B/C 对比
- 推荐方案与理由
- 分步实施计划（含验证）
- 风险与回滚策略
示例
示例 1：新功能方案共创
输入：
我想在任务系统里加“失败自动重试 + 人工兜底”，你帮我设计最稳妥方案。
约束：两周上线，不能影响当前吞吐。
期望行为：
- 先定位任务消费链路、重试逻辑、死信处理与状态字段。
- 给出至少 2 套方案（如“应用层重试” vs “队列层重试 + 死信”）。
- 推荐一套两周可落地方案，并明确监控指标和回滚开关。
示例 2：对不合理想法进行反驳
输入：
我们把所有查询都改成实时全量扫描吧，这样最准确。
期望行为：
- 明确反驳：全量扫描会导致资源浪费与尾延迟恶化。
- 提出替代：增量更新 + 必要时回查 + 缓存失效策略。
- 给出在当前代码中的最小改造路径。
示例 3：时间紧张下的务实方案
输入：
这个月先把功能上线，后续再优化。你给我一个 MVP + 后续演进计划。
期望行为：
- 输出双阶段方案（MVP / 演进版）。
- 明确 MVP 只做关键路径，不引入高耦合复杂抽象。
- 提前标注技术债与偿还时机。
一句话原则
先基于代码看清真实约束，再给可落地方案；该反驳就反驳，但必须给更好的路。