OpenAI 內部效率提升 500% 的秘密：不是更強的模型，而是一個 Markdown 文件
整理版優先睇
OpenAI內部效率提升500%的秘密：唔係更強模型，而係一個SPEC.md規範文件
呢篇文章講述OpenAI內部團隊點樣透過一個叫Symphony嘅項目，將效率提升500%。作者係OpenAI嘅工程團隊，佢哋遇到嘅問題係：用Codex生成代碼雖然快，但人類工程師要同時管理多個AI會話，注意力變成系統瓶頸。佢哋嘅解決方案係將項目管理工具Linear變成AI編碼代理嘅控制平面，等AI自己從任務板拉活幹，人類只需審核結果。
Symphony嘅核心竟然係一個Markdown文件（SPEC.md），定義咗問題、組件、狀態機同工作流，然後讓Codex一次過實現成個系統。團隊仲用Symphony嚟構建Symphony自己，實現自舉。呢個做法令試錯成本接近零，工程師可以大量嘗試投機性任務，產品經理直接喺Linear提需求就得。
整體結論係：軟件開發嘅瓶頸正從「寫代碼」轉向「管理寫代碼嘅agent」。OpenAI提倡將隱性流程顯性化、從管理會話轉向管理任務、規範先行實現跟上。Symphony唔係一個產品，而係一個參考實現，邀請大家攞個spec去開發適合自己團隊嘅版本。
- 結論：效率提升500%嘅關鍵係從管理AI會話轉向管理任務，人類角色由微觀管理變為審核結果。
- 方法：Symphony將Linear issue自動分配畀獨立AI agent，每個agent喺隔離工作區運行，Symphony持續監控任務板。
- 差異：核心唔係複雜架構，而係一個Markdown規範文件（SPEC.md），讓Codex讀spec之後一次性實現成個系統。
- 啟發：當改代碼嘅邊際成本接近零，工程師會瘋狂嘗試投機性任務，產品經理可以直接提需求，創新方式徹底改變。
- 可行動點：團隊應將隱性流程文檔化、從管理會話轉向管理任務、寫清楚spec讓AI實現，令試錯成本接近零。
OpenAI Symphony 開源項目原文
文章引用的OpenAI官方博客，詳述Symphony嘅設計理念同實現。
從微觀管理到任務管理：OpenAI嘅瓶頸反思
OpenAI內部團隊用Codex生成代碼初期好成功，但好快撞到新牆——上下文切換。工程師同時開住五個Codex會話，喺終端之間來回跳轉，三個仲頂得順，五個就開始混亂，再多就係災難。
團隊意識到佢哋一直優化錯嘢——佢哋圍繞編碼會話</highlight>合併PR嚟組織工作，但呢啲只係手段，唔係目的。軟件開發嘅真正單元係任務：issue、ticket、milestone。
「如果唔再直接管理AI會話，而係讓AI自己從任務看板上拉活幹呢？」
Symphony嘅核心：一個SPEC.md規範文件
Symphony嘅設計好簡單：每個Linear上嘅open issue自動分配一個獨立AI agent，每個agent喺自己嘅隔離工作區裡面幹活；Symphony持續監控任務板，確保每個活躍任務都有agent喺度跑。agent冧咗自動重啟，新任務嚟咗自動分配，人類只需要review結果。
SPEC.md包含嘅關鍵定義：
- 1 問題定義：將issue tracker變成agent編排器
- 2 所需組件：Workflow Loader、Orchestrator、Workspace Manager等
- 3 狀態機轉換：Unclaimed → Claimed → Running → Released
- 4 工作流定義：一個WORKFLOW.md文件放喺代碼倉庫
- 5 agent之間通信：JSON-RPC協議
仲有一個有趣嘅位：佢哋用Symphony嚟構建Symphony本身——喺Linear開issue，讓Symphony管理嘅agent去實現功能迭代。呢個自舉模式令個工具達到自洽。
限制與教訓：畀agent目標而非指令
OpenAI團隊都坦承有侷限性：由交互式管理agent轉向ticket級別任務分配後，失去咗實時糾偏嘅能力，有時agent完全偏離目標。但佢哋冇手動修補結果，而係將每次失敗轉化為系統改進——加入端對端測試、Chrome DevTools驅動、QA冒煙測試，仲大幅改善文檔。
「畀工具，畀上下文，然後放手讓佢發揮。」
範式轉移：對現代軟件開發嘅啟示
Symphony揭示咗一個緊要嘅範式轉移：軟件開發嘅瓶頸正從「寫代碼」轉向「管理寫代碼嘅agent」。OpenAI已經行到呢一步，其他公司遲早都要面對同樣問題。
可以採取嘅行動：
- 將隱性流程顯性化：團隊裡面「大家都知但從來冇寫低」嘅工作流程而家需要文檔化，因為agent唔識潛規則
- 從管理會話轉向管理任務：唔好再盯實AI每一步操作，集中注意力喺任務定義同結果審核
- 讓試錯成本趨近零：當你可以免費嘗試任何諗法，創新方式會完全唔同
- 規範先行，實現跟上：與其自己寫代碼然後讓AI review，不如寫清楚spec讓AI實現
OpenAI自己都話，Symphony唔係一個佢哋打算長期維護嘅產品，而係一個參考實現——示範Codex App Server配合工作流工具可以做啲咩。真正嘅邀請係：攞呢個spec，讓你自己嘅AI編碼助手去實現一個適合你團隊嘅版本。呢個可能係2026年最值得試嘅工程實踐之一。
OpenAI 內部效率提升500%嘅秘密：唔係更強嘅模型，而係一個Markdown文件
上個月，OpenAI 靜靜雞開源咗一個叫Symphony嘅項目，GitHub上三個星期已經有15K星星。
但係好多人睇完個repo之後都一頭霧水——
「成個系統嘅核心，就係一個 SPEC.md 文件。」
冇複雜嘅微服務架構，冇分佈式調度引擎，冇花哨嘅Web UI。一個Markdown文件，定義咗問題同解法，然後等AI自己去實現。
呢個唔係簡化，而係一次範式轉移。
由「睇住AI寫代碼」到「俾AI派工」
故事要由六個月前講起。OpenAI內部有個團隊做咗一個激進嘅決定：成個項目倉庫，唔寫一行人類代碼，全部由Codex生成。
佢哋成功咗。但係之後撞到一堵新牆——「上下文切換」。
想像一下呢個場景：你係一個工程師，同時開住五個Codex會話，每個做緊唔同嘅任務。你喺終端之間跳來跳去，check嚇邊個跑完，邊個卡住咗，邊個偏離咗需要糾正。三個仲得，五個就開始亂，再多就係災難。
❝"We had effectively built a team of extremely capable junior engineers, then assigned our human engineers to micromanaging them."
（我哋實際上組建咗一隊能力極強嘅初級工程師團隊，然後俾人類工程師去微觀管理佢哋。）
❞
問題嘅本質係：「人類嘅注意力變咗系統樽頸。」
AI夠快、夠聰明，但每個AI會話都需要一個人類喺旁邊睇實。呢個就好似請咗50個實習生，但係得5個導師——實習生再優秀都發揮唔到。
一個關鍵嘅思維轉變
OpenAI團隊意識到，佢哋一路以嚟都喺度優化錯嘅嘢。
佢哋圍繞「編碼會話」同「合併嘅PR」嚟組織工作——但呢啲只係手段，唔係目的。軟件開發嘅真正單元係「任務」：issue、ticket、milestone。
於是佢哋問咗自己一個問題：
「如果我哋唔再直接管理AI會話，而係等AI自己由任務睇板度拉job做呢？」
呢個想法變咗做Symphony。
Symphony到底做咗啲乜
一句講曬：
❝「將項目管理工具（Linear）變成AI編碼代理嘅控制平面。」
❞
具體嚟講：
每個Linear上面嘅open issue，自動分配一個獨立嘅AI agent 每個agent喺自己嘅隔離工作區（workspace）入面做嘢 Symphony持續監控任務睇板，確保每個活躍任務都有一個agent喺度跑 agent死咗？自動重啟。新任務嚟咗？自動分配。 人類只需要review結果
「工程師由「管理AI嘅人」變咗做「審核AI產出嘅人」。」
呢個唔係微調，而係角色重新定義。
500%嘅產出提升，但呢個唔係最重要
喺OpenAI內部，一啲團隊用咗Symphony之後嘅頭三個星期，合入嘅PR數量增加咗500%。Linear嘅創辦人Karri Saarinen都留意到一個異常：workspace創建量突然飆升。
但OpenAI團隊自己話，產出數量唔係最大嘅變化。「最大嘅變化係團隊思考工作嘅方式。」
以前，每一次代碼修改都有成本——你需要投入人類嘅時間同注意力去驅動實現。而家，呢個成本接近零。
「當改變代碼嘅邊際成本接近零時，行為會發生根本性變化：」
工程師開始大量嘗試投機性任務——試一個想法、探索一個重構、驗證一個假設，只保留睇落靠譜嘅結果 產品經理同設計師可以直接喺Linear入面提需求，唔需要checkout代碼庫，唔需要理Codex會話。佢哋描述功能，然後拎返一個包含視頻演示嘅review包 有個工程師喺山間小屋入面，用手機上面嘅Linear App，通過唔穩定嘅WiFi，完成咗三個重要嘅代碼變更
「試錯變得幾乎免費。」
呢個先係真正嘅生產力革命——唔係等你做同樣嘅事更快，而係等你做到以前根本唔會嘗試嘅事。
最反直覺嘅部分：Symphony本質上只係一個Markdown
打開Symphony嘅GitHub倉庫，你會發現佢嘅核心就係一個 SPEC.md 文件。
唔係代碼框架，唔係SDK，唔係CLI工具。就係一份規範文件，用Markdown寫嘅，定義咗：
問題係乜（將issue tracker變成agent編排器） 需要邊啲組件（Workflow Loader、Orchestrator、Workspace Manager等） 狀態機點樣轉（Unclaimed → Claimed → Running → Released） 工作流點樣定義（一個 WORKFLOW.md文件，放喺你嘅代碼倉庫入面）agent之間點樣通訊（JSON-RPC協議）
然後呢？「佢哋叫Codex讀呢個spec，一次性實現咗成個系統。」
參考實現揀咗Elixir語言——一個相對小眾但天生擅長併發嘅語言。為咗打磨spec嘅質量，佢哋仲叫Codex用TypeScript、Go、Rust、Java、Python分別實現咗一次，通過多語言實現嚟發現歧義、簡化設計。
「每種語言都成功咗。」
呢個意味住啲乜？當你嘅系統設計夠清晰，實現就變咗AI嘅機械性工作。規範即係代碼，設計即係實現。
用Symphony嚟構建Symphony
最初版本嘅Symphony就係一個跑喺 tmux 入面嘅Codex會話，輪詢Linear、為新任務生成子agent。用得，但唔可靠。
第二個版本進咗主項目倉庫，利用咗已有嘅agent harness（俾agent提供技能同上下文嘅基礎設施）。
然後，「佢哋用Symphony嚟構建Symphony本身」。呢個唔係文字遊戲——佢哋真係喺Linear上開issue、等Symphony管理嘅agent去實現Symphony嘅功能迭代。
自舉（bootstrapping）係計算機科學入面最優美嘅模式之一。當一個工具能夠構建自身時，佢就達到咗某種自洽。
唔係所有任務都適合Symphony
OpenAI團隊都坦白咗侷限性。
當佢哋由交互式管理agent轉向ticket級別嘅任務分配時，失去咗實時糾偏嘅能力。有時agent嘅產出完全偏離咗目標。
但佢哋冇手動修補結果，而係「將每次失敗轉化為系統改進」：
加入咗端到端測試嘅能力 等agent可以通過Chrome DevTools驅動應用 建立咗QA冒煙測試 大幅改善咗文件
佢哋仲學到一個重要教訓：「唔好將agent當成狀態機入面嘅死板節點。」 模型越來越聰明，解決到嘅問題比你預設嘅框框大得多。
❝"So we eventually moved toward giving agents objectives instead of strict transitions, much like a good manager would assign a goal to a direct report on their team."
（我哋最終轉向俾agent目標而唔係嚴格嘅狀態轉換，就好似一個好嘅管理者會俾下屬分配目標而唔係指令。）
❞
俾工具，俾上下文，「然後放手等佢發揮」。
呢件事對我哋意味住啲乜
Symphony揭示咗一個正在發生嘅範式轉移：
「軟件開發嘅樽頸，正在由「寫代碼」轉向「管理寫代碼嘅agent」。」
OpenAI已經行到呢一步，其他公司遲早都會面對同樣嘅問題。而Symphony提供咗一個答案——可能唔係唯一嘅答案，但佢指出咗方向：
「將隱性流程顯性化」。團隊入面嗰啲「個個都知道但從來冇寫低」嘅工作流程，而家需要文件化，因為agent唔識潛規則 「由管理會話到管理任務」。唔好再睇住AI嘅每一步操作，將注意力放喺任務定義同結果審核上面 「等試錯成本接近零」。當你可以免費嘗試任何想法時，創新嘅方式會完全唔同 「規範先行，實現跟上」。與其自己寫代碼然後俾AI review，不如寫清楚spec俾AI實現
OpenAI自己都話，Symphony唔係一個佢哋打算長期維護嘅產品。佢更像一個參考實現——一個示範，話俾你知Codex App Server配合工作流工具可以做到啲乜。
「真正嘅邀請係：拎呢個spec，叫你嘅AI編碼助手去實現一個適合你團隊嘅版本。」
呢個可能係2026年最值得嘗試嘅工程實踐之一。
❝原文連結：https://openai.com/index/open-source-codex-orchestration-symphony/
❞
OpenAI 內部效率提升 500% 的秘密：不是更強的模型，而是一個 Markdown 文件
上個月，OpenAI 悄悄開源了一個叫 Symphony 的項目，GitHub 上三週拿下 15K star。
但很多人看完 repo 之後都懵了——
「整個系統的核心，就是一個 SPEC.md 文件。」
沒有複雜的微服務架構，沒有分佈式調度引擎，沒有花哨的 Web UI。一個 Markdown 文檔，定義了問題和解法，然後讓 AI 自己去實現。
這不是簡化，這是一次範式轉移。
從"盯着 AI 寫代碼"到"給 AI 派活"
故事要從六個月前說起。OpenAI 內部有個團隊做了一個激進的決定：整個項目倉庫，不寫一行人類代碼，全部由 Codex 生成。
他們成功了。但隨後撞上了一堵新牆——「上下文切換」。
想象一下這個場景：你是一個工程師，同時開着五個 Codex 會話，每個在做不同的任務。你在終端之間來回跳轉，檢查哪個跑完了，哪個卡住了，哪個跑偏了需要糾正。三個還行，五個就開始混亂，再多就是災難。
❝"We had effectively built a team of extremely capable junior engineers, then assigned our human engineers to micromanaging them."
（我們實際上組建了一支能力極強的初級工程師團隊，然後讓人類工程師去微觀管理他們。）
❞
問題的本質是：「人類的注意力成了系統瓶頸。」
AI 夠快、夠聰明，但每個 AI 會話都需要一個人類在旁邊盯着。這就像請了 50 個實習生，卻只有 5 個導師——實習生再優秀也發揮不出來。
一個關鍵的思維轉換
OpenAI 團隊意識到，他們一直在優化錯誤的東西。
他們圍繞"編碼會話"和"合併的 PR"來組織工作——但這些只是手段，不是目的。軟件開發的真正單元是「任務」：issue、ticket、milestone。
於是他們問了自己一個問題：
「如果我們不再直接管理 AI 會話，而是讓 AI 自己從任務看板上拉活幹呢？」
這個想法變成了 Symphony。
Symphony 到底做了什麼
一句話總結：
❝「把項目管理工具（Linear）變成 AI 編碼代理的控制平面。」
❞
具體來說：
每個 Linear 上的 open issue，自動分配一個獨立的 AI agent 每個 agent 在自己的隔離工作區（workspace）裏幹活 Symphony 持續監控任務看板，確保每個活躍任務都有一個 agent 在跑 agent 崩了？自動重啓。新任務來了？自動分配。 人類只需要 review 結果
「工程師從"管理 AI 的人"變成了"審核 AI 產出的人"。」
這不是微調，這是角色重定義。
500% 的產出提升，但這不是最重要的
在 OpenAI 內部，一些團隊在使用 Symphony 後的前三週，合入的 PR 數量增長了 500%。Linear 的創始人 Karri Saarinen 也注意到了一個異常：workspace 創建量突然飆升。
但 OpenAI 團隊自己說，產出數量不是最大的變化。「最大的變化是團隊思考工作的方式。」
以前，每一次代碼修改都有成本——你需要投入人類的時間和注意力去驅動實現。現在，這個成本趨近於零。
「當改變代碼的邊際成本接近零時，行為會發生根本性變化：」
工程師開始大量嘗試投機性任務——試個想法、探索個重構、驗證個假設，只保留看起來靠譜的結果 產品經理和設計師可以直接在 Linear 裏提需求，不需要 checkout 代碼庫，不需要管 Codex 會話。他們描述功能，拿回一個包含視頻演示的 review 包 有個工程師在山間小屋裏，用手機上的 Linear App，通過不穩定的 WiFi，完成了三個重要的代碼變更
「試錯變得幾乎免費。」
這才是真正的生產力革命——不是讓你做同樣的事更快，而是讓你能做以前根本不會嘗試的事。
最反直覺的部分：Symphony 本質上只是一個 Markdown
打開 Symphony 的 GitHub 倉庫，你會發現它的核心就是一個 SPEC.md 文件。
不是代碼框架，不是 SDK，不是 CLI 工具。就是一份規範文檔，用 Markdown 寫的，定義了：
問題是什麼（把 issue tracker 變成 agent 編排器） 需要哪些組件（Workflow Loader、Orchestrator、Workspace Manager 等） 狀態機怎麼轉（Unclaimed → Claimed → Running → Released） 工作流怎麼定義（一個 WORKFLOW.md文件，放在你的代碼倉庫裏）agent 之間怎麼通信（JSON-RPC 協議）
然後呢？「他們讓 Codex 讀這個 spec，一次性實現了整個系統。」
參考實現選了 Elixir 語言——一個相對小眾但天生擅長併發的語言。為了打磨 spec 的質量，他們還讓 Codex 用 TypeScript、Go、Rust、Java、Python 分別實現了一遍，通過多語言實現來發現歧義、簡化設計。
「每種語言都成功了。」
這意味着什麼？當你的系統設計足夠清晰，實現就變成了 AI 的機械性工作。規範即代碼，設計即實現。
用 Symphony 來構建 Symphony
最初版本的 Symphony 就是一個跑在 tmux 裏的 Codex 會話，輪詢 Linear、為新任務生成子 agent。能用，但不可靠。
第二個版本進入了主項目倉庫，利用了已有的 agent harness（給 agent 提供技能和上下文的基礎設施）。
然後，「他們用 Symphony 來構建 Symphony 本身」。這不是文字遊戲——他們真的在 Linear 上開 issue、讓 Symphony 管理的 agent 去實現 Symphony 的功能迭代。
自舉（bootstrapping）是計算機科學裏最優美的模式之一。當一個工具能夠構建自身時，它就達到了某種自洽。
不是所有任務都適合 Symphony
OpenAI 團隊也坦誠了局限性。
當他們從交互式管理 agent 轉向 ticket 級別的任務分配時，失去了實時糾偏的能力。有時 agent 的產出完全偏離了目標。
但他們沒有手動修補結果，而是「把每次失敗轉化為系統改進」：
加入了端到端測試的能力 讓 agent 能通過 Chrome DevTools 驅動應用 建立了 QA 冒煙測試 大幅改善了文檔
他們還學到一個重要教訓：「不要把 agent 當成狀態機裏的死板節點。」 模型越來越聰明，能解決的問題比你預設的框框大得多。
❝"So we eventually moved toward giving agents objectives instead of strict transitions, much like a good manager would assign a goal to a direct report on their team."
（我們最終轉向給 agent 目標而非嚴格的狀態轉換，就像一個好的管理者會給下屬分配目標而非指令。）
❞
給工具，給上下文，「然後放手讓它發揮」。
這件事對我們意味着什麼
Symphony 揭示了一個正在發生的範式轉移：
「軟件開發的瓶頸，正在從"寫代碼"轉向"管理寫代碼的 agent"。」
OpenAI 已經走到了這一步，其他公司遲早也會面對同樣的問題。而 Symphony 提供了一個答案——也許不是唯一的答案，但它指出了方向：
「把隱性流程顯性化」。團隊裏那些"大家都知道但從沒寫下來"的工作流程，現在需要文檔化，因為 agent 不懂潛規則 「從管理會話到管理任務」。別再盯着 AI 的每一步操作，把注意力放在任務定義和結果審核上 「讓試錯成本趨近於零」。當你可以免費嘗試任何想法時，創新的方式會完全不同 「規範先行，實現跟上」。與其自己寫代碼然後讓 AI review，不如寫清楚 spec 讓 AI 實現
OpenAI 自己也說了，Symphony 不是一個他們打算長期維護的產品。它更像一個參考實現——一個示範，告訴你 Codex App Server 配合工作流工具能做到什麼。
「真正的邀請是：拿這個 spec，讓你的 AI 編碼助手去實現一個適合你團隊的版本。」
這可能是 2026 年最值得嘗試的工程實踐之一。
❝原文連結：https://openai.com/index/open-source-codex-orchestration-symphony/
❞