用 ce-bakeoff 让多个独立候选方案竞争并选出最优【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugincompound-engineering-plugin 中的ce-bakeoff解决的是一个具体的决策问题当你要做一个有分量的技术选择架构形态、产品机制或手上只有几个粗略选项还没想清楚时靠列名字和优缺点清单往往不够需要先把候选方案真正做出来再比较。ce-bakeoff的做法是让多个彼此隔离的 agent 各自独立开发一个候选方案再引入一个独立评审最后由协调者比较、验证并给出获胜方案或明确的无法决出结论。什么时候该用 ce-bakeoff什么时候不用ce-bakeoff适用场景是一个已经定义清楚的目标brief但替代方案尚未充分展开需要先做出来再比较。文档明确划出的边界材料已经成型、只差判断用哪个 → 用ce-pov还不知道该做什么方向的机会 → 用ce-ideate目标本身尚未确定 → 用ce-brainstorm需要运行时实验验证性能类主张 → 用ce-optimize依赖人实际体验才能判断的选择 → 用ce-prototype。两个容易踩的边界显式调用ce-bakeoff不会把已经定下来的决定重新打开agent 会直接返回该决策已定这一约束而不是硬造几个假候选它产出的是不可执行的工件approach brief、架构草图、方向性伪代码不是可运行代码。发起一次 Bake-off最直接的方式是斜杠命令直接调用文档给出的示例/ce-bakeoff develop competing retry-ownership approaches under these requirements and choose one在 Codex 上则使用对应的美元前缀技能名$前缀。发起时把你的需求作为 brief 提供给它目标、约束、已定决策、期望的工件保真度fidelity和预算。调用后 agent 会先宣布一次 Bake-off 开始然后默认启动三个全新上下文命名为 Baker A、B、C从同一份 common brief 出发。关键的独立性规则见 candidates.md每个候选开发者只拿到共同的 brief、已定决策和读取范围看不到彼此的输出也看不到协调者倾向的答案每个候选返回一份 approach sketch其独特的机制、证据与假设、影响选择的权衡、以及它明确拒绝过哪些做法默认最多允许1 个恢复候选recovery candidate用来补一个被遗漏的维度同样看不到其他候选要宣称比较完成至少需要两个可用的独立候选候选更少了结果是 incomplete运行期间产出写入私有的运行暂存目录/tmp/compound-engineering-$(id -u)/ce-bakeoff/下的一次性 run 目录共享输入与候选输出分开存放。模型如何分配给候选和评审Bake-off 自己负责候选调度派发顺序是见 SKILL.md 与 judging.md尊重显式指定的候选模型或混合explicit candidate model mix——优先级最高否则使用调用方解析好的模型偏好ce-plan传plan_modelce-brainstorm传brainstorm_model都没有时优先让不同模型家族分头开发先走宿主原生的模型访问再尝试可用的已授权模型 CLI以上路线都失败时回退到宿主动用自身模型启动全新 agent并明确披露这是回退。注意模型多样性只是偏好全新上下文fresh context才是硬性要求——所有 baker 用同一个模型也仍然满足独立性但复用上下文不算新的独立尝试。独立评审选赢家之前必须有一票外部评委比较和选基座base由协调者做但在选择之前必须有一个全新子 agent 以 guest 身份运行ce-pov做独立评估见 judging.md。规则要点评委没有写任何候选优先选择与协调者不同模型家族的模型同家族的评委是披露过的回退没有独立评委则整个结果是 incomplete评委拿到 common brief、比较标准、匿名标签的完整候选和源指针但看不到协调者的排名评委要区分有源码/权威依据支撑的结论和纯假设识别一旦不成立就会推翻可行性、必需保证或排名的依赖协调者把评委结论与自己的比较对账出现实质分歧时用源证据裁决并记录理由而不是按票数表决仅在显式请求、或一个经源码核实后仍存在的关键分歧需要更多视角且预算允许时才走ce-pov的 oracle panel。验证获胜方案与判定结果选出基座、吸收其他候选的有用贡献之后不能直接宣布赢家。按 verification.md用具体案例挑战最终机制包括评审之后才引入的修改什么样的输入会打破必需保证或推翻这个选择把这个案例按要求的保真度实际走一遍展示决定性的检查及其结果——没找到反例本身不构成证明对每个决定性的前提decision-critical premise要能指出本次运行中实际检查过的实现证据或权威来源。引用标签、凭记忆的记忆、未验证的评委断言都不算证据。已有代码依赖某平台保证也不能证明该保证存在关键支撑仍然缺失或被推翻时结果是unresolved可以附带一个临时偏好provisional preference但不能宣布验证过的赢家。返回给你的完整结果包含outcomeselected / unresolved / incomplete、brief、获胜工件、实际候选比较、决定性理由、被吸收的贡献及其来源、有意义的拒绝及原因、验证限制与剩余证据需求、参与情况launch 失败与掉线按观察记录、以及预算/用量证据。聊天里只高亮决策和理由如果结果较大或你要求留档完整记录写入持久文档路径解析见 output.md从仓库根.compound-engineering/config.yaml读docs_root未设置时默认docs目录。在 ce-plan 和 ce-brainstorm 中触发这两个集成都只在显式请求时才运行不会自动触发/ce-plan plan the migration; run a Bake-off for the unresolved sequencing decision /ce-brainstorm run a Bake-off for the onboarding mechanism after we settle the goals在ce-plan中研究完成后、在 Standard/Deep Durable 计划的关键 HOW 决策固化之前运行选出的方案进入正常计划撰写后续的评审与交接照常进行见 ce-plan 指南。模型偏好可以用提示词指定如use fable、have opus plan this或在 CE 配置中设置plan_model: model提示词请求优先于配置键显式请求的候选模型混合优先于这两者。在ce-brainstorm中目标明确后请求它会替换所选产品机制的普通 Phase 2 生成不再为同一问题额外产出一套普通方案结果回到 Phase 2 呈现可选项先于推荐出现用户确认依然是最终权威。边界与限制ce-bakeoff的调用授权只覆盖范围内读取、候选与评委派发、私有暂存写入和工件验证不授权生产实现、发布或新的外部接收方用户显式给出的预算有效且优先这些是 agent 管理的边界不是供应商的花费上限也没有自动时间截止独立尝试可能收敛到同一机制——比较时检查机制而不是标签单个幸存机制只有在证据解释了为何有意义的替代方案无法满足 brief时才支持选择否则返回 unresolved把 routine 选择变成自动竞赛不被鼓励Do it when a consequential choice needs development而不是给每个小决定都开一场 bake-off。验证是否做完了的标准可以直接对照 SKILL.md 开头的定义至少两个可用独立候选拿到了独立评估、协调者完成对账、最终工件经过证据与 brief 验证、完整决策送达消费者——否则你就应该收到一个明确的 incomplete 或 unresolved 结果而不是一个看似完成的赢家。【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考