用 ce-work 执行 implementation-ready 计划并把实现路由到指定引擎同时由宿主验证【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin你手上已经有一份ce-plan生成的 implementation-ready 计划想让代理按它把功能做出来同时希望实现这一步由指定的外部引擎比如 Codex 或经 Cursor 走的 Composer 模型来写而验证、提交和发布仍留在当前宿主上完成。compound-engineering-plugin 的ce-work执行技能就是为此设计的它读取计划、按计划的护栏实现代码、连续跑测试最后走完整的质检与 PR 流程实现可以留在当前宿主也可以把有边界的实现单元路由到另一个模型或 harness——但文档明确宿主始终拥有验证verification、canonical commit 和发布shipping。适用前提当前会话有一个可写 git checkout计划位于docs/plans/或你在调用时显式指定路径如果要走外部引擎目标 harness 的 CLI 或认证必须可用。什么时候该用 ce-work以及它拒绝什么ce-work 指南把触发场景列得很清楚一份ce-plan计划已就绪你也准备发布没有计划的小型或中型工作bare-prompt 模式按复杂度分诊恢复一个已部分交付的工作幂等检查避免重复实现想要保守的并行执行或完整的交付流程测试、simplify、review、residual、operational validation、PR。同时要注意它的拒绝规则这直接决定你的计划是否够格计划必须是artifact_readiness: implementation-ready。统一计划如果还是requirements-onlyce-work会拒绝执行直到你用/ce-plan plan-path把它补齐空调用只输入/ce-work会自动挑选docs/plans/中最新一份合格的 implementation-ready 代码计划但如果最新匹配项仍然是 requirements-only、knowledge-work 计划或 approach-plan它会停下来而不是猜标记为execution: knowledge-work的计划走另一条支线读来源、综合、产出交付物跳过整个代码生命周期分支、测试、review、PR 都不发生。如果你拿到的还是 requirements-only 产物先用 ce-plan 的补全流程见 ce-plan 指南再回来执行。准备可写 checkout 与干净状态workspace-setup 参考要求repo-local 写入必须先确认当前是一个可编辑的 git checkout没有可写 checkout 时会跳过 repo-local 写入并报告而不是在仓库外的临时目录里伪造文件变更。对路由到外部引擎这条路径还有一个额外条件外部单元在私有 worktree 中工作如果选中的计划是唯一的脏路径ce-work会先披露并创建一个 plan-only 的 checkpoint commit但任何不相关的脏文件都会让外部路由不可用。所以执行前建议先确认工作区干净或处理好与本计划无关的未提交改动。第一步用计划路径调用 ce-work文档示例计划路径请替换为你自己docs/plans/下的真实文件# 执行一份指定计划并自己走完交付尾巴 /ce-work docs/plans/notification-mute.md # 不带路径自动选 docs/plans 中最新的合格 implementation-ready 代码计划 /ce-work调用后ce-work会按 SKILL.md 定义的分阶段流程走Phase 0 输入分诊识别恢复请求、控制令牌、计划就绪状态Phase 1 建立工作区并先解析引擎、再选执行策略Phase 2 执行Phase 3-4 质检与收尾。计划正文在执行期间只读进度通过 git commit 和任务追踪器体现不写回计划文件。每个任务开始前的幂等检查是这条路径的关键行为如果某个单元的工作已经存在且验证已满足它直接标记完成并继续。这对恢复中断的会话、接手别人的分支、或数周后回到一份部分交付的计划尤其重要。第二步把实现路由到指定引擎默认引擎是宿主本地的 inline/subagent 执行。要改谁来写代码有两种方式且都不改变谁来验证、提交和发布。方式一在当前调用里直接指定per-runce-work 指南给出的示例路径为文档示例替换成你的计划路径# 偏好prefer尝试该路由不可用则回退原生执行并醒目披露 /ce-work use Codex for implementation on docs/plans/2026-07-15-example.md /ce-work implement docs/plans/2026-07-15-example.md with Cursor /ce-work use Cursor with Grok for implementation on docs/plans/2026-07-15-example.md # 强制require路由可用期间固定该外部身份绝不换成其他外部接收方 /ce-work only use Composer for implementation on docs/plans/2026-07-15-example.md # 无计划bare prompt也能指定实现方 /ce-work use Codex to add retry limits to the existing webhook sender偏好与强制的区别文档定义得很明确use X/with X是偏好强度preferce-work尝试该路由若路由不可用继续原生执行并醒目披露 requested-versus-actual想要谁、实际用了谁only use X是强制强度require路由可用期间固定这个外部身份绝不替换成另一个外部接收方但即使路由不可用也只是一次披露后在当前 harness 和会话模型上继续而不是报错或弹选择。判定依据是意图而不是某个固定关键词use Codex 默认按偏好处理must use Codex、only use Codex 这类无歧义的严格表述才按强制处理。另外功能描述、引用文字、示例、文件名里顺带提到的模型名不会激活路由。execution-engines 参考还给出了路由解析的优先级当前任务的显式指定 仍生效的会话偏好 调用方类型化绑定 已在上下文中的项目/用户指令 启用中的 per-checkout 配置 原生执行。低优先级来源只能补充未指定的细节不能与高优先级来源冲突。方式二写入 checkout 配置作为持久默认把有序偏好列表放进 CE 配置文件configuration 指南的 Implementation routing 一节解析顺序为先读.compound-engineering/config.local.yaml再读config.yaml位于仓库根目录work_engine_mode: prefer # off | prefer | require work_engine_preferences: - harness: cursor model: composer - harness: codex model: gpt-5.6 - harness: claude配置字段的文档约束work_engine_modeoff、prefer、require三选一off、注释掉的或非法的 mode 都保持原生默认。off只关掉持久偏好不取消当次会话里的明确意图或调用方绑定harness只接受codex、claude、grok、cursor、opencode五种model可选省略表示该 harness 的配置默认模型。Composer 是经 Cursor 到达的模型族必须写成harness: cursormodel: composer只写{ harness: cursor }指的是 Cursor 的默认模型配置里不要放 CLI 命令或参数——列表表达实现意图具体怎么调由技能内的 adapter 配方决定ce-work按列表顺序逐个 preflight跳过与当前宿主/默认模型等价的条目prefer和require在列表耗尽或候选不可用时都会披露一次尝试过的路由和原因然后回退到当前 harness 和会话模型的原生执行。当前任务的措辞可以为单次运行选择与配置不同的路由而不改配置例如 use Codex for implementation偏好或 only use Composer for implementation强制。团队共享的默认写进config.yaml个人/本 checkout 的选择放config.local.yaml插件升级后文档建议重跑/ce-setup刷新示例配置并诊断已退役或畸形的设置。外部引擎实际执行时发生了什么选择外部路由后cross-model-execution 参考定义了完整事务宿主视角需要理解的核心事实出栈前披露。任何仓库内容离开宿主之前ce-work会披露并持久化记录授权外部执行的来源source、固定接收方与中间链路、暴露的仓库/单元材料、哪些限制是 adapter 强制的哪些是协作的以及 linked worktree 隔离只是防并发误改、不是操作系统级安全沙箱。私有 worktree 与硬时限。每个外部单元从一个干净的已记录 SHA 出发在/tmp/compound-engineering-effective-uid/ce-work/run-id//tmp无法承载可写私有根时回落到$TMPDIR下的 detached linked worktree 中工作。每次 runner 启动都固定一个独立于共享 runner 默认值的两小时硬上限。宿主独占验证与提交。外部 worker 只在自己的 worktree 内编辑完成后把已完成的 worktree保持未提交状态宿主把该 worktree 快照成一个完整的合成 transport commit检查真实变更集把变更应用到 canonical checkout不提交跑权威测试最后创建宿主自己的 canonical commit。worker 的 packet 不包含 canonical commit、push、PR、发布、切换接收方、fallback 或扩大范围的权限。原生单元不受影响。普通同步的原生实现仍留在活跃 checkout 中ce-work不会为每个单元都建临时 worktree只有并发运行的外部单元才使用控制器管理的 detached worktree。验证与结果确认这条路径的成功条件全部由宿主侧证据构成文档给出了明确的检查点单元级每个外部单元进入 fail-stop 的integrate事务后权威验证在 canonical 树上运行验证和干净状态核对都发生在mark-verified之前验证被拒绝或 pre-commit 步骤失败会禁止提交并走恢复流程。任何对 tracked 状态的改动HEAD、分支、index 或 status 可见路径都会让核对失败。计划级所有外部单元提交并清理后计划范围的 Verification Contract 门槛通过控制器的verify-run执行cross-model 参考明确不要报告运行完成直到控制器返回RUN_VERIFIED并存下成功回执。交付级standalone 模式下发布前必须有一个真实完成的ce-code-review回执或者记录两条文档授权的跳过短语之一Code review: skipped (mechanical diff)仅格式、依赖升级、lint、生成文件的机械 diff或Code review: skipped (ce-code-review unavailable)。PR 级每个 PR 描述都包含Post-Deploy Monitoring Validation小节即使确实没有生产影响该小节也要以无影响作为记录的决策存在。路由回执层面运行记录会保留requested_route/actual_route、requested_model/actual_model及回执状态、fallback_reason或null等事实——也就是说你以为用的是 Codex实际跑的是原生这种情况会以披露形式出现在运行记录里而不是被静默吞掉。排查与限制执行中遇到以下现象时文档给出的解释是调用后直接停止并提示需要 ce-plan最新匹配的计划还是 requirements-only。按提示用/ce-plan plan path补齐后再执行不要试图绕过。外部路由不可用不相关的脏文件会让外部路由不可用只有计划文件是唯一脏路径这种状态可以被 checkpoint候选 CLI/认证缺失、或 adapter 无法强制某条必需限制时该候选按不可用处理并继续下一个候选。路由不可用后的行为prefer和require都会披露一次尝试过的路由与原因然后继续原生执行require在路由可用期间绝不换成未请求的外部接收方。运行中断失败、超时、分歧或未集成的运行保留在私有 run 目录用报告的 run id 重新调用恰好恢复一次例如文档示例/ce-work resume run 20260812-1430-ab12run id 替换为你的实际值。恢复不会派发新 worker、不会重跑已完成的验证。不要把 worktree 当安全边界外部 CLI 与宿主以同一 OS 用户运行隔离的是并发的 Git 状态和意外的误改更强的 OS 隔离在该功能范围之外。下一步ce-work独立交付的产物是 commits 和通常通过ce-commit-push-pr打开的 PR计划本身全程只读是否已交付从 git 推导而不是记录在文档里。ce-work 指南在 TL;DR 中给出的后续动作review 这份 PR然后运行/ce-compound把可复用的经验捕获进docs/solutions/供后续ce-plan与ce-work运行使用。【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 ce-work 执行 implementation-ready 计划并把实现路由到指定引擎同时由宿主验证
用 ce-work 执行 implementation-ready 计划并把实现路由到指定引擎同时由宿主验证【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin你手上已经有一份ce-plan生成的 implementation-ready 计划想让代理按它把功能做出来同时希望实现这一步由指定的外部引擎比如 Codex 或经 Cursor 走的 Composer 模型来写而验证、提交和发布仍留在当前宿主上完成。compound-engineering-plugin 的ce-work执行技能就是为此设计的它读取计划、按计划的护栏实现代码、连续跑测试最后走完整的质检与 PR 流程实现可以留在当前宿主也可以把有边界的实现单元路由到另一个模型或 harness——但文档明确宿主始终拥有验证verification、canonical commit 和发布shipping。适用前提当前会话有一个可写 git checkout计划位于docs/plans/或你在调用时显式指定路径如果要走外部引擎目标 harness 的 CLI 或认证必须可用。什么时候该用 ce-work以及它拒绝什么ce-work 指南把触发场景列得很清楚一份ce-plan计划已就绪你也准备发布没有计划的小型或中型工作bare-prompt 模式按复杂度分诊恢复一个已部分交付的工作幂等检查避免重复实现想要保守的并行执行或完整的交付流程测试、simplify、review、residual、operational validation、PR。同时要注意它的拒绝规则这直接决定你的计划是否够格计划必须是artifact_readiness: implementation-ready。统一计划如果还是requirements-onlyce-work会拒绝执行直到你用/ce-plan plan-path把它补齐空调用只输入/ce-work会自动挑选docs/plans/中最新一份合格的 implementation-ready 代码计划但如果最新匹配项仍然是 requirements-only、knowledge-work 计划或 approach-plan它会停下来而不是猜标记为execution: knowledge-work的计划走另一条支线读来源、综合、产出交付物跳过整个代码生命周期分支、测试、review、PR 都不发生。如果你拿到的还是 requirements-only 产物先用 ce-plan 的补全流程见 ce-plan 指南再回来执行。准备可写 checkout 与干净状态workspace-setup 参考要求repo-local 写入必须先确认当前是一个可编辑的 git checkout没有可写 checkout 时会跳过 repo-local 写入并报告而不是在仓库外的临时目录里伪造文件变更。对路由到外部引擎这条路径还有一个额外条件外部单元在私有 worktree 中工作如果选中的计划是唯一的脏路径ce-work会先披露并创建一个 plan-only 的 checkpoint commit但任何不相关的脏文件都会让外部路由不可用。所以执行前建议先确认工作区干净或处理好与本计划无关的未提交改动。第一步用计划路径调用 ce-work文档示例计划路径请替换为你自己docs/plans/下的真实文件# 执行一份指定计划并自己走完交付尾巴 /ce-work docs/plans/notification-mute.md # 不带路径自动选 docs/plans 中最新的合格 implementation-ready 代码计划 /ce-work调用后ce-work会按 SKILL.md 定义的分阶段流程走Phase 0 输入分诊识别恢复请求、控制令牌、计划就绪状态Phase 1 建立工作区并先解析引擎、再选执行策略Phase 2 执行Phase 3-4 质检与收尾。计划正文在执行期间只读进度通过 git commit 和任务追踪器体现不写回计划文件。每个任务开始前的幂等检查是这条路径的关键行为如果某个单元的工作已经存在且验证已满足它直接标记完成并继续。这对恢复中断的会话、接手别人的分支、或数周后回到一份部分交付的计划尤其重要。第二步把实现路由到指定引擎默认引擎是宿主本地的 inline/subagent 执行。要改谁来写代码有两种方式且都不改变谁来验证、提交和发布。方式一在当前调用里直接指定per-runce-work 指南给出的示例路径为文档示例替换成你的计划路径# 偏好prefer尝试该路由不可用则回退原生执行并醒目披露 /ce-work use Codex for implementation on docs/plans/2026-07-15-example.md /ce-work implement docs/plans/2026-07-15-example.md with Cursor /ce-work use Cursor with Grok for implementation on docs/plans/2026-07-15-example.md # 强制require路由可用期间固定该外部身份绝不换成其他外部接收方 /ce-work only use Composer for implementation on docs/plans/2026-07-15-example.md # 无计划bare prompt也能指定实现方 /ce-work use Codex to add retry limits to the existing webhook sender偏好与强制的区别文档定义得很明确use X/with X是偏好强度preferce-work尝试该路由若路由不可用继续原生执行并醒目披露 requested-versus-actual想要谁、实际用了谁only use X是强制强度require路由可用期间固定这个外部身份绝不替换成另一个外部接收方但即使路由不可用也只是一次披露后在当前 harness 和会话模型上继续而不是报错或弹选择。判定依据是意图而不是某个固定关键词use Codex 默认按偏好处理must use Codex、only use Codex 这类无歧义的严格表述才按强制处理。另外功能描述、引用文字、示例、文件名里顺带提到的模型名不会激活路由。execution-engines 参考还给出了路由解析的优先级当前任务的显式指定 仍生效的会话偏好 调用方类型化绑定 已在上下文中的项目/用户指令 启用中的 per-checkout 配置 原生执行。低优先级来源只能补充未指定的细节不能与高优先级来源冲突。方式二写入 checkout 配置作为持久默认把有序偏好列表放进 CE 配置文件configuration 指南的 Implementation routing 一节解析顺序为先读.compound-engineering/config.local.yaml再读config.yaml位于仓库根目录work_engine_mode: prefer # off | prefer | require work_engine_preferences: - harness: cursor model: composer - harness: codex model: gpt-5.6 - harness: claude配置字段的文档约束work_engine_modeoff、prefer、require三选一off、注释掉的或非法的 mode 都保持原生默认。off只关掉持久偏好不取消当次会话里的明确意图或调用方绑定harness只接受codex、claude、grok、cursor、opencode五种model可选省略表示该 harness 的配置默认模型。Composer 是经 Cursor 到达的模型族必须写成harness: cursormodel: composer只写{ harness: cursor }指的是 Cursor 的默认模型配置里不要放 CLI 命令或参数——列表表达实现意图具体怎么调由技能内的 adapter 配方决定ce-work按列表顺序逐个 preflight跳过与当前宿主/默认模型等价的条目prefer和require在列表耗尽或候选不可用时都会披露一次尝试过的路由和原因然后回退到当前 harness 和会话模型的原生执行。当前任务的措辞可以为单次运行选择与配置不同的路由而不改配置例如 use Codex for implementation偏好或 only use Composer for implementation强制。团队共享的默认写进config.yaml个人/本 checkout 的选择放config.local.yaml插件升级后文档建议重跑/ce-setup刷新示例配置并诊断已退役或畸形的设置。外部引擎实际执行时发生了什么选择外部路由后cross-model-execution 参考定义了完整事务宿主视角需要理解的核心事实出栈前披露。任何仓库内容离开宿主之前ce-work会披露并持久化记录授权外部执行的来源source、固定接收方与中间链路、暴露的仓库/单元材料、哪些限制是 adapter 强制的哪些是协作的以及 linked worktree 隔离只是防并发误改、不是操作系统级安全沙箱。私有 worktree 与硬时限。每个外部单元从一个干净的已记录 SHA 出发在/tmp/compound-engineering-effective-uid/ce-work/run-id//tmp无法承载可写私有根时回落到$TMPDIR下的 detached linked worktree 中工作。每次 runner 启动都固定一个独立于共享 runner 默认值的两小时硬上限。宿主独占验证与提交。外部 worker 只在自己的 worktree 内编辑完成后把已完成的 worktree保持未提交状态宿主把该 worktree 快照成一个完整的合成 transport commit检查真实变更集把变更应用到 canonical checkout不提交跑权威测试最后创建宿主自己的 canonical commit。worker 的 packet 不包含 canonical commit、push、PR、发布、切换接收方、fallback 或扩大范围的权限。原生单元不受影响。普通同步的原生实现仍留在活跃 checkout 中ce-work不会为每个单元都建临时 worktree只有并发运行的外部单元才使用控制器管理的 detached worktree。验证与结果确认这条路径的成功条件全部由宿主侧证据构成文档给出了明确的检查点单元级每个外部单元进入 fail-stop 的integrate事务后权威验证在 canonical 树上运行验证和干净状态核对都发生在mark-verified之前验证被拒绝或 pre-commit 步骤失败会禁止提交并走恢复流程。任何对 tracked 状态的改动HEAD、分支、index 或 status 可见路径都会让核对失败。计划级所有外部单元提交并清理后计划范围的 Verification Contract 门槛通过控制器的verify-run执行cross-model 参考明确不要报告运行完成直到控制器返回RUN_VERIFIED并存下成功回执。交付级standalone 模式下发布前必须有一个真实完成的ce-code-review回执或者记录两条文档授权的跳过短语之一Code review: skipped (mechanical diff)仅格式、依赖升级、lint、生成文件的机械 diff或Code review: skipped (ce-code-review unavailable)。PR 级每个 PR 描述都包含Post-Deploy Monitoring Validation小节即使确实没有生产影响该小节也要以无影响作为记录的决策存在。路由回执层面运行记录会保留requested_route/actual_route、requested_model/actual_model及回执状态、fallback_reason或null等事实——也就是说你以为用的是 Codex实际跑的是原生这种情况会以披露形式出现在运行记录里而不是被静默吞掉。排查与限制执行中遇到以下现象时文档给出的解释是调用后直接停止并提示需要 ce-plan最新匹配的计划还是 requirements-only。按提示用/ce-plan plan path补齐后再执行不要试图绕过。外部路由不可用不相关的脏文件会让外部路由不可用只有计划文件是唯一脏路径这种状态可以被 checkpoint候选 CLI/认证缺失、或 adapter 无法强制某条必需限制时该候选按不可用处理并继续下一个候选。路由不可用后的行为prefer和require都会披露一次尝试过的路由与原因然后继续原生执行require在路由可用期间绝不换成未请求的外部接收方。运行中断失败、超时、分歧或未集成的运行保留在私有 run 目录用报告的 run id 重新调用恰好恢复一次例如文档示例/ce-work resume run 20260812-1430-ab12run id 替换为你的实际值。恢复不会派发新 worker、不会重跑已完成的验证。不要把 worktree 当安全边界外部 CLI 与宿主以同一 OS 用户运行隔离的是并发的 Git 状态和意外的误改更强的 OS 隔离在该功能范围之外。下一步ce-work独立交付的产物是 commits 和通常通过ce-commit-push-pr打开的 PR计划本身全程只读是否已交付从 git 推导而不是记录在文档里。ce-work 指南在 TL;DR 中给出的后续动作review 这份 PR然后运行/ce-compound把可复用的经验捕获进docs/solutions/供后续ce-plan与ce-work运行使用。【免费下载链接】compound-engineering-pluginOfficial Compound Engineering plugin for Claude Code, Codex, Cursor, and more项目地址: https://gitcode.com/GitHub_Trending/ev/compound-engineering-plugin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考