SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场review

review

编程与开发

查看项目

更新于 10-15 13:51

技能介绍

用途

Review 是一个代码审查技能，用于审查代码变更并识别高置信度、可操作的缺陷。当用户想要审查 pull request 或分支 diff，或查找缺陷、安全问题时使用。该技能设定审查者身份为资深主任级软件工程师和专家级代码审查员。

主要能力

审查聚焦范围包括：功能正确性、语法错误、逻辑 bug；损坏的依赖、契约或测试；安全问题与性能问题。

技能会主动检查多类高信号缺陷模式，且仅在 diff 中有证据时才评论：

  • 空值/未定义安全：Optional 类型解引用、不可信 JSON 载荷的缺失键错误、未检查的 .find() / array[0] / .get() 结果。
  • 资源泄漏：未关闭的文件、流、连接；错误路径缺少清理。
  • 注入漏洞：SQL 注入、XSS、命令/模板注入、认证/安全不变量违反。
  • OAuth/CSRF 不变量：state 必须按流程不可预测并经验证；标记确定性或缺失 state 检查。
  • 并发风险：TOCTOU、丢失更新、不安全共享状态、进程/线程生命周期 bug。
  • 缺失错误处理：针对网络、持久化、认证、迁移、外部 API 等关键操作。
  • 错误变量/遮蔽：变量名不匹配、契约不匹配（serializer 与 validated_data、接口与抽象方法）。
  • 类型假设 bug：在 datetime/字符串上做数值运算、排序键类型不匹配、比较对象引用而非值。
  • 偏移/游标/分页不匹配：差一错误、prev/next 行为、提交语义。
  • Async/await 陷阱：forEach/map/filter 使用 async 回调（fire-and-forget）、需要其结果或副作用时缺失 await、未处理的 promise 拒绝。

技能还列出系统性分析模式，包括逻辑与变量使用、空值/未定义安全、类型兼容与数据流、Async/Await、安全（SSRF、XSS、认证/会话、输入验证、时序、缓存投毒）、并发、API 契约与破坏性变更。

使用方式

启动方式：先理解上下文（识别当前分支与目标/base 分支；如有 PR 描述或关联工单则阅读以了解意图与验收标准）；获取 diff（优先使用预计算产物，否则通过 git diff $(git merge-base HEAD <base-branch>)..HEAD 计算）；审查所有改动文件，不跳过任何文件，系统性地遍历 diff。

两遍审查流水线：

第一遍 候选生成：

  • 步骤 0：理解 PR 意图，阅读 PR 描述；若包含工单 URL（如 Jira、Linear、GitHub issue 链接）或工单 ID，需获取它。
  • 步骤 1：分诊并分组改动文件。读取 diff 识别所有改动文件，按相关功能、文件关系、风险画像、依赖关系分组，目标 3-6 组；示例：组 1（Auth）、组 2（API handlers）、组 3（Database）。
  • 步骤 2：并行派发子代理审查每组。使用 Task 工具，subagent_type 为 "file-group-reviewer"，在单次响应中派发全部子代理以并行执行；每个子代理返回 JSON 数组形式的发现。
  • 步骤 3：汇总子代理结果。收集并合并数组，去重（相同 path + line 保留一条，优先更高优先级 P0 > P1 > P2），过滤已存在问题，撰写 1-3 句 reviewSummary。

第二遍 验证： 验证器独立复核每个候选。除应用上述报告门槛外，若满足任一条件则拒绝：推测性/无具体触发；风格/命名/格式；未锚定有效改动行；已报告（去重）；需要改动锚点才能使建议生效；对实际不会崩溃的代码路径标记缺失错误处理；描述未指明具体并发访问模式的假设性竞态；关于出现在 diff 中但不属于 PR 主要变更的代码。

基于置信度过滤：P0 若触发路径成立则批准；P1 若能验证逻辑错误或安全问题真实则批准；P2 默认拒绝，仅当（1）可独立验证 bug 存在、（2）有用户或调用者可现实触发的具体路径、（3）不涉及边界情况/防御性编码/风格，三者全部成立才批准。

严格去重：候选之间若描述同一底层 bug（同一根因，即使锚定不同行），仅批准锚点最佳、解释最清晰的一个；针对已有 PR 评论重复的候选拒绝；同一文件 + 重叠行范围 + 同一问题 = 重复，即使正文不同。

报告门槛

满足以下至少一项才报告：确定的运行时失败（TypeError、KeyError、ImportError 等）；具有清晰触发路径和可观察错误结果的错误逻辑；具有现实利用路径的安全漏洞；数据损坏或丢失；可在代码、测试或文档中发现的破坏性契约变更（API/响应/schema/验证器）。

不报告：测试代码卫生问题（未使用变量、setup 模式），除非导致测试失败；无现实触发的防御性 what-if 场景；外观问题（消息文本、命名、格式）；没有具体失败路径的“加守卫”“更安全”建议。

置信度校准：P0 近乎确定崩溃或可利用；P1 高置信度的正确性或安全问题；P2 疑似 bug 但无法从可用上下文完全验证触发路径。优先确定 bug 而非可能 bug。

优先级：P0 阻塞（崩溃、利用、数据丢失）；P1 紧急正确性或安全问题；P2 真实但影响有限的 bug；P3 轻微但真实的 bug。

每个发现应包含：优先级标签（[P0]/[P1]/[P2]/[P3]）；清晰的祈使句标题（<=80 字符）；一段简短说明为何是 bug 及如何显现；文件路径与行号；可选代码片段（<=3 行）或建议修复。高置信修复建议可使用 suggestion 块，规则包括：建议块 <= 100 行、保留被替换行的精确前导空白、仅使用 RIGHT 侧锚点、插入型建议需重复锚点行再追加新行。

去重规则：同一根因即使不同位置也不重复标记；若之前报告的问题已修复，注明为已解决。

输出

在本地（TUI/CLI）调用时，分析变更并给出结构化发现摘要，列出每个发现的优先级、文件、行号与描述。除非用户明确要求，不向 PR 发布内联评论或提交 GitHub review。

适用场景

适用于审查 pull request 或分支 diff、查找代码变更中的 bug 与安全问题。

限制

技能强调仅标记有把握的问题，避免推测性或风格挑剔；标记前需用 Grep/Read 验证，不臆测；需追踪数据流确认真实触发路径；需检查同一模式是否在别处已存在（可能是有意为之）；对测试需验证测试假设与生产行为一致。P2 级别问题默认拒绝。具体计费、价格、平台支持范围等信息暂未提供。