Cursor 的 SQLite 实验：AI 编程的胜负手不只是模型，而是编排

导语

Cursor 最近公布的 SQLite 实验，为“AI 写代码”提供了一个更接近工程系统的样本：一组智能体没有源码、没有测试套件、不能联网，只拿到 835 页 SQLite 手册，最终用 Rust 从零实现了一个数据库引擎，并通过了预留的 sqllogictest SQL 结果一致性测试。

这件事的重点并不在于这个实现能否直接替代 SQLite，而在于 Cursor 试图回答一个更现实的问题：当任务足够大、上下文足够长时，应该让最强模型一路写到底，还是把工作拆成规划、执行、评审和合并？

核心要点

• 测试设计更接近真实验收：Cursor 使用 SQLite 项目的 sqllogictest，并保留智能体事先不知道的测试集；团队还人工检查运行过程，避免系统只是在“刷题”。
• 成本差异非常明显：全部使用前沿模型的方案花费 10,565 美元；由强模型做规划、便宜模型做执行的组合，在质量相近的情况下花费 1,339 美元，接近 8 倍差距。
• 规划与执行分离是关键：规划器负责拆解目标和做设计决策，worker 只处理边界清晰的小任务。这降低了单个智能体在长任务中同时维持全局目标和局部细节的压力。
• 工程化编排比“多开智能体”更重要：旧蜂群出现锁竞争、重复造轮子、文件膨胀和大量合并冲突；新架构引入定制版本控制、中立冲突解决智能体、共享设计文档和可追溯决策引用，使产出更集中。

意义与影响

这次实验说明，大型 AI 编程任务的瓶颈未必只是模型能力，而是如何把昂贵的推理能力用在最值得的环节。真正需要前沿模型判断的，往往是任务拆解、架构选择和关键取舍；大量实现性工作可以交给成本更低的执行模型。

它也指向软件工程角色的变化：开发者越来越像在编写“规格”和“验收器”，而不是逐行实现代码。目标描述、约束设定、测试设计和智能体监督，可能会成为更稀缺的能力。

不过，SQLite 手册结构完整，属于相对理想的输入。真实企业代码库常常文档过期、隐含规则复杂、历史包袱沉重。Cursor 的实验展示了方向，但距离在混乱现实中稳定落地，仍需要更多验证。

来源：InfoQ 中文