用途：在保持代码行为完全不变的前提下降低复杂度，使代码更易读、理解、修改和调试。目标是“新人能否比原版更快看懂”，而不是减少行数。适用于功能已完成且测试通过后的重构、代码审查中被指出可读性问题、遇到深层嵌套或长函数、时间紧迫下写出的代码、以及合并后出现的重复逻辑。若代码本已清晰、尚未理解其作用、属于性能关键路径、即将整体重写，则不建议使用。
五条原则：1）精确保持行为，输入输出、副作用、错误行为和边界情况都不变；2）遵守项目既有约定，先读 CLAUDE.md 并参考相邻代码的风格；3）清晰优先于炫技，冗长的 if/else 常比紧凑嵌套三元更易读；4）保持平衡，避免过度内联、合并无关逻辑、删除有意义的抽象；5）限定在近期改动范围内，不做无关的顺带重构。
流程：先理解再动手，运用“切斯特顿栅栏”思路，弄清代码职责、调用关系、边界与错误路径、测试定义和 git blame 历史；再识别结构性问题（深层嵌套、长函数、嵌套三元、布尔参数、重复条件）、命名问题（笼统或缩写名、名不副实）、注释问题（解释“是什么”的删掉，解释“为什么”的保留）和冗余问题（重复逻辑、死代码、过度抽象、多余类型断言）；随后逐条增量修改，每改一处跑一次测试，失败就回退，重构与功能改动分开提交，改动超过 500 行时建议用 codemod 等自动化手段；最后整体复核前后差异，若简化版更难理解就回退。
语言示例涵盖 TypeScript/JavaScript（去掉无谓 async 包装、简化条件赋值、用 filter 替代手工数组构建、直接返回布尔表达式）、Python（字典推导、卫语句替代嵌套条件）、React/JSX（简化条件渲染；prop drilling 属判断题需标记而非自动重构）。
验证清单：测试无需修改即全部通过、构建无新警告、linter/formatter 通过、每处改动可独立审查、diff 干净、符合项目约定、未削弱错误处理、无遗留死代码。危险信号包括：为通过测试而改测试、简化后反而更长更难懂、按个人偏好而非项目约定改名、以“更干净”为由删除错误处理、简化尚未完全理解的代码。