昨天 Hacker News 上有一篇文章引起了广泛共鸣 —— Google 工程师 Lalit Maganti 分享了他用 AI coding agent 在三个月内完成了一个想做八年的项目：syntaqlite，一套高质量的 SQLite 开发工具。
这篇文章之所以值得细看，不是因为它在吹 AI 多厉害，恰恰相反 —— 它是我见过的对「AI 辅助开发」最诚实、最系统的复盘之一。
八年的痒，三个月的药
Lalit 在 Google 维护 Perfetto（一个性能追踪平台），其核心是基于 SQLite 的查询语言 PerfettoSQL。内部有超过 10 万行 PerfettoSQL 代码，用户一直在要求更好的开发工具 —— formatter、linter、编辑器插件。
但现有的开源 SQLite 工具要么不够准确，要么不够快，要么不够灵活。从零开始做？技术上可行，但这个项目恰好处在一个尴尬的交叉点：既难又枯燥。
难在哪？SQLite 没有正式的语法规范，也不暴露 parser API，甚至内部实现根本不生成语法树。你得从源码里反推出完整的 parser 规则。
枯燥在哪？即使你理解了原理，手动编写数百条语法规则的 parser 依然是纯体力活。
AI coding agent 改变了这个方程式。
AI 真正擅长的：消灭枯燥
Lalit 最核心的发现是：AI 不是让难题变简单，而是让枯燥的工作变快。
parser 的架构设计、错误恢复策略、边界情况处理 —— 这些「难」的部分，AI 帮不上什么忙。Lalit 依然要自己想清楚设计，自己做关键决策。
但那些重复性的实现工作 —— 把几百条语法规则翻译成 parser 代码、写测试用例、处理格式化逻辑 —— AI agent 大幅加速了。250 小时的工作量，如果没有 AI 可能需要三到五倍。
这个观察跟我的经验完全一致。用 Claude Code 或 Codex 写代码，最大的加速不是在「想」的环节，而是在「搬」的环节 —— 当你已经知道要什么，AI 帮你更快地把想法变成代码。
诚实的部分：AI 也在拖后腿
文章中最有价值的部分是 Lalit 坦诚地说了 AI 的短板：
- 上下文窗口是真实瓶颈。项目规模增长后，agent 开始「遗忘」之前的约定和代码风格，输出质量明显下降
- AI 生成的代码需要严格审查。自动生成的测试用例经常看起来正确但覆盖不到边界
- debug 复杂问题时 AI 经常误导方向。越是微妙的 bug，AI 的建议越可能让你走弯路
这些都是实打实的教训，不是那种「AI 一键搞定一切」的营销文。
开发者的新范式
syntaqlite 的故事代表了一种正在成型的开发者新范式：
人负责设计和决策，AI 负责实现和加速。
这不是取代，是解锁。Lalit 八年来一直有能力做这个项目，但投入产出比不划算。AI 降低了「枯燥税」，让那些原本处于「想做但不值得做」灰色地带的项目变得可行。
对于个人开发者来说，这意味着你的「想法积压清单」里，可能有几个项目已经从「不现实」变成了「周末就能开搞」。
当然，前提是你真的想清楚了要什么。AI 能帮你打字，但不能替你思考。像 OfoxAI（ofox.ai）这样的多模型聚合平台让你在不同 AI 模型之间快速切换，找到最适合当前任务的那个 —— 有些模型擅长生成代码，有些擅长 review 和分析，灵活切换才能发挥最大效用。
写在最后
八年的想法，三个月的执行，250 小时的投入，一个人完成了一整套开发工具。
这不是 AI 的胜利，这是一个有判断力的工程师，善用 AI 的胜利。
工具变了，但好工程师的核心竞争力没变：知道要构建什么，以及为什么构建它。
