当前时间、请求编号、随机数会让输入很难复用。
成本、速度与模型选择
时间戳和动态变量为什么烧钱？
很多 AI 系统明明已经做了缓存，成本还是降不下来。常见原因是：时间戳、请求 ID、随机数、实时状态等动态变量，把本来一样的请求变成了每次都不一样。
一句话回答
动态变量本身不是问题，问题是它们太容易把本来稳定的输入变成每次都不一样。一旦变化太多，缓存命中率会下降，输入 Token 也会变多，成本就容易上去。
01 先看一张图：动态变量为什么会破坏复用？
stable prefix, moving tail
系统规则、工具说明、输出规范尽量保持稳定。
只把当前任务真需要的变量放到后面。
Trace ID、UUID、调试编号优先留在日志里。
固定内容尽量放在一起，动态内容尽量往后放。
02 哪些东西最常被塞进 Prompt？
dynamic inputs
当前日期、当前时间、精确到秒或毫秒的时间戳。
用户 ID、会话 ID、账户编号、租户编号。
请求编号、追踪 ID、重试次数、调试序号。
随机数、随机文案、随机推荐结果。
库存、订单、余额、价格、物流、行情。
当前任务目标、当前选择、当前步骤。
03 时间不一定要精确到那么细
use only the needed precision
写日报只要日期，不需要精确到毫秒。
安排会议通常需要日期 + 时间。
实时价格只在用户问价格时再查。
程序能判断的内容，不必都交给模型。
精度只保留完成任务真正需要的部分，不要无脑把秒、毫秒、微秒都送进去。
04 程序层和模型层要分开
keep internal fields internal
Trace ID、请求 UUID、服务器节点、日志编号。
任务目标、必要实时信息、业务规则、用户当前问题。
真正需要时再去查库存、价格、订单或日历。
程序需要知道，不代表模型必须知道。Trace ID、请求 UUID、服务器节点这些更像日志字段，不是模型需要理解的业务内容。
05 Prompt 的结构最好先稳后动
fixed first, dynamic later
固定前缀稳定，动态内容尽量少。
06 实时数据也要拆开看
fixed rules + live data
交易范围、风控规则、解释模板。
BTC、ETH、当前持仓、实时价格。
用户真正问价格时再查工具。
不要把每秒变化的内容提前塞满 Prompt。
07 动态变量为什么会直接增加 Token？
more changing text, more input
动态内容越多，模型需要读的字越多。
输入一变，稳定前缀也更难完整复用。
模型要先过滤这些变化，再找真正重点。
重复变化会把省下来的钱慢慢吃掉。
动态变量越多，不只是缓存变差，输入 Token 也会跟着涨。
08 最好的办法：能晚取就晚取
delay dynamic fetch
模型先决定这次任务到底需不需要实时变量。
需要库存、价格、订单或日历时，再去查最新值。
只把这次真正需要的动态信息返回给模型。
动态信息不是不能用，而是不要提前把所有实时字段都塞满 Prompt。
09 写 Prompt 前，先问 6 个问题
use the checklist
不需要就别传。
能就别给模型。
别过度精确。
会变就尽量缩小范围。
能就延迟调用工具。
会就重排结构。
本节练习
把一个客服 Agent 的 Prompt 重新排版
把固定客服规则、工具说明和输出规范放前面；把订单状态、当前日期和用户问题放后面；Trace ID、请求 UUID 留在日志里。
这次真的需要吗？不需要就别传。
能留在程序层吗？能就别给模型。
精度够了吗？别过度精确。
每次都会变吗？会变就尽量缩小范围。
能按需获取吗？能就延迟调用工具。
会破坏缓存吗？会就重排结构。
本节小结
动态变量不是不能用，而是要放对地方、用对粒度、只传当前任务真正需要的那一份。
- 缓存最喜欢“重复”，动态变量最容易制造“变化”。
- 固定规则、工具说明、输出规范尽量放在稳定前缀里。
- 当前时间、用户 ID、请求 ID、随机数、实时状态等变量，只在任务真的需要时才给模型。
- 不是动态变量不能用，而是不要让“每次都变”的东西污染本来可以复用的内容。