載入中...
基礎知識

即使你不是工程師，也必須現在開始學習 Claude Code 的八個理由

第 1 篇，共 12 篇
↗ 全螢幕播放簡報

前陣子，我教會一位朋友使用 Claude Code。他完全不會寫程式，連 Terminal 是什麼都沒聽過。但他有一個很清楚的產品想法，一直找不到工程師幫他做。

兩週後，他把那個產品完整地實作出來了。

不是原型、不是 wireframe，是一個可以實際運作的產品。他全程沒有寫過任何一行程式碼——他只是用中文描述他要什麼功能，Claude Code 就幫他把程式寫出來、跑起來、除完錯。

你可能會想：那它跟 ChatGPT 到底差在哪？

一、你說中文，它寫程式

大部分人聽到「Claude Code」就先退了一步。Code，程式碼，那不是工程師的事嗎？

試試看跟它說這句話：「幫我把這個資料夾裡所有 PDF 的檔名，整理成一份清單。」

它會自己寫一段程式碼、跑完、把清單生出來。你完全不需要看懂那段程式碼。同樣的事在 ChatGPT 上做，它會把程式碼貼給你看，然後你得自己想辦法找地方執行。

你需要學的不是程式語言，而是怎麼把需求講清楚。但光是能下指令還不夠——如果它每次只能做一件事就停下來等你，那跟比較聰明的 Siri 也沒什麼兩樣。

二、它不是聊天機器人，它是 Agent

用過 ChatGPT 或 Gemini 的人對 AI 的印象通常是：問一個問題，得到一個答案。一來一回，像在傳訊息。

跟 Claude Code 說「幫我把這 20 張圖片都縮小到寬度 800px，轉成 WebP 格式，存到 output 資料夾」，看看會發生什麼。

ChatGPT 會給你一段教學。Claude Code 直接幫你做完，output 資料夾裡已經躺著 20 張處理好的圖片。中間如果某張圖片格式有問題，它會自己發現錯誤、換個方式處理、繼續往下跑。

聊天機器人給你資訊。Agent 幫你完成工作。

不過，這裡有一個問題。它能做事、能跑程式，但它做事的地方在哪裡？

三、它能直接操作你的電腦

一般的 AI 聊天活在瀏覽器的分頁裡，跟你的電腦之間隔著一道牆。它摸不到你的檔案、打不開你的資料夾、跑不了你的程式。

Claude Code 不一樣。它跑在你的終端機裡，你的整台電腦就是它的工作空間。

你跟它說「把桌面上那份報告裡的表格抓出來，轉成 Excel」。它真的去讀那份報告、解析內容、生成一個 .xlsx 檔案放在你指定的位置。不是給你教學叫你自己做——是它做完了，你打開檔案確認就好。

聽起來很強。但如果每次開啟它都要重新自我介紹、重新解釋你的工作背景和偏好，那你大概用三天就煩了。

四、它記得你是誰

跟 ChatGPT 聊天，每次開新對話都要重新說一遍：「我是做行銷的」「報告格式要用繁體中文」「我們公司用 HubSpot」。每次都要講，它每次都忘。

Claude Code 有一個叫 CLAUDE.md 的設定檔。你把工作背景、偏好、常用格式、公司的內部規範寫進去，每次啟動它都會先讀這份檔案。

你可以根據不同的專案類型，設計不同的 CLAUDE.md。寫部落格的專案有一份，管理客戶資料的專案有另一份，做產品開發的專案又是另一份。每份都帶著不同的背景知識和工作規範。

同一個工具，在不同的專案裡表現出完全不同的行為。它不是一個通用的 AI，它是你針對每一種工作量身定做的 AI。你甚至可以隨時告訴它「記住這件事」，下次開新對話，這些記憶還在。

但「認識你」只是第一步。你的工作領域有大量的專業知識——格式規範、品質標準、判斷邏輯——光靠一份設定檔裝不下。

五、它能學會你的專業領域

這就是 Skill 的用途。

Skill 是一份結構化的知識文件，告訴 Claude Code 在特定任務上應該怎麼做。我們團隊有一個「寫部落格文章」的 Skill，裡面定義了文章格式、語氣標準、該避免的用詞、品質評分方式。每次寫文章，Claude Code 就按照這份 Skill 的標準來執行。

把它想像成一本操作手冊。你把你最擅長的工作方法寫成 Skill，Claude Code 就能用你的標準幫你做事。

一個會計可以寫一份「月結報表」的 Skill。一個設計師可以寫一份「設計稿命名規範」的 Skill。一個業務可以寫一份「客戶提案信」的 Skill。這些 Skill 可以分享給同事，也可以跨專案使用。你的專業知識不再只存在你的腦袋裡。

到這裡，你有了一個認識你、懂你專業的 AI。但你每天的工作不只在一個工具裡完成——你要收 Email、更新 Notion、在 Slack 回報進度、到 Google Sheets 整理資料。這些工具之間，還是得靠你自己搬資料。

六、它能連接你用的所有工具

Claude Code 能透過 API、CLI 和 MCP 連接其他服務。

MCP（Model Context Protocol）聽起來很技術，概念卻很簡單——它是一個標準化的方式，讓 AI 可以直接跟其他軟體對話。裝了對應的 MCP 之後，你可以跟 Claude Code 說「把這份報告的摘要貼到 Slack 的 #marketing 頻道」，它就直接發出去了。

不用切換視窗、不用複製貼上、不用開 Zapier 設定自動化流程。一句話，串起原本要在三個工具之間跳來跳去的動作。

現在想像一下：你有一個理解你工作方式的 AI、它懂你的專業知識、還能操作你所有的工具。但如果你教會它的東西，每次都會消失呢？

七、一次教會，反覆使用

前面提到的記憶、Skill、MCP 連接，有一個共同的特性：它們是累積的。

你今天花 30 分鐘教會 Claude Code 怎麼處理月報，下個月只要說一句「跑月報」就好。你花一個小時把客戶分類的邏輯寫成 Skill，之後每次新客戶進來，它自動按照你的邏輯分類。

ChatGPT 的對話是一次性的，下次還是要從頭教。Claude Code 的設定是持久的，你投入的每一分鐘都在為未來節省時間。

三個月後回頭看，你會發現它已經知道你的工作方式、品質標準、常用格式和偏好工具。你投入的時間是線性的，但它帶來的時間節省是指數型的。

這就引出了最後一個問題：既然這些能力這麼強，為什麼是「現在」開始？

八、這是下一個必備技能

還記得 2000 年代初期，有人說「我的工作不需要用電腦」嗎？還記得 2010 年代，有人說「我不需要學 Excel」嗎？

我認為，「會不會用 AI 工具」正在成為跟「會不會用 Office」一樣基本的職場技能。差別在於，這次的轉變速度快得多。

現在學 Claude Code 的門檻，是它誕生以來最低的時候。社群資源在快速成長、操作介面越來越友善、Anthropic 持續在降低入門的摩擦。但工具的能力每週都在增加。

早一天開始，你就多累積一天的記憶、Skill 和工作流。等到身邊的人都開始用的時候，你已經有了三個月甚至半年的領先優勢。

這個優勢不是「我比你多認識一個工具」，而是「我的 AI 已經理解我的工作方式，而你的還在從零開始」。

從哪裡開始？

不需要一次學完所有功能。

第一步：安裝 Claude Code，用中文跟它說一件你今天本來要手動做的事。整理檔案、改檔名、合併資料——任何重複性的工作都行。

就這樣。從一件具體的小事開始。

當你第一次看到它在 15 秒內完成你原本要花 30 分鐘的工作，你就不需要任何人再說服你了。

基礎知識

我為什麼選擇 Claude Code

第 2 篇，共 12 篇
↗ 全螢幕播放簡報

為什麼不是 Codex？為什麼不是 Gemini CLI？為什麼不是 OpenClaw？

每隔幾天就有人問我這些問題。或者換個問法：「你怎麼不用 XXX？大家都在用欸。」

我的答案一直沒變過。但要解釋清楚為什麼，得從頭說起。

用了一年多，我對模型能力的判斷

我是 WordPress 工程師，寫了十幾年的 PHP。當 AI 開始能輔助寫程式的時候，我第一個反應不是興奮，是懷疑。畢竟 WordPress 的生態系有它自己的一套規則和慣例，這些不是通用的程式知識，而是你要在這個生態待過才會知道的細節。

各家模型我都試過。老實說，每一家都有各自擅長的領域，寫程式的能力也都在快速進步。但就我個人的使用情境——WordPress 外掛開發、WooCommerce 客製化、LINE 串接——Claude 的模型在這些場景中的表現，一直是最讓我順手的。

真正讓我做出判斷的，不是某一次的驚艷體驗，而是持續使用超過一年的累積。這一年多來，我用它跑過多個客戶專案，也拿它開發自己的產品。從最早期的版本到現在，我能明顯感受到它的進步——對 WordPress 生態系的理解越來越深，給出的方案也越來越貼近實務。它不只是語法正確，而是真的理解 WordPress 的開發慣例和設計邏輯，給出的方案越來越貼近有經驗的工程師會做的選擇。這不是靠「會寫程式」就能做到的，是長期迭代後才有的理解深度。

這不代表其他模型不好。只是當你在一個工具上投入了足夠的時間、建立了足夠的工作流程和信任感之後，除非有明確的理由讓你搬家，否則留下來是最合理的選擇。

這跟我一直選擇 WordPress 是同一個道理。十幾年來，每隔一陣子就有人問我：「為什麼不換框架？」Laravel、Next.js、各種新東西輪番出現，每個都有它的優勢。但我在 WordPress 上累積的理解、踩過的坑、建立起來的開發效率，不是換一個框架就能帶走的。工具的價值不只在功能本身，還在你跟它之間磨合出來的默契。

Claude 也是一樣。一直沒有給我搬家的理由。反而是每次更新，都讓我更確定留在這裡是對的。

但模型好只是第一步。接下來的問題是：你要怎麼用它？

工具越包越多層，體驗反而越來越差

既然 Claude 的模型寫程式最好，那用整合了 Claude API 的開發工具應該不錯吧？我也是這樣想的。

Cursor 我用了一陣子。體驗確實不錯，自動補全的速度快、上下文理解也到位。但它的訂閱費用對我來說是個問題——每個月的開銷加上去，對一個小團隊的荷包不太友善。當我發現 Claude Code 能做到同樣的事，甚至做得更多，而且計費方式更透明的時候，就沒有繼續留在 Cursor 的理由了。

Antigravity 我也試過。介面設計得漂亮，操作體驗流暢。但核心問題沒變：中間隔了一層，你不確定它到底是把你的需求原封不動傳給了模型，還是做了什麼改寫或截斷。

後來我直接用 Claude Code。

沒有華麗的 GUI，就是一個終端機介面。但第一次用完一整天的感受是：終於沒有東西擋在中間了。

我描述需求，它理解。它改了什麼檔案、改了哪幾行，全部攤在你面前。不用猜它在背後做了什麼。出問題的時候，你知道是你的需求沒描述清楚，還是它的判斷有誤——這個透明度，在其他工具上得不到。

我沒有客觀數據證明它「更快」或「更準」。這純粹是主觀體驗。但這個主觀體驗夠強烈，讓我再也沒打開過其他工具。

功能迭代的速度，其他工具追不上

選定 Claude Code 之後，這幾個月的觀察更讓我確信這個選擇是對的。

Claude Code 的開發團隊顯然有在看社群。一個功能需求在 GitHub Discussions 或 X 上被討論幾天，很可能下個版本就出現了。不是那種「我們聽到了，會排進路線圖」的官方回覆，是真的直接做出來。

Hooks 機制就是一個例子。社群裡有人想在每次 commit 前自動跑 lint，有人想在檔案修改後觸發自訂腳本。Claude Code 直接做了一套 hooks 系統，讓你可以在特定事件觸發時執行任意 shell 指令。這個機制後來被好幾個 AI 開發工具借鑑。

CLAUDE.md 也是。一個純文字檔案，放在專案根目錄，告訴 AI 這個專案的架構、慣例、偏好。這個概念簡單到不行，但它解決了一個所有 AI 工具都在頭痛的問題：怎麼讓 AI 理解「這個專案」的脈絡，而不只是「這個語言」的語法。類似的做法在其他工具上也有，像 Cursor 的 .cursorrules 甚至更早就出現了。但 Claude Code 在這個基礎上做得更完整——支援全域、專案、子目錄三層載入，加上自動記憶系統，讓專案脈絡的管理更有彈性。

還有 MCP（Model Context Protocol）、自訂 Skill、記憶系統、子代理人（Sub-agent）、背景任務⋯⋯這些功能一個接一個地推出，而且每個都不是花拳繡腿，是解決真實開發場景的問題。

