GoForum🌐 V2EX

关于大模型的过度设计

Jinmu24 · 2026-08-30 12:38 · 0 次点赞 · 7 条回复

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

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

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

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

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

7 条回复
jacketma · 2026-08-30 12:43
#1

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

maolon · 2026-08-30 12:48
#2
coreJK · 2026-08-30 12:53
#3
Jinmu24 · 2026-08-30 12:53
#4

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

nightwitch · 2026-08-30 12:53
#5

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

Jinmu24 · 2026-08-30 12:58
#6

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

yidinghe · 2026-08-30 13:18
#7

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

添加回复
你还需要 登录 后发表回复

登录后可发帖和回复

登录 注册
主题信息
作者: Jinmu24
发布: 2026-08-30
点赞: 0
回复: 0