# AI 工具為什麼越用越挫折：實際學習地圖

> 作者的四階段學習比喻、實際工作流程跡象，以及在一個 AI 協作專案中推進成果的三大支柱實驗。

Source: https://ailoot.ai/blog/zh-hant-tw/why-you-quit-ai-tools/
Canonical: https://ailoot.ai/blog/zh-hant-tw/why-you-quit-ai-tools/
Language: zh-Hant-TW
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-198
Revision: sha256-1475040287e48c42d3f245b9639ea1846f21035e297b926e5fad4d7a988232fd


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

本文把常見的四階段學習曲線，當成使用 Claude Code 或 Cursor 的作者比喻：初期興奮可能轉為挫折，之後透過刻意練習形成較穩定流程。這些標籤用來反思，不是每個人都會依序經歷的驗證規律、放棄預測或診斷測驗。下方清單與三大支柱，只是在一個專案中可嘗試的實用建議。

</div>

更多 Ailoot 使用說明請見[文件](https://ailoot.ai/docs/)。



## 學習的比喻，不是普遍心理定律

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

鄧寧－克魯格效應涉及判斷自身表現的侷限。常見的山峰、低谷、斜坡與高原圖是通俗示意，不能證明每位學習者必須按順序經歷四階段。本文只藉它整理期待、挫折與練習的例子。

</div>

本文的實際問題比心理診斷更窄：你的期待是否符合可驗證成果？請比較原先期待完成什麼與實際能運作什麼，再依證據調整下一項任務。

不要只以信心衡量能力；應檢查真實成果及支撐它的驗證。

此後，鄧寧－克魯格曲線成為廣受歡迎的四階段示意圖。首先，信心攀升至「愚蠢山峰」。接著跌入「絕望谷」。之後，它會慢慢沿著「啟蒙斜坡」攀升，前往「穩定高原」。

本文只把曲線當作比喻，沒有針對讀者的研究能證明放棄比例、固定學習時長，或人人都會經歷這些標籤的路徑。

## Vibe coding 的 4 個階段——你現在在哪裡？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

下列四個標籤描述學習者可能熟悉的情況，並非每個 Claude Code 使用者必經階段。愚蠢山峰：你讀了一篇關於代理程式的文章，就覺得自己會 vibe coding。絕望谷：你開始研究 MCP 和 Skills，才發現自己什麼都不懂。啟蒙斜坡：規則開始奏效，方法也帶來成果。穩定高原：你的知識與信心相符，能穩定地打造產品。每個階段都有各自的內心想法和外在行為。

</div>

每個階段都有典型的想法和行為，可以從中辨認。以下是這張地圖。

### 階段 1——愚蠢山峰

你讀了一篇關於 Claude Code 的文章，也許還看了一支影片。一切看起來都很清楚：安裝工具、輸入提示詞、取得程式碼。文章作者描述自己如何「一個晚上就打造出一套 SaaS」。你也想在一個晚上完成。

你心裡想著：

- 「我想我懂了。」
- 「這不就是聊天，只是更聰明嗎？」
- 「我是創業家，不需要程式設計師。」
- 「我一個月就能精通，然後去杜拜。」

行為：

- 你下載並安裝 Claude Code。
- 你在聊天中輸入「幫我做一個預約應用程式」。
- 你得到無法執行的程式碼。
- 你覺得是模型不對，於是買了 Max 訂閱方案。

在這個階段，你高估了工具，也高估了自己。這只是可能的起點。期待若持續與可運作成果脫節，挫折可能增加；小型專案與明確檢查，可提供具體學習依據。

實際自我檢查時，請另一個人依明確標準查看相同輸出。自稱「AI 專家」等充滿信心的描述，不能證明生成成果的品質。

把初期自信當成假設。執行程式、查看輸出，讓結果修正你對自身能力的估計。

### 階段 2——絕望谷

你開始深入研究。你閱讀 MCP 的資料，嘗試連接伺服器。你下載現成的 Skill，試著弄懂它。你啟動 Plan Mode——代理程式寫了一份計畫，卻在第三步偏離方向。你打開 `~/.claude/`——裡面有 12 個資料夾，你不知道任何一個是做什麼用的。

你心裡想著：

- 「我什麼都不會。」
- 「社群媒體上那些人都在說謊。」
- 「別人能用的方法對我就是行不通。」
- 「也許我太早開始接觸這些了。」
- 「我花了 $200 買 token，結果拿得出什麼？」

行為：

- 你同時打開 20 個文件分頁。
- 每次聊天都從「忘掉前面的對話」開始。
- 你瀏覽論壇，閱讀「X 搞壞了我的專案」之類的討論串。
- 你拿 Claude 和 Cursor 比、拿 Cursor 和 Codex 比、再拿 Codex 和 Cline 比。你覺得自己用錯了工具。
- 你早上坐下來要寫程式，午餐時間還沒到就開始滑動態消息。

這可能令人挫折，但本文沒有測量此時的放棄比例。請用下方跡象找出一項值得嘗試的改變。

### 階段 3——啟蒙斜坡

你停下來，放慢腳步，不再追逐每一項新東西。你寫出第一份 CLAUDE.md，並放進專案裡。你建立 `business/` 資料夾，把產品、價格和受眾的描述放進去。你用了十次 `/compact`，終於明白它該保留哪些上下文。你做出第一個 Skill——只處理一項特定任務，長度 30 行。

你心裡想著：

- 「啊，原來是這樣運作的。」
- 「我今天完成了一件一週前還做不到的事。」
- 「我想我明白 `business/` 和 `ai-clone/` 有什麼不同了。」
- 「我已經為 X 任務準備好現成提示詞了。」

行為：

- 每次新任務開始前，你都會回到 Plan Mode。
- 在對 Claude 寫任何內容之前，你會先問自己：「這有寫在我的 CLAUDE.md 裡嗎？」
- 你尋找下一條方法規則；新工具不再輕易吸引你的注意力。
- 你在聊天中幫助別人：「我也卡在這裡過——你試試這樣做。」

### 階段 4——穩定高原

這不是事情變得輕鬆的時刻，而是你的知識終於與信心相符的時刻。

你心裡想著：

- 「我知道自己有哪些不知道的事。」
- 「這項任務要花我三個小時；我以前做過。」
- 「這需要一個新的 Skill，我現在就來整理。」
- 「如果 Claude 偏離計畫，我知道三個可能的原因。」

行為：

- 你穩定地打造產品——一個用一個晚上，另一個花一個週末。
- 你有自己的 Skills 資料夾、自己的子代理程式，以及每個專案各自的 `business/` 資料夾。
- 你有選擇地聘用承包人，處理那些你根本無法自行完成的部分。
- 你很少看別人的影片教學——主要是為了找新點子，而不是學基礎。

自我評估清單——你現在在哪個階段？

- 如果你還沒試過 Claude Code，卻覺得「噢，我一個晚上就能完成」，那你在階段 1。
- 如果你試過、打開過 MCP、試著讀過 Skills，並且想著「我幹嘛要碰這個？」，那你在階段 2。
- 如果你已經建立 CLAUDE.md，而且看得出它確實如何改變 Claude 的行為，那你在階段 3。
- 如果你穩定地打造產品，也清楚知道何時該用哪個工具，那你在階段 4。

## 你現在正身處絕望谷的 7 個跡象

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

把這七項跡象當作反思提示，而非計分診斷。選出最明顯妨礙目前任務完成的一項，嘗試相對應的改變。

</div>

絕望谷不會突然到來，而是慢慢滲入。以下是這些跡象：

**1. 你一直比較工具，卻沒有打造東西。** 你打開一個「Cursor vs Claude Code」分頁，讀完後再打開「Cline vs Cursor」，接著是「Codex vs 其他所有工具」。每看一篇比較，你就想：「也許我找錯方向了。」一天結束時，你一行程式碼都沒寫，卻花了四個小時。

**2. 你每次開新聊天都說「忘掉之前的一切」。** 你沒有 CLAUDE.md，也還沒掌握 `/compact`，更不懂什麼是上下文視窗。每次工作階段都從一張白紙開始。一週後，你會發現自己已經第十五次向 Claude 解釋同一件事。

**3. 你收集提示詞，卻不使用它們。** 你在 Notion 建了一個「Claude Code 提示詞」資料夾，裡面有 47 個書籤，卻沒有任何一個用過兩次。每次你都覺得：「這次一定就是我需要的。」

**4. 你覺得別人「成功是因為他們有人脈」。** 你打開社群媒體，看到有人在一個週末推出產品的第一版。你想：「他們有團隊，有人脈，我做不到。」你沒想到的是，他們在階段四，而你在階段二。

**5. 你在第三天就放棄專案。** 每個新專案都以興奮開始（「這一定很棒！」），到第三天就結束。當挑戰從「在聊天中打聲招呼」變成「處理付款」時，你就離開了。做困難的事讓人害怕。

**6. 因為 Claude 沒做好，你就到 ChatGPT 找答案。** Claude 給了你糟糕的答案，所以你打開 ChatGPT。ChatGPT 給了你糟糕的答案，所以你打開 Gemini。你從沒想過可能是請求寫得不好——你總是怪工具。

**7. 你告訴自己：「這真的不適合我。」** 這是最陰險的跡象。它聽起來像一句防衛性的結語，說完之後那個人就離開了。這個想法可能反映挫折，而非無法學習。「低谷」在本文只是比喻；沒有實測百分比或固定時間表可說明誰會有這種感受、接下來一定怎樣。

若幾項跡象符合，下一個目標就選一項小而可運作的成果。記錄阻礙並改變流程的一個部分；這份清單不能預測進步需要多久。



## 為什麼人們會在低谷中放棄——這不是懶惰

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

在這個比喻中，低谷指預期與實際進度的落差。看似很快的任務，可能需要陌生的設定與除錯；社群媒體範例也可能讓比較更令人灰心。這是對挫折的實際描述，不是神經學診斷。

</div>

對工具感到挫折，不能可靠衡量能力。對工具作長期決定前，先檢查任務大小、欠缺知識及執行環境。

不要從艱難的一週推論大腦機制，應記錄可觀察事實：嘗試什麼、哪些成功、哪個錯誤擋住下一步，以及花了多久。這些紀錄能指出具體改善位置。

在低谷裡，你同時遭受兩種打擊。第一，你自己的進展不如預期。第二，身邊的人發表了你還沒有的成果。你打開社群媒體——有人推出產品第一版，有人打造了代理程式，有人用 Claude API 賺到了第一個一百美元。你花了三週，卻連資料庫都連不上。

除了主觀速度，也請記錄實際耗時。代理可能讓人感覺有效率，卻增加審查與返工；請與先前流程比較代表性任務，不要把感覺提升當成實測提升。

陌生任務進展緩慢，不能證明你缺乏能力。請把學習成本與工具輸出分開，定義一項更小、可檢查的成果。

沒有可重複的下一步時，很容易更換工具或放棄任務。下方三大支柱是作者提出的結構，不是對離開原因的統計證明。

## 3 大支柱——走出低谷的方法

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

新工具或新提示詞無法讓你走出絕望谷。能帶你走出低谷的是由三大支柱組成的架構：AI 分身（Skills 和個人方法論）、第二大腦（CLAUDE.md 和 `business/` 資料夾），以及上下文工程（Plan Mode 和上下文視窗管理）。每一根支柱都能處理低谷的一種症狀。三者可能讓流程更易檢查與重複，但不會消除幻覺，也不能取代成果驗證。

</div>

根據本文作者的經驗，走出低谷花了三個月：期間試過數十種工具。最後我明白一件事：問題不在 Claude，而在於我每次都從一張白紙開始。沒有記憶、沒有規則、沒有界線。

之後，我整理出一套架構，稱之為「三大支柱」。這個名稱指的是 Claude Code 工作流程所依靠的三類組成部分。少了任何一根，整個架構就會垮掉。

### 支柱 1——你的 AI 分身

AI 分身是將你的專業知識整理成一種格式，讓 Claude 自動套用。

在絕望谷裡，你每次都從頭向 Claude 說明你的做法，請它「幫我處理這項任務」。支柱 1 就是要解決這個問題：你的方法論以一組檔案的形式放在 `ai-clone/` 資料夾裡。一個 Skill 說明「我如何處理客戶案例」，一個 Skill 說明「我如何撰寫 Telegram 貼文」，還有一個名為「產品架構師」的子代理程式，在規劃階段像你一樣思考。

支柱 1 的實際形式：

- Skills——針對特定任務提供指示的檔案（`/build-article`、`/build-reel-script`）。
- 子代理程式——具備不同專業領域的人設，Claude 會在這些角色之間分派子任務。
- `ai-clone/feedback/` 資料夾——從錯誤中學到的規則。每條規則採用 Rule - Why - How 的格式。

我在[Skills、Subagents、MCP 和 Plugins 指南](https://ailoot.ai/blog/zh-hant-tw/skills-subagents-mcp-plugins-claude-code/)中詳細介紹了這些內容，並說明何時該使用什麼。

### 支柱 2——第二大腦

第二大腦是關於專案的知識結構化儲存庫，Claude 可以直接存取。

在絕望谷裡，你每次都要向 Claude 解釋產品是什麼、受眾是誰、商業模式又是什麼。到了第三週，你發現自己已經第十五次解釋同一件事。支柱 2 就是要解決這個問題：你把專案知識整理成程式碼旁邊的檔案，Claude 需要時會自行讀取。

支柱 2 的實際形式：

- `CLAUDE.md`——代理程式的入口檔，包含行為規則、路徑，以及指向其他內容的連結。
- `business/` 資料夾——產品、受眾、經濟狀況、目標、內容計畫和競爭者。
- `plans/` 資料夾——按階段整理的技術計畫，以及各階段的狀態。
- `retrospectives/` 資料夾——從先前工作階段學到的經驗，避免重蹈覆轍。

完整說明請參閱[設定 CLAUDE.md 指南](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)和[Claude Code 第二大腦指南](https://ailoot.ai/blog/zh-hant-tw/claude-code-second-brain/)。

### 支柱 3——上下文工程

上下文工程是在你按下 Enter 之前，管理要放進 Claude 上下文視窗的內容。

在絕望谷裡，你不明白為什麼 Claude 在聊天四十則訊息後就「忘了」指示，也不懂為什麼需要 `/compact`。你不開 Plan Mode，因為覺得「不用它比較快」。支柱 3 就是要解決這個問題：你有意識地決定要載入哪些內容。這能提供更相關輸入，但仍需驗證主張與輸出。

支柱 3 的實際形式：

- Plan Mode——代理程式先寫出任務計畫，你核准後再執行。不使用它的話，你第一次嘗試就會得到一團亂的結果。
- `/compact`——智慧壓縮聊天歷史。上下文開始填滿時，把它壓縮，只保留關鍵決策。
- 結構化提示詞——不要只寫「幫我」，而要寫「這裡是背景資訊 A，這裡是任務 B，請依格式 C 回傳結果」。
- 子代理程式——把子任務交給全新的上下文處理，避免主上下文超載。

我在[上下文工程指南](https://ailoot.ai/blog/zh-hant-tw/context-engineering/)和[Plan Mode 指南](https://ailoot.ai/blog/zh-hant-tw/claude-code-plan-mode/)中介紹了這些內容。

### 為什麼是三大支柱，而不是一根

你可以只建立第二大腦，讓 Claude 了解你的專案，但它會像沒有規則的實習生一樣行動。

你可以只建立 AI 分身，讓 Claude 接手你的專業知識，但沒有專案記憶，每次工作階段都會從頭開始。

上下文工程可能改善任務輸入，但不保證流程順利，也不會單獨保存知識。

只有把三者組合起來，才能得到我所說的「可預測架構」。Claude 會記得你的專案，自動套用你的方法論，也不會在任務中迷失方向。

這就是你走出絕望谷的時刻。

## 讓你困在低谷的 7 種反模式

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

以下是作者反思挫折工作流程時使用的模式例子：缺少 CLAUDE.md、長對話不整理上下文、相信第一個答案，或忽略成本追蹤。請選一項相關改變，評估是否有助於完成真實任務；這份清單沒有經驗證的及格分數。

</div>

值得在自己的流程檢查的反模式：

**1. 沒有 CLAUDE.md 就說「幫我寫一個能用的應用程式」。** 你打開新的 Claude Code 聊天，立刻交代任務。Claude 不知道你的專案、方法論或偏好，只會給你一個通用範本，讓你很失望。

該怎麼做：建立 CLAUDE.md，先放入最基本的內容——你的技術堆疊、商業模式、目標受眾，以及其他檔案的連結。每次聊天都從這些背景資訊開始。

**2. 長時間對話卻不使用 `/compact`。** 你進行了 80 則訊息的工作階段。Claude 已經不記得你在第 12 則訊息做了什麼決定。上下文視窗塞滿了沒有關鍵決策、只有猶豫不決的歷史記錄，回答品質也跟著下降。

該怎麼做：每 30–40 則訊息呼叫一次 `/compact`，並說明哪些內容要保留。上下文就會更聚焦。

**3. 相信第一個答案。** Claude 提出一個解法，你馬上套用。一小時後，你發現它弄壞了另外三個檔案。你因為「它又不好用了」而放棄。

該怎麼做：複雜任務使用 Plan Mode。先寫計畫、討論計畫，再執行。這樣你可以在規劃階段發現錯誤，而不是忙了半天後才發現。

**4. 提示詞雜亂無章，毫無結構。** 你寫「把它做好」，期待 Claude 自己理解。它做不到，因為它不知道你所說的「好」是什麼意思，只能猜。

該怎麼做：按照「背景資訊 - 任務 - 限制 - 格式」的結構撰寫提示詞。這會大幅提高第一次就得到好結果的機率。

**5. 忽略成本追蹤。** 你不知道自己用了多少 token。月度方案用完後，你打開控制面板，發現已經花掉 $200。你嚇了一跳，於是退出。

該怎麼做：設定 token 用量追蹤器。我在token 追蹤器指南中介紹了相關工具。即時看到支出後，你就不會白白消耗 token。

**6. 沒完沒了地尋找「正確工具」。** Cursor 推出，你就換到 Cursor。Cline 出現，你就試 Cline。Codex 更新，你又回到 Codex。每兩週換一次新工具，每次都重新開始，因此永遠達不到工具開始為你效力的程度。

該怎麼做：選一種工具，用三個月。不要一遇到藉口就換。我只會在目前的工具根本做不到某件事時，才查看比較資料。

**7.「沒時間讀方法論。」** 你覺得工具不需要準備就應該會動，覺得寫提示詞是天生的技能，覺得 CLAUDE.md「又多一層麻煩」。結果到了第二個月，你還在做一週內就能用方法論完成的事。

該怎麼做：接受 Claude Code 和任何專業工具一樣需要學習。學習方式就是方法論；直覺在這裡行不通。

延伸閱讀：[Claude Code 中的諂媚效應指南](https://ailoot.ai/blog/zh-hant-tw/claude-code-sycophancy-prompts/)探討如何避免低谷中最大的誤解——Claude 只要同意你的想法，就一定是對的。

## 你已經走出低谷、踏上啟蒙斜坡的 5 個跡象

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

你可以從幾種平靜的變化辨認出啟蒙斜坡，而不是靠亢奮的感覺。你的 CLAUDE.md 超過 200 行；你不用提醒就會回到 Plan Mode；你熟記自己的 Skills；工作節奏穩定下來，你知道一項典型任務需要多久；而且你開始得到別人的求助，因為你做出了成果。

</div>

以下五個跡象表示你已經在階段三：

**1. 你的 CLAUDE.md 超過 200 行，而且你有意識地持續維護。** 你不是從範本複製而來，而是自己逐步建立。你知道每個章節的內容，也知道它為什麼存在。看到新的模式時，你會去新增一條規則。

**2. 每次遇到非例行任務，你都會開啟 Plan Mode。** 不用提醒，也不是因為自律，而是你明白沒有計畫就會白白浪費一小時，還得到錯誤結果。它不再是「多一道步驟」，而是變成反射動作。

**3. 你有自己的 Skills 和 Subagents 目錄。** 不是從 GitHub 下載的，而是自己建立、專門處理你的特定任務。新任務和舊任務相似時，你會想起自己的 Skill，而不是從頭寫提示詞。

**4. 你的工作節奏穩定下來。** 你現在知道：「像這樣的任務，我需要 3 小時。」不會再想「噢，這很快」，也不會想「噢，這要花好久」。你能合理估算所需時間。這表示你已在兩個方向上超越鄧寧－克魯格效應——不再高估，也不再低估。

**5. 別人開始向你求助。** 有人在聊天中問 MCP 的問題，你就用具體例子回答：「我之前就是這樣遇到的。」有人問 Plan Mode，你就展示自己的例子。這是精通方法論的副作用：低谷裡的人會在你的經歷中認出自己的處境，於是來找你。

請用這些跡象反思最近進展，不要自行計分或預測何時抵達高原。持續確認估算與可運作成果是否逐漸一致。

在高原上，人類在代理程式架構中的角色會改變。

這就是走出低谷的成果：你不再是「學習寫提示詞」，而是管理一套代理程式架構、擔任流程架構師，成為掌舵的人。

## 如果你現在正灰心喪志，該怎麼做

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重點摘要

如果你讀完這篇文章，發現自己卡在低谷，先別關掉分頁。採取三個步驟：大聲說出自己在哪個階段（診斷）、放慢腳步（先做一個專案，從一根支柱開始）、建立架構（用自己的方法，或借用別人的方法）。先試有結構的工作流程，再判斷是否需要新工具；只有結果改善才保留。這個比喻或一張時間表，都不能保證進步。

</div>

下個任務可嘗試的三個步驟。

**步驟 1——說出具體障礙。** 告訴自己：「這是目前工作流程中令人挫折的部分。我可以指出具體阻礙，選擇更小的下一步。」以可觀察問題取代對能力或心理階段的診斷。

**步驟 2——放慢腳步。** 選擇一個專案，一個就好，不要兩個，也不要三個。從三大支柱中選擇一根，挑出最能解決這個專案痛點的那一根。如果專案是新的，完全沒有上下文，就選第二大腦（CLAUDE.md）。如果專案已經存在，但 Claude 的行為不像「你」，就選 AI 分身（Skills）。如果任務很長，而且上下文快填滿了，就選上下文工程（Plan Mode + `/compact`）。

一個專案、一根支柱、兩週。別試著在一個週末打造所有東西——那會讓你再度跌回低谷。

**步驟 3——建立架構。** 你可以自己建立方法論。根據本文作者的經驗，這花了三到六個月。



<div class="section" role="doc-bibliography" aria-label="Sources">

### 資料來源

- [Anthropic Engineering，為 AI 代理程式有效進行上下文工程（2025）](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - 說明上下文視窗為什麼會退化，以及為什麼需要管理。
- [Claude Code 文件 - 記憶](https://code.claude.com/docs/en/memory) - Claude Code 官方的記憶層級說明。


</div>





若要繼續使用各種模型，請前往 [Ailoot](https://ailoot.ai/)。

## 常見問題：AI 工具為什麼越用越挫折：實際學習地圖

### 四個階段會預測我一個月後就放棄嗎？

不會。本文把常見曲線當作比喻，沒有測量放棄比例或普遍時間表。請用例子找出具體障礙，不要拿來診斷自己，或預測何時一定會進步。

### 一直更換 AI 工具時，實際下一步是什麼？

選一個專案及一項可驗證的小成果。改善最造成困擾的部分，例如專案指示、可重用流程或上下文管理，再與前次嘗試比較實際成果及所花時間。


## Ailoot · 公司及其專案組合

Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。

公司及其專案組合：數百萬客戶，每月銷售額達數十億。

Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。
