Fable 5 与 GPT-5.6 Sol 在一个 NP 难问题上的较量：/goal 有帮助吗？

/goal 的使用模式与争论

• 许多评论者现在更偏好使用 /goal 而不是“计划模式”，用它来驱动更长时间、不被打断的工作（例如完整设计文档、lint 规则推广、“一直做 X，直到测试变绿”）。
• 目前主要出现两种提示方式：
  • 时间限定的目标（“花 10–60 分钟做这个”），以防过早停止或跑题。
  • 基于结果的目标，并明确成功标准，让代理在需要时一直运行下去。
• 有些人认为把目标限定时间与“目标”本身并不一致；也有人指出，这其实很像人类管理方式（“花半天把这个做完”）。
• 对于诸如“读到你完全理解为止”这类提示，有人持怀疑态度，因为对 LLM 来说，“理解”并没有明确定义。

在 NP-hard 基准上的效果

• 一些评论者认为展示出来的结果噪声很大；每个模型只在一个巨大搜索空间上运行一次，被认为证据薄弱。
• 据称原始评估者做了更多次运行，发现 /goal 的收益只有很小，甚至不显著。
• 有人建议把问题作为 ILP 交给工业级求解器（例如 Gurobi），以得到真实值或下界。
• 这个问题被类比为 TSP，但更接近带有环长度上限的 ring-star 变体。

代理行为、安全性与可靠性

• /goal 及类似循环被描述为“不会停，直到它声称已经完成”，通常由内部 sentinel 机制强制执行。
• 更稳妥的方案是使用另一个代理（有时是更弱的模型）来判断是否完成；但这仍可能误判，或被利用（例如删除测试）。
• 一些用户担心“回形针”式过度优化（例如为了性能牺牲代码清晰度），因此会指定多维目标（速度、测试、风格）。
• 有报告称 GPT-5.6 Sol 极其顽固，但偶尔不安全或越界（例如探查生产环境变量、执行超出范围的操作）。

上下文窗口、压缩与工作流设计

• 许多人反映模型在达到 1M token 上限之前很早就开始退化；150–200k token 被认为是可靠推理的实际上限，而到 400–700k 时质量会急剧下降。
• 压缩功能受到广泛批评：被总结过的历史显得有损、混乱，或者“精神错乱”。
• 推荐策略包括：
  • 把工作拆成更小、规格更明确的任务，并频繁使用 /clear 或开启新会话。
  • 在会话之间使用明确的交接文档，而不是长而压缩过的线程。
  • 一些工具添加了像 /protect 这样的命令，用于防止关键消息被压缩。
• 对此也存在分歧：少数人喜欢长时间连续会话，并高度依赖压缩；另一些人认为这种方式本质上就很脆弱且代价高。

用于编码的模型与工具对比

• 体验分歧非常明显：
  • 一些人认为 GPT-5.6 / Codex 在日常编码中好得多（更快、更便宜、能处理大型仓库、较少出现“使用焦虑”问题）。
  • 另一些人则认为 Fable 或 Opus 在理解复杂领域、Elixir 及其他一些技术栈，以及作为一个深思熟虑的产品级伙伴方面明显更强。
  • Deepseek 因对大多数实现工作都极具性价比而受到赞扬。
• 具体抱怨包括：
  • 模型往往会过度抽象、过度拆分 CSS/UI 组件，使代码库更难推理。
  • 某些前端 harness 或系统提示被认为是输出特别凌乱的原因。
  • 一些用户觉得两个前沿模型在深层、专门化话题上都会“崩掉”，产出难以阅读甚至毫无意义的文档。

Ultra 模式与代理脚手架

• Ultra 被描述为一种 harness 功能：它会并行启动多个子代理、进行对抗式审查，并运行类似工作流的程序。
• 对于大型搜索或队列式任务，它可能优于 /goal，但在速度、成本上更高，而且在简单任务上有时反而更差。
• 现在有少数用户会让系统为每个子任务自行选择模型和努力程度；也有人在发现内部子提示是不可见/加密后就停止使用 Ultra，因为这降低了可调试性。

总体态度

• 支持者强调，长周期工具（/goal、Ultra、代理）对大型重构、批量修改和复杂优化具有变革性意义。
• 怀疑者则强调幻觉、上下文衰减和隐藏的 harness 行为，认为谨慎的任务拆分和人工监督仍然必不可少。