最近在公司推 Claude Code，我觀察到一個有點違反直覺的現象。

越懂軟體工程、越有專案管理底子、跨領域知識越廣的人，通常越容易把 Claude Code 用好。

這跟很多人最初想像的「AI 會把所有人拉到同一條起跑線」不太一樣。

AI 工具的確降低了技術操作門檻，但它同時放大了一件事——

一個人原本怎麼思考問題、怎麼拆解任務、怎麼判斷成果品質，會直接決定他能不能把 AI 用出價值。

真正的瓶頸在於思維方式

很多同仁一開始用 Claude Code 卡住，表面上看是不熟工具、不會下 prompt。但再往下挖一層，真正卡住的是：

  • 不知道自己要問什麼
  • 不知道怎麼描述現況
  • 不知道怎麼定義完成
  • 不知道怎麼判斷 AI 做出來的東西到底對不對
  • 也不知道下一輪該怎麼修正

換句話說，Claude Code 的學習門檻，表面是工具操作，實際上是系統性思維、軟體工程觀念與專案管理能力。

引導式協作方法：ORID 框架

我自己在使用 Claude Code 時，很常用類似 ORID 的方式引導 AI。

不是一開始就說：「幫我完成這個功能。」

而是：

  1. 客觀現況（Objective） — 讓 AI 看見目前有哪些檔案、系統流程是什麼、錯誤訊息在哪裡、需求單寫了什麼

  2. 反思洞察（Reflective） — 讓它理解痛點與風險——這個問題會影響哪些功能、會不會牽動既有邏輯、團隊最不放心的是哪一塊

  3. 詮釋分析（Interpretive） — 請它分析與收斂——這個問題的本質是架構問題、資料問題、流程問題、權限問題，還是單純的程式 bug？

  4. 決策行動（Decisional） — 最後才進入決策與行動——要改哪裡？怎麼改？怎麼驗證？怎麼證明真的做對？

這套方法之所以有效，不是因為 ORID 這個框架本身多神奇，而是它背後其實是一種專案管理與工程協作的思維：先釐清問題，再決定行動；先定義驗收，再開始實作。

AI 的角色定位：高級實習生

我也越來越覺得，與其把 Claude Code 當搜尋引擎，或是寫程式機器，不如換一個比喻：

它像一位非常有能力，但需要被好好帶領的高級實習生。

你不會對一位實習生說「幫我弄一個登入系統」，然後期待他完美交付。你會給他背景、目標、限制、參考資料、驗收標準。你也會要求他做完後自己先檢查，而不是每做一步就把半成品丟回給你。

實例：Markdown 文件與 Mermaid 圖轉換

這點我最近在處理 Markdown 文件時特別有感。

有些 Markdown 檔裡面有 Mermaid 圖，我請 Claude Code 轉成 PDF 或 Word 時，常常遇到一種情況：文件轉好了，但 Mermaid 圖的圖片難以閱讀——字太小、線太亂、比例跑掉，整張圖塞在頁面裡像一團資料毛線球。

更有趣的是，Claude Code 有時會說：「請你打開檔案確認一下。」

但這不是我想要的工作方式。 如果每一輪都要我自己打開 PDF、自己檢查圖清不清楚、再回頭跟它說哪裡壞掉——那 AI 只是把工作切碎丟回給我而已。

所以我後來反過來要求它：

  • 請你先把 Mermaid 圖獨立轉成 PNG 或 SVG
  • 請你自己檢查圖片解析度、字體大小、版面比例與可讀性
  • 請你確認圖在 PDF 或 Word 裡放進去之後，人類可以正常閱讀
  • 都確認沒問題之後，再請我打開最終版

這個小例子讓我體會很深——成熟的 AI 使用方式，不只是叫 AI「做事」，而是要讓 AI 形成一個完整的工作閉環：

理解任務 → 執行任務 → 自我檢查 → 修正問題 → 交付可驗收成果

工具選擇：沒有完全替代方案

