「这是一个 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 流程
