代码到底能不能上线Sol Advisor的ship/fix-first/rethink三级终审机制全拆解【免费下载链接】sol-advisorCodex-native architect orchestration with Luna and Terra implementation lanes and mandatory fresh Sol review.项目地址: https://gitcode.com/gh_mirrors/so/sol-advisorSol Advisor 是一个专为 Codex 打造的 AI 开发编排插件由 Sol 负责架构与规格Luna / Terra 分工实现代码最后由一个全新的 Sol 评审者对真实 diff 给出ship、fix-first或rethink三级判决——只有终审通过代码才算真正可以上线。这篇指南带你完整拆解这套AI 代码终审机制的运作方式。为什么 AI 写的代码上线前更需要一道终审AI 编程助手写得快但能跑起来不等于可以放心上线。常见的三个隐患⚠️自我汇报偏差执行者自己说做完了但可能遗漏边界情况⚠️上下文污染写代码的会话带着自己视角评审时容易对己方产出心软⚠️评审与实现混为一体同一个角色既写代码又验收等于既当运动员又当裁判。Sol Advisor 的回答是把终审权交给一个新鲜的、只读的、不许动手改代码的独立评审者并要求它只依据真实 diff 和验证证据下判决。判决只有三种没有差不多就行。先认识 Sol Advisor一条角色分工清晰的 AI 交付流水线整套工作流由四个角色协作全部是 Codex 原生自定义 Agent路由规则见 SKILL.md阶段角色模型档位职责规划Sol / High解析意图、架构、分解与完整规格常规实现sol_advisor_luna_implementerLuna / Max默认处理边界清晰、规格完整的例行工作显式升级sol_advisor_terra_implementerTerra / High判断密集型、高风险工作或纠正一次后暴露误分类的工作终审sol_advisor_sol_reviewer新鲜 Sol / High审查真实 diff返回ship/fix-first/rethink之一三个角色的模型与推理档位被写死在各自的 TOML 配置里例如终审角色固定为 Sol 模型、high 推理、只读沙箱sol-advisor-sol-reviewer.toml两条实现线分别是 sol-advisor-luna-implementer.toml 和 sol-advisor-terra-implementer.toml。ship / fix-first / rethink 三级判决详解终审评审者检查实际文件、累计变更集、接口约束和验证证据后必须且只能返回三种判决之一完整输出格式定义在 role-contracts.md✅ ship可以上线附验证证据代码正确、完整、无回归、范围克制、风险可控。主会话此时才可以向用户报告完成并附上验证证据。这是唯一能宣布交付的绿灯。 fix-first先修再报修完必须重新评审存在边界清晰、必须修正的问题。处理流程是主会话把修复任务委派给对应的实现角色Luna 或 Terra主会话自己重新检查 diff、重跑验证命令再发起一次全新的终审。旧判决在修复后即刻作废——没有改完直接过的捷径。 rethink架构要重来禁止宣布完成问题不是改几行代码能解决的架构或范围本身必须调整。此时主会话必须回到设计层面修订方案不允许报告完成。三句话总结ship放行fix-first打回小修rethink推倒重想。规则出处见 SKILL.md 的 Require the final Sol review 一节。为什么终审必须新鲜而且评审员不许动手Sol Advisor 对终审角色有两项看似苛刻、实则关键的设计1. 全新的会话上下文fork_turns: none评审者从不继承实现过程的对话历史。它没有当时为什么这么写的记忆包袱只能基于眼前的代码和证据判断——这保证了评审是上下文干净的独立判断。2. 评审者永远不实现自己的修复评审角色运行在只读沙箱中指令里明令禁止创建、修改、删除文件。评审发现fix-first后修复必须由实现角色完成然后由又一个新鲜评审重新把关。作者不改自己的卷子改卷子的老师不发卷子这条链路被制度锁死。项目文档也坦诚说明Sol 评 Sol 带来的是上下文干净而不是跨模型族的独立。这种克制反而让机制的边界清晰、可预期。修正代码后如何重新终审fix-first不是终点而是一个循环的起点终审 → fix-first → 委派修复 → 主会话重新验证 → 再次新鲜终审 → ship / fix-first / rethink配套规则 任何一次修复都使先前判决失效必须跑一次新的新鲜评审 主会话不能悄悄修好子代理的失败补丁也不能隐藏未解决的修正 运行时证据选中的角色、模型、档位必须与配置一致缺失或不一致就停止该通道绝不允许静默降级到其他模型或角色。仓库自带的 verify.sh 会校验上述所有契约三个角色 TOML 的模型钉扎、fork_turns: none的新会话要求、一次纠正的 Luna 尝试即升级 Terra的升级规则全部可脚本化验证。三步安装并跑起这套终审机制第 1 步安装插件需 Codex CLI 或启用插件的 ChatGPT 桌面端codex plugin marketplace add sol-advisor 仓库地址或本地路径 codex plugin add sol-advisorsol-advisor第 2 步安装三个原生角色并做只读校验插件安装不会自动注册角色文件plugin_dir$(codex plugin list --json | jq -r .installed[] | select(.pluginId sol-advisorsol-advisor) | .source.path) sh $plugin_dir/scripts/install-agents.sh sh $plugin_dir/scripts/install-agents.sh --check安装器 install-agents.sh 是失败即拒绝且非破坏性的已存在的角色文件不会被覆盖--check只做逐字节比对。第 3 步开启新任务并使用编排技能原生角色在任务创建时发现所以安装后请新开一个 Codex 任务主会话选择 Sol / High 推理然后显式调用Use $sol-advisor:orchestration to build this feature, verify it, and obtain the fresh Sol review before reporting done.如果某次运行没有暴露模型或档位元数据可用 inspect-agent-runtime.sh 按线程 ID 只读查询路由证据它只输出白名单字段绝不猜测缺失值。常见问题FAQQ评审员给了fix-first我修完能直接上线吗不能。任何修复都会使旧判决作废必须再跑一次全新的终审拿到新的ship才算过。Q为什么 Luna 失败后要升级到 Terra而不是换个模型重试这是显式升级通道一次纠正后的 Luna 尝试仍暴露判断密集 / 高风险 / 误分类就交给 Terra / High。没有静默回退也没有第二套隐藏路由。Q这套流程对我自己的项目有参考价值吗有。即使不用 Sol Advisor它的三条原则值得抄走终审者必须新鲜上下文、评审者只读不动手、证据先于结论。总结Sol Advisor 用一条角色分工清晰的流水线把AI 写的代码能不能上线这个模糊问题变成三个可执行的判决✅ship带证据放行fix-first小修后重新终审旧判决作废rethink回炉重做架构禁止宣布完成。配合只读沙箱、新鲜会话和绝不允许静默降级的硬规则这套三级终审机制给 AI 交付的代码质量加了一道可审计、可复现的闸门。更多细节可阅读 README.md 中的完整路由表与 role-contracts.md 中的角色契约。【免费下载链接】sol-advisorCodex-native architect orchestration with Luna and Terra implementation lanes and mandatory fresh Sol review.项目地址: https://gitcode.com/gh_mirrors/so/sol-advisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考