BridgeCraft logobridgecraft
週報顧問服務作品集關於聯絡登入
聯絡

bridgecraft

從資料視覺化到 AI Agent,一直在找下一個 meta

文章主題指南週報顧問服務Labs作品集系統架構關於聯絡RSS

© 2026 BridgeCraft — Waiting7777. All rights reserved.

← 所有文章
Claude Code 要這樣學 — 動手做比看文件有用多了

Claude Code 要這樣學 — 動手做比看文件有用多了

2026年3月31日 · Waiting7777 · 4 分鐘閱讀

AI
📂 AI 系列

別再看文件了 — 直接用 Claude Code 來學才是正解

看到這個互動式學習平台的想法,我第一個反應是「終於有人懂了」。

老實說,Claude Code 的官方文件寫得還行,但你看完之後呢?通常就是一頭霧水,然後開始瘋狂 Google 找範例。這種學習方式實在太辛苦了 — 你花了兩小時看文件,結果真正動手寫的時候還是不知道從哪開始。

為什麼看文件學不會?

問題出在「認知負荷」。當你在看文件的時候,腦子裡要同時處理:

  1. 理解語法結構
  2. 想像實際應用場景
  3. 記住各種參數和選項
  4. 推測可能的錯誤狀況

這四件事同時進行,大腦早就超載了。結果就是看完覺得都懂,一寫就卡住。

我自己剛開始摸 Claude Code 的時候也是這樣。看了半天 prompt engineering 的最佳實踐,結果第一個 chatbot 寫出來還是很蠢,回答問題總是答非所問。

互動式學習的核心設計

這種「Learn by doing」的平台厲害在哪?它把學習拆成小塊,每一步都有即時反饋。

比如說你想學 Claude Code 的 function calling,傳統方式是:

  1. 看文件了解 function calling 的概念
  2. 看範例程式碼
  3. 自己寫一個完整的 function
  4. 測試,發現不 work
  5. Debug,通常要花很多時間

互動式平台的做法是:

  1. 先給你一個半成品的 function
  2. 讓你填空補完關鍵的 2-3 行
  3. 立刻執行,看結果
  4. 如果錯了,直接告訴你哪裡有問題

這種方式的學習效果差很多。你的認知負荷降低了,專注力可以放在核心概念上,而不是被語法細節卡住。

實際案例:學 Claude Code 的 context window 管理

假設你要學怎麼處理長對話的 context window 限制,傳統文件會告訴你:

「Claude 有 context window 限制,當對話過長時需要進行 context trimming 或 summarization...」

然後給你一大段範例程式碼。看起來很完整,但你還是不知道什麼時候該 trim、怎麼 trim 比較好。

互動式平台可以這樣設計:

Step 1: 給你一個簡單的聊天機器人,故意讓 context 爆掉 Step 2: 讓你體驗 context 過長的錯誤 Step 3: 引導你實作最簡單的 sliding window 策略 Step 4: 測試效果,發現會丟失重要資訊 Step 5: 改用 summary-based 的方法 Step 6: 比較兩種方法的 trade-off

整個過程你都在「做」,每一步都有具體的輸出可以觀察。這比看一小時文件有效多了。

設計這種平台的關鍵考量

我覺得要做好這種互動式學習,有幾個重點:

漸進式複雜度 — 不要一開始就丟一個完整的 AI Agent 給學習者。從最簡單的 prompt 開始,一層一層加功能。

即時反饋 — 每寫一行都要能立刻看到結果。Claude Code 的好處是執行速度快,這個優勢要善用。

錯誤設計 — 刻意讓學習者踩坑,然後引導修正。光看正確的範例學不到什麼,踩過坑才知道為什麼要這樣寫。

真實場景 — 練習的案例要是實際專案會遇到的問題,不是那種 hello world 等級的範例。

對比:為什麼這比看 tutorial 好?

最大的差別在於「主動 vs 被動」。

看 tutorial 是被動接收資訊,你的大腦處於「接收模式」。而實際動手是主動建構知識,大腦處於「解決問題模式」。後者的記憶效果好很多。

而且 tutorial 通常會跳過很多細節 — 作者覺得理所當然的地方,對初學者來說可能是最大的卡點。互動式學習強迫你處理每一個細節,包括那些「理所當然」的部分。

我會怎麼用這種平台?

老實說,就算我現在對 Claude Code 算熟了,遇到新功能時我還是會選擇這種學習方式。

比如 Claude 推出新的 model 或新的 API features,與其花時間讀 changelog 和文件,我寧願直接找個互動式的 playground 玩一遍。十分鐘就能摸清楚新功能的特性和限制。

這就是為什麼我覺得「Learn by doing」才是學習 AI tools 的正確姿勢。文件是參考書,不是教科書。

<h2>延伸閱讀</h2> <ul> <li><a href="/blog/claude-code-more-control-but-keeps-it-on-a-leash">Claude Code 權限升級 — AI 寫程式的安全邊界在哪?</a></li> <li><a href="/blog/how-coding-agents-are-reshaping-engineering-product-and-design">How Coding Agents Are Reshaping Engineering, Product and Design</a></li> <li><a href="/blog/thinking-fast-slow-and-artificial-how-ai-is-reshaping-human-reasoning">Thinking Fast, Slow, and Artificial: How AI Is Reshaping Human Reasoning</a></li> </ul>

每週一篇 — 技術趨勢背後的商業邏輯

分享:

Waiting7777

WoW Arena 冠軍轉前端,用電競 meta 思維拆解技術趨勢。

關於作者

相關文章

YC 裡越來越多二次創業者 — AI 時代為什麼老手反而更吃香創業創投+4

YC 裡越來越多二次創業者 — AI 時代為什麼老手反而更吃香

為什麼 AI 時代反而讓「老手」更吃香?從 YC 的數據看 repeat founder 的優勢在哪,以及這對第一次創業的人有什麼啟示。

2026年8月12日 · Waiting7777 · 7 分鐘閱讀

繼續閱讀 →
OpenChamber:專為 AI Agent 設計的開發環境,跟 IDE 的差別在哪?AI Agents開發工具+5

OpenChamber:專為 AI Agent 設計的開發環境,跟 IDE 的差別在哪?

拆解 OpenChamber 的設計邏輯:為什麼 agent 需要專屬的開發環境、跟直接在 terminal 跑 Claude Code 有什麼本質差異,以及這個方向的商業潛力在哪。

2026年8月11日 · Waiting7777 · 8 分鐘閱讀

繼續閱讀 →
AI coding 工具燒錢有多快?Databricks 告訴你怎麼控成本AI開發工具+4

AI coding 工具燒錢有多快?Databricks 告訴你怎麼控成本

從「Databricks 燒完錢才搞出控制工具」這個角度切入,拆解 AI coding 工具的真實成本結構,以及企業在 scale up 後才發現的坑。對比 Rippling 同樣在燒錢後才蓋 ROI 工具,這是一個系統性問題。

2026年8月8日 · Waiting7777 · 7 分鐘閱讀

繼續閱讀 →

這篇文章對你有幫助嗎?

每週一篇 — 技術趨勢背後的商業邏輯

AI 產業在變什麼、工程師該注意什麼——拆清楚寄到你的信箱。