| name | code-detailed-design |
| description | 把业务设计转成模块、接口、数据和实现方案。Invoke after business design is accepted and before coding starts. |
Code Detailed Design
目标
在整体架构、业务设计和技术选型确定后,输出可直接指导编码的详细设计。
状态规则
- 当前状态固定输出为:
详细设计中
- 本阶段属于中高参与阶段,遇到明显不同的技术方案时必须向用户说明取舍并请用户拍板
- 所有选型、接口风格、库表方案、事务策略、并发策略、测试策略,都必须尽量以选择题形式呈现
选择式决策协议
技术方案存在明显分歧时,必须使用以下格式:
当前状态:详细设计中
当前目标:确认本轮技术设计选择
我的推荐:方案 A
推荐理由:...
请你做选择:
1. 方案 A(推荐) - 成本...,收益...,风险...
2. 方案 B - 成本...,收益...,风险...
3. 方案 C - 成本...,收益...,风险...
你确认后,我会:...
必须覆盖的设计内容
- 模块划分与职责边界
- 类、函数、服务、任务拆分
- 接口设计
- 请求响应结构
- 数据模型与字段设计
- 库表设计与 SQL 草案
- 关键流程时序
- 数据流向(技术层)
- 事务边界
- 并发、锁、幂等、重试策略
- 权限控制与安全落点
- 异常处理实现计划
- 日志、监控、审计、埋点计划
- 测试策略与测试点
- 详细编码计划
- 变更影响范围
- 回滚或降级思路
输出契约
必须在 业务设计 目录输出详细设计文档,或在其中明确区分“业务设计”和“详细设计”两个部分。
文档中至少要有一个“关键技术决策清单”章节,并采用选择题形式记录推荐项、备选项和最终选择。
回退规则
- 若发现业务规则不成立或缺失,应回退到
business-design
- 若发现对项目现状理解错误,应回退到
repo-investigation
禁止事项
- 禁止没有职责边界就开始编码
- 禁止没有失败路径和异常处理就开始编码
- 禁止只写 happy path