驯服AI子代理的五段式规格模板Sol Advisor规格先行设计全拆解【免费下载链接】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子代理去实现一个功能结果它自由发挥改了一堆不该动的文件、还留下一堆说不清楚的改动Sol Advisor正是为解决这个问题而生的——它是一个基于 Codex 的架构师编排工作流核心理念是规格先行spec-first由主会话Sol完整写出五段式实现规格再分派给原生子代理执行最后强制用全新的 Sol 审查员复核。本文将带你完整拆解这套规格模板与三段式协作机制。一、为什么规格先行能驯服AI子代理 大多数AI编码工具失败的原因不是模型不够强而是指令不够契约化。模糊的提示帮我加个分页功能会放大量子代理的自主空间从而产生架构偏离、越界修改和自说自话的完成声明。Sol Advisor 的做法是把自主性收敛到主会话子代理只负责在既定契约内执行主会话Sol / High拥有需求澄清、架构决策、任务分解、完整规格、父级验证、最终验收子代理Luna / Terra只做在已定架构内、按规格实现有边界的任务审查员全新 Sol / High只看真实 diff 和证据返回ship/fix-first/rethink三种裁决之一完整职责划分见 SKILL.md角色契约与提示模板见 role-contracts.md。二、三段式角色分工Luna 常规执行、Terra 显式升级、Sol 新鲜审查Sol Advisor 用三个原生 Codex 自定义代理组成一条能力路由流水线每个角色的模型与推理档位都由 TOML 配置文件钉死pin派发时不允许再覆盖阶段原生角色职责规划Sol / High主会话解析意图、架构、分解与完整规格常规实现sol_advisor_luna_implementerLuna / Max 处理边界清晰、已充分规格化的工作显式升级sol_advisor_terra_implementerTerra / High 处理判断密集或高风险工作最终审查sol_advisor_sol_reviewer全新 Sol / High 审查真实 diff返回ship/fix-first/rethink三个角色的配置文件sol-advisor-luna-implementer.toml —— 钉死gpt-5.6-lunamax推理sol-advisor-terra-implementer.toml —— 钉死gpt-5.6-terrahigh推理sol-advisor-sol-reviewer.toml —— 钉死gpt-5.6-solhigh推理并声明sandbox_mode read-only 两条关键路由规则默认走 Luna边界清晰、完全规格化的工作都从常规车道走。一次纠正后升级 Terra如果一次修正后的 Luna 尝试暴露出工作其实判断密集或高风险即常规路由误分类就把修正后的规格升级到 Terra。这是项目明确写入 README 的升级判据杜绝默默换模型的静默降级。三、五段式规格模板逐段拆解这是全文的核心。Sol Advisor 要求每一条实现提示词必须包含五个区块一个都不能少定义在 role-contracts.md 的共享实现契约中3.1 OBJECTIVE目标可观测的结果以及它为什么重要。不是实现分页而是列表页在数据超过 20 条时分页展示用户翻页后 URL 同步更新。可观测三个字是关键——它直接为后面的验证环节埋下锚点。3.2 FILES AND OWNERSHIP文件与所有权你只拥有- 精确的文件或模块这一段专门解决子代理越界修改的顽疾。契约模板里写死了一句提醒你不是代码库里唯一的代理。其他代理或用户可能正在并发编辑。保留他们的编辑不要回退无关工作并适应已存在的变更。不要修改所有权之外的文件。️ 这一条在并发多代理协作场景中价值极高等于给每个子代理划了责任田。3.3 INTERFACES接口必须保持兼容的签名、类型、模式、命令或行为。子代理可以自由选择内部实现但接口是红线。这保证了多个子代理的工作可以组合而不会出现各自为政的接口漂移。3.4 CONSTRAINTS约束仓库惯例、安全边界、排除范围、已定决策。把已拍板的决定显式写出来防止子代理在实现时重新发明架构。这也是 Luna 角色被要求暴露模糊性而不是重新设计架构见 Luna 的 developer_instructions的原因。3.5 VERIFICATION验证运行精确命令成功标准具体预期结果检查精确文件、diff 或产物成功标准具体预期证据验证必须是精确命令 具体证据不接受应该没问题。没有证据的完成声明在本工作流里直接无效——契约里原文写明Return exact commands and actual evidence. A completion claim without evidence is invalid.返回精确命令与实际证据无证据的完成声明无效。附赠RETURN 与 IMPLEMENTATION REPORT结构化回报执行完五个区块的任务后子代理必须按固定结构回报STATUScomplete/partial/blocked、OBJECTIVE复述、CHANGES基于真实 diff 的逐文件总结、VERIFIED命令输出证据、JUDGMENT CALLS规格留下的开放决策、GAPS未完成项或模糊点。这套结构化回报让父会话能快速判断是真完成还是看起来完成了。四、完整协作流程从规格到 ship 的五步闭环把规格模板放回整条流水线Sol Advisor 的完整闭环是规划主会话Sol / High解析意图、做架构决策写出完整五段式规格派发用精确角色名agent_type: sol_advisor_luna_implementerfork_turns: none派发给原生子代理fork_turns: none意味着全新上下文避免继承主会话的偏见父级验证主会话亲自检查完整 diff、确认只改了范围内文件、自己重跑验证命令并把证据与目标/接口/约束逐项对照新鲜审查父级验证通过后必须再派一个全新的sol_advisor_sol_reviewer同样fork_turns: none让它只看真实文件与累计 diff返回ship、fix-first或rethink裁决执行ship→ 带验证证据报告完成 ✅fix-first→ 派回同一合适角色修正再验证、再审查rethink→ 修改架构不得报告完成⚠️ 两条铁律值得新手记住审查员永远不修自己的发现任何修正都会使先前裁决作废必须重新走一轮全新审查。规则出处见 SKILL.md 的Require the final Sol review一节。五、安装与自检三步跑通 Sol Advisor需要最新的 Codex CLI或启用插件的 ChatGPT 桌面端、jq以及 GPT-5.6 系列模型的原生自定义代理支持。完整说明见 README。第一步把仓库加入 Codex 市场并安装插件仓库地址https://gitcode.com/gh_mirrors/so/sol-advisor。第二步安装三个原生配套自定义代理模板并运行非变更式精确检查sh $plugin_dir/scripts/install-agents.sh sh $plugin_dir/scripts/install-agents.sh --check安装器是失败即关闭fail-closed且非破坏性的被修改过、符号链接、未知或内容不一致的目标文件都会被拒写并报告冲突详见 install-agents.sh。第三步检查通过后开启新的 Codex 任务原生代理类型只在任务创建时发现主会话选择 GPT-5.6 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 只读检查真实路由证据模型/推理档位拒绝猜测式回退verify.sh —— 仓库级验证脚本检查三个角色 TOML 钉死、文档路由措辞、安装器行为等六、新手落地建议从哪一步开始用 给刚接触多代理协作的你的三条建议先抄五段式模板哪怕不用 Sol Advisor也建议直接借用 role-contracts.md 里的 OBJECTIVE / FILES AND OWNERSHIP / INTERFACES / CONSTRAINTS / VERIFICATION 五段结构作为你自己的子代理提示词骨架——这是全文最值得抄的资产。验证要可复跑把 VERIFICATION 区块里的命令写成父会话能原样重跑的形式而不是检查功能正常这种无法复核的描述。审查必须新鲜如果你让刚写过代码的同一个会话来审查它会有上下文偏见。Sol Advisor 强制fork_turns: none的全新线程审查本质是在用流程对抗 AI 的自我确认偏差。总结Sol Advisor 给出的答案很朴素却极其有效用规格把自由度收回来用证据把完成声明钉死用新鲜视角审查自己的成果。五段式模板 Luna/Terra/Sol 三角色路由 强制新鲜审查这套规格先行设计可以作为任何 AI 子代理工作流的设计范本。【免费下载链接】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），仅供参考
驯服AI子代理的五段式规格模板：Sol Advisor规格先行设计全拆解
驯服AI子代理的五段式规格模板Sol Advisor规格先行设计全拆解【免费下载链接】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子代理去实现一个功能结果它自由发挥改了一堆不该动的文件、还留下一堆说不清楚的改动Sol Advisor正是为解决这个问题而生的——它是一个基于 Codex 的架构师编排工作流核心理念是规格先行spec-first由主会话Sol完整写出五段式实现规格再分派给原生子代理执行最后强制用全新的 Sol 审查员复核。本文将带你完整拆解这套规格模板与三段式协作机制。一、为什么规格先行能驯服AI子代理 大多数AI编码工具失败的原因不是模型不够强而是指令不够契约化。模糊的提示帮我加个分页功能会放大量子代理的自主空间从而产生架构偏离、越界修改和自说自话的完成声明。Sol Advisor 的做法是把自主性收敛到主会话子代理只负责在既定契约内执行主会话Sol / High拥有需求澄清、架构决策、任务分解、完整规格、父级验证、最终验收子代理Luna / Terra只做在已定架构内、按规格实现有边界的任务审查员全新 Sol / High只看真实 diff 和证据返回ship/fix-first/rethink三种裁决之一完整职责划分见 SKILL.md角色契约与提示模板见 role-contracts.md。二、三段式角色分工Luna 常规执行、Terra 显式升级、Sol 新鲜审查Sol Advisor 用三个原生 Codex 自定义代理组成一条能力路由流水线每个角色的模型与推理档位都由 TOML 配置文件钉死pin派发时不允许再覆盖阶段原生角色职责规划Sol / High主会话解析意图、架构、分解与完整规格常规实现sol_advisor_luna_implementerLuna / Max 处理边界清晰、已充分规格化的工作显式升级sol_advisor_terra_implementerTerra / High 处理判断密集或高风险工作最终审查sol_advisor_sol_reviewer全新 Sol / High 审查真实 diff返回ship/fix-first/rethink三个角色的配置文件sol-advisor-luna-implementer.toml —— 钉死gpt-5.6-lunamax推理sol-advisor-terra-implementer.toml —— 钉死gpt-5.6-terrahigh推理sol-advisor-sol-reviewer.toml —— 钉死gpt-5.6-solhigh推理并声明sandbox_mode read-only 两条关键路由规则默认走 Luna边界清晰、完全规格化的工作都从常规车道走。一次纠正后升级 Terra如果一次修正后的 Luna 尝试暴露出工作其实判断密集或高风险即常规路由误分类就把修正后的规格升级到 Terra。这是项目明确写入 README 的升级判据杜绝默默换模型的静默降级。三、五段式规格模板逐段拆解这是全文的核心。Sol Advisor 要求每一条实现提示词必须包含五个区块一个都不能少定义在 role-contracts.md 的共享实现契约中3.1 OBJECTIVE目标可观测的结果以及它为什么重要。不是实现分页而是列表页在数据超过 20 条时分页展示用户翻页后 URL 同步更新。可观测三个字是关键——它直接为后面的验证环节埋下锚点。3.2 FILES AND OWNERSHIP文件与所有权你只拥有- 精确的文件或模块这一段专门解决子代理越界修改的顽疾。契约模板里写死了一句提醒你不是代码库里唯一的代理。其他代理或用户可能正在并发编辑。保留他们的编辑不要回退无关工作并适应已存在的变更。不要修改所有权之外的文件。️ 这一条在并发多代理协作场景中价值极高等于给每个子代理划了责任田。3.3 INTERFACES接口必须保持兼容的签名、类型、模式、命令或行为。子代理可以自由选择内部实现但接口是红线。这保证了多个子代理的工作可以组合而不会出现各自为政的接口漂移。3.4 CONSTRAINTS约束仓库惯例、安全边界、排除范围、已定决策。把已拍板的决定显式写出来防止子代理在实现时重新发明架构。这也是 Luna 角色被要求暴露模糊性而不是重新设计架构见 Luna 的 developer_instructions的原因。3.5 VERIFICATION验证运行精确命令成功标准具体预期结果检查精确文件、diff 或产物成功标准具体预期证据验证必须是精确命令 具体证据不接受应该没问题。没有证据的完成声明在本工作流里直接无效——契约里原文写明Return exact commands and actual evidence. A completion claim without evidence is invalid.返回精确命令与实际证据无证据的完成声明无效。附赠RETURN 与 IMPLEMENTATION REPORT结构化回报执行完五个区块的任务后子代理必须按固定结构回报STATUScomplete/partial/blocked、OBJECTIVE复述、CHANGES基于真实 diff 的逐文件总结、VERIFIED命令输出证据、JUDGMENT CALLS规格留下的开放决策、GAPS未完成项或模糊点。这套结构化回报让父会话能快速判断是真完成还是看起来完成了。四、完整协作流程从规格到 ship 的五步闭环把规格模板放回整条流水线Sol Advisor 的完整闭环是规划主会话Sol / High解析意图、做架构决策写出完整五段式规格派发用精确角色名agent_type: sol_advisor_luna_implementerfork_turns: none派发给原生子代理fork_turns: none意味着全新上下文避免继承主会话的偏见父级验证主会话亲自检查完整 diff、确认只改了范围内文件、自己重跑验证命令并把证据与目标/接口/约束逐项对照新鲜审查父级验证通过后必须再派一个全新的sol_advisor_sol_reviewer同样fork_turns: none让它只看真实文件与累计 diff返回ship、fix-first或rethink裁决执行ship→ 带验证证据报告完成 ✅fix-first→ 派回同一合适角色修正再验证、再审查rethink→ 修改架构不得报告完成⚠️ 两条铁律值得新手记住审查员永远不修自己的发现任何修正都会使先前裁决作废必须重新走一轮全新审查。规则出处见 SKILL.md 的Require the final Sol review一节。五、安装与自检三步跑通 Sol Advisor需要最新的 Codex CLI或启用插件的 ChatGPT 桌面端、jq以及 GPT-5.6 系列模型的原生自定义代理支持。完整说明见 README。第一步把仓库加入 Codex 市场并安装插件仓库地址https://gitcode.com/gh_mirrors/so/sol-advisor。第二步安装三个原生配套自定义代理模板并运行非变更式精确检查sh $plugin_dir/scripts/install-agents.sh sh $plugin_dir/scripts/install-agents.sh --check安装器是失败即关闭fail-closed且非破坏性的被修改过、符号链接、未知或内容不一致的目标文件都会被拒写并报告冲突详见 install-agents.sh。第三步检查通过后开启新的 Codex 任务原生代理类型只在任务创建时发现主会话选择 GPT-5.6 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 只读检查真实路由证据模型/推理档位拒绝猜测式回退verify.sh —— 仓库级验证脚本检查三个角色 TOML 钉死、文档路由措辞、安装器行为等六、新手落地建议从哪一步开始用 给刚接触多代理协作的你的三条建议先抄五段式模板哪怕不用 Sol Advisor也建议直接借用 role-contracts.md 里的 OBJECTIVE / FILES AND OWNERSHIP / INTERFACES / CONSTRAINTS / VERIFICATION 五段结构作为你自己的子代理提示词骨架——这是全文最值得抄的资产。验证要可复跑把 VERIFICATION 区块里的命令写成父会话能原样重跑的形式而不是检查功能正常这种无法复核的描述。审查必须新鲜如果你让刚写过代码的同一个会话来审查它会有上下文偏见。Sol Advisor 强制fork_turns: none的全新线程审查本质是在用流程对抗 AI 的自我确认偏差。总结Sol Advisor 给出的答案很朴素却极其有效用规格把自由度收回来用证据把完成声明钉死用新鲜视角审查自己的成果。五段式模板 Luna/Terra/Sol 三角色路由 强制新鲜审查这套规格先行设计可以作为任何 AI 子代理工作流的设计范本。【免费下载链接】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），仅供参考