迎战 AI 原生软件开发：Jira 的全面演进与革新
- Atlassian
- 5天前
- 讀畢需時 7 分鐘
全新推出的 Jira 与 Teamwork Graph 功能，助力工程团队跨越“人类与 AI 智能体”的边界，实现工作的全面规划、指派、治理与效能度量。
无论是在与客户交流，还是在与 Atlassian 自身的工程团队沟通时，我听到的反馈都高度一致：功能强大的编程智能体正以空前的速度被广泛采纳，并彻底改变了软件开发的面貌。然而，软件交付中那些真正啃硬骨头的部分依然相当棘手。
团队仍然需要决定该构建什么、为什么构建它；他们需要理解正在修改的系统以及有哪些关键的约束条件；他们必须明确“完成”的定义，并确保输出的代码可以安全上线。
这就是“AI 生产力鸿沟”背后的现实。 在我们与 DX 联合对专业工程团队进行的一项长期研究中发现：虽然 AI 的使用率飙升了 65%，但开发人员的整体吞吐速度并未按比例增长。其增长率最终在 15% 封顶，许多企业的平均增幅甚至仅为 10%。
这一鸿沟的出现，并非因为模型不擅长写代码，而是因为软件开发从来都不只是写代码。它的本质是在真实的组织架构中，将业务目标、战略和上下文转化为可运行的软件。
二十多年来，Jira 历经演进，满足了各种规模和协作模式的软件团队的需求——我们是核心的“事实源（Source of Truth）”，记录着要构建什么、谁来执行、进展如何以及交付了什么。
而今天，软件团队的形态正在发生剧变。
AI 原生的软件开发团队需要一种全新的系统：在这个系统中，提供给智能体的上下文必须是核心要素，任务被委派给智能体执行，而人类则负责掌舵与评审。工程师、产品经理、设计师和安全团队将为工作注入关键的判断力和上下文。
这是一种全新的人机协同模式——拥有清晰的规划、共享的上下文，以及对交付产物的验证能力，确保团队能为其最终质量负责。
今天，我们正式宣布在 Jira 中推出全新的“智能体化产品开发功能”，正式迎接这一变革。 团队现在可以利用 AI 规划工作、将业务意图转化为契合智能体的需求规范、向编程智能体指派任务、监控会话流程、自动化工程循环，并实现 AI 投入成本与产出效益的精准度量。
Jira 始于缺陷跟踪工具，如今已成为数百万团队工作的核心记录系统。未来，我们将继续演进，全力赋能面向未来的 AI 原生团队。
何谓“AI 原生软件开发”？
落地到实际层面，它的含义是：软件开发生命周期必须对智能体而言变得清晰易懂，同时又不能降低对人类的问责标准。
具体而言，包含以下三个核心要素：
在工作开始前，必须对“意图”进行结构化：智能体需要的不仅仅是一个提示词或一个 Jira 摘要。它需要明确的需求、相关的架构设计、决策历史以及团队已知的约束条件。
选择不同的智能体，不应导致协作流程的分裂：一个团队可能会使用 Cursor IDE 进行前端开发，使用 Claude Code 处理复杂的后端任务，使用在云端沙箱中运行的自定义智能体来应对独特的代码库，并使用 Jira Coding Agent 以低成本自动化处理日常修复。无论运行环境如何切换，工作流都不应该分叉。
自主性必须保持“可观测性”：智能体的会话不能凭空消失在终端、浏览器标签页或断联的日志中，更不能把关键上下文锁在本地设备里。团队需要看清发生了什么、谁进行了评审，以及是由哪项工作任务触发的。
将这三点结合起来，整个系统就会发生质变。智能体不再是孤立运行的副驾驶（Copilot），而是开始与团队其他成员一样，深度参与到同一个 SDLC 中。
这就是 Teamwork Graph 的价值所在。它是 Atlassian 的上下文层——一张将工作、代码、人员、决策和依赖关系串联起来的动态图谱，帮助智能体不仅能看懂眼前的任务，还能理解其背后的整个系统环境。
为什么说 Jira 是承载这一变革的不二之选？
随着大量编码工作移交给智能体，它们需要被清晰定义、且包含丰富显式上下文的任务，从而在交付高质量代码的同时，有效控制 Token 成本。然而，上下文几乎从不会散落在单一地方。这也正是 Atlassian 构建 Teamwork Graph 的原因：它将 Jira 中的原子任务、Confluence 中的需求文档、Slack 中的讨论沟通、GitHub 中的代码上下文以及 Jira Product Discovery 中的客户洞察完美融合在一起。
Jira 利用 Teamwork Graph 提供的上下文，将宏大的想法拆解为智能体可处理的原子任务，并在其工作时打包打包好所需的上下文。
缺少了上下文，智能体产出的代码反而在后续会引发生产力瓶颈。 它们可能会过于机械地解决工单，忽略了架构层面的约束，或者生成了一个看似合理、实则需要资深工程师花上一个小时去重构清理的 PR。
因此，这次发布不仅仅是为了在更多地方塞进更多智能体，而是为了让智能体能够访问到您团队已经赖以生存的组织记忆。
Teamwork Graph 提供上下文，而 Jira 则负责将这些上下文转化为工作流：意图在此发起、智能体任务在此指派、会话历史在此记录，最终的输出产物也在此提交供人类评审。
我们发布了什么
智能体化工作模式通常在一些可预测的地方出现断层：模糊的规划、低效的交接，以及团队不知如何信任的输出物。我们正是针对这些痛点进行了产品设计。
1. 结合更丰富的上下文进行规划
Jira Planner 将“规范驱动开发”引入 Jira。对于复杂的项目，Jira Planner 可以从您的代码库、Jira 和 Confluence 的历史记录以及团队上下文中提取信息来定义需求，并在 Confluence 中生成结构化的技术规范。这份产物既能让团队成员一目了然，也能直接供智能体高效读取。同一份资产，服务两类受众。
Jira for Slack 将孕育灵感与工作的聊天对话，转化为包含丰富上下文的 Jira 工作项。团队可以直接 @Jira 来创建工作、捕捉上下文细节、将对话更新同步为评论，并在不脱离当时讨论语境的情况下，直接向编程智能体指派任务。此外，我们针对 Microsoft Teams 的扩展功能也即将推出。
Loom 视频提示词可以将您的演示和口述直接转化为结构化的指令，供智能体执行任务。您只需录制屏幕并讲解任务，Loom 就会捕捉您的屏幕画面、点击动作、链接以及语音指令，生成一份行动计划。只需点击几下，即可将其转化为智能体就绪的 Jira 工作项。
2. 将工作精准委派给合适的智能体
Jira 中的智能体允许团队将工作项直接指派给 Claude Code、Cursor 或 GitHub Copilot，且即将支持 Codex。Jira 始终作为“事实源”稳固全局，同时将丰富的上下文无缝传递给正在执行任务的智能体。
Jira Coding Agent 已内置于所有 Jira 付费方案中。它能够接收定义清晰的工作项，通过 Teamwork Graph 利用企业级上下文和代码智能进行修改，并在无需开发人员为了日常修复而切换到本地环境的情况下，直接返回一个可供评审的 PR。
Jira 中的智能体会话管理：一目了然地查看哪些 AI 编程智能体遇到了卡点、哪些正在等待评审、哪些已经完成。每位使用 Jira 的工程师都可以在单个视图中，集中观测其所在空间和代码库中运行的智能体会话，并依优先级对需要关注的事项进行分组排序。
3. 通过体系化治理，规模化扩展智能体化工程
编程智能体自动化允许团队利用 Jira 企业级的自动化规则构建器，将缺陷修复、漏洞修补、测试生成和文档更新等日常工作自动分发给智能体。当 PR 准备就绪时会主动通知工程师，且执行的每一步都会与原始请求紧密关联。
智能体化工程项目模板帮助团队在几分钟内搭建起契合智能体运转的 Jira 项目，其中工作流、状态、跟踪机制和集成组件均已预配置完毕。
DX AI 成本管理为工程主管提供了一种洞察 AI 开发经济效益的方法。它统一了 Claude、Cursor、GitHub Copilot 和 Jira 等工具的开销与 Token 数据，将这些投入映射到具体的团队和项目上，并在 DX 中估算出每个 PR 的成本。
属于人类与智能体的协同系统
我们已经在 Atlassian 内部的工程团队中全面跑通了这些模式。我们发现，Atlassian 的 Teamwork Graph 为这些功能提供了强大的企业级上下文支撑，贯穿整个 SDLC，将工作、团队、目标、代码和知识紧密相连，从而让智能体能够以更高的相关性和准确性采取行动。
在内部基准测试中，得到 Teamwork Graph 赋能的智能体，其结果准确度提升了 44%，同时消耗的 Token 减少了 48%。不仅如此，我们还看到了 PR 周期时间的缩短，以及在日常事务性工作上投入时间的显著减少。
“AI 原生开发面临的瓶颈不在于智能体的能力，而在于如何进行规模化的协同，从而让我们的工程师保持专注。我们正与 Atlassian 合作解决这一难题：打造一个统一的平台，让每一个智能体的动作都清晰可见、处于治理之中，并与业务成果紧密挂钩。”
—— Sean Joerg Reddit 副首席信息安全官（Deputy CISO）兼企业工程负责人
智能体势必会改变软件构建的方式。但它们并不会取代人类的商业判断、上下文理解或最终的问责制。
这正是 Jira 必须演进的原因。Jira 的下一个篇章，绝不仅仅是单纯地跟踪软件工作的进度，而是全力协助人类与智能体并肩作战，共同完成卓越的工作。
留言