# 一键 PR 代码审核 **输出语言** : 中文 ## 审核范围 * 基础分支：`x` * Diff: `git fetch origin && git diff origin/x...HEAD` (三点) ## 工作流程 1. **结帐** — `gh pr checkout `（如果已经在分支上，则跳过） 2. **范围** — `git diff origin/x...HEAD --stat` 查看更改范围 3. **分类** — 确定适用哪些审核模块（参见分类表） 4. **初步审查** - 读取每个更改的文件，应用“references/”中的相关检查 5. **Codex 交叉审查** — 如果 Codex MCP 可用，则运行全面并行审查（见下文） 6. **公关评论分析** - 获取所有现有的公关评论（机器人+人类），使用本地代码库上下文进行分析（见下文） 7. **合并结果** — 合并主要 + Codex + PR 评论结果，删除重复，注释置信度 8. **评分** — 从 4 个维度对 PR 进行评分（请参阅评分系统）。 **此步骤是强制性的 - 每份报告都必须包含评分表。** 9. **报告** — 使用统一格式生成结构化报告。 **完全遵循模板 - 每个部分都是必需的。** 10. **GH 评论** — 对于拦截器问题，提出发布内联 PR 评论（需确认） ## Codex MCP 集成检查“mcp__codex__codex”是否在可用工具中。 **如果有：** 1. 将完整的差异发送给 Codex 进行独立的全面审查：查看 OneKey 加密钱包 monorepo 的 PR 差异。重点关注： - 安全漏洞（秘密泄露、身份验证绕过、供应链风险） - 运行时错误（竞争条件、空安全、内存泄漏） - 架构违规（导入层次结构、跨平台问题） - 代码质量（钩子安全、错误处理、性能）报告每个发现：文件：行、严重性（严重/高/中/低）、描述、修复建议。 2. 通过 `mcp__codex__codex-reply` 检索响应 3. 合并初审： * **两者都发现了同样的问题** → 标记“{交叉验证✅}”，自动升级为🔵高置信度 * **仅限法典的发现** → 包含标签“[Codex]”，手动审查以分配置信度 * **仅主要发现** → 通常包括 4. 在报告中添加**Codex交叉验证摘要**表格（参见报告模板） **如果不可用：** 静默跳过。在报告标题中设置“Codex交叉验证：⏭️未启用”。不要在其他地方提及 Codex。 ## 公关评论分析收集 PR 上的所有现有评论（机器人和人类），然后使用本地代码库上下文分析每个评论。您拥有完整的源代码访问权限、类型系统和依赖关系图；大多数评论者只看到了差异。利用这种不对称性。 ### 获取所有评论使用“gh api”获取完整的用户元数据（包括用于机器人检测的“type”字段）： # 顶级公关评审（评审机构） gh api 存储库/{owner}/{repo}/pulls/{pr_number}/reviews \ --jq '[.[] |选择（.body！=“”）| {作者：.user.login，is_bot：（.user.type ==“Bot”），正文：.body，状态：.state，关联：.author_association}]' # 内联评论注释（文件：行注释） gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \ --jq '[.[] | {作者：.user.login，is_bot：（.user.type ==“Bot”），路径：.path，行：.line，正文：.body，关联：.author_association}]' # 一般公关评论（问题级别） gh api 存储库/{owner}/{repo}/issues/{pr_number}/comments \ --jq '[.[] | {作者：.user.login，is_bot：（.user.type ==“Bot”），正文：.body，关联：.author_association}]' **机器人检测** — 使用 GitHub API 中的 `user.type == "Bot"` 字段，而不是硬编码的用户名列表。这会自动覆盖任何机器人（当前和未来），无需维护。如果没有评论，请在报告标题中设置“PR评论分析：⏭️无评论”并跳过此部分。 ### 分析框架对于每条实质性评论（跳过空批准、CI 状态徽章、纯格式）：判决 |意义|行动 ---|---|--- **✅ 已确认** |评论指出了一个真正的问题 |包含在调查结果中，标记来源“[]” **🔍丰富** |真正的问题，但分析肤浅或修复错误 |包含来自您的代码库知识的更深入的修复指南 **❌噪音** |考虑到完整的代码库上下文，这不是问题 |在“评论错误报告分析”中注明，并简要说明原因 **📋 已涵盖** |您的主要评论抓住了它 |交叉验证，增强信心 **你的本地优势——积极利用它们：** * **完整源代码** - 跟踪跨文件的数据流，而不仅仅是差异 * **类型系统** — 运行 `tsc`，端到端验证类型 * **架构** — 您了解 OneKey 的导入层次结构和平台模式 * **依赖项** — `yarn info`、变更日志、实际漏洞可达性 * **运行时推理** — 状态流、异步生命周期、竞争条件当有人提出含糊不清的内容时，请深入研究来源以确认或反驳。当评论缺少上下文时（例如，某个函数在上游受到安全保护），请解释原因。当评论正确时，用更丰富的上下文来放大。 ### 交叉验证规则 * 评论+初审同意 → 标记“{交叉验证✅}”，提升至🔵高 * 仅评论发现您确认 → 以适当的置信度包含“[]”标签 * 仅评论发现，您无法确认或反驳 → 包含为 ⚪ 低并附注 * 评论你反驳的证据 → 加入“评论误报分析”栏目 ### 安全注释特殊处理对于与安全相关的评论（来自 Snyk/Dependabot 等机器人或来自人工审核者）： * **漏洞报告** — 检查在 OneKey 的使用中是否确实可以访问易受攻击的代码路径 * **许可证问题** — 根据 OneKey 的许可证政策进行验证 * **依赖警报** - 检查标记的版本是否实际使用（不仅仅是在锁定文件中） ## 分类：运行哪些检查运行 `git diff origin/x...HEAD --name-only` 并匹配：更改的文件匹配 |负载 ---|--- `package.json`、锁文件、`node_modules` 补丁、`patches/*.patch` | [security-and-supply-chain.md] — 全面的供应链审查 `**/auth/**`、`**/vault/**`、`**/signing/**`、`**/crypto/**`、`manifest.json`、`**/manifest/*.js` | [security-and-supply-chain.md] — 全面的安全审查任何具有业务逻辑的`.ts`/`.tsx` [code-quality-patterns.md] — 钩子、竞争条件、空安全 `.android.ts(x)`、`.ios.ts(x)`、`.native.ts(x)`、`.desktop.ts(x)`、`.ext.ts(x)`、`.web.ts(x)`、本机模块、`BigNumber` 用法 | [onekey-platform-patterns.md] — 平台崩溃和数字安全 Shell 脚本 (`.sh`)、CI 工作流程 (`.yml`) | [onekey-platform-patterns.md] — 构建和 CI 部分 **始终检查**，无论文件类型如何： * 意外文件提交（`.DS_Store`、`.env`、`node_modules`） * 导入层次结构违规（见下文） * PR 描述与实际更改相符 * 运行[quick-commands.md]中的相关命令 ## 导入层次结构（始终验证） @onekeyhq/shared <- 禁止从其他 OneKey 软件包导入 ↓ @onekeyhq/components <- 仅导入共享 ↓ @onekeyhq/core <- 仅导入共享 ↓ @onekeyhq/kit-bg <- 导入共享核心（绝不是组件或套件） ↓ @onekeyhq/kit <- 导入共享、组件、kit-bg ↓ apps/* <- 导入全部 # 对更改的文件进行快速层次结构违规检查 git diff origin/x...HEAD --仅名称 | grep -E '\.tsx?$' | grep -E '\.tsx?$' | \ 而 IFS= 读取 -r f； do [ -f "$f" ] && grep -l "from.*@onekeyhq" "$f" 2>/dev/null;完成 | \ 而 IFS= 读取 -r f；做 echo "=== $f ==="; grep "from.*@onekeyhq" "$f";完成 ## 文件风险分类风险|图案|行动 ---|---|--- **关键** | `**/vault/**`、`**/signing/**`、`**/crypto/**`、`**/core/src/**`、硬件钱包 SDK |逐行审查 **高** | `**/auth/**`、API 端点、状态管理、`package.json`、`manifest.json` |深度回顾 **中** | UI 组件、特定于平台的代码、后台服务 |标准审查 **低** |评论、仅输入、格式、测试、文档 |扫描异常情况 ## 评分系统 **强制** — 每份报告都必须包含此评分表，无一例外。在 4 个维度上对 PR 进行评分（每个维度 1-10）：尺寸|重量 |评估什么 ---|---|--- **🔒安全性** | 35% |秘密泄露、身份验证绕过、供应链风险、输入验证 **💎 代码质量** | 30% |钩子安全、错误处理、竞争条件、空安全、DRY **🏛️ 架构稳定性** | 20% |导入层次结构、关注点分离、跨平台一致性 **✅ 主权** | 15% |处理的边缘案例、测试覆盖率、迁移路径、文档 **总分** = 加权平均分，四舍五入至小数点后一位。分数 |判决 |行动 ---|---|--- **8.0 - 10.0** | ✅ 可直接合入 |没有阻碍，只有小建议 **5.0 - 7.9** | ⚠️ 需后复审 |存在应在合并之前解决的问题 **< 5.0** | ❌建议打回重做|安全或架构中的基本问题 **评分锚点** — 保持分数一致： * 每个维度从 8 开始，扣除发现的问题 * 单一严重安全问题 → 安全上限为 3 * 单个高 bug → 代码质量上限为 5 * 导入层次结构违规 → 架构上限为 4 ## 置信度 **强制** — 每项发现都必须使用这三个表情符号标签中的一个。不要使用百分比，不要使用没有表情符号的纯文本，例如“高/中/低”。始终使用这种精确格式：标签 |意义|何时使用 ---|---|--- **🔵高** |已确认，可通过代码验证 |明显的bug、明显的违规、可重现 **🟠 中等** |可能出现的问题，需要上下文 |模式表明存在问题，可能是故意的 **⚪ 低** |可能存在问题，需要人工检查 |启发式匹配，取决于业务逻辑交叉验证的结果（主要 + Codex 同意，或主要 + PR 评论同意）→ 自动 **🔵 高**。 ## 自动修复补丁 **这些类别是强制性的** — 如果结果与其中之一匹配，则必须包含差异补丁： * `console.error/warn/log` → 项目记录器 (`defaultLogger`) * 可为空引用缺少可选链接 * 导入层次结构违规 * useEffect 中缺少清理 * BigNumber 类型强制转换 (`Number(decimals)`) * 联合类型定义中缺少类型 **格式 - 始终使用这个精确的结构：** **自动修复：** \````差异 - 旧代码 + 新代码 \```` 对于修复明确且不需要业务上下文的其他发现，还包括自动修复。如有疑问，请将其包含在内 - 有建议的修复比没有更有用。不要为以下内容生成自动修复： * 需要理解业务上下文的逻辑变化 * 需要架构决策的安全修复 * 性能优化与权衡 ## GH CLI 内嵌注释生成报告后，如果有符合评论阈值的发现： **评论阈值**：🔴高优先级（任何置信度）或🟡中优先级和🔵高置信度。这意味着： * 所有🔴高发现（无论置信度如何） * 所有 🟡 中的结果都具有 🔵 高置信度（交叉验证或通过代码确认） * 排除：🟢 低调查结果，以及 🟡 中和 🟠 中等或 ⚪ 低置信度 1. 列出值得公关评论的合格调查结果 2. **询问审稿人** : "以下问题建议直接评论到PR上，是否确认？" 3. **仅在明确同意**之后，通过以下方式发布： # Inline comment on specific file:line gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \ --field body="🟡 **问题标题**: 描述... **建议修复:** \`\`\`suggestion 修复代码 \`\`\` _— Auto-review by Claude_" \ --field path="path/to/file.tsx" \ --field line=42 \ --field side="RIGHT" \ --field commit_id="$(git rev-parse HEAD)" **Rules:** * Never post without explicit reviewer confirmation * Only post findings meeting the comment threshold (see above) * Include auto-fix in `suggestion` block when available * Maximum 5 inline comments per PR ## Unified Report Format **CRITICAL: Follow this template exactly. Every section marked [REQUIRED] must appear in every report. Do not skip or reorder sections.** # PR #NUMBER 代码审查报告 ## 审查概要 [REQUIRED] - **变更范围**: X 个文件, +Y / -Z 行 - **风险等级**: Critical / High / Medium / Low - **涉及平台**: Extension / Mobile / Desktop / Web - **Codex 交叉验证**: ✅ 已启用 / ⏭️ 未启用 - **PR 评论分析**: ✅ 已分析 (N 条评论, 其中 M 条来自 Bot) / ⏭️ 无评论 ## 评分 [REQUIRED — NEVER SKIP THIS SECTION] | 维度 | 得分 | 说明 | |------|------|------| | 🔒 安全性 | X/10 | 简要说明 | | 💎 代码质量 | X/10 | 简要说明 | | 🏛️ 架构合理性 | X/10 | 简要说明 | | ✅ 完整性 | X/10 | 简要说明 | | **总分** | **X.X/10** | **✅ 可直接合入 / ⚠️ 需修改后复审 / ❌ 建议打回** | ## Codex 交叉验证摘要 [REQUIRED if Codex was used, OMIT if not] | 发现 | Primary | Codex | 状态 | |------|---------|-------|------| | 问题描述 | Yes/No | Yes/No | 交叉验证 / 仅 Primary / 仅 Codex | ## PR 评论分析 [REQUIRED if comments exist, OMIT if none] | 来源 | 类型 | 发现 | 判定 | 说明 | |------|------|------|------|------| | Snyk | 🤖 Bot | 依赖漏洞 CVE-XXXX | ✅ Confirmed | 漏洞路径在 OneKey 中可达 | | @reviewer | 👤 Human | 缺少 null check | 🔍 Enriched | 实际需要在上游 hook 中处理 | | Devin | 🤖 Bot | 变量命名建议 | ❌ Noise | 命名符合项目规范 | ### 评论误报分析 [OMIT if no noise findings] - **[来源] 误报**: 具体说明为什么这不是问题（引用源码上下文） ## 发现的问题 [REQUIRED] ### [🔴 高] [🔵 High] 问题标题 {Cross-validated ✅} **文件**: `path/to/file.tsx:42` **类型**: 安全 / 构建 / 运行时 / 性能 / 规范 **描述**: 问题是什么，为什么有风险 **Auto-fix:** \```diff - old code + new code \``` --- ### [🟡 中] [🟠 Medium] 问题标题 **文件**: `path/to/file.tsx:18` **类型**: 运行时 **描述**: ... **修复建议**: ... --- ## 修改清单 [REQUIRED] | 优先级 | 置信度 | 文件 | 类型 | 描述 | Auto-fix | |--------|--------|------|------|------|----------| | 🔴 高 | 🔵 High | file1.tsx:42 | 安全 | 描述 | ✅ | | 🟡 中 | 🟠 Medium | file2.tsx:18 | 运行时 | 描述 | — | ## 测试建议 [REQUIRED] 1. 测试场景 2. 测试场景 ## GH 评论操作 [REQUIRED if qualifying findings exist, OMIT if none] 以下问题（🔵 High 置信度 + 🟡 中及以上）建议直接评论到 PR： - [ ] 问题1 — `file.tsx:42` - [ ] 问题2 — `file.tsx:88` > 确认后将通过 `gh` CLI 发送 inline comments。 ## Priority Definitions Priority | Criteria | Action ---|---|--- **🔴 高** | Build failure, security vulnerability, data loss, crash | Must fix before merge **🟡 中** | Runtime bug, incorrect behavior, maintainability | Should fix before merge **🟢 低** | Nice-to-have, minor inconsistency | Can fix in follow-up ## Review Discipline * **Read the code** — don't just grep. Read each changed file to understand intent. * **No false positives** — only report issues you're confident about. Uncertain? Lower the confidence. * **No style nitpicks** — focus on security, correctness, architecture, performance. * **Context matters** — understand why the code was written this way before suggesting changes. * **Prioritize** — 3 high-quality findings beats 20 marginal complaints. * **Score honestly** — the score reflects reality, not diplomacy. * **Auto-fix aggressively** — when the fix is clear, always include a diff patch. Reviewers prefer actionable suggestions. ## Reference Files * [references/security-and-supply-chain.md]() — PII 泄漏、AuthN/AuthZ、供应链、清单权限 * [references/code-quality-patterns.md]() — Hooks、竞争条件、空安全、并发请求、错误处理 * [references/onekey-platform-patterns.md]() — Android/iOS 崩溃、Fabric、BigNumber、build/CI * [references/quick-commands.md]() — 用于自动检查的 Bash 语句

1k 代码审查项目

包含技能