Theo 重新設計 AI 編程工作流：別再盯程式碼了，高手玩的是對話¶

🎯 核心金句：「如果你花在看程式碼的時間，比看關於程式碼的對話還要多，那你其實已經落後了。」

TL;DR¶

Theo（T3 Stack / T3 Code 作者）在半年後推翻自己之前的 AI 編程教學，提出一套完全相反的哲學：停止對工具和程式碼的執念，回歸「對話 + 極致簡單」。模型越來越聰明，瓶頸已經從「會不會寫程式」轉移到「懂不懂你想要幹嘛」。

一、工作流全面解構¶

背景¶

Theo 是 T3 Stack 和 T3 Code 的作者，超級 AI 編程狂熱分子
半年前拍過「我是怎麼用 AI 寫程式的」教學，現在覺得超丟臉
最大體悟：不是挖到外星黑科技，而是完全相反的哲學

核心轉變¶

舊思維（半年前）              新思維（現在）
┌─────────────────────┐     ┌─────────────────────┐
│  追求最強工具鏈     │ ──► │  對話 + 極致簡單    │
│  研究 prompt 技巧   │ ──► │  對齊意圖（AGENTS.md）│
│  盯著程式碼 diff    │ ──► │  讀 AI 輸出的文字    │
│  多模型並行         │ ──► │  單一主力模型        │
│  複雜的 workflow    │ ──► │  兩句話 prompt       │
└─────────────────────┘     └─────────────────────┘

Theo 的心智演進¶

階段	心態	行為模式
初期	迷信工具	安裝各種外掛、研究最佳 prompt 模板
中期	發現瓶頸	模型變聰明了，但輸出總不對味
成熟	回歸本質	把時間花在 AGENTS.md 和對話品質上

💡 關鍵洞察：AI 編程的瓶頸已經從「模型能力」轉移到「人類能否清楚表達意圖」。

二、工具選擇：炫酷工具的誘惑與陷阱¶

Theo 的工具棧¶

┌──────────────────────────────────────────────┐
│              Theo 的工具棧                    │
│                                              │
│  ┌──────────────┐   ┌──────────────────┐    │
│  │  GPT 5.5     │   │  Codex 執行環境  │    │
│  │  (主力模型)   │   │  (AI 在本機跑)   │    │
│  └──────┬───────┘   └────────┬─────────┘    │
│         │                    │              │
│         ▼                    ▼              │
│  ┌──────────────────────────────────┐       │
│  │  桌面 App（遠端開發）             │       │
│  │  筆電合上 → AI 在雲端跑 → 自動同步│       │
│  └──────────────────────────────────┘       │
└──────────────────────────────────────────────┘

SSH 終端機 vs 桌面 App 對比¶

面向	SSH 終端機	桌面 App
連線穩定性	❌ 容易斷線	✅ 自動重連
快捷鍵	❌ 需額外配置	✅ 原生支持
貼圖/附件	❌ 超麻煩（一半 prompt 要附圖）	✅ 原生拖放
多工追蹤	❌ 終端切換負擔大	✅ 視覺化管理
遠端體驗	❌ 筆電合上就斷	✅ 後台持續運行

⚠️ 現實濾鏡（必讀）¶

Theo 的特權	一般開發者的現實
10 倍 API 額度（近乎無限 Token）	需要精打細算用量
一人專案（可跳過 PR）	團隊協作需要 Code Review
T3 Code 作者（Claude Code 競爭對手）	無利益衝突，客觀評估
大量前置投資 AGENTS.md	需要花時間建立設定檔

🏷️ 最佳實踐：不要盲目抄襲 Theo 的工具選擇。他評價競品 Claude Code 時存在利益衝突——他自己是 T3 Code 的作者。選工具時優先考慮你自己的使用場景。

三、怎麼寫信給你的 AI 模型（含金量最高）¶

3.1 第一招：認真讀 AI 講的「廢話」¶

大多數人只盯著 AI 輸出的程式碼區塊，完全忽略前面的文字說明。Theo 認為這是大錯誤。

AI 輸出結構：
┌──────────────────────────────────────────┐
│  ████ 文字說明（大多數人跳過）████        │  ← 這裡藏著 AI 對你意圖的理解程度
│  - 為什麼這樣改？                          │
│  - 做了哪些假設？                          │
│  - 有什麼需要注意的？                      │
├──────────────────────────────────────────┤
│  ```typescript                            │  ← 大多數人只看這裡
│  // generated code                        │
│  ```                                      │
└──────────────────────────────────────────┘

