AI 进入 Jira 的三条路

三条路，同一个 backlog

到了 2026 年，AI 本身已经不稀缺了。真正稀缺的，是知道该把它用在什么地方。

如果你的团队围绕 Jira 运转，这种变化你一定已经感受到了。Atlassian 把 Rovo 直接做进了平台里。OpenAI 和 Anthropic 打开了连接器，让 ChatGPT 和 Claude 能直接读取你的 backlog。与此同时，也出现了一批新的 Forge 原生应用，其中就包括 Just。这类产品把 AI 直接嵌进 issue 面板里，把 Jira 工单既当作输入，也当作结果落点。

三条路。一个 backlog。体验却完全不同。

很多人第一反应是问，哪一种最好。可这往往问偏了。更诚实的问题通常是：哪一种真正适合我们的团队怎么做事？

对有些团队来说，最重要的是覆盖范围和可控性。对另一些团队来说，更重要的是模型选择自由。还有一些团队真正需要的，是一个留在 Jira 里的结构化流程，能够调动多个提供方的能力，而不用离开 issue。

第一条路：Rovo

Rovo 是 Atlassian 自己的 AI 层，已经织进 Jira Cloud、Confluence 和 Jira Service Management 里。它依托的是 Teamwork Graph，也就是 Atlassian 生态内部把人、项目和内容关系串起来的一张图谱。Rovo 最初围绕三根主线展开：Search、Chat 和 Agents。

优势：覆盖面广。 Rovo Search 可以跨 Jira、Confluence 以及大量第三方应用检索内容，同时遵守现有权限体系。对于知识分散、信息到处都是的团队来说，这一点很有价值。
优势：最容易走审批。 不需要管理提供方密钥，不需要自己挑模型，也不用盯着 token 预算。治理仍然留在 Atlassian 原有的权限和审计框架中。价格逻辑也更简单了：到 2026 年，Rovo 更像是 Atlassian Cloud 套餐的一部分，访问能力和使用额度与套餐级别绑定。
代价：控制权更少，对单个 issue 的深入程度也有限。 模型无法自由切换，而且 AI 更像是待在工作旁边，而不是深入 issue 面板里的结构化规划流程。

如果你的核心问题是要在多个产品之间找信息，而优先级又是受控、免配置地快速接入，那么 Rovo 就是合适的路线。

当问题是如何在整个 Atlassian 平台上获得广泛访问能力时，Rovo 最有优势。

第二条路：连接器

连接器走的是反方向。它不是把 AI 包进 Atlassian，而是把 Jira 数据带到 AI 已经存在的地方，比如 ChatGPT、Claude Desktop、Cursor，或者任何支持 Model Context Protocol（MCP）的客户端。

优势：模型选择自由。 你能用的是外部客户端所提供的能力。放到今天，这意味着 Claude Opus 4.6、GPT-5.4、Gemini 3.0 Pro，以及明天会出现的新模型。
优势：使用环境熟悉。 这也是为什么连接器特别吸引那些本来就长期待在 Claude、ChatGPT 或 Cursor 里的重度用户。他们想用前沿模型，但不想重新学习另一套界面。如今这座桥越来越多是通过 MCP 来搭的：客户端连接到 Atlassian 或第三方的 MCP 服务器，发现 Jira 工具，再直接在对话里使用。
代价：真正承担集成工作的，最后还是用户自己。 如果没人持续补上下文，对话里的信息深度通常不够；写回 Jira 虽然可以做到，但很少是结构化的；而且每一段对话通常都被困在单一客户端里。认证过程也未必顺手：Atlassian 官方 MCP 服务器采用 OAuth，很多团队最后还是会加上一层第三方托管连接器来把体验打磨顺一些。

当你的核心诉求是把 Jira 上下文送进一个强大的外部 AI 工具，而且使用者更看重模型灵活性而不是团队共享流程时，连接器就是更合适的路线。

第三条路：Just

Just 走的是第三条路。它是一款 Forge 原生 Jira 应用，把 AI 体验直接放进 issue 面板里，不是做成旁边的聊天窗口，而是做成一个有步骤的生命周期：先产出洞察，再澄清问题、制定计划、执行任务，最后把结果回写到 Jira 字段。

