---
name: dev-tech-view-supplement
description: 根据设计补充Dev视角的技术细节（数据库/API/通信协议），帮助Dev快速进入实施。当L1/L2设计缺乏技术细节、或准备向Dev交付前使用。
stage: DESIGN
level_supported: [L1, L2, L3]
---

## dev-tech-view-supplement: Dev技术视图补充

### 描述
根据设计文档中的业务语言和架构信息，补充 Dev 视角的技术细节视图。由于 L1/L2 受 CRAFT 的 80% 业务语言约束，技术细节可能不足，导致：
- Dev 收到设计后需要频繁向设计人员问询"数据库怎么设计？""API 有哪些 endpoint？"
- Dev 浪费时间推导技术细节，而不是专注实施
- 设计交接效率低

此 SKILL 补充 Dev 需要的技术视图，加速 DESIGN → IMPLEMENTATION 交接。

### 适用场景
- **WORKFLOW_STEP_4 Task S4-2 Round 2**：生成所有 artifacts 后，为 Dev 补充技术视图
- **WORKFLOW_STEP_4 Task S4-7**：准备向 Dev 团队交付设计时，补充技术细节
- **Dev 反馈场景**：如果 Dev 反馈"设计缺乏实施细节"或"不知道数据库怎么设计"时
- **L1/L2 特定**：L1/L2 受 CRAFT 的 80% 业务约束，此 SKILL 补充技术视图
- **技术栈确认**：在 DESIGN 确认了技术栈后，需要具体的技术设计指导

### 输入
- `spec/design/` 目录（所有 VS/SD/DM/ARCH/ADR）
- `spec/requirements/` 目录（US/NFR，特别是 NFR 中的性能/安全/可扩展性需求）
- 当前级别（L1/L2/L3）
- 项目类型（Web/Mobile/API/CLI 等，从 SPEC_PRJ_DESC 推断）

### 输出
- **Dev 友好的技术细节补充文档**（markdown）
- **数据库设计概览**
  - 主要表清单（表名、用途）
  - 关键字段清单（不需要完整 schema，只需关键字段）
  - 主要索引（哪些字段需要索引及为什么）
  - 数据关系（表之间的关联）
- **API 设计清单**
  - 主要 endpoint 列表
  - 请求/响应格式概览
  - 常见的参数和返回值
- **通信协议选择**
  - 同步 vs 异步决策原因
  - 选择 REST/GraphQL/gRPC 的理由
  - 错误处理策略概览
- **技术栈与模块映射**
  - 哪个模块用什么技术
  - 依赖库选择和理由
- **NFR 技术实现细节**
  - 性能优化方案（缓存策略、索引等）
  - 安全加固方案（认证、加密、权限等）
  - 可扩展性方案（分片、负载均衡等）
- **常见 Dev 问题解答**（FAQ 形式）

### 执行策略
1. **提取已有的技术信息**：
   - 从 ARCH 读取架构层次（前端/后端/数据库 等）
   - 从 ADR 读取已做的技术决策
   - 从 DM 读取数据模型（有助于推导数据库设计）
   - 从 DESIGN artifacts 读取 entry_points 和 value_path

2. **从 NFR 提取技术需求**：
   - 性能 NFR：并发数、响应时间、数据量 → 推导缓存、索引、分片策略
   - 安全 NFR：认证、加密、权限 → 推导安全加固方案
   - 可扩展性 NFR：未来用户量、数据量增长 → 推导分层、负载均衡策略

3. **补充 Dev 需要的技术细节**：
   - **数据库**：
     - 列出主要表（从 DM 推导）
     - 关键字段（哪些字段必须有、哪些可选）
     - 主要索引（基于 NFR 的性能需求）
     - 数据关系（一对多、多对多）
   - **API**：
     - 列出主要 endpoint（基于 VS 的 value_path）
     - 请求格式（GET/POST 等，参数）
     - 响应格式（成功/失败 HTTP code，数据结构）
   - **通信**：
     - 同步 vs 异步（基于 NFR 的实时性需求）
     - 协议选择（基于 ARCH 的技术栈）
     - 错误处理（如何处理超时、重试）
   - **技术栈**：
     - 前端框架/库选择和理由
     - 后端框架/库选择和理由
     - 数据库选择和理由
   - **性能/安全/扩展**：
     - 缓存策略（什么数据缓存、缓存多久）
     - 索引策略（哪些查询频繁、需要加索引）
     - 安全策略（认证、授权、数据加密）
     - 扩展策略（如果用户/数据增长 10 倍怎么办）

4. **确保水位合理**：
   - L1：精简版（仅列出主要数据库表、API endpoint、技术栈理由）
   - L2：标准版（上述内容 + 索引、缓存、安全策略）
   - L3：详细版（上述内容 + NFR 推导过程、性能测试建议、扩展方案细节）

5. **生成 Dev 友好的格式**：
   - 用表格、清单、图表，而不是长段落
   - 用代码示例（JSON 格式的请求/响应，SQL schema 概览）
   - 用 FAQ 解答常见 Dev 问题

### 价值
- **Dev**：快速理解技术设计，减少与设计人员沟通的往返，加速开发启动
- **Tech Lead**：为 Dev 补充 80%/20% 约束下缺失的技术视图，确保实施质量
- **设计人员**：不需要在 IMPLEMENTATION 阶段频繁被 Dev 打断，专注后续设计
- **交接效率**：减少 DESIGN → IMPLEMENTATION 的沟通成本和延误

### 验收标准
| 指标 | L1 | L2 | L3 |
|------|----|----|-----|
| **覆盖范围** | 主要表、endpoint、技术栈 | + 索引、缓存、安全 | + NFR推导、性能/扩展细节 |
| **内容完整性** | ≥80% Dev 问题有答案 | ≥90% Dev 问题有答案 | ≥95% Dev 问题有答案 |
| **交接时间** | Dev 理解时间 <2h | Dev 理解时间 <1h | Dev 理解时间 <30min |
| **技术精准度** | 概览准确，细节允许Dev微调 | 大部分精准，少量细节调整 | 精准可直接用于实施 |