我把 Copilot、Claude Code 卸载了，然后得出了一个让同事沉默的结论

上个月，有位同事私信我：「我最近发现一个很奇怪的现象，离开 Cursor 之后我不知道怎么写代码了，感觉脑子空了。」

他说这句话的语气不是炫耀，是有点慌。

这不是个例。Hacker News 上有篇文章 「Spending 3 months coding by hand」 拿到了 224 分、229 条评论，评论区里大量工程师分享相似的体验：用 AI 用顺手了，回头发现自己搜 API 文档都懒得搜了，更别说独立调试一个陌生系统。

我不想写一篇「AI 工具是毒药，手写代码才是真功夫」的文章——那种论调本质上是在炫耀自己的苦难经历。我想分析的是：在什么情况下，AI 工具会让你变弱？在什么情况下，它会让你变强？ 这个问题有明确答案，不是「各有利弊」的废话。

AI 工具依赖的本质不是「用多了」，而是「用错了地方」

先说我的核心观点：AI 辅助编程本身没有问题。GitHub Copilot 的研究数据显示，使用 Copilot 的开发者完成同等任务的速度比对照组快 55%（平均 1 小时 11 分钟 vs 2 小时 41 分钟），这个数字不是假的。Stack Overflow 2024 年开发者调查也显示，62% 的开发者已经在日常工作中使用 AI 工具，这个趋势不可逆。

但同样不假的是：评论区里那位在公司接手了一个「AI 生成的代码库」的工程师说的，他们团队没有任何人真正理解这套代码，没人敢动，没人会改。这两件事同时是真的，问题出在哪？

问题出在任务类型和工具选择的错配。

这里有一个分类框架，我用了将近两年时间才想清楚：

AI 编程工具使用场景分类矩阵，横轴为任务创意性，纵轴为任务重复性，四个象限分别标注 AI 可替代、AI 加速、手写更好、工具中性

AI 编程工具使用场景分类矩阵，横轴为任务创意性，纵轴为任务重复性，四个象限分别标注 AI 可替代、AI 加速、手写更好、工具中性

这张图的核心逻辑是：重复性高、创意性低的任务（写单测、生成 CRUD 代码、格式转换）让 AI 做，是真正的效率提升——你把认知资源从无意义的重复劳动中解放出来。重复性低、创意性高的任务（系统架构设计、核心算法优化、复杂业务逻辑调试），让 AI 做，是在绕过你最需要完成的思维训练。

很多人用 AI 用出问题，不是因为用太多，而是因为在第四象限的任务里也习惯性地先问 AI。

时间一长，大脑对这类思维的调用能力就真的会减退。这不是玄学，有认知科学的支撑：不被频繁调用的神经回路会逐渐被弱化——熟悉这一点的读者可能会想到「use it or lose it」这个原则。

哪些能力会首先退化：一条具体的因果链

我见过不少工程师描述自己「被 AI 带坏了」的感受，综合下来退化是有固定顺序的：

过度依赖 AI 编程工具的技能退化路径，从停止查文档到无法独立调试到设计能力退化的因果链

过度依赖 AI 编程工具的技能退化路径，从停止查文档到无法独立调试到设计能力退化的因果链

第一步退化：停止主动查文档。 这个过程非常隐蔽。AI 给你答案的速度比搜文档快得多，久而久之你就不再练习「如何在文档里找到我需要的信息」这个技能了。这不是大事——直到有一天 AI 给你一个过期的 API，你发现自己没有习惯去验证。

第二步退化：理解能力退化。 HN 评论区里有工程师说得很准：「当我自己写枯燥的胶水代码，我会在脑子里建立项目的地图；但如果 AI 写完之后我再来 review，几周后我就会问自己『这段代码是放在哪来着』。」手写代码本身是学习的过程，AI 辅助跳过了这个过程，代价是你对代码库的掌握深度更浅。

