第13章 AI 走进物理世界：本地智能体与摄像头识别工程

本章导读

从第3章搭建本地大模型和 VS Code 插件环境开始，协作模式就很清楚：不是独自写代码，也不是 AI 直接代做，而是人提出目标、智能体生成方案和程序，人确认边界并验收结果。

前面章节已经多次训练了这种协同方式。现在我们把它推进到物理 AI 场景：让本地智能体检查摄像头、生成视觉识别程序、构建一个最小规则模型，并把识别结果转化为反馈。

这一章的案例仍然保持小而清楚：桌面三色卡反馈终端。它用摄像头识别红、黄、绿三种颜色卡，并给出停止 / 请确认 / 通过的反馈。这个项目看起来简单，却包含物理 AI 工程的关键结构：

  1. 摄像头能不能被系统识别；
  2. 程序怎样读取图像；
  3. 模型怎样从图像中提取特征并判断；
  4. 反馈怎样呈现给用户；
  5. 需求变更后，智能体怎样修改程序并重新测试；
  6. 人怎样判断智能体完成得是否可靠。

本章的重点不是训练复杂视觉模型，而是让你体验一次完整的人机协同工程流程。本章还会加入需求变更任务：你将修改需求，观察智能体如何理解变化、改代码、跑测试、记录结果。

《大学》说：致知在格物。 让 AI 接触摄像头，并不是让它替人感知世界，而是把真实现象变成可以观察、记录和复核的过程。

学习目标

先修要求与环境清单

知识准备：先认识这些词

  1. 本地智能体（local agent）
    • 一句话说明：在本机开发环境中，能够根据你的指令规划任务、创建文件、运行命令、读取结果并继续改进的 AI 协作助手。
    • 工程要点：智能体可以生成方案、创建文件并在授权范围内运行命令，但不代表它拥有最终决定权。路径、权限、风险和验收标准必须由人确认。
  2. 摄像头探测（camera probing）
    • 一句话说明：在正式开发前，先检查系统是否能打开摄像头。
    • 工程意义：很多项目不是模型失败，而是设备根本不可用。先探测设备，可以少走弯路。
  3. 视觉输入（visual input）
    • 一句话说明：摄像头采集到的一帧图像或一段视频流。
    • 工程边界：视觉输入可能包含隐私，因此采集、保存、上传都必须被限制。
  4. 规则模型（rule-based model）
    • 一句话说明：用人工设计的规则完成判断的最小模型。
    • 本章例子：统计画面中红、黄、绿颜色区域占比，根据最大占比输出颜色类别。
    • 工程价值：规则模型不一定高级，但可解释、可调试、适合验证物理 AI 闭环。
  5. 需求变更（requirement change）
    • 一句话说明：项目运行后，使用者提出新的规则或功能要求。
    • 本章例子：原本只识别红、黄、绿，后来要求加入蓝色求助状态，或者要求识别不到颜色时写入日志。
    • 工程要点：需求变更后必须重新测试，防止改好一个功能又破坏原功能。
  6. 回归测试（regression testing）
    • 一句话说明：修改程序后，重新测试原有功能是否还正常。
    • 本章例子：加入蓝色卡后，仍要测试红、黄、绿是否识别正确。
  7. 失败兜底（fallback）
    • 一句话说明：摄像头不可用、图像不清楚、模型无法判断时，系统要有备用流程。
    • 本章原则：摄像头不可用时使用样例图片；识别不确定时输出未识别；涉及隐私时立即停止。

13.1 问题与现象：让智能体开发现实世界程序，难在哪里

13.1.1 软件任务和物理任务的差别

第10章中，智能体在沙盒里写文件；第11章中，智能体按步骤完成多步任务；第12章中，智能体辅助设计专业工作流。这些任务主要发生在文件、文本和程序环境中。

摄像头识别不同。它第一次把智能体写出的程序接到了现实世界。

现实世界会带来新问题：

相关内容见表13-1。

表13-1 问题与具体表现记录表

问题 具体表现
设备不确定 电脑可能没有摄像头，或摄像头被其他软件占用
权限不确定 操作系统可能禁止程序访问摄像头
环境不确定 光线、背景、距离都会影响识别
隐私不确定 摄像头可能拍到不该拍的画面
结果不确定 模型可能把黄色识别成绿色

所以，物理 AI 项目不能直接从写代码开始，而要从检查环境和风险开始。

13.1.2 为什么选择三色卡项目

三色卡反馈终端不是为了展示视觉 AI 有多强，而是为了训练工程闭环。

