第12章 - 空间智能技术路线与展望

前十章解决「怎么用、怎么采、怎么算、怎么部署、怎么评测、怎么交付」，这一章只谈判断：同一套需求，为什么有的团队半年上线、有的团队一年半还在做演示？差别多半不是算法水平，而是把四条主线（感知、重建、智能体、部署）的成熟度时钟读错了。下面先摊开四条主线在 2026 年的真实状态，标清哪些能进生产、哪些要带护栏、哪些只能算试点；再给 2027–2028 年的八条趋势判断，每条附触发条件与反例；然后是可直接抄的选型矩阵、两档预算算例、风险清单和分角色的 90 天行动建议，最后把十二章收回成三条学习路线。

学习目标：能说清四条主线各自的技术边界与不可交付项；能对 2027–2028 年的趋势判断逐条给出证据与证伪信号；能按场景抄出技术栈并说出不推荐的理由；能按项目规模估出人力、工期与 GPU 预算；能把风险拆成技术、工程、组织三类并配上触发信号；能为自己的岗位排出未来 90 天的三件事。 前置知识：读完第 01–11 章中与你方向相关的至少五章；参与过至少一个真实项目（哪怕是试点）；能读懂 Python 与 TypeScript 片段；对 YOLO 系列、3DGS、MCP 中的两项有基本概念。

12.1 四条主线的 2026 现状

12.1.1 为什么用四条主线切分

空间智能的交付物不是一个模型，而是一条从像素到决策的链路。链路上四段的技术时钟完全不同：感知几年一换代，重建正在从研究品变成商品，智能体的接口标准今年才定形，部署则被硬件节奏推着走。用四条线切分不是为了分类好看，而是为了让滞后可定位——项目延期时，你能指认出到底是「模型换代导致重训」「重建精度不达标」还是「工具契约写不清导致 agent 调错参数」。

    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
    │ 感知         │    │ 重建        │    │ 智能体       │    │ 部署         │
    │ 像素 → 目标   │───▶│ 影像 → 三维  │───▶│ 意图 → 动作  │───▶│ 模型 → 现场  │
    └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
        换代 2–3 年          商品化 1–2 年      标准刚定形         随硬件走

判断一条主线在你们团队里是否成熟，问三个问题就够：

这三问的答案决定预算往哪投。一条经验数据：四条线里只要有一条停在试点级，整条链路都进不了生产——感知漏检会导致重建漏拍，重建缺尺度会让智能体的空间查询算出错误结果，部署没做好运维则把前面所有努力变成每周一次的现场救火。所以本章的现状描述一律带「成熟度」和「可交付边界」两列，而不是只写「支持什么能力」。

12.1.2 感知：端到端检测与概念分割同时到位

2026 年的感知侧发生了两件互不相关、但会同时影响选型的事：检测器把后处理做进了模型（YOLO26 的 NMS-free 端到端推理），分割器把「类」从固定列表换成了自然语言概念（SAM 3 / SAM 3.1 的 Promptable Concept Segmentation，下称 PCS）。前者改的是延迟与部署形态，后者改的是需求变更的成本——客户加一类目标的报价方式完全变了。

  旧链路：模型 → NMS → 阈值筛选 → 业务规则      （三段可分别调参，也可分别甩锅）
  新链路：模型 → 结果                            （端到端，调参集中到一处，可解释性下降）

选型规则可以写死成三条：

• 类别固定、延迟死线在 20 ms 以内：用 YOLO26n/s 闭集，配 TensorRT 11.x 的 FP16 引擎，不要引入任何在线大模型。
• 类别随客户改、但又要求实时：两段式——YOLO26 闭集跑主干类别，SAM 3.1 只在触发帧上做兜底分割。用触发帧把大模型调用量压到 1%–5%，成本才可控。
• 离线抽帧做标注或质检：SAM 3.1 加文本提示打伪标签，人工只做复核。这一步能把标注成本压掉一半以上，前提是复核比例不低于 10%。

延迟这件事必须自己量，不能引用论文表格。同一份权重换一次 TensorRT 版本、换一档 batch，数值就能差出 30%：

# 1) 导出 TensorRT 引擎：NMS-free 模型不要手工再加 NMS 插件
yolo export model=yolo26s.pt format=engine half=True imgsz=640 batch=1

# 2) 用 trtexec 量 p50 / p95，不要用 Python 里的 time.time() 循环
trtexec --loadEngine=yolo26s.engine --shapes=images:1x3x640x640 \
        --warmUp=500 --duration=10 --avgRuns=200 --percentile=95

# 3) CPU 侧退路用同一份 ONNX 对照，边缘盒子降级时才有的选
trtexec --onnx=yolo26s.onnx --shapes=images:1x3x640x640 --avgRuns=50

命令里的参数名以当前版本的 yolo export --help 与 trtexec --help 为准，TensorRT 11.x 相比 10.x 在动态 shape 与插件注册上有迁移项，照抄旧脚本大概率报错。

12.1.3 重建：3DGS 进可交付，前馈进采集闸门

2026 年的三维重建有两条腿：一条是显式表示 3DGS 的工程化成熟——训练、编辑、发布都有现成工具；另一条是前馈式几何（VGGT 系）把「看到结果」的时间压到分钟级。两条腿踩的地方不一样：3DGS 负责好看和可编辑，前馈负责快和判断采集质量。把两者混为一谈，就会出现「用 VGGT 的位姿直接出量测成果」这种交付事故。

VGGT（Visual Geometry Grounded Transformer）的价值要说准：它前馈一次就输出相机参数、深度图和点图，2026-05-15 修过显存问题后同等显存能跑约 2–3 倍帧数，2026-05-18 又发布了后继 VGGT-Omega；商用 checkpoint（VGGT-1B-Commercial）从 2025-07-29 起需要申请许可。这三条合起来指向一个判断：VGGT 在 2026 年的正确位置是采集质量闸门，不是最终成果。前馈位姿的绝对精度还不足以通过控制点检核，但足够回答「这段视频糊没糊、有没有断、重叠够不够」。

# 采集质量闸门：几分钟内判断这段素材能不能进正式重建
vggt --images frames/ --output vggt_out/          # 输出相机、深度、点图

python tools/check_poses.py vggt_out/ \
       --min-overlap 0.6 --max-jitter 0.02        # 自己写的小脚本，阈值按机型标定

# 通过后才进正式链路：COLMAP 出位姿，brush 训 splat
colmap feature_extractor --database_path db.db --image_path frames/ \
       --ImageReader.single_camera 1 --SiftExtraction.use_gpu 1
colmap exhaustive_matcher --database_path db.db --SiftMatching.use_gpu 1
colmap mapper --database_path db.db --image_path frames/ --output_path sparse/
brush frames/ --output splat/ --total-steps 30000

这条链路里最容易被跳过、但代价最大的一步是 check_poses.py 那道闸门。跳过它的后果是：你在 GPU 上跑完两小时训练，导出的场景才发现有两段轨道没接上，重拍的成本远高于那几分钟的检查。

splat 的「可交付」在 2026 年还有一个新前提：Cesium 在 2026-04 发布了 3D Tiles 加层次 LOD 的 3D Gaussian Splats 方案，CesiumJS 1.147（2026-11）能加载带 LOD 的 splat tileset。这让 splat 从「单文件浏览」变成「可瓦片化加载」，是它进入城市级底座的门槛性变化。但工具链还没统一：ply 到 tileset 的切分、坐标系对齐、属性挂接都要自己验证，别指望一条开源命令全包。

给重建定一条硬线，交付形态就清楚了：能不能量测，决定交付物是「视觉参考」还是「测绘成果」。不能量测的，交付时写清「视觉参考，量测需另配控制点网络」；能量测的，必须附控制点残差报告（中误差指标按项目约定，常见是 3–5 cm），并把控制点坐标文件写进验收单——否则三个月后没人能复现你的精度结论。

12.1.4 智能体：MCP 定形之后，瓶颈是工具描述

2026 年智能体侧最重要的变化不是模型变强，而是接口定形：MCP（Model Context Protocol）按 2026-07-28 规范收敛为 stateless 核心加 Streamable HTTP 传输，用协议版本头协商能力，能力面是 tools / resources / prompts，另有一条 MCP Apps 方向；旧的 HTTP+SSE 传输属于过渡形态。协议层解决的是「怎么发现能力、怎么传参、怎么回错误」，不解决「这个工具到底该长什么样」。

GIS 场景里，agent 调错工具的原因九成不是模型笨，而是工具描述不合格。四条合格线：

