互联网与软件技术
├── 业务研发主线
│ ├── 前端开发工程师（Web 侧）
│ ├── 后端开发工程师（Java／Python／Go）
│ ├── 客户端开发工程师
│ └── AI 应用工程师（提示工程方向）← 本篇
├── 质量与稳定主线
│ ├── 测试开发工程师
│ └── SRE 与运维开发工程师
└── 平台与治理方向（安全、架构、技术项目管理）
定位一句话：AI 应用工程师是把通用大模型能力"接进具体业务"的人——模型能力是别人训练的，但怎么问、给什么上下文、怎么验证结果好不好、怎么控制成本与延迟是这个岗位的活；它和算法岗的分界线很清楚：不训模型，但必须比任何人都清楚模型在业务里会在哪里翻车。
在业务研发主线中的位置：它与前端、后端、客户端同属"把能力变成产品"的一环，区别在于它的原材料是不确定的——传统代码给定输入就有确定输出，而模型的输出是概率性的。这份工作的大部分难度，都来自如何在这种不确定性之上建立工程可控性。
一句话定义：AI 应用工程师（提示工程方向）负责把大模型能力落地为可用的业务功能，通过提示设计与上下文工程、评测体系搭建、检索增强与工具调用编排、效果与成本监控，让模型输出在真实业务约束下稳定达标。
这个岗位最容易被误解为"就是写提示词"。实际工作中，写提示词只占一小部分；更重的部分是评测与迭代——没有评测集，提示的改动就是凭感觉调；没有回归机制，一次改动可能悄悄打坏另外五个场景。因此在成熟团队里，AI 应用工程师的第一产出常常不是功能，而是一套能跑的评测与回归机制。
职责边界（五类日常）
一、场景识别与需求拆解
判断一个业务需求适不适合用大模型做，把模糊需求拆成模型的输入输出契约。判断维度大致有四条：
- 容错率：输出错了会怎样？推荐一句话写歪了无伤大雅，合同金额抽错了就是事故。容错率低的场景必须配人工确认或强校验，不能直接自动执行。
- 数据可得性：模型需要的信息能不能稳定拿到？拿不到就别做——模型不会"不知道"，它只会编。
- 成本敏感度：单次调用成本乘以调用量，是否还在业务可承受范围内。
- 有无更简单的替代：大量需求本质是规则匹配或关键词查找，用模型是过度设计。能不用模型解决的，先用简单方案解决，这是成熟团队的常见共识。
这一步做错，后面全是白工——"这个场景该不该上模型"往往比"怎么调好"更考验判断力。
二、提示设计与上下文工程
系统提示与任务指令设计、少样本示例选取、结构化输出约束、长文本的切分与压缩、多轮对话的状态管理。
- 上下文的三要素：放什么、按什么顺序放、放多少。三者直接影响效果与成本。经验上，把最关键的约束放在靠近问题的位置、把无关内容删掉，效果改善往往比换模型更明显。
- 结构化输出：要求输出 JSON 等固定格式时，要同时给出格式约束与失败处理方式（解析失败怎么办、字段缺失怎么办）。不要假设模型永远输出合规。
- 日常迭代最频繁：这一块改动成本低、见效快，因此也很容易演变成"堆提示词"——没有评测兜底时，提示会越写越长、越来越难维护，最后没人敢改。
三、检索增强与工具编排
搭建知识库检索链路（切分、向量化、召回、重排）、设计工具调用与多步流程编排，让模型能拿到企业私有知识与实时数据并执行动作。
- 检索链路的关键在于切分粒度与召回质量：切得太碎会丢上下文，切得太大会引入噪音；只用向量召回常常漏掉精确匹配需求，通常要叠关键词召回再重排。
- 失败模式定位能力是核心技能：效果不好时，先判断是"召回没给到"还是"模型没用对"——前者改检索，后者改提示或模型。搞错方向会白费大量时间。
- 工具编排：多步流程要让每一步的输出可检查、失败可重试、越界可拦截，否则一个环节跑偏会一路传下去。
四、评测体系与效果迭代
建评测集（含边界与对抗样本）、定评价标准（人工评审与自动指标结合）、做版本对比与回归测试、分析错误类型并定向优化。
- 为什么它是分水岭：有评测，改动才是可比较的实验；没有评测，所有优化都只能凭感觉，且无法回答"这次改动到底是不是变好了"。
- 评测集怎么建：从真实业务问题里取样，覆盖典型场景、边界情况与已知容易出错的对抗样本；样本量不必一开始就很大，但必须能稳定复现问题。
- 错误分类：把错例按类型归类（知识缺失、指令误解、格式不合规、幻觉、超长截断），再定向处理。按类型治理的效率远高于逐个修。
- 回归：任何提示、模型或链路的改动，都要跑一遍既有评测集，避免"修好一个、打坏五个"。
五、上线监控与成本优化
- 监控：线上质量指标（命中率、人工修正率、用户反馈、会话完成度）与工程指标（延迟、错误率、限流触发）都要看。
- 合规与安全：异常输出拦截、敏感内容审查、日志与数据留存策略——这块随着业务规模上升会越来越重要。
- 成本优化：模型分级路由（简单请求走小模型）、缓存常见问题、批处理、精简上下文。业务方最终看的是单位成本下的效果，这项能力决定方案的生死。
一次模型功能上线的完整流程
- 场景评估——用上面的四条维度过一遍，明确要不要做、边界在哪；
- 原型验证——用最小成本跑通一个能看的版本，验证思路可行性；
- 评测集建设——从真实需求里取样建集，这一步常被压缩，但它决定后面能不能持续迭代；
- 迭代提示与链路——在评测上反复比较，记录每次改动的效果变化；
- 灰度上线——小流量观察真实表现，重点看线上分布与评测集分布的差异；
- 监控与回归——上线后建立反馈闭环，把线上暴露的新问题补进评测集；
- 成本复核——按真实调用量核对成本与延迟是否可接受。
真实项目里最常见的偏差是跳过第 3 步直接冲第 4 步：效果看着不错就上，上线后问题不断，回头补评测集时才发现连"原来哪些是对的"都没记录。
常见失败模式与排查顺序
模型功能出问题时，按以下顺序排查最省时间：
- 上下文里有没有该有的信息（没有 → 检索或数据问题）；
- 有信息但模型没照做（→ 提示的约束表达或示例问题）；
- 信息太多把关键内容挤掉了（→ 上下文精简或分段处理）；
- 输出格式不合规（→ 结构化约束与解析兜底）；
- 延迟或限流异常（→ 链路与容量问题，不是模型能力问题）。
先确认"喂进去的是什么"，再看"模型怎么答"——顺序反了，容易把数据问题误判为提示问题。
相邻岗位辨析
| 岗位 | 与之的区别 | 重叠区 |
|---|---|---|
| 07-人工智能与数据领域总览 | AI 应用与提示工程（07 领域同源岗位） | 07 领域从"AI 与数据"视角写，侧重模型侧与数据侧；本篇从"互联网与软件技术"视角写，侧重工程落地与业务交付；两篇互挂双链、独立成篇 |
| 算法工程师（NLP／CV） | 算法岗训练与微调模型，本岗使用现成模型；算法岗交付模型指标，本岗交付业务指标 | 评测方法、数据构造、效果分析 |
| 大模型应用工程师（模型侧） | 模型侧负责训练、微调、推理优化与部署，本岗负责调用与产品化；两者在提示接口与输出规范上协作 | API 契约、输出格式、上下文长度 |
| 产品经理 | 产品定做什么与做到什么程度，本岗定怎么做与能不能做；本岗需要在需求阶段给出技术可行性判断 | 需求拆解、成功指标、迭代排期 |
| 后端开发工程师 | 后端管服务、数据与稳定性，本岗管模型链路的逻辑与效果；工程能力是共同底座 | 服务架构、接口设计、监控告警 |
| 数据工程师 | 数据工程管数据管道与质量，本岗管知识与上下文的组织方式；检索增强的语料质量由两者共同保障 | 数据清洗、知识切分、数据管道 |
三组最容易混的场景：
- 本岗 vs 算法工程师：同一个"效果不好"，算法岗的解法是换模型、调参、补训练数据；本岗的解法是改上下文、补检索、加约束。分界判据是"你要改的是模型本身，还是用模型的姿势"。
- 本岗 vs 后端开发：功能上线后成了稳定性问题（超时、限流、并发），归后端与本岗共同处理，但重心不同：后端保服务不倒，本岗保模型链路在延迟约束下仍能给出可用结果（降级策略、超时兜底）。
- 本岗 vs 数据工程师：检索增强效果差时，两边都可能是原因。分界大致是：语料是否被正确采集、清洗、更新归数据侧；切分、召回、重排、上下文组织归本岗。不事先约定，容易互相等待。
判断口诀：问"你要改的是模型本身还是用模型的姿势"——后者是本岗；"你要交的是模型指标还是业务指标"——前者算法，后者本岗；"你要定的是做什么还是怎么做"——前者产品，后者本岗；"问题出在检索没给到还是模型没用对"——这是本岗日常排查的第一分叉。
不同落地场景下的重心差异
- 客服与知识问答：重心在检索质量与答案的可追溯性；"答不上来时要能转人工"和"答案要能指明依据"往往比答案本身更重要。
- 内容生成与改写：重心在风格一致性与合规审查，评测更依赖人工评审。
- 信息抽取与结构化：重心在格式稳定与字段准确率，容错率低，通常需要规则校验与人工复核。
- 流程自动化与多步任务：重心在每一步的可靠性与失败可恢复性，对工程能力的要求最接近传统后端。
- 分析与洞察：重心在数据接入与计算准确性，模型更多承担"把结果讲清楚"的角色。
入行与转出（公开口径）
- 背景：计算机、软件工程、人工智能、数据科学等专业最主流；也有语言学、新闻、法律、医学等专业背景的人从"领域专家＋AI 应用"切入，在垂直行业里优势明显。
- 前置知识：编程能力（Python 为主，含 API 调用与服务化）；大模型基本原理与能力边界（上下文窗口、幻觉来源、指令遵循特性）；检索与向量基础；评测方法论（指标设计与样本设计）；提示设计的常见范式；成本与延迟的基本估算能力。
- 面试通常怎么考察：偏重实操与判断——让你讲一个自己做过的模型功能，追问"怎么知道它变好了""错误怎么分类治理""成本怎么控"；也会现场给一个业务场景让你判断该不该用模型、怎么做评测。能说清评测与错误治理的人，明显比只会讲提示技巧的人更占优势。
- 常见入口：① 校招进互联网公司的 AI 应用或创新业务团队；② 从后端、前端、测试开发等转岗，补模型认知与评测方法；③ 从数据分析或算法助理岗转入；④ 从业务岗（运营、产品、行业专家）转入，凭场景理解力切入，需补工程能力。
- 适配画像：既愿意写代码、又能和业务方聊清楚需求的人；对"输出质量"敏感、愿意反复构造评测样本的人；能接受技术栈快速变化、把跟进前沿当成日常习惯的人。
- 三个常见认知误区：① 以为核心是"提示词技巧"——长期看，评测与工程能力才是护城河；② 以为效果不好就该换更强的模型——多数问题出在上下文与检索；③ 以为这行门槛低、可以速成——入门确实比算法岗快，但要做稳做久，需要工程与业务理解双线积累。
- 职业特点：热度高、入行窗口相对开放，跨专业转岗案例多；但技术迭代快、概念更替频繁，容易陷入"追新而根基不牢"，扎实的工程能力与评测能力才是长期护城河；纵向可向 AI 产品、技术负责人延伸，横向可转向垂直行业的 AI 落地岗。
- 转出方向：转 AI 产品经理、转技术负责人或团队管理、转垂直行业 AI 落地与解决方案、转数据与平台方向。