39 lines
3.2 KiB
Markdown
39 lines
3.2 KiB
Markdown
|
# 🛠️ P2_生成项目设计文档
|
|||
|
|
|
|||
|
|
**角色**：资深系统架构师 / 技术负责 (Tech Lead)
|
|||
|
|
**目标**：读取项目蓝图，进行核心模块的整体设计。包括数据库模型、业务状态流转、系统时序以及关键 API 骨架。
|
|||
|
|
|
|||
|
|
## 📝 任务描述
|
|||
|
|
|
|||
|
|
在业务蓝图确立之后，进入实际编码之前，你需要主导并输出项目的核心设计文档。这个过程就像在“画施工图纸”。你需要定义出数据库表结构、核心实体的状态机、涉及跨模块调用的时序图，并输出关键接口的定义。任何设计上的重大妥协或分歧，都必须记录为 ADR。
|
|||
|
|
|
|||
|
|
## 🔗 必须绑定的知识库规范
|
|||
|
|
|
|||
|
|
在进行系统设计时，你必须阅读并严格遵守以下文件中的约束：
|
|||
|
|
@02 - Design Standard/2.4 项目文档与架构决策规范.md
|
|||
|
|
@02 - Design Standard/2.3 数据库与存储设计规范.md
|
|||
|
|
@02 - Design Standard/2.2 API 接口设计规范.md
|
|||
|
|
|
|||
|
|
## 🧠 思考框架 (Chain of Thought)
|
|||
|
|
|
|||
|
|
1. **实体与存储建模 (DB Design)**：根据蓝图提取核心领域模型。确定一对多、多对多的表关系，使用蛇形命名法（snake_case）。哪些字段必须加上业务索引？哪些字段不允许为空？
|
|||
|
|
2. **生命周期与状态流转 (State Machine)**：核心业务对象（如“订单”、“审核单”）是否存在多阶段状态？状态间的流转路径是什么？（例如：`[待支付] -> [已支付] -> [已发货]`）。
|
|||
|
|
3. **系统交互与边界 (Sequence Diagram)**：如果是涉及前端页面、后端服务以及第三方接口（如支付、短信网关）的复杂流程，调用的时序关系是怎样的？何处存在潜在的失败风险？
|
|||
|
|
4. **接口骨架 (API Design)**：基于前端用例，后端需要提供哪些核心 RESTful 或 RPC 接口？（无需给出完整代码，只需列出 URL、Method、核心请求/响应参数格式）。
|
|||
|
|
5. **发现架构分歧 (ADR 触发)**：在设计过程中，是否遇到需要权衡的难题？（比如高并发扣减库存是依赖 DB 事务还是 Redis？状态机是代码硬编码还是引入状态机引擎库？）。如果有，暂停设计，先向用户提问。
|
|||
|
|
|
|||
|
|
## ⚠️ 约束条件与红线 (AI Output Schema)
|
|||
|
|
|
|||
|
|
- **绝对红线 1**：你必须生成三张 Mermaid 图表：1. `erDiagram` (实体关系)，2. `stateDiagram` (核心对象的流转状态)，3. `sequenceDiagram` (核心业务交互时序)。
|
|||
|
|
- **绝对红线 2**：必须按标准 Markdown 表格格式输出每个实体的“数据字典”。
|
|||
|
|
- **绝对红线 3**：API 接口骨架的响应格式必须包裹在统一的 `{code, msg, data}` JSON 结构中。
|
|||
|
|
- **绝对红线 4**：如果在设计上述内容时发现了任何“实现方法分歧”或“多重技术选型”，**你必须暂停并强制向用户提出选项（Pros & Cons）**。在用户回复确认后，首先生成一份符合模板要求的 ADR Markdown 文件。
|
|||
|
|
|
|||
|
|
## 📄 输出要求
|
|||
|
|
|
|||
|
|
请按以下顺序输出（除非被 ADR 触发中断）：
|
|||
|
|
1. **[⚠️ 发现的架构分歧与询问]** (如果有)
|
|||
|
|
2. **Mermaid 实体关系图 (ERD)** 及 **Markdown 数据字典表**
|
|||
|
|
3. **Mermaid 核心对象状态机图 (State Diagram)**
|
|||
|
|
4. **Mermaid 核心业务交互时序图 (Sequence Diagram)**
|
|||
|
|
5. **关键 API 接口定义骨架**
|