列表筛选提示词：长标识符推高调用费

让模型从商品列表里挑选匹配项，直接把数据库里的 UUID 一起塞进提示词，看起来很自然。但作者发现，在一组包含 50 件商品的测试里，把 UUID 换成 1 到 50 的编号，单次调用费用竟相差约 4.8 倍。

这不是换模型或压缩商品描述带来的收益，而是改了模型用来指认商品的方式。对做搜索筛选、推荐和列表匹配的程序员来说，这个案例值得看：有些 token 开销来自数据格式，业务信息并没有增加。

为什么商品 ID 比商品名称还贵

模型按 token 计费，数据库按字节识别主键，两者对「简洁」的理解并不一致。

UUID 是 128 位标识符，通常写成包含十六进制字符和连字符的 36 字符字符串。分词器（tokenizer）的词表来自普通文本，遇到随机字符组合，往往只能拆成每段 1 到 3 个字符的小片段。

作者用 OpenAI 的开源分词库 tiktoken 构造了一组测试：46 token 的指令、50 行 id | name 商品数据、一行查询，以及返回三个 ID 的 JSON 数组。随后只替换 ID 格式，统计输入和输出 token。

结果是，一个 UUID 平均约占 23 token，旁边的商品名称约占 4 token。在这组短名称列表里，ID 占了约 80% 的输入。模型还没开始判断商品是否匹配，就先读了大量没有商品含义的字符。

输出也要付钱，而且通常比输入贵。原文称输出单价往往是输入的五六倍；在作者使用的 GPT-5.6 价格中，恰好是六倍。

下面的代码把实测 token 数代入价格，比较每月 30 万次调用的费用：

PRICE_IN, PRICE_OUT = 2.00, 12.00   # GPT-5.6 list price, $ per 1M tokens
MONTH = 300_000                     # 10,000 queries a day for 30 days

for name, tin, tout in [("UUID", 1439, 72), ("list index", 336, 9)]:  # measured
    cost = (tin * PRICE_IN + tout * PRICE_OUT) / 1e6
    print(f"{name}: ${cost:.6f}/call  ${cost * MONTH:,.2f}/month")

重点看循环里的两组数据：UUID 方案是输入 1439、输出 72 token；编号方案是输入 336、输出 9 token。按代码计算，月费用分别为 1122.60 美元和 234 美元，相差 888.60 美元，也就是原文取整后的 889 美元。

这里的价格是作者从其参与开发的 LLM gateway 目录中取得的、标注日期为 2026 年 11 月 9 日的厂商公开价。它解释了这笔账怎么算，不应直接当成读者实际账户的结算价格。

作者还列出 GPT-5.6-mini 的月费用约为 112 美元与 23 美元，倍率同为 4.80；Claude Haiku 5.5、Claude Sonnet 5.5 和 Gemini 3.8 Flash 则为 4.72 倍。不过，原文没有展开这些模型各自的完整统计过程。

让模型返回编号，把真实 ID 留在程序里

模型需要的是能选中商品的标记，真实数据库主键可以留在应用代码中。

作者的办法是为本次候选列表从 1 开始编号，同时在代码里保留编号到真实 ID 的映射。模型返回编号后，应用再还原主键。

下面这段代码完成列表构造、映射和结果解析：

import json

def build_listing(rows):
    """rows: list of (real_id, name). Returns prompt text and index -> real_id map."""
    lines = [f"{i} | {name}" for i, (_, name) in enumerate(rows, start=1)]
    return "\n".join(lines), {str(i): rid for i, (rid, _) in enumerate(rows, start=1)}

def parse_answer(answer_text, index_map):
    picked = [str(x) for x in json.loads(answer_text)]
    return [index_map[p] for p in picked if p in index_map]   # drop unknown numbers

listing, index_map = build_listing([("89fa6a68-8fb5-427b-beb7-99193f22faf8", "cable box"),
                                    ("62801c45-1043-4a10-98ae-43346c12ace8", "desk lamp")])
print(listing)
print(parse_answer('["1", "7"]', index_map))   # "7" isn't on the list, so it's dropped

要看的是 if p in index_map：返回值必须属于当前候选列表。示例中的 "7" 没有映射，因此被丢弃。映射只服务于一次请求，不必持久化保存。

这段示例仍有边界：它会静默丢弃未知编号，没有处理非法 JSON，也没有完整检查返回结构。原文结尾建议把列表外的值视为错误，实际接入时，需要明确选择报错、重试还是接受部分结果。

短编号还减少了逐字符复制的负担。UUID 方案中，即使只返回三个 ID，也用了 72 个输出 token，占该次 GPT-5.6 调用费用的约 23%。至于复制错误是否更少，作者没有测量，不能据此承诺准确率提升。

我的判断

这个优化值得采用的前提很清楚：候选项由程序提供，编号只在当前请求内使用，模型的任务是从中选择。它改动小，也不需要更换模型。

但 4.8 倍是这组提示词的结果，不是所有列表任务的固定收益。 作者刻意使用了短商品名，ID 才会占据如此大的比例。如果每件商品附带一段描述，编号替换节省的比例就会下降。原文关于不同厂商倍率接近的结论，也不能直接推广到所有提示词和分词器。

与直接使用数据库整数主键相比，临时编号还需要维护一次映射。作者给出的数据库整数方案费用倍率为 1.35 倍，可作为暂时无法修改提示词格式时的折中，但没有详细展开其数据分布。

跨轮对话、agent 的多次工具调用，以及需要保存后再读取的结果，则需要稳定 ID。此时短整数键或 cable-box 这样的 slug 更合适，单次列表编号不能脱离原请求使用。

此外，校验只能发现不存在的编号。模型把正确答案选成另一个合法编号，映射照样成功。成本下降有统计支撑，选择质量是否变化仍需要单独验证。

能拿来做什么

• 检查现有的商品筛选或列表匹配提示词，分别统计真实 ID 和临时编号下的输入、输出 token，再用实际结算价格计算收益。
• 在 Node 服务中构造候选列表时，同步建立本次请求的编号映射，解析模型结果后校验编号，再转换成数据库主键。
• 明确列表外编号的处理方式，并补上 JSON 解析和返回结构检查，避免示例中的静默过滤掩盖异常。
• 如果结果需要跨轮引用或保存后使用，优先评估稳定的短整数键或 slug，确保后续仍能定位到同一条记录。