AI 应用与提示工程

人工智能与数据
├── 数据工程侧（大数据开发／数据治理／BI 与可视化）
├── 数据洞察侧（数据分析师）
└── 模型与策略侧
    ├── 算法工程师
    ├── 机器学习工程（MLOps）
    ├── AI 应用与提示工程 ← 本篇
    └── 推荐与搜索算法

定位一句话：这个岗位把大模型的能力"接进真实业务"——不训练模型，而是通过提示设计、知识接入、流程编排与效果评测，让模型从"能聊"变成"能干活、且干得可靠"。

与互联网与软件技术领域中同名岗位的分工：同一职能在两个领域都有落点。软件研发视角下（见 L2-互联网与软件技术-05-AI应用工程师提示工程方向|软件研发线·AI 应用工程师（提示工程方向））更强调系统集成与工程交付；本篇所在的模型与数据视角更强调模型能力边界判断、语料与评测数据、以及效果的可解释性。实务中两者常由同一批人承担，取舍取决于团队归属。

一句话定义：AI 应用与提示工程岗位负责基于预训练大模型的应用设计与效果优化，包括业务场景拆解与任务定义、提示与工作流的迭代、外部知识与工具的接入、评测集建设与效果验收、成本与响应速度优化，以及上线后的质量监控与风险控制。

职责边界（五类日常）

一、场景拆解与任务定义

把业务需求翻译成模型可承接的任务（抽取、分类、生成、对话、判定），明确输入输出格式、边界条件与人工兜底环节。

• 这一步决定成败：把"提升客服效率"翻译成"对用户问题做意图分类并检索标准答案"，与翻译成"让模型自由回答"，结果完全不同。前者可评测、可兜底；后者几乎无法验收。
• 该配人工的地方要配：涉及钱、承诺、法律与人身安全的场景，通常只让模型做"建议"或"初筛"，最终动作留给人工或规则。
• 切分粒度：一个能拆成五步的小任务，往往比一个"什么都能干"的大任务效果好、也更容易定位问题。

二、提示与工作流设计

编写并迭代提示，设计多步流程与角色分工，通过结构化输出约束与校验规则提升稳定性。

• 稳定的手段主要靠结构而非措辞：限定输出格式（按字段返回）、要求先给依据再给结论、把复杂判断拆成多次调用，通常比反复调整形容词更有效。
• 把经验沉淀成模板：反复调出来的提示要变成可复用模板，并记录"什么情况下失效"，这是这个岗位少有的可积累资产。
• 失败要有降级路径：模型不返回合法格式时怎么办、检索不到内容时怎么办，必须在设计阶段写清楚。

三、知识接入与工具调用

结合检索增强思路将企业知识库或公开资料接入流程，配置模型可调用的工具与数据接口。

• 检索质量决定上限：文档切分方式、召回数量、重排策略对结果影响极大，很多"模型答不准"实际是"没检索到"。
• 知识要有出处与时效：接入的资料要标明来源与更新时间，过期的知识比没有知识更危险。
• 工具调用要有权限约束：可调用的接口要限定范围与参数，避免模型触发不该做的动作。

四、评测与验收

建设覆盖典型与边界场景的评测集，定义准确率、召回、一致性、幻觉率等指标，用可复现的方式比较方案优劣。

• 评测集分三层：日常高频场景（保证基本盘）、边界与陷阱场景（保证不出错）、历史问题回归集（防止改旧坏新）。
• 不要只用主观感受：同一批问题、同一套评分标准、记录每次改动后的前后对比，才能说清"这次到底改好了没有"。
• 人工审核不可省：用模型评模型可以降低成本，但必须有抽样人工校准，否则误差会被系统性放大。
• 评测要绑定考点：每个用例应说明"它在考什么能力"，否则失败后无从改进。

五、上线运维与风控

监控线上效果与异常输出，控制调用成本与延迟，落实内容安全与隐私要求。

• 成本要从设计阶段管：调用量、上下文长度、模型档位三者共同决定成本；把"每次都要塞入的长文本"改为按需检索，往往是最有效的降本手段。
• 异常输出的处理：把输出送进人工复核队列、在界面提示可能不准确，都是常规做法。
• 风险方向性提示：要对幻觉、越权回答、提示注入保持警惕；防护依靠边界设计与审核流程，不提供任何绕过安全机制的做法。

模型选型时看什么

• 任务难度与稳定性要求：简单分类与抽取用轻量模型往往足够；复杂推理、长文档理解、多步规划需要更强的模型。
• 上下文长度与资料规模：要一次性读进大量材料，就要确认模型能承载的长度与费用。
• 成本与延迟：面向用户实时交互的场景，延迟是硬约束，不能只看单次调用成本。
• 微调还是检索：知识要更新、要出处 —— 走检索增强；风格与格式要稳定、任务形态固定 —— 可考虑微调；两者都需要的场景通常先做检索，再按缺口评估微调。
• 可替换性：把调用层做一层封装，模型换代时改动范围才可控。把业务逻辑硬绑在某一个模型上，是这个领域最常见的架构性风险。

