代码审查

• 代码审查
  • 工作原理
  • 触发审查
    • 通过聊天
    • 通过 Telegram 或 Teams
    • 通过 GitHub（请求审查）
    • 通过自动化
  • 你会看到什么
    • 实时进度
    • 审查结论
    • 在收件箱中
    • 在 GitHub 上
  • 审查准则
  • 自审检测
  • 大型 PR
  • 使用技巧
  • 状态参考

Themis 可以审查 GitHub 上的 Pull Request——分析代码变更、检查问题，并发布带有行内评论的结构化审查。它就像一个随时在线的首轮审查者，在人工审查者查看 PR 之前捕获常见问题。

工作原理

1. 你让 Themis 审查一个 PR（通过仓库和编号）
2. Themis 获取 PR diff、已有评论和 CI 状态
3. 它根据你项目的审查准则分析变更
4. 它在 GitHub 上发布包含审查结论、摘要和行内评论的审查

审查以标准的 GitHub Pull Request Review 形式出现——对所有 PR 参与者可见。

触发审查

通过聊天

向 Agent 提供仓库和 PR 编号：

“审查 pipihosting/themis PR #302”

“审查 pipihosting/web 上最新的 PR”

通过 Telegram 或 Teams

@ 机器人：

@themis review pipihosting/themis#298

@themis review pipihosting/web PR 45

通过 GitHub（请求审查）

直接在 GitHub PR 上向 Themis 机器人请求审查——就像你向队友请求审查一样。

1. 在 GitHub 上打开一个 Pull Request
2. 点击侧边栏的 Reviewers
3. 选择 Themis（或你机器人的 GitHub 账号）
4. Themis 收到审查请求的 webhook 并开始审查

这与你团队的 PR 工作流自然集成。将 Themis 添加到你的 CODEOWNERS 文件或默认审查者中，即可对每个 PR 自动获得首轮审查。

通过自动化

GitHub → PR 已打开 或 PR 准备就绪 的事件触发自动化也可以自动触发审查。

自动化 prompt 示例：

Review the pull request at #.
Focus on security issues, performance regressions, and Rails anti-patterns.

你会看到什么

实时进度

聊天中会出现进度条：

排队中 → 获取 PR → 分析中 → 审查中 → 提交中

审查结论

完成后，你会看到以下三种结果之一：

结论	图标	含义
通过	✅	代码良好，没有阻塞性问题
需要修改	⚠️	发现需要在合并前解决的问题
已评论	💬	发布了观察意见，但不阻塞 PR

在收件箱中

审查记录出现在收件箱的 信号 > 审查 下。每条记录显示：

• PR 标题 和仓库（owner/repo#number）
• 结论标记 — 通过、需要修改或已评论
• 审查摘要 — 结构化 Markdown，包含关键问题、优点和建议
• 行内评论 — 按文件和行号组织的具体代码反馈
• 推理日志 — Agent 的分析过程
• 元数据 — 成本和状态

在 GitHub 上

审查以标准的 GitHub Pull Request Review 形式发布：

• 审查正文 包含结构化摘要（关键问题、优点、建议）
• 行内评论 附加在 diff 的特定行上
• 结论 设置为 Approve、Request Changes 或 Comment

所有 PR 参与者在正常的 GitHub 工作流中都能看到该审查。

审查准则

如果你的项目有 .claude/skills/reviewing-code/ 技能，Themis 会在审查时使用它。该技能可以定义：

• 需要验证的安全检查清单
• 需要标记的项目特定反模式
• 代码风格要求
• 审查质量标准

如果没有自定义审查技能，Themis 会使用针对检测到的语言和框架的通用最佳实践。

自审检测

GitHub 不允许 PR 作者对自己的 PR 进行批准或请求修改。如果 Themis 的 GitHub token 属于 PR 作者（在自动化工作流中很常见），它会自动将结论降级为 Comment。审查内容保持不变——只有结论类型会改变。

大型 PR

对于大型 Pull Request，Themis 分页获取 diff 以处理任意大小的 PR。每页包含标注的行号，确保行内评论定位在正确的行上。

非常大的 PR（1000+ 行变更）审查时间可能较长。建议将大型变更拆分为更小、更聚焦的 PR，以获得更快、更深入的审查。

使用技巧

在 PR 创建时自动审查，获得即时反馈。开发者在打开 PR 后几分钟内就能收到首轮审查，即使是在非工作时间。

与人工审查结合使用。 Themis 捕获机械性问题（安全、风格、N+1 查询），让人工审查者专注于架构和设计决策。

先检查 CI 状态。 Themis 会在审查过程中读取 CI 结果。如果测试失败，审查会标记出来——无需审查未通过 CI 的代码。

状态参考

状态	含义
Pending	排队等待处理
Fetching PR	加载 PR 元数据和文件列表
Analyzing	读取带有逐行标注的 diff
Reviewing	Agent 分析代码并编写反馈
Submitting	发布审查到 GitHub
Approved	审查已发布 — 代码已批准
Changes Requested	审查已发布 — 需要修改
Commented	审查已发布 — 仅为观察意见
Failed	发生错误 — 请查看错误信息
Dismissed	审查在 GitHub 上被驳回