运营

ce-optimize

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

阶段 0 — 测量门

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

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

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

执行面（三项能力决定怎么跑）

• 持久状态根——宿主指名、跨轮次与上下文重置都活着的可写位置，且在仓库检出之外；没有它，状态放 .context/compound-engineering/ce-optimize/<spec-name>/。
• 轮次结束后唤醒——不占着工具调用、靠外部事件或定时器把技能重新叫起来；没有它，循环就在本会话里跑，握不住的等待以检查点 + 恢复调用结束本轮。
• 分离 worker——结果以推来的 ref、存储文件或宿主消息到达，而不是本地树上的改动；execution.backend: remote 必须有它，没有就让该 spec 跑 worktree。

证据是"在当前工具清单里"或"宿主给的上下文里"；缺一个二进制或环境变量什么也证明不了。退路直接取，不要问。

4 个阶段（顺序不可换）

两个阶段 1 闸门

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

阶段 2 闸门

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

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

1. 声明的全部必达目标均已达成。
2. 达到最大迭代次数。
3. 达到最大活跃小时数。
4. 墙钟兜底时限到达。
5. 花销上限达到。
6. 进入平台期。
7. 用户中断。
8. 已无可运行的假设。

落盘纪律

磁盘上的实验日志是唯一事实来源。写入顺序 = 先测量，再写，验后呈现。CP-0..CP-5 检查点（布局与续接见 references/persistence.md）。

步骤只有跑了才算完成——描述一次测量、一次派发或一个检查点不算做了。有在范围内的活没干完就不结束这一轮；只有在检查点已验证、且要么有有界的自动续跑、要么给了明确的手动恢复交接时，活才可以活过本轮。续接不是重开一轮：只为探测运行与补齐日志缺的 result.yaml 标记进 Phase 0，然后从日志记录的阶段继续、跳过它证明已完成的活；Phase 1 的批准记录绑定 spec 摘要与其批准的上限，缺了或不匹配就重新过那道门。

失败可见与整轮预算

• worker 失败可见：实验提示模板的 failure-evidence 块把当前最优的最差 case 连同「错在哪」一起交给 worker——假设仍然决定实现什么，但这些失败用来对照检查改动，也可能据此换掉整个做法。
• 整轮花销上限：stopping.max_total_cost_usd 封顶整轮支出，在每一笔花钱的派发前核对（含阶段 2 调研与每个带评判的批次），不是只在停止检查时看；上限封的是花销，不是越线后才触发。
• 有界派发：宿主的活跃子代理上限与 execution.max_concurrent（封 worktree 数）是两本账；容量类拒绝按背压处理——排队、等槽位释放后重试，不算实验失败。只有修正调用后仍失败的非容量原因、或已派发实验出错/超时，才标记失败。子代理只在确实有收益时才派发。

仅询问

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

分支与日志

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

参考（共 15 份、2 个智能体、约 2,614 行）

• references/spec.md（107）
• references/measurement.md（168）
• references/loop.md（286）— 含 tick 协议、每结果落盘与批次检查点
• references/wrap-up.md（54）
• references/persistence.md（93）— CP-0..CP-5、状态根布局与续接
• references/usage-guide.md（147）
• references/text-targets.md（51）— 文本目标的评测纪律
• references/optimize-spec-schema.yaml（570）— 完整 YAML schema
• references/experiment-log-schema.yaml（563）— 完整 YAML schema
• references/experiment-prompt-template.md（143）— worker 提示模板（含 failure-evidence 块）
• references/judge-prompt-template.md（117）— 评判提示模板，输出契约精简为纯 JSON
• 4 份示例 spec：expensive-benchmark、hard、judge、text-target
• 2 个智能体：learnings-researcher、repo-research-analyst

ce-retune

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

6 个阶段

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

硬规则

• 绝不为了“让测试通过”而改测试。
• 不是每个停机信号都是敌人 — 动手前先看另一边站着的是谁。
• 看完结果再设定的下限，不是下限。
• 完成 = 下限被越过，或本次运行明确报告某条主张无法支撑。绿灯测试套件 ≠ 完成。
• 候选选择后的 streak 证据要经资格检查：最终确认只用没参与选择该候选的新运行；结果若又指导了下一处修改或再次确认，就进入选择历史，之后的显著性主张不得忽略它——搜索级的显著性主张必须覆盖候选选择与停止规则。改候选重置其 streak，但不重置搜索历史。
• 非目标：压缩文字。精简是陈述条件的副作用。

参考（共 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；或用 standards 起草/刷新编码规范与 review 文档。disable-model-invocation: true。

3 个阶段

Review Docs（standards）

调用要求起草、刷新或更新编码规范 / review 文档时（standards 参数，或同样的自然语言请求），改读 references/project-docs.md、取代阶段 1–2，并把整套文件都起草出来——即便用户只点名了其中一份。完成后回到阶段 3 汇报。评审者要被指向这些 review 文档，书面规则随之刷新。

阶段 1 — 健康检查（scripts/check-health）

一键产物健全性检查：可选工具能力逐项报告（gh、jq、ast-grep、ffmpeg、agent-browser——缺失是可选能力缺口，不是安装失败）；仓库本地配置安全；产物根解析结果 + 由哪一层配置提供；插件版本经 --version 传入核对；跨模型 peer 的 Node ≥ 22.13 前置检查；acpx pin（acpx@0.19.5）与两个 ACP adapter 的版本一致性。

健康报告给出 node 行可用时，可提议预热 npm 缓存（references/acpx-cache-warm.md）：经用户批准后跑 bash "$SKILL_DIR/scripts/check-health" --warm-acpx，把被 pin 的 acpx 及其 codex / claude adapter 提前拉进 npx 缓存，首个 peer 运行不必现场下载；用户拒绝就什么都不拉。

Pack 脚手架

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

阶段 2 — 7 项动作

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

报告点名的每个项目问题都要修，各占 references/repo-fixes.md 的一步：包括报告标为不可用或非法的 ce-work 实施引擎、已退役的标量路由键、以及残缺的休眠 work_engine_preferences / work_engine_effort。

硬规则

• 绝不批量安装可选依赖；仅汇报，让用户按需选取。
• 每一项用户所属文件的改动：先提议，获批后再应用。
• 报告制品根路径 + 哪一层配置提供了它（按阶段 1）。

参考（共 6 份）

• references/config-template.yaml（227）— CE 仓库配置模板，含 gitlab_token 行（fork 的 GitLab 通道令牌）
• references/repo-fixes.md（121）— 仓库本地修复，第 4–10 步
• references/project-docs.md（71）— 起草/刷新编码规范与 review 文档（standards）
• references/pack-scaffold.md（45）— Compound Pack 脚手架
• references/acpx-cache-warm.md（14）— 跨模型 peer 的 npm 缓存预热
• references/legacy-codex-tool-map.md（15）— 移除已下线的 Codex 工具映射

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

跨技能边界