最近关于gpt-5.6使用体验的话题很多，涉及模型档位、skills、子代理、大型代码库、代码审查、前端开发，以及各种成功或失败案例
这些讨论看起来比较分散，但在我看来，它们最终都指向了同一个结论：
gpt-5.6 更适合轻流程、强边界、短闭环
下面结合论坛里的讨论和我自己的实际体验，简单总结为以下几点：
1. 少依赖流程型框架，多使用方法论和边界明确的 skill
gpt-5.6 的问题往往并不是“不听话”，反而是：过于听话、过于谨慎、容易过度完成任务
当提示词或框架给它规定了非常复杂的流程时，它通常会认真地把每一步都执行完。像superpowers这类偏流程化的框架，虽然理论上覆盖得很全面，但用在gpt-5.6上时（说白了就是给弱智模型用的框架你给大牛用收效肯定很小），很容易出现流程过重、反复规划、频繁验证，最终导致速度明显下降
所以我个人更建议佬们使用两类skill：
提供方法论的skills，帮助模型发现问题、梳理需求或检查盲区
边界清晰、用途明确的skills，解决具体项目中的特定问题
例如 grill-me，它比较适合在项目开始前帮助你发现那些自己没有意识到的unknown unknowns，也就是连自己都不知道需要确认的问题
我目前一般使用：
- mattpocock 的skills集
- karpathy skills
- 根据具体项目编写的特化 Skills
相比让模型机械执行一整套固定流程，我更倾向于把skills当作可以按需调用的工具箱：需要什么就调用什么，不需要就让模型直接工作
2. 模型档位要根据任务阶段选择
我目前对各档位的使用方式大致如下：
根据我自己的体验，一个项目在开荒阶段如果已经通过 Sol Max 产出了一份质量比较高的指导文档，那么后续执行阶段对模型能力的要求其实会下降很多
在有清晰文档和约束的情况下，Sol low/medium、Terra，甚至 Luna Max，都能够完成得相当不错
我在让 Sol Max 编写项目文档时，通常还会专门要求它思考：
* 项目最容易在哪些地方踩坑；
* 哪些设计可能在后期形成技术债；
* 哪些接口和边界需要提前固定；
* 后续实现时应该遵循哪些原则；
* 哪些看似方便的方案应该明确禁止。
（这几项是gpt优化提示词后的一段，我直接复制过来了）
这部分非常重要。因为高档位模型真正有价值的地方，不只是替你写出第一版代码，而是提前识别风险，给后续执行模型铺好轨道
从实际效果来看，只要前期文档足够扎实，后面即使换成更低档位的模型执行，也能在很大程度上避免留下严重的技术债
3. 不要写一点代码就测试一次
关于 GPT-5.6 速度过慢的问题，我目前一个比较有效的解决方案是：
不要让它每写一点代码就立刻运行完整测试，而是让测试集中发生在合适的阶段
我的处理方式一般是：
- 小任务：完成全部修改后统一测试
- 大任务：拆成几个明确阶段，每个阶段结束后集中测试
- 最终提交前：再进行一次完整验证
总结说就是测试次数需要与任务规模匹配
如果每改几行代码就执行一次编译、测试、lint 和全量检查，模型等待结果出来，尤其是在大型代码库或rust项目中，整体效率会下降得非常明显
将任务拆成几个可以独立验收的小阶段，让模型在每个阶段内连续完成实现，再统一进行测试，通常能显著提高速度
对我来说，这种方式在大型项目和rust项目上的提升尤其明显（虽然耗时仍然比5.5长，但最起码不是几个小时几个小时的耗了）
各位佬们有什么秘诀也欢迎分享一下，众人拾柴火焰高嘛
jfmoe 07-16 09:151楼
approachai 07-16 10:063楼
Nelumbo 07-16 10:214楼
jia WANG 07-17 12:406楼