这个 Skill 能做什么，适合哪些场景？
这是 vibetools 仓库中的一个代理技能，教 AI 代理如何正确使用阿里巴巴 OpenCodeReview（ocr）CLI 来评审代码变更。它规定了关键的操作纪律：先预览评审范围、以后台分离进程运行并设置 20 分钟超时下限、用短轮询等待结果，而不是在前台运行（前台会因约 2 分钟的看门狗被杀且丢失缓冲输出）。评审完成后，技能将发现按高/中/低三级分类汇报，并在用户明确要求时应用高、中级别修复。它还依赖仓库内的全局 rule. 来把测试文件纳入评审并应用资深工程师评分标准。
- 运行
ocr review --preview快速确认将评审哪些文件（含测试文件）。 - 用
nohup分离启动ocr review --audience agent --timeout 20后台评审，日志写到 /tmp/ocr_review.log。 - 通过
ps -p $PID短轮询（sleep 90）直到进程结束，再读取日志；约 25 分钟无输出则视为挂起，改查~/.opencodereview/sessions/的会话日志。 - 将评审意见按高（明确 bug/安全）、中（可维护性/边界情况）、低（疑似误报/风格）三级分组汇报。
- 在用户请求"评审并修复"时，直接应用安全的高、中级修复；仅"评审"时先征询。
- 需要
ocr llm test验证已配置 LLM 提供商，并可选安装全局评审规则以包含测试文件。
- 提交 PR 前的开发者，希望代理对 `--from <base> --to <head>` 的差异做一次全自动 AI 评审并输出分级报告。
- 团队维护者，担心默认 ocr 会排除测试文件，想通过全局 rule. 让测试代码也进入评审。
- 使用 Claude Code / LLxprt Code / Gemini CLI 等代理平台的工程师，需要一份能防止 ocr 前台超时陷阱的操作手册。
- 代码作者在收到评审报告后说"修复高、中级问题"，由代理安全地直接应用修复。
- 评审超大型变更的工程师，把 `--timeout` 提高到 30 分钟并仍以后台方式运行。
- 未安装 ocr CLI 且未配置 LLM 提供商的环境——这是硬性前置条件。
- 无法长时间后台运行命令或访问 `~/.opencodereview/` 的受限执行环境。
- 想要纯客户端/无网络评审的场景——ocr 依赖远程 LLM 提供商，评审结果需联网产生。
如何安装这个 Skill？
- 代码 diff 会被发送到 ocr CLI 配置的外部 LLM 提供商，敏感/专有代码使用者应先审查遥测与数据流设置。
- 依赖 @alibaba-group/open-code-review npm 包及可用 LLM 提供商，未验证安装路径；中国大陆网络环境下该 CLI 及其 LLM 后端可能不可达。
- 技能无版本号和变更记录，行为可能随仓库更新而变化；发布者身份未经验证。
- 全部结论基于静态源码阅读，未实际执行任何命令。
- Shell / 命令行
- 网络访问
- 本地文件系统
ocr CLI (npm i -g @alibaba-group/open-code-review)configured LLM provider for ocr
本技能属于 vibetools 仓库 skills/ 目录下的技能集合，以 SKILL.md 形式分发。Claude Code / LLxprt Code / Gemini CLI：使用仓库自带的安装脚本（README 说明其安装到平台对应的用户技能目录，未指明具体平台路径）：
git clone https://github.com/accoliver/vibetools
skills/install.sh
或安装到指定项目：
skills/install.sh /path/to/project
另需安装 ocr CLI 并（推荐）复制全局评审规则：
npm i -g @alibaba-group/open-code-review
mkdir -p ~/.opencodereview
cp review-configs/ocr/rule. ~/.opencodereview/rule.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/acoliver/vibetools.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/open-code-review" ~/.claude/skills/
rm -rf "$tmp"根据源仓库地址和 Skill 路径自动生成，只复制这个 Skill 的文件夹。如果上文有作者提供的安装方式，请优先按作者说明操作；想只在当前项目中使用，把 ~/.claude/skills 换成项目里的 .claude/skills。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 用 ocr 评审 main 分支上我最近提交的代码变更，并按严重程度给我一份分级报告。
- 请评审并修复 feature/auth 分支相对 develop 的差异，高危和中危问题直接改掉。
- 先用 --preview 看看这次评审会覆盖哪些文件，确认测试文件没有被排除后再跑完整评审。
- 这次变更特别大，把超时设到 30 分钟后台评审一下，结束后汇总所有发现。
当用户请求评审代码变更时，代理会触发此技能。流程：先用 --preview 确认范围；再以后台分离进程启动评审并轮询日志；最后把发现按高/中/低分级汇报。可选选项：--timeout 20（下限，勿降）、--format （结构化发现）、--rule <file>（临时包含测试或替换规则）；无差异时可改用 ocr scan --path <dir> 全文件评审。规则优先级为 --rule > 项目 .opencodereview/rule. > 全局 ~/.opencodereview/rule. > 内置。若仅要求"评审"，代理在改动前会先征询；若要求"评审并修复"，则直接应用安全的高、中级修复。
这个 Skill 有哪些优点和局限？
- 明确规避了 ocr 在 `--audience agent` 下前台运行被 ~2 分钟看门狗杀死并丢失全部输出的陷阱。
- 强制 20 分钟超时下限，并给出挂起时的会话日志排查路径（sessions/*.l）。
- 通过全局 rule. 把测试文件纳入评审并应用资深工程师评分标准，弥补 ocr 默认排除测试的缺陷。
- 三级严重度分类清晰：高危/中危可直接修复，低危需个案评估而非一刀切丢弃。
- 强依赖 ocr CLI 与已配置的 LLM 提供商，未提供任何替代后端。
- 后台+轮询流程最多可占用约 25 分钟，交互体验慢。
- 修复仅覆盖高、中级别，且需在"安全"前提下——不安全的修复只做描述。
- 无独立测试套件证据；其正确性主要体现在流程说明而非自动化验证。
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| Open Code Review（开源代码评审技能） 本页 | 50 · 谨慎使用 | ★ 35 | 2 个月前 | Unlicense |
| CodeRabbit 代码审查技能 | 53 · 谨慎使用 | ★ 35 | 2 个月前 | Unlicense |
| Move 代码质量检查器 | 54 · 谨慎使用 | ★ 23 | 1 年前 | MIT |
| Open Code Review — AI 代码质量门禁 | 46 · 谨慎使用 | ★ 40 | 6 个月前 | NOASSERTION |
| OpenCodeReview 代码审查技能 | 待评估 | ★ 47k | 11 天前 | Apache-2.0 |
同仓库的 coderabbit-review 技能是它最直接的对照：后者本地运行 CodeRabbit CLI（--agent 结构化发现）并支持自主实现-评审-修复循环；本技能则基于阿里 OpenCodeReview，配套 review-configs/ 中的 OCR 与 CodeRabbit 模板，仓库的研究结论是两者互补而非高下之分——匹配评审发现了不同的已验证缺陷。
FollowSkills 如何评估这个 Skill？
技能仅调用一个已知的 npm CLI（@alibaba-group/open-code-review），以用户请求为触发，修复前要求确认（仅 review 时不改代码），运行于用户本地环境，权限面可控；但第三方 LLM 审查服务会把代码 diff 发送到外部 LLM 提供商，数据流披露不完整（telemetry 存在但未说明），无回滚机制说明，发布者身份未经验证。扣分点：外部数据流向与遥测披露、无恢复/回滚路径。
指令自洽、路径清晰（预览→后台运行→轮询→分类→修复），对已知的看门狗/缓冲问题给出具体规避方案和会话日志排查路径，失败反馈较好；但全部依赖 ocr CLI 可安装且 LLM provider 已配置，无测试覆盖证据，错误场景（安装失败、provider 未配置）处理薄。静态审查上限为 10，扣分点：依赖可用性未验证、异常输入处理不足。
触发条件明确（被要求审查代码变更时），场景清晰（agent 辅助代码审查），前置条件与不适用情形（未安装 ocr）有说明；但未声明能力边界（如仅支持 git diff 审查）、无中文环境说明，ocr 与其 LLM 后端依赖海外服务，对中国大陆用户可达性存疑。扣分点：边界声明不完整、海外服务依赖未提示。
结构分层良好（前置条件→步骤→注意事项），引用仓库内 review-configs/ocr/ 作为配置来源，许可证为 Unlicense（公共领域），仓库 README 有版本跟踪 issue；但技能本身无版本号/changelog，维护责任不明确，发布者未验证。扣分点：版本治理缺失、维护者承诺不明。
编码了一个真实、非平凡的工作流（后台运行规避看门狗、严重度分类、按需修复），对 agent 比手动摸索有明确边际价值；但输出质量完全取决于 ocr 后端，且无代表性输出的可用性证据。静态上限 7，扣分点：结果可用性无验证、替代方案（直接跑 ocr 或 CodeRabbit）对比未充分论证。
关键命令和配置路径可审计、与仓库内 review-configs/ocr/ 交叉对应，README 引用了一项已发布的 AI 审查研究作为间接佐证；但无测试、无 CI 覆盖该技能路径，无第三方执行证据。静态上限 5，扣分点：核心行为无可复现的执行证据。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →