Logo
Published on

從 Theo 的 AI Agent 開發流程看現代軟體工程實踐

AI-AgentAI-Coding開發流程Cursor

最近看了 Theo 分享他如何使用 AI Agent 進行日常開發的影片，裡面提到許多實用的經驗和想法，讓我重新思考了自己目前的開發流程

Theo 的 AI Agent 工作流程

影片中 Theo 透過建立一個名為「Auto Draftify」的專案來示範他的開發流程。這個專案的目標很明確：比較不同 AI 模型在寫作任務上的表現

整個流程分為三個階段：

  1. AI 模型 A 撰寫初稿
  2. AI 模型 B 對初稿提供回饋
  3. AI 模型 A 根據回饋修改內容

所有的初稿、回饋和修訂稿都會以 Markdown 格式儲存，方便後續比較

專案初始化的細節

Theo 特別強調要手動初始化專案，例如使用 bun init，而不是讓 AI 自動處理。這樣可以確保對初始環境有完全的控制權

他使用了一個很有趣的技術：Git worktrees。這個功能可以讓你在不同的 Git 分支和獨立目錄中並行處理任務。簡單來說，就是可以同時讓多個 AI Agent 在不同的工作環境中執行相同的計畫，最後再比較它們的輸出結果

在 worktree 設置中，他配置了自動執行 bun install 並複製 .env 檔案的腳本，確保每個獨立工作環境都能正常運作

AI 輔助規劃階段

在 Cursor 的「Plan 模式」中，Theo 使用語音輸入工具（像是 WhisperFlow）向 AI 闡述專案需求

他主要使用 Opus 模型來做規劃，因為它在規劃任務上表現較好，不過他也提到，其實 GPT-5 也是不錯，所以它的示範是使用 GPT-5 而不是 Opus

這裡有個很重要的原則：務必閱讀並審查 AI 產生的計畫。不要盲目接受 AI 的建議，而是要主動檢查並提供反饋。例如在影片中，AI 錯誤地引入了 OpenAI 套件，Theo 立即指正並要求修改

AI 會詢問一些實作細節，比如專案應該以 CLI 腳本形式運作，還有模型 ID 是否要硬編碼等等。這些互動能讓 AI 更精確地理解你的需求

平行執行與結果比較

利用 Git worktrees 的功能，Theo 同時啟動了三個 AI Agent，分別使用 Composer、Opus 和 Gemini 模型執行相同的計畫。這種做法可以直接比較不同模型在相同任務上的表現

他觀察到 Composer 模型雖然不一定最聰明，但執行速度非常快。而 Opus 撰寫的論文品質顯著優於舊版模型，修改後的版本也更為流暢

在審查程式碼時，他發現 Composer 產生的程式碼格式更佳，儘管 Opus 的內容可能更優質。當 AI 產生的程式碼格式有問題時，他會直接要求 AI 修正，而不是自己手動調整

這裡他也有提到，是他自己想要測試不同模型的表現，所以才會同時啟動三個 AI Agent，並比較不同模型在相同任務上的表現，一般如果在開發上面是可以不需要學他一次啟用三個 AI Agent，而是根據需要選擇使用其中一個模型來完成任務就好

提升效率的關鍵策略

從 Theo 的實踐中，可以整理出幾個重要的策略

專注於規劃而非修復

當 AI 產生不理想的結果時，與其花時間修復程式碼，不如重新審視並改進原始的計畫或提示詞

這個觀點很有趣：AI 產生的程式碼成本低廉且快速，因此在必要時直接捨棄重來，反而能更有效率地達到目標。這也呼應了 Theo 在影片最後提到的想法：程式碼（開發分支）其實是不值錢的

建立緊密的回饋迴圈

提供 AI 自我驗證的機制非常重要

簡易測試或乾跑模式（Dry Run）：針對複雜專案，建立快速執行的迷你測試，讓 AI 能在短時間內驗證其變更是否有效

型別檢查：整合 bun run tsc 等命令，強制 AI 驗證程式碼的型別安全。這可以避免產生不符合規範的程式碼

明確指示：明確告知 AI 預期的輸出格式、行為和限制。不要讓 AI 猜測你想要什麼

提供充足的上下文與範例

AI 在大型專案中表現更佳，因為有更多現有程式碼可作為模式和範例

