AI 工程师岗位与平台与基础设施工程师

• 薪资分布与市场供需的真实数据
• 职业天花板的稳定性与可预测性
• 岗位迭代速度与技术栈变化对职业发展的影响

AI 工程师的薪资在头部区间（结构性公司和模型公司、大厂 AI 团队）通常显著高于传统后端，尤其是在大模型爆发后的 2023-2025 年，供需缺口推高了薪资。但它的"不确定性"也更高：一方面赛道高度依赖技术热点（从推荐算法、NLP 到大模型、Agent），热点迁移会整体重定价；另一方面岗位边界模糊，模型应用、评测、数据工程等分类常交叉，导致同一"AI 工程师"头衔下薪资方差极大。传统后端工程师的上限相对稳定、可预测，拥有成熟的晋升阶梯和稳定的市场需求，但增长曲线平缓。因此 AI 工程师是"上限更高、但方差与波动更大"的选项，而传统后端是"稳健、可预期"的选项。

判断一个岗位优劣势不能只看平均值，还要看分布的离散度与时间的持续性。AI 工程师的溢价来自短期的稀缺性，稀缺性会随人才培养和工具化而稀释；而后端的价值来自长期积累的系统复杂度，不易被快速替代。回答时应既承认 AI 岗位的薪资红利，也指出其天花板的不确定性来源，体现辩证与理性。

• 应用 AI 工程师的核心职责（接入模型、构建应用、业务落地）
• 从需求到交付的完整链路
• 工程化落地与业务价值度量

作为应用 AI 工程师，我负责把大模型能力接入真实业务。曾有一次为客服系统构建智能问答，我首先梳理业务场景与数据，确定是用检索增强（RAG）还是直接调用模型；随后设计 Prompt 与上下文管理，接入向量库做召回，处理模型输出不稳定、格式解析失败等问题；再通过评测集（如准确率、引用正确率）衡量效果并迭代提示词；最后做工程化上线，包括限流、缓存、降级与监控。我的职责核心是"把模型能力变成可持续运行的业务能力"，而非训练模型本身。

应用 AI 工程师和传统后端工程师最大的区别在于"不确定性"——模型返回是概率性的，需要额外设计评测、错误处理与降级策略。回答应突出工程化思维、评测闭环与业务价值，而不是泛泛谈"调用了一个 API"。

• 特征工程、模型训练与评估
• 训练与推理的工程化（数据管道、模型服务）
• 模型指标与业务指标的关联

作为机器学习工程师，我曾负责一个推荐或风控类模型。工作分几层：数据侧，构建特征工程与训练数据管道，处理样本不平衡与数据泄漏；建模侧，选择模型、划分训练/验证集、调参并评估精召/曲线等指标；工程侧，把模型封装成在线服务，处理特征一致性与版本管理，做模型上线与回滚；最后把离线指标和线上业务指标（如转化率、坏样本率）对齐，持续监控漂移。ML Engineer 强调"让模型真正稳定跑在线上并产生价值"。

ML Engineer 与应用 AI 工程师的显著差异在于前者更靠近模型训练与特征工程，后者更靠近大模型应用编排。回答应体现数据管道、模型生命周期、线上一致性等工程细节，凸显"工程化"而非"调参"。

• 多 Agent 的角色划分与协作机制
• 工具调用链与工作流编排
• 记忆与状态管理的设计

作为 AI Agent Engineer，我曾构建一个多 Agent 协作系统。设计上，我会把任务拆分为规划（Planner）、执行（Executor）、审查（Reviewer）等角色，每个 Agent 有明确职责与工具集；工具调用链上，我设计了一套可发现的工具注册表与结构化调用协议，让 Agent 能拆解任务、依次调用搜索、数据库、代码执行等工具，并在失败时重试或回退；记忆上区分短期（对话上下文）与长期（向量知识库）记忆，状态管理则用任务状态机跟踪每一步的进度与结果；同时加入安全护栏，限制工具权限、敏感操作需人工确认，并用评测集检验任务完成率与越轨率。

