先從大同電鍋說起

家裡的大同電鍋，煮好飯會「啪」一聲跳起來。你不用一直盯著它，聽到聲音再去盛飯就好。

用 Claude Code 寫程式時，常常也是這種情境：丟一個大任務給 Claude，它要跑個一兩分鐘。你轉頭去回 LINE、倒杯咖啡，結果忘了回來看，它早就做完在等你了。

如果 Claude Code 也能像電鍋一樣「啪」一聲提醒你，是不是很棒？這篇文章就用 Claude Code 新推出的 mods（模組） 功能，親手幫它裝上這個「電鍋跳起來」提醒。

Mods 是什麼？把它想成「手機殼」

Mod 就是一個小小的 JavaScript 或 TypeScript 檔案，會在你的 Claude Code 工作階段裡執行。就像給手機套個殼、貼個指環支架：手機還是那支手機，但用起來更順手。

它能做的事情主要有三種：

它的運作方式像工廠的輸送帶：事件（例如「Claude 要執行一個指令」、「一個回合結束了」）會依序經過你的 mod、其他外掛，最後才到 Claude Code 本身。你可以在自己那一站看一眼、改一下，或直接把件抓下來。

Mod 還能畫自己的介面，例如提示列上方的一條資訊帶、右側的面板、或一個彈出的小通知（toast）。需要 Claude Code 2.1.287 以上版本，預設就是開啟的。

動手做：「電鍋跳起來」提醒 mod

目標很簡單：Claude 做一件事超過 30 秒，做完時就彈出一個小通知。太短的任務不吵你，就像煩泡麵不需要開鐘一樣。

懶人做法：用說的就好

你不必先學 API。開啟 claude，貼上這段話：

幫我做一個 Claude Code mod，叫做 rice-cooker。
當主要回合花超過 30 秒才完成時，用 toast 彈出提醒：
「 飯煮好了！Claude 忙了 N 秒」。
子代理（subagent）的回合不要提醒。

Claude 會問你是否開啟「熱重載（hot reload）」，按允許。這回合結束後 mod 就生效了。之後想改成 60 秒、想換文字，繼續用說的就好。

自己動手：看懂背後怎麼運作

想知道 Claude 幫你寫了什麼，或想自己寫，只要四步。

1. 建立資料夾。一個 mod 就是一個普通的外掛（plugin）資料夾：

rice-cooker/
├── .claude-plugin/
│   └── plugin.json
└── hooks/
    ├── hooks.json
    └── rice-cooker.mjs

plugin.json 是外掛的身分證：

{
  "name": "rice-cooker",
  "version": "0.1.0",
  "description": "長任務完成時，像電鍋一樣提醒你。"
}

hooks.json 告訴 Claude Code 要載入哪個程式檔：

{ "modules": ["./rice-cooker.mjs"] }

2. 寫主程式。只要監聽「回合結束」這個事件，看花了多久，時間夠長就「啪」一聲：

// hooks/rice-cooker.mjs
const LONG_MS = 30_000; // 超過 30 秒才提醒

export function register(on) {
  on("turn.complete", async ($, e, next) => {
    const result = await next(e);        // 先讓 Claude Code 照常收尾
    if (e.agentId) return result;        // 子代理的回合不理它
    if ((e.durationMs ?? 0) >= LONG_MS) {
      const sec = Math.round(e.durationMs / 1000);
      await $.ui.toast({ text: ` 飯煮好了！Claude 忙了 ${sec} 秒` });
    }
    return result;
  });
}

這就是前面說的「觀察」：先呼叫 next(e) 讓事情照常發生，再回頭看一眼結果，完全不干擾 Claude 做事。

3. 載入測試。用這個外掛開一個工作階段：

claude --plugin-dir ./rice-cooker

資料夾會被監看，每次存檔就自動重載，不用重開。叫 Claude 跑個大一點的任務，例如「幫我整理整個專案的 README」，等它做完就會看到提醒。

4. 檢查一下。claude plugin validate 會讀你的程式，列出它掛了哪些事件、呼叫了哪些 API：

claude plugin validate ./rice-cooker

小提醒：$.ui.toast 的參數格式可能隨版本調整。Claude Code 每次載入 mod，都會把你這個版本的型別宣告寫進 .claude-plugin/types/，以那裡的定義為準。

進階玩法與四個好習慣

電鍋提醒只是開胃菜。照著同樣的套路，你還可以做這些：

• 油表「剩多少油」：用 $.session.usage() 讀出上下文用了多少，在提示列上方畫一條油表。官方範例 Token Weather 就是用「晴、陰、雨、暴風雨」來表示。
• 牆上的「小心地滑」：用 tool.call 攔截 rm -rf、git reset --hard 這類危險指令，先問你一句再執行。
• 團隊家規：用 prompt.submit 在每次提問自動附上團隊的程式風格規範。
• 自訂斜線指令：用 $.command.register 加一個 /午餐 之類的小指令。

寫 mod 時，有四個習慣會讓你少踩坑：

1. 資料放 $.state，不放一般變數。熱重載會重跑一次程式，普通變數會歸零，就像白板被擦掉。
2. 元件屬性在 e.props 裡，例如可用寬度 bodyColumns。
3. 以自動產生的型別為準，放在 .claude-plugin/types/，編輯器也能直接提示。
4. 畫不出來就看 log：用 claude --debug 開啟，找錯誤訊息。

做好了想分享？ mod 就是外掛，放到 GitHub 加上 marketplace 檔案，別人用三行指令就能安裝：

/plugin marketplace add your-name/my-mods
/plugin install rice-cooker@my-mods
/reload-plugins

反過來安裝別人的 mod 時要小心：mod 跟 Claude Code 有一樣的權限，安裝前先看過程式碼，只裝信任的來源。

結語：你想幫 Claude Code 加什麼？

官方的三個範例，各自來自一個問題：「我的上下文還剩多少？」「這個指令會刪掉什麼？」「Claude 剛剛改了哪裡？」我們的電鍋提醒也一樣，只是「做完了叫我一聲」。

下次用 Claude Code 覺得「要是能…就好了」，就是你的下一個 mod 題目。直接用中文跟 Claude 說，讓它幫你做出來。

參考資料：Getting started with Claude Code mods（claude.dev Blog，Addy Osmani，2026 年 10 月 1 日）

過去我們使用 AI 寫程式，最常做的事情大概就是問它：「這段 C# 能不能幫我重構一下？」

現在的 AI Coding 工具，已經開始負責閱讀整個專案、修改多個檔案、執行測試、操作 Git，甚至與其他 Agent 合作完成一個開發任務。

但企業真正需要的，並不是一個寫程式速度很快的 AI，而是一個能被控制、能夠追蹤、發生錯誤可以恢復，而且不會隨便把程式碼弄丟的 AI 開發助手。

2026 年 10 月 15 日（UTC），Anthropic 與 OpenAI 分別推出：

• Claude Code v2.1.301
• Codex CLI v0.163.0

這兩次更新有一個非常值得關注的共同方向：AI Coding 工具正逐漸從「互動式程式碼助手」，進化成「具有流程控制與安全機制的自主開發代理人」。

以下用實際開發情境，說明這次到底更新了什麼，以及 .NET 工程師該如何應用。

一、Claude Code v2.1.301：開始把「執行可靠性」當成重點

這次 Claude Code 沒有推出什麼令人眼花撩亂的新介面，但其中幾項功能，對長時間執行的 Agent 開發流程相當重要。

1. Git Worktree 保護：避免 AI 把未推送的程式碼清掉

如果使用 AI 同時處理多個 Issue，Git Worktree 是非常實用的技術。

例如同一個 ASP.NET Core 專案，需要同時處理：

• Issue #101：新增訂單查詢 API
• Issue #102：修復庫存計算錯誤
• Issue #103：重構 JWT 驗證

我們不希望三個 Agent 同時修改相同的工作目錄，因此可以利用 Git Worktree 建立彼此隔離的開發環境。

這次 Claude Code 修正了一個重要問題：透過 WorktreeCreate Hook 建立的 Worktree，在結束工作階段時，如果存在未推送的 Commit，先前可能會被直接移除，而沒有經過適當確認。

新版本修正了這個情況。

要注意，這項修正特別針對 Claude Code Hook 所建立的 Worktree，並不是宣稱所有 Git Worktree 操作都會自動備份。

實作範例：建立獨立工作目錄

在 Git Repository 目錄執行：

git worktree add -b feature/order-api ../OrderApi-feature
cd ../OrderApi-feature
claude

接著在 Claude Code 輸入：

請分析目前 ASP.NET Core 專案，新增訂單查詢 API，要求：

1. 保留現有架構與 Coding Style。
2. 使用 Dependency Injection。
3. 補上必要的 Unit Tests。
4. 修改完成後執行 dotnet test。
5. 提供 Git Diff 摘要。
6. 不要自行 Commit、Push 或刪除 Worktree。

這是一個非常典型的企業開發情境：讓 AI 執行工作，但不把版本控制的最終決策權完全交出去。

2. Workflow Agent 修正：避免「事情沒做完卻回報完成」

以前使用多代理人時，有時最麻煩的不是執行失敗，而是 Agent 明明沒有完成指定步驟，卻回報整個任務成功。

Claude Code v2.1.301 修正了一種 Workflow Agent 可能跳過步驟、但執行結果仍被視為成功的狀況。

這對企業自動化尤其重要。

例如，我們安排以下工作：

需求分析 → 程式開發 → 單元測試 → 安全檢查 → 產出報告

如果測試 Agent 跳過測試，卻讓整個流程呈現成功，後續 CI/CD 就可能將未驗證的程式碼交付出去。

這次修正降低了特定情境下發生誤報成功的風險。不過企業仍應自行建立驗收關卡，例如測試 Exit Code、測試報告存在性、Code Review 與必要的人工作業核准。

