夜雨聆风求关注，随手点个赞、在看、转发三连吧
周四下午，我盯着屏幕发了十分钟的呆。
不是因为代码难，是因为一个很简单的逻辑错误，AI帮我写出来的代码，我居然看了三遍都没看出来哪里不对。
直到测试的同学跑过来跟我说：「哥，这个接口返回的数据，顺序是反的。」
我低头一看，果然。一个sort方向写反了，升序写成了降序。
这种错误以前我自己写的时候，基本不会犯。不是因为我多厉害，是因为自己写代码的时候，每一行都是脑子里过了一遍才敲出来的，写到sort的时候会下意识想一下"到底排升序还是降序"。
但AI写的时候，它直接给了一个看起来很合理的代码，我看了一眼，觉得"嗯，对"，就接受了。
问题就出在这个"嗯，对"上。
以前写代码慢，但脑子是在线的
说一个我自己真实的感受。
以前手写代码的时候，拿到需求会先想：这个功能涉及哪些模块，数据怎么流转，有哪些边界情况。想清楚了再动手，有时候想半小时，写代码只要十分钟。
现在用AI，拿到需求直接扔一句话过去，三秒钟代码就出来了。我扫一眼觉得没问题，接着扔下一个需求。
效率确实高了，但我的脑子在这整个过程中，基本处于半休眠状态。
以前是"先想后写"，现在是"先扔后看"。
区别在哪？以前我在写之前就把架构想清楚了，现在我是写完之后才发现架构有问题——因为AI不会帮你规划架构，它只会按你说的写。你没说的，它不会替你想。
软件质量出了什么问题
我跟几个同样重度用AI写代码的朋友聊了一圈，发现大家踩的坑惊人地相似：
坑一：代码能跑，但没人看得懂
AI生成的代码，变量名很规范，注释也有，结构也清晰——但你问一句"为什么要这样写"，答不上来。
因为当初写这段代码的时候，做决策的是AI，不是你。你只是验收了它的产出，但你不知道它的思考过程。
三个月后需求变了要改，你打开代码一看，得花两天重新理解。
坑二：边界条件全靠运气
AI最擅长的是"正常路径"——输入正确、格式合规、网络通畅的情况下，代码完美运行。
但现实世界里，用户会输入空值，网络会断，数据库会死锁。这些边缘情况，你不提，AI不会主动处理。
以前自己写代码，写到一半会突然想到"万一用户不填这个字段呢"——这种直觉来自经验。现在AI帮你写了，你连"写到一半"这个过程都没有了，直觉无处发挥。
坑三：测试形同虚设
很多人用AI写完代码，让AI顺便把测试也写了。
AI写测试有个致命问题：它会按照它自己写的代码来写测试，而不是按照需求来写测试。
等于自己出题自己做，永远满分。
真正的测试应该从需求出发，覆盖各种异常场景。这个判断力，AI目前还不具备。
思维方式没跟上，才是根源
工具变了，但工作方式还是老一套——这才是问题的本质。
以前一个月写2000行代码，现在一个月写8000行。但你审代码的时间，可能还是那几个小时。
代码量翻了四倍，审阅时间没变，bug率自然上去。
更深层的问题是：很多人把AI当成了一个"更快的自己"，而不是一个"需要管理的下属"。
你交给下属一个任务，你不会直接让他写完就上线。你会review他的方案，问他为什么这样设计，检查他的边界处理。
但交给AI，很多人就是"写完跑通就交差"。
管理一个人需要判断力，管理一个AI同样需要。但大多数人没意识到AI也需要管理。
我现在的工作流
说说我自己的做法，不一定是最好的，但至少比之前好：
第一，先花五分钟画草图再扔给AI。
拿到需求，先在纸上或者脑子里过一遍：这个功能涉及几个模块，数据怎么流转，有哪些异常情况。花五分钟想清楚，再把需求描述给AI。
这五分钟能省后面两小时的debug。
第二，AI写的代码，不扫一眼就接受。
尤其是这几个地方要逐行看：边界条件、空值处理、异常捕获、排序方向、循环终止条件。这五个地方是AI最容易犯错的，因为它们需要业务上下文才能判断对错，而AI没有你的业务上下文。
第三，测试自己设计，让AI实现。
哪些场景要测，这个判断你自己做。你可以让AI帮你写测试代码，但测试用例的设计必须来自你对业务的理解。
第四，每周花一小时回顾这周AI写的代码。
不回顾的话，三个月后你的项目会变成一座没人能拆的炸弹。回顾的目的不是找bug，是重新建立你对代码的全局认知。
结语
AI写代码，是这两年最大的生产力变革，没毛病。
但车换了跑车，驾照还是C2，弯道上还是会翻。
工具升级了，人没升级，就会出问题。速度从来不是目的，又快又稳才是。
你上一次认真审AI写的代码，是什么时候？
Claude code 与cursor,codex生产代码速度太快了，现在感觉更累了。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。
用 AI 赋能，让智慧生长
Empower with AI, let intelligence grow.
