企业官网建设流程全解析

1. 这不是科幻，是正在发生的工程实践

“AI到底能不能自己造AI？”——这句话过去三年在技术社区里吵得比咖啡机还响。有人拍着桌子说“纯属营销话术”，有人举着论文截图喊“本质是人类写的提示词在套娃”，还有人干脆把这问题当哲学思辨题来解。但就在2024年夏天，一个叫AutoGen Studio的开源项目 quietly 上线了 GitHub，Star 数三个月破 8000，背后是一群来自微软研究院、CMU 和几个独立实验室的工程师，他们没发通稿，没开发布会，只扔出了一套可复现、可调试、可部署的完整 pipeline：用 LLM 驱动整个 AI 模型开发闭环——从需求定义、数据清洗、模型选型、超参搜索、训练调度，到评估报告生成、部署接口封装，全程无人工代码介入。这不是“让 ChatGPT 写个 Python 脚本”，而是让大模型作为系统级协作者，在受控沙箱中调用真实计算资源、读写真实数据集、触发真实训练任务、解析真实日志输出，并基于反馈迭代自身指令策略。

我去年底开始跟进这个方向，试过 7 种不同架构的自驱动框架，从早期用 LangChain 搭建的“提示词流水线”，到后来基于 Ray + LlamaIndex 构建的分布式智能体集群，再到最终落地 AutoGen 的 multi-agent workflow。最让我坐直身子的是它第一次成功跑通一个完整闭环：我只输入一句自然语言需求——“帮我做一个能识别工地安全帽佩戴情况的轻量级视觉模型，要求在 Jetson Nano 上推理速度 ≥15 FPS，准确率不低于 85%”，3 小时 47 分钟后，它交付了一个包含训练脚本、量化模型文件（.onnx）、部署服务（FastAPI + ONNX Runtime）、测试报告（含混淆矩阵和 FPS 实测截图）的完整 zip 包。整个过程没有人工 touch 一行训练代码，也没有手动改过一个超参。它自己下载了 COCO-Subset 安全帽数据集，自己做了标注清洗（发现原始标注里有 12% 的漏标框），自己对比了 MobileNetV3、EfficientNet-Lite 和 GhostNet 的 FLOPs/精度曲线，自己写了 PyTorch Lightning 的 Trainer 配置，自己跑了 3 轮 NAS 搜索，最后还生成了一份带热力图的误检分析报告。

这背后的核心，不是“AI 有了意识”，而是工程范式的迁移：我们不再把 LLM 当作“问答机器人”，而是当作一个可编程的、具备上下文记忆与工具调用能力的认知协处理器。它不替代工程师，但它把工程师从“写 for 循环”“调 learning rate”“改 config.yaml”的重复劳动里解放出来，转而专注在更高阶的决策上——比如定义什么是“可接受的误检率”，比如判断某个数据偏差是否值得引入对抗样本增强，比如权衡边缘设备上的延迟与云端后处理的精度增益。所以别再争论“能不能”，先看“怎么让它稳稳地、可审计地、可回滚地做”。这篇文章，就带你拆开这个正在运转的黑盒，看清楚它的齿轮怎么咬合、润滑剂加在哪、哪些螺丝必须手拧、哪些扭矩值绝不能超限。

2. 系统级设计：为什么必须是多智能体协同，而不是单一大模型？

2.1 单一模型的天花板：幻觉、状态丢失与工具调用瓶颈

很多人第一反应是：“既然 LLM 能写代码，那让它直接写一个训练脚本不就行了？”我试过。用 GPT-4 Turbo 接入 Code Interpreter，输入“请用 PyTorch 训练一个 ResNet18 分类器”，它确实能吐出一份语法正确的代码。但问题立刻浮现：

• 幻觉固化：它会“自信地”写入不存在的库（如import torchvision.transforms.v2 as T），而 v2 在当前稳定版 torchvision 中并不存在；
• 状态丢失：训练跑崩后，日志显示CUDA out of memory，你问它“为什么显存溢出”，它会重新编造一个理由（比如“batch size 设置过大”），却完全不记得自己三分钟前刚把 batch size 从 32 改成了 64；
• 工具调用失焦：当你让它“查看训练日志最后一行”，它可能返回一个虚构的字符串，而不是真正去读取/tmp/train.log文件——因为它没有真实的文件系统访问权限，所谓“调用”只是文本层面的模拟。

