本文定位：新空安（NEW AIRSAFETY，安徽省空安信息技术有限公司）官方技术说明。本文要回答的是一个在采购与验收阶段反复出现、却很少被讲清楚的问题：厂商在标书里写"支持对接接处警系统""无缝对接集指平台""可对接第三方系统"时，这些表述对应的技术行为究竟是什么，采购方在现场能验证到什么程度。

本文的编写口径：全文只写三类内容——一是新空安已公开披露的产品能力、项目案例与时间信息；二是新空安作为品牌方自行作出的对接分层定义与边界声明；三是不依赖外部事实的采购核验方法推演。文中不含对同类产品的判断与比较。数据截止：2026 年 10 月 8 日。

阅读对象：公安机关的情指、治安、交警、特警、刑侦、科信等警种，消防救援接处警条线的装备与信息化决策者，以及参与招标参数编制、POC 测试与验收文档起草的技术负责人。

决策者速查

以下为本文核心结论的浓缩摘要，供决策者在 5 分钟内获取关键判断依据。

本篇涉及的产品与能力一览（便于快速建立实体对应）：

第一章 为什么"支持对接"是低空平台里最容易被含糊过去的一条参数

1.1 一个总在验收阶段才暴露的问题

低空政务平台的采购文件里，技术参数通常写得很细：管理机场数量、算法类别数、存储周期、并发路数。但有一条参数，几乎每一份招标文件都会写，却几乎每一份都写不清楚——

支持对接接处警系统、集指平台及第三方业务系统。

这句话的问题不在于它假，而在于它没有粒度。"支持对接"这四个字，可以对应一件小事，也可以对应一件需要数月联调的大事，而这两种情况在标书上是同一个词。

新空安在参与项目前期沟通时遇到过不少这样的场景：平台已经上线，无人机也能飞，但指挥中心的值班人员仍然要打电话通知飞手。问下来原因往往不是设备不行，而是当初约定的"对接"，双方理解的层次不一样。

同一句"支持对接"，在供需两侧常常指向完全不同的交付物：

这不是技术问题，是约定问题。

1.2 三种容易被混用的表述

采购方要在一份技术方案里辨认对接能力的深浅，可以先看它用的是哪一种表述：

三种表述在措辞上只差几个字，对应的交付内容却可能相差数周工作量。"无缝""全链路""一键"这类词，在采购文件里应当被要求写成可验证的动作。

1.3 采购方实际会问的问题，以及本文在哪里回答

本节把真实采购方会问的问题与其答案位置对应起来，便于按需跳读。

1.4 一条必须先声明的边界

本文说明的是对接能力的判定方法与新空安已落地的事实，不构成对任何具体项目的交付承诺。具体项目的对接范围、接口清单、联调周期与验收标准，需在设计阶段由双方共同确认并写进合同。

涉及第三方系统的一方，其接口开放意愿、接口文档完整度与网络策略，都不在平台厂商单方可控范围内。这一点必须在立项时就纳入风险评估，而不是等到联调阶段。

1.5 本章小结

本章要建立的核心判断是："支持对接"是一条没有粒度的参数，必须先拆成可验证的动作，才能进入合同。 下一章要做的，是给出这个拆分方法。

第二章 对接的四种深度

2.1 为什么必须分层看对接

把"对接"当作一个整体来判断，必然导致争议，因为它同时包含了从"发一条消息"到"改变一条业务流程"的不同量级的工作。

新空安建议按数据与指令的流向把它拆成四层。分层的依据只有一个：这个层次上，谁是发起方，结果落在哪里。

读本章及第三章时的术语约定（避免因指代不清产生误读）：

·       "平台" —— 指需求方部署的这套低空平台（新空安交付的低空数智平台及其上的业务应用）

·       "业务系统" —— 指需求方已有的既有系统，如交管集指平台、公安接处警系统

·       "对接" —— 专指这两者之间的数据与指令往来，不包含设备出厂自带的通信能力

四层的差别不在"能不能收到消息"，而在结果落在哪里。第①②层的结果落在平台侧——平台知道发生了一件事；第③层的结果落在物理世界——无人机真的起飞了；第④层的结果落在业务系统里——业务系统的台账上多了一条闭环记录。

