写一份开发者真会看的需求文档

什么该写，什么不该写

把每个像素都写清楚的文档，两周后就没人再更新了；只写愿景的文档，会每天带来二十个问题。中间那个点是：对每项能力，写清谁在用、正常路径上发生什么、出错时发生什么、以及满足什么条件才算做完。

验收条件能省掉大部分争论。「用户在一分钟内收到通知」是条件，「流程要快」是愿望。

写流程，不要写页面

把流程写成一串顺序：起始状态、操作、结果。然后写失败路径——没网络、用户中途关掉、文件损坏、权限被拒。在真实项目里，失败路径占一半工作量，却只占四分之一的文档篇幅。

页面会被重做，流程会留下来。所以设计稿是从文档里链接过去的，而不是嵌进文档中。

大家都会跳过的那部分

明确写出这一版的范围之外是什么。一份「暂不做」清单是管理工具，不是托词：它让你可以说「对，这个排在下一步」，而不是每次开会都重新吵一遍。

把你依赖的假设也写上。写下来的假设是被管理的风险；留在脑子里的假设，就是日后的意外。