吴恩达Andrew Ng那份关于「到底要不要转 AI」的报告最近刷屏了。我看完整份材料第一反应是他没给「转还是不转」这种二选一的鸡汤答案而是把问题换了个角度——别纠结改不改行先看自己身上这四项能力缺不缺。这份东西不是拍脑袋列出来的。他们团队扒了一万多条招聘要求找 AI 专家、HR 和猎头聊了几十场又发了问卷最后把数据做了一次聚类看看到底哪些技能被高频提及、而且短期内不会过时。这种「从真实招聘信号里提炼」的做法比任何「我认为是这样」的论断都靠谱。有意思的是这份报告出来的背景恰好是很多人对「AI 会不会抢我饭碗」最焦虑的时候。吴恩达的潜台词其实是与其担心被替代不如看清替代到底发生在哪一层。他的结论很明确——被替代的是「只会照着需求敲代码」的那部分而不是「能判断该做什么、并能把它稳稳交付」的那部分。他最后给出的答案是四项技能。下面我逐条拆开讲再说说落到自己身上该怎么补。① 构建与部署 AI 应用第一项也是被反复强调的一条构建和部署 AI 应用。AI 软件和传统软件最大的区别在于它的输出有随机性。你输入同一个东西模型给的反馈可能每次都不一样。所以这项技能绝不是「会调 API」那么简单。你得理解上下文、RAG 和 Agent 工作流这些机制到底怎么转。举个具体的例子。传统软件里一个登录接口返回 200 还是 401结果是确定的但一个「根据用户提问推荐文章」的 AI 功能同一个问题问三次可能三次给出的排序都不一样。如果你还用测传统软件的那套思路——跑一遍没报错就算过了——那上线之后你根本不知道它哪天会给你整出什么幺蛾子。更关键的是你得学会用统计方法去管这种不确定性。老老实实做评估和错误分析而不是凭感觉「看着顺眼」就上线。我见过太多 demo 阶段惊艳、一上生产就翻车的东西——根子往往就在这没人用数据去量化「它到底有多经常答错」。落到个人这条意味着你至少得补三块一是能把 RAG 和 Agent 跑通并理解原理——不是复制一段代码示例让它跑起来而是真知道检索怎么召回、上下文窗口怎么填、Agent 怎么决断下一步二是建立评估意识每次改动后知道用指标说话比如准确率、召回率、人工抽检的坏样例比例三是把「随机性」当成一个需要被测量的工程问题而不是祈祷它别出错。这里有个常见的误区很多人以为「会用 LangChain 拼几个链」就算掌握了①。其实那只是调用层。真正的①是「能上生产、有评估、可回滚」——当线上模型换个版本准确率掉了三个点你能立刻从监控里看到并且知道往哪调。② 软件工程基本功第二项是软件工程基本功。这一条说出来可能有点反直觉——都在聊 AI 了怎么还在说基本功原因很现实。成本、扩展性、稳定性、响应速度加上安全和隐私这些指标永远在拉扯。不懂这些底层逻辑的人去「vibe coding」凭感觉让 AI 写代码写出来的东西基本是一团糟。因为他自己都不知道该给 AI 喂什么上下文。我见过一个真实案例有人让 AI 写一个接口AI 很听话地写出来了但没加分页、没做缓存、SQL 是字符串拼出来的。正常人一眼就能看出这是生产事故但 vibe coding 的人看不懂因为他脑子里没有「高并发下数据库连接会被打满」这根弦。AI 把代码写出来了问题反而被藏得更深。反过来底子扎实的人是在用工程规范精准指挥 AI 办正事。他知道哪里该优化延迟、哪里该加缓存、哪里的安全边界不能碰。也就是吴恩达想说的AI 不会让软件工程消失它只是把「写代码」这件事的门槛降了但「判断该写什么、写得对不对」的门槛反而高了。这条没有捷径。它不是某个新框架而是老老实实的工程素养系统设计、性能权衡、安全性、可观测性。这些东西二十年前重要今天更重要因为现在你手里的工具更猛一不小心造出的混乱也更猛。一个没底子的人用 AI造出的 bug 规模是过去的十倍一个有底子的人用 AI交付速度是过去的十倍。工具一样差距在底子。③ 用好编码智能体第三项是用好编码智能体coding agent。吴恩达把它单列出来说明它已经不是「加分项」而是基本操作。关键不在于你会不会用工具而在于你知不知道它的边界在哪里——什么时候该盯紧什么时候能放手。盯太紧你自己干活省下的时间又赔进去了放太松轻则烧 token重则删库跑路。这里面具体涉及几件事怎么管上下文喂什么、留什么、怎么平衡「先规划还是直接干」、要不要加自动校验机制跑测试、跑 lint而不是靠肉眼兜底以及多 Agent 怎么协同、边界怎么切。说几个我自己的习惯。第一我给 Agent 下任务前会先把「验收标准」写清楚而不是只说「帮我实现个功能」——标准越含糊它越容易跑偏你后面擦屁股的时间越多。第二我让它改代码前先让它列计划给我看确认方向对了我才让它动手避免它一口气改了十个文件你都来不及拦。第三所有 Agent 产出的代码必须过一遍测试和我的人工 review 才合进主干绝不让它直接 push。我的体会是把 Agent 当成「需要被管理的协作者」而不是「自动许愿机」这件事本身就值钱。会用工具的人一大把会管边界的人不多。④ 定义和塑造需求Shaping the build第四项也是最容易被忽视的一项定义和塑造需求。当 Agent 只要拿到一份清晰的需求文档spec就能把代码写出来时工程师的重心自然就前移了重点变成「这个需求到底该怎么定」。吴恩达那句被疯狂转发的话翻译过来就是——以后不会再有人甩给你一份像素级完备的设计文档让你照着敲代码了。你要懂业务、懂产品、懂用户痛点主动决定「做什么」。同时还要拿捏好时机什么时候该发 MVP 快速验证什么时候该精细打磨。前者怕拖后者怕糙节奏得自己把握。这一项难补因为它不是看书能看会的。它要求你真的泡在业务里知道用户为什么半夜还在用你的产品、知道哪个流程让他们骂娘、知道老板嘴上说的「要快」其实是要「先跑通再谈体验」。这些东西需求文档里不会写AI 也给不了你只能靠你在真实场景里一点点攒体感。这条其实是四者里最「软」也最硬的一项。它不考你某个技术点考的是判断力。而判断力恰恰是 AI 短期内替代不掉的。四条串起来看把这四项放在一起会发现它们有个清晰的逻辑递进从「能把东西做出来」①到「做得对、做得稳」②再到「用对工具做」③最后到「决定做什么」④。越往后越靠近价值判断也越靠近人本身的不可替代性。这也解释了为什么吴恩达说别纠结转不转行。因为真正被需要的从来不是「我会用 AI」这个标签而是这四项能力组合出来的「判断 交付」的复合体。你今天哪怕不做 AI只要这四项里有短板转过去也会吃力反过来四项扎实转不转只是个时间问题。我的几点看法说点我自己的判断不一定对但供你对照。第一四项里最该优先补的是②。它不是最炫的但它是地基。地基不牢①②③都建在沙子上。很多人急着学 Agent、学 RAG却连一个高并发服务的瓶颈都看不懂这种「上半身 AI、下半身悬空」的状态最危险。我自己的建议是先把数据结构、网络、数据库、系统设计这些老本行啃扎实再往上叠 AI顺序别反了。第二①和③要绑在一起练。别把「调通一个 RAG demo」当成掌握了①真正的①是「能上生产、有评估、可回滚」。而 coding agent 是最好的练兵场——你每天用它就是在反复打磨「怎么把需求讲清楚、怎么管住边界」。练着练着你会发现①和③其实是同一个能力的正反两面一个关注产物质量一个关注产出效率。第三④是拉开差距的那项但急不得。它需要业务体感体感是泡出来的不是看出来的。所以别等「我先学完再实践」现在就去找一个真实的小问题从定需求开始做一遍。哪怕是给团队写个内部的工具从「这个工具到底解决谁的问题」想清楚再动手也是在练④。第四把这份清单当参照系别当毕业考题。吴恩达自己也说了这四项都不是学一次就能一劳永逸的。AI 这行变化太快今天的最佳实践可能半年后就过时。它真正的用处是给你一个定期拿出来照镜子的标准接下来该往哪儿补课。如果你正在犹豫要不要入这行我的建议和吴恩达一致先别急着做职业决定把这份清单摊开诚实地给自己打个分。缺哪条补哪条。等四项都不再让你心虚的时候转不转答案自己就出来了。
