在 Ottermind 中使用 Linear：从工单列表到清晰的下一步

将 Linear 工单带入对话，讨论接下来该做什么。在 Ottermind 中配置 Linear 技能后，智能体可以读取有权访问的工单和评论，协助准备评审，并利用团队已经记录的上下文起草后续事项。获得批准后，还可以通过受支持的写入操作，将这些内容写回 Linear。

当工单系统里已经有了细节、却仍需要把它们串起来时，这种方式很有用。哪条工单需要做决定？两份客户报告说的是不是同一个故障？补充哪些信息，才能让工程师接手下一条工单？

下面以一个包含邀请链接问题的虚构版本发布为例，展示具体过程。工单 ID、来源事实和输出示例均为演示内容，不代表在已连接的工作空间中进行过实际测试。

连接你要协作的团队

使用 byungkyu 发布的 Linear API 技能。这款第三方技能通过 Maton 连接，需要完成 Maton 身份验证，并具备有效的 Linear OAuth 连接。连接决定了智能体可以访问哪个工作空间及其中哪些资源。

按照 Ottermind 技能指南，启用技能并将它绑定到负责当前任务的智能体。如果你有多个 Linear 连接，请明确指定要使用的工作空间。首先让智能体读取一条已知工单，并确认它的 ID 和标题。

该技能文档涵盖工单搜索、查询、创建、更新和评论。写入操作需要明确批准，部分操作可能还需要额外的授权范围。技能配置说明介绍了这些要求。

围绕团队需要做出的决定准备评审

假设团队正在准备一次版本发布，有三条工单提到了邀请链接。其中一条已经分配了负责人，另一条最近收到要求澄清的评论，第三条包含一份尚未复现的客户问题报告。

打开看板，你能看到工单在哪里。准备评审则需要弄清哪些事实应该放在一起讨论。让智能体读取描述和相关评论，再整理一份简短议程，并附上指向依据的链接。

为 [团队] 的 Linear 工作空间中的 [项目] 准备一份版本发布评审议程。
读取活跃工单，以及理解其当前状态所需的评论。

每个讨论项都要包含工单 ID、标题、状态、负责人、
已记录的问题或待解答事项，以及支撑该讨论项的工单链接。
将议程分为需要决策、缺失信息和已确认的阻塞项。
依据已记录的事实，不要仅因为工单存在时间较长就推断它已被阻塞。
说明你审阅了哪些内容，以及哪些记录无法获取。不要编辑工单。

有效的议程应提供足够细节，让同事知道每一项为什么值得讨论。在这个虚构示例中，可以这样转化：

在这个请求中，智能体的职责是汇集依据、组织问题。缺少复现步骤是一个具体的信息缺口。如果要断言整个版本发布存在风险，则还需要更多信息。

Linear 支持根据工单属性和关系进行筛选。限定具体项目、团队或工单集合，能让评审更聚焦，也更容易判断审阅覆盖范围。

读取工单集合: Linear 筛选参考文档 · Linear GraphQL 指南

议程准备好后，可以要求一个更精简的版本：“给我一段用于评审开场的五分钟内容。先讲邀请功能需要做的决定，再放补充信息的请求。”需要核查细节时，完整的依据表仍然可用。

对比相似报告，同时保留差异

“邀请链接无法正常使用”可能指向多种故障。一位用户可能打开了过期链接，另一位可能登录了错误的账户，还有一位可能在接受有效邀请后看到了错误提示。

创建新工单之前，先搜索可能相关的已有记录，再让智能体对比描述、触发条件和预期行为。这样就能将宽泛的关键词匹配，转化为可供审阅的假设：哪些报告可能适合放在一起处理。

在 [团队] 的工单中搜索邀请链接过期或无法打开的问题。
读取相关工单的描述和评论。

对比报告中的行为、复现条件、受影响的上下文
以及预期结果。每行都要包含工单 ID 和来源链接。
建议值得作为潜在重复项审阅的工单组合，并逐一说明理由。
将不确定的匹配项分开保留。不要关闭、合并或修改工单。

下面是可以要求生成的简短对比示例。这些 ID 和报告均为虚构：

DEMO-41 和 DEMO-63 可以考虑放在同一场讨论中，但这并不能证明它们具有相同根因。DEMO-58 也提到了邀请，不过它的复现条件指向了另一个问题。

一个有用的追问是：“需要什么依据，才能判断 DEMO-41 和 DEMO-63 是否应该放在一条工单中处理？”答案可能是需要相互对应的截图、准确的错误消息，或复现步骤的对比。这个答案应来自报告本身，而不是凭空给出诊断。

在工单分类和初步评估时，这种区分很重要。你希望减少重复调查，同时保留工程师后续可能需要的信息。

将已达成一致的行为整理成可实施的工单

现在假设评审做出了一个决定：邀请过期时，应解释问题，并引导用户向工作空间管理员申请新的邀请。该决定不包含修改邀请有效期规则。

这些笔记足以起草一条边界明确的工单。继续在同一段对话中处理，便能保留相关报告和决策原因作为上下文。

根据这些已批准的产品决策起草一条 Linear 工单：[笔记]。
使用 [团队] 和 [项目]，链接到我们刚刚审阅过的相关报告。

包含简洁的标题、观察到的行为、预期行为、
范围内的工作、笔记中明确列出的排除项，以及验收标准。
不要自行编造实施方案。除非笔记有明确指定，
否则不设置负责人和优先级。创建前先展示完整草稿。
在我批准创建后，返回工单 ID 和 URL。

针对这个虚构决定，草稿可以包含：

• 标题： 邀请过期时说明下一步操作。
• 观察到的行为： 报告中的过期链接流程结束时，没有提供有用的恢复操作。
• 预期行为： 说明邀请已过期，并引导用户向管理员申请新的邀请。
• 不在范围内： 修改邀请有效期规则。
• 验收检查： 打开过期邀请时，显示已约定的解释和恢复操作说明。

这只是写作示例，并不表示 Ottermind 创建或测试过工单。它旨在说明，如何将决定变成可执行的工作，同时避免悄悄增加需求。

将预期行为和验收标准放在一起审阅。如果笔记没有说明恢复操作应呈现为按钮还是纯文本，就应将其标记为待解决事项。现在提出一个准确的问题，比在工单里编造设计细节更有价值。

所选技能支持创建工单和添加评论。批准具体写入内容后，请智能体返回生成的工单链接。如果该决定属于一条已有工单，就在那条工单中准备一条聚焦的评论，而不是为同一项工作再建一个跟踪位置。

让下一步始终关联原始报告

一次有效的会话可以留下三份相互关联的产物：评审议程、工单对比，以及反映团队决定的草稿。每份产物都应链接回解释工作缘由的原始记录。

从 Linear 技能 和一组需要关注的工单开始。技能入门介绍说明了如何让智能体具备这项能力。若想了解更完整的工作方式，AI 项目管理指南涵盖评审与交接，智能体工作空间指南则介绍了上下文如何支撑跨步骤的工作。