Claude Code Ultracode模式实测：12小时生成SQLite的SPARQL扩展

Simon Willison 最近的一次实验，展示了 AI 编程代理在“Ultracode”模式下的惊人产出，也暴露了一个尴尬的现实：我们可能正在制造自己无法理解的代码。

实验背景：当“删除行”变成“SPARQL 引擎”

Simon Willison 在 Claude Code 的“Ultracode”模式下，输入了一个包含手机输入法 typo 的提示词：要求用 Rust 写一个 SQLite 扩展，植入 SPARQL 并“直接命中 delete 行”以实现高速运行。他本意是“hit the rows directly”，但“delete”是个意外。

这个小小的输入错误，加上 Ultracode 模式对动态工作流的激进使用，让 Claude Code for web 持续运行了超过 12 个小时。它生成了大量 Rust crate，并自动协调子代理网络来分解复杂问题。

据 Simon 的后续记录，他第二天检查进度时，只追加了一条提示：要求每个 crate 目录都有 README，并附带 tutorial.md 和示例数据脚本。最终，他得到了一个“完整的 SPARQL 1.1 实现”，以 Rust 编写，运行在 SQLite 内部。

SQLite 扩展是 SQLite 提供的一种插件机制，允许开发者用 C/C++ 或支持 C ABI 的语言（如 Rust）编译出动态库，在运行时加载，从而为 SQLite 增加新的函数、虚拟表或查询能力。由于 SQLite 本身是嵌入式数据库，扩展机制让它在保持轻量的同时具备可扩展性。Rust 通过 rusqlite 等 crate 提供了对 SQLite C API 的安全封装，因此“用 Rust 写 SQLite 扩展”意味着生成的 crate 需要妥善处理 FFI 边界、内存安全和错误传递。SPARQL 是 W3C 定义的 RDF 图数据查询语言，其 1.1 版本包含图模式匹配、聚合、属性路径和联邦查询（SERVICE）等复杂特性。将 SPARQL 实现为 SQLite 扩展，本质上是在关系存储之上构建一个图查询引擎，需要处理 RDF 三元组到关系表的映射、查询解析与代数执行，因此涉及的工作量远大于普通脚本。

Ultracode 模式：动态工作流如何工作

根据 Claude Code 文档，Ultracode 模式会“激进地使用动态工作流”——它生成 JavaScript 代码来定义和协调一组子代理，让它们协同解决复杂问题。这不再是简单的单次代码补全，而是一个多代理编排系统。

这种模式的优势在于处理长周期、多模块的任务。一个 SQLite 扩展涉及解析器、查询优化器、存储引擎接口等多个层面，SPARQL 1.1 又包含复杂的图模式匹配和联邦查询特性。单次提示很难覆盖，但动态工作流可以把它拆解为可管理的子任务。

Simon 的实验表明，这种编排可以持续 12 小时以上，自动创建多个 Rust crate 并保持代码结构。他只需要在关键节点检查并追加指令。

子代理（sub-agent） 指由主代理动态派生、负责特定子任务的独立 AI 实例，通常拥有各自的上下文窗口和工具权限。主代理通过生成代码或结构化指令来编排这些子代理，例如让一个子代理负责解析器、另一个负责测试用例，并汇总它们的输出。动态工作流则强调编排逻辑本身不是预先硬编码的，而是由模型在运行时生成（Claude Code 文档中提到生成 JavaScript 来定义工作流）。这种方式适合任务边界模糊、需要探索的场景，但也带来可预测性下降的问题：开发者难以预先知道代理会创建哪些模块、以何种方式协调，审查时也必须同时理解生成的代码和工作流本身的逻辑。

成果与困惑：无法审查的代码

项目被命名为 sparqlite，托管在 Simon 的 research 仓库中。从表面看，这是一个功能完整的 SPARQL 1.1 实现，能够直接在 SQLite 中运行。SPARQL 是 RDF 数据的查询语言，在语义网和知识图谱领域有重要地位。将它与 SQLite 结合，理论上可以让嵌入式数据库直接查询 RDF 数据，无需额外的图数据库。

但 Simon 的困惑同样真实：“这感觉像是下一级别的 vibe coding——审查这里产生的代码是根本不可行的，甚至跟随文档也是一项重大的工作投入。”

他坦言：“我似乎现在有了一个完整的、用 Rust 编写的 SQLite 内 SPARQL 实现，但如果我是一时兴起创建的，并且不能（或不愿意）投入必要的时间去理解它能做什么，那它有多大价值？”

这触及了 AI 辅助编程的核心矛盾：生成速度远超理解速度。当代码量达到数千行、涉及多个 crate 和复杂算法时，人工审查的成本可能高于从头编写。

vibe coding 是 Andrej Karpathy 在 2025 年提出的说法，指开发者主要依靠自然语言提示让 AI 生成代码，自己更多是“感受”结果而非逐行审查。Simon 称此次实验为“下一级别的 vibe coding”，是因为任务规模和自主性都显著提升：不再是一次生成一个函数，而是由代理连续工作数小时、产出多个 crate。这一概念与代码审查成本直接相关——传统审查假设代码量可控、作者能解释设计意图；当生成方是 AI 且缺少同步产生的设计文档时，审查者需要逆向重建意图，成本急剧上升。这也解释了为什么 Simon 强调“甚至跟随文档也是一项重大的工作投入”：可维护性不仅取决于代码正确性，还取决于人类能否建立心智模型。

对开发者的启示：效率与理解的平衡

这个实验对日常开发者有几点参考价值。

第一，AI 代理已经能够处理需要多天人类工作的模块化任务。12 小时的自主运行和自动协调子代理，意味着某些类型的项目可以大幅压缩前期开发时间。

第二，提示词的精确性依然关键，但容错性在提高。一个意外的“delete”没有导致项目失败，反而被 AI 合理化并继续执行。这既显示了模型的鲁棒性，也提醒我们结果可能偏离初衷。

第三，代码审查和知识转移成为新的瓶颈。Simon 的困境不是个例：当 AI 生成大量代码时，团队如何确保可维护性？或许未来的工作流需要 AI 同时生成解释性文档、测试用例和架构图，而不仅仅是代码。

sparqlite 项目本身是否会被广泛采用尚不可知，但它作为一个标志性案例，记录了 AI 编程代理从“辅助补全”向“自主构建”的转变。对于关注 AI 编程工具发展的开发者来说，值得跟踪这个仓库的后续演进。