早上起来刷到一篇帖子，标题就让我愣了两秒——"AI Did It in 12 Minutes. It Took Me 10 Hours to Fix It"。
说的是有个开发者让AI（GLM-5）写一个PHP媒体管理工具，12分钟，AI哐哐哐生成了大约5000行代码。听起来很爽对吧？但这人最后花了10个小时才把那堆代码"重构"到能看的状态，最终精简到1254行可维护代码。
5000行→1254行，这中间差的那3746行是什么？
是"看起来能跑"的幻觉。
速度幻觉：AI给你的不只是代码，还有焦虑
我看完这个故事第一个反应不是"AI不行"，而是"这人居然真的愿意花10小时去重构"。
说实话，现在网上铺天盖地的AI编程教程，什么"5分钟做一个网站"、"3秒生成后台管理系统"，看多了真的会让人产生一种错觉：编程这件事，已经被AI解决了。
但代码能跑，和代码能上线，中间差了十万八千里。
那些教程从来不教你怎么部署、怎么排查bug、怎么应对并发、怎么写注释让三年后的自己能看懂。AI生成代码也是一样的——它给你的是"看起来完整"的解决方案，不是"可以交付"的产品。
5000行"面条代码"长什么样
根据文章描述，AI生成的代码大概是这样的：HTML/CSS/数据库查询全搅在一起，变量命名混乱，逻辑嵌套七八层，没有任何模块化可言。
我做过类似的事情。
之前用AI生成过一个数据处理脚本，200行代码，5秒钟出来，测试数据跑得飞快。我兴奋地发到群里炫耀，结果同事一跑生产数据，内存直接爆了——AI没告诉我这脚本处理大数据量时会OOM。
后来我老老实实加上了分批处理、内存监控、异常捕获。前后折腾了两天。
那200行AI代码只值5秒钟吗？不对，它值我花的那两天。
代码审查比代码生成更重要
这个故事最触动我的一点，是作者最后的那句话：
"不要部署自己不理解、没审查过的代码。"
听起来是常识对吧？但问题是，AI让"审查"变得特别特别难。
因为你面对的不再是"自己写的代码"——自己写的代码，你知道为什么要这么写，每一个if else你都能追溯到业务逻辑。
但AI写的代码？它是"凭空出现"的。你得先理解它，才能审查它。而理解AI代码这件事，有时候比从零写还累。
因为你得不断问自己：这段逻辑为什么要这样？有没有边界情况没考虑到？这个函数会不会有副作用？
所以我现在养成了一个习惯：AI生成代码之后，先不要急着运行，而是用"代码审查"的心态过一遍——不是为了找AI的茬，而是为了确认我真的理解了这段代码在做什么。
做AI资讯网站的一点思考
既然我是做AI资讯内容的，顺着这个话题聊几句。
很多读者看我们写的东西，最想看到的就是"AI能做什么"。但其实更有价值的问题是"AI不能做什么"——或者更准确地说，"AI在做的时候有什么局限"。
就像这个故事告诉我们的：AI擅长的是"快速产出"，但"质量保证"这事儿，目前还是得人来。
不是说AI生成的代码不能用，而是说，你得有能力判断AI生成的代码质量如何、有没有坑、适不适合你的场景。
这就回到一个很古老的话题：工具越强大，对使用者的要求反而越高。
会开车的都知道，自动挡让开车变简单了，但真要处理复杂路况，还是得靠驾驶经验。AI编程也一样——它降低了"写代码"的门槛，但对"理解代码"的要求，一点没降低。
不是否定AI，而是认清边界
写这篇文章不是来泼冷水的。
AI编程工具确实好用，我自己也天天用。但好用和"可以闭眼用"是两回事。
就像那篇文章的作者说的：AI给了你一个起点，但终点还是得你自己走。
12分钟生成5000行代码听起来很爽，但如果你没有那10小时的审查和重构能力，那5000行代码就只是5000行垃圾——只不过是打包得很精美的垃圾。
所以，下次当你用AI跑出一段"完美代码"的时候，不妨先问自己三个问题：
1. 我真的理解这段代码在做什么吗？
2. 它能应对我所有可能的输入吗？
3. 如果线上出了bug，我能快速定位问题吗？
如果三个问题的答案都是"不确定"，那建议你先把AI当助手，而不是主角。
毕竟，写代码不是目的，解决问题才是。