Agent 工程的核心已从"调用模型"转向"编排自主决策系统"，涉及规划、工具设计、记忆、评测与安全。回答应体现系统架构思维，说明如何保证可观察、可回退、可评测，而非简单描述"让模型自己跑"。

• 两类岗位的能力差异
• 规划与任务分解能力
• 工具设计与执行环境

AI Engineer 的典型工作是"调用模型并工程化落地"，能力集中在 Prompt 设计、上下文管理、RAG、评测与部署；而 AI Agent Engineer 的核心是"编排自主决策系统"，需要额外具备：规划能力（把复杂目标拆解为可执行子任务并设计执行顺序）、工具设计能力（定义 Agent 可用的工具、参数与执行约束）、安全护栏能力（控制权限、防止越轨与误操作、设置人工确认点）、以及评测能力（对多步任务的完成度、工具调用正确率、安全性进行系统化度量）。这些能力使 Agent 工程师更接近"系统架构师"，而非"模型用户"。

问题本质是考察对 Agent 工程复杂度的理解。回答应指出能力模型从"确定性调用"转向"不确定性下的自主决策编排"，并逐一展开新增的四种能力，体现对自主系统风险的清醒认识。

• 需求增长的真实驱动因素
• 薪资水平与头部溢价
• 长期可持续性的判断逻辑

AI Agent 工程的需求增长主要来自企业从"用 AI 辅助"走向"用 AI 自主执行业务流程"，这类岗位需求在 2024-2025 年快速上升，薪资也处于 AI 工程师中的较高位置，尤其是具备端到端编排能力的工程师。但长期可持续性需要谨慎评估：一方面 Agent 能力会随基座模型与框架进步而增强，工具化（如各类 Agent 框架）会降低入门门槛，稀释部分岗位价值；另一方面，真正有价值的是一手业务场景、数据与评测能力，而非框架本身。因此可持续性取决于工程师能否沉淀到"业务理解 + 编排 + 评测安全"的复合能力，而非依赖单一工具。

对新兴岗位的评估应避免"只看当下热度"。回答应区分"短期红利"与"长期壁垒"，指出可持续性来源于通用能力与业务数据积累，而非框架与应用层技能，体现理性判断。

• AI 产品经理的职责边界
• 从需求到产品的能力定义
• 评测与迭代闭环

作为 AI Product Manager，我曾负责一个 AI 产品的定义与落地。核心工作是把模糊的业务需求转化为可工程化的产品需求：明确用户场景与痛点，定义产品能力边界（哪些用模型、哪些用规则、哪些人工兜底），设计评估指标（如回答准确率、用户满意度、成本），并评审模型效果与成本权衡。同时需要协调算法、工程、数据与业务多方，推动产品落地并依据用户反馈持续迭代提示词与数据策略。产品经理的核心是"把不确定的模型能力包装成确定、可用的产品体验"。

AI 产品经理与传统 PM 的差异在于必须理解模型的能力边界与不确定性，才能设定合理的产品预期。回答应体现"技术理解 + 产品定义 + 指标闭环"三位一体的能力。

• 平台工程师的职责（内部开发平台的构建）
• 面向开发者体验的能力
• 可复用性与抽象层的设计

作为平台工程师，我曾构建内部开发平台，为研发团队提供统一的构建、部署、环境与可观测性能力。工作包括：把分散的 CI/CD、环境管理与监控抽成标准化服务，提供自助式自助入口；设计统一的抽象层（如部署模板、配置规范），屏蔽底层基础设施差异；同时关注开发者体验（DX），提供文档、示例与快速上手路径，并回收使用反馈持续优化。平台工程师的价值在于"让其他人的开发效率更高"，即通过"平台化"减少重复劳动。

Platform Engineer 的核心是杠杆效应——通过构建可复用的平台提升整个组织的效率。回答应突出抽象层设计、开发者体验与度量平台使用率，而非单纯描述运维工作。

• LLM 应用的生产运维
• 成本、延迟、稳定性的持续优化
• 评测与可观测性

