# AI 项目 POC 评估清单

> 用途：在投入资源做 AI 项目（RAG / Agent / 垂直应用）之前，判断「值不值得做」。
> 心法：先证明业务价值，再谈技术效果；先算成本账，再画大饼。

## 0. POC 基本信息

- 项目 / 场景：
- 提出方 / 决策人：
- 评估日期：

## 1. 业务价值（先于技术）

- [ ] 真实用户痛点明确（有访谈 / 数据支撑，不是拍脑袋）
- [ ] 一句话能说清 AI 带来的增量价值（省钱 / 省时 / 增收）
- [ ] 有可量化的成功指标（如：解决率 ≥ 70%、人工成本降 30%）
- [ ] 不用 AI，业务照常转——那这个项目还成立吗？

## 2. 数据资产

- [ ] 高质量数据存在（数量、格式、更新频率）
- [ ] 数据可访问（不在纸面上 / 老系统 / 个人电脑里）
- [ ] 数据隐私 / 合规允许使用（含脱敏）
- [ ] 效果天花板判断：这件事本身是否高度依赖「隐性知识」

## 3. 技术可行性

- [ ] 准确率 / 幻觉容忍度：业务能接受多高的错误率？
- [ ] 识别了「错误代价」：答错的损失 > 不用 AI 的损失吗？
- [ ] 老系统对接：API / 数据接口存在吗？改造量多大？
- [ ] 是否需要私有化部署（数据出域限制）？算力成本算过吗？

## 4. 成本账

- [ ] 一次性成本：开发、集成、数据治理
- [ ] 持续成本：token / 算力 / 维护（按真实用量估算）
- [ ] 对比人工成本：回本周期多长？
- [ ] 成本失控风险：有缓存 / 限流 / 降级设计吗？

## 5. 组织与落地阻力

- [ ] 业务方有「第一责任人」，不是技术单方面推动
- [ ] 使用方愿意改变流程（工具不做，人不变 = 白做）
- [ ] 验收标准双方共识（谁说了算、什么时候算成功）

## 6. 判定

- [ ] 值得做：__________________________
- [ ] 不值得做：________________________
- [ ] 缩小范围再做：____________________

## 7. POC 设计（决定做之后）

- [ ] POC 要验证的 1 个核心假设是：
- [ ] 通过标准（可量化）：
- [ ] 时间盒（建议 ≤ 2 周）：
- [ ] 验证后无论成败，复盘记录在哪里：