视觉项目的风险清单

风险管理的常见做法是列一张表、写一堆「可能延期」「可能存在技术风险」这样的泛泛条目，然后束之高阁。这份清单不一样：每一条都对应一个具体的现象、一个可以观测到的触发信号，以及一个明确的动作。它们的共同来源是大量项目的实际教训，而不是推测。

清单

三个最高频的风险，展开说

判据未冻结是排在第一位的。它的表现是：项目已经开始写算法、选相机、打光，而「什么样算合格」这件事还在讨论中。这种情况下的所有技术工作都建立在不稳固的基础上——判据一改，相机选型可能就不合适了，光照方案可能要重做，已经标注的样本可能有一半要重标。冻结判据并不意味着以后不能改，而是要有一次正式的确认动作，把它从「讨论中」变成「已确认，可以开始」，后续修改走变更流程。

验收样本不足排在第二。视觉项目的验收离不开样本，尤其是缺陷样本，而缺陷样本的产生具有偶然性——试产阶段没有出现的缺陷，量产后才出现，这时候才发现系统从没学过这类缺陷。应对方式不是硬等，而是在立项时就明确：如果某类缺陷样本凑不够，验收范围就要相应收窄并写明，或者在合同中约定样本补齐后的补充验收。含糊过去的结果是验收时双方都下不来台。

节拍超预算排在第三，它的特点是发现得很晚。开发阶段用单张图像测试，速度看起来很快；上线联调时多相机同时工作、加上通信与记录的开销，端到端时间才暴露出来。等到这时候再优化，可用的手段已经不多，往往只能降分辨率或者换算力，两者都要重新验证精度。所以节拍预算必须在立项时做，并且在每个选型节点上对着它确认一次。

清单不要写得太长

清单长了就不会被用，这是所有检查表的共同命运。一份能真正执行的视觉项目风险清单，条目控制在十条上下比较合适，每条一行，能在一页纸内看完。多出来的条目要么合并，要么降级到方案文档里作为前提条件，不要留在清单上稀释注意力。另外，清单上的条目应当定期清理：已经过去的风险划掉，新出现的加上，让它保持是一份「当前还有效的担心」，而不是一份从立项起就不再更新的历史文件。判断一条该不该留的标准很简单：如果它今天发生，会不会改变方案、工期或验收方式。会，就留着；只是让人不舒服，就删掉。一个每年还在被翻动、上面有划改痕迹的清单，才说明它真的在工作。