起點是每天的後勤維運。營運遇到訂單、規則或數據問題，第一反應就是貼到工程群組；每一題都會打斷一位工程師。工具其實並不少：公司已有知識助手、資料庫唯讀權限，大家也會用 Claude Code。問題是文件會過期，口語問法常搜不到；直接查資料庫，又可能算出一個「錯得很像對的」業績數字。
我判斷缺的不是另一個聊天介面，而是公司脈絡：AI 讀不到 code，也不知道每個數字的正確口徑。因此我沒有再寫一份查詢手冊，而是把「這家公司該怎麼查才對」固化成 12 支唯讀工具。每次查詢都會自動套用正確查法，營運自己問 AI，就能得到原本得排隊問工程師的答案。
AI 不缺寫 SQL 的能力，缺的是這家公司的常識。
這個專案做的，就是把常識變成基礎設施。
CHALLENGE 01
「這個月業績多少」聽起來只要一句 SQL，實際上藏著一串業務口徑：金額必須用明細視圖，不能拿訂單總價；資料要按產線分組；訂購日期看建單時間，不是訂閱續扣日；公益捐款單還要排除。漏掉任何一項，查詢仍會跑出一個看似合理、其實錯誤的數字。營運就曾因為算出的業績與後台對不上，請工程師花半天重新對帳。
這不是權限問題，而是業務邏輯沒有跟著查詢一起執行。我的做法是把業績算法鎖進 MCP：不論誰來問同一個問題，都會走同一套口徑、得到同一個數字。
CHALLENGE 02
動手前，我先沿用 UX 的方法盤點使用者。這次不先列功能，而是先看每一種人手上有什麼、真正卡在哪裡：
| 使用者 | 手上有 | 缺的 | 於是 |
|---|---|---|---|
| 營運 | SQL 唯讀權限、Claude Code、知識助手 | 正確查法、code 存取 | 裸查算錯，或排隊問工程師 |
| 客服 | 知識助手 | 文件的新鮮度 | 搜不到就回頭問人 |
| 工程師 | 全部 | 時間 | 一天被打斷好幾次 |
沒有人缺權限或工具，缺的是一條能把既有能力接起來、而且值得信任的路。
這個判斷決定了後面所有設計。
CHALLENGE 03
專案初期爭論最久的，是要擴充既有知識助手，還是另做一個工具。前者已有使用者與介面，看起來最省；我最後仍選擇拆開，理由有三個：
一、正式服務不該承擔實驗風險。 知識助手是客服每天在電話中使用的正式服務。若把查 DB、讀 code 等全新能力直接掛上去，每次迭代都可能影響既有工作。後來唯一一次為了共用能力調整部署，就造成兩次短暫中斷。
二、介面必須跟著工作方式走。 知識助手住在 Teams，適合一問一答；但目標使用者已經在 Claude Code 工作。他們需要的不是另一個輸入框，而是讓手上的 AI 直接取得能力。MCP 提供的是 AI 可呼叫的介面，因此營運、工程與未來更換的模型都能共用，不會綁死在單一聊天視窗。
三、能力可以共用，不必複製。 我讓知識助手對內開兩個小 API，新工具直接重用它的檢索與寫入能力。這樣全公司的文件寫入邏輯只維護一份，不會兩邊各自演進。
改舊的還是做新的，不能只看開發成本，也要看誰在承擔上線風險。
APPROACH
最後的方案是一個唯讀 MCP，把業務邏輯固化成 AI 可以直接呼叫的工具。資料庫存取權早就存在；真正新增的價值，是讓每次查詢自動套用正確口徑。同一個業績問題，不再因為提問者不同而得到不同答案。
規劃上是一個核心、兩個出口：同一套工具，Phase 1 先讓營運在 Claude Code 自助查詢、養成習慣；Phase 2 給工程部的自動 triage 用——報錯訊息進來，機器人用同一套工具查完、產出交接文件。核心做穩一次，兩邊受益。
FEATURES
貼單號到工程群等人撈
query_sql + query_mongo
設計時的堅持是 Mongo 一定要收：發票真正的開立結果、客人有沒有走到完成頁、遺失訂單的結帳快照——這些真相 SQL 裡沒有，只接 SQL 就會有一類問題永遠查不到。
翻文件（可能舊了）、問資深同事（可能記錯）
search_code
直接 grep 六個 repo 的遠端預設分支。程式碼是唯一不會過期的文件。
文件與系統行為對不上，只能再找人確認
explain_business_rule
同時 grep 程式碼和語意搜尋文件，把兩邊並列回傳讓 AI 對照。code 是確定性的，它把整個答案的可信度撐起來。
查到舊文件，還要另外排時間修改
propose_kb_update / apply_kb_update
查到的當下順手產生修改草稿，人確認後發布。把「知識保鮮」從某個人的待辦事項，變成查詢的副作用。
每次遇到同類問題，都重新想一次查法
diagnostic_playbook
把每一類問題的固定查法沉澱成可讀的 SOP。
營運先寫需求，工程再逐項追問
draft_requirement_guide
幫營運在寫需求的當下就找到整合點、範本與該回答的完整性問題。
DECISIONS — ADR
每一個決策都有「另一條比較省事的路」，我把當時的取捨原樣寫出來——這些決策後來都進了只能追加的決策紀錄（ADR），讓之後接手的人看得懂當初為什麼這樣蓋。
決策一：先用既有方案驗證，再用數據決定是否擴容
工程師提議把 MCP 直接做成主站的 /mcp 路由，開發最快；我否決了，因為 search_code 會 clone 六個 repo、執行 git grep，可能與正式站搶資源。Windows 測試方案不支援 Python，也已放了九個站，因此我先部署到既有的 Linux B1 測試方案，額外成本為零。
我知道這不是長期最穩定的架構，但現階段更重要的是用最低成本驗證需求。先觀察實際使用量與回應速度；若資源不足，或同仁已明顯依賴這套工具，再用數據爭取升級或獨立服務，支撐工程部後續開發全公司共用的 AI 工具。
決策二：權限模型
資料全面開放，不做角色分層。老闆本來就給了營運唯讀權限，如果 MCP 卡得更嚴，他們只會回頭裸查——那正是我要解決的問題。限制權限不會讓數字變準。
決策三：查詢打哪裡
query_sql 一律查唯讀副本，不碰正式資料庫。這是「爆炸半徑」思維：即使查詢出問題，最壞也只是副本變慢，不會影響客人結帳。
決策四：寫入邊界
對正式程式碼、資料庫、雲端資源永遠唯讀。唯一的寫入入口是知識庫，且經人工確認才落地。能讀的工具被騙最多回錯字；能寫的工具出事是另一回事。
架構決策的重點不是選了什麼，是把「沒選什麼、為什麼」寫下來。這四條每一條都擋掉過一次「當初為什麼不直接……」的重新討論。
AI COLLABORATION
這個專案的大部分程式碼由 AI 產出，但工具裡的業務判斷、風險邊界與驗證方式，都來自我對公司流程的理解。我的工作不是比 AI 打字快，而是把 code、數據與真實業務場景對起來，讓它產出的程式一開始就走在正確邏輯上。三個例子最能說明這個分工：
教它業績怎麼算。 「訂購日期看建單時間，不是續扣日」這種知識，AI 猜不到，欄位註解也不會告訴它。這是某次對帳失敗、追查半天才確認的規則。以前它只存在我的腦中與聊天紀錄裡；現在鎖進工具層，所有人與所有 AI 都會自動查對。
用真實範例校準它。 draft_requirement_guide 不讓 AI 憑空生成範本，而是比較需求庫裡四個寫得好的、三個被退回的、四個特別複雜的案例，歸納出「範圍、狀態、例外、口徑」四個必要條件。工程 PM 原本要事後追問的內容，就能前移到營運開始寫需求的時候。
接受它的不確定，再用架構補足。 知識庫的查詢展開由 LLM 執行，同一個問題重問，排名就可能變動。我沒有繼續追求不存在的「完美檢索」，而是讓 explain_business_rule 同時取得文件與程式碼，用確定性的 code 補住機率性檢索的限制。
我不訓練模型，我設計工具的邊界。模型會換、對話會斷，寫進工具層的業務邏輯才能留下來。
GOVERNANCE
會變動的知識放在 Markdown，穩定且高風險的能力才留在程式碼裡。diagnostic_playbook 就是這個原則的產物：每類問題的固定查法各寫成一個 .md 檔，工具只負責列出清單與回傳全文。新增查法只要新增檔案，不必改程式或重新部署。
這也是公司 AI 治理的一環。個人對話裡的 know-how，先沉澱成有版控、有審核流程的 skill；其中高風險、高頻，而且所有人必須拿到同一答案的內容，例如業績算法，再往下鎖進 MCP 工具層。越往下越穩定、越不容易出錯，修改成本也越高。先放對層級，才能同時保留速度與控制。
SECURITY
這個工具讓十幾位同仁能直接查詢公司資料，因此安全不能只靠使用者小心。每人使用專屬權杖，沿用後台既有的 PAT 系統，撤銷一人不影響其他人；帳密集中託管，連線字串只留在伺服器端；每次呼叫都寫入稽核 log，記錄誰用了哪支工具、查了什麼、花多久、回傳多大。
驗證機制本身也必須被驗證。接上 PAT 後，我發現即使使用舊的共用密鑰，請求仍會回 200，表面上看不出實際走了哪條驗證路徑。最後我改看健康端點的「已快取身分數」是否增加；只有真正經過 PAT 驗證的請求才會進入快取。
「請求成功」和「走的是你以為的那條路」是兩件事。
CHALLENGE 04
工具完成後，真正的採用問題才開始：怎麼讓十幾位從未開過終端機的同事，把 MCP 裝進自己的電腦？
第一版：操作手冊，加上「讓 AI 帶你裝」。 想法看似合理，實際上 AI 只把手冊轉述成「請打開終端機」「先安裝 git」等指令。對非技術同事而言，每一步都是新的門檻，最後仍由 IT 一台一台陪裝。我原本以為「手冊＋AI」就等於有人帶，卻忽略了 AI 只是解釋步驟，沒有消除步驟。
對不會終端機的人來說，「請打開終端機」跟沒有說明是同一件事。門檻不是使用者的問題，是設計者的問題。
第二版：把門檻收進安裝包。 我把原本要使用者處理的環境檢測與安裝步驟全部寫進腳本：它會判斷目前進度，缺什麼就補什麼；中途失敗後重跑，也能從斷點接續。再搭配一支「幫同仁裝公司工具」的 skill，讓 AI 直接執行並用白話回報，而不是把指令丟回給使用者。正式發布當天，就有未經 IT 陪裝的同事自行完成安裝並開始查詢。
採用率是設計出來的，不是宣導出來的。
RESULTS
8/18 上線，9/1 正式發布給全公司。截至 9/1：累計 1,702 次工具呼叫、14 位同仁實際查詢、17 人完成安裝，單日最高峰達 404 次。query_sql 使用最多（740 次，平均 3.4 秒），其次為 search_code（342 次，平均 7.3 秒）。
使用者組成比總量更能驗證目標是否達成：使用量排名第二、第三的都不是工程師。他們開始自行查會員、訂單與商品設定，不必再把同一類問題貼到工程群組等待回覆。
LESSONS
正式環境暴露了測試階段看不到的問題：上線前兩天，SQL 全域連線快取一旦被 Azure 閘道切斷，就只會回傳「Not connected」，無法自行復原；容器沒有 git，導致 search_code 每次重啟後會有 1～2 分鐘無法使用；另有兩個必要設定缺少時，錯誤訊息完全沒有提示；備份排程也曾在半夜連續失敗六次才被發現。
最嚴重的是發布當天揪出四個「系統回報成功、實際上壞掉」的問題——其中一個是伺服器同步指令參數錯誤，意味著過去所有查法更新其實一次都沒生效，而系統從頭到尾都回報成功。
「沒有錯誤訊息」不等於「正常運作」。會騙人的從來不是紅色的錯誤，而是綠色的成功。
從那之後，每做完一項變更，我都會再問 AI：先假設它其實沒有生效，要用什麼證據證明它真的動了？
NEXT
將稽核 log 接入 Log Analytics（目前僅輸出到容器、三天即清除）；從查詢紀錄回推工具設計——大家實際輸入的問題，就是下一批 playbook 的題目來源；工程部的自動 triage（Phase 2）——錯誤訊息進來，用同一套工具自動查詢完成、產出交接文件，工程師接手，不自動執行任何修改。
STACK
Python 3.13、FastMCP（Streamable HTTP）、Azure App Service（Linux B1，複用既有方案、零額外成本）、Azure SQL 唯讀副本、Cosmos DB for MongoDB、Bitbucket（六個 repo 鏡像 clone + 定時 fetch）、知識庫透過後勤知識助手的內部 API 重用、PAT 驗證與稽核 log、架構決策紀錄（ADR）。內部工具，原始碼不公開。