2. V2EX
  3. 关于大模型的过度设计

关于大模型的过度设计

Jinmu24 2026-08-30 12:33 1

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



  • 非常倾向于过度设计

  • 为问题引入非必要的复杂度

  • 在实现过程中写一堆测试


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



  • 有效性：是否能高质量解决问题

  • 复杂性：是否引入了非必要的复杂度

  • 后果： 是否引入了新的问题
    在 Skill 中也定义了大模型提出方案的基线，以及围绕解决方案的排查思路


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

最新回复 (13)
  • jacketma 08-30 12:36
    1楼
    发现是有这个问题，不过不好解决。
    本质上是用户偏好的问题，有的人就喜欢事无巨细的答复，有些人喜欢简明扼要的回答。
    一方面考虑大模型自身的能力，另一方面也看大模型猜用户的喜好准不准了
  • maolon 08-30 12:44
    2楼
    你这个和 https://github.com/lennney/stop-that-shit 的区别？
  • coreJK 08-30 12:49
    3楼
    https://github.com/DietrichGebert/ponytail
    试试这个？
  • Jinmu24 楼主 08-30 12:50
    4楼
    @maolon 简单来说，are you sure 重点在于提升决策质量，用于 Agent 改代码之前
    stop that shit 主要倾向于评估 Agent 的改动是否越界,也就是“做的时候别乱做”
    我感觉二者是上下游的关系
  • nightwitch 08-30 12:50
    5楼
    只有 gpt 这个问题比较严重。grok 用的不多，国内模型 glm/ds 都还好。
    gpt luna 其实也还好，sol 感觉特别喜欢过度设计
  • Jinmu24 楼主 08-30 12:54
    6楼
    @coreJK 感谢回复，我在写这个 skill 之前有看过 Ponytail ，二者有一些相似的地方，但本质还有有区别的
    Ponytail：在目标/方向大致确定后，优先寻找最小、最原生、最少依赖的实现方式，核心仍是 implementation minimization 。
    AYS：在实施之前，把方案本身当作待验证假设，判断它是否有效、是否过度复杂、以及会带来什么后果。核心是 solution evaluation 。
  • yidinghe 08-30 13:18
    7楼
    过度设计的判断是非常主观的，它需要使用者和 Agent 的长期磨合，积累记忆，总结风格，形成 skill 。
  • wombat 08-30 14:30
    8楼
    我也觉得很保守。gpt 5.6 sol ，比之前的 gpt 模型更保守。特别是一些发散性的问题，保守到感觉是一个裹了脑的老人。 最近我都切到别的工具开发了。。。
  • qgswzmz 08-30 15:14
    9楼
    @nightwitch 我的体验是，gpt 在实现的时候自然而然的就会加那些防御，如果在设计方案的时候明确不要这么干，他就会给你端上来一个 西红柿炒鸡蛋（不加东坡肉版）
  • lujiaosama 08-30 19:21
    10楼
    5.6sol 的过度设计过于严重，以至于我不得不在 AGENTS.MD 里专门限制必须按照最小可行方案来设计。其次是不要做什么做什么是隐式契约，不要一直婆妈的强调。
  • hachimen 08-30 21:19
    11楼
    我觉得写一堆测试是好事情。
  • Jinmu24 楼主 08-30 21:47
    12楼
    @hachimen 写测试肯定是必要的，不过我之前有一个工程没有对 AI 做测试端的限制，每次跑一个任务，AI 总是会花大量的时间写 TDD ，任务好久才能完成，后面我自己看了看，发现都是大部分测试都是冗余的
  • loveleyla2013 08-30 21:59
    13楼
    Claude 没这么多的问题
* 帖子来源V2EX
附近帖子
返回
飞读
随机推荐