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

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

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

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

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

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

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

凌晨两点，线上出了一个支付失败的问题。你登录日志平台，输入订单号，回车。三千条日志滚动出来。你加上时间过滤，缩小到五百条。再加 ERROR 级别，剩三十条。你一条一条看——全是超时告警，没有一条告诉你为什么超时。

你把级别放宽到 WARN，三百条。大多是重试成功的记录，看起来没啥用。你换了个关键词搜，又出来几百条。折腾了一个小时，你发现关键信息藏在一个 INFO 级别的日志里，存的是上游服务的返回值，但打印的时候没用 JSON 格式，正则匹配不到。

最后你靠着回忆和猜，定了位。第二天写故障报告，复盘建议第一条写着："增加更多日志。"

这个场景大概不需要太多解释，每个值过班的工程师都经历过。但真正值得思考的不是"日志不够"这个表面结论，而是更深的问题：你有成千上万条日志，为什么还需要靠猜？如果日志真的有用，为什么越紧急的时刻，日志越帮不上忙？

日志的安全感是假的

很多团队对日志有一种近乎宗教性的信任——出了问题看日志，没问题也要看日志确认一下。代码评审的时候，一句"这里加个日志吧"几乎不会被拒绝，因为加日志没有成本，看起来还体现了严谨。

但日志给你的安全感是虚假的。

前端开发有一个有趣的规律：每隔两三年，社区就会宣布一个新的状态管理"最佳实践"。Redux曾是不可撼动的标准，然后MobX说响应式才是正道，Dva试图让Redux更人性化，Zustand说状态管理不该这么啰嗦，Jotai说应该是原子化的，现在Signal又告诉你要从原语层面重新思考这个问题。每一次更迭都伴随着"旧方案已死"的宣言，和一波迁移重构。

但有一个问题始终没人回答：如果每个新方案都比上一个好，为什么我们还是不满意？

经历过Redux到Dva再到Zustand的完整迁移，我发现每一次换库的时候，团队都觉得这次终于对了。每一次，半年后又会发现新的别扭。这种循环让人不得不怀疑——问题可能根本不在库里。

Redux的铁律和代价

Redux的核心思想并不复杂：单一数据源，纯函数更新，不可变数据。这三条铁律在2016年前后确实解决了一个真实痛点——复杂应用中状态变化的不可预测性。组件树里的状态到处飞，回调层层传递，谁能改、谁不能改、改了之后谁是新的，没人说得清。Redux用一套严格的规则堵住了这个口子。

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

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

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

兼容性承诺是一种债务

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

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