Theo（t3.gg）分享了他觀察到開發者在使用 AI 編程工具時最常犯的幾個錯誤。從選錯問題讓 AI 解決、塞入過多上下文導致輸出品質下降、使用過時工具卻以為 AI 沒用，到開發環境本身就有問題讓 AI 無所適從，以及過度配置 MCP 和外掛反而適得其反。這些錯誤一旦修正，AI 工具的效果會有顯著提升。

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

影片重點

• 不要只在「走投無路」時才使用 AI，應該先用它來解決你已知道答案的問題
• 不要把整個程式碼庫塞進上下文，模型知道越多反而越笨
• Claude MD / Agent MD 檔案是用來記錄「地雷」的，不是用來描述整個專案的
• 確保開發環境沒有問題（型別檢查、ESLint 設定等），否則 AI 會反覆追鬼
• 不要過度配置 MCP、Skills 和外掛，簡單才是王道
• 使用最新的工具，不要用兩年前的體驗來評判今天的 AI 能力
• Plan Mode 能有效防止錯誤累積，輸出不好就回頭修正計畫而不是繼續追加指令
• 建立你自己的「真實世界評測」：保存 AI 解不了的問題，每次新工具出來就測試

詳細內容

[00:00] 開場：為什麼你覺得 AI 不好用

Theo 指出，大多數開發者目前對 AI 的看法是：它在小專案和 side project 上蠻有用的，但碰到真正的大型程式碼庫就不太行了。他理解這種感受，因為他自己幾週前也是這樣想的。但事實是情況正在快速改變，而大多數人之所以體驗不佳，是因為犯了一系列可以修正的錯誤。

[02:13] 錯誤一：選錯問題讓 AI 解決

這是 Theo 認為最大的錯誤。大多數人的問題解決流程是：驗證問題 → 嘗試明顯的解法 → 深入調查 → 嘗試新方案。但多數人只在最後一步「走投無路」時才想到用 AI，這時候給模型的是一個自己都搞不清楚的難題。

正確的做法是先讓 AI 解決你「已經知道答案」的問題。這樣你可以比較 AI 的解法和你的解法，建立對工具能力的直覺。就像你把工作交給團隊裡的初階工程師一樣——你不會把自己都不懂的問題丟給他們，而是把你已經知道怎麼做的事交出去。

Theo 還建議了一個非常實用的方法：當你修復了一個 bug 之後，回到修復前的程式碼狀態，把你用來解決問題的所有資訊整理好，然後測試 AI 能不能也解決它。如果不能，你就得到了一個比任何 benchmark 都有價值的「真實世界測試案例」。每次新模型推出時都可以拿來測試，這種 eval 比官方 benchmark 有用得多。

[08:57] 錯誤二：上下文管理失當

Theo 痛批了 Repomix 這個工具——它會把整個程式碼庫壓成一個檔案塞給 AI。他直言這個工具「應該從網路上消失」，而且已經讓他的 T3 Chat 花了數十萬美元的額外成本。

核心概念是：AI 本質上就是自動補全（autocomplete）。當你給它「The capital of the US is」，它會預測下一個最可能的 token 是「Washington DC」。如果你塞入太多無關的上下文，模型找到正確答案的機率就會大幅下降。

他引用了「Context Rot」（上下文腐爛）的概念：模型在上下文 token 數增加後，準確率會快速下滑。例如 Sonnet 4 在一定 token 數內是 100% 成功率，但上下文過多後會降到 60% 以下。即使 Gemini 能處理 1-2 百萬 token，也不代表你應該塞滿它。模型知道越多，反而越笨。

正確的做法是讓工具（如 Claude Code、OpenCode、Cursor）自己用搜尋工具去找需要的程式碼，而不是一次性把所有東西塞進去。就像你解決問題時不會逐行讀完整個程式碼庫，而是用搜尋功能找到相關的地方。

[13:10] Claude MD 檔案的正確用法

Claude Code 團隊的做法是：每當發現模型在程式碼庫中犯錯，就立刻去修改 Claude MD 檔案來引導模型走正確的方向。Theo 自己也是這樣做的——他在 T3 Chat 的專案中發現模型老是執行 pnpm dev 開啟開發伺服器（但他自己已經開了），所以就在 Claude MD 中標註「除非被告知，否則不要執行這個指令」，問題立刻消失。

他強調 Claude MD 檔案的角色不是描述整個專案——它是一份「地雷清單」，記錄你看過模型犯的錯誤來避免重蹈覆轍。這個檔案應該從小而簡單開始，逐步新增微調。就像他在 Twitch 工作時的經驗：他因為內部文件寫得不清楚而犯了錯，資深工程師看到後不是教他怎麼做，而是去修正了那份文件，讓下一個人不會犯同樣的錯。AI 代理就是那個「每次都是新人」的工程師，你需要為它建立記憶。

[18:38] 錯誤三：使用過時的工具

如果你對 AI 編程的評價是基於早期用 Sonnet 3.5 在 Windsurf 上的體驗，那你跟現在的使用者完全不在同一個世界。Theo 用了一個類比：這就像拿記事本跟 Vim 比。

他坦言在軟體開發的歷史中，通常一個工具不好用就是不好用——幾年後再試也不會好到哪去。但 AI 工具是個例外：他親眼看到 6 個月前完全無法解決的問題，3 個月後就被解決了。這種從「不可能」到「輕鬆搞定」的速度，在軟體開發史上幾乎前所未見。

