这篇指南聚焦“Muse ChatPRD”。下面把问题拆成容易跟做和复查的步骤。
01｜先认清这是自定义连接器
ChatPRD 在 2026 年 10 月 1 日发布了给 Muse 使用的连接方式。发布者随后说明，它目前是 custom connector，还没有成为 Muse 目录里的官方连接器。ChatPRD 同时公开了一份专门给 Muse 自定义连接流程读取的 brief，里面给出 REST API、认证方式、读写范围和错误处理。
这条路径也不要和 ChatPRD 的通用 MCP 服务混在一起。本文采用的是 https://app.chatprd.ai/connectors/muse.md 里的 Muse REST 自定义连接器说明，不把 https://app.chatprd.ai/mcp 当成消费者 Muse 已经支持的入口。本站没有登录账号完成连接，实际可用性以你当前 Muse 的自定义连接结果为准。
原帖配图是 ChatPRD 品牌玩偶，没有展示连接卡片、API key 或成功创建的 PRD。它只能说明这次发布来自 ChatPRD 一方，不能代替账号里的连接结果。
02｜第一次只开读取范围
先在 Muse 里发一条简单要求。请帮我按这份说明设置自定义连接器 https://app.chatprd.ai/connectors/muse.md。先只配置读取权限，不创建或改写文档。 Meta 的帮助页说明，Muse 会引导自定义连接器设置，API 凭据应放进 Secure Credentials Store。不要把 ChatPRD key 粘在普通聊天、提示词或截图里。
ChatPRD 的连接说明把 key 分成 connector:read 和 connector:write。新 key 默认只读，用户主动打开写权限后才可创建或改写文档。第一轮先保留只读，给 key 起一个单独名称，例如 Muse PRD test，后面可以只撤销这把 key。
连接前还要看 ChatPRD 的隐私范围。它的政策把提示词、文档、文件和 integration data 都算作 Customer Content，并说明可能使用服务商和外部 AI 提供方来运行服务。只交这次需求需要的内容，先删姓名、邮箱、合同数字和内部客户标识。
03｜让它先报账号和空间，不搜文档
连接完成后，先要求 Muse 只确认 ChatPRD 返回的账号、计划、key 名称、scope 和可见组织，不列出文档正文。ChatPRD 的 /me 就是为这一步准备的。返回结果应该能告诉你 key 是否只有读取权限，以及当前账号能看到哪些团队组织。
个人空间和团队空间要分开选。连接说明规定，省略 organizationId 时使用个人空间，团队文档则要一直带同一个组织 ID。项目也有自己的 projectId。如果你准备把草稿放进团队，先让 Muse 列出少量项目名称与 ID，再由你点名一个目标。
公开说明没有提供“自动挑正确团队”的保证。账号名、组织名或项目名对不上，就停在这里。不要让它搜索全部文档来猜，也不要因为看见一个同名项目就直接写入。
04｜把零散需求压成一张输入卡
下面用一条虚构练习需求演示。用户导出月报时看不到进度，失败后只能重新开始，希望页面能显示状态并允许重试。这是一条教学需求，没有使用本站的真实调研或转化数据。
先补成四块内容。事实写用户原话和当前流程；约束写第一版仍沿用现有导出接口；范围写单个导出任务的进度和失败重试；待确认项写平均耗时、能否取消、失败后是否支持续传。没有答案的地方保留问题，不替工程、设计或用户补答案。
再给每条加标签。[来源事实] 只放已有材料，[工作假设] 放为了继续起草而暂用的判断，[待确认] 留给负责人。这样打开 PRD 时，读者能看出哪句话可以直接采用，哪句话还要找人。
05｜先在对话里看完整草稿
写权限仍然关着时，把输入卡交给 Muse。要求它先在对话中生成完整 Markdown，结构包含问题、目标用户、当前流程、目标、非目标、需求、边界情况、成功指标、依赖和待确认问题。每一条需求旁边保留来源标签。
可以复制这段任务说明。只使用我提供的输入卡。先在对话里起草 PRD，不调用创建或更新文档。把事实、假设和待确认项分开。成功指标没有基线、负责人或时间窗时保留空缺。不要搜索无关 ChatPRD 文档，也不要分享、导出或发布。
第一稿最容易偷偷补齐数字。看见“提高留存 10%”或“导出应在 30 秒完成”时，回到输入卡找来源。找不到就删掉数字，改成需要产品或工程确认的问题。
06｜批准后只新建一个命名草稿
草稿内容过关后，才给这个 key 打开写权限。先定一个容易查重的标题，例如 DRAFT 月报导出进度与失败重试 2026-10-02。ChatPRD 说明创建接口没有幂等保护，同一个请求重跑可能产生两份，因此创建前应按完整标题搜索一次。
接着明确个人或团队组织、目标项目 ID 和动作。要求 Muse 只有在完整标题没有结果时才新建一份 Markdown 文档，不更新任何已有文档。创建接口返回 id、title、threadId 和稳定 url，让它把标题、空间、项目和 URL 原样交回。
出现 401 或 402 就停。前者可能是 key 缺失、已撤销或没有写权限，后者表示当前计划不满足要求。不要反复创建来试权限，也不要把只读 key 换成权限更大的长期 key。
07｜打开真实 URL，逐段做人审
打开返回的 ChatPRD URL，不拿 Muse 的完成消息当交付。先核标题、空间和项目，再从头读正文。问题段要能回到用户反馈，目标用户和场景不能越写越大，非目标要把通知中心、批量导出等本轮不做的内容挡在外面。
需求段逐条检查动作、可见结果和失败状态。成功指标至少需要口径、当前基线、负责人和时间窗；暂时没有就留成待确认。依赖要写到具体接口或负责团队，边界情况要覆盖刷新、重复点击、网络断开和重试后的状态。
最后看来源标签。事实和假设混在一句里，就拆开。某条需求找不到来源，也没有负责人确认，就先留在候选区。这一步要让问题露出来，第一版可以保留缺口。
08｜小修改也要先读最新版
你可以直接在 ChatPRD 编辑器里改，并利用版本记录看重要修改。若要让连接器再改一轮，先限定一项，例如只把三条边界情况补进现有草稿。ChatPRD API 每次更新都会提交整份 Markdown。
连接说明要求更新前重新读取全文，并带上刚读到的 updatedAt。团队成员已经先改过时，接口会返回 409 conflict。这时重新获取最新版，把获批的改动重新应用，不能拿旧全文覆盖。
每轮改完重新打开 URL，看版本、标题和全文。不要在同一轮里顺便改目标、指标和范围。一次只审一类变化，谁批准了什么才看得清。
09｜交付草稿，并把临时连接收好
最终交付写清文档标题、ChatPRD URL、所在空间和项目、仍未回答的问题，以及谁要做下一轮审核。保持 DRAFT，不自动分享、导出或发布。需要正式报告的出处核对，可继续看报告与 PDF 交付教程。
一次性任务结束后，在 ChatPRD 撤销这把专用 key，并在 Muse 的 Connectors 里断开自定义连接。Meta 说明断开后会停止继续交换数据，但之前用于任务的信息仍可能留在 Muse 对话或记忆里，需要另行检查。
当前 Muse 看不到自定义连接入口，或连接器没有返回可核对的 scope，就改用手动路线。把同一张输入卡复制到 ChatPRD，按官方 PRD 写作流程在编辑器里起草和审核。想系统检查连接权限时，可以接着看Muse 权限与隐私入门。
参考来源
以下资料用于核对本文中的产品信息。Musevip 为独立中文指南，与 Meta 无隶属关系。
本文最后核验于 2026.10.02。产品页面可能更新。