用 AI 编程越用越累？你的问题不是模型，是把「生成」和「验证」搞反了

症状

我交过最贵的一次「学费」，是一个半小时的 bug 定位。

当时一个诡异的偶发失败，我懒得换模型，让一个便宜的模型去查。它很勤快：翻日志、查调用链、列可能原因，每次都说「可能是这里」，我每次都得停下来验证它说的对不对。二十分钟一轮，三轮下来，我已经被它带偏了三次。最后我换了个顶配模型，它把同样的上下文重读一遍，两分钟给出定位：「第三层缓存没做失效，命中旧值。」

问题在于：定位是验证型的活，我让便宜的模型干；修复才是生成型的活，便宜模型反而够用。我整个用反了。时间、钱、耐心，三样全亏。

后来我反复琢磨这件事，发现这不是一次失误，是大多数刚把 AI 编程用起来的人都会踩的同一个坑。我见过同事把 AI 当搜索引擎用：把报错贴进去，AI 解释了，复制官方文档的做法，跑不通；再问，再跑不通。一上午过去，他得出结论：「AI 编程都是吹的。

」我也见过反过来的：一个朋友用 AI 写代码，写完基本不 review 直接提交，直到某次 AI 把「删除」写成了「覆盖」，而他的测试断言只查了状态码，测试还绿着。

如果你也有这种感觉——AI 好像让一切变快了，但我的时间一点没省，甚至更累了——这篇是写给同类人的。它不是工具教程，是几个在真实项目里把 AI 编程用起来的人，用各自踩过的坑换来的共识：你的问题不是模型不够好，是节奏错了。

原因

先立一条第一性原理：生成便宜，验证贵。

AI 生成一行代码，几毫秒、几分钱；验证这行代码对不对——读进去、理解上下文、判断边界、想清楚它会怎么坏——花的是你这个人最贵的资源：注意力和时间。所以 AI 编程的总账是这样算的：

总成本 = 生成成本（越来越便宜）+ 验证成本（你的时间，一分没少）

谁承担验证，谁就是成本中心。把验证推给「看起来挺对」，省下的每一秒，都会在以后的 bug 里加倍还回来。

顺着这条原理，几乎所有「越用越累」的现象都能解释：

• 顺序反了。正确节奏是「我先想 → AI 跑 → 我验收」。大多数人实际是「AI 先跑 → 我再看」：AI 已经生成了几千行，你才开始判断这是不是你要的东西——等于把最贵的验证工作，放在最坏的时间点做。
• 模型用反了。验证型任务（定位 bug、审查、把关）用了便宜模型，生成型任务（按需求写、批量改）用了贵模型。成本错配：便宜模型看不清，你反复替它验证；贵模型在「生成」这种不值得花钱的地方烧钱。
• 上下文不是免费的。每往 prompt 里加一句话，都是此后每一轮对话都要支付的成本；常驻上下文越长，缓存命中率越低。有人把 2 万行日志直接糊进去问「为什么报错」，等于一上来就把窗口打爆，然后抱怨模型「记不住」。
• 半吊子水平。Prompt 写两句就完事，业务规则讲不清楚，测试和可观测性基建懒得搞。AI 时灵时不灵，今天跑通明天就废——这真不能怪 AI，是地基没打。

解法

下面每条经验都按「现象 → 做法 → 为什么」展开。它们不是一家之言，而是多篇独立实践里反复出现的共识。

经验 1：先给任务分类——生成型用便宜模型，验证型用最贵的脑子

现象：我一开始也把贵模型当「周末才舍得开的好车」供着，平时让便宜模型干活。结果便宜模型看什么都「挺好」，等于没验。

做法：把活分成两类：生成型——按需求写代码、批量改造、出素材，中档模型是主力：快、便宜、错了重来的成本低；验证型——代码审查、质检、定位疑难 bug、创作把关，上最高档，别省。

为什么：改 bug 是最容易用反的地方，因为它其实是两个动作：定位是验证型，修复是生成型。定位要全库找线索，读的比写的多，得用贵的；定位清楚之后的修复常常就改三行，便宜模型绰绰有余。大多数人正好反着来：便宜模型定位半天定不着，火了，换贵模型从头再排一遍——两头的钱都花了，跟我的那次「学费」一模一样。

经验 2：让「我先想，让 AI 跑，我检查」成为肌肉记忆

现象：面试 AI Coding 相关的岗位时，我最怕听到候选人把 AI 聊得像新闻联播：上下文窗口、推理模型、多模态、MCP，一个词接一个词。一问「你自己平时怎么用 AI 写代码、怎么判断它写得对不对」，马上开始虚。

