用途
Code Simplification 是一个用于简化代码、提升可读性的技能，灵感来自 Claude Code Simplifier 插件，被改编为模型无关、流程驱动的技能，适用于任意 AI 编码智能体。它的目标不是减少代码行数，而是降低复杂度，让代码更易读、易理解、易修改和易调试。每次简化都要通过一个简单测试：“新加入团队的成员能否比原版更快地理解这段代码？”
适用时机
- 功能已可用且测试通过，但实现比实际需要更笨重时
- 代码审查中可读性或复杂度问题被指出时
- 遇到深层嵌套逻辑、过长函数或含义不清的命名时
- 重构在时间压力下写出的代码时
- 合并分散在多个文件中的相关逻辑时
- 合并引入重复或不一致的改动之后
不适用的情况：代码已经清晰可读；你还不理解代码在做什么；代码对性能敏感而“更简单”的版本会明显变慢；你即将整体重写该模块。
五大原则
-
精确保持行为：只改变表达方式，不改变代码行为。所有输入、输出、副作用、错误行为和边界情况必须保持一致。若不确定是否保持行为，就不要改。每次改动前自问：对每个输入是否产生相同输出？是否保持相同错误行为？是否保留相同副作用与顺序？现有测试是否无需修改即可通过？
-
遵循项目约定：简化是让代码更符合代码库，而不是强加外部偏好。先阅读 CLAUDE.md 或项目约定，研究邻近代码如何处理类似模式，匹配项目的导入顺序、模块系统、函数声明风格、命名约定、错误处理模式和类型注解深度。破坏项目一致性的简化不是简化，而是无谓改动。
-
清晰优先于炫技：当紧凑写法需要停顿才能解析时，显式代码更好。例如密集的三元链应改为可读的映射或 if/else；带内联逻辑的链式 reduce 应改为命名的中间步骤。
-
保持平衡：简化也有失败模式——过度简化。注意这些陷阱：过度内联，移除给概念命名的辅助函数反而让调用处更难读；合并无关逻辑；移除“不必要”的抽象（有些抽象是为了可扩展性或可测试性）；以行数作为优化目标。
-
限定改动范围：默认只简化近期修改的代码。除非明确要求扩大范围，避免顺手重构无关代码，否则会在 diff 中制造噪音并带来意外回归风险。
简化流程
第 1 步：先理解再动手（切斯特顿栅栏）。在修改或删除任何东西前，先理解它为何存在。回答：这段代码的职责是什么？谁调用它？它调用谁？边界情况和错误路径是什么？是否有测试定义预期行为？它为何这样写（性能、平台限制、历史原因）？查看 git blame 了解原始上下文。答不上来就还没准备好简化。
第 2 步：识别简化机会。扫描具体信号：结构复杂性方面，深层嵌套（3 层以上）可提取守卫子句或辅助函数；长函数（50 行以上）可拆分为职责聚焦的函数；嵌套三元可替换为 if/else、switch 或查找对象；布尔参数标志可替换为选项对象或独立函数；重复条件可提取为命名谓词函数。命名与可读性方面，通用名（data、result、temp、val、item）应改为描述内容的名字；缩写名应使用完整单词（id、url、api 等通用缩写除外）；误导性命名应反映真实行为；解释“是什么”的注释应删除，解释“为什么”的注释应保留。冗余方面，重复逻辑应提取共享函数；死代码在确认后移除；无价值包装应内联；过度设计模式应替换为简单直接方案；冗余类型断言应移除。
第 3 步：增量应用改动。一次只做一个简化，每次改动后运行测试。重构改动应与功能或缺陷修复分开提交。每次简化：做改动、运行测试套件、通过则提交或继续、失败则回退并重新考虑。避免把多个简化批量放入一个未测试的改动。500 行规则：若重构涉及超过 500 行，应投入自动化（codemod、sed 脚本、AST 转换）而非手工修改。
第 4 步：验证结果。全部简化后整体评估：简化版是否真的更易理解？是否引入与代码库不一致的新模式？diff 是否干净可审查？队友是否会批准？若“简化”版更难理解或审查，就回退。并非每次简化尝试都会成功。
语言特定指导
资料提供了 TypeScript/JavaScript、Python、React/JSX 的示例，包括：移除不必要的 async 包装、简化冗长条件赋值、用 filter 替代手工数组构建、简化冗余布尔返回、用字典推导替代冗长字典构建、用提前返回替代嵌套条件、简化冗长条件渲染等。对于通过中间组件逐层传递 prop 的情况，资料建议考虑 context 或组合是否更好，并指出这是判断问题，应标记而非自动重构。
常见合理化借口与危险信号
资料列举了若干借口及其现实，例如“能跑就别动”“行数少总是更简单”“顺手把无关代码也简化了”“类型即自文档”“这个抽象以后可能有用”“原作者一定有原因”“边加功能边重构”等，并给出对应反驳。危险信号包括：需要修改测试才能通过（很可能改变了行为）；“简化”后代码更长更难懂；按个人偏好而非项目约定重命名；以“更干净”为由移除错误处理；简化自己不完全理解的代码；把多个简化批量放入一个难以审查的大提交；未经要求重构当前任务范围外的代码。
验证清单
完成一轮简化后应确认：所有现有测试无需修改即可通过；构建成功且无新警告；linter/formatter 通过；每个简化都是可审查的增量改动；diff 干净无无关改动；简化代码遵循项目约定；未移除或削弱错误处理；未留下死代码（未使用导入、不可达分支）；队友或审查智能体会认可这是净改进。