3. OpenTelemetry 加強：開始追蹤 Agent 為什麼執行工具

這是我認為此次非常值得企業關注的功能。

Claude Code 在 OpenTelemetry tool_decision 事件中，新增了：

第三個欄位需要設定 OTEL_LOG_TOOL_DETAILS=1，並搭配既有的 OpenTelemetry 匯出設定。

這讓企業可以進一步分析，Agent 的某次工具操作是如何被許可、限制或阻擋。

例如在 PowerShell 啟動 Claude Code 前：

$env:OTEL_LOG_TOOL_DETAILS = "1"
claude

此設定不會單獨啟用完整的 OpenTelemetry 匯出，仍需先依照官方文件完成 Telemetry 設定。

如果企業有 Azure Monitor、OpenTelemetry Collector 或其他監控平台，可以研究如何將 Agent 工具事件與應用程式 Trace 整合。

未來的 AI Agent 管理平台，除了觀察 Token 消耗、Latency 和 Error Rate，也需要知道：Agent 做了什麼、為什麼被允許執行，以及是否符合權限政策。

4. 無人值守任務：避免無止境等待使用額度恢復

新版新增環境變數：

`CLAUDE_CODE_RETRY_WATCHDOG_MAX_USAGE_LIMIT

對習慣使用 C#、ASP.NET Core 和 SQL Server 開發企業系統的工程師來說，投入 AI Agent 開發時，很容易產生一種錯覺：

「我已經把模型接進 Web API，也能呼叫工具、查詢資料庫，這應該算是一個完整的 Agent 專案了吧？」

但真正開始檢視系統設計，或準備在面試中介紹專案時，就會發現：

「能跑起來」、「值得寫進履歷」和「可以正式上線」，其實是三個不同的門檻。

一個展示用的 Agent，可以在順利的情境下完成任務；一個能展現開發能力的專案，必須說得清楚設計取捨；而一個能上線的系統，還必須面對權限、失敗、成本、監控與維運。

面試官不會只問你用了哪個模型、哪套框架。他更可能追問：

「這個需求為什麼要用 Agent？一般工作流程不行嗎？模型選錯工具怎麼辦？呼叫內部系統時，權限由誰檢查？文件改版後，知識庫怎麼更新？你怎麼證明這次調整真的讓效果變好？」

如果這些問題回答不出來，架構圖上放再多模型、資料庫和 Agent，也很難證明真正的工程能力。

從 .NET 工程師的角度來看，轉向 Agent 開發，不是把過去的後端經驗丟掉，而是把原本擅長的系統設計能力，延伸到一個「包含不確定性」的新環境。

一、先找出值得解決的問題，不要先決定「我要做一個 Agent」

開始專案之前，我會先問的，不是「要用哪套 Agent 框架」，而是：

「這個系統，究竟要幫誰減少哪一件麻煩的事？」

例如，企業員工申請費用報支時，可能需要先查制度、確認適用條件、檢查附件，再登入內部系統填寫資料。

這時候，可以考慮設計一個報支助理：協助查詢制度、整理申請條件、辨識缺少的資訊，並產生待確認的申請草稿。

但需求不能只寫成「使用 AI 提升報支效率」。還要繼續拆解：使用者最常卡在哪個步驟？哪些資料能取得？哪些判斷有明確規則？哪些操作需要本人確認？完成任務的標準是什麼？

對 .NET 工程師而言，這其實就是熟悉的需求分析與系統分析，只是多了一個必須判斷的問題：

哪些事情適合交給模型理解，哪些事情必須由程式保證？

理解使用者口語描述、整理文件內容，可以考慮交給模型；金額計算、資格判斷、資料驗證與權限控管，則應該由明確的規則與後端服務處理。

如果需求只是搜尋制度並附上來源回答，檢索加上生成可能就已經足夠，不一定需要自主規劃的 Agent。

專案的價值，不在於它被叫做什麼，而在於它是否解決了真實問題。

二、把 Agent 放進系統架構，而不是讓 Agent 取代系統架構

一個比較完整的 .NET Agent 專案，不應該只剩下：

「使用者輸入 → 呼叫模型 → 回傳答案。」

我會把它當成一套企業應用來設計。

ASP.NET Core Web API 負責接收請求、驗證身分與提供服務入口；應用服務負責管理任務流程、狀態與業務規則；模型存取層處理模型請求與回應；知識檢索層負責文件搜尋及來源資訊；工具層則透過受控介面，存取既有 ERP、EIP 或其他內部系統。

任務紀錄、操作結果與必要的稽核資料，也必須有適當的保存方式。

以報支助理為例，模型可以提出「需要查詢這位使用者的申請狀態」，但真正執行查詢的，仍然應該是經過授權的 C# 服務。

模型不能因為產生了一個員工編號，就自動取得該員工的資料；也不能因為生成了格式正確的參數，就被視為通過業務驗證。

模型負責提出下一步，系統負責決定這一步能不能做。

這正是後端工程師能發揮優勢的地方。

過去處理的介面、資料庫、權限、交易、例外、日誌與並行問題，並沒有因為加入大語言模型而消失。只是系統裡多了一個可能理解錯、判斷錯，也可能輸出不一致的元件。

因此，更需要清楚的責任邊界，而不是更少。

三、不是每個流程都需要 Agent，更不是 Agent 越多越厲害

如果一個流程已經很明確：

「提交申請 → 驗證欄位 → 檢查額度 → 產生單號 → 寫入資料庫。」

那就先把它當成一般業務流程來設計。

這些步驟既然有固定規則，就沒有必要每次都花 Token，請模型重新猜一次下一步要做什麼。

Agent 比較值得介入的地方，是任務路徑無法事先完全確定。例如，使用者只說：「幫我確認這筆出差費用還缺什麼，整理好後讓我送出。」

系統可能需要根據現有資訊，判斷要查哪份制度、讀取哪些申請資料、是否需要追問使用者，以及接下來該呼叫哪個工具。

這時候，模型的理解與動態選擇才有發揮空間。

但即使如此，最終的驗證、核准與寫入，仍然可以維持固定流程。

實務上值得考慮的設計，是讓 Agent 處理不確定的理解與選擇，讓傳統程式處理確定的規則與執行。

多 Agent 也是同樣的道理。

只有當任務真的需要不同專業、不同工具權限或可獨立處理的子任務時，才有理由拆分。否則，只是把一個難除錯的流程，變成好幾個互相傳話、一起難除錯的流程。

架構的成熟度，不取決於 Agent 的數量，而取決於每一個元件是否有存在的必要。

四、RAG 的重點，不是把文件塞進向量資料庫

如果履歷上的專案介紹只有：

「使用 Embedding 將文件向量化，搭配向量資料庫實現 RAG 問答。」

這比較像是在描述技術流程，還沒有說明你真正解決了什麼問題。

企業文件不一定乾淨、完整，也不一定只有一個版本。報支制度可能有附件、表格、例外條件，甚至同一項規定在不同年度有不同標準。

因此，RAG 的設計要從資料開始。

文件如何解析？表格中的金額與適用條件能不能保留關聯？切分後的段落是否失去前後文？每個片段能不能追溯到原始文件、章節、版本與生效日期？

接著才是檢索策略：關鍵字與向量搜尋如何搭配？召回多少內容？是否需要重排序？遇到不同版本互相衝突，該採用哪一份？

更重要的是權限。

使用者不能看的文件，就不應該先交給模型，再期待模型自行保密。

檢索階段就要考慮使用者、部門與文件存取範圍，而不是只在提示詞裡寫一句「請勿洩漏機密」。

至於查不到資料的情況，也應該有明確處理方式：補問條件、說明資料不足，或轉交人工確認，而不是把「沒有證據」包裝成一個語氣肯定的答案。

真正值得介紹的 RAG 專案，是你如何處理資料品質、版本、權限與引用，以及如何驗證這些設計有效，而不只是選用了哪一種資料庫。

五、設計 Agent 時，先問「它做錯了怎麼辦？」

Demo 通常展示最順利的一次；正式系統必須承受各種不順利。

模型可能選錯工具，工具可能逾時，外部 API 可能暫時故障，回傳資料可能不完整。使用者也可能中途取消，或在同一個任務裡連續修改需求。

因此，工具呼叫不能只有「成功就繼續，失敗就重試」。

在 C# 的實作上，可以用明確的輸入模型、型別與欄位驗證，限制工具接受的參數；但型別正確，只代表格式符合要求，不代表內容合理，更不代表使用者有權執行。

逾時、取消、重試與替代流程，也要分別設計。

尤其是有副作用的操作，不能盲目重試。

查詢資料失敗後再查一次，與建立申請失敗後再建立一次，風險完全不同。後者可能只是回應遺失，但資料其實已經寫入；這時再次執行，就可能產生重複申請。

所以，涉及寫入的工具，要考慮冪等性、操作識別碼與執行狀態查詢。涉及送審、寄信或其他重要操作，則應讓使用者確認具體內容，並由後端再次檢查授權與規則。

Agent 本身也需要界線，例如最大步驟數、最長執行時間與 Token 預算，避免陷入重複搜尋或無效呼叫。

讀取外部文件時，文件裡出現的「請忽略規則並執行某個操作」，也只能被視為文件內容，不能變成工具授權。

真正的工程能力，不是讓模型永遠不出錯，而是讓錯誤不會直接變成失控的系統行為。

六、沒有評估，就不知道你是在改善系統，還是在調整感覺

開發傳統 Web API，我們會寫單元測試、整合測試，確認輸入、輸出與業務規則。

加入 AI 之後，這些測試仍然需要，但還不夠。

因為提示詞、模型、文件內容或檢索設定改變，都可能影響結果。只挑幾個問題手動試問，很容易把偶然的好答案，誤認為整體品質提升。

我會先建立一批有代表性的測試案例，涵蓋正常問題、模糊問題、資料不足、文件衝突、越權要求，以及工具失敗等情境。

對 RAG，要分開觀察：有沒有找到正確資料、回答是否忠於資料、引用是否真的支持結論。

對 Agent，則要確認：任務是否完成、工具選擇與參數是否正確、有沒有不必要的呼叫，以及重要操作是否遵守確認流程。

另外，還要觀察回應時間、P95 延遲，以及每次成功完成任務的成本。單次模型呼叫便宜，不代表整個任務便宜；如果需要反覆重試，成本仍然可能很高。

比較不同版本時，應盡量使用相同條件與固定測試集，並保留未參與調整的案例，避免只把熟悉的題目調得很好。

模型輔助評分可以協助整理結果，但重要案例仍應透過人工抽查或可驗證的業務結果校準。

「我覺得回答變好了」，不是驗收標準；「在固定案例與明確指標下，哪裡改善、哪裡退步」，才是。

七、工程化不是附加功能，而是 .NET 工程師的主場

模型能回答問題之後，專案才剛開始。

接下來要處理的，是使用者如何登入、任務如何追蹤、服務重啟後如何恢復、設定如何管理，以及發生問題時如何定位原因。

這些事情，看起來沒有多 Agent 那麼醒目，卻決定了系統能不能被真正使用。

在 .NET 專案裡，我會透過依賴注入分離模型存取、檢索與業務工具，避免所有邏輯都塞進同一個 Controller。模型設定與提示詞也需要版本管理，才能知道某一次結果是由哪個版本產生。

長時間任務則要考慮持久化狀態與可靠的背景處理，而不只是把工作丟到背景就結束。任務做到一半服務重啟，究竟要繼續、重做，還是等待人工處理，必須有答案。

監控也不能只記錄「API 成功或失敗」。

一次任務可能包含多次模型呼叫、檢索與工具執行。需要透過一致的追蹤識別碼，把這些步驟串起來，才能知道時間花在哪裡、哪一步失敗，以及成本為何增加。

同時，日誌不能因為方便除錯，就無限制保存完整對話、個資與機密文件；紀錄範圍、遮罩與存取權限，也屬於設計的一部分。

至於 Redis、訊息佇列、Docker 或 Kubernetes，要依需求選擇，而不是為了讓履歷看起來豐富而全部加入。

工程化不是把技術堆滿，而是讓每一個重要行為都能被控制、追蹤、測試與維護。

八、第一個 .NET Agent 專案，應該怎麼落地？

我會選擇範圍明確、能取得資料，而且可以定義完成標準的場景，而不是一開始就做「什麼都能處理的企業助理」。

以前面的報支助理為例，第一版可以只完成：

查詢制度、讀取本人申請資料、辨識缺少資訊，以及產生待確認草稿。

先不讓它自動核准，也不開放任意 SQL 或任意系統操作。

接著，把流程拆成確定與不確定兩部分：由模型理解需求、選擇受控工具、整理說明；由 C# 服務處理查詢授權、資料驗證、計算與狀態管理。

完成主要路徑後，不是立刻增加更多 Agent，而是補上資料不足、檢索錯誤、工具逾時、使用者取消與重複提交等情境，再建立評估集與部署方式。

最後，整理能被驗證的成果，包括解決了什麼問題、為什麼採用這個架構、有哪些限制，以及測試結果如何。

對於確實完成上述功能的專案，履歷可以寫成：

使用 ASP.NET Core 與 C# 開發企業報支助理，整合制度文件檢索與既有系統 API，提供附來源的制度查詢、申請資訊檢查及草稿產生功能。將工具呼叫限制於授權服務，加入參數驗證、逾時控制與操作確認，並以固定測試集追蹤任務完成率、引用正確性、延遲與成本。

這段描述的重點不是名詞多，而是能讓對方看見你做了哪些設計、解決哪些問題，以及如何驗證。

若有改善數據，就附上實際量測結果與測試條件；沒有就不要編造。專案仍在 PoC 階段，也應清楚標示，不要把「設計上可部署」寫成「已正式上線」。

結語：轉向 Agent，不是離開後端，而是更需要後端思維

對 C#／.NET 工程師而言，投入 AI Agent 開發，不代表過去累積的技術突然失去價值。

恰恰相反，當模型可以參與判斷、選擇工具，甚至觸發業務操作時，介面設計、授權、資料一致性、錯誤處理與可觀測性，只會變得更重要。

一個值得寫進履歷的 Agent 專案，應該讓你清楚說明：為什麼做、為什麼這樣設計、模型與程式如何分工、失敗時如何處理，以及效果如何評估。

你不一定需要龐大的使用者數，也不一定需要複雜的多 Agent 架構，但必須對系統的行為、限制與結果有足夠理解。

Demo 證明模型在某些條件下做得到；工程化專案則要說明，系統如何穩定完成任务，又如何在做不到時安全停下來。

真正的 Agent 開發，不是替模型接上更多工具，而是把模型的不確定性，轉化成可以被驗證、管理與持續改善的服務。

這也是 .NET 工程師最值得帶進 AI 時代的能力。

做後端開發，談到 Redis，第一個想到的通常是快取：商品資料先放一份、Session 集中管理、熱門查詢少打幾次資料庫。

但當系統開始加入 AI 助理，新的問題出現了。

使用者前面才說要查台中門市，下一輪問「那今天還有貨嗎？」系統卻不知道「那」指的是哪一項商品。模型回答得很流暢，查到的卻是昨天的庫存。

站在 .NET 系統架構的角度，我更關心的是：每次呼叫模型之前，應用程式能不能把正確、最新，而且符合權限的資料準備好？

Redis 的 AI 能力，值得從這個問題開始理解。

模型負責理解與生成；應用程式必須負責提供可信的上下文。

先釐清：Redis 的 AI 能力有不同層次

「Redis 接入 AI」很容易讓人以為，只要升級資料庫，就會自動多出一個懂業務的助理。

實際上，可以分成資料檢索與上層服務來看。Vector Sets 提供原生向量集合操作；Redis Query Engine 則能在 Hash、JSON 資料上建立索引，組合向量、全文與結構化條件。兩者的操作方式與適用情境不同。Redis 向量索引說明

Redis Iris 則把 Agent Memory、LangCache、Context Retriever 與 Data Integration 組合成上下文服務，涵蓋記憶、語意快取、受治理的資料存取及資料同步。Redis Iris 官方文件

選型時，我會分別確認資料庫版本、部署方案及服務需求。支援某個向量命令，並不表示整套 Agent 記憶流程已經完成設定。

用餐飲 POS 來看：三種問題，需要三種資料

假設我們正在替連鎖餐飲系統開發 AI 客服。使用者可能問：

這三題都以自然語言提出，資料來源卻完全不同。

退款規則適合從知識庫找；口味偏好適合從記憶找；退款進度應查詢實際訂單。若把所有問題都丟進同一套向量搜尋，很容易找到「看起來相關、實際上不能作答」的內容。

因此，我會先設計問題分流，再決定 Redis 在各條路徑扮演什麼角色。

向量搜尋：先限定資料範圍，再找語意相近的內容

向量可以協助系統找到用詞不同、意思相近的內容。例如「外帶取消」與「撤銷取餐訂單」，不一定包含相同關鍵字，卻可能指向同一份規則。

如果只需要輕量的相似度查詢，可以評估 Vector Sets；若文件還要搭配門市、分類、日期或其他查詢條件，則可以評估 Query Engine。後者提供向量搜尋與 metadata 過濾，向量索引可依需求選擇 FLAT、HNSW 等演算法。Redis 向量搜尋文件

在多租戶系統中，我會讓後端從已驗證的身分取得租戶範圍，把必要的存取限制帶進檢索流程。不能讓使用者輸入一句「查另一家公司的文件」，就改變查詢權限。

資料範圍正確後，才有討論相似度與排序的意義。

Agent 記憶：保存對話，還要管理事實如何更新

Redis Agent Memory 區分會話與長期記憶。啟用相關功能後，可以在背景摘要較早的對話，並抽取值得保留的事實與偏好，形成可搜尋的長期記錄。Agent Memory 官方說明

但「存起來」只是起點。

使用者上個月偏好辣味，今天說最近想吃清淡一點，系統該採用哪一筆？他只是替朋友訂餐，這次選擇又該不該成為本人的長期偏好？

我的設計會讓記憶保留來源、時間與適用對象，並提供更正、刪除與失效機制。對會影響實際交易的資訊，還要有明確的確認程序。

此外，重要條件不能只靠向量搜尋「剛好找到」。應用程式必須明確載入的限制，就應作為固定業務條件處理。

語意快取：相似的問法，未必有相同答案

LangCache 的用途，是讓語意相近的請求有機會重用既有回答，減少重複生成。Redis Iris：LangCache

例如同一門市、同一版本規則下，「外帶怎麼取消？」與「取消外帶的流程是什麼？」可能適合共用答案。

但是「我的退款到了嗎？」與「他的退款到了嗎？」即使語意非常接近，也不能因此共用結果。

我會先定義哪些回答允許快取，再檢查租戶、權限、語言、政策版本與有效期限。即時訂單、庫存與個人交易狀態，則走業務查詢路徑。

衡量成效時，也不只看命中率。錯誤重用答案的比例、政策更新後的失效速度，以及整體回應延遲，都應一起觀察。

放進 ASP.NET Core，責任應該怎麼分？

我會把請求入口設計成以下流程：

1. 驗證使用者身分，取得租戶、門市與資料存取範圍。

2. 判斷問題需要政策文件、個人記憶，還是即時業務資料。

3. 對允許重用的問題檢查語意快取，其他問題直接進入檢索或服務查詢。

4. 將取得的資料連同來源、時間與必要限制，整理成模型上下文。

5. 產生回答；資料不足時，要求補充資訊或說明尚無法確認。

6. 依保存政策更新對話、候選記憶及允許快取的答案。

在程式結構上，我會把知識檢索、記憶存取、快取判斷與訂單查詢拆成不同服務介面，讓 Controller 保持簡單，也方便單獨驗證每個環節。

若涉及取消訂單、退款或修改資料，仍由應用服務驗證權限、狀態轉移與重複請求。模型可以協助理解使用者意圖，交易是否成立則必須由業務規則決定。

這樣一來，未來更換模型或檢索服務時，也不必重寫整套訂單邏輯。

導入前，我會先算清楚兩件事

第一件是記憶體。

以 1,536 維 FLOAT32 向量為例，單筆純向量資料是 1,536 × 4 = 6,144 bytes；一千萬筆約 61.44 GB，還沒計入索引、文件、metadata、副本與其他開銷。

即使採用更低位元表示，也不能直接把純向量的縮小比例，當成整個 Redis 執行個體的節省比例。容量規劃應以實際資料與查詢品質測試為準。

第二件是資料生命週期。

可重建的快取與需要保存的長期記憶，對淘汰、備份及復原有不同要求。我不會因為都能放進 Redis，就直接讓它們共用相同的容量與淘汰策略。是否拆成不同執行個體，要看資料重要性、負載與故障影響。

我會從一個能驗證的小場景開始

第一階段，我會選單一門市的政策問答：整理文件版本，建立檢索，再用一組固定問題檢查答案與來源是否一致。

第二階段，才針對穩定、重複的問法加入語意快取，同時測試「問法相近但答案不同」的反例。

等這些行為可預期後，再加入跨會話偏好與即時訂單工具。每增加一項能力，就驗證它對正確率、延遲與維運成本的影響。

從 .NET 架構師的角度看，Redis 在 AI 時代的價值，是讓我們多了一組管理上下文的工具。真正決定系統品質的，仍是資料來源、權限邊界、更新機制，以及每次回答前的判斷流程。

讓 AI 記得更多之前，先讓系統知道：哪些資訊值得記住、什麼時候必須更新，以及這一次回答到底能相信哪一份資料。

但若 AI 只能停留在聊天視窗中，它多半只能告訴你：

• 指令應該怎麼下
• 程式應該怎麼寫
• 系統應該怎麼部署
• 錯誤可能發生在哪裡

真正要讓 AI 參與開發、測試、部署與維運，就需要搭配 CLI 工具。

CLI 是 Command-Line Interface，命令列介面。透過終端機、PowerShell、Git、Docker、Python、Node.js，以及各種雲端 CLI，AI 才能把「建議」轉換為「可執行的工作流程」。

簡單來說：

聊天介面讓 AI 提供答案，CLI 則讓 AI 有機會把答案轉換成實際操作。

當開發環境準備完成後，AI 可以協助：

• 建立專案
• 建立資料夾與程式檔案
• 安裝開發套件
• 執行程式
• 執行測試
• 分析錯誤
• 修改程式
• 操作 Git
• 建立 Docker 容器
• 部署雲端服務
• 操作 Firebase
• 查詢資料庫
• 建立 CI/CD
• 撰寫 PowerShell 自動化腳本
• 分析系統 Log
• 重複執行、修正與驗證

這也是 AI Coding Agent、AI CLI、Vibe Coding 與 Agentic Development 的核心基礎。

一、什麼是 CLI？

CLI 是透過文字指令操作電腦、開發工具與雲端平台的介面。

例如，使用 Git 下載專案：

git clone https://github.com/example/project.git

使用 Docker 啟動服務：

docker compose up -d

登入 Azure：

az login

部署 Google Cloud Run：

gcloud run deploy

當 AI 開發工具具備 CLI 操作能力後，通常可以依照以下流程工作：

1. 理解使用者需求。
2. 檢查本機開發環境。
3. 建立專案與資料夾。
4. 安裝必要套件。
5. 產生程式碼與設定檔。
6. 執行建置。
7. 執行測試。
8. 分析錯誤訊息。
9. 修改程式。
10. 再次執行與驗證。
11. 建立 Git Commit。
12. 部署到測試或雲端環境。

因此，CLI 不只是工程師輸入指令的工具，也是 AI 與作業系統、開發工具及雲端平台之間的重要橋梁。

二、Windows 本機建議安裝的基礎工具

若要在 Windows 電腦上使用 AI 搭配 CLI，建議先安裝以下工具。

1. Windows Terminal

Windows Terminal 是 Windows 上的現代化終端機工具。

官方安裝說明：

https://learn.microsoft.com/zh-tw/windows/terminal/install

Windows Terminal 可以同時操作：

• PowerShell
• Command Prompt
• WSL
• SSH
• Azure Cloud Shell
• 各種 CLI 工具

Windows Terminal 可視為整個 CLI 開發環境的主要入口。

安裝完成後，可以從開始功能表開啟 Windows Terminal，並在不同分頁中分別執行：

• PowerShell
• Git
• Docker
• Node.js
• Python
• Azure CLI
• Google Cloud CLI

2. PowerShell 7

PowerShell 是 Windows 上非常重要的命令列與自動化腳本工具。

官方安裝說明：

https://learn.microsoft.com/zh-tw/powershell/scripting/install/install-powershell-on-windows?view=powershell-7.6

PowerShell 可以用來：

• 管理檔案與資料夾
• 安裝軟體
• 呼叫 REST API
• 控制 Windows Service
• 控制 IIS
• 建立部署腳本
• 建立備份腳本
• 建立排程工作
• 檢查網站健康狀態
• 分析 Log
• 操作 Git
• 操作 Docker
• 操作雲端 CLI
• 建立 CI/CD 腳本

確認 PowerShell 版本：

pwsh --version

啟動 PowerShell 7：

pwsh

PowerShell 特別適合以下環境：

• Windows Server
• IIS
• .NET
• SQL Server
• Active Directory
• 企業內部系統
• 自動部署
• 自動更新
• 系統維運

例如，AI 可以協助建立一支 PowerShell 腳本，自動完成：

1. 下載 GitHub 最新 Release。
2. 解壓縮檔案。
3. 停止 IIS。
4. 備份現有網站。
5. 保留 appsettings.json。
6. 更新程式。
7. 啟動 IIS。
8. 驗證網站狀態。
9. 失敗時自動還原。

3. Git

Git 是目前最重要的分散式版本控制工具之一。

官方網站：

https://git-scm.com/

Windows 使用者通常可以從 Git 官方網站下載 Git for Windows。

Git 可以用來管理：

• 程式碼版本
• 修改紀錄
• 分支
• Commit
• Tag
• Merge
• 衝突處理
• 程式碼還原
• 遠端 Repository
• 團隊協作
• CI/CD 觸發
• Release 版本

確認 Git 是否安裝完成：

git --version

查看目前 Git 設定：

git config --list

設定使用者名稱：

git config --global user.name "Your Name"

設定電子郵件：

git config --global user.email "you@example.com"

查看設定結果：

git config --global user.name
git config --global user.email

Git 的基本工作流程

Git 最常見的操作流程如下：

工作目錄
→ 暫存區
→ 本機 Repository
→ 遠端 Repository

查看目前修改狀態：

git status

將修改加入暫存區：

git add .

建立 Commit：

git commit -m "feat: add login feature"

推送到遠端：

git push

建立新的 Git Repository

在目前資料夾初始化 Git：

git init

加入所有檔案：

git add .

建立第一個 Commit：

git commit -m "Initial commit"

設定遠端 Repository：

git remote add origin https://github.com/owner/repository.git

推送至遠端：

git branch -M main
git push -u origin main

下載既有專案

Clone Git Repository：

git clone https://github.com/owner/repository.git

進入專案：

cd repository

查看目前分支：

git branch

取得最新版本：

git pull

建立功能分支

建立並切換到新分支：

git switch -c feature/add-login

較舊的寫法：

git checkout -b feature/add-login

完成修改後：

git add .
git commit -m "feat: add login feature"
git push -u origin feature/add-login

常見 Git 指令

查看 Commit 紀錄：

git log

以精簡格式查看：

git log --oneline

查看程式修改內容：

git diff

查看已暫存的修改：

git diff --staged

查看遠端 Repository：

git remote -v

切換分支：

git switch main

合併分支：

git merge feature/add-login

建立標籤：

git tag v1.0.0

推送標籤：

git push origin v1.0.0

Git 在 AI 開發中的重要性

AI 可以快速修改大量程式碼，但修改範圍越大，風險也越高。

因此，在讓 AI 操作專案前，建議先建立 Git Commit：

git status
git add .
git commit -m "chore: backup before AI changes"

AI 修改完成後，可以透過以下指令檢查差異：

git diff

若修改錯誤，可以使用 Git 還原。

還原單一檔案：

git restore path/to/file

取消暫存：

git restore --staged path/to/file

回到上一個 Commit 前，必須先確認是否會影響尚未保存的修改。

Git 對 AI 開發最大的價值包括：

• 保留 AI 修改前的版本
• 比較 AI 修改內容
• 快速找出錯誤
• 分批提交修改
• 容易進行程式碼審查
• 發生問題時可以還原
• 可與 GitHub、GitLab、CI/CD 整合

4. Docker Desktop

Docker 可以將應用程式與其執行環境封裝成容器。

官方下載：

https://www.docker.com/products/docker-desktop/

Docker 適合用來建立：

• PostgreSQL
• MySQL
• Redis
• RabbitMQ
• Nginx
• Elasticsearch
• Qdrant
• Milvus
• AI API
• Python 執行環境
• .NET 執行環境
• React 前端
• 測試環境
• 微服務架構

確認 Docker 是否安裝：

docker --version

確認 Docker Compose：

docker compose version

查看執行中的容器：

docker ps

查看所有容器：

docker ps -a

例如，使用 Docker 建立 PostgreSQL：

docker run --name postgres-dev `
  -e POSTGRES_USER=postgres `
  -e POSTGRES_PASSWORD=YourPassword `
  -e POSTGRES_DB=appdb `
  -p 5432:5432 `
  -d postgres