一個工具的迭代速度能維持這麼快，代表它背後的團隊真的在用自己的產品。這件事聽起來理所當然，但在軟體業，做到的人比你想的少。

選工具，就是要選最底層的那一個

回到最初的問題：為什麼不用其他工具？

我的核心觀點是：Claude Code 目前是這個市場的規則制定者。

它不只是一個好用的工具。它在定義「AI 輔助開發應該長什麼樣子」這件事上，走在最前面。其他工具在追它的功能、參考它的設計模式、借用它的概念。

在這個前提下，我認為選擇 AI 工具的原則很簡單：選最底層的。

什麼叫最底層？就是它能做到的事情，是其他工具的功能來源。用 Claude Code 你可以做到那些「套殼」工具做得到的所有事情，甚至做到它們做不到的事情。反過來就不行了。

那些包了一層 GUI、加了一些限制、重新包裝過的工具，本質上都是在 Claude 的能力之上做篩選和呈現。篩選的過程中，一定會有東西被擋掉。有些是刻意的設計選擇，有些是能力上的限制。不管是哪種，你能用的，都只是模型完整能力的一部分。

我不想只用一部分。我想要完整的能力。

當然，Claude Code 的學習門檻比其他 AI 開發工具高。你得會用終端機，得理解基本的命令列操作，得學會怎麼寫 CLAUDE.md、怎麼設定 hooks、怎麼用 MCP 連接外部工具。這些東西第一次接觸確實需要花時間。

但這個投資是值得的。因為你學會的是最底層的操作方式，往上的工具你隨時都能理解、隨時都能切換。反過來，如果你只會用上層工具，一旦它們的限制卡住你，你就得從頭學起。

不是信仰，是工程判斷

我不是 Anthropic 的粉絲，這個選擇跟品牌忠誠沒有關係。如果明天有另一家公司做出了更強的模型和更好的開發工具，我會毫不猶豫地換過去。

但以 2026 年 3 月的時間點來看，Claude Code 就是目前最好的選項。模型能力最強、工具迭代最快、社群最活躍、對開發者的理解最深。

選工具不是選信仰。它是一個工程判斷——在你手邊可選的方案裡，哪個能讓你用最少的時間、做出品質最高的成果。

就我個人來說，目前這個答案是 Claude Code。就這麼簡單。

基礎知識

Claude Code x 技術小白第一次安裝就上手

第 3 篇，共 12 篇

你聽說 Claude Code 很厲害，能用中文下指令就幫你寫程式、整理檔案、自動化重複工作。但打開教學文章，第一步就叫你「打開終端機輸入 npm install」——然後你就默默關掉教學分頁了…

這篇文章就是寫給你的。我們會介紹兩種安裝 Claude Code 的方式，從最簡單到稍微進階，讓你根據自己的需求選擇。

方法一：下載 Claude Desktop App（最簡單）

如果你只是想趕快開始用，這個方法三分鐘就能搞定。

第一步：下載安裝

到 claude.ai/download 下載 Claude Desktop App。Mac 和 Windows 都有，跟你平常安裝 LINE 電腦版或 Spotify 一樣——下載、打開、拖進應用程式資料夾，結束。

第二步：登入帳號

打開 App 之後用你的 Anthropic 帳號登入。如果還沒有帳號，在這一步就能註冊。

第三步：升級到 Pro 方案

免費帳號無法使用 Claude Code。登入後到帳號設定頁面，訂閱 Pro 方案（每月 20 美元）。這是使用 Claude Code 的最低門檻——付完之後，Code 分頁才會開放。

第四步：切換到 Code 模式

登入之後你會看到一般的聊天介面，跟網頁版 Claude 一樣。但注意上方——有一個 「Code」 分頁。點下去。

Claude Desktop App 上方的 Code 分頁

這就是 Claude Code。

第四步：選擇工作資料夾

進入 Code 分頁後，它會請你選擇一個「目的地資料夾」。這個資料夾就是 Claude Code 工作的地方——所有你要餵給它的檔案，或是它幫你產生的檔案，都會放在這裡。

選擇工作資料夾

你可以從最近使用過的資料夾裡選，也可以點「Choose a different folder」自己指定。如果你還不確定要用哪個資料夾，先在桌面建一個新的空資料夾就好，之後隨時可以換。

選好之後，你就能開始在對話框裡打字，告訴 Claude Code 你想做什麼了。

想像你打開 Word 之後，上面有「文件」和「簡報」兩個分頁。Claude Desktop App 的概念類似——「Chat」是一般聊天，「Code」是讓 AI 幫你處理電腦上的工作。

這個方法適合誰？

  • 第一次接觸 Claude Code，想先試試看能幹嘛
  • 不想碰任何技術設定
  • 主要用來做簡單的任務，例如整理文件、產生報表、轉換格式

方法二：用終端機安裝（進階但更靈活）

Desktop App 用起來很順手，但用一陣子之後你可能會碰到一些限制。比方說：

  • 有些指令需要你回答問題。 安裝軟體或跑自動化工具的時候，它會問你「要選哪個選項？」「確定要繼續嗎？」這類互動在終端機裡才能直接處理。
  • 有些工作本來就要在終端機裡做。 例如啟動某個程式、跑資料處理腳本等等。如果你已經在終端機裡用 Claude Code，它可以直接幫你執行，不用再另外開視窗。用 Desktop App 的話，碰到這類需求還得自己切過去終端機處理。

終端機是什麼？

你每天都在用圖形介面操作電腦：用滑鼠點資料夾、拖拉檔案、按按鈕。終端機是另一種操作電腦的方式——用打字代替點滑鼠。

打個比方：圖形介面像觸控螢幕的點餐機，你看到什麼就點什麼。終端機像直接跟店員說「一杯中杯拿鐵、去冰、加燕麥奶」——你得知道怎麼說，但說出來之後更快、更精確，還能一口氣講完複雜的要求。

你不需要記住什麼指令。Claude Code 的強大之處就在於——你只要用中文告訴它你想做什麼，它會自己跑對應的指令。終端機只是它工作的地方。

第一步：下載 Warp 終端機

Mac 和 Windows 都有內建的終端機程式，但老實說，預設的終端機介面不太友善。我們推薦用 Warp——它是專門為現代使用設計的終端機軟體，介面乾淨、操作直覺，打字的時候有自動完成，還能把輸入和輸出分成清楚的區塊。

到 warp.dev 下載安裝就好，Mac 和 Windows 都有，流程跟裝一般軟體一樣。

第二步：安裝 Claude Code

開啟 Warp 之後，在可以輸入指令的地方，複製以下的安裝指令並按下 Enter。它會自動幫你安裝 Node.js、Git 和 Claude Code。

安全提醒： 在網路上看到任何「貼上一行指令就能安裝」的做法時，請養成一個好習慣——先把指令貼給 ChatGPT 或 Gemini，請它幫你檢查這段指令在做什麼、有沒有危險性。有些惡意人士會利用這種方式在你的電腦安裝後門程式。以下這兩行指令你也可以先檢查，我們完全公開原始碼：Mac 版 / Windows 版。

Mac：

curl -fsSL https://gist.githubusercontent.com/oberonlai/f4f6b8a7a2f8e0c70118d2d437e326b5/raw/install-claude-code-mac.sh | bash

過程中會跳出密碼輸入框（安裝 Node.js 需要系統權限），輸入你的 Mac 登入密碼後按 Enter。密碼不會顯示在畫面上，這是正常的。安裝 Git 時會彈出一個視窗，點「安裝」就好。

執行完成後，你會看到類似這樣的畫面，代表全部安裝成功：

Mac 一鍵安裝完成畫面

Windows： 在工作列搜尋「Warp」，右鍵選「以系統管理員身分執行」，貼上這行指令後按 Enter：

irm https://gist.githubusercontent.com/oberonlai/61ef05497999adc560600fceaabfe2b8/raw/install-claude-code-windows.ps1 | iex

安裝完成後，輸入：

claude

第一次執行會請你登入 Anthropic 帳號。畫面會出現三個選項，選第一個「Claude account with subscription」就對了。

Claude Code 登入畫面

登入完成後，就可以開始用自然語言跟 Claude Code 聊天了。直接打中文告訴它你想做什麼，它就會幫你處理。

Claude Code 對話畫面

為什麼要多費這個工夫？

Desktop App 很方便，但終端機版本有幾個優勢：

跑互動式指令。 有些工具會在過程中問你問題——「要選哪個選項？」「確定要繼續嗎？」——這類互動在終端機裡可以直接處理，Desktop App 目前還不支援。

不用在 App 和終端機之間來回切換。 有些工作本來就需要在終端機裡執行，例如啟動程式或跑腳本。如果你已經在終端機裡用 Claude Code，它可以直接幫你處理，不用另外開視窗。

簡單來說，Desktop App 像是在餐廳用平板點餐，終端機版本像是直接走進廚房。大部分時候平板就夠了，但如果你想做更細緻的事，廚房讓你有更多可能。

該選哪一種？

Desktop App終端機版本
安裝難度下載就能用貼上一行指令自動安裝
上手速度馬上需要 1 分鐘設定
適合用途簡單任務、初次體驗專案開發、檔案操作、進階自動化
彈性基本完整

我們的建議：先從 Desktop App 開始。等你用出心得、發現有些事情它做不到的時候，再來裝終端機版本。兩個可以同時存在，不衝突。

常見問題

Claude Code 要付費嗎？

要。Claude Code 需要至少 Pro 方案才能使用，免費帳號無法開啟。最入門的 Pro 方案是每月 20 美元，適合偶爾使用的人。如果用量比較大，Max 方案有每月 100 美元和 200 美元兩種選擇，額度更多。建議先從 Pro 開始，不夠再升級。

我用 Windows 可以嗎？

可以。Desktop App 有 Windows 版，直接下載安裝就能用。終端機版本也支援——上面的安裝步驟 Mac 和 Windows 都有，照著做就行。

Claude Code 和網頁版 Claude 有什麼不同？

網頁版 Claude 是聊天機器人——你問它問題，它回答你。Claude Code 是工作助手——它能直接操作你電腦上的檔案、執行指令、建立專案。差別在於，聊天機器人只能給你建議，Claude Code 能幫你動手做。

我完全不懂程式，真的能用嗎？

能。你不需要看懂它寫的程式碼，就像你不需要知道微波爐的電路設計才能加熱便當。你只要用中文描述你想做的事：「幫我把這 50 個 Excel 檔合併成一個」「把這個資料夾裡的照片按日期重新命名」——它會自己處理。

安裝到一半出問題怎麼辦？

一鍵安裝指令會在最後顯示 Node.js、Git 和 Claude Code 的版本號碼。如果其中任何一個沒有出現，可以個別檢查：

  • 打開終端機，輸入 node --version，有出現版本號碼就是裝好了
  • 輸入 git --version，同上
  • 輸入 claude --version，同上

如果某個工具顯示「command not found」，關掉終端機重新打開再試一次——有些安裝需要重啟終端機才會生效。

Mac 用戶： 如果安裝過程中沒有跳出密碼輸入框就直接出現錯誤，重新執行一次指令，這次留意密碼提示。

Windows 用戶： 如果出現紅字錯誤訊息，最常見的原因是沒有用系統管理員身分執行 Warp。關掉目前的視窗，重新在工作列搜尋「Warp」，右鍵選「以系統管理員身分執行」，再貼上指令。

Desktop App 的 Code 模式和終端機版本是同一個東西嗎？

核心功能相同，都是 Claude Code。差別在於運作環境——Desktop App 把它包在一個圖形介面裡，終端機版本直接在你的電腦環境中執行，能做的事情更多。

職場應用

Claude Code x WordPress 網站管理

第 4 篇，共 12 篇
↗ 全螢幕播放簡報

我一直在想一件事：怎麼讓 Claude Code 直接幫我管 WordPress 網站？

最早的想法是自己寫一支外掛，開一組 REST API 讓 Claude Code 呼叫。後來也研究過用 MCP（Model Context Protocol）來串接。但越想越覺得不對——不管是自建 API 還是 MCP，Claude Code 能做的事都被限制在這些工具提供的端點裡。我想新增一個功能，就得先回去改 API；我想查一個 log，得先確認有沒有對應的 endpoint。

我真正想要的不是這個。我想要的是：Claude Code 直接幫我寫外掛、直接丟到主機上測試、直接用 WP-CLI 操作資料庫。不是透過中間層間接控制，而是像我自己 SSH 進主機一樣，什麼都能做。

透過 API 或 MCP 技術上做得到，但要把 WordPress 的管理權限開放給外部呼叫，風險太高。一個 API endpoint 設計不好，等於幫攻擊者開了一扇門。

後來發現答案其實很簡單——SSH。

