观点观点 · 趋势观察

Addy Osmani：AI 写代码的「70% 问题」

原文 · Addy Osmani（Google Chrome 工程负责人）

AI 能飞快带你到 70%，最后那 30% 还是人的活

导读

Google Chrome 工程负责人 Addy Osmani 这篇广为流传的文章，戳破了 AI 编程最常见的幻觉：前期快得像魔法，越到后面越卡。他把这叫「70% 问题」。

下面按原文结构做完整精译导读。

Osmani 观察到两类用法。Bootstrappers 起盘型：用 Bolt、v0 这类工具，几小时就把设计稿变成能跑的 MVP。Iterators 迭代型：在 Cursor、Copilot 里把 AI 揉进日常工作流，天天用。

两类都很爽，但都会撞上同一堵墙。

反直觉的地方：从 AI 获益最多的是资深工程师，不是新手。因为老手会监督、会改、知道哪里不对。

新手不加判断地全盘接受 AI 的建议，产出的是自己都 debug 不了的脆弱代码。Osmani 的比喻：AI 就像团队里一个非常热心的初级开发者。

“AI is like having a very eager junior developer on your team.”

非工程师用 AI 写代码，会撞上一堵让人沮丧的墙：原型飞快做到 70%，然后收益急剧递减。

于是出现「两步前进、一步后退」的循环：每修一个问题又冒出新问题，陷入打地鼠式的调试。

“Non-engineers using AI for coding find themselves hitting a frustrating wall.”

AI 擅长「happy path」一切顺利的主路径，但会漏掉错误处理、可访问性、边界情况，而正是这些把「能用的 demo」和「让人愉快的软件」区分开。

他的判断：软件质量从来不主要受限于写代码的速度。目标不是更快地写更多代码，而是做出更好的软件。

“Software quality was never primarily limited by coding speed.”

新一代工具（Claude 的 computer use、Cline 等）正从「被动助手」转向能自己规划、测试、迭代的自主 agent，但这反而更需要人在架构层面把关。

他给的实操套路：AI 出初稿，人来 review、重构成模块化、补错误处理、测试、写文档；每个任务开新对话、保持上下文聚焦、频繁提交；关键路径手动审查加自动化边界测试。

“The goal isn’t to write more code faster. It’s to build better software.”

作者 · Addy Osmani（Google Chrome 工程负责人）

本页为 GoodVibe 对原文的中文整理，著作权归原作者所有；建议点击上方链接阅读原文全文。