PRD到技术设计文档

PRD 转技术设计时，常见失败不是“不会设计”，而是需求还没对齐就扫描代码、脑补业务规则、沿用错误的项目约定，最后产出一份看似完整但落不了地的文档。这个技能把流程拆成强制阶段，先识别输入和场景，再解析需求、感知代码库、澄清歧义，最后才进入模块、API、数据库与架构设计。

它解决什么问题

PRD 经常缺少关键约束：状态流转、角色权限、唯一键、并发冲突、历史数据处理、数据量级、幂等要求。如果直接开写，很容易把猜测写成设计。技能的核心规则是：遇到 PRD 未明确的信息立即停止，用结构化方式一次性提问；提取不到的信息标注 [未提及]，不编造。

另一个问题是场景混淆。给已有流程加一个审批、给所有模块统一加审计、重构一个大 Service，与从零搭建新模块的设计强度完全不同。技能要求先做场景分类，再决定输出范围。

它如何工作

流程分为十个 Phase，关键链路如下：

• Phase 1 问题识别：先分析输入形态，区分 PRD 文件、口头描述、一句话需求；不扫描代码，先做场景关键词预判。
• Phase 2 解析需求：识别 .pdf、.docx、.md、.txt 或文字输入，提取业务规则、实体、状态、非功能需求，输出清单等待确认。
• Phase 3 代码库感知：基于已确认实体做定向扫描，再补全项目结构、技术栈、配置、Entity/Service/Controller、API 前缀、响应包装、审计字段和命名约定，形成项目感知卡片。
• Phase 4 场景分类：判定是全新功能、增量改造、横切机制还是重构优化，并输出结论供确认。
• Phase 5 澄清歧义：按 11 项通用检查提问，再按场景追加存量数据、兼容性、生效范围、等价性、回滚与风险等问题，一次提完，不超过 10 个一批。
• Phase 6 模块设计：划分领域，说明模块职责、聚合根、实体、领域服务、依赖；对含状态流转的实体强制画状态机，每个变迁必须有触发条件。
• Phase 7 API 设计：按资源建模给出 URL、方法、请求/响应字段级结构、排序分页默认值和硬上限、错误码编码。
• Phase 8 数据库设计：输出 ER 关系、CREATE TABLE 逻辑、索引设计、数据量预估；API 与表结构要交叉校验，状态枚举和字段名不匹配时标注待对齐。
• Phase 9 架构设计：描述分层、Service 职责、核心调用链，并为关键流程中的至少 3 条决策路径画时序图，覆盖异常分支和边界条件。
• Phase 10 资产交接：把项目感知、澄清结论、模块/API/DB/架构设计打包给对应场景子 Skill，由子 Skill 按模板输出文档和增量资产。

适用边界与注意点

它适合已经有代码库的后端项目，尤其是需要把 PRD 转成可评审设计文档的场景。它不是需求挖掘工具，无法替 PRD 补齐业务目标；也不能替代性能测试。数据量分表阈值、数据库选型和索引效果仍要结合真实硬件、查询模式和数据库类型验证。重构场景只改内部架构时，应确认外部行为是否允许变化，并准备验证与回滚策略。