SuperPlane 1.0 發布：把待辦、程式代理、CI 與人工審查接成軟體工廠
SuperPlane 1.0 將待辦評估、程式代理、測試與 PR 回饋接進團隊共用流程，並提供 Apache 2.0 引擎。解析信心分數、驗證證據、52% 內部數字與自架、雲端費用差異。
工程師請 AI 改完程式後，工作常還沒結束。測試失敗要補脈絡，審查意見要再交回代理，每個人的環境與做法又可能不一樣。
SuperPlane 在 2026 年 10 月 27 日發布 1.0 穩定版，把待辦評估、代理執行、持續整合測試與審查回饋接進團隊共用的軟體工廠。
這裡的工廠不是一個新的程式模型，而是圍繞既有代理安排工作、保留狀態與證據的系統。團隊可以選模型，也可以使用公開的 Apache 2.0 引擎在自己的基礎設施運作。
創辦人說，上個月團隊合併的 PR 中有 52% 經 SuperPlane 自動化完成。這是他們內部的合併比例，不等於工程時間省下 52%，也不能保證每一項需求都適合自動執行。
我會先看它能否把一個定義清楚的任務交回可審查的變更，再評估吞吐量。如果成功條件還說不清楚，增加平行代理只會擴大需要人追查的工作。
因此，軟體工廠的第一個關卡，不是立即叫代理寫程式，而是先判斷待辦能否成為一項有邊界、可驗證的工作。
SuperPlane 如何判斷待辦是否能交給代理？
系統先評估任務是否有清楚結果、足夠脈絡與可觀察的驗證方式，再讓工作進入執行。
待辦可以來自連接的議題管理服務，也能在看板手動建立。不過，「有人記下一個想法」與「程式代理有足夠條件完成」之間，仍可能差一段需求整理。
工作進件文件用清晰度、複雜度與可驗證性等條件協助判斷。例如只說改善登入，還不足以決定要改外觀、速度，或修正特定失敗情況。
若要求已指出觸發條件、期待結果與可查證的測試，代理就比較有依據。這裡的信心分數用來協助分流，成功率與安全程度則需要另外驗證。
發現工作，不等於立即批准執行
對模糊任務，文件建議先改善原始議題，讓後面的人與代理都能取得更新後的需求，而不是只在某次聊天補一段只有當事人看得到的說明。
開始執行則是另一個界線。系統發現待辦、分析準備程度，不能被解讀成已經獲准對所有議題動手。團隊仍須安排誰能啟動哪些工作。
以登入問題為例，應先界定可修改的行為和不能改動的規則。這個示例用來說明任務邊界，不是宣稱 SuperPlane 已替某個客戶修好登入系統。
當任務的範圍與驗收條件確定，下一步才是讓代理在一致的環境裡實作。
團隊共用環境，如何接住代理的第一版修改？
共用設定讓不同成員的任務沿用同一套工具、技能與工作標準，每項任務再取得自己的執行環境。團隊不用讓每一位工程師都重建一套個人流程。
1.0 官方公告把這個設計稱為軟體工廠：需求進來後，由既有程式代理實作，再把結果交給測試與審查。
這裡的代理負責寫程式、查看專案與修正變更。SuperPlane 負責安排任務如何流轉。兩者分工不同，因此更換模型不會自動替團隊解決驗收規則不清楚的問題。
個別任務有自己的雲端開發環境，避免多項工作直接在同一份工作目錄互相覆蓋。團隊也能平行處理不同任務，讓等待測試的時間和其他工作重疊。
共用的是標準，不是混在一起的工作目錄
例如專案需要特定測試工具與啟動方式，這些條件適合放進共用配置。某項任務產生的檔案、變更與執行紀錄，則要能對回該次工作。
官方也保留選擇模型、代理與基礎設施的空間。這表示工廠不只綁定單一模型，但不是所有外部服務、帳號與權限都已替每個新工作區連接完成。
因此，接入前仍要確認專案取回方式、執行工具和需要的憑證。共用設定的價值，是把已確認的條件一致交給各項任務，而不是讓代理臨場猜測公司的做法。
第一版變更交回後，系統仍要分辨代理有沒有完成，和結果是否真正通過驗證。
延伸閱讀：Factory Delegations 正式開放：從 Slack、Linear 派工作給 Droid，權限與審查怎麼設？
CI 與審查失敗，如何回到可修正的步驟？
驗證階段把專案測試、任務行為與審查條件組成證據，再將失敗原因交回能處理的階段。持續整合，也就是 CI，負責在變更過程中自動跑專案指定的檢查。
但測試命令成功，還不一定涵蓋這次要求。若任務是修改一段介面流程，既有測試沒有碰到該情境，就需要另有對應行為的證據。
Verify 文件因此區分專案檢查與任務特定檢查，也納入 PR 狀態、代理檢查與人工審查。PR 是集中呈現程式變更、讓團隊討論和合併的紀錄。
畫面截圖與錄影也可成為部分任務的證據，但不能因為拍到一個正常畫面，就推論所有操作都已通過。需要哪些證據，仍由工作本身決定。
工具沒跑起來，和程式做錯了，是兩種失敗
若測試服務暫時不能連線，這是執行過程出了問題。若環境正常而測試指出行為不符期待，則是結果沒有通過驗證。兩者應回到不同的處理方式。
後一種失敗需要把命令、錯誤內容與相關脈絡交回實作，讓代理知道應修哪裡。只丟一句「失敗了」，就容易迫使下一輪重猜整個問題。
修正循環也要有界線。官方設計讓反覆無法解決的工作進入需要關注的狀態，而不是無限制地呼叫模型、消耗資源直到碰巧得到綠燈。
修正循環要讓整個團隊看得懂，也必須保留每次運作、等待與人工決定的紀錄。
共用規則與看板，留下什麼管理資訊？
同一套準備與驗證標準，讓團隊能在看板上看到工作進度、失敗原因、花費與需要人決定的位置。它讓各項工作不只留在某位工程師的個人對話裡。
工作紀錄會連結多次執行、重試與交接，讓人能回頭看哪一輪產生變更、哪個檢查擋住進度，以及何時開始等待人工審查。
官方的主要流程從待辦進入實作，再到驗證。1.0 發布說明以 PR 合併後進入完成為預設描述，但實際驗證的退出條件仍能依工廠規則安排。
這個差別對主管有實際影響。準備好供審查、已核准合併，以及正式部署到使用者環境，是不同階段。看板上顯示完成，不能自行補成所有部署也已完成。
規則一致，才知道卡住的是哪一段
若兩個專案對完成的定義不同，單看完成任務數就不容易比較。某個專案可能等人工審查，另一個則已經合併，兩者的等待責任不相同。
看板可以把這些位置呈現出來，讓團隊判斷是代理需要更多脈絡、測試環境不穩，還是審查人力成為瓶頸。這比把所有延遲歸到模型速度更接近實際流程。
共用設定也應留得下變更背景。當團隊修改測試方式，後面的結果應按新規則閱讀，不能把前後不同條件的工作直接混成一個表現數字。
這些紀錄提供了計算自動化比例的基礎，但每個數字仍要先弄清楚分母。
52% 的 PR，能說明多少自動化價值？
52% 描述開發團隊自己上個月已合併 PR 的來源，不能直接換算成人力、品質或投資報酬。這是創辦人的內部經驗，沒有提供外部獨立對照。
其中的分母是已合併的 PR，而不是程式碼行數、工程師人數或所有待辦。即使兩項修改各算一個 PR，它們的難度與影響也可能差很多。
官方的解釋也包含多做原本沒時間處理的工作。因此，比例提高可能代表擴大處理範圍，而非把原本一半的人力成本移除。
吞吐量要和工作類型一起比較
工廠表現文件讓團隊查看一段期間的任務與效率資料。但關閉更多任務，仍要搭配任務是否有用、是否合併及完成規則來看。
我會把相近專案、相近難度和相同完成條件的工作放在一起，分開看實作時間、等待時間與每輪花費。這是判讀資料的方法，不是替官方數字補上一項未公布的實驗。
例如大量簡單維護工作增加，可能拉高完成量，卻不表示複雜產品功能同樣加速。反過來，較長任務若減少人工交接，也可能帶來完成數看不出的改善。
這些紀錄更適合找流程瓶頸，而不是直接替個別員工排名。代理、測試與人工審查共同影響結果，不能把一個看板數字全歸到某一個人。
要把這個經驗拿來比較自己的工作，還需要把部署選擇與模型、執行環境的成本算進去。
自架與雲端方案，該先確認哪一項成本？
公開引擎提供調整與自架的選擇，雲端服務則另有組織、席次與用量費用。Apache 2.0 授權提供的是程式碼使用條件，並不讓主機與模型運算免費。
依 10 月 27 日查閱的官方價格頁，隨用隨付方案沒有月費，另收用量費，提供十個席次及五項平行工作，並要求綁定付款卡。
Starter 每組織每月二十美元，另加用量，同樣十個席次但平行工作不設該項上限。Team 每使用者每月五十美元，另加用量，提供最多五十席的團隊配置。
模型費和執行環境費要分開算
各方案都可連接 Codex 訂閱。自行帶入 OpenAI、Anthropic 或 OpenRouter API 金鑰，也就是程式呼叫服務的存取憑證，則列在 Team 與 Enterprise。不能把兩種連接方式當成所有方案都有的同一功能。
使用平台提供的模型額度，按供應商一般價格另加百分之十。連接 Codex 或自備金鑰沒有該項模型加價，但上游費用與沙箱運算仍需分開負擔。
預算控制也有方案範圍。群組、使用者、工作區與個別任務的預算限制列在 Team 與 Enterprise，不能只看到價格頁有這項能力就假設入門方案全部包含。
平行工作不設該項數量上限，也不等於運算用量免費。若團隊讓更多工作同時進入實作，模型與沙箱仍會各自消耗資源，應把同時執行數和可接受的總花費分開設定。
例如十人團隊只需要五項工作同時前進，先觀察等待是否來自測試或人工審查，再決定是否增加平行量，會比只因方案支援就全面展開更有判斷依據。這是按流程成本提出的評估方式，並非官方公布的節省結果。
自架則要計入環境維護、連線與憑證管理。對已具備平台團隊的公司，公開引擎能增加調整空間。對想減少維運的團隊，雲端費用要和接手這些責任的成本一起比較。
SuperPlane 1.0 值得評估的，是把原本分散的交辦、修正與審查接成團隊能回看的流程。當團隊能把任務、證據與每輪成本接起來，才適合把這座工廠的範圍逐步擴大。
延伸閱讀：HumanLayer 核心開源：把 Claude Code、Codex 與團隊審查接在一起
常見問題
SuperPlane 1.0 是新的程式模型嗎？
不是。它圍繞既有代理安排需求、執行、驗證與回饋，模型與代理仍是流程中的工具。
52% 代表省下一半工程時間嗎？
不代表。官方說的是自家團隊上個月已合併 PR 中，透過平台自動化完成的比例，沒有直接測量節省的人力時間。
自架引擎和雲端方案費用相同嗎？
不同。公開引擎採 Apache 2.0，使用者仍負責自己的運算與維運。雲端另依方案、模型與沙箱用量計費。
