ben2pc 代码简化
code-simplify 处理不改变外部可观察行为的代码级简化。目标是让相关代码更容易理解、修改和排查，而不是减少行数或套用某种重构手法。
边界
- 函数、类、文件内部，以及它们之间的局部职责搬移属于本技能。
- 模块边界、分层、依赖方向或领域职责需要变化时，转到
arch-design。 - 已知或怀疑存在缺陷时，先由
systematic-debugging建立问题验证路径；缺陷修复不是代码简化。 - 改动需要改变用户可观察行为、公共接口或数据契约时，退出本技能并进入相应的需求澄清流程。
- 代码已经清楚，或目标区域即将被替换时，不为形式完整而重构。
授权边界
从请求区分只普查与实施清理：只要求普查时交付清单；明确要求简化、重构或普查并处理时，在指定范围内按风险执行，不让用户再次逐项选择已授权的低风险改动。
其他任务中，可完成当前修改直接必要、行为不变且影响确定的低风险局部整理；独立重构先说明维护成本与影响范围，取得授权后实施。
核心约束
- 保持外部行为。 输入、输出、副作用、错误语义和边界情况应保持不变。行为契约测试原则上不因重构而改变；绑定内部结构的测试可以随实现调整，但必须说明外部契约为何仍被保护。
- 从真实代码和项目规则出发。 阅读调用方、依赖、错误路径、相关测试和邻近实现。只有当代码意图或历史约束仍不清楚时，才使用
git blame、git log或提交记录补充上下文。 - 处理具体维护成本。 给问题准确命名，并说明它如何增加理解、修改、排查或回归风险。不要按个人风格偏好制造清理任务。
- 做最小连贯改动。 一次完成一个可独立理解和回退的结构改进；按风险选择验证节点，始终保持代码处于可构建、可测试的状态。
- 清晰优先。 更短不等于更简单。只有当改后版本在当前代码库语境下更容易理解和维护时，改动才成立。
流程
1. 框定问题
- 明确目标文件、类型或目录，以及不在本次处理范围内的内容。
- 阅读实际代码、调用点、相关测试和项目指令。
- 写清具体问题及其维护成本。可参考改动频率、缺陷历史、依赖范围和理解难度，但不要把固定行数或嵌套层数当作结论。
- 若问题实际属于缺陷、行为变更或架构边界调整，按前述边界退出。
2. 确认行为保护
- 找到能够保护相关外部行为的现有测试或其他有效验证路径。
- 证据不足时，按
test-driven-development判断如何补足及是否新增永久测试。 - 无法建立足够保护时，缩小改动范围；剩余风险不清楚则停止并报告，不用猜测证明安全。
3. 选择简化方向
- 选择能直接消除已命名问题的最小结构变化。
- 需要回忆坏味道名称或可用重构手法时，读取
references/smells-and-refactorings.md。它是提醒列表，不是必须逐项执行的检查表。 - 若处理过程中暴露出新的、超出授权范围的问题，记录并交回用户，不继续扩张。
4. 修改与验证
- 以最小连贯步骤修改代码，在与风险匹配的节点运行相关测试、构建、类型检查或静态检查。
- 出现行为差异时，先判断是实现错误还是测试绑定了内部结构；不能证明外部契约保持不变就撤销本次简化。
- 最后检查完整差异：没有无关改动，错误处理和边界行为没有被削弱，改后的职责与命名比原来更清楚。
如果验证通过，但改后版本没有降低已命名的维护成本，也应撤销本次简化；“代码不同了”不是完成证据。撤销仅限本次可识别的改动，不触碰用户或其他写入者的变更；无法安全区分时保留现场并说明冲突。
目录或模块普查
按授权范围执行普查：
- 划定目录或模块范围，逐文件识别具体维护性问题。
- 按维护成本与改动风险排序，记录位置、证据、建议方向和影响范围。
- 只普查时返回清单；已授权处理时按风险依次执行本技能流程，只有超出范围或存在实质架构决定的项目再交回用户。
与其他技能的关系
arch-design：处理模块边界、依赖方向、分层与领域职责。systematic-debugging：处理错误、异常行为和性能退化的根因定位与修复。test-driven-development：在结构改动前补足行为保护网。deep-review：发现拉取请求中的代码质量问题；本技能在用户授权后负责实施代码级简化。