最近看到一个说法“一个20年老程序员决定卸载AI”。作为一个同样有接近二十年编码经验的人我想认真聊聊这件事。先说结论我完全理解他而且我自己也做了类似的事情。但“卸载AI”不是否定AI更不是回到石器时代。它更像是在一段时间的重度使用之后重新给工具画了一条边界线。这条边界的核心不是“AI有没有用”而是“我该在什么时候信任它什么时候不信任它”。这篇文章不是来劝大家卸载AI的。恰恰相反如果你刚入行、正在学新语言、写一次性脚本AI编程工具确实能带来很大帮助。但如果你写的是核心业务代码、维护的是老系统、或者要带一个团队长期交付我建议你先看完这篇文章再决定要不要让AI深度进入你的写码流程。1. 先搞清楚“卸载AI”卸的到底是什么1.1 我卸掉的是哪些工具很多人听到“卸载AI”第一反应是“把大模型、聊天助手、所有AI应用全部删掉”。其实不是这样。我卸载的是IDE里的AI代码生成插件、自动补全助手、AI自动写注释、AI自动生成提交信息这类东西。说得更直白一点我关掉的是“让AI替我写代码”的能力。但有些东西我保留下来了搜索引擎、官方文档、源码阅读习惯、Git、代码评审流程、测试用例还有AI网页问答工具。后面这些我依然在用只是使用方式变了。它们不是“替代我思考”而是“辅助我思考”。这一步很关键。因为很多人对AI编程工具的态度是“要么全开要么全关”但真实情况是“工具本身没问题错的是使用姿态”。1.2 为什么一个二十年经验的老程序员会做这个决定二十年的编码经验意味着什么意味着我脑子里有大量已经验证过的模式怎么写事务边界、怎么设计接口、怎么处理异常、怎么组织模块、怎么排查问题。这些模式不是一次性的而是在无数个项目里反复被验证过的东西。在这种情况下让AI替我写一段代码节省的只是“打字时间”但增加的是“验证时间”。以前的工作流是理解需求 - 设计方案 - 自己写代码 - 测试 - 交付。引入AI后的工作流变成了理解需求 - 设计方案 - 让AI生成代码 - 逐行审查 - 修改 - 测试 - 交付。你发现问题了吗中间多了一个“审查AI生成的代码”的步骤。而且这个步骤的成本往往比直接写代码还要高。因为AI生成的代码看起来太正常了你会下意识放松警惕但正是在这种时候最容易放过一个隐蔽的逻辑错误。这不是AI不够聪明而是对我的工作场景来说它的介入增加了“信任成本”。当这个成本高于“手写成本”的时候选择关闭它就是理性的决定。1.3 这不是否定AI而是选工作流我也见过很多年轻同事用AI写代码效率极高。他们对新框架不熟用AI生成示例代码再看文档上手速度非常快。这种情况我完全支持继续用。难点在于每个人所在的位置不一样需要的工具不一样。一个写了二十年代码的人最稀缺的资源不是“能跑的代码”而是“对代码的掌控感和对系统长期演化的判断力”。AI在这两件事上帮不了我反而可能让我分心。所以我说的“卸载AI”本质上是把AI从“代码创作者”降级为“参考资料提供者”。2. 重度使用AI编程一段时间后我看到的几个危险信号2.1 补全越快我对代码的掌控感反而越低一开始用AI补全的时候体验确实很爽。输入一个函数名后面几十行自动生成。看着代码刷刷出现有种“生产力大爆发”的错觉。但用了一两周之后我开始意识到一个问题我对自己代码的熟悉程度下降了。以前写代码每个分支、每个变量、每个边界条件都是自己设计的代码在脑子里是有一张地图的。AI补全之后代码是“看起来对”的但我没有经历过设计它的过程。如果这段代码马上要上生产环境我心里会很不踏实。这种不踏实不是矫情。它真的会影响接下来的调试和排错。因为你没有一个完整的心理模型遇到问题时只能靠猜或者靠反复打印日志去看实际行为。我后来和一个做过多年技术管理的朋友聊他说了一句让我印象很深的话“代码不是写出来的是理解出来的。你不理解的代码跑得再快也没有用。”2.2 最大的问题不是“错”而是“看起来对”AI生成代码最危险的地方不是它会给出明显的错误而是它经常给出“看起来非常合理但实际并不存在”的API、参数或处理方式。举个例子。有一次我要调用某个内部SDK的一个接口输入接口名之后AI自动生成了完整的调用代码。代码结构很规范异常处理、日志打印都有。但编译之后直接报错说方法不存在。我去查了官方文档才发现AI把老版本SDK的接口和当前版本的方法混在一起了。这种错误不像是手写代码时那种“单词拼错”一眼能看出来的低级错误更像是“整个思路都是对的但对象根本不存在”。这种错误排查起来非常耗时间。因为你不会第一时间怀疑代码框架你会先去查环境、查配置、查依赖。最后才发现是生成内容的底层材料出了问题。对资深程序员来说时间最宝贵。如果写一段代码要花十分钟查一个“看起来对但实际错”的坑要花半小时那我为什么要让AI来写这一段2.3 上下文处理能力撑不起系统级任务另一个让我重新思考的问题是AI的上下文窗口再大也装不下一个复杂系统的所有约束。老系统里有很多“隐性逻辑”某个接口为什么不能加缓存某个字段为什么不能直接删某个模块为什么只能串行处理。这些约束不在文档里不在代码注释里而在参与过的老同事脑子里。AI看不到这些。它只知道“根据当前文件生成最合理的代码”但这个“最合理”往往忽略了业务背景、历史包袱、团队约定和性能约束。所以AI更适合处理“单点任务”生成一个工具函数、解释一个报错、写一段测试数据。它不适合处理“全局任务”设计一个模块、重构一个老系统、调整事务边界。3. 真正让我决定退出的三个可复现场景3.1 场景一重构老模块时AI生成代码无法融入现有代码库有一次我要重构一个维护了好几年的老模块。模块本身逻辑不复杂但代码风格、异常处理方式、日志格式和团队后来定的规范完全不一样。我尝试用AI生成新版本。生成出来的代码很干净设计也更现代但问题在于它和这个模块周边十几个文件的风格完全割裂。旧的代码用错误码AI生成代码用异常旧的日志是某种格式AI生成的是另一种格式。代码不是孤岛。一段代码要有长期价值必须能融入整个代码库的“生态”。AI生成的代码是“标准答案”但标准答案不等于“贴近现场”。最后我选择自己重写只把AI生成的内容当作思路参考。从那之后我开始意识到在老系统里AI生成代码的融入成本很高。这不是AI的能力问题而是“代码风格一致性”本身就是一种非常昂贵的东西。3.2 场景二排查线上问题时AI给了“听起来合理”的猜测还有一次印象很深的经历。一个线上问题反馈过来现象是偶发超时。我在排查日志、监控和调用链AI助手在旁边给出了一句“可能是缓存穿透或者连接池耗尽”。这个判断本身听起来非常合理如果放到互联网上搜索大概率能看到大量类似解释。但问题在于它没有看到当天的完整日志没有看到流量曲线没有看到相关依赖服务的状态。后来真正的原因是一个配置项被同事临时改错了导致某个资源没有得到释放。这种情况靠AI的大概率猜测根本没用它只能给你一个“可能性清单”但排查问题需要的是“确定性证据链”。从那天开始我再也不在排查线上问题时让AI做判断了。它可以帮我整理日志格式、解释某个报错术语但绝对不能替代“日志 - 监控 - 时间线 - 代码走查”这个基本链路。3.3 场景三团队成员指着代码说——“我不知道AI写的”真正让我下定决心卸载的是一个团队场景。有次代码评审我指着一处逻辑问成员“这里为什么这样处理这个边界条件考虑到了吗”对方看了一眼很自然地回答“这块是AI写的我没细看。”我当时心里一沉。代码一旦提交它就不再属于“AI”了而是属于团队。后人维护这段代码时不会去问“这是谁写的”他们只会问“这段代码在干什么为什么这么写”。如果连提交代码的人都解释不清楚那这段代码就是一个定时炸弹。从工程的角度看代码是负债不是资产。它需要被理解、被维护、被演进。AI生成代码的速度很快但“被团队理解”的速度并没有变快。当生成速度超过了理解速度代码库就会变成一个越来越失控的泥潭。4. 卸载AI之后我的工作流反而更顺了4.1 我保留了哪些工具关掉了哪些工具我给自己列了一个清单明确什么能用什么不用。保留的搜索引擎和官方文档GitHub等平台上的源码阅读测试框架和自动化脚本本地代码片段库面向AI的网页问答主要用于概念解释关掉的IDE内的AI自动补全AI自动生成业务代码AI自动生成提交信息AI自动修改已有代码“一键生成整个文件”类功能这个清单不是为了“证明自己意志坚定”而是为了让工作流保持一个原则AI可以给我参考资料但绝对不能替我按下“提交代码”的按钮。4.2 新的写码流程长什么样现在的流程说实话比之前“无脑AI生成”要踏实很多。第一步先写测试用例或接口定义。先想清楚输入是什么、输出是什么、异常情况怎么处理。这一步不是浪费时间它是在帮我把真正重要的逻辑想明白。第二步自己写骨架代码。一个函数、一个模块的核心逻辑我会先自己写出来。不用写得完美但主体结构必须在脑子里成型。第三步遇到具体API不会用再去查文档或问AI。这时候AI给我的不是“整段代码”而是“某个API的参数解释”或“某个报错的含义”。它扮演的是“代码词典”不是“代码作家”。第四步代码评审。自己先看一遍再看有没有需要重构的地方。如果需要改就自己动手改而不是让AI再生成一版。很多人担心这样效率会变低。实际上对大多数我熟悉的领域来说直接写比“生成审查修改”更快。因为我不需要额外验证那些“看似合理”的代码。4.3 效率真正来自哪里卸载AI之后我的效率并没有下降。原因是我的主要精力不再花在“检查AI有没有骗我”上了。以前用AI生成代码表面上很快但心理上一直绷着一根弦。提交前要反复确认调试时发现问题还要倒回去看是不是生成的代码有问题。换句话说我承担了“作者”的责任却没有享受“作者”的掌控感。现在的效率来自几个方面常用代码片段已经存在本地一键插入不需要AI生成。需要用到的API、框架我平时会主动看文档和源码知识在大脑里完成了索引。写代码时注意力更集中精神负担反而减轻了。调试时间明显减少因为大部分代码是自己写的出问题时很快能定位。所以说效率不是“有没有AI”决定的而是“你对代码的理解深度”决定的。5. 什么情况下我会重新装回AI5.1 新语言、新框架、一次性脚本仍然适合AI虽然卸载了IDE里的AI辅助但我在某些场景下还是会打开AI甚至不排斥重新安装插件。最典型的是接触一门新语言或新框架。这时候没有任何经验负担AI生成示例代码能帮我快速理解基本写法和常见模式。比如我想用Python写一个处理Excel的临时脚本或者想快速了解某个前端框架的组件用法这时候AI生成一个示例我再改成自己的版本效率确实比自己查文档更快。这类场景的共同点是一次性、低风险、不需要长期维护。它不会给系统带来长期负担所以可以大胆用。5.2 读陌生代码和理解报错仍然适合AI另一个AI很有用的场景是“解释复杂报错”。有些报错信息很晦涩尤其是那些堆栈信息特别长的。AI能快速把“用户代码的第几行”和“底层框架的哪个异常”联系起来省去很多查文档的时间。但你仍然不能盲信。AI给的思路只能作为“第一候选”最终要靠官方文档或源码验证。它帮我定位方向但它不能帮我做最终决定。5.3 给不同阶段程序员的建议如果让我给建议我不会说“大家都要卸载AI”也不会说“赶紧装上AI”。我会分人群说。刚入门的新手可以大胆用AI辅助学习但有一个底线——AI生成的每一行代码你都要能解释清楚。如果你解释不了就把它当作学习素材不要提交到项目里。工作两三年的中级程序员可以用AI生成样板代码、接口定义、测试数据。但核心业务逻辑必须自己写因为你正处于建立代码审美的关键阶段。如果处处依赖AI生成你会错过大量“自己踩坑、自己修正”的成长机会。资深程序员和技术负责人更应该在“上下文、架构、长期维护”层面做判断。AI可以节省很多重复劳动但团队代码库的“可解释性”始终应该排在第一优先级。6. 如果想用AI又不至于失控我给自己定了几条规矩6.1 核心业务代码禁止AI直接生成什么叫核心业务代码在我看来至少包括这几类涉及资金、交易、订单状态流转的逻辑权限校验和身份认证多线程并发下的数据一致性处理核心算法和复杂的业务规则数据库事务边界这些代码一旦出错损失的不只是时间还可能是真金白银或者是用户信任。AI可以帮我写注释、写测试数据、做代码格式整理但不能碰真正的状态判断和事务逻辑。6.2 AI生成代码必须通过“可解释测试”我给自己定了一个标准拿到一段AI生成代码我会先试着向一位同事解释它。如果我能讲清楚“它为什么这么做、边界条件是什么、失败时会怎样”那这段代码可以进入项目。如果讲不清楚不管代码多漂亮我都不会提交。因为“讲不清楚”意味着我还没有理解它。一个我不理解的代码不应该进入生产环境。这比任何代码规范都有用。因为它逼着我去把AI生成的内容“内化”成自己的知识。6.3 把AI当作“代码搜索源”而不是“代码粘贴源”现在我对AI的使用方式是查资料时把AI当作一个更友好的搜索引擎。看到AI给出的代码后我会手动把它敲进编辑器或者复制下来后按自己的风格重构一遍。这个“手动重写”的过程非常关键。表面上看起来多了一步实际上它帮我从“被动接受”变成了“主动理解”。用不了几次我就能把AI给的写法变成自己真正的能力。很多人觉得这样太慢了。但写代码这件事慢一点没有关系错了才麻烦。6.4 定期训练不依赖AI的基本功最后一条规矩我会定期安排完全不使用AI编码工具的时间。可能是周末写个小项目也可能是工作日的某个半天。目的不是证明自己厉害而是保持“不依赖AI也能写代码”的能力。这就像开车。自动驾驶再方便你也不能五年不摸方向盘。因为一旦系统失灵、遇到突发情况你的基础操作能力会直接决定你能不能在最短时间内接管控制权。编程也一样。AI是我们手里的辅助工具但真正的核心能力——理解需求、设计逻辑、排查问题、承担责任——永远只能长在你自己身上。最后说几句卸载AI之后我一直在想一个问题为什么二十年的经验会让我做出这个决定后来想明白了。因为二十年里我见过太多工具来来去去也见过太多“用工具代替思考”最后付出代价的例子。工具永远是工具关键是谁在掌握方向盘。我卸掉的不是AI而是“无脑依赖AI”的状态。真正想卸掉的是没有上下文、不背锅、不理解业务逻辑的盲从感。如果你现在也觉得自己对代码的掌控感在下降不妨也试试从关闭一个自动补全插件开始跑一段时间再决定要不要继续。你会发现代码世界还是那个代码世界但你的状态已经不一样了。