Simon Willison用Codex和GPT-5.6 Sol Ultra造了个新库：alchemy-utils 0.1a0。他把自己维护多年的sqlite-utils从只认SQLite，改成底层用SQLAlchemy、能跑在PostgreSQL和DuckDB上。几轮追问就发出alpha，这本身不算新闻。
真正值得记一笔的，是他顺手扔出的一个数字。同一份旧金山树木CSV导入DuckDB，第一次跑了近一小时。他让Codex重新优化一次，降到35秒左右。这个落差比发布本身更说明问题：AI写代码的速度，和这段代码能不能用，是两件事。
速读：这次发布了什么
alchemy-utils 0.1a0是alpha版本。核心目标很具体：把sqlite-utils最常用的一批API——insert、upsert、insert_all、upsert_all、create、update，还有表结构探查——原样搬过来，换成SQLAlchemy驱动。
已经测试过的引擎是PostgreSQL、SQLite、DuckDB三家。一行CLI命令能查PostgreSQL里的表；喂一份CSV进去，能自动建表把数据导进DuckDB，不用手写schema。
开发流程也不是凭空生成：Codex参照他现成的sqlite-utils代码，PostgreSQL测试思路借了他另一个项目django-sql-dashboard的做法。整个流程用uv建项目、pytest跑红绿TDD，要求频繁提交。
这东西目前谁用得上：写Python数据工具的人，做数据库封装的开发者，还有正在琢磨编码代理到底能不能顶工程活的技术团队。
从近1小时到35秒：alpha还剩多少没扫完
第一次导入近一小时，Simon看不下去，追加一句让Codex去优化，才降到35秒。这条时间线说明：编码代理写出“能跑”的代码很快，但“跑得快”不是模型自己想到的，是人明确提出要求之后才发生的。
原型和能用的软件之间那道坎，不是模型自己迭代填平的，是靠一个知道该问什么的人，一轮一轮把要求提清楚。
alpha版本目前留了几个没验证的地方，摘要里没说清楚，也不该替它拔高：
| 维度 | 目前状态（0.1a0） | 有没有验证清楚 |
|---|---|---|
| 核心API | insert/upsert/insert_all/upsert_all/create/update、表结构探查 | 已实现，测试覆盖范围未知 |
| 数据库覆盖 | PostgreSQL、SQLite、DuckDB | 按指令跑通，测试用例规模未说明 |
| 导入性能 | 树木CSV从~60分钟降到约35秒 | 单个案例，没有其他基准数据 |
| 方言差异 | 类型系统、事务、upsert语义 | 三家数据库差异不小，是否统一处理没说 |
这张表里最后一行才是接下来该盯的地方：SQL方言、类型系统、事务和upsert语义，PostgreSQL、SQLite、DuckDB三家本来就不一样，alpha阶段能不能兜住，现在看不出来。
这事对谁有用，该怎么做
对写Python数据工具的开发者：可以拉0.1a0跑一遍自己常用的表，对比它和sqlite-utils的行为差异。但生产项目先别迁移——upsert语义、事务处理这些边界情况，alpha阶段大概率还没扫完。真正值得直接搬走的，是这套“清晰spec+参考代码+红绿TDD+人工验收”的流程，用来指挥编码代理写自己的小工具。
对正在评估编码代理工程价值的技术负责人：别把“几轮追问发出alpha”当成“代理能独立扛工程”的证据。可复制的不是这次发布的速度，而是Simon提供的那套约束——现成的API清单、参考实现、测试框架、逐步验收。考核编码代理该看团队有没有能力搭这套脚手架，不是看模型参数表。
工欲善其事，必先利其器。这次的器是真利，Codex能把一小时的活压到35秒。但器利不代表事必成——决定alchemy-utils能不能从alpha走到能用的，还是那个知道该测什么、该问什么的人。接下来该看的，是它有没有出0.1beta，方言差异的测试补没补上，而不是又一次“追问几轮就发布”的速成故事。