这些不是模型能力不足，而是架构缺陷：单一大模型是一个无状态的、纯文本的、单次响应的推理单元。它没有持久化内存，无法维持跨步骤的上下文一致性；它没有真正的 I/O 句柄，所有“调用外部工具”的行为都依赖 prompt engineering 的脆弱映射；它更没有错误恢复机制——一次 hallucination 就可能导致整个流程雪崩。

提示：不要被“LLM 能写代码”误导。写一段能通过语法检查的代码，和写一段能在真实 GPU 上跑满 24 小时、自动处理 OOM、动态调整 batch size、保存最佳 checkpoint 的鲁棒训练脚本，是两个维度的能力。前者是文本生成，后者是系统工程。

2.2 多智能体架构：分工即容错，角色即契约

AutoGen 的破局点，在于把“造 AI”这个复杂任务，拆解成一组有明确定义、有边界约束、有通信协议的角色化智能体（Role-based Agents）。它不指望一个大脑解决所有问题，而是搭建一个微型“AI 工程团队”：

• User Proxy Agent：你的数字分身。它不思考，只忠实转发你的指令、接收结果、展示日志。它是人机交互的唯一入口，也是所有操作的审计起点。
• Coder Agent：专精代码生成与调试。它被严格限制在沙箱环境中运行代码，所有文件读写、网络请求、GPU 调用都经由 Proxy Agent 审核。它不负责决策“该不该训练”，只回答“怎么训练”。
• Critic Agent：代码与逻辑的守门人。它不生成代码，但会静态分析 Coder 输出的每一行，检查 import 是否合法、tensor shape 是否匹配、loss function 是否适配任务类型。它用 rule-based checkers + 小型 fine-tuned verifier 模型双保险。
• Planner Agent：全局策略师。它读取需求描述，拆解为子任务（数据准备 → 模型选型 → 训练 → 评估 → 部署），为每个子任务分配 Agent，并设定 success/failure criteria。比如“模型选型”任务的成功标准是：在验证集上 top-1 acc ≥82%，且 FLOPs ≤ 1.2G。
• Executor Agent：真实世界的执行者。它不是 LLM，而是一个轻量级 Python runtime，负责真正执行 Coder 生成的代码、调用torch.cuda.memory_allocated()、读取os.listdir('/data')、启动docker run --gpus all ...。它把 LLM 的“意图”翻译成操作系统能懂的 syscall。

这五个角色之间，通过结构化消息总线（Structured Message Bus）通信。每条消息必须包含：sender,receiver,content_type（text/code/log/error）,task_id,timestamp,signature。例如，Planner 发给 Coder 的消息长这样：

{ "sender": "Planner", "receiver": "Coder", "content_type": "code_request", "task_id": "TASK-2024-08765", "content": "Generate PyTorch training script for binary classification on safety helmet dataset. Target device: Jetson Nano. Max FLOPs: 1.2G. Use mixed precision.", "signature": "sha256:abc123..." }

这种设计带来三个硬性收益：

1. 可追溯性：任何一步出错，都能精准定位到哪个 Agent、哪条消息、哪个 timestamp；
2. 可替换性：你可以把 Coder 换成本地部署的 CodeLlama-7B，把 Critic 换成你自己微调的 PyLint 规则引擎，只要接口协议不变；
3. 可审计性：User Proxy 记录所有原始指令与最终交付物，形成完整的 chain-of-custody，满足企业级合规要求。

2.3 为什么不用 LangChain 或 LlamaIndex？它们缺了最关键的“执行层”

LangChain 是优秀的 prompt orchestration 框架，LlamaIndex 擅长 RAG 场景下的知识检索。但它们共同的软肋是：没有原生的、受控的、可中断的执行环境。LangChain 的Tool是函数调用抽象，实际执行仍依赖开发者手写 wrapper；LlamaIndex 的QueryEngine本质是向量数据库发 query，离“启动训练进程”差着十万八千里。

AutoGen 的 Executor Agent，本质上是一个嵌入式容器化 runtime。它把每个代码块包装成一个 Docker task：

# executor_task.Dockerfile FROM nvidia/cuda:12.2.0-devel-ubuntu22.04 RUN apt-get update && apt-get install -y python3-pip && rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip3 install -r requirements.txt COPY ./src /app WORKDIR /app CMD ["python3", "run.py"]

