X记录空间人工智能在30秒内编写了代码。
三行代码，一个简单的函数，我提示它生成，我复制了它，看起来没问题，语法清晰，变量名正确，没有明显的错误。
接下来的五个小时我都在调试它。
问题不在于逻辑。人工智能悄悄地做出了一个假设——列表永远不会为空。99% 的情况下都有效。1% 的情况在生产环境中崩溃了。一个真实的用户。一次真实的故障。我生命中 5 个小时的宝贵时间。
生成仅需 30 秒，调试却要 5 小时。
那不是效率，那是没人谈论的权衡取舍。
这不是一篇反人工智能的文章，我每天都在使用人工智能，它确实改变了我的工作方式。但我已经不再假装写入速度是唯一重要的指标了。
以下是我在多次付出代价后，注意到人工智能生成代码的隐性成本模式后所学到的。
快速代码的神话
我们被灌输了一种说法：人工智能让你的速度更快，提示复制、发送、重复。写作速度确实更快了，快得多。以前需要一个小时才能完成的工作，现在只需几分钟。这部分是真的。
但故事总是止步于此，没有提及之后发生了什么。
AI 在几秒钟内编写代码，你发布代码，然后继续进行下一步。几周后，一个 bug 出现了——一个微妙的、难以重现的、隐藏在你没有编写且不完全拥有的代码中的 bug。
现在你调试的不是你理解的逻辑，而是对一个无法解释自身假设的系统进行逆向工程，就像在阅读陌生人的笔迹，试图弄清楚他们的意思一样。
快速的代码并非免费，而是借来的时间。
债务会在之后显现出来——到那时，你已经完全忘记了人工智能在编写它时所做的假设。
三次人工智能代码让我付出的代价比节省的还多。
1. 无形的假设（5小时）
人工智能假定列表永远不会为空，没有进行检查，也没有添加任何限制。它为什么要这么做？它只知道我问了什么，却不知道真实用户实际做了什么。
在我发布产品两周后，生产环境中出现了这个漏洞。一个没有任何数据的用户访问了流程，导致整个流程崩溃。
解决方法？只需一行代码：一个简单的“如果未列出则检查”。
调试过程？我花了五个小时，一边困惑一边越来越沮丧地查看日志，添加打印语句，甚至开始怀疑自己的理智，最后才找到一个缺失的假设。
| 时间 | |
|---|---|
| ⚡ 写入时已保存 | 5分钟 |
| 🔥调试时的成本 | 5小时 |
比例：60倍。
2. 我的机器陷阱的制作（整整一天）
AI代码通过了我的所有测试，在本地运行完美，我很有信心把它发布出去。
制作阶段？情况就完全不同了。
人工智能针对我的测试环境进行了优化——我用来测试的干净输入、我的测试装置中整齐的数据形状、我编写的正常路径。它没有考虑真实数据，也没有考虑真实用户创建的奇怪边缘情况。
我花了一整天时间去追逐一种只存在于野外的昆虫。
| 时间 | |
|---|---|
| ⚡ 写入时已保存 | 10分钟 |
| 🔥调试时的成本 | 整整一天 |
3. 命名陷阱（3 小时）
人工智能命名了一个变量data。
通用、模糊、技术上可接受，而且对于一个不知道什么重要的AI来说，这样做完全合情合理。
三个月后，我仍然不知道数据中包含什么内容。是原始用户输入？转换后的输出？数据库缓存的结果？还是我筛选过的数据？
我花了 3 个小时追踪原本 10 分钟就能理解的代码，因为人工智能选择了便捷而非清晰，而我没有发现这一点。
| 时间 | |
|---|---|
| ⚡ 写入时已保存 | 0 分钟（我会给它取个更好的名字） |
| 🔥调试时的成本 | 3小时 |
人工智能代码的实际成本是多少？
除了工时之外，还有一些成本是秒表无法显示的。
认知负荷。代码不是你写的，所以你没有相关的心理模型。每次接触代码，你都必须从头开始重建理解。这就像回到一个你从未见过的代码库，而你却被认为是代码的作者。
信心逐渐丧失。在自己的机器上反复测试之后，你会开始不再信任自己的测试。你会带着淡淡的焦虑发布产品。你会添加日志以防万一。你会编写额外的测试，不是因为代码需要，而是因为你不信任自己没有编写的代码。
这种“以防万一”的恶性循环。额外的检查、额外的验证、额外的错误处理，并非因为需求要求，而是因为你在弥补对代码的不确定性，而你无法完全保证其可靠性。这会在不知不觉中消耗大量时间。
机会成本。你花在调试人工智能生成的代码上的每一小时，都是你无法花在真正需要你的判断力、背景知识和经验的工作上的时间。
这些成本是看不见的，没有工单记录它们，没有仪表盘衡量它们，也没有回顾性分析将它们揭示出来。
但它们是真实存在的，而且它们会悄无声息地慢慢累积，直到有一天你意识到调试已经开始感觉像是真正的工作了。
我的做法有所不同
我不会放弃人工智能。那艘船早就驶离港口了，我也不想再回到过去。
但我做了一些小的改动，悄然改变了这个比例：
1. 我不发布自己无法解释的代码。
如果我不能逐行梳理逻辑，而不是仅仅浏览一遍，我就不会发布。即使它在测试环境中运行正常。这样做可以在生产环境出现问题之前发现并解决隐藏的假设。
2. 我把AI的输出当作初稿。AI负责
构建框架。我重写那些关键部分——边界情况、错误处理、变量命名，以及凌晨两点出现问题时需要有人阅读的内容。这样做速度慢一些，但毕竟是我自己编写的代码。
3. 我会明确地添加缺失的假设。
人工智能总是优化到理想情况，所以我养成了一个习惯，那就是立刻问自己：如果输入为空（Null）、格式错误或意外值，会破坏什么？我每次都会手动添加这些检查。
4. 我预留了一笔调试费用。
每个由人工智能生成的函数都会在我的时间预估中额外增加 30 分钟，用于审查和加固。这不是悲观模式识别。这笔费用在它预防的第一个问题上就能收回成本。
这些方法都不能彻底解决问题，但它们确实显著降低了我个人的 10 倍风险比率，现在有些周甚至接近 3 倍。
这是进步。
诚实的权衡
AI 代码编写速度更快，调试速度更慢。这个比例有时是 2 倍，有时是 20 倍，有一次甚至达到了 60 倍，我当时都开始怀疑自己的人生选择了。
问题从来都不是人工智能是好是坏？那是一场毫无意义的争论。
真正的问题是：你和你的团队在代码库上的工作量比例是多少？
对于一次性脚本？使用人工智能，无需回头。
对于六个月后凌晨两点可能需要调试的核心逻辑，务必谨慎。深思熟虑。全身心投入。
这种权衡是真实存在的，它不会消失。假装它不存在并不能让它消失，只是意味着你会在生产过程中而不是生产之前发现它。
一个问题
你听过最糟糕的人工智能编写速度很快但调试速度很慢的故事是什么？
这个漏洞花了多长时间才被发现？你忽略了什么假设？
我先在评论里说——空列表崩溃导致程序运行了 5 个小时，原因仅仅是缺少一个 if 语句。
