跳到主要内容

AI产品与业务落地

核对日期：2026-05-13。

不稳定项：模型价格、企业采购政策、行业监管、AI 办公套件能力、SaaS 产品形态、数据合规要求和用户对 AI 的接受度变化较快；立项和采购前必须重新核对供应商条款、公司安全要求和适用法规。

1. 阶段目标​

本阶段目标是把技术能力转化为可采用、可验证、可治理的业务成果。AI 产品落地不是把模型接进产品，也不是做一个漂亮 demo，而是把 AI 能力嵌入真实工作流，并用明确指标证明它提升了效率、质量、收入或风险控制能力。

学完本阶段，你应该能做到：

  • 从业务流程中筛选适合 AI 的高价值场景。
  • 判断一个场景适合规则、传统 ML、RAG、Workflow、Agent 还是人工流程。
  • 设计 AI 产品 MVP，明确不做什么。
  • 计算 ROI：节省时间、提升质量、降低错误、增加收入和控制风险。
  • 设计 AI 产品体验：可编辑、可确认、可追溯、可回退、可反馈。
  • 评估 Build vs Buy：自研、采购 SaaS、使用平台、开源部署或混合方案。
  • 制定试点、灰度、培训、运营和治理计划。
  • 设计业务验收标准，避免“看起来聪明但没人用”。

本阶段的核心产出是：

  • 一份 AI 产品立项方案。
  • 一个场景优先级评分表。
  • 一个 ROI 测算模型。
  • 一个 MVP 范围和试点计划。
  • 一份供应商/自研决策表。

2. 学习前置条件​

建议已完成：

  • 08-AI应用工程，理解模型接入、前端体验和成本账本。
  • 09-Agent系统设计，理解 Agent 适用边界和工具风险。
  • 10-评测体系，能定义任务级验收指标。
  • 11-安全与治理，理解数据、权限、审计和供应商风险。
  • 12-LLMOps与生产化，理解灰度、回滚、成本和生产运营。

不要求：

  • 成为产品经理或咨询顾问。
  • 一开始就能做企业级 AI 平台战略。
  • 把所有 AI 项目都量化成精确财务模型。

3. 核心知识地图​

4. 详细讲义​

4.1 AI 落地的基本判断​

一个值得做的 AI 场景通常满足：

  • 高频：每天或每周发生，能形成规模价值。
  • 非结构化：涉及文本、文档、代码、图像、对话等。
  • 可验证：输出能被用户、规则、证据或评测集验证。
  • 可控风险：错误可发现、可撤销、可人工复核。
  • 数据可得：有样例、文档、历史记录或业务系统。
  • 工作流明确：知道 AI 输出会被谁使用、如何使用。

不适合优先做的场景：

  • 只是为了展示 AI。
  • 成功标准模糊。
  • 低频且价值低。
  • 错误不可逆。
  • 数据无法访问或质量很差。
  • 用户没有动力改变流程。

4.2 场景筛选矩阵​

用 5 个维度给场景打分，每项 1-5 分：

维度高分特征低分特征
业务价值节省大量时间、减少重大损失、提升收入只是体验新奇
发生频率高频重复偶发低频
技术可行性输入输出清晰，有数据和证据目标开放且不可验证
风险可控可人工确认、可回滚错误不可逆
组织可采用已有流程入口和负责人无 owner，无流程

优先级公式示例：

priority = business_value * frequency * feasibility * adoption / risk

风险不是越低越好。高风险高价值场景也可以做，但必须增加审批、评测和治理成本。

4.3 AI 方案选择：不要默认上 Agent​

问题类型推荐方案不建议
明确规则判断规则/配置LLM 自由判断
表格预测传统 ML直接聊天问模型
文档问答RAG只靠模型参数记忆
固定多步骤流程Workflow自主 Agent
开放多步研究Agent 或半自动 workflow单次 Prompt
高风险写操作AI 草稿 + 人工审批全自动执行

产品判断：AI 能力应该服务任务，不应该成为架构炫技。

4.4 从流程图开始，而不是从模型开始​

落地前先画当前流程：

谁发起任务
-> 输入是什么
-> 当前如何处理
-> 哪一步最慢/最容易错
-> 谁审核
-> 结果进入哪个系统
-> 失败如何处理

