每一份需求文档，其实都是在告诉研发和测试要做什么，为什么要做，验收标准是什么。
1）'要做什么'是最好写的。
拍个脑袋都能写出来一大堆需求。但要写完整，写清晰，就还是要有些工作要做的。一份清晰的需求文档，至少要让有一些上下文背景的研发一眼就能理解目标，并且在脑海里大概勾勒出怎么做，而不至于看完还是一脸茫然。
2）'为什么要做'往往容易被忽略。
有些人觉得没必要跟研发讲，干活不就完了嘛，为啥要问东问西的；还有些人写不清楚，或者理由不能服人，于是随便糊弄一通。
但讲清楚背景，一方面是让研发能从工程视角给一些专业建议，另一方面也是倒逼产品想清楚一个需求到底有什么价值。
3）'验收标准'就更容易被忽视了。
每个人的思路都有局限，或者说关注点不一样。对同一个需求，研发可能只关注了具体功能是否实现了，而不会注意到可能还会对别的逻辑造成联动影响。
这个时候，每多一个人提示应该注意测试哪些地方，在研发和测试时，就会多一些考量。
ps. 感觉给大模型写提示词，和写需求文档很相像。区别可能在于，人的综合解决问题的能力更强，需求一次性说不清楚也没关系，还能通过反复沟通来对齐。
1）'要做什么'是最好写的。
拍个脑袋都能写出来一大堆需求。但要写完整，写清晰，就还是要有些工作要做的。一份清晰的需求文档，至少要让有一些上下文背景的研发一眼就能理解目标，并且在脑海里大概勾勒出怎么做，而不至于看完还是一脸茫然。
2）'为什么要做'往往容易被忽略。
有些人觉得没必要跟研发讲，干活不就完了嘛，为啥要问东问西的；还有些人写不清楚，或者理由不能服人，于是随便糊弄一通。
但讲清楚背景，一方面是让研发能从工程视角给一些专业建议，另一方面也是倒逼产品想清楚一个需求到底有什么价值。
3）'验收标准'就更容易被忽视了。
每个人的思路都有局限，或者说关注点不一样。对同一个需求，研发可能只关注了具体功能是否实现了，而不会注意到可能还会对别的逻辑造成联动影响。
这个时候，每多一个人提示应该注意测试哪些地方，在研发和测试时，就会多一些考量。
ps. 感觉给大模型写提示词，和写需求文档很相像。区别可能在于，人的综合解决问题的能力更强，需求一次性说不清楚也没关系，还能通过反复沟通来对齐。