AI POC 到底在验证什么？一份给金融 B 端 AI PM 的推进地图

刚开始接触 B 端 POC 时，它是一个很容易让人产生错觉的词。它看起来像一个小项目：客户提出需求，厂商准备数据、搭建方案、演示效果，最后做一次汇报。但真正参与推进时，很快会遇到一连串问题：客户只是想看看产品，还是已经进入采购选型？POC 要做到什么程度？准确率达到多少才算通过？业务人员、技术研发人员和双方负责人分别需要做什么？结果不错之后，是直接签约，还是还要补充验证？

这些问题之所以难，不是因为 POC 没有流程，而是因为大家经常把不同目的、不同完成度的活动都叫作 POC。

在国内金融软件采购中，POC 经常位于正式合作之前，并直接服务于产品和供应商筛选。中国银行的部分软件采购会安排符合资质的供应商参加 POC；光大证券的公开项目则会围绕性能、架构、功能和管理能力测试市场主流产品，并把测试结果作为后续合作的重要依据。但对于尚不成熟的 AI 场景，客户往往还没有完全确定问题边界、技术路径和人机分工，POC 也同时承担着场景与方案探索。

因此，本文不试图提供一套适用于所有公司的标准制度，而是站在金融软件厂商侧 AI PM 的位置，回答一个更实用的问题：怎样把一次模糊的客户需求，组织成一项能够支持正式投入决策的 AI POC？

对 AI PM 来说，这项工作可以归结为四个产品决策：验证什么、验证到哪里、什么算有效，以及结果如何进入正式产品或项目。后文的流程、指标、协作和交接，都服务于这四个判断。

AI PM 在 POC 中最重要的工作，不是推动一个 Demo 按时完成，而是把客户要作出的决定，转化为一条可信的验证证据链。

一、POC 到底是什么，又不是什么

POC 是 Proof of Concept 的缩写，通常译作“概念验证”。但“概念”并不一定是一项全新的技术发明，它也可能是一个业务场景、一种解决路径，或者某个产品能否适配客户环境的判断。本文所说的 POC，主要指：在完整解决方案正式采购、立项或全面建设之前，通过有限范围的验证，判断场景是否成立、方案是否可行，以及产品或供应商是否适配。

这一定义强调的是 POC 在决策链中的位置，而不是有没有签署任何合同。有些 POC 完全免费，有些会签订单独的测试协议或付费验证合同，但它们都不等于完整项目已经进入正式开发。

几个容易混淆的概念，可以按“当前要回答的决策问题”和“所处项目阶段”做一个工作层面的区分。下面不是统一行业定义，而是为了防止在本文中把展示、验证、正式建设和用户验收混为一谈。

微软的 POC 指南建议选择依赖最少的简单工作负载，同时在实施前定义目标和成功标准；而 UAT 通常位于正式系统部署前，用于从用户视角确认约定的业务场景能否正常运行。两者的区别，不只是完成度高低，而是要回答的问题不同。

可以把它压缩成一句话：Demo 展示“能做什么”，POC 判断“值不值得正式做”，UAT 验收“约定建设的东西是否可以接受”。

金融 AI POC 的特殊性在哪里

如果去掉“金融”和“AI”，本文的基本决策链仍然适用于多数 B 端软件 POC。标题保留这两个限定，并不是因为金融 AI 需要一套完全不同的流程，而是因为相同节点上的判断更重：金融数据与部署环境更敏感，高风险错误的代价更不对称，业务正确性更依赖领域专家和依据追溯，多厂商选型、能力边界与过程留痕也往往更正式。

AI 又进一步增加了概率性输出、样本代表性、模型与知识版本变化、人机复核边界等不确定性。因此，本文的通用骨架也能被传统软件 PM 使用，但后文对高风险错误、评测设计、可重复验证和正式项目交接的强调，主要来自金融 AI 场景。

这也意味着，POC 不应该追求完整产品，但不能把“不完整”理解为“不严谨”。页面可以简单，部分接口可以模拟，代码也未必能直接用于生产；但测试对象、样本来源、评测过程和结论边界必须说得清楚。

POC 可以工程轻，但验证不能虚。

二、一张图看懂 POC 怎样往前推进

