吴恩达老师刚刚发了一篇文章，专门拆解AI工程师的核心能力。
他研究了大量招聘信息，做了系统的专家访谈和问卷调查，最终把「会做AI应用」这件事拆成了6块。
这6块能力分别是：LLM基础、用数据给模型打地基、搭建智能体系统、以评估驱动开发、生产环境运维，以及机器学习基础。
听起来像是目录，但每一块展开，都有东西。
AI应用和普通软件，差在哪？
先说一个根本性的差异。
传统软件，输入确定，输出确定。你写一个排序函数，跑一万次结果都一样。
AI应用不是这样的。LLM会输出什么，你事先不知道。模型会犯什么错，你也不知道。这种不确定性，让整个开发过程必须反复迭代——写一版，看看效果，再决定下一步怎么改。
所以AI工程师的核心能力，本质上是在不确定中做决策的能力。
第一块：搞懂LLM的底层
很多人用LLM，就像用一个黑箱，扔进去一个问题，等答案出来，然后不知道为什么它答对了，也不知道为什么它答错了。
吴恩达认为，这不够。
你要理解LLM怎么把文本切成token，怎么逐步生成输出。这样你才能判断：这个任务它能干好吗？在什么情况下它容易出错？
除此之外，还有一堆工程细节需要掌握：什么时候用多模态模型，怎么在有限的上下文窗口里做取舍，缓存怎么算，模型的知识截止到哪里，推理的算力怎么控制，工具调用什么时候用。
再往深走，还有一个问题：什么时候需要微调模型，什么时候考虑自己部署。
这些事，理解了底层才能做出对的判断。
第二块：给模型喂对数据
LLM的输出质量，很大程度取决于它的输入。
早期流行的做法是RAG，用向量搜索把相关内容塞进上下文里。但现在，这套玩法已经远不止于此。
你需要判断：哪些内容应该直接写进prompt，哪些让模型在用的时候自己用工具去查？
数据的组织方式怎么选？向量索引、知识图谱、结构化数据上的语义层，各自适合什么场景？
文档要怎么处理才能让模型读得懂，PDF、HTML、图片，不同格式的处理方式不一样。
还有一件容易被忽视的事：数据的质量要持续维护，不能一次性处理完就不管了。
第三块：搭智能体，有讲究
智能体系统的形态，差异很大。
简单的是固定工作流：预先设计好一系列LLM调用步骤，一步接一步执行。复杂的是让LLM自己判断下一步，循环决策直到任务完成。
怎么选？吴恩达给了几个判断维度：
哪些步骤可以并行跑，哪些必须串行？什么地方用代码更可靠，什么地方用LLM更灵活？出错了怎么回退？
工具调用方面，模型能用哪些工具、能执行什么命令，都需要设计。记忆怎么管理——特别是会话很长的时候，上下文放不下，怎么办？什么时候需要多个智能体协作而不是一个智能体搞定所有事？
还有一件很重要的事，往往被跳过：原型跑通了，怎么让它变成可以放进生产环境的可靠系统？这需要考虑安全边界、对抗性输入，以及防止数据泄露之类的风险。
第四块：用评估驱动开发，这是真正的分水岭
这一块，吴恩达说：
在他见过的AI工程师里，能够跑通一套严格的评估闭环，是区分优秀和普通的最关键特质。
什么意思？
很多人改系统靠感觉，觉得哪里不对就改哪里，改完凭主观判断「好像好了一点」。
厉害的工程师是另一种做法：先把要衡量什么想清楚，再建立一套评估机制，每次改动之后跑评估，根据数据决定下一步改什么。
评估本身也是技术活。你要分析系统的输出和中间过程，结合业务目标确定衡量指标。评估的形式也有很多：代码写死的规则、用LLM来打分、让人来判断。这三种各自适合什么场景，本身就需要判断力。
而且评估也不是一次性的，它要跟着系统迭代一起演进。
第五块：生产环境，另一个世界
把系统做出来是一回事，在生产环境里跑起来是另一回事。
AI应用的运维，和传统软件的运维有几个关键差异。
第一是观测。你需要知道系统在真实用户身上的表现，而不只是测试集上的表现。性能要监控，数据分布的漂移要发现，模型突然变差或者被攻击注入，要能快速响应。
第二是测试体系。AI系统的回归测试，比传统软件复杂——很多结果没有唯一正确答案，需要统计方法来判断是不是变好或者变差了。测试的力度，要和出错的代价匹配。
第三是成本和延迟控制。选哪个模型、要不要蒸馏、工作流能不能简化，这些决策在用户量上来之后，会直接影响系统能不能活下去。
第六块：机器学习基础，绕不开
最后一块，吴恩达说：
他认识的所有在LLM应用上做得好的工程师，都对机器学习和深度学习有一定深度的理解。
为什么？
因为LLM本身就是机器学习的产物，很多判断需要从ML的视角才能做对。而且很多实际应用场景里，还是需要用到传统的机器学习——无论是用别人训练好的模型，还是自己训练。
更重要的是，机器学习里有几个核心概念，对做AI应用极其有用：偏差方差的权衡、错误分析、数据工程。这些概念提供了一套思维框架，帮你在面对不确定输出的系统时，做出更好的判断。
本文来源：AI寒武纪
