<KeyTakeaways>
  <p>
    工作流程和代理該怎麼選？
    <a href="https://academy.claude.com/zh-TW/courses/building-with-the-claude-api">
      Building with the Claude API
    </a>{" "}
    的第 57–67 堂先從 Claude Code 與 MCP
    整合看代理如何使用工具，再用平行化、串連、路由與評估者-優化者拆出可預先定義的工作流程；本篇也整理抽象工具、環境檢查，以及可靠性和彈性的取捨，Computer
    Use 主要作為理解環境觀察的例子。
  </p>
</KeyTakeaways>

[上一篇〈Building with the Claude API（6/7）：MCP：Tools, Resources & Prompts〉](/posts/building-with-the-claude-api-part6/)把 MCP 的 tools、resources、prompts 接起來，讓 Claude 能碰到外部工具和資料。走到最後一段，我開始想另一個問題：工具都有了，下一步到底該由誰決定？

這次打開 [Claude Academy 的 Building with the Claude API](https://academy.claude.com/zh-TW/courses/building-with-the-claude-api)，也回到 [Claude Platform](https://platform.claude.com/) 對照 API、Claude Code 和代理的關係。課程先用 Claude Code 拆解一個已經存在的代理，再把工作流程和代理放到同一張設計圖上比較。

## 這一段先看兩個問題

| Section                                       | 這一組在處理的問題                                                               |
| --------------------------------------------- | -------------------------------------------------------------------------------- |
| Anthropic apps - Claude Code and computer use | Claude Code、Computer Use 為什麼可以當成代理的案例？MCP 又怎麼把外部能力接進來？ |
| Agents and workflows                          | 已知步驟、未知任務，以及可靠性、彈性和可測試性之間要怎麼取捨？                   |

這兩組放在一起很有意思。前半段從產品回頭拆設計原則，後半段則從設計模式回頭問：這個任務真的需要代理嗎？

## Anthropic apps - Claude Code and computer use（Anthropic 應用程式 - Claude Code 與 Computer Use）

### 57. Anthropic apps（Anthropic 應用程式）

Claude Code 和 Computer Use 可以當成理解代理的兩個成品案例。

Claude Code 是跑在終端機裡的代理式編碼助手，可以編輯檔案、修復錯誤、回答程式設計問題，並協助建立開發流程。Computer Use 則讓 Claude 存取網站、瀏覽網路，或與需要視覺介面導航的桌面應用程式互動。

課程把它們拆成四個值得觀察的原則：

- 工具整合與使用
- 多步驟任務執行
- 和環境互動
- 自主解決問題

這個角度比「某個產品有哪些按鈕」更有用。你可以把 Claude Code 看成一個已經把工具、迴圈和環境互動組合好的案例，再反過來問自己的代理少了哪一塊。後面的環境檢查，也會從 Computer Use 的螢幕截圖機制接回來。

### 58. Claude Code setup（Claude Code 設定）

Claude Code 的能力可以先分成四類：

| 類別               | 能力                            |
| ------------------ | ------------------------------- |
| 檔案操作           | 搜尋、讀取並編輯專案中的檔案    |
| 終端機存取         | 直接從對話中執行命令            |
| 網路存取           | 搜尋文件、擷取程式碼範例等      |
| **MCP 伺服器支援** | 透過連接 MCP 伺服器新增額外工具 |

課程示範的設定流程很短：先安裝 Node.js，再安裝 Claude Code，最後執行 `claude` 登入 Anthropic 帳戶。安裝命令是：

```bash
npm install -g @anthropic-ai/claude-code
```

它支援 macOS、Windows WSL 和 Linux。這堂課的重點不在安裝本身，而在於安裝之後，Claude Code 會從「回答程式碼問題」往「在專案裡採取行動」移動。

### 59. Claude Code in action（Claude Code 實戰）

`/init` 會掃描 codebase，理解專案結構、依賴項、程式碼風格和架構，再把整理出的內容寫進 `CLAUDE.md`。之後的對話可以把這個檔案當成專案上下文的一部分。

`CLAUDE.md` 可以放在三個範圍：

| 範圍            | 用途                                                               |
| --------------- | ------------------------------------------------------------------ |
| 專案（Project） | 放在專案根目錄，讓參與專案的工程師共用，通常提交到 version control |
| 本地（Local）   | 個人的專案筆記，不提交到 git                                       |
| 使用者（User）  | 放在個人設定資料夾，套用到自己的所有專案                           |

這個區分很重要。團隊共享的專案規範應該放在 project-level，個人偏好則留在 user-level；兩者混在一起，久了就會分不清哪條規則是專案共識、哪條只是某個人的習慣。

輸入 `#` 也可以快速加入筆記，例如：

```text
# Always use descriptive variable names
```

Claude 會接著詢問這條筆記要加入專案、本地，還是使用者範圍。

課程整理出的工作節奏，是先讓 Claude 讀懂上下文，再讓它只做規劃，最後才進入實作：

1. 找出和新功能相關的檔案，請 Claude 讀取並分析，讓它先掌握既有的程式碼模式。
2. 明確要求 Claude 先規劃，不要寫任何程式碼。
3. 確認計畫後，再請 Claude 實作。

如果改成測試驅動開發（TDD），順序會再多一步：先給上下文，再請 Claude 想測試案例，挑選相關案例寫成測試，最後請它寫出能通過測試的程式碼。這樣成功標準會先被固定下來，Claude 後面每一輪修改都有一個可以檢查的方向。

官方示範的完整節奏如下：

```
// First, ask Claude to read relevant files
> Read the math.py and document.py files

// Then ask for planning (not implementation)
> Plan to implement document_path_to_markdown tool:
1. Create a function that:
   - Takes a file path parameter
   - Validates the file exists
   - Determines file type from extension
   - Reads binary data from file
   - Leverages existing binary_document_to_markdown function
   - Returns markdown string
2. Add appropriate documentation
3. Register the tool with MCP server
4. Add tests

// Finally, ask for implementation
> Implement the plan
```

這和前面 Claude Code 課程裡的 `Explore 探索 → Plan 計畫 → Code 編碼 → Commit 提交` 是同一種節奏：先把問題放進正確的上下文，再定義成功的形狀，最後才讓模型動手。

### 60. Enhancements with MCP servers（透過 MCP 伺服器進行增強）

Claude Code 內建 MCP client，可以接上 MCP server 擴充能力。每個 server 可以公開三類東西：tools 負責執行動作，prompts 提供可重複使用的指令範本，resources 則提供可以帶入上下文的資料。

註冊 MCP server 的命令很直接：

```bash
claude mcp add [server-name] [command-to-start-server]
claude mcp add documents uv run main.py   # 例子
```

啟動 Claude Code 時，它就會自動連上已註冊的 server。課程用前面建立的 document server 當例子：當使用者要求把 `tests/fixtures/mcp_docs.docx` 轉成 Markdown，Claude Code 可以自行判斷要呼叫 `document_path_to_markdown`。

這裡把前一篇 MCP 課程的抽象概念接回日常工具。MCP server 負責維護外部能力，Claude Code 負責在任務中決定什麼時候使用它；原本散落在應用程式裡的整合程式碼，於是變成可以獨立測試與接入的工具介面。

## Agents and workflows（代理與工作流程）

### 61. Agents and workflows（代理與工作流程）

工作流程和代理，都是處理「Claude 無法在單次請求中完成的任務」的策略。差別在於下一步怎麼產生：

| 選哪個       | 條件                                                                           |
| ------------ | ------------------------------------------------------------------------------ |
| **工作流程** | 你能清楚描繪出 Claude 該經歷的確切流程／步驟；或 UX 把使用者限制在一組特定任務 |
| **代理**     | 你不確定究竟會給 Claude 什麼任務或任務參數                                     |

工作流程是一系列預先安排的 Claude 呼叫，依固定步驟解決特定問題。代理則拿到一個目標和一組工具，讓 Claude 在執行當下決定如何組合它們。

課程先用「圖像轉 CAD」說明工作流程。使用者拖放一張金屬零件圖片，要產出 STEP 檔，流程可以固定成：

1. 把圖片交給 Claude，請它描述物件。
2. 依照描述，請 Claude 用 **CadQuery** 建模。
3. 建立渲染圖。
4. 把渲染圖和原始圖片比對評分，有問題就修正。

這是「評估者-優化者（evaluator-optimizer）」模式：

| 角色     | 職責                                           |
| -------- | ---------------------------------------------- |
| 生產者   | 接收輸入、產生輸出，例如用 CadQuery 建模並渲染 |
| 評分者   | 依照標準評估輸出                               |
| 回饋循環 | 評分者不接受時，把回饋送回生產者改善           |
| 迭代     | 重複到評分者接受                               |

前幾篇的提示評估是在開發階段找出比較好的 Prompt；這裡則把「產生、評分、修正」搬進產品執行期間。相同的思路，使用時機不同。

### 62. Parallelization workflows（平行化工作流程）

假設正在做材料設計：使用者上傳零件圖片，系統要在金屬、聚合物、陶瓷、複合材料、彈性體或木材之間建議最佳材料。

把所有標準塞進一次請求，Claude 得同時處理太多競爭條件；只寫一個簡單提示，又沒有交代每種材料的判斷依據。平行化的做法是把同一張圖片送出多次，每個請求只負責一種材料的專門標準，最後再把分析結果交給彙總步驟比較。

流程可以畫成：

```text
同一張零件圖片
      ├── 金屬標準 → Claude 分析
      ├── 聚合物標準 → Claude 分析
      ├── 陶瓷標準 → Claude 分析
      ├── 複合材料標準 → Claude 分析
      ├── 彈性體標準 → Claude 分析
      └── 木材標準 → Claude 分析
                    ↓
              彙總所有結果
                    ↓
                最終建議
```

這種拆法的好處不只在於可以同時執行：

| 優點           | 內容                                              |
| -------------- | ------------------------------------------------- |
| 專注的注意力   | Claude 一次只專注一個面向，不必平衡相互競爭的考量 |
| 更容易調校     | 每個子提示可以獨立改善與測試                      |
| 更好的可擴展性 | 加一種材料等於加一個平行請求，不必重寫既有提示    |
| 提升可靠性     | 降低模型的認知負擔，讓結果更一致                  |

平行化適合複雜決策可以拆成獨立評估的情況。每個子任務都要能自己運作，並為最後的決策提供一塊獨特分析；如果子任務彼此需要對方的輸出，就該換成串連。

### 63. Chaining workflows（串連工作流程）

串連把一個大任務拆成較小、連續的子任務。後面的步驟必須吃前面的輸出，所以順序固定，也無法像平行化那樣同時處理。

官方用自動建立並發布影片的社群媒體行銷工具示範：

1. 在 Twitter 上尋找相關的熱門話題。
2. 選擇最有趣的話題。
3. 研究該話題。
4. 為短格式影片撰寫腳本。
5. 用 AI 虛擬形象與文字轉語音建立影片。
6. 發布到社群媒體。

第 1、5、6 步不需要由 LLM 完成，這也是串連的彈性所在：流程裡可以混入搜尋、影音處理和發布等一般程式。

串連最有說服力的用途，是處理「長提示裡有幾條規則一直被忽略」的情況。與其在同一個 Prompt 裡持續加粗、加標題、重複提醒，可以把創作和修訂拆成兩次請求：第一步先接受一個還不完美的初稿，第二步讓 Claude 專心做規則檢查。

```text
修訂下方提供的文章。請按照以下步驟重寫文章：
1. 找出文本中任何將作者標示為 AI 的位置並移除
2. 找出並移除所有表情符號
3. 找出任何令人尷尬的寫法，並替換成技術文件撰寫者會寫的文字
```

第二次請求只負責修訂，就不需要同時處理「產生內容」和「遵守所有限制」兩件事。這個做法也很容易套進文章、程式碼或報告的產出流程。

### 64. Routing workflows（路由工作流程）

路由處理的是另一種問題：不同類型的使用者請求，需要不同的 Prompt、工具或知識背景。課程的例子是影片腳本——「程式設計」需要教育性內容，「衝浪」則需要娛樂導向的內容。單一通用提示很難同時把兩種需求處理好。

官方列出的六個內容類別如下：

| 類別         | 特徵                                 |
| ------------ | ------------------------------------ |
| 娛樂         | 高能量、具文化相關性，使用流行語言   |
| 教育         | 清晰、引人入勝的解釋，配相關範例     |
| 喜劇         | 尖銳、出乎意料，巧妙的觀察與時機掌握 |
| 個人影音日誌 | 真實、親密，對話式敘事風格           |
| 評論         | 果斷、基於經驗，突顯優缺點           |
| 敘事         | 生動細節與情感連結的沉浸式內容       |

路由是兩步流程：先分類，再交給分類對應的專門處理流程。分類請求可以這樣寫：

```text
Categorize the topic of a video into one of the listed categories:
<topic>Python functions</topic>

<categories>
- Educational
- Entertainment
- Comedy
- Personal vlog
- Reviews
- Storytelling
</categories>
```

如果 Claude 回傳「教育」，第二次呼叫就使用教育範本。使用者的輸入只會進入其中一個專門流程，每一個流程都可以針對自己的使用情境調校。

```text
API 1：「墾丁天氣好嗎適合衝浪嗎？」+ <分類表>       → 回傳：娛樂
API 2：「墾丁天氣好嗎適合衝浪嗎？」+ <娛樂 prompt template> → 回傳：風格化的娛樂語氣回答
```

這裡的「專門流程」不只可以換語氣。客服系統可以依問題類型換知識庫和工具組，報告系統可以依文件類型換輸出格式；路由那一次分類呼叫，換來的是後面更窄、更容易調校的處理環境。

實作時也要替分類失準準備預設路徑。當回傳的標籤不在既定類別裡，系統仍然需要知道要交給哪個流程，這是路由額外引入的邊界條件。

### 65. Agents and tools（代理與工具）

走到這裡，代理的定義變得很清楚：知道確切步驟，就把步驟寫成工作流程；不知道下一個任務會長什麼樣，就給 Claude 一個目標和一組工具，讓它在執行時決定怎麼組合。

工具的設計會直接影響代理能處理的情境。課程用幾個日期時間工具示範組合能力：

| 請求                             | Claude 怎麼組                                          |
| -------------------------------- | ------------------------------------------------------ |
| 「現在幾點？」                   | 只呼叫 `get_current_datetime`                          |
| 「11 天後是星期幾？」            | 串 `get_current_datetime` + `add_duration_to_datetime` |
| 「設定下週三的健身房提醒」       | 依序用全部三個工具                                     |
| 「我的 90 天保固什麼時候到期？」 | 先反問購買日期，才能算到期日                           |

最後一列很有代表性：代理不只會挑工具，也知道目前資訊不足，需要先向使用者提問。

課程最重要的設計洞見，是工具應該保持抽象、可組合，而非為每一種高階任務各做一個專門按鈕。Claude Code 的工具可以概括成：

`bash`（執行任何命令）、`read`（讀取任何檔案）、`write`（建立任何檔案）、`edit`（修改檔案）、`glob`（尋找檔案）、`grep`（搜尋檔案內容）

它沒有一個叫「重構程式碼」或「安裝依賴項」的專門工具。Claude 會自己把基本工具組合起來完成複雜任務，這讓代理有機會面對開發者事前沒有規劃過的情境。

這裡也能分清楚 workflow 和 agent 的另一個差別：工具描述本身不會讓系統變成代理，因為固定流程呼叫工具時也需要 schema。真正的差別在於誰決定呼叫順序和次數——workflow 把決定寫在程式碼裡，agent 則交給模型在執行時決定。

### 66. Environment inspection（環境檢查）

代理能採取行動，還不代表它知道行動有沒有成功。它需要一個觀察環境的手段，才能依結果調整下一步。

Computer Use 的例子很直觀：Claude 每輸入文字或點擊按鈕，就會收到新的螢幕截圖。按鈕可能把畫面導向新頁面、打開選單，或觸發其他狀態變化；如果看不到後果，它就沒有足夠資訊判斷剛才的操作是否生效。

檔案操作也遵循相同原則。要在 Python 檔案新增路由，先讀現有程式碼，了解目前的結構和命名方式，再開始修改。這個「先讀取再寫入」不是形式上的步驟要求，重點是不要憑印象覆蓋尚未確認的現況。

課程給影片建立代理的系統提示，則把觀察手段寫得更具體：

- 用 bash 執行 **whisper.cpp**，產生帶時間戳記的字幕檔，驗證對話放置的位置。
- 用 **FFmpeg** 以固定間隔從影片擷取螢幕截圖，視覺檢查輸出。
- 把生成內容和原始需求比較。

因此，設計代理時可以反覆問一句話：**「Claude 如何知道這個動作是否成功？」**

| 動作     | 可以使用的觀察手段                    |
| -------- | ------------------------------------- |
| 修改檔案 | 修改前先讀取，修改後跑測試或檢查 diff |
| 操作介面 | 取得新的螢幕截圖，確認畫面狀態        |
| 呼叫 API | 檢查回應是否包含預期資料              |
| 產生內容 | 依需求驗證格式、內容和輸出檔案        |

沒有觀察手段的代理，很容易變成只會一路往下執行的盲打流程。系統提示可以協助它記住檢查規則，但真正重要的是每個動作都要有相對應的回饋路徑。

### 67. Workflows vs agents（工作流程與代理的比較）

把兩者放在一起看，差異可以整理成這張表：

|              | 優點                                                                                            | 缺點                                                     |
| ------------ | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
| **工作流程** | 一次專注一個子任務，通常準確度較高；更容易評估與測試；執行可預測可靠；適合定義明確的問題        | 彈性較低；UX 較受限；需要更多前期規劃與設計              |
| **代理**     | UX 更靈活；能以意想不到的方式組合工具；能處理開發時未預料的新情況；需要時可向使用者詢問額外輸入 | 任務成功完成率較低；更難監測、測試與評估；行為較不可預測 |

所以判斷順序可以很簡單：

- 流程和輸入都能先定義，就先用工作流程。
- 任務變化很大，或需要 Claude 自己探索路徑，再考慮代理。

這個結論有點反高潮，卻很務實。使用者在意的是產品能不能穩定完成工作，不在意背後是不是用了看起來很厲害的代理。可靠性是第一個目標，代理的彈性要在真的有需要時才換進來。

## Course Quiz 7（代理與工作流程測驗）

有 7 題。官方頁面本身是繁中，以下保留實際題目與正確答案。

### 1. 您的應用程式會產生不同類型的社群媒體內容。程式設計主題需要教育性腳本，而體育主題需要以娛樂為重點的內容。您應該使用什麼模式？

答案：**將請求路由到專門的處理流程**

### 2. 您需要 Claude 透過考慮金屬、塑膠、陶瓷和木材等選項，為某個零件推薦最佳材料。每種材料都有不同的標準。最佳方法是什麼？

答案：**針對每種材料類型平行發送個別請求**

### 3. 您需要為您的應用程式在工作流程和代理之間做出選擇。可靠性和可預測的結果對您來說最重要。您應該選擇哪一個？

答案：**使用工作流程，因為它更可靠且可測試**

### 4. 您正在建立一個具有工具的代理。哪種方法能讓 Claude 擁有最大的靈活性來處理意外的請求？

答案：**提供抽象工具，例如「read_file」、「write_file」和「run_command」**

### 5. 您正在建立一個應用程式，使用者上傳損壞汽車零件的照片，並總是獲得維修成本估算。您確切知道每次需要哪些步驟。您應該使用什麼？

答案：**具有預定步驟的工作流程**

### 6. 您希望 Claude 撰寫一份報告，然後檢查是否足夠好，並在需要時進行改進。您使用的是什麼模式？

答案：**評估者-優化者模式**

### 7. 當您給 Claude 一個包含許多要求的長提示時，它一直忽略您的一些規則。什麼工作流程方法會有所幫助？

答案：**將任務鏈接成專注的連續步驟**

## 小結

這個 section 沒有再手寫程式，重點轉成：什麼時候該用哪種工作流程。課程用範例把差別講清楚；上課時，我除了看課程內容，也會反問 agent：這是不是我平常工作流程的某一種形式，再把自己的案例帶進去追問。這樣比較快確認自己是真的理解，還是只記住了名詞。下面整理幾個我用來對照的問題，以及每一堂課留下的筆記：

### 61. Agents and workflows（代理與工作流程）

在 Agents and workflows 裡，工作流程和代理都在處理單次請求做不完的任務。前者先寫好步驟，後者讓 Claude 在工具集合裡自己決定路徑；評估者-優化者則把提示評估的「打分再改」循環帶進 runtime。

### 62. Parallelization workflows（平行化工作流程）

平行化的本質，是把一個任務拆成互不相干的子任務。每個子任務只專注一種標準，同時發出去獨立判斷，彼此不知道對方的存在，最後再彙總結果。這個「拆窄→品質穩」的原則不限定於技術定義上的「代理」；任何一次 Claude 呼叫都適用。職責越單一、標準越明確，判斷就越可靠。

拿自己日常使用的 Claude Code 多 subagent 模式來對照：如果「分幾隻、每隻查什麼」是**寫死在程式碼裡**的，那就是這堂教的 parallelization（workflow）；如果由主控在執行時判斷要開幾隻、各自查什麼，則更接近 [Anthropic〈Building effective agents〉](https://www.anthropic.com/engineering/building-effective-agents) 裡介紹的 orchestrator-workers。這是 Anthropic 列出的五種 workflow pattern 之一，而本課 61–64 堂只教了其他四種，剛好漏掉自己每天使用的這一種。

### 63. Chaining workflows（串連工作流程）

串連的核心，是把一件事拆成**有先後依賴**的小步驟，一步步個別執行。後面的步驟一定要吃前面的輸出，順序固定，不能打亂，也不能同時做；這和 62 堂子任務互相獨立、可以平行處理的做法正好相反。

### 64. Routing workflows（路由工作流程）

路由可以看成兩次獨立的 API 呼叫：第一次把問題和分類表交給 Claude，取得類別標籤；第二次把原問題和該類別專屬的 prompt template 交給對應流程，產生最後的風格化回答，這次不需要再帶分類表。以「墾丁天氣好嗎，適合衝浪嗎？」為例，第一次呼叫可能回傳「娛樂」，第二次就使用娛樂範本回答。

官方列出的六個類別——娛樂、教育、喜劇、個人影音日誌、評論、敘事——主要是在換風格、語氣和人設，因為底層任務都是寫影片腳本。但路由能換的不只是語氣，也可以是不同的知識背景、工具組和輸出格式。放到客服機器人裡，分類後對應的往往是一整套不同的知識與工具。實作時還要替分類失準準備預設或兜底範本。

### 65. Agents and tools（代理與工具）

工具描述本身和「是不是代理」沒有直接關係。無論是 MCP 還是原生 tool schema，workflow 呼叫固定工具時也要先描述清楚；這是工具呼叫的前提，不是代理獨有。真正的差別在於誰決定呼叫順序和次數：workflow 把決定寫死在程式碼裡，agent 則交給模型在執行時判斷。

既然要做代理，工具的顆粒度就應該像 **Unix 哲學**一樣原子化：每個小工具只專精做一件事，例如讀檔、查時間或上網，不要包成一個全能的複雜功能。這樣 Claude 才能依需求推算並重新組合工具；至於抽象程度要設多高，還是要看模型本身能不能撐得起那個抽象層級。

### 66. Environment inspection（環境檢查）

環境檢查不是「在系統提示詞裡定義什麼叫做完」這麼單薄，核心原則更廣——代理每做一個動作，都要配一個觀察這個動作結果的手段，依動作類型不同，實作方式也不同：UI 操作配截圖、檔案操作配先讀後寫、生成內容配主動跑驗證工具或跟原始需求比對。寫進系統提示詞只是其中一種實作，不是全部。

「先讀取再寫入」的深層含義，不是「輸入一定要先於輸出」這種計算上的必然順序，而是：不要憑「假設／印象」去寫，要憑「剛確認過的現狀」去寫。防的是這種情境——如果使用者在背景同時改了筆記，而我憑對話前面讀過的舊版本去寫，就會蓋掉使用者剛做的改動、甚至產生衝突。使用者手動提醒「筆記我改過，你再讀一次」，做的正是這件事；而這個 session 自己用的 Edit 工具也有一部分自動防呆——檔案在讀過之後被改過，工具會拒絕寫入、逼重讀最新版本，是同一個保護機制。

主動跑驗證工具（官方例子是驗證自己生成的字幕時間戳），可以延伸成兩個方向：驗證「我自己剛做出來的輸出對不對」（官方方向），以及驗證「我拿到的輸入本身有沒有問題」（例如使用者可能貼錯圖片）——兩者都是「別盲目相信，主動找工具查證」，只是查證的對象相反。

### 67. Workflows vs agents（工作流程與代理的比較）

這門課最後留下的判斷順序很簡單：能預先定義流程，就先用 workflow；任務多變、路徑難以規劃時，再考慮 agent。選擇的起點是可靠地解決問題，工具數量或架構名稱都排在後面。

## 心得

最後，Building with the Claude API 是我到目前為止上過最扎實的一門課。課程設計了 67 堂課，預計總共 9 小時；但我原本規劃用三天上完課、寫程式，再同步寫鐵人賽文章，根本做不到 XDD。

第一天上完前兩個 section，筆記就累積了一萬九千多字，嚇到我自己，根本看不完。光是把課程內容聽完、理解它實際在說什麼，就花了三小時，還沒開始寫文章。發完鐵人文章後，我馬上重新排課，直接改成七天；現在回頭看，這個調整完全沒錯。

第二天進入第三個 section「提示工程技巧」後，每堂課都帶著很完整的教學心法。跟著課程走一遍，真的會發現很多平常沒注意到的細節，所以這門課很值得推薦大家跟著走一遍。

我自己的做法是先讓一個 agent 爬過課程筆記，再開始上課；上課時把筆記打開，另外讓一個 agent 用教學引導模式跟我討論哪裡理解錯了。每節課結束，我會先用口頭方式說出這堂課的核心重點，等 agent 確認方向沒有偏掉，再繼續往下一堂。這個方法不能保證我完全沒有誤解，但至少會逼我在前進前先說清楚自己到底學到了什麼。

## 拿到完成徽章前：最終測驗

如果你也想把這門課完整走完，可以接著挑戰[〈Building with the Claude API：Final Assessment 最終測驗〉](/posts/building-with-the-claude-api-final-assessment/)，裡面整理了 23 題最終評量、對應章節與考點。