# 探一个 MCP 服务的工具面：initialize 之后先 tools/list，再决定接哪几个工具
curl -s http://127.0.0.1:8000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"capabilities":{},"clientInfo":{"name":"kjzn-probe","version":"0.1.0"}}}'

curl -s http://127.0.0.1:8000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

这段 curl 是排查时的第一道工具：能把 initialize 与 tools/list 跑通，说明传输与版本协商没问题，剩下的就是工具设计问题。注意 Accept 头要同时带 application/json 和 text/event-stream，只带其一会返回 406；协议版本头缺失或与服务器不一致时，服务方应回明确的错误而不是静默降级——这条也是验收项。

12.1.5 部署：端上算力上台阶，瓶颈移到运维

2026 年的边缘侧有一个反直觉现象：算力涨得比模型涨得快。NVIDIA Jetson Thor 配 JetPack 7.x（7.2.x）成为高端档，取代 Orin 家族；Orin Nano / NX / AGX 仍在售、且是存量项目的主力。TensorRT 11.x 在 Jetson 侧有明确的 10.x → 11.x 迁移指南，ONNX → engine、FP16 / INT8、动态 shape 仍是标准流程；服务侧的 vLLM 支持多模态模型与 OpenAI 兼容接口，量化（AWQ / GPTQ / INT4）加批处理已是常态。结论是：「模型跑不跑得动」不再是主要矛盾，「模型换了现场能不能自愈」才是。

DJI 上云 API 2（2026，免费 License、不限设备台数）之所以值得单列，不是因为它的协议更先进，而是它把运维面做成了可编程接口：设备模拟器、远程调试与操控、日志、媒体管理、模型重建、4G 私有化增强图传都在 PaaS 里，还给了 AI Plugin 与 AI Coding 脚手架。相比之下，v1.x（含 v1.10.0）仍是大量存量项目的协议基线——MQTT 加 HTTPS 混合，主题形如 thing/product/{gateway_sn}/osd|state|events|services/…。新项目优先上云 API 2，存量项目按 v1.x 维护，这个判断在 2027 年之前不会变。

# 边缘侧的最小自愈：健康检查失败就回滚到上一版引擎
set -euo pipefail
MODEL_DIR=/opt/models
CUR=$(cat "$MODEL_DIR/current")
if ! docker exec infer python /app/healthcheck.py; then
  PREV=$(cat "$MODEL_DIR/previous")
  echo "rollback: $CUR -> $PREV"
  cp "$MODEL_DIR/$PREV.engine" "$MODEL_DIR/active.engine"
  systemctl restart infer
fi

这段脚本只有十几行，却比换一块更贵的板子更能提升可用性。边缘项目最常见的故障不是模型精度掉了，而是某次远程升级后服务没起来、而现场没人会回滚——等到第二天运维爬塔，损失已经发生。

12.1.6 四条主线的技术 → 成熟度 → 可交付边界

把四节内容压成一张表。成熟度分四级：L4 生产默认（换版本不必重写下游）、L3 生产可用需护栏（要监控、要回滚预案）、L2 试点（有成功案例但失败率高）、L1 观察（论文与 demo 阶段）。

这张表里最有用的是最后一列。投标时把「不可交付」改写成「交付前置条件」——比如「量测成果需甲方提供不少于 6 个控制点，残差中误差按 5 cm 验收」——后面能省掉八成扯皮。反过来，如果方案里只写第一列的技术名，评标时看不出差别，交付时却要按最后一列的边界买单。

12.1.7 这一节的四个坑

1. 拿榜单指标当现场指标：YOLO26 的 COCO mAP 40.9–57.5 是在通用数据集上测的；巡检小目标要先切图，切图后的 mAP 与现场查全率是两套数，验收必须用现场抽检集。
2. 用旧版导出经验套 NMS-free 模型：阈值语义、batch 行为、INT8 校准集全变了，照抄 YOLOv8 时代的脚本，精度掉 5 个点都算轻的。
3. 把 3DGS 当量测成果：无尺度、无绝对精度，必须配控制点与残差报告；只交付 ply 文件的项目，验收阶段一定要出事。
4. 以为接了 MCP 就「打通了」：协议只解决传输与能力发现，工具描述、失败重试、写操作确认仍要自己设计，这部分工作量通常占整个智能体项目的一半。

12.2 趋势判断（2027–2028）

趋势判断有个标准写法：结论 + 证据 + 触发条件 + 反例。缺了后两条就退化成口号，而口号在立项会上最容易通过、在验收时最容易翻车。下面八条判断我都给出会在什么信号出现时承认判错，这样读者可以拿未来 18 个月的事实来对我们的判断记账。

这里不做时间点承诺。凡是写「2027 年一定如何」的，多数是在卖东西；本节只写方向、触发条件与可观测的先行指标。

12.2.1 判断一：端到端推理成为默认，后处理退到配置层

结论：到 2028 年，主流视觉推理链的默认形态是「模型直接出结果」，NMS、阈值筛选、规则后处理不再是代码的一部分，而是配置文件里的一组参数。

证据：YOLO26 把 NMS 从推理链里去掉，同时用统一头覆盖检测、实例分割、语义分割、姿态、OBB 五种任务；TensorRT 11.x 在动态 shape 与插件注册上的改进，让「一份 ONNX 导出多档引擎」比过去省事。这两件事叠起来，后处理从「必须写的代码」变成了「可以关掉的开关」。

触发条件：主流检测框架的下一版继续以「NMS-free + 多任务头」为默认；量化工具把边缘侧 INT8 的精度损失吸收进校准流程，不再需要手工补偿后处理。

反例：如果垂直场景的验收指标仍依赖可解释的后处理（例如电力金具巡检要求能按框级 NMS 参数回溯每一次误检，作为质量追溯的一部分），后处理会留在合规链路里，端到端只做预筛。判断在这种情况下只对一半。

含义：现在就该把阈值与后处理参数从代码搬进配置文件，并按数据集版本做版本管理。等趋势兑现时，这项改造成本已经变成历史包袱。

12.2.2 判断二：概念分割吃掉一部分闭集检测的活，但不是全部

结论：2028 年之前，「加一类目标」的标准做法会从「采数据 + 重训 + 重新验收」变成「改一句提示 + 抽样复核」，但闭集检测不会被取代，只是退回它擅长的位置。

证据：SAM 3 / SAM 3.1 的 PCS 用文本概念或图像 exemplar 一次提示，就分割并跟踪该类全部实例；3.1 的 Object Multiplex 把多目标视频处理压到单台 H100、128 目标相对 2025-11 版约 7× 加速。成本结构一变，需求变更的报价模型就得跟着变。

触发条件：客户对新增类别的容忍周期从「按季度」压到「按周」，或者类别长尾超过 30 类、其中一半是低频类。

反例：要求 20 ms 内出结果、或者类别定义本身就是有国标编号的闭集（按标准图式分类的地物）时，闭集检测仍是主路径；几十像素的极小子目标也是，PCS 的召回还不稳，切图加闭集更靠谱。这两类场景在低空巡检与基础测绘里占比不低。

含义：报价模型要改。以前「加一类」报重训成本，之后报「提示工程 + 抽样复核」成本，后者毛利更高但更难写进验收单——因为甲方看不见交付物的变化。

12.2.3 判断三：splat 成为三维底座的一等公民

结论：3DGS 系表示会从「炫技成果」变成三维底座的默认背景层，与矢量层、实体模型层并列，并具备瓦片化加载能力。

证据：Cesium 在 2026-04 发布了 3D Tiles 加层次 LOD 的 3D Gaussian Splats 方案，CesiumJS 1.147（2026-11）可加载带 LOD 的 splat tileset；3D Tiles 1.1 的 metadata 与隐式瓦片提供了挂接属性与按需加载的机制；brush（Rust + WebGPU / Burn，跨平台单二进制）与 SuperSplat（浏览器内免费开源编辑器）把训练与编辑的门槛压到「会用浏览器」。

触发条件：splat 瓦片的生产工具链出现事实标准——谁做切分、属性怎么挂、坐标怎么对齐都有约定，且至少两家主流三维平台能直接消费而不需要自己写转换器。

反例：验收要求「可量测的实体模型」（BIM 级别的属性与拓扑）时，splat 只能当背景，主体仍是 Mesh；强反射、透明、大面积镜面的场景，splat 的视觉优势在量测需求面前没有意义。这两类反例在建筑与工业场景里很常见。

含义：现在设计三维底座，就按「splat 层 + 矢量层 + 模型层」三层来留结构，别把 splat 当成唯一的三维表达。这条在 12.3 的选型矩阵里会展开成具体的技术栈。

