AI 编程工具的三个隐藏成本:上下文、token 与团队协作的真实坑

从一次月底账单说起

上周财务找朋友对账，让他解释一下团队这个月在某 AI 编程平台上为什么花了将近 4 万块。朋友点开后台一看，乐了——12 个工程师，平均每人月消耗 token 折合 3000 多块。最离谱的一个同事，单月 token 用量是中位数的 6 倍。

朋友一开始的反应是：哦，这哥们儿用得猛，效率应该爆表。结果一看产出，提交的 PR 数量、代码行数、Bug 修复数全都在团队中位数以下。再翻聊天记录，他和 AI 的对话动辄几十个回合，一个简单的 CRUD 接口能让 AI 重写七八版。

从这个故事我意识到一件事：用 AI 编程工具的成本，从来不只是 API 账单。token 的钱是显性成本，但还有一些藏得更深的东西，正在悄悄吃掉团队的效率红利。今天聊三个我和团队这半年踩过的坑，希望对正在大规模铺 AI 工具的同行有点参考。

坑一：上下文不是免费的

「全文塞进去」是个昂贵的错觉

大多数 AI 编程工具都鼓励你把整个项目目录、相关文档、历史 PR 都喂给模型，美其名曰「上下文越全，效果越好」。这个说法对，但只对了一半。

我让团队做过一次实验。同一个任务——给现有 Spring Boot 服务加一个分页查询接口——分三组：

A 组：把整个 service 模块（约 8 万行代码）都加入上下文；
B 组：只加入 Controller、Service、Repository 三个目录（约 1.2 万行）；
C 组：只加入相关的 5 个文件加一个 README（约 800 行）。

结果出乎意料：

看明白没？上下文不是越多越好，而是越准越好。A 组反而最慢、质量最低、token 消耗最大。原因很简单——大量无关代码会稀释模型注意力，模型容易被某个相似但不相关的实现误导，写出风格不统一的代码。

怎么做精准上下文

我后来给团队推了一个简单的 .aiignore 规范，类似 .gitignore，但用来告诉 AI 工具哪些目录不要纳入默认上下文：

# .aiignore - 默认不纳入 AI 上下文

# 自动生成的代码
**/build/
**/generated/
**/*.pb.go
**/*Generated.kt

# 第三方依赖与历史包袱
node_modules/
vendor/
legacy/
deprecated/

# 测试夹具与大数据
**/testdata/*.json
**/fixtures/large_*

# 文档站全量构建产物
docs/_site/

另外配一份 CONTEXT.md 放在项目根目录，里面写明：

# CONTEXT.md - 项目地图（喂给 AI 用）

# 核心目录
- api/        : OpenAPI 定义
- service/    : 业务逻辑层
- repository/ : 数据访问层
- internal/   : 内部工具

# 关键约定
- 错误返回统一用 errx.Wrap
- 时间字段统一用 time.Time UTC
- 数据库字段命名 snake_case
- HTTP handler 不直接调 SQL

# 不要碰
- migrations/ 不要让 AI 改
- crypto/ 内的密钥派生函数

