让 AI 写代码这件事，为什么到硬件就不行了

今年 2、3 月份，我开始密集使用 Claude Code。第一次让它直接生成一个完整项目的代码文件、目录结构和 README 文档，又让它读取我的代码仓库、分析现有逻辑、制订修改计划并直接执行，整个过程流畅得有点不真实。那段时间有一种很强的感觉：这套工具几乎可以用在所有研发场景里。

就在差不多同一时间，我听说一位做硬件的创业朋友那边，团队试用了一段时间 AI 写代码的工具，最后放弃了，还是回到人工写代码。当时我的第一反应是：他们用法不对吧？可能用的是效果较差的国内模型，或者没有选对工具。

上个月和这位朋友吃饭，同桌还有一位大厂程序员，才把这个疑惑真正解开了。

软件侧：真实发生的范式转变

先说软件这侧，因为只有感受到这边的变化，才能理解硬件那边的反差有多大。

同桌的大厂程序员说，2026 年他没有亲自写过一行代码，现在 agent 一天的工作量，大概相当于他以前一周。他自己的工作重心也变了：以前是写代码，现在更多是做架构设计、给 agent 分配任务、审查输出结果。

这不是个例。Claude Code 的创建者 Boris Cherny 在接受 Fortune 采访时表示，他个人已经有两个多月没有手动编写过任何代码，100% 由 Claude Code 生成，单日最多提交过 27 个 PR，每一行都是 AI 写的。Anthropic 公司整体的 AI 代码生成比例在 70%–90% 之间（官方声称，未经独立验证）。他在 Lenny's Podcast 上也提到，自 2025 年 11 月起，他就再没有手动修改过一行生产代码。

为什么会发生这种转变？根本原因在于，Claude Code 这类工具在软件世界里能形成一个完整的数字闭环：读取代码仓库 → 理解上下文 → 制订计划 → 写代码 → 执行 → 读取报错 → 修改 → 再执行。

这个循环能跑起来，依赖一个前提：反馈是即时的、可读的、数字化的。写完一段代码，几秒内知道有没有报错；测试跑完，日志直接打出来；出了 bug，错误信息是文字，AI 可以直接读取并分析。整个过程不需要离开数字世界一步。整个流程的每一步，AI 都能独立完成，人只需要在关键节点做判断。

硬件开发的反馈回路

硬件开发，尤其是嵌入式系统、固件、驱动这类方向，表面上也是"写代码"，但反馈回路从根本上就不一样。

代码写完，要烧录到芯片上才能运行。出了问题，报错不是一行文字，可能是某个引脚没有预期电平，或者系统直接挂死，或者某个传感器读数异常。要定位问题，需要逻辑分析仪、示波器、串口调试，有时候问题根本不在代码里，在电源噪声、时序偏差，或者硬件本身的制造差异。学术研究对此有明确描述：嵌入式系统中，代码编译成功并不等于运行正确，部署到真实硬件后可能因为时序违规、外设配置错误或硬件特定的边缘情况而失败，而这些行为错误无法通过纯数字化的仿真环境完全捕获。

本质差异：确定性 vs 概率性

但这还不是最根本的问题。反馈慢只是表象，更深的问题是：硬件的反馈不可复现。

在软件世界里，相同的输入必然产生相同的输出。这个确定性，是 AI agent 能够迭代的基础。改一行代码，跑一下，报错，再改，这个循环能工作，是因为"跑一下"本身是可靠的、可重复的。AI 在这里扮演的角色是：观察结果 → 判断原因 → 修改代码 → 再观察，整个链条在数字世界里是自洽的。

硬件打破了这个前提。传感器会老化，温湿度会影响读数，接触电阻会漂移，同样的代码在不同环境、不同时间点、不同硬件个体上，可能跑出完全不同的结果。AI agent 面对这种情况，会陷入一个无法解开的困境：这次失败，是代码逻辑写错了，还是传感器今天状态不对？这两种原因对应完全不同的处理方式，但 AI 没有能力区分。

用一句话概括这个本质差异：软件是确定性系统，硬件是概率性环境。软件里的不确定性（网络超时、并发竞争）影响的是"能不能执行"，硬件的不确定性影响的是"执行结果对不对"。前者 AI 可以处理（重试、换策略），后者会污染 AI 的判断层，让推理链条从根本上断掉。

正如业内文章所描述的：大模型理解的是语法，不是语义；它看到的是文本中的规律，不是微控制器里的信号。

数字孪生能绕过这个问题吗

一个自然的反驳是：如果把物理世界数字化，用数字孪生或仿真环境来模拟硬件行为，是不是就能让 AI 重新介入？

方向上是对的，但目前绕不过去，原因有两层。

第一层是技术层面。学术界把仿真环境和真实硬件之间的偏差专门命名为"reality gap"（现实鸿沟），指出数字孪生的准确性会随着物理系统的老化、传感器漂移、跨域交互等因素持续偏离现实，这个问题目前仍然是开放性挑战。仿真模型本质上是对物理世界的简化，这个简化和真实世界之间的 gap，不会随着模型变强自动消失。

第二层是工程层面。把一个真实商业生产环境完整数字化，本身就是一个巨大的工程，而且即便数字化完成，训练时用的仿真环境和实际部署时的物理环境，也很难做到完全匹配。环境变量太多了，温度、湿度、硬件个体差异、长期老化，要让这些保持一致不现实。

这个方向上目前有真实的进展。NVIDIA Isaac Sim、Real2Sim 等技术正在试图缩小仿真和现实之间的 gap，机器人领域把"sim-to-real 问题"列为核心攻坚方向之一。但从研究突破到真实商业生产环境的大规模落地，中间的距离还很长。

有效边界，而不是全局失效

说 AI 写代码在硬件开发里效果有限，不等于对硬件公司整体没用。这个边界值得说清楚。

我那位做硬件的创业朋友，在核心硬件研发上确实没有引入 AI 写代码的流程，但他们最新的官网，交互 demo 是产品和业务人员自己用 AI 工具做的，不需要依赖开发团队。这个场景之所以能成立，是因为官网开发本质上还是软件，反馈回路是数字闭合的。

所以更准确的判断是：AI 写代码的有效性，取决于反馈回路能不能在数字世界里闭合，而不取决于公司是做软件还是做硬件。硬件公司里的软件层（官网、小程序、后台系统）同样受益，只是硬件研发本身这条线，目前还走不通。

这道沟，现在是本质性的

我的判断是：这道沟目前是本质性的，但不是永久的。

说本质性，是因为它不是工具不够强、使用姿势不对这类可以快速迭代解决的问题，而是物理世界的不确定性和数字化验证之间存在的结构性缺口。AI agent 要在硬件开发里真正起作用，需要的不只是更强的模型，而是整套物理-数字交互基础设施的成熟——传感器精度、实时数字孪生、sim-to-real 的可靠迁移。这些条件目前都不具备。

说不是永久，是因为具身智能这个方向，本质上就是在试图解决这个问题：让 AI 能够感知物理世界、在物理世界里验证行为、并从物理反馈中学习。这个方向上的投入是真实的，进展也是真实的，只是时间表目前还不清晰。

我自己经历的那次认知转变，从"他们用法不对"到真正理解这道沟在哪里，回头看是一个很典型的误判路径：在软件世界里体感极强的工具，很容易让人以为它可以无边界地迁移。但工具的有效边界，最终由它所依赖的前提条件决定。软件给了 AI 一个可以闭合的数字回路，硬件目前没有。

这个判断我自己没有硬件开发的一线经验，如果有工程师觉得哪里不准，欢迎来指正。