企业团队通过组合四项实践来降低智能体式开发工作流中的 token 用量：消除低效网络搜索的结构化文档访问、避免高成本修正迭代的领域专属技能、用于非推理任务的确定性工具，以及在工作流各阶段有意识地选择模型层级。高效使用 AI token 并非减少 AI 的使用，而是把 AI 用在能带来回报的地方。
即将到来的定价拐点
智能体 AI 的经济模式即将发生变化。 GitHub 宣布，所有 Copilot 方案已于2026年6月1日起转为按使用量计费——按使用量计费已成为各大代码智能体服务商的默认模式。各方案将不再是覆盖无限用量的固定月度席位费，而是包含每月一定额度的 AI 额度，输入、输出及缓存 token 的消耗均按公开费率计入该额度。智能体会话已成为团队使用 Copilot 的默认方式，其算力成本早已超出最初固定价格模式所能支撑的范围，GitHub 不再承担这部分成本。
此前，Anthropic 也曾宣布，从2026年6月15日起，Claude 订阅将拆分为交互式与程序化两个额度池，智能体及自动化用量将转入按 API 费率计费的独立月度额度体系——但随后暂缓了这一调整。对企业团队而言，实际约束并未因此放宽：Claude 用量仍按会话、周、模型分别设有上限，高强度的智能体式工作流依然会触及这些上限。
用标准订阅无限制运行高成本智能体会话的时代正在结束。各大 AI 服务商的发展方向趋于一致：成本将越来越直接反映实际 token 用量，大规模运行智能体式开发工作流的企业团队将直接感受到这一变化。
对于使用 Qt 构建嵌入式设备软件的企业而言，现在正是评估这一问题的合适时机。
智能体式开发在编写、评审、编写文档以及测试 Qt 代码等环节都能提升效率，其价值显而易见，因此问题并不在于是否该使用智能体 AI，而在于每一个环节都会消耗 token，成本会在整个团队范围内累积。目标是让每一个 token 都发挥出应有的价值。过去几个月，Qt 团队一直在构建并发布一套智能体式开发技能和一项文档服务，专门用来让这些工作流更精简、更准确、更具成本效益。本文分享了我们的经验，以及企业团队现在就能采取的举措，在不放弃智能体式开发本身价值的前提下控制相关成本。
结构化文档访问如何降低 AI token 用量
结构化文档访问只返回 Qt API 参考文档中的相关摘录，而非包含导航栏、侧边栏及无关内容的完整 HTML 页面，由此降低 AI token 用量。单次查询所消耗的 token 仅为同等网络搜索的一小部分，同时为智能体保留更多工作上下文用于实际编程任务。
每当 AI 智能体在网络上搜索 Qt API 信息时，得到的都是完整的 HTML 页面：导航菜单、Cookie 提示栏、相关文章侧边栏，以及可能对应更早 Qt 版本的论坛帖子。仅针对 Qt 模型-视图架构这类具体行为进行一次网络搜索，就可能在智能体读到任何一句有用文档之前消耗数千个 token。将这一成本乘以一次典型智能体式编程会话所需的数十次 API 查询，费用会迅速累积。
Qt 于2026年5月发布的文档MCP，作为AI 驱动开发工具的一部分，直接解决了这一问题。它不再抓取完整 HTML 页面，而是为 AI 智能体提供对 Qt 权威 API 参考文档及指南的结构化、针对性访问，只返回相关摘录而非整页内容。实际使用中，通过该服务进行单次查询所消耗的 token 仅为同等网络搜索的一小部分，为智能体保留更多工作上下文用于实际编程任务，并消除了困扰 Stack Overflow 等社区论坛答案的版本不匹配问题。
不仅如此，每一条回答都直接来自 Qt 官方维护的文档，而非可能针对旧版本 Qt 撰写的社区帖子。智能体获得的正是 Qt 实际发布的内容：类参考、属性表、信号与槽说明、枚举值，以及官方支持的用法示例。在重视代码可追溯性的受监管行业中，这不仅是效率上的提升，更是正确性的保证。
领域专属技能消除高成本的智能体式迭代
让通用 AI 智能体编写 Qt UI 代码时，得到的结果乍看之下能够运行，但也会出现一类可预见、本可避免的错误——布局属性混用错误、遗漏无障碍访问要求、针对特定目标硬件做出欠佳的 UI 设计决策，或是产出通过评审却在运行时出现性能问题的代码。这些问题单独来看都不算致命缺陷，但每一个都需要一次追加提示、一次修正以及新一轮推理——而这些用于修复错误的 token，本可通过领域知识提前避免。
Qt 不断扩充的智能体式开发技能套件直接解决了这一问题。UI 编程、UI 设计、代码评审、文档编写、测试生成以及性能分析等技能，各自内置了一套经过筛选的 Qt 专属知识，供智能体在任务执行过程中而非事后应用。这些技能共同构成了面向企业级 Qt 团队的、具备领域感知能力的智能体式开发环境。
这一差异在实践中是可以量化的：在 QML100 编程基准测试中，Qt 的编程技能将某前沿模型的成功率从64%提升至75%——这11个百分点的提升，同时意味着修正轮次减少11%，进而使工作流中编程环节所消耗的 token 减少11%。每一次被避免的修正，不仅是质量上的提升，在按使用量计费模式下更是直接的成本节约。
确定性工具降低对高级 AI 模型的依赖
许多人认为智能体式 AI 工作流的每一步都需要用到能力最强、成本最高的模型。但实际上，软件开发中的许多关键任务本质上是模式匹配与执行，更适合交由确定性工具处理，而非依赖 AI 推理。
Qt 的代码评审技能就是一个具体例子。C++ 与 QML 评审流程的第一阶段，都是在 AI 智能体介入之前，对范围内所有文件运行一次单次遍历的自动化静态检查工具（linter）。该 linter 以机械方式检查超过100类规则——从 include 顺序、已弃用 API 的使用，到错误处理模式与生命周期正确性——整个过程不消耗任何 AI 推理 token。只有在这一确定性阶段完成之后，专项分析智能体才会介入，此时表层问题已经得到处理。UI 性能剖析遵循同样的逻辑：性能技能调用 Qt 自身的性能分析工具采集时序数据，再将结构化输出交由 AI 解读——而不是要求 AI 直接从原始源代码推理性能问题。
测试执行遵循相同模式。Qt 的测试运行技能并不要求 AI 智能体解读测试输出，而是使用内置脚本解析标准化测试结果文件，提取通过与失败的数量，识别耗时最长的测试用例，并标记可能的回归问题。AI 只接收一份清晰、结构化的报告，无需处理原始输出，也无需对测试基础设施进行推理。
对企业团队而言，这带来的实际意义是：在确定性预处理阶段已经完成机械性工作的工作流环节，可以降低所使用的模型层级。这正是 AI 成本优化的体现——用成本较低的模型汇总确定性工具产出的 linter 结果，用标准模型完成报告整合，而将高级模型保留给真正需要更大工作上下文和更强能力的推理密集型任务，例如架构分析和跨文件语义推理。
什么情况下这笔成本是值得的
当 AI 推理所替代的人力活动成本更高时，较高的 AI token 成本就是合理的。例如，Qt 的智能体式代码评审比简单任务消耗更多 token，但能在几分钟内发现真实问题，相比之下两名工程师每次评审需要花费数小时。AI 推理成本必须对照所替代的人力投入来衡量，而不能孤立看待。
智能体式开发工作流中的每一个环节，并非都以不惜代价压低 token 用量为目标。有些任务在 AI token 上开销较高，但因为省去了成本更高的人力活动而具有合理性。例如，在嵌入式软件中代码评审本身就是资源密集型工作，尤其是在汽车、工业自动化和医疗设备等强制要求充分同行评审的受监管行业中更是如此，需要经验丰富的工程师花费数小时审查代码的安全性、线程处理以及 Qt 用法是否得当。这一成本本身很高，并且会随团队规模和发布频率的增加而上升。
相对于较简单的智能体式任务，Qt 的代码评审技能在 AI token 上的开销较高。它会对 C++ 与 QML 代码运行超过100项自动化检查，随后并行启动多个专项分析智能体，每个智能体分别审查一个独立的质量维度，例如内存所有权、线程安全、API 正确性、错误处理与性能。对跨多个文件的重大变更进行评审，需要相当可观的推理量。
但需要考量它所替代的是什么。一次全面的多智能体代码评审能在几分钟内发现真实问题并给出具体的缓解建议，几乎在任何成本指标上，都优于两名工程师花费两到四小时手动完成同样工作。完成一次全面评审所需的 AI 推理成本，仅相当于资深工程师小时费率中的一小部分。与一次性的人工评审不同，智能体式评审可以在开发者每次提交前检查变更时随时运行，而不局限于正式的评审节点。
尽管如此，token 成本与人力投入是相互关联的：token 效率最高的流程，并不一定是整体成本效益最高的流程。团队应将 token 效率对照所替代的人力投入来衡量，而不是作为一个绝对指标。某项技能可能消耗更多 token，但能节省大量工程时间，因而具有很高的价值。借助这类技能，人工代码评审仍会产生成本，但可以变得更聚焦、更快速。
自主性与可控性：该由 AI 自行决定何时调用技能吗？
自主调用技能能够发现开发者可能忽略的问题，但 token 消耗难以预测。人工触发的命令只在开发者判断相关时才启动技能，从而让成本保持可预测。混合模式——轻量级技能始终启用，较重的分析由明确指令触发——对于需要大规模管理 AI token 用量的企业团队而言效果良好。
每个采用智能体式开发的团队都会面临一个选择：应该由 AI 自行决定何时调用技能，还是应该由开发者通过明确指令来触发技能？这两种方式的成本特征并不相同。
自主触发之所以有吸引力，是因为它能自动判断何时运行代码评审或设计审查，发现开发者可能忽略的问题，并简化工作流程。这使质量检查更加一致，也减少了对人工记忆的依赖。
支持人工触发命令的理由在于成本可控与可预测性。智能体自行决定运行多智能体代码评审时，可能恰好作用于开发者本就打算修改的在途变更，导致 token 与评审结果的重复消耗，而这些结果开发者要么忽略、要么再次处理。人工触发能确保技能只在开发者认为相关时才被激活，而不是在智能体做出模式匹配判断时就启动。
这两种方式都不是普遍适用的最优解。token 预算充裕、且偏好自动化的团队，会倾向于在合理防护机制下采用自主触发——例如在每次代码生成时被动运行一个轻量级代码质量技能，但只在明确的提交评审请求下才运行完整的多阶段代码评审。而对自动化分析何时运行、为何运行有严格成本控制或合规要求的团队，则会更倾向于带审计留痕的明确指令触发方式。
混合模式行之有效：轻量级、低 token 消耗的技能在代码生成过程中持续运行，以较低成本带来即时收益；而代码评审、测试生成以及设计令牌提取等较重任务则由人工触发。这种方式既能维持较低的基线成本，又能让人工对高成本的分析环节保有监督权。
坦诚面对局限：当前这一代技能尚做不到什么
自 2026 年 4 月以来，我们关于 Qt 智能体式开发技能的系列博客文章一直如实记录着相关的局限与成效。
输出质量会因模型不同而有所差异，也会受到智能体工作上下文被其他任务占用程度的影响。当前沿模型将全部注意力集中在单一任务上时，其技能输出质量明显优于较小模型，也优于工作上下文已被大型代码库占满的前沿模型。例如，测试生成技能在针对单一、聚焦的组件时能产出充分的覆盖，但如果一次性对数十个文件调用，可能只会产出流于表面的模板化覆盖——因为智能体的注意力被过度分散，无法对每个文件进行细致推理。
这些局限并不意味着这些技能不值得使用。它们说明的是，这些技能最适合作为整体软件开发流程中的一个环节，而不能完全取代人工评审、专门的静态分析工具以及架构层面的把控。真正从 Qt 智能体式开发技能中获益最多的团队，正是理解这一点并据此加以整合的团队。
展望未来：token 经济学将重塑技能与服务的构建方式
按用量计费的模式已经在重塑 Qt 及整个生态系统设计智能体工具的方式。管理智能体 AI 成本，如今已与功能正确性一样，成为一项核心设计标准。
三个方向尤为突出。分层模型调用会将机械性、格式化工作交给轻量模型处理，而将更强能力的模型留给深度推理，从而在不牺牲分析类任务质量的前提下，降低确定性任务的推理成本。Qt 的代码评审技能已经体现了这一方向：自动化 linting 以零 AI 推理成本处理机械性检查，之后才由专项分析智能体介入。
对领域知识的结构化访问，将不再局限于文档本身。对发行说明、重大变更日志以及平台兼容性数据的有序访问，将使智能体能够回答 API 稳定性和迁移相关问题，而无需在过时的社区讨论中搜索网络、白白消耗 token。
增量式、具备上下文感知能力的分析方式也即将出现。一项能够跟踪自上次运行以来发生变更的文件、而非重新评审整个代码库的评审技能，在大多数文件在两次变更之间保持稳定的项目中，可将分析成本降低一个数量级。
更大的转变是文化层面的。那些最有效管理智能体 AI 成本的团队，并不是使用更少的技能，而是清楚自己工作流中哪些部分能从 AI 推理中获益，哪些部分更适合交给确定性工具、结构化知识服务或人工判断来处理。Token 效率的关键不在于减少使用 AI，而在于——该用时用对 AI，不该用时不硬塞给它。
Qt Development插件将这些技能与 Qt 的文档 MCP 打包在一起，可直接从 Claude Marketplace 获取——搜索 "qt-development" 即可找到。
