11 AI能力边界要画清

专业解读

这张图围绕大模型组织 Prompt、RAG、Agent、工具调用、记忆和评测六类能力，并把幻觉、数据质量、成本延迟和合规风险放在能力边界之外观察。下方的人工确认提示，说明重要结果与高风险操作需要明确人员责任。产品经理需要把这些能力放进具体任务，说明系统在什么条件下可以工作，以及怎样确认输出能够被使用。

能力边界应由真实场景证据支持。团队需要明确输入内容、资料条件、输出要求、质量标准和使用范围，并记录失败类型与处理方式。图中的技术模块提供讨论方向，具体方案还需要与业务、工程、数据和专业人员共同验证，使产品承诺与实际能力保持一致。

一、Prompt 需要说明任务与输出要求

Prompt 可以组织任务目标、必要背景、输入材料、处理要求和输出形式。产品经理需要从用户工作中提取这些条件，说明模型准备完成什么以及结果怎样进入后续流程。任务表达应采用清楚的业务名称，区分用户提供的信息、系统提供的资料与需要模型处理的内容，帮助团队检查输入是否完整。

Prompt 的效果需要通过实际任务评测确认。团队可以记录输入条件、预期结果和实际表现，观察任务表达变化怎样影响质量。对于需要稳定格式的输出，还应检查内容规则、字段含义和异常状态。持续保存设计依据与评测记录，能够帮助产品经理理解 Prompt 适合承担哪些工作，以及哪些要求需要其他能力共同支持。

二、RAG 需要检查资料与检索过程

图中的 RAG 用于检索外部知识。产品经理需要确认任务需要哪些资料，资料是否可信、具备适当授权并保持更新，以及检索结果怎样提供给模型使用。知识清单应说明来源、版本、适用范围和更新责任，让团队能够解释结果依据来自哪里，并检查资料条件是否支持当前任务。

检索质量需要单独验证。相关内容没有被找到、资料版本不适用或上下文组织不清楚，都可能影响最终输出。评测应观察检索结果与任务问题之间的关系，并记录模型是否准确使用资料。用户界面可以提供必要的来源信息与确认方式，使人员能够核验内容，并把发现的问题反馈到知识维护过程。

三、Agent 需要明确任务步骤与控制条件

图中的 Agent 关注多步骤任务规划。产品经理需要说明用户任务可以划分为哪些明确行动，各行动需要什么输入和权限，以及完成之后怎样判断可以继续。流程设计还需要记录状态、依赖和终止条件，使工程人员能够理解系统在不同情况下应执行什么工作。

多步骤任务的验证应覆盖整体结果与每个关键行动。团队需要能够追踪计划、工具输入、工具结果和重要判断，检查是否存在重复操作、权限不足或任务目标不清楚等问题。对于影响业务系统的行动，应明确用户授权与人员确认方式，让自动执行范围与组织责任保持一致，并在错误发生时提供清楚状态。

四、工具调用需要连接真实业务规则

工具调用可以把模型任务连接到查询、计算或业务系统操作。产品经理需要与工程人员明确工具承担的职责、输入要求、权限条件和返回结果，并说明它对业务状态产生什么影响。工具说明应使用清楚的名称和字段，使团队能够判断模型提出的操作是否符合用户任务与系统规则。

工具结果需要被验证和追踪。接口失败、参数不完整、目标对象不存在或状态已经变化时，系统应明确报告当前问题，并停止需要依赖该结果的后续行动。重要操作需要保留确认与审计依据，方便人员检查。把工具边界写进需求、测试和运行材料，可以减少不明确操作对业务结果造成的影响。

五、记忆需要限定上下文与保存范围

图中的记忆用于保留必要上下文。产品经理需要明确哪些信息服务当前会话、哪些信息属于持续任务状态，以及哪些内容需要经过授权保存。上下文设计应说明来源、有效时间、使用对象和更新条件，使系统在后续任务中能够准确理解信息，同时避免把不同用户或不同任务的内容混合使用。

记忆能力需要与数据权限和生命周期共同设计。用户修改目标、任务结束或资料发生变化时，应明确已有上下文如何更新与失效。涉及敏感信息时，需要与相关专业人员确认保存必要性和访问范围。评测可以检查系统是否使用了正确的任务背景，以及是否能够说明当前判断依赖哪些已保存信息。

六、评测需要定义真实场景中的质量

评测用于确认效果与能力范围。产品经理需要把用户任务转化为可检查的条件，说明怎样判断内容正确、依据充分、格式可用和流程完成。评测材料应覆盖重要角色、输入差异、资料条件和异常情况，并由具备相应责任的人员确认标准，让不同方案能够在共同口径下比较。

评测记录需要同时观察质量、响应时间、成本和人工处理工作。仅检查最终文本，可能无法发现检索、权限或工具操作中的问题，应根据任务流程保存必要证据。方案变化之后，需要重复检查相关场景，确认改进是否产生预期影响。持续评测能够帮助团队准确说明当前支持的使用条件，并组织后续改进。

七、风险边界需要进入产品流程

图片列出的风险包括输出不准确、数据质量不足、成本与延迟，以及隐私、安全和权限要求。产品经理应说明这些问题可能出现在哪些任务环节，影响哪些人员与结果，以及怎样发现和处理。风险讨论需要结合实际场景与专业责任，形成可执行的检查条件与处理安排。

对于无法满足质量或权限条件的输入，产品应清楚说明当前限制，并阻止不适当的后续行动。对于需要专业判断的结果，应设置明确的确认过程和责任人员。运行记录应支持问题定位，帮助团队判断错误来自资料、模型、工具还是流程条件，并把处理结果进入后续评测与需求更新。

八、人工确认需要明确责任与信息

人工确认应放在影响重要结果的位置，说明由谁确认、需要查看哪些依据以及确认后允许执行什么行动。用户需要能够理解模型输出的范围，查看必要的资料与操作记录，并有能力修改、拒绝或报告问题。确认过程应与具体岗位职责一致，使人员能够承担相应的判断责任。

设计完成后，产品经理需要组织业务、工程和专业人员共同检查能力说明、流程、评测和运行记录。每项产品承诺应能够找到证据，每项重要限制应能够进入用户体验与操作规则。持续维护这些材料，可以让团队在技术和业务条件变化时重新核验边界，并可靠地扩大已经得到验证的使用范围。