我在 Terminal 裡打了一句話：「幫我找出 Gmail 裡的退信，把對應的殭屍帳號從 WordPress 刪掉。」

三十秒後，Claude Code 讀完退信、提取出失敗的 email、SSH 進遠端主機、用 WP-CLI 查到那個帳號、確認是機器人註冊的，然後刪除。整個過程我只按了一次確認。

這不是什麼未來場景。我今天早上剛做完。

先搞懂 SSH 是什麼

你的 WordPress 網站放在一台遠端的電腦上，也就是主機。平常你透過瀏覽器打開後台管理介面來操作它，但其實還有另一種方式——直接「登入」那台電腦，用打字下指令的方式操作。

SSH 就是這個遠端登入的通道。你可以把它想像成一條加密的秘密隧道，連接你的電腦和主機。透過這條隧道，你可以在自己的電腦上對主機下達指令，就像你坐在那台主機前面一樣。

那 SSH key 又是什麼？一般登入需要帳號密碼，但每次都要輸入密碼很麻煩，而且密碼可能被猜到。SSH key 是一種更安全的驗證方式——它會產生一對鑰匙，一把「私鑰」留在你的電腦上，一把「公鑰」放到主機上。連線時兩邊自動配對，對上了就放行，不需要輸入任何密碼。

這對 Claude Code 來說很重要。因為它沒辦法像人一樣互動式地輸入密碼，但有了 SSH key，它就能直接連進主機執行指令，完全不需要人工介入。

設定步驟

整個設定大概五分鐘。

第一步：產生 SSH Key

在 Claude Code 裡直接請它幫你產生：

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_你的主機名稱 -N "" -C "claude-code"

-N "" 是空密碼，這樣 Claude Code 才能非互動式地使用這把 key。ed25519 是目前推薦的演算法，比 RSA 更快更安全。

第二步：把公鑰加到主機

產生完會有兩個檔案：私鑰和 .pub 結尾的公鑰。把公鑰的內容複製起來，貼到你主機的 SSH 設定裡。

每家主機商的操作位置不同：

  • Kinsta — Dashboard → 站台 → SFTP/SSH → SSH Keys → Add SSH Key
  • Cloudways — Server → Security → SSH Keys
  • 自管 VPS — 貼到 ~/.ssh/authorized_keys

第三步：設定 SSH Config

這一步最關鍵。在 ~/.ssh/config 加上一組別名：

Host kinsta
  HostName 你的主機IP
  Port 你的SSH Port
  User 你的使用者名稱
  IdentityFile ~/.ssh/id_ed25519_你的主機名稱
  IdentitiesOnly yes

設完之後，ssh kinsta "whoami" 能成功回傳使用者名稱，就代表搞定了。

從這一刻起，Claude Code 只要執行 ssh kinsta "任何指令"，就等於在你的遠端主機上操作。

實際能做什麼？

設定好之後，你可以用自然語言請 Claude Code 做這些事：

網站維護

「幫我看一下遠端主機裝了哪些外掛，有沒有需要更新的。」

Claude Code 會執行 ssh kinsta "cd public && wp plugin list" 然後列出清單。需要更新就一句話搞定。

會員管理

「幫我搜尋這個 email 的會員帳號，如果是殭屍帳號就刪掉。」

它會用 wp user get [email protected] 查詢，確認角色和註冊時間，然後執行刪除。刪除前還會跟你確認。

除錯

「網站回報 500 錯誤，幫我查一下 error log。」

它會直接 SSH 進去看 log，分析錯誤訊息，可能還會順便找到問題根源。

資料庫操作

「幫我把所有草稿狀態超過一年的文章刪掉。」

ssh kinsta "cd public && wp post delete \$(wp post list --post_status=draft --format=ids --date_query='{\"before\":\"1 year ago\"}') --force"

你不需要自己寫這串指令。告訴 Claude Code 你要什麼，它會自己組出來。

批次作業

「把所有商品的 SEO 標題，從商品名稱改成『商品名稱 | 品牌名稱』的格式。」

這種手動要改幾百筆的工作，Claude Code 可以寫一段 WP-CLI 腳本一次跑完。

搭配其他工具更強大

SSH 只是基礎層。當你把其他工具也串起來，Claude Code 就變成一個完整的網站維運助手。

我們今天早上做的那個「清理殭屍帳號」的任務，實際流程是這樣的：

  1. 用 Google Workspace CLI 搜尋 Gmail 裡的退信
  2. 從退信內容裡提取出失敗的 email 地址
  3. 透過 SSH + WP-CLI 到遠端主機查詢對應的 WordPress 帳號
  4. 確認是殭屍帳號後刪除
  5. 用 Cloudflare API 建立 WAF 規則，防止未來的機器人註冊

五個步驟，跨了三個不同的服務。全部在 Claude Code 裡一氣呵成，我只需要描述需求和按確認。

先測試站，再正式站

能直接操作主機，不代表應該直接對正式站動手。

好的工作流程是這樣的：在 ~/.ssh/config 裡設定兩組別名——一組指向測試站，一組指向正式站。

Host staging
  HostName 測試站IP
  User ...
  IdentityFile ~/.ssh/id_ed25519_staging

Host production
  HostName 正式站IP
  User ...
  IdentityFile ~/.ssh/id_ed25519_production

日常操作的原則很簡單：改東西先在測試站跑，確認沒問題再到正式站執行。

跟 Claude Code 協作時也一樣。「幫我在測試站更新 WooCommerce 到最新版」，確認功能正常、沒有衝突之後，再說「正式站也更新」。外掛更新、PHP 版本升級、WP-CLI 批次腳本——任何可能影響網站運作的變更，都應該先過測試站。

有些操作例外。查 log、查會員資料、看外掛狀態這類唯讀操作，直接在正式站跑沒問題。刪殭屍帳號這種只影響特定資料的操作，確認對象正確後也可以直接執行。判斷的標準是：這個操作如果出錯，會不會影響到正在使用網站的人？ 會的話，先去測試站。

大部分主機商都提供一鍵建立測試站的功能。Kinsta 的 Staging Environment、Cloudways 的 Staging Area，都能從正式站複製一份完整的環境。還沒有測試站的話，強烈建議先建一個。

安全性考量

把 SSH 存取權交給 AI 工具，第一反應通常是「這樣安全嗎？」

幾個重點：

私鑰只存在你的本機。 Claude Code 跑在本機，SSH key 也在本機，沒有任何憑證被上傳到雲端。

每個指令都會顯示在 Terminal。 Claude Code 不會偷偷執行什麼。每一步操作你都看得到，破壞性操作（刪除檔案、刪除帳號）會先跟你確認。

可以限制 SSH 使用者權限。 大多數主機商的 SSH 帳號本來就不是 root。你在遠端能做的事有上限，Claude Code 也一樣。

建議用獨立的 SSH key。 不要共用你平常登入用的 key。獨立的 key 方便管理，要撤銷存取權只要刪掉那把 key。

測試站和正式站用不同的 key。 這樣即使你不小心在對話中搞混別名，也不會因為同一把 key 通行兩邊而造成意外。

常見問題

連線時一直要求輸入密碼怎麼辦？

確認 ~/.ssh/config 裡有加 IdentitiesOnly yes，而且 IdentityFile 路徑正確。如果主機端的公鑰沒加好，SSH 會 fallback 到密碼驗證。

適用哪些主機商？

任何支援 SSH 的主機都行。Kinsta、Cloudways、Linode、DigitalOcean、自架 VPS，甚至共享主機（如果有開 SSH）都可以。

WP-CLI 一定要有嗎？

不一定，但強烈建議。沒有 WP-CLI，Claude Code 還是能透過 SSH 操作檔案和跑指令。但有了 WP-CLI，它就能用結構化的方式管理 WordPress——查外掛、管使用者、操作資料庫，效率差很多。大部分主機商都有預裝 WP-CLI。

會不會不小心搞壞網站？

Claude Code 在執行破壞性操作前會先跟你確認。但更好的做法是養成習慣：有風險的變更先在測試站驗證。確保你的主機有自動備份，Kinsta 每天自動備份，大部分主機商也都有類似機制。真的出事可以回滾。

多個網站怎麼管理？

在 ~/.ssh/config 裡設定多組別名就好：

Host site-a
  HostName ...
  User ...
  IdentityFile ~/.ssh/id_ed25519_site_a

Host site-b
  HostName ...
  User ...
  IdentityFile ~/.ssh/id_ed25519_site_b

跟 Claude Code 說「連到 site-a 看一下外掛狀態」「連到 site-b 更新 WooCommerce」，它會自動用對應的別名。

跟 FTP / SFTP 差在哪？

FTP 只能傳檔案。SSH 能執行指令。Claude Code 需要的是在遠端「做事」，不只是搬檔案。用 SSH 它能跑 WP-CLI、看 log、改設定、重啟服務，這些 FTP 都做不到。

回頭看整個流程

設定 SSH key 本身不難，五分鐘的事。但它打開的可能性很大。

以前管 WordPress 網站，我得開 Dashboard 點來點去，或是 SSH 進主機自己打指令。現在我只要用中文跟 Claude Code 講一句話，它會自己決定該用什麼指令、怎麼組合、按什麼順序執行。

它不只是一個更快的 Terminal。它是一個理解你意圖、能跨工具協作的維運助手。而 SSH key，就是讓這一切成為可能的第一步。

職場應用

Claude Code x 製作商業簡報

第 5 篇，共 12 篇
↗ 全螢幕播放簡報

我們團隊每次寫完一篇文章，就會開始想：這個內容之後要對客戶提案、在內部分享，或拿去社群聚會上講。每一次都得重新打開簡報軟體，把文章的重點一段一段搬過去，調版型、對齊、改字級。

同一份內容做了兩次，結果文章改了，簡報忘了更新。

後來我們團隊找到了一種「網頁簡報」的做法——使用一套叫做 Marp 的工具，讓文章內容可以直接轉換成簡報，而且簡報的風格會自動跟官網一致。只要跟 AI 助手說一句「幫我做成簡報」，五分鐘後就有一份可以直接使用的簡報，還能嵌在文章頁面上讓讀者直接翻閱。

什麼是網頁簡報？

簡單來說，網頁簡報就是一份可以在瀏覽器裡播放的投影片。它看起來跟傳統簡報一模一樣——有封面、有內容頁、可以一頁一頁翻——但它本質上是一個網頁。Marp 就是把文字內容自動轉換成這種網頁簡報的工具。

Marp 官網首頁

這代表什麼？

  • 不需要安裝任何軟體。 用瀏覽器就能播放，不管是 Mac、Windows 還是手機都能看。
  • 可以直接嵌在網站上。 就像上面這份簡報，讀者不需要另外下載檔案，在文章裡就能翻閱。
  • 分享一個連結就好。 不用寄附件、不用擔心檔案太大、不用管對方有沒有裝 PowerPoint。

為什麼不繼續用 PowerPoint？

PowerPoint 或 Keynote 當然是好工具，但對我們團隊來說，有幾個痛點一直存在：

內容要做兩次。 文章寫完了，簡報還要再做一份。同樣的重點、同樣的結論，卻要手動搬到另一個工具裡排版。

品牌風格不一致。 每個人做的簡報長得都不太一樣。字體大小、顏色、間距，每次都要從頭調整。就算有範本，實際使用時還是會跑版。

更新很麻煩。 文章修改了，簡報也要跟著改。但通常改了文章就忘了簡報，結果兩邊的內容對不上。

網頁簡報解決了這三個問題。

一份內容，自動變成兩種形式

我們團隊的做法是這樣的：寫文章和做簡報用的是同一份內容來源。文章更新了，重新產生一次，簡報也跟著更新。不會再有「簡報跟文章對不上」的問題。

而且因為簡報的視覺風格是事先設定好的——用的是跟官網同一組品牌色、同一套字體——所以產出的簡報不需要額外調整，每一份都跟官網的風格一致。

不需要自己調顏色、不需要對齊文字、不需要煩惱排版。風格一致這件事，從設定好的那一刻起就自動完成了。

四種頁面風格，涵蓋所有場景

我們設計了四種頁面類型，基本上涵蓋了商業簡報會遇到的所有場景：

封面頁

深灰色背景搭配金色標題，置中排版。放上簡報主題和公司名稱。封面頁會自動隱藏頁碼，讓畫面乾淨俐落。

封面頁範例——深灰背景、金色標題、品牌識別

一般內容頁

白色底色的標準頁面，適合放條列重點、表格、引述等內容。左上角會顯示品牌名稱，右上角顯示公司全名，每一頁都有一致的品牌識別。

一般內容頁範例——白色底色、條列重點、品牌標示

深色強調頁

當你需要做章節分隔，或是有一段話特別重要想要強調時，可以切換到深色背景。標題會自動變成金色，整個畫面的視覺衝擊力明顯不同。

