作者 / 来源：中智凯灵 / AiDD

——从 AiDD 上海站到 FDE 方法论：PoC 的目标不是把AI 演出来，而是把不确定性测出来

▼

过去一年，很多企业的 AI 项目都经历过同一个拐点。

Demo 阶段通常很顺：模型能读文档，Agent 能调工具，页面能生成报告，几分钟的演示足以让会议室里的人觉得“方向可行”。但到了下一步，问题很快冒出来：真实数据拿不到，业务口径不统一，用户反馈靠会议口头收集，评估标准说不清，系统权限不敢开放，流程也接不进现有工作方式。

项目没有马上失败，却也没有真正进入业务。它卡在一个尴尬位置：证明了AI 看起来能做事，却没有证明这项能力值得继续投入。

这就是企业 AI PoC 最容易掉进去的陷阱：PoC 被做成了演示工程。

在第 9 届 AI+研发数字峰会（AiDD 2026 上海站）的多场分享里，这个问题反复出现。AI 进入企业之后，瓶颈已经不只是“模型能不能做”，而是业务意图是否清楚、结果是否可验证、数据和知识是否可用、流程是否能嵌入、权限是否可控，以及上线后是否有人持续运营。

会后FDE 深度工作坊《AI 大模型时代的 FDE 转型实战》也把这个问题讲得很直接：大模型和智能体项目不是传统确定性软件项目，它会遇到需求涌现、输出概率性、技术快速变化、验收模糊等挑战。如果还用传统软件项目的方式来设计 AI PoC，就很容易得到一场顺滑演示，而不是一次真实验证。

图 1：FDE 深度工作坊《AI 大模型时代的 FDE 转型实战》：AI 项目交付面临需求涌现、设计返工、技术更新快、验收无止尽四类挑战（PPT 第 4 页）

所以，企业设计 AI PoC 时，第一个问题不应该是“这个智能体能不能做出来”，而应该是：“我们能不能用最低成本判断，它是否值得继续投入？”

PoC 的任务，不是证明技术很强，而是找到真实问题

很多 AI PoC 一开始就把顺序放反了。

团队先看到模型能力，再倒推应用场景：模型能读文档，于是做知识库；模型能写代码，于是做开发助手；Agent 能调工具，于是做流程助手。这些方向未必不对，但如果起点只是“技术能做什么”，PoC 很容易变成能力展示。

真正有价值的 PoC，应该先回到业务现场：谁在什么场景下被什么问题反复卡住？现在靠什么方式解决？成本在哪里？如果 AI 做得更好，哪个业务结果会发生变化？

AiDD 上海站关于 Spec Driven 和意图驱动交付的分享，也在提醒同一件事。兴云数科资深需求 AI教练郑涛在《意图驱动交付：Agent 时代从交付系统到交付价值的实践》中提出，需求正在从一次性的文字描述，转向可执行、可追踪的数字化资产。对 AI 项目来说，这意味着 PoC 的入口不能只是一句“我们想做一个智能体”，而要先把业务意图变成可验证的问题。

图 2：郑涛《意图驱动交付：Agent 时代从交付系统到交付价值的实践》：需求重塑，意图成为可执行的数字化资产（PPT 第 20 页）

这也是 FDE 与普通驻场开发的区别。FDE 不是等需求写完以后再排期，也不是只负责写代码和调 Prompt，而是要进入业务现场，和业务方一起把模糊想法拆成可运行、可验证、可迭代的 AI 能力。

图 3：FDE 深度工作坊《AI 大模型时代的 FDE 转型实战》：FDE 不是“驻场开发”的新名字，而是进入业务现场、转化业务意图、建立评估反馈闭环的复合型交付角色（PPT 第 7 页）

如果问题本身没有被定义清楚，后面的开发越快，偏差也可能来得越快。PoC的第一项产出，不该只是一个能点开的原型，而应该是一份足够清楚的业务场景说明：目标用户是谁，核心流程是什么，样本从哪里来，判断对错的标准是什么，哪些边界暂时不做，哪些风险必须提前暴露。

Demo 往往喜欢干净样本。

资料完整，字段规整，问题标准，答案唯一，流程没有异常。这样的样本适合展示能力，却不适合判断项目能不能落地。真实业务里通常相反：文档版本混乱，历史记录缺失，口径互相打架，用户提问模糊，系统权限复杂，异常场景比标准流程更能决定项目成败。

FDE 实践框架在“场景探索与 PoC”阶段提出，PoC 不需要一开始覆盖全部场景，但必须聚焦核心逻辑，处理 1-2 个典型 case，并向用户、BA或 AIBP 获取 2-3 个真实样本数据，用来验证基本逻辑是否正确。

图 5：FDE 深度工作坊《AI 大模型时代的 FDE 转型实战》：PoC 后进入周度迭代，用每周 Demo 和业务反馈推动智能体从 Alpha/Beta 走向可用版本（PPT 第 34 页）

这个机制的价值，不只是让团队“更敏捷”，而是让业务方持续参与判断。AI 输出具有概率性，业务方对“好不好”的判断也会在使用中变化。第一周觉得惊艳的能力，第二周可能暴露不稳定；第一次觉得没用的功能，换成真实数据后可能找到高价值切口。