AI 可以協助產生：

• Dockerfile
• docker-compose.yml
• Volume
• Network
• Health Check
• 環境變數
• 多階段建置
• 正式環境映像檔
• 容器啟動腳本

5. Node.js

Node.js 是 JavaScript 與 TypeScript 的執行環境。

官方網站：

https://nodejs.org/zh-tw

Node.js 常用於：

• React
• Vue
• Angular
• Next.js
• Nuxt
• Vite
• Three.js
• Express
• NestJS
• MCP Server
• AI CLI
• 自動化工具
• 前端建置

確認 Node.js：

node --version

確認 npm：

npm --version

建立 Vite 專案：

npm create vite@latest

安裝套件：

npm install

啟動開發環境：

npm run dev

建立正式版本：

npm run build

AI 可以透過 Node.js CLI 協助：

• 建立 React 專案
• 安裝 UI 套件
• 建立 API
• 建立 Three.js 場景
• 執行 ESLint
• 執行測試
• 建立 Production Build
• 分析 npm 安裝錯誤

6. Python 或 Anaconda

Python 是 AI、機器學習、資料分析、自動化與後端 API 常用的程式語言。

Python 官方下載：

https://www.python.org/downloads/

Anaconda 下載：

https://www.anaconda.com/download

Python 常見用途包括：

