AI对物联网的两面性：除了正向赋能，也可能形成"技术债务"物联网智库·2026年05月11日 21:55如何避免AI在项目中制造技术债务? 大语言模型为代表的AI新技术在物联网系统研发和实施中的应用，给物联网系统带来前所未有的效率提升，将AIoT推进到新的阶段。不过，AI和物联网的融合，带来正向赋能的同时，也存在一些潜在的风险。近日，一位长期从事工业物联网的专家撰文指出，人工智能工具加速物联网开发，但在接近硬件的层面，一些看似正确的代码可以悄无声息地同时破坏数千台设备，人工智能可能会给物联网形成大量“技术债务”，需高度重视这一现象并提前采取措施。 “技术债务”引发的严重后果 为了说明“技术债务”，作者引用了1996年6月欧洲发射的一款重型运载火箭Ariane 5号发射事件，这款火箭在发射不到40秒后发生爆炸，这一严重后果源于惯性导航系统软件中的规格和设计错误所致，之前Ariane 4号版本的软件模块被重复使用，但未验证其约束是否适合新环境，这成为历史上最昂贵的软件错误之一。 这一事件揭示了什么道理？它可以帮助我们记住一个简单的原理：在复杂系统中，危险的不仅是“糟糕的代码”，还有那些看起来可以接受但与上下文不符的代码。作者提出疑问，目前的AI助手也会出现类似的问题吗？如果答案是肯定的，则产生了潜在的“技术债务”，对未来整体系统造成影响。在这里，“技术债务”是指任何在短期内加快系统开发进程但从长远看会产生更高成本。 作为工业物联网领域的专家，特别是在预测性维护领域有丰富经验，作者看到以下情况：AI工具能快速生成看似适合本地任务的功能代码，但它们并未在整个系统层面验证自身假设。在工业物联网中，这意味着解决方案在单个功能或服务层面可能是正确的，但未能考虑特定硬件、数据流、架构边界或真实设备运行条件的限制。结果，本地正确的代码成为系统性故障和昂贵修复的根源，导致整个平台的失败，或者发展速度变慢。 AI可能给物联网带来的几种“技术债务” 一是重现遗留模式与错误 AI助手根据当前环境中代码的上下文生成建议，并不总能识别更广泛的设计或架构问题。GitHub一篇文章明确指出，Copilot的适用范围有限，依赖于代码的上下文，也可能继承现有代码库的错误和偏见。因此，如果项目已经包含过时的方法、冗余的数据存储或“变通方法”而非合适的架构解决方案，AI助手会将其视为常态并持续复制。从这个意义上说，不良做法不仅被保留，而且使规模更广泛。 这不仅仅是理论上的风险，一项对6000多个真实世界代码库中30多万个经过验证的AI生成提交的研究显示，五个评估的AI工具中，每个提交中都至少有15%存在至少一个代码质量问题，其中四分之一的问题在最终版本代码中仍未修复。 在物联网系统中，这种机制尤其危险，因为遗留模式很少会在单一模块内成为局部问题。如果助手在设备固件代码、网关服务或遥测处理中重现了薄弱的解决方案，它会迅速在整个链条中传播，从设备层到系统云端都会产生影响。 二是没有形成有意识的“快速修复” AI在解决本地工程任务方面非常有效，它可以快速生成测试、编写模板代码。然而，它不一定能够看到整体架构，包括哪些数据库用于哪些数据，有哪些限制，以及组件之间如何相互作用。因此，AI即使不复制遗留模式，也可能产生技术债务。如果架构规则没有明确说明——无论是在文档、决策记录，甚至提示本身——模型会将本地任务作为孤立任务进行优化。 在复杂的工业物联网系统中，可能会产生如下情况：时间序列、参考数据和日志存储在不同的数据库中，每个数据库都针对自身工作负载进行优化，但AI助手在被要求存储新数据时并不知道这种拓扑结构，生成的代码逐渐违反团队建立的架构协议。 三是逻辑重复与维护复杂度增加 AI助手不知道它需要的代码已经存在于系统其他地方，所以它会编写一个新版本，结果是同一逻辑的多个独立实现，当需要更改时，开发者会花时间寻找所有重复的部分。近年来，重复代码的比例不断上升，AI助手工具很可能进一步加速这一趋势。 在物联网系统中，如果同一逻辑，例如数据包解析或连接验证在多个地方独立实现，修复一个副本的漏洞却找不到其他副本，可能导致现场设备在同一输入信号下表现不同。解决此类不一致不仅需要修改代码，还需要同时在数千台设备间同步固件更新。 四是忽略硬件约束 有些物联网设备没有云服务那样无限的资源，网关有特定的内存容量、有限的网络带宽和固定的电池预算。AI助手可以考虑这些限制，但前提是开发者必须明确说明。 如果没有做到这一点，助手会为它主要训练的环境，即云端和服务器端系统生成解决方案，这些系统内存实际上是无限的，网络也稳定。结果是可预见的：无休止的重试循环且无超时，采用“重型”文本数据格式取代紧凑的二进制协议，以及编译正确但未考虑特定板子硬件特性的代码。因此，在模拟器中运行良好的解决方案，在资源有限的物理设备上运行时可能会失败。 如何避免AI在项目中制造技术债务 物联网系统中采用AI工具比没有采用AI工具的开发更需要严格的工程“纪律”，需要时刻保持代码质量控制。 一是强制性人工代码审查。虽然听起来很显而易见，但实际上，在使用AI助手时，人们很容易倾向于接受未经深入分析的生成代码，调研显示超过一半的开发者认为代码通常看起来“正确”，一项针对1100多名开发者的调查中，只有48%的人在提交AI生成代码前会进行审查。人工审查更重要的是要考虑具体硬件环境的约束，逻辑是否重复，以及解决方案是否与系统整体架构相符。不过，人工代码审查存在一个问题，即AI助手会以更快速度增加新代码的数量，使人工审查形成瓶颈。 二是限制项目关键部分AI工具应用。并非所有代码都同样关键，物联网系统开发中值得明确定义自主AI生成的“禁区”，例如处理接收设备数据包、授权逻辑、中断处理和监控模块定时器逻辑，以及直接与固件交互的代码等。作者提出，如果代码中的错误需要现场设备固件更新，或同时破坏所有客户端的数据完整性，那么AI助手应仅在人工监督下来实施，最终决策权必须由理解系统上下文的开发者掌握。 三是定期重构和监控。随着代码生成速度的提升，隐藏问题的积累速度也会加快，定期重构是必需的。作者认为，架构至少每六个月审查一次，同时特别关注AI生成代码可能带来的隐藏问题。同时，在物联网系统中，监控也非常必要，包括追踪设备自身的状态至关重要，如边缘内存消耗、设备与网关之间的延迟以及遥测异常，在这些环境下，AI生成的未被考虑的硬件约束代码往往最先浮现。 当然，“技术债务”早在AI普及之前就广泛存在，只是AI目前最新的发展可能会加速“技术债务”的积累。在物联网系统中，这种加速的成本不仅体现在开发者时间上，还体现在数千个物理设备的可靠性上，因此破坏性更大，需要提前做好应对。 本文来自微信公众号 “物联网智库”（ID：iot101），作者：赵小飞，36氪经授权发布。 该文观点仅代表作者本人，36氪平台仅提供信息存储空间服务。