How to write PRD
我有这个问题不是说为了人类写 PRD，而是为 AI 写 PRD。我想写一种 PRD，这个里面我们规定 AI 需要做的，边界权限等，然后我们坐等 AI 去根据文档去实现所有功能。而不是我们像个监工一样，总是时不时要看看 AI 写的对不对。
What is PRD
看了几篇文章，好像每个人理解的都不一样，主要区别是 scope。
比如我原本的理解，几乎就是一个设计文档。我有一个 feature，我需要如何修改 UI 界面，我需要增加怎样的功能，详细的列出来。但是网上对于 PRD 有不同层面的理解。
一种 PRD 文档，就是已经有了一个产品了，我们只需要加一个新功能，那么内容大致如下：
- overview，需求背景，stakeholder，大概要如何解决问题，要添加怎样的功能。都是梗概性，力求简洁。
- use case 或者说 用户画像，就是解决了那些用户的怎样的问题。用户的使用案例是什么
- 可以说一些功能设计了，比如 ux，ui 设计，需要在哪里加怎样的功能等等。然后可以把设计师的设计文档链接贴上，把工程师的设计文档链接贴上
- 需求排期，比如大概什么时候做，多长时间做完等等
- 上线检测，看看上线这个功能后，又怎样的变化。有何反馈
- 风险点，我看到有的文档还会说一些风险点。比如法律、用户使用习惯、程序开发影响点可能导致的 bug 等等。
一种 PRD 涵盖的范围很大，是一个全新的产品，看起来有点像商业企划书了。还会讲 vison
- 整个产品的背景，我们发现了怎样的用户需求，我们希望开发一个怎样的产品。
- vison，这个领域有多少用户量。商业逻辑是什么，产品变现逻辑是什么
- 产品交互图，大致的一个交互图。
- 产品具体的 feature，然后由于是一个新产品，因此需求很多，还需要排优先级
- 希望达到的里程碑事件
上面描述了 PRD 大致在写什么，还有很多文章通过 PRD 延伸出 PM 应该做什么，什么是好的 PM，好的 PRD 应该是怎样的。比如 PRD 应该是一个信息交流的平台，PM 使用 PRD 来传达自己的想法，让信息透明。
- 让各方能够知道需求的由来，理解了来由之后，才能有默契的高效的合作。
- 信任。知道 PM 不是拍拍脑袋瓜随便想出来的，需求是有背景的。
还有一些讨论，在于什么是正确的需求。
AI 能够理解理念么？
比如我们想说什么是一个好的 PM？什么是一个好的 PRD？什么是一个好的组织？这些问题更像是一个理念，这些理念当然可以写到纸面上，但是这些理念的权衡，AI 真的能够理解么？AI 真的能够权衡理念观念么？
或许我们对 AI 太苛刻了？毕竟人类也无法权衡理念。
如何更好的执行
下面是 figma 的一个 PRD 样例
https://coda.io/@yuhki/figmas-approach-to-product-requirement-docs/prd-name-of-project-1
figma 给出的 PRD 普遍都具体些，都是针对某个小需求来做的。很适合我们作为 PRD，只有足够具体的明确的需求，AI 才能够执行好。当然对于人类可能也是这样，但是人类的隐含的 context 太多，因此人类可以在语言信息不完整的情况下，也能意会。AI 很像一个知识极其丰富、学习能力极强的、单纯的、木纳的小孩子。
今天我用 PRD 完成了前端的工作
我首先写了 RPD 文档，但实际上那个文档很短，基本上就是介绍前端需要做什么，后端需要做什么，就这些。我感觉那都不能称为一个文档了，因为他太细碎了，我把每个她需要改的文件地址都告诉他了，然后接口需要改什么字段也都告诉她了。我觉得我只是把 cursor 对话框里面的 prompt 放到一个文件里面了。
前端代码生成还不错，但是仍然有不少错误。
- ui 设计，我把 ui 设计图放到文档中了，AI 写出的按钮放错了位置。可能是他的图像识别有一点问题？我不太清楚图像识别出的信息是什么，各个组件的位置关系？
- 第二个就是代码逻辑，当然那个可能也不算错误吧，可能是另一种实现方法。这个是我的文档中的缺失。如果我能明确写出来，那么他可能直接就能搞定。
后端的问题，逻辑方面，我就自己写了。我觉得自己写可能比 AI 更快点。关键的是我很难描述我要做的东西。我说的难，是指我需要花很多口舌，去描述我的需求是什么，每个字段应该如何设计，每个字段意义，业务逻辑是什么。如果我真的把这些都描述清楚，我认为还不如我直接编码呢。
能否让 AI 自己设计代码？
我们总是把需求设计好了，字段设计好了，ui 设计好了，然后才告诉 AI 怎么做。
我们是否能直接把需求告诉 AI，让他扫描代码库，让他自己出方案，我们评估方案，最终确定方案后，AI 自己生成 PRD 文档，自己去执行，调试呢？
