有些任务只需要一个执行者，有些任务更需要第二双眼睛。
SuperDiscussion 是一个面向 Codex 的开源 Skill：Codex 继续负责本机工作、工具调用和最终决策；当你明确邀请时，Kimi 或 ZCode 可以加入，提供独立审核、反方意见、方案建议或限定轮次的讨论。
它不替换、不 fork Codex Harness，也不要求你换到另一套聊天前端。平时仍然像往常一样和 Codex 对话；需要协同时，用一句自然语言把外部 Agent 请进来即可。
使用成本提示：SuperDiscussion 可以显著增加复核深度和代码质量，代价是更多 Token 与更长时间。并非每个问题都值得“开会”，请按任务价值选择使用。
- 默认不开会。 安装和配置 API Key 都不会触发外部调用。你不指定外部 Agent 时，只有 Codex 工作。
- 需要时再邀请。 可以只用 Kimi、只用 ZCode、让二者双盲审核，或让它们围绕一个问题讨论；参与者和角色由当前对话决定，不在安装时写死。
- Codex 保持主导。 外部 Agent 只收到为当前角色裁剪的上下文包，没有文件系统、终端或代码修改权限。Codex 负责验证意见、决定采纳与否，并完成真正的本机操作。
SuperDiscussion 当前正式支持 Codex、Kimi K3 和 ZCode GLM-5.2，适用于 Windows、macOS 与 Linux，运行时只依赖 Python 标准库。
| 任务 | 推荐方式 | 为什么 |
|---|---|---|
| 小修改、状态询问、普通解释 | 只用 Codex | 额外协同通常只会增加等待和 Token |
| 已完成的代码需要第二双眼睛 | 单审 | 一个独立 reviewer 足以发现盲区 |
| 核心功能、发布前检查、安全敏感改动 | 一轮双审 | 两个 reviewer 独立检查，减少共同偏差 |
| 修复后仍担心遗漏 | 两至三轮单审或双审 | 每轮只审核新的候选版本，最多三轮收敛 |
| 编码前已有产品、交互或架构候选方案 | Design Review | 先挑战目标、假设、替代方案和取舍，再决定是否开发 |
| 开放式架构、产品或研究问题存在真实取舍 | 多 Agent 讨论 | 允许不同立场交锋，而不是只返回一份 JSON 审核表 |
| reviewer 与 Codex 存在重要分歧 | 咨询型 judge | 外部 judge 提供意见，最终决定仍由 Codex 作出 |
在 Codex 中发送下面这一句话即可安装：
请从 https://github.com/supergitty520/superdiscussion 安装 SuperDiscussion Skill；安装完成后告诉我结果，不要调用任何外部 Agent。
安装完成后发送：
进行配置
Codex 会说明配置方法并打开用户级 config.json。API Key 只填写在该文件中，不要粘贴到对话里。安装、配置和连通性检查是三件不同的事：保存 Key 不等于授权调用，也不会偷偷探测 Provider。
下面的句子不是必须背诵的命令，只是可以直接改写的例子。
修复登录表单在网络断开时没有错误提示的问题。
没有点名外部 Agent，SuperDiscussion 不会调用 Kimi 或 ZCode。
让 ZCode 作为 reviewer，独立审核刚才的修改。不要只看代码，还要检查黑盒测试和浏览器实际体验。
也可以换成 Kimi，或明确要求两轮：
让 Kimi 对这次改动做两轮单审。Codex 根据第一轮意见修改并验证，再把新版本交给 Kimi 复审。
让 Kimi 和 ZCode 分别独立审核当前改动，彼此不要看到对方意见。两份结果都完成后，由 Codex 合并重复问题并逐条裁定。
如果你明确要求“审核”但没有指定单审、双审或轮数，默认是一轮 Kimi/ZCode 双盲审核。审核策略一共有六种：single 或 dual × 一至三轮。超过三轮通常只会重复已有分歧，因此状态机拒绝第四轮。
先不要写代码。让 Kimi 和 ZCode 对这个注册流程做两轮双审，重点检查产品逻辑、前端状态、异常恢复和整体架构；由 Codex 收敛成最终设计后再告诉我。
这不是必须记忆的 design-review 命令。Codex 会根据自然语言判断当前审核对象是“尚未实现的设计”还是“已经完成的代码”，并在内部选择对应契约。Design Review 只修改设计候选，不会在审核阶段偷偷开始开发。
设计 reviewer 必须检查问题定义、隐藏假设、用户旅程、前端交互、状态与数据流、架构边界、失败恢复和不必要的复杂度，并至少提出一个真正不同的替代方案及其代价。没有浏览器原型时必须明确说明，不能虚构体感测试。
Design Review 与代码审核一样支持一至三轮单审或双盲双审；仍由 Codex 逐条裁定，最终设计会成为后续开发的设计契约。
如果配置中已允许 ZCode 使用 coder 角色，让它以 coder 顾问身份提出一份数据库迁移方案。Codex 检查假设和风险后决定是否采用，并只由 Codex 执行本机修改。
外部 coder 是建议者，不会获得终端或写文件权限。对话可以调整本轮角色分配，但 Provider 必须先在本机配置中允许该角色；运行时不会绕过角色白名单。
让 Kimi 做 reviewer；如果它和 Codex 对一个关键问题仍有分歧，再让 ZCode 给出一次咨询型 judge 意见。最终工程裁定仍由 Codex 完成。
单独请一个外部 Agent 充当最终 judge 通常价值有限，因此正常审核流程始终由 Codex 终审。Judge 只在你明确需要另一种判断视角时加入。
让 Kimi 和 ZCode 讨论这个项目应该使用 SQLite 还是 PostgreSQL，最多三轮。先讲各自判断，再回应真正的分歧，最后由 Codex 自然总结。
讨论使用自然语言流式输出，而不是把 JSON 直接堆到主对话里。每轮所有声明参与者都发言后才能进入下一轮；最多三轮，能够提前收敛就提前结束。
SuperDiscussion 的核心不是“多模型写代码”，而是让 Codex 在需要时获得一组受控、可追踪的外部视角。只要任务能够被整理成清晰的目标、证据和约束，就可以使用。
先由 Codex整理当前约束和候选方案，再让 Kimi 从长期维护成本出发、ZCode 从交付风险出发各自提出意见。最多两轮，最后由 Codex 给出取舍和下一步。
Codex 先整理我提供的资料和证据来源，然后让 ZCode 检查论证是否跳步，让 Kimi 专门寻找反例。不要把未经证实的模型记忆当作证据。
外部 Agent 没有自动浏览网页或读取整个资料库的权限。Codex 应先收集证据，再只发送与角色相关的摘要、引用和必要片段。
Codex 先根据日志形成根因假设，再让 Kimi 和 ZCode 分别挑战这些假设，指出还缺什么证据。不要修改系统，先完成诊断。
让 ZCode 作为红队 reviewer 审查这份上线计划，重点找不可逆步骤、隐含依赖和回滚缺口；由 Codex 判断哪些风险成立。
让 Kimi 检查这份技术说明是否让新用户看得懂，让 ZCode 检查技术承诺是否与实际功能一致；Codex 合并意见后再修改文档。
让 ZCode 和 Codex 共同讨论这张产品图的视觉叙事：既要有技术可信度，也要让 GitHub 访客愿意继续阅读。只讨论一轮，然后由 Codex完成设计。
附件仍由 Codex 在本机读取。只有在你明确授权外部协同时，Codex 才会把与任务直接相关的文字摘要、证据引用或必要片段发送给指定 Provider。
角色不是固定绑定某个 Provider：
coder：提出方案或候选实现，Codex 仍是唯一的本机执行者。reviewer：独立找问题、补测试、挑战假设；可以配置一个或两个。judge：只提供咨询型裁决意见，不能替代 Codex 的最终决定。
你可以随时在自然语言中调整组合，例如：
这一轮只让 ZCode 做 reviewer，不调用 Kimi。
下一轮改成 Kimi 和 ZCode 双审，仍然由 Codex 做最终 judge。
Kimi 已连续两次因 overload 或 quota 失败，跳过它并把本轮明确记录为用户授权的单审降级；不要写成双审通过。
未配置的 Provider 设置为 enabled: false 即可；只有一个外部 Agent 也是完整、可用的配置。自动故障切换只能在你已经授权的 Provider 集合内发生，不能借故把内容发送给另一个未授权模型。
第一次外部调用必须由你明确提出。授权会绑定当前 Codex 对话、精确项目目录、任务 ID、调用用途和 Provider 目的地。新对话、新项目、新任务，或者端点、模型、网络范围与代理路径发生变化时，都不能继承旧授权。
同一连续任务中的必要复审或你已经指定的 judge 步骤可以继续；如果边界不清楚，Codex 应先问你，而不是自行扩大调用范围。
外部 Agent 不会收到完整聊天记录。Codex 会保留本机历史，只投影当前目标、固定约束、相关决定、证据引用、必要工件片段、已有立场和仍未解决的分歧。这样既降低 Token 消耗，也减少无关信息外泄。
随时可以停止：
停止外部 Agent。撤销本对话授权，接下来由 Codex 自己完成。
也可以说“不要再调用 Kimi，ZCode 可以继续”或“只撤销当前任务”。撤销完全在本机完成，不会联系 Provider。恢复调用必须再次明确授权；旧请求文件和旧 parent_run_id 不能自行恢复权限。已经发送出去的内容无法撤回。
- 双审请求彼此隔离，完成屏障之前 reviewer 看不到同伴结果。
- Reviewer 只对同一个候选哈希形成 approval。代码一旦修改，旧 approval 不会被冒充为新版本通过。
- 只有最终候选获得完整 reviewer approval 时，才记录
reviewer_approved或dual_approved。 - 其他情况由 Codex 逐条接受或拒绝 finding，记录测试证据，并如实结束为
codex_finalized、codex_finalized_with_dissent或blocked。 - 每轮冻结请求、原始 reviewer JSON、finding 到修改的映射、测试证据、最终源码哈希和 Codex 终审理由都会进入本机审核档案。
task-status可以只读显示当前轮次、缺失 reviewer、阻塞原因和下一责任方；只有与当前对话、项目、Provider 配置、当前工作流所需角色和撤销状态完全匹配的授权才会显示为可用。preview-request在联网前同时展示授权状态、实际可执行性和具体阻塞原因，包括角色漂移、冷却、未配置及默认双审人数不足；invoke、review-team与doctor都绑定同一份不可变请求快照，状态机记录的也是实际解析或发送的快照身份，内容变化时关闭失败。若 Provider 已经收到请求，随后发生的本地快照漂移也会留下失败审计记录。
Review 与 Judge 使用结构化 JSON，讨论使用自然语言流式输出。两种模式共享同一授权与上下文裁剪边界。
默认配置面向编程与深度审核，使用订阅计划的 Coding 端点：
| Provider | endpointProfile |
国际版端点 | 模型 | 常用角色 |
|---|---|---|---|---|
| Kimi | coding |
https://api.kimi.com/coding/v1 |
k3 |
reviewer、judge |
| ZCode | coding |
https://api.z.ai/api/coding/paas/v4 |
glm-5.2 |
reviewer |
按量付费通用 API 必须同时把 endpointProfile 改为 general：Kimi/Moonshot 国际站使用 https://api.moonshot.ai/v1，Z.AI 使用 https://api.z.ai/api/paas/v4，模型按对应账户实际可用列表填写。订阅计划与通用 API 的密钥、余额和额度不能混用。
代理、loopback 测试或其他兼容服务必须使用 custom。内置 coding/general 档位要求端点与文档值完全一致，避免把档位错误误报为密钥无效或余额不足。Kimi 的通用余额接口只在 general 档位查询。
thinkingEnabled 可为不支持 thinking 参数的 ZCode 模型关闭。structuredTemperature 与 discussionTemperature 默认均为 1，设为 null 才会省略。连接建立默认上限 30 秒；transportIdleTimeoutSeconds 只检测流式连接连续无进展，不是任务总时长或 Token 上限；非流式深度审核默认没有人为总时限。系统环境代理不会被继承。
在 Codex 中发送：
请仅通过已安装的 SuperDiscussion 官方签名稳定版更新器，将 SuperDiscussion 更新到最新稳定版本。更新器只能使用官方 GitHub Stable Release，必须验证签名清单和文件哈希，更新前备份当前版本，失败时自动回滚；不要调用任何外部 Agent，也不要修改我的配置、API Key、授权记录、运行状态或项目审核工件。
更新器依次执行 check、prepare 和 apply，验证官方稳定版、Ed25519 detached signature 与逐文件哈希。签名信任缺失或验证失败时会关闭失败，不会降级成 checksum-only 或手工覆盖。更新不等于授权外部 Agent。
默认卸载只删除 Skill 代码，保留 API Key 配置、运行状态、ledger 和项目审核记录：
卸载 SuperDiscussion Skill，保留本机 API Key 配置、运行状态和项目审核记录。
如需同时删除用户级数据，必须明确发送：
完全卸载 SuperDiscussion Skill，并删除用户级配置、API Key、运行状态和 ledger；保留各项目审核记录。
完全卸载仍不会自动搜索或删除项目中的 .superdiscussion 及旧版审核目录，避免跨项目误删。自定义用户数据目录需要再次确认精确路径；卸载脚本只允许删除 $CODEX_HOME/skills/superdiscussion，在源码仓库内运行时会拒绝删除。
本项目当前只正式支持 Codex、Kimi 和 ZCode。
本 Skill 过去没有、现在没有、未来也不会加入对 Claude 或任何 Anthropic 产品的内置或官方支持；本项目同样反对将此类支持合并进官方代码库。这是明确的项目范围和维护立场，而不是对用户环境的技术封锁：项目不会主动拦截用户自行维护的第三方适配器，但不会为其提供官方兼容保证、文档、测试或问题支持。
未来可以讨论 Grok、Gemini 等 Provider，但不会在未经用户授权的情况下自动启用任何外部服务。
- 不要提交真实的
config.json、.env、运行记录或 API Key。 - 连通性检查和实质协作使用不同用途的授权链，不能互相复用；每次 HTTP 重试和后续探测都会重新检查授权。
- Provider 重定向被拒绝，系统代理不会被隐式继承；DNS 解析结果与实际连接地址必须满足 public/loopback/private 策略，metadata、link-local、CGNAT、保留、组播和 mapped-address 绕过永久禁止。
- Provider Base URL 不得嵌入用户名、密码、查询参数或片段。损坏的授权 ledger 或运行状态会 fail-closed。
- 运行状态递归校验；讨论状态使用跨进程内核锁和事务合并，多个 speaker 不会相互覆盖。
- 发布 ZIP 只接受冻结的
release-manifest.json文件集合，拒绝额外文件，并验证签名、逐文件哈希与常见密钥形态。 - Provider 不提供 quota 数值时，不伪造进度条或百分比；认证、余额、quota、过载、模型与网络错误分别处理。
更多安全信息见 SECURITY.md。
SuperDiscussion 背后的思考不只关于代码，也包括 AI 协作、权限边界、信息判断，以及技术如何进入真实生活。更多中文文章与持续更新，欢迎访问 苏西的界。
微信公众号 · 苏西的界
在微信中长按识别，或使用扫一扫
README.md 与 README.en.md 保持同等信息范围。安装说明、配置变更、迁移提示、主要用法和 Release Notes 均应同时提供中文与英文版本。Issue 与 Pull Request 可以使用任一语言。
开发需要 Python 3.10 或更高版本，不需要第三方 Python 包：
python3 -m unittest discover -s tests -v
python3 scripts/superdiscussion.py validate-config --config config.example.json
Windows 可将 python3 替换为 py -3 -X utf8。
项目采用 AGPL-3.0-only 许可证。分发修改版时必须提供对应源代码；如果修改版通过网络向用户提供服务，也必须向这些用户提供对应源代码。商业使用和收费仍然允许，但不能把修改后的受 AGPL 约束部分闭源。完全私人、既不分发也不提供网络服务的修改通常不触发公开义务。