先直接上链接：human-in-the-loop-device-debugging
AI 写代码很快，但当前的AI它有一个短板：它看不见真实世界。 （所以这里我认为将来的AI发展方向是能捕捉到全模态的信息，包括视觉、听觉、触觉、甚至脑电波，这需要大量的数据和算力来训练）
普通软件 bug 还好，报错、日志、单测、接口返回都能直接喂给 AI。可一旦问题发生在真机、硬件、蓝牙、摄像头、麦克风、扬声器、机器人、传感器这些场景里，事情就变了。
用户说"我听不到声音""设备插上后没反应""机器人动了但方向不对"，这些都是真实现象，但 AI 无法直接确认。它不能替你听声音，也不能替你看设备状态，更不能判断你手机上跑的是不是最新包。
所以我意识到，真机调试不能只靠"AI 分析代码"。它更像一种人机协作：人负责观察真实世界，AI 负责拆解问题、改代码、埋断点、记录过程。
真机调试的核心是闭环 🔁
我把这类问题抽象成一个调试闭环：
text
用户描述现象 -> AI 理解目标 -> 拆解阶段 -> 改代码加观测点
-> 用户真机复测 -> 反馈新现象 -> AI 修正判断这里最重要的不是某一次代码改动，而是每一轮都让问题变得更可观察。
很多时候，用户一开始不会完整描述目标，只会说"真机上不对""插上设备后没效果"。这时 AI 不应该立刻改代码，而是先引导用户补齐几个关键信息：当前场景是什么，最终预期是什么，实际看到或听到什么，这次最想先调通哪一段。
一旦这几个问题说清楚，调试方向会稳定很多。
大目标必须拆开 🧩
真机问题最怕一上来端到端乱改。
一个看似简单的目标，背后可能包含设备连接、权限、原生回调、前端接收、队列缓冲、网络发送、后端处理、UI 展示、声音播放等多个环节。
所以我在 SKILL 里要求：先根据目标和当前代码做阶段拆分。
比如通用顺序可以是：
text
先确认入口和最新代码
再确认设备/权限/连接
再确认原生或系统回调
再确认业务层收到数据
再确认数据发送出去
最后确认 UI、声音或硬件反馈这样每一轮只验证一个主要变量。失败了，也知道该往哪一段继续查。
每个目标都要有目录 📁
为了避免调试过程散掉，我要求所有问题都创建目标目录，即使只有一个阶段。
结构大概是：
text
scenarios/某个调试目标/
├── goal.md
├── 01-第一阶段.md
├── 02-第二阶段.md
└── 03-稳定性验证.mdgoal.md 记录大目标、成功标准、代码链路理解和阶段拆分。每个阶段文件记录当前问题、测试版本、用户反馈、阶段结论和下一步。
这样做的好处是，新开一个 AI 会话也能接着查，不用重新讲历史。更重要的是，它能避免一个常见问题：调着调着忘了当初为什么这么改。
真机测试必须能确认版本 🏷️
真机调试里最容易踩的坑，是你以为自己在测新代码，其实手机上还是旧包。
所以每次改动后，我都会要求 AI 给出明显测试版标识，比如：
text
测试版 20260603-音频回调诊断这个标识要出现在用户能看到的地方：页面横幅、诊断页、toast、控制台日志都可以。
同时，这个标识也要写进 commit：
text
checkpoint: 测试版 20260603-音频回调诊断这样后面如果要回退，就不用靠记忆找版本。
把"看不见"变成"可观察" 🔍
AI 看不到真机现象，那就主动制造观测点。
比如一条设备数据链路，可以加出这样的断点：
text
设备是否连接
原生回调是否触发
业务层是否收到数据
数据是否进入队列
数据是否发出
服务端是否收到
UI 或硬件输出是否生效用户下一轮反馈就不再只是"还是不行"，而是能变成"设备连接了，但没有回调"或者"前端发出了，但后端没收到"。
这类反馈的价值高很多。
什么时候该用这套 SKILL？⚡
判断标准很简单：关键现象是否必须由用户在真实设备或物理环境里观察？
如果是，比如真机、硬件、机器人、蓝牙、音频、摄像头、传感器、第三方 App、系统权限，就适合用。
如果只是单测失败、构建报错、接口异常、纯后端 bug、浏览器里能复现的页面问题，那就没必要。
总结 ✨
AI 面对真机调试不是没用，而是不能用普通软件调试的方式去用它。
它确实不能替我听声音、看设备、判断现场状态。但它可以帮我做另一件很重要的事：把用户的现场反馈变成一个稳定的工程闭环。
人负责观察真实世界，AI 负责拆目标、埋断点、改代码、做版本标识、写记录、提交 checkpoint，并根据用户反馈持续收敛。
这套 SKILL 的核心思想就是：
text
当 AI 无法直接观察现象时，
就把真实世界的反馈结构化，
让调试变得可验证、可记录、可回滚。这不是让 AI 变得无所不能，而是让它在自己的能力边界内，把真机调试推进得更稳。