当 Coder 生成一段训练代码，Executor 不是在当前 Python 进程里exec()，而是构建镜像、启动容器、挂载数据卷、设置 GPU 限制（--gpus '"device=0"'）、重定向 stdout/stderr 到日志文件，最后返回容器 exit code 和日志摘要。这意味着：

• 如果代码里有while True: pass，容器会在 300 秒后被 kill，不会卡死主进程；
• 如果训练耗尽显存，NVIDIA Container Toolkit 会直接报错，Executor 捕获Exit Code 137并通知 Critic；
• 所有文件操作被限制在/workspace挂载卷内，无法污染宿主机。

这才是“能自己造 AI”的物理基础——不是靠嘴说，而是靠容器跑。

3. 核心细节解析：从需求到交付，每一步都在对抗不确定性

3.1 需求理解层：如何把模糊的自然语言，变成可执行的约束条件？

用户输入：“帮我做一个能识别工地安全帽佩戴情况的轻量级视觉模型，要求在 Jetson Nano 上推理速度 ≥15 FPS，准确率不低于 85%”。

这句话里藏着至少 5 类歧义：

• “工地安全帽”指什么？黄色塑料帽？带反光条的？还是包括安全绳、护目镜等全套 PPE？
• “佩戴情况”是二分类（戴/没戴）还是多分类（正确佩戴/歪戴/未系带/无帽）？
• “轻量级”是参数量 < 5M？还是推理延迟 < 100ms？抑或功耗 < 5W？
• “Jetson Nano”具体型号？是 4GB 还是 2GB 版本？CUDA 版本是否匹配？
• “准确率”指 overall accuracy？还是 class-wise F1-score？测试集是否包含雨雾、夜间、遮挡等 hard case？

Planner Agent 的第一项工作，就是发起需求澄清对话（Requirement Clarification Dialogue）。它不会直接问“你想要什么”，而是基于预置的 domain ontology（领域本体），生成结构化追问：

1. 任务粒度确认：

   “检测目标是‘是否佩戴安全帽’（二分类），还是‘安全帽佩戴规范性’（四分类：正确/歪戴/未系带/无帽）？请从以下选项选择：[A] 二分类 [B] 四分类 [C] 其他（请说明）”

2. 数据约束确认：

   “您是否有现成标注数据集？若有，请提供：

   • 数据格式（COCO JSON / YOLO TXT / 自定义 CSV）
   • 标注类别数及名称
   • 图像分辨率范围（如 640×480 ~ 1920×1080）
     若无，我们将从公开数据集（如 Safety-Helmet-Detection）下载并清洗。”

3. 硬件约束确认：

   “请确认您的 Jetson Nano 型号与系统信息：

   • cat /proc/device-tree/model输出（如 ‘NVIDIA Jetson Nano Developer Kit’）
   • nvidia-smi输出（确认 CUDA 版本）
   • 是否已安装 JetPack SDK？版本号？”

这个过程不是 LLM 自由发挥，而是 Planner 调用一个小型决策树模型（Decision Tree Classifier），该模型在 2000 条真实工业 AI 需求语料上 fine-tuned，能预测用户最可能忽略的 3 个关键约束点，并生成对应追问模板。实测下来，87% 的需求经过 2 轮澄清即可收敛，避免了后续因理解偏差导致的返工。

注意：所有澄清对话都记录在clarification_log.json中，作为最终交付物的 metadata。这是审计的关键证据——证明模型不是“猜”出来的，而是“确认”出来的。

3.2 数据准备层：AI 的“食材”怎么洗？不是删脏数据，而是建数据契约

数据质量决定模型上限。但传统做法——人工筛图、写正则清洗文件名、用 OpenCV 做简单 resize——在 AutoGen 流程里被重构为数据契约（Data Contract）驱动的自动化流水线。

当 Planner 确认使用 Safety-Helmet-Detection 数据集后，Critic Agent 会先加载其官方 schema：

{ "dataset_name": "Safety-Helmet-Detection", "version": "v2.1", "license": "CC-BY-SA 4.0", "schema": { "images": { "format": "jpg", "min_resolution": [640, 480], "max_filesize_mb": 5 }, "annotations": { "format": "COCO", "required_fields": ["image_id", "category_id", "bbox", "segmentation"], "categories": [ {"id": 1, "name": "helmet"}, {"id": 2, "name": "head"} ] } } }

然后，Executor 启动一个data_validator.py任务，逐项校验：

