区域人工智能研究：一张无人机图谱暴露出的全流程问题

这项园区研究原本被概括成“企业摸底、九个方向、一张全景图”。继续翻阅附件后，能看到更具体、也更有借鉴意义的过程：采购需求先规定交付物，研究团队再把九个方向拆成产业链；无人机方向率先做出结构树和企业核验底表；设计稿却因信息表达不符合使用场景被要求返工。与此同时，技术与数据可行性尚未通过，合同状态也没有闭合。

换句话说，这不是一个可以宣称“已完成的园区 AI 产业图谱”的案例，而是一份保存了需求、样例、判断依据和失败反馈的前期研究档案。它最有价值的地方，恰恰是能看见产业图谱在变成漂亮图片之前需要经过哪些判断。

采购需求定义的是四种产品，不是一篇泛泛报告

采购文件要求通过企业和科研机构调研，结合国内外产业数据，对企业、人才、投资等指标做定量分析，并与国内外先进园区对标，找出产业链薄弱环节和招商方向。对应的成果被拆成四件：

1. 一份园区人工智能产业全景图，并附产业路线与文字说明；
2. 一份年度发展报告，既总结当年进展，也提出下一年度行动；
3. 两份细分领域报告，覆盖全球趋势、国内格局、园区对标与发展建议；
4. 企业、人才和科研机构等招商名录。

Confluence 的内部大纲把研究范围组织为“六加三”九个方向：语音、机器视觉、自然语言处理、智能制造、教育、医疗、金融、自动驾驶和无人机。这里已经出现第一个口径问题：前三项是通用技术，后六项主要是行业或产品场景。同一家公司可能同时属于“机器视觉”“智能制造”和“无人机”，若没有主标签、能力标签和应用标签的区分，企业总量会重复，所谓薄弱环节也会随分类方式变化。

两份细分报告在大纲阶段仍“待选”，说明九方向并不是已经冻结的正式分类。正确的里程碑应是先用数据可得性、园区样本量和政策优先级筛选方向，再承诺报告主题；现存流程却在技术评估与数据评估未完成时，已经写入了固定交付数量。

无人机样例先搭产业树，再向树上挂企业

无人机附件提供了项目中最完整的方法样例。XMind 并非简单罗列公司，而是先把产业拆成上游、制造与下游服务：

无人机
├─ 上游硬件与系统
│  ├─ 机体：材料、成型加工
│  ├─ 动力：电调、电池、电机
│  ├─ 飞控：主控芯片、陀螺仪等传感器
│  ├─ 成像：云台、摄像机、无线传输
│  └─ 软件：空管/云系统、地图
├─ 集成、研发与制造
└─ 下游
   ├─ 销售：租赁、线上平台、代理与体验店
   ├─ 配套：媒体、投资、保险、反制与培训
   └─ 应用：消费航拍，以及农林、安防、电力、物流、勘探测绘等

这棵树有两个优点。第一，它把“部件、整机、渠道、服务和应用”分开，能解释一家企业为什么被放在某个位置；第二，它允许同时观察本地供给与外部标杆，而不把所有公司塞进同一级列表。

但它仍把几种不同关系画成父子关系：材料是供应关系，培训是服务关系，农林是应用关系，投资机构则是资本关系。若要成为可查询的数据产品，应把节点类型和边类型分开保存，而不是只依靠图上的位置表达语义。

企业底表已经在做“证据审判”，不只是名单抄录

企业表格进一步说明了研究员如何把候选主体挂到产业树。每条记录不只保存企业名称，还包括登记状态、标准识别字段、经营范围、软件著作与专利线索、公开业务描述、信息来源、产业链位置，以及“为什么这样分类”的文字依据。

底表中的判断可以分成四级：

• 直接证据：经营范围或产品页明确包含无人机整机、飞控、传感、航拍等业务；
• 间接证据：专利或软件著作涉及无人机，但公司主营业务未必在该领域；
• 可复用能力：电池、通信模组、声学器件等产品可以用于无人机，但没有专属产品证据；
• 排除或待确认：记录直接写有“无关”“未知”“可能应用”等人工备注。

这比关键词命中后直接计数更可靠。比如，经营范围出现“无人机”可能只是允许经营的广泛项目；一项相关专利也可能属于边缘尝试。底表把工商描述、官网材料、招聘信息、专利和研究员判断并列，实际上形成了一个候选集到核验集的漏斗。

