ce-simplify-code

优化最近更改的代码——三个并行审阅者代理发现重用、质量和效率问题；应用修复；验证行为由类型检查、lint 和范围测试保留。

ce-simplify-code 是精炼技能。它完成了编写代码后很容易跳过的作业：搜索新代码意外重复的现有实用程序，标记黑客模式和死代码，显示错过的效率胜利。三个并行审核代理从不同角度（重用、质量、效率）处理相同的差异，协调器应用他们的发现，然后验证行为是否保留。

前提是简化保留了精确的功能。该技能通过在修复后运行类型检查、lint 和范围测试来强制执行此操作。 它拒绝放宽断言、削弱类型签名或跳过测试以使检查通过 - 这违背了保证。

复合工程构思链是/ce-ideate → /ce-brainstorm → /ce-plan → /ce-work。 ce-simplify-code 作为 /ce-work 第 3 阶段内的质量门运行（对于差异 ≥30 条已更改的行），并且可以在打开 PR 之前直接调用以细化功能分支。

TL;DR

＃＃ 问题

编写功能后，代码通常会存在一些很容易被忽略的优化债务：

• 重新实现实用程序 - 您编写了一个已存在于 lib/utils/ 中的字符串修剪助手
• Hacky 模式 — 复制粘贴略有变化、冗余状态、参数蔓延、抽象泄漏
• 死代码 - 未使用的导入，没有导出任何引用，代码路径不再可达
• 字符串类型值，其中枚举或品牌类型已存在
• 效率缺失 — 可能是并行的顺序操作、冗余计算、N+1 模式
• **注释解释了代码的作用（标识符已经做了），而不是不明显的“为什么”

单个审阅者可以找到其中一些，但很少能找到全部。要求代理“审查和改进”往往会暴露最明显的问题，而忽略需要交叉搜索的问题。

解决方案

ce-simplify-code 运行三个并行审阅者，每个审阅者专注于一个维度：

• Reuse Reviewer 搜索新代码重复的现有实用程序
• 质量审核员 标记黑客模式、死代码、字符串类型代码、不必要的注释、嵌套条件
• 效率审核员发现丢失的并发、热路径膨胀、重复的无操作更新、广泛的操作

编排器汇总他们的发现，应用修复，并运行类型检查 + lint + 范围测试来验证行为是否得到保留。

是什么让它如此新颖

1. 三个平行评审代理——不同角度，相同差异

单一的“审查和改进”提示会分解为代理最受过训练的指示。三位审稿人各自专注于一个维度，涵盖了更多有意义的领域：

• 重用 — 搜索现有实用程序和助手；标记与现有函数重复的新函数；标记可以使用现有实用程序的内联逻辑
• 质量 — 冗余状态、参数蔓延、变化的复制粘贴、抽象泄漏、字符串类型代码、不必要的包装器（在组件树 UI 框架中）、深度嵌套条件、不必要的注释、死代码/未使用的导入/未使用的导出
• 效率 - 不必要的工作（冗余计算、重复读取）、错过并发、热路径膨胀、重复无操作更新、TOCTOU 预检查、内存问题、过于广泛的操作

2. 智能范围检测 — 用户命名 > git diff > 最近编辑

该技能按优先级顺序解析简化作用域：显式的用户命名作用域（一个文件，“我刚刚写的函数”）是权威的；否则当前分支与其基础分支之间的 git diff ；其他最近的编辑；否则它会询问而不是猜测。 用户命名的范围永远不会扩大。

3.行为保存验证

应用修复后，该技能会对项目运行类型检查和 lint，并运行针对已更改路径的测试（当更改范围广泛时，范围会扩大 - 例如，重写了大量导入的实用程序）。通过失败的检查名称和相关输出清楚地显示故障。 该技能拒绝放松断言、削弱类型签名或跳过测试以使检查通过 - 要么修复潜在的中断，要么恢复导致其的特定简化。

4. 中层模型选择——成本意识

审阅代理被派遣到平台的中间层模型上。对已知差异的代码审查不需要顶级推理。在模型覆盖不可用的平台上，该技能会忽略覆盖而不是使调度失败。

简单示例

您花了一个小时编写通知静音功能。在打开 PR 之前，您调用 /ce-simplify-code。