• OpenAI API
• Azure OpenAI
• RAG
• Embedding
• 向量資料庫
• 機器學習
• 深度學習
• OCR
• Whisper
• YOLO
• 資料分析
• Excel 處理
• 網頁爬蟲
• FastAPI
• Flask
• 自動化腳本

確認 Python：

python --version

確認 pip：

pip --version

建立虛擬環境：

python -m venv .venv

啟用虛擬環境：

.\.venv\Scripts\Activate.ps1

安裝套件：

pip install fastapi uvicorn openai

輸出套件清單：

pip freeze > requirements.txt

安裝專案套件：

pip install -r requirements.txt

Anaconda 則特別適合：

• Jupyter Notebook
• 資料科學
• AI 模型研究
• 多 Python 環境管理
• 機器學習套件管理
• 教學與實驗環境

三、如果要建立雲端服務

若希望 AI 協助建立或部署雲端服務，應安裝對應平台的官方 CLI。

1. Google Cloud CLI

官方網站：

https://cloud.google.com/cli

Google Cloud CLI 的主要指令為：

gcloud

可操作：

• Cloud Run
• Compute Engine
• Cloud Storage
• Cloud SQL
• Google Kubernetes Engine
• Artifact Registry
• Secret Manager
• Cloud Functions
• IAM
• Service Account
• VPC
• Load Balancer

