ce-work-beta

工作执行命令

高效执行工作，在保证质量的同时完成各项功能。

简介

此命令接受一份工作文档（计划或规范）或一条描述工作的简短提示，并系统地执行其中的内容。重点在于交付完整功能：快速理解需求、遵循现有模式，并在整个过程中保持质量。

Beta 推出说明： 如果要试用 Codex 委派，请手动调用 ce-work-beta。在 Beta 期间，规划和工作流交接仍指向稳定版 ce-work，以避免双路径编排的复杂性。

输入文档

<input_document> #$ARGUMENTS </input_document>

参数解析

解析 $ARGUMENTS，查找以下可选标记。在将剩余内容解释为计划文件路径或简短提示之前，移除所有已识别的标记。

标记	示例	效果
delegate:codex	delegate:codex	为计划执行启用 Codex 委派模式
delegate:local	delegate:local	即使配置中已启用委派，也停用委派

所有标记均为可选。未提供标记时，按下方的解析链处理。

模糊启用： 也将「使用 codex」「委派给 codex」「codex 模式」或「委派模式」等表示委派意图的祈使短语识别为等同于 delegate:codex。在提示中单纯提及「codex」（例如「修复 codex 转换器的错误」）不得启用委派；只有明确表示委派意图时才启用。

模糊停用： 也将「不要使用 codex」「本地模式」「标准模式」等短语识别为等同于 delegate:local。

设置解析链

从参数中提取令牌后，按以下优先级链解析委派状态：

1. 参数标志 -- 当前调用中的 delegate:codex 或 delegate:local（优先级最高）
2. 配置文件 -- 从下方的配置块中提取设置。work_delegate 的值为 codex 时启用委派；值为 false 时停用。
3. 硬默认值 -- false（关闭委派）

读取配置。 仓库根目录已在技能加载时预先解析： !git rev-parse --show-toplevel 2>/dev/null || true

如果上面的行是绝对路径，则将其用作 <repo-root>。如果它为空或仍显示反引号命令字符串（即未执行预解析的非 Claude 执行环境），则在运行时使用 shell 工具运行 git rev-parse --show-toplevel，以解析 <repo-root>。然后使用原生文件读取工具读取 <repo-root>/.compound-engineering/config.local.yaml（例如，Claude Code 中的 Read，Codex 中的 read_file）。如果无法解析根目录或文件不存在，则所有设置均回退到默认值。否则，提取下方列出的键对应的值。

如果某个设置的值无法识别，则回退到该设置的硬默认值。对于没有硬默认值的可选设置（work_delegate_model、work_delegate_effort），无法识别或无法解析的值将解析为未设置——在 codex exec 调用中省略相应标志，让 Codex 从 ~/.codex/config.toml 解析。切勿将无效值传入 CLI 标志。

配置键：

• work_delegate -- codex 或默认值 false
• work_delegate_consent -- true 或默认值 false
• work_delegate_sandbox -- yolo（默认值）或 full-auto
• work_delegate_decision -- auto（默认值）或 ask
• work_delegate_model -- 要使用的 Codex 模型。可选 — 未设置或无法解析时，使用用户 ~/.codex/config.toml 中的默认值。直接传递 — 任何非空字符串均视为有效；只有 YAML 解析失败或值为空时，才解析为未设置。
• work_delegate_effort -- minimal、low、medium、high 或 xhigh 之一。可选 — 未设置或值不在此枚举中时，解析为未设置，并使用用户 ~/.codex/config.toml 中的默认值。

存储解析后的状态，供后续使用：

