PR代码审查还在手动贴评论？Add Review Comment帮你精准定位每一行🔥-Skill优仓

核心功能

Add Review Comment 是一个专为 GitHub Pull Request 代码审查场景设计的 Skill，能够通过 GitHub CLI（gh）直接向 PR 的指定行添加审查评论，支持单行注释和多行范围注释两种模式。无论是指出某一行的 Bug、给出代码建议，还是对一段逻辑提出重构意见，都能精准定位，不再靠滚动截图来回比对。

它的核心能力包括：自动获取当前 PR 的最新 commit ID（通过 gh pr view 动态拉取 headRefOid），支持 RIGHT（新增/修改行）和 LEFT（删除行）两侧定位，还支持 GitHub 原生的 suggestion 块，让维护者一键 Apply 你的修改建议，极大降低沟通成本。

适用平台

这个 Skill 完美适配当前主流的 AI 编程助手，堪称这些工具的”最强外挂”：

Cursor：在 Cursor 中触发代码审查流程，自动生成带行号的 PR 评论
GitHub Copilot：与 Copilot 的代码建议联动，直接将建议以 suggestion 块形式写入 PR
Claude Code：Claude 分析完代码后，直接调用此 Skill 将审查意见落地到具体行
OpenAI Codex / Gemini Code Assist：AI 生成的审查结论不再停留在对话框，直接推送到 PR 评论区
文心快码、腾讯云CodeBuddy、华为云CodeArts：国内 AI 编程平台同样可以通过此 Skill 打通 GitHub 审查流程

对于任何依赖上下文理解的 AI 助手来说，这个 Skill 提供了”从分析到行动”的最后一公里，让 AI 的审查意见真正落地。

实操代码示例

单行评论，指向新增代码的第 42 行：

gh api repos/myorg/myrepo/pulls/88/comments 
  -f body='这里的空指针没有处理，建议加一个 null check。

🤖 Generated with Claude' 
  -f path='src/utils/parser.js' 
  -F line=42 
  -f side='RIGHT' 
  -f commit_id="$(gh pr view 88 --repo myorg/myrepo --json headRefOid -q .headRefOid)" 
  --jq '.html_url'

多行 suggestion 块，覆盖第 10 到 13 行：

gh api repos/myorg/myrepo/pulls/88/comments 
  -f body='建议改成更简洁的写法：

suggestion
const result = items.filter(Boolean).map(transform);
🤖 Generated with Claude' 
  -f path='src/utils/parser.js' 
  -F start_line=10 
  -f start_side='RIGHT' 
  -F line=13 
  -f side='RIGHT' 
  -f commit_id="$(gh pr view 88 --repo myorg/myrepo --json headRefOid -q .headRefOid)" 
  --jq '.html_url'

优势分析

和直接在 GitHub 网页上手动评论相比，Add Review Comment 的优势非常明显：

动态获取 commit ID：不需要手动复制粘贴 SHA，避免因 commit 更新导致评论挂载失败
支持 suggestion 块：这是 GitHub 原生功能，但手写格式容易出错，Skill 帮你规范化输出
AI 流程闭环：AI 分析代码 → 生成评论内容 → 自动调用 Skill 写入 PR，全程无需人工介入
精准行号定位：支持 LEFT/RIGHT 两侧，删除行和新增行都能准确挂载评论，不会错位

应用场景

几个真实会用到的场景：

自动化 Code Review Bot：CI 流程中集成 AI 审查，每次 PR 提交后自动扫描并在问题行留下评论，团队成员打开 PR 就能看到 AI 的意见
安全漏洞标注：安全扫描工具发现 SQL 注入或 XSS 风险后，直接在对应行打上评论，附上修复建议的 suggestion 块
代码规范检查：Lint 工具发现命名不规范或格式问题，通过此 Skill 将每条违规精准标注到源码行，比单纯的 CI 报错更直观
跨时区团队协作：异步审查时，AI 先跑一遍基础检查并留下评论，人工审查者只需关注 AI 没覆盖到的业务逻辑部分，节省大量来回沟通时间

最佳实践

用好这个 Skill，有几个工程化细节值得注意。评论内容要具体，避免只写”这里有问题”，应该说明问题原因和建议方案，AI 生成的评论也要做同样的约束。重复问题只留一条代表性评论，如果同一个反模式在文件里出现了十次，只在第一处留评论并说明”全文同理”，避免刷屏式评论让 PR 难以阅读。

suggestion 块要保留原始缩进，这是最容易踩的坑——GitHub 在 Apply suggestion 时会原样替换，缩进错了直接导致语法错误。commit_id 要动态获取，不要硬编码，PR 在审查过程中往往会有新的 push，动态拉取能确保评论始终挂载在最新的 diff 上。

如果你的团队在多个项目中都需要这套 AI 审查流程，可以把这个 Skill 和其他 GitHub 相关 Skill 组合成一套完整的 Code Review 工作流。Skill优仓上汇聚了大量类似的工程化 Skill，涵盖 PR 管理、Issue 追踪、CI 集成等场景，可以直接搜索组合使用，不用从零搭建。