1. 工具会过时，判断力不会

这两年AI编程工具的更迭速度，快到什么程度？我粗略算过，光是去年一年，我深度用过的代码补全插件、对话式编程助手、终端Agent工具，加起来换了不下七八款。有的从惊艳到平庸只用了三个月，有的昨天还在社区里被吹上天，今天团队就宣布停止维护。如果你把精力全押在“学会某个工具”上，那你的技能保质期可能比冰箱里的牛奶还短。

我见过太多人陷入一个误区：花大量时间研究某个AI编程工具的快捷键、提示词模板、配置文件写法，却从来没想过一个问题——当这个工具明天被替代了，我手里还剩下什么？

答案其实很简单：剩下的是你在反复使用中沉淀下来的判断力。判断什么？判断一段AI生成的代码能不能直接上生产、判断一个需求该不该交给AI去写、判断AI给出的方案里哪部分是靠谱的哪部分是胡编的、判断什么时候该信AI什么时候该信自己的直觉。这些东西，换任何工具都不会丢。

举个很具体的例子。我刚开始用AI辅助写代码的时候，特别迷信它的“一次生成”能力。给一段需求描述，它哗哗哗吐出来五十行，我扫一眼觉得逻辑通顺，直接复制粘贴跑测试。结果呢？十次里有三次会在边界条件上翻车——要么是空数组没处理，要么是并发场景下状态错乱，要么是异常分支直接吞掉了错误。后来我养成了一个习惯：AI生成的每一段代码，我都要在脑子里过一遍“如果输入是空的会怎样”“如果同时来两个请求会怎样”“如果网络超时了会怎样”。这个习惯不是某个工具教我的，是我被坑了无数次之后自己长出来的。

这就是判断力。它不依赖于你用的是哪款工具，不依赖于工具背后的模型是第几代，它只依赖于你对问题本身的理解深度和对代码质量的敏感度。

工具是租来的，判断力是买断的。租的东西随时可能被收走，买断的东西永远在你身上。

那为什么很多人还是忍不住把精力花在“学工具”上？因为学工具见效快。花一个下午研究某个插件的配置项，马上就能在编辑器里看到效果，这种即时反馈让人上瘾。而培养判断力呢？它没有进度条，没有“已完成80%”的提示，你甚至说不清楚自己到底进步了没有。但恰恰是这种慢功夫，决定了你三年后还在不在这个牌桌上。

我自己的做法是：每接触一个新工具，只花20%的时间摸清它的核心能力边界，剩下80%的时间用来做一件事——拿它去解决我手头真实的问题，然后记录它在哪些地方让我失望。失望的地方，就是判断力生长的地方。比如某个工具在生成正则表达式时特别容易出错，那我就记住“正则这块不能全信它”；某个工具在处理大型重构时上下文丢失严重，那我就记住“跨文件重构还是得自己来”。这些经验一条一条攒起来，比任何教程都值钱。

2. 把AI当实习生，而不是当老师

很多人用AI编程工具的心态是“我不懂，你教我”。这个心态在入门阶段没问题，但到了实际工作中，它会让你吃大亏。因为AI最擅长的不是“教你对的东西”，而是“用非常自信的语气说出听起来很对的东西”。这两者之间的差距，有时候就是线上事故和正常发版的差距。

我习惯把AI编程助手当成一个知识面极广但缺乏实战经验的实习生。这个实习生读过海量的代码，见过无数的设计模式，你问他什么他都能接上话。但他有几个致命弱点：第一，他不知道我们项目的历史包袱，不知道哪些代码是绝对不能动的；第二，他分不清“理论上可行”和“工程上可靠”的区别；第三，他特别容易在细节上想当然，尤其是涉及具体版本、具体环境、具体依赖的时候。

所以我的工作方式变成了：让实习生先出方案，我来做最终决策。具体怎么操作？

2.1 需求拆解阶段：让AI做广度，自己做深度

拿到一个需求，我不会直接让AI写代码。我会先让它帮我做一件事：列出这个需求可能涉及的所有技术点和潜在坑。比如我要实现一个“用户上传文件后异步处理并通知结果”的功能，我会问AI：“这个功能在实现时需要考虑哪些边界情况？”它会给我列出一堆：文件大小限制、文件类型校验、并发上传、处理超时、通知失败重试、幂等性保证等等。

这一步的价值在于查漏补缺。我自己可能只能想到五六个点，AI能给我列出十五个。但接下来才是关键：这十五个点里，哪些是真正需要处理的，哪些是过度设计，哪些在我们当前架构下根本不成立，这些判断必须我自己来做。AI不知道我们用的是单体还是微服务，不知道我们的消息队列有没有持久化，不知道我们的用户量级是多少。这些上下文只有我有。

2.2 代码生成阶段：让AI做草稿，自己做精修

到了写代码环节，我通常会让AI先生成一版“能跑通基本逻辑”的代码。注意，我从来不指望它一次生成就能直接上生产。我把它当成一个打字速度极快但不太靠谱的初级工程师——它能帮我把框架搭起来，把重复性的样板代码填好，把常见的API调用写对，但核心的业务逻辑、异常处理、边界条件，必须我自己来。