深色強調頁範例——深色背景、金色標題、視覺強調

結尾頁

最後一頁放公司資訊和 QR Code。掃描 QR Code 就能直接連到完整的文章頁面。QR Code 會在每次產生簡報時自動更新，不需要另外製作圖片。

結尾頁範例——公司資訊、服務項目、QR Code

AI 助手幫你完成所有事

這是整個流程最省力的部分。

我們團隊使用 Claude Code 作為 AI 助手。只要說一句「幫我把這篇文章做成簡報」，它就會自動完成以下所有步驟：

  1. 讀取文章內容 — 理解文章在講什麼、有哪些重點
  2. 拆分大綱 — 判斷哪些內容該放在同一頁，怎麼分頁最合理
  3. 精簡文字 — 把長段落濃縮成條列式的重點，去掉不適合放在投影片上的細節
  4. 套用品牌風格 — 自動使用我們設定好的視覺主題，加上公司名稱和頁碼
  5. 加入 QR Code — 最後一頁自動放上連結到文章的 QR Code
  6. 產生網頁簡報 — 輸出一份可以直接播放的簡報檔案

整個過程不需要打開任何設計軟體，也不需要手動調整任何排版。從一篇兩千字的文章到一份十五頁的簡報，大約五分鐘。

簡報內容的取捨原則

簡報跟文章最大的差異是空間限制。文章可以無限往下捲，但簡報的每一頁就是一個固定大小的畫面，超出的內容會直接被截斷。

幾個我們團隊摸索出來的原則：

  • 每一頁只講一個重點。 不要試圖把所有相關的事情塞在同一頁。
  • 條列項目控制在四到五個以內。 超過五個，觀眾根本記不住。
  • 表格不要超過五列。 太多列在投影片上根本看不清楚。
  • 塞不下就拆成兩頁。 不要縮小字體來硬塞更多內容。投影片的重點是「一眼看懂」，不是「放得下」。

AI 助手在幫你轉換時，也會自動遵循這些原則來安排內容。

可以匯出成其他格式嗎？

可以。Marp 本身就支援多種匯出格式，除了網頁簡報之外，同一份內容也能透過 Marp 直接轉換成：

  • PDF — 適合需要寄給客戶或列印的場合，畫面跟瀏覽器裡看到的完全一樣。
  • PowerPoint（PPTX） — 如果客戶堅持要 PowerPoint 格式也沒問題，不過自訂的視覺風格可能會有些微差異。建議優先使用 PDF。

不管匯出什麼格式，都是從同一份來源產生的，不需要額外製作。

如果你習慣用其他簡報工具呢？

Marp 是我們團隊的選擇，但不是唯一的選擇。如果你的團隊已經習慣用 PowerPoint、Keynote、Canva 或 Google Slides，現在也有對應的 AI 整合工具，同樣可以讓 AI 助手直接幫你製作簡報。

PowerPoint

Office-PowerPoint-MCP-Server 是一套開源的 AI 整合工具，讓 AI 助手可以直接建立和編輯 PowerPoint 檔案——新增投影片、插入圖表、調整格式，全部由 AI 完成。如果需要更精緻的成品，SlideSpeak 和 Plus AI 則是商業方案，支援自訂範本和更豐富的視覺效果。

Keynote

Mac 使用者可以試試 keynote-mcp，它讓 AI 助手透過 macOS 的自動化功能直接操控 Keynote，支援三十多種操作，包含建立簡報、新增投影片、插入圖片等。

Canva

Canva 官方已經推出了 AI 整合工具，可以讓 AI 助手直接在 Canva 裡建立設計、套用範本、搜尋素材，還能匯出成 PDF 或圖片。如果你的團隊本來就在用 Canva，這是最無痛的整合方式。

Google Slides

Google Workspace MCP 讓 AI 助手可以操作整個 Google 工作區，包含 Google Slides。Google 自己也推出了官方的 AI 整合方案，支援直接透過 AI 建立和修改簡報。

不管你選哪一套工具，核心概念都一樣：讓 AI 幫你處理排版和格式，你只需要專注在內容上。

常見問題

需要會寫程式才能用嗎？

不需要。整個流程是由 AI 助手完成的。你只需要會寫文章，然後告訴 AI 助手「幫我做成簡報」就好。所有技術上的事情——格式轉換、套用風格、產生檔案——都是自動完成的。

簡報可以離線播放嗎？

簡報本身可以離線播放，因為它是一個獨立的網頁檔案。但最後一頁的 QR Code 需要網路連線才能顯示。如果需要在沒有網路的環境使用，可以事先把 QR Code 圖片存到本地。

每一頁放不下所有內容怎麼辦？

拆成兩頁。不要試圖縮小字體來塞更多內容。簡報的核心原則是讓觀眾「一眼看懂」，而不是「把所有東西都放上去」。

文章更新了，簡報會自動更新嗎？

不是全自動，但非常簡單。文章修改後，只要再跟 AI 助手說一聲「重新產生簡報」，它就會根據最新的文章內容重新產生。因為來源是同一份，所以不會出現內容不一致的問題。

可以加入圖片嗎？

可以。但要注意投影片的畫面空間有限，圖片太大會擠壓文字的空間。建議一張投影片上如果有圖片，文字就少放一點，讓畫面保持清爽。

我們團隊目前的工作流程

最後整理一下：

  1. 寫完文章
  2. 跟 AI 助手說「幫我做成簡報」
  3. AI 讀取文章、整理大綱、套用品牌風格
  4. 最後一頁自動加上 QR Code
  5. 產生網頁簡報
  6. 簡報直接嵌在文章頁面上

整個過程不需要打開任何設計軟體，不需要手動排版，也不需要擔心品牌風格不一致。

對我們團隊來說，最大的改變是心態上的轉換：簡報不再是一個獨立的產出物，而是文章的延伸。寫完文章，簡報就自然而然地產生了。

職場應用

用 Claude Code 串接 Cloudflare Web Analytics API：自動產生每日流量報告

第 6 篇，共 12 篇

我們團隊的官網 codotx.com 部署在 Cloudflare Pages 上，流量分析用的是 Cloudflare Web Analytics——輕量、不需要 cookie、隱私友善，而且網站本來就掛在 Cloudflare 上，在 Dashboard 開啟就能用。

但每次要看數據都得登入 Dashboard 點來點去，不太方便。我們想在 Claude Code 裡直接查流量，甚至每天自動產生報告。這篇記錄整個串接過程，包括中間踩到的幾個坑。

Cloudflare Web Analytics Dashboard，顯示 codotx.com 的流量數據和 Core Web Vitals

建立 API Token

Dashboard 看數據當然可以，但我們想在 Claude Code 裡直接查詢。Cloudflare Web Analytics 的數據可以透過 GraphQL API 取得，不過需要一組有適當權限的 API Token。

第一個嘗試是用 wrangler CLI 的 OAuth token。結果不行——wrangler 的 token scope 不包含 analytics 相關權限。

需要另外建立一組 API Token。到 Cloudflare Dashboard → My Profile → API Tokens，選擇「查看分析與記錄」範本。

API Token 建立頁面，選擇「查看分析與記錄」範本

建立時有幾個重點：

  • 權限需要：區域 Analytics 讀取、帳戶 Account Analytics 讀取
  • 區域資源建議限定為特定網域，不需要開放整個帳戶的存取

API Token 權限設定，區域資源限定為 codotx.com

建立完成後，用 verify endpoint 確認 token 有效：

curl -s "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  -H "Authorization: Bearer YOUR_API_TOKEN" | jq '.success'

回傳 true 就表示可以用了。

用 GraphQL API 查詢流量數據

Cloudflare Web Analytics 的 API endpoint 是 https://api.cloudflare.com/client/v4/graphql。查詢需要三個參數：

  • Account ID：在 Cloudflare Dashboard 首頁或 wrangler whoami 可以找到
  • siteTag：用來識別網站的唯一標籤
  • 日期範圍：ISO 8601 格式

siteTag 的坑

這裡我們卡了一陣子。直覺上會以為 siteTag 就是 Dashboard 上給的 beacon token，但如果你用的是自動注入模式，Cloudflare 會分配一組不同的 siteTag。

用 beacon token 查詢，回傳空陣列。資料明明在 Dashboard 上看得到，API 卻拿不到。

解法是先不帶 siteTag 篩選，改用 requestHost 來找：

curl -s -X POST "https://api.cloudflare.com/client/v4/graphql" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "{ viewer { accounts(filter: {accountTag: \"YOUR_ACCOUNT_ID\"}) { rumPageloadEventsAdaptiveGroups(filter: {datetime_geq: \"2026-03-09T00:00:00Z\", datetime_leq: \"2026-03-10T23:59:59Z\", requestHost: \"codotx.com\"}, limit: 10, orderBy: [count_DESC]) { count dimensions { requestPath siteTag } } } } }"
  }'

這樣就能從回傳結果裡拿到實際的 siteTag。拿到之後，後續查詢就能直接用 siteTag 篩選了。

欄位名稱的坑

GraphQL schema 裡的欄位命名不太直覺。一開始我們用 path 查詢頁面路徑，結果噴 unknown field 錯誤。正確的欄位名稱是 requestPath。

類似的情況還有國家欄位要用 countryName、瀏覽器要用 userAgentBrowser。效能數據更是要用完全不同的 dataset——rumPerformanceEventsAdaptiveGroups 而不是 rumPageloadEventsAdaptiveGroups。

完整的查詢範例

以下是我們實際在用的查詢，一次拉回熱門頁面和國家分布：

{
  viewer {
    accounts(filter: {accountTag: "YOUR_ACCOUNT_ID"}) {
      topPages: rumPageloadEventsAdaptiveGroups(
        filter: {
          datetime_geq: "2026-03-09T00:00:00Z"
          datetime_leq: "2026-03-10T23:59:59Z"
          requestHost: "codotx.com"
        }
        limit: 20
        orderBy: [count_DESC]
      ) {
        count
        dimensions { requestPath }
      }
      topCountries: rumPageloadEventsAdaptiveGroups(
        filter: {
          datetime_geq: "2026-03-09T00:00:00Z"
          datetime_leq: "2026-03-10T23:59:59Z"
          requestHost: "codotx.com"
        }
        limit: 10
        orderBy: [count_DESC]
      ) {
        count
        dimensions { countryName }
      }
    }
  }
}

效能數據的查詢長這樣：

{
  viewer {
    accounts(filter: {accountTag: "YOUR_ACCOUNT_ID"}) {
      performance: rumPerformanceEventsAdaptiveGroups(
        filter: {
          datetime_geq: "2026-03-09T00:00:00Z"
          datetime_leq: "2026-03-10T23:59:59Z"
          siteTag: "YOUR_SITE_TAG"
        }
        limit: 1
      ) {
        count
        quantiles {
          pageLoadTimeP50
          pageLoadTimeP75
          pageLoadTimeP90
          pageLoadTimeP99
        }
      }
    }
  }
}

注意效能數據的單位是微秒，需要除以 1000 才是毫秒。

自動化每日報告

能從 API 拿到數據之後，下一步是自動化。我們寫了一個 shell script，每天早上用 cron job 執行，產生 markdown 格式的流量報告。

核心邏輯：

  1. 用 date -v-1d 取得昨天的日期作為查詢範圍
  2. 送出三個 GraphQL 查詢：總覽 + 來源 + 裝置 + 瀏覽器、頁面 + 國家、效能
  3. 用 jq 解析 JSON 回傳值，組合成 markdown 表格
  4. 儲存到 reports/YYYY-MM-DD.md

產生出來的報告長這樣：

# codotx.com 每日流量報告

**日期：** 2026-03-09

## 總覽

| 指標 | 數值 |
|------|------|
| 瀏覽量 (Pageviews) | 25 |
| 造訪數 (Visits) | 15 |

## 熱門頁面

| 頁面 | 瀏覽量 |
|------|--------|
| `/` | 18 |
| `/about/` | 2 |
| `/news/2026-03-09-claude-code-lsp-setup/` | 2 |

一開始我們用 Claude Code 的 /loop 指令來排程，設定每天早上 10 點自動跑報告。用起來很方便，但有個根本問題：/loop 的排程只存在於當前 session，Claude Code 關掉就沒了。對於每天要跑的任務來說不太實際，最後還是回到 cron job。

設定 cron job 的指令：

# 每天早上 10:03 執行
3 10 * * * /path/to/scripts/daily-report.sh >> /path/to/reports/cron.log 2>&1

reports/ 和 scripts/ 資料夾都加到 .gitignore，不進版控。

踩坑總結

