老样子，在分享实操方法前，我习惯先理清底层逻辑。这不仅能照顾到非技术背景的用户，对我自己也是一种锻炼——将晦涩的专业知识讲得通俗易懂，本身就是一件具有挑战的事。

计费原理

WorkBuddy 是怎么计费的？

WorkBuddy 采用**积分（Credits）**制进行计费。积分本质上是一种计量单位，用于衡量 AI 在执行任务过程中消耗的计算资源。

积分的消耗主要由以下两部分构成：

  • 输入 Token：你发送给 AI 的内容（即提问请求 + 对话历史消息 + 附带的文件内容等）。
  • 输出 Token：AI 经过思考后生成的回复内容。

同时，整体的积分消耗还受以下两个核心因素影响：

  • 使用的模型：不同模型单价各不相同。旗舰级模型能力更强，但 Token 单价更贵，消耗的积分也相应更多。
  • 任务复杂度：简单问答消耗极少；而复杂的任务（如超长文档分析、工具调用等）消耗会显著增加。

既然积分的消耗与 Token 息息相关，那我们接下来就必须要弄明白：到底什么是 Token？

什么是 Token？

Token 是大模型的“最小信息处理单元”，它不能简单等同于字数或单词数。根据语言的差异，大致的换算经验是：

  • 一个汉字通常 ≈ 1 Token。
  • 在英文中，1 Token ≈ 0.75 个单词。
  • 各类标点符号、空格及代码格式也会占用 Token。

其实你没必要记住这些换算比例。因为各家大模型使用的底层词表（Vocabulary）不同，导致最终的 Token 统计结果也会有所差异。

对于非技术用户，没必要深究 Token 的底层逻辑，只需建立一个直观的概念即可：字符越长，消耗的 Token 就越多，两者基本成正比。

明白了 Token 和字符长短的关系后，有的朋友可能会疑惑：明明每次提问文字都不多，为什么越聊到后面消耗的 Token 却越来越多？这就不得不介绍一个概念：“上下文窗口”。

理解上下文窗口

上下文窗口（Context Window） 是指大模型在单次交互中，能“装下”并处理的最大 Token 数量。

很多人容易把 AI 客户端（如 WorkBuddy）和大模型看作一个具备长期记忆的整体。但为了方便理解，今天我们需要将它们拆解来看：

  sequenceDiagram
    participant User as 用户
    participant Client as WorkBuddy客户端
    participant LLM as 云端大模型

    User->>Client: 1. 提出新问题
    Note over Client: 客户端（无大脑，负责记忆）：<br/>调取本地保存的对话内历史消息
    Client->>LLM: 2. 整体打包发送：历史消息 + 新问题 + 工具说明
    Note over LLM: 大模型（但无持久记忆）：<br/>接收数据（若超出上下文窗口限制则截断或报错）
    LLM-->>Client: 3. 经过思考，返回生成的回复
    Note over Client: 客户端将新产生的对话更新到本地记录中
    Client-->>User: 4. 向用户展示最终回复
  • WorkBuddy（客户端）：具备本地执行能力的 AI 桌面工具。它负责保存你的对话历史和任务记录，但本身并没有“大脑”。它需要将这些信息一轮又一轮地打包发送给大模型，让大模型来做决策。
  • 大模型（云端大脑）：本身无法持久记住你们的对话记录，且面临“上下文窗口”限制（如 128K、200K 甚至 1M 的窗口上限）。客户端每次发送的内容不能超过它的窗口上限，否则它将无法处理。

客户端和大模型是通过 API 进行交互的。我们通过一段常规的 API 数据结构演示，来看看客户端发送给大模型的消息到底长什么样：