小红书资深工程师林能源在《从跑分到护栏：AI Agent 可观测和质量保障体系》中也提到，Agent 落地的瓶颈正在从“能不能跑”转向“能不能评估”。这句话放在 PoC 阶段尤其重要：没有评估集、质量维度和 Bad Case 回流，项目很容易停留在主观试用。

图 6：林能源《从跑分到护栏：AI Agent 可观测和质量保障体系》：Agent 时代需要新的 Ops 范式（PPT 第 10 页）

因此，PoC 方案里要提前写清楚：谁每周看结果，谁提供样本，谁判断答案对错，哪些 Bad Case 要回流，哪些反馈进入下一轮迭代。没有这些安排，PoC 很容易从技术项目变成汇报项目。

不是每个 AI PoC 都应该导向上线。

这句话听起来有些反直觉，但它恰恰是 AI 项目管理里很重要的一点。AI 项目天然带有不确定性：有些场景业务价值不够，有些数据拿不到，有些合规风险过高，有些模型能力暂时不稳定，有些组织投入不匹配。如果没有决策关口，团队就会把“不该继续”的项目也拖进后续开发。

FDE 方法论把企业 IT 投资逻辑的变化讲得很直接：AI 项目需要从“大项目制”转向“小步快跑”，从“确定性规划”转向“探索性投资”，并设置 Fail Fast 决策关口。

图 7：FDE 深度工作坊《AI 大模型时代的 FDE 转型实战》：AI 项目需要从大项目制转向小步快跑，并设置 Fail Fast 决策关口（PPT 第 39 页）

这意味着 PoC 结束时，不能只给一个“演示成功”的结论。它更应该回答几个接近经营决策的问题：技术是否可行？数据和知识是否可持续获取？业务接口人是否愿意持续投入？合规和权限风险是否可控？业务价值是否足以支持下一阶段投入？

如果答案不成立，及时暂停、换场景、缩小范围、补数据、补知识库、补评估体系，都可能是 PoC 的合理结果。一个好的 PoC 不一定证明“项目一定能上线”，它也可以帮助企业更早知道“不该继续这样做”。

这类判断，比一次漂亮演示更有价值。

企业做 AI PoC，最后真正要判断的，不是有没有做出一个“智能体产品”，而是有没有可能形成一项可以持续运行的 AI 能力。

产品可以有界面、有功能、有说明书；能力则还需要知识来源、业务规则、样本集、评估指标、权限边界、反馈机制、版本记录和运营负责人。产品上线后可能没人管，能力上线后必须有人持续看、持续改、持续沉淀。

FDE 把生产级智能体拆成四个阶段：场景探索与 PoC、迭代交付与用户试用、持续优化与可配置化、自主运营与持续监控。这个拆法很清楚地说明，PoC 不是终点，而只是第一阶段。

图 8：FDE 深度工作坊《AI 大模型时代的 FDE 转型实战》：生产级智能体要经历场景探索、迭代交付、持续优化、自主运营四个阶段（PPT第 32 页）

如果一个 PoC 从一开始就没有考虑运营，后面大概率会卡住：业务方不知道怎么提反馈，技术方不知道怎么判效果，管理层不知道怎么衡量投入，系统出了问题也不知道谁负责。

所以，PoC 设计里至少要提前回答三件事：上线后谁运营，哪些指标持续看，错误和反馈如何进入下一轮优化。没有运营设计的 PoC，最多只能证明“做得出来”；有运营设计的 PoC，才可能证明“跑得下去”。

企业 AI 项目最怕的不是失败，而是不知道为什么失败。

一个被设计成演示工程的 PoC，会把不确定性藏起来：它避开脏数据，绕开真实流程，暂时不谈权限，也不建立评估和运营机制。短期看起来顺，长期反而会增加风险。

一个真正面向落地的 PoC，则会主动暴露不确定性：问题是不是真，样本够不够真，反馈能不能闭环，决策关口是否清楚，运营能力能不能接上。它不承诺每个项目都成功，但能让企业更早知道哪些项目值得继续，哪些项目应该调整，哪些能力需要先补。

这也是 FDE 在AI 时代重新被讨论的原因。FDE 不只是把模型接进业务系统的人，而是把业务意图、数据知识、智能体能力、工程实现、评估反馈和持续运营组织起来的人。好的 FDE 会把 PoC 做成一台筛选器：筛出真实问题，筛出可行路径，也筛出组织必须补上的能力。

主要参考资料

AI 项目 PoC 的故事，上海站只是开篇。

当企业从“试一试AI”进入“把 AI 放进真实业务”，更需要讨论的就不只是模型能力，而是场景识别、PoC 设计、评估护栏、组织协同和持续运营。

2026 年 AiDD 北京站，将在上海站的基础上继续关注 AI 研发、Agent 工程化、企业智能体和组织级落地。8 月 23-24 日的 FDE 专题实践，也会把这些问题带到更具体的业务场景里：如何识别场景，如何设计 PoC，如何搭建知识库和智能体，如何建立评估与反馈闭环，并把 AI 项目推向真实使用。

PoC 的目标不是让 AI 看起来能做事，而是让企业更清楚地知道：什么值得做，怎么做，以及谁来把它持续做下去。