整個串接過程遇到三個問題：

  1. wrangler OAuth token 權限不足 — 需要另外建立有 Analytics 讀取權限的 API Token
  2. siteTag 跟 beacon token 不同 — 自動注入模式下，Cloudflare 會分配不同的 siteTag，需要用 requestHost 反查
  3. GraphQL 欄位名稱不直覺 — path 要用 requestPath，效能數據要用不同的 dataset

從建立 API Token 到 cron job 跑出第一份報告，整個過程大約一個小時。大部分時間花在找 siteTag 和摸索 GraphQL schema 上。一旦搞清楚 API 的結構，後面的自動化就很順了。

職場應用

如何使用 Claude Code 自動產出 SEO 週報

第 7 篇，共 12 篇

經營技術部落格一段時間後，我們發現自己很少主動去看 Google Search Console。不是不想看，是每次都要登入後台、點來點去、手動比較數據，久了就懶了。但 SEO 數據其實藏著很多寶貴資訊——哪些關鍵字有人在搜、哪些頁面帶來最多流量、哪些主題值得寫更多文章。

所以我們決定：寫一個腳本，每週一早上自動從 GSC API 撈數據，產出一份 Markdown 週報，打開就能看。

我們想要的報告長什麼樣

動手之前先想清楚報告該包含什麼。我們定了四個區塊：

  1. 關鍵字排名 Top 20 — 哪些搜尋字詞帶來最多點擊
  2. 頁面導流排名 Top 15 — 哪些頁面是流量主力
  3. 內容機會分析 — 高曝光但低點擊的關鍵字，代表搜尋需求存在但我們的內容還沒接住
  4. 本週總覽 — 總點擊、總曝光、平均 CTR 等摘要數字

第三點是我認為最有價值的部分。一個關鍵字如果曝光 300 次但只被點了 1 次，要嘛排名太後面，要嘛標題不吸引人，要嘛根本沒有對應的文章。不管是哪種情況，都是可以改善的機會。

前置準備：用 gcloud 建立 API 存取

要從程式存取 GSC，需要一個 Google Cloud 的 Service Account。整個設定用 gcloud CLI 就能完成，不用進 Google Cloud Console 的網頁介面。

建立 GCP 專案

gcloud projects create codotx-gsc --name="Codotx GSC"

建議為這個用途開一個獨立專案，跟其他 GCP 資源分開管理。

啟用 Search Console API

gcloud config set project codotx-gsc
gcloud services enable searchconsole.googleapis.com

建立 Service Account

gcloud iam service-accounts create gsc-reader --display-name="GSC Reader"

下載金鑰

gcloud iam service-accounts keys create gsc-credentials.json \
  [email protected] \
  --project=codotx-gsc

這會在當前目錄產生一個 gsc-credentials.json，Python 腳本會用這個檔案來驗證身份。記得把它加進 .gitignore，千萬不要 commit 進版本庫。

# .gitignore
gsc-credentials.json

四個指令，API 端的設定就完成了。

在 GSC 後台授權 Service Account

API 端設好了，但 GSC 那邊還不認識這個 Service Account。需要到 Google Search Console 後台手動加一次。

進入 設定 → 使用者和權限，你會看到目前的使用者清單：

GSC 設定頁面

點「新增使用者」，輸入 Service Account 的 email：

[email protected]

權限選「限制」就夠了，我們只需要讀取數據。

Service Account 已加入 GSC

加完之後，使用者清單會多出 gsc-reader 這筆，狀態顯示為「限制」權限。到這邊，API 跟 GSC 的連線就建立好了。

撰寫查詢腳本

安裝 Python 套件：

pip3 install google-api-python-client google-auth

腳本的核心是透過 searchanalytics().query() 來查詢數據。這個 API 支援多種 dimension（query、page、date、country 等），可以根據不同維度來拆分數據。

我們對同一個日期範圍發了三次查詢：

# 1. 關鍵字排名（依點擊數排序）
keywords = query_gsc(service, start_date, end_date, ['query'], 50, 'clicks')

# 2. 頁面排名（依點擊數排序）
pages = query_gsc(service, start_date, end_date, ['page'], 30, 'clicks')

# 3. 內容機會（依曝光數排序，後續再篩選）
all_keywords = query_gsc(service, start_date, end_date, ['query'], 100, 'impressions')

第三個查詢拿到所有高曝光的關鍵字後，用條件篩選出「內容機會」。

一開始我們用固定門檻（曝光 >= 50 算高優先、>= 20 算中優先），但馬上發現問題：對一個新站來說，一週 50 次曝光的關鍵字可能根本沒幾個；等流量長起來後，50 次又變得不值一提。固定數字沒辦法適應不同規模的網站。

最後我們採用混合制——先設最低門檻過濾噪音，通過門檻的再用百分位數分級：

MIN_IMPRESSIONS = 20  # 週曝光低於 20 的直接忽略.

# 篩選：通過最低門檻，且 CTR 低於全站平均或排名低於全站平均.
qualified = [r for r in all_keywords if r['impressions'] >= MIN_IMPRESSIONS]
avg_ctr = sum(r['clicks'] for r in qualified) / sum(r['impressions'] for r in qualified)
avg_pos = sum(r['position'] for r in qualified) / len(qualified)

opportunities = [
    r for r in qualified
    if r['ctr'] < avg_ctr or r['position'] > avg_pos
]

# 用百分位數動態分級.
imp_values = sorted([r['impressions'] for r in opportunities])
p75 = percentile(imp_values, 75)  # 前 25% = 高優先.
p50 = percentile(imp_values, 50)  # 前 25%~50% = 中優先.

這個做法的好處是門檻會隨著網站流量自動調整。報告裡也會標出本週的實際門檻值，讓你知道「高優先」這週代表的是曝光幾次以上。

分級結果：

  • 高優先（曝光前 25%）— 搜尋量在你的網站中相對最大，值得專門寫一篇文章
  • 中優先（曝光前 25%~50%）— 有一定搜尋量，可以優化現有內容或在相關文章中補充
  • 潛力關鍵字（通過最低門檻但排名較後）— 早期訊號，持續觀察趨勢

報告日期範圍

報告自動計算「上週一到上週日」的完整七天：

days_since_monday = today.weekday()
last_monday = today - timedelta(days=days_since_monday + 7)
last_sunday = last_monday + timedelta(days=6)

這樣每週一執行時，拿到的永遠是上一個完整週的數據，不會有不完整的天數。

產出格式

最後把所有數據組成 Markdown 表格，寫入 reports/gsc-weekly-YYYY-MM-DD.md。選 Markdown 而不是 CSV 或 HTML，是因為在終端機、GitHub、筆記軟體裡都能直接閱讀，不需要額外工具。

完整腳本放在 scripts/gsc-weekly-report.py，手動執行一次確認沒問題：

python3 scripts/gsc-weekly-report.py

如果 API 連線正常，會看到：

Report generated: reports/gsc-weekly-2026-03-10.md

設定每週自動執行

腳本能跑了，最後用 cron 排程讓它每週一早上 10 點自動執行：

crontab -e

加入這行：

# codotx.com GSC 週報 - 每週一上午 10:00 執行
0 10 * * 1 /usr/local/bin/python3 /path/to/scripts/gsc-weekly-report.py >> /path/to/reports/cron.log 2>&1

注意幾個細節：

  • 用絕對路徑指定 python3 和腳本位置，cron 的 PATH 環境跟你的 shell 不一樣
  • 把 stderr 導到 log 檔，萬一執行失敗有紀錄可查
  • * * 1 的 1 代表星期一（0 是星期日）

報告實際長什麼樣

產出的週報會長這樣：

關鍵字排名：

#關鍵字點擊曝光CTR平均排名
1line flex message6976.2%4.7
2line user id 查詢61250.0%3.3
3flex message41163.4%6.8
4line login42961.4%6.9
5line notify 替代方案4557.3%4.2

內容機會分析：

篩選條件：週曝光 >= 20，且 CTR 低於全站平均或排名低於全站平均 本週門檻：高優先 >= 206 曝光、中優先 >= 76 曝光

高優先（>= 206 曝光，前 25%）：

關鍵字曝光點擊CTR排名
line notify34710.3%9.9
line login29641.4%6.9

中優先（76~205 曝光）：

關鍵字曝光點擊CTR排名
flex message11643.4%6.8
ai 圖像辨識網站7600.0%10.3

跟一開始用固定門檻的版本比，原本列出 18 個「機會」，混合制篩到只剩 7 個。數量少了但每個都更值得投入。例如「line notify」曝光 347 次但只被點了 1 次，排名在第 10 名左右，寫一篇完整教學搶進前 5 名，流量成長空間很大。而像「ai 圖像辨識網站」曝光 76 次、完全沒被點擊，代表有搜尋需求但我們沒有對應內容，是一個明確的內容缺口。

整體需要的工具

回顧一下，實現這個自動週報需要以下工具：

  • gcloud CLI — 建立 GCP 專案、啟用 API、建立 Service Account
  • Google Search Console — 在後台授權 Service Account 讀取權限
  • Python + google-api-python-client — 查詢 Search Analytics API、產出 Markdown 報告
  • cron — 每週一自動執行腳本

設定完成後，每週一早上報告就會自動出現在 reports/ 資料夾裡。不用登入任何後台，打開檔案就能看到上週的 SEO 表現和下一步該寫什麼文章。

對我們來說，這份報告最實用的部分是內容機會分析。它把「猜測讀者想看什麼」變成了「數據告訴你讀者在搜什麼」，寫文章的方向清楚很多。更進一步，每週一早上拿到報告後，我們會直接把內容機會丟給 AI，請它根據這些高曝光、低點擊的關鍵字來撰寫對應的文章。從數據採集到內容產出，整條流程都能在同一個早上完成。

職場應用

用 Claude Code Skill Creator 打造技術部落格寫作 Skill

第 8 篇，共 12 篇

我們團隊用 Claude Code 寫程式已經一段時間了，最近開始研究它的 Skill 機制——可以把特定的工作流程封裝成一份指令文件，之後只要觸發對應的 Skill，Claude 就會依照預設的規範執行任務。

我們第一個想做的 Skill 是「技術部落格寫作」。原因很直接：公司的技術文章產出頻率不高，每次寫都要重新跟 AI 溝通語氣、格式、禁用詞彙，效率不好。如果能把這些規範寫成 Skill，以後只要丟素材進去就能產出符合風格的初稿，應該能省下不少時間。

這篇記錄我們從零開始設計這個 Skill 的完整過程，包含中間踩的坑和迭代修正。

我們想要的效果

  • 丟入技術主題和背景素材，產出一篇符合公司風格的繁體中文技術文章
  • 文章語氣專業但不僵硬，有真實經驗的支撐
  • 自動遵守格式規範：正確的 frontmatter、檔案命名、圖片路徑
  • 避免 AI 味的寫法：「隨著…的發展」「賦能」「讓我們拭目以待」這類用語一律不出現

第一步：分析現有文章的風格

設計 Skill 之前，我們先分析了自己網站上幾篇文章的寫作模式。抓了三篇不同類型的文章來讀：

  1. Cloudflare Pages 預覽環境設定教學 — 踩坑紀錄型
  2. 與 AI 合作開發的四種方式 — 工具比較型
  3. 多巴胺開發 Dopamine Coding — 個人反思型

從這三篇歸納出幾個共同特徵：

  • 開場直接交代「我們要做什麼」或「發生了什麼事」
  • 用「我們」或「我」當主語，不用被動語態
  • 踩坑的描述帶有排查脈絡，不只是列出問題和答案
  • 結尾用具體清單或成果收束，沒有感性結語
  • 程式碼區塊只放讀者需要複製的部分

同時也讀了 content config 和 category 設定，確認 frontmatter 的格式要求。

第二步：參考 humanizer-tw

除了分析自己的文章，我們還參考了 GitHub 上的 humanizer-tw 這個 Skill。它專門處理中文 AI 寫作的去痕跡問題，把常見的 AI 味寫法分成八大類、19 個具體問題，每個都附上替換表和改寫範例。

這個 Skill 有幾個設計值得借鑑：

  • 系統化分類：不只是列一堆「禁用詞」，而是按類別整理（開場套話、互聯網黑話、翻譯腔、書面語過重等），方便 AI 逐項檢查
  • 「個性與靈魂」的概念：它指出「乾淨但無靈魂」的文字跟 AI 味重的文字一樣有問題。光是去除壞模式不夠，還要主動注入真實感
  • 品質評分機制：用五個維度各 10 分的方式自評，給 AI 一個具體的品質標準

不過 humanizer-tw 的語氣定位偏口語，像是「我覺得」「得想想」「聊一下」，這對個人部落格合適，但我們是公司技術部落格，需要再正式一些。

第一個坑：語氣太像個人部落格

第一版 Skill 寫完後，我們用三個測試案例跑了一輪：

  1. wp-env Docker 開發環境的踩坑紀錄
  2. Cursor vs Claude Code 的工具比較
  3. AI 時代接案公司轉型的反思