它有四个优点：

  1. 输入简单：红、黄、绿三种颜色容易准备。
  2. 结果可见：你能一眼判断程序是否识别正确。
  3. 模型可解释：颜色占比规则容易理解和调试。
  4. 需求可变更：可以加入蓝色状态、阈值、日志、样例图片等扩展。

如果一开始就让智能体识别所有物体、判断垃圾分类或识别人的表情，项目会立刻变得不稳定，也会带来隐私和伦理风险。

13.1.3 本章要观察智能体的什么能力

本章不是只看最终程序能不能运行，还要观察智能体的工作过程。

你要重点记录：

【思考 1】 为什么本章要求智能体先检查摄像头，而不是直接生成识别程序？

思考提示：摄像头可能不存在、被占用或没有权限。先检查设备可以避免把设备问题误认为模型或程序问题，也能帮助项目建立失败兜底。

13.2 原理与分析：本地智能体如何完成物理 AI 小工程

相关结构如图13-1所示。

图13-1 颜色证据闭环：从现实色卡到人工复核

图13-1的重点不是展示“摄像头到程序”的简单流程，而是把物理 AI 的关键桥梁画出来：真实色卡先变成图像帧，图像帧再变成颜色占比证据，规则模型只根据证据输出状态，最终仍由人结合环境线索复核。

13.2.1 工程结构：从需求到反馈

人提出目标和边界
  ↓
智能体列计划、路径、风险
  ↓
摄像头探测
  ↓
生成识别程序和规则模型
  ↓
运行测试
  ↓
记录日志
  ↓
人提出需求变更
  ↓
智能体修改程序并回归测试

这个流程里，智能体并不是自动完成一切。它负责生成和执行，人负责确认和验收。

13.2.2 最小视觉模型：为什么先用规则模型

拓展学习阶段当然可以接触视觉大模型、目标检测模型或轻量分类器。但本章先使用规则模型，原因有三点：

相关内容见表13-2。

表13-2 原因与说明记录表

原因 说明
可解释 你能看懂为什么判断为红、黄、绿
可调试 出错时能调光线、背景、阈值
可运行 不依赖大型模型下载和显卡资源

本章的规则模型大致如下：

读取摄像头画面
  ↓
统计红、黄、绿颜色区域占比
  ↓
如果某种颜色占比超过阈值
  ↓
输出对应状态
  ↓
否则输出未识别

这也是一种模型，只是它不是训练出来的神经网络，而是人工设计的规则模型。规则模型适合做第一版，后续可以替换为视觉大模型或轻量学习模型。

规则模型的意义在于“可解释”。当程序输出错误时，学生能回到颜色占比、阈值、光线、背景这些具体证据上排查，而不是只说“模型不准”。这正是本章作为物理 AI 入门项目的价值。

13.2.3 人机协同中的四个责任点

相关内容见表13-3。

表13-3 环节与智能体负责记录表

环节 智能体负责 人负责
需求澄清 把任务拆成文件、命令和步骤 确认目标是否合理
环境检查 运行摄像头探测程序 判断是否允许访问摄像头
程序生成 创建识别程序和日志文件 检查路径、权限和隐私边界
测试改进 根据结果修改代码 判断是否通过验收

物理 AI 中，人的责任更重。因为程序连接了真实设备，错误可能影响现实环境。

13.2.4 需求变更为什么重要

真实项目很少一次写完。用户经常会说：

这些要求看似简单，但会考验智能体是否真的理解项目结构。优秀的智能体协作不是第一次生成看起来能跑的程序，而是需求变化后仍能稳定修改、测试、记录。

13.2.5 回归测试：改完不能只测新功能

如果你让智能体加入蓝色卡识别，只测试蓝色是不够的。还要重新测试红、黄、绿。

这叫回归测试。

相关内容见表13-4。

表13-4 修改内容与必须重新测试记录表

修改内容 必须重新测试
增加蓝色识别 红、黄、绿、蓝、未识别
修改颜色阈值 所有颜色是否仍能正确识别
增加日志 程序是否仍能实时反馈
增加样例图片模式 摄像头模式是否仍可用

相关结构如图13-2所示。

图13-2 需求变更与回归测试：新功能通过不等于项目通过

图13-2强调的是工程直觉：新增蓝色求助状态后，不能只验证蓝色。只要程序被修改，红、黄、绿和未识别这些旧功能都要重新测试，运行日志和失败兜底也要重新核查。

【思考 2】 智能体把蓝色识别加好了，蓝色测试通过。为什么你还要重新测试红、黄、绿？

思考提示：修改程序可能影响原有逻辑。只测新功能，可能漏掉旧功能被破坏的问题。

AI 协同实践：让智能体开发并改造三色卡反馈终端

实践目标

本实践分为两个阶段：