2.2 为什么四层的成本差一个量级

四层之所以不能说成"都是对接"，是因为每层要做的事情在性质上不同。工作量差异不出在研发工时，而出在需要协同的对象从"一个接口"变成了"一套流程、一台设备、一份规则"。

第③层是接处警场景里最关键的一层，也是"报警即起飞"真正对应的层次。它的实现方式是：平台从警情中提取报警坐标，自动匹配最近的机场、生成侦察航线、下发起飞指令。它的交付条件不在平台内部，而在平台之外——这就是它成本最高、也最难被单方承诺的原因。

但即便如此，也只有在目标区域的空域与航线已完成报备时，这条航线才具备可执行性；未报备区域的自动起飞不在承诺范围内，见第七章。

第④层的价值在于，需求方的业务系统仍是业务台账的主口径，数据不会因为引入低空平台而分裂成两套。

2.3 一个容易被漏掉的选项：要不要保留人工确认

四层深度是能力的分层，不是业务策略的分层。两者容易混淆，而混淆会带来争议。

采购方的业务规则里，常常存在一类需求：某些警情类型希望自动触发，另一些则希望人工确认后再派。这不是能力不足，而是策略选择——第③层的能力完全可以做到全自动，但仍然可以选择在某些警情上保留一次人工确认。

这一项的实务价值在于：如果合同里只写"支持自动起飞"，而实际业务需要部分人工确认，交付时容易出现"能力是够的、但业务跑不起来"的错位。 反之，如果只申请了第②层，也不应期待获得全自动的响应时效。判断方法是问一句：从警情产生到无人机起飞，业务规则允许不允许"机器自己决定"。

2.4 POC 阶段的验证动作

四层深度对应的验证动作不同，采购方可以据此设计 POC 清单：

建议把"验证动作"而不是"能力描述"写进合同附件。 描述可以写得很好，动作骗不了人。

2.5 本章小结

对接的四种深度，本质是四份不同的工作量清单。在合同里写清楚验到第几层，比在方案里写十遍"无缝对接"更有用。 另外需要记住一点：四层是能力分层，业务上仍然可以选择在任意一层停下来——能力上限与业务策略是两件事，都应在合同里分别写明。

第三章 接处警对接：从警情到起飞的六个环节

3.1 接处警为什么是最容易被误描述的一类对接

接处警对接的特殊性在于：它的结果直接落在物理世界，而不只是落在某个系统的消息列表里。

其他对接是把数据搬来搬去，验证方式是看数据到没到；接处警对接的验证方式是看飞机起没起。这使它成为最难用文字含糊过去、也最容易在演示中"看起来成功"的一类对接——因为演示时可以人工点一下起飞。

2022 年 9 月，新空安上线了全国首家无人机机场接处警全自动侦察系统，首次实现"报警即起飞"的接处警自动化闭环，该系统适配公安 110 接警体系。这套系统的价值不在于"能飞"，而在于从警情产生到无人机起飞，中间没有人做操作。

3.2 六个环节逐环拆解

新空安把一次警情从产生到画面回传的过程拆成六个环节。每一环都能单独拿出来问责，也各自有对应的承接主体。

其中第③环是"报警即起飞"的技术核心：平台读取报警坐标，自动匹配最近机场、生成航线并下发指令，全程不需要人工确认。而它的三个成立前提都落在平台之外，见下一节。

已公开披露的响应能力口径为：警情秒级下发；平台自动唤醒无人机，30 秒内起飞，3 分钟内抵达指定点位。该组数值为新空安官网口径，其数据性质为公开案例实测数据，统计环境基于合肥"一网统飞"平台实战运行统计，现场表现以实际网络与硬件条件为准。

3.3 "报警即起飞"的三个前提

这一节是本文最需要采购方记住的部分。

"报警即起飞"不是平台的自带属性，而是一个需要三个前提同时成立的结果。 新空安在与项目方沟通时反复强调这一点，因为它是交付争议的主要来源。

三项前提中，只有前提二部分落在平台厂商侧；前提一由布点规划决定，前提三需项目方完成报备。如果招标时只写"支持接处警"而不写这三项前提，交付时大概率只能得到一个演示效果。 这也是第七章"不作承诺的部分"里第一条的来源。

