rethink

name	rethink
description	思维框架，帮助跳出局部修补的循环。两种触发模式。 模式一（用户主动）：当用户说"rethink"、"重新思考"、 "跳出来看"、"全局视角"、"这个问题我们是不是想错了"时加载， 直接进入完整分析。 模式二（AI 提议）：当你检测到以下信号时， 在回复末尾加一句提议 "我觉得我们可能在局部修补，要不要退一步重新看？"： 你对同一个文件做了 3 次以上修改仍未解决， 或用户连续 2 次否定你的方案， 或你发现方案里 workaround 和 edge case 越来越多。 用户同意后再执行完整分析。用户说不用则继续正常工作。

Zoom Out & Rethink

当局部修补反复无效时，退后一步重新审视问题本身。

核心原则

反复修补却无效，往往不是执行力的问题，而是问题定义错了。 你在水面下堵漏洞，而船底的钢板需要更换。

执行流程

1. 诊断

回顾当前对话，识别最可能的问题。以下是诊断参考框架：

问题定义是否正确？

信号	可能的根因
修了 A，B 坏了；修了 B，A 又坏了	这两个问题本质是同一个，被错误拆分了
每次修都引入新问题	当前架构无法优雅地容纳这个需求
讨论"怎么做"多于"做什么"	目标没定义清楚就跳进了实现
反复调整参数/阈值/边界条件	核心方案选错了，不是参数的问题

三层视角定位根因：

1. 当前层：我们在讨论的具体问题是什么？
2. 架构层：这个问题的上下文环境，模块边界是否正确？
3. 本质层：抛开现有设计，这件事理想状态下应该是什么样？

问题本身是否值得解决？

• 是真实存在的问题，还是假设性/边缘 case？
• 解决它的 ROI 值得吗？接受现状是否更合理？
• 能否通过简化需求来规避？

2. 输出

完成诊断后，输出以下内容：

盲点：我们一直在解决的可能不是真正的问题。真正的问题是 [你的判断]。

路径：基于盲点所在层级，选择一条替代路径：

路径	适用场景	代价
架构重构	根因是模块边界或数据模型选错	需要中间态，可能暂时退化
换方案	当前技术路线本身不适合这个需求	之前投入作废，但新方案可能更简单
简化需求	需求本身包含矛盾	砍掉非核心部分，MVP 先行

选择依据：盲点在结构层 → 重构；在路线层 → 换方案；在需求层 → 简化。只推荐一条，不要列三个让用户选。

下一步：一个具体、可立即执行、可观察结果的实验。不是"再调研一下"或"重新评估"。

3. 退出条件

以下情况直接告知用户，不要硬分析：

• 信息不足以判断根因 → "我需要 X 信息才能判断，当前硬分析会产出空洞结论"
• 问题不在技术层面 → "这可能需要和团队/PM 对齐，不在代码层面"
• 分析本身也在原地打转 → "zoom-out 也没帮上忙，可能需要换个时间或环境重新讨论"

常见陷阱

执行过程中自检：

陷阱	自检问题
沉没成本	如果从零开始，我会选当前方案吗？
细节沉迷	这个问题在全局视角下重要吗？
虚假进度	我是在"做了事"还是"解决了问题"？
问题膨胀	我是不是在试图一次性解决所有相关问题？