三篇都順利產出，格式正確、沒有 AI 套話。但讀完之後有個明顯問題：語氣太隨性了。

踩坑紀錄那篇出現了「光看那個 crash log 真的完全猜不到原因」，反思那篇寫了「玻璃心碎了一地」「快崩潰」。這些表達放在個人部落格完全沒問題，但放在公司的技術部落格就顯得不夠專業。

問題出在 Skill 裡的語氣指引。第一版寫的是「讓人覺得是一個真的工程師在跟你聊天」，這個定位太偏聊天了。

修正方式

我們重新定義了語氣定位：「專業技術文章，但讀起來不會想睡。」並且加了一張三欄語氣校準表，明確標出「太正式」「適當」「太隨便」的分界：

太正式適當太隨便
經由詳細的調查分析排查之後發現隨便 google 一下
予以高度重視我們很重視這個問題超在意的

還特別標注了一點：「我認為」在本部落格是適當的用語，不需要降到「我覺得」。這是跟 humanizer-tw 不同的地方。

修正後重跑三篇測試，語氣明顯改善。「光看那個 crash log 真的完全猜不到原因」變成了「一開始我們沒有馬上聯想到是架構相容的問題」，「玻璃心碎了一地」變成了「這個問題困擾了我好一段時間」。專業但不死板。

第二個坑：AI 寫作問題沒有系統化分類

第一版 Skill 有列禁用清單，但只是把所有禁用詞和句型混在一起。AI 在執行時容易遺漏，因為沒有分類就沒有逐項檢查的依據。

參考 humanizer-tw 的做法後，我們把 AI 寫作問題整理成八大類、19 個具體問題：

  1. 開場白與連接詞（3 個）：時代開場白、共識開場白、連接詞濫用
  2. 互聯網黑話（2 個）：商業術語、動詞術語
  3. 翻譯腔（3 個）：「這是一個…」結構、「的」字堆疊、被動語態
  4. 書面語過重（2 個）：書面代詞、介詞結構
  5. 公式化結構（2 個）：三段式公式、否定式排比
  6. 結尾套話（2 個）：展望類、反思類
  7. 語氣問題（3 個）：過度正式、缺乏觀點、絕對詞
  8. 節奏問題（2 個）：句子長度單一、過渡詞依賴

每個類別都附上替換表或改寫範例，讓 AI 有明確的對照可以參考。

第三個坑：光去除 AI 味不夠

這個問題是從 humanizer-tw 的「個性與靈魂」段落得到的啟發。即使文字通過了所有 AI 味檢查，如果每句話都正確但沒有觀點、沒有轉折、沒有真實經驗的痕跡，讀起來還是像機器寫的。

我們在 Skill 裡加了「缺乏靈魂的警訊」清單：

  • 每個句子長度和結構都相同
  • 沒有觀點，只有中立描述
  • 不承認不確定性或取捨
  • 全文沒有第一人稱
  • 讀起來像產品文件或新聞稿

以及七個「增添人味的技巧」：交代決策脈絡、加入具體數字、寫出轉折、帶入觀點、變化節奏、承認不確定性、對感受要具體。

最終成果

經過兩輪迭代，最終產出的 Skill 是一份約 300 行的 SKILL.md，包含以下模組：

  • 文章格式規範：frontmatter 格式、檔案命名規則、圖片路徑
  • 三種文章結構模板：踩坑紀錄、工具比較、觀點反思
  • 語氣定位：語氣校準表、開場和結尾的寫法指引
  • 人味注入指南：靈魂警訊清單、七個增添人味的技巧
  • 19 個 AI 寫作問題：八大類分類，附替換表和改寫範例
  • 品質評分：直接性、節奏、信任度、真實性、精煉度五個維度，各 10 分
  • 快速檢查清單：交付前的 11 項逐項確認

實際使用時，只要告訴 Claude Code「幫我寫一篇關於 X 的文章」，它就會自動載入這份 Skill，按照規範產出初稿。如果素材不足，它會主動詢問缺少的資訊，不會自己編造技術細節。

設計 Skill 的幾個心得

先分析再動手。 我們一開始就讀了自己的文章和別人的 Skill，這讓第一版的品質有一個不錯的起點。如果直接憑感覺寫，可能要多迭代好幾輪。

測試案例要涵蓋不同類型。 如果我們只測了踩坑紀錄，可能不會發現語氣在反思型文章中過於隨性的問題。三種模式各跑一篇，問題很快就浮現了。

語氣校準需要明確的邊界。 光說「專業但不僵硬」太模糊，AI 不知道邊界在哪。三欄對照表（太正式 / 適當 / 太隨便）比抽象描述有效得多。

去除 AI 味和注入人味是兩件事。 前者是刪掉壞的，後者是加入好的。只做前者會得到乾淨但無聊的文字。兩者都做，才能產出讀起來像真人寫的文章。

職場應用

Claude Code x 設計電子書閱讀體驗

第 9 篇，共 12 篇

我平常就有在使用電子書裝置來閱讀書籍。翻頁、調字體、換背景色、關掉瀏覽器下次自動接上——這些體驗一旦習慣了，回頭看網站上的文章就覺得少了點什麼。

捲動式的長頁面、旁邊的側邊欄、頂部的選單列，這些東西在「瀏覽」的時候很好用，但在「閱讀」的時候是干擾。於是我開始想：我們寫的這些 Claude Code 教學文章，是否也可以改用電子書的形式，提供給讀者更乾淨、沒有干擾的閱讀體驗？

加上這些文章散落在十個不同的網址，讀者想從頭讀到尾，得在不同頁面之間跳來跳去。讀起來像在翻一本被拆散的書。

我們決定把這些文章重新組裝起來，做成一本可以在網頁上直接翻頁閱讀的電子書。

電子書目錄頁，顯示書名、篇數、字數與預估閱讀時間

散落的文章，斷裂的閱讀

一般部落格的閱讀方式是這樣的：打開一篇文章，從頭捲到尾，看完了，回到列表頁，找下一篇，點進去，再捲一次。每篇文章之間沒有連結、沒有順序、沒有「上一篇 / 下一篇」的脈絡。

對於偶爾逛進來的讀者來說，這沒什麼問題。但對於想系統性學習的讀者，這個體驗很破碎。

他不知道應該先讀哪一篇。讀完一篇之後，也不確定下一步該看什麼。如果中間被打斷，下次回來得重新找到上次讀到的那篇文章——還不一定找得到。

我們想解決的，就是這個斷裂感。

像翻書一樣，一頁一頁讀

我們跟 Claude Code 描述了這個需求：想要一個獨立頁面，把十篇文章串成一本書，讓讀者可以像用 Kindle 一樣，一頁一頁往下翻。不是捲動，是真的翻頁——畫面上一次只顯示一頁的內容，點一下就翻到下一頁。

Claude Code 聽完之後，提出了一個跟專業電子書引擎相同的做法。它把所有文章的內容排列在一起，再根據螢幕大小自動切成一頁一頁的畫面。讀者看到的每一頁，剛好就是螢幕能容納的內容量。

最後做出來的閱讀器，有幾個讓我們滿意的細節。

翻頁手感。 在手機上左右滑動，或是點螢幕的左右兩側，就能翻頁。在電腦上用鍵盤的方向鍵也行。操作方式跟一般電子書 App 一樣直覺。

閱讀器的翻頁畫面，一次只顯示一頁內容

閱讀設定。 讀者可以自己調整文字大小、行高、背景顏色（白色、米色、深色）和字型。每個人對「好讀」的定義不同，把控制權交給讀者自己。

閱讀設定面板，可調整文字大小、行高、背景主題與字型

章節目錄。 左上角有一個目錄按鈕，點開後從螢幕左側滑出完整的章節列表。想跳到特定文章，直接點就能到。目前正在讀的那篇會特別標示出來。

側邊欄章節目錄，當前閱讀的文章會高亮顯示

自動記住進度。 關掉瀏覽器，下次再打開，會自動跳回上次讀到的那一頁。目錄頁的按鈕也會從「開始閱讀」變成「繼續閱讀」。

三個分類，一條閱讀路徑

十篇文章不是隨便排在一起的。我們把它們分成三個章節：

  • 基礎知識 — 為什麼要學 Claude Code、怎麼安裝
  • 職場應用 — 用 Claude Code 管理網站、做簡報、產報告、寫部落格
  • 實務技巧 — 進階設定、程式碼審查、開發環境優化

從「這是什麼」到「怎麼用在工作上」再到「怎麼用得更深」，讀者跟著目錄讀下去，就是一條從入門到進階的路徑。

這個順序是刻意設計的。我們發現，很多讀者對 Claude Code 感興趣，但不知道從哪裡開始。給他一份排好順序的閱讀清單，比丟十個連結給他有用得多。

發佈一本電子書，只需要一句話

對我們來說，這個電子書系統最有價值的地方，是它的管理流程幾乎沒有成本。

我只要跟 Claude Code 說有哪些文章要把它變成是書的內容，並請他自己幫我分類；如果要修改的話，我就直接口頭跟他講哪些文章要歸類於哪個分類底下，全部都可以用自然語言完成。

用自然語言請 Claude Code 把新文章加入電子書

更重要的是，電子書裡的內容跟原本的文章是同一份。我們更新了某篇文章的內容，電子書裡的那一章也會自動更新。不需要另外維護兩份內容，不會出現「文章改了但電子書忘了更新」的問題。

目錄頁會自動計算收錄了幾篇文章、總共多少字、預估閱讀時間。這些數字不需要手動更新，加了新文章之後它自己會算。

這套系統也不限於 Claude Code 這個主題。如果未來我們寫了另一個系列的文章——比如 WordPress 開發實戰——只要建立一份新的文章清單，就會自動產生另一本電子書，擁有完全相同的閱讀體驗。

從十篇文章到一本書

回頭看這件事，技術上的實作其實不是重點。重點是：我們把十篇各自獨立的文章，變成了一個有結構、有順序、有連貫閱讀體驗的產品。

讀者不需要在十個頁面之間跳來跳去。他打開這本書，從第一頁開始讀，隨時可以放下，下次回來繼續。讀完一個章節，自然接上下一個章節。就像讀一本真正的書。

而我們要做的，就是持續寫文章，然後把新文章的名字加進清單裡。

電子書會自己長大。

常見問題

電子書可以離線閱讀嗎？

目前不行，需要網路連線才能開啟。但只要頁面載入完成，閱讀過程中斷網也不會影響翻頁和設定操作。

手機上怎麼翻頁？

點螢幕右側是下一頁，左側是上一頁。也可以左右滑動。進入閱讀器時會有提示。

閱讀進度會自動儲存嗎？

會。關掉瀏覽器後再次開啟，會自動跳回上次讀到的頁面。目錄頁的按鈕也會從「開始閱讀」變成「繼續閱讀」。

可以調整閱讀的字體大小嗎？

可以。點右上角的設定按鈕，能調整文字大小、行高、背景顏色（白色、米色、深色）和字型。設定會自動記住。

文章更新後，電子書的內容會同步嗎？

會。電子書的內容跟原始文章是同一份，文章更新後重新部署就會自動同步，不需要額外維護。

我可以把電子書分享給朋友嗎？

可以。目錄頁右上角和閱讀器的設定面板裡都有分享按鈕。讀完最後一頁也會出現分享提示。

實務技巧

我為什麼不再用 IDE，改在終端機裡開發

第 10 篇，共 12 篇

我把 IDE 關掉了。現在打開電腦，只開 Warp 終端機，整天的開發工作都在裡面完成。

這不是為了追求極簡或懷舊。原因很單純：當 AI 寫程式的能力越來越強，我親手看程式碼的時間越來越少，那個佔據螢幕 80% 面積的程式碼編輯視窗，開始顯得多餘。

開發工具的使用歷程

在 AI 時代前，我都是使用 PhpStorm。PHPStorm 確實順手——跳到函式定義、儲存時自動格式化和檢查，這些功能讓開發效率提升不少。

進入 AI 時代後，我用了 Cursor 好幾個月。自動補全和聊天介面加速了不少開發流程。但用了一段時間，我發現自己還是需要理解程式碼的能力，最後回到 PHPStorm 搭配 Claude Code 的組合。

後來也試過 Google 的 Antigravity。除了免費額度以外，用起來跟 VS Code 差不多。直到某天我打開系統監控，發現 Antigravity 的記憶體佔用竟然到了 40 幾 GB。

40 幾 GB，只為了一個程式碼編輯器。

程式碼視窗還重要嗎？

這讓我開始重新思考一個問題：傳統 IDE 的設計核心是「程式碼」。整個介面以程式碼編輯器為主體，側邊欄、終端機、除錯面板都是輔助角色。