• delegation_active -- 布尔值，表示是否启用委派模式
• delegation_source -- argument、config 或 default -- 委派状态的解析来源（环境保护机制据此决定通知详略）
• sandbox_mode -- yolo 或 full-auto（来自配置或默认值 yolo）
• consent_granted -- 布尔值（来自配置 work_delegate_consent）
• delegate_model -- 配置中的字符串，或未设置（交由 Codex 配置处理）
• delegate_effort -- 配置中的字符串，或未设置（交由 Codex 配置处理）。批次级 effort 选择的下限；不直接传入 codex exec。
• effective_effort -- 按批次派生的值（default | medium | high | xhigh），每个批次开始前根据 delegate_effort 和所选级别，按照 references/codex-delegation-workflow.md（“Per-Batch Effort”）计算。用于 codex exec 调用，替代 delegate_effort。

---

执行工作流

阶段 0：输入分流

根据 <input_document> 中提供的内容，确定如何继续。

计划文档（输入是现有计划或规范的文件路径）：先阅读计划的元数据——Markdown 计划的 YAML frontmatter，或 HTML 计划中可见的标题文本（两种格式包含相同字段）。如果其中包含 execution: knowledge-work，则这是一个非代码计划——阅读 references/non-code-execution.md，并遵循其中的例外说明，而不是继续本工作流的其余部分。否则（字段缺失或为 execution: code）→ 跳转到阶段 1，运行常规代码生命周期。（标记检查位于此处的计划文档处理流程中，因为检测标记需要先有文件；下文的“直接提示词”不受影响。）

直接提示词（输入是工作描述，而不是文件路径）：

1. 扫描工作区

   • 根据提示词，确定可能需要更改的文件
   • 找出这些区域现有的测试文件（搜索导入、引用或与实现文件名称相同的测试/规范文件）
   • 记录受影响区域的本地模式和约定

2. 评估复杂度并确定路径

   复杂度	信号	操作
   简单	1–2 个文件，没有行为变化（拼写错误、配置、重命名）	继续执行阶段 1 的第 2 步（环境设置），然后直接实现——无需任务列表或执行循环。如果更改涉及承载行为的代码，则应用测试发现
   小 / 中	范围明确，少于约 10 个文件	根据发现结果构建任务列表。继续执行阶段 1 的第 2 步
   大型	涉及多个方面、需要架构决策、10 个以上文件，或涉及身份验证/付款/迁移	告知用户，这项工作可以通过 /ce-brainstorm 或 /ce-plan 来梳理边缘情况和范围界限。尊重用户的选择。如果继续，则构建任务列表并继续执行阶段 1 的第 2 步

---

阶段 1：快速开始

1. 阅读计划并澄清 （如果从阶段 0 的直接提示词流程进入，则跳过）

   • 完整阅读工作文档
   • 将计划视为决策依据，而不是执行脚本
   • 如果计划包含 Implementation Units、Work Breakdown、Requirements（或旧版 Requirements Trace）、Files、Test Scenarios 或 Verification 等章节，请将其作为执行的主要依据
   • 检查每个实现单元中的 Execution note —— 这些内容体现了该单元的计划执行方式（例如，测试优先或特征描述优先）。创建任务时请注意这些内容。
   • 检查是否有 Deferred to Implementation 或 Implementation-Time Unknowns 章节 —— 这些是规划者有意留给你在执行过程中解决的问题。开始前请先注意这些问题，以便据此调整方法，而不是在任务进行中才措手不及
   • 检查是否有 Scope Boundaries 章节 —— 其中列出了明确不在目标范围内的事项。如果实现过程中开始偏向相邻工作，请回头参考这些边界
   • 查看计划中提供的任何参考资料或链接
   • 如果用户明确要求在本次会话中采用 TDD、测试优先或特征描述优先的执行方式，即使计划中没有 Execution note，也要遵照该要求
   • 如果有任何不清楚或模糊之处，现在就提出澄清问题
   • 如果上面需要提出澄清问题，请就已解决的答案征求用户批准。如果无需澄清，则无需单独征求批准即可继续 —— 计划范围是计划的权威依据，无需重新协商
   • 切勿跳过此步骤 —— 现在提出问题，总比做错要好
   • 执行期间不要编辑计划正文。 计划是决策依据；进度记录在 Git 提交和任务跟踪器中，而不是计划里。ce-work 不会修改计划 —— 是否已交付应根据 Git 状态判断，而不是记录在文档中。旧版计划可能会在单元标题中包含 - [ ] / - [x] 标记，或包含 status: 字段 —— 请忽略这些状态；每个单元是否完成，应在执行期间通过读取当前文件状态来判断。