12.2.4 判断四：MCP 成为工具接口事实标准，GIS 服务被「工具化」重写

结论：到 2028 年，GIS 平台对外暴露能力的主要形态会是「一组 MCP 工具」，而不是「一套 REST 文档 + 一份 SDK」。REST 不会消失，但会被压到工具层下面，用户（包括 agent）看到的是工具契约。

证据：MCP 2026-07-28 规范把核心收敛为 stateless 加 Streamable HTTP 传输，用协议版本头协商，能力面固定为 tools / resources / prompts，同时给出 MCP Apps 方向；旧版 HTTP+SSE 被明确为过渡形态。规范一旦稳定，服务端实现成本就从「研究怎么接」变成「照规范写」。GIS 侧的需求端也已经成熟：一张图类项目的自然语言入口，本质就是把空间查询、统计、出图包装成工具。

触发条件：至少两家主流 GIS 或云厂商提供官方 MCP server，且工具描述出现约定俗成的字段（bbox、CRS、时间窗、分页游标），甲方开始把「是否支持 MCP」写进需求清单。

反例：强事务类操作——多要素编辑、拓扑校验、版本化提交——在 agent 里做不稳，仍要留在传统客户端或人工审核工作台上。内网环境里，stdio 方式启动的本地 server 往往比远程 HTTP 更现实，这会削弱「MCP 即服务」的形态，但不影响协议本身。

含义：平台团队今年该做的不是重写服务，而是把现有 REST 接口改造成合格工具：补全参数、补全错误码、把写操作拆出去并加确认参数。工作量集中在「契约设计」，不在「协议接入」。

12.2.5 判断五：评测与合规成为采购硬门槛

结论：2027 年起，空间智能项目的招标文件里会普遍出现两条硬要求：模型版本可冻结、评测集随合同交付。没有可复现评测的供应商，会先被技术标刷掉，再谈价格。

证据：实景三维中国已进入「十五五」提质增效阶段，国省市县协同建设，全国 DEM 在东部与西部重点区域优于 2 m 格网、其余优于 5 m 格网，重要地理实体年度增量更新——这套质量口径一旦落到项目验收，就会顺着传导到 AI 环节。低空侧也一样：国家电网 2026 年首批无人机巡检框架采购 18.3 亿元（大疆行业应用中标的公开披露口径），这种体量的框架采购必然配套统一的数据与评测规范。

触发条件：出现「验收时按同一评测集重跑、结果须与交付报告一致」的条款，或者甲方要求提供推理链路的版本快照（权重、引擎、预处理参数三者哈希）。

反例：预算低于五十万的小项目仍会沿用「功能演示 + 人工抽检」的老办法，因为构建评测集的成本高于项目毛利。这类项目不会消失，但会越来越集中在标准化程度高的轻量场景。

含义：把评测集当交付物管理——版本号、标注规范、判据、复现脚本四件套齐备。第 10 章的评测方法、第 11 章的验收流程在这里合并成一条产品线能力，而不是两次性的项目动作。

12.2.6 判断六：边缘从「够用」转向「多模态常驻」

结论：边缘设备的负载会从「跑一个检测模型」变成「常驻一个多模态小模型 + 若干专用模型」，端云分工从「端上推理、云上训练」变成「端上预筛、云上复核」。

证据：Jetson Thor 配 JetPack 7.x（7.2.x）把高端档算力抬了一档，Orin 家族仍在存量项目里服役；TensorRT 11.x 有明确的 10.x → 11.x 迁移路径；服务侧 vLLM 支持多模态模型与 OpenAI 兼容接口，量化方案（AWQ / GPTQ / INT4）成熟。硬件与推理栈两边同时到位，多模态才有资格「常驻」。

触发条件：现场需求从「框出缺陷」升级为「用一句话解释这是什么缺陷、按规程该定几级」，且网络条件不允许把视频流稳定回传。

反例：功耗与载荷受限的机载场景（几百克载荷、电池供电）仍然只能跑闭集小模型，散热与供电决定上限，多模态要等下一代平台。判断在这种场景下会晚 1–2 年兑现。

含义：端云接口要按「预筛结果 + 关键帧 + 置信度」设计，而不是按「原始视频流」设计。按 token 计费思维估成本——把「每帧都问一次大模型」改成「只问触发帧」，成本差两个数量级。

12.2.7 判断七：微调从「训模型」转向「训适配层」

结论：2028 年之前，多数项目里的「微调」会变成「冻结主干 + 训适配层」（LoRA、prompt、decoder），全参微调收缩到两类场景：领域先验差异极大，或基座不再更新。

证据：SAM 3 的官方微调路线本身就是「冻结视觉编码器 + 训 prompt / decoder」或 LoRA；Qwen3-VL 的 2B / 4B 小模型可单卡部署，社区框架（ms-swift、LLaMA-Factory）把这条路径做成了流水线；VGGT 的商用 checkpoint（VGGT-1B-Commercial，2025-07-29 起）需要申请，许可约束反过来推动团队只训适配层、不动主干。

触发条件：基座模型的迭代周期短于项目交付周期（半年一换），并且换基座后适配层能在两周内重训完成。

反例：专业符号识别、遥感波段组合、特殊几何先验这类任务，冻结主干的表达能力不够，全参微调反而更省事——少一层抽象就少一处 bug。判断在这类任务上会偏保守。

含义：项目预算里要单列一条「基座升级重适配」，按初版微调成本的 20%–30% 预留。没留这条预算的团队，会在第二年发现自己的模型锁死在一个过期基座上。

12.2.8 判断八：数据资产比模型更稀缺

结论：未来两年，决定项目天花板的不是「有没有用上最新的模型」，而是「有没有可持续的采集与标注资产」。模型会商品化，数据集不会。

证据：实景三维中国的年度增量更新说明基础测绘数据在变成持续供给，而不是一次性成果；3DGS 的成品质量几乎完全由采集质量决定（第 06 章的采集规则比训练参数更影响结果）；SAM 3.1 打伪标签能降标注成本，但复核环节仍然需要懂业务的人。

触发条件：同一个模型换到新区域后掉点超过 15%（域偏移），而补一批本地数据的效果好于再训一版模型。

反例：通用能力已经外溢到目标场景、零样本可用时，数据资产的价值下降——这在文本类任务上已经发生，空间任务上还没发生，因为空间任务对几何与坐标的精确性要求更高。

含义：把标注规范、采集规范、控制点库当资产经营：有版本、有负责人、有复用记录。这三样东西比权重更保值，也是团队换人时唯一能留下来的东西。

12.2.9 八条判断的先行指标与证伪信号

判断要能被记账，就得提前写下「看到什么就承认错了」。下表可直接抄进项目周报的技术雷达页：

记账方式建议落到一个文件里，别放在脑子里：

# judgment-ledger.yaml —— 每季度复核一次，改判断要写明理由
- id: T1
  claim: 端到端推理成为默认
  signal: 主流框架新版本默认关闭 NMS 后处理
  falsifier: 头部项目为合规保留 NMS 并写入验收条款
  check_by: 2027-06
- id: T4
  claim: MCP 成为 GIS 工具接口事实标准
  signal: 两家以上主流 GIS 平台发布官方 MCP server
  falsifier: 各平台私有工具协议互不兼容
  check_by: 2027-12

12.2.10 这一节的四个坑

1. 把趋势当排期：趋势只说明方向，不说明你所在项目的交付窗口。用趋势去说服甲方接受一个还没成熟的方案，是把判断力变成风险。
2. 只写结论不写反例：没有证伪信号的判断无法复盘，团队会陷入「我说过会这样」的事后解释。每条判断都要预先写下「看到什么我认错」。
3. 用单一指标代表趋势：只看某篇论文的指标就断言「闭集检测要死了」，忽略了工程约束（延迟、功耗、可解释性）。趋势判断至少要两个独立信号同向。
4. 忽略存量：判断新项目该用什么，不等于存量项目要立刻迁移。存量迁移的成本常常高于收益，尤其是边缘设备的现场运维成本。

12.3 选型矩阵

选型这件事的失败方式高度雷同：先选了一个「先进」的技术，再倒推需求去适配它。正确的顺序反过来——先写清交付物与验收方式，再倒推技术栈，最后用「不推荐清单」砍掉看着诱人但不合场景的选项。

12.3.1 选型原则：四条否决线

在进入具体场景之前，先过四条否决线。任何一条不通过，后面的技术比较都没有意义：

四条线里最容易被跳过的是「运维可行」。算法团队评估时默认「有问题远程连上去看」，而现场的真实约束是「塔上设备两个月才有人上去一次」。

