谷歌团队埋头研究1年=Claude Code 1小时？Gemini API负责人大赞竞品，却引程序员破防

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

新年伊始，科技圈因为一场关于 AI 编程能力的问题“吵翻了天”。

事情起因是 1 月 3 日， 谷歌首席工程师 Jaana Dogan 在社交平台上公开“夸起了自己 Gemini 的竞品”。她晒出的经历堪称“降维打击”：谷歌团队吭哧吭哧干了一年的工作成果，结果 Anthropic 的 Claude Code 只用 1 小时就拿出了方向一致的方案。

Jaana Dogan 还直言：“我不是在开玩笑，这一点也不好笑。”

此番言语一出，Reddit、Hacker News 上的开发者直接炸了锅，有人赞同表示，“AI 编程要革传统开发的命”，也有人深度质疑：“确认这对比真的没水分？”

用三段提示，1 小时追上 1 年研究进度？

如果说这话出自一位普通工程师，或许并不能掀起多大风浪，但让人不可置信的是，Jaana Dogan 也负责谷歌 Gemini API 的开发工作。

她在 X 上发帖表示，自己只是把问题描述丢给了 Claude Code，结果一个小时后拿到的方案，和团队过去一年努力构建的方向几乎一致。

要知道 Jaana Dogan 询问 Claude Code 这个问题本身并不简单，涉及的是“分布式智能体编排器”——也就是协调多个 AI 智能体协同工作的系统。

Dogan 透露，过去一年里，谷歌内部其实已经尝试过不少思路，但一直没能在方案上达成共识。

更让网友惊讶的是，她给 Claude Code 的提示词一点都不“复杂”。在评论区，当有人追问 “提示写得有多详细？更接近一个随手的简要说明，还是完整、正式的产品需求文档？”，Jaana 回复得很实在：“提示词非常简略，因为不能用公司内部信息，我当时正在基于一些现有想法构建一个玩具版本，用来评估 ClaudeCode。提示词只有三段。”

当然，结果也不是一步到位。Dogan 坦言，生成的方案还不完美，需要进一步打磨。她给“代码智能体怀疑论者”的建议是：「不妨先在自己非常熟悉、判断力最强的领域试一试，感受一下它们到底能做到什么程度。」

争议四起：谷歌为什么不用自家工具？AI 编程是否存在“水分”？

看到 Jaana 的帖子，许多用过 AI 编程工具的程序员观点不一，评论区也立刻分成了“三派”，吵得不可开交。

观点一：“这算不算是谷歌被竞品‘打脸’了？”

不少网友质问道：“你们自家有 Gemini，为什么不用它测？Gemini 什么时候能做到这水平？”、“谷歌工程师使用竞争对手的 LLM 而不是他们自己的内部 LLM，这难道不更能说明问题吗？”

Jaana 倒是没回避这些犀利的提问，其直接回应：“我们正在全力推进，不管是模型本身，还是配套的工程体系，都在赶。”

此外，当被问到谷歌内部是否在使用 Claude Code 时，Dogan 表示，目前只允许用于开源项目，不能用于公司内部开发。

她还补充说，这个行业从来都不是零和博弈，该给竞争对手的肯定就要给。“Claude Code 的确做得很出色，这让我既兴奋，也更有动力去推动大家一起往前走。”

观点二：“1 小时 vs 1 年，是不是太夸张了？”

这也是争议最大的点，如果 AI 能做到这种程度，工程师、开发者、程序员的未来该怎么办？

对此，有开发者觉得“数据不对劲”，质疑 “过去一年，难道谷歌团队都在‘摸鱼’？”

也有程序员觉得：“它生成的代码（Svelte、TypeScript、Python）通常充满了小错误、过时用法、重复实现，还有糟糕的模块划分。这是 Opus 4.5 的表现。老实说，如果我每次不仔细审查并彻底修改，它都会变成一座难以调试的技术债务大山。说实话，这是否真的比手工写更快，还很难说。我觉得，人们把对这项技术的期望当作已经实现的现实来表达，这种现象本身就非常有意思。”

还有人认为 Jaana 这番公开的夸赞似是在否定人类工程师的价值：

「我对这些说法深表怀疑。

