| name | rethink |
| description | 思维框架，帮助跳出局部修补的循环。两种触发模式。 模式一（用户主动）：当用户说"rethink"、"重新思考"、 "跳出来看"、"全局视角"、"这个问题我们是不是想错了"时加载， 直接进入完整分析。 模式二（AI 提议）：当你检测到以下信号时， 在回复末尾加一句提议 "我觉得我们可能在局部修补，要不要退一步重新看？"： 你对同一个文件做了 3 次以上修改仍未解决， 或用户连续 2 次否定你的方案， 或你发现方案里 workaround 和 edge case 越来越多。 用户同意后再执行完整分析。用户说不用则继续正常工作。 |
Zoom Out & Rethink
当局部修补反复无效时，退后一步重新审视问题本身。
核心原则
反复修补却无效，往往不是执行力的问题，而是问题定义错了。
你在水面下堵漏洞，而船底的钢板需要更换。
执行流程
1. 诊断
回顾当前对话，识别最可能的问题。以下是诊断参考框架：
问题定义是否正确？
| 信号 | 可能的根因 |
|---|
| 修了 A，B 坏了；修了 B，A 又坏了 | 这两个问题本质是同一个，被错误拆分了 |
| 每次修都引入新问题 | 当前架构无法优雅地容纳这个需求 |
| 讨论"怎么做"多于"做什么" | 目标没定义清楚就跳进了实现 |
| 反复调整参数/阈值/边界条件 | 核心方案选错了，不是参数的问题 |
三层视角定位根因：
- 当前层：我们在讨论的具体问题是什么？
- 架构层：这个问题的上下文环境，模块边界是否正确？
- 本质层：抛开现有设计，这件事理想状态下应该是什么样？
问题本身是否值得解决？
- 是真实存在的问题，还是假设性/边缘 case？
- 解决它的 ROI 值得吗？接受现状是否更合理？
- 能否通过简化需求来规避？
2. 输出
完成诊断后，输出以下内容：
盲点：我们一直在解决的可能不是真正的问题。真正的问题是 [你的判断]。
路径：基于盲点所在层级，选择一条替代路径：
| 路径 | 适用场景 | 代价 |
|---|
| 架构重构 | 根因是模块边界或数据模型选错 | 需要中间态，可能暂时退化 |
| 换方案 | 当前技术路线本身不适合这个需求 | 之前投入作废，但新方案可能更简单 |
| 简化需求 | 需求本身包含矛盾 | 砍掉非核心部分，MVP 先行 |
选择依据：盲点在结构层 → 重构；在路线层 → 换方案；在需求层 → 简化。只推荐一条，不要列三个让用户选。
下一步：一个具体、可立即执行、可观察结果的实验。不是"再调研一下"或"重新评估"。
3. 退出条件
以下情况直接告知用户，不要硬分析：
- 信息不足以判断根因 → "我需要 X 信息才能判断，当前硬分析会产出空洞结论"
- 问题不在技术层面 → "这可能需要和团队/PM 对齐，不在代码层面"
- 分析本身也在原地打转 → "zoom-out 也没帮上忙，可能需要换个时间或环境重新讨论"
常见陷阱
执行过程中自检：
| 陷阱 | 自检问题 |
|---|
| 沉没成本 | 如果从零开始，我会选当前方案吗？ |
| 细节沉迷 | 这个问题在全局视角下重要吗？ |
| 虚假进度 | 我是在"做了事"还是"解决了问题"？ |
| 问题膨胀 | 我是不是在试图一次性解决所有相关问题？ |
