两周路由日志：终结选AI模型的玄学决策

每次有新的编程模型发布，我的 feed 就会被各种基准测试截图刷屏，然后我就会陷入最糟糕的评估方式：凭感觉。"这个感觉更聪明。"两天后我就忘了到底是哪个模型真正修好了我的 bug，哪个又信心满满地把我的测试搞坏了。

经过几轮这样的折腾，我不再试图给模型做全球排名，而是开始回答一个更小但更有用的问题：对于我实际做的那些任务，什么时候免费模型就够了，什么时候值得用更强的？答案来自一个无聊的产物：一个我记录了两周的路由日志。本文就是这个日志格式、它产生的决策规则，以及一个让你能跑同样实验的小脚本。

为什么基准测试解决不了这个问题

公开基准测试衡量的任务是干净、自包含、自动评分的。我的真实任务则完全不是这样：记了一半的遗留代码、缺了关键帧的堆栈跟踪、文档和实际 schema 已经对不上的迁移。某个模型是否"足够好"取决于任务形态，而不只是模型本身。所以测量单位必须是我自己的任务历史。

每个 AI 辅助任务一行。五列，仅此而已：

date | task_shape | model_tier | outcome | rework_minutes
2026-08-03 | regex-refactor | free | pass | 0
2026-08-04 | flaky-test-diagnosis | free | fail->escalated | 25
2026-08-05 | sql-migration-review | paid | pass | 5

task_shape —— 一个你边做边起的短标签（我的收敛到：boilerplate、single-file-bug、cross-file-bug、design-question、unfamiliar-lib、review-my-diff）。

model_tier —— 就是 free 或 paid/strong。最初不要记录模型名称；你要的是层级的对比，而且模型名称每周都在变。

outcome —— pass（正常 review 后发布）、fail->escalated（免费模型的回答是错的或没用，我用更强的模型或手动重做）、fail->manual。

rework_minutes —— 发现并修复模型错误所花的时间。这是所有人都跳过的那一列，也是唯一重要的那一列。

让数据说真话的脚本

记忆会骗人；但一个提醒你的 prompt 不会。我把它保存为 airoute 放在 PATH 里（Python，无需依赖）。在完成一个 AI 辅助任务后立即运行它 —— 它追加一行，而且一旦你有足够的数据，就会打印出哪些任务形态在免费层上让你付出了返工代价：

#!/usr/bin/env python3
"""airoute: log AI task outcomes and summarize rework by task shape.
Usage:
  airoute add <task_shape> <free|paid> <pass|escalated|manual> <rework_min>
  airoute report
"""
import csv, sys, os
from collections import defaultdict

LOG = os.path.expanduser("~/.airoute.csv")

def add(shape, tier, outcome, rework):
    exists = os.path.exists(LOG)
    with open(LOG, "a", newline="") as f:
        w = csv.writer(f)
        if not exists:
            w.writerow(["shape", "tier", "outcome", "rework_min"])
        w.writerow([shape, tier, outcome, rework])

def report():
    stats = defaultdict(lambda: {"n": 0, "esc": 0, "rework": 0})
    with open(LOG) as f:
        for row in csv.DictReader(f):
            key = (row["shape"], row["tier"])
            stats[key]["n"] += 1
            stats[key]["esc"] += row["outcome"] != "pass"
            stats[key]["rework"] += int(row["rework_min"])
    print(f"{'shape':<22}{'tier':<6}{'n':>4}{'escal%':>8}{'rework/task':>13}")
    for (shape, tier), s in sorted(stats.items()):
        print(f"{shape:<22}{tier:<6}{s['n']:>4}"
              f"{100*s['esc']/s['n']:>7.0f}%"
              f"{s['rework']/s['n']:>11.1f}m")

if __name__ == "__main__":
    if len(sys.argv) >= 6 and sys.argv[1] == "add":
        add(sys.argv[2], sys.argv[3], sys.argv[4], sys.argv[5])
    elif len(sys.argv) == 2 and sys.argv[1] == "report":
        report()
    else:
        print(__doc__)

两周和大约 40 行数据就足以让模式不再只是噪声。

我的日志实际显示了什麼

这是我的数据，不是通用法则 —— 这正是让你自己跑这个实验的意义：

由此产生的路由规则：

boilerplate、contained bugs 和 diff review 优先用免费层。升级率足够低，偶尔的失误比为每个 prompt 付费更划算。

跨文件调试和陌生的库完全跳过免费层。从免费层开始是昂贵的路径 —— 花 25 分钟返工才发现还是需要更强的模型。

设计问题走到我正在对话的模型，但输出是提案，不是决定。

意外的是第 2 行。我原本以为"先试免费，有需要再升级"一定更便宜。对于复杂的任务并非如此 —— 你付了免费尝试的代价，又付了升级的代价，还付了返工的代价。

免费层从哪里来

为了让这个成为永久习惯而不是试验期把戏，免费层必须真的是免费且真的可用的。披露：本文是作为 MonkeyCode 产品推广的一部分准备的。MonkeyCode 是符合这里约束的一个选项 —— 它提供免费模型访问和免费服务器选项，这就是我上面日志中使用的免费层。对于这个工作流来说，有用的特性不是它暴露的任何一个单一模型；而是我可以运行路由策略中那高volume、低风险的一半，而脑子里没有计费器在后台转。如果你好奇，免费层是诚实复现这个实验的方式 —— 但任何可靠免费的访问都可以，这个脚本不在乎你指向哪一个。

局限，以及谁不应该费这个事

两周的样本很小。把这些数字当作路由提示，而不是统计数据。每月重新跑一次 report；模型质量在你脚下变化。

日志测量的是我的仓库、我的 prompt、我的耐心。你的升级表会看起来不同，尤其是如果你的工作主要是 greenfield（免费模型在那里表现更好，根据我的经验）或者主要是遗留代码挖掘。

任何涉及 secrets、凭证或生产数据的操作根本不做路由 —— 未经你的组织明确批准，它不应该进入任何层的第三方工具。如果你的雇主有 AI 使用政策，那个政策凌驾于本文一切之上。

如果你一周只做几次 AI 辅助工作，日志的开销成本比路由节省的更多。这个方法在你每天多次做免费 vs 强模型选择时才划算。

更大的教训跟任何模型无关："感觉更聪明"是不可测量的，但"每个任务形态的返工分钟数"只差一个 CSV。如果你一直在凭感觉换模型，我真的很想听听你的路由表长什么样 —— 特别是它和我的在哪里不一致。