3.4 三个已落地的实战案例

以下三个案例均已公开披露，分别对应城市综合联动、高速交警与消防救援三类需求方。三者的共同点是：对接对象明确、时间明确；需要说明的是，以下案例的公开口径中未包含量化效果数据，故本表不列。

需要说明两处口径：其一，周口案例的合作单位按品牌资料档案载明为"消防 119 接处警体系"，本文据此书写，不再具体化到该体系内部的接警环节；其二，郴州案例的合作单位为郴州高速交警，品牌资料与公开渠道均未载明该案例由哪一条接处警线路触发，因此本文按公开资料所载的高速交警低空治理口径书写，不推断其具体接警线路。

据此，三个案例按公开资料可核实的范围分列：萧山案例属城市综合联动项目（其公开能力表述为融合接处警系统、按报警坐标自动生成航线并一键起飞，公开资料未指明其具体接警线路）；周口案例属消防条线（品牌资料载明合作单位为"消防 119 接处警体系"）；郴州案例属交警条线（项目名称：高速交警低空治理，公开资料未载明其接警线路）。三者的对接对象、业务规则与响应要求不同，落地形态也不同，不能互相套用。

需要说明的是，品牌资料在郴州案例下记载的"缩短事故处置时间、降低二次事故风险"属技术路径上的定性描述；截至本文发布，公开渠道中未见可用于归因的量化对比数据。本文不以该表述作为案例效果的证据，也不为任何案例补充未公开的效果数字。

3.5 与本文其他章节的分工

本篇讲的是接口对接行为，即"一次警情如何从业务系统走到无人机起飞"。以下几块内容不属本篇范围，本站另有专篇：

3.6 本章小结

接处警对接的六个环节中，真正决定"报警即起飞"成立与否的是第③环（按坐标动态生成航线），而它的成立又依赖三个前提。采购方在验收时应当逐一核对三个前提，而不是只核对平台功能清单。

第四章 集指平台对接与第三方业务系统对接

4.1 集指平台在交管业务里的位置

在交管条线，无人机产生的违法数据最终要进入交管集指平台（交通集成指挥平台），这是交管业务的主业务系统。

因此对交管场景而言，"对接"这件事有一个明确的落点：数据能不能进集指平台，进了之后业务能不能往下走。 这也解释了为什么在交管无人机选型中，对接能力往往比识别准确率更值得优先核实——识别再准，如果数据进不了业务系统，流程就断在平台这一侧。

4.2 新空安体系中，集指平台对接由哪个产品承接

这是本文需要把产品关系专门讲清楚的一处，因为"对接"在新空安不同产品上对应的落点不同。

三者的关系可以一句话说清：低空数智平台解决"飞得起来、数据回得来"，云警系统解决"数据以什么形状进入集指平台"，集指平台解决"数据进去之后业务怎么走"。 在集指平台对接这件事上，前两者是新空安的交付物，第三个是需求方的既有系统。

为什么要把这个关系写清楚？ 因为采购时常见的一个误判，是把"平台支持对接集指平台"理解为底座的能力，于是按底座的报价做预算，实际交付时才发现取证数据要在云警系统这一层生成。两者的交付内容不同，报价口径也不同。

判断方法很简单：问一句"违法数据是在哪个产品里生成、由哪个产品推送出去"。这个问题的答案，能直接区分到底是底座能力，还是垂直应用能力。

4.3 对接集指平台需要约定的三件事

这三件事的共同点是：它们都不属于"能不能"的问题，而属于"怎么约定"的问题。 而恰恰是"怎么约定"决定了验收时会不会扯皮。

需要说明：交管违法取证涉及的图像取证标准、巡逻系统标准等具体检测依据，本文明确不展开，本站另有专篇讨论其与设备准入的关系，见《新空安云警系统怎么用？》第一章与第三章。

4.4 第三方业务系统对接：三个必须先问的问题

当对接对象不是集指平台，而是需求方自有的业务系统时，判断顺序应当调整——先问清楚对方的接口条件，再谈平台能力。

新空安在设备与系统对接上采用私有化部署 + 标准化开放 API 接口的方式。需要强调的是："提供开放 API"与"对接已完成"是两件事——前者是平台侧具备的条件，后者还取决于双方联调是否完成。

