附录 A：场景卡模板
老板怎么用： 这是团队转型第一步就该交到你手上的「范围说明书」。你审批试点预算前，可要求 Agent 落地工程师和 AIBP 先填好这张卡——填不上的格子就是还没想清的地方，能早发现伪需求、防止项目范围蔓延和验收扯皮。
场景卡是 Agent 落地工程师的第一份交付物。 Kickoff 现场就能填，用来把「想做个 AI」这类模糊意图，收敛成一个可验证、可验收的 PoC 范围。填不满的格子，就是下一次和业务方对齐要问的问题。
怎么用
- Kickoff 会上和 AIBP（业务效果负责人）一起填，不要 Agent 落地工程师独自脑补。
- 空着的格子标
❓，作为需求共创的待办。 - 一张卡只描述一个场景；多个场景拆多张卡，再用附录 E 排优先级。
模板
| 字段 | 内容 | 说明 |
|---|---|---|
| 场景名称 | 一句话，业务能听懂 | |
| 提出人 / AIBP | 谁为业务效果负责 | |
| 业务 Owner | 最终对业务结果负责的人 | |
| 技术 Owner | 对 PoC 架构、集成和质量负责的人 | |
| 数据 Owner | 能授权、解释和维护数据的人 | |
| 决策人 / Sponsor | 能批准试点、资源和上线的人 | |
| 业务目标 | 降本 / 增效 / 提质 / 控险 / 增长，选一到两个 | |
| 现状痛点 | 现在怎么做、慢在哪、错在哪 | |
| 目标用户 | 谁来用、什么频率 | |
| 触发时机 | 什么时候会用到这个能力 | |
| AI 介入点 | 哪一步交给 AI，哪一步人工确认（见附录 B） | |
| 数据来源 | 公开 / 企业授权 / 知识库 / 业务系统 / 人工上传 | |
| 涉及系统 | CRM / ERP / 工单 / IM / 数据库 / API | |
| 权限边界 | 谁能看什么、能做什么、哪些动作必须人审 | |
| 验收指标 | 3–5 个可量化指标（见附录 D） | |
| 价值假设 | 「如果做成，能节省 X / 降低 Y / 提升 Z」 | |
| 风险与合规 | PII、采集频率、平台限制、幻觉风险 | |
| 数据就绪度 | 可获得 / 可理解 / 可用 / 可合规 / 可持续，各自红黄绿 | |
| PoC 范围（做） | 本轮明确要做的 | |
| PoC 边界（不做） | 本轮明确不做的，防止范围蔓延 | |
| PoC 停止条件 | 数据拿不到 / 无 Owner / 指标不成立 / 合规不通过等 | |
| 交付路径 | 课堂 Demo → 2 周 PoC → MVP → 生产 → 自主运营 | |
| 上线后运营指标 | 调用量、采纳率、失败率、成本、人工复核量等 |
已填示例（片段）：竞品与舆情洞察 Agent
| 字段 | 内容 |
|---|---|
| 场景名称 | 竞品价格与差评每日洞察 |
| 业务目标 | 增效 + 控险（响应更快、差评风险早发现） |
| 现状痛点 | 人工每天翻 6 个平台、信息分散、复盘难、漏看差评 |
| AI 介入点 | AI 采集+聚类+情绪分析+生成周报；人工确认风险预警是否上报 |
| 数据来源 | 公开竞品页面 + 平台授权评论样本 |
| 数据就绪度 | 可获得：绿；可理解：黄（分类口径待对齐）；可用：绿；可合规：绿；可持续：黄（采集失败告警待补） |
| 验收指标 | 报告生成时间、竞品覆盖率、评论分类准确率、风险预警命中率、运营采纳率 |
| PoC 边界（不做） | 不做自动回复差评、不接入内部定价系统 |
| PoC 停止条件 | 平台采集不合规、评论授权撤回、高风险样本漏报无法降到 0 |
本模板对应正文：第 6 章「一张卡钉死范围」。