SQLite 作者类比：AI 不会让程序员消失，只会改工种

结论

SQLite 作者 D. Richard Hipp 借历史打比方：SQL 没有消灭程序员，只是把「手写查询代码」变成了「写清楚要什么」。今天用自然语言让 AI 生成代码，走的是同一条路——重复、模板化的实现越来越便宜，但「说清楚需求、守住边界、验收结果」仍要人来做。对 junior 而言，焦虑「会不会被替代」不如问：下一档稀缺能力是什么。

要点

• 以前贵的是「实现」，现在贵的是「规格」。 没有 SQL 时，查大表要靠 COBOL 程序员逐行写访问逻辑，人力贵、周期长。SQL 用一句 SELECT 就能生成底层代码，程序员没失业，工作从「写访问代码」转向「设计表结构、写查询、调性能」。AI 编程助手同理：从「逐行敲代码」转向「描述意图 + 审查 diff」。

• 「能生成」不等于「能交付」。 SQL 时代也不是随便写查询就完事——索引、事务、锁、数据一致性都要人判断。AI 生成的代码能编译、测试过，仍可能在空输入、并发、权限、错误处理上埋雷。Hipp 的类比提醒：工具升级的是表达层，责任仍在工程师。

• 工种迁移，不是人数清零。 COBOL 查询专家没有集体失业，而是岗位定义变了：更多人能直接写 SQL，但数据库架构师、性能工程师、数据建模师的需求仍在。当下「用 Cursor / Copilot 写 CRUD」变容易，不代表系统架构、安全审计、跨团队协作可以外包给模型。

• 类比来自 SQLite 作者，语境是工程可信度。 Hipp 长期维护被广泛嵌入的 SQLite，说话偏「基础设施怎么活几十年」。Simon Willison 摘这条语录，标签落在 careers 与 sql——不是炒作「AI 取代一切」，而是给工程师一个可对照的历史坐标。

怎么做

1. 把 AI 当成「SQL 级抽象」，不是「自动上线按钮」。 用自然语言或 Agent 生成实现前，先写清：输入输出、失败时要怎样、谁有权限、数据从哪来。这和写 SQL 前先画 ER、定约束是一类工作。

2. 刻意练「规格 + 验收」，少练「盲敲」。 日常任务里固定一步：生成代码后自己过 diff，问边界问题（空值、超时、重复提交、并发）。能发现 AI 漏掉的 case，比手速快更有护城河。

3. 向上游走一层技能栈。 SQL 普及后，只会拼 SELECT 的人压力变大，懂建模与性能的人更吃香。对应今天：在能借助 AI 写业务代码的基础上，补系统设计、可观测性、安全、成本与发布流程——这些仍是团队缺口。

4. 别用 Hipp 类比当躺平理由。 历史是「岗位变形」而非「全员躺赢」；不适应新抽象的人会被边缘化。把学习预算投在：如何与 AI 结对、如何定义任务、如何为生成结果负责。

关键图表

flowchart LR
    A["昂贵手写实现<br/>COBOL 查询 / 逐行编码"] --> B["高层规格表达<br/>SQL / 自然语言 + AI"]
    B --> C["人负责边界与验收<br/>建模 · 性能 · 安全 · Review"]
    C --> D["交付可维护系统<br/>工种变化，人数不归零"]

Hipp 类比的核心：抽象层上移，工程师价值从「写实现」转向「定规格与守质量」