把需求写成设计说明
让接手的开发者不用问你就知道怎么做
把下面这个需求写成设计说明（不含代码）。包含：1）用户要完成的动作，按步骤；2）每一步的界面元素与状态；3）异常与边界情况；4）不做什么（明确的排除项）；5）验收标准。 [粘贴需求]
适合什么场景
- 需求在自己脑子里很清楚，但要交给不熟悉背景的开发或外包——把动作顺序、每步状态、排除项写死，能省掉一大半来回确认。
- 需求评审前先自查漏洞——写说明的过程会暴露「异常情况根本没想过」的地方，比在会上被问住好。
不适合的场景
- 需求还在探索、可能整个推翻——此时写详细说明是给废案做精装，先用低保真草图对齐方向。
- 涉及强技术约束（性能上限、第三方接口限制）而你并不了解——说明会写出做不到的方案，应先跟开发对一次可行性。
示例
输入
做一个「发票抬头管理」：用户能存常用抬头，下单时选一个，也能临时新增
你会得到
按步骤写清：进入订单页、点「选择抬头」、列表带默认项标记、选中后返回并回填。异常覆盖抬头为空、超过 20 条上限、税号格式错、并发修改四种。排除项明确写出不做编辑历史、不做工商信息自动校验。验收标准写成可勾选的句子，例如「返回订单页时抬头已回填且不可直接编辑」。
常见误用
- 只写正常流程，异常与边界留白——开发只能自己猜，问题拖到联调才暴露，返工成本最高。
- 把「不做什么」当成可选项省略——没写排除项，开发会按自己的理解补功能，范围和工期一起失控。
可以这样改
- 把「不做什么」提到第 1 条并要求给出理由——先划边界，后面每一步都更好写，也更容易在会上挡掉加需求。
- 加一句「每条验收标准必须能被测试同学直接写成一条用例」——「体验流畅」这类模糊表述会被当场筛掉。