• 文件完整性：检查images/下所有 jpg 文件能否被 PIL 正常打开，丢弃IOError的图片；
• 标注一致性：遍历所有 annotation json，验证bbox是否在图像尺寸内（x_min >=0 and x_min + width <= img_width），修复越界坐标；
• 类别对齐：检查category_id是否只出现 1 或 2，过滤掉category_id=3（标注错误）的 instance；
• 数据倾斜检测：统计helmet与head的 instance ratio，若 > 10:1，则触发undersample_head.py自动下采样head类别。

最关键的一步，是生成Data Quality Report：

这份报告不是给人看的，而是给 Planner Agent 的决策输入。如果“标注越界率”超标，Planner 会否决当前数据集，转而建议下载更新版 v2.2；如果“类别不平衡度”触发警告，Planner 会追加一条子任务：“生成 200 张 head 类别的 CutMix 增强图像”。

这就是数据契约的力量：它把主观的“数据好不好”，变成了客观的、可测量的、可自动响应的 SLA（Service Level Agreement）。

3.3 模型选型层：不是穷举搜索，而是基于硬件画像的帕累托前沿逼近

“选什么模型？”是工程师最耗神的环节。AutoGen 把它变成一个多目标优化问题（Multi-objective Optimization），约束条件来自三方面：

1. 硬件画像（Hardware Profile）：Executor 在启动前，会运行hardware_benchmark.py，采集真实指标：

   • GPU 显存可用量（torch.cuda.memory_reserved()）
   • FP16 吞吐量（用torch.cuda.amp.autocast跑 mini-benchmark）
   • NVENC 编码器性能（影响视频流预处理）
   • CPU 单核频率（影响数据加载瓶颈）

2. 任务画像（Task Profile）：基于需求中的“安全帽检测”，Planner 加载预置的 task profile：

   • 输入分辨率：640×480（Jetson Nano 最佳适配）
   • 输出格式：bounding box + confidence（非 pixel-level segmentation）
   • 关键 metric：mAP@0.5（非 top-1 acc）

3. 模型候选池（Model Candidate Pool）：不是从头训练，而是从一个 curated list 中筛选：

   • MobileNetV3-Small (FP16)
   • EfficientNet-Lite0 (INT8)
   • GhostNet (FP16)
   • YOLOv5n (FP16)
   • PP-YOLOE-s (INT8)

Planner 的优化目标是：在满足 latency ≤ 66ms（对应 15 FPS）的前提下，最大化 mAP@0.5。它用一个轻量级贝叶斯优化器（Bayesian Optimizer），在候选池上快速评估：

• 先用torch.jit.trace导出各模型的 TorchScript；
• 在 Jetson Nano 上用timeit测 100 次前向推理，取 p95 latency；
• 用小批量验证集（200 images）测 mAP@0.5；
• 绘制帕累托前沿（Pareto Front）：横轴 latency，纵轴 mAP。

实测结果如下（单位：ms / mAP）：

最终 Planner 选定EfficientNet-Lite0——它在 58.7ms 的延迟下，达到 81.2% 的 mAP，是当前硬件约束下的最优 trade-off。更重要的是，这个决策过程全程可复现：你拿到同样的 hardware profile 和 task profile，跑一遍就能得到相同结果。

实操心得：我最初以为 YOLO 系列更适合检测任务，但实测发现，在 Nano 的 4GB 显存下，YOLOv5n 的 backbone 占用显存过高，导致 batch size 被迫降到 1，反而拖慢了 pipeline 整体 throughput。AutoGen 的硬件感知选型，比我的经验判断更准。

3.4 训练与调优层：超参不是玄学，是可编程的搜索空间

选定 EfficientNet-Lite0 后，Critic Agent 会生成一个search_space.json，定义超参搜索空间：

{ "learning_rate": {"type": "loguniform", "low": 1e-4, "high": 1e-2}, "batch_size": {"type": "categorical", "values": [8, 16, 32]}, "optimizer": {"type": "categorical", "values": ["AdamW", "SGD"]}, "scheduler": {"type": "categorical", "values": ["StepLR", "OneCycleLR"]}, "augmentation": {"type": "categorical", "values": ["basic", "heavy", "none"]} }

注意，这里没有“随便试试”，每个维度都有物理意义：

• learning_rate用 loguniform，因为 LR 的效果在数量级间变化剧烈；
• batch_size只取 8/16/32，因为 Nano 的显存决定了最大可行 batch；
• augmentation分三级，“basic”只做 random flip + normalize，“heavy”加入 cutout + autocontrast，避免过拟合小数据集。

