← 返回信息流
Agent SkillLINUX DO · AI·1 小时前

sub2api二开提示词:支持GPT-5.6 MAX和Ultra推理强度

原标题:sub2api目前还未支持gpt-5.6 MAX和Utral推理强度,分享一下我二开提示词。

速览

用户针对sub2api项目提出二开提示词,以支持GPT-5.6的sol、terra、luna模型的MAX和Ultra推理等级。要求保留原有推理等级,确保max独立且不被降级,Ultra作为Codex客户端模式处理。需保持兼容性,添加回归测试,并生成静态二进制文件。

AI 深度解读

背景

该帖子来自 LINUX DO 论坛的 AI 技能 / 提示词 / 工作流分享板块,作者分享了自己对开源项目 Wei-Shaw/sub2api 的二次开发提示词。sub2api 是一个将订阅链接转换为 API 的工具,当前版本 v0.1.149 尚未支持 GPT-5.6 的 MAX 和 Ultra 推理强度。作者希望借助 AI 分析代码并实施最小范围的修改,使 sub2api 能够正确识别并处理 GPT-5.6 系列模型的多种推理等级,同时保持与现有部署、数据库、业务逻辑的兼容性,并最终生成一个可部署的静态二进制文件。

核心内容

原帖是一份完整的开发指令,要求 AI 完成以下工作:

  1. 分析并修复对 GPT-5.6 推理等级的支持。当前环境为 sub2api v0.1.149,通过官方 install.sh 二进制安装,路径为 /opt/sub2api/sub2api。目前支持的模型包括 gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna。

  2. 保留原有的 low、medium、high、xhigh 四个推理等级,并在此基础上扩展:

    • gpt-5.6-sol 和 gpt-5.6-terra 需要支持 maxUltra 模式。
    • gpt-5.6-luna 支持 max,但不声明支持 Ultra。
  3. 明确 max 与 Ultra 的语义差异

    • max 必须作为独立等级记录,不能被归一化成 xhigh。
    • Ultra 是 Codex 客户端模式,而不是 API 的 reasoning.effort 枚举值。因此,合法的上游请求格式必须为:
      {
        "reasoning": {
          "effort": "max",
          "context": "all_turns"
        }
      }
      
    • 不允许直接向上游发送 "effort": "ultra"
    • 不得删除或覆盖 reasoning.contextreasoning.encrypted_content 等 Codex 字段。
  4. 保持一致性:Chat Completions、Responses API、usage 日志和计费识别应保持一致,不修改数据库结构、管理员账号、Redis、systemd 配置和现有业务数据。

  5. 添加回归测试:确认 max 不降级、Ultra wire 字段不被删除、旧模型行为不变。

  6. 最终产出:生成带嵌入式前端的 linux_amd64 静态二进制,BuildType=release。

  7. 部署与回滚:部署前先备份 /opt/sub2api/sub2api,失败自动回滚。保持兼容官方 install.sh,官方后续适配后仍可通过 upgrade 覆盖更新。

  8. 实施原则:先检查代码和实际请求链路,再实施最小范围修改,不要把客户端的 Ultra 多代理行为错误地伪装成一个新的服务端 effort 枚举。

关键要点

  • 推理等级扩展:新增 max 和 Ultra 两个等级,但 Ultra 不能作为 API 的 reasoning.effort 值,而是通过客户端特定的请求格式(Codex 模式)实现。
  • 等级独立性:max 必须是独立等级,不可降级为 xhigh;Ultra 的上游请求必须保持 effort: "max" 并附带 context: "all_turns"
  • 字段保护reasoning.contextreasoning.encrypted_content 等 Codex 字段在请求转发过程中不得被删除或覆盖。
  • 最小修改原则:只修改与推理等级相关的代码逻辑,不触碰数据库、系统配置、业务数据。
  • 回归测试:必须验证新模型行为正确,同时确保旧模型(low/medium/high/xhigh)不受影响。
  • 部署安全:备份原二进制,失败自动回滚;保持与官方升级机制兼容。
  • 避免错误抽象:Ultra 是客户端多代理模式,不应在服务端侧将其抽象为新的 reasoning.effort 枚举值。

意义与影响

该帖子反映了 AI 工具社区中二次开发与定制化的典型需求:当上游开源项目尚未支持新模型特性时,开发者通过提示词工程引导 AI 进行代码级修复和扩展。这种方式降低了手动修改代码的门槛,使非核心开发者也能参与功能增强。

从技术角度看,帖子强调了三个重要原则:语义准确性(max 和 Ultra 不能混淆)、兼容性(不破坏现有架构)和最小侵入性(只改必要部分)。特别是对 Ultra 模式的处理——不将其视为一个新的 API 枚举,而是保留为客户端侧的特殊请求格式——避免了服务端逻辑的过度扩展,体现了对上游协议设计的尊重。

此外,帖子要求生成可部署的静态二进制并附带回滚机制,说明该修复不仅要解决功能问题,还需具备生产环境可落地的可靠性。这种“提示词驱动的代码修复”模式,可能成为未来开发者与 AI 协作的一种常见工作流,尤其适用于快速适配新模型、修复已知 bug 的场景。

查看原文 →linux.do