这里有一个很实用的技巧：让AI生成代码时，明确告诉它“不要处理异常，不要做参数校验，只写核心逻辑”。为什么？因为如果你让它把所有东西都写全，它会生成一大堆看起来面面俱到但实际上你根本不会用的代码。比如它会给每个方法都加上try-catch，但catch里面只是打印日志然后返回null——这种代码在真实项目里就是灾难。不如让它只写核心逻辑，异常处理和参数校验你自己来，这样你对代码的掌控力会强很多。

2.3 代码审查阶段：让AI做检查，自己做决策

代码写完之后，我会让AI帮我做一轮review。但我不指望它发现所有问题，我主要用它来检查那些我可能忽略的细节。比如：“这段代码有没有潜在的并发问题？”“这个SQL在数据量大的时候会不会慢？”“这个正则有没有 catastrophic backtracking 的风险？”

AI在识别“已知模式”方面很强。如果你写的代码里有一个经典的N+1查询，它大概率能指出来。但如果你写的代码里有一个业务逻辑上的微妙错误——比如状态机的某个转换条件写反了——它基本发现不了，因为它不理解你的业务。

所以我的流程是：AI负责找“技术模式”层面的问题，我负责找“业务逻辑”层面的问题。两者结合，才能保证代码质量。

把AI当老师，你会学到很多似是而非的东西。把AI当实习生，你会得到很多草稿，但最终成品由你把关。

这个心态转变带来的另一个好处是：你不会再因为AI给出了一个看似完美的方案就盲目照搬。你会自然地追问：“这个方案在我们场景下真的可行吗？”“它有没有考虑到我们的特殊情况？”这种追问的习惯，就是判断力在起作用。

3. 判断力的三个核心维度

说了这么多，判断力到底包含哪些具体的能力？我把它拆成三个维度，每个维度都可以刻意练习。

3.1 技术判断：这段代码能不能上生产

这是最基础的一层。AI生成的代码，从“能跑”到“能上生产”，中间隔着一条河。这条河里有几块石头你必须踩稳：

第一块石头是边界条件。AI特别容易忽略空值、零值、极值、并发这些边界。我养成了一个条件反射：看到AI生成的任何函数，先看它的参数校验和异常处理。如果它假设输入永远合法，那这段代码就不能直接用。

第二块石头是性能特征。AI生成的代码往往是“正确但低效”的。比如它可能会在循环里查数据库，可能会用O(n²)的算法处理本可以O(n)解决的问题，可能会生成一个巨大的正则。这些在测试环境数据量小的时候看不出来，一上生产就炸。

第三块石头是依赖风险。AI有时候会“发明”一些不存在的API，或者使用某个库的过时用法。它还会推荐一些看起来很方便但实际维护状态堪忧的第三方包。每次它引入一个新依赖，我都会去查一下这个包的最近更新时间、issue数量、star趋势。

3.2 需求判断：这个功能该不该让AI写

不是所有代码都适合交给AI生成。我总结了一个简单的判断标准：

这个表不是绝对的，但大方向是：越靠近业务核心、越涉及安全边界、越需要领域知识的代码，越应该自己写。AI可以帮你写一个排序算法，但它写不了一个符合你公司风控规则的交易逻辑。

3.3 时机判断：什么时候该用AI，什么时候该自己上

这一点最容易被忽略，但可能最重要。我见过有人写一个简单的for循环也要问AI，也见过有人面对一个复杂的状态机设计硬是自己憋了三天。这两种都是判断力不足的表现。

我的经验法则是：当你对问题本身已经有清晰的思路，只是懒得打字时，用AI。当你对问题本身还一头雾水，需要先理清思路时，自己先想，想清楚了再用AI加速实现。因为如果你自己都没想清楚，AI给你的方案你根本没有能力判断好坏，最后就是被它牵着鼻子走。

还有一个时机判断是：当你需要学习一个新领域时，先用AI快速了解全貌，然后自己深入细节。比如你要用一个新的消息队列，可以让AI给你列一个核心概念清单和最小示例，但真正要上生产，你得自己去读官方文档的可靠性章节。

4. 那些AI教不会你的事

有些东西，无论AI进化到什么程度，它都教不会你。不是因为它不够聪明，而是因为这些东西本质上不属于“知识”范畴。

4.1 对“坏味道”的嗅觉

代码的坏味道，AI能识别一部分——比如重复代码、过长函数、过大的类。但更深层的坏味道，它闻不出来。比如：一个看似合理的抽象，实际上引入了不必要的间接层；一个“灵活”的配置系统，实际上让代码变得难以追踪；一个“通用”的工具类，实际上在掩盖设计上的混乱。

这些判断依赖于你对项目演进历史的了解，对团队协作模式的感知，对未来需求变化的预判。AI没有这些上下文，它只能看到代码本身。

4.2 对“技术债”的权衡