所有操作都在 VS Code 插件聊天窗口中完成。本实践不要求手写代码，但必须审查智能体的计划、文件路径、运行命令和测试结果。

第 1 步：创建工作区前先让智能体列计划

向 VS Code 插件中的本地智能体发送：

请帮我完成第13章本地智能体驱动摄像头识别工程。

目标：
1. 在 ch13_physical_ai_color_demo 文件夹中创建项目；
2. 先检查电脑是否能打开摄像头；
3. 再生成一个摄像头三色卡识别程序；
4. 识别红、黄、绿三种色卡，并输出停止 / 请确认 / 通过；
5. 如果摄像头不可用，使用样例图片完成同样流程；
6. 运行日志写入 run_log.md；
7. 不主动保存摄像头画面，测试前确认画面不含人脸或隐私内容，不上传图片，不访问工作区外文件。

请先不要创建文件。
请列出：
1. 你准备创建的文件路径；
2. 每个文件的作用；
3. 需要运行的命令；
4. 可能的风险；
5. 验收标准。
等待我确认后再执行。

验收智能体计划时，重点看：

相关内容见表13-5。

表13-5 检查点与合格表现记录表

检查点 合格表现
路径 所有文件都在 ch13_physical_ai_color_demo/
风险 明确不上传图像、不保存隐私画面
步骤 先检查摄像头，再生成识别程序
兜底 摄像头不可用时有样例图片模式
验收 有红、黄、绿和失败测试

第 2 步：摄像头探测

确认后，让智能体先只做摄像头探测：

我确认可以创建工作区。
请先只创建并运行 device_probe.py。
要求：
1. 检查摄像头是否可用；
2. 不保存摄像头画面；
3. 不联网；
4. 输出摄像头索引、是否打开成功、画面尺寸；
5. 如果失败，写出可能原因和下一步建议；
6. 把结果写入 run_log.md。

可能结果：

相关内容见表13-6。

表13-6 结果与处理方式记录表

结果 处理方式
摄像头可用 进入摄像头实时识别模式
摄像头不可用 进入样例图片模式
缺少依赖 记录依赖缺失，由课程环境统一处理，不让智能体擅自安装未知包
权限被拒绝 打开系统摄像头权限后重试

第 3 步：生成最小识别程序

继续发送：

请生成 color_terminal_v1.py。

功能要求：
1. 摄像头可用时读取摄像头画面；
2. 摄像头不可用时读取 samples 文件夹中的样例图片；
3. 使用规则模型识别红、黄、绿三种主要颜色；
4. 红色输出：STOP / 停止；
5. 黄色输出：CHECK / 请人工确认；
6. 绿色输出：PASS / 通过；
7. 无明显颜色时输出 UNKNOWN / 未识别；
8. 每次测试结果写入 run_log.md；
9. 程序运行说明写入 README.md。

请完成后运行一次自测，并报告测试结果。

智能体完成后，你要查看它的报告是否包含：

第 4 步：人工验收 v1

填写 v1 测试表：

相关内容见表13-7。

表13-7 测试编号与输入记录表

测试编号 输入 预期输出 实际输出 是否通过
T1 红色卡 STOP / 停止
T2 黄色卡 CHECK / 请人工确认
T3 绿色卡 PASS / 通过
T4 无明显颜色 UNKNOWN / 未识别

如果某项失败，让智能体先解释原因，再修改。

提示词：

测试结果如下：____。
请先分析失败原因，不要马上改代码。
请区分：
1. 摄像头或光线问题；
2. 背景干扰问题；
3. 规则阈值问题；
4. 程序逻辑问题。
分析完后提出最小修改方案，等待我确认。

第 5 步：提出需求变更

现在模拟真实项目：用户提出新需求。

需求变更如下：

在红、黄、绿之外，新增蓝色卡。蓝色表示HELP / 请求协助。加入后，原来的红、黄、绿功能不能坏。

向智能体发送：

现在提出一次需求变更：
1. 新增蓝色卡识别；
2. 蓝色输出 HELP / 请求协助；
3. 原有红、黄、绿、未识别功能不能受影响；
4. 请先说明需要修改哪些文件、为什么修改这些文件；
5. 请更新测试用例；
6. 修改后必须做回归测试。
请先给修改计划，等待我确认。

这一步的重点不是蓝色本身，而是观察智能体是否具备工程协作意识。

它合格的表现应该是：

第 6 步：执行变更并回归测试

确认后让智能体执行：

我确认修改计划。
请执行需求变更，生成 color_terminal_v2.py 或在原文件中清楚标注版本。
完成后运行完整测试：
T1 红色 → STOP
T2 黄色 → CHECK
T3 绿色 → PASS
T4 蓝色 → HELP
T5 无明显颜色 → UNKNOWN
请把测试结果写入 run_log.md，并生成 change_report.md。