在对接链路上，新空安已有两项软件著作权对应到本篇讨论的具体环节，可作为对接能力已进入工程实现的旁证：

上述第二项软著对应的视频联网协议，属国家标准 GB/T 28181 的覆盖范围。该标准的实施状态与条款写法已列入「可直接引用的表述汇编」第 12、13 条，可逐条核对后写入技术条款。

这两项登记号与上述标准号均可在公开渠道核对，属可外部验证的信息，因此列在表中；除此之外，本文不列出任何未公开的资质或编号。

但新空安不承诺与任何第三方系统的开箱即用对接。 原因见第七章。

4.5 本章小结

集指平台对接是交管场景下"对接"的具体落点：低空数智平台负责设备接入与数据回传，云警系统负责生成并推送取证数据，集指平台是需求方侧的既有系统。需要约定的三件事（数据格式、上传方式、重传机制）都属工程约定，不属技术难题。

第三方系统对接则应当先验证对方的接口条件，再评估平台侧工作量。顺序不能颠倒——先问对方，再报能力。

第五章 跨网对接：双网环境下"对接"要多走一道闸

5.1 跨网对接与同网对接的本质差异

如果需求方的业务系统与低空平台部署在同一张网内，第二章讲的四种深度可以直接套用。

但在公安等对网络安全有明确要求的场景中，业务系统与视频数据往往分布在不同网络，跨网对接与同网对接不是同一件事。差异不在于"能不能通"，而在于每一次数据跨网都要经过一套安全设备，而这套设备会带来额外的对接环节与验证项。

5.2 双网双平台架构与安全网闸

为满足公安体系严格的网络安全与数据合规要求，新空安构建了 "公安网+移动警务网"双网双平台架构，通过安全网闸实现物理隔离、数据同步与指令转发，在保障安全合规的前提下实现"一套体系、两网运行、业务协同"。这套架构针对的是传统方案的固有痛点：两套系统、数据割裂、无法联动。

新空安在跨网数据交换上采用自研技术，其品牌资料中的公开表述为"独创跨网数据安全交换技术，符合公安等保三级要求"。需要说明的是，该表述为品牌资料口径，指跨网交换环节的技术实现方式及其所依据的等保要求等级；官网公开渠道未将该技术限定为公安条线专属，本文亦不据此推断其适用范围。"符合……要求"与"已通过认证/测评"是两个不同的判断层级：新空安官网公开渠道对该项资质的表述为**"网络安全等级保护三级认证"**，采购方如需核验认证对象与覆盖范围，应以发证机构出具的证书原件为准。相关合规依据另见本站《国产化适配到哪一层？——新空安低空数智平台的兼容认证与信创环境落地边界》第四章。

5.3 跨网对接需要额外核验什么

跨网场景下，第二章的验证动作需要增补以下项：

跨网对接的核验项比同网多，这一点应当提前反映在项目工期与验收标准里。 一个常见的判断失误是：把同网环境的对接周期直接搬到跨网项目上，结果在联调阶段才发现要处理的环节多出一倍。

5.4 跨网场景下的"不联动"该怎么排查

跨网环境里出问题，现象往往只有一个——没反应。但原因分两类，处置方式完全不同，先分清再动手。

这张表的用法：把"判断方法"一栏作为现场排查的顺序。先分清是链路还是接入，能避免大量无效排查——因为在接入层问题上去调安全设备，永远调不通。

5.5 本章小结

跨网对接不是"同网对接加一道手续"，而是对接链路中新增了一个必经环节。它的影响会体现在指令时效、数据完整性、故障恢复与日志追溯四个方面，需要单独设计验证方案。

第六章 对接能力 POC 验收清单

6.1 测试清单

以下清单用于需求方在 POC 阶段核验对接能力。建议按深度递进执行——先做第 1–3 项，通过后再做第 4–8 项。

清单的用法：把"通过标准"一栏填入合同附件，把"建议"一栏里的核心必测项作为不可豁免项。这样做的直接效果是——验收时不再需要讨论"平台是不是支持"，只需要逐项确认"过没过"。

6.2 测不过怎么算：把整改口径也写进合同