然后标出 AI 可介入的位置：

  • 前置理解：分类、路由、意图识别。
  • 信息收集：检索、摘要、抽取。
  • 草稿生成：回复、报告、代码、文案。
  • 审查辅助：风险提示、对比、校验。
  • 决策支持：解释数据和建议。
  • 自动执行：仅限低风险或经过审批的动作。

4.5 MVP 范围设计​

AI MVP 的目标是验证核心假设，而不是一次性做完整平台。

MVP 必须回答：

  • 目标用户是谁。
  • 具体任务是什么。
  • AI 输出如何被使用。
  • 成功指标是什么。
  • 哪些风险必须拦住。
  • 哪些能力暂时不做。

好的 MVP：

  • 场景窄。
  • 数据真实。
  • 有人工兜底。
  • 有评测集。
  • 有用户反馈入口。
  • 有成本和延迟记录。

坏的 MVP：

  • 做通用聊天助手。
  • 没有明确业务流程。
  • 没有验收指标。
  • 只做演示，不处理失败。

4.6 AI 产品体验原则​

AI 产品体验的核心是让用户保持控制权。

原则说明
可编辑AI 生成草稿，用户能修改
可确认高风险动作必须确认
可追溯关键结论有来源或证据
可回退错误结果可撤销或重做
可解释告诉用户依据和限制
可反馈用户能标记好坏和错误
可接管需要时转人工

AI 输出不要假装确定。对不确定内容要展示置信度、引用、缺失信息或建议下一步。

4.7 ROI 测算​

ROI 不只看节省人力。常见收益：

  • 节省时间。
  • 提升处理量。
  • 降低错误率。
  • 提升响应速度。
  • 提高转化率。
  • 降低培训成本。
  • 改善知识复用。
  • 降低合规风险。

成本包括：

  • 模型 token 成本。
  • 开发成本。
  • 数据整理成本。
  • 评测和标注成本。
  • 安全和合规成本。
  • 运维和监控成本。
  • 用户培训和变更管理成本。
  • 人工复核成本。

简化公式：

月收益 = 月任务量 * 单次节省时间 * 人力成本 * 采纳率
      + 错误减少带来的收益
      + 收入提升

月成本 = 模型成本 + 工程运维 + 人工复核 + 培训治理

ROI = (月收益 - 月成本) / 月成本

注意：很多 AI 项目前期 ROI 不确定，应先用试点验证关键假设。

4.8 业务指标设计​

指标要同时覆盖效率、质量、采用和风险。

类别指标
效率平均处理时长、等待时间、吞吐量
质量正确率、审核通过率、返工率
采用DAU、使用率、采纳率、留存
体验用户满意度、编辑距离、重新生成率
成本token 成本、人工复核成本、单位任务成本
风险安全拦截率、错误承诺率、越权尝试

不要只看调用量。调用量高可能是因为用户反复重试。

4.9 Build vs Buy​

方案优点缺点适用
采购 SaaS上线快、能力完整定制弱、数据和锁定风险通用办公/客服/销售
使用云平台基础能力强、合规选项多成本和复杂度中等企业级应用
自研应用贴合流程、差异化强工程和运维成本高核心业务
开源自托管控制强、可私有化维护和安全责任大数据敏感或定制强
混合方案平衡速度和控制架构复杂多团队、多场景

判断问题：

  • 这是核心差异化能力吗？
  • 数据能否给第三方？
  • 需要多深的流程集成？
  • 供应商是否支持审计和权限？
  • 成本随规模如何增长？
  • 退出和迁移是否可行？

4.10 供应商评估​

供应商评估维度：

  • 模型能力和评测结果。
  • 数据保留和训练政策。
  • 安全认证和企业协议。
  • 权限、审计和日志能力。
  • 私有化或区域部署能力。
  • API 稳定性和 SLA。
  • 价格透明度。
  • 集成成本。
  • 可导出数据。
  • 退出方案。

采购前必须做小规模试点和安全评审。不要只看演示效果和报价。

4.11 组织落地​

AI 落地经常卡在组织，而不是模型。

需要明确：

  • 业务 owner。
  • 产品 owner。
  • 技术 owner。
  • 安全/合规 reviewer。
  • 一线用户代表。
  • 运营和培训负责人。

推广步骤：

选场景
-> 小范围试点
-> 收集反馈和失败样例
-> 修复流程和产品
-> 培训关键用户
-> 灰度推广
-> 建立运营指标
-> 持续迭代