登入 Google Cloud：

gcloud auth login

查看帳號：

gcloud auth list

查看專案：

gcloud projects list

設定預設專案：

gcloud config set project YOUR_PROJECT_ID

查看目前設定：

gcloud config list

設定預設區域：

gcloud config set run/region asia-east1

部署 Cloud Run：

gcloud run deploy

AI 可以根據需求協助：

1. 建立 Google Cloud 專案。
2. 啟用相關 API。
3. 建立 Artifact Registry。
4. 建立 Docker Image。
5. 推送映像檔。
6. 建立 Cloud Run。
7. 設定 Secret Manager。
8. 設定環境變數。
9. 設定自訂網域。
10. 建立自動部署腳本。

2. Firebase CLI

官方文件：

https://firebase.google.com/docs/cli?hl=zh-cn

Firebase CLI 通常透過 npm 安裝：

npm install -g firebase-tools

確認版本：

firebase --version

登入：

firebase login

查看專案：

firebase projects:list

初始化 Firebase：

firebase init

切換專案：

firebase use PROJECT_ID

部署：

firebase deploy

Firebase CLI 可管理：

• Firebase Hosting
• Firestore
• Authentication
• Cloud Functions
• Storage
• Emulator
• Remote Config
• App Hosting
• Security Rules

AI 可以協助建立：

• firebase.json
• Firestore Rules
• Storage Rules
• Functions 專案
• Hosting 設定
• Emulator 設定
• CI/CD 部署流程

3. Azure CLI

官方安裝說明：

https://learn.microsoft.com/zh-tw/cli/azure/install-azure-cli?view=azure-cli-latest

Azure CLI 的主要指令為：

az

登入 Azure：

az login

查看訂閱：

az account list --output table

設定訂閱：

az account set --subscription "訂閱名稱或訂閱 ID"

建立 Resource Group：

az group create `
  --name DemoResourceGroup `
  --location eastasia

Azure CLI 可操作：

• App Service
• Azure Functions
• Container Apps
• Azure Kubernetes Service
• Azure SQL
• PostgreSQL Flexible Server
• Storage Account
• Key Vault
• Azure OpenAI
• Virtual Machine
• Azure Container Registry
• Application Insights
• Azure Monitor
• Service Bus
• Redis

AI 可以根據需求產生：

• 建立資源腳本
• 更新部署腳本
• 環境變數設定
• Key Vault 設定
• 網路安全設定
• Application Insights 監控
• 刪除測試環境腳本

四、資料庫工具

AI 應用通常需要儲存：

• 使用者資料
• 系統設定
• 對話紀錄
• 文件索引
• Embedding
• 分析結果
• 操作 Log
• 任務狀態
• 權限資料
• AI Agent 執行紀錄

因此，資料庫也是 AI CLI 開發環境的重要部分。

1. PostgreSQL

下載網址：

https://www.enterprisedb.com/downloads/postgres-postgresql-downloads

PostgreSQL 適合：

• 企業管理系統
• SaaS
• AI 應用
• RAG
• JSON 資料
• 全文檢索
• 地理資訊
• 向量搜尋
• 多租戶系統

搭配 pgvector 後，PostgreSQL 也可以儲存與搜尋 Embedding。

確認 PostgreSQL CLI：

psql --version

連線本機 PostgreSQL：

psql -h localhost -U postgres

指定資料庫：

psql -h localhost -U postgres -d appdb

建立資料庫：

CREATE DATABASE ai_demo;

查看資料庫：

\l

查看資料表：

\dt

離開：

\q

2. pgAdmin

官方網站：

https://www.pgadmin.org/

pgAdmin 是 PostgreSQL 的圖形化管理工具，可用來：

• 建立資料庫
• 建立資料表
• 執行 SQL
• 管理帳號
• 管理權限
• 查看連線
• 備份
• 還原
• 查看效能

CLI 適合自動化，pgAdmin 適合視覺化管理，兩者可以搭配使用。

3. SQLite

官方網站：

https://www.sqlite.org/

SQLite 是輕量級嵌入式資料庫，不需要獨立資料庫伺服器。

適合：

• 桌面程式
• 手機 App
• 小型系統
• 單機工具
• PoC
• 快速雛型
• 開發測試
• 本機 AI 工具
• 小型 RAG

資料通常儲存在單一檔案中，例如：

app.db

開啟資料庫：

sqlite3 app.db

查看資料表：

.tables

查看資料表結構：

.schema users

離開 SQLite：

.quit

4. DB Browser for SQLite

官方網站：

https://sqlitebrowser.org/

DB Browser for SQLite 可以透過圖形化介面：

• 開啟 SQLite
• 查看資料表
• 編輯資料
• 執行 SQL
• 匯入 CSV
• 匯出 CSV
• 查看索引
• 修改資料表結構

當 AI 產生 SQLite 專案後，可以使用 DB Browser 驗證資料是否正確。

五、版本控制與遠端平台 CLI

Git、GitHub CLI 與 GitLab CLI 是不同層級的工具。

可以簡單理解為：

GitHub CLI 與 GitLab CLI 不能取代 Git。

一般情況下，應先安裝 Git，再安裝 GitHub CLI 或 GitLab CLI。

1. Git

官方網站：

https://git-scm.com/

Git 負責：

• Clone
• Add
• Commit
• Pull
• Push
• Branch
• Merge
• Tag
• Diff
• Restore

例如：

git clone https://github.com/owner/repository.git
git switch -c feature/new-page
git add .
git commit -m "feat: add new page"
git push -u origin feature/new-page

2. GitHub CLI

官方網站：

https://cli.github.com/

GitHub CLI 的主要指令是：

gh

登入 GitHub：

gh auth login

查看登入狀態：

gh auth status

建立 Repository：

gh repo create

下載 Repository：

gh repo clone owner/repository

建立 Issue：

gh issue create

查看 Issue：

gh issue list

建立 Pull Request：

gh pr create

查看 Pull Request：

gh pr list

查看 GitHub Actions：

gh run list

查看執行結果：

gh run view

查看失敗 Log：

gh run view --log-failed

GitHub CLI 可讓 AI 協助：

• 建立 Repository
• 建立 Issue
• 建立 Pull Request
• 查看 Review
• 分析 GitHub Actions
• 下載 Release
• 建立 Release
• 管理 Workflow
• 管理 GitHub 專案

3. GitLab CLI

GitLab CLI 發布頁：

https://gitlab.com/gitlab-org/cli/-/releases

GitLab CLI 的主要指令為：

glab

登入 GitLab：

glab auth login

GitLab CLI 可以連線：

• GitLab.com
• 自建 GitLab Server

查看 Issue：

glab issue list

建立 Issue：

glab issue create

