对 Git 仓库的 MR/PR 进行标准化代码审查，输出结构化报告。本 skill 对最终审查效果负责，所有环节围绕"确保不漏问题、不误判、不遗漏影响面"设计。
采用分角色审查机制：由六种角色专家分别从各自专业视角对代码进行审查，汇总成综合报告，确保审查无盲区。所有角色审查均由 agent 自身承担；除本文明确要求的 graphify 调用链分析外，不依赖其他外部工具。
每次 skill 被调用时，必须首先执行此步骤。 本步骤用于检查是否有新版本可用，若有则先完成更新再继续后续工作。
Step 1：读取本地版本号
从本文件 frontmatter 中读取 version 字段，记为 LOCAL_VERSION。当前本地版本：0.1.0
Step 2：获取远端最新版本
使用 WebFetch 工具访问以下地址，获取 skill 详情页内容：
https://platform-eaglelab.tcl.com/skill-page/skill/255
version、v0.1、v1.2.3 等格式的字符串），记为 REMOTE_VERSIONStep 3：版本比较
比较前先对两个版本号做格式规范化，确保比较结果正确：
v 前缀（如 v0.1 → 0.1）0.1 → 0.1.0，1 → 1.0.0）major、minor、patch 比较规范化后，将 REMOTE_VERSION 与 LOCAL_VERSION 进行语义化版本比较：
REMOTE_VERSION 大于 LOCAL_VERSION：进入 Step 4（执行更新）REMOTE_VERSION 等于 LOCAL_VERSION：打印"✅ skill 已是最新版本（LOCAL_VERSION），继续执行。"，进入 Step 5REMOTE_VERSION 小于或无法解析：打印"⚠️ 无法解析远端版本，跳过更新。"，进入 Step 5Step 4：执行自动更新
raw_url、download_url、skill_url 或 .md 链接形式出现）/Users/rebert/.agents/skills/code-reviewer/SKILL.mdLOCAL_VERSION 更新至 REMOTE_VERSION，正在使用新版本继续执行。"LOCAL_VERSION）执行。"Step 5：继续执行主流程
版本检查完成（无论结果如何），继续执行下方"前置条件"及后续所有步骤。
> 设计约束： 版本检查步骤不得阻断主流程。任何网络异常、版本解析失败或更新失败，均应静默降级、打印说明后继续执行，禁止因版本检查失败而中止 code review 任务。
执行 review 前，一次性向用户收集以下所有信息（禁止分多轮询问）：
https://gitlab.example.com/group/project/-/merge_requests/123）glab mr view --repo 获取 MR 元信息folder_token，步骤 0 核心工具检查通过后立即用于创建 Review 文档开始审查前逐项检查以下依赖工具。任何核心工具检查失败，立即终止 review，不得继续执行。
核心工具（必须可用，缺一不可）：
| 检查项 | 检查命令 | 预期结果 | 失败处理 | ||
|---|---|---|---|---|---|
| -------- | ---------- | ---------- | ---------- | ||
| git 可用 | git --version | 输出版本号 | ❌ 终止，提示安装 git | ||
| glab 已安装 | `which glab 2>/dev/null \ | \ | glab --version 2>/dev/null` | 输出路径或版本号 | ❌ 终止，提示 brew install glab |
| glab 已认证 | glab auth status | 显示已登录实例和用户 | ❌ 终止，提示 glab auth login | ||
| graphify 可用 | 确认 skill 已在 | 可调用 graphify | ❌ 终止，提示升级 OpenClaw |
可选工具（缺失时降级，不阻断主流程）：
| 检查项 | 检查命令 | 失败处理 |
|---|---|---|
| -------- | ---------- | ---------- |
| 网络连通 | ping -c 1 -W 3 | 无法 clone/fetch，终止 review |
检查流程：
glab auth status 确认认证状态飞书文档创建（核心工具检查全部通过后必须立即执行）：
调用飞书文档 API，在 folder_token 指定目录下创建本次 Review 文档：
[Code Review] MR! doc_token，立即将文档 URL 告知用户；后续各步骤完成后即时将结论追加写入该文档，无需等待全部流程结束folder_token 有效性及写权限，无需继续执行后续审查步骤1.1 确定 Review 根目录
| 系统 | Review 根目录 |
|---|---|
| ------ | ------------- |
| macOS / Linux | ~/review_projects/ |
| Windows | %USERPROFILE%\review_projects\ |
1.2 每次 Review 创建唯一隔离目录
格式：
# macOS / Linux
REVIEW_ROOT="${HOME}/review_projects"
TIMESTAMP=$(date +"%Y%m%d%H%M%S")
REVIEW_DIR="${REVIEW_ROOT}/${TIMESTAMP}-${PROJECT_NAME}"
mkdir -p "${REVIEW_DIR}"
cd "${REVIEW_DIR}"
git clone <repo-url> .
git fetch origin <source-branch>
# Windows PowerShell
$REVIEW_ROOT = "$env:USERPROFILE\review_projects"
$TIMESTAMP = Get-Date -Format "yyyyMMddHHmmss"
$REVIEW_DIR = Join-Path $REVIEW_ROOT "${TIMESTAMP}-${PROJECT_NAME}"
New-Item -ItemType Directory -Force -Path $REVIEW_DIR | Out-Null
Set-Location $REVIEW_DIR
git clone <repo-url> .
git fetch origin <source-branch>
1.3 自动清理 3 天前的 Review 痕迹
# macOS / Linux
find "${REVIEW_ROOT}" -maxdepth 1 -mindepth 1 -type d -mtime +3 -exec rm -rf {} +
# Windows PowerShell
$Cutoff = (Get-Date).AddDays(-3)
Get-ChildItem -Path $REVIEW_ROOT -Directory | Where-Object { $_.CreationTime -lt $Cutoff } | Remove-Item -Recurse -Force
> 清理操作仅作用于 review_projects/ 根目录下的直接子目录，绝对不操作开发者的原始工作目录。
# 获取变更文件列表
git diff --name-only <target-branch>...origin/<source-branch>
# 获取完整 diff
git diff <target-branch>...origin/<source-branch>
# 获取 MR 元信息（标题、描述、关联 Issue）
glab mr view <mr-id> --repo <project-path>
强制要求：在深入代码细节前，必须先输出"变更意图理解"段落，包含：
只有确认变更意图后，才进入后续审查环节。
> 📝 即时写入：变更意图确认后，立即将"变更意图理解"段落追加写入飞书文档。
规模评估在两个层级分别执行，二者相互独立、均不可跳过：
| 评估层级 | 执行时机 | 目的 |
|---|---|---|
| ---------- | ---------- | ------ |
| MR 整体评估 | 步骤 2 完成后，进入步骤 3 之前（只执行一次） | 识别整体是否属于"巨型 MR"，及早发出警告，决定是否建议用户先拆分 MR |
| 批次级评估 | 步骤 3 分批完成后，每个批次进入步骤 4 角色审查之前（每批执行一次） | 决定该批次内部采用哪种审查深度策略（全量/分层/采样） |
规模档位定义：
# MR 整体：统计全量 diff 行数
git diff <target-branch>...origin/<source-branch> | wc -l
# 批次级：统计该批次所含文件的 diff 行数
git diff <target-branch>...origin/<source-branch> -- <file1> <file2> ... | wc -l
| 规模档位 | Diff 总行数 | MR 整体评估行为 | 批次级评估行为 |
|---|---|---|---|
| ---------- | ------------- | ---------------- | ---------------- |
| 正常 | < 500 行 | 无需特殊处理 | 全量深度审查，所有文件逐行覆盖 |
| 偏大 | 500～2000 行 | 无需特殊处理 | 全量审查，报告标注"变更较大，建议开发自测后再合并" |
| 超大 | 2000～5000 行 | 报告中提示"建议拆分为多个 MR" | 触发分层审查策略（见下方） |
| 巨型 | > 5000 行 | 报告开头强制发出警告，建议拆分后重新提交 | 触发强制采样审查（见下方） |
> 注意：MR 整体档位与批次档位可以不同。例如整体是"超大"（4000 行），但拆成 3 批后每批只有 1300 行，则批次级按"偏大"处理，不触发分层策略。反之，整体"偏大"但某个批次集中了大量变更导致批次级超过 2000 行，则该批次独立触发分层策略。
分层审查策略（批次 diff 2000～5000 行时执行）：
将该批次文件按风险等级分为三层，各层采用不同审查深度：
| 层级 | 文件类型 | 审查深度 | 判断依据 |
|---|---|---|---|
| ------ | ---------- | ---------- | ---------- |
| Tier 1（深度审查） | 核心业务逻辑、安全相关（鉴权/加密/权限）、数据库 Schema、对外 API | 逐行精读，全检查清单覆盖 | 文件名含 service/auth/security/dao/repository/controller/api/schema/migration |
| Tier 2（正常审查） | 服务实现、组件逻辑、工具类 | 读完整函数，覆盖高风险检查项 | 非 Tier 1 的业务代码 |
| Tier 3（快速扫描） | 单元测试、配置文件、自动生成代码、构建脚本、文档 | 只看结构变化，不逐行审查 | 扩展名 .json/.yaml/.xml/.md，文件名含 test/spec/mock/generated |
分层审查时，报告中必须声明每个文件所在层级及审查深度。
强制采样审查（批次 diff > 5000 行时执行）：
> ⚠️ 本次批次 diff 超过 5000 行，完整深度审查超出容量上限。已按采样策略审查，以下文件经过完整深度审查，其余文件仅做结构性扫描。强烈建议将此 MR 拆分为多个更小的 MR 后重新提交。
> ⚠️ 以下文件因 diff 规模超限未进行逐行审查，存在漏检风险：file-a.java, file-b.java, ...
变更文件数 ≤ 10 时，直接跳至步骤 4，所有文件作为一个整体批次处理。
变更文件数 > 10 时，必须先完成分批，再对每个批次执行步骤 4 的分角色审查。按以下优先顺序选择拆分维度：
| 优先级 | 拆分维度 | 适用场景 |
|---|---|---|
| -------- | ---------- | ---------- |
| 1 | 按业务模块 | 变更横跨多个业务域（如设备管理/用户/订单） |
| 2 | 按调用层次 | 变更覆盖多层（入口层/服务层/数据层） |
| 3 | 按变更类型 | 混合了功能新增/Bug 修复/重构 |
每批文件数控制在 5～10 个，保证每个角色能对每个文件进行深度审查。
当变更文件 > 10 时：
Batch 1 (模块A, 5文件) ──▶ 6个角色逐一审查 ──▶ Batch 1 各角色结论
Batch 2 (模块B, 6文件) ──▶ 6个角色逐一审查 ──▶ Batch 2 各角色结论
Batch N (模块C, 4文件) ──▶ 6个角色逐一审查 ──▶ Batch N 各角色结论
│
▼
跨批次汇总 + 步骤 5 去重合并
│
▼
最终报告
当变更文件 ≤ 10 时：
全量文件 ──▶ 6个角色逐一审查 ──▶ 步骤 5 去重合并 ──▶ 最终报告
每个批次都必须经过完整的角色审查，不可跳过任何角色或批次。
> 📝 即时写入：每个批次的全部角色审查完成后，立即将该批次所有角色的审查结论追加写入飞书文档，不等待后续批次完成。
测试工程师角色特殊说明：测试工程师必须参与每个批次的审查，并必须结合 graphify 产出的调用链/依赖关系评估测试范围，不得仅凭 diff 主观判断测试案例。
产品经理角色特殊说明：产品经理只审查业务逻辑相关的批次（Controller/Service/API/UI），纯基础设施/配置/脚本类批次可跳过，但必须在该批次的产品经理审查区块中注明"本批次不涉及业务需求，跳过产品对齐"。
所有角色审查由 agent 自身完成；除本文明确要求的 graphify 调用链分析外，无需外部工具。agent 依次以每个角色的身份和视角对当前批次的代码进行独立审查，输出该角色的独立审查结论。
每个角色审查时，agent 按以下框架切换视角，逐一执行对应的检查清单，每项未发现问题时记录"✅ 通过"，发现问题时记录问题级别和描述。
角色一：🏛️ 架构师
> 身份设定：15 年系统架构经验，擅长分布式系统设计、DDD 和微服务架构。
> 审查目标：评估变更是否符合整体架构设计，是否引入技术债务或架构退化。
检查清单：
角色二：⚡ 性能工程师
> 身份设定：专注系统性能优化，熟悉数据库调优、JVM 调优、并发编程和分布式性能模型。
> 审查目标：识别变更引入的性能风险，给出具体优化建议。
检查清单：
SELECT * 无分页、无 LIMIT）？角色三：🔒 安全工程师
> 身份设定：应用安全工程师，熟悉 OWASP Top 10、渗透测试和安全编码规范。
> 审查目标：识别变更引入的安全漏洞，所有发现的安全问题默认为 Blocker。
检查清单（基于 OWASP Top 10）：
角色四：👨💻 资深开发工程师
> 身份设定：10 年工程经验，熟悉代码整洁之道、设计模式和测试最佳实践。
> 审查目标：从代码质量、正确性、可维护性三个维度评估变更。
检查清单：
tmp/data/flag/obj 等模糊命名？角色五：🧪 测试工程师
> 身份设定：测试工程师 / QA Engineer，熟悉测试策略设计、回归范围分析、接口测试、E2E 测试和缺陷预防。
> 审查目标：基于 graphify 调用链和依赖图评估实际影响范围，输出 QA 可直接执行的测试范围与必须覆盖案例。
graphify 使用要求：
检查清单：
输出要求：
角色六：📋 产品经理（仅在提供 PRD 时执行）
> 身份设定：8 年产品经验，熟悉需求分析、用户故事和验收标准编写。
> 审查目标：对照 PRD，评估代码实现是否完整覆盖需求，是否存在理解偏差或遗漏场景。
检查清单：
绝对禁止仅看 diff 片段就下结论。所有角色的每条审查意见必须基于以下至少一项：
grep -rn 或 graphify 针对单个变更函数做定向查询，确认直接调用方是否需要适配。此处 graphify 用于回答"谁调用了这个函数"这一具体问题，属于审查过程中的辅助工具，与步骤 6 的全局依赖分析相互独立、不可替代。上下文验证检查清单（每条审查意见必须覆盖）：
在执行角色检查清单之前，必须先识别本次变更涉及的主要编程语言，并将对应的专项检查项附加到相关角色的检查清单末尾。
语言识别方式：统计 diff 中各扩展名的文件数量，取占比最高的一到两种作为主语言。
git diff --name-only <target>...<source> | sed 's/.*\.//' | sort | uniq -c | sort -rn
Java（文件扩展名 .java）
附加到 资深开发工程师 清单：
Optional 的 .get() 直接调用？应使用 orElse/orElseThrowcatch (Exception e) {}）或转成 RuntimeException 时丢失了原始异常链？equals 是否同步重写了 hashCode？== 比较字符串而非 .equals()？附加到 性能工程师 清单：
parallelStream()？+ 拼接字符串而非 StringBuilder？附加到 安全工程师 清单：
ObjectInputStream 或不安全的 JSON 反序列化（如 Jackson 开启 enableDefaultTyping）？附加到 架构师 清单：
@Lookup 或 ApplicationContext.getBean() 获取？@Transactional 的传播级别是否符合业务语义？同类内方法调用是否导致事务失效？Go（文件扩展名 .go）
附加到 资深开发工程师 清单：
_ = someFunc()）？fmt.Errorf("%w", err) 保留错误链，而非直接返回原始 error 导致上下文丢失？defer 是否在循环内使用（会延迟到函数返回而非循环结束，导致资源堆积）？附加到 性能工程师 清单：
map 进行读写（应使用 sync.Map 或加锁）？sync.Pool）复用？附加到 安全工程师 清单：
context.Context 以支持超时和取消？Python（文件扩展名 .py）
附加到 资深开发工程师 清单：
def f(lst=[]):）？应改为 None 并在函数体内初始化mypy 可验证）？except Exception: 或 except:）掩盖了真实错误？yield）而非一次性构建列表？附加到 性能工程师 清单：
asyncio）？map/filter 替代显式 for 循环？附加到 安全工程师 清单：
pickle.loads()？eval()/exec() 执行动态字符串？TypeScript / JavaScript（文件扩展名 .ts/.tsx/.js/.jsx）
附加到 资深开发工程师 清单：
== 进行比较（应统一使用 ===）？async 函数内的 await 调用是否有 try/catch 或 .catch() 兜底？await 且未处理的 Promise（unhandled rejection）？as any 或 as SomeType 绕过了 TypeScript 的类型检查？?.）防止 null/undefined 错误？附加到 性能工程师 清单：
addEventListener）、定时器（setInterval）是否在组件销毁时清理？附加到 安全工程师 清单：
Object.assign/扩展运算符）？innerHTML/dangerouslySetInnerHTML/document.write 插入未转义的用户数据？localStorage/sessionStorage（明文存储）？SQL（文件扩展名 .sql，或包含内嵌 SQL 的变更）
附加到 性能工程师 清单：
EXPLAIN 验证，无全表扫描？附加到 安全工程师 清单：
各角色独立完成审查后，在写入汇总报告前必须执行去重合并，确保同一问题在汇总清单中只出现一次。
满足以下任意一条，判定为重复问题：
| 情形 | 处理方式 |
|---|---|
| ------ | ---------- |
| 多角色发现同一问题，级别相同 | 合并为一条，"发现者"字段列出所有角色，标注"多角色共同发现" |
| 多角色发现同一问题，级别不同 | 取最高级别，在备注中注明："X 角色认定为 Blocker，Y 角色认定为 Suggestion，取最高级别 Blocker" |
| 多角色对同一问题结论相反 | 保留分歧，不强制合并，在汇总清单"备注"列标注"存在角色分歧"，并在 Question 区块列出，供人工决策 |
| 问题相关但不完全相同 | 保留各自条目，但在备注中互相引用，便于阅读者关联理解 |
**[问题类别]** `file:line`：问题描述
- 发现者：架构师、资深开发工程师（多角色共同发现）
- 级别：🚫 Blocker（取架构师最高定级，资深开发定级为 Suggestion）
- 修改建议：...
> 📝 即时写入：去重合并完成后，立即将汇总问题清单追加写入飞书文档。
> 与步骤 4.3 的 graphify 使用区别：
> - 步骤 4.3（微观）：各角色审查过程中，针对单个变更函数做定向调用方查询，属于逐点验证
> - 测试工程师角色（测试视角）：在角色审查过程中，围绕测试范围、必测案例和覆盖缺口使用 graphify 识别直接/间接影响链路
> - 步骤 6（宏观）：所有角色完成审查后，对整个 MR 的模块级依赖图和调用链路做全局可视化分析，生成报告附件
步骤 6 在所有角色审查完成后执行一次，涵盖以下场景：
| 场景 | graphify 任务 | 输出 |
|---|---|---|
| ------ | -------------- | ------ |
| 核心链路修改 | 生成变更函数的完整调用图（上游调用方 + 下游依赖） | 调用链路图，标注影响边界 |
| 公共组件/工具类变更 | 分析全局调用方，检查是否引入循环依赖 | 依赖关系图，标注循环依赖风险点 |
| 接口/API 变更 | 追踪所有消费方（跨模块/跨服务） | 接口消费方清单，标注兼容性风险 |
graphify 输出必须作为 Review 报告的附件或引用，不能仅凭主观判断影响范围。
> 📝 即时写入：全局影响分析完成后，立即将 graphify 分析结论及影响范围追加写入飞书文档。
按下方【输出模板】生成综合结论，完成报告收尾。
此时飞书文档中已包含各步骤增量写入的内容（变更意图理解、各批次角色审查结论、汇总问题清单、全局影响分析），本步骤只需补充写入综合结论区块，无需重新创建文档。
收尾动作（必须同时执行）：
glab mr note 将审查结论（含飞书文档链接）回写到 MR 评论glab mr note <mr-id> --repo <project-path> --message "Code Review 完成，详细报告：<飞书文档链接>"
| 维度 | 负责角色 | 关注点 |
|---|---|---|
| ------ | ---------- | -------- |
| 架构合理性 | 架构师 | 模块边界、依赖方向、耦合度、可扩展性 |
| 正确性 | 资深开发工程师 | 逻辑正确性、边界条件、异常处理 |
| 影响范围 | 资深开发工程师 + 架构师 | 改动影响哪些模块、接口、业务功能 |
| 安全性 | 安全工程师 | OWASP Top 10、硬编码密钥、输入校验 |
| 兼容性 | 架构师 + 资深开发工程师 | 接口契约破坏、向下不兼容 |
| 性能 | 性能工程师 | 慢 SQL、N+1 查询、内存泄漏、并发竞争 |
| 可维护性 | 资深开发工程师 | 代码规范、高内聚低耦合、关键逻辑中文注释 |
| 测试覆盖 | 资深开发工程师 + 测试工程师 | 受影响路径是否有单元测试/接口测试/E2E 覆盖 |
| 测试范围 | 测试工程师 | 基于 graphify 调用链评估回归范围、必测案例、无需测试范围 |
| 产品对齐 | 产品经理（需 PRD） | 功能完整性、业务逻辑一致性、边界场景覆盖 |
综合结论判定标准：
### 📝 Code Review 报告
**基本信息**
- MR 分支：`<source-branch>`
- 目标分支：`<target-branch>`
- 变更文件数：`X`（批次数：`Y`，每批文件数：`Z`）
- 变更概要：`<简述改动意图>`
- PRD 文档：`<已提供 / 未提供>`
**综合结论**
- [ ] ✅ 通过，可以合并
- [ ] ⚠️ 有条件通过，修改后可合并
- [ ] ❌ 不通过，需修改后重新 review
> 综合结论由角色审查结论汇总得出：任意角色发现 Blocker → 整体不通过；无 Blocker 且 Suggestion ≤ 3 → 通过；无 Blocker 但 Suggestion > 3 → 有条件通过。
---
### 🔧 环境自检结果
| 工具 | 状态 | 说明 |
|------|------|------|
| git | ✅/❌ | <说明> |
| glab (安装) | ✅/❌ | <说明> |
| glab (认证) | ✅/❌ | <说明> |
| graphify | ✅/❌ | <说明> |
---
### 📌 变更意图理解
- 本次 MR 的业务目的：<基于 MR 描述/关联 Issue/PRD 的描述>
- 主要改动范围：<列出核心变更模块>
- 预期影响的业务功能：<列出可能受影响的功能>
---
## 🎭 分角色 Review 结果
### 🏛️ 架构师 Review
**架构风险评估**：`无问题 / 有隐患 / 有严重问题`
**🚫 Blocker（必须修改）**
1. **[架构]** `<file>:<line>`：问题描述
- 修改建议：<具体修复方向>
**⚠️ Suggestion（建议修改）**
1. **[架构]** `<file>:<line>`：问题描述
**💬 Question（讨论项）**
1. `<file>:<line>`：疑问描述
**✅ 架构亮点**
- <值得肯定的架构设计>
---
### ⚡ 性能工程师 Review
**性能风险评估**：`无问题 / 有隐患 / 有严重问题`
**🚫 Blocker（必须修改）**
1. **[性能]** `<file>:<line>`：问题描述
- 修改建议：<具体修复方向>
**⚠️ Suggestion（建议修改）**
1. **[性能]** `<file>:<line>`：问题描述
**💬 Question（讨论项）**
1. `<file>:<line>`：疑问描述
---
### 🔒 安全工程师 Review
**安全风险评估**：`无问题 / 有隐患 / 有严重问题`
**🚫 Blocker（必须修改）**
1. **[安全]** `<file>:<line>`：问题描述
- 修改建议：<具体修复方向>
**⚠️ Suggestion（建议修改）**
1. **[安全]** `<file>:<line>`：问题描述
**💬 Question（讨论项）**
1. `<file>:<line>`：疑问描述
---
### 👨💻 资深开发工程师 Review
**代码质量评估**：`无问题 / 有隐患 / 有严重问题`
**🚫 Blocker（必须修改）**
1. **[代码质量]** `<file>:<line>`：问题描述
- 修改建议：<具体修复方向>
**⚠️ Suggestion（建议修改）**
1. **[代码质量]** `<file>:<line>`：问题描述
**💬 Question（讨论项）**
1. `<file>:<line>`：疑问描述
**✅ 代码亮点**
- <值得肯定的实现>
---
### 🧪 测试工程师 Review
**测试风险评估**：`低风险 / 中风险 / 高风险 / 无法判断`
**graphify 证据**
- 调用链入口：<基于 graphify 识别的入口/API/任务/消费方>
- 直接影响：<直接受影响的模块/函数/接口>
- 间接影响：<依赖链路上的下游模块/外部系统/数据表>
- 已有测试覆盖：<已有测试文件/测试类型/覆盖链路>
- 覆盖缺口：<缺少测试的高风险路径>
**🚫 Blocker（必须修改或补充测试）**
1. **[测试]** `<影响点>`：缺少关键测试导致无法判断合并风险
- 必须补充：<单测/接口测试/E2E/手工验证要求>
**⚠️ Suggestion（建议修改）**
1. **[测试]** `<影响点>`：建议补充的测试或回归验证
**💬 Question（讨论项）**
1. `<影响点>`：需确认的测试边界或验收标准
**P0 必测案例**
1. 场景：<主流程/权限/数据一致性/跨模块链路>
- 前置条件：<账号、权限、数据、环境开关>
- 操作路径：<执行步骤>
- 预期结果：<可观察结果>
- 覆盖影响点：<graphify 调用链/依赖关系>
**P1 建议覆盖案例**
1. 场景：<异常流/边界值/兼容性/并发重试>
- 前置条件：<测试准备>
- 操作路径：<执行步骤>
- 预期结果：<可观察结果>
- 覆盖影响点：<graphify 调用链/依赖关系>
**P2 可选回归案例**
1. 场景：<低风险展示/文案/配置/只读路径>
- 回归理由：<为什么可选>
---
### 📋 产品经理 Review
**（无 PRD 时输出）**
> ⚠️ 因缺少 PRD 文档，本次未进行产品对齐 review。如需产品对齐审查，请提供 PRD 文档后重新执行。
**（有 PRD 时输出）**
**产品对齐评估**：`符合需求 / 部分偏差 / 严重偏离需求`
**🚫 Blocker（必须修改）**
1. **[产品]** `<功能点>`：与 PRD 的偏差描述
- 修改建议：<具体修复方向>
**⚠️ Suggestion（建议修改）**
1. **[产品]** `<功能点>`：问题描述
**💬 Question（讨论项）**
1. `<功能点>`：需和产品确认的疑问
---
## 📊 汇总问题清单（去重合并后）
| # | 发现角色 | 级别 | 位置 | 问题摘要 | 备注 |
|---|----------|------|------|----------|------|
| 1 | 架构师 | 🚫 Blocker | `file:line` | <摘要> | |
| 2 | 安全工程师、架构师 | 🚫 Blocker | `file:line` | <摘要> | 多角色共同发现 |
| 3 | 性能工程师 | ⚠️ Suggestion | `file:line` | <摘要> | |
| 4 | 架构师 vs 资深开发 | 💬 Question | `file:line` | <摘要> | 存在角色分歧，需人工决策 |
---
### 📋 测试人员专区：业务影响范围与测试建议
> 本区块由测试工程师基于 graphify 调用链、依赖图和现有测试覆盖情况生成，必须与"测试工程师 Review"结论保持一致。
**🔴 P0 必须测试（直接受影响）**
- **[功能名称]**
- 测试场景：<必须覆盖的主流程/权限/数据一致性/跨模块链路>
- 前置条件：<账号、权限、测试数据、环境开关>
- 操作路径：<操作步骤>
- 预期结果：<验证什么>
- 覆盖影响点：<graphify 调用链/依赖关系>
**🟡 P1 建议测试（间接受影响）**
- **[功能名称]**
- 影响原因：<为什么间接受影响>
- 测试场景：<异常流/边界值/兼容性/并发重试>
- 预期结果：<重点验证什么>
**🔵 P2 可选回归（低风险）**
- **[功能名称]**
- 回归理由：<为什么风险较低>
- 建议方式：<手工抽测/自动化回归/无需本次执行>
**🟢 无需测试（已确认不受影响）**
- **[功能名称]**：<基于 graphify 依赖边界或代码路径的排除原因>
**⚠️ 特别注意事项**
- <环境配置、兼容性场景、数据迁移、测试数据、外部依赖等>
---
### 💻 影响点与风险评估（面向开发）
**直接影响**：<直接修改的模块/函数>
**间接影响**：<调用链/依赖间接受影响的模块>
共 1 个版本