ai-product-canvas

AI 产品画布技能

像做任何产品决策一样严谨地定义 AI 产品——但还要增加数据、模型、评估和负责任 AI 等层面。这份画布可避免最常见的 AI 产品失败：打造出技术上令人印象深刻、却没有解决实际问题的功能。

先检查 AI 产品反模式

开始构建之前，如果出现以下任一情况，请标记：

• ❌ “我们应该给[现有功能]添加 AI”——却没有明确的用户问题
• ❌ 开始构建前未定义准确率目标
• ❌ 没有计划应对模型出错的情况
• ❌ 面向用户的 AI 输出没有人工审核或备用方案
• ❌ 未审查训练数据是否存在偏见或质量问题
• ❌ 没有评估指标——“到时候我们自然就知道了”

---

AI 产品画布输出格式

AI 产品画布 — [功能名称] — [日期]

PM 负责人： [姓名] ML/AI 负责人： [姓名] 状态： 探索 / 设计 / 构建 / 评估 / 已上线

---

1. 问题定义

要解决的用户问题：

[用户处于什么具体情境？他们想完成什么任务？]

为什么使用 AI？

[为什么这个问题需要 AI，而不是确定性解决方案？如果答案是“因为我们能做到”，就到此为止。]

对用户而言，成功意味着：

[AI 功能正常运行时，用户会获得什么结果？]

---

2. AI 方法

任务类型：

• 分类
• 生成（文本、图像、代码）
• 摘要 / 提取
• 推荐
• 搜索 / 检索
• 预测 / 预报
• 对话 / Agent

模型方法：

• LLM API（GPT-4、Claude、Gemini 等）— 指明：[模型名称 + 版本]
• 使用自有数据微调的模型
• 从头开始训练的定制模型
• RAG（检索增强生成）
• 嵌入 + 向量搜索

选择该方法的理由： [为什么选这个，而不是其他方案]

---

3. 数据需求

数据类型	来源	数据量	质量状态	偏见风险
[训练数据]	[来源]	[数据量]	[审查状态]	高/中/低
[评估数据]	[来源]	[数据量]	[审查状态]	高/中/低

数据缺口： [缺少什么，以及获取计划] 隐私考量： [训练或推理数据中是否包含任何 PII] 数据所有权： [我们拥有这些数据吗？可以将其用于训练吗？]

---

4. 评估框架

主要指标： [定义成功的数值——准确率、F1、BLEU、用户评分、任务完成率] 最低可接受门槛： [低于 X 时，不发布该功能] 人工评估计划： [人类将如何审核模型输出？抽样率是多少？由什么评审小组负责？]

评估类型	方法	频率	负责人
离线（发布前）	[测试集、基准测试]	发布前	ML 负责人
在线（发布后）	[A/B 测试、用户反馈]	每周	PM + ML
对抗性评估	[红队测试、边缘情况]	发布前	安全审查员

---

5. 用户体验设计

如何呈现 AI 输出？

• 直接向用户展示输出（需要高度信任）
• AI 辅助，由用户确认
• 用户可接受或拒绝的建议
• 带审计日志的后台操作

置信度和不确定性的处理：

• 置信度较低时会发生什么？[显示替代方案、请求澄清、回退至手动处理]
• 如何向用户传达不确定性？[UI 模式]

备用方案：

• 如果模型失败或返回错误：[具体的备用行为]
• 如果准确率降至门槛以下：[紧急停用开关或平稳降级方案]

---

6. 负责任 AI 检查清单

• 已完成训练数据偏差审计
• 已评估人口统计公平性（不同用户群体的表现是否存在差异？）
• 已评估并缓解幻觉／虚构风险
• 用户可以查看并更正 AI 输出
• 提供退出机制（用户能否禁用 AI 功能？）
• 在相关情况下显示输出来源（用户是否知道内容由 AI 生成？）
• 未以用户未同意的方式使用 PII
• 已完成监管审查（GDPR、AI Act、行业特定法规）
• 已完成模型卡／文档

---

7. 发布与监控计划

逐步推出： [用户百分比，以及分阶段扩大的标准] 监控指标：

• 模型性能：[指标＋警报阈值]
• 用户对 AI 输出的参与情况：[采纳率、覆盖率、反馈评分]
• 错误率：[% 的推理失败率]
• 延迟：[P95 目标]

模型更新频率： [模型多久重新训练或更新一次？] 漂移检测： [如何判断模型在生产环境中的性能何时下降？]

---

指南

• 绝不要跳过“为什么使用 AI？”部分——这是 AI 产品开发中最重要的问题
• 备用 UX 并非可选项——AI 失效时会发生什么，决定了用户对产品的信任程度
• 负责任 AI 检查清单必须在发布前完成，而不是发布后
• 将延迟纳入成功指标——AI 响应若需 5 秒，往往还不如完全不用 AI
• 建议先采用有人参与的设计，只有在准确性得到验证后才进行自动化

必需输入

根据现有信息开展工作。如果缺少以下任何信息，仍须提供完整输出：用合理假设填补每处空缺，标记为 (假设，需确认)，并在末尾列出这些假设。只有在核心主题缺失（无内容可写）时才先提问。

• 功能或产品描述（AI 旨在实现什么）
• 用户问题（AI 要为用户解决什么问题）
• 可用数据（现有的训练／推理数据）
• ML／AI 负责人（负责技术实现的人）

反模式

• 不要跳过“为什么使用 AI？”这个问题——如果答案是“我们想用 AI”，就先停下来，围绕用户问题重新梳理
• 不要在未定义准确率阈值的情况下发布——“足够好”不是阈值；必须在开始构建前设定具体数值
• 不要设计隐藏 AI 生成内容的 UX，让它看起来像系统事实——用户需要知道何时涉及 AI，才能覆盖其输出
• 不要把负责任 AI 检查清单推迟到发布后——偏差和隐私问题在生产环境中比在设计阶段更难解决
• 不要把模型延迟视为发布后的优化事项——用 6 秒的 AI 响应取代 1 秒的基于规则的响应，是退步而非功能改进

质量检查

• 已清楚回答“为什么使用 AI？”（而非“因为我们做得到”）
• 已在开始构建前定义最低可接受准确率阈值
• 已明确规定模型失效或输出置信度低时的备用 UX
• 已完成负责任 AI 检查清单（未推迟到发布后）
• 监控计划同时包含模型性能和用户参与度指标

示例触发短语

• “构建 AI 驱动的功能。”
• “评估 LLM 集成。”
• “设计 AI 产品。”
• “评估 AI 准备情况。”