文章目录前言那种不安是慢慢长出来的一个很真实的坑本质问题你在使用一个不可解释的合作者为什么看起来没问题的代码最危险我现在的解决办法1. 分层信任不是所有代码都一样对待低风险可以高度依赖 AI中风险需要 review高风险必须自己主导2. 强制自己做二次建模3. 引入最小验证测试4. 让 AI 参与审查而不是只写代码5. 控制上下文复杂度6. 给关键代码加可观测性7. 建立自己的可信代码库8. 乖乖地加各种测试用例一个很真实的变化AI 不是问题失控才是最后P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01前言一个被 AI 坑过的人掏心窝子聊聊说实话最近这一年我的开发方式被 AI 彻底重塑了。写页面、封装 hooks、补接口、甚至搞 Node 服务——很多时候我不是在写代码而是在描述需求。回车一按代码哗啦啦就出来了。这感觉就像你从手工木匠变成了操控自动化工厂的人。只不过这个工厂有时候会偷偷往你产品里塞螺丝钉。效率提升肉眼可见原来半天的功能现在半小时跑起来重复性工作几乎可以忽略连不熟的技术栈也能快速拼出个能用的版本但奇怪的是——我开始越来越不敢直接把这些代码上线了。那种不安是慢慢长出来的一开始我没多想。AI 写的代码大多数时候看起来都挺对的结构清晰、命名合理、甚至还会加注释。有些代码比我写的还规范。但问题就在于——它太顺滑了。顺滑到你很容易失去警惕。就像你点外卖包装越精美你越不会怀疑里面是不是过期了。一个很真实的坑有一次我在做一个简单的前端缓存优化。需求就三条相同请求短时间内复用结果、支持过期时间、出错时不缓存。AI 很快给了一版实现Map 做缓存、有 TTL 控制、逻辑清楚。我就直接用了。上线之后一切正常直到某一天接口压力突然变大。排查发现某些失败请求被错误地缓存了。后续请求直接命中错误结果。问题的根源它在处理 Promise 的时候没有区分 resolve / reject 的缓存策略。失败的 Promise 也被缓存进去了。平时完全正常一旦触发就是连锁反应。就像你家的烟雾报警器平时不响一响就是房子真着火了。那一刻我意识到AI 写的代码不是错很多而是偶尔错但错得很深。就像你相亲对象平时看着人模人样一遇到大事才发现是个巨婴。本质问题你在使用一个不可解释的合作者后来我慢慢想明白了一件事AI 编程的本质不是工具升级而是——你多了一个写代码的搭档但你不了解它。这个搭档有几个特点写得很快知识面很广但不会对自己的设计负责也不会主动告诉你风险点这和团队里的新人还不一样。新人你可以带可以问可以 review 他的思路。但 AI 直接给你结果而不是过程。就像你请了个厨师菜端上来了但你不知道他有没有洗手。这就导致一个很大的问题你很容易在没有完全理解的情况下引入复杂逻辑。为什么看起来没问题的代码最危险因为它会骗过你的直觉。在日常开发中我们的大脑有一套快速判断机制代码结构 OK → 通过命名合理 → 通过跑起来没报错 → 通过但 AI 写的代码很擅长满足这些表层条件。就像一个人穿着西装打着领带你下意识觉得他是精英结果他可能连 Excel 都不会用。问题往往藏在边界条件异常处理并发场景状态一致性这些地方你不仔细想是看不出来的。我现在的解决办法踩过几次坑之后我开始系统性调整自己用 AI 的方式。不是不用而是加护栏。下面这些方法是我用血和泪主要是泪因为加班到半夜换来的。1. 分层信任不是所有代码都一样对待低风险可以高度依赖 AIUI 组件、样板代码、简单工具函数。这类代码问题成本低可以大胆用。中风险需要 review业务逻辑、数据处理、状态管理。AI 可以写但必须过一遍。高风险必须自己主导并发逻辑、缓存策略、权限安全、核心架构。这类我基本不会直接用 AI 结果最多参考。就像你不可能让 AI 帮你写遗嘱对吧虽然它可能写得比律师还工整。2. 强制自己做二次建模现在我有一个习惯AI 写完之后我会在脑子里重新建一遍模型。比如数据是怎么流动的状态在哪儿变化哪些地方可能出错如果我讲不清楚这段代码在干嘛我就不会上线。就像你不可能把一道菜端上桌却说不出里面放了什么调料。3. 引入最小验证测试不用一上来就搞完整测试体系但至少要做正常路径测试异常路径测试边界测试比如刚才那个缓存问题// 失败请求是否被缓存awaitrequestFail()awaitrequestAgain()// 是否还失败这种小测试能救很多命。就像你出门前检查钥匙虽然麻烦但总比被锁在门外强。4. 让 AI 参与审查而不是只写代码我现在经常这样用 AI这段代码有什么潜在问题 有没有边界情况没考虑 如果是高并发场景会怎样有时候它真的能指出一些问题。相当于多了一层自动 code review。虽然这个 reviewer 有时候也会瞎说但总比没有强。就像你问路人这条路对吗他可能指错但至少你多了一次验证的机会。5. 控制上下文复杂度一个很重要的经验是不要一次性让 AI 生成太复杂的东西。越复杂的上下文越容易出错越难 review。我现在更倾向于拆小任务、分步骤生成、每一步都验证。就像你不可能让一个人一次性做好满汉全席但让他先炒个番茄炒蛋再做个红烧肉就靠谱多了。6. 给关键代码加可观测性以前写前端很多时候不太重视日志。现在不行了。对于关键逻辑我会加日志log、监控monitor、错误上报。AI 写的代码你无法完全预判只能提高可观测性。就像你养了一只猫你不知道它什么时候会打翻水杯所以你只能在杯子下面垫个托盘。7. 建立自己的可信代码库一些常用能力比如请求封装、缓存策略、状态管理模式我会沉淀成自己的一套实现。之后AI 只能用不能改核心。这样可以避免反复踩坑。就像你家厨房刀和锅是你自己的AI 只能帮你切菜不能换你的刀。8. 乖乖地加各种测试用例以前我对写测试这件事说实话是有点抗拒的。尤其是前端页面能跑就行手点一遍没问题就 OK写测试有时间再说吧。但自从开始大量用 AI 写代码之后我的态度彻底变了。现在不是要不要写测试而是不写测试我根本不敢提交代码。就像你不可能不系安全带就飙车虽然车是 AI 开的。一个很真实的变化以前我觉得“代码写出来能跑就行。”现在变成“代码我必须解释得清楚才敢上线。”这个变化其实挺大的。就像以前你吃路边摊吃完没事就行现在你开始看配料表了。AI 不是问题失控才是说到底AI 编程本身没有问题。问题在于你是不是在无意识地依赖。当你开始不看代码、不理解逻辑、直接复制粘贴——那风险就已经埋下了。就像你闭着眼睛坐过山车虽然刺激但你不确定下一秒是安全着陆还是脸着地。最后我现在依然大量使用 AI甚至比以前更多。但我给自己设了一条底线我可以不写代码但我不能不理解代码。这条线一旦守住了AI 是加速器。守不住它就是放大器——把问题放大。如果你也在用 AI 写代码可能会有类似的感受速度变快了但确定性变低了。而我们要做的不是拒绝它而是——重新建立对代码的掌控感。最后问一个问题AI 到底是在帮我们加速还是只是把复杂度换了个地方我的答案是它把复杂度从写代码换到了审代码。就像你请了个代驾你是不用开车了但你得盯着导航还得随时准备踩刹车。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01