Bad Solution

垃圾方案反思

将审查范围强制收敛到五个最可能导致方案结构性翻车的维度。对每个维度反思提问，基于回答构造可验证失败链（"若 X → 则 Y → 最终 Z 翻车"），再给出最小替代设计。

何时使用

• 用户要求审查方案、压力测试设计，或问"这个方案有什么结构性问题"。
• 用户希望得到可以继续推进的改进方案，而不是一份风险列表。

工作方法

1. 确认审查对象与边界

重述方案目标、约束、scope: 范围，分列事实、假设、决定性未知。不确定时停止猜测，向用户发问而非默默选择。

2. 强制五个反思维度

维度一：路径规划是否清晰？

• 从起点到终点的链路能否逐段枚举？有没有"先这样以后再说"的模糊段？
• 数据流向是否单向可追溯？是先定数据结构再补逻辑，还是反过来依赖倒置？
• 初始化与加载顺序是否明确？是否存在循环依赖、隐式时序、靠运行顺序碰巧成立？
• 破坏半径多大？改这一步会牵连几个模块？回滚路径在哪？

维度二：模块职责是否清晰？

• 这个模块叫它该叫的名字了吗？名字和实际逻辑是否相符，对外接口有没有缩写？
• 能否用一句话说清它做的一件事？说不清就是混了多件事。
• 主链路里是否混入"兼容/回退/临时/特定模式生效"的代码？
• 信任边界校验与业务不变量是否显式表达，还是散落各处靠注释提醒？

维度三：拓展性是否变差？

• 加一个同类需求要改几处？相同代码出现三遍就该重构。
• 互斥状态是用一个 state 表达，还是堆了一堆 bool 各自维护？
• 变化能否用数据结构表达，还是靠流程控制（if/switch）硬扛？
• 边界情况是被消除（统一到主路径），还是靠 if 一个个补？

维度四：决策是否犯了选择性错误？

• 技术选型是基于真实约束（性能、生态、团队熟悉度），还是凭印象/热度拍板？有没有比较过替代方案？
• 选的工具/框架/库是否真正匹配场景？是用大炮打蚊子，还是用错了工具硬凑？
• 工具使用方式是否符合其设计意图？有没有反模式用法、绕过官方推荐、自己造一套约定？
• 是否跳过了决策阶梯（标准库 > 平台原生 > 现有依赖 > 更小模型 > 才写代码）？

维度五：产物是否造成项目污染？

• 新增文件/目录是否符合现有规划与层次？有没有破坏目录职责、制造孤儿目录？
• 改动是否产生孤儿代码（无用导入、死变量、因改动失效的函数）？
• 命名是否规范：对外接口不缩写、变量带语义不带序号、布尔函数以 is 开头？
• 产物是否方便验收？设计时是否想好了测试规则，能否用 Log 定位，还是只能靠人肉 review？

3. 输出格式

对每个反思点产出改前/改后对照，整合成 markdown 表格：

不限于代码，同样适用于架构设计、变更影响、方案决策、流程设计。