Limin Ge

12

上一章下一章

第 12 章：Token 作为项目规模的量化指标

token 是一个可以对一个项目所含信息量进行量化的一个指标，一个项目沉淀的所有资产转换为 token 的数量就是对这个项目规模的衡量。

Cover Image for 第 12 章：Token 作为项目规模的量化指标

"token 是一个可以对一个项目所含信息量进行量化的一个指标，一个项目沉淀的所有资产转换为 token 的数量就是对这个项目规模的衡量。"

延伸阅读：Context Window 的限制如何创造了基于 Token 的测量需求，参见AI 的无状态性与 Context Window。Token 规模如何影响工具选择，参见工具与 Context 选择：为什么 AI IDE 卖的是"上下文选择能力"。

1. 为什么用 Token 来衡量项目规模

在传统软件工程里，我们衡量项目规模的方式通常是：

  • 代码行数（LoC）
  • 文件数量
  • 功能模块数量
  • 团队人数

但在 AI-Native 时代，这些指标都有局限性：

代码行数方面，AI 生成的代码可能很“啰嗦”，行数多不代表复杂度高；文件数量方面，AI 倾向于生成大量小文件，文件数量不能反映真实的信息密度；功能模块数量方面，模块边界在 AI 时代变得更模糊，数量意义不大；团队人数方面，AI 让单人产能大幅提升，人数和项目规模的关系被打破了。

Token 作为一个新的量化指标，有其独特优势：

  1. 直接反映 AI 的“理解成本”
    一个项目需要多少 token 才能被 AI 完整理解，这个数字直接决定了：

    • AI 能否在一个 session 里处理整个项目
    • 需要多少轮 AI 接力才能完成一个需求
    • Context 选择策略的复杂度

  2. 统一衡量所有资产
    Token 可以统一衡量：

    • 代码
    • 文档
    • 测试用例
    • 配置文件
    • 甚至会议录音、设计稿（如果转成文本）

  3. 和 AI 的成本直接挂钩
    Token 消耗 = AI 使用成本，这个指标直接关系到：

    • 团队能否持续使用 AI
    • 哪些工具/模型适合当前项目规模

2. 1M Token 和 10M Token 的边界

根据实践经验，有两个关键的数字边界：

1M Token，是一个超小型AI-Native的团队15-30天生产的所有内容正好在这个规模左右。10M Token，则是在这个规模以内，AI-Native 方案都能带来至少 3 倍的生产力提升。

1M Token 意味着什么：

  • 一个中等规模的代码库（几万到十几万行代码）
  • 加上必要的文档和测试
  • 可以在一个“大上下文模型”（如 Gemini 100 万 token）里完整加载
  • AI 可以在一次会话里理解整个项目的全貌

10M Token 意味着什么：

  • 一个大型项目，或者多个相关项目的集合
  • 已经无法在一个 session 里完整加载
  • 必须依赖 Context 选择策略，让 AI 只关注“相关的部分”
  • 但在这个规模内，只要 Context 选择做得好，AI 仍然能带来显著的生产力提升

超过 10M Token 之后：

  • Context 选择的复杂度会急剧上升
  • AI 的准确率会明显下降（因为总是只能看到“部分上下文”）
  • 可能需要考虑“项目拆分”或“架构重构”，把大项目拆成多个 1–10M Token 的子项目

The 1M and 10M token water lines

3. 如何测量项目的 Token 规模

一个粗略的估算方式是：

  1. 代码部分

    • 把整个代码库的文本加起来
    • 按照“1 token ≈ 4 个英文字符”或“1 token ≈ 1.5 个中文字符”估算
    • 或者直接用工具（如 tiktoken）精确计算

  2. 文档部分

    • 把所有 markdown、文本文档加起来
    • 同样按 token 比例估算

  3. 测试部分

    • 测试代码和测试数据
    • 如果测试用例很多，这部分可能占很大比例

  4. 其他资产

    • 配置文件、SQL schema、API 文档等
    • 如果项目里有“会议录音转文字”“设计稿转文字”等，也要算进去

实际测量建议：

  • 可以用脚本定期扫描整个代码库，计算总 token 数
  • 关注 token 数的增长趋势，而不是绝对数字
  • 如果发现 token 数增长过快，要思考：是不是文档/测试写得太多了？是不是代码重复度太高？

4. Token 规模对工程实践的影响

在 1M Token 以内：

  • 可以相对“奢侈”地使用 AI
  • 可以让 AI 读整个代码库，做全局性的重构和优化
  • 文档可以稍微“冗余”一点，因为 context 空间还够用

在 1–10M Token：

  • 必须开始关注 Context 选择
  • 文档要更精简，只保留“快照式”的高层文档
  • 代码要更模块化，让 AI 可以“只看相关模块”就能工作

超过 10M Token：

  • Context 选择成为核心瓶颈
  • 可能需要引入“项目索引”“符号索引”等更复杂的机制
  • 或者考虑“拆分项目”，把大项目拆成多个独立的小项目

5. 实际决策建议

在一个两人小团队、强依赖 AI 的前提下，可以这样使用 token 指标：

  1. 定期测量项目的 token 规模

    • 每月或每季度测量一次
    • 关注增长趋势，如果增长过快，要分析原因

  2. 根据 token 规模调整策略

    • 1M 以内：可以“粗放”一点，让 AI 多读一些上下文
    • 1–10M：开始关注 Context 选择，精简文档
    • 超过 10M：考虑项目拆分或架构重构

  3. 用 token 规模评估工具/模型选择

    • 如果项目在 1M token 以内，可以直接用 Gemini Web（100 万 token 上下文）
    • 如果超过 1M，可能需要 Codex/Cloud Code 这类“符号索引 + 智能选择”的工具

6. 小结

Token 作为项目规模的量化指标，在 AI-Native 时代有其独特价值：

  • 它直接反映 AI 的“理解成本”
  • 它统一衡量所有类型的项目资产
  • 它和 AI 的使用成本直接挂钩

1M Token 是一个“舒适区”，10M Token 是一个“临界点”。
在这个范围内，AI-Native 方案能持续带来至少 3 倍的生产力提升。
超过这个范围，就需要更复杂的 Context 选择策略，或者考虑项目拆分。

定期测量和关注 token 规模，是 AI-Native 团队管理项目复杂度的重要手段。