运营

ce-optimize

用途：用带测量的循环优化一个具名目标——归因某个工作负载的成本，或对若干变体打分并保留赢家。

阶段 0 — 测量门

三项缺一则技能无法运行：

1. 一份运行归档或能产出它的运行框架（每次运行的日志，含工具调用轨迹、终止标记、token 计数、最终消息）。
2. 一份构建选择器——框架能把一次运行指向某个指定的源码检出。
3. 一条语料可端到端执行的可重复任务。

任一缺失 → 停下来点名。不要回退到静态审计（那是另一个请求）。

4 个阶段（顺序不可换）

两个阶段 1 闸门

• 干净树闸门：scope.mutable / scope.immutable 下不能有未提交改动。
• 用户批准闸门：阶段 2 前需明确批准。如果主类型为 judge 且 max_total_cost_usd 未设置 → 明确告知花销无上限。

阶段 2 闸门

依赖预审批：汇总所有假设引入的全部新依赖，列出整体清单批量审批。未批准的依赖留在待办，批量选择时跳过，在收尾阶段再回报。

阶段 3 — 七条停止标准（任一即可）

1. 声明的全部必达目标均已达成。
2. 达到最大迭代次数。
3. 达到最大小时数。
4. 评判预算耗尽。
5. 进入平台期。
6. 用户中断。
7. 已无可运行的假设。

落盘纪律

磁盘上的实验日志是唯一事实来源。写入顺序 = 先测量，再写，验后呈现。CP-0..CP-5 检查点。

仅询问

无上限花销 / 新依赖 / 收尾要推送或开 PR / 完成后可选动作。

分支与日志

optimize/<spec-name> 分支。磁盘日志走 scripts/measure.sh + scripts/decide.mjs。

参考（共 13 份、2 个智能体、约 2,437 行）

• references/spec.md（101）
• references/measurement.md（143）
• references/loop.md（262）
• references/wrap-up.md（54）
• references/persistence.md（59）
• references/usage-guide.md（147）
• references/optimize-spec-schema.yaml（498）— 完整 YAML schema
• references/experiment-log-schema.yaml（348）— 完整 YAML schema
• 3 份示例 spec：expensive-benchmark、hard、judge
• 2 个智能体：learnings-researcher、repo-research-analyst

ce-retune

用途：为新模型重新调优一份技能语料，测量先行。disable-model-invocation: true。需要一个能做 A/B 两个构建的基准框架；没有则拒绝执行。

6 个阶段

1. 挖掘归档 — 历史运行就是现成的基线。
2. 建立噪声下限 — 拿两个完全相同的副本做 A/B；任何差异就是每条结论必须越过的下限。在动手之前就把下限书面登记下来。
3. 对抗式审计语料 — 每个技能派一名智能体 + 再派一名持反方意见的智能体。上下文必须独立；同一上下文既辩又驳 = 缺陷。
4. 外科手术式精简 — 每个智能体只负责一类问题。
5. 测量并循环 — 让失败点选择下一处修复。下限被越过即停。
6. 发布 — 提交 + 总结。

硬规则

• 绝不为了“让测试通过”而改测试。
• 不是每个停机信号都是敌人 — 动手前先看另一边站着的是谁。
• 看完结果再设定的下限，不是下限。
• 完成 = 下限被越过，或本次运行明确报告某条主张无法支撑。绿灯测试套件 ≠ 完成。
• 非目标：压缩文字。精简是陈述条件的副作用。

参考（共 6 份、706 行）

• references/workflow-shapes.md（73）— 派发任何阶段前先读
• references/baseline-mining.md（122）
• references/noise-floor.md（131）
• references/corpus-audit.md（128）
• references/cut-passes.md（129）
• references/halt-taxonomy.md（123）— 工作流停机分类

ce-sweep

用途：扫一遍已配置的反馈来源（Slack / GitHub Issues；email 实验中）。在源头确认，分析录制内容，核实修复已合入 main，产出一份 lfg 可用的计划。disable-model-invocation: true；支持 mode:non-interactive 以便定时运行。

阶段 0 — 按配置路由

• feedback_sources 未设置 → 首次运行访谈（交互模式）或停下报错“首次运行需交互式配置”（非交互模式）。
• setup 或 reconfigure 标记 → 不论模式都走首次运行访谈。
• 否则 → 阶段 2。

阶段 2 — 顺序不可换

锁规则

来源侧写入规则

approved: false 的来源 → 绝不写入确认或收尾。条目仍以 ack_deferred 形式 upsert。

状态写入器

scripts/sweep-state.py（793 行）是 sweep state 的唯一写入器。绝不手工编辑状态文件。

收尾

git add 只加计划 + 仓库内部状态（绝不 -A）。提交失败 = 报告，不是致命错误。永远输出总结 + 计划路径 + 交接 /lfg <plan-path>。

参考（9 份 + 1 个智能体，约 800 行）

• references/state-schema.md（157）— sweep state schema v1
• references/run.md（124）— sweep 阶段 2a–2i
• references/interview.md（208）— 首次运行访谈
• references/plan-template.md（62）— sweep 计划模板
• references/model-tiers.md（11）
• references/sources/email.md（57）— 来源
• references/sources/github-issues.md（59）— 来源
• references/sources/slack.md（61）— 来源
• references/subagent-template.md（60）
• 1 个智能体：media-analyzer
• 1 个脚本：scripts/sweep-state.py（793）

ce-setup

用途：检查 Compound Engineering 健康度与仓库本地配置；或用 pack:<id> 脚手架搭建一个 Compound Pack。disable-model-invocation: true。

3 个阶段

Pack 脚手架

pack:<id> → 读 references/pack-scaffold.md；替换阶段 1–2；只有在用户批准后才写入 pack + config 条目。

阶段 2 — 6 项动作

• 移除过时的 compound-engineering.local.md
• 刷新 config.example.yaml
• 缺失时提议创建 config.yaml
• 修复无效的 work_engine_preferences 与 docs_root
• 两项 .gitignore 提议
• 智能体指令提议（知识库提及、compounding 指令、为 ce-noslop 准备的聊天风格指令）

硬规则

• 绝不批量安装可选依赖；仅汇报，让用户按需选取。
• 所有路径都以 git rev-parse --show-toplevel 为锚点解析，不依赖 CWD。
• 维护 config.example.yaml 是阶段 2 的本职；刷新并移除已被取代的 config.local.example.yaml。
• 每一项用户所属文件的改动：先提议，获批后再应用。
• 报告制品根路径 + 哪一层配置提供了它（按阶段 1）。

参考（共 4 份、383 行）

• references/config-template.yaml.md（205）— CE 仓库配置模板
• references/repo-fixes.md（118）— 仓库本地修复
• references/pack-scaffold.md（45）— Compound Pack 脚手架
• references/legacy-codex-tool-map.md（15）— 移除已下线的 Codex 工具映射

1 个脚本：scripts/check-health（732 行）。

跨技能边界