12.3.2 五类场景的总表

12.3.3 低空巡检：先保实时，再谈智能

巡检项目的硬约束是「同一段航线要重复飞几百次」，所以技术栈的第一目标是稳定与可复现，不是精度上限。

推荐组合：机上或机场侧跑 YOLO26 闭集（类别固定、指标明确），对疑似目标做二次抓拍并回传关键帧；云端用 SAM 3.1 对关键帧做概念分割复核，把「疑似」升级为「确认」。编排走上云 API 2（新项目）或 v1.x（存量），直播与远程调试用它自带的通道，别自己造。

不推荐在机载端跑多模态大模型，理由不是「跑不动」，而是「不可控」：一次推理 300 ms 会让航线速度必须降下来，而巡检的架次成本主要由飞行时间决定。要上多模态，放在机场侧或地面站。

   航线规划 ─▶ 机上闭集检测（≤20 ms） ─▶ 触发抓拍 ─▶ 回传关键帧
                                                     │
   报告生成 ◀─ 缺陷定级（规则表） ◀─ 云端复核（SAM 3.1）◀┘

12.3.4 一张图智能体：先把只读做到稳，再开放写操作

一张图类项目的用户不是算法工程师，是坐窗口的业务人员。这决定了选型的第一原则：宁可少一个功能，不可多一次胡说。所有查询必须能落回「哪个图层、什么范围、什么时间」这三个要素，回答里带不出来，就不算可用。

不推荐的一条：让模型直接生成 SQL 打库。理由有三层——越权（模型不知道行级权限）、慢查询（一次全表扫描就能拖垮共享库）、不可解释（出了错无法定位是模型还是数据）。正确的做法是模型只选工具与填参数，SQL 由工具内部用参数化查询拼装，参数范围在工具层校验。

工具描述写成这样才算合格：

{
  "name": "query_features_in_bbox",
  "description": "按经纬度范围查询指定图层的要素。只读。返回要素数与分页游标，不返回完整几何。",
  "inputSchema": {
    "type": "object",
    "required": ["layer", "bbox", "crs"],
    "properties": {
      "layer": { "type": "string", "description": "图层编码，取值见图层清单" },
      "bbox":  { "type": "array", "items": { "type": "number" }, "minItems": 4, "maxItems": 4,
                 "description": "minX,minY,maxX,maxY，顺序不可颠倒" },
      "crs":   { "type": "string", "enum": ["EPSG:4326", "EPSG:4490"], "description": "bbox 的坐标系" },
      "timeWindow": { "type": "string", "description": "可选，ISO 8601 区间；不传表示不过滤时间" },
      "cursor": { "type": "string", "description": "分页游标，首次调用不传" }
    }
  }
}

三个细节值得单说。第一，required 里包含 crs——不写坐标系，模型就会默认 WGS84，而政务数据常用 CGCS2000（EPSG:4490），差出几百米。第二，bbox 顺序写死在描述里，不要指望模型记住「经度在前」这类隐含约定。第三，返回分页游标，别一次吐一万个要素——那会撑爆上下文，也会让响应时间不可控。

响应时间预算提前定好，否则验收时没法谈：意图路由 ≤ 300 ms，工具执行 ≤ 3 s，模型生成 ≤ 5 s，端到端目标 8 s 内首屏可用。超过这条线的功能，先砍功能再谈优化。

12.3.5 三维重建：先回答「要不要量测」

三维重建的选型只有一个分叉口：交付物要不要量测。要，就走控制点 + Mesh / 点云的测绘路线；不要，就走 splat 的视觉路线。两条路线的工具、精度口径、验收方式完全不同，混着做必然返工。

                      ┌── 要量测 ──▶ 控制点 + 7 参数对齐 ──▶ Mesh / 点云 + 残差报告
    交付物是什么？ ────┤
                      └── 不量测 ──▶ splat（算视觉底座） ──▶ 3D Tiles + LOD 瓦片

城市级最容易犯的错是「一次训练出全城」。显存与训练时间都会爆，而且单点误差会污染整块。正确做法是分块：按 500 m × 500 m 或按航线架次切，块内独立重建，再用控制点把每块拉到统一坐标系，最后按 3D Tiles 的瓦片结构组织。目录约定如下，越早定越好：

tileset/
├── tileset.json                 # 根瓦片，含 boundingVolume 与 geometricError
├── block_000_000/
│   ├── tileset.json             # 块级 LOD 链
│   ├── L0.ply                   # 低精度（远景）
│   └── L2.ply                   # 高精度（近景）
└── block_000_001/
    └── ...

一个必须写进合同的参数是 geometricError：它决定每级 LOD 在什么距离切换。设得太小，浏览器会疯狂请求高精度瓦片；设得太大，近景会糊成一片。经验起点是块尺度的 1/20，再按实测的加载耗时调。

12.3.6 自动驾驶仿真：仿真不是奢侈品，是长尾的唯一来源

自动驾驶与低速无人车的项目里，真实数据永远覆盖不到长尾：突然横穿的行人、逆光下的施工围挡、被雪盖住的车道线。仿真的价值就在这里——不是替代实车，而是定向生成实车采不到的样本。

一条判断：仿真里程与实车里程的比例，按 10:1 到 50:1 配置比较健康。低于 10:1，长尾覆盖不足；高于 50:1，团队会陷入「仿真刷分、实车翻车」的循环。这个比例不是行业标准，是从第 05 章那套导航线任务里试出来的经验值，换任务要重标。

12.3.7 多模态微调：小模型 + 适配层是默认答案

微调项目的选型可以按三步走：先问「基座能不能直接提示出来」，能就别微调；再问「能不能只训适配层」，能就别全参；最后才问「要不要换基座或从零训」。

对 GIS 场景，推荐 Qwen3-VL 的 2B / 4B 这一档：单卡可部署、显存友好、社区框架（ms-swift、LLaMA-Factory）支持完善。分割侧的微调走 SAM 3 的官方路线——冻结视觉编码器，只训 prompt / decoder，或用 LoRA。训练配置留个可复现的骨架：

# lora-sft.yaml —— 数值是起点，不是最优；按验证集曲线调
model: Qwen3-VL-4B
method: lora
lora_rank: 16
lora_alpha: 32
target_modules: [q_proj, k_proj, v_proj, o_proj]
learning_rate: 1.0e-4
num_epochs: 3
batch_size: 4
grad_accum: 4
max_length: 2048
dataloader: 领域样本 8k 条，按 8:1:1 切分训练/验证/留出

两个经验数字：2k 条高质量样本的效果通常好于 20k 条噪声样本；留出集必须包含至少 15% 的「现场难例」，否则微调后的模型在真实场景里会掉点。这两个数字来自第 07 章的实验记录，换任务要重新标定，别当常数用。

12.3.8 场景选型的抄作业清单

把五类场景压成一张可以贴在工位上的检查表。评审方案时按行打勾，任何一行打不了勾就退回改：

[ ] 交付物是什么？视觉参考 / 可量测成果 / 决策建议 / 自动化动作
[ ] 验收指标是什么？口径、数据集、阈值、抽检比例四项是否写死
[ ] 基座与权重许可允许商用吗？下游要开源吗？
[ ] 数据从哪来、能不能持续更新、标注规范谁维护
[ ] 现场有人能回滚吗？升级失败的平均恢复时间是多少
[ ] 端到端延迟预算是多少？哪一段超了就砍功能
[ ] 写操作有确认与审计吗？出事后能不能复现
[ ] 评测集是不是交付物的一部分？复现脚本在哪

12.3.9 一次选型评审会怎么开

选型的结果通常不是一个人定的，但评审会常常开成技术分享会：讲了四十分钟的模型对比，最后没人说清「选哪个、为什么、什么时候会反悔」。下面这套议程是压缩版，40 分钟出决议。

三条会议纪律，比议程本身更重要：

1. 不在评审会上比精度。精度是评测集的事，评审会比的是「约束是否满足」。要比精度，提前一周把评测报告发出来。
2. 不接受「再看看」当决议。要么定方案加复核日期，要么明确否决并写下否决理由。
3. 记录反对意见与条件。「在有进口替代要求时改用国产模型」这类条件，比一句「大家同意」有用得多。

一页纸的模板可以直接抄：

【交付物】____________________________________________
【验收】指标 / 数据集 / 阈值 / 抽检比例 = ____________
【技术栈】候选 A = ______  候选 B = ______
【不推荐】______，理由（延迟/许可/运维/精度）：______
【否决线】许可 __ 数据 __ 运维 __ 验收 __（打勾或不通过）
【预算】人力 __ 人周 / GPU __ 卡时 / 外采 __ 元，合计 ____
【三大风险】1.____ 兜底 ____  2.____ 兜底 ____  3.____ 兜底 ____
【决议】做 / 不做 / 换方案    复核日期：________

