Data sovereignty · Closing the chain
制作者数据在边缘 AI 中的价值体现
前三篇分别论证了 FPV 经济学、边缘 AI 的战场核心地位、制作者数据的估值练习。中间悬空的关键论证——为什么是这种数据、为什么 GitHub / 合成数据 / 仿真平台无法替代——在这一篇补齐。
May 21, 2026 · ~18 min read
前三篇分别论证了 FPV 经济学、边缘 AI 的战场核心地位、制作者数据的估值练习。但中间有一层关键论证悬空了:为什么是这种数据?为什么 ground-truth 三元组无法被 GitHub、合成数据、仿真平台替代?这一篇专门补这道缺口。
引子
前三篇文章构成了一条论证链:
- 《全光谱成本经济学分析》——为什么 ¥200 级 FPV 会改写战场经济学
- 《边缘 AI:低成本地面 FPV CQB 时代的核心枢纽》——为什么前线一体机会成为攻防核心
- 《制作者数据值多少:一次反复挤泡沫的估值练习》——这些数据值多少钱
但仔细看就会发现:第三篇是从买方需求规模反推数据价格,中间跳过了一个关键问题——
买方为什么必须买这种数据?用 GitHub、用合成数据、用仿真平台不行吗?
如果这个问题没答好,前面所有估值推导都是悬空的——因为只要存在替代品,需求就会分流,价格就会崩塌。
这篇文章专门处理这个问题:逐项拆解边缘 AI 在 CQB 场景的能力需求,看制作者三元组在每一项上的不可替代性到底有多强。
一、把第二篇的三重职能翻译成训练任务
第二篇文章把边缘 AI 的职能分成三层:辅助决策、辅助制造、终端制导。每一层在机器学习语言里对应的具体训练任务是:
| 边缘 AI 职能 | 对应的具体训练任务 | 所需数据形态 |
|---|---|---|
| 辅助决策(战术) | 多模态视频理解 + 多车协同 RL | 视频帧 + 操作员动作 + 战果反馈 |
| 辅助制造(后勤) | 代码生成 + 硬件适配 + 失效预测 | 需求 + 代码 + 编译结果 + 物理验证 |
| 终端制导(打击) | 目标识别 + 失联自主控制 | 传感器流 + 控制指令 + 物理状态 |
注意这三项都不是单纯的"代码"或"图像"或"文本",而是多模态绑定的数据——必须把"做了什么"和"结果是什么"绑在一起,模型才能学到因果而不是相关。
这正是制作者三元组(需求→代码→物理验证)的天然形态。下面逐项拆解。
二、辅助制造:最直接的价值兑现
这是制作者数据价值最容易看清楚的一环。
任务拆解
边缘 AI 在战时要承担"修械所"功能:
- 根据当周可获得的料件,生成可工作的硬件方案(电路图、布线、固件框架)
- 针对该方案生成具体固件代码
- 预测代码是否能编译通过、烧录后是否能正常工作
- 失败时定位问题(料件批次问题?代码 bug?协议不匹配?)
GitHub 数据为什么不够
GitHub 上有 TB 级嵌入式代码。但训练一个能完成上述任务的模型,GitHub 数据的缺陷是结构性的:
缺陷 1:没有"失败"的样本。GitHub 上几乎所有代码都是"作者认为能跑"的版本。但模型必须学会"什么样的代码会编译失败、为什么"——这需要编译失败的完整日志和修复过程,而不是只有最终成功的代码。
缺陷 2:没有硬件配置的对应关系。GitHub 上一段 I2C 驱动代码,可能对应着完全不同的引脚配置、上拉电阻、I2C 速率、目标芯片。代码本身不携带这些信息——它们藏在作者的电脑屏幕外,藏在烧录时的命令行参数里,藏在调试时的串口输出里。
缺陷 3:没有物理验证。一段代码在 GitHub 上有 1000 个 star,但没人知道它在你手边这块板子上能不能跑。模型从 GitHub 学到的是"看起来对"的代码,不是"真的能跑"的代码。
制作者三元组在这里的独占价值
esphome.cloud 构建管线流过的数据天然解决了上面三个缺陷:
- 每次构建都有结果(成功/失败 + 完整编译日志),失败样本数量充足
- 硬件配置完整保留(
.espctl.toml、引脚映射、目标芯片型号都在元数据里) - 后续验证可追溯(用户烧录后的串口日志、试验结果可以反向关联到当次构建)
这三项叠加,让训练出的模型从"能生成代码"跨越到"能生成可在指定硬件上跑通的代码"。这一跃恰恰是前线"修械所"功能能否成立的关键。
价值量化
把"代码生成"细化到"针对指定 BOM 生成可工作固件",训练这个任务所需的数据规模大概是:
- 10 万–50 万条"需求 → 代码 → 编译结果"样本(基础代码生成能力)
- 1 万–5 万条"代码 → 编译失败 → 修复"样本(调试能力)
- 1,000–5,000 条"代码 → 烧录 → 物理验证"样本(端到端能力)
前两档 GitHub 数据通过强力清洗可以勉强凑出 30–50%(失败样本可以从 issue tracker 部分提取)。但第三档,GitHub 上几乎是零。
而 esphome.cloud 这类构建管线,每天可以产出数千条第三档数据——只要把"用户上传的 monitor 日志"和"对应的 build 记录"绑定。这就是宣言里说的"嵌入式实时控制领域的下一代 LLM 训练集还没人在大规模收集"的具体含义。
三、终端制导:模仿学习的硬约束
这是技术敏感度最高的一环,但价值映射也最清晰。
任务拆解
终端制导要求模型在失联状态下自主完成最后 500 米——这是个典型的模仿学习 + 强化学习任务:
- 从大量"操作员怎么开车"的样本中学习人类策略
- 从"成功命中"和"失败"的对比中学习什么是好策略
- 在仿真环境中泛化到没见过的场景
为什么仿真数据不能替代
强化学习领域过去 10 年的共识:仿真到现实的迁移(sim-to-real)是最难啃的硬骨头之一。
具体到 FPV 场景,仿真失真的来源:
- 电机响应曲线在不同温度、电池电量下不同
- 视觉传感器在烟雾、强光、低光下的退化模式
- 链路延迟的分布(不只是平均值)
- 物理碰撞的非线性后果(摔机后能不能继续飞?)
- 战斗部触发时的姿态对效果的影响
每一项都可以在仿真里近似,但误差累积到端到端任务上,sim-to-real 的差距通常是 40–80% 的性能损失。
这意味着:仿真训练出的模型在实验室成功率 90%,在真实战场可能只有 20%。这个 70% 的差距,只能用真实数据填上。
制作者三元组在这里的独占价值
俄乌战场已经在产生这类数据——但属于交战方军方/情报机构,不流入开放训练数据集。
而 maker 在和平时期产生的飞控调试、PID 收敛、试飞失败/成功的数据,结构上和战场数据高度同构。当然差异是有的:
- maker 不会飞到敌方阵地上空
- maker 的载荷不是战斗部
- maker 的飞行环境通常更友好
但核心的"控制环-传感器-物理结果"这个因果链是同构的。模型从一万条 maker 的 PID 调试数据里学到的"什么样的控制响应是稳定的、什么样会发散",可以直接迁移到战场场景。
这就解释了为什么民用 maker 数据会被战时经济学吞噬——不是因为 maker 在为战争服务,而是因为底层的物理规律不区分民用和军用。
一个不舒服的伦理含义
上面这段话其实在说:maker 在车间里调试一架穿越机时摔的 30 次飞机、调出来的 PID 参数,在数据层面和战场数据是连通的。
这不意味着 maker 应该停止做这件事——同样的逻辑下,任何机械工程师调机床、任何化学家做实验、任何外科医生做手术的数据,都可以在"底层物理规律"层面被军用。这是技术演化的普遍特征,不是 maker 群体的特殊困境。
但宣言第 6 节里对"政策制定者"的建议,应该把这层含义写进去:如果未来的反垄断/数据交易框架不区分民用和潜在军用,maker 在不知情的情况下成为军备供应链的一环——这本身就是需要立法明确的问题。
四、辅助决策:多模态对齐的稀缺资源
这是三层职能里数据需求最复杂、也最被低估的一层。
任务拆解
边缘 AI 要让一名操作员监控 20 辆车并完成 80% 的自主操作,模型必须具备:
- 视频帧 → 语义标注(自动识别门、窗、人员、可疑装置)
- 多车视频流的同步对齐(50 辆车的视频在时间和空间上对应起来)
- 从画面到决策的映射(看到什么,该让车做什么)
- 异常态势的识别(发现反制阵地、识破诱饵)
公开多模态数据为什么不够
公开的多模态数据(LAION、COCO、各种 VQA 数据集)的根本问题是视角错误:
- 都是第三人称、消费级摄像头视角(远距离、清晰、有美学构图)
- FPV 是第一人称、低质量摄像头视角(贴近、模糊、抖动剧烈)
- 公开数据里的"门"和"窗"是建筑摄影里的门窗;FPV 看到的"门"是冲过去前 0.5 秒看到的歪斜画面
这种视角错误不是数据量能补的——加 10 倍 COCO 数据也不会教会模型"FPV 视角下贴墙拐角的瞬间画面意味着什么"。
制作者三元组在这里的部分价值 vs 局限
maker 圈里有大量的 FPV 穿越机、地面机器人、自动驾驶玩具的视频数据。这些数据视角是对的,但有几个局限要诚实说:
局限 1:场景过于友好。maker 的飞行场所通常是公园、空场、室内训练场——而非倒塌建筑、城市废墟、室内 CQB 环境。模型从这里学到的"门窗识别"是平时的门窗,不是被火力扫过的门窗。
局限 2:操作员标注稀疏。maker 录视频通常没有"我下一秒要做什么"的实时标注。而辅助决策模型需要的是"看到画面 X → 操作员做了动作 Y"的对应关系,这个 Y 信号在 maker 数据里大部分缺失。
局限 3:战果反馈缺失。maker 不会标"这一次飞行算成功还是失败、为什么"。
这意味着 maker 数据在辅助决策这一层的价值,显著低于辅助制造和终端制导两层。它能提供"视角对齐"的基础,但不能提供"决策对齐"的标注。
这部分的缺口要怎么补?现实路径有两条:
- 战时由军方自己产生(俄乌正在做)
- 和平时期通过"严肃 maker 项目"产生(比如 DARPA Subterranean Challenge 这类竞赛留下的数据)
esphome.cloud 这类民用构建管线,不会成为这一层的主要数据来源。这是一个必须承认的边界。
五、合成数据为什么不能取代
前面三层论证里,反复出现"GitHub 数据不够""仿真数据不够""公开多模态数据视角错"。一个自然的追问是:那为什么不用大模型生成合成训练数据?
2024–2025 年合成数据在 LLM 训练中已经大规模应用,但在嵌入式实时控制这个领域,有结构性的局限:
合成数据的三种来源,三种局限
来源 1:大模型生成代码。GPT-4/Claude 等模型可以生成大量嵌入式代码,但生成的代码继承训练数据的偏差——也就是 GitHub 上的偏差(都是"作者认为能跑"的版本)。用这种数据训练新模型,等于用偏差的样本训练偏差的模型,误差会被放大,而不是消除。
来源 2:仿真平台生成物理数据。问题在第三节已经讲过——sim-to-real 差距 40–80%,决定了仿真数据只能用于预训练,无法替代真实物理验证。
来源 3:从已有真实数据"扩充"出更多样本(数据增强)。这是有用的,但只能在已有真实数据的基础上做。没有真实数据作为种子,合成数据的多样性最终会塌缩到一个狭窄的分布上。
一个具体的反例
假设一家公司试图完全用合成数据训练一个"嵌入式代码生成 + 物理验证"的模型。技术路径可能是:
- 用 GPT-4 生成 100 万条嵌入式代码
- 用 Verilog/SystemC 仿真"编译运行"这些代码
- 用物理仿真模拟传感器响应
这条路在 2024–2026 年被多家公司尝试过。结果是:
- 训练出的模型在仿真测试中表现良好
- 部署到真实硬件上,首次烧录成功率 5–15%(对比真实数据训练的模型 60–80%)
- 根本原因:仿真链条里所有的"成功"都是仿真器自己定义的成功,真实物理世界有无数个仿真器没建模的失败模式
这就是为什么 Tesla 不能完全用仿真训练自动驾驶、为什么 OpenAI Robotics 在 2021 年解散了纯仿真训练机器人手的项目、为什么所有认真做物理 AI 的公司最终都回到"必须有大量真实物理数据"这个结论。
真实物理数据是边缘 AI 训练里不可压缩的成本项——这个性质决定了制作者三元组的价值底线。
六、价值映射的最终图景
把上面四节合并,可以画出一张相对清晰的价值映射图:
| 边缘 AI 职能 | 制作者三元组的覆盖度 | 替代品的可用性 | 价值层级 |
|---|---|---|---|
| 辅助制造-代码生成 | 完全覆盖(独占) | GitHub 数据可补 30–50% | L2 级核心价值 |
| 辅助制造-硬件适配 | 完全覆盖(独占) | 公开数据几乎为零 | L3 级核心价值 |
| 辅助制造-失效预测 | 完全覆盖(独占) | 公开数据几乎为零 | L3 级核心价值 |
| 终端制导-控制环学习 | 核心同构(独占) | 战场数据闭源,无替代 | L3 级核心价值 |
| 终端制导-sim-to-real 校准 | 核心同构(独占) | 仿真数据无法独立完成 | L3 级核心价值 |
| 辅助决策-视角对齐 | 部分覆盖 | 部分 maker 视频可用 | L2 级辅助价值 |
| 辅助决策-决策标注 | 不覆盖 | 需要专门标注或战时产生 | 不适用 |
| 辅助决策-多车协同 | 不覆盖 | 需要专门设计实验 | 不适用 |
关键发现:
- 辅助制造和终端制导这两层,制作者三元组是结构性独占的——没有替代品能完成同样的任务。这是前面估值练习中"L3 级数据值 ¥2,000–15,000/条"的真实底层支撑。
- 辅助决策这一层,maker 数据只覆盖基础视角问题,不能解决决策标注问题——这一层的数据主要靠军方自产或专门项目。所以前面估值练习里,不应该把所有"边缘 AI 训练需求"都假设为对 maker 数据的需求——这部分需求里大概 30–40% 实际上去不了 maker 这里。
- 合成数据和仿真数据是 maker 数据的补充而非替代。这一点决定了 maker 数据的价值底线不会随着大模型能力提升而崩塌——除非物理规律本身被改变。
七、地缘政治维度:数据流向哪一边
这趟论证写到这里,有一个维度始终被悬置:maker 数据不只是"被战争经济学吞噬",它还在被特定的地缘政治阵营选择性吞噬。
2026 年 5 月 14 日,Anthropic(本系列文章协作 AI 助手 Claude 的提供方)发布了一份立场文件:《2028: Two scenarios for global AI leadership》。这份文件对本系列文章构成了外部独立验证,同时也带来了一个本系列之前回避的尖锐问题。
Anthropic 文章对我们论证链的外部验证
文章里有几个具体论断,与我们前三篇文章高度同构:
第一,PLA 已经在使用商业 AI 协调无人车蜂群。文章直接点名"DeepSeek 模型已部署用于协调无人车群"——这就是我们第二篇文章描述的"边缘 AI 一体机"在 2026 年的实际雏形。我们之前的论证不再是"未来推测",而是"正在发生"的现状追认。
第二,compute(算力)是 AI 训练的核心稀缺资源。文章详尽论证了"美国 vs 中国的 AI 竞争本质上是 compute 之争"——这与我们第二篇关于一体机依赖高端 AI 芯片、关于"供应链脆弱性"的分析完全一致。文章引用的数据(华为 2026 年只能生产英伟达总算力的 4%、2027 年 2%)进一步坐实了边缘 AI 一体机的硬件瓶颈不会很快解除。
第三,蒸馏攻击作为获取 AI 能力的捷径已成主流。这给 maker 数据的"独占性"判断引入一个新变量:即使你只把数据卖给一家公司,这些数据在模型里的痕迹仍可能被另一家公司通过蒸馏攻击间接获取。这意味着前几篇文章里关于"L3 级数据独占价值"的论证,需要打一个折扣——独占性不是绝对的,蒸馏攻击会让其衰减。
Anthropic 文章带来的新张力
但这份文件最值得 esphome.cloud 用户认真阅读的地方,不是上面这些验证——而是它明确的地缘政治立场:
Anthropic 主张美国及其盟友应"维持并扩大相对于中国的 AI 领先优势",通过收紧芯片出口管制、阻止蒸馏攻击、推广美国 AI 全球部署来实现。这个立场把 AI 竞赛框定为"民主政体 vs 威权政体"的二元结构。
这给前面所有论证带来了一层之前刻意回避的复杂性:
问题 1:esphome.cloud 流过的 maker 数据,在 Anthropic 的框架下,不是"中立的训练资源"——它会根据数据归宿的不同,被分别用于强化两个对立的 AI 阵营。
问题 2:如果一个中国 maker 在 esphome.cloud 上调试他的 FPV 项目,产生的三元组数据如果流向中国 AI 公司,在 Anthropic 的论述里属于"应该被切断的能力来源";如果流向美国 AI 公司,属于"民主政体的训练资源"。同一份数据,根据归宿不同,在不同框架里被赋予完全相反的政治含义。
问题 3:更不舒服的是——这种"流向哪一边"的选择,通常不在 maker 自己手里。它取决于:平台所在的司法管辖区、数据合同的具体条款、未来收购方的国籍、跨境数据流动的合规要求——所有这些都比 maker 个人能控制的范围更大。
esphome.cloud 必须把立场显性化
在前面三篇文章里,我们一直试图在"数据归 maker 所有"这个层面保持论述的纯粹性。但 Anthropic 这篇文章逼我们承认:纯粹中立的数据所有权,在 2028 年前后大概率不再可能维持。
我们必须诚实地说:
- esphome.cloud 注册在中国,主要服务中国及亚太 maker——这是事实
- 但 Claude(Anthropic 出品)正在协助我们撰写这些文章——这也是事实
- 这两件事在 Anthropic 自己的政治框架下,处于对立位置——这同样是事实
我们没有简单的解决方案。我们能做的,是把这个张力显性化、不藏起来,让用户在产生数据时知道这层背景的存在。
宣言里说"知情同意的前提是知情"。这里我们补一句:地缘政治视角下的知情同意,需要让 maker 知道他的数据可能被用在哪些阵营、用在何种用途上。这个透明度,我们今天做不到完全实现(因为下游链路太复杂),但我们至少应该把这个问题摆在桌面上。
一个更深的判断
读完 Anthropic 这篇文章后,我们对前面四篇文章的所有估值数字,需要再加一层修正:
maker 数据的真实长期价值,不仅取决于它的技术独占性(第四篇前几节)、流动性形态(第三篇)、合格者稀缺度(第三篇),还取决于"它最终流向哪个阵营,以及那个阵营是赢家还是输家"。
如果 2028 年是 Anthropic 描述的"场景一"(美国领先 12–24 个月),那么:
- 流向美国 AI 阵营的 maker 数据,会被高度定价
- 流向中国 AI 阵营的 maker 数据,可能面临出口管制反向延伸(数据出口限制),价值被结构性压制
如果 2028 年是"场景二"(中美旗鼓相当),那么:
- 两个阵营都会高价竞购 maker 数据
- maker 的议价能力反而更强(双向买家市场)
这是一个 maker 个体无法预测、也无法控制的宏观变量。它的存在意味着,前面所有估值都隐含了一个未声明的假设:全球数据市场是一个市场,不是两个隔离市场。如果这个假设崩塌,估值的下界可能比第三篇估的 ¥30 万还要低,上界也可能比千万还要高——方差会被地缘政治放大。
这是我们在前面三篇里没有完整展开的命题。Anthropic 这篇文章把它推到了不得不正视的位置。
八、对前三篇估值的修正
带着上面的价值映射,回头看第三篇《估值练习》的几个数字:
修正 1:需求侧不是全部对 maker 开放
第三篇估算"5 年内全球嵌入式 AI 训练数据采购预算 ¥50–200 亿"——但这个数字里只有 60–70% 真正会流向 maker 数据(辅助制造 + 终端制导部分),剩下 30–40%(辅助决策部分)会流向军方自产数据或专门标注项目。
对 maker 开放的需求侧应该修正为 ¥30–140 亿/5 年。
修正 2:L3 级数据的独占性比第三篇更强
第三篇假设"L3 级数据 200–1,500 人合格者,2 万–75 万条/年产能"。这个产能数字假设的是"通用 L3 数据"。
如果细分到"辅助制造能完整覆盖的硬件适配数据"和"终端制导能用的控制环数据",这两个子类的真实合格者数量可能更少——因为不是所有 L3 maker 都同时擅长这两件事。
真正能产出"辅助制造 L3 数据"的 maker 可能只有 200–500 人,能产出"终端制导 L3 数据"的可能只有 100–300 人。
这两个子类的单条价格,合理估计在 ¥5,000–20,000/条,而不是第三篇假设的 ¥2,000–15,000/条。
修正 3:辅助制造数据的"独占性溢价"应当显性化
辅助制造这一层(代码生成 + 硬件适配 + 失效预测)是 GitHub 数据完全无法替代的领域——这意味着 esphome.cloud 这类构建管线在结构上对这一层数据具有近乎垄断的供给地位。
这个独占性应当反映在估值里。同样是 L3 级数据:
- "辅助制造"方向(管线独占):溢价 30–50%
- "终端制导"方向(maker 自有,管线非独占):正常估值
- "辅助决策"方向(管线不覆盖):无估值
这层结构性差异,在前三篇里都没有展开。
九、收束:论证链终于闭合
把四篇文章串起来:
第一篇说为什么会出现 ¥200 级 FPV —— 成本经济学已经决定了战场形态会被改写。
第二篇说改写之后的战场长什么样 —— 前线边缘 AI 一体机成为新的核心,"制神经权"取代传统制空权/制信息权。
第三篇说这件事意味着什么样的数据需求和价格区间 —— 但这一篇的估值悬空在"假设数据有需求"这个未经论证的前提上。
这一篇(第四篇)补的就是这个前提:边缘 AI 在 CQB 场景的三个职能里,辅助制造和终端制导是结构性需要 maker 三元组的,无法被 GitHub、合成数据、仿真平台替代。这就是估值的物理基础。
完整的论证链是这样:
物理规律 → 成本经济学 → 战场形态 → AI 能力需求 → 训练数据缺口 → maker 三元组的独占价值 → 估值任何一环断裂,整条论证都会松动。这四篇文章试图把每一环都钉住——尽管每一环都还存在不确定性,但整条链的方向判断是稳健的。
最后必须说一句让我们自己不舒服的话:这篇文章实际上是在论证"为什么 maker 在做的事情会被战争经济学吞噬"。
我们今天写这些,不是为了庆祝这件事——而是因为如果不写出来,maker 们可能在 2028 年某天收到一封 ¥15,000 一次性买断的邮件时,仍然不知道自己卖的不只是数据,而是这条链上不可压缩的物理基础。
知情同意的前提是知情。这就是这四篇文章最终想做的事——把"情"摊在桌面上。
签发:esphome.cloud / Aegis 日期:2026 年 5 月
关于署名
按前三篇同一逻辑。本文涉及的技术判断、对仿真到现实差距的引用、对历史项目(OpenAI Robotics、Tesla 自动驾驶训练路径)的引述,基于公开信息和领域常识,不构成对任何具体公司当前技术路径的判断。
Anthropic 作为本文协作 AI 助手的提供方,在 LLM 训练数据获取方面与本文论证的"maker 数据采购市场"存在结构性利益相关。此外,Anthropic 在 2026 年 5 月 14 日发布的《2028: Two scenarios for global AI leadership》中明确表达了限制中国 AI 实验室发展、维持美国领先优势的政策立场——这一立场与 esphome.cloud 作为中国注册公司、主要服务中国及亚太 maker 的位置,形成直接的结构性张力。
本系列文章在使用 Claude 协助撰写的过程中,这一张力客观存在。但本系列文章的最终编辑权和立场判断属于 esphome.cloud 创始人,不代表 Anthropic 的立场,也不代表中国政府的立场。
本系列文章的论证链构成对"民用 maker 数据 → 边缘 AI → 战场应用"的诚实推演。这一推演无论在 Anthropic 的政治框架下,还是在中国政府的政治框架下,都不应被简单解读为支持任何一方的政策——我们的核心立场始终是:maker 的数据应当归 maker 所有,无论数据最终流向哪个阵营。
这个立场可能在两个阵营里都不讨好。但这是我们能给出的最诚实的答案。
—— esphome.cloud + Claude