AI工具比你的工作流死得更快

AWS刚把Amazon Q从移动端下架，GitHub宣布GPT-5.2系列即将废弃。这周又有一批"编程未来"变成了"请于6月前迁移"。

没人觉得这是大事。但这件事恰恰暴露了团队最危险的盲区：我们以为买的是工具，实际上押注的是习惯。

工具会死，习惯会留

开发团队爱谈工具选型，组织真正运转靠的是工作流。一次采购周期就能换掉IDE插件，但 onboarding 文档里的步骤、PR 模板的填写规范、事故响应时的检查清单、安全评审的隐性规则——这些才是系统的骨骼。

它们不会随工具更新而自动刷新。

作者观察到一个反复出现的症状：团队把工作流文档写成产品说明书。

「用Claude X做重构」「用GPT Y生成测试」「用Amazon Q查AWS问题」「用Copilot写PR摘要」——作为个人偏好没问题，作为架构决策就是债务。

模型名称是版本化的实现细节，不是设计对象。真正的架构单元应该是能力本身：代码审查、测试生成、文档补全、配置校验。这些能力可以路由到不同的助手、模型、提示策略或执行环境，只要工作流围绕能力而非产品表面来设计，工具替换就只是配置变更，而非微型迁移项目。

这道理和云服务、CI平台、监控工具、消息队列的演进一模一样。抽象层不该假装实现不存在，但要让"可替换部分"一目了然。

而在AI工具领域，这个可替换部分往往就是品牌名本身。

界面消失，工作还在

今天的工作流是：选中日志→右键→用助手总结。明天的现实是：IDE插件废弃、模型更名、上下文窗口缩水、定价模型切换、安全团队禁用粘贴权限、助手搬进了带不同记忆机制的聊天标签页。

活儿没少一件。入口全换了。

AI助手被营销成耐用的同事，实际表现更像跑马圈地期的SaaS功能。有些会沉淀为稳定产品，很多不会。它们的迭代速度注定快过工程流程的演进节奏。

作者的核心建议很简单：设计AI辅助工作流时，假设每一个具体助手、模型代号、IDE集成、托管功能都有短半衰期。

不是悲观，是承认当前市场的真实结构。

架构该防什么

具体做法上，团队可以检查现有文档：有多少步骤绑定了特定产品名称？有多少检查清单假设了某个插件的菜单结构？有多少自动化脚本硬编码了模型端点？

这些就是未来的迁移成本。

反过来，把工作流描述为"需要X能力时，通过Y接口获取"，Y可以是任何满足契约的实现。这种写法在工具变动时只需要更新路由表，不用重写操作手册。

云原生时代我们学会了不把代码绑死在某台机器上。AI原生时代需要同样的觉悟：别把习惯绑死在某个品牌名上。

AWS移动端的Q下架只是开始。GitHub的GPT-5.2废弃通知不会是唯一一封。当工具半衰期短于工作流生命周期，架构的韧性就取决于你区分"能力"和"实现"的清晰度。