AI 提示词工程师的工作，是把「人类模糊的需求」翻译成「模型能稳定执行的指令」，并让它在大规模调用下依然可靠。关键词是「稳定」和「大规模」——只做一次能出好结果，那是使用者；能做一千次都出好结果，那才是工程。
这个角色最早出现在做 AI 产品的团队里，后来扩散到内容、客服、教育、电商、法务等所有把 AI 接进业务流程的地方。岗位名字五花八门：提示词工程师、AI 应用工程师、AI 训练师、AI 内容运营，做的事高度重叠。
和业务方聊需求，拆成模型能做的步骤。这部分占时间不多，但决定了后面所有工作的天花板。
收集真实案例做成测试集，每条指令改完都跑一遍，看是变好还是变坏。这是和「业余爱好者」最大的分界线。
提示词不是一次性用品。要抽成带变量的模板、记录版本、写清适用边界，让同事能直接复用。
和工程配合把提示词接进接口，设计输出校验、异常兜底、成本与延迟的取舍。这部分更像产品经理＋工程师的结合。
| 维度 | 会用 AI 的人 | 提示词工程师 |
|---|---|---|
| 目标 | 这一次拿到能用的结果 | 长期稳定拿到可用的结果 |
| 判断标准 | 「我觉得这个版本更好」 | 测试集通过率、人工评分、成本、延迟 |
| 面对失败 | 换个说法再试一次 | 定位是哪条约束导致，改成可复现的规则 |
| 交付物 | 一段对话 | 模板 + 变量说明 + 测试用例 + 使用文档 |
| 换模型 | 重新摸索 | 跑一遍测试集，按差异补丁式调整 |
很多人以为最重的是「提示词技巧」，实际招聘里最看重的是前三项：
| 能力 | 为什么重要 | 怎么练 |
|---|---|---|
| 业务理解（最重） | 不知道业务标准，就判断不了输出好坏。写文案的、做客服的、懂财务的，各有天然优势。 | 在你熟悉的领域里做 30 个真实任务，记录什么算合格 |
| 结构化表达（很重） | 把模糊需求拆成步骤、条件和边界，是这份工作的日常 | 练「五要素」写法，练把一件事拆成 5 步 |
| 评测意识（很重） | 没有评测就没有优化，只能靠感觉 | 给自己建一个 20 条的小测试集，每次改动都跑一遍 |
| 模型认知 | 知道上下文长度、随机性、幻觉边界，才能设计兜底 | 同一条提示换两三个模型对比，记录差异 |
| 基础工程 | 会调接口、读 JSON、写简单脚本，效率高一个量级 | 学 Python 基础 + 一次 API 调用即可起步 |
| 写作功底 | 影响输出的文字质感，但不是决定因素 | 多读好文，练删冗余 |
换句话说：行业经验 + 表达清晰 + 会做验证，比背一百条「神级提示词」有用得多。
按每周 5–8 小时设计，前提是你已经能正常使用 AI 工具。每一周都有一个可验收的产出，不做完不进入下一周。
| 周次 | 学什么 | 这周的产出（验收标准） |
|---|---|---|
| 第 1 周 | 五要素结构与前后对比 读：怎么写 | 把 5 个「一句话需求」改写成完整提示词，每个都能一次出可用结果 |
| 第 2 周 | 指令词与任务拆解 读：指令大全 | 把一个复杂任务拆成 5 步指令链，跑通并记录每步输出 |
| 第 3 周 | 建自己的测试集 | 在你的业务领域收集 20 条真实案例，写下「什么算合格」的判断标准 |
| 第 4 周 | 用测试集做迭代 | 同一任务做出 3 个版本，用同一批案例跑，输出对比表（通过率、问题类型） |
| 第 5 周 | 模板化与变量 | 把最好的版本抽成带变量模板（如 {行业}、{字数}），同事能直接填 |
| 第 6 周 | 异常与兜底设计 | 列出 10 种失败情况（编造、跑题、超长、格式错），每种给一条防线 |
| 第 7 周 | 跨模型对比 + 成本 | 同一套模板在 2–3 个模型上跑，记录质量差异、耗时、费用 |
| 第 8 周 | 整理成作品集 | 3 个项目文档 + 一份「怎么用」说明，能直接发给面试官 |
如果只有两周时间，压缩成：第 1 周学会写完整提示词，第 2 周建 20 条测试集并做一次对比。这两件事最能体现专业度。
面试这个岗位，没人想看你的聊天记录截图。他们想看的是「你怎么判断好坏」。三个方向：
选你熟悉的领域，比如「客服工单自动分类」。交付物包含：业务目标 → 输入样例 → 提示词模板（带变量）→ 20 条测试结果 → 失败案例分析 → 最终版本与取舍理由。
同一个任务，三个提示词版本，同一批 20 条输入，输出一张对比表：通过率、平均字数、格式正确率、编造次数。结论写清「哪一版更好」以及「为什么」。
这个项目最值钱的地方在于它证明你会做验证，而不是只会调措辞。
模拟团队协作：命名规则、变量约定、版本记录、适用边界、常见失败与处理。哪怕只有 3 页，也能立刻把你和「爱好者」区分开。
不必一开始就会写代码。但会调一次接口、能读 JSON，效率会明显不同。技术是加速器，不是入场券。
模板会过期，结构不会。掌握「任务—约束—格式」这层逻辑，比收藏一千条提示词有用。
它的门槛在业务理解，而业务理解需要时间。把它当捷径的人，往往在第一轮面试就被问住了。
不够。不能复现、不能评测、不能交接的提示词，在团队里等于零。可维护性才是工程的核心。
能，而且有优势。运营、客服、编辑、法务这些岗位的人更懂「什么算好结果」，而这正是评测的前提。需要补的是结构化表达和一点点工程常识，不需要从零学编程。
目前没有公认的权威认证。招聘方看的是作品集和实操，证书的权重很低。把时间花在做一个真实项目上，回报更高。
常见三类：① 现场把一个模糊需求改写成提示词；② 给一段输出，问你哪里有问题、怎么改；③ 让你设计一套评测方案。少数会考接口调用和成本估算。共同点是都在考判断力。
能读懂 JSON、会一次 API 调用、能用脚本批量跑 50 条测试，基本够用。再往上（做产品、做 Agent）才需要更系统的工程能力。
「只负责调措辞」的部分确实在被取代。「定义什么叫好、建评测、接进业务」这部分反而更重要了，因为模型越强，选错方向造成的浪费越大。
先学提示词。它是最小可用的抓手，一周就能见效，而且不管你后面走产品、运营还是开发，都用得上。
给自己定 20 条真实任务，写下合格标准（比如「必须包含数字」「不能出现没提供的参数」），每次改提示词都跑一遍，用表格记录通过率。这套方法一个人就能做。
影响不大。中文场景用中文写完全可以。涉及代码、学术术语时保留英文原词即可。真正需要英文的是读国外的一手资料，那可以用翻译工具辅助。