这两年我听到最多的一句话就是AI 都能写代码了我们学软件开发还有什么意义问这个问题的人里有刚入行的新人也有写了五六年业务代码的老手。我自己的答案是AI 时代的软件开发学习恰恰比以往任何时候都更值得投入只是学习的方向、方法和判断标准彻底变了。以前学开发核心是从无到有地构建——你要记住语法、背下框架用法、手撸算法、处理各种边界条件。现在这些事AI 几乎都能做得比人快。但有个东西 AI 暂时替代不了那就是判断判断一段代码该不该这么写判断一个需求背后真正的痛点是什么判断 AI 给出的方案在真实场景里会不会翻车。这些判断力的来源就是你持续学习的成果。所以这篇文章我不打算给你列一份必学清单而是想聊聊 AI 时代学习软件开发这件事本身该学什么、为什么学、怎么学才能真的产生竞争力。下面这五块内容是我自己这两年实践下来最有感触的部分也是我带过的新人、同事踩过坑之后总结出来的经验。1. 学习的重心从怎么能写出来变成凭什么这么写老一代开发者包括我的学习模式很大程度上是以写出来为目标的。拿到一个需求先想用什么框架、起什么项目结构、调哪个 API代码能跑通就算成功一半。这种模式在 AI 时代被彻底解构了——因为这些事你只要描述清楚AI 能在几秒内给你一版能跑的代码。但问题也出在这里。AI 给出的是一个可能正确的方案而你需要判断的是这是否是当前场景下最合适的方案。1.1 你学的不再是 API而是 API 背后的设计逻辑举个例子。以前学一个新框架大家会去背它的生命周期方法、配置项、常用注解。在 AI 时代这些细节你随时可以问 AI而且它答得比记忆更全。真正需要花时间去研究的是这个框架为什么要这样设计生命周期它的数据流为什么是单向的它对异常处理的态度是什么这些问题的答案决定了你在真实项目里遇到诡异问题时是能顺着设计逻辑推断出问题可能出在哪一层还是只能病急乱投医地反复改代码碰运气。我见过一个真实案例某团队用 AI 生成了一段缓存更新的代码跑起来测试也过了但上线后偶发数据不一致。新同事盯着代码看了很久没发现问题因为从单条代码来看逻辑没问题。后来是另一位老手顺着缓存为什么需要失效、失效的时机应该在哪、并发情况下会有几种执行顺序这几个问题一推才发现 AI 生成的版本漏掉了并发场景下的竞态条件。这个案例说明什么说明知识的具体内容会贬值但知识的结构和判断依据不会。框架会过时AI 会帮你写代码但你对一套系统如何被设计出来、为什么被设计成这样的理解才是你能发现 AI 漏洞的根本原因。1.2 需求分析能力成为最核心的杠杆以前需求分析是产品经理和资深架构师的事初级开发基本是拿到需求就开写。但 AI 时代出现了一个新情况需求描述得越模糊AI 给你的代码就越像空中楼阁。你问 AI帮我写一个用户登录功能它能给你一版标准的账号密码登录但你追问我们这是扫码登录而且要考虑同一账号多端互踢、弱网环境下的重试策略、以及风控拦截之后用户看到什么提示AI 才能给出贴近真实场景的代码。这种把模糊需求拆成清晰边界条件的能力就是需求分析能力。它不是产品经理专属的而是每一个写代码的人都必须练的。我自己训练这种能力的方法是拿到任何需求先逼自己写出这个功能必须具备的五个边界条件三种可能失败的情况两类受影响的用户角色写完再让 AI 生成代码。你会发现你对需求的理解越清晰AI 生成的代码质量就越高。反过来你连需求都说不清楚时AI 给你的东西一定也充满臆测。所以 AI 时代学软件开发学的是把心里的模糊想法变成精确描述的能力。这个能力不跟着 AI 走只跟着你的思维走。2. 底层知识没有过时只是它服务的对象变了很多初学者问过我一个很实际的问题现在还需要学数据结构、操作系统、网络这些底层知识吗反正写业务代码都用不上。我懂这个困惑——你用 Python 写一个 CRUD 接口确实用不上红黑树也用不上操作系统的页面置换算法。看起来底层知识跟日常开发是脱节的。但在 AI 时代底层知识的价值从帮你从零实现变成了帮你验证和纠偏。2.1 算法和数据结构AI 出错时你才有底气AI 生成代码最常见的错误不是语法错误而是在复杂度敏感的场景下选错了数据结构或算法。它可能给你一段功能上完全正确、但数据量一上来就卡死的代码。我自己就遇到过让 AI 写一个频繁判断一批用户 ID 是否在某个大列表中的功能它第一版用的是列表遍历。功能没问题测试数据量小时也很快。但当我追问这个 list 可能有十万条每秒钟要判断几百次你确定用 in 操作符合适吗它立刻改成了用集合。为什么它能改因为 AI 知道你问到了复杂度。但如果你自己不懂复杂度你根本问不出这个问题也就发现不了隐患。所以学数据结构和算法不是为了在面试时手写快排而是为了建立一种对性能隐患的嗅觉。AI 帮你写代码你负责给代码做体检。没有底层知识你连体检项目都不知道有哪些。2.2 操作系统和网络排查问题的导航地图我见过太多人遇到线上问题时第一反应是直接把报错信息扔给 AI让它分析。这没错AI 确实能帮你定位很多问题。但你能从 AI 的回答里得到多少帮助取决于你能不能理解它说的那些概念。比如 AI 告诉你这个错误可能是 TCP 连接池耗尽导致的你如果不知道什么是连接池、不知道 TCP 连接的四次挥手过程、不知道为什么连接会处于 TIME_WAIT 状态那你就只能再问一句那怎么办然后瞎子摸象一样去改配置。但如果你懂网络基础你就会接着问当前连接池大小是多少服务端和客户端分别是什么角色TIME_WAIT 主要出现在哪一端这一串问题问下来AI 才能给你精确的解决方案。底层知识在 AI 时代更像是你在黑屋子里走路时手里那根拐杖。AI 能告诉你屋子里大概有什么但你没拐杖还是寸步难行。2.3 一个实操案例AI 生成的代码为什么会错说个我最近踩过的坑。我让 AI 写一段定时任务的代码内容是每小时从外部接口拉取数据并更新数据库。AI 给的版本看起来完美有重试、有日志、有异常捕获。但我在 review 的时候发现一个隐蔽问题它给的重试逻辑是出错后等 5 秒再重试但外部接口的限流策略是每分钟最多 30 次。如果连续出错程序会一直卡在重试循环里把自己这边的请求额度耗尽然后把外部接口彻底打挂。这个问题怎么发现的不是靠 AI 帮我 review 的——AI 在生成代码时不会主动考虑另一个系统外部接口的约束条件除非我明确告诉它。我能发现这个问题靠的是对分布式系统里限流、重试、熔断这套思路的理解。这就是底层知识或者说系统设计知识在 AI 时代的实际价值在 AI 想不到的地方你能替它想到。3. 最高效的学习路径逆向式学习让 AI 当你的导师而不是答案机器传统的学习路径是正向的先学理论再做练习最后做项目。这条路在 AI 时代显得太慢了也不符合现在信息获取的方式。我这两年实践下来最有效的是逆向式学习——先让 AI 给你一个结果然后往回追问为什么。3.1 逆向式学习的四步循环这个循环大概是这样的抛出任务把一个真实的、有细节的问题丢给 AI让它给出完整方案或代码。逐行追问对 AI 给出的结果里每一个你不理解的细节逼问为什么这里要这样写如果换一种写法会怎样这里的边界情况是什么。这步是核心不能只停留在看懂。主动制造变化修改 AI 给你的方案中的某个条件比如如果并发量翻十倍会怎样如果数据源换成消息队列呢观察 AI 怎么调整方案。提炼沉淀把这次对话里你学到的东西提炼成几条自己的判断准则记录下来。下次遇到类似问题时优先用自己提炼的准则去判断。这套方法的精髓在于你不是在向 AI 要答案你是在用一个高仿真模拟器练习自己的判断力。AI 给你一个结果你的任务不是接受它而是审问它。每一次审问都是一次真实的学习。3.2 提问方式决定了你的学习深度很多人觉得用 AI 学习效果不好原因在于提问方式。你问帮我写一个文件上传功能AI 给你一段代码你复制粘贴跑通觉得自己学会了。其实你什么都没学会——你只是把问题外包了。真正有效的提问方式是带限定条件的帮我写一个文件上传功能要求支持大文件分片、断点续传、服务端校验文件类型和大小、同时要防止重复提交。顺便解释一下你为什么要用这些技术方案。你看前半部分是任务后半部分是要求 AI 解释设计理由。当 AI 被迫解释自己的设计理由时它会把它内部隐藏的决策链条摊开在你面前这才是最有学习价值的部分。你看到的不是最终代码而是这代码为什么长这样。3.3 用 AI 模拟面试和 code review逆向式学习还有一个高阶玩法让 AI 扮演一个严格的面试官或者 code reviewer对你自己写的代码或 AI 生成的代码进行提问。比如我让 AI 生成一段代码后会追加一句请你假设你是一个资深架构师正在审查一个初级开发提交的代码从可维护性、异常处理、性能、安全性四个维度给我挑毛病。每个毛病都要给出具体的修改建议和理由。然后我会根据它挑的毛病逐条去查资料、理解原理再回来跟它讨论。这种被挑战的感觉比单纯刷题、看教程更能逼出深度理解。因为你被迫面对自己的盲区——那些你平时根本不会注意的差不多就行的地方全被 AI 毫不留情地指出来了。4. 工程能力的分量比代码本身更重聊完了学什么和怎么学还得聊一个更现实的话题在 AI 时代什么样的软件开发能力最值钱我的观察是写代码的能力正在快速贬值而工程能力正在快速升值。以前你写代码快是很大的优势现在 AI 写代码更快你的优势必须转移到把代码放到真实环境里还能稳定运行这件事上。4.1 调试能力AI 时代的硬通货AI 生成的代码不是不会出 bug恰恰相反它出的 bug 往往更隐蔽——因为单看语法和逻辑都没问题问题出在它没有真实环境的反馈。而调试这件事恰恰是最依赖人的能力的环节它需要你对系统有全局理解需要你设计实验来定位问题需要在多种可能性中做排除。我有个习惯性的断言如果一个开发者在 AI 能流畅生成代码的今天还觉得自己没有竞争力那他最应该练的其实就是调试。因为调试是唯一一个 AI 帮你做完 90%剩下的 10% 反而更难的环节——它给出了可能出错的位置你需要判断真正出错的位置。怎么练调试我的建议是别满足于把 bug 修好每次都追问三层这个 bug 为什么会产生、我为什么之前没发现它、我要加什么机制让同类 bug 在将来更容易暴露。这样练下来你会逐渐从遇到 bug 就慌变成遇到 bug 就兴奋——因为你又能学到一个系统里隐藏的规律。4.2 架构能力和代码审查从自己写到判断别人写的AI 时代你每天要看的代码里可能有七八成不是人写的而是 AI 生成的。这时候你的代码审查能力变得空前重要。我参与过的项目里有一个比较典型的案例团队引入 AI 辅助开发后交付速度确实快了但线上事故率不降反升。复盘下来问题出在所有人都在信任AI 生成的代码没有人真正去审查它。后来我们定了一条铁律凡是 AI 生成的关键逻辑涉及金额、权限、并发、数据一致性必须由至少一个人工工程师逐行审查并在代码里留下注释说明为什么这段逻辑是对的。这个要求听起来简单做起来很难。因为要说明为什么对你必须真正理解业务背景和系统约束。而不少开发者习惯了 AI 给什么用什么连为什么对都说不出来。所以我说未来软件工程师的核心竞争力是审查和判断的能力——判断一段代码该不该上线判断一段代码是不是藏着风险。这种能力只能靠大量的实践复盘来练没有任何捷径。4.3 代码量不是在贬值而是你的价值权重在转移有些老开发者担心AI 写代码比我快我的经验是不是没用了。我觉得这个问题问反了。你的经验价值从来不在你敲键盘的速度而在于你能预判 AI 不知道的坑你能设计出 AI 想不出的方案你能在系统崩溃时稳住局面。举个例子。我的一位同事写代码速度中等偏下但他有一个绝活他能在一段 AI 生成的代码上线前凭经验预判出这个方案在高峰期可能撑不住需要加缓存降级策略。这种经验AI 给不了新人也给不了是他靠多年的线上事故喂出来的。这种能力会越来越值钱因为它稀缺。所以别被AI 替代程序员的焦虑带走。与其焦虑不如把你过去积累的那些说不出但很有用的实战经验整理成你自己的判断清单。这样一来AI 是你的超级助手而不是你的竞争对手。5. AI 时代学习的边界哪些事必须自己动手做这一节我想聊聊一个容易被忽略的问题AI 时代学习软件开发哪些环节是不能外包给 AI的这关乎你是不是真的在成长。5.1 保留手写代码的最低限度我认识不少新人现在写代码的方式是让 AI 生成然后自己改改跑通就完事。这样学三个月看起来什么功能都会做但一旦失去 AI 的帮助他们连一个最简单的页面都写不出来。这不是危言耸听。代码能力跟肌肉记忆一样需要持续的负重训练才能维持。我自己的做法是每周找个周末关掉 AI 工具只靠编辑器和文档从零手写一个小功能。可以是一个工具脚本可以是一个小页面甚至可以是某个算法题的暴力解法。重点在于让大脑保持从思路到语法的完整通路。这个习惯看起来有点复古但它是保持开发者基本功的底线。AI 是你的外挂但不能让你的本体退化。5.2 解决问题的能力不能交给 AI说实话AI 最擅长的是回答已知的问题。但真实开发里大量问题是第一次遇到、连怎么提问都不知道的。这种模糊的卡住感只能靠人自己扛。我还记得有一次排查一个内存泄漏问题前后花了两天。期间我也用 AI 分析了 heap dump它给了我很多信息但那些信息零零散散无法直接指向根因。最后是凭我对业务逻辑的熟悉手动梳理了对象引用链才发现是一个事件监听器忘记注销导致的。这个过程如果全交给 AI你永远学不会怎么从一团乱麻里理出头绪。因为这种能力非常依赖上下文而上下文就是你作为人类对系统的整体理解。所以遇到难题时先别急着丢给 AI先亲手处理一遍处理完再去跟 AI 印证、补充。这种先自己挣扎的过程才是学习最扎实的部分。5.3 定期做输出式复盘最后分享一个我坚持了两年的习惯每个月选一个本周做过的任务用文字把它的完整过程写下来——需求是什么、我最初怎么想、遇到了什么坑、AI 在其中起了什么作用、我最后怎么解决的。写这个过程的意义不在于总结而在于逼你发现自己思路的断层。很多时候你觉得自己会了一落笔才发现这里当时为什么这么改其实我也说不清。发现说不清的地方就是下一次学习的起点。这也是我会建议每个开发者尝试的不要只做知识的消费者也要做知识的生产者。哪怕你只是把你的排查过程发在团队文档里、发给新同事看对你自己的帮助都比默默学大得多。因为教是最好的学而 AI 时代恰恰是把教的门槛降到最低的年代——你随时可以让 AI 当你的学生向它解释你刚搞懂的一个机制。我自己的体会是AI 时代学习软件开发最忌讳的是什么都让 AI 干自己只看结果。真正有效的方式是把 AI 当成一个可以随时对话的资深同事它帮你生成候选方案你负责审题和判断它帮你提速你负责兜底和复盘。方向对了路径清晰了剩下的就是一天天积累。这条路没有捷径但它也没有你想象的那么远。 
长河君 · 2026/10/22 9:36:45 · 阅读 1.2k AI时代软件开发学习指南：从写代码到练判断力
这两年我听到最多的一句话就是AI 都能写代码了我们学软件开发还有什么意义问这个问题的人里有刚入行的新人也有写了五六年业务代码的老手。我自己的答案是AI 时代的软件开发学习恰恰比以往任何时候都更值得投入只是学习的方向、方法和判断标准彻底变了。以前学开发核心是从无到有地构建——你要记住语法、背下框架用法、手撸算法、处理各种边界条件。现在这些事AI 几乎都能做得比人快。但有个东西 AI 暂时替代不了那就是判断判断一段代码该不该这么写判断一个需求背后真正的痛点是什么判断 AI 给出的方案在真实场景里会不会翻车。这些判断力的来源就是你持续学习的成果。所以这篇文章我不打算给你列一份必学清单而是想聊聊 AI 时代学习软件开发这件事本身该学什么、为什么学、怎么学才能真的产生竞争力。下面这五块内容是我自己这两年实践下来最有感触的部分也是我带过的新人、同事踩过坑之后总结出来的经验。1. 学习的重心从怎么能写出来变成凭什么这么写老一代开发者包括我的学习模式很大程度上是以写出来为目标的。拿到一个需求先想用什么框架、起什么项目结构、调哪个 API代码能跑通就算成功一半。这种模式在 AI 时代被彻底解构了——因为这些事你只要描述清楚AI 能在几秒内给你一版能跑的代码。但问题也出在这里。AI 给出的是一个可能正确的方案而你需要判断的是这是否是当前场景下最合适的方案。1.1 你学的不再是 API而是 API 背后的设计逻辑举个例子。以前学一个新框架大家会去背它的生命周期方法、配置项、常用注解。在 AI 时代这些细节你随时可以问 AI而且它答得比记忆更全。真正需要花时间去研究的是这个框架为什么要这样设计生命周期它的数据流为什么是单向的它对异常处理的态度是什么这些问题的答案决定了你在真实项目里遇到诡异问题时是能顺着设计逻辑推断出问题可能出在哪一层还是只能病急乱投医地反复改代码碰运气。我见过一个真实案例某团队用 AI 生成了一段缓存更新的代码跑起来测试也过了但上线后偶发数据不一致。新同事盯着代码看了很久没发现问题因为从单条代码来看逻辑没问题。后来是另一位老手顺着缓存为什么需要失效、失效的时机应该在哪、并发情况下会有几种执行顺序这几个问题一推才发现 AI 生成的版本漏掉了并发场景下的竞态条件。这个案例说明什么说明知识的具体内容会贬值但知识的结构和判断依据不会。框架会过时AI 会帮你写代码但你对一套系统如何被设计出来、为什么被设计成这样的理解才是你能发现 AI 漏洞的根本原因。1.2 需求分析能力成为最核心的杠杆以前需求分析是产品经理和资深架构师的事初级开发基本是拿到需求就开写。但 AI 时代出现了一个新情况需求描述得越模糊AI 给你的代码就越像空中楼阁。你问 AI帮我写一个用户登录功能它能给你一版标准的账号密码登录但你追问我们这是扫码登录而且要考虑同一账号多端互踢、弱网环境下的重试策略、以及风控拦截之后用户看到什么提示AI 才能给出贴近真实场景的代码。这种把模糊需求拆成清晰边界条件的能力就是需求分析能力。它不是产品经理专属的而是每一个写代码的人都必须练的。我自己训练这种能力的方法是拿到任何需求先逼自己写出这个功能必须具备的五个边界条件三种可能失败的情况两类受影响的用户角色写完再让 AI 生成代码。你会发现你对需求的理解越清晰AI 生成的代码质量就越高。反过来你连需求都说不清楚时AI 给你的东西一定也充满臆测。所以 AI 时代学软件开发学的是把心里的模糊想法变成精确描述的能力。这个能力不跟着 AI 走只跟着你的思维走。2. 底层知识没有过时只是它服务的对象变了很多初学者问过我一个很实际的问题现在还需要学数据结构、操作系统、网络这些底层知识吗反正写业务代码都用不上。我懂这个困惑——你用 Python 写一个 CRUD 接口确实用不上红黑树也用不上操作系统的页面置换算法。看起来底层知识跟日常开发是脱节的。但在 AI 时代底层知识的价值从帮你从零实现变成了帮你验证和纠偏。2.1 算法和数据结构AI 出错时你才有底气AI 生成代码最常见的错误不是语法错误而是在复杂度敏感的场景下选错了数据结构或算法。它可能给你一段功能上完全正确、但数据量一上来就卡死的代码。我自己就遇到过让 AI 写一个频繁判断一批用户 ID 是否在某个大列表中的功能它第一版用的是列表遍历。功能没问题测试数据量小时也很快。但当我追问这个 list 可能有十万条每秒钟要判断几百次你确定用 in 操作符合适吗它立刻改成了用集合。为什么它能改因为 AI 知道你问到了复杂度。但如果你自己不懂复杂度你根本问不出这个问题也就发现不了隐患。所以学数据结构和算法不是为了在面试时手写快排而是为了建立一种对性能隐患的嗅觉。AI 帮你写代码你负责给代码做体检。没有底层知识你连体检项目都不知道有哪些。2.2 操作系统和网络排查问题的导航地图我见过太多人遇到线上问题时第一反应是直接把报错信息扔给 AI让它分析。这没错AI 确实能帮你定位很多问题。但你能从 AI 的回答里得到多少帮助取决于你能不能理解它说的那些概念。比如 AI 告诉你这个错误可能是 TCP 连接池耗尽导致的你如果不知道什么是连接池、不知道 TCP 连接的四次挥手过程、不知道为什么连接会处于 TIME_WAIT 状态那你就只能再问一句那怎么办然后瞎子摸象一样去改配置。但如果你懂网络基础你就会接着问当前连接池大小是多少服务端和客户端分别是什么角色TIME_WAIT 主要出现在哪一端这一串问题问下来AI 才能给你精确的解决方案。底层知识在 AI 时代更像是你在黑屋子里走路时手里那根拐杖。AI 能告诉你屋子里大概有什么但你没拐杖还是寸步难行。2.3 一个实操案例AI 生成的代码为什么会错说个我最近踩过的坑。我让 AI 写一段定时任务的代码内容是每小时从外部接口拉取数据并更新数据库。AI 给的版本看起来完美有重试、有日志、有异常捕获。但我在 review 的时候发现一个隐蔽问题它给的重试逻辑是出错后等 5 秒再重试但外部接口的限流策略是每分钟最多 30 次。如果连续出错程序会一直卡在重试循环里把自己这边的请求额度耗尽然后把外部接口彻底打挂。这个问题怎么发现的不是靠 AI 帮我 review 的——AI 在生成代码时不会主动考虑另一个系统外部接口的约束条件除非我明确告诉它。我能发现这个问题靠的是对分布式系统里限流、重试、熔断这套思路的理解。这就是底层知识或者说系统设计知识在 AI 时代的实际价值在 AI 想不到的地方你能替它想到。3. 最高效的学习路径逆向式学习让 AI 当你的导师而不是答案机器传统的学习路径是正向的先学理论再做练习最后做项目。这条路在 AI 时代显得太慢了也不符合现在信息获取的方式。我这两年实践下来最有效的是逆向式学习——先让 AI 给你一个结果然后往回追问为什么。3.1 逆向式学习的四步循环这个循环大概是这样的抛出任务把一个真实的、有细节的问题丢给 AI让它给出完整方案或代码。逐行追问对 AI 给出的结果里每一个你不理解的细节逼问为什么这里要这样写如果换一种写法会怎样这里的边界情况是什么。这步是核心不能只停留在看懂。主动制造变化修改 AI 给你的方案中的某个条件比如如果并发量翻十倍会怎样如果数据源换成消息队列呢观察 AI 怎么调整方案。提炼沉淀把这次对话里你学到的东西提炼成几条自己的判断准则记录下来。下次遇到类似问题时优先用自己提炼的准则去判断。这套方法的精髓在于你不是在向 AI 要答案你是在用一个高仿真模拟器练习自己的判断力。AI 给你一个结果你的任务不是接受它而是审问它。每一次审问都是一次真实的学习。3.2 提问方式决定了你的学习深度很多人觉得用 AI 学习效果不好原因在于提问方式。你问帮我写一个文件上传功能AI 给你一段代码你复制粘贴跑通觉得自己学会了。其实你什么都没学会——你只是把问题外包了。真正有效的提问方式是带限定条件的帮我写一个文件上传功能要求支持大文件分片、断点续传、服务端校验文件类型和大小、同时要防止重复提交。顺便解释一下你为什么要用这些技术方案。你看前半部分是任务后半部分是要求 AI 解释设计理由。当 AI 被迫解释自己的设计理由时它会把它内部隐藏的决策链条摊开在你面前这才是最有学习价值的部分。你看到的不是最终代码而是这代码为什么长这样。3.3 用 AI 模拟面试和 code review逆向式学习还有一个高阶玩法让 AI 扮演一个严格的面试官或者 code reviewer对你自己写的代码或 AI 生成的代码进行提问。比如我让 AI 生成一段代码后会追加一句请你假设你是一个资深架构师正在审查一个初级开发提交的代码从可维护性、异常处理、性能、安全性四个维度给我挑毛病。每个毛病都要给出具体的修改建议和理由。然后我会根据它挑的毛病逐条去查资料、理解原理再回来跟它讨论。这种被挑战的感觉比单纯刷题、看教程更能逼出深度理解。因为你被迫面对自己的盲区——那些你平时根本不会注意的差不多就行的地方全被 AI 毫不留情地指出来了。4. 工程能力的分量比代码本身更重聊完了学什么和怎么学还得聊一个更现实的话题在 AI 时代什么样的软件开发能力最值钱我的观察是写代码的能力正在快速贬值而工程能力正在快速升值。以前你写代码快是很大的优势现在 AI 写代码更快你的优势必须转移到把代码放到真实环境里还能稳定运行这件事上。4.1 调试能力AI 时代的硬通货AI 生成的代码不是不会出 bug恰恰相反它出的 bug 往往更隐蔽——因为单看语法和逻辑都没问题问题出在它没有真实环境的反馈。而调试这件事恰恰是最依赖人的能力的环节它需要你对系统有全局理解需要你设计实验来定位问题需要在多种可能性中做排除。我有个习惯性的断言如果一个开发者在 AI 能流畅生成代码的今天还觉得自己没有竞争力那他最应该练的其实就是调试。因为调试是唯一一个 AI 帮你做完 90%剩下的 10% 反而更难的环节——它给出了可能出错的位置你需要判断真正出错的位置。怎么练调试我的建议是别满足于把 bug 修好每次都追问三层这个 bug 为什么会产生、我为什么之前没发现它、我要加什么机制让同类 bug 在将来更容易暴露。这样练下来你会逐渐从遇到 bug 就慌变成遇到 bug 就兴奋——因为你又能学到一个系统里隐藏的规律。4.2 架构能力和代码审查从自己写到判断别人写的AI 时代你每天要看的代码里可能有七八成不是人写的而是 AI 生成的。这时候你的代码审查能力变得空前重要。我参与过的项目里有一个比较典型的案例团队引入 AI 辅助开发后交付速度确实快了但线上事故率不降反升。复盘下来问题出在所有人都在信任AI 生成的代码没有人真正去审查它。后来我们定了一条铁律凡是 AI 生成的关键逻辑涉及金额、权限、并发、数据一致性必须由至少一个人工工程师逐行审查并在代码里留下注释说明为什么这段逻辑是对的。这个要求听起来简单做起来很难。因为要说明为什么对你必须真正理解业务背景和系统约束。而不少开发者习惯了 AI 给什么用什么连为什么对都说不出来。所以我说未来软件工程师的核心竞争力是审查和判断的能力——判断一段代码该不该上线判断一段代码是不是藏着风险。这种能力只能靠大量的实践复盘来练没有任何捷径。4.3 代码量不是在贬值而是你的价值权重在转移有些老开发者担心AI 写代码比我快我的经验是不是没用了。我觉得这个问题问反了。你的经验价值从来不在你敲键盘的速度而在于你能预判 AI 不知道的坑你能设计出 AI 想不出的方案你能在系统崩溃时稳住局面。举个例子。我的一位同事写代码速度中等偏下但他有一个绝活他能在一段 AI 生成的代码上线前凭经验预判出这个方案在高峰期可能撑不住需要加缓存降级策略。这种经验AI 给不了新人也给不了是他靠多年的线上事故喂出来的。这种能力会越来越值钱因为它稀缺。所以别被AI 替代程序员的焦虑带走。与其焦虑不如把你过去积累的那些说不出但很有用的实战经验整理成你自己的判断清单。这样一来AI 是你的超级助手而不是你的竞争对手。5. AI 时代学习的边界哪些事必须自己动手做这一节我想聊聊一个容易被忽略的问题AI 时代学习软件开发哪些环节是不能外包给 AI的这关乎你是不是真的在成长。5.1 保留手写代码的最低限度我认识不少新人现在写代码的方式是让 AI 生成然后自己改改跑通就完事。这样学三个月看起来什么功能都会做但一旦失去 AI 的帮助他们连一个最简单的页面都写不出来。这不是危言耸听。代码能力跟肌肉记忆一样需要持续的负重训练才能维持。我自己的做法是每周找个周末关掉 AI 工具只靠编辑器和文档从零手写一个小功能。可以是一个工具脚本可以是一个小页面甚至可以是某个算法题的暴力解法。重点在于让大脑保持从思路到语法的完整通路。这个习惯看起来有点复古但它是保持开发者基本功的底线。AI 是你的外挂但不能让你的本体退化。5.2 解决问题的能力不能交给 AI说实话AI 最擅长的是回答已知的问题。但真实开发里大量问题是第一次遇到、连怎么提问都不知道的。这种模糊的卡住感只能靠人自己扛。我还记得有一次排查一个内存泄漏问题前后花了两天。期间我也用 AI 分析了 heap dump它给了我很多信息但那些信息零零散散无法直接指向根因。最后是凭我对业务逻辑的熟悉手动梳理了对象引用链才发现是一个事件监听器忘记注销导致的。这个过程如果全交给 AI你永远学不会怎么从一团乱麻里理出头绪。因为这种能力非常依赖上下文而上下文就是你作为人类对系统的整体理解。所以遇到难题时先别急着丢给 AI先亲手处理一遍处理完再去跟 AI 印证、补充。这种先自己挣扎的过程才是学习最扎实的部分。5.3 定期做输出式复盘最后分享一个我坚持了两年的习惯每个月选一个本周做过的任务用文字把它的完整过程写下来——需求是什么、我最初怎么想、遇到了什么坑、AI 在其中起了什么作用、我最后怎么解决的。写这个过程的意义不在于总结而在于逼你发现自己思路的断层。很多时候你觉得自己会了一落笔才发现这里当时为什么这么改其实我也说不清。发现说不清的地方就是下一次学习的起点。这也是我会建议每个开发者尝试的不要只做知识的消费者也要做知识的生产者。哪怕你只是把你的排查过程发在团队文档里、发给新同事看对你自己的帮助都比默默学大得多。因为教是最好的学而 AI 时代恰恰是把教的门槛降到最低的年代——你随时可以让 AI 当你的学生向它解释你刚搞懂的一个机制。我自己的体会是AI 时代学习软件开发最忌讳的是什么都让 AI 干自己只看结果。真正有效的方式是把 AI 当成一个可以随时对话的资深同事它帮你生成候选方案你负责审题和判断它帮你提速你负责兜底和复盘。方向对了路径清晰了剩下的就是一天天积累。这条路没有捷径但它也没有你想象的那么远。