零手写代码搭维基搜索引擎：Claude Code的另一面

前谷歌工程负责人 Hugh Williams 又干了一件能上 Hacker News 头条的事：用 Claude Code 从零搭出一个能跑的搜索引擎 Zettair，索引了 150 万条维基百科词条，自动补全、摘要片段、相关搜索推荐、热门榜单、AI 生成摘要——现代搜索引擎该有的功能基本齐了。整个过程他一行代码都没手写。

这是他继 48 小时用 Claude Code 拉起一套 AWS 系统之后的第二次公开实测。结论比项目本身更值得琢磨：Williams 没有像很多自媒体那样高喊"工程师要失业"，而是给了一个相当冷静的判断——AI 编程的上限，取决于使唤它的人懂多少。

一个被忽略的前提：Zettair 不是从 0 开始的

先把这件事的水分挤一挤。

Zettair 这个名字对老一辈做信息检索的人来说并不陌生——它是 21 世纪初 RMIT 大学（澳大利亚皇家墨尔本理工）开发的开源搜索引擎，Williams 本人就是核心研发者之一。换句话说，他这次让 Claude Code 实现的底层检索框架，是他自己二十多年前亲手写过、亲手调优过、亲手发过论文的东西。

这就意味着：

• 倒排索引怎么建、文档频次怎么算、BM25 的参数怎么调、压缩用 variable byte 还是 Elias gamma——这些 Claude Code 不需要从零探索，Williams 心里有答案。
• 当模型生成的代码在某个分词环节出错、或者在打分函数上跑偏时，他能在几秒钟内指出问题。这种"代码审稿人"的判断力，不是看几篇博客能补上的。
• 提示词本身就是一份高密度的领域知识转译。一个不了解 IR（信息检索）的人，根本写不出能让 Claude Code 直接落地的需求描述。

Williams 自己也没回避这一点。他给出的核心结论是："AI 开发更像是当指导者，而不是写代码。而经验丰富的工程师，永远是最好的指导者。"

这话翻译过来就是：Claude Code 是放大器，不是发生器。 你脑子里有什么，它放大什么；你脑子里没有的，它也变不出来。

这不是个例：Claude Code 正在重写工程师的工作方式

把视野拉远一点，Williams 的实验只是过去这一年里同类故事的最新一例。

年初，谷歌负责 Gemini API 的资深工程师 Jaana Dogan 在 X 上爆了一颗雷：她把团队打磨了一年的分布式 Agent 编排器，用三段话描述给 Claude Code，一小时跑出了一个高度接近的原型。这条推文当时直接把工程师圈引爆，评论区分成两派——一派惊呼"我们一年白干"，另一派则冷静指出：花一年时间反映的是流程问题（会议、对齐、Jira 梳理、命名风格争论），写代码本来就是最容易的部分。

再看 Claude Code 的创造者 Boris Cherny。他在 2025 年底公布的数据更夸张：30 天里，他在 Claude Code 项目上提交了 259 个 PR、497 次 commit、新增约 4 万行、删除约 3.8 万行代码，全部由 Claude Code + Opus 4.5 完成。那个月他甚至没打开过 IDE。

到了 2026 年，Cherny 的工作方式已经进一步演化：

• 主战场转到手机。他每天在 iOS 版 Claude 应用里同时挂着 5–10 个会话，背后挂着几百个 agent，晚上还有几千个 agent 在做后台任务。
• Loop 成为核心抽象。本质就是 cron + 可重复 agent 任务：自动修 CI 冲突、自动 rebase、定时聚类 Twitter 用户反馈，全部自动跑。
• Anthropic 内部已经没有手写代码，所有 SQL、所有功能都是模型写的，团队里不同 Claude agent 之间通过 Slack 互相协调。

听起来像科幻，但这就是 Cherny 描述的 2026 年日常。

那么"编程被解决了"这话到底该怎么听

Cherny 自己有过一个判断："对我来说，编程已经被解决了。" 但他同时补了一句——这不是普遍情况，还有大量复杂代码库、冷门语言模型还搞不定。

把 Williams 的 Zettair 实验和 Cherny 的日常拼在一起看，能得出几个相对靠谱的结论：

