PRD里功能需求，一般包含这几个部分：
业务逻辑
业务规则
界面交互
权限/埋点/统计等
业务逻辑是核心，是对输入的处逻辑，可能涉及到多个系统，多个服务，多个接口
业务规则是逻辑执行的依据，比如，系统要判断验证码过期时间，那多长时间算过期，这个就是业务规则。
比如系统跟员工分配工单，是平均分还是按时间分，每人分多少，这也是业务规则。
界面交互，包括界面组件的显示，默认状态、空状态，不同状态下的不同展示方式，点击后的交互，加载过程，返显数据。
还有表单的输入规则，是否必填，最大长度，可输入内容等。
PRD里包含这么多内容，如果事无巨细，全部考虑完的话，一个很简单的功能，也可能写出很多字。
为了提高效率，把握PRD的颗粒度，就显得比较重要了。
按照PRD的详细程度来看，大概可以分为三档：
1、简略。
2、一般。
3、详细。
简略。
只需要描述关键的业务逻辑和业务规则就行了。
业务逻辑的体现，是业务流程，里面包含主流程，分支流程和异常流程。
业务规则的体现，是规则集，可以通过规则表或规则树来体现。
具体的呈现形式，通过Axure远处页面+流程图+简单的备注就可以了，原型不需要加跳转，简单的组件可以不画。
一般。
描述业务逻辑和业务规则，在原型适当加一些交互，描述字段规则。
详细。
原型能做到中高保真，做一些交互，甚至动效。
这个程度的PRD在Axure里面写不太合适，内容太多了，改起来麻烦，改交互的时候又要该文字描述。
所以要用word写PRD，word的结构完整。
界面交互部分，包括页面，字段等非常详细的描述。
根据团队规模，和规范化的要求，不同的公司要求会不一样。
一般小公司，就一个产品经理，甚至没产品经理，简略就可以了。
中型公司，2-3个产品经理，要求不是特别高，一般就可以了。
大厂，多条业务线，产品经理比较多，要求就比较高，需要写到非常详细。
也能理解，大厂人多，沟通链条长，多花点时间把文档写细，反而能提升整体工作效率。
现在产品形态趋于稳定，很少会写到那么详细了，很多规则和交互细节都已经成为常识。
我还是比较喜欢简略的版本，最多到一般，详细的太花时间了。
产品经理应该多留点时间出来研究市场，研究竞品，研究增长，研究业务。
当然，你可以不写到很详细，但是要具备写详细的能力，要具备完整描述需求的思维框架。
