解题技法

要解决的问题

软件开发中常有这样的场景：限流逻辑、连接池、会话管理越写越相似，彼此互相冲突；团队被「只能这样做」的隐含假设绑架，常规方案已经不够用。此时继续堆补丁只会让复杂度螺旋上升，需要的是思维层面的重构，而不是又一个局部优化。

这个技能针对的正是「卡住」的时刻——当问题反复出现、复杂度失控、又不确定方案能否扛住生产尺度，它提供一套结构化的调度机制来破局。

核心能力与关键步骤

该技能扮演解题教练的角色，核心机制是卡点判定与子技法路由：

步骤 1 — 判定卡点类型

通过调度表把「卡住」的表现映射到具体类型：

• 不知用哪种技法 → when-stuck（调度入口）
• 需要突破式创新 → collision-zone-thinking（碰撞区思维）
• 被假设绑架 → inversion-exercise（逆向练习）
• 同一模式在 3+ 处出现 → meta-pattern-recognition（元模式识别）
• 不确定能否扛住生产尺度 → scale-game（尺度博弈）
• 复杂度螺旋上升 → simplification-cascades（简化瀑布）

步骤 2 — 路由

按上表把用户问题转给对应子技法，每个子技法都是独立技能，处理完再回到主流程。

步骤 3 — 收敛

无论走哪条路径，最终都落到一个原则：一个强大抽象 > 十个聪明技巧。输出结构化工件 ProblemDispatch，包含卡点类型、路由目标和理由，供下游开发技能（backend-development / frontend-development）消费并落地。

适用边界与注意点

这个技能不适用于：

• 已有明确工程解法的琐碎问题——直接按标准方案实现即可；
• 安全、合规等不容发散的领域——思维实验的试错成本过高。

它的价值在于「用优雅的抽象让复杂性变得不必要」，而不是替代日常工程判断。当问题本身需要确定性验证时，发散式技法反而会引入风险。