填不满这一页，说明还没到能决策的阶段。此时最该做的不是继续调研，而是回去把交付物与验收口径问清楚——这两行空着，后面的所有比较都没有基准。

12.3.10 这一节的四个坑

1. 按「最先进」选型：选型的因变量是交付物与验收方式，不是论文新鲜度。用没定形的技术写进合同，等于把研发风险转成违约风险。
2. 忽略许可：VGGT 的商用 checkpoint 需要申请，部分 3DGS 相关权重与数据集许可仅限研究。签约前把权重、代码、数据集三份许可都过一遍。
3. 只评估精度不评估恢复时间：现场一次升级失败，停摆一天的损失往往超过全年 GPU 预算。把「回滚到上一版」做成一条命令，比多两个点的 mAP 更值钱。
4. 把城市级当单场景放大：分块、统一坐标、LOD 三件事不做，规模一上来质量与加载速度同时崩，且后期返工成本极高。

12.4 团队与成本

选型之后就是算账。这一节的数字都是估算口径：人力按 2026 年国内的混合成本、GPU 按公开按需报价的常见区间。真实报价随区域、行业、甲方流程浮动，写方案时用自己公司的单价替换，别直接抄数字——但估算方法可以抄。

12.4.1 角色配置：五个角色，两个不能省

空间智能项目的最小可行团队是五个角色。少了「三维」和「交付」，项目不会立刻崩，但会在验收阶段集中爆发。

五个角色里，「三维」之所以容易被省掉，是因为它的产出看起来像「数据」而不是「功能」——直到验收时甲方要求残差报告。能对坐标负责的人，必须在项目里有明确的名字，这不是岗位设置问题，是责任归属问题。

12.4.2 工期与预算的估算方法

别用「拍脑袋 + 20% buffer」估工期。空间智能项目的成本可以拆成三条互不干扰的式子：

人力（人周） = Σ 阶段功能点 × 复杂度系数 ÷ 单人周产出
              复杂度系数：成熟场景 1.0，新场景 1.8，跨域迁移 2.5
GPU（卡时）   = 实验轮数 × 单轮卡时 × 1.6（预留返工）
              实验轮数经验值：闭集检测 8–15 轮，splat 重建 3–6 轮，微调 10–20 轮
标注（条）     = 目标类别数 × 每类样本数 × 2.2（含复核与返工）

三条式子各自独立，所以超支能定位：是人力系数估低了（新场景按 1.0 算），还是卡时估算忽略了返工（没乘 1.6），还是标注量不够导致反复补采。定位不到超支来源的项目，下一轮一定还会超。

单价假设（2026 年 11 月口径，用自己公司的数替换）：

12.4.3 算例 A：低空巡检，12 周

场景假设：2 条固定航线、3 类固定缺陷、端上实时推理、云端复核与报告。这类项目的功能边界清楚，成本主要落在数据与集成上。

合计约 38 人周、360 卡时。按上表单价：人力 30.4 万、GPU 0.72 万、标注外采约 4 万，总成本 35 万左右，12 周可交付。这个量级的项目如果报价低于 25 万，基本是靠「不标注、不评测、不写回滚」省出来的，交付后会以维护费的形式还回去。

12.4.4 算例 B：城市级三维重建，24 周

场景假设：12 平方公里园区级实景，要求可量测（控制点检核），交付 3D Tiles 加 splat 背景层。难度不在算法，在采集组织与精度控制。

合计约 60 人周、1500 卡时。按单价：人力 48 万、GPU 3 万、外业与存储约 12 万，总成本 65–80 万，24 周。比算例 A 高的不是算法复杂度，而是外业组织与精度返工——控制点少布两个，后期整块重做的代价是周级别的。

两个算例放在一起能看出一条规律：巡检类项目的成本重心在数据与集成，重建类项目的成本重心在外业与精度。用同一套报价模型去套两类项目，必然一类亏一类贵。

12.4.5 外采与自研的边界

不是所有能力都值得自研，也不是所有能力都能外采。判据只有三条：是否构成差异化、是否随规模线性增长、是否有人能长期维护。

「外采开源 + 自研编排」是最常见也最健康的组合：核心能力自己掌握，通用能力用成熟件，中间用编排层黏合。反过来「外采闭源 + 自研接口」的组合看着省钱，实际上把升级节奏交给了供应商，两年后想换要多付一次迁移成本。

12.4.6 报价时最容易漏算的五项

算例给的是「看得见」的成本。真实项目里还有五项常年被漏算，五项合计通常占直接成本的 25%–40%，漏哪一项都足以让项目从盈利变亏损。

五项里最容易被低估的是「评测与回归」。团队在做算例时通常按「训一次、验一次」估，而真实项目里模型要迭代 10 轮以上，每轮都要跑同一套评测集，这项工作量会线性累积。把它按人力比例（10%–15%）硬性计入，比逐轮估更可靠。

第二容易被低估的是「运维交接与培训」。交付时没做培训的项目，三个月后甲方会以「不会用」为由要求驻场，驻场的成本远高于那 5 个人天。培训不是赠品，是交付物的一部分，写进合同反而能减少后期的无形成本。

12.4.7 这一节的四个坑

1. 不标单价就报价：用别人的单价报自己的项目，结果人力成本算成一半。单价要写进内部模板，每季度更新。
2. 卡时不乘返工系数：一次训练成功是小概率事件，按 1.6 倍预留返工，比事后追加预算容易得多。
3. 标注按「条」估不按「类」估：类别越多，单类的边界样本越难找，成本非线性上升。按类别数乘样本数估，误差小一半。
4. 把交付当研发的附属：交付与研发的边界不清，会导致「研发在做交付的活、交付在猜研发的排期」。两条线各有负责人，比合并成一个更能保工期。

12.5 风险清单

项目翻车的方式就那么几种，但每次翻车都有人惊讶。这一节把风险分三类，每类给触发信号——风险管理的本质不是列清单，是把「什么时候该警觉」写下来。

12.5.1 技术风险

版本兼容。这是空间智能项目最高频的技术风险：CUDA、驱动、TensorRT、PyTorch、GDAL、PROJ、GEOS 七层依赖，任意一层升版都可能让昨天能跑的流水线今天报错。2026 年的情况更糟，因为 Jetson 侧要从 TensorRT 10.x 迁到 11.x，而桌面侧新卡默认装的是新驱动。

对策不是「不升级」，而是把升级变成可回退的动作：

# 把「环境版本」当交付物：锁文件 + 镜像 + 一条重建命令
python -m pip freeze > requirements.lock
docker build -t kjzn/infer:2026.11.13 -f Dockerfile.infer .
docker run --rm kjzn/infer:2026.11.13 python -c "import torch, tensorrt; print(torch.__version__)"
# 升级前后各跑一次同一份评测集，结果记进版本台账
python tools/eval.py --suite smoke --engine active.engine --out reports/2026-11-13.json

模型许可。SAM 3 系列、VGGT、以及各类三维数据集的许可差别很大：有的允许商用但要求署名，有的仅限研究，有的商用 checkpoint 要单独申请（VGGT-1B-Commercial 从 2025-07-29 起需要申请就是例子）。签约前把「权重、代码、数据集」三份许可分别过一遍，别只看代码仓库首页的 license 徽章。

数据合规。影像是否涉密、控制点坐标是否属涉密测绘成果、数据能否出境，这三件事要在项目启动时就有书面判断，而不是等安全审查。具体判定以现行法规与主管部门要求为准，本节只给流程建议：采集前定密级、入库前脱敏、交付前留痕。

12.5.2 工程风险

边缘运维。塔上设备、机载设备、无人值守站点，共同点是「出事时没人能立刻到现场」。这里的风险不是设备坏，而是坏了没人知道、或者知道了没人会修。对策是把可观测性做成标配：心跳、推理延迟、GPU 温度、磁盘余量四项指标，缺一项就不许上线。

长尾场景。试点的 100 个样本里表现很好，扩到 10 个站点的 10 万帧就掉点。长尾风险的特点是「采样越多越暴露」，所以对策不是「再多训一点」，而是建立难例回流机制：现场误检误漏的帧自动回流、按周聚类、按月补训。

