GPT 5.6 Sol 总是过度设计？一个关键词“消融实验”直接封神！
不需要 Skill，不需要 MCP。只要扔出这个词，模型就会开始疯狂砍自己的代码。
最近用 GPT-5.6 Sol 写代码，我最大的感受只有两个字：
窒息。
倒不是因为它能力不行。
恰恰相反，它太行了。
行到你让它写一个简单的 CRUD 接口，它能给你整出六层抽象、四个工厂类、三个策略模式，外加一套完整的事件机制。
你只是想在数据库里加一条记录。
它已经开始为三年后的跨区域容灾做准备了。
你问它为什么要搞这么复杂，它每一层都有理由：
- 接口是为了扩展性。
- 工厂是为了统一对象创建。
- 策略模式是为了应对未来变化。
- 事件机制是为了降低模块耦合。
- Value Object 是为了避免非法状态。
单独看，每句话都对。
合在一起，就是一场工程灾难。
最让人精神内耗的是：你明明知道它设计过头了，却很难指出其中哪一层“绝对错误”。
它写的不是烂代码。
它写的是一堆逻辑上正确、当前根本用不上的代码。
删吧，好像不够专业。
留吧，看着又浑身难受。
01 “保持简单”为什么没有用
我一开始也试过最常见的办法。
在 System Prompt 里写：
保持简单。 避免过度抽象。 不要提前优化。 遵循奥卡姆剃刀。
甚至连 Agent 外层框架里，都塞满了类似的约束。
结果呢？
该抽象还是抽象。
该封装还是封装。
该为一个根本不存在的第二种实现创建接口，还是照建不误。
这件事最气人的地方在于，模型当然知道什么叫奥卡姆剃刀，也知道什么叫 YAGNI，甚至能给你写一篇洋洋洒洒的“避免过度设计最佳实践”。
可一到它自己动手，全部忘光。
原因其实很简单。
“不要过度设计”是一句态度，不是一套动作。
什么叫过度？
多一个接口算不算过度？
提前预留一个扩展点算不算过度？
把两个相似函数抽成基类，到底是消除重复，还是制造继承地狱？
这些问题没有统一答案。
模型收到了“保持简单”的要求，却没有拿到判断标准。它只能凭自己的默认倾向做决定。
而 GPT-5.6 Sol 给我的使用体感是：只要存在一点不确定性，它就倾向于多考虑一层；只要某个地方未来可能变化，它就想提前留个接口；只要理论上可能出错，它就恨不得当场把重试、补偿、降级和熔断全部安排上。
它不是在写今天的需求。
它在替一个尚未存在的百人研发团队写五年规划。
就在我快要被这些抽象逼疯的时候，我学到了一个词：
消融实验。
然后，奇迹发生了。
02 四个字，让模型开始对自己下刀
消融实验，英文叫 Ablation Study。
它原本是机器学习里的研究方法：从一个完整系统中拿掉某个模块，再看整体效果有没有下降。
拿掉之后，效果明显变差，说明这个模块有价值。
拿掉之后，什么都没发生，说明这个模块很可能只是来凑热闹的。
这个思路放到代码和架构设计里，简直绝配。
现在，每次 GPT-5.6 Sol 完成设计或者写完代码，我都会补上一句：
现在进行消融实验，去掉不必要的抽象和设计。
就这一句。
不需要安装 Skill，不需要配置 MCP，也不用再写一篇几千字的 System Prompt。
模型的状态会立刻变化。
前一秒，它还在努力证明自己的方案有多完整。
下一秒，它开始逐个拷问自己刚刚创造出来的东西：
- 这个接口删掉，直接依赖具体类，行不行？
- 这个工厂取消，直接创建对象，行不行？
- 这个策略模式现在真的有第二种策略吗？
- 这个事件有人订阅吗？
- 这层封装到底降低了复杂度，还是只把代码藏得更深？
- 这个扩展点对应的是明确需求，还是脑补出来的未来？
- 如果整个类删掉，测试还能不能通过？
然后你会看到非常解压的一幕。
刚才还被它保护得像传家宝一样的接口，删了。
只有一个实现的工厂，删了。
没人订阅的事件，删了。
为了“未来可能变化”提前搭起来的策略模式，也删了。
代码一下子安静了。
03 为什么它比“别过度设计”好用
关键不在于“消融实验”是什么神秘咒语。
这个词给了模型一个明确的动作：先尝试删除，再验证删除后的结果。
“别过度设计”太模糊了。
模型不知道“度”在哪里，只能继续猜。
消融实验就具体得多：
消融检查顺序 找到抽象 → 假设它不存在 → 重新检查需求 → 运行测试 → 评估可读性和维护成本
如果删除之后功能依然完整，测试照样通过，代码反而更容易看懂，那还留着干什么？
砍。
这套方法最爽的地方，是它把举证责任反过来了。
过去，想删除一个抽象的人需要证明：“这个东西没用。”
现在，每一个抽象都要先回答：“你凭什么存在？”
没有第二个实现的接口，不能只靠“以后可能会有”活下来。
没有真实订阅方的事件，不能只靠“这样比较解耦”活下来。
没有进入开发计划的扩展点，也不能拿想象中的未来需求当免死金牌。
复杂度不是免费的。谁把它加进来，谁就应该证明它值得。
04 另一个毛病：被害妄想症式防御
解决完过度抽象，我又发现 GPT-5.6 Sol 身上还有另一个熟悉的毛病：
过度防御。
它特别擅长想象事故。
空指针怎么办？
并发冲突怎么办？
外部接口超时怎么办？
重试失败怎么办？
补偿任务也失败怎么办？
告警系统恰好又挂了怎么办？
你让它写一个内部使用的小工具，它能按银行核心交易系统的标准给你做容灾。
空值判断、边界检查、分布式锁、指数退避、死信队列、降级开关、补偿任务……
恨不得每个函数外面都裹十层救生衣。
防御当然重要。
支付、资金、权限、隐私和不可逆的数据操作，再小的概率也不能随便忽略。
但大量普通业务根本没有这么高的风险。
为了百万分之一的低影响异常，长期维护几百行补偿代码，这笔账很可能是不划算的。
所以，消融实验之后，我又加了一刀：
按发生概率和影响程度分类。
让模型把所有异常场景分成三类：
- 高频或高损失：必须在代码里处理，必要时提供自动恢复。
- 偶尔发生、影响可控：保留明确报错、日志、告警和人工恢复入口。
- 极少发生、影响很小：不要建设复杂的重试和补偿系统，留好日志就够了。
然后逐段追问：
这段防御代码在处理哪一类问题？ 它发生的概率有多大？ 真的发生以后，损失是什么？ 人工修复一次需要多久？ 为了避免一次人工处理，我们准备长期维护多少代码？
问到这里，很多看起来无比专业的防御设计，当场就失去了存在的理由。
05 我现在直接复制的提示词
如果你也快被 GPT-5.6 Sol 的过度设计逼疯，可以在它完成第一版之后，直接发送下面这段：
现在进行一次消融实验。 逐项检查当前实现中的接口、抽象层、工厂、设计模式、扩展点、中间对象和防御逻辑。尝试删除它们，并重新验证当前需求、测试、可读性和已经确认的扩展需求。 删除后没有造成实质退化的设计，直接删除。不要因为“未来可能会用到”而保留抽象。只有已经存在的第二个实现、明确进入计划的需求，或者可以量化的现实收益，才能成为保留理由。 同时按照“发生概率 × 影响程度”检查异常处理：高概率或高损失的问题必须处理；中等风险的问题保留日志、告警和恢复入口；极低概率、低影响且可以人工修复的问题，不要提前建设复杂的重试、补偿和自愈机制。 最后给出删除清单、保留清单，以及每项设计被保留的具体理由。
这段话的效果，比反复强调“保持简单”直接得多。
因为你没有要求模型表现得克制。
你是把刀塞进它手里，让它回头审判自己刚刚写出来的代码。
06 一个词，换掉一套验收标准
我以前总觉得，想控制模型的过度设计，必须继续完善 System Prompt，或者专门做一个 Skill，再不然就搞一套复杂的 Agent 工作流。
后来才发现，有时候根本不用这么重。
第一版让它尽情发挥。
第二版让它做消融实验。
抽象有没有价值，删掉看看。
防御值不值得写，算算概率和代价。
测试过不了，就恢复。
需求不受影响，就别留。
未来的模型也许会把这种自我审查直接内化，不需要用户再主动提醒。
但在那之前，我只需要记住两个词：
“消融实验”——砍掉没有证明价值的抽象。 “按发生概率分类”——砍掉收益配不上成本的防御。
下次 GPT-5.6 Sol 又开始给一个小需求修建地下三层停车场时，别再苦口婆心地劝它“简单一点”。
把这四个字扔过去：
进行消融实验。
看着它亲手拆掉自己刚搭出来的六层架构。
那一刻，精神内耗真的消失了。
AI 博主亲测。
真香。
原载：微信公众号「荒岛书生codedoctor」 · 首发：2026-09-03。本文按原稿整理为网页阅读版，保留发表时的产品版本、案例与数据口径。