第一，AI 编程的真实生产力曲线，是被"用户的领域专业度"调制的。

Williams 能用 Claude Code 做出 Zettair，是因为他就是 Zettair 的原作者。Dogan 用一小时复现谷歌团队一年的成果，是因为她本来就是这个领域的 staff engineer，知道要什么、不要什么。换成一个完全不懂搜索引擎的开发者，给 Claude Code 同样的提示词，大概率只能拿到一个能搜但完全没法用的玩具——分词不对、相关性排序混乱、性能崩溃，每一项都需要专业知识才能诊断。

第二，编程这个动作的技能价值，正在从"实现"向"判断"迁移。

Cherny 在红杉那场对谈里举的印刷术类比很到位：印刷机出现之前，欧洲只有 10% 的人识字，他们靠"读写"这个稀缺技能受雇于贵族。印刷机普及之后，识字率最终爬到 70%，但会写字本身不再是一种职业。会计师、律师、医生、记者——他们都识字，但识字只是基础设施。

软件工程正在走同一条路，只是会快得多。未来真正稀缺的不是会写代码的人，而是：

• 能把一个模糊业务问题拆解成清晰技术目标的人
• 能在 AI 跑偏时一眼看出问题在哪的人
• 能设计出让 agent 协同工作的流程的人
• 能在 AI 给出的方案里识别架构隐患的人

Williams 在 Zettair 项目里做的，全部是上面这些事。

第三，"我没写一行代码"这种叙事要警惕。

它在传播层面非常吸引眼球，但容易误导读者跳过最关键的部分——前置知识。一个更准确的表述是："我没写一行代码，但我写过这个系统、我懂这个系统、我能判断这个系统每一步对不对。"

给想跟进的开发者几点实操建议

如果你也想把 Claude Code（或者类似的 agentic coding 工具）真正用起来，从 Williams 和 Cherny 的实践里能提炼出几条相对通用的方法论：

1. 先用 Plan 模式磨方案，再让它一把梭实现。Cherny 反复强调，规划环节多花几分钟，落地环节能省几个小时。这跟人类工程师 code review 的逻辑一致——前期对齐成本永远比后期返工低。
2. 把高频重复操作固化成 slash command 或子 agent。代码简化、E2E 测试、CI 修复、自动 rebase，这些动作 Claude 完全可以自己跑 Loop。
3. 并行起多个 agent。一个 agent 写功能、一个 agent 做 review、一个 agent 跑测试，不要让 AI 串行执行你完全可以并发的任务。
4. 在你最熟悉的领域试水，别在陌生领域试水。Williams 选 Zettair 不是巧合——他能即时判断输出对错。如果你刚开始用 Claude Code，先拿自己最熟的业务模块开刀，体感会差很多。
5. 把 AI 接进工程流程，而不是停在编辑器里。Slack、BigQuery、Sentry、PR review——Claude Code 能接的工具远比你想象的多，让它进入团队的协作链路才能发挥真正的杠杆。

写在最后

Williams 这个实验真正有价值的部分，不是"AI 多强"，而是它给行业递了一面镜子：

当编程的执行成本无限趋近于零时，谁还能持续创造价值？ 答案显然不是那些坚持"我必须手写每一行代码"的人，也不是那些以为"会用 AI 就够了"的人，而是那些既懂领域、又懂如何让 AI 替自己干活的人。

Zettair 这个搜索引擎本身不重要，重要的是 Williams 二十年前积累的那套知识，在 2026 年依然是他撬动 Claude Code 的支点。这件事对每个还在写代码的人都是个提示：你今天积累的领域 know-how，可能就是你五年后让 AI 干活的资本。

顺带一提，如果你在国内想试 Claude Code、对比一下 Sonnet 4.5、Opus 4.5、GPT-5 和 Gemini 在同一段提示词下的表现，可以看看 OpenAI Hub——一个 Key 切换主流模型，省去翻来覆去开账号的麻烦，对做对比实验来说比较顺手。

参考来源

• 谷歌前工程负责人用 AI 开发出维基百科搜索引擎 - IT之家：Hugh Williams 用 Claude Code 搭建 Zettair 搜索引擎的事件原始报道。