每次有人说“AI 一小时就完成了我们花了一年的工作”，他们真正的意思其实是：人类花了一年时间做了艰难的思考，而 AI 只是以硅速度把这些内容复述了一遍。这当然和真正的生产力完全不同。

而且，如果你的团队真的花了一年时间完成，那更多说明的是你们的流程问题，而不是 AI 的问题。但这并不会威胁到我的世界观——只是以另一种方式，更安全的方式提醒你。

要明确一点：写代码是最简单的部分。真正的工作是开会、达成共识、进行架构讨论、整理 Jira 任务，以及在 snake_case 和 camelCase 之间做道德斗争。Claude 并没有做这些。因此它实际上什么也没做。

我个人花了多年时间培养直觉、判断力和审美。这些东西无法被自动化，除了显然可以被一个在我坚持认为“微妙”的领域不断超越我的概率文本模型所取代。

当然，输出可以运行，当然，它可以通过测试，当然，它可以替代数月的工作。但它根本不理解自己在做什么。不同于我，我至少完全理解自己从 Stack Overflow 上复制的东西。

另外，我去年试过 AI，它曾出现过一次幻觉，所以我断定整个领域已经永久达到瓶颈。众所周知，技术在早期糟糕的演示之后通常不会再进步。

总之，我仍然毫不担心。如果 AI 真有那么强大，它早就让我变得无关紧要了，但我现在还有工作，所以这一切肯定都是炒作。证毕。

现在请原谅，我得花整个下午解释，为什么一个刚刚让人类一年努力白费的工具，不过是“自动补全”。」

面对“AI 用1 小时 vs 人类工程师耗费 1 年”所带来的巨大落差争议，Jaana 随后专门发了系列帖子补充项目背景情况，她表示：

“为了在这个话题上理清思路，提供更多背景会很有帮助：去年我们已经构建了这个系统的几个版本。每种方案都有优缺点，没有明确的赢家。

• 当用存活下来的最佳思路对 AI 工具进行提示时，编码智能体能够走得很远，大约一小时就能生成一个相当不错的‘玩具版’。

• 现在用你的知识重新构建它完全很容易，而这在过去是不可能的。

• 组织惯性确实存在，但在大公司里构建适用于多种使用场景的基础设施也非常困难。

• 将想法落地到产品并形成可长期沿用的模式需要数年时间。

• 一旦你拥有了这些洞察和知识，实际构建就没那么难了。因为可以从零开始构建，最终产物不会带有历史包袱。”

而针对“AI 生成方案是否等于产品”的疑问，她反驳道：“构建第一个版本不等于构建产品。”

Jaana 表示，“我这个周末做的这个还不是量产级的，只是个玩具版本，不过是个很有用的起点。最终成品的质量让我很惊喜，因为我并没有深入探讨设计选择，但 CC 还是给了我一些不错的建议。”

即便如此，依然有网友认为她起初的说法夸张——“Claude Code 用 1 个小时就搞定了团队过去一年的摸索方向”，对此，Jaana 进一步解释：“并不完全是这样。它是从非常简略的描述中抓住了正确的设计选择。过去的 12 个月，我们主要是在验证各种方案。最终，我知道理想的架构模式，但它能够在没有指令的情况下提出这个方案。”

观点三：“AI 编程到底是革命，还是炒作？”

针对这一点，Jaana 自己都感慨：“自从开始从事编程语言相关工作以来，我还从未在开发者社区里见过如此两极分化的反应。围绕编码智能体有大量的炒作和空洞宣传，不幸的是，这些声音常常淹没了真正踏实、有价值的工作。事情本不必如此对立。”

对于 AI 编程目前的进展，Jaana 表示：“我们仍处在一个阶段，这可以被视作整个行业范围内的研究项目。语言模型仍在不断探索和优化。我们会在看到价值的地方投入生产化，这也帮助我们进行更多探索。

三四年前，我曾考虑过退休，因为整个行业看起来已经过于饱和。几乎没有真正新的东西可供开发了。作业调度器、网络接口……我们实际上是在重新造已经造过的东西，只是带来了更多复杂性。

我很喜欢这个领域带给我们的新鲜感，为像我这样的工程师提供了一条不同寻常的探索之路。大型语言模型过于迅速地变得触手可及，也因此引发了强烈的反应。但在此之前，有一小群人带着好奇心探索这些模型。我怀念那些岁月。”

