企业官网建设流程全解析

Kilo 代码清理实战：用 rmslop 命令从分支 diff 中系统移除 AI 生成垃圾代码

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode

导读

rmslop是 Kilo（本仓库GitHub_Trending/ki/kilocode）内置的一个自定义 Agent 命令（Custom Command），用于在合并分支之前，自动审查当前分支与dev分支的差异，并清除由 AI 辅助编码产生的"slop"（多余注释、过度防御式检查、为绕过类型问题强转any、与文件风格不符的写法、无意义的 emoji 等）。读完本文，你将掌握该命令的完整执行规范、判断标准与报告约束，并能基于仓库内的实际实现路径，理解这类命令在 Kilo/OpenCode 体系中的加载机制与配套最佳实践。

命令总览

rmslop命令定义在仓库根目录下的 .opencode/command/rmslop.md 中，属于.opencode/command/目录下的自定义命令。这类命令文件采用 Markdown 格式，文件顶部使用 YAML frontmatter 声明元信息，正文则是给 Agent 的指令。

该命令的 frontmatter 只有一项元信息：

--- description: Remove AI code slop ---

description字段会在命令列表中展示，也是 Agent 理解该命令用途的入口。命令的核心指令正文如下：

Check the diff against dev, and remove all AI generated slop introduced in this branch.

即：将当前分支与dev分支做 diff，然后移除本分支引入的所有 AI 生成的 slop。这是一条面向合并前代码审查与清理的工作流命令，适合在功能分支合入dev之前执行。

什么是 "AI slop"：五类清理对象

命令正文明确给出了需要清理的 slop 清单，共五类，每一类都需要 Agent 结合文件上下文与代码库既有风格进行判断：

1. 多余注释：人类开发者不会添加、或与文件其余部分风格不一致的注释。这类注释通常由模型为了"解释"代码而生成，但实际价值低且破坏文件一致性。
2. 异常防御式检查 / try-catch 块：对该区域代码而言不正常的防御性检查或try/catch，尤其是当调用方是受信任/已验证的调用路径（trusted / validated codepaths）时。Kilo 这类项目大量使用 Effect、Schema 等在编译期或边界层做校验的框架，内部路径往往无需重复防御。
3. 绕过类型问题的as any强转：为了绕过 TypeScript 类型检查而进行的cast to any。这类写法在合并前必须清除，改用正确的类型收窄或显式类型声明。
4. 与文件风格不一致的任何写法：包括缩进、命名、语句组织方式等与所在文件其余部分不一致的风格。
5. 无意义的 emoji 使用：代码、注释或提交信息中不承载信息的 emoji。

值得注意的是，命令本身不要求 Agent 重写功能逻辑，只要求移除上述 slop，属于减法式清理，避免在清理过程中引入新的行为变化。

执行流程

rmslop的执行流程非常精简，只有两步：

1. 对比差异：对dev分支执行git diff，定位本分支引入的变更。
2. 清理并汇报：移除识别出的 slop，最后用1～3 句话概括本次改动内容。

命令对汇报格式有硬性约束：Report at the end with only a 1-3 sentence summary of what you changed。这意味着 Agent 在完成清理后必须输出极简摘要，说明"改了什么"（what you changed），而不是复述清理过程或罗列文件清单。

这条约束与仓库中其他命令的设计理念一致。例如 .opencode/command/commit.md 要求提交信息"从最终用户视角解释 WHY 而非 WHAT"，并禁止improved agent experience这类泛泛之词；.opencode/command/changelog.md 则反复强调Focus on writing the least words to get your point across。可见该仓库的 Agent 命令体系整体推崇"少而准"的输出纪律，rmslop的 1～3 句摘要约束正是这一纪律在清理场景下的落地。

命令体系的配套机制

rmslop并非孤立存在，它与其他命令共享同一套command目录与加载约定，理解这套约定有助于你在自己的仓库中复用或扩展：

• 命令文件位置：全部位于 .opencode/command/ 目录下，每个 Markdown 文件对应一个命令。
• Frontmatter 元信息：description是通用字段；部分命令还声明model（指定执行该命令的模型）与subtask（标记为子任务，如 commit 命令）。rmslop未指定model，即使用当前会话默认模型执行。
• 模板变量与子命令：命令正文可引用$ARGUMENTS接收用户输入参数（见 .opencode/command/issues.md），可借助!前缀执行子命令并把输出注入上下文（见 .opencode/command/changelog.md 中的!`bun script/raw-changelog.ts $ARGUMENTS`）。rmslop走的是"纯指令 + Agent 自主执行 git 操作"的轻量路线。

命令目录的加载与配置还受到 .opencode/opencode.jsonc 这类配置文件的管辖，其中可配置 provider、permission（如对特定路径deny编辑权限）、references（为 Agent 提供外部仓库语义参考）、MCP 与工具开关等。这说明该命令体系是"配置 + 指令"双层驱动的：命令文件负责告诉 Agent"做什么"，配置文件负责约束"在哪做、用什么做"。

清理质量保障：配套检查脚本

清理工作本身属于代码修改，仓库还提供了若干配套脚本用于保障修改质量，建议在运行rmslop之后结合使用：

• script/check-forbidden-strings.ts：检查代码中是否出现被禁止的字符串，可用于兜底拦截 AI 常生成的模板化文案。
• script/check-kilocode-duplication.ts 与 script/check-architecture.ts：分别检查重复代码与架构边界违规，帮助验证清理过程没有破坏分层约束。

这些脚本与rmslop的定位互补：rmslop依靠 Agent 的语言理解做语义级清理，而脚本提供可重复执行的结构级校验。

适用场景与使用方式

rmslop的典型适用场景：

• 合并前清理：功能分支准备合入dev前，执行本命令确保合并 diff 干净、可读、符合既有代码风格。
• AI 协作代码复盘：在使用 AI 编码助手生成大量代码后，批量剔除注释噪声、冗余防御与any强转。
• 代码评审预处理：在提交 PR 或发起评审前，先由 Agent 自动清理，减少评审者的认知负担。

使用方式即调用该命令并让它基于当前分支与dev的 diff 执行：

rmslop

命令会自行执行git diff对比dev，完成清理后输出 1～3 句改动摘要。若需限定范围，可参考其他命令的模式扩展参数（例如借助$ARGUMENTS），但原命令保持零参数、开箱即用的简洁形态。

与代码库风格的一致性印证

从源码结构看，该仓库对"AI 生成代码质量"有系统性的关注，rmslop是其中面向 diff 场景的一环。仓库中的 docs/jetbrains-vscode-settings-parity.md、plans/ 目录下的多份方案文档，以及遍布各 package 的AGENTS.md（例如 .opencode/glossary/README.md 中描述的按目录层级组织 Agent 知识的约定），共同体现了"以一致性约束 AI 产出"的工程文化。rmslop的五类清理标准（注释、防御检查、any强转、风格、emoji）正是这种文化在代码提交层面的具体执行规范。

小结

rmslop是一个聚焦、克制、开箱即用的代码清理命令：对比devdiff，按五类标准移除 AI slop，并以 1～3 句摘要收尾。它位于 .opencode/command/rmslop.md，可与仓库内的架构/字符串检查脚本配合，形成"语义清理 + 结构校验"的合并前质量保障闭环。

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode