前言：這個系列借了孟子一句話

盡信書，則不如無書。

書不是不能讀，是不能全信。code 也一樣，不是不能讓 AI 寫，是不能不驗就收。

而且「不驗就收」比「沒有」更危險。

沒有 code 的時候，你知道自己沒有；AI 寫好 code 之後，你「以為」它是對的，就一路往後走，等到發現不對，成本(和 token)早就付出去了。

所以題目就是這樣來的：盡信 Claude，不如無 Code。

最近六年，主要工作是開發原生的 iOS App，一路走來大多是手工寫 code，沉浸在快速鍵與鍵盤敲擊的節奏裡。架構規劃好之後，剩下的就是把腦袋裡的東西轉成產品，過程中也練出了肌肉記憶(X)，以及 debug 時的某種直覺反應。

去年(2025)開始就不一樣了。感謝公司提供 AI 工具讓我們試，Cursor、Antigravity IDE、Claude Code、Codex 都各自跑過一輪，最後投票的結果，大家決定選用 Claude，所以這個系列主要會搭配 Claude 來做說明。

剛開始用 AI Agent 的時候，只敢讓它補測試、寫 commit message，做一些簡單的需求。也經歷過它還沒有現在這麼聰明的年代，一起 debug，然後一路鬼打牆，最後花了不少力氣才修正。

後來才敢讓它讀陌生專案、寫架構文件、寫文章，把重複講三次的活變成一行指令(或 skill)。到現在，AI 已經佔了工作流中的很大一塊，因此，人機協作這件事，本身就是現代開發的一門學問。

所以接下來這 30 天，不會從「Claude Code 怎麼安裝」開始講。

我想講的是另一件事。前 20 天介紹我日常開發在用的工具與心法，每一個都會講怎麼用、怎麼驗收，以及背後的心法(思考方式)；後 10 天則讓 AI 實作一個全端的小題目 —— 只有幾個最關鍵的規則，我會先手寫一版，再與 AI 的版本對照。

AI 出錯不可怕，可怕的是你看不出來

今年(2026)用下來，只確定一件事：它交出來的東西，不能只用看的。

不是「它會出錯」—— 每個工具都會出錯，那不值得寫一整個系列。而是它出錯的時候，看起來跟做對的時候一模一樣。

碰過最典型的一次是這樣的：讓它跑測試，它回報 163 個測試全部通過，一個失敗都沒有，連完整的測試報告都給了，時間戳是新的。

而那個專案當下根本編不起來。

編譯失敗的情況下，它把上一次的測試結果原封不動端了回來。如果我那天只看那份報告就往下走，會帶著一個「163 passed」的印象，繼續在一個連 build 都過不了的專案上做決定。

它沒有騙我 —— 它只是把一份過期的答案，用一個看起來很新的格式交出來。而我沒有任何辦法「一眼看出」那是過期的。

所以結論很短：你需要的不是一個更聰明的 AI，是一個不會說謊的裁判。

這 30 天我不打算用「相信」或「不相信」來回答這件事。會先把每個工具怎麼驗講清楚，再讓它打造一個 App。

前 20 天：工具與心法

前 20 天講的是我平常開發時用的工具與心法，每一篇不只講工具怎麼用，還會多做一件事：講怎麼驗證(驗收)。

• 讓它先讀懂再討論：陌生的 repo 怎麼掃成一張圖、圖怎麼變成閱讀路徑、它產的架構文件哪些能信 —— 這一篇我會逐句標「可驗證 / 查無 / 編造」，然後算比例
• 在它動手前說清楚：CLAUDE.md 該寫什麼、規格先行(手寫一次，再讓工具拆一次)、Plan Mode、Git 上哪些東西絕對不讓它碰，以及同一條規則寫在 CLAUDE.md 和寫成 hook 差在哪
• 把工作流變成可複用：重複講的話變成指令與 Skill、把寫測試整個外包給地端模型跑，然後用突變檢查驗那些測試是不是假的
• MCP，以及工具本身會出錯：「MCP 支援 X」有三個答案，手打三行才知道是哪一個、實際接一支 server 走到它第一次撞牆、拿現成的工具實測它宣稱的數字 —— 前面那個「163 passed」，就是這樣抓到的

這 20 篇會反覆出現同一個順序：碰到什麼問題 → 用哪個工具 → 怎麼確認它真的解決了 → 它的邊界在哪。 第三步「怎麼確認」，就是每一篇多做的那件事。

後 10 天：實作一個完整的小專案來練習使用 AI

後 10 天從零做一個活動報名系統 —— 學習用，不上架。技術棧：Cloudflare Workers + Hono 當 API、D1(SQLite)當資料庫、Pages 做 web 前端、SwiftUI 做一個 iOS 骨架，兩個前端吃同一份 OpenAPI 契約。

選這個題目，是因為報名系統表面簡單，但是底下有一整組能被機器裁決、而眼睛看不出來的規則：錢怎麼算、折扣怎麼疊、票價漲了舊訂單怎麼辦、開賣瞬間誰搶到、保留過期那一刻誰說了算。每一條都會配一個不靠人眼的裁判 —— 測試、靜態檢查、CI。

這 30 天不會有的東西

先把邊界畫掉，你才知道要不要跟：

• 不教安裝與基本操作。 官方文件寫得比我好。
• 不做模型橫向評測。 我不會告訴你 Claude 比誰強，那是另一種文章。
• 不談 prompt 技巧。 這個系列的立場是：與其把話講得更漂亮，不如把驗收做得更硬。
• 沒有精美的 UI 設計。 本實作主要用來練習與學習使用。

總結

前 20 天講工具與心法，後 10 天拿它們做完一個完整的小專案。

如果你只想從今天帶走一句話，我希望是這句：

一份你沒驗過就採信的 code，比沒有那份 code 更危險。

明天就從第一個工具開始。而每一篇的最後，我都會留下當天真正量到的東西 —— 數字，或是一條你可以直接拿去用的規則。

明天：拿一個陌生的 repo 開刀 —— 不讀 README，先問圖：該從哪三個檔開始讀？
節點、邊、群集的數字全部貼出來。

參考資料

• 《孟子·盡心下》：「盡信書，則不如無書。」—— 系列名的出處
• Claude Code 官方文件：code.claude.com/docs
• 2026 iThome 鐵人賽活動辦法：r.itho.me/ironguide2026
• 本系列的實作專案(公開 repo)：github.com/n913239/event-signup-lab
• 延伸閱讀：Xcode 內建 MCP 實測：它回報 163 個測試全過，而專案根本編不起來 —— 上面那個「163 passed」的完整追查