作为 LLM Ops 工程师，我负责大模型应用的线上稳定运行。工作包括：搭建对模型调用的可观测性（令牌消耗、延迟、错误率、输出质量），建立成本控制（缓存、模型分层、提示词压缩、批量处理）；设计降级与容错（模型不可用时回退到规则或小模型）；持续监控输出漂移与质量，配合评测集做回归；并做好模型版本管理与灰度发布。核心是让 LLM 应用在企业级场景下"稳定、可控、可度量、可优化"。

LLM Ops 是传统运维思想在 AI 场景的延伸，但多了一层"输出质量"这个不确定维度。回答应体现对成本、延迟、稳定性、可观测性的综合管理，以及与普通 SRE 的差异。

• 两类面试考查维度的差异
• 评测能力的重要性
• 模型与数据直觉

传统开发面试侧重算法题、数据结构和系统设计的确定性工程能力；AI 岗位面试则更侧重：评测能力（如何给模型效果建模、设定指标、做回归）、模型/数据直觉（预判一个方案在数据上是否有效、理解偏差与风险）、以及不确定场景下的系统设计（如何做降级、重试、缓存、人工兜底）。AI 面试常考察"面对概率性输出你会如何设计保障"，而传统面试考察"面对确定性需求你如何实现且高效"。两者都有系统设计，但 AI 的难点在于把不确定的模型行为纳入工程约束。

理解两类面试差异，本质是理解"确定性工程"与"不确定性工程"的区别。回答应具体点出评测、模型直觉在 AI 面试中的权重，并说明它们如何影响最终决策。

• 基础设施的设计与交付
• 稳定性、性能与成本
• 基础设施即代码与可观测性

作为基础设施工程师，我曾负责设计和维护支撑业务的基础设施。工作包括：规划云上网络、存储、计算资源，设计高可用架构（多可用区、负载均衡、故障转移）；用基础设施即代码（如 Terraform）管理资源配置，保证环境可复现可审计；搭建日志、监控、告警体系，保障系统可观测性；并结合业务容量做性能优化与成本控制（如合理装箱、弹性伸缩）。核心是把"顶层的可靠性与性能要求"落到"可维护、可扩展的底层环境"。

Infrastructure Engineer 与 Platform Engineer 相近但更贴近底层资源与稳定性。回答应体现基础设施即代码、高可用设计、可观测性与成本权衡，这些都是考察的关键工程点。

• 提示词工程的核心方法
• 结构化输出与约束
• 评测驱动迭代

作为提示词工程师，我曾负责把业务需求转化为稳定、高质量的提示词。工作包括：明确任务定义与输入输出格式，设计结构化提示词（角色、指令、约束、示例）；通过 few-shot 示例与说理（CoT）提升复杂任务表现；用结构化输出（如 JSON Schema）保证结果可解析；针对边界情况和幻觉设计约束与兜底；并用评测集对多个提示词版本做 A/B 对比，迭代优化。核心是"把不确定的模型输出稳定到满足业务要求的程度"。

Prompt Engineer 的关键不是"写一句魔法话术"，而是体系化的提示词工程与评测驱动。回答应体现结构化、示例、约束与评测闭环的方法论，避免把它描述成玄学。

• 云上架构设计与迁移
• 云资源管理与成本优化
• 云安全与合规

作为云工程师，我曾负责把业务系统在云上落地与优化。工作包括：设计云上架构（计算、存储、网络、数据库选型），进行资源容量规划与成本估算；使用 IaC 管理云资源，实现环境可复现；实施云上安全基线（权限最小化、网络隔离、密钥管理）；并对存量系统做成本优化（如按需/预留实例混合、存储分层、闲置资源回收）。核心是让业务在云上"稳定、安全、低成本地运行"。

云工程师强调多云架构、成本优化与安全合规的综合能力。回答应体现架构选型、IaC、成本治理与安全基线的闭环，展示从迁移到持续优化的完整价值。

• RAG 的链路设计（切分、向量化、检索、生成）
• 检索质量与生成质量的权衡
• 评测与迭代

