夜雨聆风
原文地址：https://dev.to/harsh2644/i-spent-10x-longer-debugging-ai-code-than-writing-it-15h4
AI 写代码真的快。
一段函数，30 秒生成；一个页面，几轮对话搭出来；一个脚本，看起来比自己手写还整齐。
问题是，速度经常只发生在“写出来”的那一刻。后面要不要调试、能不能上线、半年后谁看得懂，就很少有人算了。
DEV 上这篇文章这两天讨论很高，筛选时已有 22 个正反馈、42 条评论。它讲的不是“AI 不好用”，而是一个更扎心的事实：
AI 省下的 30 秒，可能会在生产环境里变成 5 小时调试债。
最狠的一笔账：写代码省了 5 分钟，调 Bug 花了 5 小时
原文里有个很典型的例子。
AI 生成了一段看起来没问题的逻辑：变量名正常，语法干净，测试也能跑。真正的坑藏在一个很小的假设里。
它默认列表永远不会为空。
结果两周后，真实用户刚好没有数据，流程直接崩了。修复只要一行 if，但定位花了 5 小时。
这类事故最恶心的地方在于：代码不是明显错，而是“在你测试过的世界里完全正确”。
所以别再只问“AI 写得快不快”。
更该问的是：这段代码出了问题时，你能不能在 10 分钟内解释它为什么这样写？
AI 代码最爱埋的 3 个坑，生产环境一个都不会放过
从原文经验看，AI 生成代码最常见的坑不是语法，而是默认前提。
dataresult、item 满天飞 |
这些坑都很小。
小到 Review 时容易被跳过，小到测试不一定覆盖，小到 AI 自己也不会主动提醒你“我刚才假设了用户一定有数据”。
但线上事故从来不嫌坑小。
真正贵的不是 Bug，而是你失去了代码所有权
手写代码出问题时，你通常知道自己当时为什么这么写。
AI 代码不一样。你没有从第一个判断条件推到最后一个返回值，它是“直接出现”的。哪怕你看过一遍，也不等于你真的拥有它。
这会带来三个后果：
最麻烦的是，这些成本很少被统计。
Jira 里不会写“AI 生成代码导致理解成本增加 3 小时”，日报里也不会写“今天主要在还昨天省下来的时间”。
但团队会感受到：代码合得越来越快，调试却越来越累。
AI 输出验收清单：没过这 7 项，不准合并
我现在更愿意把 AI 输出当成初稿，而不是成品。
初稿可以很快，但合并前必须过清单。
data/result/info 滥用 | ||
这张表看起来麻烦，但比线上熬夜便宜。
尤其是“可解释性”这一条，不要放水。能跑不等于你理解了，测试通过也不等于风险消失。
Prompt 别只写“帮我实现”：要逼 AI 暴露假设
很多人用 AI 写代码时，提示词太像派活：
这当然能生成代码，但它也给了 AI 很大空间去脑补。
更稳一点的写法，是让它先把假设说出来：
这不是为了让 Prompt 变长，而是为了把风险提前摊开。
AI 最怕的不是不知道答案，而是它不知道自己不知道什么。让它先列假设，至少能把一部分隐形坑拉到台面上。
给每段 AI 代码加“调试税”：估时别再按生成速度算
原文里有个建议很实际：每个 AI 生成函数，预留额外 30 分钟做 Review 和加固。
我很认同。
这不是悲观，是把真实成本放回计划里。
AI 让你写得快，不代表你可以估得更乐观。
如果一个功能本来估 2 天，现在因为 AI 生成很快就改成半天，大概率是在偷 Review、测试和理解成本。这个成本不会消失，只会换个时间点回来。
哪些代码可以大胆让 AI 写，哪些必须人手重写
我不是反对 AI 写代码。
恰恰相反，很多场景不用 AI 才浪费。
但下面这些，AI 可以辅助，不能接管。
真正成熟的用法不是“让 AI 多写点”，而是“让 AI 写那些你愿意接手维护的部分”。
最后一句：AI 代码不是免费的，它只是晚点收费
AI 写代码最大的诱惑，是让人误以为开发成本主要在敲键盘。
可真正做过项目的人都知道，敲键盘只是很小一部分。更贵的是理解需求、处理边界、定位问题、承担后果，以及半年后还能读懂自己当时为什么这么写。
所以以后再看到 AI 30 秒写完一段代码，先别急着高兴。
问自己四个问题：
能过这四问，AI 才是真的帮你省时间。
过不了，它只是把 30 秒的爽感，换成了 5 小时的调试债。