{
  "messages": [
    {"role": "system", "content": "你是乐于助人的助手，叫“小猪”，你擅长..."},     // 系统初始指令
    {"role": "user", "content": "你叫什么名字？"},               // 历史提问
    {"role": "assistant", "content": "我叫“小猪”"},              // 历史回复
    {"role": "user", "content": "帮我读一下本地的报告文件"}       // 当前的新需求
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "read_local_file",
        "description": "用于读取计算机本地文件的工具，当用户需要分析文件时调用...",
        "parameters": { /* ...各种复杂参数说明... */ }
      }
    }
    // ...实际运行中，这里可能会一次性传入几十个不同的工具定义...
  ]
}

从示例数据中，你可以直观地看到两个消耗 Token 的“大户”：

  1. 历史堆积：每一次发起新提问，客户端（WorkBuddy）都会把当前任务内积累的所有历史记录，全部打包重新发送给大模型。
  2. 工具描述的冗余占用：一旦你希望 AI 能真正“干活”（比如操作文件、搜索网络等），客户端就必须把极其厚重的 “工具使用说明书” 一并发送给大模型，大模型才能知道怎么用工具。赋予它的工具越多、能力越强，但消耗的 Token 就越多。

随着对话轮数越来越多，再加上厚重的工具定义，“输入 Token” 的雪球会越滚越大，消耗呈“指数级倍增”。这就是为什么大家觉得“越聊越贵”的核心原因，同时这也为我们接下来在挑选“交互模式”时敲响了警钟。

怎么省钱？

搞懂了上述底层原理后，你就能主动把控成本，把钱花在刀刃上。

1. 减少上下文无意义堆积

  • 不相关的内容，务必新建“任务”处理 如果在进行中突然有一个与当前对话毫不相干的新需求，请务必新建对话（WorkBuddy 中称为新建“任务”）。切忌在同一个长对话里让 AI 处理不同任务，因为这会把毫无关联的历史消息都打包发给大模型，造成大量的 Token 浪费。

  • 善用 /compact 命令压缩长对话 在较长的对话中，输入 /compact 命令，系统会自动对历史内容进行总结提炼，保留核心脉络，丢弃冗余细节。这一步能大幅降低后续提问时的输入 Token。

2. 选对合适的交互模式

WorkBuddy 提供了不同的交互模式，核心区别在于 “是否需要执行实际的系统操作”。

  • Ask 模式（问答）： 纯粹的咨询分析、概念解释或头脑风暴。此模式下，AI 不会对你的文件和系统进行操作，消耗极低。
  • Craft / Plan 模式（干活）： 赋予了 AI 自主调用工具的能力，他能规划任务、生成新文件、处理工作流等。消耗会显著增加。适合需要实际交付成果的场景（如写长报告、写代码）。

敲黑板：如果你的需求只需简单的问答探讨，千万不要使用 Craft 模式。因为该模式会将庞杂的“工具定义（Tool Descriptions）”塞入提示词中，造成不必要的 Token 消耗。

3. 使用合适的大模型

WorkBuddy 支持多种模型无缝切换（混元、DeepSeek、GLM、Kimi 等），不同模型擅长不同领域，咱们应该按需使用：

  • 日常简单查询、文案、会议纪要： 选轻量/快速模型（如DeepSeek Flash、混元基础版）。速度快、成本低。

  • 办公、报告撰写： 混元或GLM，中文理解强，性价比高。

  • 复杂推理、代码/数据分析： DeepSeek Pro或对应较强模型。

  • 创意/图像相关： Kimi等。

正所谓“杀鸡焉用牛刀”，不必事事都用强的模型。另外，哪怕 Auto（自动路由）模式能自动帮你挑模型，但在你明确当前需求时，手动指定模型绝对更精准可控。

结语

本文主要梳理了对 Token 消耗影响较大的几个核心因素，目的是带你了解计费的底层机制。所谓授人以鱼不如授人以渔[来自Mona的启示]，懂了规则底层，相信你能在日常实践中，发现更多“省钱小妙招”。

毕竟，节约 Token 消耗不仅是为了给自己省钱，也能节约算力资源，为降低能耗尽一份绵薄之力。