# 修改某模块时，建议同时阅读
- service/order/ → repository/order/
- api/v2/* → docs/api-v2.md

这两个文件加起来不超过 200 行，但能让 AI 工具的回答质量肉眼可见地稳定下来。我们的 token 消耗在三周内降了 40%，团队里之前那个用得最猛的同事，现在和大家用量持平，但产出反而变多了。

坑二：Token 预算需要工程化管理

免费心态会反噬

AI 工具刚铺开的时候，公司是统一买单的，工程师不需要为每次调用考虑成本。这听起来很美好，但实际效果是——大量的「无效会话」开始堆积。

我看过一个工程师为了写一个正则表达式，跟 AI 来回 15 轮，每次都「不太对，再改改」。如果他自己花 5 分钟写一遍，可能比这 15 轮还快。但因为不花他自己的钱，他就没有任何「停下来想一想」的动机。

说实话，我最开始也不信「免费会反噬」这个说法，觉得只要产出值就行。但后来盘账发现，团队里每月 token 消耗的前 20% 用户，他们的实际产出贡献只占 25%——也就是说，token 消耗和产出几乎是完全脱钩的。

个人配额 + 软提示

我们后来上了一个简陋但有效的预算管理工具：每个工程师每月有一个软配额（比如 200 万 token），用到 70% 时弹个提示，用到 100% 不会硬停，但会触发一次自我复盘——把当月的高消耗会话列出来，让本人勾选「哪些是真有价值的」「哪些其实可以本地搞定」。

这个动作不需要打分、不需要扣钱，它只是让人意识到自己在花钱。结果是团队的人均月消耗从 350 万 token 降到了 180 万，产出基本不变。

核心代码很简单，就是个埋点 + 聚合：

# budget_tracker.py 简化版
from dataclasses
    import dataclass
from datetime
    import datetime
import redis

@dataclass
class Usage:
    user_id: str
    session_id: str
    prompt_tok: int
    completion_tok: int
    cost_cny: float
    ts: datetime

class BudgetTracker:
    def __init__(self, r: redis.Redis):
        self.r = r
        self.quota = 2_000_000

    def record(self, u: Usage):
        key = f"tok:{u.user_id}:
            {u.ts:%Y-%m}"
        total = self.r.incrby(
            key,
            u.prompt_tok
            + u.completion_tok,
        )
        if total > self.quota * 0.7:
            self._notify_soft(
                u.user_id, total)
        return total

    def _notify_soft(self, uid, t):
        # 发飞书提示，不阻塞
        pass

就这么个东西，跑了一个月后，团队对「上下文该塞多少」「该不该让 AI 重写第 5 次」这些问题，开始有了直觉。意识到成本，是工程师变自律的第一步。

坑三：团队协作里的「AI 沉默税」

谁知道这段代码是怎么来的？

这是个更隐蔽但杀伤力更大的问题。半年前，我们一个负责支付模块的同事突然离职，交接的时候我接手了他的代码。看了三天，我发现一个尴尬的事实：

有大约 30% 的代码，他自己也讲不清楚为什么这么写——因为是 AI 生成的，他当时看着合理就提交了，没留任何 design doc 或者 commit message 的解释。

等我去问他细节，他的回答清一色是：「当时 AI 给的方案，我跑通了就合了。」我问那为什么这里用了重试 3 次而不是 5 次？他说不知道，AI 默认就这样。我问那个状态机为什么这样转？他说也不知道，反正测试过了。

这就是我说的「AI 沉默税」——AI 把代码写出来了，但代码背后的「为什么」并没有进入团队的知识库。维护成本 100% 落到下一个接手的人头上。

让 AI 顺手写「为什么」

我们的解法是把 AI 工具的提示词模板里硬性加一条：每次生成超过 30 行的代码，必须同时输出一个简短的 design rationale。这部分内容直接写到 commit message 或者代码顶部注释里。

不是花架子，举个真实的例子。改造后的 commit 长这样：

feat(payment): add idempotent
    retry for callback handler

Why:
- 第三方回调存在重复推送问题，
  线上日均出现约 0.3% 重复
- 之前用 unique 索引拦，但
  数据库压力较大，p99 抖动

How:
- Redis SETNX 做幂等键，
  TTL 24h（业务保留窗口）
- 失败时降级到 DB 唯一索引

Trade-off:
- Redis 不可用时会回退到
  DB 唯一索引，可能短时
  抖动，但保证不重复处理
- 不用消息队列去重是因为
  现有 MQ 不支持 exactly-once

[ai-assisted: claude-3.7,
  reviewed by zhangsan]

这种 commit 看着累，但未来某个新人接手的时候，他会感谢现在写这个 commit 的你。我们团队推了 3 个月以后，code review 的争议明显变少——因为大部分「为什么这么做」的问题，commit 里就答完了。

另外有个意外的收获：写 design rationale 这件事本身，会逼着 AI 用户自己想清楚再合代码。讲不清「为什么」的代码，他自己也会犹豫要不要合。这个机制比代码 review 兜得还前。

一个简易的成熟度自查表

聊到这儿，给个我自己用的团队 AI 工具成熟度自查表。每个维度三档，对照看看自己现在在哪一档：

说实话，我们团队目前在「成本意识」和「知识沉淀」上算是 🥇，但「质量监控」还停在 🥈，AI 代码的覆盖率单独跑指标这件事我已经规划了两个月，一直没排上。

最后一点小思考

这半年带团队铺 AI 工具，我最大的感受是：AI 工具本身没有问题，问题永远在使用它的工程文化上。

那个一个月烧 18000 块的同事，并不是恶意挥霍，他只是没有「成本意识」这根弦——以前写代码不消耗 token，他从来不需要想这件事。同样的，那些写完不留 design rationale 的工程师，也不是偷懒，他们只是还没意识到「AI 写的代码也是自己的代码」。

所以铺 AI 工具，买工具是 5% 的工作，剩下 95% 是建立配套的工程文化和反馈机制。.aiignore、CONTEXT.md、token 配额、design rationale，这些东西单看都很不起眼，但它们是把 AI 从「玩具」变成「生产工具」的脚手架。

你们团队在用 AI 工具的过程中，踩过哪些「不算技术问题但又恶心人」的坑？欢迎评论区分享，我打算下个月专门整理一篇团队反馈的合集。