迎戰 AI 原生軟體開發：Jira 的全面演進與革新

全新推出的 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 的下一個篇章，絕不僅僅是單純地跟蹤軟體工作的進度，而是全力協助人類與智能體並肩作戰，共同完成卓越的工作。