AI Demo惊艳，但落地B端却频频翻车？问题不在模型，而在产品架构。本文提出五层架构：模型、知识、规则、系统、流程，教你如何设计可验证、可执行、可追责的AI产品，从“提示词设计者”升级为“任务系统设计者”。

一个AI Demo通常很容易让人兴奋。

上传一份材料，几秒钟后系统就完成了摘要；输入一句业务问题，模型迅速给出结构完整的分析；再说一句“帮我处理”，它甚至能规划出后续步骤。

但Demo进入真实业务后，问题会接连出现：材料版本已经过期，系统没有读取当前用户的数据权限，确定性规则被模型“理解”错了，结果只能停留在聊天框里，失败后也没人知道该从哪一步继续。

这类问题很难靠换一个更强的模型彻底解决。因为模型只是AI产品的一层。一个能够稳定进入B端业务的AI产品，至少还需要知识、规则、系统和流程共同工作。

产品经理要设计的不是“模型回答什么”，而是五层能力如何共同交付一个可验证、可执行、可追责的业务结果。

一、为什么“接个模型”只能完成AI产品的第一步

大模型最擅长处理开放性和非结构化问题：理解自然语言、提取信息、生成内容、归纳线索。它可以把原本难以写死在代码里的任务，转化为可处理的文本和决策候选。

但真实业务同时包含大量确定性要求。用户能看哪些数据、某个状态能否推进、字段范围是否合法、哪一版制度当前有效，这些都不能靠模型自由发挥。模型也不知道企业系统当前发生了什么，更无法凭空完成可靠回写。

因此，AI产品的基本结构应当是：模型负责理解和生成，知识提供依据，规则锁定边界，系统提供真实状态与工具，流程定义任务如何开始、交付和被接管。

二、五层架构分别解决什么问题

1. 模型层：处理不确定性，但不要承包所有判断

模型层负责把自然语言和非结构化材料转化为结构化理解。

例如识别文档字段、生成沟通草稿、把用户问题翻译成查询意图、从多条线索中归纳风险。

产品经理需要先拆分任务：哪些环节需要模型的泛化能力，哪些环节其实可以用普通程序稳定完成。把格式校验、数值计算、权限判断也交给模型，不仅成本更高，还会引入不必要的不确定性。

2. 知识层：让回答有依据，也让依据可维护

知识不是简单上传一批文档。

产品必须管理来源、版本、适用范围、更新时间和责任人。相同问题在不同组织、产品版本或时间段可能有不同答案，检索到“相关内容”不等于检索到了“当前可用的依据”。

因此，结果附近应展示关键来源和更新时间；关键知识变更要能够触发重建或失效；没有找到可靠依据时，系统应明确提示，而不是让模型根据常识补全。

3. 规则层：把确定性边界从概率模型中拿出来

规则层负责“必须正确”的部分。

必填项、金额范围、状态流转、数据权限、敏感词、对外承诺和审批条件，都应该由规则或程序执行。模型可以解释规则、提示如何调整，但不应自行改变规则。

这里最常见的产品错误，是把一大段制度文字放进提示词，然后要求模型“严格遵守”。文本约束可以改善输出，却无法替代确定性校验。只要错误影响较大，就要把关键边界做成可测试的规则。

4. 系统层：给AI真实上下文和边界清晰的工具

如果AI只能读取用户复制进来的信息，它很难理解当前任务的完整状态；如果它不能调用业务工具，最终只能告诉用户“建议去某个页面操作”。系统层的作用，是提供经过权限控制的数据与动作。

每个工具都应该有清晰的输入、输出、权限、幂等性和错误信息。查询与修改要分开，单条操作与批量操作要分开，生成待发送内容与直接发送也要分开。工具越通用，模型越灵活；工具越模糊，执行风险也越高。

5. 流程层：定义谁在什么时候承担责任

流程层决定AI如何真正进入工作。

• 任务由用户发起，还是由时间、状态或异常自动触发？
• 模型缺少关键数据时是追问、跳过还是转人工？
• 哪些步骤可以自动完成，哪些动作必须确认？
• 结果写入后谁负责复核？

如果这些问题没有答案，AI产品即使每次都能生成漂亮内容，也无法稳定交付业务结果。

三、三个通用场景，看看五层如何协同

场景一：从文档中识别信息并完成处理

模型负责理解版式、定位字段和识别内容；

知识层提供文档类型、字段解释和标准模板；

规则层检查必填信息、格式和操作权限；

系统层读取任务、保存结构化结果并调用后续工具；

流程层决定低置信度字段是否必须人工确认，以及失败材料如何退回。

