用语音输入，更快写出清晰的验收标准
“让用户可以保存草稿”听起来很简单，直到有人追问：标题为空怎么办？保存以后会直接发布吗？你可能马上就能口头解释清楚，任务描述却迟迟没有写出来。
语音输入能把这段解释变成初稿。先说清一个场景，再整理成验收标准，也就是工作通过验收时应当能观察到的结果。基本概念可参考Atlassian 的验收标准介绍（英文）。下面是一套从口述到文字的具体流程。
1. 先打开任务和相关资料
在 Mac 上，把任务描述与相关设计稿或已确认的笔记并排打开。一次只描述一个小范围的行为，不要从整个功能讲起。如果这次讨论手动保存草稿，定时发布、公开文章和自动保存就先放到其他议题中，除非它们已经确定属于本次范围。
先写一句目标，例如：“编辑人员可以保存未完成的文章，之后回来继续编辑。”这样，口述内容就有了明确的用户视角。
2. 围绕五个问题口述
想象你正在给同事演示操作流程，每个问题之间稍作停顿。
- 谁： 使用这项功能的是哪类用户或角色？
- 前提： 操作前已经具备哪些条件？
- 操作： 用户做了什么？
- 结果： 操作后应当能看到或确认什么？
- 例外： 在一个相关的失败场景中，应当如何处理？
遇到团队还没有决定的内容，先说“待确认”。整理文字时，就能把它移到单独的部分，避免将一种设想误写成确定的需求。
3. 把初稿拆成可检查的条目
下面是一个虚构功能的口述示例，并非 TypeFree 的功能说明。
编辑人员打开一篇尚未发布的文章，里面有标题和正文。保存草稿后，会看到保存成功的提示。重新打开时，标题和正文都还在。保存不会让文章公开。如果标题为空，要提示填写标题，而且不能保存。自动保存还没有决定。
完成语音输入后，可以整理成供团队评审的标准草案：
- 编辑人员保存标题非空的未发布文章，保存成功后会看到确认提示。
- 重新打开已保存的草稿时，会恢复该次保存的标题和正文。
- 保存草稿不会让文章对外公开。
- 标题为空时尝试保存，会显示要求填写标题的提示，且不保存更改。
“是否加入自动保存？”放在待确认事项中，不要混入已经达成一致的标准。上述规则只是虚构功能的提案，实际行为仍需由你的团队决定。
4. 先核对意思，再润色表达
重点检查“不”“仅”“为空”“未发布”等词。漏掉一个否定词，就可能把需求意思完全颠倒。按钮名称如果需要精确一致，直接从设计稿复制，不要只依赖语音识别。
接着站在评审者的角度逐条阅读：需要做什么操作，看到什么结果，才能判断通过？如果写了“快速保存”，就确认团队实际需要的时间和测量条件，不要为了显得具体而随意编一个数值。
如果口述时谈到了数据存储方式或内部命名，把这些内容移到技术讨论笔记中。用户能观察到的结果，与内部采用什么实现方式，最好分开表达。
5. 和团队一起解决未决问题
分享时明确标注这是草案，并保留尚未决定的问题。在把清单视为确定范围之前，请负责开发和评审的人一起确认场景。语音输入能记录你的解释，但不代表团队已经达成共识，也不能证明功能已经通过测试。
其他相关写作任务，可以参考用语音输入撰写项目简报和写出更清晰的缺陷报告。
TypeFree是把语音转成可编辑文字、加快写作速度的简单方式。先选一个功能场景，说出预期行为，检查生成的文字后再加入任务描述。