整个 POC 可以先压缩成一条决策链：先明确客户要作出的决定，再定义验证内容和标准，确认条件后完成最小验证，最后形成是否进入正式投入的结论。

客户需求进入
    ↓
明确价值与决策目标
业务基线 / 价值假设 / 场景·方案·供应商
    ↓
定义验证内容
核心能力 / 硬门槛 / 比较指标
    ↓
验证条件是否具备？
业务人员 / 数据 / 环境
├─ 否：补条件、缩范围或暂停
└─ 是
    ↓
最小验证循环
实现 → 评测 → 失败分析 → 调整
    ↓
证据是否足够？
价值证据 / 核心能力 / 风险边界 / 实施适配
├─ No-Go：停止
├─ Adjust：补充或调整验证
└─ Go：进入后续决策
    ↓
正式投入决策
供应商选择 / 商务签约 / 正式项目定义

这张图不是开发排期，而是一条判断链。流程图只负责让读者知道当前在哪一关；每个节点具体看哪些维度、由谁提供判断，则放在后文展开。

业务价值在这条链中会出现两次，但含义不同。开始阶段需要先建立价值假设和业务基线，否则不知道为什么值得做 POC；评测阶段再用数据判断这种价值是否真的发生、幅度多大、代价如何。对于已经进入多厂商选型的成熟项目，客户通常已经认可项目层面的业务价值，POC 更侧重验证某个产品能否实现这份价值；对于尚未定型的 AI 场景，价值假设本身也可能是 POC 的验证对象。

图中虽然有六个流程节点，但从产品决策看只有四件事：前两个节点决定验证什么，验证条件与最小循环决定验证到哪里，证据判断决定什么算有效，最后一个节点决定结果如何进入正式产品或项目。

接下来，文章将沿着这张图逐步展开：先说明客户究竟想作出什么决定，再把决定翻译成验证标准，随后讨论怎样完成可信验证、怎样形成结论，以及结论如何进入正式项目。

三、客户究竟想通过 POC 决定什么

其中第一步不是列功能清单，而是先确认：客户最终准备根据 POC 结果作出什么决定？在金融软件场景中，通常包含三层判断。

场景与价值判断：这件事值得做吗

客户可能知道自己存在一个问题，却不确定 AI 能否真正改善它。

例如，证券公司希望降低营销材料的合规初筛成本，但还不知道：

• 大模型能否稳定识别关键风险；
• 它是替代人工审核，还是只做初步提示；
• 误报会不会反而增加工作量；
• 业务价值是否足以支持后续投入。

方案判断：这条解决路径走得通吗

即使场景值得做，不同方案也可能完全不同：

• 使用规则、传统模型还是大模型；
• 采用纯 Prompt、RAG，还是规则与模型组合；
• 只给出风险提示，还是同时提供依据和修改建议；
• 使用厂商云服务，还是部署在客户环境；
• 由 AI 自动处理，还是保留人工复核。

POC 需要识别的不只是“模型行不行”，还包括哪种人机分工和系统边界更合理。

产品与供应商判断：谁更适合承担正式项目

在成熟的软件采购中，这往往是 POC 最直接的任务。

光大证券公开的数据库同步、交易系统和安全管控平台 POC，会统一关注功能、架构、性能、管理和运维等内容，并要求厂商提供测试环境、测试方法、自测报告和金融行业案例。POC 结果不是一场孤立的技术演示，而是后续供应商评审和合作的重要依据。

AI 项目经常同时包含以上三层判断：客户一边比较厂商，一边也在借多家方案重新理解自己的需求。这里的判断并不都由厂商侧 AI PM 独自作出；更准确地说，AI PM 需要推动业务人员、技术研发人员和相关负责人共同给出答案，并把这些答案连接成一条能够支持后续决策的证据链。

四、怎样把客户的决定翻译成验证标准

客户说“效果要好”“回答要准确”“系统要智能”，并不等于已经有了验证标准。更合理的顺序是：先明确当前业务基线和希望验证的价值，再决定哪些结果属于硬门槛、比较指标或差异化能力，最后补充 AI 场景特有的评测与风险要求。

先明确业务基线与价值假设

