你让 AI 根据一次客户通话写复盘。最省事的办法，是把整份通话记录直接塞给它。但一份记录可能超过 7 万字符；不同团队每做一次总结，都要重新寻找、读取和消化同一批材料。dbt Labs 的新实验想回答一个朴素的问题：如果先把资料整理好，再交给 AI，究竟能省下多少时间和钱？
这里的关键词是“上下文工程”（Context Engineering）——有组织地挑选、整理并提供模型完成任务所需的资料。它不改变 AI 要做什么，而是改变 AI 开工前拿到什么。本文所有实验结果均来自 dbt Labs 自家博客，尚无独立复现。
同一项任务，连续跑 80 次
dbt Labs 为一项内部 AI skill——预先包装好、让 AI 完成特定任务的指令——设计了对照实验。研究者用四种方式获取同一客户的上下文，共运行 80 次，并比较成本、速度和输出质量。实验采用真实客户数据。
团队此前的做法，是让 AI skill 通过 Gong、Salesforce 或 Slack 等供应商提供的 MCP connector 直接取资料。MCP connector 可以理解为 AI 调用外部系统的接口。但这种方式有三个麻烦：整个组织共享 API 调用额度；接口提供的检索条件可能不够；不同技能还会重复编写相似的查找逻辑。
例如，dbt Labs 称 Gong 的 MCP 当时不能按客户名称查找通话。AI 只能翻看某一天的多场通话，甚至去其他系统交叉核对。把完整记录搬进自家数据仓库后，客户名变成了可直接查询的字段。仅仅让资料更好找，就意外节省了约 14%，即使文本本身并没有缩短。
先消化一次，再反复使用
更进一步的方案，是在数据仓库里先生成 engineered summary，也就是按任务需要制作的工程化摘要，再通过 dbt MCP 提供给 AI。数据仓库是企业集中保存和分析数据的地方；仓库内建 AI，则允许数据团队直接在那里压缩会议记录。
这像是先把一摞会议材料整理成索引清楚的简报，以后每位同事都读简报，不必各自重翻原件。dbt Labs 此前称，这种做法把 Gong 转录数据量缩小了 20 倍，并将单次分析消耗的 token 从数万降到数百。Token 是模型读取和生成文字的计量单位；输入越长，通常费用越高、处理也越慢。需要注意，数据量缩小 20 倍与 token 的变化是两个不同指标，不能直接画等号。
在这次 80 次运行的实验中，dbt Labs 报告：通过 dbt MCP 提供工程化摘要，相比其对照方案，成本降低 48.5%，运行时间缩短 43.2%。工程化摘要保留了完整转录中的多数日期、数字和后续行动，但漏掉了一些已经作出的决定和职位名称。
便宜和完整，不是同一件事
实验里还有一个很能说明问题的对比。Gong 自己生成的 brief 只有约 500 至 600 个字符，是最短、最快的版本；但在 20 次运行中，它一次也没有带回通话里的具体日期、数字、职位、决定或下一步，只反复提到五种工具中的一种。
dbt 自制的摘要则刻意保留每通约 1.2 万至 2 万字符。它留住了多数细节和下一步，却在“已经作出的决定”这一项上连续 20 次遗漏。换句话说，摘要不是越短越好，也不是做得更长就自然完整。上下文工程真正要优化的是：哪些内容必须留下，哪些可以丢弃，以及资料怎样才能被准确找到。
为什么这组数字值得看
关于上下文工程的讨论常停留在经验判断：少给模型一些无关材料，应该更省钱、更快。dbt Labs 的价值在于把这个判断放进了同一技能、重复运行的对照实验里。反复测试可以减少某一次输出偶然偏快或偏慢造成的误判，也让成本、时间与信息损失能够放在一起看。
它给出的不是“压缩越多越好”，而是一份更实用的修订清单：检索条件会影响成本；摘要能明显减负；质量检查必须细到日期、数字、决定和后续行动等具体类别。
局限与未知
- 材料没有披露四种方案的完整定义、模型与版本、提示词、运行分配、成本口径、质量评分方法、误差范围和原始数据。
- 48.5% 和 43.2% 暂时无法独立复算，“成本降低”具体相对哪一种方案也不够明确。
- 这是 dbt Labs 在自身数据与工作流上的单一信源实验。真实客户数据增加了现实感，但不能证明结果适用于所有机构、MCP 接口或业务场景。