00/ 一个不报错的错误

一块 STM32 板卡在跑网络时偶发失效。最开始我们几乎没有人工介入，把代码、日志和测试结果持续交给 AI 排查。它不断提出假设，指导刷机、加日志、改配置，但折腾很久始终无法真正收敛，人配合反复烧录和测试都开始疲惫。

问题麻烦的地方在于，它并不稳定地表现出来。网络负载、任务调度、DMA、中断和内存生命周期都在影响故障出现的时机，甚至只是增加几行日志，Bug 就会消失。每一次为了观察问题而做的修改，都可能同时改变问题本身。

后来人工真正介入判断，从这种异常的随机性反推底层内存关系，很快发现发送队列 g_txq 与 lwIP heap 在物理地址上发生了重叠。修改内存地址后，连续测试恢复正常。

代码当然有问题，AI 也完全有能力理解这个问题。真正困难的是，在真实硬件上，代码错误的表现会被负载、时序和运行环境不断扰动，原因与现象之间不再保持稳定对应。

AI 越来越会分析代码，但一旦代码进入真实世界，它面对的就不再只有代码。

01/AI 最擅长的，是一个已经被完全数字化的世界

AI 在纯软件开发上进步这么快，不只是因为模型更聪明，更因为软件世界本身就是为机器准备的：需求、代码、API 文档、编译器报错、日志都是文本，测试结果是结构化信息。

于是 Agent 可以形成完整闭环：写代码→编译→跑测试→读报错→改代码→再跑。测试全绿，它就有理由认为任务完成了。

在传统软件工程里，决定系统正确性的事实，绝大部分本身就能被机器直接读取。所以今天的 Coding Agent 强得反常，并不奇怪——它进入的是一个几乎为它量身定做的环境。

在那个世界里，一切都可以被表达成 Token。而现实不能。

02/ 现实的报错，不长这个样子

Web 服务出错会告诉你：连接失败、参数为空、数组越界、接口 500。

现实设备的 " 报错 " 是这样的：

偶尔断网，连续跑几小时后复位；

实验室一直正常，到客户现场开始出错；

冬天没事，夏天偶发；接上调试器就稳定了；

加一行日志，Bug 消失；

同一份固件，十块板子里只有两块出问题。

原因可能在代码里，也可能在代码之外：电压、温度、时钟、Cache、DMA、中断、EMI、内存布局、芯片批次、总线竞争、PCB 走线，甚至一根几十厘米长的线。

而这些事实中的绝大多数，不会自动进入 AI 的上下文。

它看到了 C 代码，没看到这一刻电源轨上几十微秒的跌落；它看到了 Ethernet Driver，不知道 DMA 正在读一块 Cache 还没回写的内存；它知道某个变量的地址，未必知道链接脚本已经把另一块动态内存盖到了这里。

问题往往不是它不会推理，而是它根本没有看到决定结果的那部分事实。

03/ 瓶颈正在从 Intelligence 转向 Observability

谈 AI 能力时，我们习惯谈参数、推理和上下文长度：模型有多聪明？能不能吃下一个百万行代码库？

这些都重要。但当 AI 走进机器人、汽车、工业控制和医疗设备，另一个问题更要命：它究竟能观察到多少现实？

推理再强，只要关键事实没进入输入，它就只能在一个不完整的世界模型上推理：

有完整工程代码，没有 .map 文件→可能永远发现不了两段内存重叠；

有了 .map，没有运行时 DMA 状态→仍可能误判一次内存异常；

有了寄存器现场，不知道 printf 改变了调度时序→会得出完全颠倒的因果。

所以把上下文从 100 万 Token 扩到 1000 万，并不能解决全部问题。

现实的难点不是上下文太长，而是大量事实从来没有被数字化。

04/ 观察这件事本身，会改变结果

底层工程还有一个更麻烦的地方：观测会扰动被观测对象。

加一行日志改变时序；打一个断点改变中断响应；接上 JTAG 改变运行状态；开 Trace 增加总线压力；把 -O2 换成 -O0，原本存在的 Bug 可能直接消失。