优势：流程深度更够。 AI 就活在 ticket 里面，而不是另一个客户端里，issue 同时就是输入和输出落点。
优势：一个原生 Jira 系统就能组合多个提供方。 Just 不是单纯地一问一答，而是运行一个结构化流程：分析、澄清、规划、网页研究、图像处理、执行以及回写 Jira。每一步都可以启用、跳过或先审阅，再决定是否写入 issue。因为它从设计上就是多提供方架构，所以团队可以把不同步骤路由给不同模型，并把可复用的项目上下文、可见的执行过程、token 消耗、成本和反馈循环集中在同一个系统里。
代价：配置更多，也要接受平台限制。 Just 确实提供内置试用密钥，方便快速开始，但长期模式仍然是按用量付费，并使用你自己的提供方密钥。这意味着配置会稍微复杂一点：团队里需要有人负责接入、创建和管理组织的 API key。如果团队内部各成员的 AI 使用量差异很大，这种方式反而更合适，因为不会强迫所有人承担一样的固定席位成本。我在几乎没人讨论的 AI 预算问题里更详细拆解过这种预算取舍。与此同时，作为 Forge 应用，它依然要运行在 Atlassian 的平台约束之内。

如果你想把多个 AI 提供方的长处都留在 Jira 里，并放进一个可审查、可追踪的流程中，而且愿意多做一点配置来换取这种控制力，那么 Just 会是合适的路线。

真正的区别：AI 到底住在哪里

如果先把功能清单放到一边，把每条路线都压缩到本质层面，你会发现差别其实是架构上的。

Rovo 像地铁。它覆盖整座城市。你可以一路从 Jira 到 Confluence，再到 Google Drive。线路是固定的，调度有人负责，你只需要相信运营方。

连接器更像网约车。你选车、你选司机、你决定要去哪儿。但路线要你自己交代，整段行程通常是私人的，团队里其他人也看不到完整过程。

Just 则像专线接驳车。它只跑一条走廊，也就是 Jira issue，但这条线有停靠点、有复核点，也有透明度。更重要的是，它还能在路线中途切换提供方，而团队不需要离开 Jira。每个人都能看到这趟车现在在哪、载着什么、什么时候到站。

一张表看懂区别

如果把整场比较压缩成最关键的部分，差异就会非常直观。

维度	Rovo	连接器	Just
AI 所在位置	Atlassian 平台	外部 AI 客户端	Jira issue 工作流
最擅长	跨产品知识检索	前沿模型自由选择	在 Jira 内进行多提供方执行
形态	搜索、聊天、代理	开放式对话	可引导、可审查的流程
团队共享可见性	高	低	高
模型控制权	由 Atlassian 管理	个人自由度最高	团队可按步骤控制
主要代价	模型选择被锁定	上下文和写回过程零散	配置更多，密钥管理更重

说到底，这个选择可以被压缩成一句话：你要的是受控的广泛覆盖、个人层面的模型自由，还是一个能在 Jira 里组合多个提供方优势的结构化流程。

以 Jira 为中心分出三条不同 AI 路线的示意图，直观展示了架构差异：平台覆盖、连接器灵活性与工作流原生执行都从同一点出发，却以不同方式推动工作。

该怎么选

没有哪一条路适合所有团队。一个需要跨六个 SaaS 产品找资料、又不想增加任何基础设施负担的团队，应该先从 Rovo 开始。

一个想在自己的客户端里用 Claude Opus 4.6、GPT-5.4 或 Gemini 3.0 Pro 来分析 backlog 的工程师，通常会更倾向于连接器。

而一个产品团队或交付团队，如果想要的是一个可审查的 Jira 工作流，不同步骤能调用不同提供方，而且成本、质量和输出都对整个团队可见，那就应该看看 Atlassian Marketplace 上的 Just。

很多团队最后会同时使用不止一种路线。它们并不是互斥关系。真正重要的是有意识地选择，依据团队真实的工作方式和真正的摩擦点，而不是上周哪个 AI 演示看起来最惊艳。