做法：判断一个人是不是真的会用 AI，就看一句话：他的回答里是否自然出现「我先想，让 AI 跑，我检查/判断」的节奏。同样觉得模型慢：「模型慢了？换个快的」是观众；「慢在读上下文还是推理还是输出？prefill 慢就精简上下文，推理慢就关推理，decode 慢就限制输出」才是驾驶员。

为什么：一个人懂不懂 AI，不是看他能说出多少模型名字，而是看他能不能把 AI 装进自己的工程流程。AI 是执行者，不是决策者；你把决策权交出去的那一刻，效率就归它管了——而它没有你的上下文。

经验 3：验证要有「断什么」，不是「跑没跑通」

现象：用 AI 写测试时，它默认输出的断言是这样的：assert resp.status_code == 200。接口通了，测试绿了——但业务对吗？订单金额算对没？优惠叠加的顺序对没？积分发对没？全都没断。

做法：真正要断的是业务结果，不是接口状态。比如促销「满 300 减 50、会员 8 折、叠加 20 元券」：要断的是 expected = (300 - 50) * 0.8 - 20，是折扣顺序 fullcut_discount_coupon，是风控规则触发了没有。这些断言的逻辑，AI 写不出来——因为它不知道你的业务规则，得你讲清楚。

为什么：「断什么」从来不是语法问题，是业务理解问题。这一层连人都常常说不清楚，AI 当然只能瞎猜。所以验证型任务里，最值钱的部分不是让 AI 写断言，是你把业务规则讲清楚。你讲得越清楚，AI 的验证才越有用；你懒得讲，AI 就替你「猜」，然后你替它兜底。

经验 4：上下文经济学——逐句问「删掉它，行为会变吗」

现象：我最早给 Agent 写配置的时候，恨不得把注意事项全写进去，结果常驻上下文越来越长，模型反而「变笨」了：缓存命中率下降，每次对话更慢更贵，还经常被废话带偏。

做法：对常驻 prompt 逐句做一个测试：如果删掉这句话，Agent 的行为会改变吗？不变，就立刻删。「Be thorough and careful」这类鼓励语删掉；「This is crucial because…」这类废话前缀删掉；重复的步骤说明删掉。另外用正面表述：「编辑前先读文件」，而不是「别忘了读文件」——否定式反而会让被禁止的行为对模型变得更「可及」。

为什么：每往 prompt 里加一句话，都是此后每一轮对话都要支付的 Token 成本；删掉一行废话，收益在整个会话周期里持续兑现。同样的道理适用于技能：一个技能解决不了别的技能解决不了的问题，就删。技能库不是收藏夹，每个技能都是常驻成本。

经验 5：把裁决沉淀下来，别让 AI 每轮重复踩同一个坑

现象：我一度很烦 AI 审查代码：同一个低优先级问题，它每轮都报成 high，我要么忽略（审查失效），要么每次都解释一遍（浪费 Token）。直到我意识到：问题不在它，在我没有给它一份「裁决基线」。

做法：把审查口径沉淀成一个 git 跟踪的文件：比如「内部工具的缺失鉴权降级为 low」「生成文件权重 0、业务逻辑权重 1」，让 AI 命中这些模式时必须按条目降级并引用。再配合校准问题：每条 finding 先过四问——能构造反证吗？换个审稿人会通过吗？是缺陷还是个人偏好？证据在影响范围内吗？

为什么：AI 没有长期记忆，它每一次都在「猜」你的标准。你把裁决写下来，它就不猜了；你不写，它就按训练数据里的通用标准来，而通用标准跟你的项目大概率对不上。沉淀是让 AI 从「每次都要你教」变成「教一次就记住」的唯一办法——这条经验对 Agent 配置、代码审查、测试断言全都适用。

怎么开始用（落地清单）

1. 今天就做一次任务分类：把手头常用的 AI 用法列出来，标成「生成型/验证型」，验证型任务换最好的模型；
2. 下次让 AI 干活前，先花 30 秒写下「我要它做什么、验收标准是什么」，再让它跑；
3. 检查你的测试断言：有没有只断「跑通了」没断「结果对」的？把业务规则补进去；
4. 给你的常驻 prompt 做一次减法：逐句问「删掉它行为会变吗」，删掉所有不变的话；
5. 把最近一次「AI 反复踩同一个坑」的裁决写下来，让 AI 下次直接引用。

收尾：最后说点掏心窝的：我写这篇，不是劝你少用 AI——恰恰相反，我用得越来越狠。我只是希望你别像我一样，先花一个半小时的学费才明白：AI 编程的效率，不取决于模型，取决于你把「想、跑、验」三段节奏的哪一段交给了谁。想清楚这件事，AI 从「偶尔好用」变成「稳定省时间」，只差一次分类、一次减法、一次沉淀。