大模型写代码有一种很危险的爽感：同一个问题，上一轮胡说八道，下一轮突然给出一段漂亮实现。失败的时候像差一点，成功的时候像中奖了。

这种体验很像抽卡。不是因为使用 AI 等同于赌博，而是因为裸模型的反馈结构具备几个相似特征：结果有波动，高分样本偶尔出现，用户很难提前判断下一轮是不是高分，于是自然产生“再试一次”的冲动。

把这种冲动看清楚，比单纯争论模型聪不聪明更重要。很多 AI coding 的燃尽感，不来自模型太弱，而来自人把自己的注意力押在一次又一次低可见度的重试上。工程工作被悄悄改造成了抽卡循环。

flowchart LR
    A[一次任务] --> B[裸模型采样]
    B --> C{输出质量}
    C -->|低分| D[补 prompt / 换模型 / 重试]
    C -->|高分| E[强奖励: 这次出货了]
    D --> B
    E --> F[提高下一轮期望]
    F --> D
    D --> G[隐藏成本: review / 归因 / 修复 / 焦虑]

输出是分布，不是一个点

OpenAI 的 reproducible outputs 文档说得很直接：Chat Completions 和 Completions API 默认是非确定性的；设置 seed、固定参数和 system_fingerprint 后，也只是接近可复现，仍不能保证完全相同。

这意味着模型能力不是一个确定点，而是一段分布。一个平均能写出 70 分答案的模型，在具体一次调用里可能落到 50 分，也可能冲到 90 分。用户看到的不是“模型真实能力”，而是一次采样结果。

代码生成尤其容易放大这种错觉。写文章时，50 分和80 分之间的差别可能只是表达粗糙；写代码时，50 分可能是编译不过，80 分可能是局部可用，90 分可能让人觉得“它真的懂了”。同一个模型在这几个状态之间跳动，用户就会开始把每一次重试理解成“下一发可能出货”。

这里的关键不是温度参数。即使把输出变得更保守，模型仍然会受到上下文、提示方式、任务颗粒度、工具反馈和隐藏系统状态影响。确定性程序的错误通常有稳定复现路径；裸模型的错误更像一块概率地形，下一脚未必踩在同一个坑里。

锯齿状智能制造误判

HBS 与 MIT 等作者的《Navigating the Jagged Technological Frontier》提出了一个很有用的概念：AI 的能力边界是锯齿状的。它能在某些任务上显著提升质量和效率，却会在相邻、看似同难度的任务上拉低表现。

Nature 2024 年的《Larger and more instructable language models become less reliable》从另一个角度补上了同一件事：模型变大、变得更听指令以后，确实能解决更难的问题，但不等于在简单区域完全可靠。论文特别强调，模型会在一些用户以为稳定的低难度区域失败，也会受到提示表述变化影响。

AI coding 最容易误导人的地方正在这里。模型刚刚写出一个漂亮的并发队列，下一秒可能在一个普通边界条件上犯错；它能解释一段复杂框架源码，却可能把一个项目里不存在的函数当成真实 API 调用。能力不是连续爬坡，而是一排高低不平的齿。

人类对这种智能很难校准。看到高分样本以后，用户会自然抬高对模型的期望；看到低分样本以后，又容易把它解释成“提示词没写好”“上下文没给够”“这次运气不好”。于是失败不再是停止信号，反而变成继续重试的理由。

抽卡感来自变量奖励

心理学里有一个老概念：variable ratio reinforcement，变量比例强化。简单说，就是奖励不是每次都有，而是在不可预测的次数后出现。很多赌博机、抽卡机制和 loot box 都利用了这种结构。关于 loot box 的研究也反复提到，随机奖励和可变比例强化会鼓励持续重复行为，但相关研究通常只能证明关联或机制相似，不能把所有随机奖励体验都直接等同于成瘾。

AI coding 的反馈结构和它相似，但赌注换成了时间、注意力和判断力。

一次失败的模型输出不会让人马上停下。它常常提供一点希望：架子是对的，接口差一点，变量名像真的，测试只差两行。下一轮改 prompt，再下一轮换模型，再下一轮补上下文。每一次都像是在靠近正确答案，但实际被消耗的是人的工作记忆。

