使用 GPT 5.6-Sol 开发遇到的问题

Zeroth 2026-08-16 13:44 1

GPT 5.6-Sol 的执行力很强,能非常好的遵循指令,但是我认为差也就差在这里。



  1. Skill/指令 强固化。 Skill的每一条步骤他从不校验是否有必要,直接按字面意义强制执行,一个步骤也不差。我开发了一个skill,要求"在开发前查询依赖版本",结果他每次对话(哪怕开发已经开始了)都强制执行这个步骤,不仅没用而且占据上下文空间,要知道GPT5.6的上下文窗口本就很紧张。

  2. 存在欺骗/偷懒行为。 如果你用过Codex,你会发现GPT5.6 几乎每一个修改都会写一个对应的测试。看上去很安全不是吗?我一开始也是这么认为的(对应的,Claude几乎从来不写测试)。我使用GPT开发了一个pathfinder,我发现他在作弊——他的测试大部分都是已固化场景,而GPT会针对这个已经固化的场景不断fine-tuning相关参数——根本就不可靠,而在实际测试中也确实如此。 更严重的是他自己永远无法发现,或者说承认自己的代码有问题。输出prompt大量出现"最小化修改",大量未经验证断言。


这一些问题让我的GPT5.6变得非常难用,我得变成赛博监工一刻不停地盯着Codex窗口,以防他走一些邪道。大家有什么解决的方案吗?

最新回复 (6)
  • 艾志恒 08-16 13:47
    1

    红蓝对抗,会话a改完必须由红队的b review过pass了才继续

  • fengg0023 08-16 13:55
    2

    偷懒是最普遍的,经常说做完了,让它仔细检查一下,它又说还差一些才做完

  • dynamic_cast 08-16 13:55
    3

    对于指令遵循过强的问题,个人感觉其实不算是模型的问题,而是反映出 skill 或者指令存在某些欠缺。这类问题可以通过调整 skill 或者指令解决,反倒是“善于变通”的模型(比如 Claude 系列)即使把指令写的很完美也要提防他过于自信/自作主张,完全没办法解决了。


    然后佬友说的第二条,其实是这类 test 驱动方法的共性问题。建议查一查安装的 skill 有没有类似 test-driven-development 类似的字眼。此类开发范式最大的问题就是测试写的不好和模型过拟合测试,这两个问题往往一起出现。最简单的解决方案是弃用这个开发范式,毕竟这样的范式一方面想用程序化的 test 来减少人工参与,另一方面又不想让死板、程序化的 test 导致模型过拟合,这是不太可能实现的。如果实在不想弃用可以看看 mattpocock 的 tdd skill 是怎么要求模型写出更好的 test 的。

  • wwwsen 08-16 13:58
    4

    用claude先写方案然后gpt5.6执行

  • Jason zhou 08-16 14:02
    5

    非常难用,我得变成赛博监工一刻不停地盯着Codex窗口,以防他走一些邪道。大家



    没错,和我的发现一模一样,然后,引入另一个模型来查问题。后来干脆只用kimi了,省心多了。

  • hzqst 08-16 14:13
    6

    个人感觉5.6系的模型就不适合让它自己凭空写测试,最好还是用其他发散能力强的模型把所有需要约束的边界情况探索出来之后,整理成文档再交给gpt来写测试。

* 帖子来源Linux.do
返回