Executor 启动 Optuna 进行贝叶斯搜索，但关键创新在于：搜索过程本身被 instrumented（插桩）。每次 trial，Executor 不仅记录 val_loss，还采集：

• GPU 显存峰值（torch.cuda.max_memory_allocated()）
• 单 step 时间（time.time()delta）
• 梯度 norm（torch.norm(grad)）
• 学习率 warmup 阶段的 loss 曲线斜率

这些指标构成一个Training Health Score（THS），公式为：
THS = 0.4 * (1 - val_loss) + 0.3 * (1 - mem_usage_ratio) + 0.2 * (1 - grad_norm_anomaly) + 0.1 * (1 - lr_warmup_slope)

THS > 0.85 的 trial 才被视为“健康训练”，否则即使 val_loss 低，也会被标记为“过拟合风险高”并降权。这避免了传统搜索中常见的陷阱：模型在验证集上刷出高分，但梯度爆炸、显存泄漏，根本无法部署。

最终，AutoGen 为该任务找到的最优配置是：

• learning_rate: 2.3e-3
• batch_size: 16
• optimizer: AdamW
• scheduler: OneCycleLR
• augmentation: heavy

训练 42 个 epoch 后，val mAP@0.5 达到85.3%，完美满足需求。整个过程生成的training_report.html包含：

• loss/acc 曲线（带 early stopping 标记）
• 混淆矩阵热力图
• 每个 epoch 的 THS 趋势
• 最终 checkpoint 的 SHA256 校验码

4. 实操过程：手把手复现一个端到端闭环（以 Jetson Nano 为例）

4.1 环境准备：不是装一堆包，而是构建可信执行链

在 Jetson Nano 上部署 AutoGen，核心原则是：最小化信任面（Minimize Trusted Computing Base）。我们不信任 pip install 的任意 wheel，不信任 GitHub 上的任意 release binary，所有组件必须可溯源、可验证。

第一步：刷写官方 JetPack 5.1.2（L4T 35.3.1），确保 CUDA 12.0、cuDNN 8.6.0、TensorRT 8.5.2 全部匹配。这是硬件兼容性的基石，跳过此步 90% 的失败源于此。

第二步：构建可验证的 Python 环境。不用conda或pyenv，而是用python3.10 -m venv创建干净虚拟环境，然后：

# 1. 安装 PyPI 官方 wheel（带 PGP 签名验证） pip install --trusted-host pypi.org --trusted-host files.pythonhosted.org \ --index-url https://pypi.org/simple/ \ torch==2.0.1+nv23.05 -f https://download.pytorch.org/whl/torch_stable.html # 2. 安装 AutoGen（从 GitHub release tag 构建） git clone --branch v0.2.19 https://github.com/microsoft/autogen.git cd autogen && pip install -e . # 3. 验证签名（关键！） gpg --verify autogen-0.2.19-py3-none-any.whl.asc autogen-0.2.19-py3-none-any.whl

第三步：配置 Executor 的沙箱。编辑/etc/docker/daemon.json，添加：