如果你公司的審批流程讓你只能用已過時的工具（例如花了一年半才批准 Copilot，結果大家都已經轉到 Cursor 和 Claude Code 了），Theo 建議：先道歉表示理解，然後建議你無視規定自己試，最後建議你考慮換一家更擁抱新技術的公司。他也點名批評 Amazon 強迫員工使用自家的 Kiro（VS Code fork）而不讓他們用更好的工具。

[23:10] 錯誤四：開發環境有問題

如果你的 monorepo 在根目錄打開時型別系統會壞掉，需要進入子套件才能讓 TS config 正常運作，那你的環境就是壞的。如果型別檢查需要 cd 切換目錄，環境就是壞的。

這個問題對 AI 的影響特別嚴重：AI 代理修好了問題，執行型別檢查，結果看到一個跟它的修改完全無關的錯誤，然後它就瘋了——嘗試各種方法修復那個錯誤，最後撤銷自己的修改，才發現那個錯誤原本就存在。下一次執行又會重複同樣的過程。用 Theo 的話說：「如果你告訴 AI 代理有鬼，它會永遠追著鬼跑。」

有趣的是，這些環境問題本身就可以用 AI 來修。Theo 在 Vibe Kanban 專案中遇到 ESLint 設定問題，直接點了 Cursor 的「一鍵修復」按鈕，AI 立刻找到了 tsconfig 路徑的問題並修好了。

[27:15] 錯誤五：MCP 和外掛過度配置

Theo 展示了他的 Claude Code 配置：MCP 伺服器數量為零。Cursor 也一樣。他只有一個 skill——一個告訴模型「不要做出 AI 美學風格的介面」的 Markdown 檔案。

他指出，如果你還在懷疑 AI 工具是否有用，但同時在折騰 MCP 配置，那你搞錯了方向。他批評了「Oh My OpenCode」這類過度配置專案，認為更多功能、更多 MCP、更多外掛不會讓一個「沒用」的東西變「有用」，只會讓體驗更差。

他用 Pieter Levels（知名獨立開發者，每天 500+ commits 的 vibe coding 高手）作為反面例子：Pieter 用的就是原裝的 Codex，配置檔只有幾行基本設定。Pieter 自己也寫了一篇文章叫「Just Talk to It」——最後你會發現，最好的用法就是簡單地說：「看看這些檔案，然後做這件事。」

[33:15] Plan Mode 與迭代的重要性

一個很常見的錯誤是：給了不好的指令，得到不好的輸出，然後不斷追加更多指令試圖修正。但記住，一切都是自動補全——如果歷史記錄中壞的資訊比好的多，輸出也會傾向於壞的方向。

正確的做法是：當輸出不好時，不要追加修正，而是回頭重來，把更好的指令放在開頭。Plan Mode 在這裡特別有用——它不會直接動手做事，而是先問你問題、釐清不確定的部分，然後輸出一個計畫。這樣你的上下文大部分都是有用的資訊，模型產出好結果的機率就會大幅提升。

如果計畫執行後結果還是不好，要反思原因：是計畫有問題？去修計畫。是對程式碼庫的理解有誤？去修 Claude MD 檔案。這個「判斷該在哪裡修正」的直覺會隨著使用經驗快速建立。

[37:35] 實際案例：Adam 的 Hydration Error

Theo 用他的頻道經理 Adam 的例子做總結。Adam 遇到了一個 hydration error，他已經定位到了可能的檔案（provider.tsx），但不知道具體原因。他把問題丟給 Opus 4.5，但沒有提供確切的錯誤訊息，結果 AI 的診斷完全錯誤。

原來 Adam 不知道 React 19 新增了 hydration error 的追蹤功能（trace），能直接顯示錯誤發生的位置。當 Theo 告訴他這個功能後，Adam 找到了確切的錯誤訊息，重新交給模型，問題立刻被完美解決。

這個案例完美展示了所有錯誤的交集：選錯了問題（用 AI 作為最後手段）、缺少正確的上下文（沒有提供確切錯誤訊息）、以及沒有善用迭代流程。

我的想法

這部影片最核心的觀點其實很反直覺：AI 工具不是用來解決你「不會」的問題的，而是用來加速你「已經會」的事情的。這跟很多人對 AI 的期望完全相反。但仔細想想確實有道理——如果你自己都不知道正確答案長什麼樣，你怎麼判斷 AI 給你的答案是否正確？

「Context Rot」這個概念值得深思。很多人以為更大的上下文視窗就是更好的，但 Theo 引用的數據說明了一個殘酷的現實：超過一定 token 數之後，模型的表現會急劇下降。這對實務操作有很大的指導意義——與其花時間把整個專案塞進去，不如花同樣的時間寫好一份精確的問題描述。

「把 AI 當成每次記憶都被清除的新進工程師」這個比喻非常精準。它解釋了為什麼 Claude MD 檔案如此重要，也解釋了為什麼那些環境中的小問題（對人類來說只是「我知道這個可以忽略」）對 AI 來說卻是災難性的。如果你的團隊有好的新人入職文件，你的 AI 代理也會表現得更好——這兩者本質上是同一件事。