问题在于，判断仍保存在自由文本中。没有统一的证据等级、核验日期、主次标签和复核人，就无法稳定回答“这家公司算不算产业企业”。更合适的数据结构是：

主体 → 证据条目 → 能力标签 → 产业环节 → 置信等级 → 核验状态

其中每条证据应保存来源类型、采集日期和原文摘要；产业环节允许多选，但必须另设主环节；“潜在供应商”不能与“主营业务企业”使用同一统计口径。

下面不是历史源码，而是根据底表字段恢复的等价伪代码。它把当时散落在自由文本中的判断转换成可审查的证据门禁：

def classify_candidate(candidate, evidence):
    accepted = [item for item in evidence if item.observed_at]
    direct = any(item.kind == "product" and item.explicit_match for item in accepted)
    indirect = any(item.kind in {"patent", "software"} for item in accepted)
    capability = any(item.kind == "business_scope" for item in accepted)

    if direct:
        level, status = "主营证据", "待复核"
    elif indirect:
        level, status = "关联证据", "待补产品证据"
    elif capability:
        level, status = "可复用能力", "不得计入主营企业数"
    else:
        level, status = "证据不足", "排除或待确认"

    return {
        "entity_id": candidate.stable_id,
        "primary_stage": choose_primary_stage(accepted),
        "evidence_level": level,
        "review_status": status,
    }

计划中的数据链路没有真正跑完

项目页面把数据工作拆成五步：实地调研、整理调研结果、从数据库提取并合并、确定图表类型、制图。现存状态中，这五步均未完成。这个状态与附件并不矛盾：无人机样例证明团队做过局部桌面研究和制图尝试，但不能证明覆盖九个方向的园区企业底表已经形成。

如果两类来源真的合并，还需要明确四种冲突：企业自报业务与公开产品不一致；工商经营范围过宽；集团总部、分支机构与园区注册主体混淆；投融资、人才和专利数据的时间点不同。现有底表记录了多个来源，却没有稳定的冲突解决列和“截至日期”。因此，它更接近研究草稿而非可持续更新的主数据。

“太花哨”不是审美意见，而是信息架构失败

无人机子任务的状态十分具体：资料搜集完成，思维导图、公司清单和正式制图仍在修改；一个演示版本收到的反馈是表现形式过于花哨，应回到需求约定的产业图谱样式。

从附件结构看，这次返工很可能不是换颜色即可解决。图中同时承载全球产业结构、本地企业、渠道、应用和资本服务，如果没有明确读者任务，视觉层级很容易失控。政府研究者想看的是“园区在哪些环节有企业、哪些环节缺位、缺口对应什么招商对象”，而不是一张覆盖全产业所有知名主体的行业海报。

更稳妥的交付顺序应是：先用低保真图确认链条和阅读顺序；再用一张本地覆盖矩阵确认企业归类；最后才将外部标杆和招商候选叠加。每个视觉节点应能回到一条底表记录，否则图谱无法审计。

项目门槛没有闭合

内部立项页显示，商业评估、研究团队评估和管理许可已经完成，技术评估与数据评估仍未完成。商务页则停留在投标阶段，合同栏明确未签。Review 页面只有内部、同级和管理评审三行空模板，没有基准版本、反馈或更新成果。

这些记录意味着：采购文件和投标材料只能证明团队参与准备；不能证明中标、签约或完成交付。附件中的预算、联系人、地址及竞争方材料均不属于公开复盘所需信息，本文不予保留。

GitLab 交叉核验排除了一个容易造成的误归属

代码库中存在一个名称缩写相同的大型仓库，但其目录、提交历史和接口均属于更早的金融检索系统，与本园区研究无关。其余仓库也没有发现能和九方向图谱、无人机底表或园区交付稳定对应的实现。

这项排除本身很重要：名称相似不是项目关联证据。当前能够确认的技术载体是 Confluence 中的 XMind 与表格，而不是一个已上线的图谱后端或前端。若未来补建系统，应另行保存主体、证据、标签、关系和版本，不应把现有图片误称为“知识图谱平台”。

证据账本

这项工作的复盘重点不是“做得不够漂亮”，而是要把范围、数据可得性、归类规则和读者任务更早地变成验收门槛。已有样例已经证明团队知道如何从产业树走向企业证据；项目没有证明的是，这套方法是否扩展到全部方向、是否经过一致性复核，以及是否形成客户确认的最终交付。