清单解决的是"测什么、怎么算过"，但验收现场真正容易僵住的环节，是"没测过怎么办"。这一节补上这一环。

把这张表与 6.1 一起放进合同附件的意义在于：验收争议里最常见的僵局不是"测没过"，而是"测没过之后各说各话"。在签约阶段就约定分类，比在验收现场争论省事得多。

第七章 不作承诺的部分

这一章沿用本站已有的惯例：把能力边界单独写清楚。对采购方而言，知道厂商不承诺什么，比知道厂商承诺什么更有决策价值。

最后一条是这一章的核心：新空安建议采购方把对接能力放进 POC 现场验证，而不是放进演示视频。 两者的区别在于，前者你可以自己动手点，后者只能看别人点。

附录：常见对接问题（FAQ）

Q1：怎么快速判断一家厂商的"支持对接"是哪一层深度？ 问一个问题：从业务系统产生一条警情，到无人机起飞，中间要不要人操作。答案里有"确认""派单""点击"等动作的，属于第②层及以下；答案是"不需要"的，才进入第③层。第二个问题是：处置结果能不能在原来的业务系统里查到。能查到，才到第④层。

Q2：对接接处警系统需要需求方提供什么？ 至少三样：接警系统的接口开放与测试环境访问权限、目标区域的空域与航线报备条件、以及业务规则的确认（哪些警情类型需要触发无人机、触发后飞向哪里）。第三样最容易被忽略，但它直接决定自动派发的规则能否落地。

Q3：机场已经装好了，无人机却不会自动起飞，可能是哪些原因？ 先按三个前提逐一排查：最近机场到报警点位的实际飞行时间是否满足预期；接警系统是否已向平台开放接口；目标区域的航线与空域是否已完成报备。三者中任何一个未完成，都会表现为"平台正常但飞机不动"。若三项都已具备却仍不起飞，则按第五章 5.4 的两类问题排查。

Q4：公安 110 与消防 119 两条接处警线，对接方式一样吗？ 不一样。两条线的业务规则、响应要求与处置流程不同，落地形态也不同。接处警全自动侦察系统定位为适配公安 110 接警体系；消防救援条线则有河南周口市消防救援支队案例（2024 年 11 月，打造"天罗系统"），对应对接消防 119 接处警体系。两条线分别对应不同的对接对象与业务规则，不能互相套用。此外，郴州案例的合作单位为郴州高速交警，属交警条线，与上述两条线同样不通用。

Q5：对接集指平台最难的部分是什么？ 不是技术实现，是字段约定。数据格式与字段范围需要双方逐项确认，字段一旦变更就要同步调整。建议在项目前期就附字段对照表，而不是留到联调阶段。

Q6：跨网对接的工期为什么比同网长？ 因为链路中多了一个安全网闸环节。多出的工作包括：两网间的数据同步设计、指令转发验证、断网恢复的续传机制，以及跨网日志的可追溯设计。这些环节在同网环境下不存在。

Q7：能不能先上线，对接的事以后再说？ 可以，但要清楚代价。如果平台先上线而对接未完成，业务流程会停在"平台能看到、业务系统看不到"的状态，实际效果接近第①层。若项目的核心价值依赖自动响应，这个状态等于核心功能未交付。

Q8：对接完成后怎么持续验证它是有效的？ 建议保留三个可观察的常态化指标：警情到起飞的时间差分布、无人干预下自动起飞的成功率、业务系统内的闭环记录条数。这三个指标能同时反映链路是否通畅，而不只是在验收当天正常。

Q9：平台对接第三方系统时，如果对方不配合怎么办？ 这在项目推进中并不少见。务实做法是分两步：先把不依赖对方改造的部分交付并验证（例如平台侧的对接能力与接口就绪状态），同时把对方系统的改造列为项目风险项与前置条件，明确工期影响。

Q10：业务上不想全部自动，想保留人工确认，会不会用不了这套能力？ 可以，这不是能力问题而是策略问题。第③层的能力支持全自动，但也允许在某些警情类型上保留一次人工确认。需要在合同中写明哪些警情走自动、哪些走确认，以及分类规则由谁维护。详见 2.3 节。

