编写开发人员实际阅读的 PRD，由 Claude 担任编辑

我的第一个 PRD 回来时说：“你能说一下要构建什么吗？”因此，我停止编写文档，开始编写疲惫的工程师可以忍受的规范。克劳德的工作是剪裁，而不是发明。

结构第一：一行关于问题，一行关于用户，“完成”含义的简短列表，以及开发人员实际遇到的边缘情况。没有背景小说。如果它需要一段上下文，它就属于链接线程。

简单地起草它，然后将其粘贴给克劳德，并附上一条指令：“删除开发人员可以推断出的每句话，并标记任何没有验收测试的需求。”这个单一的提示消除了 PRD 可跳过的多余内容。

然后我添加克劳德标记为缺失的验收测试。未经测试的要求只是一种意见。开发人员阅读他们可以验证的规格；他们略读其余部分。

改变一切的习惯：我在编写 PRD 时假设读者了解上下文并且没有耐心。克劳德删除了礼貌性的散文，帮助我坚持了这一点。

克劳德 (claude.ai)

最适合：长篇写作、编辑和通过结构进行推理。

主要特点：文档模式、长上下文、草稿工件、仔细编辑。

免费计划：具有每日限制的免费套餐。

定价：Pro 版的使用量较高，每月 20 美元左右。

优点：擅长修剪和重组，保持简短。

缺点：除非你告诉它不要这样做，否则它会软化钝点。

我的结论是：我写骨头，克劳德去除脂肪，我重新添加边缘情况。生成的文档足够短，可以阅读，也足够具体，可以构建。

常见问题：

问：Claude 应该从头开始编写 PRD 吗？

A：我写结构；克劳德编辑。全代偏离了团队的实际需求。

问：多短才算太短？

答：如果开发人员可以构建它并从文档中测试它，那么它就足够长了。较长的通常是填充。

问：我需要对每条生产线进行验收测试吗？

答：对于 QA 人员会检查的任何内容，是的。模糊的要求后来会成为指责。