关于大模型的过度设计

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

目前在高强度使用 GPT 5.6 和 Grok 发现大模型在提出具体的解决方案时，有这样几个特点：

非常倾向于过度设计
为问题引入非必要的复杂度
在实现过程中写一堆测试

我写了一个 Skill ，让大模型围绕以下三个维度“反思”它提出的方案或者观点：

有效性：是否能高质量解决问题
复杂性：是否引入了非必要的复杂度
后果：是否引入了新的问题在 Skill 中也定义了大模型提出方案的基线，以及围绕解决方案的排查思路

目前我在多个项目里实测了几天，感觉效果拔群，配合 Matt Pocock 的工作流会更好欢迎各位大佬们体验： https://github.com/nscTechArt/are-you-sure

大模型

过度设计

反思

7 replies • 2026-08-30 13:18:00 +08:00

jacketma

48 mins ago

发现是有这个问题，不过不好解决。
本质上是用户偏好的问题，有的人就喜欢事无巨细的答复，有些人喜欢简明扼要的回答。
一方面考虑大模型自身的能力，另一方面也看大模型猜用户的喜好准不准了

maolon

40 mins ago

你这个和 https://github.com/lennney/stop-that-shit 的区别？

coreJK

35 mins ago via Android

https://github.com/DietrichGebert/ponytail
试试这个？

Jinmu24

34 mins ago

@maolon 简单来说，are you sure 重点在于提升决策质量，用于 Agent 改代码之前
stop that shit 主要倾向于评估 Agent 的改动是否越界,也就是“做的时候别乱做”
我感觉二者是上下游的关系

nightwitch

34 mins ago

只有 gpt 这个问题比较严重。grok 用的不多，国内模型 glm/ds 都还好。
gpt luna 其实也还好，sol 感觉特别喜欢过度设计

Jinmu24

30 mins ago

@coreJK 感谢回复，我在写这个 skill 之前有看过 Ponytail ，二者有一些相似的地方，但本质还有有区别的
Ponytail：在目标/方向大致确定后，优先寻找最小、最原生、最少依赖的实现方式，核心仍是 implementation minimization 。
AYS：在实施之前，把方案本身当作待验证假设，判断它是否有效、是否过度复杂、以及会带来什么后果。核心是 solution evaluation 。

yidinghe

PRO

6 mins ago

过度设计的判断是非常主观的，它需要使用者和 Agent 的长期磨合，积累记忆，总结风格，形成 skill 。