AI 工具改变人的工作方式，要给用户解释“为什么用、什么时候不用、出错怎么办”。

4.12 AI 产品治理​

治理内容：

  • 哪些场景允许使用 AI。
  • 哪些数据不能进入模型。
  • 哪些输出必须人工确认。
  • 哪些模型和供应商可用。
  • Prompt 和评测如何管理。
  • 日志和审计保留多久。
  • 事故如何响应。
  • 用户如何申诉和反馈。

治理不是阻止创新，而是让 AI 能持续上线和扩展。

4.13 从试点到规模化​

试点成功不等于规模化成功。

规模化需要：

  • 标准化 SDK 或平台。
  • 可复用评测集。
  • 成本预算。
  • 用户培训材料。
  • 安全和合规模板。
  • 运营仪表盘。
  • 支持流程。

从单点项目走向平台化时，要避免两个极端：

  • 每个团队重复造轮子。
  • 中央平台过度抽象，业务无法快速试错。

4.14 立项文档结构​

推荐 AI 产品立项文档：

# AI 产品立项方案

## 1. 业务背景
## 2. 当前流程和痛点
## 3. 用户和使用场景
## 4. AI 方案和非目标
## 5. MVP 范围
## 6. 技术方案选择
## 7. 数据、权限和安全边界
## 8. 评测和业务指标
## 9. ROI 测算
## 10. Build vs Buy
## 11. 试点计划
## 12. 风险和治理

5. 关键概念表​

概念含义工程/业务意义常见问题
Scenario fit场景适配度决定是否值得做 AI为了 AI 而 AI
MVP最小可验证产品快速验证核心假设范围过大
ROI投入产出判断是否持续投入只算 token 成本
Adoption用户采用决定真实价值只看调用量
Workflow integration流程嵌入让 AI 进入日常工作做成孤立工具
Human confirmation人工确认控制风险确认信息不足
Build vs Buy自研/采购判断平衡速度和控制只看报价
Pilot试点降低不确定性直接全量上线
Governance治理可持续规模化上线后才补
Change management变更管理用户培训和流程调整忽视组织阻力

6. 工程案例​

6.1 AI 客服助手​

目标：生成客服回复草稿，降低响应时间。

适合原因：

  • 高频任务。
  • 有知识库和历史工单。
  • 输出可由客服确认。
  • 可用采纳率和编辑距离评估。

MVP：

  • 只支持 5 类高频问题。
  • 只生成草稿，不自动发送。
  • 必须显示引用和政策来源。

风险：

  • 错误承诺赔付。
  • 泄露用户隐私。
  • 过度自动化导致客服不审查。

6.2 AI 代码 Review​

目标：辅助发现 PR 风险。

适合原因：

  • 输入结构化为 diff。
  • 输出可由开发者判断。
  • 可与 CI 结合。

MVP：

  • 只做风险提示和测试建议。
  • 不自动修改代码。
  • 输出文件路径、问题、影响和建议。

指标：

  • 有效问题命中率。
  • 误报率。
  • 开发者采纳率。
  • Review 时间变化。

6.3 AI 销售线索总结​

目标：从通话记录、邮件和 CRM 中生成客户摘要。

适合原因：

  • 非结构化信息多。
  • 销售需要快速了解上下文。
  • 输出可编辑。

风险：

  • 编造客户承诺。
  • 泄露敏感商业信息。
  • CRM 字段写入错误。

6.4 AI 内部知识库​

目标：回答制度、流程和技术文档问题。

适合原因：

  • 文档分散。
  • 新人学习成本高。
  • 答案需要引用。

MVP：

  • 只接入审核过的文档。
  • 支持拒答。
  • 记录未命中问题。

6.5 AI 数据分析助手​

目标：帮助业务人员查询指标和生成分析草稿。

适合原因：

  • 用户有自然语言问题。
  • 指标口径需要解释。
  • 输出可以被分析师复核。

边界：

  • SQL 只读。
  • 关键指标口径由系统提供。
  • 不直接做财务决策。

7. 常见误区与反模式​

