为什么现在要做采购前审计
采购星空app这类识别能力时，最容易出问题的不是价格，而是需求没写清就进入比价。等方案交付后才发现夜间、远距、遮挡等场景根本没被纳入评测口径，返工成本远高于前期多花的两天审计。本文把星空app采购前的识别配置拆成一份可逐项打勾的审计清单，供内部评审会直接使用。
审计的目的不是给供应商打分排名，而是让团队先对自己的场景、必备项和权衡点形成书面共识。清单里的每一条都应当是现场可观察、可复现、可写进验收条款的，而不是“效果好不好”这类无法验证的描述。
界定评测范围与场景边界
先划定范围，再谈配置。范围不清时，任何识别方案都显得“差不多能用”。建议在评审会前完成以下界定，并形成一页纸的书面记录。
- 使用场景清单：列出实际会遇到的观测条件，例如夜间、逆光、薄云、城市光污染、移动拍摄等，逐条标注出现频率。
- 输入来源：明确是手机摄像头、相机长曝还是已有图片导入，输入质量直接决定识别配置的下限。
- 输出用途：识别结果用于现场辅助、事后整理还是教学演示，不同用途对响应时间与准确度的容忍度不同。
- 使用人员：是熟悉星图的爱好者还是首次接触的新手，决定界面提示与容错设计的要求。
- 评测样本：准备一批自己场景下的真实图片作为评测集，避免只用厂商演示素材做判断。
必备项核对清单
必备项是“缺了就一票否决”的条件，应写进采购需求书。以下每一条都可以在试用阶段现场验证。
- 场景覆盖可验证：用自备评测集跑一遍，确认在约定的观测条件下能给出结果，而不是只在理想条件下可用。
- 识别结果可解释：界面需给出候选目标与置信提示，便于使用者判断是否采信，而不是只给一个结论。
- 离线或弱网可用性：明确在无网络或信号弱的环境下功能边界，现场使用往往不在稳定网络覆盖内。
- 数据与隐私条款：确认图片是否上传、存储多久、能否关闭上传，条款需可写入合同附件。
- 版本与更新机制：识别模型更新是否影响既有结果，更新前是否提供说明，避免验收后行为漂移。
- 验收口径书面化：把评测集、通过条件、复测方式写进验收条款，避免口头承诺。
可选项与权衡清单
可选项不是不重要，而是需要与成本、维护负担做权衡。建议逐条记录“要或不要”的理由，而不是默认全要。
- 附加功能：如轨迹记录、观测计划、社区分享等，评估其是否真的进入日常流程，还是只在演示时用一次。
- 多端同步：跨设备同步方便，但涉及账号与数据留存，需要与隐私条款一起权衡。
- 定制识别范围：定制能贴合场景，但会带来维护与升级依赖，需评估长期由谁负责。
- 集成方式：自研算法、集成第三方SDK或采购成品，三者在可控性、交付周期与后续维护上各有取舍，应按团队能力选择。
- 培训与交接：供应商提供的培训深度影响落地速度，但不应替代内部文档，交接材料需在采购时约定。
红旗信号：这些现象先停下来
审计过程中若出现以下现象，建议暂停推进，先补充验证再继续比价。 星图识别
- 只提供剪辑过的演示视频，拒绝用采购方自备样本现场评测。
- 对“夜间识别不准”的解释始终停留在参数调整，无法说明适用边界。
- 验收条件写得模糊，如“效果良好”“基本满足”，无法复测。
- 数据上传与存储说明含糊，或条款与实际行为不一致。
- 报价单中把关键能力放在未标明的附加项里，后期再追加费用。
整改顺序与下一步动作
发现问题后不必全盘推翻，按影响面排序处理更有效率。建议顺序如下：先补齐场景边界与评测集，这是所有判断的基础；再修订必备项条款与验收口径；随后处理数据与隐私条款；最后才讨论可选项的取舍与集成方式。完成上述步骤后，把审计结论整理成一页纸的需求摘要，作为后续选型与采购谈判的共同底稿。
清单的价值在于可重复使用。每次采购或版本升级前重跑一遍，把新增场景补进评测集，识别配置的决策就会越来越有据可依。