AI 编程双车道工作流：量大任务用便宜模型，重大判断需人工审核

Full translation

完整中文译文

之前我写过一篇文章，讲的是在让人工智能编程模型接触真实代码库之前，先跑两小时的适配测试。那篇文章讲的是如何筛选模型。这篇文章讲的是筛选之后发生的事：既然你已经接受人工智能辅助将成为日常工作的一部分，如何防止它悄无声息地成为你工作流中最昂贵、同时审计最少的一环？

我不断碰到的失败模式不是糟糕的代码，而是对所有任务使用同一个模型、同一个工具、同等程度的信任——让顶级模型去重命名变量，更糟糕的是，让一个响应快速的模型去勾勒迁移方案。这两个错误根源相同：没有区分容量型任务（volume work）和判断型任务（judgment work）。

所以我把人工智能的使用分成了两条车道，这个方法效果还不错，值得写下来分享。

车道一——容量型。高频、低爆炸半径的任务，答错了损失三十秒，而不是一次部署：

生成样板测试脚手架（不是断言部分——只是骨架）

为已经能正常工作的代码起草 docstring 和类型注解

改写错误信息和日志行

"解释这个正则表达式 / 这个堆栈跟踪 / 这个配置块"

第一轮重构建议，我会阅读但不会盲目应用

车道二——判断型。低频、高爆炸半径的任务，被自信地误导才是真正的风险：

Schema 和迁移设计

任何涉及认证、支付或数据删除的部分

并发和缓存决策

对车道一产出进入 PR 的最终审查

这个经济学的洞察很无聊但是真实的：车道一占我 80%–90% 的提示词，风险接近于零。车道二恰恰相反。用车道二的价格（钱、延迟或速率限制）处理车道一的流量——这只是预算上的一个 bug。

免费层实际适合在哪里

这就是免费模型访问从一种好奇心变成基础设施的地方。披露：本文是 MonkeyCode 产品推广的一部分。MonkeyCode 目前提供免费访问编程模型以及免费服务器选项，这正是车道一需要的形态：一个我可以整天用机械请求猛敲而不用盯着计量表的东西，也是运行下面那个小型路由框架的地方，而无需配置任何基础设施。

我要精确说明我没有声称什么：我没有将他们的模型与付费替代品进行基准测试，我不知道配额是多少，也不知道免费层能持续多久，我不会在没有退出计划的情况下在免费层上构建关键业务。免费层是会变化的。设计时要考虑到这一点。

但对于车道一，门槛不是"可用最佳模型"，而是"足够好，好到我的验证步骤很便宜"。这就引出了那个产物。

产物：一个提示词路由器加验证门

整个系统分两部分。首先，一个路由脚本对请求进行分类，将车道一的工作发送到免费层，车道二的工作发送到任何你信任的强大工具（本地模型、付费 API，或者就只是你自己的大脑加一只橡皮鸭）：

#!/usr/bin/env python3
"""lane_router.py — route AI coding requests by blast radius, not by habit."""
import sys

# Judgment keywords: presence of ANY of these forces Lane 2.
# Tune this list for your codebase. Mine grew after every incident.
JUDGMENT_TRIGGERS = [
    "migration", "schema", "auth", "token", "password", "payment",
    "delete", "drop", "cache", "lock", "race", "transaction",
    "permission", "encrypt", "production", "rollback",
]

# Volume tasks that are safe to delegate when verification is cheap.
VOLUME_VERBS = [
    "explain", "rename", "docstring", "annotate", "scaffold",
    "rephrase", "summarize", "draft tests for",
]

def classify(request: str) -> str:
    r = request.lower()
    if any(t in r for t in JUDGMENT_TRIGGERS):
        return "lane2"
    if any(v in r for v in VOLUME_VERBS):
        return "lane1"
    return "lane2"  # default: distrust the unknown

def main():
    request = " ".join(sys.argv[1:]) or input("Request: ")
    lane = classify(request)
    if lane == "lane1":
        print("LANE 1 → free-tier model, then run verification gate")
        # e.g. POST to your MonkeyCode free-server endpoint here
    else:
        print("LANE 2 → strong model / manual design, mandatory human review")

if __name__ == "__main__":
    main()

是的，关键字匹配很粗糙。但这正是它的一个特性：它是透明的，失败时倾向于车道二，而且我可以在十秒内读懂我自己的路由逻辑。一个更复杂的分类器只是把信任问题往上挪了一层而已。

其次，验证门——每条车道一输出在接触文件之前要通过的检查清单。这正是使免费模型变得可行的原因：你假设输出是错误的，并把检查费用算进去。

验证门（车道一输出，约 60–90 秒）
[ ] 编译 / 解析 / lint 干净
[ ] 没有我不认识的导入、API 或标志（幻觉检查）
[ ] 没有我指定之外的文件路径
[ ] 行为符合我一句话的预期——我重读的是我的提示词，
    而不是模型对我所做事情的解释
[ ] 如果是测试脚手架：当功能缺失时它会失败
[ ] Diff 足够小，即使来自人类我也会审查

最后那个复选框才是真正的规则。如果模型的 diff 大到我无法审查，那这个任务就不是车道一，无论路由器说了什么。

对于喜欢压缩版的人：

这在哪里会出问题

坦诚地说说局限性，因为我希望别人对我也这样：

验证门只有在真正运行它的时候才有效。哪天你开始粘贴车道一输出而不做那 60 秒检查，你就变成了一条车道的工作流还多了几个步骤。这是一个纪律系统，不是技术系统。

免费层是一个移动的目标。配额收紧、模型被替换、服务终止。我的路由器把端点放在一行配置里是有原因的。如果你的工作流在免费层变化时死掉了，那你建立的是依赖，不是工作流。

有些人不应该分车道。如果你职业生涯早期到还无法区分一个看似合理但错误的答案和一个正确答案，车道一就是危险的——它恰好生成那些教授坏习惯的看似合理但错误的产物。先手动做车道二的工作；稍后再加人工智能的容量。同样，如果你的仓库没有快速的测试/lint 循环，验证不便宜，整个经济论点就会崩溃。

分类错误双向都会发生。我曾发现自己问免费层一个问题，结果对话进行到一半发现是个设计问题。解决方法很朴素：注意到，停下来，用车道二的方式重新问。

几周后发生了什么变化

可衡量的差异不是代码质量——那基本保持不变，这本身就是重点。变化的是：我的付费工具使用量降到了原来的一小部分，机械任务的提示延迟下降了，而且——这是我没能预测的部分——我的审查纪律提高了，因为验证门给每个人工智能产物一个定义的怀疑时刻，而不是模糊的 Ambient 信任。

如果你想尝试，最小的可能起点是：选择一个免费选项（MonkeyCode 免费模型和服务器是一个；还有其他），只用它跑 docstring 和解释任务一周，配合上面的检查清单，然后观察验证门在哪里捕获到了问题。那个捕获率——不是感觉，不是基准测试——才是告诉你车道划分是否在你的设置中赢得一席之地的东西。