AI 产品：从用户问题到产品机制
认识应用产品、平台产品和策略产品的工作差异，理解产品人员为什么要讨论模型边界、评测和成本。
与本章一起读的原文
方法 / 教程User Interviews 101个人面经AI 产品 · 业务一面 · Fauna_Blanc个人面经语音助手 · 策略产品 · Fauna_Blanc讲义为教学整理；个人经验反映作者当时的情境。查看完整导读与资料目录 →
01产品工作从场景开始
用户说“希望用 AI 提升效率”，还不是可执行的需求。需要继续确定：谁在什么情境下做什么任务，现有方式在哪里耗时或出错，AI 处理哪一段，结果由谁确认。功能名称是解法的一部分，场景和约束才决定解法是否值得做。
例如研究生需要整理文献，可能真正困难的是筛选主题、理解方法、追踪证据或制作汇报。它们对应不同产品流程。把所有材料放进聊天框并不能同时解决这些问题。
02同叫产品，服务对象可能不同
平台产品的直接用户往往是开发者或企业管理员；应用产品直接面对业务人员或消费者；策略产品围绕某个业务结果调整规则、模型使用方式和评测标准。一个岗位也可能覆盖多种对象。
| 类型 | 常见工作 | 需要读懂的信息 |
|---|---|---|
| 应用产品 | 对话、任务流程、反馈和异常处理 | 用户行为、任务成功率、模型局限 |
| 平台产品 | 工具配置、发布、权限、观察和计费体验 | API、知识库、工作流、开发者操作 |
| 策略产品 | 分流、排序、模型路由与评价口径 | 样本、错误类型、线上线下指标 |
| 行业产品 | 把领域流程转为可以落地的产品方案 | 业务规则、数据来源、责任和交付边界 |
03AI 产品多出的三个决策
第一是能力边界。生成结果具有不确定性，产品需要说明哪些回答必须有来源、哪些行为需用户确认、哪些失败交给人工。第二是效果定义。一次回答流畅，不代表事实准确或任务完成；评测应与用户要完成的事情对应。第三是资源约束。模型选择、调用次数、响应时间和费用会共同影响体验。
以自动回复为例，“可以生成文字”只证明接口可用；“能正确引用政策、处理信息不足并让人工接手”才描述了完整的服务机制。这些要求需要产品、运营和技术团队共同落实。
04JD 里的词怎样落到日常工作
“用户研究”可能是访谈与行为分析；“模型评测”可能是建立样本、制定判定规则、归纳失败类型；“推进落地”通常涉及需求澄清、设计研发协作和验收。遇到 Builder、AI Coding、Prompt 等词，应继续看是否要求独立原型、具体编程技能或工具使用。
判断实习职责时，把动作词和对象连起来读，例如“分析—用户反馈”“构建—评测集”“设计—工作流”。不要仅凭“AI 产品经理”标题推断岗位完全不涉及技术，也不要把掌握某一个工具当成全部产品工作。
05用户研究材料应该关注什么
访谈可以帮助了解用户如何完成任务，但“愿不愿意用 AI”这样的泛问很难说明产品需求。更有信息的材料是任务发生的情境、现有步骤、耗时点、例外情况和用户如何判断完成。观察实际过程，还能发现口头描述中遗漏的操作。
Google PAIR 从用户需要与 AI 的价值交点讨论问题选择；Microsoft HAX 提供人机交互准则与设计例子。两者适合补充“如何认识问题和系统行为”，再与岗位中的用户研究、流程设计和体验分析对应。
来源与延伸阅读
正文为教学整理与分析。下列公开资料用于核对概念、产品能力和招聘入口；具体岗位条件以原公告为准。
先读访谈与可用性测试的区别，再看研究目标、提纲、试访和追问。适合对照面经中“你如何发现用户需求”的问题。
产品读 UX for Language User Interfaces，开发读 LLMOps 和 askFSDL 项目讲解，再对照同一应用如何从界面走到上线。