提示词工程师和AI工程师区别

你可能正在刷招聘软件，看到「提示词工程师」和「AI 工程师」两个岗位名就懵了——听着都跟大模型有关，薪资差得还挺多，但到底哪个是写字的、哪个是写代码的？这篇不灌鸡汤，把两类岗位的日常活、技能栈、入行门槛和面试会问什么摊开对比，再给你一条自查顺序，看完能判断自己该往哪边走、下一步先补什么。

你可能正在刷招聘软件，看到「提示词工程师」和「AI 工程师」两个岗位名就懵了——听着都跟大模型有关，要求却差挺远，到底哪个是写字的、哪个是写代码的？这篇不灌鸡汤，把两类岗位的日常活、技能栈、入行门槛和面试会问什么摊开对比。

先给一个最粗的判断：提示词工程师主要产出可复用的指令集、评测用例和调优记录，交付物偏文档加配置；AI 工程师主要产出能跑起来的服务、数据处理管线和接口封装。看完这篇，你能判断自己该往哪边走、下一步先补什么，而不是两边都学一半。

先看日常：一天下来各自在忙什么

提示词岗位的一天，大概率是反复试同一类任务：换一种说法、加一段约束、记下结果，再拿去跟业务方确认这算不算变好了。你会花很多时间在整理对照表、归类失败案例上，写代码不是主活，但经常要跑个脚本批量过一遍测试集。

AI 工程师的一天更像传统后端加一点模型味道：读日志找为什么这次调用超时、改代码加重试和缓存、盯线上延迟和用量有没有异常。数据处理和接口封装占大头，模型本身反而是最不用操心的那一环。

• 判断自己适合哪边，先问一句：你更愿意把时间花在打磨文字规则上，还是花在调试代码和数据上
• 如果你看到一堆错误日志就头大，提示词方向起步会更舒服
• 如果你忍受不了同一句话改十遍还不确定好没好，工程方向反而更踏实，因为跑通就是跑通
• 两边都逃不掉的活是记录：不写实验记录，换个人接手就全乱

技能栈对照：重叠部分比你想的多

先讲两边都得懂的公共底子。Token 和上下文怎么算、模型输出为什么天生不稳定、评测要做到什么程度才算数，这些概念不搞明白，两个方向都走不远。站内词典可以一页页查这些基础词（/ai-dict/category/basics），当工具书翻。

提示词侧重点

结构化表达、边界条件设计、失败案例归类、把口头需求翻译成一串可执行约束

工程侧重点

一门主力语言、接口调用与重试、向量检索与数据清洗、部署与监控

共同盲区

很多人以为会写几句提示词就算入门，其实不会做评测就说不清自己到底改好了没有

共同加分项

能把一次实验结果讲成可复现的流程，别人照着做能复现同一结论

有个常见的误区值得单独说：提示词方向不需要编程能力。现实里你往往要批量跑评测、把输出整理成表格、对比不同配置的稳定性，这些活纯靠手工点会疯掉。看得懂、改得动脚本，是这条路的隐藏门槛，不是加分项。

工程方向的误区在另一头：只会调接口不算 AI 工程师。数据怎么清洗、上下文塞不下怎么切、失败怎么重试、成本异常从哪查，这些才是面试和上线后会真正卡你的地方。

入行门槛与常见背景：谁更容易转进来

提示词岗对科班要求相对松，运营、文案、客服、行业顾问转过去都有先例，前提是能拿出成体系的提示词作品集，而不是零散截图。招聘方想看到的是你有方法，不是你会说好听话。

AI 工程师岗普遍要求能独立写代码，纯文科背景直接转的难度大。更现实的路径是先做应用侧，用现成接口攒工程经验，再一点点补底层。从测试、数据分析、后端等岗位横向转，比从零起步省时间，因为调接口、看日志、做对比实验这些活你本来就熟。

• 什么情况下不适用：如果你所在行业对合规和准确性要求极高，比如医疗、金融，光靠提示词经验很难被直接录用，需要补行业知识和验证流程
• 什么情况下不适用：如果目标公司是基础模型团队，提示词岗极少，对方要的是训练和推理工程能力
• 一个务实的判断：翻目标岗位的职责描述，数一数要求里出现几次「代码」「部署」「脚本」，超过一半就往工程靠
• 另一个信号：描述里出现「业务」「场景」「方案」，说明这活更偏提示词和应用

作品集怎么攒：两类岗位各要准备什么

