我如何用 LLM 寫軟體：一套實用的多模型工作流 - Toolsify AI Blog

2026年3月10日，Stavros 發表了一篇可能是關於用大語言模型建構軟體最誠實、最實用的指南。不是炒作文章。不是「看 AI 在10分鐘內做出了什麼」的演示。而是一套經過多個已交付專案驗證的真實工作流，並清晰地指出了它的適用場景和失敗模式。

起點：做東西，而不是寫程式

Stavros 用一個區分重新定義了整個對話。他不把程式設計本身當作目的。他在乎的是做出東西來。LLM 改變了這個等式，讓程式設計感覺更接近直接建構——花更少的時間與語法搏鬥，花更多時間塑造軟體的實際功能。

他用這種方法建構和維護了多個專案：一個叫 Stavrobot 的個人助手、一個語音筆記錄製設備、一個藝術時鐘專案，以及一個叫 Pine Town 的小鎮模擬。

Stavros 工作流的核心是將關注點分離到三個模型角色中。每個角色使用不同的模型，根據具體任務選擇。

第一個模型扮演架構師角色。Stavros 在寫任何程式碼之前，會花最多30分鐘與這個模型對話。關鍵指令是：在我明確批准之前不要開始實作。這個約束至關重要。LLM 渴望生成程式碼。沒有硬性門檻，規劃對話會在設計確定之前就滑入實作階段。

規劃批准後，一個更便宜的模型負責實作。這個模型的自由度有限——它執行計劃，而不是重新設計。使用更便宜的模型有兩個目的：對高量級 token 生成來說更划算，同時約束實作模型降低了偏離既定架構的風險。

實作完成後，Stavros 讓程式碼通過多個審查模型。他明確提到了使用 Codex、Gemini 和 Opus 進行審查。多樣性很重要——不同的模型捕捉不同的問題。使用多個審查者創造重疊覆蓋。

Stavros 手寫 agent 指令，不讓 LLM 生成自己的技能檔案或配置。人類定義約束。模型在約束內執行。當你讓 LLM 寫自己的指令時，它優化的是它認為你想聽的東西，而不是真正有效的東西。

當 Stavros 已經理解他正在使用的技術堆疊時，多模型工作流效果最好。他能發現實作何時偏離了計劃。他能判斷審查者的建議是否真的是改進。

在不熟悉的領域，工作流效果差得多。錯誤決策會累積。程式碼庫堆積出人類直到為時已晚才認識到的技術債務。設計錯誤累積的問題比聽起來更嚴重。早期決策設定的模式會被後續程式碼遵循。

人類角色正從程式碼行級編碼轉向架構級監督。在這個環境中脫穎而出的開發者不是編碼最快的。而是能定義清晰約束、儘早識別薄弱抽象、並執行有紀律的多模型流程的人。

分離規劃與實作。為不同角色使用不同模型。多元化審查者。自己寫指令。保持在熟悉領域。警惕錯誤累積。