第三步退化：调试能力退化。 这是最影响日常工作的一步。独立调试需要一套「提出假设 → 设计验证 → 缩小范围」的思维流程，这个流程需要练习才能快。习惯了先把报错丢给 AI，这套流程就逐渐生疏——即使最后问 AI 解决了问题，下次同类问题你还是得问 AI，你没有从这次调试里学到东西。

第四步退化：设计能力退化。 这是最严重的一步，也是最难被意识到的。架构设计本质上是在大量 tradeoff 中做判断，这个判断能力需要在真实场景里反复推导才能建立。如果每次设计方案都让 AI 给出建议然后你来选，你的判断力成长的速度就远低于你处理问题的数量——时间长了，你会发现脱离 AI 你很难独立把一个设计推导清楚。

这条链最危险的地方在于：每一步在当时都感觉合理，「我只是让工具替我做了重复工作」——但每一步都是下一步的前提条件。

我真实踩过的坑：一次架构评审的尴尬

大约 18 个月前，我负责一个中台服务的重构方案。整个设计过程我高度依赖 Claude——让它比较不同的分布式事务方案，让它生成几种架构选项，让它分析每种方案的 pros and cons。最终拿出来的方案看起来很完整，文档也写得漂亮。

评审会上，我们团队的 Tech Lead 问了一个问题：「如果下游 B 服务在第二阶段提交之前崩了，这里的恢复逻辑是什么？」

我沉默了大概五秒钟。

我知道「理论上应该有什么」，但我不知道「我的方案里具体是什么」。因为这部分细节是 AI 给出的，我 review 了，觉得没问题，但没有自己从头推导过——所以遇到追问，我没有原始的推理路径可以调用。

这种尴尬不是「知识不够」，而是「我从来没有真正理解过这个方案」。AI 帮我生成了一个足够像样的答案，而我把「能看懂」误认为了「真正理解」。这是使用 AI 最常见的认知陷阱：生成的内容有足够的可信度，让你不会去质疑它，也不会去深挖它，结论在纸面上是完整的，但你脑子里没有对应的推理结构。

后来我花了三天重新把整个方案从头推了一遍，手写。那三天推导的质量远比之前 AI 辅助的版本更扎实——不是因为手写「更神圣」，而是因为你只能写你真正理解了的东西，写不下去就意味着还没搞清楚。评审通过了，但更重要的是，这次经历让我开始认真区分两类任务：「AI 帮我做事」和「AI 替我思考」。前者可以，后者是在给自己挖坑。

这个问题的答案，取决于你在哪类任务上用了 AI。

那些真正受益于 AI 的场景

说了这么多风险，我也必须说清楚：AI 工具在正确的场景下是真的好用，不是有点好用，是生产力倍增器。

写单元测试。 这是 AI 最值得放心依赖的场景之一。测试代码通常有固定模式，需要覆盖边界条件，写起来既重复又重要。让 AI 生成测试框架，你来 review 并补充遗漏的场景，是真正把认知资源用到了有价值的地方——「哪些边界条件需要测试」这个判断是需要人来做的，「把这些条件写成代码」的机械部分交给 AI 完全合理。

文档和注释。 代码逻辑清楚的情况下，写文档是一件重要但高度模板化的事。AI 在这里几乎不会让你退化任何能力，因为「写文档」本来就不是需要深度思维训练的技能——它是表达，不是推理。

不熟悉语言的一次性脚本。 偶尔需要写一个 Bash 脚本或者 Go 工具，但平时主要用 Java/Python 的工程师，让 AI 帮你快速完成这个任务是完全合理的。你不会因此退化你的核心技术栈能力，这类任务本来就不是你需要深耕的领域。

已有清晰设计后的实现。 如果你已经独立完成了架构设计和模块划分，清楚地知道每个部分要做什么，这时候用 AI 来加速具体实现是很健康的使用方式——你保留了设计能力，AI 承担了重复性的实现工作。

区别不在于「用了多少 AI」，在于你有没有在过程中真正思考过。

手写 3 个月之后，真正改变了什么

