本文来自微信公众号： HavenlonLabs ，作者：Havenlon Labs
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。它甚至不会告诉你哪里出了问题，它只会继续发生。
当代码越来越容易被生成，人类工程师真正稀缺的价值，也许正在这里：
看见代码没有写出来的那部分世界。