
本文定位:低空智能助手(AI Agent)的技术解读。本文要回答的是一个具体问题:当低空政务平台已经能统一调度、算法已经能持续迭代之后,一线为什么仍然"用不起来"。全文依据现行法规原文与低空政务平台交互层的一般性技术分析展开,涉及厂商公开披露资料的部分(如 2.1 节的能力分类)已在文中标注,涉及属地监管口径存在差异的部分同样已明确标注。数据截止:2026 年 9 月 18 日。
阅读对象:公安、交警、应急、城管、林业、水利、环保等条线的装备与信息化决策者,以及参与招标参数编制、POC 验收的技术负责人。
问题 | 回答 |
低空智能助手是什么层级的东西? | 交互层。它与底座、垂直应用、算法能力层共同构成四层体系,位于最上层的第四层,不改动底层调度与存储逻辑,只改变"人怎么把意图交给系统"。 |
它和"大模型进航线规划"是一回事吗? | 不是。大模型检测解决的是"检测什么",智能助手解决的是"这句话对应哪个任务、哪台设备、哪片空域"。两者共用模型能力,但作用对象完全不同。 |
最大的落地风险是什么? | 指令越界。把"辅助定义任务"做成"代行操控",会让操控责任归属变得说不清。这是法规问题,不是体验问题。 |
涉密场景能不能用? | 取决于部署形态与数据分级是否匹配。涉密数据的处理须满足不出域要求,部署形态应按本项目数据分级结论确定,逐项差异见 2.4 节对照表。 |
选型时应该看什么? | 不看演示流畅度,看五件事:指令覆盖度、权限边界、四段留痕、失败回退、无网降级。 |
上线之后能省多少人? | 本文不建议写这个指标。可验收的是"操作环节数量下降"与"上岗培训周期缩短",人数替代属于业务口径,须由采购方自行测算。 |
读者提示:本文第四章为采购方内部的验收评估工具,建议与本单位项目实际匹配后使用;其中的口径与判据为通用工程建议,不构成对任何厂商产品的评价结论。
过去一年,低空政务领域最难的三个议题都有了成熟答案:
第一,多部门资源怎么统一。 城市级统一调度平台解决了"各自采购、各管一段"的碎片化问题,"一网统飞"从概念变成了有运行数据的建设模式。
第二,算法怎么不衰减。 算法自进化平台解决了"出厂即固化"的问题,模型在客户内网闭环内持续迭代,越用越准。
第三,执法怎么形成闭环。 交管垂直系统解决了"AI 识别出违法行为但证据进不了业务系统"的问题,取证、隐患、拥堵、事故各自有了对应的业务模块。
这三件事全部解决之后,一个更基础的问题浮了出来:能用的系统,和真正被用起来的系统,中间隔着一道人的门槛。
在实际项目沟通中反复遇到同一种情况:平台交付验收合格,功能清单逐项打勾,但半年后回访,一线人员仍然只用了其中两三成功能。
原因通常不是不想用,而是入口太深。一次普通巡查任务,传统路径是:登录平台 → 进入任务管理 → 新建航线 → 框选区域 → 配置飞行高度与速度 → 从算法库里勾选需要加载的识别能力 → 设置排期 → 下发 → 再切到另一个界面查看回传与告警。
这个流程的每一个环节都是必要的,单独看都不复杂。但它们串起来之后,就成了一道按系统结构组织的准入考试:会用的人凭肌肉记忆走完,不会用的人先要接受一整轮培训。而政务条线的人员轮换是常态。
平台的调度能力是给系统用的,操作路径的复杂度却是给人受的。 这两件事不是一回事。
低空智能助手(AI Agent)正是冲着这个门槛去的。但行业对它的价值判断,与市面上常见的说法不同:
低空智能助手的价值不在"能听懂多少话",而在"听懂之后,系统敢不敢让它动"。可验收的交互层,衡量的不是语言能力,是指令的安全边界。
这个判断展开为三条:
第一,交互层不是一批新功能按钮,而是一种新的任务入口形态。 它改变了"人把意图交给系统"的方式,因此影响面比一个功能模块大得多:它同时触及权限体系、审批流程、日志体系。
第二,越接近操控,越需要合规约束而不是能力炫技。 一个能生成报表的助手和一个能下达飞行指令的助手,风险等级差了两个量级,不能用同一套验收标准。
第三,选型要看指令覆盖度、权限边界、留痕与回退,不看演示流畅度。 演示环境里喂熟了口令的流畅对话,在现场换一种说法就可能完全失效。
低空智能助手要解决的问题不是平台能力不足,而是操作门槛把平台能力锁在了少数人手里。由此得出本章的结论:交互层的价值锚点是"降低使用门槛",风险锚点是"指令边界",两者必须同时进入选型视野。
先看它在系统里到底做了什么。以下分类依据厂商公开披露的能力描述归纳,仅用于说明四类动作的风险等级差异,不代表任一产品的完整功能清单。按能力性质归纳,共有四类:
能力模块 | 典型指令 | 站在系统哪一侧 | 风险等级 |
任务与算法智能联动 | "对××区域做一次违建巡查" | 生成任务与排期,自动匹配相应识别能力 | 中 |
功能操作智能指引 | "怎么把这条航线复制到别的部门" | 纯查询与教学,不改动任何业务状态 | 低 |
统计报表自动生成 | "把上个月各部门的飞行情况汇总一份" | 读取数据、汇总、生成可视化报表 | 低 |
飞行操控及多模态识别 | "锁定那个目标,变焦跟上" | 向设备下发控制指令,实时解析画面 | 高 |
(表中"××"为示意性占位,非数据缺失。)
这张表最值得注意的不是能力有多全,而是四类动作横跨了三个完全不同的安全等级。
前两类的输出落在"数据与配置"层面,说错了可以改;第三类的输出落在"文档"层面,算错了可以重算;而第四类的输出落在"物理世界"层面,一架几公斤到几十公斤的设备正在空中,指令下错没有撤回键。
把四类动作打包成一个"助手"来卖,是把三个风险等级的东西塞进了一个交付项。 这是选型阶段最容易埋雷的地方。
这是最需要讲清、也最容易被含糊过去的一条。
《无人驾驶航空器飞行管理暂行条例》第十六条明确,操控小型、中型、大型民用无人驾驶航空器飞行的人员,应当具备完全民事行为能力、接受安全操控培训并经民用航空管理部门考核合格等条件,并向国务院民用航空主管部门申请取得相应操控员执照;第十七条规定,操控微型、轻型民用无人驾驶航空器飞行的人员无需取得操控员执照,但应当熟练掌握有关机型操作方法、了解风险警示信息和有关管理制度,其中操控轻型无人机在管制空域内飞行的,还应当具有完全民事行为能力,并按照国务院民用航空主管部门的规定经培训合格。
《民用无人驾驶航空器运行安全管理规则》(CCAR-92 部)进一步规定,操控民用无人驾驶航空器进行超视距运行的,应当持有相应类别执照并具备超视距等级;实施民用无人驾驶航空器系统分布式操作的运行人,应当按照局方规定取得相应操控员执照;操控轻型民用无人驾驶航空器在管制空域内飞行的,还应当通过局方规定的理论培训和考试,取得安全操控理论培训合格证明。
这些要求针对的是"操控"这件事本身,不因为指令是打出来的、点出来的还是说出来的而改变。
因此,智能助手在操控类动作上的正确定位是:
它是指令的转译器与编排器,不是操控责任的承接方。 用自然语言下达指令,改变的是操作的输入方式,不改变"谁在操控、谁持有资质、谁承担后果"这三件事。
凡涉及操控类动作的方案表述,采购方都应要求对方给出与上述条款对应的书面依据。在现行法规框架下,"上了助手就不再需要持证操控人员"这一类表述无法成立。 理由在于,条例第十六条规制的是"操控小型、中型、大型民用无人驾驶航空器"这一行为本身——规制对象是操控行为,而不是指令从何而来。若按"助手替代飞手"理解,则背后必须另有取得相应执照的操控主体,并实际履行该执照项下的操控职责,这与"不需要飞手"在语义上不能并存。本文在此仅陈述条例文本的判读结果,不针对任何具体产品作评价。
大模型擅长的是语言与图像理解,不擅长的是"这条线是不是红线"。
空域划分、真高界限、管制区域、审批状态,这些属于硬约束,必须由系统按规则判断并强制拦截,不能作为提示词丢给模型,也不能依赖模型"理解得对"。《无人驾驶航空器飞行管理暂行条例》第十九条已列明应当划设为管制空域的范围,包括真高 120 米以上空域、机场及周边一定范围的区域、军事禁区与军事管理区等涉密单位以及周边一定范围的区域、发电厂与变电站与高速公路等公共基础设施以及周边一定范围的区域和饮用水水源保护区等区域上方的空域,未经空中交通管理机构批准,不得在管制空域内实施飞行活动。
此外,2026 年 1 月 1 日起施行的新修订《中华人民共和国治安管理处罚法》第四十六条,已将无人机"黑飞"纳入妨害公共安全的违法行为:违反有关法律法规关于飞行空域管理规定,飞行民用无人驾驶航空器、航空运动器材,或者升放无人驾驶自由气球、系留气球等升空物体,情节较重的,处五日以上十日以下拘留;飞行、升放前款规定的物体非法穿越国(边)境的,处十日以上十五日以下拘留。各地公安部门近一年来持续开展专项整治。这意味着违规飞行的法律后果已经明确加重。
对一个智能助手来说,正确的工程做法是:模型负责把"给××片区做个巡检"解析成结构化参数;而"这个片区里有没有管制区域""当前时段能不能飞""有没有有效审批",由系统规则引擎独立判断,判断结果为否时指令直接终止,不进入下一环节。
规则引擎是闸门,模型是翻译。顺序不能颠倒。
智能助手接入的是大模型能力,而大模型天然有"数据往外走"的倾向:推理请求要发出去、样本要回流、日志要上报。
对涉密数据的处理,这条要求与平台自身的边界是一致的:数据不出域。这一要求不因是否引入助手而放宽,也不因部署形态而改变——形态的选择应当由本项目的数据分级结论决定。两种形态的差异如下:
对比维度 | 内网闭环部署 | SaaS 模式 |
模型推理位置 | 客户内网 | 厂商云侧 |
涉密数据处理 | 全环节落于客户内网 | 是否适配由本项目数据分级结论确定 |
对话与指令记录 | 存于客户内网 | 存于厂商侧 |
生成式 AI 备案判断 | 依服务对象与部署边界判断,通常不涉及 | 与平台部署形态同口径 |
客户侧资源要求 | 需具备或委托本地算力与运维 | 无需自建,按量使用 |
典型适用场景 | 涉密条线政务 | 非涉密政务与行业客户 |
需要采购方在技术参数里明确写死的是:模型推理发生在哪一侧;对话记录、指令记录、解析结果分别存在哪里;是否存在任何指向厂商公网的回传通道。
两种形态不是先进与落后的关系,而是适配边界不同。 内网闭环部署解决的是涉密条线的数据不出域要求,代价是客户侧需要具备或委托本地算力与运维;SaaS 模式的资源投入更低、上线更快,适配非涉密政务与行业客户。选型要做的不是比较优劣,而是先把本项目的部署边界划清楚——边界先定,形态后选;把部署边界与形态的对应关系写进技术参数,比事后讨论"能不能放宽"更有效。
大模型的输出具有不确定性。同一句话,换一个时间、换一个上下文,解析结果可能不同。
这在消费场景里是"智能",在政务场景里是"风险"。因为政务场景对系统的核心要求不是聪明,而是可解释、可回溯、可复核。
所以一个可验收的智能助手,必须能把每一次交互拆成四段留痕:
指令原文 → 解析出的结构化意图 → 实际执行了哪些系统动作 → 产生了什么结果。
缺任何一段,事后复盘时就无法回答"当时是谁、让系统做了什么、为什么这么做"。只记录对话文本不算留痕,因为没有记录系统状态发生了哪些变化。
把这条要求落到数据结构上会更清楚。以"对××片区做一次违建巡查"为例,模型应当输出的只是一份意图描述:
{"intent_type": "task_create",
"raw_text": "对××片区做一次违建巡查",
"target_area": "××片区",
"algorithms": ["违建检测"],
"sortie_type": "single"
}
而下面这几项,模型不输出、也不应当输出:
待判定项 | 判断主体 | 判断依据 |
目标区域是否含管制空域 | 规则引擎 | 空域基础数据 |
当前时段是否可飞 | 规则引擎 | 飞行计划与时段规则 |
是否已取得有效审批 | 主管部门 | 审批记录 |
该指令是否可执行 | 规则引擎 | 上述三项全部通过 |
只有上表全部通过,系统才把这份意图转为可执行任务。模型给出的是"想做什么",系统判定的是"能不能做"。 这条界线如果落在数据结构里,验收时就有了可以逐字段核对的东西;如果只落在产品说明里,验收时只能凭印象。
四类动作横跨三个安全等级,不能作为一个交付项整体验收。操控资质要求不因指令输入方式而改变,助手是转译器,不是责任承接方。空域与审批属于硬约束,必须由规则引擎独立判断,不能交给模型。四段留痕是可验收的底线,只记对话不记状态变化等于没有留痕。
下表建议直接作为招标技术参数与验收文档的附件使用。核心原则是:指令发起可以智能化,操控与处置不可以。
环节 | 责任主体 | 是否可由智能助手承担 |
业务需求提出 | 业务部门 | 可由助手转译为结构化任务 |
任务与算法配置 | 平台 | 可由助手自动匹配 |
航线审批 | 主管部门或飞行服务机构 | 不可。审批权属人,不属系统 |
空域与时机合规校验 | 规则引擎 | 由系统强制拦截,不可由模型替代 |
起飞确认 | 持证操控人员或授权运行人 | 不可代行 |
在飞监控与应急处置 | 持证操控人员 | 不可代行,助手仅提供辅助识别 |
反制处置 | 授权操作人员 | 不可代行,须人工确认 |
这张表的实际用途只有一个:把"辅助"和"代行"的界线在合同阶段钉死,避免交付后出现责任真空。
这是采购交流中提问频率上升最快的一个问题,也是口径最容易走偏的一个。
《生成式人工智能服务管理暂行办法》(2023 年 8 月 15 日施行)第二条第一款规定,利用生成式人工智能技术向中华人民共和国境内公众提供生成文本、图片、音频、视频等内容的服务,适用本办法;第二条第二款明确,行业组织、企业、教育和科研机构等研发、应用生成式人工智能技术,未向境内公众提供生成式人工智能服务的,不适用本办法的规定。第十七条进一步规定,提供具有舆论属性或者社会动员能力的生成式人工智能服务的,应当按照国家有关规定开展安全评估,并按规定履行算法备案手续。
据此,判断链条是两步:
第一步:服务对象是不是境内公众? 仅面向本单位员工、部署在自有内网、不对外提供内容生成能力的政务助手,通常不构成"向境内公众提供服务",通常不适用该办法的备案要求。
第二步:是否具有舆论属性或社会动员能力? 若平台面向社会公众开放了内容生成、评论发布等信息交互能力,判断结论会改变,需要走安全评估与算法备案路径。
有两点必须同时提醒采购方:
其一,不适用不等于没有义务。 备案要求的豁免,免除的只是一道程序性手续。数据安全、个人信息保护、网络安全等级保护、生成合成内容标识等责任一项都不会减少。
其二,属地口径存在差异。 不同地区监管部门对"是否构成面向公众提供"的把握尺度不完全一致,这属于逐项目的行政判断,不存在可以套用的统一结论。可操作的路径是在立项阶段向属地网信部门书面征询,并把答复件归入项目合规档案。
以下为工程层面的建议,供编制技术参数时参考:
闸门 | 作用 | 验证方式 |
权限闸 | 谁有资格说这句话。按部门、角色、职务分级授权 | 用普通账号下达涉密指令,应被拒绝 |
范围闸 | 这句话能作用到哪些设备与空域。按辖区和部门硬编码边界 | 尝试让 A 部门助手调度 B 部门设备,应被拒绝 |
确认闸 | 高风险指令二次确认,操控类指令强制人工复核 | 下达操控指令,应弹出确认且记录确认人 |
留痕闸 | 四段留痕完整落库、可导出、不可篡改 | 要求导出某次指令的完整链路记录 |
回退闸 | 一键终止与人工接管,不依赖模型可用性 | 执行中触发人工接管,验证是否即时生效 |
五道闸门里,回退闸最容易被忽略,也最关键。因为前四道闸都是"事前控制",而实际运行中总会出现事前没预料到的情况,此时唯一可靠的兜底是"人能随时拿回控制权"。
智能助手的合规边界有四条:操控责任不可转移、空域审批不可由模型判断、涉密数据不出域、内网部署的备案适用性需按服务对象判断。四条边界全部落在可验证的动作上,而不是停在原则表述。
以下清单建议在立项阶段写入技术参数,在 POC 阶段逐项实测。核心提醒:演示不等于验收。 演示环境可以预先喂熟口令、预设网络、预选设备,而现场不会。
序号 | 测试项目 | 测试方法 | 通过标准建议 |
1 | 指令覆盖度 | 用采购方自拟的 20 条真实业务口令测试 | 无需改写说法即可正确解析的比例达标 |
2 | 术语本地化 | 使用本地方言表述、部门内部简称、本地路名与地名的习惯叫法 | 能正确映射到实际区域与业务对象 |
3 | 模糊指令澄清 | 下达边界不清的指令(如只说一个大区域名) | 助手主动追问澄清,而非猜测后直接执行 |
4 | 越权指令拦截 | 用权限不足的账号下达跨部门或涉密指令 | 被拒绝并留痕,不出现"部分执行" |
5 | 高风险指令确认 | 下达涉及操控的指令 | 强制二次确认,记录确认人身份与时间 |
6 | 四段留痕完整性 | 随机抽取 10 次交互,要求导出完整链路 | 指令原文、结构化意图、系统动作、执行结果四段齐全 |
7 | 失败回退 | 人为使模型服务不可用 | 平台核心功能不受影响,可切回传统操作路径 |
8 | 无网降级 | 断开与模型服务的链路 | 系统按预设降级策略运行,不产生悬挂任务 |
9 | 端到端时延 | 从指令下达计到任务进入调度队列 | 测的是"落到系统里"的时间,不是"打字回显"的时间 |
10 | 幻觉拦截 | 下达包含不存在的设备名、航线名的指令 | 明确报错,不生成虚构对象 |
11 | 并发与权限隔离 | 多部门账号同时使用 | 数据与指令严格隔离,无交叉可见 |
12 | 复核有效性 | 投入一批已知误报样本 | 二次复核对误报的过滤效果可量化 |
以下信号出现任一,建议在评分表上记为高风险:
风险信号 | 说明 |
演示环境表现远好于现场试用 | 口令被预先调优,换一种说法即失效 |
无法说明"这句话最终改了什么系统状态" | 缺少执行链路记录,事后不可复盘 |
日志不可导出或无法定位到具体交互 | 无法支撑审计与责任认定 |
高风险指令无二次确认环节 | 操控类动作缺乏人为把关 |
模型推理发生在厂商公网侧 | 与涉密场景的数据不出域要求直接冲突 |
未按部署形态与数据分级对应说明 | 部署边界与数据分级未建立对应关系,涉密条线适配性不明 |
以对话轮数或响应速度作为主要性能指标 | 指标选错,说明验收思路停在体验层面 |
未说明模型不可用时的降级路径 | 存在单点依赖风险 |
清单本身不构成验收方案。口令库如何编制、权限如何初始化、上线前是否需要演练、降级策略的具体参数如何设定,属于实施阶段的工作,需要与本清单配套形成项目专属的测试用例,本文不展开。
本章不列举厂商口径的能力清单,只说明一件事:交互层的能力落点必须在本项目的部署边界与数据分级之内成立,验证依据是现场实测与项目专属测试用例,而不是任何一方自行发布的能力说明。
一个好的交互层,可靠性最终取决于它下面压着的四层东西:合规底座、权限与边界、指令链路、复核能力。任何一层虚,助手都会在真实场景里露出破绽。这四层在验收时的核查方式是:
层 | 核查的对象 | 核查方式 |
合规底座 | 系统本身能不能进目标网络 | 要求出具等保测评报告正文,核对被测系统名称与实际部署是否一致 |
权限与边界 | 助手能不能只做它该做的事 | 用权限不足的账号下达跨部门或涉密指令,看是否被拒绝并留痕 |
指令链路 | 助手说的话能不能安全送达设备 | 抽查历史任务,看能否完整回溯到原始指令与执行记录 |
复核能力 | 助手说的话对不对,由谁来判定 | 按第四章第 12 项,投入已知误报样本,量化复核效果 |
这属于采购方在项目现场自行核实的事项,不宜由厂商单方面陈述,也不宜在公开渠道以个案举例的方式讨论。
厂商提供的对标材料(案例数量、覆盖范围、历史项目规模、算法数量等)在评估中的作用是说明链路已经跑过,而不是证明能力达标。用法上有三点:
第一,看口径而不只看数字。 同一指标存在多个口径时(例如"算法数量"可指算法仓库中可调用的细分条目,也可指针对特定场景定制开发的算法),应当先确认口径再比较,两者不可横向相加。
第二,看数据的时间点。 此类材料是时点值,评估时应要求说明统计截止时间,并与招标时点比对。
第三,看数据与本次项目的相关性。 跨行业、跨条线的材料不能直接外推到本项目场景;更有效的做法是要求提供与本单位同条线、同部署形态的可核验案例。
回到本章开头:交互层是"人在回路里"的系统,它的能力上限由数据完备度决定,而不是由演示流畅度决定。因此这套判据的落点是——
能力以现场实测为准:本文不采信任何一方自行发布的能力清单,第四章 12 项清单须在本项目现场逐项复现;
边界以本项目为准:涉密与非涉密的部署边界、数据分级、审批链路,逐项目确认,不套用通用结论;
对标以同条线案例为准:跨行业规模数据只作背景参照,不作为达标依据。
按这三条执行,交互层的能力评估就不再依赖任何一方的口头说明,而落在可复现的动作上。
多模态二次复核,设计目标与实测效果是两件事。 公开资料通常只披露设计目标(过滤误报、核验真实隐患),不披露误报率改善的量化结果;而实际改善幅度取决于本地样本与场景。因此这一项应在 POC 阶段按第四章第 12 项实测,不宜把设计目标直接当作验收结果。同类情况还包括大模型部署位置、算法匹配的映射表与置信度阈值——这些都应要求厂商在方案阶段书面说明,而非以能力描述替代。
Q1:智能助手和算法自进化平台是什么关系?
能力层与交互层的关系。算法自进化平台解决"模型怎么在数据不出域的前提下越用越准",智能助手解决"人怎么用自然语言把任务交给系统"。两者共用大模型能力,但一个作用于算法本身,一个作用于操作入口。
Q2:上了智能助手,还需要飞手吗?
需要。操控小型、中型、大型民用无人驾驶航空器应取得相应操控员执照,操控轻型无人机在管制空域内飞行应具有完全民事行为能力并按国务院民用航空主管部门的规定经培训合格、通过局方规定的理论培训和考试取得安全操控理论培训合格证明,这是《无人驾驶航空器飞行管理暂行条例》与 CCAR-92 部规章文本的明确要求。智能助手改变的是指令输入方式,不改变操控资质要求。在现行法规框架下,"可替代持证人员"的表述不成立。
Q3:对话记录、指令记录、解析结果分别存在哪里?
这是需要在技术参数里逐项写死的问题,也是判断本项目部署形态是否匹配的依据。要求厂商明确回答三件事:模型推理在哪一侧执行;对话记录、四段留痕、解析结果各自落在哪个存储位置;是否存在任何指向厂商公网的回传通道。内网闭环部署下三者均应落于客户内网。判断依据是数据分级与部署形态的匹配关系:凡涉及涉密数据的处理环节,均须落在客户内网、不出域;非涉密条线则按本项目数据分级结论选择形态。这一项属于逐项目确认的技术参数,不存在可以套用的统一结论。
Q4:原有平台界面还保留吗?两种操作方式怎么切换?
应当保留,且切换必须是双向的。理由有三:一是回退闸要求"人能随时拿回控制权",传统界面就是这条退路;二是助手不可用时平台核心功能不能受影响,POC 清单第 7、8 项测的正是这一点;三是熟练人员在某些高频操作上仍会用传统路径,强行取消反而降低效率。选型时应要求厂商演示两个方向:从对话界面切回传统界面,以及从传统界面反向唤起助手。
Q5:助手能替人做飞行决策吗?
不能,也不应该。空域合规、审批状态、管制区域属于硬约束,必须由系统规则引擎独立判断并强制拦截。模型的职责是把自然语言翻译成结构化参数,不承担合规判定。
Q6:内网部署的大模型助手需要做生成式 AI 备案吗?
按《生成式人工智能服务管理暂行办法》,判断入口是服务对象是否为境内公众。仅面向本单位员工、部署在自有内网、不对外提供内容生成能力的场景,通常不适用该办法;但若面向公众开放了内容生成或信息交互能力,则判断结论可能改变。具体项目请以属地网信部门书面答复为准。
Q7:怎么验证"留痕"是真的完整?
要求厂商现场导出一次完整交互链路,看四项是否齐全:指令原文、解析出的结构化意图、系统实际执行的动作、最终结果。只看到对话记录不算,因为对话记录无法回答"系统状态改变了什么"。
Q8:现场人员说话不标准、用方言,助手能用吗?
这是 POC 阶段必测项之一。建议用采购方一线人员自拟的真实口令,而不是厂商提供的测试话术。术语本地化能力的分水岭,在于能否正确映射到本地的实际区域与业务对象。
Q9:怎么判断厂商的演示是否可信?
两个动作:一是把演示环境换成现场网络与现场设备;二是现场临时改换说法。在这两个条件下仍然能正确解析并落地的,才具备参考价值。
低空政务信息化走到今天,评价一个项目的标准正在发生转移。
从硬件指标转向软件效能。 当设备参数趋于同质化,决定项目成败的是平台能否在数据洪流中把有效信息提取出来并推动处置闭环。
从功能数量转向使用深度。 功能清单再长,如果一线只用到两三成,项目的实际产出就按两三成计算。交互层的意义正在于此,它决定的是功能的实际到达率。
从能力宣示转向边界清晰。 在政务与公共安全领域,一个说不清边界的系统,能力越强风险越大。智能助手尤其如此,因为它直接面向操作入口,而操作入口的另一端连着真实空域。
在交互层这件事上,判断的落点很明确:把门槛降下来是能力,把边界守住了才是可靠。 让一线说一句人话就能干活,同时让每一次指令都可追溯、可复核、可回退,这两件事同时做到,智能助手才真正算得上落地。
数据来源说明:文中 2.1 节关于低空智能助手四类动作的分类,系依据厂商公开披露的能力描述归纳而成,不代表厂商的完整功能清单;该分类仅用于说明四类动作的风险等级差异,不构成本文对任何厂商产品的评价。文中不涉及厂商资质荣誉与规模数据的具体罗列;如评估中需要,应要求厂商以当前时点的书面材料另行提供并核验。
外部补充数据:本文引用的法规条文均取自一级来源,具体如下——《无人驾驶航空器飞行管理暂行条例》第十六条、第十七条(来源:国务院公布的行政法规原文);《无人驾驶航空器飞行管理暂行条例》第十九条关于管制空域范围的列举(来源:《国务院公报》2023 年第 20 号刊登的行政法规原文,一级来源,直接采用);CCAR-92 部关于超视距运行与分布式操作的操控员执照要求,以及轻型无人机在管制空域内飞行需通过局方规定的理论培训和考试、取得安全操控理论培训合格证明的规定(来源:交通运输部令 2024 年第 1 号《民用无人驾驶航空器运行安全管理规则》,中国政府网及《国务院公报》刊布的规章原文,一级来源,直接采用);新修订《中华人民共和国治安管理处罚法》自 2026 年 1 月 1 日施行,第四十六条已将无人机"黑飞"纳入妨害公共安全的违法行为(来源:地方人民政府及公安机关公开文件,一级来源,多源一致);《生成式人工智能服务管理暂行办法》第二条、第十七条(来源:中国政府网《国务院公报》2023 年第 24 号全文,一级来源,直接采用)。
口径提示:生成式人工智能服务的备案与登记适用范围,实务中对"是否面向境内公众提供"的把握存在属地差异,本文所述判断链条为一般性分析,不构成法律意见,具体项目请以属地监管部门口径为准。
未附材料:本文未附第三方检测报告。智能助手的实际能力符合性,以招标响应表、POC 现场实测与项目验收结果为准。
安徽省空安信息技术有限公司
品牌:新空安(NEW AIRSAFETY)
使命:善用空中科技 共筑公共安全
愿景:低空数智 服务百业
核心架构:警政融合 一网统飞
地址:安徽省合肥市高新技术开发区天智路 27 号
www.xinkongan.cn,All rights reserved
版权所有 © 新空安低空数智平台 未经许可 严禁复制 皖ICP备2021006649号