从多个写作视角准备一份清晰 PRD，供五类利益相关者评审

在改进句子之前先确定范围

用简单的语言写下当前的决定：谁需要什么结果、适用哪些条件、什么超出范围以及哪些问题尚未得到解答。将提议的决策与已批准的决策进行不同的标记。否则，优雅的重写可能会悄悄地将建议变成要求。

Atlassian 将 PRD 描述为有关产品目的、功能、用户需求和成功标准的共同说明。让这一共同目的约束 AI 生成的差异。面向不同利益相关者的解释，应帮助理解同一个需求，而不是生成五个无法同时交付的产品版本。

提出正确问题的虚构要求

设想一个虚构报表产品，其草稿写道：“用户应该能轻松导出报告。”实际已批准的范围更窄：工作区所有者可以把当前筛选表格导出为 UTF-8 CSV 文件；定时导出不在范围内。文件大小限制、空结果和失败时的行为尚未决定。这些只是示例需求，并非 Colay 功能。

更清晰的核心陈述是：工作区所有者可以将与活动表过滤器匹配的行导出为 UTF-8 CSV 文件。将排除项和未回答的问题放在旁边。不要让模型用虚构的持续时间来替换缺失的性能决策。

请求八个视角，然后合并它们

使用Ask separately中选定的可用智能体来检查他们的初步解释。八个请求的视角不需要八个独立的模型。保留任何指向真正产品选择的分歧。例如，空表是否生成仅包含标头的文件是团队的决定，而不是平均的风格偏好。

审阅以下 PRD 摘录：[文字]。已批准决定：[事实]。提案：[尚未批准]。不在范围内：[清单]。开放问题：[清单]。给出八种表述，分别强调用户结果、简明范围、可测试性、权限、失败行为、性能、客服需求和管理层关注点。每个版本必须保留相同的已批准范围。不要编造技术限制，也不要悄悄决定开放问题。每个版本指出一处暴露出的歧义。然后提出一份统一需求、验收案例示例，以及带建议负责人的待决事项清单。把所有新建议标为提案。

围绕一项要求构建审核数据包

对于虚构的导出要求，批准的案例可以检查所有者是否收到包含与活动过滤器匹配的行的 CSV。非所有者的预期界面和空结果响应仍然是问题，除非团队已经决定。这种区别可以防止人工智能生成的测试列表成为意外范围。

1. 选择一份核心表述，对照已批准决定清单，逐字检查角色、条件、输出和排除项。
2. 为已做出的决策添加接受案例示例。将涉及未解决行为的案例标记为问题而不是商定的测试。
3. 将措辞编辑与范围提案分开。新的行限制、权限规则或恢复路径需要产品决策，即使句子读起来更好。
4. 通过现有的审核流程向审核者发送规范文本、有意义的更改以及向所有者提出的开放式问题。

使用 macOS 快捷方式进行重点措辞

保持 PRD 打开并默认使用 ⌘⇧K 或您在“设置”中配置的快捷方式调用 Colay。仅粘贴审阅所需的摘录和允许的上下文。悬浮窗口打开起草工作区；它不会自动读取文档或提交 PRD 进行批准。

审核后，记录哪些评论更改了措辞以及哪些评论更改了产品决策。一起更新规范要求及其示例。在需要时重复使用困难段落的提示，而不是重复重写整个 PRD。有用的结果是团队可以做出更小、更清晰的实际决策。

问题及解答