上周三下午三点，我盯着屏幕上一个卡了四小时的 CI 流水线，手里那杯咖啡已经凉得像西伯利亚的冬天。突然想到：如果有个助手能自己发现问题、自己修复、自己跑完测试，那我是不是就能去睡个整觉了？

巧了，这周 Qwen Code 0.16.0 刚好把 /goal 推上了舞台。而更巧的是，隔壁 Codex 也刚上线了类似功能。今天咱们不聊参数对比表，就聊聊：当代码助手开始"自主驾驶"，我们程序员到底是解放了，还是失业了？

/goal 到底是啥？

简单说，以前你用 AI 写代码，像带个实习生：每步都要确认，“这个文件改吗？”“那个命令跑吗？”。现在 /goal 让你直接说：“把项目从 Jest 迁移到 Vitest”，然后——去喝咖啡。

但等等，Codex 不也能这样吗？

关键差异在这里：Qwen Code 的 /goal 请了个"第三方裁判"（judge model）。执行模型负责干活，裁判模型负责验收。就像你装修房子，施工队和监理不能是同一个人，对吧？

# 传统模式（自我判断）
Agent: "我觉得改完了" → 其实漏了三个测试文件 😅

# Qwen 模式（独立裁判）
Executor: "这轮改完了"
Judge: "等等，vitest.config.ts 还没创建，继续"

这个设计让我想起康德的"批判哲学"：理性需要自我批判，但更需要外部审视。代码执行也是同理——让同一个模型既当运动员又当裁判，难免会有"我觉得我行了"的幻觉。

上个月我让某个助手"优化项目性能"，结果它把 console.log 全删了，包括生产环境的关键埋点。为什么？因为它觉得"任务完成了"。

Qwen 的 judge model 有个很人性的设计：遇到不可能的目标会主动放弃。比如你说"用纯前端实现比特币挖矿"，它不会硬着头皮跑三小时烧你 token，而是直接告诉你：“兄弟，这事儿在浏览器里真干不了”。

这点我特别认同。很多工具为了"显得能干"，硬着头皮执行不可能任务，最后留下一堆半成品的代码垃圾。承认"这个我做不到"，反而是更高级的智能。

和 Codex 的 /goal：表面相似，内核不同

举个实际场景：你要把 200 个测试文件从 Jest 迁移到 Vitest。

• Codex 模式：跑着跑着遇到一个特殊语法不支持，可能卡住或乱改，需要你人工介入。
• Qwen 模式：judge 发现"这个文件依赖了 Jest 特有 API，当前上下文无法处理"，直接跳过并记录，最后给你一份"已完成 197 个，3 个需人工处理"的清单。

哪种更让你放心？反正我选后者——毕竟凌晨三点被叫醒改 bug 的体验，一次就够了。

自主与控制的永恒张力

写到这里，突然想起福柯在《规训与惩罚》里说的：权力不是压制，而是生产。AI 编程工具的发展，本质上也是"控制权"的重新分配。

• 过去：程序员 100% 控制，每行代码亲手写
• 现在：程序员定义目标，AI 执行细节
• 未来？：程序员定义"什么是好代码"，AI 自主迭代优化

/goal 的 judge model 设计，其实是在"完全放权"和"完全控制"之间找了个平衡点。就像教孩子骑车：一开始扶着后座，后来悄悄松手，但还在旁边看着。

“Man is condemned to be free.” — Sartre

我们既渴望解放双手，又害怕失去控制。这种矛盾，可能才是技术演进最底层的驱动力。

结语

回到开头那个凌晨三点的问题：如果 AI 能自己跑完全程，我们还要做什么？

我的答案是：定义什么是"完成"。

/goal 的 judge model 之所以重要，不是因为它能判断代码对不对，而是因为它把"验收标准"这个最核心的权力，交还给了人类。你可以说"测试通过就算完成"，也可以说"还要通过代码审查"，甚至可以自定义一套复杂的验收逻辑。

技术越智能，人的判断力越珍贵。就像相机自动对焦再厉害，构图和光影的审美，永远在摄影师眼里。

所以下次当你输入 /goal 时，不妨多想一秒：我真正想要的"完成"，到底是什么样子？

毕竟，工具可以跑完全程，但方向，永远在你手里。🚀