| 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 也没帮上忙,可能需要换个时间或环境重新讨论"
常见陷阱
执行过程中自检:
| 陷阱 | 自检问题 |
|---|
| 沉没成本 | 如果从零开始,我会选当前方案吗? |
| 细节沉迷 | 这个问题在全局视角下重要吗? |
| 虚假进度 | 我是在"做了事"还是"解决了问题"? |
| 问题膨胀 | 我是不是在试图一次性解决所有相关问题? |