业务价值需要在 POC 开始前被提出，但不能在开始前就被当作已经证明。前置阶段要说明当前业务基线、希望改变什么，以及客户为什么愿意为此投入；评测阶段再判断变化是否真实发生、幅度是否足够、实现它需要付出多少成本。对于成熟产品选型，重点通常不是重新证明整个项目有没有价值，而是比较哪种方案能以更可接受的成本和风险实现既定价值。

为了避免把“功能有效”误写成“业务有价值”，本文沿着价值从系统结果传导到业务结果的过程，归纳出四个观察层次：效率与质量首先发生变化，业务人员愿意把结果纳入流程，最后才可能形成经济回报。前一层成立，并不自动代表后一层成立；这四层也不是所有项目价值的完整清单，而是一条便于 POC 逐步验证的因果链。

这四层也是本文的归纳，并不试图覆盖所有业务价值。收入增长、客户体验、品牌风险等项目特有价值，可以映射到其中某一层或单独补充；关键是说明它们怎样影响后续投入，而不是为了完整性罗列更多指标。

在数据条件允许时，可以做一版方向性测算：年化净价值约等于年处理量乘以单笔节省时间和人工成本，再减去软件、部署、运维以及新增复核治理成本。但对风险损失、品牌影响等难以可靠货币化的收益，不应为了得出漂亮 ROI 强行换算成人民币；它们更适合作为硬门槛或风险判断单独保留。

例如，在合规预审场景中，业务价值至少要同时观察审核时间和人工复核负担。如果模型提升了风险召回，却产生大量误报，业务人员可能花更多时间排除无效提示，技术指标提高并不等于业务价值成立。

总准确率也会把不同错误平均在一起，但金融场景中的错误代价并不相同。十个普通问题的正确，未必能抵消一个关键合规风险的漏检。POC 因此需要同时关注平均表现和高风险失败，而不是只追求一个漂亮的综合分数。

中国人民银行发布的《人工智能算法金融应用评价规范》将人工智能金融应用的基本要求、评价方法和判定准则纳入统一框架；国家金融监督管理总局在 2026 年发布的银行业保险业人工智能安全开发应用指导意见，则进一步强调治理架构、数据治理、风险分类分级、人工监督和全生命周期管理。它们并不直接给出某个 POC 的分数线，但说明金融 AI 的判断天然不应被压缩成单一效果指标。

再区分硬门槛、比较指标与差异化能力

为了让测试结果能够真正支持后续决定，本文按照指标在决策中的作用，将验证标准归纳为三层：先判断有没有继续参与或建设的资格，再比较不同方案的相对表现，最后识别可能影响合作选择的额外价值。这是本文的工作框架，不是统一的行业标准；同一项能力在不同项目中也可能从比较指标升级为硬门槛。

例如，在证券营销材料合规预审场景中，客户真正想验证的，不应该只是“模型能不能识别违规内容”，而可以表述为：

在限定类型的营销材料中，AI 能否帮助合规人员减少基础筛查时间，同时把预先定义的关键高风险漏检控制在可接受范围内。

三层标准可以这样落到具体场景：

AI POC 还要增加哪些验证内容

AI POC 和传统软件 POC 共用同一条基本流程，差异主要不在“多了哪个阶段”，而在同一阶段要验证的对象发生了变化。下面沿着需求、数据、实现、评测、风险和交接六个环节进行对照，目的是突出 AI 带来的增量问题，并不意味着传统软件的结果完全确定、无需业务判断。

因此，AI POC 不需要另造一套生命周期，但需要在验证标准、样本设计、失败分析和结论边界上投入更多精力。AI 改变的主要不是 POC 的流程，而是每一步需要证明的内容。

五、怎样做一个最小但可信的验证

POC 最容易走向两个极端：一种是把它做成 Demo，只挑选少量成功样本，现场效果很好，却不能代表真实业务；另一种是把它做成免费项目，需求不断扩张，提前建设正式权限、全部接口、管理后台和生产部署，最后投入越来越大，仍然没有明确结论。合理的 POC 应该同时做到两点：范围足够小，证据足够真。

先划定最小验证范围

一次验证能否成立，至少取决于四个组成：做什么、在什么条件下做、用什么证据输入、怎样判断结果。因此，下面不是按部门或技术模块分类，而是按一套验证系统的交付范围、运行条件、证据输入和判断方法来划分。只有与正式长期运行相关、但不影响当前结论的内容可以后置；一旦省略会改变结论的内容，就不应以“这只是 POC”为理由跳过。

