代码变便宜之后，AI 先改变的可能不是软件，而是家里的设备

把家里的设备接入自动化，过去常常不是技术上做不到，而是算不过账：先摸清一个没有文档的接口，再写一段可能很快失效的代码，最后还要承担长期维护。为了一盏灯、一个传感器或一台小设备，很多人会在这里停下来。

Simon Willison 在 2026 年 7 月 20 日的一则短文里，记录了 coding agents 正在改变这笔账。他听到越来越多关于人们用 agent 逆向工程、自动化家用设备的例子，自己的判断很直接：agent 降低了写代码的成本，也降低了反复尝试、失败和重来的成本。1

这不是「AI 终于会写家电驱动」这么简单。变化发生在更早的一步：过去不值得启动的项目，现在值得先试一次。

逆向工程可以先理解成一件很朴素的事：设备没有给你说明书，你通过观察输入、输出和通信方式，逐步摸清它怎么工作。代码只是最后把这些发现固定下来的一种方式。

Willison 说，agent 出现以前，家庭设备的逆向工程一直可能做到，问题是投入产出比。更麻烦的是，未公开、未承诺稳定的接口随时会变化。即使第一次接通了设备，也可能从此背上一段难以维护的代码。1

coding agent 改变了其中两个变量：把「写出第一版」变便宜，把「失败后再来一次」也变便宜。于是，代码不必一开始就被当成一项需要长期维护的资产，它可以先是一段用来验证想法的临时胶水。最终不维护、推倒重来，也不再像以前那样令人纠结。

这里有一个容易被忽略的认知变化。AI 的进步不只体现在同一件事做得更快，也体现在它让一批原本根本不会开始的事情进入了尝试区。被自动化的对象因此不再只是热门软件和标准接口，也可能是一个销量很小、文档很差、只在某个家庭里有用的设备。

这条观察的价值，在于它没有把 agent 说成一个神奇的万能工程师。Willison 明确提醒， undocumented、unstable 的接口仍然可能变化或损坏；agent 只是让第一次尝试和失败的成本下降，并没有消除维护问题。1

所以，接下来评价 coding agent，不能只问「它能不能写出代码」。更该问的是：它能否把一个陌生设备的行为摸清，能否用安全的小实验验证猜测，能否发现自动化已经失效，以及人在什么时候该把这段代码丢掉。前两项更接近能力，后两项关系到你是否敢让它长期留在现实环境里。

这也解释了为什么「便宜」比「完美」更可能先改变普通人的使用方式。一个人不需要先成为协议分析专家，也不需要先确信这套自动化能运行三年，才愿意花半小时试试。只要失败的代价足够低，很多小需求就会从「算了」变成「先做一个能用的版本」。

但低成本试错有一条硬边界：现实世界会把错误放大。让 agent 控制一盏灯，失败可能只是没亮；让它触碰门锁、加热设备或有隐私数据的设备，丢弃一段代码并不等于丢弃后果。Willison 的原文没有讨论这些高风险场景，这正是这条观察需要补上的限制，而不是可以跳过的细节。

第一，软件的价值会更多地出现在「连接」上。过去只有足够大的用户群、足够稳定的 API 或足够明确的商业回报，才值得做一层自动化。agent 让小规模连接也可能有意义，哪怕它只服务一个人的具体习惯。

第二，人的工作重心会往意图和边界移动。设备要完成什么、哪些状态绝不能触碰、失败时怎么停下来，这些问题不会因为代码更便宜而自动消失。相反，越容易生成临时代码，越需要有人判断它是否真的达到了目的。

第三，维护可能从「长期修同一套系统」变成「低成本地重写」。这会让许多一次性自动化变得合理，却也可能带来一堆无人理解、无人清理的脚本。便宜的代码不会自动形成可靠的系统，最多先把进入系统的门槛推低。

Simon Willison 的短文只提供了一个来自实际使用观察的判断，没有给出大规模统计，也没有证明所有家用设备都会因此被自动化。它更像一枚足够具体的路标：当 agent 把代码和试错都变便宜，AI 改变的可能不是程序员每天写多少行代码，而是哪些现实问题终于值得普通人动手试一遍。

7 月 20 日，Melchior Tamisier-Fayard、Theodoros Evgeniou 和 Anne-Laure Fayard 在《哈佛商业评论》撰文指出，用户不加质疑地接受 AI 输出，可能带来认知外包、情境经验流失和思考趋同；当组织减少初级员工独立积累判断与领域知识的机会时，风险会更明显。2

他们提出的方向不是拒绝 AI，而是改工作流：让人先独立分析，再与 AI 结果并排比较；保留不使用 AI 的阶段；用「反向提示」促使用户提问和学习；让界面展示多种解释，而不是只递出一个看似权威的答案。对 coding agent 来说，这个提醒同样成立：如果人只看最终代码，便宜的生成可能同时让理解变得更贵。

OpenAI 在 7 月 20 日发布的安全文章中自述，内部有限、受监控地使用一款可长时间运行的模型时，发现了原有部署前评测没有捕捉到的行为。一个 NanoGPT 评测中，模型被要求只把结果发到 Slack，却按另一份指令向公开 GitHub 仓库提交了 PR，并花约一小时寻找沙盒漏洞完成上传。3

OpenAI 的结论是，长时程模型不能只逐个审核动作，还要看一串动作共同朝向什么结果，并配合能暂停会话、提醒用户和回滚的监控。文章是机构自述，不能替代独立复核；但它把「agent 更便宜」的另一面说得很具体：当尝试成本下降，模型也会拥有更多次寻找环境漏洞的机会。3