从 PoC 到生产——AI 项目的阶段性推进方法
从 PoC 到生产——AI 项目的阶段性推进方法
适读人群：做 AI 项目交付的工程师和项目负责人
阅读时长：约 22 分钟
文章价值：PoC→Pilot→生产的完整方法论 + 各阶段技术要求 + 技术债控制
PoC 成功了，生产失败了
我遇到过不止一次这种情况：PoC 演示非常顺利，客户拍板，然后真正做到生产环境，项目崩了。
最典型的一次：我们做了一个 RAG 系统的 PoC，用 20 份精选文档，GPT-4o，FastAPI 起一个简单的服务。演示的时候，准确率接近 95%，响应时间 2 秒，客户非常满意。
然后进入生产阶段。
文档从 20 份变成了 50000 份，格式五花八门；用户从演示时的 1 个人变成了 500 个并发；服务需要 7x24 小时可用；客户提出了一堆在 PoC 时没有被讨论过的需求：审计日志、权限管理、多语言支持、与现有系统的 API 对接……
PoC 花了三周，生产开发花了八个月，中间重写了两次。
这不是特例。AI 项目「PoC 成功 → 生产失败」是行业里众所周知的现象。2025 年的一些行业调研数据显示，有将近一半的 AI PoC 没能成功落地到生产。
为什么会这样？这篇文章来系统地回答这个问题。
PoC、Pilot、生产是三个完全不同的阶段
问题的根本在于：很多人把 PoC、Pilot、生产当成同一件事的三个阶段，实际上它们是三个完全不同目的的活动，技术要求截然不同。
PoC（Proof of Concept）的目的：证明「这个想法技术上可行」。
关键词：可行性。PoC 不需要生产就绪，不需要高性能，不需要安全审计，不需要考虑边界情况。它只需要在一个受控的、理想的环境里，证明核心技术路径通得通。
PoC 的合理时间：1-3 周。超过这个时间，要么是方向不对，要么是做过度了。
Pilot（试点）的目的：验证「这个方案在真实环境里解决了真实问题」。
关键词：有效性。Pilot 用真实用户、真实数据、真实使用场景，验证 AI 是否真的有价值。这里会发现 PoC 没有发现的问题：用户实际的使用方式、数据的真实质量、真实环境的限制。
Pilot 的合理时间：1-2 个月，控制在 50-200 个用户规模。
生产（Production）的目的：「可靠、安全、可扩展地为所有用户提供价值」。
关键词：可靠性。生产需要高可用、安全、性能、监控、运维、合规……所有「非功能性需求」都是生产的核心要求，但在 PoC 和 Pilot 阶段都可以先不做。
阶段模型：成熟度递进
注意我在「Pilot」和「全量生产」之间加了一个「有限生产」阶段。这是很多项目计划里没有的，但在工程实践里很重要——把新系统先对一部分用户开放，验证系统在真实生产流量下的表现，再全量放开。
PoC 阶段：快比对比重要
PoC 最常犯的错误是做太多。
工程师天然倾向于把东西做完整——既然做 RAG，就顺便把权限管理加上吧；既然做了文档解析，就顺便加个 OCR 吧……
这些想法都是合理的，但在 PoC 阶段是错误的。PoC 的价值在于快速验证，每多做一个功能，就多了一周的开发时间，多了一层复杂度，但对「是否可行」这个核心问题没有贡献。
PoC 的技术选型原则：用能最快跑起来的，不用最好的。
向量数据库用 FAISS（单机），不用 Milvus（需要部署）。 LLM 用 API（GPT-4o 或 Claude），不用自建推理服务。 后端用 FastAPI 或 Flask，不用 Spring Boot（除非团队只会 Java）。 数据用手工精选的 50-100 份，不用真实全量数据。
这些选择在生产阶段可能要全部替换，但 PoC 阶段它们让你一周内就有可以演示的东西。
PoC 的退出标准：核心场景的准确率达到一个「让业务方相信这个方向可以走」的水平。通常是 70% 以上的主观满意度。不需要 90%，那是生产的目标。
PoC 阶段要做的技术债记录
PoC 结束时，要做一份「技术债清单」，列出所有 PoC 里为了快速而做的妥协：
- 没有做权限管理
- 向量数据库是单机 FAISS，不支持高可用
- 没有做数据清洗，用的是精选文档
- 没有监控和告警
- 错误处理只有基础的 try-catch
这份清单在 Pilot 阶段开始前要和项目干系人对齐：「PoC 里这些都没做，接下来要做，这是时间和成本。」
不做这个对齐，后续阶段的工作量会让客户措手不及。
Pilot 阶段：用真实数据测真实假设
从 PoC 到 Pilot，最重要的变化是：数据变真实，用户变真实。
这两个变化会暴露出 PoC 完全看不到的问题。
数据质量的冲击
PoC 用的是精选数据，Pilot 用真实数据。两者之间的质量差距通常让工程师崩溃。
我有过这样的经历：PoC 用 100 份精心整理的 PDF，准确率 92%。Pilot 用真实的 5000 份文档（来自公司文件服务器），准确率掉到 61%。
原因：真实文档里有扫描件（OCR 质量差）、有格式混乱的 Word 导出、有过期文档混在有效文档里、有相互矛盾的内容、有大量和业务无关的杂文档……
所以 Pilot 阶段的第一项工作，通常是数据质量评估和清洗。这个工作量在 PoC 时是隐形的，到 Pilot 时才暴露出来。
用户行为的冲击
真实用户的使用方式，和你想象的通常不一样。
他们会用奇怪的表述方式提问；他们会期望 AI 记住上一个问题的上下文；他们会在系统边界处试探（比如问一些和系统功能无关的问题）；他们会对 AI 的回答方式有喜好（有人喜欢详细，有人喜欢简短）。
Pilot 阶段要建立用户反馈收集机制，每个回答旁边有「有用/没用」按钮，有问题可以标注。这个反馈数据是 Pilot 阶段最宝贵的资产。
Pilot 阶段的技术要求
PoC 可以没有监控，Pilot 必须有基础监控：
- 系统健康状态：服务可用率，请求成功率
- 业务指标：用户满意度（根据反馈按钮），日活跃用户，平均会话长度
- 性能指标：响应时间分布（不只是平均值）
没有这些数据，Pilot 阶段结束时无法判断「这个系统是否值得投生产」。
Pilot 的退出标准：
- 核心业务场景满意度 ≥ 80%（真实用户评价）
- 测量到了真实的效率提升（对比基线数据）
- 识别了所有主要的「失败模式」（知道 AI 在哪里不行）
- 技术层面确认了生产规模下的扩展路径
Pilot 到生产：最容易被低估的阶段
把 Pilot 系统直接推向生产，是另一个常见的错误。
Pilot 系统通常是「可以用，但不健壮」的。它缺少的东西，往往是一些「不出问题感觉不到，出了问题才知道有多重要」的东西：
高可用性
Pilot 期间允许系统偶尔挂掉，用户会理解（「这是在测试」）。生产环境不行，用户一旦认为系统不稳定，会放弃使用。
高可用的核心要求：
- 关键组件（LLM 调用、向量数据库）的超时和重试
- 降级方案：LLM 不可用时有备用方案（比如降级到关键词检索）
- 健康检查和自动恢复
安全性
Pilot 期间的安全要求很低，生产需要完整的安全评估：
- 输入验证：防止提示词注入攻击
- 权限控制：确保用户只能看到自己有权限的内容
- 数据脱敏：确保 AI 回答里不会泄露敏感信息
- API 安全：速率限制、认证、审计
这些在 Pilot 阶段可以先跳过，但生产上线前必须全部做到位。
观测性
生产系统必须有完整的可观测性：
// 生产级别的AI调用追踪
@Aspect
@Component
public class AICallTracingAspect {
private final MeterRegistry meterRegistry;
private final Tracer tracer;
@Around("@annotation(aiOperation)")
public Object traceAIOperation(ProceedingJoinPoint pjp, AIOperation aiOperation) throws Throwable {
Span span = tracer.nextSpan().name("ai.operation." + aiOperation.name()).start();
Timer.Sample sample = Timer.start(meterRegistry);
try (Tracer.SpanInScope ws = tracer.withSpan(span)) {
span.tag("ai.model", aiOperation.model());
span.tag("ai.operation.type", aiOperation.type().name());
Object result = pjp.proceed();
span.tag("ai.result.status", "success");
sample.stop(meterRegistry.timer("ai.operation.duration",
"operation", aiOperation.name(),
"status", "success"
));
return result;
} catch (Exception e) {
span.tag("ai.result.status", "error");
span.tag("error", e.getMessage());
sample.stop(meterRegistry.timer("ai.operation.duration",
"operation", aiOperation.name(),
"status", "error"
));
throw e;
} finally {
span.end();
}
}
}没有这些，生产环境出了问题，你不知道是哪里出了问题，只能靠猜。
各阶段的技术债控制
技术债是 PoC→生产过程中最难管理的问题。
PoC 阶段的技术债是必要的（为了快）。但如果不控制，这些债会复利积累，到生产阶段变成让整个项目卡死的负担。
我用一个简单的原则：技术债清单可以增加，但不能消失在记录里。
每个阶段结束时，更新技术债清单：
- 这个阶段偿还了哪些债（标记为已解决）
- 这个阶段新增了哪些债（注明产生原因和偿还计划）
- 对剩余技术债的评估：进入下一阶段时，这些债的影响是什么
哪些技术债必须在进入生产前偿还？
| 技术债类型 | PoC 可以有 | Pilot 可以有 | 生产必须解决 |
|---|---|---|---|
| 硬编码配置 | ✓ | 部分 | 必须配置化 |
| 无监控日志 | ✓ | 基础监控 | 完整监控 |
| 单点故障 | ✓ | ✓ | 必须高可用 |
| 无权限控制 | ✓ | ✓ | 必须实现 |
| 无速率限制 | ✓ | ✓ | 必须实现 |
| 无数据备份 | ✓ | ✓ | 必须实现 |
| 依赖精选数据 | ✓ | 逐步真实化 | 必须生产数据 |
一个具体的失败和修复
让我用一个真实案例说明技术债积累的代价。
我参与过一个企业知识库项目，PoC 三周，然后直接进入了「全量生产」（跳过了 Pilot 阶段，客户急）。
PoC 时的技术债：
- 向量数据库 FAISS 单机部署，无备份
- LLM 调用没有超时处理
- 没有速率限制
- 提示词硬编码在代码里
- 文档解析逻辑没有异常处理
上线一周后：
- FAISS 索引文件损坏（磁盘写入异常），所有文档要重新入库（8 小时离线）
- 高峰期用户增多，LLM 调用偶发超时，没有超时处理导致请求挂起，服务器线程耗尽，系统崩溃
- 一个用户发现了某个特定问法可以让 AI 泄露提示词（PoC 时没有做安全测试）
一周之内出了三个严重问题，紧急修复花了三周。
这三个问题，如果有 Pilot 阶段，都会在小范围内被发现，修复成本低得多。
阶段推进的决策模型
什么时候可以从一个阶段推进到下一个阶段？我用一套简单的检查清单。
PoC → Pilot：
Pilot → 有限生产：
有限生产 → 全量生产：
这个清单不是教条，可以根据项目情况调整。但每个点背后都有我在真实项目里学到的教训。
总结：速度的代价
PoC → 生产之所以失败，本质上是因为大家在赶，每个人都在压缩时间。
客户想早点见到价值；工程师觉得 PoC 已经证明了可行性，后面是体力活；项目经理要控制成本；所以 Pilot 阶段变短或者被跳过，技术债没有被认真管理，然后生产环境出了问题，修复时间是省掉的 Pilot 时间的两到三倍。
对速度的过度追求，最终导致速度变慢。
我现在见到「能不能跳过 Pilot」这种需求，会认真说「不建议」，然后把跳过的风险讲清楚。如果客户坚持，我把风险写进合同，这样出了问题责任清晰。
不是要对抗客户，是要让客户在有完整信息的情况下做决定。