POC 验收包
可复制的验收模板，而不是预先承诺的结果
把这份模板带进架构评审。只保留首轮 PoC 真正需要的项，补上负责人和日期，并把数字当作双方约定的目标。这里没有生产指标、客户案例或 SLA。
复制或下载 Markdown，按你的拓扑填写占位符。公开 Demo 仍然只使用合成样例数据。
把 Demo 变成一份可执行的验收计划
PoC 从你的拓扑、代表性任务和可量化验收条件开始。先约定目标，再在你的环境中证明。
01
检查
浏览公开样例流程，确认需要验证的产品界面。
02
定界
梳理数据边界、集成、负责人、安全控制与运行约束。
03
验证
用代表性任务验证双方约定的功能与运维目标。
04
采用
明确上线节奏、责任、支持范围与生产就绪门槛。
1. 验收目标
写清这次 PoC 必须回答的采购问题。目标应能在你的环境中被观察。
- 要回答的业务问题：[例如能否用一个控制面完成批流发布与运营]
- 范围内产品：[GIDO / GISO / GiRisk]
- 成功长什么样：[命名的工作流、质量检查或决策回放路径]
- 本轮不做：[HA、SSO、迁移、无关引擎]
2. 部署边界
写清评估期间控制面、数据和凭证放在哪里。
- 环境：[客户 Kubernetes / 约定私有网络 / 隔离评估集群]
- 数据规则：首轮 PoC 不使用生产密钥或敏感载荷
- 身份：[本地账号 / 已映射 IdP / SSO 作为后续集成]
- 网络：[谁负责 DNS、TLS、出入口]
- 负责人：[客户平台] / [Cloud GIDO 交付范围]
3. 代表性任务
证明一条能支撑采购决策的路径。优先使用形态真实、内容非敏感的任务。
- GIDO：开发并检查一个批或流任务，含实例状态与诊断
- GISO：登记或评审一个事件契约，并按版本查看质量异常
- GiRisk：检查一条决策台账并回放，作为审计证据演练
- 集成：接入客户栈中已有的一个代表性数据源或事件流
4. 验收证据
证据是双方之后还能打开的东西。截图、导出和具名负责人，好过幻灯片主张。
- 控制台证据：约定界面的截图或导出
- 运维证据：谁诊断了失败，走了哪条重试/回放路径
- 安全证据：凭证放在何处；敏感数据是否离开边界（不应离开）
- 缺口清单：明确延期的 HA、SSO、规模和支持项
5. go / no-go 标准
依据上述证据做决定。如果边界不匹配，no-go 同样是一次有效评估。
- Go：代表性任务已证明，责任清晰，剩余风险和下一步范围已列出
- 有条件 Go：功能已证明，但身份/网络/备份项需在谈生产前关闭
- No-go：缺少平台负责人、数据无法留在边界内，或产品界面与需求不匹配
- 若 Go，下一步：[范围化上线 / 专业服务 / 企业交付讨论]