回到最开始那篇 HN 文章的作者 Miguel Conner 的经历。他的观察和我的判断高度吻合：对于深度学习类的工作，手写代码的同时你在同步理解代码库；AI 代理会精确执行你的需求，但如果你自己没有真正理解，你就没有从这个过程里学到东西。

他在 6 周时间里完成了斯坦福 CS336 第一个作业（50 页）——从头手写一个 GPT-2 风格的 Transformer，跑 hyperparameter ablation，在 OpenWebText 上训练。没有 AI 辅助的情况下，这个过程让他建立了对 LLM 底层机制真正扎实的理解，这种理解是他之后用 AI 工具「有更大杠杆」的基础。

这就是关键：深厚的基础知识是你使用 AI 工具获得更大杠杆的前提，而不是 AI 工具的替代品。

HN 评论区里有人分享了一个更直接的对比：他在公司待过两个团队，一个团队大量使用 AI 生成代码，代码量很高，功能交付很快；另一个团队对 AI 使用更谨慎，速度慢一些。但当系统出现复杂故障时，第二个团队的工程师能在两小时内定位并修复，第一个团队花了两天，因为没有人真正理解那套 AI 写的代码里的因果关系。

还有一条评论让我印象很深：「真正让公司害怕的那种工程师，是那个不依赖 AI 也能工作的人。」这句话背后的逻辑不是「不用 AI 就牛逼」，而是：当所有人都把 AI 用成拐棍时，那个没有丢掉底层能力的人的相对价值反而在上升。这不是悲观的预言，是可以验证的趋势——看看现在的高级工程师岗位面试，手写代码、系统设计、故障排查，这些完全不依赖 AI 的能力仍然是核心评估维度。

手写代码 3 个月改变的不是产出速度，而是你对自己能力边界的清醒认知。知道自己在哪里真正有能力、在哪里只是在依赖工具，这种清醒本身就有价值。

如何判断你现在在哪个位置

理论讲完了，给一个可操作的自检框架。下面这张决策树可以帮你快速判断自己目前的状态：

判断是否过度依赖 AI 编程工具的自检决策树，三个关键问题帮助工程师评估自身 AI 依赖程度

判断是否过度依赖 AI 编程工具的自检决策树，三个关键问题帮助工程师评估自身 AI 依赖程度

三个核心问题，每一个都是一道实际的检测信号，不是泛泛的自我反问：

关掉 AI，你能独立写完眼前这个函数吗？ 注意，这里说的不是「你以前能不能」，而是「现在，今天，眼前这个任务」。如果答案是「想了一会儿能」，没问题，AI 还没有影响你的独立编写能力。如果答案是「完全不知道从哪开始」或者「会写但需要 30 分钟来找回感觉」，这是需要注意的信号。

出现 Bug 时，你的第一反应是什么？ 停下来想想，你最近一次遇到 Bug 是怎么处理的。「先自己看一遍 log 和调用栈，推测两三个可能原因，然后逐个验证」还是「把报错截图丢给 AI，等它给答案」？后者偶尔是可以的，毕竟 AI 有时候确实比搜索引擎快得多——但如果已经成为你的默认行为，不经过独立思考直接求助，调试能力正在悄悄衰退。

独立做一个模块的设计，你能不依赖 AI 把思路推完吗？ 「推完」的定义很具体：从需求出发，把数据流向、边界条件、错误处理、扩展点都自己推导一遍，形成一个完整的设计初稿。这之后你当然可以用 AI 帮你找漏洞，这是健康的用法。但如果连第一步的独立推导都做不到——坐下来脑子空白，必须先问 AI「给我几个方案」才能开始——设计能力已经退化到了需要干预的程度。

如果这三个问题有任何一个让你觉得「确实不太行」——建议的修复方案不是戒掉 AI，而是每周刻意留出一到两天完全关闭 AI 工具写代码。就像运动员不会每次训练都用最好的装备，刻意增加阻力才能维持肌肉。时间不需要多，两个月后你会发现自检结果明显不同。

我的明确判断（这里不讲「各有利弊」）

到这里可以给出几个有立场的结论，不给「各有利弊，需要具体问题具体分析」这种回避式答案：