為什麼要讀文字？ - AI 太囉嗦 → 糾正它（建立風格契約） - AI 排版痛苦 → 調教它（提升後續可讀性） - 不掌控對話風格 → 失去專案脈絡控制權

3.2 第二招：AGENTS.md 情書寫法¶

把 AGENTS.md 當成「給 AI 的情書」而非冷冰冰的技術規格書。

傳統技術規格書 vs 情書式 AGENTS.md：

<!-- ❌ 傳統寫法：冷冰冰的規格書 -->
# 專案規格
- 框架：Next.js 14
- 資料庫：PostgreSQL
- 禁止使用 var
- 遵循 ESLint Airbnb 配置

<!-- ✅ 情書式寫法：對齊意圖 -->
# 我們在做什麼
我們正在建一個讓開發者能快速原型化想法的工具。
這個專案誕生於我對現有工具鏈的挫敗感——
每次想試一個想法，都要花 30 分鐘配置環境。

## 核心執念
- Boil the Ocean：大膽到瘋狂的方案也 OK
- Fight for the "Obvious"：不耍聰明，追求 obvious
- Don't Be Afraid to Lie：工具可以模擬，
  但合約不能騙——持久性、隔離性、安全性必須真實

3.3 Theo 的 AGENTS.md 哲學框架（Lakebed 專案）¶

原則	含義	實際應用
Boil the Ocean	大膽到瘋狂的方案也 OK	鼓勵 AI 提出激進的架構建議
Let Their Agents Build What They Need	建 Primitives 不是 Features	提供基礎元件，讓使用者的 Agent 自行組合
Fight for the "Obvious"	不耍聰明，追求 obvious	拒絕過度設計，選擇最直覺的方案
Don't Be Afraid to Lie	工具可模擬，合約不能騙	持久性、隔離性、安全性必須真實實現

3.4 5 種 AGENTS.md 模式（來自 dev.to 參考文章）¶

AGENTS.md 模式選擇決策樹：

你的專案需要什麼？
│
├─► 明確的架構層級？
│   └─► Context Pyramid（金字塔模式）
│       架構 → 慣例 → 禁止事項，逐層收斂
│
├─► 不同檔案區域有不同的規則？
│   └─► Task Router（任務路由）
│       按目錄/檔案類型分派上下文
│
├─► AI 一直重新建議你已拒絕的方案？
│   └─► Decision Log（決策日誌）
│       用 ADR 記錄架構決策，防止死灰復燃
│
├─► 需要控制 AI 的操作危險等級？
│   └─► Safety Net（安全網）
│       允許 / 需確認 / 禁止 三級分類
│
└─► 專案持續迭代，上下文不斷變化？
    └─► Living Docs（活文件）
        定期更新，加入 Sprint 上下文

🏷️ 最佳實踐：手寫 AGENTS.md，不要用自動生成。感性地告訴 AI 你在腦袋裡想什麼、為什麼非做這個專案。對齊意圖後，AI 會變成超級懂你心意的高階隊友。

四、極致簡單原則¶

Theo 的日常操作模式¶

傳統 AI 編程工作流（複雜）：
┌──────────────────────────────────────┐
│  1. 打開 10 個平行對話              │
│  2. 寫 200 字超詳細 prompt          │
│  3. 指定要改哪個檔案的第幾行        │
│  4. 複製程式碼區塊，手動貼上        │
│  5. 對照 diff，逐行檢查             │
│  6. 切換視窗，跑測試                │
└──────────────────────────────────────┘

Theo 的工作流（極致簡單）：
┌──────────────────────────────────────┐
│  1. 開一條新對話（一個任務一條）     │
│  2. 說兩句話（語音轉文字）          │
│  3. 結束。不指定檔案，不貼程式碼    │
└──────────────────────────────────────┘

Prompt 長度對比¶

風格	Prompt 範例	效果
❌ 過度指導	「請在 src/components/UserProfile.tsx 的第 45 行附近，找到 handleAvatarUpload 函式，將裡面的 fetch 改為 axios，記得加上 error handling 和 loading state」	AI 可能改錯位置，你指的檔案可能是錯的
✅ 極致簡單	「用戶上傳頭像要能預覽」	AI 自己找到正確的檔案和函式

