autofix

autofix skill 概览

autofix 做什么

autofix skill 可以帮助你安全地把 CodeRabbit review 线程里的反馈，真正转化为当前 GitHub PR 中的代码改动。它适用于你希望 agent 先读取线程级评论、再验证内容，并在明确批准后应用修复，而不是盲目照着 reviewer 文本直接改代码的场景。对于需要面向 CodeRabbit 的 Code Review 工作流，而不只是一个泛泛的“修复 review comments”提示词的开发者来说，autofix 特别有用。

适合谁使用

如果你的分支已经有打开的 PR，PR 里包含 CodeRabbit review threads，而且你想要一个可重复的方式把这些线程处理完，就可以用 autofix。它很适合维护者、贡献者，以及那些在具备 GitHub CLI 访问能力的 repo 中工作的 agent。相反，如果你手头只有一串扁平的评论、没有 PR 上下文，或者没有权限检查仓库并推送改动，那它的价值就会小很多。

它为什么不同于普通提示词

autofix 的核心价值在于“有纪律”：它把 reviewer 提供的 prompt 文本视为不可信输入，先检查仓库状态，并且预期的是一个能感知分支的 GitHub 工作流。这样可以降低应用不安全或上下文不匹配改动的风险。如果你想要的 autofix skill 是偏决策型、而不是一次性提示词，这种设计才更合适。

如何使用 autofix skill

安装 autofix

使用仓库的 skill manager 命令安装：npx skills add coderabbitai/skills --skill autofix。运行前先确认 gh auth status 可以正常通过，并且你当前目录就是包含 open PR 的那个 repo。只有在分支上已经有可处理的 CodeRabbit review 反馈时，autofix 的安装才真正值得。

给 skill 提供正确的输入

要把 autofix 用好，需要提供分支上下文、PR 目标，以及会影响实现的本地约束。低质量请求会写成“修复 review comments”。更强的提示会像这样：“对当前分支的 PR 使用 autofix，检查未解决的 CodeRabbit threads，遵守 AGENTS.md，只对失败的 auth 和 lint 评论应用经过验证的修复。”目标区域越具体，skill 越不容易把不相关的代码也顺手改过头。

先读这些文件

先看 SKILL.md，再看 github.md，然后再看任何仓库级的 AGENTS.md。SKILL.md 说明工作流和安全规则；github.md 提供可复用的 GitHub 基础操作；AGENTS.md 可能会覆盖 build、test 或 commit 的行为。如果跳过这些文件，autofix 仍然能跑，但补丁质量和流程安全性通常都会下降。

这些工作流建议很重要

把 autofix 用在一个已经有 open PR、并且已经被 CodeRabbit review 过的分支上，同时确保 git status 足够干净，方便清楚归因改动。对每个建议的修复，都要先结合实际代码进行验证，而不是只看 review thread 的措辞。如果某个 thread 的要求有歧义，先用自己的话复述意图，再去改代码；这是避免把 reviewer 的提示误读成指令的最简单办法。

autofix skill 常见问题

autofix 只适用于 CodeRabbit review threads 吗？

是的，这就是它的核心适配场景。autofix 是为 GitHub PR 上带有 thread 语境的 CodeRabbit 反馈而设计的，不是为通用 issue 分流，也不是为普通 pull request 摘要准备的。如果你的评论来自其他 review 工具，你也许还能借用这套工作流的一些思路，但这个 skill 并不是为那条路径优化的。

使用 autofix 需要 GitHub CLI 吗？

需要。autofix skill 默认 gh 和 git 都可用，而且 gh auth status 必须成功。如果没有 GitHub CLI 访问能力，你就失去了分支到 PR 的查找、thread 获取，以及协调 PR 的能力，而这些正是这个 skill 可靠的基础。

autofix 适合新手吗？

如果你已经会在 Git repo 里工作，也能理解 PR，那么它对新手是友好的。这个 skill 能减少猜测，但它仍然要求你能判断 reviewer 评论是否有误、是否不完整、或者是否不该字面照搬。新手应该在需要结构化帮助时使用 autofix，而不是指望工具替自己做完所有判断。

什么时候不该用 autofix？

如果没有 open PR、没有 CodeRabbit review，或者没有修改分支的权限，就不要用 autofix。对于那些本质上是在讨论产品决策、架构选择，或者需要在 PR thread 之外获得人工批准的 scope 变更，也应避免使用它。在这些情况下，普通讨论或更完整的实现计划，比 autofix 更合适。

如何改进 autofix skill

提供更好的 PR 上下文

autofix 想要更好的结果，关键在于你要明确写出分支目标、最可能涉及的文件，以及任何重要的 repo 规则。例如：“修复 src/auth/* 里未解决的 CodeRabbit notes，保持当前 API 稳定，并按照 AGENTS.md 运行仓库要求的测试”，这比泛泛一句“应用 review”可操作得多。好的输入会缩小修复范围，但不会把实现方式死死钉住。

注意常见失败模式

最常见的失败模式，是把 review-thread 文本当成权威代码。autofix 更安全的做法，是先把评论当作报告，再在编辑前检查代码库。另一种常见问题是过度清理：修一个 thread 时，可能顺手碰到无关逻辑。把请求范围控制住，只要求处理你真正想解决的未解决 CodeRabbit 项。

第一轮之后继续迭代

第一次运行 autofix 之后，要检查 diff 的正确性，而不只是看评论有没有被关掉。如果某个改动范围太大，下一轮就明确说明哪些内容要保留、哪些地方要收紧。如果某个 thread 看起来仍未解决，把 thread 的具体目标和相关文件路径直接引用出来，这样 skill 才能区分是真漏掉了，还是有意做出的选择。