如果你是工作 0-2 年的工程师，在大量使用 AI 辅助，这是一个严肃的风险。 你正处于建立基础能力的关键阶段——阅读报错信息、查阅原始文档、从零调试陌生代码、在没有参考的情况下设计一个模块。这些能力的建立需要时间和痛苦，无法被绕过。如果这个阶段大量使用 AI，你会积累一个「看起来能做事但没有真正理解为什么」的知识结构——这个结构在你遇到非标准问题时会塌。不是不能用 AI，而是比例要更谨慎，核心学习任务必须手写完成。

如果你是工作 5 年以上的工程师，AI 工具对你几乎是纯收益。 你已经建立了独立调试、独立设计、独立推导的能力，这些能力不会因为用了 AI 就消失——能力一旦建立，除非你长期完全不用，否则不会快速衰退。AI 工具是在这个基础上放大产出，帮你把重复劳动的时间省出来做更有价值的事。对你来说，不充分使用 AI 才是在浪费时间。

工作 2-5 年的中间地带是最需要主动思考的阶段。 基础能力已经有了一定积累，但还没到「用 AI 完全无风险」的程度。这个阶段最好的策略是：核心业务逻辑、需要深度理解的模块、正在学习的新技术领域——手写为主；重复性高、标准化程度高的任务——放心用 AI。

不同任务类型的结论已经写在上面那张矩阵图里，这不是「仁者见仁」的问题，是可以分析清楚的工程判断。真正的问题不是该不该用 AI，而是在哪里用、怎么用。

常见问题

Q: 我现在已经依赖 AI 了，是不是已经晚了？

A: 不晚。能力退化是可逆的，条件是你重新开始用它。马丁·福勒团队在研究 AI 辅助编程时的核心发现是：开发者的技能仍然是决定 AI 工具能否发挥价值的关键变量——技能越强，AI 的杠杆效应越大。从今天开始刻意安排一些纯手写的时间，两三个月内就能找回手感。

Q: 用 AI 生成的代码质量真的差吗？

A: 对于标准化任务，AI 生成的代码质量往往不差，有时比匆忙手写的更规范。真正的质量问题出现在两类情况：一是生成了看起来对但有逻辑漏洞的代码，而你没有能力识别（这是你的理解能力问题）；二是生成了能用但设计不合理的结构，而你没有动机去重构（这是长期技术债问题）。这两个问题都不是 AI 的错，是工程师没有尽到 review 责任。

Q: 团队里有人完全不用 AI，是不是在浪费时间？

A: 如果他们在做的是高重复性的标准任务，是在浪费时间。如果他们在做的是需要深度理解的核心模块，「慢一点但真正理解了」可能比「快一点但依赖黑盒」更值钱。判断的标准是任务类型，不是哲学立场。

Q: 学新技术的时候是否应该用 AI？

A: 这是最值得谨慎的场景。「让 AI 帮我学 Rust」和「用 Rust 完成一个任务时遇到语法问题查 AI」是两件完全不同的事。前者会让你跳过最关键的认知阶段——那些搜索、困惑、试错的过程本身就是学习内容。遇到具体问题查 AI 是合理的查询工具使用，让 AI 替你学习是在欺骗自己。

Q: 我的公司要求大家都用 AI 提高效率，但我担心自己退化，怎么办？

A: 这两件事不矛盾。在对外交付物（文档、测试、模板化代码）上用 AI 提高产出，在个人能力建设上（核心模块的独立实现、新技术的从头学习、架构设计的独立推导）保持不依赖 AI。对公司来说你效率高，对自己来说你能力没退化。

62% 的开发者在用 AI 工具，这个数字还在涨。真正的问题不是用不用，而是你有没有意识到自己用 AI 的时候是在让自己变强，还是在让自己变弱。

这个问题没有外部标准答案，只有你自己知道。但有一个粗暴的检验方法：如果今天把所有 AI 工具都关掉，你还能正常工作吗？如果这个问题让你感到一丝不安，那不安本身就是答案。