除錯心智模型迴圈¶

              AI 聽不懂你的需求？
                     │
           ┌─────────┴─────────┐
           │                   │
     ❌ 本能反應          ✅ 正確做法
           │                   │
    寫 200 字超複雜       回頭改 AGENTS.md
    的 super prompt       （從源頭補盲點）
           │                   │
           ▼                   ▼
    ┌────────────┐     ┌────────────────┐
    │ AI 更困惑  │     │ 回到乾淨新對話  │
    │ 越寫越長   │     │ 繼續用兩句話    │
    │ 惡性迴圈   │     │ prompt          │
    └────────────┘     │                │
                       │ 良性迴圈 ✨    │
                       └────────────────┘

核心原則清單¶

🏷️ 最佳實踐清單 - ✅ 一個任務 = 一條乾淨的新對話 - ✅ Prompt 不超過兩句話 - ✅ 用語音轉文字輸入，保持自然口語感 - ✅ 絕不告訴 AI 要改哪個檔案（人類自己常指錯） - ✅ 把 AI 當聰明的高階工程師，只丟目標 - ✅ 在 AGENTS.md 放微型詞彙表：「你就是 AI，我們就是開發者」 - ❌ 不要同時跑十幾個平行任務 - ❌ 不要在 prompt 裡指定檔案路徑 - ❌ 不要寫超長的 step-by-step prompt

五、什麼該抄什麼該打折¶

現實數據¶

Theo 的專案有 414 個未合併的 PR —— AI 讓寫程式太容易，Code Review 大塞車。

該抄 vs 該打折¶

┌─────────────────────────────────────────────────┐
│              ✅ 絕對該抄                         │
├─────────────────────────────────────────────────┤
│  • AGENTS.md 情書寫法（手寫、感性、對齊意圖）    │
│  • 極短 prompt 策略（兩句話搞定）                │
│  • 認真讀 AI 輸出的文字（不只看程式碼）          │
│  • 給模型自我驗證工具（讓 AI 自己跑測試）        │
│  • 除錯改 AGENTS.md 而非寫更長的 prompt          │
└─────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────┐
│              ⚠️ 必須打折                         │
├─────────────────────────────────────────────────┤
│  • 略過 Code Review（僅適用一人專案）             │
│  • 無限燒 Token（Theo 有特權 API 額度）          │
│  • 對競品的嚴苛評價（T3 Code vs Claude Code）    │
│  • 完全放棄 Claude（可能不適用你的場景）          │
│  • 桌面 App 遠端開發（需視你的基礎設施而定）      │
└─────────────────────────────────────────────────┘

DHH 的背書¶

DHH（Ruby on Rails 創始人）也盛讚 GPT-5.5：

"I've had more 'I can't believe it's this good' moments with GPT5.5 than any other model since Opus 4.5. All steering, no handwriting."

「All steering, no handwriting」——完美總結了 Theo 的哲學：你在方向盤上，AI 在寫程式碼。

個人反思與行動項¶

核心收穫¶

從「指令者」到「對話者」：AI 編程不是下指令，而是一場持續的對話。品質取決於你如何引導，而非你如何命令。
AGENTS.md 是投資，不是負擔：花 2 個月打磨 AGENTS.md，換來的是後續每次對話的高效率。
簡單是最難的：兩句話 prompt 背後是對 AGENTS.md 的深度投資和對專案的全盤理解。

行動項¶

檢視目前的 AGENTS.md / system prompt，是否更像規格書還是情書？
嘗試用兩句話 prompt 完成一個任務，觀察效果
開始閱讀 AI 輸出的文字部分（不只是程式碼區塊）
建立 Decision Log，記錄已拒絕的方案，防止 AI 死灰復燃

附錄¶

A. AGENTS.md 模板範例（Context Pyramid 模式）¶

# 專案意圖
一 句話描述這個專案為什麼存在、解決什麼問題。

## 架構概覽
- 技術棧：[列出]
- 目錄結構邏輯：[簡述]

## 編碼慣例
- 命名規則：camelCase
- 程式碼風格：簡潔、可讀優先
- 測試策略：[簡述]

## 絕對禁止
- 不要使用 [列出]
- 不要引入 [列出]
- 不要修改 [列出]（除非明確要求）

B. 語彙表範例¶

## 詞彙表
- "AI" = 你，即協助寫程式的 AI 模型
- "開發者" = 我們，專案的所有者
- "Lakebed" = 這個專案的名稱
- "primitives" = 基礎可組合元件，不是完整功能