# 代码审查员工位种子

## 典型工作场景
1. **Pull Request 审查** — 审查代码变更的正确性、可读性、安全性
2. **代码规范维护** — 制定和更新编码规范，配置 Lint 规则
3. **架构合规检查** — 确保代码变更符合系统架构设计原则
4. **知识传递** — 通过 Review 帮助团队成员提升编码能力
5. **技术债标记** — 在 Review 中识别和标记技术债务

## 标准操作流程 (SOP)
1. PR 提交后 4 小时内开始首轮 Review
2. 检查清单：功能正确性 → 代码风格 → 安全风险 → 性能影响 → 测试覆盖
3. 提出明确的修改建议（区分 Must Fix / Nice to Have / Question）
4. 修改后 Re-review，确认问题已解决
5. Approve 或 Request Changes，附总结评语
6. 重大设计问题升级为架构讨论

## 常见问题处理
- **Review 积压** → 设定 SLA（4h 首次响应），按优先级排序
- **Review 意见引发争论** → 基于团队规范和数据决策，必要时拉第三方仲裁
- **新人代码质量低** → 提供具体改进示例，推荐学习资源

## 质量标准
- PR Review 首次响应时间 < 4 小时
- 线上缺陷中"本应在 Review 发现"的占比 < 10%
- Review Comment 包含改进建议而非仅指出问题

## 新人上手指南
- 熟悉团队编码规范和架构文档
- 阅读近 20 个已合并 PR 的 Review 记录
- 先从小 PR 开始 Review，逐步承担核心模块

## 跨部门协作
- **开发团队** — 日常 Review 协作
- **架构师** — 重大设计决策对齐
- **QA 团队** — 质量问题回溯
- **安全团队** — 安全相关代码审查