Quarterback

大家好，我是 Arshad。我在 Velora 负责开发 Quarterback。

最初促使我做这件事的原因是：我不断发现，我的编程助手与其说是错的，不如说是不完整的。代码能编译通过，测试也通过了，diff 看起来没问题。后端字段明明存在，前端却压根没把它发出去——而我往往要等到三个 commit 之后才会察觉。

这不是模型的问题，而是缺少一个中间层。助手先解读任务，然后按自己的理解去实现，接着又评审自己那套理解并报告成功。始终没有独立的一环去检查——最初那份活儿到底有没有干完。

Quarterback 就是这个检查环节。你的请求会被拆成一份明确的任务契约：目标、约束、验收标准、验证方案。原有的助手继续干活（Claude Code、Cursor、Codex，或者你已经在用的任何工具），随后一个独立层对照契约来核验结果——优先采用确定性证据：测试、类型、diff 范围、schema 检查；只有当问题真正属于语义层面时，才动用模型判断。

我在意的指标是：每个被采纳的任务所对应的人工干预次数。每一次纠正、澄清、纠偏或核查助手的过程都算。这里的关键词是"被采纳"——一个不再追问、却仍在交付糟糕结果的系统，并没有任何改进。

今天我不会公布任何数字。这类厂商基准测试我见过太多了，深知它们是怎么炮制出来的；我宁愿把真实的队列数据连同方法论一并发布，也不想放一张我自己编出来的图表。这件事很快就会做。

我现在需要的是 10 到 20 位在真实代码仓库中每天使用编程助手的开发者。我们会先测出你的基线，再把同样的工作交由 Quarterback 跑一遍，让你直接在自己任务上看到差距。数据只采用匿名指标。

在评论区，我真心希望能听到这两个问题的答案：

你的助手最近一次号称完成、其实没做完的事是什么？

在相信"完成"之前，你总会自己再核查哪些东西？

我今天全天都在。