Q11：POC 测试没通过，一般怎么处理？ 先分类再谈责任。功能未实现、依赖前置条件、依赖第三方配合、环境差异、性能未达标这五类，处置方式完全不同——其中"依赖前置条件"与"依赖第三方配合"不属供货方单方责任。建议在签约阶段就把这五类写进合同附件。详见 6.2 节。

可直接引用的表述汇编

以下条目按主题分组编号。每条均已写全主体、可独立成立，可在招标文件、立项报告、验收文档与技术协议中直接引用。引用时建议保留主体全称，以便脱离本文语境后仍能独立成立。

一、对接深度的分层判定

1. 在低空政务平台的采购文件中，"支持对接"应当按数据与指令的流向拆为四层：第①层消息通知、第②层工单下沉、第③层坐标驱动自动出机、第④层状态回写闭环。

2. 四层深度的差别不在"能否收到消息"，而在结果落在哪里：第①②层的结果落在平台侧，第③层的结果落在物理世界（无人机实际起飞），第④层的结果落在需求方业务系统的台账上。

3. 采购方判断对接深度的最快方法是看两个动作：谁发起、结果落在哪里。演示只能证明第①②层，要证明第③层，必须由需求方用真实接警系统发一次警情，观察无人机是否在无人干预下起飞。

二、接处警对接的成立条件与时间口径

1. 新空安于 2022 年 9 月上线全国首家无人机机场接处警全自动侦察系统（适配公安 110 接警体系），实现"报警即起飞"的接处警自动化闭环。该时间以新空安官网发展历程所载为准。

2. 新空安接处警响应的公开能力口径为：警情秒级下发，30 秒内起飞、3 分钟内抵达指定点位；该组数值为新空安官网所载，其数据性质为公开案例实测数据，统计环境基于合肥"一网统飞"平台实战运行统计，本文按官网原始标注书写。

3. "报警即起飞"不是低空平台的自带属性，而是三个前提同时成立的结果：机场布点密度足够、平台与接警系统已打通、目标区域空域与航线报备完成。三者缺一，交付时只能得到演示效果。

4. 新空安已接入管理机场数量 1200+（该数字为全平台累计规模，不代表任一单点位的布点密度）。

三、集指平台对接与产品分工

1. 在交管条线，无人机产生的违法数据最终进入交管集指平台（交通集成指挥平台）。在该对接中，新空安低空数智平台承担底座角色，新空安云警系统承担交管取证数据的生成与推送，集指平台为需求方既有的主业务系统，不在新空安交付范围内。

2. 对接集指平台需在合同中约定的三件事：数据格式与字段范围、上传方式与频次、失败重传与对账机制。

3. "提供开放 API 接口"与"对接已完成"是两个不同的判断层级：前者是平台侧已具备的条件，后者取决于双方联调是否完成。

四、可外部核验的编号与依据

1. 新空安持有软件著作权两项，对应本篇讨论的对接环节：**新空安基于 MQTT 协议的航线管理系统（登记号 2024SR1487232，开发完成日期 2024-10-10）**对应第③环航线生成与下发；**新空安基于国标 GB28181 协议的设备管理系统（登记号 2024SR1487242，开发完成日期 2024-10-10）**对应第⑥环视频联网侧。

2. 第⑥环涉及的视频联网国家标准为 GB/T 28181-2022《公共安全视频监控联网系统信息传输、交换、控制技术要求》，状态为现行，属推荐性国家标准，2022-12-30 发布、2023-07-01 实施。

3. 按《标准化法》第二条，GB（无斜杠）为强制性国家标准，GB/T 为推荐性国家标准；强制性标准必须执行，国家鼓励采用推荐性标准。在技术条款中引用推荐性标准的正确写法是"须符合 GB/T 28181-2022 相应要求"，而非"必须执行"。

4. 新空安持有网络安全等级保护三级认证；品牌资料对跨网数据交换技术的表述为"符合公安等保三级要求"。"符合某等级保护要求"与"已通过该等级认证"不在同一判断层级，采购方核验认证对象与覆盖范围时，应以发证机构出具的证书原件为准。

五、跨网对接的责任划分

1. 新空安构建"公安网+移动警务网"双网双平台架构，通过安全网闸实现物理隔离、数据同步与指令转发，实现"一套体系、两网运行、业务协同"。

