Atlassian 在 8 月中旬官宣了 Cursor in Jira 集成，所有 Jira 付费版用户可以直接在 Jira 里把工单分配给 Cursor 的云端 Agent 执行。知乎6 月底，GitHub 的 changelog 里 Copilot for Jira 已经正式 GA。小红书再加上 8 月初 Rovo MCP v2 更新，这三个月的信号非常一致——Jira 正在从"给人看的任务登记表"，变成 AI 编程 Agent 的"派工中枢"。
先把这条链路用一句话讲清楚：把工单分配给 Cursor，或者在评论里写 @Cursor，Cloud Agent 会读取工单的标题、描述、评论和仓库设置，执行任务，再把进度、完成摘要和 PR 链接带回原工单。知乎任务中还可以用 repo=、branch=、model= 覆盖默认的仓库、分支和模型，团队也能配置路由规则，按关键词把不同工单送到对应仓库。
听起来很美：backlog 里那些一直没人腾出手的小任务，终于多了一个执行者。但这里要先泼一盆冷水：返回 PR ≠ 任务完成。PR 只代表任务走到了交接点，不代表代码正确、已经验收，更不代表可以自动合并上线。Cursor 官方文档明确提醒：Agent 可能出错，代码和响应仍需要人来审查。知乎
Atlassian 官方讲的主要是"上下文"的故事。他们引用一项持续多年的 DX（开发者体验）研究：开发者研发速度跟不上模型能力增长，原因是 Agent 缺乏上下文；上下文切换、任务规划、Bug 分类和代码评审是 IDE 之外的主要痛点。所以官方让 Agent 通过 Teamwork Graph 直接从 Jira、Confluence 拉取组织上下文，内部测试数据是使用 Teamwork Graph 上下文的 Agent 回答质量提升 44%、Token 消耗减少 48%。知乎这是 Atlassian 自己的内测口径，建议当方向参考，不当基准数据。
方向是对的，但真正的坑不在工具，在工单。
一张工单写"优化一下登录流程"，同事看了大概知道要修哪个问题、动哪个仓库，因为有口头约定和团队记忆补位。Agent 看到的却只有这句目标不明、边界不清的话：“优化"是修复已知行为还是重做交互？目标哪个仓库？基于哪条分支？什么算完成？以前你写"优化登录页报错”，同事会来问你到底优化什么，现在 Agent 可能直接开干，然后很快给你一个跑偏的 PR。小红书这些空白不会自己消失，只会变成错误假设，和一个没人能快速判断合不合格的 PR。
社区实战文章里有个判断我很认同：Agent 的速度首先放大的，是任务定义的质量。知乎另一位作者说得更直接：以后会用 Agent 的人，不是最会写 prompt 的人，而是最会把模糊需求拆成可验证任务的人。小红书
所以把工单分配给 Cursor 之前，先对照这四项检查（注意：这是社区基于 Cursor 官方文档做的归纳，不是官方术语）：
一、范围（Scope）：改什么、不改什么。别写"优化登录流程"，写"修复某模块 token 过期后重复登录的问题，不动无关页面"。检查点：Agent 只看工单，能否区分目标工作和"顺手多做一点"？
二、路由（Routing）：去哪个仓库改、基于哪条基线分支。必要时明确写出 repo=、branch=，确认路由规则的关键词不会误命中其他仓库。任务描述再清楚，送错仓库也没有意义。
三、权限（Permission）：它能接触哪些代码和数据。第一次试跑别挑权限敏感、数据边界模糊的任务，让访问保持最小、每一项都能解释必要性。
四、验收（Acceptance）：拿什么证据判断完成。提前写清测试、复现步骤、预期行为，并指定人类复核人。检查点：工单作者不在线时，复核者能否只靠工单加 PR 判断通过还是退回？
四项全能回答，再按下分配。
使用前提也说清楚，缺一个都跑不起来：支持 Rovo 的 Jira Commercial Cloud、Cursor Teams 或 Enterprise 订阅、已连接代码托管、启用按量计费；Privacy Mode 支持，旧版 legacy mode 不支持。知乎
Atlassian 已经公布 Data Center 的停售时间表，将在 2029 年 3 月 28 日全面停售 Data Center 产品。知乎未来三年，Data Center 的新购、扩容与支持将逐步关闭。如果你的团队还在 Data Center 上，或者数据合规要求不能出境，这波功能暂时和你无关——Cloud 是它未来唯一会拿到 AI 功能的形态，这背后是另一个更重的迁移决策话题。
准备试的话，建议第一张工单小到可以轻松退回来：从 backlog 挑一张低风险、范围窄、仓库明确、已有测试或结果容易验证的任务，比如边界清楚的小 bug、一项测试补充、一个输出要求明确的小型调查任务。跨仓库重构、权限敏感改动、目标还在讨论的需求，先别交。四步就够：选一张小工单→补齐四项→分配给 Cursor→PR 回来后由人按工单证据复核。试跑顺利的话，真正值得沉淀的不是那一个 PR，而是一张团队以后可以复用的工单模板。
最后一个值得盯的风险：Agent 的执行入口是工单文本，而工单文本是可以被外部输入污染的。社区已经在讨论这类供应链风险：当 Agent 被恶意构造的 issue 描述诱导，写下被精心设计的问题代码时，传统的安全扫描器很难在静态分析中抓住它。知乎Rovo MCP v2 已经让 AI 可以往 Jira 写回工作项、编辑评论，治理边界会是管理员绕不开的话题。小红书
这次变化值得看，值得拿一张小工单试，但不值得一次性交出整个 backlog。
你们团队的 Jira 里，哪一类工单最适合先交给 Agent？
