Glasswing翻车48小时后，我逼团队用上了7步清单

4月7日，Hacker News首页被三件事屠版：Project Glasswing发布、Claude Mythos Preview系统卡、以及一条1200赞的GitHub issue直斥「Claude Code无法处理复杂任务」。同一天，三个八位数营收系统的技术负责人在内部群里发了同一个表情包：「又来了」。

这不是唱衰AI编程。我上周刚逼着Glasswing和Mythos Preview走完一个真实支付服务的重构——结果很诚实：模型生成的diff漂亮得像艺术品，但藏着三处会导致缓存泄漏、连接池耗尽和更新丢失的坑。所谓「长周期任务」的营销话术，在HN评论区被工程师用战故事撕得粉碎。

我跑过八位数规模的产线系统。不写评论，只发搬钱的代码。这套清单是我上周强制执行的，12分钟跑完，零事故。

第一步：先写架构决策记录，再开模型

约束条件、失效模式、回滚方案——在打开Claude之前就得落纸。事务边界、锁级别、缓存失效规则、合规要求。

模型不知道你的业务不变量。我知道。单这一步就在生成前干掉了40%的烂建议。

上周的支付服务重构里，模型建议把订单状态机改成异步事件驱动。看起来优雅，但我的ADR里写着「必须支持同一秒内的幂等退款查询」。模型没读这条，生成的代码在竞态条件下会直接双扣。

第二步：每处数据库变更强制带检测查询

现在每份AI生成的SQL或迁移必须附带：

EXPLAIN ANALYZE（执行计划分析）输出，且模型必须用大白话解释

外键缺索引？两亿行表上SELECT *？当场现形。这些经典模式我之前在产线见过，单起事故成本从1万到14万美元不等。

Mythos Preview给我生成过一段「优化后的」库存扣减逻辑。EXPLAIN显示它打算全表扫描。我问模型为什么，它道歉说「忽略了索引提示」。如果我没强制这步，凌晨三点的报警电话已经响了。

第三步：一次只动一个模块或文件

绝对不搞「重构整个服务」。上下文坍塌大概在5到8千行代码时发生——模型会忘记命名规范、重试策略、熔断器配置。我只审一个逻辑单元，省下几小时的追bug时间。

Glasswing在处理一个包含12个文件的PR时，把用户ID和价格数据混进了同一个缓存键。这是Step 4清单里的明确禁忌，但模型在文件第7个时才犯这个错。如果我没拆成单文件审查，这个漏洞会溜进合并队列。

第四步：跑一遍真实事故预防清单

合并前我打开同一份清单——在三家公司用过同一套：

连接池大小与max_connections（最大连接数）的数学关系

热表上的行级锁

缓存键设计（禁止用户ID+价格数据混用）

Webhook重试逻辑与熔断器存在性

高负载下真能跑通的回滚路径

清单上每项都对应真实的、五位数美元以上的损失。

上周模型建议把连接池从20扩到200，说「提升并发」。我的清单第1项要求计算：max_connections是100，服务实例跑8个，200×8=1600已经爆表。模型没算这笔账，它只管生成好看的数字。

第五步：模拟凌晨3点的寻呼机场景

我问模型：「如果这玩意儿挂了，凌晨2点我会收到什么检测查询和报警？写出来。」然后在预发环境测。

模型产不出有用的检测方案？变更不许上线。

Glasswing给的那段缓存重构代码，我按这步测试时发现：它写的「失败检测」是检查Redis连接状态——但真正的故障模式是缓存穿透导致DB被打爆，Redis连接明明活着。检测方案文不对题，打回重写。

第六步：前后对比测量

跑我惯用的同一套负载测试：延迟、错误率、连接数、缓存命中率。任一指标走错方向，退回第一步。

数字不撒谎。营销会。

Mythos Preview的「性能优化」版本在测试里把P99延迟从120ms压到80ms，但连接数涨了3倍。我的连接池清单第1项再次报警——这优化在流量峰值时会直接熔断。

第七步：部署后自动验证脚本

每次部署AI生成的代码后自动运行。抓那些溜过前六步的漏网之鱼。

上周它 caught 了一个：模型把新加的缓存TTL设成了毫秒而非秒，意味着缓存几乎永不失效。Step 2的EXPLAIN没查这个，Step 4的清单没覆盖单位错误，但部署后脚本对比了缓存命中率曲线，异常平坦的直线暴露了问题。

这套流程现在写进我们团队的合并门禁。不是因为我信不过AI，是因为我信得过自己付过的学费。

Glasswing和Mythos Preview的Hacker News热度已经退了，但那个1200赞的issue还在更新——最新回复是某工程师贴出的生产事故时间线，从「模型建议看起来很合理」到「回滚花了4小时」。

你团队的AI代码审查流程，能拦住凌晨3点的电话吗？