北京
“開發者不喜歡用Jira。”Atlassian DevAI工程負責人Ming Wu在接受The New Stack采訪時開門見山。這句話幾乎成為行業里的半公開調侃，但凡看過Hacker News評論區的人，都清楚這已經算是委婉的說法。Wu后來也補充道：“開發者是一群很難取悅的人。”
正因為此，Atlassian在周三推出一批圍繞AI的功能更新，目標直指把開發者留在Jira里，而不只是讓產品經理獨享。Wu的假設很直白：“讓開發者花更多時間在Jira里，是這次體驗設計的初衷。我們要讓開發者覺得這是個好地方，一個方便干活的地方，而不是非跑回IDE重新拽一堆上下文。”在一個把一切搬回IDE幾乎成為肌肉記憶的群體面前，這番話聽起來像是要反過來重塑工作流。
這次更新的核心是一套把Jira工作項直接甩給開發工具和AI代理的體系。團隊可以把Jira tasks指派給Claude Code、Cursor、GitHub Copilot，后續還會接入OpenAI的Codex。更激進的是內置的Jira Coding Agent，它不需要任何本地環境配置，所有付費計劃都帶，直接能把工作項生成pull request。點進運行中的會話，會彈出一個類似VS Code的編輯器，帶代碼差異對比和終端，Wu把它描述為“把你IDE環境搬到了云端”。
此外還有幾個讓計劃、生成和協作更順手的組件。Jira Planner能從Jira和Confluence的歷史記錄里提取團隊上下文，自動生成技術規格文檔并沉淀到Confluence。Jira for Slack則允許在討論串里@Jira，當場建工作項。自動化規則可以把修bug、修復漏洞、生成測試這類活，在后臺分發給不同的代理去執行，開發人員只需要關注結果。
歷史上，Jira的使用重心一直偏向工程經理和技術負責人，尤其在規劃階段。Wu承認：“人們天生不愛寫太多細節，而且他們的活都在本地，就想回到IDE，這是事實。”現在通過把工作“分配”給代理，Atlassian試圖打破這種慣性。工作項多了一個指派對象——人機并列，可以挑合適的那個去執行。“代理和人是肩并肩的，你選擇哪個更合適就用哪個。”Wu說。如此，開發者不再必須親自踩進每個表單，許多流程性作業被推到后臺。
但把AI塞進Jira，真的能扭轉開發者對它的固有印象嗎？反方意見會指出，Jira的笨重不僅在于手動操作，更在于流程本身的設計；把工作代理生成代碼，不代表團隊協作里的摩擦會消失。正方則可以看到，Atlassian并非要再造一個IDE，而是讓規劃、生成、分配、追蹤這些環節在同一個系統里閉環，減少切來切去的損耗。無論哪邊更占理，一個棘手的行業問題已經浮現：如果代碼生成變得極快，瓶頸會不會只是轉移到review階段？
Wu的回答很冷靜：“說到底，瓶頸還是人。”代碼審查、理解、決策這些事，代理還沒法接手。更深的痛，源自組織內部對復雜度的管理。Atlassian的解題思路是用代理承擔機械部分，讓開發者把注意力留給真正需要判斷的環節。但歷史經驗表明，工具越省力，往往會在別處堆積出新的認知負載。Jira這次升級，更像是一場關于“開發者的默認工作界面應該是什么”的實驗，而對Jira的反感，恐怕不是幾項AI功能就能完全消解的。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
