12 AI产品是一条工作流

专业解读

从业务场景确定工作流入口

这张白板图把 AI 产品画成一条连续的工作流：业务场景提供问题，知识库提供依据，检索负责选择相关材料，模型组织回答，工具执行动作，人工确认关键结果，最终输出进入用户的工作。这样的图示提醒产品经理，用户期待的是能够继续使用的结果。一个回答即使表达流畅，只要缺少来源、无法进入下一步操作，或者需要重新录入大量信息，就会增加工作负担。设计入口时需要说明用户当前正在完成什么任务、已经拥有哪些材料，以及完成任务之后准备把结果交给谁。

确定场景可以从一次完整任务开始记录。例如整理业务资料时，用户可能已经上传文档、选择客户和指定输出模板。产品经理应记录这些条件如何进入系统，哪些字段必须确认，哪些内容允许暂时缺失。入口还需要说明任务的责任人、截止时间和操作权限。对于无法满足条件的输入，应立即显示具体原因和可以执行的操作。任务开始之后才发现没有必要资料，会让用户重复投入时间，也会让后续模型处理缺少明确依据。

为知识库建立可以追溯的依据

图中的知识库承担证据来源的职责。产品经理需要关注材料来自哪里、由谁维护、适用于哪些业务范围，以及当前使用的是哪个版本。把文件集中保存只是基础工作；要让材料能够被正确使用，还需要处理重复文件、过期说明、权限分组和更新记录。某些资料适用于全部用户，某些资料只能由指定团队读取，检索过程必须遵守这些边界。页面展示引用时，应让用户能够打开来源并找到对应位置，减少核查成本。

知识更新需要明确触发条件。例如业务规则发生变化、负责人确认文档调整，或者用户发现引用内容已经失效，都应进入更新流程。更新后要重新检查与该材料有关的任务，确认已有结果是否需要提醒用户重新核查。产品经理可以建立资料清单，记录资料责任人、有效时间、关联场景和检查日期。这样能够把维护工作安排进团队的日常协作，减少知识库长期无人检查的情况。

让检索结果支撑模型处理

检索 RAG 位于知识库和模型之间。它的作用是根据当前问题选择有关材料，并把这些材料连同来源信息交给模型。产品经理需要检查问题表达、检索条件和结果覆盖范围是否一致。用户询问某个版本的操作方法时，系统应检索对应版本，不能把其他版本的说明混合使用。结果数量也需要根据任务确定：材料过少可能遗漏必要条件，材料过多可能增加处理时间和阅读负担。

检索质量可以通过真实任务检查。团队选择已经确认答案和来源的案例，核查系统是否找到必要材料、是否引入无关内容，以及引用位置是否准确。对于没有足够依据的问题，页面应说明资料缺失，让用户补充材料或转交相关人员。产品经理还应区分检索没有找到资料和模型没有正确理解资料这两类问题，因为它们需要不同的修正方法。只有明确问题发生的位置，后续改进才有具体目标。

给模型和工具分配清晰职责

模型适合完成信息整理、内容生成和基于材料的判断表达，工具则承担查询系统、写入业务记录或者执行其他明确动作。图中把两者分别呈现，意味着产品经理需要为它们制定独立的输入与输出要求。模型生成一份建议之后，工具是否可以执行，取决于业务规则和权限判断。不能仅凭语言表达中的肯定语气就启动具有实际影响的操作。

工具调用需要说明动作对象、必要参数、允许范围和结果检查方式。例如创建一条工作记录时，系统应确认记录归属、内容、执行人员和时间条件。用户确认之前可以查看拟执行的内容，完成之后可以核查实际结果。工具返回错误时应明确指出失败位置，不应继续显示已经完成。重复点击、网络中断和页面刷新也需要纳入设计，确保同一任务的状态始终能够被正确识别。

把人工确认安排在关键节点

人工确认需要出现在能够改变结果的地方。白板图将这个节点放在工具动作与最终输出的连接位置，强调具有重要业务影响的结果需要责任人检查。产品经理可以根据影响范围安排确认要求：普通文字整理允许用户直接修改，涉及权限调整、对外发送或者专业判断的内容，需要展示依据、操作对象和可能影响。确认页面应清楚说明将要执行什么，以及执行后用户如何检查。

确认过程还要考虑工作节奏。如果每个普通步骤都要求点击，用户容易形成机械操作，重要内容反而得不到充分注意。团队应根据任务风险确定需要确认的节点，并给这些节点提供充足信息。责任人无法立即处理时，任务应保持可识别的等待状态，其他人员不能随意代替完成。确认意见、修改内容和最终决定需要记录，方便后续追踪责任与改进流程。

让输出成为可以继续使用的成果

工作流的输出可以是一份文档、一条业务记录、一组待处理事项，或者一个已经执行的操作结果。产品经理应根据用户下一步工作设计输出形式。需要审核的内容应便于逐项检查，需要继续编辑的内容应保留结构，需要进入其他系统的内容应符合字段要求。页面还应显示引用来源、生成时间、任务状态和责任人，使用户能够判断当前结果是否适合使用。

以下检查表对应图中的主要节点，可以用于需求评审和验收讨论。每个节点都需要一个可检查的结果，前一个节点的输出应满足后一个节点的输入要求。评审时可以选择一项真实任务，沿着工作流逐项检查，记录用户需要额外补充的信息和人工操作。这样的检查能够发现流程连接处的问题，帮助团队判断产品是否真正完成了任务。

用日志和监控发现流程问题

图的下方连接日志监控、数据回流和知识更新，构成持续改进的路径。日志应记录任务在哪个节点开始、用了哪些材料、调用了哪些工具，以及最后获得什么结果。记录内容需要满足检查问题的需要，同时控制敏感信息的使用范围。用户反馈一个错误时，团队应能够找到对应任务和相关版本，核查问题发生在输入、检索、生成、执行还是确认环节。

监控指标应与任务结果关联。例如某个节点耗时增加，会影响用户完成工作的时间；某类检索结果经常被用户删除，可能说明材料选择不合适；工具失败之后没有明确提示，会导致用户误判任务状态。产品经理应把这些观察转成具体问题清单，安排负责人检查并记录修正结果。只展示调用数量或者生成次数，难以说明整个工作流是否帮助用户完成目标。

建立从反馈到修正的完整路径

工作流设计完成之后，需要持续收集真实使用中的问题。每一条问题应记录场景、输入条件、预期结果、实际结果和影响范围，再根据证据确定修正位置。资料缺失需要补充知识，检索条件错误需要调整查询方式，输出结构不合适需要修改需求，工具执行异常需要检查接口与权限。完成修正之后，应使用原有案例重新验证，并检查相关任务有没有受到影响。

对于 AI 产品经理，这张图可以成为跨团队协作的共同参考。需求讨论沿着节点说明职责，研发评审核查数据与状态，测试按照完整任务执行，运营收集用户完成工作的证据。每次版本更新都应说明哪些节点发生变化，以及需要检查哪些任务。工作流能够被追踪、结果能够被核查、问题能够被修正，产品才具备持续服务用户的基础。