AI编程代理的新流程：先做原型，再做计划

Compound Engineering（CE）是个技能插件，支持 Claude Code、Cursor、Codex、Grok 等代理，名单还在变长。它的新版本想做的事很明确：让 AI 编程代理从「生成一段代码」走向「跑完一整条工作流」。3.22 版在原有基础上加了新功能，也补了不少缺口，整体更接近开箱即用。

CE 的核心哲学写在项目说明里：每项工程工作，都应该让下一个任务更容易。人的判断力集中在两个端点——开始时的规划，结束时的打磨。代理在工作中学到的东西会累积在仓库里，下一个代理不必再碰见同样的细小麻烦。

先做原型，再做计划

版本 3.22 最重要的新技能叫 ce-prototype。过去，计划准备就绪后就直接交给代理动手；现在，先做原型。你不必事先想清楚要尝试什么，当然想清楚也行。把聊天记录、计划或产品本身指给它就行。它会自己判断哪些部分真正需要先做原型，从搞错代价最高的那个开始。如果讨论或画草图仍然没法让团队做决定，ce-brainstorm 和 ce-plan 会主动建议：先做个原型。

原型做完，决策会反馈到计划上。计划此前如果被认为可以进入实施阶段，现在会被打回需求规划。免得有人拿已经过时的方案直接去构建。反过来，如果原型改变了你想建的东西，代理会停下来，把学到的东西交还给你。它不会继续为一个已经不再相关的问题做原型。

合并流程也能堆起来

合并流程也在更新。GitHub 刚把堆叠拉取请求开放为公开预览。简单说，把相互依赖的改动排成一列，审查可以并行推进，不用干等前一步落地。适合什么场景，取决于具体工作和团队习惯。

ce-commit-push-pr 和 ce-babysit-pr 现在都能处理这种 PR 堆栈。代码审查意见、变基，都在范围内。有一点没变：除非你明确要求，技能不会自动合并任何东西。

上一个版本里，CE 已经做过类似的审查升级。ce-doc-review 和 ce-code-review 会自动加入跨模型对抗性审查，让另一个模型对输出提出质疑。上个版本还支持在 Claude Code 里直接调用 Codex。

模型更新后，工作流可能变差

维护自动化工作流有个隐性风险：AI 模型一更新，技能可能突然变差。同样的工作流可能卡住、跳过一个必需步骤，或者多花 3 倍的令牌。

CE 为此新增了 ce-retune，专门用来测量和修复技能。它不靠感觉改提示词。先挖掘技能运行记录，摸清基线。再测量同一个技能定义在不同运行中的差异。然后小步调整，直到指标通过。这个工具必须手动调用，不会自动执行，因为一次完整运行的成本很高。

环境、文档与未完成的兼容

运行环境也在 3.22 里补齐了。Windows 上，以及 Mac 的沙盒 Claude Code 里，插件此前老出同一个问题。看起来装好了，但从未运行。现在 PR 看护、同行代码审查、文档审查都能在这两种环境下正常工作了。这些技能需要的临时文件也没问题。

文档方面，CE 插件默认把计划和学习内容写到 docs/ 目录下。plans、solutions 等按子目录分好。新增的 docs_root 设置可以把整棵文档树挪到指定文件夹，避免和项目已有的文档结构冲突。设置之后是否会影响已有文档，目前没有明确说明。

兼容性还有一块没完成。oh-my-pi 现在原生支持了，但 Agent Plugins 1.0 标准没能完全落地。不同工具对 frontmatter 的处理方式不一致，团队只能先退回来等。目前不清楚 1.0 标准什么时候能全面支持。

CE 团队在等一个不用为每个插件的运行框架手动写转换器的未来。在那之前，适配工作还得一项一项来。

如果你已经装了插件，官方建议很直接：更新插件，把下一个本来要在文档里反复争论的功能交给 ce-prototype 跑一遍。或者等 ce-brainstorm 主动提议。这一版的原型先行、经验累积、按需调校，背后是同一条原则。每份工程产出，都应该让下一个任务更容易。