先说个我差点栽跟头的事
上个月我改一个小服务的接口，让 AI 帮我顺手重构了一下返回结构。它干得挺利索，代码看着也漂亮，我扫了两眼就合并发布了。
结果第二天前端同学问我，那个 `user_id` 字段怎么没了。我一看傻眼，AI 把它改成了 `userId`，还顺带把 `status` 从字符串变成了整型枚举。
逻辑一行没写错，测试也全绿，就这么把调用方给干崩了。
那一刻我特别理解社区里那条帖子的焦虑：AI 写的代码越来越多、越来越快，审是真审不过来的，就怕它顺手引入破坏性变更导致故障。发帖的人还问，大家会不会上 oasdiff 这种 API 兼容性检查工具、会不会引入 API 规范 linter，说自己组里啥也没有，感觉有点草台班子。
我看完就想笑，因为我也是草台班子。大团队那套 CI 里挂 linter、挂 oasdiff、卡门禁的流程，对我一个人做产品来说太重了。
但栽过一次跟头之后我明白一件事：这个问题不解决，AI 提效带来的时间，迟早要在排障上还回去。
一个反常识的判断：崩的往往不是逻辑
先抛个我踩坑之后总结的观点，你可能不爱听但我觉得是真的——**真正让线上崩的，很少是 AI 把业务逻辑写错了**。逻辑错了，你测一下大概率能发现，报错也直白。
真正阴的是那种"看起来无害"的改动。字段改个名、类型从字符串变数字、原来可选的参数突然变必填、枚举值悄悄少了一个。
这些改动在你自己的代码里跑得好好的，测试也过，因为测试用的就是新代码。但你的调用方还按老约定发请求、解老结构，啪一下就断了。
AI 特别容易犯这类错，因为它在"让代码更规范"这件事上太积极了。你让它重构，它就真给你重构得"更好"——命名更统一、类型更严谨——完全不知道这个字段有几十个外部调用方正指着它吃饭。
所以我要防的不是 bug，是"契约"被单方面改了。接口就是一份合同，AI 不知道合同不能随便改，那我就得有个东西在发布前替我盯着这份合同。
独立开发者版的自查：自己动手写一个
我没上 oasdiff，原因很简单，我的接口定义也不一定严格是标准 OpenAPI，有些就是我自己约定的 JSON schema。与其套一个重工具，不如自己写个几十行的小脚本，把我真正关心的那几类破坏性变更抓出来就够了。
思路我拆成三步。
第一步，解析并对比新旧两版接口定义。核心就是把两版接口都读成结构化的字段树，然后逐个对比。
我重点盯四类信号：字段被删了、字段类型变了、原来非必填的变成必填了、枚举/可选值集合缩小了。这四类基本覆盖了会打爆调用方的绝大多数情况。
这种纯逻辑的解析和 diff，用 Python 写最顺手，写完直接丢到Python在线运行里跑，拿两版真实接口喂进去，看它标出来的东西对不对，边跑边调，不用在本地搭环境。
第二步，把每一版的接口快照存起来做历史对比。这一步是我后来才想明白的关键。
光对比"这次改动"不够，我想知道的是"这个接口从上线到现在，一共被动过几次、每次动了啥"。所以我给每个接口版本都存一份快照进数据库，一张表记版本号、时间、字段结构的序列化内容。
发布前脚本自动拉出上一版快照，跟当前版本 diff。存这种结构化历史数据，SQLite 刚好够用，不用为这点数据专门起个数据库服务。
调试的时候我直接用SQLite编辑器打开表看字段结构，哪一版改了什么一目了然，比翻 git log 猜测直观多了。
第三步，把它固化成一个随手能跑的东西。脚本调通之后我不想每次都手动执行，就把它做成一个自查工具，发布流程里跑一遍，有破坏性改动就红着脸提醒我，让我确认这是不是我有意为之。
做成常驻可调用的在线工具之后，我每次准备发版就点一下，几秒钟出结果，心里踏实很多。
哪些脚本能揪，哪些它真管不了
这部分我必须说清楚，不然你会对脚本产生一种虚假的安全感，那比没有脚本更危险。
脚本能可靠揪出来的，都是**结构层面**的变更：字段增删、类型变化、必填项变化、枚举值缩减。这些是纯粹的形状对比，机器判断又快又准，几乎不会漏。
这一层交给脚本，你就能把审代码的精力省下来。
但有一类脚本**根本判断不了**，就是**语义层面**的兼容性。举几个例子你就懂：字段名没变、类型没变，但这个字段的含义变了——原来 `amount` 是分，现在 AI 改成了以元为单位；或者原来 `status=1` 表示成功，现在 `1` 表示待处理。
字段的形状一模一样，结构 diff 完全看不出问题，但调用方拿到的数据意思全反了，这种是最要命的。
还有分页语义变了、排序默认值变了、时间字段时区变了这类，脚本都抓不住。这些必须人来看，而且得是知道业务上下文的人来看。
所以我现在的心态是：**脚本负责把 80% 机械的、我肉眼容易漏的结构变更全清掉，让我能把有限的注意力集中在那 20% 语义层面的判断上**。它不是替我审代码，是帮我筛掉噪音，让人审的部分变少、变准。
别指望一个脚本解决所有问题，那是另一种草台班子。
为什么这事对独立开发者尤其值
社区里还有一拨帖子在聊程序员的赚钱焦虑，说会写代码不等于能赚钱，真正要积累的是产品、客户和把技术变现的能力。我挺认同的。
而当你真的自己做产品、自己维护对外接口时，接口的稳定性直接就是你的口碑。
大公司崩一次有一堆人兜底，你一个人做的产品，接口一崩、调用方一投诉，信任就掉一截。你又没有大团队那套流程护着，全靠自己不出错——但 AI 帮你写得越多，你越不可能行行都审到。
这个缺口，只能用一点点自动化补上。
这套东西的好处是它长在你自己手里。脚本是你写的，快照是你存的，规则是你定的，哪天接口定义格式变了你随时能改。
不依赖某个第三方工具的口味，也不用为这点需求上一整套 CI。
今天就能干的一件小事
别想着一步到位做个完美工具。你现在就可以把当前项目最核心的那个对外接口，手动导出一份字段结构，存成第一份快照。
就这一步。
下次你让 AI 改这个接口、准备发布之前，再导一份新的，用几十行 Python 对比一下字段增删和类型变化。哪怕先手动跑，你也大概率会发现一两处"咦我没想动它啊"的改动。
发现的那一刻，你就明白这事为什么值得做了。