超越提示詞-回應迴圈：基於 LLM 的編碼新範式

AI 編碼中的「煞車」挑戰

傳統的 LLM 編碼工作流以重複的提示詞-回應迴圈為特徵，這經常會中斷開發者的心流狀態（flow state）。這種「停止-等待-審查-提示」的週期會產生認知摩擦，使開發者扮演手動編排者的角色，而非創作者，導致每隔幾分鐘就會有一種突然煞車的感覺。

為了消除對手動干預的持續需求，開發者正在構建「框架」（harnesses）——即 LLM 的封裝層，能夠自主處理代碼的簿記、執行與驗證。

某些開發者正在實作「工作箱」（workboxes），即在沙盒（例如使用 e2b）中為每個功能建立隔離的工作樹。這種方法允許開發者輸入一個提示詞，自動建立分支與 PR，並啟動一個編碼會話，最終產生一個用於手動測試的公開 HTTPS 端點。這將開發者的角色從逐行編碼轉向高層級的審核與迭代提示。

進階的設置涉及在具有獨立電子郵件與帳戶的 macOS VM 中運行 LLM。在這些配置中，任務透過 Linear 等專案管理工具分配；AI 實作任務並提交 PR 進行審查。這讓人類開發者能專注於故事撰寫與代碼審查，而非追隨 AI 的每一個動作。

越來越多人的共識是，AI 生成代碼的品質取決於規格（specification）的精確度，而非模型本身的能力。

開發者正在採用一種稱為「拷問」（grilling）或「尋路」（wayfinding）的流程，即在編寫任何代碼之前，利用 LLM 嚴格地挑戰規格以提取問題並消除意圖的歧義。一個理想的規格定義為具備：

新的工具正在湧現，將規格視為主要介面。一些開發者使用 Kanban 風格的 CLI 工具，工作發生在工單描述與生成的計畫中，接著由代理人實作。其他人則使用簡單的 tasks.md 檔案來分組實作步驟，以便為專案中互不干擾的部分啟動多個並行的聊天會話，以維持動能。

除了完全的自主性之外，開發者也在實驗不同的方式與 LLM 互動，以更好地符合人類的認知模式。

其中一種實驗性方法捨棄了完全的自主性，轉而採用配對編程夥伴模型。該系統利用獨別的「駕駛員」（driver）與「領航員」（navigator）模式，允許開發者在編寫代碼與指導 AI 之間快速切換，模擬傳統的人類配對編程動態。

一些開發者透過刻意限制 AI 的使用來維持其心流狀態。這包括使用空白編輯器進行初步實作以維持「編碼的樂趣」，並且僅在處理特定細節或卡住時才調用 LLM。其他人則結合使用自動補全工具（如 GitHub Copilot）進行低層級的協助，並搭配獨立的提示詞工具進行高層級的架構變更。

經驗豐富的使用者正在識別特定的技術槓桿來提升 LLM 在編碼方面的性能：

技能優於代理人： 有一種觀點認為「技能」（skills，即關於如何與專有系統或自定義程式進行介面的特定指令）比代理人更強大。雖然代理人可以保留上下文，但技能可以增加實際能力。
上下文管理： 一些開發者避免使用長期記憶或掛鉤（hooks），以防止「上下文腐敗」（context rot），而是傾向於建立 markdown 檔案作為記憶，讓模型可以僅在需要時進行 grep（漸進式揭露）。
約束環境： 目前正在進行「軌道內」（on-rails）開發的實驗，即限制 LLM 使用非常固定的函式庫、資料庫與架構（schemas），以確保輸出更具可控性且產出速度更快。