岗位分工：一个 AI 应用由谁完成
用知识客服串起产品、运营、Research、算法与开发，区分工作对象、交付物和岗位之间的联系。
01两条线，分别对什么负责
AI 团队可以先按工作重心分成两条线：非技术线主要是产品与运营，技术线主要是 Research、算法与开发。这里的“非技术”指主要交付物不是模型训练或软件代码，并不意味着不需要理解技术。产品需要判断模型能力能否支持用户任务，运营需要理解数据、质量和反馈怎样影响系统。
一个面向员工的知识客服可以同时涉及五类工作：产品定义员工遇到什么问题、怎样获得答案；运营整理业务知识、维护评价规则；开发连接登录、检索和模型接口；算法改善召回和答案质量；Research 则可能研究新的检索或推理方法。具体团队不一定设置全部岗位，同一人也可能承担相邻工作。
02产品与运营的分界，看改变了什么
产品工作的重心是决定系统应该提供什么能力，以及用户怎样使用。以“查报销规则”为例，需要明确适用员工、查询范围、资料出处、答案格式，以及问题涉及多个制度版本时的处理方式。需求文档、用户流程和交互原型服务于这些决定。
运营工作的重心是让业务内容、用户使用和质量过程持续运转。制度更新后哪些旧文档需要下线，员工反馈应该分到哪类，哪些问题需要交给业务专家复核，都可能属于运营工作。增长运营、内容运营与模型数据运营处理的对象不同，不能仅凭“运营”二字判断工作内容。
| 方向 | 主要对象 | 可见的工作结果 |
|---|---|---|
| AI 应用产品 | 用户任务与功能规则 | 需求说明、流程、验收条件 |
| 平台产品 | 开发者或企业配置流程 | 接口与权限规则、管理台方案 |
| 策略产品 | 搜索、推荐或自动化决策 | 策略定义、实验与效果分析 |
| 产品 / 用户运营 | 使用流程与用户反馈 | 引导内容、行为分析、改进反馈 |
| 数据 / 模型运营 | 知识、标注、评价样本 | 分类规则、数据质量与复核记录 |
03Research、算法、开发各自回答的问题
Research 关心一个方法上的问题是否成立：例如，补充文档上下文能否改善某类检索错误，效果在什么条件下出现。它通常需要文献理解、方法实现和有解释力的实验。算法更接近给定任务的效果优化，例如选择表示模型、调整排序方式、训练分类器或分析误差。两者可能高度重叠，区别要结合招聘描述中的研究目标和交付要求判断。
开发关心能力怎样成为可以使用的系统。知识库怎样更新，用户怎样认证，多个请求怎样处理，工具返回错误时界面显示什么，都是实际工作。AI 应用开发仍可能考查数据库、网络、数据结构和代码质量；接通模型接口只是系统中的一环。AI Infra 则更靠近训练、推理资源与服务基础设施。
04岗位名称相同，场景也可能完全不同
“AI 产品实习生”可能服务个人用户，也可能面向企业客户或公司内部员工。个人助手关注任务完成与使用体验；企业知识平台还涉及权限、数据接入和组织管理；内部提效工具需要理解员工原本的业务流程。C 端、B 端、内部应用是服务对象的划分，产品、算法、开发则是职责划分，这两组维度可以交叉。
读招聘说明时，可以用一句话还原岗位：“为谁，在什么场景，处理什么对象，产出什么结果。”例如“为企业员工设计知识问答流程，并组织问答质量验证”，与“训练检索模型提升专业文档召回”，虽然都涉及知识问答，工作的中心并不相同。
05五类岗位怎样共享一条反馈
假设员工反馈：“系统给出的报销上限不对。”产品确认用户所在地区、问题含义与正确的交互规则；运营检查制度版本和适用范围；开发查看实际传入的查询条件与调用过程；算法检查检索候选和排序；如果现有方法长期无法处理某类条件约束，研究工作才进一步讨论方法改进。
因此，岗位之间并非完全不互通。理解共同链路可以帮助协作，但承担哪部分工作仍需要对应的经验。了解 RAG 概念可以帮助产品与开发沟通，并不自动等于具备检索模型训练经验。