80% 困境：工程师曾经栖身的那最后 20%

背景

在生成式 AI 迅速介入软件工程领域的当下，一个看似乐观的现象背后隐藏着深层的职业危机。AI 编码助手（如 GitHub Copilot、Cursor 等）能够以惊人的速度生成代码，让开发者迅速达到“可用”状态。然而，这种效率的提升并非没有代价。

这篇文章源自 Hacker News 上的深度讨论，作者通过回顾软件工程中的经典悖论——“前 90% 的代码占用 90% 的时间，剩下的 10% 代码占用另外 90% 的时间”，指出了 AI 时代的新问题：AI 极大地压缩了前 80% 的开发时间，但被省略或简化的“最后 20%”，恰恰是工程师建立专业判断力、理解系统底层逻辑以及应对生产环境复杂性的关键区域。如果这一部分被忽视，不仅会导致系统在生产环境中崩溃，更会导致工程师自身专业能力的退化。

核心内容

经典的“最后 10%”悖论与 AI 的位移

文章首先引用了 Bell Labs 的 Tom Cargill 和 Jon Bentley 在《Programming Pearls》中著名的段子：编写代码的前 90% 需要 90% 的时间，而剩下的 10% 需要另外 90% 的时间。这个段子之所以经典，是因为它荒谬的算术背后是精确的工程体验：系统可见的、用于演示的部分（Happy Path）往往能迅速完成，但真正决定系统生死的是那些未被预算覆盖的部分——边缘情况（edge cases）、故障模式（failure modes）、高负载下的表现以及运维现实。

生成式 AI 并没有废除这一规则，而是将其“迁移”了。当你要求一个编码模型构建一个功能时，它能以惊人的速度和流畅度生成前 80% 的代码：包括正常的逻辑流程、通过基础测试的结构以及演示用的脚手架。但这 80% 的有效性有一个前提：模型必须在类似的问题上受过训练，并能泛化到当前场景。如果指向训练数据触及甚少的领域，模型虽然不再“流利”，但会给出同样自信的、幻觉般的脚手架。

被静默跳过的“最后 20%”

AI 真正静默跳过的是那关键的 20%。这部分代码在开发环境中通常是不可见的，因为开发环境很少能暴露出那些需要持续运营经验才能处理的场景。例如：

• 防止并发请求破坏状态的幂等性键（idempotency key）；
• 防止重试风暴的退避与抖动机制（backoff and jitter）；
• 避免长时间表锁的迁移策略；
• 速率限制器（rate limiter）、熔断器（circuit breaker）；
• 使得凌晨 3 点故障可诊断的结构化日志。

代码可以编译，测试可以通过，演示可以运行，工件看起来已经完成。但当它面对并发、流量激增、部分网络故障或生产环境中的其他“普通残酷性”时，它实际上并未完成。

工程师的成长与判断力的丧失

这最后的 20% 是工程师曾经“居住”的地方。它从来不是有趣的部分，但是塑造性的部分。

• 通过追踪无法解释的段错误（segfault）和并行程序中的随机损坏，工程师学会了内存管理；
• 通过调试只在周二出现的竞态条件，工程师学会了并发处理；
• 通过观察查询在千行数据上飞掠、在千万行数据上崩溃，工程师学会了数据形态的理解。

这些教训虽然不温和、也不高效，但它们有效，因为系统会在你真正理解它之前拒绝工作。AI 生成的 80% 是阻力最小的部分，而被跳过的 20% 恰恰是负责“教学”的部分。

合成能力（Synthetic Competence）

文章提出了一个核心概念：合成能力（Synthetic Competence）。这不是无能，也不是幻觉，而是“具有理解表面纹理但缺乏底层理解”的输出。 开发者利用 AI 可以生成流畅的设计文档、看似合理的代码、自信的建筑建议、整洁的迁移计划和清晰的事件摘要。表面上看，胜任力（competence）的表面积急剧膨胀，但背后的深度可能毫无进展。工件看起来被理解了，但人以及工件所适用的系统可能并没有。

