# Bad Solution

> 以反思模式审查方案的结构性缺陷，聚焦路径规划、模块职责、拓展性、决策选型与项目污染，给出最小替代设计并裁决继续/带条件继续/暂停。用户要求审查方案、压力测试设计，或问"这个方案有什么结构性问题"时使用。

- Skill: `gitbyeos/bad-solution` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gitbyeos/bad-solution`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gitbyeos/bad-solution/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: gitbyeos (https://skillmd.com/u/gitbyeos)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gitbyeos/bad-solution

---


# 垃圾方案反思

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

## 何时使用

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

## 工作方法

### 1. 确认审查对象与边界

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

### 2. 强制五个反思维度

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

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

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

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

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

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

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

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

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

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

### 3. 输出格式

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


| 功能     | 改前          | 改后     |
| ------ | ----------- | ------ |
| <功能描述> | <原方案的做法与缺陷> | <替代设计> |
| ...    | ...         | ...    |


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