change_report.md 应包含：

相关内容见表13-8。

表13-8 项目与内容记录表

项目 内容
变更原因 为什么加入蓝色
修改文件 改了哪些文件
新增规则 蓝色对应什么反馈
回归测试 原有功能是否仍通过
风险 蓝色和其他颜色是否可能混淆

第 7 步：观察智能体完成任务的质量

请用下面表格评价智能体：

相关内容见表13-9。

表13-9 观察项与表现记录表

观察项 表现 评分（1~5）
是否先列计划
是否遵守工作区边界
是否先检查摄像头
是否解释失败原因
需求变更是否最小修改
是否做回归测试
是否记录日志
是否提醒隐私和安全

【思考 3】 如果智能体在需求变更时直接重写整个项目，而不是最小修改，你认为可能带来什么风险？

思考提示：重写整个项目可能破坏原本已经通过测试的功能，也会让问题更难追踪。工程中应优先做最小必要修改，并配合回归测试。

验证与证据：智能体协同记录与需求变更测试

《物理 AI 智能体协同记录表》

相关内容见表13-10。

表13-10 项目与记录内容记录表

项目 记录内容
初始需求提示词
智能体计划摘要
创建文件清单
摄像头探测结果
v1 测试结果
需求变更内容
v2 修改文件
回归测试结果
最终风险说明

《需求变更测试表》

相关内容见表13-11。

表13-11 测试编号与输入记录表

测试编号 输入 v1 预期 v2 预期 v2 实际 是否通过
T1 红色 STOP STOP
T2 黄色 CHECK CHECK
T3 绿色 PASS PASS
T4 蓝色 不支持 HELP
T5 无明显颜色 UNKNOWN UNKNOWN

三个核心指标

相关内容见表13-12。

表13-12 指标与说明记录表

指标 说明
首次跑通率 v1 是否能在摄像头或样例图片模式下成功运行
变更成功率 新需求是否被正确加入
回归通过率 旧功能是否在修改后保持正常

原理小结（200~300 字）

请写一段小结，回答：

伦理、安全与边界

第一条底线：摄像头权限必须可解释

程序访问摄像头前，必须说清楚为什么要访问、访问多久、是否保存画面、是否上传画面。

本章的安全底线可以概括为：

只访问摄像头用于课程色卡识别；
不主动保存摄像头画面，测试前确认画面不含人脸或隐私内容；
不上传图像；
退出程序后停止摄像头；
所有日志只记录识别结果，不记录隐私画面。

第二条底线：智能体不能擅自扩大项目范围

如果智能体提出这些建议，应当拒绝：

扩展功能必须围绕本章目标，不能为了炫技扩大风险。

第三条底线：现实反馈先低风险

本章只允许屏幕文字反馈。可选小灯或蜂鸣器也必须是低电压、低风险、可手动关闭。

不允许接入：

第四条底线：智能体生成的程序也要验收

智能体写出的程序不能因为能跑就算合格。至少要验收：

总结与思考

本章核心判断

  1. 第13章不是单纯看图，而是让本地智能体开发一个能接触现实输入的小工程。
  2. 摄像头识别项目必须先做设备探测，再做识别程序。
  3. 规则模型是适合入门的最小视觉模型，简单、可解释、容易调试。
  4. 需求变更是观察智能体工程能力的重要方式。
  5. 物理 AI 项目必须默认保守：不确定就停，涉及隐私就停，动作风险高就停。

基础题（理解层面）

  1. 本章中的规则模型和视觉大模型有什么区别？
  2. 为什么摄像头探测要放在程序开发之前？
  3. 什么是回归测试？本章中为什么需要它？

迁移题（专业场景）

请把三色卡反馈终端迁移到一个专业场景中，写出：

风险题（伦理与边界）

如果智能体建议把摄像头画面保存下来，方便以后训练更好的模型，你会如何判断这个建议是否允许？请从隐私、授权、必要性、保存期限四个角度回答。

补充题（自测层面）

请判断下列说法是否正确，并说明理由：

  1. 智能体生成的程序能运行，就说明项目合格。
  2. 增加一个新颜色后，只测试新颜色就够了。
  3. 摄像头项目比纯文本项目更需要安全边界。

本章交付物

完成本章后，你应提交以下材料：

  1. 《物理 AI 智能体协同记录表》1 份；
  2. 摄像头探测结果记录 1 份；
  3. v1 三色卡测试表 1 份；
  4. 需求变更说明 1 份；
  5. v2 回归测试表 1 份；
  6. change_report.md 摘要 1 份；
  7. 200~300 字原理小结 1 段。