这个笑话成立，是因为它根本不只是笑话
在中文语境里，它更常被直接叫做「陨石开发」；这个说法本来就带着日文工程圈里 Meteo Fall 的梗味。终点先宣布，站点中途再改，预算默认你会想办法吞下，而工程团队需要在列车已经“快要发车”时继续铺轨。
这个工作流之所以做成梗会好笑，是因为现实团队里它真的一直在发生。
创始人先签下一单，再反过来承诺一个连边界条件都还没想清楚的 feature。产品团队在 design 已经往前走之后，又把 onboarding flow 重画一遍。领导层觉得 AI 已经把上一屏做得这么便宜了，那再加“一个 integration”应该也不难。路线一直在变，期限却完全不动。
坏消息是，没有任何架构模式能阻止人类提出不现实的预期。
好消息是，不现实的预期已经不必再自动演变成工程停摆。
真正的痛点从来不只是预期不现实
糟糕的规划当然烦人。它浪费时间，制造压力，也逼着团队反复谈判。但它本身还不是最致命的部分。
真正会拖垮交付的，是每一次晚到的产品变更都会立刻变成一次全系统风险。
这正是快速 AI-generated codebase 最经典的 failure mode。Version one 上线太快，于是所有人都会开始相信后面的每次变更也应该一样快。然后现实来了：
- auth provider 需要更换
- analytics 必须变成 optional
- 某条 deep link path 是错的
- 一个 styling 决策扩散到了 40 个 screen
- 一个“很小”的 feature 穿过了三个原本无关的 module
这时候团队面对的就不只是不现实的预期了。他们还得面对一个 无法局部吸收变化 的 codebase。
这就是双重税负。组织层面的问题已经够难了，技术层面的问题只会把事情再放大一遍。
陨石开发最先压垮的是脆弱的代码库
这也是为什么这个梗会精准击中工程师。
我们都看过同一种模式：
- 路线在地图还没成形前就先被宣布。
- 实现已经开始后，范围还在继续膨胀。
- 幻灯片上的期限完全不变。
- 工程团队被要求“先适应再说”。
如果系统的 boundaries 很弱，那么所谓“适应”通常真正意味着：
- 逆向理解那些根本没人设计过的 AI-generated abstraction
- 拆开彼此直接伸手进内部实现的 module
- 修复那些本来没想碰却被连带打坏的部分
- 花一整周去保留一个本来就不该保留的实现
到这一步，团队已经不是在 build product 了，而是在期限压力下做考古。
这一部分，我们已经没必要再接受。
Autotomy 改变的是失败方式
Autotomy 不会让幻想式预估 magically 变得现实。它做的是一件更有用的事：让系统保持可替换。
核心想法很简单。当某个 module 错了、晚了、或者已经不再匹配现在的路线时，你应该可以 把它切掉、换掉，然后继续往前走。
这要求几件不能谈判的东西：
- 给 auth、analytics、storage、notifications 这类易变服务加上 interface
- 用一个 composition root 决定 app 实际使用哪套 implementation
- 用 dependency boundaries 阻止 screen 直接 import vendor details
- 用 contract tests 和 deterministic checks 验证模块替换后的行为
- 用 dependency tiers 防止 optional tools 像 launch-critical infrastructure 一样运行
这些东西一旦到位，不断移动的目标依旧烦人，但它已经不再是生死问题。
provider 变更会变成 interface 背后的一次 replacement。产品绕路会变成局部重写，而不是系统级 refactor。一个糟糕的 AI-generated module 会变成你可以直接删除的东西，而不是你必须小心保留的东西。
当路线变化时，开发仍然可以继续
这才是最重要的实际转变。
没有 Autotomy 的时候，陨石开发听起来通常像这样：
“我们又改了 onboarding 方案，所以现在得去动 auth、profile state、analytics、styling 和 navigation。先给我们一周时间看看会坏掉什么。”
有了 Autotomy，它更像这样：
“预期依然不现实，但这次变化是局部的。我们需要重新谈范围或日期，而不是重建整个 app。”
这是好得多的一种失败模式。
你仍然可能要对交付承诺提出反对。你仍然可能得把 launch 拆开、从路线里砍掉一站，或者对临时加出来的支线说不。但工程组织不需要再双倍受苦了。人的问题还是人的问题，软件问题则保持在可管理范围内。
AI 速度让这件事更重要，不是更不重要
AI coding 正是陨石开发现在更常出现的原因之一。
当 Cursor 或 Claude Code 能在几小时内生成一个 feature 的 first version 时，领导层就会开始默认后续每轮迭代也应该像第一稿一样快。他们看到的是表层速度，于是误以为 change 在整个系统里都同样便宜。
事实并不是这样。
AI 很擅长补全 implementation，但它不负责在 product reality 改变时保护系统结构的安全。如果 codebase 没有 boundaries，AI speed 只会帮你更快抵达 fragility。
所以我才会一直回到同一个点：面对 AI-native development，正确反应不是更乐观，而是更可替换。
快速生成。强制边界。做 deterministic validation。当路线变化时，删掉坏模块。把影响范围控制在局部。
你还是得处理幻想的那一部分
没有哪个 framework 会自己走进规划会议，然后告诉别人他们的上线日期根本是想象出来的。
Autotomy 不会解决优先级排序。不会解决一厢情愿的路线图。也不会阻止相关方在施工开始后又往地图上画一个新站点。
那一部分，你还是得以工程师和成年人身份去处理。
但困难应该只剩这一部分。
这份工作不应该还附带一个任务：每次计划一变，就得去抢救一套会跟着塌掉的 codebase。
陨石开发也许会一直像一种组织天气一样存在。没关系。就让它继续做预期管理的梗。
有了 Autotomy，它不必再是工程受苦的梗。