radical-simplification

激进简化——化繁为简的认知动作

提炼了数学家、物理学家和工程师经过记录的工作方法，他们总能将复杂问题转化为简单方案。这项技能不是一份步骤清单，而是一套认知动作工具箱，每种动作都针对能力出众的模型面对复杂性时常见的一种错误默认倾向加以纠正。这些动作大多彼此正交；选择与当前症状相匹配的动作即可。

这是位于重构（code-simplifier）、指标设计（deterministic-metric-design）和评审（design-review）之上的思考层。这些技能会针对已知形态的产物应用方法论。而这项技能本身就是方法论——如何从一开始就找到简单的形态。

何时使用

遇到以下情况时使用这项技能：

• 用户表示问题感觉过于复杂、团队在兜圈子，或者一定有更简单的方法
• 某个设计不断增加参数、依赖或分支，显得过度设计
• 计划已经起草，但仍有未解决的决策，而 Agent 即将擅自假定答案并继续
• Bug 调查尝试了同一方法的多个变体，却没有进展
• 评审发现某些复杂性可能是意外产生的（Brooks），而非问题本质所需
• Agent 被要求为棘手的工程或产品问题寻找优雅的解决方案
• 正向搜索已无进展，Agent 需要换个角度（逆向推理、求逆、借鉴其他领域）
• Agent 输出流畅，却无法在展开说明时给出依据（费曼测试）

这项技能不适用于清理已经正确运行的代码——这属于 code-simplifier。当需要简化的是方法本身时，才使用这项技能。

如何使用

这九类认知动作彼此正交。根据症状选择相应动作：

症状	选择	首先阅读的规则
解题感觉不对——可能是问题找错了	界定	frame-restate-problem
计划已起草，但仍有未解决的决策	澄清	clarify-interview-one-at-a-time
被各种情况、参数和分支淹没	缩减	reduce-toy-case-first
各部分纠缠在一起；改动会引发连锁反应	分解	decomp-orthogonal-axes
正向搜索呈指数增长或陷入停滞	求逆	invert-work-backwards
尚未发现系统的结构性真相	约束	constrain-name-the-invariant
受困于当前的词汇体系	迁移	transfer-cross-domain-analogue
具体问题始终难以解决	泛化	gen-rising-sea
输出流畅，却无法给出依据	审视	audit-feynman-technique

有关各类别的概述及排序依据，请参阅 references/_sections.md。

规则类别

#	类别	前缀	方法	规则数
1	重新界定问题	frame	换一种方式表述，区分本质与偶然因素，找到决策点	3
2	通过访谈澄清	clarify	一次只问一个问题，并提供推荐答案；提问前先阅读源文件	2
3	缩小到最简单的情况	reduce	玩具案例、极限情况、帕累托压缩	3
4	沿正交轴分解	decomp	正交轴、WHAT 与 HOW	2
5	反向搜索	invert	逆向推演，假设失败	2
6	用不变量和对称性约束	constrain	明确不变量，检查量纲	2
7	借鉴其他领域	transfer	跨领域类比，警惕术语固化	2
8	泛化问题，直到问题消解	gen	涨潮	1
9	审查自己的理解	audit	费曼法，指出困惑，费米估算	3

快速参考

1. 重新界定问题

• frame-restate-problem — 开始求解前先用自己的话重述问题；趁纠正错误问题的代价还很低时，及时发现问题出在哪里
• frame-essential-vs-accidental — Brooks 的区分：指出每一项复杂性是固有的，还是后来叠加的
• frame-find-decision-point — 找出答案必须改变的决策；回答这个问题，而不是照字面回答提问

2. 通过访谈澄清

• clarify-interview-one-at-a-time — 一次沿设计树走一个分支；每个问题都配上你的推荐答案，让用户审视一个立场，而不是从头生成答案
• clarify-prefer-source-over-asking — 如果 grep、读取文件或运行时检查就能回答问题，那就先去做；只询问源文件无法告诉你的内容

3. 缩小到最简单的情况

• reduce-toy-case-first — 先完整解决 n=1，再推广；这样就能看清大问题的结构
• reduce-limit-cases — 检查零、无穷、空值和恒等情况，找出设计在哪些情况下会退化
• reduce-pareto-compress — 针对产生 80% 结果的 20% 输入进行设计

4. 沿正交轴分解

• decomp-orthogonal-axes — 改变一个轴时无需改变其他轴，才说明轴划分正确；优先使用动词，而非当下的名词
• decomp-what-vs-how — 先写清 WHAT，再讨论 HOW；规范是裁判

5. 反向搜索

• invert-work-backwards — 正向搜索呈指数级增长时，思考到达目标前一步必须满足什么条件
• invert-assume-failure — 先写事后复盘，再写设计（Munger 的逆向思维）

6. 用不变量和对称性约束

• constrain-name-the-invariant — 不发生变化的性质往往就是答案的另一种形式
• constrain-dimensional-check — 单位、类型或类别不匹配，在造成运行时故障之前就已经是 bug

7. 借鉴其他领域

• transfer-cross-domain-analogue — 在其他领域寻找结构上的对应物；对应领域的解决方案往往可以直接移植
• transfer-suspect-vocabulary-lock-in — 后缀不断堆叠（Manager、Helper、Coordinator）表明最初的名词可能选错了

8. 泛化，直到问题消解

• gen-rising-sea — Grothendieck 的上涨之海；更抽象的版本有时反而更简单——但前提是概念更少，而不是更多

9. 审视自己的理解

• audit-feynman-technique — 将技术简写展开为初学者也能理解的句子；含糊带过之处就是理解的漏洞
• audit-name-the-confusion — 遇到困难时，明确说出自己不知道什么——不要反复尝试同一种方法的变体
• audit-fermi-sanity-check — 给出答案前，先估算其数量级；相差 10× 就是需要关注的信号

相关技能

• code-simplifier — 确定正确方法后使用的重构模式（这项技能到此结束，另一项从这里开始）
• deterministic-metric-design — 将此方法应用于设计指标这一具体问题
• design-review — 将此方法应用于审查 UI 这一具体问题

编写说明

这些方法是承重结构，而非装饰。每条规则都点明了它要纠正的错误默认做法——如果某条规则只是重述一个有能力的模型已经能正确做到的事情，就删掉它。这项技能的覆盖度由 /dev-skill:eval 在真实复杂问题提示词上的表现来验证，而不是靠凑规则数量。