如果客户正在选型一款成熟标准产品，验证对象会比方案探索更完整。标准功能、架构、部署、运维和行业案例本身就是客户准备作出选择的依据，不能因为“这只是 POC”而全部省略。POC 真正避免的是：为尚未决定的正式项目，提前承担与当前判断无关的定制建设成本。

再控制证据失真

验证结果最常被四个位置扭曲：测试对象不同、运行条件不同、系统外部有人为干预、迭代过程被选择性呈现。因此，本文从对象、条件、干预和变化四个来源控制证据失真。这个框架不穷尽所有项目风险，但能够覆盖 POC 中最常见的“为什么同一个数字不能直接相信或比较”的问题。多家厂商参测时，还需要在相同位置保持基本一致。

这里需要区分两个容易混在一起的要求：

• 能够重复验证：同一方案在记录清楚的模型、数据和配置下再次运行，或换一批同类样本后，核心结论仍大致成立，而不是依赖一次幸运输出或演示人员的临场操作。
• 能够公平比较：多家厂商的结果建立在相近的数据、时间、环境和评测口径上，差异能够主要归因于方案本身，而不是测试条件不同。

公平比较不要求所有厂商使用同一技术路线，而是要求它们在共同目标和边界下接受足够一致的检验。

让关键责任在验证中不缺位

不同公司的岗位名称差异很大，因此本文不按职位罗列项目成员，而是沿着“定义—组织—验证—授权”四种权责进行归纳：谁定义业务上的正确，谁组织并记录验证过程，谁判断技术结果，谁有权配置资源并决定下一步。这里划分的是责任和决策权，不是四组必须独立存在的人员；同一个人可以兼任多项，但作出结论时需要明确自己代表哪一种责任。

“验证设计与组织”和“后续决策与授权”由相近人员参与并不奇怪，尤其是在小型项目中；但两者不是同一种权力。前者负责把客户决策转化成验证范围并留下可信材料，后者负责配置预算、接受剩余风险并拍板是否继续。人员可以重叠，责任不能混写。对厂商侧 AI PM 来说，重点不是成为所有事项的 Owner，而是识别当前缺少哪一种判断，并推动真正有责任和权限的人在正确时间介入。

六、怎样判断 POC 是否真的成功

生成式 AI 的 POC 很容易获得一个“看起来不错”的结果：模型可以写出流畅的文本，演示人员也能避开容易失败的问题。但 POC 的目标不是证明系统曾经成功回答过，而是判断这项能力是否足以支持正式投入。

AWS 的生成式 AI 指南将评测视为开发循环中最关键也最困难的部分，并强调评测框架和指标必须针对具体业务问题设计。对于 POC，技术指标最终还需要被翻译成业务价值和退出条件，而不是停留在模型表现上。

先排除几种假成功

下面六种“假成功”并不是随意罗列，而是分别对应证据最容易被扭曲的六个位置：样本、指标、测试条件、隐藏人工、产品边界和业务结果。它们不是所有失败模式的全集，但覆盖了本文讨论的售前 AI POC 中最常见的失真来源，足以帮助读者先判断漂亮结果究竟来自真实能力，还是来自验证设计本身。

再判断证据是否完整

要支持正式投入，POC 结果需要连续回答四个问题：这件事是否值得做、方案是否做得到、失败是否可以接受，以及它是否有现实的实施路径。本文据此将证据归纳为业务价值、核心能力、风险边界和实施可行性四个方面。它们不是监管标准中的固定四分类，但覆盖了从“值得”到“能做”、再到“可控”和“可落地”的主要决策链；具体项目仍可在风险或实施维度下继续展开安全、合规、运维和供应商服务等子项。

POC 阶段不需要所有指标达到生产标准，但必须提前定义“达到什么程度，足以支持当前决定”。

对于高风险审核类场景，POC 可以暂时不验证全量并发、长期稳定性和完整运维体系，却不能把关键风险漏检留给正式项目再看。因为如果最核心的风险控制能力都无法证明，双方就没有足够依据继续投入。

最后形成阶段决策

结果通常可以归纳为三种：

