MuseVIPMuse 独立使用指南
注册上手EN

工作流教程 · 来源整理与实用步骤

用 Muse 整理 bug 反馈，再交给 Linear 人工审核

把零散的报错和复现信息整理成一条可审核的 Linear issue 草稿，先查重复、确认团队与权限，再决定是否创建。

适用场景：从一段用户反馈中提取可核对的复现步骤和证据，准备一条 Linear issue 草稿。

核验于 2026.10.02主要来源：Meta Help Center: How Muse works with Connectors8 分钟阅读
开始阅读 ↓下一篇 →
一条报错经过事实整理、重复检查和人工确认后成为待创建的 Linear issue 草稿
原创流程封面。草稿先由人审阅，确认后才创建。

这篇指南聚焦“Muse Linear”。下面把问题拆成容易跟做和复查的步骤。

01｜先把反馈写成草稿

一条 bug 反馈进 Linear 前，先把原话里哪些是看到的现象、哪些是猜测分开。比如“按钮点了没反应”是观察，“服务器挂了”可能只是猜测。Muse 可以先帮你压成一页 issue 草稿，复现条件、团队归属和优先级还要由提交者确认。

公开线索提到 Linear 连接器，但没有展示 issue 创建成功。先把报告整理成待审草稿，再确认权限和内容，由人决定是否提交。

按原始反馈、可复现事实、相似 issue、团队与权限、人工批准的顺序准备 Linear issue 草稿
原创步骤图。相似项只是候选，提交前仍需人来判断。

02｜先确认连接入口和能做的动作

如果你的 Muse 账户能连接 Linear，先按 Meta 帮助页查看连接说明和授权信息。Meta 的产品安全说明也提到 Muse 能为有 API 或 CLI 的服务编写自定义连接器。每个连接器具体能读什么、能不能写 issue，要看当前界面实际列出的能力和授权范围。

Linear 的官方 MCP 文档是另一条连接路线。标准地址 /mcp 默认提供读写工具，/mcp/readonly 只提供读取工具，也可以在标准地址只申请 read 权限。Linear MCP 文档不能证明 Muse 原生连接器暴露了相同工具。第一次整理反馈时，优先用读取权限；如果只能在 Muse 里起草，也可以先把草稿留在聊天中。

03｜原始反馈先拆成事实和空缺

保存用户原话或客服转述的原始版本，再让 Muse 从中抽取三类信息。第一类是确实发生的动作和结果，第二类是用户当时看到的设备、系统版本、页面或账号环境，第三类是还没问到的部分。报告里没有说到的信息保持空白，不让模型补一个常见答案。

可以先追问反馈者什么时候发生、重复几次、按什么步骤能再现、有没有临时绕法。报错截图、日志和短录屏会更有帮助，但先遮住邮箱、客户姓名、访问令牌、订单号和其他人的信息。Linear 提醒私有团队内容通过第三方集成或自建 API 应用时，也要检查谁能看到集成输出。

04｜用固定字段整理一份 issue 草稿

Linear 的 issue 模板可以让团队预设标题、描述和属性；表单模板还能要求提交者补标题、重现步骤或组件等信息。你的团队字段可能不同，先看已有模板，再让 Muse 输出能贴进去的内容，不要擅自造一个 Severity 1 或组件标签。

试试这段指令。请只根据我提供的反馈写一份 Linear bug issue 草稿。分开写摘要、环境、复现步骤、实际结果、期待结果、发生频率、用户影响、证据位置和未知信息。每个事实注明来自哪句原话或附件。猜测放进“待确认”，没有的信息留空。先不创建 issue、不评论、不改状态、不分配负责人，也不设优先级。

05｜把复现步骤写到别人能照着做

复现步骤应从一个可说明的初始状态开始，每一步只描述一个动作，最后写下页面或系统实际出现了什么。把操作系统、应用版本、浏览器、网络条件和发生时间照原报告记录；不知道的值标作未知。不要把一句“打不开”扩写成一串用户没提供的点击路径。

期待结果写成用户原本要完成的事，实际结果记录屏幕上确实发生的变化。若反馈者只说“体验很差”，先追问哪个任务被挡住、出现频率和影响范围。开发者有了具体入口才容易复现，猜测性的解决方案可以留到团队讨论。

06｜搜索相似 issue，不自动判重

先用错误提示里的独特词、受影响页面、操作路径和产品版本，在正确 workspace 和可见 team 范围里搜索。Linear 官方目前说明，Business 与 Enterprise workspace 可以启用 Triage Intelligence，由管理员打开后给进入 Triage 的 issue 提供关系建议。它适用于已创建并进入 Triage 的 issue，聊天中的草稿不会自动出现在这里。提交新草稿前先手动搜索；若已创建的 issue 有相似建议，也要逐条核对，不能当成重复结论。

打开候选 issue，对照触发条件、版本、实际结果、解决状态和原报告证据。症状相近但复现路径不同，可以保留两条并按团队规则关联；证据还不够时，在草稿列出链接和相同或不同之处，等维护者确认。只有负责人确认重复后，再按 Linear 的流程标记 Duplicate。该操作会把 issue 状态改成系统的 Duplicate，并将它指向原 issue，不能只因为标题相似就自动合并。

07｜团队、状态和优先级都要有人确认

每条 Linear issue 归属一个 team；不同 team 可以有自己的状态、标签和模板。先让草稿建议可能的 team 并说明依据，再由提交者在有权限的团队中选择。若问题涉及人事、客户资料、安全细节或尚未公开的信息，先确认团队可见范围和集成权限，不要把私有材料交给不明的连接器。

Linear 的优先级是可选字段，值为 No priority、Low、Medium、High 或 Urgent。用户描述的影响范围不等于团队的优先级决策。没有团队规则或负责人确认，就让优先级留空；状态和标签也使用所选 team 实际提供的选项。

08｜获批后创建，再核对 Linear 原件

把草稿、目标 team、模板、状态、标签、优先级和附件清单一起展示给提交者。创建前明确问一句是否创建这条 issue。用户确认后，只有当当前连接器确实提供创建动作并拥有对应写入权限，Muse 才能发送创建请求；只读连接器就把完整草稿交给用户手动提交。

创建结果要回到 Linear 检查，确认 issue ID、链接、团队、标题、正文、状态和证据附件都正确。若响应只显示“已完成”却没有可打开的 issue 链接，就先到目标 team 搜索确认，不要直接告知反馈者 issue 已建好。把草稿和最终 issue 链接对应保存，之后的开发判断仍交给团队。

Meta Muse 连接器发布主题图中能看到 Linear 标志与其他工具标志
图源 @alexandr_wang，连接器发布示意图。

参考来源

以下资料用于核对本文中的产品信息。Musevip 为独立中文指南，与 Meta 无隶属关系。

  1. [1] Meta Help Center: How Muse works with Connectors
  2. [2] Meta: How We Built Safety Into Muse
  3. [3] Linear MCP server
  4. [4] Linear issue templates
  5. [5] Linear issue relations and duplicates
  6. [6] Linear teams and workflows
  7. [7] Linear priorities
  8. [8] Linear private teams
  9. [9] Linear issue creation
  10. [10] Linear Triage Intelligence
本文最后核验于 2026.10.02。产品页面可能更新。