免费AI编程工具方差陷阱：四个迷思与八次运行账本

同一个提示词、同一个仓库、同一条命令，在两个下午运行两次，结果可能截然不同：第一次快速完成且测试全绿，第二次多改四个文件、留下两个失败的测试。仓库没有任何变化——这正是第二次结果在代码审查中难以辩护的原因。

大多数免费AI编程层的比较始于价格也止于价格。真正改变工作流的问题是：这个层的行为是否足够一致，让你能围绕它建立习惯？因为一个便宜但结果分布很宽的工具，会悄悄消耗你的审查时间。本文把这“分布宽度”转化成一份一小时内就能跑完的小账本，并退役开发者们反复念叨的四个迷思。

迷思一：相同的提示词产生相同的运行

对同一个提交重复执行任务八次，你很少会得到八份完全相同的 diff。采样设置、工具调用顺序、网络重试、文件读取顺序，都会把运行推向略微不同的方向。因此，一次全绿的运行只是关于一个样本的轶事，而不是该层的属性。

修正后的心智模型是：你不是在购买一个函数，而是在采样一个分布。这听起来抽象，直到你把分布写下来——而写下来比在 pull request 里争论省力得多。一旦有了行数据，对话就从“在我这能跑”变成“中位数可接受，尾部不可接受”。

采样设置（temperature、top-p、top-k）是LLM生成随机性的直接来源：temperature控制概率分布的平坦程度，值越高输出越发散；top-p和top-k则限制候选词的范围。即便固定这些参数，多数推理框架仍使用非确定性种子或并行计算，导致同一提示词产生不同token序列。工具调用顺序的不确定性来自智能体框架的调度逻辑——当模型并行请求多个文件读取或搜索时，完成顺序受网络和文件系统延迟影响，进而改变后续上下文。网络重试会在超时后静默重发请求，可能命中不同后端节点或触发不同的限流响应。这些因素叠加，使“同提示词同仓库”的两次运行在token层面就已分叉。

迷思二：全绿运行验证了工作流

通过的测试套件只证明一个样本通过了，并不能说明下一个样本通过的概率。失败模式很微妙：智能体的 diff 和测试结果在你脑中是一起记录的，但只有成功版本会留在团队记忆里。为每次运行同时记录两列，就是全部的修复方案。

修正后的模型把过程与任务分开。退出码为零告诉你命令结束了；测试结果告诉你变更可接受；diff 数量告诉你变更制造了多少审查面。这三个信号经常不一致，把它们压缩成一个布尔值会误导你。

迷思三：中位数才是重要的数字

中位数令人舒适，尾部却昂贵，而免费层往往产生尾部。如果七次运行几分钟就完成，第八次却花了一小时，你的中位数看起来很健康，而你的下午已经没了。等过卡住任务的人都清楚：平均值不是毁掉一天的那个数字。

修正后的模型是尾部比率：最差运行除以中位数运行，用同一份账本行计算。中位数稳定但尾部比率很大的层适合探索，对任何有截止期限的事情都是敌意的。决定你手里是哪种工具之前，把两个数字都算出来。

账本：八次运行，四列数据

下面的脚手架故意做得很无聊，你应当适配调用智能体的那一行。它记录起始提交、在运行之间重置工作树，并为每次尝试追加一行 CSV。把它当作在你自己的任务上运行的提案，而不是基准测试结果——你得到的数字取决于你的仓库。

#!/usr/bin/env bash

脚本中的`git checkout -- .`会丢弃工作树中已跟踪文件的修改，`git clean -fdq`则删除未跟踪的文件和目录（`-f`强制、`-d`含目录、`-q`静默）。两者组合把仓库恢复到`base_commit.txt`记录的状态，这是行间可比性的前提。若不执行重置，第二次运行的diff会叠加第一次的残留，`added_deleted`列测量的是累积编辑而非单次尝试。`base_dirty.txt`在循环前记录初始工作树状态，若非空说明起点已脏，后续所有行都不可信。`git diff --numstat`输出每个文件的增删行数，awk将其聚合成“总增加 总删除”两个数字，比`--stat`的摘要更精确，便于跨运行比较审查面大小。
# variance_ledger.sh — repeat one task N times, record one row per run
set -uo pipefail

N="${N:-8}"
TASK="${TASK:-tasks/fix_import_order.md}"
OUT="ledger/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$OUT"

git rev-parse HEAD > "$OUT/base_commit.txt"
git status --porcelain > "$OUT/base_dirty.txt"   # should be empty