带宽与存储。原始影像与点云的体积常被低估。12 平方公里、0.05 m 分辨率的影像加中间产物，2 TB 只是起步。回传策略要在方案阶段定死：哪些数据必须回传、哪些在边缘侧处理后只回传结果、哪些只留抽样。

12.5.3 组织风险

交付与研发的边界。研发追求「通用、可复用」，交付追求「这次能验收」。两者不设边界，结果是研发被项目拖死、交付拿不到能用的版本。常见做法是切出 20% 的研发带宽做平台化，其余按项目排期，且平台需求必须由交付方提出、有明确的复用次数预估。

验收口径漂移。需求阶段说「检出率达到 95%」，验收阶段变成「每个缺陷都要检出」。漂移的根源是口径没写死：哪类缺陷、什么条件下、按帧还是按目标、谁来做仲裁。把评测集随合同交付，是防漂移最有效的一招。

关键人依赖。空间智能项目里「懂坐标与精度」的人往往只有一个。这个人离职，项目直接停摆。对策不是留人，而是把判断依据写成文档与脚本——控制点检核脚本、评测脚本、回滚脚本三件套，谁都能跑。

12.5.4 风险 → 触发信号 → 缓解措施

三类风险压成一张可执行表。使用时按「触发信号」那一列做监控，别按风险名称做监控——名称不会自己报警，信号会。

这张表里最值得抄的是最后一列。「兜底方案」不是给风险管理的体面，是给项目经理的止损按钮——没有兜底方案的风险，等于没识别。

12.5.5 一个能跑的许可与依赖体检脚本

技术风险里最容易被漏掉的是「许可」，因为没人愿意读法务条文。至少可以做一件低成本的事：把依赖树里的许可类型扫出来，人工过一遍红旗项。

#!/usr/bin/env bash
# license-scan.sh —— 扫 Python 与 Node 依赖的许可类型，输出需要人工确认的清单
set -euo pipefail
OUT=reports/license-$(date +%Y%m%d)
mkdir -p "$OUT"

# Python 侧：pip-licenses 列出每个包的许可
python -m pip install -q pip-licenses
pip-licenses --format=csv --with-urls > "$OUT/python.csv"
awk -F',' 'NR>1 && $2 !~ /MIT|BSD|Apache|ISC|Python/ {print "CHECK: "$1" -> "$2}' "$OUT/python.csv" > "$OUT/python-check.txt"

# Node 侧：license-checker 只输出非宽松许可
npx --yes license-checker --summary --onlyAllow 'MIT;ISC;BSD-2-Clause;BSD-3-Clause;Apache-2.0' \
  > "$OUT/node-allow.txt" 2>&1 || true

echo "---- 需要人工确认的项 ----"
cat "$OUT/python-check.txt"
echo "报告目录：$OUT"

这个脚本只能发现「显式标注的许可」，发现不了「权重文件另有限制条款」——比如代码是 Apache-2.0，但 checkpoint 需要申请商用许可。所以脚本要做，人工审也要做：脚本负责不漏，人负责看懂。权重许可必须回到模型卡（model card）上逐个确认，这一条没有自动化捷径。

12.5.6 三个延期项目的复盘

风险表看多了会麻木，讲三个脱敏的真实类型更有用。三个项目的类型分别是低空巡检、城市三维、政务一张图；延期的直接原因各不相同，但都命中了 12.5.4 表里的某一行。

案例一：低空巡检，延期 10 周。 表象是「模型精度不达标」，实际是标注口径错了——需求写的是「绝缘子破损检出」，标注时把「污秽」也标成了破损，模型学到的是错误的类别边界，现场抽检误检率超过 30%。回炉重标 3 周、重训 2 周、重新试点 4 周。复盘结论：验收口径必须在标注之前写死，且标注规范要与甲方共同签字确认一次。

案例二：城市三维，延期 12 周。 表象是「重建质量不满足」，实际是控制点布设不足——12 平方公里只布了 9 个控制点，且集中在主干道两侧，边缘街区的高程误差超限，整块返工。复盘结论：控制点密度要按「每平方公里不少于 4 个、均匀覆盖」布设，这条要写进采集方案，不能留给外业临时决定。

案例三：政务一张图，延期 6 周。 表象是「智能体答不准」，实际是工具描述含糊——早期版本让模型自己决定坐标系，同一个「范围统计」问题在 CGCS2000 和 WGS84 下差了 400 多米，回答时对时错，排查了两周才定位到参数缺失。复盘结论：空间参数一律必填，宁可让调用失败，也不要让模型猜默认值。

三个案例的共同点是：延期的直接原因都在技术之外，但修复手段落在工程规范上。把口径、控制点密度、必填参数写进方案模板，比在事故后加人手更有效——这也是 12.5.4 那张表最右一列「兜底方案」存在的理由。

12.5.7 这一节的四个坑

1. 风险表做成摆设：列了二十项风险却没有一项挂在看板上。风险管理的产出不是表，是每周更新的「当前活跃风险前三名」。
2. 只识别人力与工期风险：技术风险（版本、许可、合规）往往一次就能让项目停摆，却常常被排除在风险清单之外，因为它不属于项目管理的传统分类。
3. 兜底方案写成「加强沟通」：兜底必须是动作加时间，例如「心跳中断 10 分钟自动重启，失败则 4 小时内派人到现场」。
4. 不做复盘就进入下一个项目：同一个团队连续三次栽在标注口径上，说明缺的不是运气，是模板。复盘结论要沉淀进方案模板，否则下一轮原样重演。

12.6 给不同角色的行动建议

这一节写给「明天要上班」的人。每条建议都设成 90 天内可完成、可检查的动作，不写「加强学习」「提升能力」这类没法验收的话。

12.6.1 技术负责人

1. 把四条主线的现状做成一张内部表，每格填上「我们用的技术 + 成熟度 + 不可交付项」。填不出来的格子就是风险点，90 天内补齐事实依据（跑一次评测、问一次供应商、读一次许可）。
2. 砍掉一个「看起来先进但不构成差异化」的自研项。空间智能团队最常见的浪费是自研地图引擎或自研标注平台，这两件事的投入产出比通常很差。
3. 定一条升级纪律：任何依赖升版必须先跑评测集，结果记进版本台账。这条纪律的执行成本很低，能避免 80% 的现场事故。
4. 给关键人配一份备份文档：控制点检核、评测、回滚三件事，至少两人能独立操作。

12.6.2 算法工程师

1. 建立现场抽检集，规模不用大，200–500 个目标就够，但必须来自真实航线、真实光照、真实季节。这一份数据决定你所有模型讨论的可信度。
2. 把后处理参数外置成配置，按数据集版本管理。这既是为 12.2.1 的趋势做准备，也让复现变简单。
3. 量一次真实的端到端延迟，用 trtexec 而不是 Python 计时循环，记下 p50 与 p95。这两个数字会改变你对模型规模的判断。
4. 给模型留一档降级路径：精度高但慢的大模型 + 精度低但快的小模型，用同一套接口切换。现场网络或算力变化时，这条路径能救场。

12.6.3 后端与平台工程师

1. 把现有 GIS 接口改造成合格工具：补 bbox、CRS、时间窗、分页游标，补机器可读的错误码。先改 5 个高频接口，比一次性重构整个服务有效。
2. 读写分离：把写操作拆成独立工具，加确认参数与审计日志。这件事在 12.2.4 的趋势兑现后会变成刚需，现在做成本最低。
3. 把任务编排做成可重放的：给定输入与版本号，能一键重跑整条流水线。空间智能项目的排错有 70% 靠「能不能重放」。
4. 给瓦片服务加缓存与限流：三维场景的加载请求量比二维高一个量级，没做缓存的瓦片服务在演示现场就会崩。

12.6.4 交付与售前

1. 把「不可交付」写进方案：视觉参考不等于量测成果、开放词表不等于零样本、端到端不等于无人值守。提前写清边界，后面省掉八成扯皮。
2. 用算例报价：抄 12.4 的三条式子，按自己公司的单价重算一遍，标出「不含」项（标注、外业、存储、运维）。
3. 准备一份 15 分钟的现场演示，内容不是「模型多准」，而是「从输入到报告的全流程」。甲方对流程的信任度远高于对指标的信任度。
4. 推动评测集随合同交付，把它写成「共同确认的验收基准」而不是「供应商自证」。这是 12.2.5 那条趋势下最有利于交付方的条款设计——有了共同基准，验收争议会大幅下降。

12.6.5 一个 90 天的时间盒

把上面 16 条压进 13 周，每周只做一件事的节奏最稳：