与此同时，Jaana 还回顾了 AI 辅助编程这几年的飞速演进：

• 2022 年，系统只能补全单行代码；

• 2023 年，可以处理一整段逻辑；

• 2024 年，已经能跨多个文件工作，甚至搭出简单应用；

• 到了 2025 年，它们已经可以创建、重构完整的代码库。

她坦言，早在 2022 年时，自己根本不相信“2024 年这个阶段”能真正规模化，成为面向全球开发者的产品；而在 2023 年看来，如今的水平至少还要五年才能实现。

“这个领域在质量和效率上的提升，已经远远超出了任何人的想象。”她写道。

Jaana 还说道，从传统工程转向机器学习的过程，本身就充满了挑战：“从传统工程转向机器学习，需要调整心态，并适应累积的不确定性。当你意识到收益与损失不再遵循常规趋势，短时间内就可能出现重大回退时，文化冲击便随之而来。打造出色的产品需要专注、奉献、近乎痴迷的投入，一支相对志同道合的优秀团队，以及对行业混乱本质的保护。优秀的产品就像独角兽一样稀有。”

她还吐槽了行业现状：“在这个行业里，大多数开发者能够真正推动事情发生的日子已经很久远了。复杂性和繁文缛节让摩擦极高，整个行业能持续运转本身就是一个奇迹。我们不能总是要求人们在不断应对冲突和处理争议的情况下保持 100% 的产出。你要么有效地消除争议并开辟新的空间，要么最终只能淘汰人手。总有东西会出问题。”

AI 编程带来的效率提升，让不少人深有感受。Jaana 直言：“关于编码智能体的所有争议，只是一个表象。自始至终，行业现状和就业市场的状况才是根本问题。”也正因为这种效率和潜力，引发了更多人对 Claude Code 本身实际表现的兴趣——不仅仅是“玩具版”的测试，还有它在真实工程环境中的生产力。

Claude Code 作者的实战心得

有意思的是，不久之前，Claude Code 的创造者 Boris Cherny 在 X 上分享了自己过去一个月使用 CC 的真实生产数据：

2024 年 9 月，我把 Claude Code 当作一个业余项目创建出来时，完全没有想到它会发展到今天这样的规模。看到 Claude Code 成为如此多工程师的核心开发工具，看到社区所展现出的巨大热情，以及人们将它用于从编程、运维、科研到非技术场景的各种用途，这让我感到既谦卑又震撼。这项技术既陌生又充满魔力，它极大地降低了人们构建和创造的门槛。越来越多的情况下，代码本身已经不再是瓶颈。

在过去 30 天里，我合并了 259 个 PR —— 共 497 次提交，新增约 4 万行代码，删除约 3.8 万行代码。而且，每一行代码都是由 Claude Code + Opus 4.5 编写的。Claude 可以稳定地持续运行数分钟、数小时，甚至数天（借助 Stop hooks）。

而近日就在 Jaana 发帖差不多同一时间，Boris Cherny 也公开了自己的使用经验，希望给正在使用 Claude Code 的开发者带来参考：

我的配置可能会让你觉得很“普通”！Claude Code 开箱即用效果就很好，所以我个人几乎不做自定义。使用 Claude Code 并没有唯一正确的方式：我们故意把它设计成你可以随意使用、定制，甚至自由改造。Claude Code 团队的每个人用法都各不相同。

那我直接说说我的做法吧：

1. 我在终端里同时运行 5 个 Claude。我给标签页编号 1–5，并用系统通知来知道哪个 Claude 需要输入。https://code.claude.com/docs/en/terminal-config-2-system-notifications

2. 我也会在 http://claude.ai/code 上同时运行 5–10 个 Claude，与本地的 Claude 并行。当我在终端写代码时，经常会把本地会话交给网页端（用 &），或者手动在 Chrome 中启动新会话，有时我会在两者之间“瞬移”。每天早上和工作中，我也会用手机（Claude iOS 应用）启动几个会话，并稍后查看。

3. 我用 Opus 4.5 并开启思考模式处理所有事情。这是我用过的最强大的编程模型。虽然它比 Sonnet 更大、更慢，但因为需要干预更少、工具使用能力更强，最终效率通常比用小模型更高。

