AI编码真相：前80%只占10分钟，后20%耗80%时间

减轻工作量，而不是消除工作量

AI 用 10 分钟完成了我功能的前 80%。

代码很干净。逻辑讲得通。主路径第一次就能正常工作。我运行了它，看它能工作，感受到了那种特别的开发者自豪感，让人忍不住在椅子里往后靠一下。

我印象深刻。我真的感到很高效。我以为再花 10 分钟，或许 15 分钟就能完成。

那是周二。到了周四晚上，我还在处理同一个功能。不是因为 AI 失败了。而是因为它在完全错误的事情上成功了——简单的部分——而把真正困难的部分完全留给了我。

边界情况。错误处理。空值检查。只有当真实用户做出主路径未能预料的事情时才会出现的情况。

AI 没写这些。它甚至不知道它们的存在。它充满信心且彻底地为一切顺利的世界优化了——而那个世界不是你的用户所处的世界。

这就是 AI 代码的 80/20 法则。前 80% 很快、令人印象深刻、有点魔幻。最后 20% 是真正的工作所在。而它需要花费 80% 的总时间。

以下是我对这个差距的认识，以及为什么我认为它比周二你省下的那 10 分钟更重要。

80% —— 快速、干净且真正令人印象深刻

在我开始谈论挫折之前，我想对这部分保持诚实。

AI 在前 80% 上的表现是非凡的。你给它一个清晰的提示，它理解主路径是什么样的，然后生成可以工作的代码。不是"勉强能工作"。真正可以工作，有合理的变量名和符合你预期的逻辑流。

我第一次看到它实际运作时，我真的觉得自己在某件事上作弊了。工单在关闭。速度图表在上升。我以前几年发布的东西比现在还多。

这种感觉是真实的——我不是在讽刺。AI 之所以快，是因为它在熟悉的领域运作。主路径是踩过的路。这是你的问题在某种形式上存在于训练数据中、已被解决过数千次、模型可以有信心地通过模式匹配解决的版本。

这 80% 是真实的。速度是真实的。

问题在于，我们开始把这 80% 当作整个事情。但它不是。

20% —— 周二变成周四的地方

AI 写了主路径。这是它没写的诚实清单：

空列表。当用户还没有数据时会发生什么？新账户、数据库中什么都没有、AI 假设总是会有项目的列表结果是空的。AI 没有检查。你从发布后三天的用户报告中才发现，花一个小时跟踪回未处理的情况，然后添加本应在周二就写好的检查。

错误处理。AI 假设网络会响应。它假设 API 会返回你要求的东西。它假设第三方服务是正常运行的。每个 try-catch 块、每个备用方案、每个"如果这失败了我们向用户显示什么"的决定——都是你的。AI 留下了空白，因为事情出错不是提示的一部分。

特定于领域的边界情况。这是每次都让我惊讶的那个。AI 不了解你的业务逻辑。它不知道"空"在你的应用程序的三个不同部分中意味着不同的东西。它不知道格式不同的遗留数据。它不知道以出乎意料的方式使用产品的企业客户。你知道这些事情。AI 从未听说过它们。

性能悬崖。AI 为它被给出的例子写的代码是有效的。它没有针对规模进行压力测试。当功能上线时你发现了瓶颈，对于有大型数据集的用户，页面突然花费四秒钟加载。代码没错。它只是没有在真实负载的考虑下编写。

可维护性成本。这是显现最慢的。AI 写的代码解决了今天的问题。三个月后当需求略微改变而你试图扩展它时，你意识到这个抽象不太适应新的形状。重构它花费的时间会比从头开始写还要多。

这些项目中的每一个都需要时间。总起来，它们通常加起来约占我用 AI 生成代码发布的任何功能的总工作量的 80%。

30 秒花费我 3 小时

我最近在看一个 pull request——大约 200 行 AI 生成的代码，我花了大约 30 秒提示它。

接下来我花了 3 小时。

不是因为代码坏了。代码很好。我花了 3 小时添加 AI 默默认为不是它的问题的所有东西：错误路径、空值检查、解释不太明显决策的注释、我通过实际思考我们的用户做什么而发现的边界情况。

在那 30 秒内我感到很快。在那 3 小时内我感到很慢。

但这里是我一直回到的事情：这 3 小时是实际的工作。那 30 秒是脚手架。AI 没有减少工作——它重新分配了它。时间从编写结构转移到使其真实化，而使其真实化是较慢的，因为它需要 AI 真正没有的东西：关于你的具体情况、你的具体用户、你对这个代码库的具体历史的背景。

这是我停止关心生成花了多长时间并开始跟踪更诚实的东西的时刻：要花多长时间才能真正准备好发布。

为什么这不是对 AI 的抱怨

我想明确一点——80/20 的分割不是 AI 的失败。它基本上就是设计。

AI 针对常见情况进行了优化。常见情况就是主路径。快速生成常见情况是真正有用的；我不是在轻视这一点。

问题不在 AI 身上。问题在于我们如何开始围绕它衡量生产力。

我们衡量速度。关闭的工单。生成的代码行数。贡献图表。所有这些指标都完美地捕捉了那 80%——因为那 80% 是快速的、可见的、显示为绿色方块的。

那 20% 对这些指标是不可见的。没有人的仪表板显示花在添加错误处理上的时间。没有人的站会以"我昨天花了边界情况 AI 没有预料到的时间"开始。它不会在任何地方出现。但那是大部分实际时间所在的地方。

那 80% 是能让你进行演示的东西。那 20% 是能让你进入生产环境的东西。如果你不跟踪那 20% 花了多长时间，你就不是在跟踪你的真实生产力——你在跟踪你能以多快的速度键入提示并感到满意。

我实际上在不同地做的事情

不是戒掉 AI。甚至都没有考虑。但我改变了几件事：

我预先为那 20% 编制预算。当我估计任何涉及 AI 生成代码的任务时，我大致添加 4 倍于生成时间所建议的任何东西。AI 说"这是一个 10 分钟的功能"。我告诉我的大脑它是一个 40 分钟的功能并相应地计划。这不是悲观主义——这只是模式成立。

我明确提示不幸路径。甚至在我生成主代码之前，我添加到提示中：空输入应该发生什么？API 失败时应该发生什么？这里存在哪些边界情况？AI 不会自己想到它们。如果我命名它们，它至少会对它们进行一次尝试。

我在代码存在之前编写失败的测试。什么会破坏这个？一个淘气的用户会做什么？我首先编写这些测试，以便 AI 有一个目标。它不会捕捉所有东西，但它比 AI 自己会发现的要多。

我记得那 3 小时。当我被诱惑因为它在演示中有效而快速推动某些东西时，我会想到那 3 小时。那 30 秒感觉很好。那 3 小时是这份工作。

这些都不会让那 20% 消失。但它使它可预测而不是令人惊讶，这是管理它和被它伏击的区别。

你在 AI 快速生成的东西的最后 20% 花费的最长时间是多少？

如果你有的话，我想要实际的数字。生成花费的时间和实际花费的时间之间的差距——那是我好奇的数字。

我的答案：生成 30 秒，完成 3 小时。

我想提醒一下，我用 AI 帮助组织这篇文章并完善我的想法。经历、故事和观点是我自己的。

一些评论可能只对登录的访客可见。登录以查看所有评论。