第 1–2 周   四条主线现状表 + 现场抽检集建档
第 3–4 周   端到端延迟实测 + 后处理参数外置
第 5–6 周   5 个高频接口工具化改造 + 读写分离设计
第 7–8 周   许可与依赖体检 + 版本台账 + 升级纪律
第 9–10 周  流水线可重放改造 + 瓦片缓存与限流
第 11–12 周 不可交付清单 + 算例报价模板 + 演示脚本
第 13 周    复盘：哪条趋势的先行指标出现了，判断要不要改

时间盒的意义在于「每周只有一件事」，而不是「13 周要做 16 件事」。前者能完成六成，后者通常完成两成还在开会。

12.6.6 这一节的三个坑

1. 把行动建议写成学习计划：「学习 3DGS」「研究 MCP 规范」不是行动，因为它们没有产出物。行动建议必须带交付物与验收条件。
2. 四个人做同一件事：技术负责人与算法工程师都去改模型、交付与后端都去接接口，结果是责任重叠但不重叠负责。先把边界写清，再谈协作。
3. 90 天排 16 件事：时间盒的容量是固定的，排得越满完成率越低。宁可写 6 件必做、10 件可选，也别写 16 件必做。

12.7 全书回顾与学习路线

十二章写完，回到最初那个问题：空间智能到底难在哪。回顾下来，难点不在单点技术，而在四件事必须同时成立——数据在坐标上是对的、模型在现场是够用的、接口在 agent 手里是可用的、交付在合同里是可验收的。任何一环缺失，其余三环的价值都会打折。

12.7.1 十二章的一句话价值

这张表建议按「你正在做的工作」重排一次。排完会发现：真正卡住项目的往往不是你以为的那一章。

12.7.2 三条学习路线

不同的人读同一本教程，应该读出不同的路径。下面三条路线按目标切分，每条给出推荐顺序、时间投入与产出物。

路线 A 快速上手（4 周，约 20 小时）
  01 ──▶ 08 ──▶ 02 ──▶ 11
  产出：一个能跑的 DSH 工作区、一份坐标正确的小数据集、
        一条能跑通的巡检 demo、一份可交付的验收清单

路线 B 工程交付（10 周，约 60 小时）
  08 ──▶ 02 ──▶ 03 ──▶ 04 ──▶ 09 ──▶ 10 ──▶ 11
  产出：一条从采集到上线的完整链路、一套评测集与门禁、
        一份可复现的交付文档包

路线 C 技术深耕（16 周，约 120 小时）
  05 ──▶ 07 ──▶ 06 ──▶ 10 ──▶ 12
  产出：一个自训的专用模型、一个可发布的 splat 场景、
        一套评测与回归脚本、一份技术判断台账

路线 A 的设计逻辑是「先让东西跑起来」。选 01（开发方式）、08（坐标不出错）、02（有真实场景）、11（知道交付标准），四章覆盖了一个人从零到能干活的最小闭环。这条路线的产出物都要求「能演示」，不要求「能生产」。

路线 B 的设计逻辑是「按交付顺序排」。08 先立地基，02 和 03 拿真实场景练手，04 加智能层，09 解部署，10 和 11 收口验收。这条路线适合已在项目里、需要补齐链路认知的人。注意它跳过了 05、06、07 —— 交付型项目里三维重建与微调往往是外采或专项，不必人人都懂。

路线 C 的设计逻辑是「按技术深度排」。05 练端到端任务，07 练微调，06 练重建，10 练评测，12 练判断。这条路线的产出物全部是可复用的技术资产，适合想往算法或架构方向走的人。它最花时间，也最容易半途而废——所以每次只做一章，做完再决定下一章。

12.7.3 十二章之间的依赖关系

不是所有章都能随便跳。下面这张图画出「读某章之前最好先读什么」，实线是硬依赖，虚线是建议但不强制：

  01 ──────────────▶ 02 ──▶ 03 ──┐
   │                  │           │
   │                  ▼           ▼
   └──────────────▶ 08 ──▶ 04 ──▶ 09 ──▶ 10 ──▶ 11 ──▶ 12
                      │           ▲
                      ▼           │
                     06 ──▶ 07 ──┘
                     ▲
                     └── 05（合成数据与仿真反过来喂 05）

三条硬依赖值得单独说。08 在 02、04 之前：坐标系与时空基准不讲清，后面的空间查询与融合全是错的，而且错得很难发现。06 在 09 之前：splat 的训练与发布要占用边缘与云端资源，不讲重建就说不清部署的显存与带宽从哪来。10 在 11 之前：没有评测集与回归门禁，验收时只能靠嘴说服甲方。

12.7.4 学完之后，怎么判断自己真的会了

一个可自测的标准：给你一个陌生的空间智能需求，你能在半天内产出一页纸，写清交付物、验收指标、技术栈、不推荐项、预算量级与三条主要风险。写得出来，说明十二章的知识被串成了判断力；写不出来，说明还停在「会用工具」的阶段，回去补 12.3 与 12.5 两节。

这个标准不好糊弄，因为它要求同时具备四件事：知道边界（12.1）、知道方向（12.2）、知道取舍（12.3）、知道代价（12.4–12.5）。四件事缺一件，那一页纸就会写空。

12.7.5 三条路线各自的典型走偏

三条路线都有人走完，也都有各自的走偏方式。提前把症状写出来，遇到时能早两周发现。

三条路线的共同走偏方式是「读完了」。阅读的完成度很容易自我确认，工程的完成度不行——所以每条路线都要有产出物，产出物才是进度条。

12.7.6 这一节的三个坑

1. 按章号顺序硬读：从 01 读到 12 需要约 130 小时，多数人会在第 04 章停下。按路线读，先拿到产出物再回来补。
2. 跳过第 08 章：坐标系、投影、精度是空间智能的「静默错误源」，跳过它省下的两小时，后面要用两周还。
3. 把回顾当复习：回顾的价值是重排知识结构，不是重读一遍。按 12.7.1 的表按自己的工作重排，比重读有效得多。

12.8 本章小结

这一章没有教任何新工具，只做了一件事：把前十章的技术细节压成可以拿去做决策的判断。小结部分按四层收口——现状、趋势、选型、代价，每层留一张表，方便下次开会时直接调出来用。

12.8.1 四条主线的结论

四行结论里，唯一「现在不做、以后会很贵」的是感知那一行的「阈值外置」。它今天只是整理代码，等端到端成为默认，它就变成了迁移的前置条件。

12.8.2 八条判断的浓缩版

「兑现概率估计」这一列是我自己的判断，不是共识。更重要的不是这八个字，而是每行背后那张证伪清单——概率估计错了不要紧，看不到证伪信号才要紧。

12.8.3 选型的六条铁律

1. 先写交付物，再选技术。选型的输入是交付物与验收方式，不是论文新鲜度。
2. 许可先过，再谈精度。权重、代码、数据集三份许可分别过一遍，别只看代码仓库的 license。
3. 能外采的绝不自研。地图引擎、渲染、标注平台这三样，自研的投入产出比通常很差。
4. 能降级的先做降级。大小模型双档、本地与云端双档，现场条件一变，降级路径就是救命路径。
5. 先保实时，再谈智能。巡检、无人车这类任务，延迟超预算的功能等于没有功能。
6. 验收口径写死到指标定义。哪类目标、什么条件、按帧还是按目标、谁仲裁，四项缺一不可。

六条里第 3 条最容易引起争论，因为「自研」在技术团队里有天然的道德优势。判断依据很简单：这项能力是否构成差异化、是否随规模线性增长、是否有人能长期维护。三条里两条答「否」，就该外采。

12.8.4 成本与风险的三条经验

第一条，预算的重心由场景决定，不是由技术决定。巡检类项目重心在数据与集成，重建类项目重心在外业与精度。用同一套报价模型套所有项目，必然一类亏一类贵。

第二条，返工系数要比你想的高。GPU 卡时按 1.6 倍预留，人力的新场景复杂度按 1.8 倍估。按理想情况报价的项目，最后都靠加班补。

第三条，兜底方案比风险识别更重要。识别出十项风险但一项兜底都没有，等于没做风险管理。风险表最右一列必须是「出事了按哪个按钮」。

12.8.5 一段收口

空间智能这个方向，过去三年最大的变化不是模型变强，而是整条链路的每一段都开始有可交付的工程答案：感知有端到端，重建有 splat 与 LOD，智能体有 MCP，部署有 Jetson 与 TensorRT，评测与交付也各自成了方法。这意味着一件事——胜负从「谁能做出 demo」转向「谁能把 demo 变成可验收、可运维、可复制的产品」。

