过度设计：猪肉该拿走，不是加锁

我要做番茄炒蛋，AI 却往里加了猪肉。我指出来，它没把猪肉拿走，而是装了几道锁，保证猪肉「不会出现在最后的盘子里」。

听着荒唐，但写代码时真的常见：一个本不该加的功能留着，外面多了关键词过滤、沙箱、检测器、熔断器，最后再来个定时自检。系统越来越复杂，最开始那个错误前提一直没撤。

先问需不需要，再谈怎么防

护栏当然有用：外部输入不可信要校验，模型输出要检查，危险操作要限权限。但如果麻烦是系统自己加进来的、根本不在需求里的东西，第一反应应该是：能不能直接删？

比如某段内容本来就不该生成，在出口过滤只是把它藏起来了。生成那条链路还在跑，钱照花，依赖照留，误触发的可能也还在。

「越修越多」的信号

我会留意三件事：原来的问题是不是还在里面发生；修的时候是不是多出了一个常驻模块；这个新模块是不是又要一套自己的检查。

代码变多不一定是坏事，补必要的校验和回归测试也可能是对的修法。要警惕的是：这些新加的东西是不是全都在伺候一个本来可以删掉的东西。

删之前也要看一眼

删之前确认一下有没有别的地方依赖它；删完再确认需求还满足、原来的问题也没了。有用的回归测试留着，只为那个功能服务的检查一起清掉。

这次之后我更愿意先问一句：它为什么要留着？ 很多时候，降低复杂度的办法就是把不属于这个任务的东西拿走。