提示词方向整理三到五个真实场景就够了，每个写清原始需求、你改了几版、改的依据是什么、怎么验证变好了。重点在过程，不在最后那句提示词本身。只贴一句「神奇提示词」的作品集，面试官看一眼就翻过去了。

工程方向一个能跑起来的小项目胜过一堆教程仓库。比如一个带缓存和重试的接口封装，附上你怎么量延迟、怎么控用量。别只写用了什么框架，写清你踩了哪些坑、怎么发现、怎么改的。

1. 挑场景选一个你真做过、能讲清前因后果的活，别选教程里的通用例子
2. 记过程每一版改动都留一句为什么改，事后回看能还原当时的判断逻辑
3. 留失败专门记一次判断错的经历，写清后来怎么发现的、下次会怎么避免
4. 能复现把评测方法写出来，别人照着跑能得到相近结论，这才叫作品不是展示

• 别把工具目录当作品集，工具清单谁都能抄，要露出你的取舍理由
• 别堆截图，截图证明不了判断力，文字记录才看得出来
• 如果只能准备一个，准备失败复盘，面试官对这个的兴趣往往超过成功案例
• 两边通用的建议：作品集讲的是你怎么想，不是你用过什么

面试会问什么：两边的提问重心不一样

提示词岗常被问：模型输出跑偏你怎么定位、同一个需求你会不会换模型、上线后效果下降先查哪一步。这类问题没有标准答案，考的是你的排查顺序是不是清楚。

工程岗常被问：接口超时怎么处理、上下文塞不下怎么切、用量翻倍了从哪几处找原因。答的时候要给出具体动作，不要只说「加监控」「做优化」这种空话。

共同考点是对数字要敏感，但别背死数字。被问价格和用量时，讲清你怎么查、按什么口径算，比背下来更可信。站内的官方价目和用量榜可以对照口径（/official-api、/usage），自己去核一遍比听人转述靠谱。

• 准备方法：把自己的项目按「问题—动作—结果—如果重来」四段讲一遍，比背题库管用
• 每个方向准备三个能展开讲的例子，剩下的用一句话带过
• 被问到不会的，说清你会怎么查、查哪些页面，比硬编答案得分高
• 提前问面试官团队现在最头疼的问题是什么，这题往往比技术题更透露信息

哪些人先别急着转：三种容易踩空的情况

第一种，只想蹭热度、平时并不动手做东西的人。两个方向都要求大量重复实验，热度撑不过三个月，试用期就会露馅。这不是能力问题，是习惯问题。

第二种，指望提示词岗完全不碰代码的人。现实里往往要写脚本批量跑评测、整理数据，至少得看得懂、改得动。看到命令行就关窗口的，这条路会很累。

第三种，只学了工具操作但没有业务理解的人。说不清这个改动到底帮业务省了什么，就做不出能落地的方案。工具可以现学，业务判断学不来。

• 自查方式一：给自己两周时间，用业余时间做一个完整小交付
• 自查方式二：做完之后问自己愿不愿意再来一遍，不愿意就别硬转
• 自查方式三：把这事讲给一个外行听，讲不清楚说明你自己还没想明白
• 不适用的情况：如果你只是想在公司内部多接点相关活，不用这么严，边做边学就行

转行路线：先走哪一步更稳

第一步，选一个方向深挖，别两个一起学。四到六周只做一件事：要么攒提示词评测案例，要么做一个能跑的小服务。同时学的结果通常是两边都半瓶水，简历上不好讲。

第二步，找内部机会。公司里总有没人愿意做的模型试验活，接过来就是带薪练手，比裸辞学风险小得多。哪怕只是帮同事整理一份评测表，也是能写进简历的经历。

1. 选方向用前面那张背景对照表定位自己，四到六周只做一件事
2. 攒交付做出一个能拿出手的东西，提示词方向是评测案例集，工程方向是能跑的小服务
3. 拆岗位投简历前把目标岗位描述拆成技能清单，逐条对照自己能讲出什么例子
4. 补缺口讲不出来的先补，补不动就直接跳过这类岗位，别硬投浪费时间
5. 核数字涉及价格和用量的说法，到站内页面核对当时的数字，别用别人转述的

别把转行想成一次跳跃。更常见的是先接相关活、再换岗、最后换行业，每一步只挪一小格。哪一步都判断不了的时候，先做那个两周小交付，答案会自己浮出来。