说明：本文面向个人开发者，目标是用最少但关键的图表把需求边界、核心对象、数据库结构、关键交互一次讲清，减少返工。
个人项目最容易走进一个循环：想到就写 -> 写着写着发现边界不清 -> 数据结构反复改 -> 关键流程靠猜 -> 最后大返工。
解决方式不是写更长的文档，而是用”最少但关键”的图表在编码前把关键不确定性消掉。
本文提供两件事：
你只需要按顺序回答几个问题：是否有数据库？复杂度如何？外部集成多吗？是否有状态变化？是否有多步跨组件交互？
flowchart TD
Start([开始新项目]) --> Qdb{有数据库吗?}
Qdb -->|是| ER[ER 图: 必画]
Qdb -->|否| Qc
ER --> Qc{系统复杂度?}
Qc -->|简单| S[简单: 用户故事 + 思维导图 + 领域模型 + （ER 如有 DB）]
Qc -->|中等| M[中等: 在简单基础上 + 用例图（>5 功能）+ 状态机（有状态）+ 时序图（多步交互）]
Qc -->|复杂| C[复杂: 在中等基础上 + C4（多外部集成）+ 活动图/数据流图（仅在优化时）]
决策树的价值不在于”画什么”，而在于”什么时候停”。你可以用下面 3 条停止条件判断是否该收手开始编码：
| 停止条件 | 你应该能做到 | 常用图表 |
|---|---|---|
| 边界清晰 | 1 分钟讲清系统边界与角色 | 用户故事/用例图 |
| 对象稳定 | 说清核心对象、关系、约束 | 领域模型 |
| 关键路径可走通 | 能按顺序走一遍关键流程，知道失败怎么处理 | 状态机/时序图 |
提示：如果你做不到以上任意一条，不要急着写代码，先补最能消除不确定性的那张图。
| 图表 | 必需? | 何时用 | 何时跳过 | 耗时 |
|---|---|---|---|---|
| 用户故事 | 必需 | 所有项目 | 不要跳过 | 30 分钟 |
| 思维导图 | 必需 | 项目启动梳理模块 | 不要跳过 | 30-60 分钟 |
| 领域模型 | 必需 | 定义核心业务对象 | 不要跳过 | 1-2 小时 |
| ER 图 | 必需(有 DB) | 需要数据库表结构 | 无 DB 项目 | 1-2 小时 |
| 用例图 | 条件 | 功能多(>5)/需对齐边界 | 简单小工具 | ~1 小时 |
| C4(System Context) | 条件 | 外部集成多、边界复杂 | 无外部依赖 | ~30 分钟 |
| 状态机图 | 条件 | 订单/审批/工作流等状态变化 | 无状态实体 | 30-60 分钟 |
| 时序图 | 条件 | 多步流程且跨组件交互 | 单组件简单流程 | 1-2 小时 |
| 活动图 | 可选 | 优化复杂分支/流程控制 | 逻辑不复杂 | ~1 小时 |
| 数据流图 | 可选 | 数据流动/处理链路复杂 | 数据链路清晰 | ~1.5 小时 |
必需图表：
建议：
在”简单项目”的基础上，按触发器补图：
| 触发器 | 常见风险 | 建议补的图 |
|---|---|---|
| 功能多（>5 个主要功能） | 边界不清、漏需求、沟通成本高 | 用例图 |
| 有状态变化（订单/审批/工作流） | 状态遗漏、转移规则写散、异常难补 | 状态机图 |
| 多步交互（>3 步且多模块参与） | 调用顺序出错、失败分支漏掉、集成返工 | 时序图 |
建议策略：
| 类别 | 内容 |
|---|---|
| 默认必备 | 用户故事 + 思维导图 + 领域模型 + (有 DB 就 ER) |
| 触发器加图 | 功能多 -> 用例图；外部集成多 -> C4；有状态 -> 状态机；多步交互 -> 时序图 |
| 留到优化再画 | 活动图/数据流图 |
| 检查项 | 通过标准 |
|---|---|
| 用户故事 | 3-5 个角色；每个角色 2-3 个故事；每个故事有价值目标 |
| 思维导图 | 模块分组清晰；分支不爆炸（5-9 个主分支） |
| 领域模型 | 核心实体齐全；关系基数明确；关键约束清楚 |
| ER 图（如有 DB） | 主键/外键/索引基本齐；字段类型合理 |
| 状态机（如有状态） | 状态完整；转移触发条件明确；异常路径可收敛 |
| 时序（如多步交互） | 关键流程 2-3 条；返回值与失败分支标注清楚 |