先验证“能不能做”。
PoC 关注可行性：数据够不够、模型稳不稳、Agent/RAG 能不能处理关键任务，权限和安全边界是否说得清。
- 把业务问题和成功标准写清楚。
- 用小样本数据先测关键能力。
- 提前看性能、准确率、权限和集成风险。
PoC 与 MVP
用 PoC/MVP 把想法快速放到真实环境中去测试
企业里的 AI 项目会碰到权限、知识治理、内部系统、用户习惯、质量评估和运营责任。越早把这些问题暴露出来，后面越少走弯路。
再验证“业务会不会用”。
MVP 关注可用性：让真实用户进入一个最小工作流，看看效率、质量、采用率和维护成本到底怎么样。
- 围绕一个明确流程搭建最小版本。
- 让业务用户参与测试，而不是最后才验收。
- 给管理层一个可继续、可停止或可转向的判断。
典型 6 周
节奏不复杂，但每周都要回答一个具体问题。
听清问题
明确业务目标、流程瓶颈、用户角色、数据来源，以及这次先不做什么。
定好边界
确定验收指标、场景范围、样本数据、权限要求和 PoC 架构。
做出原型
搭建 Agent、RAG、知识库、工作流或数据分析 MVP，边做边校准质量。
让用户试
让目标用户试用，记录命中率、效率、体验、错误类型和采用阻力。
决定下一步
整理指标结果、风险清单和后续路线，判断继续做、改方向还是暂停。
不只讲方向，也不把工具丢给你就走。
我们会把业务判断、原型构建、团队共建和指标复盘放在一条线上。目标不是做一个漂亮 Demo，而是判断这件事能不能进入真实工作。
技术跟着场景走，不反过来。
- Agent
- 适合任务拆解、工具调用、流程编排和人机协同。
- RAG / 知识库
- 适合文档治理、检索策略、权限边界和答案质量评估。
- Workflow
- 适合审批、通知、记录，以及 CRM、ERP、协作系统衔接。
- 评估与安全
- 适合评估集、日志、敏感数据边界和人工复核机制。
适合先做 PoC 的场景
越具体的场景，越适合先试。
企业 RAG 知识库 PoC
把制度、案例、产品资料、项目文档和专家经验放进一个可检索、可问答、可更新的知识助手。
销售 / 客服 Agent
从线索跟进、客户问答、话术生成、工单摘要和知识推荐开始，看效率和准确率有没有提升。
运营与管理 Copilot
把周报、经营分析、数据解释、流程提醒和跨部门协作做成一个可运行的辅助流程。
内容生产与审核
先验证内容生成、资料重写、多渠道改写、事实核验和品牌口径一致性。
内部流程助手
从审批、查询、资料准备、会议纪要、任务分发这些高频流程里找小切口。
行业场景原型
制造、零售、B2B 服务、跨境、咨询服务等行业，都可以从一个具体流程开始。
验收指标
开始前就要说清楚：什么算通过。
| 指标类型 | 可观察指标 | 为什么重要 |
|---|---|---|
| 效率 | 人工节省时间、流程时长、首响时间、任务处理量。 | 看它是否真的减少等待、重复劳动和跨系统切换。 |
| 质量 | 回答准确率、命中率、错误类型、人工复核通过率。 | 看它在真实业务边界内是否稳定。 |
| 采用 | 目标用户试用率、复用率、满意度、反馈数量。 | 看业务团队是否愿意把它放进日常流程。 |
| 风险 | 权限问题、数据质量、安全边界、系统集成复杂度。 | 提前暴露规模化前必须解决的问题。 |
| 投入 | 实施周期、协作人力、外部工具成本、后续维护成本。 | 帮助管理层判断 ROI 和下一阶段预算。 |
FAQ
开始前，先把边界问清楚。
一定要接入企业内部系统吗？
不一定。第一阶段可以先用样本文档、脱敏数据或局部流程验证关键假设。如果系统入口和权限本身就是核心风险，那就应该纳入 PoC。
6 周里最多验证多少场景？
通常建议聚焦 1 个主场景和少数辅助流程。场景太多会稀释验证质量，也很难判断结果到底从哪里来。
PoC 成功后下一步是什么？
通常是扩大用户范围、补齐权限和运营机制、接入更多业务系统、建立评估集，再决定内部产品化还是进入更大规模实施。
哪些场景不适合作为第一批 PoC？
边界过宽、数据拿不到、业务负责人不明确、指标无法衡量，或者必须先做大规模底层改造的场景，都不适合作为第一批。