simple

简洁——为人编写的代码，而非为艺术而作

代码不是写给机器的。代码是写给人阅读、修改和删除的。（这也是我们用英语而不是机器码编写代码的原因。）因此，代码最重要的品质是易用性：它的形式（你看到的内容）能多清楚地暗示其用法（它的工作方式）——就像路标一样，任何人都能在时速 130 公里的情况下立刻看懂，无需任何背景信息。

不要设计艺术品。要设计路标。

复杂度会放大 Bug 和成本，而不是简单地增加一项成本：它会让阅读、修改和删除代码的代价成倍上升，而且大脑解析一条错综复杂的路径所耗费的精力，远远多于解析一条简单明确的路径。复杂度也很隐蔽——它会逐渐引入，每次只增加一点点，因此人们很容易对它麻木（温水煮青蛙效应），而不是注意到它在不断累积。

“复杂和单挑霸王龙二选一，grug 选霸王龙：至少 grug 看得见霸王龙”——grugbrain.dev

核心检查项

在下列情形出现时应用这些检查项——它们彼此独立，按需选用。

1. Bug 修复质量测试

通过增加分支（再加一个 if、再加一个特殊情况）来修补症状的 Bug 修复是糟糕的修复，即使它“能用”。好的 Bug 修复会简化代码，或修复底层系统，让这一类 Bug 不再复发。在提出或评审修复方案时，主动检查：这个修复会减少还是增加代码中的路径数量？如果它只是在症状周围增加一条保护性判断，就指出这一点，并再深入一层，查明真正出问题的地方。（这正是 Dantotsu 的根除步骤所警告的那种失败模式——把临时对策伪装成永久修复。）

2. 抽象的成本呈指数级增长，而非线性增长

在引入新的抽象层之前（通用辅助工具、配置驱动机制、插件系统、“让它支持配置”——典型例子：根据配置模式生成表单），应将其_感知成本_视为随未来读者和调用点的数量呈指数级增长，而不是随编写所需时间线性增长。抽象写起来很便宜，长期维护却很昂贵：今后每位读者都得先理解这个抽象，_还得_循着它追溯到自己真正关心的具体情况。默认遵循三次原则：同一种具体需求至少独立出现三次之后再进行抽象。假设中的未来需求并不是真实需求。

3. 复杂度上限由领域决定——但两个方向都要检查

代码复杂度的下限由业务／领域复杂度决定，因此当代码感觉过于复杂时，应先质疑领域模型或需求，而不只是实现方式（“垃圾进，垃圾出”——无论如何实现，混乱的领域模型都会产出混乱的代码）。但这也有另一面：有些领域（税务规则、保险监管、合规逻辑——这位用户所从事的领域）确实存在无法消除的复杂度，在这些领域强行追求表面上的简洁并不能消除复杂度，只会把它转移到不那么显眼的地方（通常是隐含假设或未经测试的边界情况）。不要在真正理解代码所表达的领域规则之前，就急于简化代码。

4. 度量指标是信号，不是判决

圈复杂度和认知复杂度能客观地衡量结构复杂度，而非凭“感觉”判断，因此在评审代码或主张重写时值得引用。但它们衡量的是机械性的分支难度，而不是人类的可读性——一个函数在这两项指标上得分都很低，仍可能因为命名不当、结构误导或缺少上下文而难以阅读。将度量指标与易用性测试（“新队友能否无需额外背景信息就快速、正确地读懂这段代码？”）结合起来作为判断依据之一，绝不要把它作为唯一理由。

注意事项

• 不要将其过度套用为一条一概而论的“始终简化”规则——有些复杂性是领域固有的，强行消除会让代码看似简单，实际却是错误的。建议简化之前，请先查看 §3。
• 三次原则的阈值是默认标准，而非教条——如果用户已经有明确证据表明某种情况真实出现了三次以上，就不要坚持等到第四次。
• “简化”不等于“代码最短”——一行写得巧妙的表达式，其可理解性可能不如稍长一些的直白写法。应以读者形成正确心智模型的速度为优化目标，而不是字符数。
• 审查他人的代码或 PR 时，先提出可理解性问题（“新读者会如何解读这段代码？”），不要先谈抽象的复杂性理论——反馈应具体，并结合实际差异。
• 除非用户提出要求，否则不要事后用这些原则为已经做出的设计决策辩护——这项技能用于评估新代码、修复和抽象，而不是重新争论用户并未质疑的已发布决策。

指导性引言

解释_为什么_更简单的版本更好时，可以引用以下内容，而不只是断言其更好：

• “完美的境界，不是无可增添，而是无可删减。” — Antoine de Saint-Exupéry
• “简单是最高级的复杂。” — Leonardo da Vinci
• “面对复杂性和与霸王龙一对一单挑的选择，grug 选霸王龙：至少 grug 看得见霸王龙。” — grugbrain.dev

---

基准测试

场景：.benchmarks/scenarios/simple-001-root-cause-fix.md · 运行时间：2026-08-31 · 日志：.benchmarks/runs/2026-08-31/simple-001-root-cause-fix.json

Model	不使用	使用	差值
claude-opus-4-8	83%	100%	+17%
claude-sonnet-4-6	83%	100%	+17%
claude-haiku-4-5	83%	100%	+17%

通过（宽松） （运行时间：2026-08-31）。提升幅度小且一致；没有回归。门槛见 .agents/skills/skill-optimizer/rules/release-gates.md。