工程师面对的不是一个静止的数学对象——你测量它的时候，它可能因为测量而改变。

现实系统的 Debug，常常不是找出哪一行写错了，而是重建系统在某个时间点究竟发生了什么。

这也是老手那种写不进文档的 " 手感 " 的来源：看到 " 加日志就好了 "，第一反应是时序变了；看到 " 跑几小时才出事 "，会去怀疑泄漏、计数器、热效应或概率性竞态；看到 " 换块板子就正常 "，不会急着认定软件没问题。

所谓经验，本质上是一套关于现实世界的先验模型。它不神秘，只是长期存在于人脑里，而不在机器可读的数据结构里。

05/ 从 "API 返回成功 " 到 " 现实真的发生 "

代码正在被商品化。把想法翻译成代码、熟悉框架、快速写出某个功能——这些能力的稀缺性正被迅速压低。这不意味着工程师贬值，而是价值在重新分布。

当代码越来越便宜，昂贵的部分就转移到了代码无法完整描述的地方。

这个系统为什么会在现实里失败？哪些状态值得相信？哪个传感器可能在说谎？软件认为设备关闭了，它真的关闭了吗？模型认为机械臂停了，它真的停了吗？

纯数字系统里，一次动作通常等于一次 API 调用。现实里不是：机器人可以在软件层正确执行每一步，却因为传感器漂移撞上墙；车可以正确识别控制指令，却因为制动系统状态变化而没有产生预期动作；工业 Agent 可以成功调用 PLC 接口，而设备真实状态早已和数字模型分叉。

发出命令与现实发生，是两件不同的事情。

于是 Physical AI 的核心问题，不再只是 "AI 有没有做出正确决定 "，而是—— AI 所依据的现实，究竟是不是真的现实？

这场竞争很可能不只是模型之间的竞争，还是一场漫长的 " 现实数字化 " 工程：更多传感器、更多 Trace 与 Telemetry、更完整的设备状态、更精确的时间同步、更可信的执行反馈，甚至需要新的硬件与系统架构，让机器能够确认：我以为发生的事情，真的发生了吗？

我们要给 AI 造的不只是更大的大脑，还有眼睛、耳朵、神经和反馈回路。

06/ 新的稀缺性：知道机器没有看见什么

过去，好工程师的标志常常是 " 知道得多 "。往后要再加一条。

好工程师还要知道：系统不知道什么。

它没有观测到什么？它默认了什么？哪些状态只是软件里的推断，而不是现实里的事实？哪些 " 成功 " 只是 API 返回成功，而不是动作真正完成？哪些安全判断依赖的是几秒钟以前的状态？

这项能力很难被归进 " 写代码 "，它更靠近系统工程、控制工程与安全工程的交叉地带。而且 AI Coding 越强，它越重要——当任何人都能批量生产看起来正确率很高的代码时，最危险的事情已经不是 " 代码写不出来 "。

而是一个系统运行得非常顺畅，但它对现实的理解从一开始就是错的。

07/ 机器如何理解现实

这并不意味着 AI 永远进不来。恰恰相反。

未来的工程 Agent 很可能会自动读取芯片手册、链接脚本、Map 文件、寄存器、ETM Trace、逻辑分析仪与示波器数据；自己烧录固件、跑压力测试、比对不同硬件版本，甚至连续跑几百组实验去逼出一个低概率故障。到那时，它在底层工程上的能力一定会大幅提升。

但这恰好说明：下一阶段的核心问题，已经不只是让模型更聪明，而是如何把现实变成它可以观察、理解并验证的东西。

语言模型解决了机器如何理解语言，Coding Agent 正在解决机器如何生产软件，Physical AI 最终必须面对第三个问题：机器如何理解现实。

这一步可能比前两步都难。语言有语法，代码有编译器，测试有 Pass 和 Fail。

而现实没有统一接口，也不会主动返回 Stack Trace。它甚至不会告诉你哪里出了问题，它只会继续发生。

当代码越来越容易被生成，人类工程师真正稀缺的价值，也许正在这里：

看见代码没有写出来的那部分世界。