「這是一個 SasaDaily 假設商業案例。」
一家 6 人法規／合規顧問工作室，
每接一個新客戶，
真正花時間的事情未必是：
「不知道法規。」
反而常常是：
又要重新讀一次同樣的法規。
例如團隊長期服務某一類產品。
每個案子都會反覆用到：
主要法規。
主管機關指引。
技術標準。
公司自己的判斷方法。
常見風險分類。
報告格式。
固定術語。
唯一真正不同的，
往往只是：
這次客戶自己的資料。
如果每做一案，
都把所有法規＋方法論＋新客戶資料整包重新交給 AI，
模型就可能一直付費重新處理大量相同 Context。
Claude Fable 5.1 的 Prompt Cache，
正好可以用來重新設計這種工作。
這家公司不是單純打開 Claude 聊天
先分清楚。
這個案例使用的是：
Claude API。
因為團隊要控制：
Prompt 結構。
固定 Context。
Cache。
客戶資料位置。
以及整套分析工作流程。
不是每位顧問自己開 Claude，
然後每天手動上傳一堆 PDF。
工作室真正要建立的是一條：
可重複的內部分析流程。
第一步：先把每個案子都會重複的東西拆出來
團隊把工作資料分成兩區。
第一區叫：
Stable Context。
長期穩定背景。
例如：
適用法規。
主管機關指引。
公司內部分析方法。
風險分類規則。
標準報告架構。
常用定義。
Tool Definitions。
引用與證據標示要求。
這些內容不是每個客戶都不同。
所以集中放在 Prompt 前面。
第二區則是：
Client Input。
例如：
客戶政策。
產品規格。
測試報告。
供應商聲明。
合約。
內部 SOP。
以及這一次真正要回答的問題。
它們才是每一案的新資料。
為什麼不能全部混在一起？
因為 Claude Prompt Cache 採用的是：
Prefix Caching。
白話來說：
AI 會看 Prompt 前面那一大段，
和之前是不是一樣。
如果前面長期固定的內容保持穩定，
就有機會重複使用已建立的 Cache。
但如果每個客戶一進來，
團隊就重新：
調整法規順序。
改寫 System Prompt。
把客戶名字插到最前面。
重新排列範例。
即使內容大部分其實相同，
原本可以重用的 Prefix 也可能被破壞。
所以第一個管理規則不是：
「Prompt 寫得越漂亮越好。」
而是：
固定背景，固定順序。
真正新的東西再放後面。
第二步：不要叫 AI 一次下完整合規結論
這家假設工作室不會下這種 Prompt：
「請閱讀所有資料，告訴我這家公司是否完全合規。」
原因很簡單。
這個問題太大。
它同時包含：
找法規。
找證據。
判斷是否適用。
比對文件。
處理矛盾。
找缺口。
評估風險。
最後做專業判斷。
團隊反而把 Fable 5.1 拆成幾輪工作。
第一輪：只建立「適用要求清單」
AI 先根據固定法規背景與本案資訊，
整理：
哪些要求可能適用。
每一項要求來自哪一份來源。
客戶目前提供了什麼證據。
不要先判：
合規。
不合規。
只建立：
要求與證據地圖。
這一步的目的是：
先把資料找齊。
不是做結論。
第二輪：找矛盾
接著要求 AI：
只找資料互相衝突的地方。
例如：
客戶 SOP 說：
A。
供應商聲明卻說：
B。
測試文件又出現：
C。
AI 不要替顧問偷偷決定：
哪一份是真的。
而是標記：
「這三份資料互相不一致，需要人工確認。」
這會比 AI 自己挑一個版本，
安全得多。
第三輪：找缺口
下一步只問：
哪些法規要求，
現在找不到足夠證據？
例如：
法規要求保存某項紀錄。
但客戶目前沒有交。
AI 就標記：
缺證據。
不是直接寫：
不合規。
這兩個詞差很多。
沒有看到資料，
可能只是：
客戶還沒提供。
也可能真的沒有。
所以 AI 最適合先做的是：
找出：
還不知道的地方。
第四輪：建立客戶追問清單
以前顧問可能看完 200 頁資料，
才自己整理：
「還要問客戶哪些問題？」
現在 AI 可以先把缺口整理成：
待補文件。
待確認事實。
互相矛盾項目。
需要負責人回答的問題。
這一步的價值很實際。
顧問第一次和客戶開會，
不用再從：
「你們目前有哪些資料？」
重新開始。
而可以直接問：
「這五個缺口我們需要確認。」
第五輪：才做風險分析草稿
前面資料比較乾淨後，
才讓 Fable 5.1 建立：
Draft Risk Memo。
例如把內容分成：
已有證據支持。
證據不足。
資料矛盾。
可能需要進一步判斷。
需要專業顧問確認。
而不是讓 AI 把所有東西硬分成：
通過。
不通過。
因為真實合規工作，
常常不是單純 Yes／No。
第六輪：正式客戶結論留給人
最後最重要的一道線：
AI 不簽核。
它可以：
找資料。
比對。
整理。
找矛盾。
找缺口。
草擬報告。
但正式對客戶說：
「這項風險可以接受。」
「這份證據足夠。」
「這個產品可以依目前條件往下一步。」
「這項要求必須先整改。」
仍由：
顧問本人判斷。
因為真正專業服務賣的不是：
把文件整理漂亮。
而是：
願意為最後判斷負責。
為什麼這類工作可能適合 Fable 5.1？
Anthropic 自己目前的定位其實很清楚。
對多數一般工作，
官方建議先從其他較低成本模型開始。
Fable 5.1 比較適合的是：
Demanding Reasoning。
Long-horizon Agentic Work。
Multistep Research。
大型文件與複雜 Knowledge Work。
所以這家假設工作室不會規定：
「所有工作全部跑 Fable。」
例如：
檔名整理。
簡單分類。
格式轉換。
可能根本不需要最高階模型。
Fable 5.1 留給：
真正需要跨大量規則、文件與多步驟判斷的部分。
這樣才比較合理。
Prompt Cache 真正替這家公司省的是哪一筆錢？
不是：
「法規不用再讀了。」
AI 每一次仍然需要利用這些 Context。
差別是：
如果前面那一大段固定法規與方法論已經建立 Cache，
後續 Request 可以用比較低的：
Cache Read
價格重新使用。
Fable 5.1 目前一般 Input 是：
每百萬 Token 10 美元。
Cache Read 則是：
每百萬 Token 0.25 美元。
但第一次建立 Cache 本身仍然有成本。
所以：
不是放進 Cache 就立刻省錢。
真正有價值的是：
同一份大背景反覆使用。
用一組假設數字看看
「SasaDaily 假設數字。」
假設這家顧問公司的固定背景包含：
法規。
技術標準。
方法論。
範例。
Tool Definitions。
合計約：
300,000 Tokens。
一個複雜客戶案，
前後需要執行：
6 次
需要相同固定背景的分析。
先只算這 300,000 Tokens 的固定 Context。
不計：
客戶新資料。
Output。
Tool Calls。
其他處理。
如果每次全部重新當一般 Input 處理
300,000 Tokens
× 6 次
＝
1,800,000 Tokens。
依 Fable 5.1 每百萬 Input Tokens 10 美元的價格，
固定背景部分約：
18 美元。
注意：
這還不是整個客戶案的 API 成本。
只是固定背景重複處理這一部分。
如果使用 1 小時 Cache 呢？
「SasaDaily 假設數字。」
假設六輪工作都發生在同一個有效 Cache 時段，
而且 Prompt Prefix 維持穩定。
第一次建立 300,000 Token 的 1 小時 Cache。
Fable 5.1 的 1 小時 Cache Write：
每百萬 Token 20 美元。
所以約：
6 美元。
後面五次讀取，
總共：
1,500,000 Cache Read Tokens。
Cache Read 每百萬 Token 0.25 美元。
約：
0.375 美元。
固定背景部分合計：
約：
6.375 美元。
和前面的：
18 美元
相比，
固定 Context 這一塊少了約：
11.625 美元。
這能不能直接說「整個案子成本降 65%」？
不能。
這非常重要。
因為上面的計算只算：
固定背景。
實際工作還會有：
每案的新文件。
新的 Input。
模型 Output。
Tool Calls。
重試。
可能的 Cache Miss。
其他模型。
人工檢查。
甚至整合系統本身的成本。
所以不能把：
固定 Context 這一塊的節省，
直接當成：
整個顧問案 ROI。
如果一個月做 12 個案子呢？
「SasaDaily 假設數字。」
如果每個案例真的都符合前面的假設，
單純固定 Context 理論差額：
11.625 美元 × 12
約：
139.50 美元。
這聽起來不像：
「AI 一個月替公司多賺幾萬美元。」
而這反而比較正常。
Prompt Cache 本來就不是：
魔法變現工具。
它是：
當大量相同 Context 不斷被重複處理時，降低其中一項運算成本。
真正大的商業價值，
可能還是在：
顧問少花多少時間找資料。
能不能多服務幾個客戶。
錯漏是否減少。
客戶等待時間是否縮短。
這些才要另外量。
這家工作室因此不只記 Token Cost
團隊真正追蹤的是：
一個客戶案花多少 API 成本。
用了多少 Cache Read。
跑了幾次。
AI 找到多少有效缺口。
顧問修改多少內容。
最後花多少人工時間。
客戶是否需要第二輪補件。
如果 API 便宜 20%，
但顧問多花兩小時修錯誤，
那完全沒有省。
最重要的 KPI 其實是「一份可交付報告的總成本」
不是：
每百萬 Token 多少錢。
也不是：
Cache Hit 多高。
而是：
從客戶文件進來，
到最後產生：
可以由顧問簽核、可以交付客戶的結果
整條流程用了：
多少 AI。
多少人。
多少時間。
多少重做。
這和我們之前談 Langfuse 的概念很接近：
不要只量：
模型呼叫成功。
要量：
工作到底有沒有真的完成。
還有一個更重要的管理問題：法規更新怎麼辦？
Cache 最危險的誤用是：
因為舊背景可以重複使用，
所以永遠不更新。
例如主管機關昨天改了規則。
公司卻因為：
「這份 Cache Hit 很漂亮。」
繼續使用舊法規。
那只會：
更便宜地使用錯誤資料。
所以這家假設公司會替 Stable Context 做：
版本管理。
例如：
Regulatory Context v12。
新規則正式生效，
重新驗證內容。
改成：
v13。
再建立新的 Cache。
舊版本退出。
所以 Cache 的真正單位不是「永遠不變」
而是：
在有效版本期間保持穩定。
這個概念非常重要。
固定背景不是：
不能改。
而是：
沒改版時不要每次亂改。
真正有新版本時，
就正式更新。
這樣才能同時做到：
成本效率。
以及：
資料正確性。
敏感客戶資料怎麼辦？
這也是法規顧問不能忽略的地方。
「可以放進 Context」
和：
「公司政策允許放進 Context」
不是同一件事。
每一家顧問公司仍然需要確認：
客戶合約。
資料分類。
個資。
商業機密。
資料保存要求。
使用的平台條件。
不能因為模型支援：
100 萬 Token Context，
就把：
100 萬 Token 客戶機密全部放進去。
Context Window 是技術容量。
不是：
資料授權。
這個案例真正改變顧問公司的哪一段工作？
以前流程可能是：
收到客戶資料。
顧問重新找法規。
重新找模板。
重新比對文件。
自己列缺口。
自己做第一版整理。
最後才開始判斷。
改造後可能變成：
固定法規背景已經準備好。
新客戶資料放到後面。
AI 建立要求清單。
AI 找矛盾。
AI 找缺口。
AI 準備追問。
AI 草擬風險 Memo。
顧問最後：
查證、判斷、簽核。
人的工作沒有消失。
但人的時間從：
「重新找一次所有東西」
往：
真正需要專業判斷的地方
移動。
這也會改變顧問公司怎麼收費
昨天 SasaDaily 才談到一個很重要的趨勢：
當 AI Agent 開始接手大量重複顧問工作，
企業會愈來愈不願意只按照：
人數 × 工時
付費。
這個假設案例剛好就是另一面。
如果一家顧問公司因為 AI：
閱讀更快。
整理更快。
第一版報告更快。
難道就代表：
應該因為工時變少，
只能收更少？
未必。
真正長期有價值的，
可能變成：
專業判斷。
風險承擔。
複雜例外。
結果品質。
以及：
客戶到底解決了什麼問題。
AI 壓縮的是：
重複勞動。
不一定是：
專業價值。
哪些專業服務也可能用同樣方法？
不只有法規顧問。
只要你的工作都有：
一大份長期固定知識。
加上一小份每案不同資料。
都值得思考。
例如：
稅務研究。
內部稽核。
資安政策檢查。
技術標準審查。
採購規範。
保險文件分析。
企業政策比較。
大型專案 QA。
共同結構都是：
背景大部分相同。
案件資料一直換。
這正是 Prompt Cache 最自然的商業使用場景之一。
但不要因為 Cache 便宜，就把所有專案塞成一個超大 Prompt
這也是另一個極端。
Context 愈大，
不代表結果一定愈好。
真正應該留下的是：
這個工作需要的：
有效法規。
必要規則。
相關定義。
工作方法。
Tool Definitions。
不是：
「公司所有資料。」
如果某份資料和這個專案無關，
塞進去只會：
增加成本。
增加噪音。
增加模型判斷負擔。
所以好的 Cache 不是：
最大的 Cache。
而是：
最穩定、最相關，而且真的會一直重複使用的 Context。
最後把這個案例縮成一條工作流程
固定法規＋方法論＋工具定義
↓
建立 Stable Context
↓
新客戶政策＋合約＋測試文件
↓
追加 Client Input
↓
AI 找適用要求
↓
AI 找矛盾
↓
AI 找資料缺口
↓
AI 草擬風險 Memo
↓
顧問回到原始證據查核
↓
顧問做正式判斷與簽核
Claude Fable 5.1 在這裡真正替公司做的，
不是：
取代合規顧問。
而是：
不要每接一個新客戶，就從第一頁法規重新讀起。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
顧問公司明明靠幫企業導入 AI 賺錢，為什麼客戶現在反而用 AI 砍掉顧問費？
AI 商業案例｜2026/08/10：8 人線上課程平台怎麼用 Langfuse？從學員客服成本、人工修改到真正解決率，找出值得留下的 AI 流程