查看 Merge Request：

glab mr list

建立 Merge Request：

glab mr create

查看 Pipeline：

glab pipeline list

查看 CI 狀態：

glab ci status

GitLab CLI 可讓 AI 協助：

• 建立 Issue
• 建立 Merge Request
• 查看 Pipeline
• 建立 Release
• 分析 CI/CD
• 操作自建 GitLab
• 管理專案工作流程

需要注意：

GitLab CLI 負責管理 GitLab 平台，真正執行 CI/CD 工作的元件仍是 GitLab Runner。

六、AI 搭配 CLI 可以做哪些事情？

1. 建立網站專案

提示詞範例：

請使用 Vite 建立 React TypeScript 專案。

需求：
- 使用 React
- 使用 TypeScript
- 使用 Tailwind CSS
- 建立首頁
- 建立登入頁
- 建立後台 Dashboard
- 使用 React Router
- 安裝套件
- 執行 npm run build
- 修正所有建置錯誤

AI 可以協助執行：

npm create vite@latest
npm install
npm install react-router-dom
npm run build

並建立：

• React 元件
• 路由
• 表單
• Dashboard
• API Service
• CSS
• 環境變數

2. 建立 Python API

提示詞範例：

請建立一個 Python FastAPI 專案。

需求：
- 提供健康檢查 API
- 提供使用者登入 API
- 提供 AI 問答 API
- 使用 SQLite
- 使用 SQLAlchemy
- 建立 requirements.txt
- 建立單元測試
- 啟動後驗證 API

AI 可以建立：

app/
├─ main.py
├─ database.py
├─ models.py
├─ schemas.py
├─ services/
├─ routers/
├─ tests/
├─ requirements.txt
└─ README.md

並執行：

python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install fastapi uvicorn sqlalchemy pytest
uvicorn app.main:app --reload
pytest

3. 建立 Docker 環境

提示詞範例：

請將目前 FastAPI 專案容器化。

需求：
- 建立 Dockerfile
- 建立 docker-compose.yml
- 建立 PostgreSQL
- 建立 Redis
- 建立健康檢查
- 使用環境變數
- 啟動後測試 API

AI 可以執行：

docker compose up -d --build

查看容器：

docker compose ps

查看 Log：

docker compose logs -f

4. 部署 Google Cloud

提示詞範例：

我要在 Google Cloud 建立一個網頁服務。

請使用 gcloud CLI 協助規劃與部署。

需求：
- Python FastAPI
- 使用 Docker
- 部署至 Cloud Run
- 區域使用 asia-east1
- 使用 Artifact Registry
- 使用 Secret Manager 儲存 API Key
- 設定環境變數
- 提供部署與刪除腳本
- 建立付費資源前先列出資源清單

AI 可以依序協助：

1. 檢查 gcloud。
2. 登入帳號。
3. 設定 Project。
4. 啟用 API。
5. 建立 Artifact Registry。
6. 建立 Docker Image。
7. 推送 Image。
8. 建立 Secret。
9. 部署 Cloud Run。
10. 驗證服務網址。

5. 部署 Azure 服務

提示詞範例：

請使用 Azure CLI 部署一個 .NET Web API。

需求：
- 建立 Resource Group
- 建立 Linux App Service
- 建立 PostgreSQL Flexible Server
- 使用 Key Vault
- 使用 Application Insights
- 設定正式環境變數
- 提供建立、更新與刪除腳本

AI 可以產生與執行：

• az group create
• az appservice plan create
• az webapp create
• az postgres flexible-server create
• az keyvault create
• az monitor app-insights component create

6. 操作 Firebase

提示詞範例：

請使用 Firebase CLI 建立一個 React 網站。

需求：
- 使用 Firebase Hosting
- 使用 Firestore
- 使用 Authentication
- 建立 Security Rules
- 建立本機 Emulator
- 建立 GitHub Actions 自動部署

AI 可以協助執行：

firebase login
firebase init
firebase emulators:start
firebase deploy

7. 操作 Git 與 GitHub

提示詞範例：

請檢查目前專案修改內容。

接著：
1. 建立 feature/login 分支。
2. 將修改分成合理的 Commit。
3. 推送到 GitHub。
4. 使用 GitHub CLI 建立 Pull Request。
5. 在 Pull Request 說明中列出修改內容與測試結果。

AI 可能執行：

git status
git diff
git switch -c feature/login
git add .
git commit -m "feat: add login feature"
git push -u origin feature/login
gh pr create

8. 操作 Git 與 GitLab

提示詞範例：

請分析目前修改內容。

接著：
1. 建立 feature/report 分支。
2. 建立 Commit。
3. 推送到公司自建 GitLab。
4. 使用 glab 建立 Merge Request。
5. 檢查 GitLab Pipeline。

AI 可能執行：

git switch -c feature/report
git add .
git commit -m "feat: add report module"
git push -u origin feature/report
glab mr create
glab pipeline list

9. 自動管理 Windows 與 IIS

提示詞範例：

請使用 PowerShell 建立網站自動更新腳本。

流程：
1. 從 GitHub Release 取得最新版本。
2. 下載 ZIP。
3. 驗證檔案。
4. 解壓縮。
5. 停止 IIS App Pool。
6. 備份目前網站。
7. 保留 appsettings.json。
8. 更新其他程式檔案。
9. 啟動 IIS App Pool。
10. 呼叫健康檢查網址。
11. 失敗時還原。
12. 將完整過程寫入 Log。

AI 可以協助：

• 撰寫腳本
• 執行腳本
• 分析權限錯誤
• 驗證 IIS
• 驗證網址
• 建立失敗還原機制

七、如何撰寫適合 AI CLI 的提示詞？

不建議只寫：

幫我建立一個網站。

這類提示詞過於模糊，AI 很難判斷：

• 使用什麼程式語言
• 使用什麼框架
• 是否使用 Docker
• 是否需要資料庫
• 是否需要部署
• 可以操作哪些 CLI
• 是否可以安裝套件
• 是否可以修改現有檔案

建議至少包含以下內容：

1. 目標。
2. 技術架構。
3. 執行環境。
4. 可使用工具。
5. 功能需求。
6. 驗證方式。
7. 權限限制。
8. 安全限制。
9. 部署平台。
10. 最終交付內容。

建議提示詞模板

你是一位資深軟體架構師、AI 工程師與 DevOps 工程師。

請在目前目錄建立一個可執行的專案。

技術需求：
- 前端：React、TypeScript
- 後端：Python FastAPI
- 資料庫：PostgreSQL
- 快取：Redis
- 容器：Docker Compose
- 雲端：Google Cloud Run
- 版本控制：GitHub

可使用工具：
- PowerShell
- Git
- GitHub CLI
- Python CLI
- Node.js CLI
- Docker CLI
- gcloud CLI

執行要求：
1. 先檢查所有必要工具是否安裝。
2. 查看目前資料夾與既有檔案。
3. 不要直接覆蓋重要檔案。
4. 建立專案結構。
5. 安裝必要套件。
6. 建立資料庫設定。
7. 建立 Dockerfile 與 docker-compose.yml。
8. 建立健康檢查 API。
9. 建立單元測試。
10. 執行建置與測試。
11. 修正所有錯誤。
12. 建立 Git 分支與 Commit。
13. 提供 Cloud Run 部署腳本。
14. 涉及付費資源前，先列出資源與可能費用。
15. 不要將密碼、Token 或 API Key 寫入 Git。

八、網頁 3D 與程式 3D 工具選擇

網頁 3D：Three.js

Three.js 是基於 WebGL 的 JavaScript 3D 函式庫。

適合：

• 網頁 3D 展示
• 產品模型展示
• 3D 模型檢視器
• 互動式場景
• 數位孿生介面
• WebXR
• 教學模擬
• 網頁小遊戲
• 工業設備視覺化

安裝 Three.js：

npm install three

建立 Vite 專案：

npm create vite@latest threejs-demo
cd threejs-demo
npm install
npm install three
npm run dev

Three.js 可以搭配：

• React Three Fiber
• Drei
• Vite
• Blender
• GLTF
• GLB
• WebXR
• Cannon.js
• Rapier

提示詞範例：

請使用 Vite、TypeScript 與 Three.js 建立 3D 網頁。

需求：
- 建立地板
- 建立環境光
- 建立方向光
- 載入 GLB 模型
- 支援滑鼠旋轉
- 支援模型縮放
- 支援物件點擊
- 顯示物件資訊
- 加入載入進度
- 加入效能統計
- 執行 npm run build 驗證

程式、遊戲與工業模擬：Unity

Unity 是跨平台 2D／3D 開發引擎，主要使用 C#。

適合：

• Windows 3D 程式
• 手機 App
• 3D 遊戲
• AR
• VR
• 工業模擬
• 教育訓練
• 數位孿生
• 物理模擬
• 互動式展示

Unity 適合需要以下能力的專案：

• 角色控制
• 動畫系統
• 物理引擎
• 碰撞偵測
• 多平台輸出
• VR／AR 裝置
• 複雜場景管理
• 手機感測器
• 工業設備模擬

工具選擇參考：

九、安全與權限管理

AI 能操作 CLI，代表它也可能執行具有破壞性的指令。

因此，必須建立明確的安全界線。

1. 不要將密碼寫入提示詞或程式碼

避免直接提供：

• 密碼
• API Key
• Access Token
• GitHub Token
• GitLab Token
• 資料庫密碼
• SSH Private Key
• Service Account Key
• Azure Client Secret

建議使用：

• 環境變數
• .env
• User Secrets
• Azure Key Vault
• Google Secret Manager
• GitHub Secrets
• GitLab CI/CD Variables

.gitignore 建議包含：

.env
.env.*
*.key
*.pem
appsettings.Production.json
secrets.json
service-account.json