该技能检测到您位于以 origin/main 为基础的功能分支上，将差异作为范围，并并行调度三个审阅者。

重用返回三个结果：您的新 formatDuration 函数几乎是 lib/utils/formatTime.ts 的重复；您的内联路径处理逻辑应该使用 path.join 代替；自定义环境检查应使用现有的 isProduction() 帮助程序。

质量标记针对 "active" 和 "paused" 的两个字符串类型比较，其中代码库已经具有 SubscriptionStatus 联合；一个嵌套的三元链，可以通过早期返回干净地展平；没有任何引用的导出；一条注释解释了一个命名良好的函数的作用。

效率表明单个处理程序中的两个 API 调用可以并行运行，并且轮询循环在每个刻度上调度状态更新，而无需更改检测防护。

协调器应用所有修复（跳过一项质量发现它判断为误报）。它对更改的路径运行类型检查（通过）、lint（通过）和范围测试（通过）。摘要列出了哪些内容是好的、哪些内容发生了更改以及运行了哪些检查。

何时去实现它

在以下情况下使用 ce-simplify-code：

• 您已经完成了一项功能，并希望在打开 PR 之前进行完善
• 人工智能生成的代码可以工作但感觉沉重
• 重构产生了新的实用程序，您想确认它们不会重复现有的实用程序
• 差异已经触及共享代码，并且您需要通过检查来保证行为保留

在以下情况下跳过 ce-simplify-code：

• 差异是机械性的（格式化、依赖项碰撞、lint 修复、生成的工件）——简化对这些没有任何有用的收益
• 差异很小（几行）——审查开销超过了产量
• 您明确希望编写代码（例如，教学或说明目的）

用作工作流程的一部分

当 diff ≥30 条更改行时，ce-simplify-code 由 /ce-work 第 3 阶段自动调用 - 它在harness-native 或 /ce-code-review 审核层之前运行，以便审核者看到简化的 diff。当您想要在多个会话上构建的分支上进行细化传递时，通常也会在 /ce-commit-push-pr 之前手动调用它。

手动调用时的流程通常如下所示：

write code → /ce-simplify-code → /ce-commit-push-pr

使用独立版

该技能在链外也同样有效：

• PR 前细化 — 在打开 PR 之前在功能分支上进行 /ce-simplify-code
• 人工智能后清理 - 当法学硕士生成的代码已发布但感觉设计过度时
• 有针对性的细化 — /ce-simplify-code "the changes I made to NotificationDispatcher" 尊重用户命名的范围
• 单文件传递 — /ce-simplify-code app/services/notification_dispatcher.rb

当在 git 存储库外部调用或没有可用的 diff 时，该技能会回退到对话中最近修改的文件。如果两者都没有产生非空范围，它会询问而不是猜测。

＃＃ 参考

＃＃ 常问问题

为什么是三位审稿人而不是一位？ 单个审阅者陷入代理最训练有素的方向。三位审阅者各自专注于一个维度（重用/质量/效率），同时涵盖了更多有意义的领域——尤其是对新代码重复的现有实用程序的横切搜索，而通才审阅者经常会错过这一点。

如果发现错误或不值得解决怎么办？ 协调器汇总发现结果并直接应用它们。如果某个发现是误报，它会被记录下来并被跳过——该技能不会争论或将其呈现给您。摘要提到了所采取的行动。

如果应用修复破坏测试怎么办？ 该技能不会放松断言、削弱类型签名或跳过测试来掩盖突破。它要么解决简化带来的根本问题，要么恢复导致回归的特定更改。前提是保留确切的功能。

为什么简化不只是原始编写的一部分？ 可以，但实际上，找到现有实用程序的时刻是在您搜索它时，而不是在您编写功能时。具有并行横切搜索的单独细化过程可以捕获原始写入未捕获的内容。

它的运行是否存在微小差异？ 默认情况下，它针对它解析的任何范围运行，但是微小差异（几行）的产量很低。因此，在 ce-work 内部，该技能受到 ≥30 行阈值的限制。

另请参阅

• ce-work — 在第 3 阶段调用此技能以处理较大尺寸的差异
• ce-commit-push-pr — 细化过程后通常的下一步
• ce-code-review — 更深入的代码审查技能； ce-simplify-code 是补充，而不是替代