前两天我听到一个挺有冲击力的例子。
一个 05 后，自己说只有初中学历，搬过砖，卖过房，也做过拼多多。现在他开始给中小企业搭 Agent。
这种故事最容易被讲成一句鸡汤：你看，学历不重要。
我觉得这么讲反而害人。
学历当然重要。很多公司筛简历，第一眼看的就是这张牌。名校、科班、研究经历、实习经历，这些东西不是装饰，它们真的会影响你能不能被看见。
但这个例子真正值得拆的地方，不是“学历没用了”，而是另一件事：
当你这张简历牌不够硬的时候，能不能用作品集把自己送上牌桌？
这才是普通人转 AI 最该问的问题。
先分清楚：你说的是哪种 AI 工程师？
很多人一听 AI 工程师，脑子里会混成一团。
训练大模型、做算法、发论文、调模型结构、看数学推导，这是一条线。更准确地说，它更接近模型研究员、算法工程师、机器学习研究岗。
这条路当然吃学历。
它吃数学，吃研究背景，吃导师、实验室、论文和大厂项目。你不能拿一个普通小项目，去硬碰别人多年积累的研究训练。
但现在市场上还有另一条更现实的线：AI 应用工程师。
这条线不是去造 DeepSeek、千问、Kimi 这种模型，而是把已经有的模型接进真实产品和真实流程里。
比如客服系统不只是陪人聊天，而是能查订单、查售后、识别自己不知道的时候不能瞎答。
比如公司内部搜索不只是生成一段漂亮废话，而是能从文档里翻出正确段落，还能告诉你依据在哪里。
比如一个 Agent 不只是喊一句“自动干活”，而是能拆任务、调工具、拿结果，失败的时候知道停下来。
这类岗位验收的是另一套东西：
能不能跑。
能不能评估。
能不能部署。
出了问题能不能查。
你会发现，学历仍然是牌，但它不再是唯一的牌。作品也是牌。问题是，你手里的作品到底像不像牌。
很多人说会 AI，其实只会说概念
现在最不值钱的话，就是“我会 AI”。
你说你懂 RAG。那你有没有拿一批真实文档搭过问答系统？检索命中了哪些段落？哪些问题没命中？你怎么知道它不是编的？
你说你懂 Agent。那你有没有让它调用过工具？工具返回空结果怎么办？API 限流怎么办？模型调错函数怎么办？它是一直兜圈子，还是能停下来告诉你哪里坏了？
你说你懂工程。那你的项目有没有部署链接？有没有日志？有没有成本记录？有没有测试用例？别人能不能不用你站在旁边解释，自己打开跑一遍？
如果这些都没有，你不是在描述能力，你是在描述兴趣。
兴趣当然可以是起点，但求职和接项目不是比谁兴趣大。市场最后看的是：你能不能交付一个能用的东西。
所以低学历、非科班、弱简历的人，别先急着给自己贴“AI 工程师”标签。
先拿三张作品牌。
第一张牌：API 小工具
第一张牌不用做大。
你先从空文件开始，用 Python 或 Node 调通一次模型 API。输入一段文本，让模型按你的要求输出，比如固定 JSON、表格、摘要字段、分类标签。
这听起来很基础，但很多人连这一步都没有真正做完整。
完整不是“调用成功一次”。
完整是你能处理报错、超时、空回复、格式不对、token 太长、密钥读取失败。你能把输入输出保存下来，能把失败原因写进日志，能让别人照着 README 跑起来。
一个最小作业可以这样做：
做一个命令行工具。用户输入一段客户咨询，它自动输出问题类型、紧急程度、推荐回复和需要人工介入的理由。
这东西不宏大，但它能证明几件事：
你知道怎么接 API。
你知道怎么控制输出格式。
你知道模型会不听话，所以你写了校验。
你知道工具会失败，所以你留了错误处理。
这比“我熟悉大模型 API 调用”这句话有用得多。
第二张牌：RAG 项目
第二张牌是 RAG。
但别只跑教程例子。
教程里的文档通常太干净，问题也太配合。你一换到真实业务，马上会遇到一堆麻烦：文档格式乱、标题不统一、表格不好拆、同一个问题在不同文件里说法冲突，用户问的问题也不会按你的关键词来。
所以 RAG 项目要用真实材料。
可以是产品手册、公司制度、课程文档、售后 FAQ、自己的知识库。材料不一定多，但必须真的会把系统弄脏。
做完以后，不要只录一段“它回答得很好”的视频。
你要有评估表。
问了哪些问题？系统命中了哪些段落？哪些问题找错了？哪些回答引用了不相关内容？下一版准备改分块、改 embedding、改检索数量，还是加 rerank？
RAG 的重点不是模型说得多顺。
RAG 的重点是它有没有找到该找的内容。
如果检索错了，后面语言再漂亮也没用。它只是把错误讲得更像真的。
第三张牌：Agent 项目
第三张牌是 Agent。
这里最容易装。
很多 demo 看起来很炸：模型规划几步，屏幕上刷一堆日志，最后吐出一个结果。问题是，你一问失败处理，立刻露馅。
真正的 Agent 项目，至少要展示三件事。
第一，它会选择工具。不是所有问题都丢给模型自由发挥，应该查订单就查订单，应该查文档就查文档，应该算价格就调用计算工具。
第二，它会读取工具结果。工具返回什么，它不能假装自己已经知道答案。空结果就是空结果，失败就是失败，权限不足就是权限不足。
第三，它会在坏掉的时候停下来。API 限流了怎么办？工具超时了怎么办？函数参数错了怎么办？连续两次失败以后，是继续烧钱兜圈子，还是把问题交还给人？
这才是 Agent 和“会聊天的模型”的差别。
一个最小 Agent 作品，可以做成内部资料助手：
用户问一个问题，它先判断要不要检索文档；如果需要，就调用检索工具；如果找到依据，就给出回答和引用；如果找不到，就明确说查不到，并把问题写进待补充清单。
这个项目不一定酷，但它像工程。
因为工程不是只展示成功路径。工程要处理失败路径。
还有一张隐藏牌：部署和复盘
很多作品集死在最后一步。
代码在自己电脑上能跑，录屏看起来也不错，但别人打不开。
这不行。
你的项目至少要有一个别人能访问的形态。可以是在线 demo，可以是本地运行说明，可以是 Docker，也可以是一个录屏加完整仓库。关键是别人能验证，不是只能听你讲。
同时要留四类记录：
测试用例：你用哪些问题验证它？
评估结果：哪些过了，哪些没过？
成本记录：一次调用大概多少钱，跑一轮测试花多少？
错误日志：失败时系统记录了什么，你怎么定位？
这些东西看起来不如封面和 demo 漂亮，但它们最能证明你像一个工程师。
因为真实工作里，老板、客户、同事不会只问“它成功的时候多厉害”。他们会问：
它坏了怎么办？
它贵不贵？
它能不能给别人用？
它下个月还稳不稳？
你答得出来，作品集才开始有分量。
别把作品集做成摆拍
这里还有一个坑。
很多人做作品集，是为了展示自己“看起来会”。于是项目名很大，页面很漂亮，README 写得很满，但一跑就露馅。
这种作品集不补牌，反而扣分。
真正有效的作品集，不怕小。
一个 API 工具很小，但错误处理扎实。
一个 RAG 项目很小，但评估表清楚。
一个 Agent 项目很小，但失败路径可见。
一个部署很简陋，但别人能打开，日志能查，成本能算。
这比“我做了一个企业级智能体平台”的空壳强多了。
普通人转 AI，不要一上来扮演架构师。先做一个能被挑毛病的小系统。有人挑你毛病，有时候反而说明他在认真买。
这条路不保证你赢，但能让你上桌
我不想把这篇写成“低学历也能轻松做 AI 工程师”。
不轻松。
学历弱、基础弱、项目经历弱，就意味着你要用更多可验证的东西补回来。别人一张学校牌能过的第一关，你可能要用三个作品、一个 demo、两份评估表去换。
这不公平吗？
不一定公平。但现实大概率就是这样。
所以真正的问题不是抱怨学历有没有用，而是问自己：我还能不能打出下一张牌？
如果你的目标是模型研究，那就老老实实补数学、补论文、补研究训练。
如果你的目标是 AI 应用工程师，那就先做作品集。别急着把简历投出去刷挫败感，也别用收藏教程缓解焦虑。
先做一个能跑的小工具。
再做一个能评估的 RAG。
再做一个能处理失败的 Agent。
最后把它部署出来，留下测试、日志、成本和复盘。
到那时候，你再去说“我想做 AI 应用工程师”，这句话才有重量。
学历是牌，作品也是牌。
你手里那张牌不够硬，就得让下一张牌能上桌。