Go：值得进入正式投入。

关键能力和硬门槛成立，主要风险有明确的后续处理路径。Go 不表示可以直接上线，只表示值得进入供应商选择、商务签约或正式项目定义。

Adjust：需要调整后再判断。

结果显示部分假设成立，但场景、范围、数据、方案或验证标准需要改变。

有效的 Adjust 必须说明：

• 调整什么；
• 为什么调整；
• 需要返回哪个环节；
• 还要补充什么证据；
• 是否值得继续投入验证成本。

如果只是不断增加功能和延长测试，Adjust 就会变成没有退出机制的拖延。

No-Go：当前不值得继续。

核心假设不成立，关键硬门槛无法达到，或者价值不足以覆盖成本与风险。

No-Go 不等于 POC 失败。用有限成本排除一个不值得建设的方向，本身就是 POC 的价值。真正失败的是投入了大量时间，最后仍然不知道该不该继续。

当多家供应商均通过硬门槛时，POC 还需要形成横向比较结论。但最终选择不必机械等同于技术总分最高，客户还会综合考虑标准产品成熟度、实施成本、服务能力、架构适配和正式项目风险。

POC 成功不是现场表现最好，而是产生了足以支持下一步决定的可信证据。

七、POC 结束后，怎样进入正式项目

先交接已经证明和没有证明的内容

POC 通过后，最危险的误解是：“既然效果已经验证，接下来只要把 POC 代码部署上线。”事实上，POC 证明的是正式建设“有路可走”，而不是整条路已经修完。

微软和 AWS 的相关指南都把 POC 与生产准备分开：POC 应使用尽量简单的工作负载验证目标，而进入预生产或正式项目后，才需要进一步补齐稳定架构、安全治理、持续评测、监控和工程化能力。

正式项目交接要解决的不是“再复述一次 POC 结果”，而是沿着四个产品决策继续往下交接：已经证明什么、结论在什么条件下成立、还剩哪些不确定性，以及下一阶段准备建设什么。结论材料因此可以压缩成四部分；具体公司仍可在其中继续展开风险、能力边界和实施任务。

再定义下一阶段的投入范围

POC 之后可能进入：

• 供应商评审和商务签约；
• 正式项目需求与一期范围定义；
• 针对少数关键问题的补充验证；
• 必要时的小范围试运行；
• 暂缓或停止。

具体名称因公司而异，并不需要人为套入一条固定的 Pilot、MVP、UAT 流水线。对于国内 B 端项目，更重要的是明确当前是否已经进入正式投入，以及下一阶段要承担哪些新的证明责任。

下面四个问题不是都由厂商侧 AI PM 独自回答，而是他在推进 POC 时，需要推动参与各方共同给出答案。它们也对应全文的四个产品决策：

1. 验证什么：客户准备根据 POC 结果决定什么，我们需要证明哪些业务价值、核心能力和硬门槛？
2. 验证到哪里：最小范围、必要人员、数据和环境是什么，哪些正式项目能力可以后置？
3. 什么算有效：结果能否重复验证；多家厂商参测时，测试条件和口径是否支持公平比较？
4. 怎样进入正式项目：哪些内容已经证明、哪些仍未证明，结论将导向采购、补充验证、正式项目还是停止？

如果这四个问题没有答案，即使演示顺利、指标漂亮，POC 仍然可能只是一次成本较高的 Demo。

POC 的真正产物，不是一个临时系统，而是一份关于是否值得正式投入、以及下一步应该建设什么的可靠判断。

参考资料

金融监管与行业标准

• 人工智能算法金融应用评价规范（JR/T 0221—2021）
• 国家金融监督管理总局关于银行业保险业人工智能安全开发应用的指导意见

金融机构公开 POC 材料

• 中国银行“数据中心存储集中监控管理项目”采购邀请公告
• 光大证券数据库同步软件采购项目 POC 测试公告
• 光大证券低延时极速订单执行系统 POC 测试公告
• 光大证券数据库安全管控平台项目 POC 测试公告

厂商官方方法与产品文档

• Microsoft：Deliver a proof of concept
• Microsoft：Types of tests that implementation projects use
• AWS：Evaluating quality and reliability in generated outputs
• AWS：Advancing a generative AI PoC to preproduction