這部影片由一位資深 Vibe Coder 分享他進入 2026 年的 AI 編程工作流程。內容涵蓋從需求規格撰寫、模型選擇策略、Planning Mode 的運用、Sub Agent 的正確用法，到如何以「觀察 diff 形狀」取代逐行審查程式碼。影片核心觀點是：開發者的角色已從寫程式碼轉變為設計反饋迴路、監控 Agent 行為並持續優化工作流。

---

原影片連結：https://www.youtube.com/watch?v=sy65ARFI9Bg

影片重點

• 用螢幕錄製 + Gemini 3 Pro 快速產出 PRD，再用 Claude Code 的 Ask User Question 工具迭代優化規格
• 用 ChatGPT 搜尋合適的 GitHub 套件，避免 Agent 從頭造輪子
• 開發者的核心角色是「設計反饋迴路」：監控 Agent、改善 CLAUDE.md 和 Prompt
• 模型選擇策略：Opus 4.5（主力 70-80%）、Sonnet 4.5（小修改/Review）、GPT 5.2（架構/除錯）、Gemini 3 Pro（設計）、Haiku 4.5（快速問答）
• Planning Mode 幾乎每個 Session 都使用，是最大的效率解鎖點之一
• 使用語音輸入（HyperWhisper）口述所有 Prompt，幾乎不再手動打字
• Sub Agent 最佳用法是「研究與思考」而非「並行編輯」
• 用 diff 的「形狀」快速判斷程式碼品質，不再逐行審查
• 多個 CLI 工具並行處理不同專案，但同一專案不建議多 Agent 並行
• Fork Session 功能用來深入理解 Agent 的決策邏輯

詳細內容

[00:00] 開場與影片目標

作者開門見山表示，這部影片將展示他進入 2026 年的 AI Agent 編程工作流程，希望觀眾能從中學到一些技巧應用到自己的工作流中。他也鼓勵觀眾如果有不同的工作流程，歡迎留言分享，因為他本人也在不斷改進自己的流程。

[00:30] 從螢幕錄製到 PRD：快速產出需求規格

作者分享了一個節省大量時間的技巧：當你有新產品或功能的想法時，很可能類似的功能已經存在於其他網站上。你可以直接到那個網站進行螢幕錄製，一邊錄一邊口述你的想法、功能需求，甚至用繪圖工具在畫面上標記。

然後將這段錄製上傳到 Google AI Studio 的 Gemini 3 Pro，讓它根據影片內容生成一份初步的 PRD（產品需求文件）。拿到初步 PRD 後，再轉到 Claude Code 中使用 Ask User Question 工具進行深度迭代——Claude Code 會向你提出一系列細節問題，例如格式工具列的位置、Emoji 鍵盤的實現方式等，通過問答不斷完善規格。

[02:30] 用 ChatGPT 搜尋合適的套件，避免 Agent 從零開始

作者指出，目前 AI 編程 Agent 常見的一個問題是：它們傾向於從頭實作所有功能，而非使用現有的成熟套件。例如，Agent 可能自己寫一個所見即所得（WYSIWYG）編輯器，而非使用現有的程式庫。更重要的是，有些只有幾千顆 GitHub 星星的優質套件，Agent 根本不知道它們的存在。

解決方法是：把規格交給 ChatGPT，開啟深度思考模式（Heavy Thinking），讓它搜尋網路上維護良好、社群活躍、與你的技術堆疊相容的套件。當有多個選項時，讓它列出各自的優缺點。這樣產出的規格會引用成熟的程式庫，大幅加速開發並提升可靠性。

[04:15] 分階段開發與開發者的角色定位

作者會讓 Claude Code 將規格拆解為多個階段（Phase），逐步完成並在每個階段之間進行測試和調整。他以自己的應用程式 HyperWhisper 為例，說明整個應用幾乎沒有手動寫任何程式碼——數萬行程式碼中，他可能只親手寫了兩三行。

那麼開發者的角色是什麼？作者認為，你的角色是設計「反饋迴路」（Feedback Loop）：讓 Agent 能有效地構建、失敗、從錯誤中學習，然後改進內部文件和 Prompt。具體來說就是維護 CLAUDE.md 文件、Skills、Slash Commands 等，以及監控 Agent 的推理過程，發現它經常犯的錯誤並加以修正。

[06:30] 模型選擇策略

作者詳細說明了他在不同場景下使用的模型：

Opus 4.5（70-80% 使用率）：主力模型，最擅長大規模功能開發、多檔案重構和撰寫乾淨專注的程式碼。幾乎每個 Session 都以它為主。

Sonnet 4.5：用於小修復、UI 微調、Code Review 以及撰寫 Changelog 和版本摘要。

GPT 5.2（透過 Codex CLI）：用於架構規劃和疑難除錯。作者發現 Opus 4.5 有時在專案初期選擇的架構不夠理想，所以大型專案會先把規格交給 GPT 5.2 規劃架構。當 Opus 4.5 在某個問題上打轉時，也會切換到 GPT 5.2 嘗試，因為不同模型的訓練資料和偏好不同，可能找到不同的解法。

Gemini 3 Pro：設計和創意相關任務，例如 UI 設計。

Haiku 4.5：快速回答問題、解釋程式碼、對已知位置進行精準小編輯。

[09:00] Claude Code vs Codex CLI 的使用節奏

自從 Opus 4.5 發布後，作者的使用比例從 50/50 變成了 80% Claude Code、20% Codex CLI。兩者的使用節奏有明顯差異：

Codex CLI 的特點是會花大量時間（10-15 分鐘）先讀取整個 Codebase，建立全面的心智模型後才動手修改，因此更適合需要深度理解的背景任務，例如分析 Sentry 錯誤、大型重構等。