只建设模型层，产品最多得到一份“识别结果”。五层协同后，用户得到的才是一个完成了校验、回写和异常处理的任务。

场景二：自然语言问数

模型负责理解问题并生成查询意图；

知识层维护指标口径、业务术语和维度定义；

规则层执行行列权限、敏感字段限制和查询范围；

系统层连接数据源、运行查询并返回可追溯结果；

流程层处理口径歧义、超时、无数据和结果分享。

如果没有语义口径和权限治理，问数产品越方便，错误扩散得越快。

场景三：生成并发送业务沟通内容

模型根据上下文生成草稿；

知识层提供当前政策和标准表达；

规则层限制敏感承诺、金额和禁用表达；

系统层读取历史记录、生成待发送内容并完成发送；

流程层根据风险决定直接发送、人工确认还是升级处理。

同一个模型输出，在内部提醒和正式对外承诺中应使用完全不同的自动化等级。这不是模型差异，而是流程责任差异。

四、需求阶段先写“任务定义卡”，不要直接写聊天框PRD

AI需求很容易从界面开始：在哪放入口、对话框长什么样、需要几个快捷指令。但界面确定之前，产品经理更应该完成一张任务定义卡。

• 任务目标：用户最终要完成什么工作，而不是要得到什么回答；
• 输入与上下文：需要哪些实时数据、文档、历史记录和用户补充；
• 知识依据：使用哪些知识源，版本和适用范围如何判断；
• 确定性规则：哪些校验、权限和红线必须由程序保证；
• 可调用工具：AI允许查询、生成、修改、提交或通知到什么范围；
• 人工介入：哪些节点需要确认，低置信度和冲突如何处理；
• 完成标准：什么结果才算任务完成，如何验证和回写；
• 失败策略：哪些异常可重试，哪些必须暂停、回滚或转人工。

这张卡片会迫使团队提前发现“模型之外”的缺口。很多看似AI效果不好的需求，真正缺的是指标口径、系统接口、业务规则或异常流程。

五、五层架构如何影响产品分工

五层架构不是技术团队的内部设计，它直接改变产品经理的协作对象。

• 与业务负责人确认任务目标、优秀结果和责任边界；
• 与知识负责人确认来源、版本、更新频率和失效机制；
• 与规则和合规人员确认硬约束、人工确认点和审计要求；
• 与研发梳理工具接口、权限继承、错误码、幂等、回滚和日志；
• 与运营建立反馈标签、问题复盘和持续优化机制。

产品经理不需要亲自实现每一层，但必须确保每一层有明确负责人，并且层与层之间的输入输出可以被验证。

六、验收时不要只测“回答对不对”

传统AI验收常常准备一批问题，检查回答准确率。五层产品需要更完整的验收。

• 模型层验收：关注意图识别、字段抽取、内容质量、稳定性和低置信度表达。
• 知识层验收：检查来源是否正确、引用是否完整、版本是否有效、无依据时是否停止推断。
• 规则层验收：验证边界条件、权限、必填、阈值、状态流转和敏感表达是否百分之百按规则执行。
• 系统层验收：验证工具调用成功率、数据一致性、重复执行、超时、重试、回滚和操作日志。
• 流程层验收：检查确认点是否合理、异常是否可接管、已完成步骤是否保留、结果是否进入后续流程。

一个回答准确率很高、但权限错误或无法回滚的产品，仍然不是合格的B端AI产品。

七、最常见的四种架构失衡

1. 模型很强，知识很乱：回答流畅，但引用过期、口径冲突；
2. 知识很多，规则缺失：看起来有依据，却仍可能越过确定性边界；
3. 模型和规则都好，系统不开放：AI只能建议，用户仍要重复操作；
4. 工具已经接通，流程没设计：正常路径能跑，异常时无人接管。

这些失衡会被误判成“模型不行”或“用户不愿意用”。产品复盘时，应该先定位问题发生在哪一层，再决定是调模型、补知识、加规则、改接口还是重构流程。

八、结语：AI产品的竞争力来自协同，而不是单点能力

模型能力仍然重要，但模型之间的差距会不断缩小。真正难以复制的，是企业如何把自己的知识、规则、系统和流程组织起来，让AI在清晰边界内承担任务。

产品经理需要从“提示词设计者”升级为“任务系统设计者”：既理解模型的可能性，也尊重业务的确定性；既追求更少操作，也设计可验证、可接管和可恢复的机制。

当模型、知识、规则、系统和流程被设计成一个整体，AI才不再是一段聪明的回答，而会成为真正能够交付结果的产品能力。