在旧世界里，不理解某事表现为无法构建它。现在构建变得廉价，理解必须通过其他方式检查：通过预测事物如何失败、命名其假设的能力，以及在压力下适应的能力来验证。

“暴力执行的良好计划” vs. “被忽视的风险”

文章引用了巴顿将军的名言：“一个现在被暴力执行的良好计划，优于未来某个不确定时间执行的完美计划。”这通常被解读为反对计划瘫痪，强调行动的重要性。

但在 AI 语境下，这引发了一个矛盾：被省略的 20% 是应该跳过并继续前进的东西，还是悄悄杀死你的东西？

• 战争类比：战场计划随着与敌人的接触而不断适应，缺口由理解局势的人填补。这就是“现在执行”优于“等待”的原因。
• AI 的陷阱：AI 跳过的 20% 不会在接触中自动填补。没有指挥官在循环中适应地面情况，只有一个看起来 finished 的工件。如果将其搁置，直到负载、竞态或部分中断发现它，它才变得可见。

因此，新的敏捷契约（new agile bargain）应该是：交付 AI 生成的 80%（在许多情况下这确实足够好），然后系统地计划去寻找和调整那 20%，使其在接触现实时能够适应。计划不是“这已经完成了”，而是“这足够好以开始，并且我们已经配备了人员和工具，以进行真正完成它的‘战火中的适应’”。

关键要点

• AI 加速了前 80%，但隐藏了最后 20%：AI 能快速生成正常路径逻辑和基础结构，但省略了处理边缘情况、并发、故障恢复和可观测性的关键工程细节。
• 经验的价值并未降低，反而提升：当打字和基础编码由 AI 处理时，决定性的技能转变为系统判断力——选择正确的算法、预见组件在压力下的行为、理解系统的真实意图。
• “合成能力”是主要风险：AI 输出的表面流畅性掩盖了深度的缺失。开发者可能产生“我理解了”的错觉，但实际上缺乏对系统失败模式和假设的深刻理解。
• 工程师的专业肌肉萎缩：过去，工程师通过调试生产环境中的棘手问题（如竞态条件、内存泄漏）来建立判断力。如果这些工作被 AI 跳过，工程师将失去通过“系统拒绝工作”来学习的机会。
• 新的敏捷策略：不应盲目追求完美计划，也不应盲目依赖 AI 生成的代码。正确的做法是快速交付 AI 生成的 80% 作为起点，但必须主动规划资源去识别、修补和适应那关键的 20%，特别是在生产环境中。
• 判断力无法被自动化：模型无法提供那 20% 所需的判断力。作者承认，尽管 AI 进步迅速，但在优化和系统权衡上，人类工程师往往仍能超越 LLM，但这取决于工程师是否保持了足够的挑剔和深度思考。

意义与影响

对工程师职业发展的警示

这篇文章对初级甚至中级工程师发出了严厉警告。如果过度依赖 AI 生成代码而跳过调试、优化和故障排查的过程，工程师将失去建立“工程直觉”的机会。这种直觉是区分“代码编写者”和“软件工程师”的关键。长期来看，这可能导致人才断层，即大量开发者能够构建“看起来工作正常”的系统，但缺乏解决复杂生产问题的能力。

对技术管理者的启示

对于 CTO 和技术负责人而言，这意味着代码审查（Code Review）的重点必须转移。审查不再仅仅是检查语法或逻辑正确性，而是要重点评估：

1. 系统是否具备足够的可观测性（日志、监控）？
2. 是否考虑了极端负载和故障场景？
3. 团队是否有机制去验证 AI 生成代码在真实环境中的表现？

管理者需要确保团队不仅仅是“交付功能”，还要投入资源去处理那些“不性感但至关重要”的运维和稳定性工作。

对软件工程方法论的重构

传统的“开发-测试-部署”流程可能需要调整为“AI 生成