用途
本技能用于在评估复杂度、规划功能时，系统性地对过度设计提出质疑，推动「有理由的简单」。当出现「over-engineering」「simpler」「is this overkill」「keep it simple」等信号时使用。
适用场景
- 规划功能或架构
- 选择框架、库、模式
- 评估提议的解决方案
- 检测过早优化或过早抽象
- 构建 vs 购买决策
不适用于：琐碎任务、需求清晰且复杂度已验证、法规/合规强制要求的方案。
主要能力
常见复杂度气味
- 构建 vs 购买：已有成熟库时仍自建。例如自定义认证 → Auth0、Clerk、BetterAuth；自定义校验 → Zod、Valibot、ArkType；自定义状态管理 → Zustand、Jotai、Nanostores；自定义表单处理 → React Hook Form、Formik。
- 间接方案：先解决问题 B、C、D 再解决问题 A。例如先编译 TS→JS 再用 JS → 直接在构建工具中使用 TS；读文件、转换、写回 → 使用流处理；存数据库在函数间传递 → 直接传递数据。
- 过早抽象：在没有具体未来需求时「为灵活性」加层。例如为 1 个用例做插件系统；为单一实现做工厂；为无状态函数做依赖注入；为 1 个数据源做通用仓储。
- 性能表演：没有测量或明确瓶颈就优化。例如未测负载先加缓存；无用户抱怨先加防抖；CPU 轻任务用 worker 线程；廉价计算做记忆化。
- 安全捷径：不配置安全特性而是直接关闭。例如 CORS: * → 配置具体来源；外部数据用 any → 用 Zod 做运行时校验；关闭 SSL 验证 → 修复证书链；代码中存密钥 → 环境变量 + vault。
- 框架过度：简单任务用重框架。例如静态内容用 React → HTML + CSS；本地 UI 状态用 Redux → useState；简单 CRUD 用 GraphQL → REST；小应用用微服务 → 先单体。
- 自定义基础设施：自建云厂商已提供的平台功能。例如自定义日志 → CloudWatch、Datadog；自定义指标 → Prometheus、Grafana；自定义密钥 → AWS Secrets Manager、Vault；自定义 CI/CD → GitHub Actions、CircleCI。
危险信号与追问
- 「以后可能会需要」→「我们现在有什么具体需求？」
- 「更灵活」→「简单方案无法提供、而我们需要的灵活性是什么？」
- 「最佳实践」→「针对什么上下文的最佳实践？该上下文与我们匹配吗？」
- 「更快」→「你测量过吗？性能要求是什么？」
- 「大家都这么做」→「针对这个规模的问题？他们有我们的约束吗？」
- 「更企业级」→「我们在满足什么企业需求？」
- 「我在 Hacker News 上看到的」→「他们的问题和我们的一样吗？」
更简单替代示例
- 特性开关优于插件架构
- 直接优于泛型
- 标准库优于框架
- 组合优于配置
使用方式
对非平凡提案应用框架时，用 TodoWrite 跟踪四个阶段：
- Identify（识别）：检测到复杂度气味时，创建 Identify in_progress。
- Alternative（替代）：生成更简单的选项。
- Question（追问）：探查约束条件。
- Document（记录）：记录决策。
TodoWrite 格式示例：
- Identify { complexity type } smell
- Propose alternatives to { specific approach }
- Question { constraint/requirement }
- Document { decision/rationale }
工作流：检测到气味时创建 Identify in_progress；转换时标记当前 completed，添加下一个 in_progress；若复杂度立即被验证，可跳到 Document；可选阶段：若替代方案显而易见可跳过 Alternative，若约束清晰可跳过 Question。
根据严重程度调整语气：
- ◇ Alternative（轻微复杂度）：「有意思的方案。能帮我理解为什么选 X 而不是更常见的 Y 吗？」
- ◆ Caution（中等风险）：「这种模式常导致[具体问题]。我们是在解决我没看到的问题吗？」
- ◆◆ Hazard（高风险）：「这违反[原则]，很可能导致[具体问题]。我强烈建议[替代方案]。如果必须继续，需要记录理由。」
四步协议：
- IDENTIFY：扫描提案中的常见触发点（构建 vs 购买、间接方案、过早抽象、性能表演、安全捷径、框架过度、自定义基础设施）。
- ALTERNATIVE：始终提供具体、明确的替代方案与示例。避免模糊（「也许用更简单的？」），要具体（「用 Zod 做校验，而不是自建校验引擎。做法如下……」），包含确切的库/模式名称、更简单做法的代码片段、为什么对实际需求足够。
- QUESTION：提出探查性问题以发现隐藏需求，例如「什么具体需求使简单方案不够用？」「如果使用标准模式，6 个月后会坏什么？」「我们在解决什么性能/规模问题？」「什么安全威胁模型要求这种复杂度？」「什么团队能力差距使标准方案不合适？」
- DOCUMENT：若验证后仍选择复杂方案，记录使其合理化的具体需求；添加 ADR（架构决策记录）说明权衡；加入 TODO 以便需求变化时重新审视；为非显而易见的复杂度添加注释。
限制
- 不适用于琐碎任务、需求清晰且复杂度已验证、法规/合规强制要求的方案。
- 始终：对非平凡提案应用质疑协议；提供带代码示例的具体替代方案；就约束提出具体问题；按严重程度匹配升级级别（◇/◆/◆◆）；记录有理由的复杂度决策。
- 绝不：在没有具体时间线时接受「以后可能会需要」；在没有威胁模型时允许安全捷径；在没有测量时跳过对性能主张的质疑；在没有明确理由时继续间接方案；在没有记录原因时接受复杂度。
参考文件
- decision-framework.md — 完整决策清单
- redux-overkill.md — 质疑简单表单使用 Redux
- custom-auth.md — 质疑自建认证