02 从三角PM到AI五角PM

专业解读

这张图片把商业目标、用户体验、技术可行、数据资产与模型能力放在 AI 产品经理周围，说明产品判断需要同时连接五个方面。不同角色分别掌握业务、使用、工程、数据和模型的信息，产品经理需要把这些信息组织成共同的目标、明确的取舍以及可以验证的结果。右上角的合规安全提示，进一步说明这些判断必须在适用的权限与使用范围内开展。

五个方面可以理解为一组持续检查的问题。用户是否需要这个结果，组织是否愿意为结果投入资源，工程是否能够稳定交付，数据是否适合当前任务，模型是否能够达到使用要求。每个问题都需要证据，并在产品研究、方案设计、开发测试和运营改进过程中持续更新。

一、商业目标提供产品工作的方向

图中的商业目标连接收入增长、用户规模和长期价值。产品经理需要理解组织当前希望改善的业务结果，并把目标转化为具体的用户任务。目标描述应说明服务对象、使用场景、预期变化和判断条件，帮助团队理解为什么需要开展这项工作。需求评审中，功能的重要程度也应结合目标和资源条件进行讨论。

商业负责人能够提供战略方向、价值判断和资源支持，产品经理需要主动核验这些信息对应的使用条件。对于面向机构的 AI 产品，还应理解采购决策、持续服务和系统接入过程。组织目标与用户任务连接得越明确，团队越容易识别当前应当解决的问题，并说明不同方案对业务结果的影响。

二、用户体验需要从完整任务观察

用户体验包含用户价值、产品体验和使用满意程度。产品经理需要观察用户在什么时间、什么环境下开展工作，怎样获取输入，怎样处理结果，以及怎样与其他人员协作。一个界面看起来简单，实际任务可能仍然包含多次确认、系统切换和信息核验。研究应覆盖这些连续过程，确认产品真正改善了哪个环节。

AI 交互还需要帮助用户理解输入要求、结果范围和确认责任。用户需要知道当前内容来自哪里、何时需要补充信息，以及哪些操作会影响业务系统。设计时可以结合实际工作流程提供编辑、确认、撤销和问题反馈能力，使用户能够有序完成任务。体验评价应同时关注任务结果、理解成本和错误处理过程。

三、技术可行性决定交付条件

图中的技术可行包含技术架构、工程成本和实施效率。产品经理需要与工程人员讨论系统边界、数据接入、权限控制、运行环境和维护方式，确认产品方案依赖哪些已有能力。每一项关键技术选择都应说明它服务的业务目的、需要满足的条件以及可能影响的质量指标，帮助团队共同判断可实施范围。

工程协作需要覆盖异常状态和持续运行。接口失败、输入不完整、模型响应过慢或业务系统状态变化，都可能影响用户任务。产品经理应说明用户能够看到什么、需要采取什么行动以及如何追踪处理结果。将这些状态纳入需求与验收材料，可以让工程实现与真实使用条件保持一致，并提高上线后的问题定位效率。

四、数据资产需要证明适用性

数据模块强调数据质量、规模和价值，连接数据采集、治理与分析工作。产品经理需要确认当前任务需要哪些信息，信息来自何处，是否具备适当授权，字段含义是否明确，以及内容能否保持更新。对于知识检索和内容生成，还需要关注资料版本、适用范围与来源可信程度，使模型得到符合任务要求的输入。

数据准备也需要形成可以检查的成果。资料清单、字段说明、更新责任、质量检查和访问权限，应当共同描述数据的使用条件。发现内容缺失或质量不足时，需要明确它会影响哪些用户任务以及如何处理。数据价值可以通过任务完成情况、信息利用情况和结果质量观察，帮助团队理解持续治理的必要性。

五、模型能力需要通过场景评测确认

图中的模型能力包含效果、泛化和持续进化。产品经理需要把业务任务转化为可验证的输入与预期结果，与模型团队共同确认成功条件、错误类型和适用范围。评测材料应覆盖实际用户会遇到的输入差异，记录需要人工确认的内容，使产品承诺具备明确的证据基础。

模型方案还需要与运行成本和响应时间一起判断。能够生成内容的模型，需要进一步确认内容是否适合当前业务、是否有可靠依据以及是否能够进入后续流程。对失败案例进行分类，可以帮助团队选择改进 Prompt、调整检索、补充数据或改变交互流程。持续评测应与每次产品变化结合，确保改进可以重复验证。

六、合规安全贯穿五个方面

图片列出了数据合规、隐私保护、法律法规、模型安全、内容风险和社会责任。产品经理需要与相关专业人员共同确定适用要求，确认数据访问、内容展示和业务操作的权限边界。产品使用范围、人员责任和审计记录应当进入方案设计与验收，使组织能够解释系统如何处理信息以及怎样控制重要操作。

在医疗工作场景中，尤其需要明确专业人员的判断职责和人工确认环节。不同场景对数据、审批和安全的要求，需要依据具体产品与适用地区核验。专业解读可以提供设计问题与检查方向，具体合规结论应由具备相应责任的人员确认。这样的协作方式能够让安全要求与产品流程共同进入日常工作。

七、产品经理通过取舍组织共同结果

五个方面之间经常存在需要讨论的条件。例如，用户希望缩短操作过程，工程需要可靠的确认步骤；业务希望扩大使用范围，数据与模型评测尚需补充材料。产品经理需要把这些条件说明清楚，展示各方案的价值、依赖、成本和风险，并组织有决策责任的人员共同确定实施范围。

取舍过程应保存判断依据与后续验证安排。团队需要知道采用了什么方案，在哪些条件下成立，哪些假设仍然等待证据，以及条件变化时由谁组织重新讨论。明确这些信息，可以减少重复沟通，并让设计、工程、数据和运营人员围绕相同目标安排工作。负责人还需要持续检查实际结果是否符合最初判断。

八、把五角能力转化为评审清单

需求评审可以围绕五个方面组织材料：商业目标说明预期价值，用户研究说明真实任务，技术方案说明交付条件，数据说明描述输入质量，模型评测说明输出能力。每一份材料都应有可追踪的来源和明确的责任人员。评审过程中重点讨论仍然存在的疑问，并形成具体的验证任务与完成条件。

上线后，五个方面仍然需要共同观察。产品经理应结合用户采用情况、运行质量、数据问题、模型失败和业务效果开展复盘，并与相关团队确认改进措施。长期保持这种共同判断过程，可以让产品能力随着使用证据持续提高，也能够让不同专业的人员理解自己的工作如何支持整体价值。