# Focused

> 专项 Review / Focused Review

- Skill: `z-zihan/focused` (Agent Skill)
- Install (CLI): `npx skillmds@latest add z-zihan/focused`
- Raw SKILL.md: https://api.skillmd.com/api/skills/z-zihan/focused/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: z-Zihan (https://skillmd.com/u/z-zihan)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/z-zihan/focused

---

## 专项 Review / Focused Review

### 触发条件 / When to Activate

**不会自动触发。** 仅在以下场景使用：

- 用户明确说明这是重要需求 / 专项需求（如"这是核心链路"、"这个需求优先级很高"）
- 用户提供具体的需求文档并要求针对该需求深入 review
- 二次 review 时用户对某个具体需求不放心，要求重点审查
- 用户明确说"专项 review"、"重点 review"、"仔细看一下 XX 功能"

**关键词识别**：专项、重点、仔细、重要需求、核心链路、这个需求很重要、不放心、仔细 review

### 与普通 Review 的区别 / Differences from Standard Review

| 维度 | 普通 Review | 专项 Review |
|---|---|---|
| 审查深度 | 覆盖整体变更，平衡广度和深度 | 聚焦指定需求，深度优先 |
| 边界情况 | 检查明显边界 | 主动穷举边界 case，列出完整清单 |
| 数据流 | 检查关键路径 | 逐层追踪完整数据流（输入→处理→存储→输出→展示） |
| 错误处理 | 检查显式 try-catch | 检查所有异常路径、降级策略、重试机制、错误兜底 |
| 并发/竞态 | 基本检查 | 深入分析竞态条件、资源竞争、时序问题 |
| 类型安全 | 基本检查 | 严格检查类型推导、null/undefined 传播、类型断言风险 |
| 向后兼容 | 基本检查 | 分析 API 兼容性、数据迁移、旧版本影响 |
| 测试覆盖 | 建议补充 | 逐条对照需求点，检查测试覆盖率和遗漏场景 |

### 专项 Review 流程 / Focused Review Process

#### Step 1 — 明确审查范围

确认以下信息（缺少则主动询问）：

- **目标需求**：具体是哪个功能/模块/需求点？
- **需求文档**：有没有需求文档、设计文档、接口文档？
- **关注点**：有没有特别担心的地方？（如并发、性能、数据一致性）
- **变更范围**：本次涉及的文件/模块有哪些？

#### Step 2 — 需求逐条对照

将需求文档中的每一条要求，与代码逐一对照：

```markdown
## 需求对照

| # | 需求点 | 代码位置 | 实现状态 | 备注 |
|---|--------|----------|----------|------|
| 1 | 具体需求描述 | 文件:函数 | ✅ 完整 / ⚠️ 部分 / ❌ 未实现 | 说明 |
```

- 每条需求必须给出明确的实现状态
- 部分实现要具体说明缺失了什么
- 如果没有需求文档，从代码和提交信息推断需求意图

#### Step 3 — 深度分析

针对目标需求，执行以下分析（根据需求类型选择重点）：

**功能完整性**：
- 是否覆盖了需求文档的全部场景
- 正常路径 + 异常路径 + 边界 case 是否都处理了
- 有没有硬编码的临时方案

**数据一致性**：
- 读写是否有竞态风险
- 事务/锁是否正确使用
- 缓存与数据库的一致性
- 并发写入时的幂等性

**错误处理**：
- 每个可能失败的操作是否有兜底
- 错误信息是否有用（对排查问题有帮助）
- 失败后是否有重试/降级机制
- 是否有静默失败（吞掉错误不处理）

**性能影响**：
- 是否引入新的 N+1 查询、大循环、频繁 IO
- 是否有不必要的数据加载（如全量查询后只取几条）
- 高频调用路径是否有性能隐患

**安全性**：
- 输入校验是否完整
- 是否有注入风险（SQL、XSS 等）
- 权限校验是否到位

**向后兼容**：
- API 变更是否影响已有调用方
- 数据结构变更是否有迁移方案
- 配置项变更是否有默认值兜底

#### Step 4 — 边界情况穷举

针对目标需求，主动思考并列举所有可能的边界情况：

```markdown
## 边界情况检查

| # | 场景 | 预期行为 | 代码处理 | 风险 |
|---|------|----------|----------|------|
| 1 | 空数据/零值 | ... | ✅ 已处理 / ❌ 未处理 | ... |
| 2 | 并发操作 | ... | ... | ... |
| 3 | 超大数据量 | ... | ... | ... |
```

主动考虑但不限于：
- 空值、null、undefined、零、空数组、空字符串
- 并发/重复操作（重复点击、重复提交）
- 超长输入、特殊字符、非法参数
- 网络异常、超时、服务不可用
- 权限不足、未登录态
- 数据不存在、已删除
- 分页边界（第一页、最后一页、空页）

#### Step 5 — 输出专项报告

专项 Review 使用专属报告格式（替代普通 Review 报告）：

```markdown
## 专项 Review 报告

**审查需求**: [需求名称/描述]
**变更范围**: [涉及的文件/模块]
**审查结论**: 可直接合入 / 修复后合入 / 建议进一步验证

### 需求完成度

[Step 2 的需求对照表]

### 边界情况

[Step 4 的边界情况检查表]

### 需要修复的问题

[同普通 Review 格式]

### 建议关注（可选改进）

[同普通 Review 格式]

### 测试建议

| 优先级 | 测试场景 | 测试方法 | 原因 |
|--------|----------|----------|------|
| P0 | 核心路径 | ... | ... |
| P0 | 关键边界 | ... | ... |
| P1 | 异常路径 | ... | ... |

### 最终结论

详细说明 + 是否可合入。
```

### 注意事项

- 专项 Review **只聚焦用户指定的需求**，其他变更用普通 Review 标准处理
- 不要因为"专项"就对非目标需求过度审查，避免把简单改动复杂化
- 如果用户没有提供需求文档，在报告中标注"⚠️ 无需求文档，以下分析基于代码推断"
- 边界情况不需要全部都覆盖，优先列出**对功能正确性有实际影响**的，避免为了"穷举"而列无意义场景


> 问题格式同主 Review 报告 §3（无影响变更/建议关注/需要修复），不再重复定义。