tikazyq/dev-tech-view-supplement

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微调 | 大部分精准，少量细节调整 | 精准可直接用于实施 |