★ FEATURED ARTICLE 1. 当“写得快”变成一种隐性代价最近半年我身边不少做开发的朋友都陷入了一种很微妙的状态代码提交频率比以前高了PR 合并速度快了需求交付周期短了但私下聊天的时候大家反而越来越没底。有个做了八年后端的老哥跟我说了一句让我印象特别深的话——“我现在写代码像在点外卖出餐快但我已经不太会做饭了。”这句话基本就是当下很多技术人面对 AI 编程工具时的真实写照。Claude Code、Cursor、各类 Agent 框架、提示词工程这些词在过去一年里几乎成了开发者日常对话的高频词汇。你打开任何一个技术社区满屏都是“怎么配置 Claude Code”“怎么写提示词让 Agent 一次跑通”“多 AI 协作怎么搭”。效率工具确实在爆发但与此同时一个很少被认真讨论的问题正在浮出水面当 AI 帮你把代码写出来的时候你自己的技术肌肉是不是正在悄悄萎缩我写这篇东西不是要劝谁别用 AI那没意义工具就在那里不用才是跟自己过不去。我想聊的是另一件事在这个“代码写得越来越快”的时代怎么让自己不至于变成一个只会敲回车、只会复制粘贴提示词的“调度员”。这篇内容适合所有正在用或者准备用 AI 编程工具的开发者不管你是刚入行的新手还是干了十几年的老手都能从中找到一些对自己有用的东西。核心关键词就几个AI 编程、Agent、Claude Code、提示词、结对编程以及最关键的——技能衰退这件事本身。2. 技能衰退到底是怎么发生的2.1 从“自己写”到“看着它写”的转变我先说一个我自己观察到的现象。以前遇到一个不熟悉的算法或者设计模式我的第一反应是去查文档、看源码、自己动手写一遍哪怕写得丑写完之后那个东西就真的长在我脑子里了。现在呢很多人的第一反应变成了打开 AI 对话框把需求描述一遍等它吐出一段代码看一眼觉得“嗯差不多”然后直接粘进项目里。这个转变本身没什么问题效率确实高。但问题在于学习发生的那个“摩擦环节”被跳过了。认知科学里有个很基础的概念叫“必要难度”意思是说当学习过程存在适度的阻力和困难时记忆和理解反而更牢固。你亲手调试一个空指针异常花了两小时这辈子都不会再犯同样的错但 AI 帮你把异常处理写好了你连那个异常长什么样都没见过下次换个场景照样抓瞎。我管这个叫“技能外包的隐性成本”。你外包出去的不只是敲键盘这个动作还包括了理解问题、拆解问题、试错、调试、形成直觉这一整套认知过程。短期看省了时间长期看省掉的是能力增长本身。2.2 Agent 和 Claude Code 让这件事加速了如果说早期的代码补全工具还只是帮你省点打字功夫那 Agent 类工具和 Claude Code 这种能自主执行多步任务的系统就把技能衰退这件事推到了一个全新的量级。传统的结对编程是两个人一起思考你一句我一句互相挑战对方的假设。但现在很多人和 AI 的“结对”实际上变成了“我描述需求它全权执行我验收结果”。这个模式里人从“共同思考者”退化成了“需求翻译器”和“结果验收员”。我见过一个挺典型的场景一个团队用 Agent 框架搭了一套自动化代码生成流程需求进去代码出来测试跑通就合并。跑了三个月之后团队里新来的两个应届生连最基本的数据库索引优化都说不清楚因为他们从来没遇到过慢查询——Agent 在生成代码的时候顺手就把索引加上了他们根本不知道为什么要加、加在哪个字段上、加了会有什么代价。这就是技能衰退最隐蔽的地方它不是你不会了而是你从来就没会过但你误以为自己会了。因为代码能跑测试能过线上没炸你就默认自己掌握了。直到有一天 Agent 挂了或者遇到一个它搞不定的边界情况你才发现自己手里什么都没有。2.3 提示词工程本身也在制造一种错觉现在网上关于提示词的内容铺天盖地什么“鹈鹕骑自行车提示词”“鹈鹕测试提示词”这种看起来莫名其妙的东西都能上热搜说明大家对“怎么跟 AI 说话”这件事的焦虑已经到了一个很高的程度。但我想泼一盆冷水提示词写得好不等于技术能力强。提示词本质上是一种沟通技巧它解决的是“怎么让 AI 理解你的意图”这个问题但它不解决“你的意图本身对不对”这个问题。一个对分布式事务一知半解的人就算提示词写得再漂亮AI 给他生成的方案该有坑还是有坑因为他根本看不出坑在哪里。我见过太多人把大量时间花在收集各种“神级提示词模板”上却很少花时间回头去补一补操作系统、网络协议、数据结构这些基本功。这就像一个人花大价钱买了最好的厨具但连食材新不新鲜都判断不了做出来的东西能好吃吗3. 哪些能力正在被悄悄侵蚀3.1 调试与排错能力首当其冲如果要我选一个被 AI 侵蚀得最严重的能力我会选调试。原因很简单调试是一个高度依赖直觉和经验的活儿而直觉和经验只能从大量亲手排错中积累。以前一个 bug 出来你得看日志、加断点、二分定位、猜测假设、验证假设这个过程又慢又痛苦但每一次成功排错都在你脑子里建立了一条新的神经通路。现在呢很多人遇到报错的第一反应是把错误信息复制给 AI等它给出修复方案。我不是说这样做不对紧急情况下这确实是最优解。但如果这变成了你唯一的排错方式那你的调试能力就会像长期不用的肌肉一样萎缩。更麻烦的是AI 给的修复方案有时候是“治标不治本”的——它可能只是把报错压下去了但根本原因还在。你没有亲手追过那个根因就永远不知道它下次会以什么形式再冒出来。我自己的做法是AI 给的修复方案我一定要自己复现一遍问题然后手动验证这个方案为什么有效。如果时间允许我还会故意把修复回滚看看问题是不是真的如我理解的那样复现。这个过程很笨但它是保持调试肌肉不萎缩的唯一办法。3.2 系统设计能力在“拼装式开发”中退化Agent 和 Claude Code 这类工具特别擅长做一件事把一个大需求拆成若干小任务然后逐个生成代码。这个能力很强但它也带来一个副作用——开发者越来越不需要自己做系统设计了。以前你要做一个新功能得先想清楚模块怎么划分、接口怎么定义、数据怎么流转、边界情况怎么处理。现在你把这些都交给 Agent它帮你拆好了你只需要验收。久而久之你就失去了从零到一设计一个系统的能力。这个能力有多重要这么说吧系统设计能力是区分“码农”和“工程师”的核心分水岭。会写代码的人很多但能从全局视角设计出一个可扩展、可维护、能扛住真实流量冲击的系统的人永远是稀缺的。如果你把这个能力外包给 AI那你基本上就把自己最核心的竞争力交出去了。3.3 对底层原理的感知在变模糊还有一个更隐蔽的侵蚀对底层原理的感知。举个例子你用 Claude Code 生成了一段数据库查询代码跑得挺快你就用了。但你有没有想过这段代码在高并发下会怎么样它会不会导致全表扫描会不会产生锁竞争连接池够不够用这些问题AI 在生成代码的时候可能会考虑也可能不会取决于你的提示词写得够不够细。但如果你自己不懂这些你连该问什么问题都不知道。我认识一个做后端的哥们用了半年 AI 编程工具之后有一次线上出了个性能问题他盯着监控看了半天完全不知道从哪里下手。最后是团队里一个不用 AI 的老工程师看了一眼慢查询日志就定位到了问题——一个缺失的联合索引。这个哥们后来跟我说那一刻他觉得自己像个外人明明代码是他“写”的但他对自己的系统一无所知。4. 怎么在效率和质量之间找平衡4.1 建立“AI 辅助但不替代”的工作流说了这么多问题总得给点解法。我的核心思路就一句话让 AI 做它擅长的把学习环节留给自己。具体怎么操作我自己的工作流大概是这样分的任务类型AI 参与程度我的参与程度目的重复性代码CRUD、样板代码高直接生成低快速审查省时间新领域探索没接触过的技术栈中生成参考代码高逐行理解并改写学东西核心业务逻辑低只用来做代码审查高自己设计自己写保质量调试排错中用来提供思路高自己动手验证练能力系统设计低用来做方案对比高自己主导设计保核心竞争力这个表格不是死的你可以根据自己的情况调整。但核心原则是凡是能让你学到东西的环节尽量自己动手凡是纯粹消耗时间的重复劳动大胆交给 AI。4.2 刻意练习给自己留“不用 AI 的时间”我给自己定了一个规矩每周至少有一天写代码完全不用 AI 工具。不补全、不生成、不问答就靠自己查文档、翻源码、手动调试。刚开始特别难受感觉自己像个刚学编程的新手什么都慢。但坚持了几个月之后我发现自己的基本功反而比以前更扎实了。因为当你没有 AI 可以依赖的时候你会被迫去理解每一个你写下的东西这种理解是 AI 辅助模式下很难获得的。这个做法还有一个额外的好处它能帮你识别出自己真正的薄弱环节。平时用 AI 的时候你感觉不到自己哪里不会因为 AI 都帮你兜住了。但一旦断掉 AI哪些地方卡壳、哪些地方要查半天一目了然。这些卡壳的地方就是你接下来要重点补的地方。4.3 把 AI 当成“陪练”而不是“代打”还有一个心态上的转变很重要把 AI 当成陪练而不是代打。陪练是什么是陪你练、给你喂招、帮你发现问题的。代打是什么是替你上场、替你拿成绩的。很多人用 AI 的方式是代打模式——需求丢过去代码拿回来完事。但更好的方式应该是陪练模式让 AI 先给一个方案你自己评估这个方案哪里好哪里不好然后自己动手改让 AI 审查你写的代码指出潜在问题但修复由你自己来让 AI 解释一段你看不懂的代码但解释完之后你要自己复述一遍让 AI 出题考你比如“给我一个关于索引失效的场景让我来排查”这些用法看起来比直接生成代码慢但它们能让你在用的过程中持续成长而不是持续退化。5. 实操搭建一套抗衰退的 AI 编程工作流5.1 环境准备与工具选型先说工具。现在市面上的 AI 编程工具大概分几类代码补全类以 GitHub Copilot 为代表适合日常写代码时提高效率对话式编程类以 Claude Code、Cursor 为代表适合做较大范围的任务Agent 框架类适合做自动化流程比如批量重构、自动化测试生成本地模型类适合对数据安全有要求的场景可以配合 LM Studio 之类的工具跑本地模型我的建议是不要一上来就全用上。先选一个对话式工具比如 Claude Code作为主力用熟了再考虑加别的。工具越多你花在配置和切换上的时间就越多真正用来思考的时间就越少。安装配置这块Claude Code 在 VS Code 里的配置大概是这样的流程先装 VS Code 扩展然后配置 API 密钥再设置工作目录和权限范围。Ubuntu 环境下也类似主要是把命令行工具装好然后配置好环境变量。这些步骤网上教程很多我就不展开写了。我想强调的是配置完之后的一件事把权限范围设小一点。不要让 AI 有权限直接改你的核心代码目录让它在一个沙箱或者临时目录里干活你审查完了再手动合并。这个习惯能帮你保持对代码的掌控感。5.2 提示词设计从“要代码”到“要思路”提示词这块我想给一个和主流不太一样的建议少写“给我代码”的提示词多写“给我思路”的提示词。举个例子。假设你要实现一个限流功能。差的提示词是“用 Python 写一个令牌桶限流器。”好的提示词是“我要在 Python 里实现一个限流功能场景是单机、每秒大概 1000 请求、允许突发到 2000。请给我三种不同的实现思路分别说明它们的优缺点、适用场景和潜在坑点。先不要写完整代码给我思路和关键伪代码就行。”看出区别了吗第一种提示词你拿到的是代码第二种提示词你拿到的是思考框架。拿到代码你只能复制粘贴拿到思考框架你可以自己动手实现实现的过程中你会遇到各种细节问题解决这些问题的过程就是你成长的过程。而且第二种提示词还有一个好处它会逼着 AI 暴露它的假设和取舍。AI 在给思路的时候会告诉你“方案 A 在突发流量下表现更好但内存占用高方案 B 相反”这些信息你在直接要代码的时候是拿不到的。知道了这些取舍你才能做出真正适合自己的选择。5.3 代码审查让 AI 当“第二双眼睛”AI 做代码审查是一个被严重低估的用法。很多人只用 AI 生成代码却不用它审查代码这挺可惜的。我的做法是自己写完代码之后让 AI 审查一遍但审查的重点不是“有没有 bug”而是“有没有我没想到的角度”。具体来说我会给 AI 这样的提示词“这是我写的一段代码功能是 XXX。请你从以下几个角度审查1边界情况处理是否完整2有没有性能隐患3错误处理是否合理4有没有更简洁的写法。不要直接给我修改后的代码先告诉我问题在哪里我自己来改。”这个用法的关键在于最后一句不要直接给修改后的代码。因为一旦 AI 给了修改后的代码你的大脑就会偷懒直接对比差异然后复制粘贴。但如果它只告诉你问题在哪里你就得自己动手改改的过程中你会真正理解那个问题。5.4 调试训练用 AI 出题而不是解题调试能力是重灾区所以我单独说一下怎么用 AI 来训练调试能力。常规用法是遇到 bug把错误信息丢给 AI等它给解决方案。这个用法在紧急情况下没问题但平时不要这么干。平时应该反过来让 AI 给你出调试题你自己来解。比如你可以这样跟 AI 说“给我一段有 bug 的 Python 代码bug 要隐蔽一点涉及并发或者边界条件。先不要告诉我 bug 在哪里让我自己排查。我排查完了会告诉你我的结论你再给我反馈。”这个用法特别适合在碎片时间做。等车的时候、午休的时候让 AI 出一道题你在脑子里过一遍排查思路或者掏出手机记下你的假设晚上回去验证。坚持一段时间你会发现自己的调试直觉明显变强了。6. 常见问题与避坑指南6.1 用了 AI 之后感觉自己变笨了正常吗正常而且很普遍。这不是你的问题是工具设计的问题。AI 编程工具的目标就是让你“少动脑”所以它必然会抑制你的思考。关键是要意识到这一点然后主动给自己创造“动脑”的机会。我的建议是把 AI 当成一个需要你监督的实习生而不是一个可以依赖的专家。实习生干活快但你需要检查他的产出、理解他的思路、纠正他的错误。这个检查和纠正的过程就是你保持能力的方式。6.2 怎么判断自己是不是过度依赖了给你几个自测问题如果明天所有 AI 工具都挂了你还能正常完成工作吗你最近一次不看 AI 提示、自己从头写一个完整模块是什么时候你能解释清楚你项目里每一段 AI 生成的代码为什么这么写吗遇到一个没见过的问题你的第一反应是思考还是打开 AI 对话框如果这几个问题的答案让你有点心虚那可能确实需要调整一下了。6.3 AI 生成的代码到底能不能直接上生产能但有条件。我的标准是AI 生成的代码必须经过你自己的理解和审查才能上生产。理解的意思是你能说清楚它为什么这么写、边界情况怎么处理、出问题了怎么排查。审查的意思是你看过每一行知道它在干什么。如果做不到这两点那这段代码就不应该上生产。不是因为它可能有 bug而是因为你无法为它负责。线上出了问题AI 不会帮你背锅背锅的是你。6.4 团队里怎么推广“抗衰退”的工作方式如果你是团队负责人想推动这件事我的建议是不要禁止 AI而是建立审查和学习的机制。比如可以要求所有 AI 生成的代码提交 PR 的时候必须附一段说明解释这段代码的逻辑和潜在风险。或者定期组织代码走查专门挑 AI 生成的代码来讨论。再或者给团队留出“无 AI 时间”比如每周五下午大家一起不用 AI 写代码互相 review。这些机制的目的不是限制效率而是在效率和质量之间建立一个缓冲带让团队不至于在追求速度的过程中把能力丢光。7. 一些个人体会我用 AI 编程工具大概有一年多时间了踩过的坑不少也总结了一些自己的原则。最后分享几条不一定对但都是真实体会。第一条AI 能帮你写代码但帮不了你理解业务。业务理解这件事只能靠你自己跟产品聊、跟用户聊、跟数据聊。AI 再强它也不知道你们公司的业务规则为什么是那样的那些规则背后的历史原因和现实约束只有人知道。第二条越是 AI 能做的事越不值得你花时间。这句话听起来有点绕但仔细想想就明白了。AI 能做的事意味着门槛低、可替代性强。你把时间花在这些事上你的价值就上不去。真正值得你花时间的是 AI 做不了的事——判断、决策、设计、沟通、创新。第三条保持手感比保持效率更重要。效率是短期的手感是长期的。你今天用 AI 省了两小时但如果你因此丢掉了自己写代码的手感未来可能要花两百小时来补。这笔账要算清楚。第四条不要跟 AI 比谁写得快要跟 AI 比谁想得深。写得快这件事人类已经不可能赢 AI 了。但想得深这件事AI 还差得远。你的竞争力应该建立在“想得深”上而不是“写得快”上。第五条定期给自己做一次“能力体检”。每隔几个月挑一个你平时用 AI 最多的领域关掉 AI 自己从头做一遍。看看自己还能不能做出来做出来的质量怎么样。这个过程可能会让你有点难受但它是保持清醒的最好方式。代码写得快是好事但别让快变成唯一的追求。技术这条路很长跑得快的人不一定跑得远跑得稳的人才能一直跑下去。
阅读完成 · 觉得有帮助？