2. 设置环境

   首先，检查当前分支：

   current_branch=$(git branch --show-current)
   default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
   
   # Fallback if remote HEAD isn't set
   if [ -z "$default_branch" ]; then
     default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
   fi
   

   如果当前已在功能分支上（不是默认分支）：

   首先，检查分支名称是否有意义 —— 像 feat/crowd-sniff 或 fix/email-validation 这样的名称能让后续读者了解工作内容。自动生成的 worktree 名称（例如 worktree-jolly-beaming-raven）或其他含义不明的名称则不行。

   如果分支名称没有意义或是自动生成的，请建议先重命名再继续：

   git branch -m <meaningful-name>
   

   根据计划标题或工作描述拟定新名称（例如 feat/crowd-sniff）。将重命名作为推荐选项，与按原样继续并列呈现。

   然后询问：“继续在 [current_branch] 上工作，还是创建新分支？”

   • 如果选择继续（无论是否重命名），请进入第 3 步
   • 如果选择新建，请按下面的选项 A 或 B 操作

   如果当前在默认分支上，请选择如何继续：

   选项 A：创建新分支

   git pull origin [default_branch]
   git checkout -b feature-branch-name
   

   使用根据工作内容拟定的有意义的名称（例如 feat/user-authentication、fix/email-validation）。

   选项 B：使用 worktree（并行开发时推荐）

   skill: ce-worktree
   # Ensures isolation: detects an existing worktree, prefers the harness's
   # native worktree tool, else creates one from the default branch
   

   选项 C：继续在默认分支上工作

   • 需要获得用户明确确认
   • 只有在用户明确说“是，提交到 [default_branch]”后才能继续
   • 未经明确授权，绝不能直接向默认分支提交

   建议：以下情况请使用 worktree：

   • 需要同时处理多个功能
   • 希望在试验期间保持默认分支干净
   • 计划频繁切换分支

3. 创建任务列表 （如果 Phase 0 已创建任务列表，或 Phase 0 将其判定为简单任务，则跳过）

   • 使用平台的任务跟踪工具（Claude Code 中的 TaskCreate/TaskUpdate/TaskList、Codex 中的 update_plan，或其他运行环境中的等效工具），将计划拆分为可执行的任务
   • 根据计划中的实施单元、依赖关系、文件、测试目标和验证标准推导任务
   • 如果计划为实施单元定义了 U-ID，则在任务标题中保留该单元的 U-ID 前缀（例如，“U3：增加解析器覆盖范围”）。这样一来，阻塞项引用、延后工作说明和最终摘要都能与计划使用的同一标识符对应，确保即使计划经过编辑，进度和可追溯性仍清晰明确
   • 如果单元中有 Execution note，将其纳入任务
   • 实施每个单元前，先阅读其 Patterns to follow 字段——其中会指出需要参照的具体文件或惯例
   • 将每个单元的 Verification 字段作为该任务主要的“完成”信号
   • 不要期待计划中包含实施代码、微步骤 TDD 指令或确切的 shell 命令
   • 明确任务之间的依赖关系
   • 按照优先级排序，优先处理需要先完成的事项
   • 包含测试和质量检查任务
   • 确保任务具体且可完成

