跳转到主要内容
评审指令让你告诉 Kody 在单次评审中应把最深入的分析集中在哪里。你无需修改任何配置，只需在触发评审时附上一条简短说明——例如”聚焦于认证和会话逻辑”——Kody 便会把最严格的分析用在匹配的改动代码上。
指令是临时的：仅对该次评审运行生效。它不会保存到你的设置中，也不会影响后续评审。若要永久改变 Kody 的行为，请改用类别指令和 Kody 的个性设置（Instructions & Personality，以前称为 Custom Prompts）或 Kody Rules。

​
何时使用

  • 一个 PR 改动了很多文件，但你最关心其中某个高风险区域（认证、支付、数据库迁移）。
  • 你希望 Kody 追踪某处改动的调用方与被调用方，并更严格地审视它。
  • 你在重新运行评审，想在不编辑任何配置的情况下引导注意力。

​
是优先级，而非过滤器

这是最需要理解的一点：
指令设定的是优先级，而不是过滤器。Kody 会优先关注聚焦区域，但仍会报告它在 diff 其他位置发现的任何具体缺陷、安全或性能问题。它绝不会隐藏聚焦之外的发现，也不会未经查看就批准 PR 的其余部分。
用指令来表达 “这里要最重点地看” ——而不是 “只看这里”。

​
如何触发

在拉取请求评论中，紧接评审命令之后写上你的聚焦文本：
你也可以使用 start-review，并与 --force 组合：
--force 会强制重新执行审查，即使 Kody 通常会跳过（“自上次审查以来没有新提交”）。无论是否附带聚焦指令，都可以在修复了导致上次运行失败的问题后获取全新审查，或将更新后的配置应用到已审查过的 PR。
只有命令之后的第一行会被用作指令。后续各行都会被忽略，因此请把聚焦内容写在一行内。
支持 GitHub、GitLab、Azure DevOps、Bitbucket 和 Forgejo。

​
Heavy mode

焦点指令告诉 Kody 在哪里最用力地看。--heavy 则让它看得更广：在常规审查之外，九个专项审查者 各自阅读完整的 diff，每个只寻找一种缺陷：
  • 说一套做一套的代码（名称、度量、结果）
  • 面向用户的文本（消息、注释、翻译）与代码不一致
  • 无效状态、被破坏的不变量和竞态条件
  • 关于边界、索引和顺序的假设
  • 密钥与身份：比较、规范化、回退值
  • 契约已更改但调用方未同步更新
  • 即使所覆盖的行为坏掉也仍会通过的测试
  • 泄漏到响应、日志和错误消息中的数据
  • 两个彼此不一致的变更文件
每个专项审查者的发现在发布前都会经过与主审查发现相同的验证，再经过常规的去重和严重级别判定， 站不住脚的猜测会像其他发现一样被丢弃。

​
默认使用 Heavy，或只用于一次审查

Code review → General 中的 Review mode 设置决定一个仓库的每次审查如何运行：Balanced（默认，只有主审查）或 Heavy。它适用于自动审查、 @kody review 和 kodus review。在某条命令上加标志，可以只针对那次审查覆盖它：
--heavy 会在设为 Balanced 的仓库上运行 heavy 审查；--balanced 会在设为 Heavy 的仓库上运行 balanced 审查。如果命令同时带有两者，以 --heavy 为准。 两个标志都可以放在命令行的任意位置 —— 焦点文本之前或之后 —— 无论哪种方式都会从指令中移除，所以 @kody review 关注重试逻辑 --heavy 会聚焦于”关注重试逻辑”。 标志可以任意顺序组合：@kody review --heavy --force 会执行强制的 heavy 审查。在 Kody 已审查过的 拉取请求上，指定与上次审查不同的模式时，会审查整个拉取请求，而不仅是此后的提交。 必须带短横线：单独的 heavy 或 balanced 会被当作指令文本，所以 @kody review heavy 结账流程 会聚焦于 “heavy 结账流程”，而不是启用该标志。

​
预期效果

  • 所有组织均可使用，云端和自托管都一样，无需申请。在 CLI 中需要已登录的团队（kodus auth login）：试用模式的审查会在不启用 heavy 的情况下运行，并给出提示。
  • 你的类别设置依然生效。 已关闭类别的专项审查者不会运行：其中七个属于 Bug，两个属于 Security。Kody Rules 和自定义代理照常运行。
  • 它运行在 Heavy 模型上。 在 AI providers → Routing → Code Review 中，Model for Heavy 选择 heavy 审查的模型，Model for Balanced 选择 balanced 审查的模型。未设置 Heavy 模型时，heavy 审查使用组织默认模型。在 Code review → General 中为仓库或目录设置的模型会同时 用于两种模式。
  • 成本更高，耗时更长。 在我们对 30 个拉取请求的评估中，与同一模型上的 Balanced 相比，heavy 审查 每个拉取请求的耗时最多约为两倍，模型成本约为 2.5 倍。它大约每两个拉取请求多发现一个真实问题，每个 拉取请求大约多发布一条并非真实问题的评论。使用自己的模型密钥（BYOK）时，额外成本计入你的服务商账单； 并发限制较低的服务商可能会让调用排队。
  • 无法访问仓库时（没有沙箱），专项审查者与主审查一样只读取 diff。
  • 拉取请求列表会在最近一次审查以 heavy mode 运行的 PR 上显示 Heavy 徽章。
把遗漏代价高昂的仓库 —— 支付服务、认证模块 —— 的 Review mode 设为 Heavy，或在单个高风险变更上 用 --heavy 请求它。

​
如何写好一条指令

  • 明确区域，而非结论。“聚焦于队列消费者的并发”比”找出缺陷”更有效。
  • 指名代码，而非结果。 指向某个模块、流程或关注点（“重试逻辑”、“报表服务中的 SQL”）。
  • 保持简短。 指令上限为 500 个字符；只会读取评论的第一行。
  • @kody review 聚焦于认证与令牌刷新流程
  • @kody review 聚焦于新的 Stripe webhook 处理
  • kodus review --focus "后台 worker 中的竞态条件"
  • @kody review 请仔细一点 —— 没有可优先的区域。
  • @kody review 只评论文件 X —— 指令不是过滤器；请用 Ignored files 来限定文件。

​
说明与限制

  • 长度： 指令会在 500 个字符处截断。
  • 仅第一行： 在 PR 评论中，只有命令之后的第一行会成为指令。
  • 设计上不信任： 由于任何能评论 PR 的人都可以提供指令，文本在使用前会被清洗（去除控制字符和尖括号）。这不会改变你的聚焦——只是防止文本篡改 Kody 的内部提示词。
  • 不持久化： 不会向你的仓库或组织设置写入任何内容。