大多數關於自主軟體開發的討論，都始於 Agent 撰寫程式碼。Agent 接手一個問題、實作功能、發起 Pull Request。示範成功，眾人興奮。
但在任何自主交付能可靠運作之前，必須有人先設計該自主系統將在其中運作的工程體系。專案結構、技術選擇、架構邊界、設計方向、工程慣例、驗證機制、專業角色、核准邊界。這些都不該由一群各自猜測的獨立 Agent 來產生。
我的做法從不同的責任劃分開始。人類設計工程體系。專業化的 Agent 執行工作。非同步循環協調何時執行工作以及下一步該做什麼。
目標不是將人類從軟體開發中移除，而是將人類的參與集中在需要判斷力、背景知識與產品理解的決策上，同時建立一個能讓更多執行工作自主進行的環境。
以下是我每次啟動一個最終希望能在無人監看下運行的專案時，所遵循的六個步驟。
第一步：人類設計工程體系
當我開始一個專案時，我不會要求自主 Agent 去發明它的基礎。
我先決定重要的部分：儲存庫該如何組織、使用哪些技術、主要架構邊界如何運作、設計方向是什麼、必須遵循哪些工程慣例，以及自主權應在哪裡停止。這些決策成為後續一切的基礎。
接著我用 opencode-onboard 將它們編碼到儲存庫中。
/make-engineer 建立專案所需的專業化 AI 工程師。前端、後端、基礎設施、測試、安全、資料、行動裝置，無論產品需要什麼。這些並非只是貼上不同標籤的通用 Agent。每個都有明確的專長、一組能力，以及在工程流程中的清晰位置。
/make-architecture 將技術結構與邊界擷取到 ARCHITECTURE.md 中。/make-design 將視覺語言、設計 Token 與元件模式擷取到 DESIGN.md 中。/make-guardrails 將所有這些決策轉換成每個 Agent 都必須遵守的具體規則。架構邊界、命名慣例、測試期望、程式碼風格、安全限制、Git 實務。它們不再是僅由原始開發者掌握的知識，而是成為運作環境的一部分。
儲存庫最終包含的不只是文件。它包含了一個編碼後的工程組織，以及一個供在其中工作的每個 Agent 使用的共享真相來源。
人類先定義系統。只有這樣，自主執行才會變得有用。
第二步：互動基礎先於自主
一旦工程體系定義完成，我便以互動方式建立初始的專案基礎。
此時我通常使用 /plan-quick 和 /plan-apply。/plan-quick 分析一個明確的目標，並將其轉化為具體、有序的任務序列。它刻意比完整的規格流程更輕量。當工作明確且我想快速推進、同時不失去能見度與控制時，我就會使用它。/plan-apply 則實作這些任務並驗證結果。
這就是我建立專案基本基礎的方式。儲存庫結構、應用程式骨架、資料庫設定、驗證基礎、設計系統、測試基礎設施、CI/CD 配置、部署基礎。
專案早期階段所做的決策會影響後續建立的一切。一個薄弱的抽象、不一致的資料夾結構、不明確的測試策略——任何一項都可能在自主 Agent 開始工作後被重複數百次。我見過這種情況，並不美好。
因此，這個階段保持快速且由 AI 輔助，但仍然在監督下進行。
目的不是要儘早最大化自主性，而是讓專案足夠穩定、可理解且可預測，以便自主性之後能安全地在其中運作。
第三步：人類參與成為專案策略
基礎就緒後，我決定交付系統應擁有多少自主權。
這並非在人工開發與完全自動化之間做二元選擇。人類參與可以在生命週期的不同節點存在，而適當的配置取決於專案。
一個完全監督的專案可能需要人類來完善問題、核准實作計畫、審查 Pull Request、核准合併、以及授權部署。
一個部分自主的專案可能讓 AI 完善並實作，而人類則回答未解決的問題、審查重要的 Pull Request，或保留對最終合併的控制權。
一個高度自主的專案可能讓系統在所需的護欄、測試與品質檢查通過時，自動完善、實作、審查並合併變更。
一個需求不穩定的新產品，需要比成熟的內部工具更多的人類參與。一個受監管的系統需要明確的核准關卡，而這對小型實驗來說則是不必要的。而且同一個專案隨著其架構、測試與交付機制的成熟，可以隨著時間變得更加自主。
重點在於，自主性是被刻意定義的。問題完善、問題解答、計畫核准、Pull Request 審查、合併核准、部署核准——這些並非意外的中斷，而是工程系統中可配置的關卡。
每個專案都選擇不同層級的自主性，而這些邊界會隨著專案演進。
第四步：想法變成持久的待辦項目
互動式控制台仍然是我探索想法的地方。
當想法還不完整時，我使用 /plan-explore。這不是一個實作命令，而是一個協作探索過程。Agent 會檢查儲存庫、映射相關元件、辨識現有模式、挑戰假設、追蹤依賴、考慮風險，並協助決定實際上該建立什麼。
許多開發問題最初看起來像編碼任務，但實際上是理解問題。將一個不明確的想法直接送入自主實作流程，通常會產生一個不明確的實作。探索能給想法足夠的結構，使其變得可行，而不會過早地承諾一個解決方案。
一旦方向明確，我就使用 /ops-backlog 在 GitHub、Azure DevOps 或 Jira 中建立一個結構化的工作項目。這個工作項目成為互動式思考與非同步執行之間的持久交接點。它可以包含後續工作階段所需的背景、範圍、驗收標準、風險、未解決問題與依賴關係。
此時，待辦事項不再只是儲存任務的地方。它變成了人類、Agent 與循環之間的共享協調層。
人類建立想法、回答問題、做出決策。循環觀察問題狀態並選出可處理的工作。Agent 接收專注的任務以及執行所需的背景資訊。
待辦事項將互動式對話轉化為在對話結束後仍能持續進行的持久工作。
第五步：loop-task 協調非同步工作
當專案、工程師、護欄、待辦事項與核准策略都準備就緒後，我在本地機器或 VM 中配置 loop-task。
loop-task 執行外部協調循環。這些循環持續檢查待辦事項、辨識可處理的工作、調用適當的工程流程，並更新每個問題的狀態。
一個完善循環可以選取一個新問題、調查它、改進其規格，並在資訊缺失時加入問題。當需要人類決策時，問題會進入等待狀態。有人在有空時回答，當資訊出現時循環恢復。
一旦問題足夠清晰，它就會進入待實作狀態。實作循環接手它，並調用自主工程流程。
一個審查循環可以檢查 Pull Request 的回饋、協調修正、重新執行必要的流程，並將變更推向接受。一個完成循環可以合併已接受的工作、關閉相關問題，並讓下一個可處理的項目進入系統。
循環之間不需要直接通訊。它們透過持久的待辦事項狀態來協調。一個典型的問題會經歷如下生命週期：
新增、完善中、等待答案、待實作、實作中、Pull Request、審查中、完成。
人類可以在專案策略要求時進入流程，但系統不需要有人持續監控終端機。即使開發者離線，VM 仍然會持續檢查待辦事項並推進可處理的工作。
這正是循環工程的核心區別：
Agent 執行工作。循環決定何時有工作、工作何時開始、由哪個流程執行，以及下一步該做什麼。
第六步：/plan-goal 端到端執行一個問題
當實作循環發現一個準備就緒的問題時，它會調用 /plan-goal。
這個命令不負責決定產品方向或發明專案架構——那些決策已經做出並編碼到儲存庫中。它的責任是在現有工程系統內執行一個經過充分完善的工作項目。
/plan-goal 讀取問題、探索程式碼庫的相關部分、建立 OpenSpec 提案、產生結構化任務、識別規格或測試缺口、選擇適當的專業工程師、分配模型層級、計算依賴關係，並將實作工作組織成平行執行波次。
獨立且修改儲存庫不同區域的任務可以同時分配給不同的工程師。依賴先前工作或觸及相同檔案的任務則按順序執行。
主導 Agent 協調工作、收集每個結果、建立聚焦的提交、執行測試、Linting、型別檢查與建置。當無法成功完成驗證時，它會停止而非送出變更。
當實作有效時，會推送分支並建立 Pull Request，附上必要的背景與證據。
接著，配置的專案策略決定下一步。人類可能審查 Pull Request。另一個 AI 系統可能執行審查。一個高度自主的專案可能在所有必要檢查通過時自動合併。在其他專案中，最終決定權仍明確保留給人類。
這揭示了系統中的兩個協調層。loop-task 是外部協調層：它管理待辦事項生命週期，並決定何時該進行完善、實作、審查或完成。/plan-goal 以及其他 opencode-onboard 命令構成內部工程流程：它們知道如何探索、規劃、分配、實作、驗證並交付一個特定的變更。
一個能超越對話的系統
基於提示詞的開發其中一個限制，是太多狀態存在於暫時的對話中。
架構必須一再解釋。先前的決策被遺忘。中斷的實作難以繼續。開發者必須在場，以便在每一步之後決定 Agent 該做什麼。
這個流程將狀態轉移到持久系統中。儲存庫包含架構、設計規則、工程師與護欄。OpenSpec 包含計畫中的變更及其任務。Git 包含實作歷史與復原點。待辦事項包含交付狀態與人類決策。本地機器或 VM 提供循環持續運行的持久環境。
結果不是一個試圖扮演整個軟體組織的單一自主 Agent，而是一個協調系統，其中不同元件有不同責任。
人類定義方向、限制與責任邊界。專業化的 Agent 執行聚焦的工程工作。循環非同步協調生命週期。待辦事項將它們連接起來。
最重要的改變不在於 Agent 能產生更多程式碼，而是從孤立的 AI 互動轉向持久的工程系統。
不再需要在每次任務前解釋儲存庫，專案本身攜帶自己的架構與護欄。不再要求通用 Agent 實作所有事情，工作分配給專家。不再手動決定每一步之後該做什麼，循環對持久的流程狀態做出反應。不再將整個流程保留在對話中，進度存在於問題、規格、提交、Pull Request 與本地狀態中。
人類的角色並未消失，而是轉向設計允許自主執行運作的環境。
這就是我目前正在建立的模型：一個人類設計的 AI SDLC，開發者首先建立工程環境與自主邊界，然後非同步循環透過待辦事項驅動的交付生命週期來協調專業化的 Agent。
從零開始，到循環自行運作。六個步驟，每一步都建立在前一步之上，每一步都將更多狀態從對話中移出，移到不會遺忘的系統中。
P.S. 你可以在 ckgrafico.com 找到 loop-task、opencode-onboard 以及其他工具。