反模式表现后果修正
为 AI 而 AI先选模型再找场景用户不用从流程痛点出发
Demo 即产品演示好看但无失败处理上线翻车做评测和异常路径
只算模型成本忽略标注、治理、培训ROI 失真全成本测算
忽略工作流做成单独聊天窗口使用率低嵌入原系统
无 owner技术团队自嗨无法推广明确业务 owner
直接全量上线无试点和灰度风险扩大小范围试点
采购后不运营买了工具没人用浪费预算培训、指标、治理
AI 直接替人决策无确认和复核合规风险人类在环
不收集失败样例问题反复出现无法迭代失败样例库

8. 阶段练习​

8.1 场景打分​

列出 5 个业务场景，按以下维度 1-5 分打分：

  • 业务价值。
  • 发生频率。
  • 技术可行性。
  • 风险可控性。
  • 组织可采用性。

选出最适合做 MVP 的一个，并说明为什么。

8.2 MVP 范围​

为一个 AI 产品写 MVP：

  • 做什么。
  • 不做什么。
  • 输入输出。
  • 用户流程。
  • 成功指标。
  • 风险边界。

8.3 ROI 测算​

为一个场景估算：

  • 月任务量。
  • 单次节省时间。
  • 人力成本。
  • 采纳率。
  • 模型成本。
  • 人工复核成本。
  • 预估 ROI。

8.4 Build vs Buy 决策​

比较自研和采购：

  • 上线速度。
  • 数据安全。
  • 定制能力。
  • 长期成本。
  • 供应商锁定。
  • 退出方案。

8.5 试点计划​

写一个 4 周试点计划：

  • 第 1 周：场景和数据。
  • 第 2 周：MVP 和评测。
  • 第 3 周：小范围使用。
  • 第 4 周：复盘和决策。

9. 项目任务​

9.1 项目要求​

完成一份 AI 产品立项方案。

必须包含：

  • 用户和业务场景。
  • 当前流程和痛点。
  • 为什么适合 AI。
  • 技术方案选择。
  • MVP 范围。
  • 数据和权限边界。
  • 评测集和业务指标。
  • ROI 测算。
  • Build vs Buy 分析。
  • 试点和推广计划。
  • 风险和治理方案。

9.2 立项方案模板​

# AI 产品立项方案

## 1. 一句话结论
## 2. 用户和场景
## 3. 当前流程
## 4. 痛点和机会
## 5. AI 方案
## 6. MVP 范围和非目标
## 7. 技术和数据方案
## 8. 产品体验
## 9. 评测和业务指标
## 10. ROI 测算
## 11. Build vs Buy
## 12. 试点计划
## 13. 风险、治理和回滚

9.3 评分标准​

维度分值标准
场景选择20高频、高价值、可验证、风险可控
产品设计20用户流程、确认、追溯、反馈清晰
技术判断15能合理选择 RAG、Workflow、Agent 或非 AI 方案
ROI15收益和全成本计算完整
落地计划15试点、灰度、培训和运营可执行
治理15数据、权限、安全、供应商和回滚清楚

10. 验收题​

  1. 什么样的场景适合优先做 AI？
  2. 为什么 AI 产品要从业务流程图开始？
  3. 如何判断一个场景应该用规则、RAG、Workflow 还是 Agent？
  4. AI 产品 MVP 应该包含哪些内容？
  5. ROI 除了模型成本还要计算哪些成本？
  6. 为什么采用率比调用量更重要？
  7. Build vs Buy 需要比较哪些维度？
  8. AI 产品为什么需要可编辑、可确认和可回退？
  9. 试点成功为什么不等于规模化成功？
  10. 组织落地通常会遇到哪些阻力？

11. 延伸阅读​

产品与落地资料​

建议阅读方式​

  • 先读 Google People + AI Guidebook，建立人机协作产品体验视角。
  • 再读 NIST AI RMF 和 OECD AI Principles，补足风险治理。
  • 最后结合自己的业务流程写立项方案，不要只做技术 demo。

12. 本阶段总结​

AI 产品落地的关键不是模型能力，而是场景选择、流程嵌入、用户控制、业务指标、组织采用和治理能力。一个好的 AI 产品让用户更快、更准、更可控地完成任务，而不是让用户猜模型到底能不能信。

你应该形成一个判断：AI 项目要先证明“值得做”，再证明“能做好”，最后证明“能持续运营”。下一阶段会进入综合实战项目，把前面所有能力整合成可展示、可评测、可复盘的作品集。