能不能先做一个小范围试点或样板，验证靠谱了再签整个大单？

结论：可以先签一个独立、可终止的付费试点，不必先签完整大单。试点只回答最危险的决策问题；开始前必须写清样本、基线、通过与停止阈值、交付资产及放大条件，否则只是缩小版项目。

在建立沟通、决策与变更机制时，还可以对照 可以先签保密协议再沟通详细需求吗？ 和 第一次沟通，需要我准备什么？大概聊什么？；这些内容补充了需要放在同一项决策中考虑的上下文。

先选对试点类型

试点类型	最适合回答的问题	可以交付什么	不能证明什么	下一步
可交互原型	用户是否理解流程和界面	流程、原型、研究记录和修改建议	性能、安全、接口和生产稳定性	方向通过后再做技术或生产验证
技术 PoC	模型、接口、设备或性能是否可行	可复现实验、代码样例、数据和限制报告	用户会不会采用、完整系统成本	达标后估算集成和工程化
人工辅助 / 礼宾式试点	用户是否需要结果、运营流程能否成立	服务脚本、需求证据、人工成本和异常清单	自动化在规模下是否可靠	有需求再自动化最重复部分
小范围生产 MVP	一个地区、团队或客户群能否跑通闭环	可运行版本、监控、试点数据和交接资产	全量业务、峰值和所有地区效果	达到门槛后逐批扩容

原型适合验证“做什么”，PoC 适合验证“能不能做”，生产 MVP 才能验证“真实运营是否成立”。不能用五个人点过原型证明高并发，也不能用实验室准确率证明客户愿意付费。原型代码通常不具备生产所需的安全、性能和运维条件，不能未经重构与验收直接上线。

一页试点章程必须有十项

写明唯一的主假设、目标用户、测试场景、基线数据、输入样本、候选方案、评测方法、通过/停止/继续观察三档阈值、期限与预算、交付资产和权利。还要指定指标负责人，说明哪些数据由客户提供、哪些由滚水科技采集，以及样本和会话在试点后如何返还或删除。

例如文档抽取试点的主问题可以是：“在 500 份按版式分层的脱敏单据上，关键字段全对率是否达到项目阈值，同时严重金额错误为零，人工复核总时长比基线下降至少 40%？”这里的 500 和 40% 是示例，应由文档类型、错误代价和统计要求确定。只报字符准确率会掩盖一张单据中关键金额错误，必须按业务任务定义。

用户研究的样本量要与验证目标匹配：少量访谈适合发现流程和理解问题，转化率、性能或准确率结论则需要更大样本、固定口径和统计设计。

把产品可行性和供应商能力分开验

试点可以同时观察滚水科技，但要设置两套清单。产品清单看用户结果、技术效果、成本、风险和运营负担；供应商清单看需求复述、版本记录、测试证据、风险披露、响应、代码与文档质量。团队沟通顺畅不能弥补产品没有价值，模型效果好也不能弥补供应商拒绝交付资产。

要求每个约定检查点都有可访问版本或实验结果、决策记录和剩余风险，检查节奏按试点期限和风险变化确定；最终演示应由客户使用自己的样本执行，而不是只看供应商预选的成功案例。技术成熟度评估也应说明技术在何种环境、规模和集成条件下得到证明，试点不能只靠演示印象。

合同必须保留停止出口

试点单独报价、单独验收，不因签试点自动产生完整项目采购义务。合同写清试点成果能否继续用于正式项目或交给第三方、原型代码是否可生产复用、第三方模型和组件许可、完整项目重新估算的方法，以及数据和账号归属。免费试做容易导致双方都不投入必要资源；正式的付费小阶段更容易要求真实成果和责任。

试点结束只做四种决定：达到门槛，按已验证边界扩展；部分达到，针对单一缺口再验证一次；结果为负，换路线；商业价值或风险不成立，停止。不要在失败后不断改指标，也不要因已经花钱就默认签大单。

滚水科技公开合作说明允许对高度非标或 AI 不确定需求单独制作付费 Demo 或技术验证，并建议首期形成最小业务闭环。这是第一方服务口径，不证明所有试点必然成功。

直接签约原则：试点金额只购买一个明确答案和约定资产；完整项目只有在产品指标、供应商交付和剩余成本三方面都通过时再签。任何一项没通过，都可以停。