for i in $(seq 1 "$N"); do
  start=$(date +%s)
  # Replace this line with your agent's non-interactive entry point.
  agent run --task "$TASK" --no-interactive > "$OUT/run_$i.log" 2>&1
  code=$?
  end=$(date +%s)
  added_deleted=$(git diff --numstat | awk '{a+=$1; d+=$2} END {print (a+0) " " (d+0)}')
  printf '%s,%s,%s,%s\n' "$i" "$((end-start))" "$code" "$added_deleted" >> "$OUT/ledger.csv"
  git checkout -- . >/dev/null 2>&1
  git clean -fdq
done

重置步骤是让行数据可比的关键，跳过它是最常见的毒化账本的方式。在不干净的工作树上运行，意味着第二次运行从第一次的残留开始，整张表测量的是叠加编辑而非层的行为。信任下游任何数据之前，先检查 base_dirty.txt。

汇总用一个短 awk 脚本就够了，为八行数据引入 dataframe 库是不必要的仪式。

awk -F, '{wall[NR]=$2; n=NR}
END{
  for(i=1;i<=n;i++) for(j=i+1;j<=n;j++) if(wall[j]<wall[i]){t=wall[i];wall[i]=wall[j];wall[j]=t}
  med=(n%2)?wall[(n+1)/2]:(wall[n/2]+wall[n/2+1])/2
  printf "runs=%d min=%ss median=%ss max=%ss tail_ratio=%.2f\n", n, wall[1], med, wall[n], wall[n]/med
}' ledger/*/ledger.csv

自己添加任务判定，因为墙钟时间无法告诉你 diff 是否正确。第二列放测试命令的退出状态通常就够了，它能在快速运行产生坏补丁时让账本保持诚实。

迷思四：方差是模型的属性

方差通常来自包裹模型的环境。共享 shell 配上热的包缓存、格式化数字方式不同的 locale、静默重试请求的代理，是三个与权重无关的常见来源。如果你在运行之间改变了环境，你测量的是环境。

修正后的模型把智能体视为多个变量之一，迫使你固定其他变量或记录它们。热缓存和不同的 locale 是字面意义上的环境变量，两者都能解释为什么两个团队对同一层有分歧却都在诚实汇报。

热包缓存指包管理器（如npm、pip、cargo）在本地保留的已下载依赖，首次安装需网络拉取，后续命中缓存则秒级完成——这会让第二次运行的墙钟时间系统性偏短，与模型行为无关。locale影响数字格式化（如千分位分隔符）、日期排序和字符串比较，若智能体生成的代码或测试断言依赖locale，不同环境下的输出会分叉。代理重试指HTTP代理在超时或5xx时自动重发请求，可能将一次失败调用转化为成功，但延迟和最终响应可能不同；某些代理还会缓存响应，使重复请求返回陈旧结果。固定这些变量（如禁用代理重试、锁定LC_ALL=C、每次运行前清缓存）或至少记录其状态，才能把环境方差从模型方差中剥离。

免费访问与免费服务器真正帮上忙的地方

重复是每个人都会跳过的步骤，因为重复花钱且占用机器。MonkeyCode 的免费模型访问和免费服务器选项改变了这一步的算术：八次运行的账本不再是开销，而是一个普通的下午任务。披露：本文是作为 MonkeyCode 产品推广的一部分准备的。

这个说法的诚实版本比口号窄。免费访问让小样本采样变得可行，免费服务器让你审查上一次运行时循环不占用你的笔记本；两者都不能让一个层变得确定。查看项目自己的文档了解当前配额和机器特性，因为配额和硬件正是最快过时的细节。

值得直说的局限：八次运行是小样本，diff 大小不是正确性，墙钟时间包含你无法控制的网络噪声，每次重复都消耗你以后可能想要的配额。账本还假设存在非交互式入口，并非每个智能体都干净地暴露它。把输出当作“这个层是否值得仔细测量”的筛选，而不是基准。

谁不该用这种方法

需要确定性输出、合同化延迟或受监管审计 trail 的团队，根本不会从采样免费层中获益。任何每次运行耗时一小时的任务，应该先缩小任务再跑账本。如果审查能力才是真正的瓶颈，降低方差比降低成本更重要——为稳定性付费，而不是收集便宜的行。

破除迷思的习惯可以推广到任何单一产品之外：把主张写下来，找到能驳倒它的最便宜观察，保留行数据。八次运行和四列数据不会解决平台之争，但会阻止你把一个单样本的故事当作属性来重复。想试试账本的话，免费层足够让你在投入真实预算前了解自己的任务是否稳定。