从 AI 原型走向可采购项目

原型回答的是：拟议交互能否在有限条件下运行。采购要回答的问题更广：组织能否按照约定条件获得、运营和支持这套系统？从前一个问题走向后一个问题，需要证据、明确责任及商务范围。

以下决策阶段适用于应用和硬件项目，是一套建议方法，不代表 CNPS 某个项目已通过这些阶段，也不构成固定交付承诺。

1. 保留原型实际证明了什么

写出演示背后的任务、用户、输入材料、配置和条件。既保存成功尝试，也保存失败尝试。例如，安静房间里的简短语音交互，只能证明在该配置下观察到的情况，不能据此认定它在繁忙接待区的表现。

列出让演示得以完成的依赖，可能包括人工准备、开发者账户、特定网络，或有人在修正输出。把这些依赖写明，下一阶段才能有意识地测试或替换它们。

每个阶段都应以一个决定及其依据结束。通过某阶段，意味着约定的问题得到了回答，并不意味着所有潜在风险都已消失。如果答案尚不明确，应说明还需要什么证据，以及由谁获取。

不要让日历日期悄悄替代阶段决策。如果发布日期固定，应调整范围或明确未解决的依赖，不能把缺失的证据当作已经通过。

对于基于公开代码的项目，明确计划使用的具体仓库、版本和组件。在决定商业模式前，审查其适用条款及所连接服务的条款。能够访问源代码只是一项输入；分发产品、使用品牌或提供托管服务的权利，可能涉及其他条件。

根据实际情况建立应用代码、模型、固件、声音、数据集和第三方服务清单，并指定变更核查负责人。本文提供采购流程，不对某项具体许可证或司法辖区作出结论。

把一次性工程费用与持续运营费用分开。按需纳入硬件与配件、托管、模型或语音用量、内容维护、监控、更新、培训及支持。说明实际需求高于或低于规划假设时会发生什么。

询问谁负责凭证、源代码变更、用户管理和故障处理。定义实际退出路径：客户如何取回数据，如何撤销访问，以及更换服务供应商需要什么条件。这些决定会影响演示团队离开后项目是否仍然有用。

商务范围应写明包含的工作、排除项、版本、客户输入、验收方法以及批准完成的人。把试点数量或用户数，与任何未来订单分开。注明哪些变更需要重新报价。

硬件应包含目的地、包装、交付假设、安装责任和更换安排；软件应包含托管方式、集成和维护边界。针对准确配置及目的地，与责任方确认适用的产品测试和文档要求。

可供采购决策的资料包，应包含需求、系统图、评估结果、依赖清单、报价及运营责任。把未解决事项保留在显眼位置，并附上下一步行动。目的是让另一位同事无需重建整段沟通过程，就能理解决定。

使用AI 采购检查清单或语音原型需求说明组织下一阶段工作。向 CNPS 提供项目范围时，请说明哪些已经运行、哪些尚未测试、目标用户或数量、目的地及时间安排。这样双方才能从清晰的起点讨论范围明确的方案。