更麻烦的是，AI 的“中奖样本”确实存在。模型偶尔会在十分钟内写出一个人类要半天才能搭好的脚手架。这个样本会被大脑牢牢记住，并反过来解释后面的低效循环：刚才都能出货，这次再试几轮也许就好了。

用意志力解释这个现象并不充分。一个系统如果持续给出不可预测的高价值奖励，人就会倾向于高估下一次尝试的期望值。AI coding 把这种结构搬进了工程日常。

燃尽来自隐藏的人工成本

表面上，用户只是在等模型输出。实际上，每一轮重试都要求人完成一组昂贵动作：

  • 重新理解模型到底错在哪里
  • 判断错误是提示词问题、上下文问题、工具问题，还是模型能力问题
  • 决定要不要补信息、拆任务、换模型、改测试
  • 从新输出里提取可用部分，同时警惕不可见错误
  • 把上一轮失败经验带进下一轮，但不能被它牵着走

这些工作不出现在 token 账单里，却直接消耗人的注意力预算。模型一轮一轮生成，人一轮一轮做隐形 code review、需求澄清、调试、归因和风险判断。工作看起来自动化了，人的大脑却一直处在高频中断状态。

很多人“用 AI 写了一天代码，最后比自己写还累”，来源就在这里。累的不是敲字，而是不停在不稳定反馈里重建判断。模型每次都给一点希望，人就很难干净地停止。

停止规则比提示词更重要

抽卡式协作的解法不是不用模型，而是给模型加停止规则。成熟的 AI coding 不是“再抽几发”，而是把每一轮尝试变成可验证流程。

一个简单的工程纪律是：同一个问题连续两轮输出没有明显改善，就停止重试，切换工作模式。不要继续改提示词。先把问题压回确定性系统：

  • 写下最小复现和预期行为
  • 补一个失败测试
  • 缩小文件范围和函数范围
  • 把相关 API、类型定义、日志、错误栈作为上下文提供
  • 让模型基于测试和具体文件改，不再让它自由发挥
  • 运行构建或测试，用机器结果决定下一步

这几条看上去朴素，却能把“随机高分”改造成“受控迭代”。模型仍然是概率系统，但反馈不再来自人的感觉，而来自测试、编译器、类型系统、lint、截图、日志和 diff。

Harness 的价值也在这里。它把模型的输出从抽卡池里拿出来，放进一个有边界、有验收、有回滚的工作系统。prompt engineering 还停留在“怎样让这一发更像好卡”；harness engineering 关心的是“怎样让坏卡不能进主干，好卡能被验证和复用”。

把抽卡池改成流水线

AI coding 里最危险的习惯，是把“继续试”当成默认动作。更好的默认动作是先判断当前问题处在哪个区间：

现象 抽卡式反应 工程式反应
输出大体可用但细节错 继续让模型改 补测试和具体错误，让模型对着失败点改
输出方向反复漂移 换模型、换说法 缩小任务，写清 non-goal 和修改范围
模型编造 API 继续提示“不要编造” 把真实文档、类型定义、源码检索结果喂进去
修一个 bug 带出三个新 bug 让模型“仔细检查” 回滚到最小 diff，分步提交，每步验证
人开始烦躁但停不下 再试最后一次 设定停止线，转人工分析或写复现

这张表的要点不是“人比模型可靠”，而是不要让人的注意力给随机奖励机制打工。人应该负责设计边界、选择证据、定义验收、判断风险；模型负责在边界里生成候选方案。两者一旦反过来，人就会被模型的波动牵着走。

高效的 AI coding 会越来越像一条流水线：问题进入、上下文装配、模型生成、机器验证、人类 review、状态写回。每一环都有明确输入输出，失败会留下证据，而不是只留下“再试一次”的冲动。

收束

裸模型像抽卡，是因为它把概率输出直接暴露给用户。高分样本偶尔出现，低分样本又总让人觉得还有救，于是协作很容易滑进变量奖励循环。

承认这种抽卡感，不会削弱 AI coding 的价值，反而能把模型放到正确的位置。模型适合产生候选路径、补全局部实现、解释代码、提炼假设；不适合独自承担验收、边界和停止条件。

下一代 AI 工程的重点，不是把所有人训练成更会抽卡的人，而是把抽卡池改造成流水线。Harness、spec、测试、工具、日志、状态文件和代码审查，本质上都在做同一件事：让随机智能进入可验证的工程秩序。

相关文章

参考资料