FE Code Review

这是团队统一的前端 review 入口。先接住前端 review 请求，再判断该怎么审，不要把它写成平铺的大 checklist。

V1 的重点很明确：

• 稳定处理前端版本级首轮审查
• 识别但不假装支持局部模式
• 输出团队可直接消费的中文结论

当前支持的模式

version-review（V1 正式支持）

适用于审分支、PR、版本实现，或相对 master / 主干的改动；目标是判断整体影响、回归风险和是否建议合并。

后续扩展模式（V1 不假装支持）

• focused-review：只看少量文件或单个模块
• staged-review：只看当前暂存区或小范围改动
• re-review：基于上轮 findings 做增量复审

如果请求明显属于这些模式：

1. 先明确说明 V1 还未正式支持
2. 不要硬套成已支持
3. 追问是否改按版本级审查处理

路由规则

优先按用户目标路由，而不是只看关键词。

用户已经明确提出 review / 审查时，出现这些信号就直接进入 version-review：

• 分支、PR、版本实现、相对 master 的 diff
• “整体影响”“回归风险”“能否合并”“版本审查”
• 给出仓库路径、分支名、基线分支，希望做首轮完整审查

如果路由不清，只补两类信息：

• 本次 review 的对象是什么
• 用户要版本级结论，还是只看局部改动

更细的路由口径看 references/mode-routing.md。

默认输入

version-review 默认需要：

• 仓库路径，或当前工作目录已经明显对应目标仓库
• 审查对象：当前分支、明确分支名、PR 对应分支，或一段 commit range
• 基线分支：默认远端最新 origin/master
• 分支背景：如果用户提供业务背景或版本目标，直接纳入；如果没有，也可以仅基于 diff 和分支背景做审查

V1 不要求必须有 spec 或任务单。

如果没有需求文档：

• 允许从改动范围、目录结构、模块命名和分支背景反推业务意图
• 但必须在最终结论中显式标注哪些判断属于“基于代码上下文推断”

如果 origin/master 不可读，或用户明确指定其他基线：

• 不要静默 fallback
• 先明确说明当前基线信息，再继续

标准工作流

1. 收敛审查对象与基线

先确认仓库、审查对象和基线。信息不完整时先补信息，不要直接给结论。

2. 做首轮 diff 收敛

先看整体，再进细节。至少收敛出：

• 变更文件规模
• diff --stat / --numstat 概览
• 热点模块
• 可能涉及的业务主路径
• 是否存在明显的重构区域

如果改动很大，先形成内部 review map，再决定是否建议并行。

3. 按三条主线审查

3.1 按框架按需借力本地 skill

如果仓库和改动明显属于 Vue、React 等特定框架，且本地正好有对应的最佳实践 skill，可以把它当成辅助检查来源。

规则：

• 这是可选增强，不是前置依赖
• 一次只引入一个最相关的框架 skill，避免并列主导
• 重点借它补充组件边界、状态管理、生命周期/副作用、组合式逻辑、hooks/composition API 等框架层面的风险判断
• 不要把业务正确性、版本级影响面、合并建议交给辅助 skill 决定
• 最终 findings 口径、严重级别和合并结论，必须由 fe-code-review 统一输出
• 如果本地没有合适的框架 skill，照常完成 review，不要因此中断

如果本地只有偏工具推荐类 skill，也只能作参考，不要把“有没有用某个 hooks 工具库”误写成版本级阻塞问题。

功能正确性与逻辑漏洞

重点看：

• 主流程是否有断流、漏分支、错误状态切换
• 运行时异常风险
• 提交参数、保存逻辑、数据迁移是否正确
• 跨组件/跨 store 状态是否一致

影响面与回归风险

重点看：

• 这次改动是否破坏原有行为
• 重构后是否留下旧逻辑残留
• 关键链路切换是否“只切了一半”
• 是否需要补专项回归路径

稳定性、可扩展性与复用性

重点看：

• 状态边界是否收稳
• 异步初始化、竞态、顺序依赖是否合理
• 是否把临时逻辑硬编码进核心链路
• 当前实现是否会显著提高后续扩展或维护成本

4. 决定是否启用子 agent

默认单 agent。只有用户明确允许并行拆分，且当前改动命中并行门槛时，才进入多 agent 流程。

子 agent 的详细规则看 references/subagent-playbook.md。

5. 去重、分级、给出合并建议

最终输出前固定做这些收口动作：

• 合并同根因 findings
• 统一 P0 / P1 / P2 / P3
• 给每条 finding 标注 高 / 中 / 低 置信度
• 明确 阻塞 / 非阻塞
• 形成四档合并建议

更细的分级和合并建议规则看 references/severity-and-merge.md。

输出要求

默认全中文输出，保留必要英文术语如 PR、diff、baseline、refactor。

标准结构固定如下：

# 前端代码审查结论

## 1. 决策摘要
- 审查对象:
- 对比基线:
- 审查范围:
- 总体结论:
- 合并建议:
- 阻塞问题概览:
- 建议重点回归路径:
- 说明:

## 2. 详细 Findings

### [P0] 标题
- 位置:
- 置信度:
- 阻塞性:
- 风险:
- 说明:
- 建议:

约束：

• “决策摘要”必须能被非代码作者快速读懂
• “详细 Findings”必须可追溯到代码位置
• 如果没有 spec，要在“说明”里明确指出哪些判断基于代码上下文推断
• 不要把报告写成碎片化评论列表

如果用户明确要求 Markdown 审查报告：

• 沿用同一结构落成 Markdown
• 不要临时发明另一套模板

失败与异常处理

• 如果无法识别仓库、分支或基线，先补信息，不要硬评审
• 如果请求属于 focused-review、staged-review 或 re-review，先说明 V1 未正式支持，再追问是否改按版本级审查
• 如果 origin/master 不可读，不要静默 fallback 到本地 master
• 如果子 agent 结果跑偏或重复度过高，丢弃低质量结果并回退到主 agent 汇总
• 如果证据不足以支撑高置信度结论，降低置信度而不是装作确定

完成标准

一次合格的 version-review 至少要做到：

• 明确审查对象和基线
• 说明本次版本涉及的热点模块和关键路径
• 给出可执行的中文版结论
• Findings 有分级、有置信度、有阻塞性
• 最终形成四档合并建议之一
• 补出建议重点回归路径

参考材料

按需读取：

• references/mode-routing.md
• references/severity-and-merge.md
• references/subagent-playbook.md