不過，這也不代表所有工作都該用 Claude Code。

我觀察到，有些很小的修改，同仁還是習慣用 Cursor——改一兩行程式、調整小段 UI、快速補一個簡單邏輯，Cursor 的互動更直覺、更即時，也更貼近他們原本的工作節奏。

這完全合理。推動 AI 工具導入的目標是提高效率，不是創造新的工具限制。

  • 有些工作適合 Claude Code，因為它比較像可以長時間閱讀專案、拆解任務、規劃修改、執行驗證的工程協作者
  • 有些工作適合 Cursor，因為它在小範圍修改、即時補完、快速調整上很順手
  • 有些時候甚至不需要 AI，自己改最快

我比較喜歡用「工具箱」來看這件事。 多會一個工具不是多一個負擔，而是多一種應對工作的方式。重要的不是大家都用同一把槌子，而是遇到不同的釘子、螺絲、木板、電線時，知道該拿哪一個工具。

這跟帶人其實很像。我們真正要訓練的不是同仁背多少 Claude Code 指令，而是讓同仁知道：

  • 什麼叫做好的任務描述？
  • 什麼叫做合理的驗收標準？
  • 什麼時候應該要求 AI 自己先檢查？
  • 什麼時候不該接受「你自己打開來看」這種交付？
  • 什麼時候適合用 Claude Code 深入處理？什麼時候用 Cursor 快速修改就好？

AI 導入的本質：工作方法再訓練

所以我現在比較不把 Claude Code 的推廣，當成工具訓練。它更像是一場團隊工作方法的再訓練。

對不同角色的價值：

  • 資深工程師 — Claude Code 可以是架構協作者
  • 中階工程師 — 可以是重構與測試夥伴
  • 初學者 — 可以先是程式碼導覽員
  • PM 或 TPM — 也可以是需求整理、風險盤點與驗收條件設計助手

但前提是，我們不能只對同仁說一句「你自己去試試看」就放他們自生自滅。 這通常只會讓人更挫折。

設計容易成功的小路

比較好的方式，是幫同仁設計一條容易成功的小路。

第一，從低風險、高結構的任務開始

請 Claude Code 解釋一段程式、整理某個 API 流程、找出某個頁面牽涉到哪些檔案，而不是一開始就要求它完成大型功能。

第二，把好用的 prompt 當教材，而不是當咒語

重點不是叫同仁複製貼上，而是拆解每一段為什麼要這樣寫，讓他理解背後的思考方式。

第三，安排配對學習

讓比較熟悉系統的人陪不熟工具的人一起操作，重點不是教按鈕，而是示範怎麼描述問題、怎麼追問、怎麼驗收。

第四，重新定義初期成功

對剛開始學的人來說，第一週的目標不一定是產出完整功能，而是敢問第二次、敢要求 AI 修正、敢把模糊問題講得更清楚。

真正的成功指標：成就感，而非使用率

推動 AI 導入，不應該只問「你有沒有用 Claude Code？」

更應該問：「你在哪一個工作環節，已經開始感覺 AI 真的幫你省力？」

興趣不是被要求出來的。興趣通常是從某一個瞬間開始：

  • 原來我可以請 Claude Code 幫我讀懂陌生模組
  • 原來我可以請它整理修改影響範圍
  • 原來我可以要求它自己先把 Mermaid 圖轉成圖片並檢查可讀性
  • 原來我可以請它用測試或 Playwright 證明功能真的有做對
  • 原來我也可以繼續用 Cursor 快速處理小修改
  • 原來 AI 不是取代我，也不是限制我，而是讓我多了一組工具來掌控工作

我越來越相信，AI 工具導入的關鍵不是壓力，也不是統一規格，而是——成就感設計，與工具選擇能力。

結語：尋求最有效的「點燃瞬間」

如果你也在組織裡推動 AI Coding 工具，我很想聽聽你的觀察：

你看過最有效的「點燃同仁興趣」的瞬間，是什麼樣子？