Complexity Review 是一个面向代码审查的技能，用于检查 diff、PR、模块或设计是否引入了不必要的复杂度。它的判断依据来自 John Ousterhout 的《软件设计哲学》（A Philosophy of Software Design）中列出的危险信号。
【用途】 该技能把复杂度定义为：结构中使系统难以理解或修改的任何东西。它强调判断每一项发现时，应看它给读者带来的代价，而不是给作者带来的代价。复杂度表现为三种症状：变更放大（一处改动引发多处编辑）、认知负担（需要知道的东西太多）、未知的未知（无法判断哪些地方必须修改，这是最糟糕的）。其成因是依赖（代码无法被孤立地理解或修改）和晦涩（重要信息不明显）。
【主要能力】 技能会扫描多种危险信号，包括：浅模块（接口几乎和实现一样复杂、单行包装、类爆炸）；信息泄漏（一个设计决策被两个以上模块知晓）；时间分解（按执行顺序拆分模块却共享知识）；过度暴露（常用场景迫使调用方了解罕见功能、缺少默认值）；单次使用方法；调用方胶水（接口缺少正确功能导致调用方写大量额外代码）；传递方法；传递变量；全局状态；相邻层相同抽象；重复；特殊与通用混杂；特殊情况；共轭方法；配置推诿；暴露内部；实现继承；异常蔓延；注释复述代码；接口被实现污染；名称含糊或难以命名；一名多义；难以描述；非显而易见代码。
【使用方式】
- 确定范围：查看 diff（git diff <base>...HEAD）及其触及的接口，阅读调用方而不只是改动的行。
- 扫描上述每一个危险信号，对每个命中写下具体位置和代价。
- 对每个命中对照“过度”标准检查，剔除失败项。
- 报告，按代价从高到低排列。
输出格式为每条发现一条记录，最昂贵的在前： [flag] path:line — 问题所在 cost: <症状> via <依赖|晦涩> — 具体后果 fix: 移除该标志的最小改动 最后以一行判断结束：该改动是让设计变好还是变坏？如果没有改善设计，那它很可能在让设计变糟。
【适用场景】 适用于审查代码变更、PR、模块设计或整体设计，帮助识别那些让系统难以理解和修改的结构问题，尤其适合在代码评审中作为复杂度检查清单使用。
【限制】 该技能明确列出“过度”（不要标记）的情况：隐藏调用方真正需要的信息（如持久性规则、必须处理的错误）；仅仅为了让模块更深而合并无关代码；分发器或同一接口的多个实现（当各自增加真实功能时，相同签名没问题）；拆分一个按块阅读很流畅的长方法（深度胜过长度）；把约定强加给实际不同的事物。这些是使用中需要避免的误报。
【修复方向】 合并或重新分配泄漏的模块；把复杂度拉低到接口之后；让接口具有一定通用性，把特化上推或下移；对传递变量使用上下文对象；通过定义消除特殊情况；选择精确的名称。