什么时候该走捷径，什么时候该老老实实做对的事？这是一个典型的工程判断，没有标准答案。AI倾向于给你“正确”的方案——它会告诉你应该写单元测试、应该做错误处理、应该考虑扩展性。但在真实项目里，有时候你就是需要在两天内上线一个功能，有些债就是得先欠着。

这种权衡能力，来自于你被 deadline 追过、被线上事故教育过、被技术债坑过之后的经验积累。AI没有经历过这些，它给的建议往往是“教科书式正确但工程上不现实”的。

4.3 对“人”的理解

代码最终是给人用的，也是给人维护的。一段代码写得好不好，除了技术指标，还要看它是否容易被同事理解、是否容易交接、是否符合团队的编码习惯。AI不知道你团队里有个同事特别讨厌链式调用，不知道你们代码规范里禁止使用某个语法糖，不知道你们的code review文化是倾向于严格还是宽松。

这些“人的因素”，只有你自己能判断。而恰恰是这些因素，决定了你的代码能不能顺利合并、能不能长期维护。

AI能帮你写出“对”的代码，但写不出“合适”的代码。“合适”这个词里，藏着太多AI看不见的东西。

5. 怎么刻意练习判断力

判断力不是天生的，也不是用多了AI就自动长出来的。它需要刻意练习。我分享几个我自己在用的方法。

5.1 先猜后验

每次让AI生成代码之前，我先自己猜一下它会怎么写。比如我要写一个“从URL中提取文件名”的函数，我会先想：它大概率会用正则，可能会忽略查询参数，可能会对编码后的URL处理不当。然后我再让AI生成，对比一下我的猜测和它的实际输出。

这个方法的妙处在于：它强迫你在AI动手之前先动脑。猜对了，说明你对这个问题的理解已经比较到位；猜错了，说明你发现了自己的认知盲区。无论哪种结果，你都在进步。

5.2 故意找茬

AI生成代码后，不要急着用。花五分钟时间，专门找它的毛病。我通常会从这几个角度入手：

• 如果输入是null/空字符串/负数/超大值，会怎样？
• 如果这个方法被并发调用，会怎样？
• 如果依赖的服务超时或返回错误，会怎样？
• 如果数据量增长100倍，会怎样？
• 如果这段代码三个月后需要修改，改起来方便吗？

这五个问题问下来，你基本能发现AI代码里80%的隐患。而且这个习惯一旦养成，你看自己写的代码也会用同样的标准，代码质量会整体上一个台阶。

5.3 定期复盘AI的“翻车现场”

我建了一个文档，专门记录AI在哪些场景下容易出错。比如：

• 涉及日期时间处理时，时区和夏令时经常搞错
• 涉及金额计算时，浮点数精度问题几乎必犯
• 涉及正则表达式时，复杂pattern的边界匹配容易出错
• 涉及并发时，锁的粒度和顺序经常有问题
• 涉及数据库时，索引和查询计划基本不考虑

这个文档越写越长，我对AI能力边界的认知也越来越清晰。现在我看到一个任务，基本能预判“这个交给AI没问题”还是“这个得我自己来”。

5.4 读别人的代码，尤其是烂代码

判断力的另一个来源是见过足够多的好代码和坏代码。我有个习惯，每周花一两个小时读一些开源项目的源码，或者review团队里其他人的代码。读好代码的时候，我会想“这个设计为什么好，如果让AI来写它会怎么写”；读烂代码的时候，我会想“这个问题AI能不能发现，如果AI来写会不会犯同样的错误”。

这种对比阅读，比单纯自己写代码的成长速度快得多。因为你是在用别人的经验来训练自己的判断模型。

6. 工具会变，但底层能力不变

回到最开始的问题：AI编程时代，我们到底该学什么？

我的答案是：学那些换工具之后还能用的东西。具体来说：

• 问题拆解能力：把一个模糊需求拆成清晰的技术任务，这个能力跟工具无关。
• 方案评估能力：面对多个技术方案，能判断哪个更适合当前场景，这个能力跟工具无关。
• 代码审查能力：能快速识别代码中的隐患和坏味道，这个能力跟工具无关。
• 工程权衡能力：在质量、速度、成本之间找到平衡点，这个能力跟工具无关。

这些能力，AI可以辅助你练习，但没法替你掌握。它们是你作为工程师的核心资产，不会因为某个工具的兴衰而贬值。

我现在的日常是：用AI帮我写掉那些重复性的、模式化的代码，把省下来的时间用来思考架构、review关键逻辑、和团队讨论方案。AI是我的打字员、我的资料检索员、我的第一轮代码审查员，但它不是我的决策者。决策权始终在我手里，因为只有我知道这个项目的来龙去脉，只有我需要对最终结果负责。

如果你现在还在纠结“该学哪个AI编程工具”，我的建议是：随便挑一个用起来，然后用它去解决你手头最真实的问题。在用的过程中，把注意力从“这个工具怎么用”转移到“这个工具在什么地方让我失望”上。那些让你失望的地方，就是你判断力需要生长的地方。

工具会一直变。今天好用的，明天可能就没人维护了。但你在使用工具过程中积累的判断力，会跟着你一辈子。这笔账，怎么算都划算。