最近在好几个技术社群里看到同一个话题被反复吵起来Coding Agent 都能自动写代码了软件工程基础是不是该靠边站了刚好吴恩达又把 AI 工程技能图更新了一版把 Coding Agent 相关能力正式放了进去这话题又被推到了风口浪尖。很多人一看技能图里塞满了 Agent、上下文工程、AI 评测这类新词第一反应就是“完了我学的那些基础课没用了”。我的看法恰恰相反。Coding Agent 越普及软件工程基础不是不重要了而是换了一种方式在起作用甚至比之前更能决定你的天花板。这篇就把吴恩达新技能图的变化、这场争议背后的真实逻辑以及我在实际项目里用 AI 编程的观察一起拆开聊给正在用或准备用 AI 写代码的开发者一个参考坐标系。1. 吴恩达这张新技能图到底改了什么1.1 从“会写代码”到“会指挥代码生产”我没有拿到技能图逐条原件不过从他公开的分享和社区讨论来看这次更新的核心变化不是把软件工程基础删掉了而是把 AI 工程相关的技能从边缘挪到了中心位置。其中被反复强调的几块集中在 Coding Agent 使用、上下文工程、AI 评测与可观测性、安全与防护以及 Agent 工作流编排。翻译成大白话就是技能图的重心从“工程师自己动手写每一行代码”转到了“工程师如何高效地定义任务、组织上下文、审核 AI 产出、建立验证闭环”。这个变化背后的驱动其实很直接。前几年的 Copilot 模式是“人写代码AI 补全”核心能力还是落在人的手指上到了 Coding Agent 模式模型可以自己读仓库、多文件改代码、跑测试、修 bug核心能力变成了“你能不能把一个模糊的想法拆成 Agent 能执行的任务序列”。所以新技能图里那些看起来新鲜的名词本质上都在回答一个问题怎么让 AI 高效、安全、可控地加入到软件生产流程里。这已经不是锦上添花的技巧而是 Agent 时代的必修课。1.2 技能图里没有明说的“隐藏前提”有一点容易被忽略技能图里新增的所有能力几乎都建立在软件工程基础的底盘之上。上下文工程再厉害你也得先读懂代码库的结构才能提炼出有意义的上下文Agent 工作流编排再熟练你也得知道模块怎么划分、依赖怎么管理才能把任务拆成 Agent 能理解的语言。我做了个对比你们感受一下这个变化能力维度传统软件工程时代Coding Agent 时代核心产出方式手写代码CTRLS 交付定义任务审查 AI 产出集成落地瓶颈所在打字速度、语法熟练度、API 记忆量需求拆解能力、上下文组织能力、判断力代码评审关注人写的逻辑漏洞关注 AI 生成的大量代码的正确性、边界与副作用测试与调试手写单测 断点调试设计验证用例让 Agent 自测人工兜底疑难杂症最容易翻车的地方语法错误、逻辑疏漏AI 一本正经地“幻觉式”改代码你看底层能力没有消失只是换了一个使用方式。技能图看着全是新词底子里还是在考你的软件工程设计能力——能画系统边界、能拆模块、能写清楚验收标准的人用 Agent 的产出质量就是比只会甩一句“帮我把这个功能做了”的人高出一个量级。2. 先把争议说透Agent 写代码基础到底被消解在哪一环2.1 “基础无用论”的三段论错在哪主张基础不重要的人通常会这样推演既然 Agent 能写代码 → 那么编码能力不再重要 → 所以数据结构、操作系统、网络这些基础课都可以不学。这个推理有迷惑性是因为第一句话部分成立后两句却偷换了概念。Agent 确实能写代码但它写的是“代码文本”不是“软件交付”。代码文本只是软件工程项目里最表层的东西就像文字处理器能生成文档但不代表你就不需要懂语法和逻辑了。被消解的环节其实很窄。打字速度、常见库的 API 拼写、样板代码的重复劳动这些确实被 Agent 大大弱化了。以前写一个 RESTful CRUD 接口你可能要花十几分钟敲代码现在 Agent 几秒钟给你生成一份还能跑的版本。这部分基础能力确实不需要再花大量时间死磕。2.2 被放大的另一半判断力、系统观和错误排查但同一枚硬币的反面是对判断力的要求成倍提高了。Agent 生成代码太快错误也被等比例放大。以前你一天写两百行代码出错范围就那两百行现在 Agent 一小时产出两千行你如果不能在更短的时间里发现、定位、修正问题那这不是提效是给自己埋雷。我自己的经验是用 Agent 重构一个老模块时它非常流畅地给我把 A 文件里的函数调用改成了新版写法语法完全正确测试也跑过了但它同时——没有任何提示地——把另一个模块里依赖旧行为的隐式调用给突破了。这类问题只有你对系统的模块边界、依赖关系、历史包袱有足够理解才能意识到“这里好像不对”。这就是软件工程基础在起作用。所以我的结论很明确Agent 消解的不是“基础”而是“不需要动脑的机械性编码”。恰恰因为它把机械部分全包了剩下的工作全部集中在最依赖基础的心智活动上——做决策、下判断、兜底排错。3. 软件工程基础的新用途当 AI 成为“初级开发者”你需要当“高级评审者”3.1 需求拆解与上下文投喂一句话需求背后的全局设计现在很多人觉得用 Agent 很省事直接甩一句“给这个项目加一个支付功能”。Agent 效果好不好全看运气。因为这句话在你的脑子里是“要对接现有订单系统、要考虑退款、要处理回调幂等、要加权限控制”而在 Agent 那边只是一句没有任何约束的任务描述。给 Agent 喂上下文本质上就是需求分析和系统设计的简化版。你要把这件事的背景、约束、边界、验收标准讲清楚它才能生成可落地的代码。比如同样一个需求我拆成下面这样再丢给 Agent产出质量就完全不一样项目技术栈Spring Boot 3 MyBatis Plus已有订单表结构见order.sql功能范围新增支付单创建接口对接第三方支付 SDK回调幂等用payment_id做唯一键不做的事不做退款流程、不做支付对账页面验收标准创建接口返回支付链接回调接口在重复请求时返回已处理结果不能报错你会发现这些内容每一条都来自软件工程基础模块划分、接口设计、幂等机制、边界控制。Agent 只是把你拆好的思路变成了代码拆思路这件事它替代不了你。3.2 代码评审的本质变化从 review 人的代码到 review AI 的代码传统的代码评审重点放在“这段代码是否符合设计意图”“有没有逻辑漏洞”“风格是否一致”。到了 Agent 时代评审的密度和难度同时上升了因为 AI 生成代码的量级远超人手而且它的错误往往是“局部正确、全局错误”。举个我实际遇到的情况。我让 Agent 给一个内部数据看板添加导出 Excel 的功能它很快就实现了一个可用的版本查数据库、组装数据、写入 Excel 文件返回下载。代码没问题性能在测试环境也正常。但上线前做评审时我发现它把查询写在一个大循环里每导出一千行就查一次数据库数据量一旦增长这个功能会把数据库连接池打满。这种 O(n) 次查询的问题说到底是算法和数据结构的基础直觉。Agent 不会觉得这个方案有什么问题因为它只看到了“这个函数能跑”看不到业务增长后的瓶颈。而你作为评审者必须一眼看出问题出在哪。这不是什么高深的玄学就是你当年学时间复杂度和系统设计时积累的判断力现在变成了给 AI 把关的尺子。3.3 测试与调试AI 代码的边界和坑靠基础兜底另一个被低估的基础技能是测试设计能力。Agent 能写代码但它对自己的代码没有“怀疑精神”。它生成的测试用例通常都是顺着实现逻辑写的——实现对了测试就绿实现错了测试照样绿。你需要自己设计出那些“刁钻”的边界用例才能真正验证代码是否可靠。比如空指针、超时重试、并发冲突、异常路径这些恰恰是 Agent 最容易忽略的地方。我在实践里的习惯是让 Agent 写完功能代码后再丢给它一套我写的边界条件清单让它补充测试。这比自己硬写省时间但前提是你能列出那份清单——这份能力来自你长期 debug、踩坑、读源码积累下来的经验AI 给你替代不了。4. 实操视角我在真实项目里用 Coding Agent 时哪些基础能力反复被用到4.1 git 冲突、依赖环境、构建链路这些“脏活”逃不掉很多人以为 Agent 时代意味着环境问题彻底消失了实际上恰恰相反。Agent 不会帮你解决 git 冲突不会帮你排查依赖版本地狱更不会理解“为什么你的 Docker 镜像在本地能构建、在 CI 上就崩了”。这些问题依然需要你自己动手。我记得有一次Agent 在一个 PR 里同时修改了十几个文件和同事的分支产生了大量冲突。Agent 在那次任务里什么忙都帮不上因为冲突的本质是两边的代码意图不同机器没有能力替你判断该留谁的。最终是我花了半小时把两边的改动逻辑理清楚手工合掉的。这就是最朴素的代码管理基础平时觉得没什么关键时刻卡你一整晚。4.2 系统设计与模块边界让 Agent 不跑偏的前提项目稍微复杂一点通信架构、数据模型、服务拆分这些东西就变得极其关键。Agent 在单文件层面的能力很强但一旦涉及跨模块改动它经常会出现“拆东墙补西墙”的操作。你想让它改 A 服务的接口它会顺手把 B 服务里调用 A 的地方也改了而且自以为很合理。这背后的问题还是因为 Agent 没有真正的全局视野。你要做的就是在任务描述里把边界划死这个改动只允许发生在哪个目录、不允许触碰哪些文件、接口签名保持向后兼容。能做到这一点的人平时一定有意识地思考过模块边界和服务依赖这不是临时抱佛脚就能补上的。4.3 写给“只会用 Agent”的人常见的四个翻车现场我把这两年观察到的以及自己也踩过的坑汇总一下给习惯直接用 Agent 的同学提个醒翻车一依赖幻觉。Agent 在代码里 import 了一个项目里根本不存在的库还写了一整套使用逻辑。如果你不会看依赖配置很容易被带偏。翻车二改 A 坏 B。Agent 为了满足新需求悄悄改了公共工具类导致其他模块的既有行为发生变化。没有全局测试覆盖的情况下很难察觉。翻车三性能塌方。Agent 给出的方案在功能上完全正确但算法效率极差。比如用双层循环处理大数据量集合或者把查询塞进循环里。翻车四安全性薄弱。Agent 生成的代码里SQL 拼接、缺少鉴权、敏感信息写死这些低级但致命的问题出现概率不低。每一个翻车现场对照的都是某类基础能力依赖管理知识、系统设计意识、算法与数据结构直觉、安全编码规范。它们不是某个课程单独教你的而是在软件工程的长期实践中沉淀出来的。5. 给不同阶段从业者的调整路线基础不必重学但要换一种练法5.1 学生和转行者用 Agent 当镜子反向暴露基础短板如果你刚开始学编程我建议别被“用 Agent 写项目”的潮流卷走。你可以用 Agent但要用一种特别的方式让它把代码写出来然后你逐行读、逐行问“为什么”。它用了什么数据结构为什么要这样设计接口这个异常处理为什么放在这里这个方法本质上是把 Agent 当成一个永远有耐心、永远不嫌你烦的“参考答案”。但前提是你得具备追问的能力。如果你连它用了 HashMap 还是 TreeMap 都看不出来你就不知道这段代码在不同场景下的表现差异。这时候暴露的短板就是你该回头补的基础课。数据结构、操作系统、计算机网络、数据库原理这些依然值得认真学它们是你在 Agent 时代做判断的底层燃料。5.2 有经验的工程师把手写能力转成判断能力别被“手生”吓到工作多年的人可能担心自己太久不手写代码基本功会退化。我的看法是手写速度退化不可怕判断力退化才可怕。你把“手写排序算法”变成“一眼看出 Agent 写的排序在数据量大时会崩”这才是转型的正确方向。具体的做法是把 check code 的习惯捡起来。以前你 review 同事代码现在你 review Agent 代码强度反而提高了。每一份 Agent 生成的代码你都要从正确性、边界、副作用、性能、安全五个维度过一遍。这个过程不需要你重写一遍但需要你知道什么是对的、什么可能是错的。这种能力不会随年龄退化只会随项目越积越厚。5.3 一个适合所有人的练习组合让 Agent 反哺基础训练最后给一个我觉得性价比很高的练习方法适合不同阶段的开发者每天挑一个你业务里真实存在的小模块让 Agent 用你指定的技术栈重写一遍不要看实现先写测试用例再看它代码能不能通过你的用例。每次 Agent 给出方案后要求自己指出一个它没考虑到的边界情况再让 Agent 补上。每周挑一个 Agent 写得最“怪”的代码片段尝试用自己的话向同事解释清楚它为什么能跑、有什么隐患。这套练习不追求量大追求的是逼自己保持思考密度。你会发现一段时间以后你对 Agent 产出的敏感度会明显提升那些常见的坑还没等到上线就能被你拦下来。这种能力就是 Coding Agent 时代的软件工程基础不是写在简历上的名词而是体现在你能不能把关住 AI 的每一条产出上。我在实际项目里最大的感受是AI 写代码的潮流不仅没有让我觉得基础白学了反而让我重新意识到当年那些“没什么用”的理论课原来都是给今天做的铺垫。你曾经迷迷糊糊听过的 B 树、索引失效、缓存一致性在 Agent 帮你把 CRUD 全包了之后变成了你唯一还能创造差异价值的地方。基础没有过时它只是换了一种计分方式从考核“你会不会写”变成了考核“你会不会判断”而后者恰恰是 AI 时代最难被替代的能力。 Coding Agent时代，软件工程基础仍是核心竞争力
最近在好几个技术社群里看到同一个话题被反复吵起来Coding Agent 都能自动写代码了软件工程基础是不是该靠边站了刚好吴恩达又把 AI 工程技能图更新了一版把 Coding Agent 相关能力正式放了进去这话题又被推到了风口浪尖。很多人一看技能图里塞满了 Agent、上下文工程、AI 评测这类新词第一反应就是“完了我学的那些基础课没用了”。我的看法恰恰相反。Coding Agent 越普及软件工程基础不是不重要了而是换了一种方式在起作用甚至比之前更能决定你的天花板。这篇就把吴恩达新技能图的变化、这场争议背后的真实逻辑以及我在实际项目里用 AI 编程的观察一起拆开聊给正在用或准备用 AI 写代码的开发者一个参考坐标系。1. 吴恩达这张新技能图到底改了什么1.1 从“会写代码”到“会指挥代码生产”我没有拿到技能图逐条原件不过从他公开的分享和社区讨论来看这次更新的核心变化不是把软件工程基础删掉了而是把 AI 工程相关的技能从边缘挪到了中心位置。其中被反复强调的几块集中在 Coding Agent 使用、上下文工程、AI 评测与可观测性、安全与防护以及 Agent 工作流编排。翻译成大白话就是技能图的重心从“工程师自己动手写每一行代码”转到了“工程师如何高效地定义任务、组织上下文、审核 AI 产出、建立验证闭环”。这个变化背后的驱动其实很直接。前几年的 Copilot 模式是“人写代码AI 补全”核心能力还是落在人的手指上到了 Coding Agent 模式模型可以自己读仓库、多文件改代码、跑测试、修 bug核心能力变成了“你能不能把一个模糊的想法拆成 Agent 能执行的任务序列”。所以新技能图里那些看起来新鲜的名词本质上都在回答一个问题怎么让 AI 高效、安全、可控地加入到软件生产流程里。这已经不是锦上添花的技巧而是 Agent 时代的必修课。1.2 技能图里没有明说的“隐藏前提”有一点容易被忽略技能图里新增的所有能力几乎都建立在软件工程基础的底盘之上。上下文工程再厉害你也得先读懂代码库的结构才能提炼出有意义的上下文Agent 工作流编排再熟练你也得知道模块怎么划分、依赖怎么管理才能把任务拆成 Agent 能理解的语言。我做了个对比你们感受一下这个变化能力维度传统软件工程时代Coding Agent 时代核心产出方式手写代码CTRLS 交付定义任务审查 AI 产出集成落地瓶颈所在打字速度、语法熟练度、API 记忆量需求拆解能力、上下文组织能力、判断力代码评审关注人写的逻辑漏洞关注 AI 生成的大量代码的正确性、边界与副作用测试与调试手写单测 断点调试设计验证用例让 Agent 自测人工兜底疑难杂症最容易翻车的地方语法错误、逻辑疏漏AI 一本正经地“幻觉式”改代码你看底层能力没有消失只是换了一个使用方式。技能图看着全是新词底子里还是在考你的软件工程设计能力——能画系统边界、能拆模块、能写清楚验收标准的人用 Agent 的产出质量就是比只会甩一句“帮我把这个功能做了”的人高出一个量级。2. 先把争议说透Agent 写代码基础到底被消解在哪一环2.1 “基础无用论”的三段论错在哪主张基础不重要的人通常会这样推演既然 Agent 能写代码 → 那么编码能力不再重要 → 所以数据结构、操作系统、网络这些基础课都可以不学。这个推理有迷惑性是因为第一句话部分成立后两句却偷换了概念。Agent 确实能写代码但它写的是“代码文本”不是“软件交付”。代码文本只是软件工程项目里最表层的东西就像文字处理器能生成文档但不代表你就不需要懂语法和逻辑了。被消解的环节其实很窄。打字速度、常见库的 API 拼写、样板代码的重复劳动这些确实被 Agent 大大弱化了。以前写一个 RESTful CRUD 接口你可能要花十几分钟敲代码现在 Agent 几秒钟给你生成一份还能跑的版本。这部分基础能力确实不需要再花大量时间死磕。2.2 被放大的另一半判断力、系统观和错误排查但同一枚硬币的反面是对判断力的要求成倍提高了。Agent 生成代码太快错误也被等比例放大。以前你一天写两百行代码出错范围就那两百行现在 Agent 一小时产出两千行你如果不能在更短的时间里发现、定位、修正问题那这不是提效是给自己埋雷。我自己的经验是用 Agent 重构一个老模块时它非常流畅地给我把 A 文件里的函数调用改成了新版写法语法完全正确测试也跑过了但它同时——没有任何提示地——把另一个模块里依赖旧行为的隐式调用给突破了。这类问题只有你对系统的模块边界、依赖关系、历史包袱有足够理解才能意识到“这里好像不对”。这就是软件工程基础在起作用。所以我的结论很明确Agent 消解的不是“基础”而是“不需要动脑的机械性编码”。恰恰因为它把机械部分全包了剩下的工作全部集中在最依赖基础的心智活动上——做决策、下判断、兜底排错。3. 软件工程基础的新用途当 AI 成为“初级开发者”你需要当“高级评审者”3.1 需求拆解与上下文投喂一句话需求背后的全局设计现在很多人觉得用 Agent 很省事直接甩一句“给这个项目加一个支付功能”。Agent 效果好不好全看运气。因为这句话在你的脑子里是“要对接现有订单系统、要考虑退款、要处理回调幂等、要加权限控制”而在 Agent 那边只是一句没有任何约束的任务描述。给 Agent 喂上下文本质上就是需求分析和系统设计的简化版。你要把这件事的背景、约束、边界、验收标准讲清楚它才能生成可落地的代码。比如同样一个需求我拆成下面这样再丢给 Agent产出质量就完全不一样项目技术栈Spring Boot 3 MyBatis Plus已有订单表结构见order.sql功能范围新增支付单创建接口对接第三方支付 SDK回调幂等用payment_id做唯一键不做的事不做退款流程、不做支付对账页面验收标准创建接口返回支付链接回调接口在重复请求时返回已处理结果不能报错你会发现这些内容每一条都来自软件工程基础模块划分、接口设计、幂等机制、边界控制。Agent 只是把你拆好的思路变成了代码拆思路这件事它替代不了你。3.2 代码评审的本质变化从 review 人的代码到 review AI 的代码传统的代码评审重点放在“这段代码是否符合设计意图”“有没有逻辑漏洞”“风格是否一致”。到了 Agent 时代评审的密度和难度同时上升了因为 AI 生成代码的量级远超人手而且它的错误往往是“局部正确、全局错误”。举个我实际遇到的情况。我让 Agent 给一个内部数据看板添加导出 Excel 的功能它很快就实现了一个可用的版本查数据库、组装数据、写入 Excel 文件返回下载。代码没问题性能在测试环境也正常。但上线前做评审时我发现它把查询写在一个大循环里每导出一千行就查一次数据库数据量一旦增长这个功能会把数据库连接池打满。这种 O(n) 次查询的问题说到底是算法和数据结构的基础直觉。Agent 不会觉得这个方案有什么问题因为它只看到了“这个函数能跑”看不到业务增长后的瓶颈。而你作为评审者必须一眼看出问题出在哪。这不是什么高深的玄学就是你当年学时间复杂度和系统设计时积累的判断力现在变成了给 AI 把关的尺子。3.3 测试与调试AI 代码的边界和坑靠基础兜底另一个被低估的基础技能是测试设计能力。Agent 能写代码但它对自己的代码没有“怀疑精神”。它生成的测试用例通常都是顺着实现逻辑写的——实现对了测试就绿实现错了测试照样绿。你需要自己设计出那些“刁钻”的边界用例才能真正验证代码是否可靠。比如空指针、超时重试、并发冲突、异常路径这些恰恰是 Agent 最容易忽略的地方。我在实践里的习惯是让 Agent 写完功能代码后再丢给它一套我写的边界条件清单让它补充测试。这比自己硬写省时间但前提是你能列出那份清单——这份能力来自你长期 debug、踩坑、读源码积累下来的经验AI 给你替代不了。4. 实操视角我在真实项目里用 Coding Agent 时哪些基础能力反复被用到4.1 git 冲突、依赖环境、构建链路这些“脏活”逃不掉很多人以为 Agent 时代意味着环境问题彻底消失了实际上恰恰相反。Agent 不会帮你解决 git 冲突不会帮你排查依赖版本地狱更不会理解“为什么你的 Docker 镜像在本地能构建、在 CI 上就崩了”。这些问题依然需要你自己动手。我记得有一次Agent 在一个 PR 里同时修改了十几个文件和同事的分支产生了大量冲突。Agent 在那次任务里什么忙都帮不上因为冲突的本质是两边的代码意图不同机器没有能力替你判断该留谁的。最终是我花了半小时把两边的改动逻辑理清楚手工合掉的。这就是最朴素的代码管理基础平时觉得没什么关键时刻卡你一整晚。4.2 系统设计与模块边界让 Agent 不跑偏的前提项目稍微复杂一点通信架构、数据模型、服务拆分这些东西就变得极其关键。Agent 在单文件层面的能力很强但一旦涉及跨模块改动它经常会出现“拆东墙补西墙”的操作。你想让它改 A 服务的接口它会顺手把 B 服务里调用 A 的地方也改了而且自以为很合理。这背后的问题还是因为 Agent 没有真正的全局视野。你要做的就是在任务描述里把边界划死这个改动只允许发生在哪个目录、不允许触碰哪些文件、接口签名保持向后兼容。能做到这一点的人平时一定有意识地思考过模块边界和服务依赖这不是临时抱佛脚就能补上的。4.3 写给“只会用 Agent”的人常见的四个翻车现场我把这两年观察到的以及自己也踩过的坑汇总一下给习惯直接用 Agent 的同学提个醒翻车一依赖幻觉。Agent 在代码里 import 了一个项目里根本不存在的库还写了一整套使用逻辑。如果你不会看依赖配置很容易被带偏。翻车二改 A 坏 B。Agent 为了满足新需求悄悄改了公共工具类导致其他模块的既有行为发生变化。没有全局测试覆盖的情况下很难察觉。翻车三性能塌方。Agent 给出的方案在功能上完全正确但算法效率极差。比如用双层循环处理大数据量集合或者把查询塞进循环里。翻车四安全性薄弱。Agent 生成的代码里SQL 拼接、缺少鉴权、敏感信息写死这些低级但致命的问题出现概率不低。每一个翻车现场对照的都是某类基础能力依赖管理知识、系统设计意识、算法与数据结构直觉、安全编码规范。它们不是某个课程单独教你的而是在软件工程的长期实践中沉淀出来的。5. 给不同阶段从业者的调整路线基础不必重学但要换一种练法5.1 学生和转行者用 Agent 当镜子反向暴露基础短板如果你刚开始学编程我建议别被“用 Agent 写项目”的潮流卷走。你可以用 Agent但要用一种特别的方式让它把代码写出来然后你逐行读、逐行问“为什么”。它用了什么数据结构为什么要这样设计接口这个异常处理为什么放在这里这个方法本质上是把 Agent 当成一个永远有耐心、永远不嫌你烦的“参考答案”。但前提是你得具备追问的能力。如果你连它用了 HashMap 还是 TreeMap 都看不出来你就不知道这段代码在不同场景下的表现差异。这时候暴露的短板就是你该回头补的基础课。数据结构、操作系统、计算机网络、数据库原理这些依然值得认真学它们是你在 Agent 时代做判断的底层燃料。5.2 有经验的工程师把手写能力转成判断能力别被“手生”吓到工作多年的人可能担心自己太久不手写代码基本功会退化。我的看法是手写速度退化不可怕判断力退化才可怕。你把“手写排序算法”变成“一眼看出 Agent 写的排序在数据量大时会崩”这才是转型的正确方向。具体的做法是把 check code 的习惯捡起来。以前你 review 同事代码现在你 review Agent 代码强度反而提高了。每一份 Agent 生成的代码你都要从正确性、边界、副作用、性能、安全五个维度过一遍。这个过程不需要你重写一遍但需要你知道什么是对的、什么可能是错的。这种能力不会随年龄退化只会随项目越积越厚。5.3 一个适合所有人的练习组合让 Agent 反哺基础训练最后给一个我觉得性价比很高的练习方法适合不同阶段的开发者每天挑一个你业务里真实存在的小模块让 Agent 用你指定的技术栈重写一遍不要看实现先写测试用例再看它代码能不能通过你的用例。每次 Agent 给出方案后要求自己指出一个它没考虑到的边界情况再让 Agent 补上。每周挑一个 Agent 写得最“怪”的代码片段尝试用自己的话向同事解释清楚它为什么能跑、有什么隐患。这套练习不追求量大追求的是逼自己保持思考密度。你会发现一段时间以后你对 Agent 产出的敏感度会明显提升那些常见的坑还没等到上线就能被你拦下来。这种能力就是 Coding Agent 时代的软件工程基础不是写在简历上的名词而是体现在你能不能把关住 AI 的每一条产出上。我在实际项目里最大的感受是AI 写代码的潮流不仅没有让我觉得基础白学了反而让我重新意识到当年那些“没什么用”的理论课原来都是给今天做的铺垫。你曾经迷迷糊糊听过的 B 树、索引失效、缓存一致性在 Agent 帮你把 CRUD 全包了之后变成了你唯一还能创造差异价值的地方。基础没有过时它只是换了一种计分方式从考核“你会不会写”变成了考核“你会不会判断”而后者恰恰是 AI 时代最难被替代的能力。