Claude Code 則啟動更快、更互動式，會主動問你問題、允許你隨時打斷和調整方向。它的節奏更像是短迴圈的快速迭代。

但 Opus 4.5 也因為啟動太快而可能跳過某些關鍵上下文，導致修復不夠全面。Codex CLI 在處理那些根植於架構層面的根本性錯誤時，表現通常更好。

[11:30] 多 CLI 並行工作的實踐

作者同時運行多個 CLI 工具處理不同專案——例如兩個 Claude Code Session 加兩個 Codex CLI Session。他嘗試過用 Git Worktree 在同一個專案中並行開發多個功能，但發現合併時非常痛苦。

他通常有一兩個主要專案，加上一些衛星專案（小型工具或自用的微應用）。實務上他最多同時管理四個 Session，再多就會因為上下文切換而感到疲憊。他對於網路上有人聲稱同時運行十個 Session 表示懷疑，認為除非大部分都是無聊的背景任務。

[13:00] 語音輸入：用口述取代打字

作者現在幾乎所有 Prompt 都透過語音口述輸入，使用自己開發的工具 HyperWhisper，搭配離線模型 Parakeet v2。口述兩分鐘以上的內容，通常在兩秒內就能轉寫完成。這大幅改變了他與 AI 工具互動的方式。

[13:45] Planning Mode：最大的效率解鎖

作者在幾乎每個 Session 的開頭或需要較大功能變更時，都會啟用 Planning Mode。不使用 Planning Mode 的問題是「架構漂移」——不同次的 Prompt 可能產生不一致的實作模式，導致 Codebase 中出現多種 API 風格、認證方式等，讓後續的 Agent 更加困惑。

Planning Mode 的運作方式是：Claude Code 會先啟動多個 Explore Sub Agent 搜索 Codebase 中已建立的模式，然後將這些資訊傳給 Planning Sub Agent，基於既有模式來規劃新功能。這比過去 RAG 索引的方式效果更好——Agentic Search（透過 Agent 主動搜索 Codebase）能找到比傳統 RAG 策略更準確的上下文。

對於任何會改動超過 10-15 行程式碼的任務，作者幾乎都使用 Planning Mode。雖然可能花更多時間，但結果更準確，而且等待時他可以切換到其他 Session。

[16:00] 用 Diff 形狀取代逐行審查

2025 年初，作者還會逐行檢查 Agent 寫的每一行程式碼。現在他只用 Cursor 快速看一下改動了哪些檔案、改了多少行——如果 diff 的「形狀」符合預期（改動了預期的檔案、行數合理），就直接 Commit。

他發現：當 Plan 是好的，且形狀正確時，程式碼幾乎總是正確的。但如果形狀看起來不對——例如改了意料之外的檔案、改動行數過多——才會深入檢查。使用型別安全的工具（如 tRPC、Prisma）讓他對形狀判斷更有信心。

在 Session 結束時，他會讓 Agent 將學到的教訓更新到 CLAUDE.md 文件中，建立層級式的 CLAUDE.md 結構來管理不同子目錄的規範。

[18:30] Sub Agent 的正確用法：研究優先，謹慎編輯

作者回顧了 Sub Agent 的演進。最初很多人（包括他自己）嘗試給 Sub Agent 分配不同角色（前端、後端等）並行編輯同一個專案，但效果很差——Sub Agent 之間存在協調問題、需求理解偏差、輸出合併困難等。

他現在的最佳實踐是將 Sub Agent 用於上下文控制，而非並行編輯：

• 研究型 Sub Agent：啟動多個不同模型的 Sub Agent（Opus、Haiku、Sonnet），配合 MCP 搜尋工具，從不同角度分析問題、查找文件，將提煉後的資訊回傳給主 Session 進行實作。
• 跨專案小修復：當發現一個 Bug 存在於多個衍生專案時，為每個專案啟動一個 Sub Agent 進行相同的小修復——因為它們不在同一個專案中，不會有合併問題。
• 批量小編輯：例如 i18n 翻譯提取——當需要將整個 Codebase 的硬編碼字串提取到翻譯文件時，可以並行化這些小規模、定義明確的編輯。

核心原則：避免多個 Sub Agent 在同一專案中進行大規模編輯。

[22:00] Fork Session：深入理解 Agent 的決策

作者會使用 claude --continue --fork-session 來複製當前的 Session，在分叉的 Session 中詢問 Agent 為什麼做出某個決策、用 Mermaid 畫架構圖、搜尋線上資料等。這樣主 Session 可以不受干擾地繼續工作，學習和探索在另一個 Session 中進行。在分叉的 Session 中，他會切換到較低成本的模型（如 Sonnet）來提問。

我的想法

這部影片最有價值的觀點不在於具體的工具使用，而在於「開發者角色重新定義」的思維轉變。作者把自己定位為「反饋迴路設計師」——不寫程式碼，但設計讓 Agent 能自我改進的系統。這和傳統軟體工程的「寫程式碼」心態有根本性差異。

模型選擇策略也很實用。不是選一個最好的模型然後一直用，而是根據任務性質在不同模型間切換——這某種程度上像是帶領一個團隊，每個成員有不同專長。特別是「當一個模型卡住時，換一個模型試試」這個做法，利用了不同模型的訓練偏好差異來突破困境。

「看 diff 形狀而非逐行審查」是一個大膽但合理的演進。前提是你有好的 Plan 和型別安全的工具鏈。這也意味著投資在前期規劃上的時間，會在審查階段大幅節省回來。

Sub Agent 的使用建議也值得注意——不要把 Sub Agent 當作「便宜的並行工程師」，而是當作「專注的研究助手」。這個認知轉變能避免很多人在嘗試 Sub Agent 時踩的坑。