Symphony 要把你的 Issue Tracker 變成 24 小時不下班的工程師，這對你意味著什麼

OpenAI 上週發布了一個叫 Symphony 的開源規範，目標很直接：把 GitHub Issues、Jira 這類問題追蹤工具，變成能自主運作的 AI Agent 系統。換句話說，以後你開一張 ticket，可能不需要等人接手，Agent 就自己去分析、寫程式、送 PR。 這不是小功能更新。Symphony 本質上是在定義一套標準架構，讓多個 Agent 能協同工作、互相交棒，而不是孤立的單一 AI 助理。它瞄準的是開發流程裡最破碎的那塊——上下文切換。一個工程師平均一天要在 Slack、GitHub、文件、IDE 之間跳換幾十次，Symphony 想把這些串起來，讓 Agent 處理掉大量的「接力傳遞」工作。 對工程師來說，這意味著什麼？短期內不是失業，而是角色分裂。你會同時扮演兩種人：一個是繼續寫核心邏輯的人，另一個是替 Agent 開 ticket、審 PR、決定要不要 merge 的人。後者聽起來像 senior，但其實任何人都可以做，這才是真正讓人不安的地方。 PM 和設計師也跑不掉。以前一張設計稿交出去，要等工程師排期、實作、回報問題，整個循環可能要兩週。Symphony 這類系統成熟之後，從設計稿到可測試的原型，時間可能壓縮到幾天甚至幾小時。這聽起來很香，但同時也代表「我在等工程師」這個擋箭牌消失了，產品決策的壓力會直接壓回 PM 和設計師身上。 還有一個更根本的問題：如果 Agent 負責大量開 ticket、寫程式、送 PR，那整個 codebase 的品質要怎麼守？今天一個資深工程師 review PR，是因為他知道這段程式碼的歷史、踩過哪些坑、為什麼三個月前做了那個奇怪的決定。Agent 不知道這些，而且不會主動問。 Symphony 還是開源規範，距離真正普及還有一段距離。但方向已經很清楚了：軟體開發的「執行層」正在被 AI 吃掉，留給人的是判斷、品味、和對系統歷史的理解。後面這三件事，你現在有在刻意練習嗎？