2. 執行刪除指令前必須確認

以下指令可能造成嚴重影響：

Remove-Item -Recurse -Force
rm -rf
docker system prune -a
az group delete
gcloud projects delete
git reset --hard
git clean -fd

執行前應先：

• 顯示操作目標
• 顯示實際路徑
• 顯示預計刪除內容
• 建立備份
• 建立 Git Commit
• 優先在測試環境操作
• 避免直接操作正式環境

3. 使用 Git 保護程式碼

AI 大量修改程式前，先執行：

git status
git add .
git commit -m "chore: snapshot before AI changes"

修改完成後檢查：

git diff
git status

這樣可以：

• 查看 AI 改了什麼
• 找出不合理修改
• 分批審查
• 還原錯誤
• 保留歷史紀錄

4. 區分不同環境

建議至少區分：

Development
Testing
Staging
Production

AI 初期應優先操作：

• Development
• Testing
• 個人雲端專案
• 測試用 Resource Group
• 測試用 Git 分支
• 測試資料庫

避免一開始就讓 AI 取得 Production 最高權限。

5. 使用最小權限原則

AI 使用的帳號、Token 或 Service Account，只應取得必要權限。

例如：

• 部署 Cloud Run 不一定需要 Project Owner
• 建立 Pull Request 不需要 Repository Admin
• 查詢資料庫不一定需要 DROP 權限
• 讀取 Log 不需要系統管理員權限
• Firebase 部署不一定需要完整 Google Cloud 管理權限

十、安裝完成後的環境檢查

可以使用 PowerShell 快速檢查常用工具是否存在：

$commands = @(
    "pwsh",
    "git",
    "docker",
    "node",
    "npm",
    "python",
    "pip",
    "gcloud",
    "firebase",
    "az",
    "gh",
    "glab",
    "psql",
    "sqlite3"
)

foreach ($command in $commands) {
    $result = Get-Command $command -ErrorAction SilentlyContinue

    if ($result) {
        Write-Host "[OK] $command" -ForegroundColor Green
    }
    else {
        Write-Host "[Missing] $command" -ForegroundColor Yellow
    }
}

也可以進一步檢查版本：

$versionCommands = @{
    "PowerShell" = "pwsh --version"
    "Git"        = "git --version"
    "Docker"     = "docker --version"
    "Node.js"    = "node --version"
    "npm"        = "npm --version"
    "Python"     = "python --version"
    "pip"        = "pip --version"
    "gcloud"     = "gcloud version"
    "Firebase"   = "firebase --version"
    "Azure CLI"  = "az version"
    "GitHub CLI" = "gh --version"
    "GitLab CLI" = "glab --version"
    "PostgreSQL" = "psql --version"
    "SQLite"     = "sqlite3 --version"
}

foreach ($item in $versionCommands.GetEnumerator()) {
    Write-Host "`n=== $($item.Key) ===" -ForegroundColor Cyan

    try {
        Invoke-Expression $item.Value
    }
    catch {
        Write-Host "未安裝或無法執行" -ForegroundColor Yellow
    }
}

十一、建議的 AI CLI 基礎工具組合

初學者可先安裝：

Windows Terminal
+ PowerShell 7
+ Git
+ Node.js
+ Python
+ Docker Desktop

需要使用 GitHub 時，再安裝：

GitHub CLI

需要使用 GitLab 時，再安裝：

GitLab CLI

需要部署 Google Cloud 時，再安裝：

Google Cloud CLI
+ Firebase CLI

需要部署 Azure 時，再安裝：

Azure CLI

需要開發資料庫應用時，可安裝：

PostgreSQL
+ pgAdmin
+ SQLite
+ DB Browser for SQLite

十二、結論

AI 能不能真正參與軟體開發，不只取決於模型本身是否聰明，也取決於它能使用哪些工具。

只有聊天能力時，AI 通常可以：

• 提供建議
• 產生程式碼
• 解釋錯誤
• 規劃架構
• 撰寫指令

搭配 CLI 後，AI 則可以進一步協助：

• 建立專案
• 建立檔案
• 安裝套件
• 執行程式
• 執行測試
• 修正錯誤
• 操作 Git
• 建立分支與 Commit
• 建立 Pull Request
• 建立 Merge Request
• 建立 Docker 容器
• 操作資料庫
• 部署雲端
• 建立 CI/CD
• 執行系統維運
• 產生自動化腳本
• 驗證最終結果

其中，Git 是 AI 開發流程中非常重要的安全基礎。

Git 可以讓開發者清楚知道：

• AI 修改了哪些檔案
• AI 修改了哪些程式碼
• 哪一個版本發生問題
• 是否需要還原
• 是否可以進行程式碼審查

因此，建議至少準備以下環境：

Windows Terminal
+ PowerShell 7
+ Git
+ Node.js
+ Python
+ Docker
+ GitHub CLI 或 GitLab CLI
+ Azure CLI 或 Google Cloud CLI

完成安裝後，可以在提示詞中清楚告訴 AI：

你可以使用 PowerShell、Git、Python、Node.js、Docker 與雲端 CLI。

請先檢查目前環境與 Git 狀態，再開始修改。

執行過程中：
1. 不要直接覆蓋重要檔案。
2. 不要刪除未確認的檔案。
3. 修改前先建立 Git 分支。
4. 修改後執行建置與測試。
5. 顯示完整錯誤訊息。
6. 修正後再次驗證。
7. 不要將密碼與 Token 寫入 Git。
8. 涉及雲端付費資源前，先列出預計建立的資源。

當 AI、CLI、Git、Docker、程式語言與雲端平台整合後，AI 就不再只是回答技術問題的聊天工具，而是能夠參與規劃、開發、測試、版本控制、部署與維運的工程協作工具。

SQLite 是全世界應用最廣泛的嵌入式資料庫引擎，從手機 App、瀏覽器到物聯網裝置都能看到它的身影。2026 年 7 月 24 日發布的 3.53.4 版本，除了修補前幾個小版本（3.53.1～3.53.3）遺留的問題外，也整合了自 3.53.0 以來累積的多項重要功能。以下用淺顯的方式，把這次更新拆解成幾個重點面向來介紹。

一、最值得關心的修復：資料庫損壞漏洞

這次更新最關鍵的一項，是修復了與 WAL（Write-Ahead Log，預寫式日誌）重置有關的資料庫損壞問題。WAL 是 SQLite 用來提升寫入效能與並行處理能力的機制，一旦這個環節出錯，最壞情況可能導致資料庫檔案損毀。對一般使用者來說，這代表：只要有使用資料庫寫入操作的應用程式，都建議儘快升級到這個版本，以避免潛在的資料遺失風險。

二、新增QRF（Query Result Formatter）

QRF（Query Result Formatter）是這次版本很有特色的新功能，簡單來說，它能把 SQL 查詢結果自動排版成整齊的表格，方便在文字介面（例如命令列視窗）中閱讀，例如數字會自動靠右對齊、輸出以框線字元組成表格。這對於習慣用命令列工具查資料庫的工程師或維運人員來說，等於是「不用額外工具，資料庫自己就把報表排版好了」。目前互動式命令列（CLI）已預設採用這種新格式，而批次執行（例如寫腳本自動跑 SQL）則仍維持舊格式，避免既有自動化流程被打亂。

三、SQL 語法更靈活

這次也強化了 SQL 語言本身的能力，重點包括：

• ALTER TABLE 更彈性：現在可以直接新增或移除欄位的 NOT NULL、CHECK 限制條件，不需要像以前一樣重建整張表。
• REINDEX EXPRESSIONS：可以單獨重建「表達式索引」（例如根據函數運算結果建立的索引），用來修復索引過期失效的問題。
• VACUUM INTO 加強：備份資料庫時可以透過 URI 參數指定保留空間大小，方便預留未來成長空間。
• 新增了 json_array_insert()、jsonb_array_insert() 兩個 JSON 處理函數，讓操作 JSON 陣列更方便。

四、查詢效能與規劃器的優化

SQLite 的「查詢規劃器」負責決定一條 SQL 該怎麼執行最有效率，這次做了幾項調整：對於 EXCEPT、INTERSECT、UNION 這類集合運算，一律改用排序合併演算法，官方說明這樣「幾乎總是」比雜湊表快；另外也改善了多表格連接（JOIN）時的順序選擇邏輯，減少不必要的運算。對開發者而言，這些改動通常不需要修改任何程式碼，資料庫會自動跑得更快。

五、浮點數精度改變 — 需要留意的相容性議題

比較值得注意的是，浮點數與文字互相轉換的精度，預設從過去的 15 位有效數字，提升到 17 位。這代表數字顯示可能比以前更精確，但也可能讓某些依賴舊有顯示格式的程式或測試出現差異。如果需要維持舊行為，可以透過 SQLITE_DBCONFIG_FP_DIGITS 設定調整回來。這是一個「預設值改變」型的更新，建議有大量數值運算的系統在升級前先做測試。

六、命令列工具（CLI）多項細節優化

命令列工具本身也有不少貼心的小改進，例如 .timer 指令可以設定只計時下一句 SQL、.progress 可以設定逾時自動中斷查詢、.indexes 指令的搜尋邏輯改為比對索引名稱本身（而非資料表名稱），讓搜尋功能真正符合預期。另外要特別提醒：點指令結尾若有沒加引號的分號，現在會被直接忽略，這是一項可能造成相容性問題的改變，若有腳本依賴舊行為，需要特別檢查。

七、其他技術亮點

新增了多個 C 語言介面函數，方便進階開發者操作字串緩衝區與虛擬表；Session 擴充功能新增了逐項新增變更的介面，方便做資料同步；JavaScript/WASM 版本則新增了 opfs-wl 檔案系統選項，透過瀏覽器的 Web Locks 機制達到更公平的鎖定共享，不過需要較新版本的瀏覽器支援。