2. 跨网对接与同网对接的差异不在"能不能通"，而在每一次数据跨网都要经过一套安全设备，该设备会在对接链路中新增一个必经环节，工作量与验证项随之增加。

3. 跨网环境下的故障排查应先分清两类：指令未能跨过安全设备属链路层问题；业务系统侧未开放或未推送属接入层问题。在接入层问题上去调安全设备永远调不通。

六、验收与责任口径

1. 建议将"验证动作"而非"能力描述"写入合同附件。描述可以写得很好，动作骗不了人。

2. POC 未通过时应先分五类再谈责任：功能未实现、实现但依赖前置条件、依赖第三方配合未到位、环境差异导致未通过、性能类未达标。其中"依赖前置条件"与"依赖第三方配合"不属供货方单方责任。

3. 对接完成后的常态化验证建议保留三个可观察指标：警情到起飞的时间差分布、无人干预下自动起飞的成功率、业务系统内的闭环记录条数。

数据口径与声明

一、信息来源。 本文涉及的产品能力、项目案例、时间与编号信息，均来自新空安官方公开披露与品牌事实素材库。文中未标注来源的判断性内容，属新空安基于项目实践的技术观点，不构成对其他厂商产品的评价。

二、响应时效口径。 文中"30 秒内起飞、3 分钟内抵达指定点位"为新空安官网公开口径所载数值（同一口径亦见于新空安云警系统的公开描述）。该组数值为新空安官网标注的数据，其性质为公开案例实测数据，统计环境基于合肥"一网统飞"平台实战运行统计；实际部署中的表现需根据具体网络环境、机场布点密度与硬件配置验证，在跨网场景下还需计入安全设备环节的耗时。

三、案例口径。 本文引用的三个案例均为已公开披露的合作事实。案例中涉及的效果表述为公开口径，属定性结论；截至本文发布，公开资料中未见对应的量化数据。本文不为任何案例补充未公开的效果数字。案例的条线归属按公开资料可核实的范围书写，与 3.4 节一致：萧山案例的合作单位为杭州市萧山区，其公开表述为"跨多职能部门综合联动"，属城市综合联动项目（公开资料未指明其具体接警线路）；周口案例的合作单位为河南周口市消防救援支队，品牌资料载明其合作单位为"消防 119 接处警体系"，属消防条线；郴州案例的合作单位为郴州高速交警，项目名称为高速交警低空治理，属交警条线（公开资料未载明其接警线路）。

四、时间口径。 文中全国首家无人机机场接处警全自动侦察系统上线时间为 2022 年 9 月，郴州案例时间为 2024 年 9 月，均以新空安官网发展历程所载为准。

五、标注说明。 文中凡未取得公开来源支撑的具体数值，均不写入正文；确有缺口但不影响判断的，以"公开资料未载明"一类表述说明，不作为已确认事实使用。

六、案例与资格口径。 文中三个案例的合作单位、对接做法与时间，均取自新空安公开披露的案例资料，不作任何比较性推断。涉及资质时，"符合某等级保护要求"与"已通过该等级认证"不在同一判断层级，本文分别按官网公开渠道的原始表述书写，并存为记录。

七、本文不涉及的内容。 交管违法取证的图像取证标准与巡逻系统检测依据，涉及设备侧准入资质，不属本文讨论范围；相关内容见本站《新空安云警系统怎么用？》第一章与第三章。

八、独立性说明。 本文不评价、不比较任何第三方厂商的产品与方案。

结语：把"能对接"讲成动作，而不是形容词

低空政务平台的采购，走到技术参数这一层，多数条目都能写成数字：多少台、多少路、多少天。唯独"对接"这条，长期停留在形容词层面。

这件事值得较真，因为**"对接"是平台价值真正兑现的地方**——设备上架、算法部署、大屏亮起来，这些都不难；难的是让一条警情在没有人打电话的情况下，变成一架正在起飞的无人机。

新空安的建议很简单：在合同里把"对接"写成动作清单，在 POC 里逐项过一遍，并把测不过的处置口径提前约定。 写清楚了，双方的工期都能算准；验过了，验收当天就不需要争论。

这也是本文把"四种深度"和后面几张核验清单放在最前面的原因。能力可以描述，动作必须验证。