夜雨聆风今天读到一篇关于 Andrej Karpathy 的文章，讲他提出的「软件 3.0」编程范式。
其中一个小例子，让我久久回味。
📷 一款扫描菜单的小工具
餐厅菜单上往往只有菜名，没有配图。食客点菜时，根本不知道这道菜长什么样。
Karpathy 做了一个工具来解决这个问题：根据菜名，自动生成对应菜肴的实物图片。
如果用传统思路（软件 2.0）来做，大概是这样：
① 拍摄菜单图片
② OCR 提取菜品名称
③ 调用 AI 生成图片初稿
④ 润色优化，返回结果
四个步骤，每一步都是独立的工程模块。
而软件 3.0 的做法呢？
① 拍摄菜单图片
② 直接告诉大模型：帮我生成这些菜的图片
③ 返回结果
中间所有环节，全部消失了。
💡 这个对比让我想到了自己的工作
我平时要处理客户提供的 TBOX 数据上传协议——一份描述 CAN 信号格式的表格文件。
问题是：由于历史原因，早期和后期的协议格式不一致，甚至存在错漏和不规范之处。我需要把它们统一整理，转换成标准的 DBC 文件，还要顺带把中文信号描述翻译成英文（DBC 不支持中文）。
我原本的思路是：开发一套通用脚本，自动适配各种协议格式。
但这套方案有个致命弱点——
只要客户的协议出现一种新的不规范写法，脚本就会失效。
然后我就得去调代码，覆盖新的边缘情况。
周而复始。
🔄 换一种思路之后
现在我换了个角度来想这件事：
与其维护一套复杂的通用脚本，不如把协议的差异直接截图或整理好，喂给 AI，同时说明目标格式要求，让 AI 直接完成理解和转换。
面对新的格式变化时，我不需要改代码——只需要重新描述差异就行了。
这正是软件 3.0 范式真正打动我的地方：
它把对「变化」的处理能力，从程序员转移给了大模型。
以前，应对变化 = 修改程序。
现在，应对变化 = 重新描述问题。
这种转变，不只是效率的提升，更是一种思维方式的切换。
很多工具根本不需要做成通用的、工程化的产品。它可以只是为了解决某个偶发性的需求而存在——核心能力全部交给大模型，开发者只需要做好"连接"。
软件 3.0，正在悄悄改变我们定义「一个好工具」的方式。
参考文章：宝玉 AI 公众号，关于 Andrej Karpathy 软件 3.0 的解读