与数据侧、算法侧怎么分工

• 数据侧：提供可用的语料、知识文档、日志与标注规范；评测数据的抽样与清洗通常需要数据侧配合。
• 算法侧：承接微调、模型评测方法、以及需要改模型行为的诉求；应用侧负责给出"错在哪、错成什么样"的具体样本。
• 容易扯皮的地方：效果不达标时，应用侧倾向说"模型不行"，算法侧倾向说"数据与评测集不行"。判定的抓手是评测集——谁的用例失败、失败类型是什么，比口头争论有效得多。

提示迭代的推荐顺序

按下面的顺序尝试，通常最省时间：

1. 先把输出结构定下来——按字段或模板返回，减少解读歧义；
2. 再补少量高质量示例——示例比形容词更能稳定模型行为；
3. 然后把复杂判断拆成多步——一次只让模型做一件事；
4. 再考虑换更强的模型；
5. 最后才评估微调。

顺序颠倒最常见的后果是：还没说清任务要求就换模型，最后既不知道问题在哪，也没建立可比较的基线。

相邻岗位辨析

三组最容易混的场景：

• AI 应用工程 vs 算法工程师：都要提升效果。分界是"改模型还是改用法"——调整提示、检索、流程的归应用；动训练数据、参数、微调的归算法。行业现实是：多数效果问题靠改用法就能解决，所以应用侧往往是第一道防线。
• AI 应用工程 vs 产品经理：都要定"做什么"。分界是"能不能做、怎么做才稳"——可行性判断与效果承诺通常由应用工程给。最典型的争执是"模型能不能做到 95% 准确"，正确回答方式是把场景与边界说清，而不是直接给数字。
• AI 应用工程 vs 数据分析师：都看指标。分界是"出结论还是出系统"——分析师的产出是一次性判断，应用工程的产出是持续运行、会被反复使用的功能。

判断口诀：调效果、写提示、建评测、接知识 → AI 应用与提示工程；训模型、调参数 → 算法工程师；建平台保部署 → MLOps；定需求定优先级 → AI 产品经理。

不同落地场景下的重心差异

• 客服与知识问答：重心在知识时效、检索质量与兜底话术，对"答不准"的容忍度极低。
• 内容与营销生产：重心在批量效率与风格一致性，人工审改通常保留。
• 研发与代码助手：重心在上下文的准确注入与结果校验，错误成本高。
• 数据分析助手：重心在口径正确与可追溯，最怕生成看起来合理但口径错误的数字。
• 流程自动化与办公场景：重心在稳定性与格式合规，单次效果不必惊艳，但必须每次都可用。

入行与转出（公开口径）

• 背景：专业限制相对更松，常见来源是产品经理、数据分析师、开发工程师、业务运营与咨询；这是一个新生方向，实践成果比学历与专业更有说服力。
• 前置知识：至少一门语言的基础编程或脚本能力（用于调用接口与做评测）＋ 对大模型能力边界的实际手感 ＋ 评测与实验设计的基本方法 ＋ 所服务业务的领域知识。
• 面试通常怎么考察：多为场景题与实操题——给一个业务场景问怎么拆、怎么保证稳定、怎么验收；也会追问"评测集怎么建""成本怎么控""失败了怎么兜底"。能讲清一次完整迭代的前后对比，通常比列举工具更有说服力。
• 常见入口：① 互联网或企业软件公司的 AI 应用团队；② 业务团队内部先做 AI 试点项目再转专岗；③ 从数据分析、产品、开发岗内部转岗；④ 通过公开可验证的个人项目建立能力证明。
• 适配画像：动手快、迭代快——这个方向的经验主要来自反复试验；能把不确定的效果用相对可比的指标说清楚；对成本与延迟等工程约束有意识；愿意持续跟进能力变化（这个领域的知识保鲜期很短）。
• 两个常见认知误区：① 以为"会写提示"就是核心能力——提示只是手段，场景拆解与评测才是门槛；② 以为效果不好就得换更强模型——多数时候问题出在任务定义与资料质量上。
• 职业特点：需求增长快、供给尚不成熟，是当前技术类岗位中机会相对集中的区域；风险也来自同一处——技术演进快、架构与惯例尚未定型，只停留在"会写几句提示"的人容易被工具与平台替代。可持续的路径是向"业务理解＋评测体系＋工程集成"三者结合的方向走。
• 转出方向：转 AI 产品经理、转算法工程（补建模能力）、转数据与智能化解决方案、转企业智能化转型的技术负责人。