对用 Jira 的团队来说，这个 8 月相当热闹。
8 月 13 日，Atlassian 官宣 Jira 集成 Cursor：工单可以直接指派给 Cursor，也可以在评论区写一句"@Cursor"，召唤它的云端 Agent 接手干活——读工单标题、描述、评论和仓库配置，自己去执行，最后把进度、摘要和 PR 链接带回原工单。知乎两天后，SpaceX 以 600 亿美元完成对 Cursor 的收购，创下史上最大创业公司收购纪录，Cursor 并入 SpaceXAI。36氪再过两天，合并后的团队发布代码托管平台 Origin，直接对标 GitHub——而 Origin 发布当天，GitHub 恰好宕机了几个小时。知乎
一周三连击。对 Jira Cloud 团队来说，问题已经从"这是什么功能"，变成了"这条流水线现在该不该开"。
门是开的，但门槛在门的另一侧
Atlassian 官方口径很好看：Cursor in Jira"面向所有付费 Jira 订阅用户开放"。知乎但对照 Cursor 官方文档的前提条件，会发现门槛其实在另一侧：
Jira 侧需是支持 Rovo 的 Commercial Cloud；
Cursor 侧需要 Teams 或 Enterprise 订阅，个人 Pro 不行；
已接入代码托管（如 GitHub），并启用 Cursor 的按量计费；
支持 Privacy Mode，不支持 legacy mode，云端 Agent 需要临时代码存储空间。
也就是说，Jira 开了门，能不能进去取决于你的 Cursor 订阅档位。知乎有团队看到"全量开放"以为可以直接上手，真到配置时才发现要先升席位、开按量计费。算成本的话，这不是免费功能，而是叠在 Jira 和 Cursor 订阅之上的"第三张账单"：席位费 + Agent 用量费。Atlassian 官方数据还说，Agent 接入 Teamwork Graph 上下文后，答案质量提升 44%、token 消耗下降 48%——这是他们自家内测数据，可以当参考，别当承诺。知乎
真正要掂量的是时机
8 月 13 日开放入口，8 月 15 日收购完成，这个时间线有点微妙。
按 The Information 的报道，这次收购不是保留被收购方独立性的那种：Cursor 被整体拆解，现金、知识产权、员工和 5 万份企业客户合同全部并入 SpaceXAI。知乎全员会上管理层承认，内部代号 Sand Agent 很可能以"Grok Bot"的名字面世——而几个月前，CEO 还在对全员说 SpaceXAI 非常看重 Cursor 品牌。
前两天又有新料。据 36氪援引 The Information 报道，收购后的首次全员会上，马斯克对 1000 多名员工坦言"Grok 落后了"，同时点名 Anthropic 目前领先。36氪从这个角度看，600 亿美元收购的逻辑就清楚了：买的不只是一个写代码工具，更是企业开发流程的入口。这也解释了 Origin 为什么赶在这个节点发布——堆叠式 PR、合并队列、AI 冲突解析，全是为"多个 Agent 同时改一个仓库"准备的；早在今年 3 月，Truell 就披露 Cursor 内部合并的 PR 已有 35%–40% 由 Agent 自主完成。知乎
那么对想开的团队，这意味着两点：
第一，这条集成的未来没人能担保。今天叫 Cursor in Jira，明天执行者可能改名 Grok，计费可能变，路线图可能重写。这不是贩卖焦虑，是整个行业正在眼前发生的事。
第二，也不必过度恐慌。那 5 万份企业合同正是 SpaceX 花 600 亿买来的资产，没人会一夜之间砍掉企业客户的流水线。"把工单交给 Agent"是 SpaceXAI 押了重注的方向，不是试验性玩法。
成本账有三层，不只是订阅费
认真评估的话，别只盯订阅费：
显性成本：Jira Commercial Cloud 席位 + Cursor Teams/Enterprise 席位 + 云端 Agent 按量计费，三张账单叠加；
准备成本：Agent 能执行好的，是范围明确、仓库分支写清、权限边界清楚、验收标准清楚的工单。"优化一下登录流程"这种写法丢给 Agent，只会得到跑偏的 PR。Agent 的速度，首先放大的是任务定义的质量；
审查成本：PR 链接带回来只是交接，不是验收。今年 4 月，Cursor Agent 9 秒删库的事故，两天内在 Hacker News 攒了 900 条评论。知乎连 Cursor 自己都吃过 AI 代码审查缺失的亏——后来被迫上线自动审查系统，判断哪些代码问题需要升级给人，今夏才制定第一份正式安全政策。36氪把仓库钥匙交给 Agent 之后，人工审查只能收紧，不能放松。
谁可以试点，谁应该等
下面四条都满足，可以从下周开始小规模试点：
Jira Commercial Cloud 且支持 Rovo；
已订阅 Cursor Teams 或 Enterprise（不是还在犹豫买不买）；
代码托管权限边界清楚，能划出低敏感仓库/试点范围；
积压工单质量尚可，或愿意借这次机会把工单模板补齐。
沾上任何一条，再等一个季度更稳：
团队还在用 Cursor 个人版，门槛都没过；
仓库里有敏感数据或客户代码，权限评审流程没建好；
没有稳定的代码审查带宽，Agent 提了 PR 没人看；
工单几乎全是一句话需求，没有验收标准。
要试点，第一张工单这样挑
社区已经有可复用的经验。知乎作者贾斯汀把官方工作流归纳成"四项卡"（这是基于官方文档的编辑归纳，不是官方术语）：按下"指派"之前，先问自己四个问题。知乎
Scope：改什么、不改什么——写清对象、预期行为、影响边界；
Routing：哪个仓库、哪个分支——工单里直接写 repo=、branch=，确认路由规则不会打偏；
Permission：能动哪些代码/数据——权限最小化，写清每次访问的用途；
Acceptance：拿什么证据算完成——测试、复现步骤、最终审查人提前写好。
第一张工单挑"小而容易失败"的：低风险、范围窄、仓库清楚，有现成测试或结果容易验证。跨仓库重构、权限敏感改动、还在讨论中的需求，先别碰。另外提醒一句：Jira 的 AI 训练新规 8 月 17 日刚生效，如果你们团队的数据合规口径还没定，建议先把隐私设置问题一起解决，再谈开启。
不开的话，盯住这三个信号
命名：官方集成文档里的"Cursor"，会不会换成 Grok 系产品；
前提条件：集成向哪些订阅档位开放，按量计费规则是否变化；
Origin 的动向：Origin 已经把"代码托管"做成自己的阵地，挖了 GitHub 工程师，收购了代码审查创业公司 Graphite。36氪如果它以后直接对接 Jira，"代码放哪儿"会成为 Jira 团队的又一个决策点。
一句话总结：Jira 工单派给 Agent 这个方向值得盯，但现阶段只适合低成本试点，不适合当依赖。
你们团队的 Jira，第一张交给 Agent 的工单，会挑什么活？
