前两周和一位做AI工具的朋友吃饭他给我看了组里的月度迭代数据提交次数翻了一倍但代码评审里真正围绕架构、边界、取舍的有效讨论反而少了四成。代码量上去了关键决策却没人管了。这个矛盾被吴恩达最新的一句判断点透了AI工程师最稀缺的能力已经不在代码里。这话放在三年前肯定会被喷——那时候AI写代码还经常翻车会写代码就是硬通货。但放到现在你只要用过几轮Cursor、Claude或者国内这些大模型编程助手就会承认生成代码这项技能确实在以肉眼可见的速度贬值。这篇文章我想跟你拆三件事判断背后的技术逻辑是什么所谓稀缺能力具体指什么以及最关键的——这种东西能不能练怎么练。1. 代码不再是分水岭AI正在重写工程师的价值链条1.1 从补全到Agent工具在四五年内走完了三层进化先说技术背景不然很多人会对“能力不在代码里”这句话产生误解。过去四年AI编程工具走完了三层进化每层都在稀释一部分传统编码能力。第一层是生成式补全以早期Copilot为代表。你写半个函数它帮你补完本质是一个极度聪明的自动补全。这个阶段工具还只是“手足”书写权还在你手里。第二层是对话式生成ChatGPT这一代你描述需求它生成完整代码。但这份代码经常不能直接用需要你复制粘贴、自己接入上下文、手动处理依赖。第三层是Agent式协作Cursor、Claude Code这类工具已经能跨文件改代码、自己跑测试、看到报错再修复甚至能执行命令行、检查运行结果。也就是说过去需要三年训练才养成的“看需求写代码”的肌肉记忆现在AI用几秒就能模拟到相当程度。这三层进化叠加起来的效果是编码环节的系统性外包。注意我用的是“系统性”三个字不是某一段代码能被AI生成而是从项目脚手架、数据库操作、接口对接、单元测试到部署脚本整条链路都可以在人的引导下由AI产出。我一个做外包的朋友说以前一个CRUD项目报价要排两周工期现在他用AI辅助一天半就能交付剩下的半天还得专门拿来跟客户确认需求——因为代码从来不是瓶颈搞清楚客户到底要什么才是。1.2 编码外包后真正贵的变成了什么编码被外包之后人力成本并不会消失而是向链条的两端迁移。一端向上游移动需求定义、边界划分、风险预判另一端向下游移动验证评估、结果解释、错误归因。中间那段“把设计翻译成代码”的动作恰恰是AI最擅长的。印刷术普及之后抄写员这个职业消失了但作者和编辑没有消失反而因为复制成本变低而变得更值钱。同样的逻辑AI让代码的“印刷成本”趋近于零那么掌握“编什么内容”“怎么判断内容对不对”的人就会成为新的稀缺资源。所以与其焦虑“会不会被AI取代”不如先问自己一个问题如果生成代码不再需要花钱花时间我的时间应该放到哪个环节去才能继续创造别人替代不了的价值这个问题的答案基本就是你未来三五年要重点修炼的方向。提示判断“编码是否稀缺”有一个更硬核的标准——看薪酬。近两年全球范围内纯执行类的前端页面搭建、简单脚本编写外包价格肉眼可见地崩了但“AI行业规则”的复合型岗位薪资还在涨。市场已经投票了。2. 被淘汰的不是“会写代码的人”而是“只会写代码的人”2.1 三张正在加速失去竞争力的画像先把前提说清楚吴恩达这句话绝不是让人不学代码。恰恰相反AI时代你得懂代码否则你连需求都描述不精准连错误信息都看不明白。这里讨论的“被淘汰”指的是只会把代码当执行工具、没有任何系统判断力的人。顺着这个标准往下看有三类画像正在快速失去竞争力。第一类接口拼装工。典型场景是拿到上游接口文档照着老代码的样子把新字段填进去联调通了就交差。AI最擅长的恰恰就是这个——你把文档甩给它它抄袭样式的能力比你更强还不会抄错。第二类只会调包不会排查的“复印机”。有段时间我面试过一些候选人简历上写熟悉Python开源项目也有不少但问到一个具体报错怎么定位就只会说“把报错贴给AI”。工具可以帮你定位但定位之后怎么判断AI建议是不是在胡扯需要你自己理解系统。第三类没有业务判断的“代码翻译机”。产品经理丢来一个需求它可以实现但从不想这个需求为什么要做、指标口径合不合理、线上线下冲突时该选哪个。这类工作正在变成高危。这三类人的共同点不是代码写得不好而是只完成了“执行”这一层。AI恰好是执行层的大力士拼体力你永远拼不过它。2.2 AI对资历的冲击是非对称的更有意思的是AI对不同资历的人冲击完全不同。初级工程师过去最大的竞争力是什么是“熟悉常用框架”“样例代码写得多”“什么需求都能快速攒出一版”。这些恰恰是AI最擅长的部分所以初级工程师的产出被AI迅速追平甚至反超。而资深工程师的核心资产是多年踩坑攒下的边界感——知道哪条路走着走着会死、哪个设计会在半年后爆发问题、哪类需求必须提前做埋点和灰度。这些东西没有写在任何公开代码仓库里AI学不到。于是你会看到一种奇怪的错位刚毕业的开发者因为有了AI能独立做出以前需要两三年经验才能做出来的Demo但真到生产环境、真到系统出问题的时候判断力依然稀缺。这种“产出通胀、判断通缩”的现象正在重构整个行业的薪酬结构。2.3 “会用AI”和“依赖AI”是两种物种最后做个小结式区分。我也每天在用AI编程工具但我非常警惕“依赖”这个词。会用AI的人是先把问题想清楚再让AI去写依赖AI的人是让AI替自己想自己只负责催。前者把AI当成执行力放大器后者把AI当成思考替代品。差距在平时的行为上就能看出来一个人写提示词时会写“输入是什么、输出是什么、约束是什么、验收标准是什么”另一个人只会写“帮我写一个Python脚本实现XX”。这两种提示词导致的结果差异不是“提示词技巧”的差异而是你脑中的问题结构差异。这一条是后面所有训练动作的地基。3. 吴恩达口中的“稀缺能力”到底指什么我按重要程度排了个序3.1 需求拆解力把模糊话语变成可验证条件吴恩达在不少场合强调过AI时代工程师最该练的不是怎么问AI而是怎么定义问题。落到日常就是需求拆解力。业务方说“帮我用Python生成一个统计报表”你要是直接把这个需求扔给AIAI只会给你一个“看起来对但实际没什么用”的脚本。真正值钱的动作是往下拆数据源从哪来表结构长什么样缺失值怎么处理统计口径是按订单时间还是支付时间输出给谁看需要什么权限要不要保留明细如果说AI是施工队那需求拆解就是你画出来的施工图。图纸上少画一根梁施工队永远不会替你补上——它只会把它理解成不需要。一个能落地的训练方法拿到任何需求先不急着打开AI先写一份两页纸的“需求澄清清单”列出所有你不确定的上下文。写满十条之后你会发现这个需求真正难的地方根本不在写代码。3.2 系统设计与取舍决定边界和契约的还是人AI非常擅长写模块内部的逻辑但模块之间的边界、接口契约、数据流向、扩展点怎么留这些依然是人来决策。举个例子做一个代码诊断插件可以设计成IDE侧的本地分析也可以设计成服务端分析。前者对用户隐私友好、响应快但更新算法需要用户升版后者可以集中升级模型但要把代码片段传到服务器还多出网络和存储成本。AI不会主动帮你权衡这些它只会等你做出决定然后执行。我曾经让AI生成过一个中间件方案它给了我一个很工整的架构接口也很优雅但部署上去才发现它默认所有节点在同一内网——我们的生产环境跨两个云网络策略不互通。这个坑就是典型的“AI替你写了代码但没替你设计系统”。3.3 领域建模同一个排序在两个行业是两种代码领域知识可能是AI时代最大的护城河因为领域知识不在GitHub上而在真实业务的每个异常里。经常有人上网搜“量化交易策略代码”以为拿到代码就等于拿到策略这是天大的误会真正值钱的不是那几行买卖判断而是背后的风控参数、仓位管理、止损逻辑、回测框架、对异常行情的处理。同样一段排序代码放在金融系统里要考虑时区、精度、除权除息、脏数据剔除放在游戏排行榜里要考虑并发写入、榜单粒度、冷热数据分离。AI能把代码写对但它不能替你搞懂“为什么这里必须这样处理”。领域知识越深你给AI的约束就越精准AI生成的东西才越接近能用。3.4 评估力定义“正确”并验证“做对”AI生成代码越来越快之后一个新的瓶颈出现了你凭什么说这段代码是对的这就是评估力。很多开发者的测试习惯是“跑通不报错就算过”但AI生成的代码经常在某些输入下不报错却算错。真正要练的是写边界用例和验收标准的能力空值、超长字符串、并发、重复执行、断网重试这些边界条件AI不会替你想到它只会按照你给出的约束尽力而为。没有评估力的人AI生成的东西他不敢上线有评估力的人AI生成的东西他敢压上生产因为他已经提前知道哪里可能出问题。这种“信任但验证”的能力正在成为AI时代工程师的标配。吴恩达所说的“能力不在代码里”很大程度就是在说这一层——代码是谁写的不重要重要的是你有没有能力和方法判定它对不对、敢不敢为它负责。3.5 协调力把个人产出变成团队资产最后想讲一个经常被忽略的能力协调。AI让一个人能完成过去一个小团队的工作量但把一个人的产出变成团队可持续维护的资产还是要靠沟通。现在最典型的问题是AI生成的代码“能跑但说不清为什么”如果作者不把设计意图记录清楚三个月后同事来维护看到一坨漂亮但陌生的代码只能再让AI解释一遍——这叫“解释性债务”。所以现在很多资深工程师在review时除了看代码逻辑还会问这段设计决策记录在哪这个方案的备选项有哪些为什么选了这个这些问题本质上是在对抗AI带来的“解释性债务”。能把代码讲清楚、能让非技术方信任技术判断的人在任何团队里都是稀缺品。4. 一次实测同一个Python需求两种做法差在提示词之外4.1 需求背景光讲能力太虚了用一个我上个月实际处理过的需求演示一遍。任务很简单文件夹里有十二张Excel月度报表列名不统一一张叫“订单号”一张叫“OrderID”还有一张叫“订单ID”现在要合并成一张总表再按客户ID和月份做一次金额汇总。懂Excel的人会用透视表但数据量大、以后每月都要跑所以要写成脚本。任务听起来很普通但两种做法效率和结果完全两个世界。4.2 做法A直接把需求丢给AI陷入无效debug的循环第一种做法也是大多数人默认的做法打开AI对话框输入“帮我写一个Python脚本合并文件夹里的Excel文件并汇总”。AI大概十秒钟就会给出一个pandas脚本看起来逻辑完整用glob遍历文件、pd.read_excel读取、concat合并、groupby汇总。你高高兴兴跑一遍然后开始踩坑第三张表编码不对报UnicodeDecodeError第五张表列名不是“金额”而是“总金额”合并后那一列全是NaN跑完才发现汇总口径里有的订单被重复计了因为源表里有跨月冲正记录。你把这些报错一条一条贴给AI它一条一条修。每修一次你都要等它、跑一遍、再等它。一个小时过去了脚本终于跑通了但你自己心里清楚你并没有验证过它是不是完全对只是它不再报错而已。4.3 做法B先把约束说清楚AI一次给出可维护代码第二种做法是我现在带人时的标准动作。动手前先花半小时写一份需求规格不需要写得像正式文档只要把约束想清楚然后原样丢给AI。我给的提示词大概是下面这个结构。背景data/ 目录下有12个月度Excel报表列名不统一订单号/订单ID/OrderID/ID 任务合并所有报表按“客户ID月份”汇总金额输出 summary_YYYYMMDD.xlsx 约束 1. 列名统一映射订单号/订单ID/OrderID/ID 统一为 order_id金额列统一为 amount 2. 金额为空按0处理整行全空的记录直接跳过 3. 最近12个月内如有重复订单按 order_id 去重保留最后一次出现的记录 4. 输出两个sheetsheet1为合并明细sheet2为透视汇总 5. 处理时按文件分块控制内存峰值 6. 运行结束后打印日志读取文件数、跳过文件数、去重数、各文件记录数 验收打印日志与源文件一致汇总表数字和人工抽查结果一致同样一个AI给到这样的约束之后生成的脚本基本可以直接跑。第一遍可能会有小问题比如某个映射没覆盖到但因为它有了明确的验收标准你可以快速定位。整个流程下来真正花时间的是需求澄清和结果验证生成代码本身只占很少一部分。我把两种做法的耗时统计了一下做法A总共耗了快两个小时其中真正的生成只占几分钟剩下的全在交互式debug做法B从写规格到验证完成五十分钟其中写规格花了二十五分钟验证花了二十分钟。代码质量的差距更大做法B的脚本有日志、有去重、有内存控制、有明确的映射关系能直接进仓库当工具长期维护。4.4 复盘时间到底花在了哪里这个案例我复盘过很多次结论很清晰对付AI难的不是“让它把代码写出来”而是你写出那一百字需求规格的能力。那一百字背后是需求拆解力、领域知识、评估力跟提示词技巧没太大关系。你把同样的规格给任何一个主流模型它都能生成质量不错的脚本但你要是把一句“帮我合并Excel”给再强的模型它也只会给你一句标准答案。所以以后再看到有人吹嘘某个提示词模板能秒出什么项目我的第一反应不是羡慕而是想知道他到底在这个领域积累了多少约束条件。约束才是竞争力提示词只是喇叭。5. 这套能力可以练不是玄学五个具体训练动作5.1 让AI帮你做“需求评审”第一个训练动作最简单以后接到需求先不要直接让AI写代码而是把需求描述先发给AI让它列出“你还缺少哪些信息”。这个动作有两个用处一是AI确实能挖出不少你没注意到的边界条件像一张免费的需求检查表二是它的反馈会让你反向意识到自己大脑默认了多少隐性假设。坚持一段时间你再写需求描述时脑子里会自动跳出那些曾被忽略的条件。你并不需要背什么提示词模板你需要的是养成“先问边界再问实现”的肌肉记忆。5.2 给AI生成的代码强制写“风险清单”第二个动作稍微反直觉每次拿到AI生成的代码不要急着跑先写三条“这里可能出错”的猜测再带着猜测去验证。比如AI生成了文件解析代码你可以猜文件里混入了空文件怎么办文件名包含空格怎么办某列全为Null怎么办把这三条写成测试或临时脚本跑一遍。这个动作训练的是评估力——你不只是相信代码而是主动寻找它最可能在哪个环节出问题。一开始你会觉得烦但习惯了之后你会发现自己对AI产出的判断力会快速超过大多数人。5.3 记录时间结构把“写代码”比例压下来第三个动作是让数据说话。找一周时间每天粗记录一下自己的时间分配需求澄清花了多久、方案设计多久、真正写代码多久、验证和排错多久。我观察过一个典型的新手工程师他的写代码时间占了60%以上但产出质量并不高。我也观察过资深工程师他们大量时间花在“跟人确认需求”“画交互边界”“设计数据流”上真正敲代码的时间不到30%。AI时代这个对比会更极端。别急着提高打字速度先调整时间结构。当你的时间重心逐渐从编码动作转移到定义、验证和设计上你其实已经踩在吴恩达说的那条“能力曲线”上了。5.4 选一个垂直领域扎进去别只当“AI工具玩家”第四个建议可能不太讨喜别把所有业余时间都花在试新AI工具和背提示词上。工具更替非常快今天热门的插件三个月后可能没人用但一个行业的深层规则不会变。选择一个你已经有背景或特别感兴趣的垂直领域——电商数据分析、量化策略、嵌入式开发、运维自动化都可以——然后带着AI天天在里面拱。你会发现AI能帮你扫清很多编码门槛让你更快触达这个领域的核心问题。而你对领域问题的理解又反过来让你在用AI时比别人精准得多。这就是我说的护城河领域知识加上AI而不是AI技巧加上更多AI技巧。5.5 提示词是表层思考边界才是底层最后说一句可能得罪人的话市面上大量“提示词课程”本质上都在教你更精确地描述需求这本身没错但它只是表层。同一个提示词框架需求理解深的人用它生成的是生产级代码需求理解浅的人用它生成的是玩具。差别不在提示词本身而在你脑中的约束集合。所以我更愿意把提示词工程理解成“把隐性思考显性化”的技术——它的价值来自你真实积累的思考而不是那几行固定的句式。想明白这一点你就不会再沉迷于收集所谓的万能模板了。回到吴恩达那句话。我自己带团队这几年越来越能体会他说的“能力不在代码里”是什么意思。以前招人我会看他的仓库、看他写过多少代码现在我会出一些更奇怪的面试题一个模糊需求你会怎么拆一条AI生成的代码你会怎么验证一个线上事故你怎么定位这些问题的答案里藏着的才是AI无法快速替代的部分。AI能替你敲键盘但不能替你想清楚为什么要敲能替你写出一堆代码但承担不了代码上生产之后的信任。把能力从“手”练到“脑”这句话我会一直贴在工位上。