4. 选择执行策略

   委派路由关卡： 如果 delegation_active 为 true 且输入是计划文件（而非单独的提示词），请阅读 references/codex-delegation-workflow.md，并遵循其中的 Pre-Delegation Checks 和 Delegation Decision 流程。如果所有检查均通过且决定继续委派，则强制采用串行执行，并使用该工作流的批次执行循环直接进入 Phase 2。如果任何检查禁用了委派，则转而采用下方的标准策略表。如果委派已启用，但输入是单独的提示词（没有计划文件），则将 delegation_active 设为 false，并简要说明：“Codex 委派需要计划文件——使用标准模式。”然后继续进行标准策略选择。

   创建任务列表后，根据计划的规模和依赖结构决定如何执行：

   策略	适用情况
   内联执行	1–2 个小任务，或需要在执行过程中与用户交互的任务。单独提示词任务的默认策略——单独的提示词很少能提供足够的结构化上下文来证明应派发子 Agent
   串行子 Agent	3 个及以上任务，且任务之间存在依赖关系。每个子 Agent 都会获得一个全新的上下文窗口，专注于一个单元，从而避免多个任务导致上下文退化。需要计划单元元数据（Goal、Files、Approach、Test scenarios）
   并行子 Agent	3 个及以上任务，且通过并行安全检查（如下）。同时派发彼此独立的单元，待其前置任务完成后再执行有依赖关系的单元。需要计划单元元数据

   并行安全检查——选择并行派发前必须执行：

   1. 根据每个候选单元的 Files: 部分，建立文件与单元的映射（包括 Create、Modify 和 Test 路径）
   2. 检查是否存在交集——同一文件路径出现在 2 个及以上单元中即表示存在重叠
   3. 如果发现重叠且无法使用工作树隔离：降级为串行子 Agent。记录原因（例如，“单元 2 和 4 共用 config/routes.rb——采用串行派发”）。串行子 Agent 仍可隔离上下文窗口，避免共享目录中的写入竞争。
   4. 如果发现重叠但可以使用工作树隔离：并行派发仍然安全——子 Agent 会在隔离环境中工作，重叠会表现为可预测的合并冲突，由编排器通过下方的批次后处理流程解决。记录预期的重叠，以便批次后处理流程了解可能发生冲突的合并。 即使文件没有重叠，并行子 Agent 共用编排器的工作目录也会面临 Git 索引冲突（并发暂存或提交会损坏索引），以及测试干扰（并发运行的测试会获取彼此尚未完成的更改）。使用工作树隔离可以消除这两类问题；下述共用目录回退限制可缓解这些问题。

   子 Agent 隔离 — 为每个并行子 Agent 分配独立的工作树：

   • **Claude Code（Agent 工具）：**传入 isolation: "worktree" 和 run_in_background: true。执行环境会在 .claude/worktrees/agent-<id> 下为每个子 Agent 创建独立工作树，并使用独立分支。依赖此机制前，请确认 .claude/worktrees/ 已被 Git 忽略。
   • 其他平台若没有内置工作树隔离：子 Agent 共用编排器的目录。

   分派子 Agent时使用可用的子 Agent 或任务生成机制。对每个单元，为子 Agent 提供：

   • 完整的计划文件路径（以提供整体上下文）
   • 特定单元的 Goal、Files、Approach、Execution note、Patterns、Test scenarios 和 Verification
   • 与该单元相关且已解决的待定问题
   • 指示：检查该单元的测试场景是否涵盖所有适用类别（正常路径、边缘情况、错误路径、集成），并在编写测试前补齐遗漏项

   共用目录回退限制 — 仅在无法使用工作树隔离时适用：

   • 指示每个子 Agent：“不要暂存文件（git add）、创建提交或运行项目测试套件。所有并行单元完成后，由编排器负责测试、暂存和提交。”
   • 这些限制可避免并发子 Agent 之间的 Git 索引冲突和测试干扰。
   • 启用工作树隔离后，请省略这些限制 — 子 Agent 可以在各自的工作树分支中暂存、提交并运行其单元的测试。

   **权限模式：**分派子 Agent 时省略 mode 参数，以便应用用户配置的权限设置。不要传入 mode: "auto" — 这会覆盖 bypassPermissions 等用户级设置。

   串行模式下，每个子 Agent 完成后：

   1. 检查子 Agent 的差异 — 确认更改符合单元范围和 Files: 列表
   2. 运行相关测试套件，确认工作树状态正常
   3. 如果测试失败，先诊断并修复，再继续 — 不要在工作树状态异常时分派有依赖关系的单元
   4. 更新任务列表（不要编辑计划正文 — 进度由提交记录）
   5. 分派下一个单元 在工作树隔离模式下，批次中的所有并行子 Agent 完成后：
   6. 等待当前并行批次中的每个子 Agent 完成。
   7. 按依赖顺序处理每个已完成的子 Agent：检查其工作树相对于协调者分支的差异。如果子 Agent 没有自行提交更改，则在该工作树中暂存并提交。
   8. 按依赖顺序，将每个子 Agent 的分支依次合并到协调者分支。如果出现合并冲突，请中止合并（git merge --abort），并针对当前已合并的树重新派发冲突单元，改为串行执行——私下手动解决冲突会偏向其中一方，丢弃另一单元的意图。（并行安全检查中预测到的重叠会在此处表现为冲突，而不是在共享目录模式下造成无声的数据丢失。）
   9. 每次合并后，运行相关测试套件。如果测试失败，先诊断并修复，再合并下一个分支。
   10. 更新任务列表（进度由合并提交体现）。
   11. 合并后，移除每个子 Agent 的工作树并删除其分支。使用子 Agent 结果中返回的绝对路径和分支名称。
       • 先解锁工作树——运行环境会锁定每个子 Agent 的工作树：git worktree unlock <absolute-path>
       • 移除工作树：git worktree remove <absolute-path>
       • 删除分支：git branch -d <branch-name>（默认情况下，分支的生命周期长于工作树；若不清理，分支会累积为孤立分支。小写的 -d 会拒绝删除尚未合并的分支，这是我们需要的安全保障——如果命令失败，请先调查，切勿强制删除）
   12. 派发下一批独立单元，或下一个依赖单元。

   在共享目录回退模式下，批次中的所有并行子 Agent 完成后：

   1. 在处理任何结果之前，等待当前并行批次中的每个子 Agent 完成。
   2. 交叉检查发现的文件冲突：比较批次中所有子 Agent 实际修改的文件（不只是其声明的 Files: 列表）。子 Agent 可能会创建或修改规划时未预料到的文件——这是预期情况，因为计划描述的是做什么，而不是怎么做。只有同一批次中的 2 个或更多子 Agent 修改了同一文件时，才算冲突。在共享工作目录中，只会保留最后写入的版本——其他单元对该文件所做的更改都会丢失。如果发现冲突：先提交所有单元中无冲突的文件，再针对共享文件串行重新运行受影响的单元，让每个单元都基于其他单元已提交的工作继续。
   3. 按依赖顺序处理每个已完成的单元：检查差异，运行相关测试套件，仅暂存该单元的文件，并根据该单元的目标编写符合 Conventional Commits 规范的提交信息。
   4. 如果提交某个单元的更改后测试失败，请先诊断并修复，再提交下一个单元。
   5. 更新任务列表（不要编辑计划正文——刚完成的提交会体现进度）。
   6. 派发下一批独立单元，或下一个依赖单元。