4. 我们团队共享一个 Claude Code 仓库的 http://CLAUDE.md。我们会将它提交到 git，团队每周多次贡献内容。每当发现 Claude 做错事情，我们就记录到 http://CLAUDE.md，这样 Claude 下次就不会再犯同样错误。其他团队会维护自己的 http://CLAUDE.md，每个团队都有责任保持文件更新。

5. 代码审查时，我经常在同事的 PR 上标记 @.claude，把需要记录的内容加入 http://CLAUDE.md。我们使用 Claude Code 的 Github Action（/install-github-action）来操作。这是我们对 @danshipper 的 Compounding Engineering 的一种实现方式。

6. 大多数会话从 Plan 模式开始（shift+tab 两次）。如果我的目标是写一个 Pull Request，我会先用 Plan 模式，并和 Claude 反复确认计划直到满意。然后我切换到自动接受修改模式，Claude 通常可以一次性完成。一个好的计划非常重要！

7. 我对每天会多次执行的“内部循环”工作流都会使用斜杠命令（slash commands）。这样可以避免重复提示，也让 Claude 能够使用这些工作流。命令会提交到 git，保存在 .claude/commands/ 下。例如，Claude 和我每天会用 /commit-push-pr 斜杠命令几十次。这个命令用内联 bash 预先计算 git status 和其他一些信息，使命令运行快速，并避免和模型来回交互（https://code.claude.com/docs/en/slash-commands-command-execution）。

8. 我还经常使用一些子智能体：code-simplifier 会在 Claude 完成工作后简化代码，verify-app 有详细说明用于端到端测试 Claude Code，等等。和斜杠命令类似，我把子智能体看作是自动化我大多数 PR 中最常用的工作流。

9. 我们使用 PostToolUse hook 来格式化 Claude 生成的代码。Claude 通常开箱就能生成格式良好的代码，hook 处理最后 10%，避免 CI 中出现格式错误。

10. 我不使用 --dangerously-skip-permissions。相反，我用 /permissions 预先允许一些我确认在环境中安全的常用 bash 命令，避免不必要的权限提示。这些设置大多记录在 .claude/settings.json，并与团队共享。

11. Claude Code 会替我使用所有工具。它经常会在 Slack 上搜索和发消息（通过 MCP 服务器）、运行 BigQuery 查询以回答分析问题（使用 bq CLI）、从 Sentry 获取错误日志等。Slack MCP 配置提交在 .mcp.json，团队共享。

12. 对于耗时很长的任务，我会采取以下做法：

    (a) 任务完成后，用后台智能体提示 Claude 验证其工作；

    (b) 使用 agent Stop hook 更确定性地完成验证；

    (c) 使用 ralph-wiggum 插件（最初由 @GeoffreyHuntley 想出的）。

    我还会在沙箱环境中使用 --permission-mode=dontAsk 或 --dangerously-skip-permissions 来避免权限提示，让 Claude 可以自由运行而不被我阻挡。

13. 最后一个提示：想要从 Claude Code 得到优秀结果，最重要的事情之一就是——给 Claude 一种验证其工作的方式。如果 Claude 有这个反馈回路，最终结果的质量可以提升 2–3 倍。

Claude 会用 Claude Chrome 扩展测试我提交到 http://claude.ai/code 的每一处修改。它会打开浏览器、测试 UI，并不断迭代，直到代码可用且用户体验良好。

不同领域的验证方式会有所不同。可能只是运行一个 bash 命令，或者运行测试套件，或者在浏览器或手机模拟器中测试应用。务必投入精力，确保这个验证过程非常可靠。

来源：https://x.com/bcherny/status/2007179861115511237

事实上，随着 AI 辅助编程能力快速提升，人类工程师的角色也在悄然发生变化。当 AI 能在短时间生成可运行方案时，人类在决策、架构判断和团队协作中的边界该如何界定？这不仅是技术问题，也涉及组织和管理，每一位开发者、管理者乃至研究者都值得认真思考。

https://x.com/rakyll/status/2007735665023488236

https://x.com/bcherny/status/2007179861115511237

https://the-decoder.com/google-engineer-says-claude-code-built-in-one-hour-what-her-team-spent-a-year-on/