PoC 是什么
PoC（概念验证）用受限范围验证新技术的可行性：先定义要验证的假设与通过标准，设定时间盒与资源上限，结束后明确采纳、再验或放弃。没有通过标准的 PoC 会退化成无限期免费试用，既占资源又迟迟无法决策。
怎么做才收得了尾
假设要可度量：把性能、集成难度、运维复杂度分别写成可观测的指标与阈值；环境尽可能贴近生产（数据量、网络与权限边界），否则结论搬不到生产。由指定负责人推进并定期同步，时间盒到期必须给出三选一结论，含迁移与运维成本评估。
基本信息
| 前置条件 | 明确假设（性能、集成、运维）与量化通过标准 |
|---|---|
| 时间盒 | 常见 2-6 周，指定负责人与资源上限 |
| 范围 | 单业务线或影子流量，默认不接入生产 |
| 产出 | 验证报告与采纳建议，含迁移成本评估 |
典型使用场景
- 中间件选型：验证目标吞吐下的延迟与稳定性
- 迁移前评估：试用新版本确认兼容性与回滚方式
- 新技术引入：验证团队能否独立运维与排障
- 供应商方案比对：用同一套用例测试不同产品
- 架构改造预演：在小范围验证拆分后的性能表现
- 成本验证：确认单位成本是否落在预算区间
PoC 计划示例
PoC 计划示例
假设：该消息队列在 3 万 TPS 下 P99 < 100ms
范围：单业务线影子流量，不接入生产环境
资源：2 人 × 3 周 + 4 台测试节点 # 有时间盒
标准：达成 → 进入生产评估；未达成 → 记录结论并关闭
产出：验证报告 + 迁移工作量与运维方式说明结论三选一
| 结论 | 条件 | 后续动作 |
|---|---|---|
| 采纳 | 全部关键假设达成 | 制定迁移计划与回滚方案 |
| 再验 | 部分假设未验证或有疑点 | 限定新的时间盒与验证点 |
| 放弃 | 关键假设不成立 | 记录原因，避免半年后重复调研 |
PoC 的结论要写清验证边界：在什么数据量、什么版本、什么网络条件下得出的结果，别人引用时才知道适用性。