场景-知识-数据梳理及可行性评估

What（是什么）

“场景-知识-数据梳理及可行性评估”是“AI 产品 PoC 和 MVP 落地”阶段的 kickoff 实践。它标志着项目从“战略探索”正式转向“技术验证”。此实践的核心是，针对一个选定的AI场景，使用“场景-知识-数据模板” 等工具，从工程师可理解的粒度上，将其彻底分解为三个核心要素：

• 上下文 (Context)：AI进行判断时需要的、动态变化的即时信息。
• 知识 (Knowledge)：AI需要引用的、相对静态的背景信息或规则库。
• 数据 (Data)：AI需要查询或操作的结构化事实记录。

这次梳理是对前期探索成果的精炼和深化，其产出的三份核心清单是构建PoC（Proof of Concept）的技术蓝图，并在此基础上进行最后一次、更聚焦的技术可行性确认。

示例图片：

When（什么时候做）

• 在“AI场景探索”阶段结束后，正式启动一个具体场景的PoC之前：这是PoC阶段的第一个动作。
• 向开发和算法团队进行技术需求沟通时：这三份清单是比产品原型或PRD更有效的沟通语言。
• 需要为PoC准备最小数据集时：通过梳理可以明确PoC阶段需要准备哪些最核心的数据和知识。

How（怎么做）

第一步：PoC目标与范围对齐

1. 召开启动会：由 业务 PO/产品经理 召集协助的 数据团队成员 及AI开发/算法工程师，明确本次PoC要验证的核心技术假设和业务目标。
2. 聚焦最小闭环：从完整的“AI场景定义地图”中，选取一个能体现核心价值的最小交互闭环作为本次梳理的范围。

第二步：使用模板进行解构

1. 协作梳理：团队共同使用“场景-知识-数据模板”，对选定的交互闭环进行逐帧分析。
2. 回答关键问题：针对流程中的每一步，回答：
   • AI需要什么“上下文”才能理解用户意图？ （例如：用户当前所在的页面、最近三次的对话历史、选择的商品ID）。
   • AI需要查阅什么“知识”才能做出正确回应？ （例如：产品说明书、内部操作SOP、行业法规条款）。
   • AI需要读写哪些“数据”才能完成任务？ （例如：从CRM中读取客户信息、在订单系统中创建一条新订单）。

第三步：产出核心技术清单

1. 具象化清单：将上述讨论的结果，转化为三份具体的、可供工程师直接使用的清单：
   • 上下文清单：明确每个上下文变量的名称、数据类型和获取方式（如从前端传入）。
   • 知识清单：列出所需的知识文档/库，并评估其格式（PDF/Word/Wiki）和结构化程度。
   • 数据清单：明确需要访问的数据库表、字段、API接口等。
2. 关联数据资产：将这些清单与在探索阶段整理的“数据资产清单” 进行关联和校验。

第四步：最终可行性评估

1. 技术路径评估：基于梳理出的清单，AI工程师可以对技术实现路径做出更精准的判断（例如，知识的非结构化程度很高，可能需要复杂的文档解析和RAG方案）。
2. 资源缺口分析：明确当前的数据和知识储备与PoC所需的差距，并制定数据准备计划。
3. 风险识别：识别出关键的技术瓶颈或资源获取障碍，并制定应对预案。

实践Tips

✅ 最佳实践

• 粒度要细：清单的粒度必须足够细，以便工程师可以直接上手工作。例如，“用户数据”是不合格的，应细化到“user_profile 表中的 user_id, level, last_login_time 字段”。
• 区分知识和数据：“知识”通常是通用的、帮助AI做判断的背景信息（读为主），而“数据”通常是与特定用户/实体相关的记录（有读有写）。
• 考虑数据格式：在梳理知识和数据时，要特别关注其格式和可解析性，一个无法解析的PDF文档和一个结构化的API，实现成本天差地别。
• 版本化管理：这三份清单应作为核心技术资产，进行版本化管理。

⚠️ 常见陷阱

• 停留在业务语言：梳理的结果仍然是业务层面的描述，未能转化为技术团队可理解的语言。
• 与前期资产清单脱节：没有复用和校验在“场景探索”阶段盘点出的数据资产清单，导致重复工作或信息不一致。
• 低估知识工程的难度：认为只要有文档，AI就能自动学习。实际上，从非结构化文档中提取高质量知识是一个巨大的挑战。
• 忽略动态上下文：只考虑了静态的知识和数据，忽略了理解用户即时意图所需的动态上下文信息。

📋 输出物清单

• 上下文清单
• 知识清单
• 数据清单
• PoC技术可行性评估结论

相关工具

[待完善]

• 场景-知识-数据三元组梳理模板 (Excel/Miro)
• PoC数据准备计划 (Data Preparation Plan)

案例参考

成功案例：AI辅助医生诊断PoC

背景：希望验证AI能否根据患者描述，为医生提供可能的诊断建议。 梳理过程：团队通过SKD模板，将场景解构为：

• 上下文：患者在对话框中输入的实时症状描述（如“头痛、发烧3天”）。
• 知识：导入系统的《内科诊断学》教材、临床指南、药品说明书等知识库。
• 数据：需要查询该患者的电子病历，获取其过敏史、过往病史等个人数据。 结果：这份清晰的梳理让算法工程师能够立刻着手设计RAG（检索增强生成）的技术方案，并让数据工程师明确了需要准备和脱敏的数据范围，PoC得以高效启动。

经验教训：智能投顾机器人PoC

问题：项目启动时，只宽泛地定义了“需要行情数据和用户数据”。 结果：进入开发后才发现，所谓的“行情数据”需要通过付费API实时获取，接口调用成本极高，远超PoC预算；而“用户数据”中的关键风险偏好信息，只存在于纸质问卷中，无法直接使用。 启示：如果在PoC启动前，进行一次彻底的场景-知识-数据梳理，就能提前暴露这些数据和知识的可行性及成本问题，从而调整PoC范围或提前制定应对方案，避免项目进行到一半才发现关键资源不可用。