但我現在的開發流程已經變了。大部分時間我在跟 Claude Code 對話，描述需求、確認方向、審查它產出的結果。真正需要自己打開檔案逐行閱讀的時候，一天可能不到三成。

既然主要的工作模式是「對話 + 指令」，那為什麼不直接在終端機裡做？

改用 Warp 之後的工作流程

Warp 終端機的開發配置：分頁切換專案、左側檔案瀏覽、主對話視窗搭配終端機

我選了 Warp 作為主力終端機。用了幾週下來，整理出三個讓我回不去 IDE 的原因。

多專案管理靠分頁就搞定

我同時在跑好幾個專案。在 Warp 裡，每個專案就是一個 Tab。早上開工時，Warp 會把我開過的專案分頁都暫存起來，只要一啟動時，就是所有我目前手邊正在進行中的專案，每個 Tab 直接切到對應的專案目錄。要切換專案，Command + 數字鍵就到了。

不用像以前那樣開好幾個 IDE 視窗，每個視窗吃掉一大塊記憶體。

視窗分割讓對話和操作並行

Command + D 就能分割畫面。我常用的配置是左邊跑 Claude Code，右邊開一個終端機執行指令。如果需要同時監看 log 或跑測試，再切一個小視窗出來。

這跟 IDE 裡開 Terminal 的體驗完全不同。在 IDE 裡，終端機是被塞在底部的附屬品；在 Warp 裡，終端機就是主角，每個分割視窗都是平等的。我可以根據當下的需求，自由調整每個視窗的比例和用途。

檔案操作也不缺

真的需要瀏覽檔案結構的時候，Warp 左側也有目錄面板，點選就能開啟檔案。雖然不像 IDE 那樣有語法高亮和智慧提示，但對於偶爾需要確認檔案內容的場景來說夠用了。

這套做法適合誰

我不會說每個開發者都該丟掉 IDE。如果你的工作需要大量手寫程式碼、頻繁使用重構工具、依賴型別檢查和自動補全，IDE 依然是最好的選擇。

但如果你跟我一樣，日常開發有一大半時間在跟 AI 協作——描述需求、審查產出、下指令執行——那 IDE 裡那個大大的程式碼視窗，可能真的不是你最需要的東西。

Warp 的介面設計剛好反映了這個轉變：它以 AI 對話為主體，終端機操作為輔助。當你的工作流程本來就是「對話 + 指令」，這樣的配置比 IDE 順手得多。

實務技巧

幫 Claude Code 裝上 LSP：從文字搜尋升級到語意導航

第 11 篇，共 12 篇

我們團隊日常開發都用 Claude Code 作為 AI 程式助手。一般情況下它靠 Grep 和 Glob 搜尋檔案，對小專案來說夠用，但專案一大，每次找定義或追引用都要翻好幾輪文字搜尋，效率明顯下降。

後來發現 Claude Code 從 v2.0.74 開始支援 LSP（Language Server Protocol），裝上之後它就像拿到了 IDE 的「程式碼地圖」——跳轉定義、查引用、看型別，都是毫秒級回應。根據社群的測試數據，查詢速度從原本的 45 秒降到 50ms，快了將近 900 倍。

這篇整理我們實際安裝的過程，涵蓋 TypeScript / JavaScript、Python、PHP 三種我們最常用的語言。

LSP 是什麼？為什麼 Claude Code 需要它？

LSP 是微軟提出的通訊協定，讓編輯器和語言伺服器之間有統一的溝通方式。VS Code、Neovim 這些編輯器的「跳轉定義」「查找引用」功能，背後都是 LSP 在運作。

沒有 LSP 的 Claude Code 只能靠文字比對來理解程式碼。問它「這個函式定義在哪」，它得用 Grep 掃一遍檔案，碰到同名變數或字串就容易搞混。裝上 LSP 之後，它能直接跟語言伺服器溝通，拿到精確的型別資訊和符號位置。

裝完 LSP 後 Claude Code 會多出一個 LSP 工具，支援以下操作：

  • goToDefinition — 跳轉到符號定義
  • findReferences — 查找所有引用
  • hover — 取得型別資訊和文件說明
  • documentSymbol — 列出檔案中的所有符號
  • workspaceSymbol — 跨檔案搜尋符號

安裝前的準備

Claude Code 的 LSP 透過 Plugin 系統運作。安裝流程分兩步：先在系統上裝好語言伺服器的執行檔，再透過 Claude Code 的 /plugin 指令從官方市集 claude-plugins-official 安裝對應的 Plugin。

確認你的 Claude Code 版本在 v2.0.74 以上：

claude --version

TypeScript / JavaScript

TypeScript 用的是 vtsls（Vue/TypeScript Language Server），支援 .ts、.tsx、.js、.jsx、.mts、.cts 等副檔名。

安裝語言伺服器

npm install -g @vtsls/language-server typescript

用 pnpm 或 bun 也可以：

# pnpm
pnpm install -g @vtsls/language-server typescript

# bun
bun install -g @vtsls/language-server typescript

安裝 Claude Code Plugin

在 Claude Code 中輸入：

/plugin install typescript-lsp@claude-plugins-official

重啟 Claude Code 讓 LSP 伺服器生效。

Python

Python 用的是 Pyright，微軟開發的高效能靜態型別檢查器。

安裝語言伺服器

npm install -g pyright

安裝 Claude Code Plugin

/plugin install pyright@claude-plugins-official

重啟 Claude Code。

PHP

PHP 用的是 Intelephense，高效能的 PHP 語言伺服器，支援程式碼補全、定義跳轉、引用查找和即時診斷。

安裝語言伺服器

npm install -g intelephense

安裝 Claude Code Plugin

/plugin install php-lsp@claude-plugins-official

重啟 Claude Code。

驗證 LSP 是否正常運作

裝完之後怎麼確認有沒有成功？兩個步驟。

檢查 Plugin 狀態

在 Claude Code 中輸入 /plugin，切到 Installed 頁籤，確認你安裝的 Plugin 顯示 Status: enabled。

這是最常見的坑——Plugin 裝了但沒有啟用。如果狀態顯示 disabled，手動啟用：

claude plugin enable typescript-lsp

實際測試 LSP 工具

請 Claude Code 對一個具體的檔案執行 LSP 操作。例如在 TypeScript 專案中：

幫我用 LSP 的 hover 看一下 src/i18n/translations.ts 第 527 行第 14 個字元的型別資訊

如果 LSP 正常運作，你會看到回傳的型別定義，而不是「No LSP server available」的錯誤訊息。

也可以試試 documentSymbol，請 Claude Code 列出某個檔案的所有符號：

用 LSP 列出 src/i18n/translations.ts 的所有符號

正常的話會看到檔案中所有變數、函式、屬性的清單和行號。

常見問題排查

「No LSP server available」

最常見的原因有三個：

  1. 語言伺服器沒裝好 — 用 which vtsls、which pyright、which intelephense 確認執行檔在 PATH 中
  2. Plugin 沒啟用 — /plugin 檢查狀態，手動 enable
  3. 沒重啟 — LSP 伺服器需要在 Claude Code 啟動時載入，裝完 Plugin 後一定要重啟

環境變數 ENABLE_LSP_TOOL

部分版本的 Claude Code 需要手動啟用 LSP 工具。如果重啟後還是看不到 LSP 工具，在 ~/.zshrc 加上：

export ENABLE_LSP_TOOL=1

或是啟動時直接帶：

ENABLE_LSP_TOOL=1 claude

Plugin Errors 頁籤

/plugin 介面有個 Errors 頁籤，如果 LSP 伺服器啟動失敗，錯誤訊息會顯示在這裡。常見的錯誤是「Executable not found in $PATH」，代表語言伺服器的執行檔沒裝好或路徑不對。

實際開發中會觸發 LSP 的場景

裝上 LSP 之後，不需要特別下指令叫 Claude Code 去用它。在日常對話中描述需求，它會自己判斷該不該呼叫 LSP。以下是我們實際遇過的幾種情境。

改名重構：改一個變數，所有引用一起改

「幫我把 menuData 這個變數改名成 navigationData，所有引用的地方都要改到。」

沒有 LSP 的時候，Claude Code 會用 Grep 搜 menuData，但可能漏掉解構賦值的寫法，或是誤改到註解裡剛好出現的同名字串。有了 LSP，它會先用 findReferences 拿到所有真正引用到這個變數的位置，再逐一修改。

追蹤函式定義：這個函式到底在哪裡定義的？

「sanitize_text_field 這個函式是 WordPress 內建的還是我們自己寫的？幫我找到它的定義。」

Claude Code 會用 goToDefinition 跳到函式定義的位置。如果是專案內的函式，直接跳過去；如果是第三方套件或框架內建的，LSP 也會指向 node_modules 或 vendor 裡的原始碼。比起 Grep 搜出一堆 sanitize_text_field 的呼叫處，精確太多。

理解型別：這個參數到底接受什麼？

「getCollection 的回傳值是什麼型別？」

Claude Code 用 hover 查詢，直接拿到完整的型別簽名。在 TypeScript 專案裡特別有用——泛型嵌套幾層之後，光讀原始碼很難直接看出展開後的型別。LSP 會幫你把推導結果算好。

檢查誰在用這個 API：改動前的影響範圍評估

「我想改 CategoryNavigation 元件的 props 介面，幫我看看哪些地方有用到這個元件。」

findReferences 會列出所有引入和使用這個元件的檔案與行號。這比 Grep 搜元件名稱可靠，因為 Grep 會把 import 語句、註解、字串裡的提及全部撈出來，LSP 只回傳真正的程式碼引用。

掌握檔案結構：這個檔案裡有哪些函式和變數？

「列出 src/i18n/utils.ts 裡面所有 export 的函式。」

Claude Code 用 documentSymbol 取得檔案的完整符號清單，包含函式、變數、介面、型別別名，附帶行號。在閱讀不熟悉的程式碼時，這比從頭讀到尾快很多。

跨檔案搜尋：專案裡有沒有某個 class 或 function？

「專案裡有沒有叫 Pagination 的元件或型別？」

workspaceSymbol 會在整個專案範圍內搜尋符號名稱。跟 Glob 搜檔名不同，它搜的是程式碼裡的符號定義——同一個檔案裡定義了多個 class 或 function，它都能找到。

WordPress / PHP 開發：Hook 和 Filter 的追蹤

「woocommerce_checkout_order_processed 這個 action hook 在我們的外掛裡哪些地方有掛載？」

PHP 專案裝了 Intelephense 之後，findReferences 能精確找到 add_action 和 add_filter 中引用到的 hook 名稱，不會像純文字搜尋那樣把 do_action 的觸發點和 add_action 的掛載點混在一起。

重點整理

這些場景有個共通點：你不需要跟 Claude Code 說「請用 LSP」。正常描述你的需求，它會根據任務性質自動選擇用 Grep 還是 LSP。型別查詢、定義跳轉、引用追蹤這類需要語意理解的操作，它會優先走 LSP；純文字內容搜尋（例如找某段中文翻譯），它還是會用 Grep。

裝完 LSP 等於是讓 Claude Code 多了一組更精確的工具，它會自己判斷什麼時候該用。

參考資源

實務技巧

用 Claude Code 設計 AI 程式碼審查機制：以 Payload CMS 為例

第 12 篇，共 12 篇

用 AI 寫程式碼的時候，有一個容易被忽略的問題：AI 很擅長把功能做出來，但它不一定了解你用的工具有哪些「該注意但沒注意就會出事」的地方。

每個開源框架都有自己的一套使用建議。有些寫在官方文件的安全性章節，有些藏在效能調校的頁面，有些是社群踩過坑之後整理出來的。這些建議通常不影響功能是否能跑，但會影響上線之後會不會出問題 — 資料被未授權的人看到、頁面越來越慢、資料庫改版時資料不見了。

問題是，這些建議散落在不同地方，就算是有經驗的開發者也不一定每次都記得。AI 更不會主動幫你對照這些清單。

我們團隊一直有在使用 Claude Code 的 Command、Agent、Skill 三層架構來擴充開發流程，剛好可以用來解決這個問題：把框架的使用建議整理成結構化的檢查清單，讓 AI 寫完程式碼之後，自動根據這份清單逐項檢查。

這篇文章分享我們怎麼設計這套機制。我們用 Payload CMS（一個 Node.js 的開源後端框架）作為實際案例，但整套設計方法可以套用到任何框架或工具。

第一步：搞清楚你用的工具有哪些「該注意的事」

第一件要做的事不是寫程式，而是好好讀一遍你用的框架的官方文件。特別是跟上線部署、安全性、效能相關的章節。大部分成熟的開源工具都會把這些注意事項寫出來，只是散落在不同頁面，需要自己整理。