这个转变对个人的要求也变了。会调模型只是入场券；能把模型放进一条有坐标、有延迟预算、有回滚、有评测的链路里，才是稀缺能力。前十章练的是这条链路的每一段，这一章练的是把链路看成一体的判断力。

最后留一句可执行的话：任何技术判断，如果写不出「在什么条件下我会认错」，它就还不是判断，只是立场。全书的技术观点都按这个标准写，也希望读者用同一个标准来检验它们。

12.9 动手练习

这一节的练习全部是「判断类」任务，不需要 GPU，但都需要你手上有真实项目或真实数据。每个练习给出输入、要求与验收三条，验收标准写成可打勾的形式，做完自己勾一遍就知道过没过。

练习之间没有依赖，可以挑着做。如果你只有两小时，做练习 1 和练习 4；如果你要为下一次技术评审做准备，做练习 2、3、5。

12.9.1 练习一：给一个真实需求写选型一页纸

输入：找一个你手上的真实需求（在做的、或投标文件里的），一页纸描述它的交付物与验收条件。

要求：

1. 按 12.3.1 的四条否决线逐条判断，写明通过或不通过，以及不通过时的替代方案。
2. 从 12.3.2 的总表里挑出最接近的场景，抄它的推荐栈，然后改三处——说明为什么这三处要按你的场景调整。
3. 写出至少两个「明确不推荐」的选项，每个给一条基于约束的理由（延迟、许可、运维、精度任选）。
4. 给出预算量级，用 12.4.2 的三条式子算，标出单价来源与「不含」项。

验收：

[ ] 一页纸内写完，没有超出一页
[ ] 四条否决线都有明确结论，不是「待定」
[ ] 两个不推荐选项各有一条约束类理由，不是「效果不好」
[ ] 预算有式子、有单价、有「不含」项
[ ] 全文没有出现「先进」「领先」「强大」这类无法验收的词

常见错误：把「不推荐」写成「暂不推荐」——这是回避判断。真不推荐就写不推荐，并给出什么条件下可以推荐。

12.9.2 练习二：建一份八条判断的台账

输入：12.2 的八条判断，以及你自己所在行业的两三条公开信号。

要求：

1. 按 12.2.9 的 yaml 结构建一个 judgment-ledger.yaml，八条判断全部录入，每条写清 signal（先行指标）、falsifier（证伪信号）、check_by（复核时间）。
2. 给你的行业补两条本章没写的判断，同样按「结论 + 证据 + 触发条件 + 反例」四段式写。
3. 为每条判断标注一个「兑现概率」与判断依据（一句话即可）。
4. 设一个季度复核的提醒，把「改判断要写理由」这条规矩写进文件头注释。

验收：

[ ] yaml 能被解析（用 python -c "import yaml,sys; yaml.safe_load(open('judgment-ledger.yaml'))" 验证）
[ ] 十条判断都有 falsifier，且 falsifier 是可观测的事件而不是感受
[ ] 至少两条判断的 check_by 落在未来 12 个月内
[ ] 文件头注释写明了复核周期与修改规则

常见错误：证伪信号写成「效果不如预期」——这不是信号，是结论。信号必须是「看到某件具体的事发生」，例如「两家以上平台发布官方 MCP server」。

12.9.3 练习三：把三个 GIS 接口改造成合格工具

输入：你项目里的三个高频 GIS 接口（图层查询、范围统计、要素定位之类）。

要求：

1. 按 12.1.4 的四条合格线重写工具描述：参数无歧义（bbox、CRS、时间窗）、返回值稳定（要素数、几何摘要、分页游标）、读写分离、错误可解释。
2. 用 JSON Schema 写出 inputSchema，required 里必须有 crs。
3. 写一个 tools/list 的样例响应，确认描述长度不超过 200 字——太长的描述会挤占上下文，模型反而容易忽略关键约束。
4. 故意传一个缺 crs 的请求，确认返回的是可读错误而不是堆栈。

验收：

[ ] 三个工具都能通过 JSON Schema 校验（可用 jsonschema 库验证样例请求）
[ ] 每个工具的 required 里都有 crs 与 bbox（或等价的必填空间参数）
[ ] 查询类工具只读，写操作被拆到独立工具并带 confirm 参数
[ ] 错误响应含机器可读错误码与一句人话原因
[ ] 工具描述单条不超过 200 字

常见错误：把 description 写成接口文档的复制粘贴。agent 需要的是「什么时候该用这个工具、什么参数容易错」，不是「这个接口返回什么字段」。

12.9.4 练习四：算一次自家项目的真实成本

输入：一个已完成或正在做的项目，以及它能拿到的真实单价（人力、GPU、标注、外业）。

要求：

1. 用 12.4.2 的三条式子把成本重算一遍，与项目实际发生的成本对比，算出偏差率。
2. 定位偏差来源：是复杂度系数估低了、返工系数漏乘了、还是标注量不够导致补采。
3. 按 12.4.6 的四个坑逐条自查，写下命中哪几条。
4. 给出下一次同类项目的三个改进动作，每个动作要能在下一轮报价里体现。

验收：

[ ] 有实际成本与估算成本的对照，偏差率有具体数字
[ ] 偏差来源定位到三条式子中的某一条，不是「估不准」
[ ] 四个坑逐条给出「命中/未命中」结论
[ ] 三个改进动作都能落到报价表的具体行

常见错误：只算 GPU 不算人力，或者只算人力不算外业。空间智能项目的成本大头往往在「不写代码的部分」，漏掉就永远算不准。

12.9.5 练习五：写一份 90 天行动清单并做一次复盘

输入：你所在岗位的职责描述（或你实际在做的事）。

要求：

1. 从 12.6 里挑出属于你角色的 3–5 条建议，改写成带交付物与验收条件的动作。
2. 按 12.6.5 的时间盒排进 13 周，每周只允许排一件事。
3. 写出三件「必做」与两件「可选」，并说明可选项在什么条件下升级为必做。
4. 90 天后做一次复盘：完成了哪些、卡在哪、下一轮要不要改判断（对应 12.2.9 的台账）。

验收：

[ ] 每条动作都有交付物与验收条件，没有「学习」「研究」这类无法验收的动词
[ ] 13 周的排期里每周只有一件事
[ ] 必做与可选分开，且有升级条件
[ ] 复盘模板里有「判断是否要改」这一栏

常见错误：把行动清单写成愿望清单。判断标准很简单：列出的一条动作，明天上午能不能立刻开始做第一步？不能，就说明它还不够具体。

12.9.6 练习的评分表

五个练习可以自评，也可以当作团队内部的技术评审清单。评分不看写得多漂亮，只看判断是否可反驳：

总分 25 分。低于 15 分的方案不要拿去评审——不是写得不好，是还没想清楚。

12.10 延伸阅读

下面这些链接是本章判断的证据来源。读的时候注意两点：技术版本以官方文档为准（清单里的版本口径截至 2026 年 11 月）；政策与市场数字要看出处年份，跨年引用时要复核。

官方文档与权重

1. DeepSeek Harness 文档 —— 本系列统一使用的 agent harness，CLI 为 dsh；仍是 developer preview，升级前先读变更说明。
2. Ultralytics 文档 —— YOLO26 的训练、导出与部署参数以这里为准；yolo export 的参数名随版本变化，别照抄旧博客。
3. SAM 3 代码库 —— 概念分割的参考实现，微调路线与权重许可以仓库说明与模型卡为准。
4. VGGT 代码库 —— 前馈式多视图几何的官方实现，做采集质量闸门时先读它的输入格式与显存说明。
5. Qwen3-VL 代码库 —— 多模态微调的基座选择，2B/4B 档适合单卡部署；权重位置、许可与微调配置以仓库与模型卡为准。

三维与发布

1. gsplat —— 稀疏 3DGS 光栅化与多 GPU 训练，构建环境对 CUDA 与 PyTorch 版本有硬要求。
2. Cesium 3D Tiles —— 瓦片化与 LOD 的规范来源，splat 进入城市级底座要靠它。

接口与部署

1. Model Context Protocol —— 以 2026-07-28 规范为准，stateless 核心加 Streamable HTTP 传输；写工具前先读 tools 能力的约束。

正文里还引用了若干官方文档但没有单列，包括 TensorRT 与 Jetson 的版本矩阵、brush 与 SuperSplat 的工具说明、DJI 上云 API 2、PostGIS、DuckDB、GeoParquet、CARLA，以及自然资源部的实景三维政策文件。这些一律以官方站点为准，引用前核对版本与年份。

读完这些不等于会判断。真正的练习在 12.9：把证据变成台账，把台账变成季度复核的习惯，判断力才会随时间累积。