重點總結

如果只想記住三件事：第一，這個版本修了一個可能造成資料庫損壞的漏洞，建議儘快升級；第二，新增的 QRF 讓命令列查詢結果變得更好讀；第三，浮點數精度與分號規則有變動，升級前建議簡單測試一下既有系統是否受影響。

需要特別說明的是，官方頁面提到 3.53.4 這個修補版本，主要是為了修正前幾個版本（3.53.1 至 3.53.3）中「主要由人工智慧引起的問題」，詳細細節官方僅指向提交紀錄，並未在頁面上進一步展開說明。

身為一個每天跟 LINE Messaging API、LIFF 混在一起的 .NET 開發者，我必須說 2026 年這個五月到七月，LINE 官方明顯是把「改版」這件事當成連續劇在更新，一集接一集，還時不時來個「未完待續」。這篇就把這段期間比較有感的更新，一次幫大家整理清楚，順便碎念幾句。

一、Rich Menu 終於有「數據」可以看了，不用再靠感覺

7 月 1 日這天，Messaging API 新增了兩支端點：取得 rich menu 洞察總覽、取得每日洞察數據。以前如果你的圖文選單是用 Messaging API 建的，你只能默默祈禱使用者有點下去；現在終於可以像用 LINE Official Account Manager 建的選單一樣，看到「顯示次數」跟「點擊次數」了。有趣的是官方特別強調，這兩套數據是互不相通的：API 建的選單看不到後台的數據，後台建的選單也看不到 API 的數據。所以如果你們家專案是兩種方式混用，記得數據要分開看，不然老闆問起「圖文選單成效」，你可能要交出兩份報告。

二、Rate Limit 被砍到只剩 0.5%，這是要逼死誰

這大概是整個五月最有戲劇張力的一則公告。5 月 7 日官方先預告：Get rich menu list 這支端點的速率限制，將從每秒 2000 次，改成每秒 10 次。沒錯，你沒看錯，是從 2000 掉到 10，砍幅超過 99%。然後 5 月 26 日，這件事真的發生了。

Get rich menu list
之前：2,000 requests / 秒
之後：   10 requests / 秒

如果你的系統有那種「每次使用者互動就順手查一次 rich menu 清單」的懶惰寫法，這波更新等於直接把你的架構考卷發回來重寫。建議是把清單資料快取起來，別再每次都問 LINE 要清單，畢竟現在問一次的成本，可能比你想像中貴很多。

三、LINE MINI App 內購：免費試用期結束，該收錢了

LINE MINI App 的應用內購買功能，原本佛心來著開放免費使用到 6 月底，官方在 6 月 5 日先預告、7 月 1 日正式上路：從 7 月 1 日之後的交易開始收取服務費用，費率則是以你申請當下公告的費率為準。同時官方也順手修訂了《LINE 應用內購買服務條款》，主要是把費用計算與請款結算方式講得更清楚。如果你們家產品有掛 MINI App 內購，這波記得回頭檢查一下財務試算，別讓會計部門措手不及。

四、日本認證 MINI App 可以跟 Business Manager 組織「牽紅線」了

6 月 10 日這則比較偏在地化：日本地區的已驗證 MINI App，現在可以把 MINI App 頻道連結到 Business Manager 組織，進而跟同組織底下的其他服務（目前支援 LINE 官方帳號）做整合。條件不少，包括地區都要設成日本、服務提供者跟已發布資料的營運公司要一致等等，細節偏繁瑣，但方向很明確：LINE 想把底下這些帳號體系越串越緊，官方也說未來會開放更多整合功能，值得先卡個位。

五、開發者帳號終於可以「刪除」了，但這是不歸路

6 月 24 日的更新算是補了一個长期缺口：LINE Developers Console 終於支援刪除開發者帳號。不過這裡有個重點要劃起來——刪除之後不能復原。而且如果你是某個 Provider 或 Channel 底下唯一的 Admin，刪除前系統會要求你先把權限交接給其他帳號，不然那個服務就等於被鎖死，沒人能再進去改設定。所以與其說這是「刪除帳號」功能，不如說它是一個「離職交接檢查表」，公司內部帳號有異動的話，記得先做好交接再按下去。

六、LIFF 悄悄升級了兩次，但你可能完全沒感覺

5 月 13 日發布 LIFF v2.29.0，6 月 29 日再發布 v2.29.1，兩次都寫著同一句話：只調整 SDK 內部行為，功能沒有變化。這種更新最適合「设了自動更新就不用管」，如果你是走 CDN edge path（https://static.line-scdn.net/liff/edge/2/sdk.js），會自動吃到新版；如果是 npm 使用者，記得手動更新一下：

npm install @line/liff@2.29.1
# 或
yarn add @line/liff@2.29.1

雖然官方說功能沒變，但內部行為調整這種話，老實講我都會半信半疑地多測一輪回歸測試，你們也是吧？

七、LIFF 瀏覽器大改版：多分頁圖示退場，換成三顆點點

5 月 19 日這則跟 UI/UX 關係最大：從 LINE 26.7.0 版開始，LIFF 瀏覽器的標頭規格整個翻新。原本那顆代表「多分頁檢視」的按鈕圖示，換成了直式三個點的選單圖示；點下去也不再直接跳去分頁畫面，而是彈出一個下拉選單，裡面塞了全部分頁、重新整理、最小化瀏覽器、分享、加到主畫面、我的最愛、權限設定、關於此服務、回報問題等一長串選項。另外，已驗證 MINI App 原本在標頭上的「最小化」按鈕，現在被收進下拉選單裡，原本的位置換成了「關閉」按鈕。如果你的 MINI App 有針對舊版標頭做過任何客製化引導教學或截圖說明，這波更新後這些素材大概都要重拍一輪了。

八、五月那場 LIFF/MINI App 事故：一段從 4/27 燒到 5/14 的小插曲

最後提一下背景插曲：4 月 27 日到 5 月 14 日之間，Android 版 LINE 26.6.0 / 26.6.1 有個 bug，導致在特定情境下（LIFF 瀏覽器開著時，用 Intent 或 App Link 又叫出同一個或另一個 LIFF/MINI App）會拿不到使用者 profile、LIFF API 也會怪怪的。官方後來在 5 月 14 日推出修復版 LINE 解決問題，但在那之前也貼心提供了一段暫時解法，用 location.href 做頁面轉跳、並在偵測到類似 invalid_request 的錯誤時手動登出再登入：

const params = new URLSearchParams(location.search)
const liffState = params.get('liff.state')
const redirectUri = liffState
  ? new URL('.' + liffState, location.href).toString()
  : location.href

liff.login({ redirectUri })

這種「先給暫時解法、再補正式修復」的節奏，其實蠻值得學起來——不管是自己開發的服務出包，還是等第三方修 bug，先讓使用者有路可走，永遠比讓他們卡死畫面來得體貼。

小結：這波更新告訴我們什麼

整體看下來，這兩個月 LINE 平台的更新可以歸納成三個關页字：限流變嚴、收費上路、體驗微調。速率限制被砍等於在提醒大家該做快取就要做；MINI App 收費代表商業模式正式進入下一階段；LIFF 的一連串小改版則是提醒我們，前端串接這種東西永遠不能「串完就沒事了」，得定期回去看看官方公告，免得哪天使用者截圖來問你「這個按鈕怎麼不見了」，你才第一次知道有這回事。

https://code.claude.com/docs/zh-TW/overview

安裝 claude code (命令提示字元)

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

OpenRouter 註冊

https://openrouter.ai/ 註冊新帳號

OpenRouter 使用在claude code的說明

https://openrouter.ai/docs/guides/coding-agents/claude-code-integration

.claude/settings.local.json

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "<your-openrouter-api-key>",
    "ANTHROPIC_API_KEY": ""
  }
}

加上 “ANTHROPIC_MODEL”:”openrouter/free” (使用系統分配，或是到model 搜尋免費 free https://openrouter.ai/models?q=free)

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "<your-openrouter-api-key>",
    "ANTHROPIC_API_KEY": "",
     "ANTHROPIC_MODEL":"openrouter/free"
​
  }
}

開啟 claude code

經營一個網站超過十年，就像是看著一個孩子長大一樣，充滿了滿滿的感情與回憶。這十多年來，我的WordPress網站一直忠實地陪伴著我，但也面臨著需要「轉大人」的考驗。

最近，我下定決心要將網站的底層引擎升級到全新的PHP 8.5，希望能讓網站跑得更快、更順暢，給大家更好的體驗。沒想到，過程卻像是在闖關打怪一樣充滿挑戰！其中最大的一個關卡，就是一個叫做hacklog remote attachment的老套件。它就像是一個充滿回憶但也捨不得搬家的老頑固，不管我怎麼嘗試，它就是無法適應新的環境，導致我的升級計畫一直卡關失敗。

正當我感到有些頭痛，差點要舉白旗投降的時候，我想起了現在最厲害的好幫手，也就是人工智慧AI！我轉念一想，何不請AI來當我的專屬工程顧問呢？於是，我帶著這個老套件的難題，和AI進行了一場深度的跨界交流。

沒想到，AI真的超級神！在它的耐心引導與程式碼微調之下，我們居然成功解開了這個老套件的心結，讓它順利跟上了時代的腳步。當畫面上顯示升級成功的那一刻，我真的感動到想從椅子上跳起來歡呼！

這不僅僅是一次系統的升級，更是我親身見證科技帶來無限可能的一刻。遇到困難真的不要氣餒，轉個彎，或許就會發現新的解法。有時候，只要一點點正向的信念，加上善用身邊的新工具，原本看似無解的難題也能迎刃而解！讓我們一起保持開放的心，快樂迎接每一天的挑戰吧！