以 Payload CMS 為例，我們花了一些時間把官方文件翻過一輪，整理出三個需要特別注意的面向：

安全性 — Payload 在伺服器端提供了一組內部 API，方便開發者直接操作資料庫。但這組 API 有一個特性：預設不會檢查使用者的權限（官方文件有明確說明）。如果開發者沒有手動開啟權限檢查，任何人都可能透過這組 API 讀到不該看到的資料。另外，官方在 Preventing Abuse 和 Deployment 頁面分別列出了防暴力破解、跨站請求偽造防護、查詢深度限制等上線前該設定的項目。

效能 — Payload 在查詢資料時，可以自動帶出關聯的資料（例如查文章時順便帶出作者資訊）。這個功能很方便，但每多帶一層關聯，就多一輪資料庫查詢。官方文件（Depth、Select、Indexes）建議開發者明確控制要帶幾層、只取需要的欄位、對常查詢的欄位建立索引。開發時資料少感覺不出差異，上線後資料量一大就會明顯變慢。

資料庫變更安全 — 開發過程中經常需要修改資料結構（加欄位、改名稱、刪欄位）。Payload 處理欄位改名的方式比較特別：它不是直接改名，而是先把舊欄位刪掉再建一個新的（Migrations 文件）。這代表舊欄位裡的資料會直接消失。官方建議的做法是分階段處理：先加新欄位、把資料搬過去、確認沒問題、最後才刪舊欄位。

每個框架會有不同的注意事項。重點是從官方文件出發，有系統地整理，而不是等出了問題才回頭找原因。

第二步：決定審查的粒度和觸發時機

找出風險維度之後，下一個決定是：要做幾個審查指令？什麼時候觸發？

我們一開始的直覺是做一個大指令，把所有檢查項目塞在一起。但實際用了幾次之後發現兩個問題：第一，每次都跑全部檢查太慢也太浪費 token；第二，migration 的風險等級遠高於效能問題，混在一起報告時容易忽略真正危險的項目。

最後我們拆成兩類，共五個指令：

日常開發用 — commit 前跑：

  • /payload-check：自動偵測改了哪些檔案，只跑需要的審查
  • /payload-review：單獨跑安全性審查
  • /payload-perf：單獨跑效能審查
  • /payload-migrate：單獨跑 migration 審查

定期健檢用 — 每週跑：

  • /payload-audit：三個維度同時掃描整個 codebase

拆開的好處是日常開發不會被完整審查拖慢。改了一個 hook 就只跑安全性和效能審查，不需要等 migration 審查跑完。/payload-check 負責自動判斷該跑哪些，開發者不用記。

觸發時機我們選在 commit 之前。原因很實際：commit 前發現問題可以直接改，改完一起 commit，git history 乾淨。如果 commit 之後才跑，發現問題還要再改再 commit，多出一堆 fix commit。

第三步：用三層架構把知識和流程分開

這是整個設計中最關鍵的決定。Claude Code 提供三種機制：Command、Agent、Skill。

層級機制放什麼
Command.claude/commands/*.md入口點。接收使用者指令，決定啟動哪個 Agent
Agent.claude/agents/*.md執行者。定義審查流程：收集 diff → 讀取知識 → 逐項檢查 → 產出報告
Skill.claude/skills/*/SKILL.md知識庫。完整的 checklist、正確 / 錯誤程式碼範例、官方文件對應

為什麼要分三層？因為知識和流程的更新頻率不同。

Skill 裡的 checklist 會隨著框架版本更新而變（Payload v3 和 v4 的最佳實踐不一樣），但審查流程（收集 diff → 讀知識 → 檢查 → 報告）基本不會變。如果把 checklist 直接寫在 Agent 裡面，每次更新 checklist 都要同時改 Agent，改錯了連流程都壞掉。

分開之後，更新 checklist 只需要改 Skill 檔案，Agent 和 Command 完全不用動。

Command：保持精簡

Command 只需要一句話說明用途，加上指定啟動哪個 Agent。以 /payload-review 為例：

Run a Payload CMS SaaS security review on the current git diff.

Launch the `payload-saas-reviewer` agent to execute the review.

不要在 Command 裡寫具體的檢查步驟。Command 是入口，不是說明書。

Agent：定義流程，不存知識

Agent 定義審查的執行流程和輸出格式，但具體要檢查什麼則從 Skill 讀取。

## Workflow

1. Gather context — Run `git diff --staged` and `git diff`.
2. Load knowledge — Read `.claude/skills/payload-saas-review/SKILL.md`.
3. Identify scope — Determine which file types changed.
4. Read surrounding code — Never review in isolation.
5. Apply checklist — Work through each category in SKILL.md, CRITICAL first.
6. Report findings — Only report issues with >80% confidence.

關鍵是第 2 步：Agent 被指示去讀 Skill 檔案。這樣 Skill 更新了，Agent 下次執行自動就會用新的 checklist。

Agent 裡還有一個重要的設計：Noise Filter。我們要求 Agent 只報告信心度超過 80% 的問題，同類問題要合併（「3 個 collection 缺少 tenant filter」而不是 3 個獨立項目）。沒有這個過濾，審查報告會充斥大量低信心度的噪音，開發者很快就會忽略所有警告。

Skill：完整的知識庫

Skill 是整套機制的核心，內容最多也最重要。一份好的 Skill 檔案需要包含：

1. 分級的 Checklist

按嚴重程度分級：CRITICAL（必須封鎖合併）、HIGH（合併前修復）、MEDIUM（後續 PR 處理）、LOW（記錄備忘）。

不分級的 checklist 等於沒有 checklist — 開發者不知道哪些問題要優先處理。

2. 正確和錯誤的程式碼範例

每個檢查項目都配一組「錯誤寫法 → 正確寫法」的程式碼對照。光是描述規則不夠，Agent 需要具體的 pattern 才能準確辨識程式碼中的問題。

以 Payload 的 depth 控制為例：

// ❌ 沒有設定 depth，使用預設值，觸發不必要的關聯查詢
const posts = await payload.find({
  collection: 'posts',
})

// ✅ 明確設定最低必要的 depth，搭配 select 只取需要的欄位
const posts = await payload.find({
  collection: 'posts',
  depth: 1,
  select: { title: true, slug: true, category: true },
})

3. 官方文件對應

每條規則標註出處，例如「根據 Preventing Abuse 文件，maxLoginAttempts 必須設定」。這讓開發者可以自己去查原始文件，也讓 Agent 的建議更有說服力。

第四步：設計整合指令和全 Codebase 審計

日常開發有三個獨立的審查指令，但每次都要想「這次該跑哪個」很煩。所以我們做了 /payload-check — 它看 git diff 改了哪些檔案，自動決定該啟動哪些 Agent。

改了 migrations/ 或 collection 欄位定義 → 啟動 migration Agent。改了 payload.find() 相關的程式碼 → 啟動效能 Agent。改了 access control 或 auth 邏輯 → 啟動安全 Agent。多個維度同時觸發就並行跑。

另外一個問題是：diff 審查只看「這次改了什麼」，不會抓到已經存在的問題。三個月前寫的 collection 沒加 index，上週部署時忘記設定 maxLoginAttempts，這些不會出現在任何一次 diff 裡面。

所以我們做了 /payload-audit，同時啟動三個 Agent 掃描整個 codebase，產出一份按嚴重程度排序的完整報告。這個指令的 token 消耗較高（大約是單一 diff 審查的 5-10 倍），不建議每天跑，每週一次或上線前跑比較合理。

最終的開發流程：

寫完功能
    ↓
/payload-check     ← 自動偵測，只跑需要的審查
    ↓
有問題 → 修完再跑一次
沒問題 ↓
  git commit → push

每週再跑一次 /payload-audit 做全面健檢。

第五步：根據專案類型設計你自己的 Checklist

到目前為止，我們的範例都是 Payload CMS 的 SaaS 平台，安全審查重點放在 tenant 隔離和計費邏輯。但同樣的三層架構可以適用於任何專案類型。

你需要做的是：根據你的專案類型，設計對應的 Skill 檔案。Agent 和 Command 的結構幾乎不需要改，因為審查流程是通用的（收集變更 → 讀知識 → 逐項檢查 → 產出報告），只有知識庫的內容需要替換。

以下是幾種不同專案類型的 checklist 方向，供你參考。

電商網站

安全性的重點從 tenant 隔離轉移到交易安全：

  • 訂單存取控制 — 買家只能查看自己的訂單，API 層級是否有做 user.id === order.customer 的驗證
  • 價格信任邊界 — 結帳時的價格是從資料庫讀的還是前端傳來的？前端傳來的價格不能直接信任
  • 庫存 Race Condition — 兩個人同時購買最後一件商品，有沒有用 transaction 或 optimistic locking 處理
  • 付款 Webhook Idempotency — 金流通知重送時不能重複建立訂單或重複扣庫存

效能的重點在商品查詢和購物車：

  • 商品列表查詢 — 有沒有對分類、價格範圍、上架狀態加 index
  • 購物車計算 — 是每次都從 DB 撈完整商品資料，還是只取價格和庫存
  • 圖片處理 — 商品圖片有沒有做 resize 和 CDN 快取

內容管理網站

安全性聚焦在發布權限和公開 API：

  • 多層審核 — 編輯、審核者、管理員的權限邊界是否清楚
  • 草稿洩漏 — 未發布的草稿有沒有透過 API 曝光
  • 公開 API 的 Rate Limiting — 沒登入的請求有沒有做頻率限制
  • 檔案上傳 — 有沒有限制大小、格式、儲存路徑

效能重點在內容查詢和快取：

  • 公開頁面的快取 — 首頁、文章列表這類不常變動的頁面有沒有做快取
  • Rich Text 處理 — Lexical JSON 是在伺服器端轉 HTML 還是丟給前端處理
  • SEO 欄位 — sitemap 產生是即時運算還是定期快取

多語系網站

額外需要關注的維度：

  • 翻譯完整性 — 主語言有的欄位，其他語言是否也有對應內容
  • Locale Fallback — 缺少翻譯時的降級邏輯是否正確
  • URL 結構 — hreflang 標籤和實際路由是否對應

設計 Checklist 的原則

不管是哪種專案類型，設計 checklist 時有幾個原則：

  1. 從官方文件出發，不要靠直覺。每個框架的 production / security / performance 章節通常就有 80% 的答案
  2. 按嚴重程度分級。不分級的 checklist 就是一堆平等的待辦事項，開發者不知道哪些真的危險
  3. 附上程式碼範例。Agent 需要具體的 pattern 來辨識問題，光靠文字描述不夠精準
  4. 只放 AI 容易犯的錯。人類開發者會犯的低級錯誤（拼錯變數名）不需要放進來，那是 linter 的工作

完整的檔案結構

最後整理一下完整的檔案結構，方便你照著建：

.claude/
├── commands/
│   ├── payload-check.md      # 入口：自動偵測 + 啟動對應 Agent
│   ├── payload-review.md     # 入口：啟動安全 Agent
│   ├── payload-perf.md       # 入口：啟動效能 Agent
│   ├── payload-migrate.md    # 入口：啟動 migration Agent
│   └── payload-audit.md      # 入口：三個 Agent 並行掃全 codebase
├── agents/
│   ├── payload-saas-reviewer.md         # 安全審查流程
│   ├── payload-performance-reviewer.md  # 效能審查流程
│   └── payload-migration-reviewer.md    # Migration 審查流程
└── skills/
    ├── payload-saas-review/
    │   └── SKILL.md           # 安全知識庫（checklist + 範例）
    ├── payload-performance-review/
    │   └── SKILL.md           # 效能知識庫
    └── payload-migration-review/
        └── SKILL.md           # Migration 知識庫

如果你要替換成自己的框架，把 payload 換成你的框架名稱，修改 Skill 裡的 checklist 和程式碼範例就可以了。Agent 的 workflow 和 Command 的入口邏輯基本上可以直接複用。

設計完之後的感想

這套機制上線大約兩週，我們的感受是：它不會取代人工 code review，但確實補上了一個盲區。AI 寫程式碼的速度很快，但速度帶來的風險是容易略過框架特有的注意事項。這些注意事項寫在官方文件裡，但分散在各個頁面，就算是人類開發者也不一定每次都記得。

把這些知識整理成結構化的 checklist，讓 AI 在產出程式碼之後自己檢查一遍，比起每次人工逐項確認高效得多。發現的問題在 commit 前就修掉，不會帶到生產環境才爆炸。

如果你也在用 AI 輔助開發，不管是什麼框架，花幾個小時把官方文件的最佳實踐整理成 Skill 檔案，設計對應的 Agent 和 Command，長期來看絕對值得。

閱讀結束

恭喜你讀完了整本書！
覺得內容實用嗎？分享給你的朋友吧。

載入中...