向供应商表达雷达需求，不只是采购流程里的一个表格。供应商方案的质量，很大程度上取决于需求说明的质量。如果买方只说“要一套 5 公里探测无人机的雷达”，供应商就不得不猜目标、现场几何、杂波、接口、告警流程和验收条件。
更好的需求说明，会给供应商足够上下文，让对方能够提出架构、说明假设、识别风险，并解释哪些能力可以被证明。目标不是把文件写得很长，而是把工程问题说清楚。
先说明任务结果
先说系统要帮助你完成什么。相比“报一套无人机雷达”，供应商更容易回应“在重大活动期间，探测并跟踪接近体育场的低空无人机，并在安保指挥中心联动 EO/IR 确认”。
建议说明：
- 被保护的资产或区域；
- 需要关注的事件或行为；
- 为什么需要雷达这一层；
- 需要多长预警时间；
- 谁会使用这些信息；
- 系统要支持什么决策。
这能帮助供应商判断项目重点是早期预警、周界态势、临时活动安保、证据留存、摄像机联动，还是多传感器融合。
定义目标和运行场景
雷达效果和目标强相关。小型多旋翼、固定翼无人机、鸟、人、车辆、小船，都不是同一个感知问题。即使都叫无人机，尺寸、速度、高度、材料、载荷和飞行行为也会改变效果。
可以提供：
- 重点目标类别；
- 典型高度和速度范围；
- 预计接近路径；
- 悬停、横穿或直接接近行为；
- 协同或非协同目标；
- 是否假设目标发射 RF 信号；
- 哪些目标属于干扰物而非威胁。
如果你不确定，也应直接说明。好的供应商应该帮助细化假设，而不是把一个距离数字当成所有目标的答案。
提供现场上下文
现场条件往往比雷达型号更能改变方案。尽可能提供图纸、地图、照片和说明。
有价值的信息包括：
- 保护区域和边界；
- 候选安装点；
- 屋顶、杆塔、塔架或车载平台选项；
- 建筑高度、地形、植被、水面、道路、塔吊或大型金属结构；
- 已知杂波源；
- 供电和网络条件；
- 接地和防雷限制；
- 维护通道和安全限制；
- 预期运行时间。
如果现场尚未最终确定，也应说明不确定性。这样供应商可以提出选项，而不是把项目锁定在错误假设上。
说明输出和操作流程
雷达需求应描述操作员需要收到什么，而不只是传感器能探测什么。
需要说明系统是否必须提供：
- 目标位置、高度、速度、航向和历史航迹；
- 地图显示和告警区域；
- EO/IR 摄像机联动；
- RF 或 Remote ID 关联；
- 事件日志和回放；
- 数据导出格式；
- 与 VMS、C2、PSIM 或客户软件集成；
- 本地和远程操作视图；
- 用户角色和审计记录。
这样可以避免常见错配：供应商交付了能工作的雷达，但客户真正期待的是一套集成态势画面。
清楚说明约束
供应商需要约束条件，就像需要功能要求一样。约束会影响设计和价格。
建议说明：
- 预算或预算范围；
- 交付时间；
- 出口或进口要求；
- 首选供电和网络方式；
- 环境条件；
- 安装限制；
- 网络安全要求；
- 语言和文档要求；
- 培训预期；
- 维护和支持模式。
如果某项不能妥协，应标注为必须项。如果只是偏好，应标注为偏好。这样供应商更容易提出现实替代方案。
区分必须项、应有项和可选项
并不是每条需求权重相同。清晰的需求说明应区分：
- 决定项目成功的必须项；
- 明显提升价值的应有项；
- 可以单独报价的可选项；
- 需要供应商确认的假设；
- 需要工程讨论的开放问题。
这种结构让供应商回复更容易比较，也能减少把可选项当成强制项，或把关键项淹没在普通文字里的风险。
要求供应商说明假设和证据
好的供应商回复不应只列出产品型号，还应说明推荐方案背后的假设。
可以要求供应商解释：
- 方案基于哪些目标假设；
- 哪些现场条件可能限制效果；
- 探测、跟踪或告警距离分别是什么意思；
- 哪些内容需要现场勘查或仿真；
- 哪些内容可以在 FAT 中证明；
- 哪些内容必须在 SAT 中证明；
- 包含或不包含哪些集成；
- 部署后包含哪些支持。
这一步能把模糊宣传变成工程承诺。
及早加入验收标准
验收不应等到项目最后才临时设计。应尽早说明成功如何判断。
实际验收模型可以包括：
- FAT 检查硬件、软件、接口、日志和文档；
- SAT 检查现场覆盖、盲区、实飞或代表性目标、告警区域、摄像机联动、事件导出和操作流程；
- 截图、日志、航迹导出和测试记录等证据；
- 对已知现场限制的处理方式；
- 偏差如何关闭。
如果供应商无法同意验收思路，应在采购前讨论，而不是安装后才发现分歧。
一个简单的需求模板
给供应商的需求说明可以很简单：
- 项目目标和保护场地。
- 目标类型和运行场景。
- 保护区域、地图和现场照片。
- 候选安装位置和约束。
- 所需输出和集成。
- 供电、网络、网络安全和文档要求。
- 交付时间和物流约束。
- 必须项、应有项和可选项。
- FAT 和 SAT 预期。
- 供应商必须回答的问题。
这些内容足够启动一次严肃的技术沟通。
常见的不良需求
尽量避免以下说法：
- “请报你们最好的雷达。”
- “我们要 5 公里探测，发价格。”
- “要全天候探测所有无人机。”
- “现场细节采购后再谈。”
- “供应商负责保证一切可用。”
这些话看似简单，却迫使供应商猜测。猜测会制造风险，而风险最终通常会变成成本、延期或验收争议。
结论
向供应商表达雷达需求，最好的方式是用清楚的工程语言描述任务、现场、目标、操作流程、集成需求和验收标准。你不需要在联系供应商前解决所有设计问题，但应提供足够上下文，让假设变得可见。
需求说得越清楚，供应商方案就越容易比较，性能声明也越容易测试，项目在安装和验收阶段发现重大误解的概率就越低。