擴展 AI 工程：分析 Claude Code 中的動態工作流程

Claude Code 中引入動態工作流程標誌著 AI 如何融入軟體開發生命週期的重大轉變。與其將 LLM 視為單一任務提示的聊天介面，動態工作流程允許協調多個平行代理、分階段執行以及自動驗證迴圈。此方法旨在將 AI 從「copilot」角色轉向能夠處理大規模架構變更的自主「agentic」系統。

儘管技術能力令人印象深刻，但此版本的發布在工程師間引發了關於原始速度與正確性之間的權衡，以及「token burn」經濟成本的激烈辯論。

規模的力量：Bun 重寫

為了展示動態工作流程的潛力，Anthropic 凸顯了一個令人驚嘆的使用案例：將 Bun 執行時期從 Zig 移植到 Rust。根據團隊共享的詳細資訊，該過程達成了以下成果：

• Scale: 大約產生了 750,000 行 Rust 程式碼。
• Accuracy: 現有測試套件有 99.8% 通過。
• Velocity: 從第一次提交到合併的過程僅用了十一天。

這是透過多階段管線實現的：首先，工作流程為 Zig 程式碼基礎中的每個結構體欄位映射了 Rust 生命週期；其次，數百個代理平行工作，編寫行為相同的 .rs 檔案，每個檔案都有兩個專門的審查代理；最後，修復迴圈推動建置和測試套件，直至乾淨運行。另外，過夜工作流程被用來優化資料複製並開啟 PR 以進行最終人工審閱。

技術優勢：內容管理與平行性

對於使用 Early Access Program (EAP) 的開發者來說，動態工作流程的主要好處不僅是速度，而是 內容衛生。

一位使用者指出，較長的對話長度常會降低模型效能（他提到 Opus 4.7 在 200k token 之後會出現問題）。動態工作流程透過生成具有乾淨、專注內容視窗的子代理來緩解此問題。透過將龐大任務拆分為較小的平行區塊，系統確保每個代理在模型注意力機制的「甜點」範圍內運作，從而對較大的工作量產出更高品質的結果。

此外，Tool User Interface (TUI) 提供了對這些工作流程「in-flight」狀態的可見性，提供了一種常見於不透明 agentic 迴圈中缺失的透明度層級。

關鍵反點：「Vibe Coding」與工程

儘管 Bun 重寫取得成功，但開發者社群中許多人持懷疑態度。批評的核心在於「通過測試」與「可維護程式碼」之間的差異。

維護債務

一些批評者認為，生成一百萬行「vibe-coded」的 Rust 程式碼——這些程式碼雖能通過測試但並非由人類設計——會創造巨大的長期維護負擔。正如一位評論者所指出的，這可能導致團隊停止支援一個工具，因為他們無法再正確導航或理解 AI 生成的程式碼基礎。

控制落差

人們日益認為，AI 工程的瓶頸不再是程式碼生成的速度，而是意圖的精確度。

"我的限制因素不是 Claude 能多快自行遍歷程式碼。而是 Claude 是否會正確完成任務。我需要更多機制來控制長時間執行的會話，並動態注入我的想法、修正和建議。"

批評者指出，如果缺乏對生成的子代理的穩健 AskUserQuestion 實作，這些工作流程可能會在高速下朝錯誤方向執行，以 CI 可能無法立即偵測到的方式破壞不變量或損毀測試 harness。

Token Burn 的經濟學

也許最一致的抱怨是這些工作流程的巨額成本。該架構——平行代理檢查其他代理——本質上是耗費大量 token 的。

使用者報告說，他們在創紀錄的時間內達到 Claude Max 的上限，其中一位使用者表示，62 個 Opus 子代理僅用 18 分鐘就耗盡了五小時的上限。這導致人們懷疑動態工作流程的設計更側重於增加 token 消耗的機制，而非優化開發者生產力。

結論：邁向新的 SWE 範式

動態工作流程代表著朝向「管道式」軟體工程模型的收斂，在此模型中，開發者的角色更像是協調者和審查者，而非程式碼編寫者。雖然這為測試覆蓋率高的任務（如移植或遷移）帶來了前所未有的速度，但它也帶來了關於程式碼可讀性和成本的新風險。

對於現代工程師而言，挑戰現在在於決定何時保持「在迴圈中」以及何時信任自動化。隨著這些工具的演進，焦點很可能會從 AI 可以編寫多少程式碼 轉變為 人類能多有效地引導 agentic 群體。