think

# /think · 开工前的需求澄清与方案设计 ## 使用场景 任一条件满足就用： - 预计耗时超过 30 分钟 - 涉及跨模块改动 - 用户需求描述模糊或可多种解读 - 涉及业务规则、状态机、不可逆操作 允许用户主动说"跳过 think 直接做"，但跳过的责任由用户承担。 ## 目标 在动手之前，把"我究竟要解决什么问题"、"边界在哪里"、"怎么验证完成"先讲清楚，**让 Agent 进入 planning mode**——Agent 默认会立刻动手，而企业场景下"立刻动手"几乎等于"立刻偏题"。 ## 必须步骤 ### 1. 复述目标 用一句话总结用户的需求。如果发现自己复述不出来，**立即向用户确认**，不要继续。 ### 2. 识别 Non-Goals 列出至少 **2 条**"本次明确不做"的事情。如果列不出，说明 scope 还不够清晰。 ### 3. 影响范围分析 - 涉及哪些模块 / 服务 / 文件？ - 是否触及 [`.qoder/business-logic/`](../../business-logic/) 中已沉淀的领域规则？相关哪几篇？ - 是否有上下游消费者会受影响？ ### 4. 方案对比 至少给出 **2 个候选方案**。每个方案列出： - 优势 - 风险 - 实现成本（粗估） 最后给出推荐选择**与理由**。 ### 5. 验证标准 本次任务"什么算完成"？至少包含 1 条**可执行的**验证命令或观察方法（不要写"看起来对就行"）。 ### 6. 风险与回滚 列出至少 1 个潜在风险与对应的兜底方案。 ## 禁止事项 - ❌ 不允许跳过"复述目标"——这是检测是否真的理解需求的关键 - ❌ 不允许只给一个方案——单方案等于没有选择，反映思考深度不足 - ❌ 不允许把"不知道"包装成方案——信息不足时明确列出"需要澄清的问题" - ❌ **在 plan 未经用户确认前，不允许动手写实现代码** ## 输出格式 ```markdown ## Goal （一句话目标） ## Non-Goals - ... - ... ## 影响范围 - 涉及文件：... - 相关 business-logic：... ## 候选方案 ### 方案 A：... - 优势： - 风险： - 成本： ### 方案 B：... - 优势： - 风险： - 成本： ### 推荐 选 A 因为... ## 验证标准 - 命令：`pnpm test xxx` - 观察：... ## 风险与回滚 - 风险：... - 回滚：... ## 需要用户确认的问题 （如果有） ``` ## 与其他 Skill 的关系 - 完成后通常进入实施阶段，配合 [`/small-diff`](../small-diff/SKILL.md) 控制 diff 大小 - 任务结束前必走 [`/check`](../check/SKILL.md) 验证 diff - 遇到 bug 用 [`/hunt`](../hunt/SKILL.md) 系统化排查