功能设计
功能设计就是把“要做什么”翻译成技术团队能照着做的说明书：字段是什么、规则怎么定、流程怎么走、出错怎么办。
功能规格包含什么
Section titled “功能规格包含什么”| 部分 | 回答的问题 |
|---|---|
| 字段 | 这个功能涉及哪些数据项？ |
| 规则 | 每个字段有什么限制和逻辑？ |
| 流程 | 用户和系统的操作按什么顺序走？ |
| 异常 | 出错、超时、没权限时怎么办？ |
四样写全，开发才不会来回问，测试才有依据。
字段与规则表
Section titled “字段与规则表”每个功能先列一张字段表。模板如下。
| 字段名 | 类型 | 是否必填 | 默认值 | 校验规则 | 说明 |
|---|---|---|---|---|---|
| 字段名 | 文本/数字/日期/枚举 | 是/否 | 空或具体值 | 具体判断条件 | 业务含义 |
示例（手机号字段）：
| 字段名 | 类型 | 是否必填 | 默认值 | 校验规则 | 说明 |
|---|---|---|---|---|---|
| 手机号 | 文本 | 是 | 空 | 11 位数字，且以 1 开头 | 用户登录账号 |
| 验证码 | 文本 | 是 | 空 | 6 位数字，5 分钟内有效 | 短信验证码 |
| 是否记住登录 | 布尔 | 否 | 否 | 无 | 勾选后下次免登录 |
规则要写成“能判定对错”的话。别写“手机号要合法”，要写“11 位数字且以 1 开头”。
先用箭头链把主流程画出来（文字版）：
打开登录页 → 输入手机号 → 点击获取验证码 → 输入验证码 → 点击登录 → 校验通过 → 进入首页
如果流程里有状态变化，再补一张状态迁移表。
示例（订单）：
| 当前状态 | 触发动作 | 下一个状态 | 说明 |
|---|---|---|---|
| 待支付 | 用户完成支付 | 已支付 | 收到支付回调后变更 |
| 待支付 | 超时未支付（30 分钟） | 已取消 | 系统自动关闭订单 |
| 已支付 | 商家发货 | 已发货 | 记录物流单号 |
| 已发货 | 用户确认收货 | 已完成 | 交易结束 |
| 已支付 | 用户申请退款 | 退款中 | 需商家审核 |
| 退款中 | 商家同意退款 | 已退款 | 原路退回 |
要点：
- 每个状态要说清“谁能触发”。
- 每个状态要说清“能不能撤回、超时会怎样”。
- 状态名全程统一，页面文案、数据库、接口都用同一套。
正常流程谁都会写，异常才见功夫。
| 场景 | 处理方式 |
|---|---|
| 网络失败 | 提示“网络异常，请重试”，保留已填内容，不丢数据 |
| 重复提交 | 按钮点击后置灰，接口做幂等，同一请求只处理一次 |
| 权限不足 | 提示“没有操作权限”，隐藏或禁用无权入口 |
| 空数据 | 展示空状态文案（如“暂无订单”）和引导操作，不显示空白页 |
| 超时 | 请求超时给出明确提示，关键操作可重试 |
原型与交互说明
Section titled “原型与交互说明”原型图（草图或设计稿）要标清楚：
- 页面上每个元素的位置和名称，名称要和字段表一致。
- 按钮点击后去哪儿、弹什么框。
- 有几种状态（默认、加载中、成功、失败、空）各长什么样。
交互说明要写清：
- 点击、滑动、返回分别发生什么。
- 必填项没填、格式不对时提示什么。
- 操作是否可撤销、是否需要二次确认。
开发前把下面这些交给技术团队，缺一项就容易返工。
- 功能说明：做什么、为什么做
- 字段与规则表
- 主流程（箭头链）
- 状态迁移表（有状态的才需要）
- 异常与边界处理表
- 原型图与交互说明
- 验收标准