如果專案涉及特定複雜框架（如 effect-ts），可以將其原始碼作為子樹提供給 AI 參考。特別是測試檔案，它們包含了豐富的實作範例

在提示詞中直接提供少量程式碼範例，能大幅提升 AI 輸出的品質

選擇合適的 AI 模型

對於規劃這類需要深思熟慮的任務，可以使用更「聰明」的模型（儘管可能更慢、更貴）

對於執行任務，則可以選擇更「便宜、快速」的模型來實作計畫

這種搭配能夠有效控制成本。Theo 表示他每月花費約 $20 美元在 AI 服務上

這點到是讓我覺得不可思議，想不到他只使用 $20 美元的方案，不確定他是不是還有其它的服務

編輯器整合的重要性

Theo 偏好使用 Cursor 這樣具備深度 AI 整合功能的編輯器，因為它提供 LSP（Language Server Protocol）支援，能即時檢查型別錯誤

純 CLI 工具雖然也能完成任務，但在開發體驗上還是有差距

我的思考與實踐

看完影片後，我對比了一下自己目前的流程，發現大方向其實差不多

  • 給第一版本的需求
  • Review 相關的計畫
  • 請 Agent 開發
  • Review 程式碼

但影片最後一段提到的想法特別有趣：程式碼是不值錢的，可以隨時請 AI Agent 再開發一個版本，或是重新 review 第一個版本的 prompt 來重新產生程式碼

這個觀點改變了我對「重構」的看法。過去我們可能會花很多時間優化現有程式碼，但現在有了 AI Agent，有時候是不是直接重新產生可能更快更好 ?

關於測試

影片中示範的專案沒有特別寫 測試。不確定是不是這是 AI 相關的專案，所以才沒有產生測試，有點可惜，沒有辦法看到這方面的相關經驗

關於 SDD（Software Development Documentation）

影片中沒有特別提到 SDD。其實我自己平常開發也沒有在使用 SDD 相關套件

SDD 本來就只是有系統地幫你產生一些文件，或者是讓你少下一點 prompt 就可以產生一些有用的內容，例如測試文件之類的

如果原本就使用 Claude Code 的 subagent 或自定 command，那這些功能大多都已經處理過了，反而不需要額外的套件

真要說的話，或許輕量的 OpenSpec 還可以考慮使用，尤其是不使用 Claude Code 開發的情況下

溝通能力的提升

Theo 在影片中提到一個很有意思的觀點：與 AI 協作要求清晰、精準的指令和回饋，而這種訓練能顯著提升工程師與人類同事溝通的能力

這讓我想到，學習如何跟 AI 溝通，其實也是在學習如何更好地表達需求、如何提供有效的回饋。這些技能在團隊協作中同樣重要

一些原則性的提醒

雖然 AI Agent 很強大，但有些原則還是要遵守

切勿使用 AI 建立自己無法理解的程式碼：AI 是一種加速工具，而非取代理解力的工具。如果你看不懂 AI 產生的程式碼，那就不應該使用它

這不是給初學者的工具：Theo 在影片開頭就強調，這並非針對初學者的「憑感覺寫程式」教學。這是幫助現有的軟體工程師更有效率地使用 AI 工具，而非取代程式設計基礎知識

理解比速度更重要：雖然 AI 可以快速產生程式碼，但如果你無法理解和維護這些程式碼，長期來看反而會造成問題

結語

Theo 對目前透過 AI 進行程式開發的工作方式感到非常興奮。他認為 AI 讓開發人員能夠更快地探索新想法、建立一次性專案、撰寫測試和制定正式計畫

雖然 AI 並非萬能，尤其在處理文件不足或高度抽象的技術時仍有挑戰，但它大大降低了試錯成本，讓工程師敢於嘗試和迭代

我自己的感受也是如此。使用 AI Agent 後，開發變得更有趣了。你可以更專注在解決問題的邏輯和架構上，而不是被語法和重複性的工作綁住

如果你還沒開始探索自己的「AI Agent 工作流程」，不妨從小處開始嘗試。記住，這不僅是技術的革新，也是個人溝通與協作能力提升的機會

支持創作

如果這篇文章對您有幫助，歡迎透過 贊助連結 支持我持續創作優質內容。您的支持是我前進的動力！

圖片來源：AI 產生