用途：在不改变行为的前提下简化、打磨和清理代码，移除死代码或 AI 生成代码中的冗余内容（所谓 AI slop）。适用于被要求简化、重构、去杂乱、删除死代码等场景。
核心原则：保持行为一致，不得悄悄增删功能；保持异步/同步边界、错误传播路径、日志与重试等运维意图以及领域特定步骤。显式优于取巧，可读性优先于紧凑；简单优于追求“干净”，三行相似代码胜过过早抽象。改动要外科手术式，只碰需要简化的部分，并匹配原有风格与命名。改动前先弄清依赖与测试覆盖。
流程：先完整阅读文件及依赖，对看似多余但不明原因的代码先查 git blame（切斯特顿栅栏）；识别必须保持的不变量（公共 API、返回类型、副作用、错误行为）；按控制流、命名、重复、数据塑形、类型顺序施加改动，结构性改动在前、表面改动在后；最后验证测试通过、类型检查、导入解析正常。
常见坏味道与对策：嵌套超过两层用守卫子句提前返回；函数超过 20 行按职责抽取具名函数；参数超过三个合并为选项对象；重复三次以上抽取共享函数（两份先保留）；魔法数字改具名常量；复杂条件抽取为具名布尔或函数；链式转换拆为具名中间量；死代码直接删除；return 后多余的 else 删除并减少缩进。
针对 AI 生成代码：删除复述代码的冗余注释、移除上下文中不可能发生的多余防御检查、修正不当类型断言、内联过度抽象、回归文件既有风格、不要用占位符替换未简化代码、去掉无意义的错误包装、用标准库替换手写啰嗦实现。
停止条件：若改动涉及公共 API、无法验证行为一致、代码因性能或协议原因刻意复杂、或需求实为重新设计，应先停下来询问。限制：只简化被要求的部分，不新增功能或依赖；不改动未涉及的代码；不把不相关的清理打包成一次补丁；保留解释意图的注释；若简化反而更难理解则跳过；不确定是否为死代码时应先询问。验证标准为测试通过、类型检查、无行为变化、范围仅限请求文件。可与 code-simplicity-reviewer 代理配合，在重构前先产出分析报告。完成后报告改动范围、关键简化点、验证结果与残余风险。