作为 RAG 工程师，我曾为企业知识库构建 RAG 问答系统。工作包括：对文档做合理的切分（chunking）与元数据管理，设计向量化方案（Embedding 模型选型）；构建向量检索与重排（RRF、重排序）以提升召回准确率；设计查询改写与多路召回，处理"检索不到"与"检索不准"的问题；把检索结果与上下文拼接输入模型，约束生成引用来源；最后用评测集衡量检索命中率、答案准确率与引用正确率，持续迭代切分与重排策略。核心是"让模型基于可信知识回答，而非凭空生成"。

RAG 的难点在于检索质量，因为"生成质量的天花板取决于检索质量"。回答应体现切分、Embedding、重排、查询改写、引用溯源与评测的完整链路，突出工程优化而非单纯调 API。

• 技术布道与内容传播
• 开发者社区运营与反馈闭环
• SDK/文档/示例设计

作为 DevRel 工程师，我负责让开发者"用起来、用得好"一个产品。工作包括：技术布道（写技术博客、做分享、录制视频，把产品价值讲得清楚），设计 SDK 与示例代码（降低接入门槛，保证开箱即用），完善文档与快速上手教程；同时运营开发者社区，收集反馈、解答问题、组织活动，并把开发者的痛点反馈给产品团队形成改进闭环。核心是"既懂技术，又懂传播，成为产品与开发者之间的桥梁"。

DevRel 的核心是"技术能力 + 沟通传播 + 社区运营"的结合。回答应体现内容的专业性、示例的工程质量和反馈闭环，强调它的价值在于加速采纳与形成社区信任。

• IC 到 DevRel 的能力迁移
• 转型的薪资与职业路径
• 转型的适用条件与风险

从 IC（独立开发者）转型 DevRel，核心是能力迁移：保留极强的技术深度以保证内容可信，同时新增写作、演讲、社区运营等能力，把"把事做成"变成"把价值讲清楚并带动更多人使用"。薪资上，DevRel 通常处于技术岗与管理岗之间，资深 DevRel 薪资不低，但整体方差大，且高度依赖公司对开发者生态的重视程度；一些公司把 DevRel 视为成本中心，投入波动大。风险在于它较难量化个人贡献，且若技术停止更新，含金量会下降。适合技术强、表达好、享受建设外部影响力的人。

转型评估应看到 DevRel 的"价值放大器"属性与"可量化性差"的短板。回答应如实说明能力迁移、薪资上限与岗位不稳定性，避免只讲光鲜一面。

• AI 评测与红队的安全测试
• 攻击面与越狱测试
• 评测集与安全护栏

作为 AI Evaluator / AI Red Team，我负责评估模型的能力与安全性。工作包括：构建评测集（覆盖能力指标与安全指标），设计红队测试用例，尝试越狱、注入攻击、有害内容诱导等，探查模型的安全漏洞与越轨行为；通过对抗性测试找出训练与防护的薄弱环节，并给出修复建议（强化护栏、增加过滤、人工审核）；同时建立持续评测机制，防止模型迭代后能力回退。核心是"用攻击者的视角发现模型的风险边界"。

AI Red Team 的本质是"投射真实攻击场景"验证安全。回答应体现系统化的攻击面分析、越狱测试、漏洞归类与修复闭环，突出安全评测的专业性。

• IDP 的构建目标
• 自助服务与黄金路径
• 平台治理与度量

作为 IDP 工程师，我负责构建内部开发者平台，让研发团队能自助、标准化地完成从代码到上线的全流程。工作包括：定义"黄金路径"（标准化的服务骨架、CI/CD 模板、环境与配置规范），把常用能力封装成自助服务；管理模板与平台治理（权限、审批、合规），避免随意性带来的混乱；通过度量平台使用率、部署效率（如 DORA 指标）持续优化。核心是"用平台封装复杂度，让大部分团队走低摩擦的标准化路径"。

IDP 的核心价值是"开发者体验 + 标准化 + 治理"的统一。回答应体现黄金路径、自助服务、平台治理与效率度量，理解它不同于单纯的工具链堆砌。