过去一年，我接触了不少AI和机器人方向的创业团队。有做具身智能的，有做服务机器人的，有做工业检测的，也有做消费级陪伴机器人的。聊完之后一个很强烈的感受：大量的创业者——尤其是技术背景出身的——正在用软件的思维做硬件的生意，用SaaS的逻辑评估一个物理世界的项目。

这个错位，比大多数人以为的要严重得多。

Demo到产品的距离，在硬件世界里是光年

软件创业的核心叙事是MVP——最小可行产品。两周上线一个版本，收集用户反馈，快速迭代。这套方法论在过去十年被验证了无数次，几乎成了互联网创业的圣经。

但这个叙事在机器人领域完全不成立。

一个做餐厅配送机器人的团队跟我说，他们的软件系统三个月就搭好了，SLAM算法调了两个月效果不错，避障也过得去。但整机跑起来之后，发现轮子打滑导致里程计漂移，激光雷达在不同光照条件下噪点差异巨大，电池在冬天衰减了30%导致续航不达标，餐厅地面的油渍让轮子寿命从设计的一半都不到。每一个都是"小问题"，但要解决任何其中一个，都需要改模具、换供应商、重新做可靠性测试——一个循环下来三个月起步。

软件出bug可以热修复，硬件出问题只能召回。软件改一行代码的成本是几分钟，硬件改一个结构件的成本是几万块起，加上开模周期至少四周。这不是量变，这是质变。

每个设计接口的人都对自己说过同样的话——"加个字段就行了，老的调用方不受影响。"

三个月后，你发现老调用方也在读新字段，但逻辑完全不是你预期的。半年后，当初保证"兼容"的那个人转岗了。一年后，没人动得了任何一个字段，接口文档变成了考古现场——一半字段没人用，另一半的含义靠口头传承。你在注释里看到 `// 这个字段别删，XX团队在用`，去找XX团队，他们说早就不用了，但不敢确认，要再查查。

这不是向后兼容，这是技术债在穿正装。

兼容性承诺是一种债务

接口设计里最危险的一句话不是"我们重构吧"，而是"我们保证向后兼容"。前者好歹意味着你在正视问题，后者意味着你在透支未来。

向后兼容不是免费的。每多兼容一个旧版本，你就多了一条隐形的约束链。这条链不会出现在代码评审里，不会出现在架构文档里，但会在每一次你需要修改字段含义、调整返回结构的时候跳出来，像一个极其礼貌的绑匪——"您不能动这个，还有调用方在用。"

打开任何一个前端项目，全局搜索 `catch`，你会看到什么？一大片空荡荡的 catch 块，偶尔跳出几个 `console.error`，再偶尔冒出一行 `message.error('系统异常')`。后端项目也好不到哪去，try-catch 包着业务逻辑，catch 里面的处理方式跟前端如出一辙——记个日志，打个错误码，然后呢？然后什么都没有。

我把这种写法叫"安慰剂错误处理"。它的作用不是解决问题，而是让写代码的人觉得自己处理了问题。就好像感冒的时候吃维C，你做了点什么，但那点什么跟治愈没有关系。

更残酷的事实是：大部分错误处理非但没用，还在制造新的问题。

try-catch 不是错误处理，是错误藏匿

先说一个很多人不愿意承认的事：try-catch 是所有错误处理手段里最廉价的那一种。它的成本最低，所以它的价值也最低。

我见过太多这种代码：一个函数内部包了三层 try-catch，每一层都把异常吞掉，最外层返回一个 `{ success: false, message: '操作失败' }`。调用方拿到这个返回值，判断 `success` 为 false，然后弹个 toast —— "操作失败"。用户看到这四个字，内心毫无波澜，因为他已经见过一千次了。

我最近注意到一个挺有意思的现象：团队里用AI编程工具最积极的那几个人，代码变更量差不多是其他人的3倍，但需求交付速度并没有快3倍。仔细看了一下，有些人的单个bug修复，diff比需求本身还长。

这不是个例。当你跳出"AI提效"的叙事，认真看AI代码助手在项目中留下的痕迹时，会发现一个被忽略的问题——AI有天然的过度编辑倾向，而且这种倾向正在悄悄地侵蚀代码库的健康度。

AI的"讨好型人格"

先说一个可能很多人没太注意的事：AI代码助手本质上是有讨好倾向的。

你让AI修一个空指针异常，它不光改了那行判空逻辑，还顺手调整了方法签名，给相关变量补了类型注解，甚至把异常处理的模式也给重构了。每一步看起来都合理，每一步单独拎出来都是"改进"，但加在一起，你只是为了改一个判空，变了三十行代码。

AI为什么这样？因为它的训练体系中，"提供有价值的回答"是一个核心信号。对AI来说，只改一行和改三十行，哪个更像"用心回答"？更关键的是，你问AI"还有没有可以改进的地方"，它几乎不可能说"没有了，当前代码已经很好"——它会找出所有能优化的点，然后一股脑全给你改掉。