第 2 阶段：执行

1. 任务执行循环

   按优先级顺序处理每项任务：

   while (tasks remain):
     - Mark task as in-progress
     - Read any referenced files from the plan or discovered during Phase 0
     - **If the unit's work is already present and matches the plan's intent** (files exist with the expected capability, or the unit's `Verification` criteria are already satisfied by the current code), the work has likely shipped on a prior branch or session. Verify it matches, mark the task complete, and move on. Do not silently reimplement.
     - Look for similar patterns in codebase
     - Find existing test files for implementation files being changed (Test Discovery — see below)
     - If delegation_active: branch to the Codex Delegation Execution Loop
       (see `references/codex-delegation-workflow.md`)
     - Otherwise: implement following existing conventions
     - Add, update, or remove tests to match implementation changes (see Test Discovery below)
     - Run System-Wide Test Check (see below)
     - Run tests after changes
     - Assess testing coverage: did this task change behavior? If yes, were tests written or updated? If no tests were added, is the justification deliberate (e.g., pure config, no behavioral change)?
     - Mark task as completed
     - Evaluate for incremental commit (see below)
   

   如果某个单元包含 Execution note，请遵循其中的要求。对于测试优先的单元，先为该单元编写失败的测试，再进行实现。对于特征刻画优先的单元，在更改行为前记录现有行为。对于没有 Execution note 的单元，灵活务实地推进。

   执行规范：

   • 采用测试优先方式时，不要在同一步中编写测试和实现
   • 不要跳过验证新测试在实现修复或功能前确实会失败的步骤
   • 采用测试优先方式时，不要超出当前行为范围进行过度实现
   • 对于简单重命名、纯配置和纯样式工作，可跳过测试优先流程 测试发现 — 在实现文件更改之前，先找出其现有测试文件（搜索导入、引用实现文件或命名模式与其相同的测试/规范文件）。如果计划指定了测试场景或测试文件，请从这些内容入手，然后检查计划可能未列出的其他测试覆盖。实现文件的更改应配有相应的测试更新——新行为添加新测试，行为变更修改测试，行为删除则删除或更新测试。

   测试场景完整性 — 在为具有功能的单元编写测试之前，检查计划的 Test scenarios 是否涵盖适用于该单元的所有类别。如果缺少某个类别，或场景描述含糊（例如，“验证正确”却未说明输入和预期结果），请在编写测试前根据该单元自身的上下文补充：

   类别	适用情况	缺少时的推导方法
   正常路径	始终适用于具有功能的单元	阅读单元的 Goal 和 Approach，了解核心输入/输出组合
   边缘情况	单元存在有意义的边界时（输入、状态、并发）	找出边界值、空值/nil 输入和并发访问模式
   错误/失败路径	单元存在失败模式时（验证、外部调用、权限）	列举单元应拒绝的无效输入、应执行的权限/身份验证拒绝，以及应处理的下游故障
   集成	单元跨越多个层时（回调、中间件、多服务）	找出跨层调用链，并编写一个不使用 mock 的场景来覆盖它

   系统级测试检查 — 在将任务标记为完成之前，暂停并自问：

   问题	应采取的措施
   运行时会触发什么？ 回调、中间件、观察者、事件处理器——从你的更改向外追踪两层。	阅读实际代码（而非文档），检查你接触到的模型上的回调、请求链中的中间件，以及 after_* 钩子。
   我的测试是否覆盖真实调用链？ 如果每个依赖都被 mock，测试只能证明你的逻辑单独运行时有效——无法说明交互情况。	至少编写一个使用真实对象并贯穿完整回调/中间件调用链的集成测试。交互涉及的层不要使用 mock。
   失败会留下孤立状态吗？ 如果代码在调用外部服务之前持久化了状态（数据库行、缓存、文件），服务失败时会发生什么？重试会创建重复项吗？	使用真实对象追踪失败路径。如果在高风险调用前创建了状态，就测试失败时是否会清理，或重试是否具备幂等性。
   还有哪些接口会暴露此功能？ Mixins、DSL、替代入口（Agent、Chat、ChatMethods）。	在相关类中搜索该方法/行为。如果需要保持一致性，现在就补上，而不是留待后续。
   各层的错误处理策略是否一致？ 重试中间件 + 应用层回退 + 框架错误处理——它们是否会冲突或造成重复执行？	列出各层的具体错误类。确认 rescue 列表与底层实际抛出的错误相符。

   何时跳过： 叶节点更改，没有回调、状态持久化或并行接口。如果更改纯属增量（新增辅助方法、新增视图 partial），这项检查只需 10 秒，结论就是“没有触发项，跳过”。

   最需要关注的情况： 涉及带回调的模型、带回退/重试的错误处理，或通过多个接口暴露的功能的任何更改。

2. 增量提交

   完成每项任务后，评估是否创建增量提交：

   提交时机	不要提交的时机
   一个逻辑单元已完成（模型、服务、组件）	仅完成更大单元的一小部分
   测试通过且取得了有意义的进展	测试失败
   即将切换上下文（后端 → 前端）	纯粹搭建框架，没有实际行为
   即将尝试有风险或不确定的更改	需要使用“WIP”作为提交信息

   判断准则：“我能否写出一条描述完整且有价值更改的提交信息？如果可以，就提交。如果提交信息只能写成‘WIP’或‘部分完成 X’，就先等等。”

   如果计划中包含实现单元，可将其作为划分提交边界的起点，但要根据实现过程中发现的情况灵活调整。一个单元如果比预期更大，可能需要拆成多个提交；几个相关的小单元也可能合并提交。根据每个单元的目标撰写提交信息。

   提交工作流：

   # 1. Verify tests pass (use project's test command)
   # Examples: bin/rails test, npm test, pytest, go test, etc.
   
   # 2. Stage only files related to this logical unit (not `git add .`)
   git add <files related to this logical unit>
   
   # 3. Commit with conventional message
   git commit -m "feat(scope): description of this unit"
   

   **处理合并冲突：**如果在变基或合并期间出现冲突，请立即解决。增量提交让冲突解决更容易，因为每个提交都小而专注。

   **注意：**增量提交使用简洁、符合约定的提交信息，不包含署名页脚。最终的 Phase 4 提交/PR 会包含完整署名信息。

   **并行子 Agent 模式：**提交所有权按隔离模式划分（参见 Phase 1 Step 4）：

   • **Worktree 隔离：**子 Agent 可以在自己的 worktree 分支中暂存并提交；编排者会在批次结束后按依赖顺序合并这些分支。
   • **共享目录回退模式：**子 Agent 不提交；整个并行批次完成后，编排者为每个单元暂存并提交。

3. 遵循现有模式

   • 计划应引用相似代码——先阅读相关文件
   • 严格遵循命名约定
   • 尽可能复用现有组件
   • 遵循上下文中已有的项目编码规范
   • 不确定时，搜索相似实现

4. 持续测试

   • 每次重大更改后运行相关测试
   • 不要等到最后才测试
   • 立即修复失败
   • 为新行为添加测试，为行为变更更新测试，为已删除的行为移除测试
   • **使用模拟对象的单元测试可验证独立逻辑。使用真实对象的集成测试可验证各层能否协同工作。**如果更改涉及回调、中间件或错误处理，就两种测试都需要。

5. 边做边简化

   完成一组相关实现单元后（或每完成 2-3 个单元），检查近期修改的文件，寻找简化机会——合并重复模式、提取共享辅助函数，并提高代码复用率和效率。使用子 Agent 时尤其值得这样做，因为每个 Agent 都在独立上下文中工作，无法看到各单元之间逐渐形成的模式。

   不要在每个单元完成后都进行简化——早期看似重复的模式，之后可能会有意分化。等到自然的阶段边界，或发现复杂性不断累积时再进行简化。

   如果有 ce-simplify-code，请在阶段边界调用它（尤其是在进入 Phase 3 前，且 diff >=30 行时）。否则，请自行检查修改过的文件，寻找复用和整合的机会。

6. Figma 设计同步（如适用）

   对于有 Figma 设计稿的 UI 工作：

   • 根据设计规范实现组件
   • 阅读 references/agents/figma-design-sync.md，并使用该本地提示词初始化一个通用子 Agent，让它对照 Figma 设计稿检查实现。不要按类型/名称派发独立 Agent。
   • 修复发现的视觉差异
   • 重复检查，直到实现与设计稿一致

7. 前端设计指导（如适用）

   对于没有 Figma 设计稿的 UI 任务——如果实现涉及视图、模板、组件、布局或页面文件，创建用户可见的路由，或计划中明确包含 UI/前端/设计相关内容：

   • 遵循此技能中包含的前端指导和当前仓库的说明：保留现有设计系统规范，使用真实的 UI 控件和状态，确保布局具有响应性，并检查文本不会溢出或重叠。
   • 如果可以使用浏览器工具，请在最终验证前检查桌面和移动端宽度下的变更后 UI。如果无法访问浏览器，请进行代码层面的响应式布局检查，并记录浏览器验证不可用。
   • 如果变更会影响用户可见内容，仍须在第 4 阶段截取屏幕截图。

8. 跟踪进度

   • 完成任务时及时更新任务列表
   • 记录任何阻碍或意外发现
   • 如果范围扩大，创建新任务
   • 及时向用户通报重要进展
   • 如果计划为实施单元定义了 U-ID，或计划或源文档包含稳定的 R-ID（以及可选的 A/F/AE ID），请在阻碍、延期工作说明、任务摘要和最终验证中引用这些 ID，而非在常规状态更新中引用。U-ID 用于在计划编辑时锚定单元；R/A/F/AE 用于在头脑风暴与计划交接时锚定产品意图。使用计划提供的 ID，不要自行编造。这样既能保留可追溯性，也不会让关键信息淹没在杂项中。

第 3-4 阶段：质量检查和收尾工作

完成第 2 阶段的所有任务并进入质量检查后，请阅读 references/shipping-workflow.md，了解完整的交付工作流：质量检查、代码审查、最终验证、创建 PR 和通知。

---

Codex 委派模式

参数解析后，如果 delegation_active 为 true，请阅读 references/codex-delegation-workflow.md，了解完整的委派工作流：预检查、批次处理、提示词模板、执行循环和结果分类。

---

关键原则

快速开始，更快执行

• 在开始时一次性获取所需澄清，然后执行
• 不要等待完全理解后才行动——提出问题并继续推进
• 目标是完成功能，而不是制定完美流程

计划是你的指南

• 工作文档应引用类似代码和模式
• 加载这些参考并遵循它们
• 不要另起炉灶——与现有做法保持一致

边做边测

• 每次变更后运行测试，不要等到最后
• 立即修复失败
• 持续测试可避免重大意外

将质量融入流程

• Tier 1 可用或符合 Tier 2 条件时进行审查（参见 shipping-workflow.md）

交付完整功能

• 继续推进前，确保所有任务都已完成
• 不要让功能只完成 80%
• 完整交付的功能胜过未能交付的完美功能

应避免的常见问题

• 分析瘫痪——不要过度思考，阅读计划并执行
• 跳过澄清问题——现在就提问，不要等到做错了再问
• 忽略计划中的参考——计划添加链接自有其原因
• 最后才测试——持续测试，否则之后会付出代价
• 忘记跟踪进度——边做边更新任务状态，否则会忘记哪些已完成
• 只完成 80%——完成整个功能，不要过早转向其他工作
• 无故跳过审查——有 Tier 1 时使用 Tier 1；仅在符合 shipping-workflow.md 中的条件时升级到 Tier 2；如果两者都跳过，请记录原因
• 把计划重新划分为按人工时间安排的阶段——计划中的实施单元定义了执行范围。不要估算每个单元所需的人工小时，不要提出跨多天的拆分，也不要让用户选择“本次会话”要做哪些单元。Agent 的执行速度远快于人工；上下文窗口压力应通过派遣子 Agent（第 1 阶段第 4 步）解决，而不是分阶段会话。如果计划文件的输入确实太大，无法一次执行，请直言并建议用户返回 /ce-plan 缩小范围——不要以分阶段会话作为权宜之计。对于仅有提示词的输入，第 0 阶段的 Large 路由已经会处理过大的工作