POC验证与风险评审

核心概念

POC 是概念验证，用有限实验检验关键假设，不是小型上线承诺。先写待验证问题、通过条件、测试范围和停止条件，再冻结资料版本、任务集、配置与 mock API 行为。保留逐条结果，让其他人能重跑或按记录复核。

风险评审记录风险事件、发生路径、影响、现有控制、验证证据、剩余风险及负责人。整体平均分可能遮住一次高影响失败；权限泄漏或未经确认的写入应单独判断，不被普通问答成绩抵消。

情境拆解

虚构企业的 POC 问题可以是：授权制度问答能否给出有效引用，建单超时后能否避免重复写入。测试正常任务，也注入过期资料、权限缺失、接口超时和恶意文档。报告明确哪些通过、哪些失败及哪些未测试。

只用合成资料和 mock API 得到的通过结论，不能推断真实集成、生产容量或真实用户效果已经成立。

常见误区

测试失败后删掉用例或换口径，会失去比较依据。为了好看只展示成功截图，也无法支持风险决策。演示完成不代表有权连接真实数据或部署。

POC 要回答一个尚未确定的问题

“做出聊天界面”不能说明项目风险已解决。更好的 POC 问题是：“在给定权限与资料版本下，六类问题能否得到有依据的回答？”或“模拟超时后，能否核实原动作而不重复建单？”

选择两个不确定点即可，不必在概念验证阶段完成全部产品。

动手：写可复查的验证记录

1. 为两个问题写假设、样本、通过条件和停止条件。
2. 固定代码或设计版本、资料、配置和模拟接口情境。保留失败样本。
3. 执行能运行的部分；尚未提供的服务与脚手架标记“未执行”。不能把设计预期填进实际结果。
4. 对每个问题做继续、修改或停止的判断。权限失守等严重问题，不能被平均分较高抵消。

要验证的问题：
假设与通过条件：
固定的输入、配置和版本：
运行方式 / 未具备的依赖：
预期结果：
实际结果与原始证据：
失败及影响：
决定与下一次验证：

检查产物

别人能复查你的结论，知道哪些内容实际测过、哪些仍是计划。模块案例要求把验证结论带回范围与架构，而不是把 POC 演示当成上线许可。