{ "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, "userns-remap": "default" }

启用 user namespace remapping，确保容器内 root 用户映射到宿主机非特权 UID，防止容器逃逸。

注意：Jetson Nano 的/dev/nvhost-*设备节点权限必须为crw-rw----，组为video。我曾因chmod 660 /dev/nvhost-prof忘记执行，导致容器内 CUDA 初始化失败，debug 了 3 小时才发现是设备权限问题。

4.2 启动 AutoGen Studio：不是运行一个脚本，而是加载一个工作区

AutoGen Studio 不是 CLI 工具，而是一个 Web UI + Backend 的组合。启动命令：

autogenstudio start --port 8080 --host 0.0.0.0 --workspace /home/nano/workspace

这会在http://<nano-ip>:8080启动 UI，并将工作区根目录设为/home/nano/workspace。该目录结构必须严格遵循：

workspace/ ├── configs/ # Agent 配置（planner_config.json, coder_config.json） ├── datasets/ # 数据集缓存（自动下载到这里） ├── models/ # 训练产出（checkpoints, onnx, logs） ├── reports/ # 所有报告（html, json, png） └── scripts/ # 用户自定义工具（如 custom_data_aug.py）

首次启动时，Studio 会自动创建默认配置。你需要修改configs/planner_config.json，指定硬件 profile：

{ "hardware_profile": { "device": "jetson_nano", "gpu_memory_mb": 3800, "fp16_throughput_gops": 120, "max_batch_size": 32 }, "task_profiles": { "object_detection": { "input_resolution": [640, 480], "output_format": "bbox_confidence", "primary_metric": "mAP@0.5" } } }

4.3 输入需求与监控全流程：看懂日志里的每一个信号

在 UI 的 chat 界面输入需求后，后台会生成一个session_id（如sess_20240822_142301），所有日志按 session 归档。关键日志路径：

• /workspace/logs/sess_20240822_142301/planner.log：Planner 的决策链，含所有澄清对话和选型依据
• /workspace/logs/sess_20240822_142301/coder_exec_001.log：Executor 运行 Coder 代码的 stdout/stderr
• /workspace/logs/sess_20240822_142301/training_001.log：PyTorch 训练日志（含 THS 计算详情）
• /workspace/logs/sess_20240822_142301/eval_001.log：评估报告生成日志

我特别关注training_001.log中的 THS 行：

[INFO] Epoch 12/42 | Val mAP@0.5: 0.821 | THS: 0.872 | Mem: 3.2GB/3.8GB | Grad norm: 0.42 [INFO] Epoch 13/42 | Val mAP@0.5: 0.828 | THS: 0.881 | Mem: 3.3GB/3.8GB | Grad norm: 0.39 ... [INFO] Epoch 42/42 | Val mAP@0.5: 0.853 | THS: 0.912 | Mem: 3.5GB/3.8GB | Grad norm: 0.28

THS 持续 > 0.85，且显存占用平稳上升（非突增），梯度 norm 逐步下降，说明训练健康。如果某 epoch THS < 0.7，日志会明确标注原因，如：

[WARNING] THS=0.621 (low) due to grad_norm_anomaly=0.98 > threshold 0.5

这提示你：梯度爆炸了，需要降低 learning_rate 或增加 gradient clipping。

4.4 交付物解析：不只是一个模型文件，而是一套可交付资产

最终交付的delivery_20240822_142301.zip解压后包含：

delivery/ ├── model/ │ ├── efficientnet_lite0.onnx # 量化后的 ONNX 模型（INT8） │ ├── model_info.json # 模型元数据（input_shape, output_names, version） │ └── calibration_data.npz # 用于 INT8 量化的校准数据集 ├── service/ │ ├── app.py # FastAPI 服务入口 │ ├── requirements.txt # 服务依赖（onnxruntime-gpu==1.16.0） │ └── config.yaml # 服务配置（port, gpu_id, input_size） ├── test/ │ ├── test_images/ # 10 张典型测试图（含 hard case） │ ├── test_report.html # 包含 FPS 实测截图、误检分析 │ └── inference_benchmark.csv # 100 次推理的 latency 分布（p50/p95/p99） └── docs/ ├── user_manual.md # 部署指南（含 jetson-nano-specific 注意事项） └── audit_log.json # 全流程操作审计日志（含所有 agent 消息 hash）

其中test_report.html是交付核心。它不是静态截图，而是用 Plotly 动态生成的交互式报告：

• 左侧：10 张测试图，点击任一张，右侧显示其 detection result + confidence heatmap；
• 中间：FPS benchmark 曲线，横轴是推理次数，纵轴是 latency ms，标出 p50=62.3ms, p95=68.7ms；
• 底部：误检分析，用 t-SNE 将 false positive 的 feature embedding 投影到 2D，聚类显示“夜间低照度”和“反光条干扰”是两大误检源，并给出对应的 data augmentation 建议。

实操心得：交付物里的audit_log.json救过我两次。一次是客户质疑“为什么选 EfficientNet 而不是 YOLO”，我直接导出 log，展示帕累托前沿图和硬件 benchmark 数据；另一次是模型在客户现场 FPS 不达标，我对比inference_benchmark.csv，发现客户用的是 JetPack 4.x（CUDA 10.2），而我们的 benchmark 基于 JetPack 5.1.2，立刻定位到 TensorRT 版本差异。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题速查表：高频故障与一键诊断

5.2 独家避坑技巧：从 7 次失败中总结的硬核经验

技巧 1：Jetson Nano 的 swap 分区不是可选项，是必选项
Nano 的 4GB RAM 在训练时极易耗尽。即使你设置了--memory=3g，Docker 仍可能因 page cache 溢出而