# Code Simplify

> 简化函数、类、文件内部及局部协作代码，降低真实维护成本。当用户明确要求重构、简化、清理代码、处理代码质量评审意见，或对指定目录或模块做坏味道普查时使用。

- Skill: `ben2pc/code-simplify` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ben2pc/code-simplify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ben2pc/code-simplify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: ben2pc (https://skillmd.com/u/ben2pc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ben2pc/code-simplify

---


# 代码简化

`code-simplify` 处理不改变外部可观察行为的代码级简化。目标是让相关代码更容易理解、修改和排查，而不是减少行数或套用某种重构手法。

## 边界

- 函数、类、文件内部，以及它们之间的局部职责搬移属于本技能。
- 模块边界、分层、依赖方向或领域职责需要变化时，转到 `arch-design`。
- 已知或怀疑存在缺陷时，先由 `systematic-debugging` 建立问题验证路径；缺陷修复不是代码简化。
- 改动需要改变用户可观察行为、公共接口或数据契约时，退出本技能并进入相应的需求澄清流程。
- 代码已经清楚，或目标区域即将被替换时，不为形式完整而重构。

## 授权边界

从请求区分只普查与实施清理：只要求普查时交付清单；明确要求简化、重构或普查并处理时，在指定范围内按风险执行，不让用户再次逐项选择已授权的低风险改动。

其他任务中，可完成当前修改直接必要、行为不变且影响确定的低风险局部整理；独立重构先说明维护成本与影响范围，取得授权后实施。

## 核心约束

1. **保持外部行为。** 输入、输出、副作用、错误语义和边界情况应保持不变。行为契约测试原则上不因重构而改变；绑定内部结构的测试可以随实现调整，但必须说明外部契约为何仍被保护。
2. **从真实代码和项目规则出发。** 阅读调用方、依赖、错误路径、相关测试和邻近实现。只有当代码意图或历史约束仍不清楚时，才使用 `git blame`、`git log` 或提交记录补充上下文。
3. **处理具体维护成本。** 给问题准确命名，并说明它如何增加理解、修改、排查或回归风险。不要按个人风格偏好制造清理任务。
4. **做最小连贯改动。** 一次完成一个可独立理解和回退的结构改进；按风险选择验证节点，始终保持代码处于可构建、可测试的状态。
5. **清晰优先。** 更短不等于更简单。只有当改后版本在当前代码库语境下更容易理解和维护时，改动才成立。

## 流程

### 1. 框定问题

- 明确目标文件、类型或目录，以及不在本次处理范围内的内容。
- 阅读实际代码、调用点、相关测试和项目指令。
- 写清具体问题及其维护成本。可参考改动频率、缺陷历史、依赖范围和理解难度，但不要把固定行数或嵌套层数当作结论。
- 若问题实际属于缺陷、行为变更或架构边界调整，按前述边界退出。

### 2. 确认行为保护

- 找到能够保护相关外部行为的现有测试或其他有效验证路径。
- 证据不足时，按 `test-driven-development` 判断如何补足及是否新增永久测试。
- 无法建立足够保护时，缩小改动范围；剩余风险不清楚则停止并报告，不用猜测证明安全。

### 3. 选择简化方向

- 选择能直接消除已命名问题的最小结构变化。
- 需要回忆坏味道名称或可用重构手法时，读取 `references/smells-and-refactorings.md`。它是提醒列表，不是必须逐项执行的检查表。
- 若处理过程中暴露出新的、超出授权范围的问题，记录并交回用户，不继续扩张。

### 4. 修改与验证

- 以最小连贯步骤修改代码，在与风险匹配的节点运行相关测试、构建、类型检查或静态检查。
- 出现行为差异时，先判断是实现错误还是测试绑定了内部结构；不能证明外部契约保持不变就撤销本次简化。
- 最后检查完整差异：没有无关改动，错误处理和边界行为没有被削弱，改后的职责与命名比原来更清楚。

如果验证通过，但改后版本没有降低已命名的维护成本，也应撤销本次简化；“代码不同了”不是完成证据。撤销仅限本次可识别的改动，不触碰用户或其他写入者的变更；无法安全区分时保留现场并说明冲突。

## 目录或模块普查

按授权范围执行普查：

1. 划定目录或模块范围，逐文件识别具体维护性问题。
2. 按维护成本与改动风险排序，记录位置、证据、建议方向和影响范围。
3. 只普查时返回清单；已授权处理时按风险依次执行本技能流程，只有超出范围或存在实质架构决定的项目再交回用户。

## 与其他技能的关系

- `arch-design`：处理模块边界、依赖方向、分层与领域职责。
- `systematic-debugging`：处理错误、异常行为和性能退化的根因定位与修复。
- `test-driven-development`：在结构改动前补足行为保护网。
- `deep-review`：发现拉取请求中的代码质量问题；本技能在用户授权后负责实施代码级简化。