challenge

# /challenge · 让方案自己挑自己刺 ## 使用场景 紧跟 `/think` 之后用： - `/think` 已经给出 plan / 候选方案 - 准备进入实施前 - 任何"看起来挺顺理成章"的方案——越顺，越要 challenge 也可以在以下场景用： - 别人给你看一份 spec / design 文档 - 你自己写完一段重要代码，想找潜在问题 ## 目标 **扮演反对方**——不是为了否定方案，而是把所有"乐观假设"翻出来。Agent 默认会"顺着用户/前置 plan 走"，`/challenge` 是对抗这种倾向的工程手段。 一个好的 challenge 不在于找出多少问题，而在于**问题是否致命**——让你（或用户）能决定"知道这些问题后，还要不要这样走"。 ## 必须步骤 ### 1. 复述被挑战的方案 一两句话概括"我们要 challenge 的是什么"——确保你理解的方案和 plan 一致。 ### 2. 列出至少 5 条质疑 按下面 4 个角度各出至少 1 条： | 角度 | 问什么 | |---|---| | 🎯 **目标** | 用户真的需要这个吗？还是只是"想到了"？砍掉这个功能用户会怎样？ | | 🌪 **边界 / 异常路径** | 失败 / 超时 / 空数据 / 重复请求 / 并发 / 用户中途关闭 时会怎样？ | | 🔗 **依赖** | 依赖的服务 / 库 / API 挂掉会怎样？依赖会不会变？谁来维护？ | | 🏚 **维护成本** | 半年后接手的人能看懂吗？要不要写文档？要不要写测试？运行时怎么发现问题？ | ### 3. 给每条质疑标严重度 - 🔴 **致命**：方案这样下去**必然出问题**，必须改 - 🟡 **严重**：高概率有问题，应该现在解决而不是 TODO - 🟢 **次要**：可能有问题，可以接受、记 TODO 或留做下一阶段 ### 4. 给每条质疑配**具体场景** ❌ "如果用户输入异常呢？" —— 太泛 ✅ "用户在 1 秒内连点 3 次提交按钮——`POST /api/admin/regrade` 现在没幂等保护，会触发 3 次并发重评，对 LLM 配额是浪费，对评分结果可能产生竞争" ### 5. 输出"如果接受当前方案，你必须接受什么" 不要只批评——总结：**如果不改方案，必须知道哪些代价**。这样用户能做知情决定。 ## 禁止事项 - ❌ 不允许只列空泛的"安全 / 性能 / 可维护性"标题——必须给具体场景 - ❌ 不允许"为了挑刺而挑刺"——找不到致命/严重时如实承认 - ❌ 不允许把"我觉得不优雅" 当作严重问题 - ❌ 不允许直接重写方案——你的工作是**挑刺**，重写交回原方案的提出者 ## 输出格式 ```markdown ## 被 challenge 的方案 （一两句话说明） ## 质疑清单 ### 🔴 致命 1. **场景**：当 X 发生时 **后果**：会触发 Y **建议**：必须先解决 Z ### 🟡 严重 2. ... ### 🟢 次要 3. ... ## 如果不改方案，你必须接受 - 接受 1：... - 接受 2：... ## 总结 （一句话：方案可走 / 必须修 / 该重做） ``` ## 与其他 Skill 的关系 - 通常在 [`/think`](../think/SKILL.md) 后**立即**跑——形成"我想 → 我挑自己刺 → 修正"的小循环 - 真正实施时配合 [`/small-diff`](../small-diff/SKILL.md) 控制改动 - 找到的致命 / 严重问题在 [`/check`](../check/SKILL.md) 阶段必须验证已经处理 - 如果 challenge 出来的内容值得长期记住，用 [`/record-gotcha`](../record-gotcha/SKILL.md) 写进 wiki