第二个工作流：让它改代码

准备一个 worktree

如果这个仓库已经有一个你用来开发、运行过项目的 worktree，直接进入第 2 步。

还没有的话，现在建一个。两个任务同时执行，各需要一个工作区：主仓库算一个，再加一个 git worktree 就够了，原因见工作区。

在主仓库根目录运行下面的命令，把 my-app 换成你的项目目录名：

git worktree add ../my-app-wt-1 -b wt-1

它在主仓库旁边新建目录 my-app-wt-1，并检出一条新分支 wt-1。这条分支只是占位，任务开始时，CodeDAG 会把这个目录切换到任务分支上。

新目录里只有纳入版本控制的文件。如果你的项目要先安装依赖才能运行测试，比如 node_modules 或 Python 虚拟环境，在新目录里照常安装一遍；.env 这类没有提交的本地配置文件，也要复制过去。任务 2 和任务 3 会在各自的工作区里运行测试，缺了这些，在 worktree 里执行的那个任务就跑不起测试。

把 worktree 登记到 CodeDAG

如果你在快速开始回答 Select your repository setup method 时已经选了 1 或 2，这一步也可以跳过。

当时选的是 4 的话，回到主仓库根目录，重新运行初始化：

cdg init

它会依次问几个问题，第一个问题的回答与快速开始时不同：

1. Select your repository setup method：选 1. I have set up git worktrees for this project。CodeDAG 会自动找出这个仓库的 worktree，不需要你输入路径，接着让你勾选要登记为副本的那些。刚建的 my-app-wt-1 默认已勾选，回车确认即可；Claude Code 和 Codex 为自己的会话创建的 worktree 默认不勾选。
2. File ".codedag/.gitignore" already exists. How would you like to handle this file?：选 3. Keep All。.codedag/ 里的设置和模板文件是快速开始时生成的，Keep All 让它们全部保持原样。本机设置文件也随之保留，所以这一次不会再问你默认 Agent。
3. Update maxConcurrency to 2?：这个项目现在有两个工作区，而保留下来的并发上限还是 1，初始化会问你要不要改成 2。默认是 Yes，回车即可。

如果快速开始时没有安装 CodeDAG Guide 插件，还会再问一次是否安装，按你的需要回答即可。完成后，输出的开头是这样的：

✔ Project initialized successfully!

  Project Repository: /Users/you/my-app
  Project Git workflow stays unchanged.
  Associated Replica Repositories:
    - /Users/you/my-app-wt-1

Associated Replica Repositories 下列出了 worktree 的路径，说明它已经登记为这个项目的工作区。

并发上限那个问题选 Yes，项目设置里的上限就跟上了工作区数量。下一步的工作流文件里仍然写明 maxConcurrency: 2，这样不论项目设置里是多少，这个工作流都允许两个任务同时执行。要用 clone 代替 worktree、准备更多副本，或者直接改本机设置里的并发数，见并行执行与工作区。

写工作流文件

新建 .codedag/dags/two-small-changes.yaml，按你要用的 Agent 选一个版本，原样粘贴进去。两个版本只有每个任务的 agent 和 mode 不同。

maxConcurrency: 2

tasks:
  - id: 1
    title: 挑选两个待办
    agent: claude
    mode: bypassPermissions
    prompt: |
      目标：
      在这个项目里找出两个最快能完成的待办，为每一项写一份简短的实施计划，交给后续两个会话分别实现。

      详细说明：
      - 待办要按我的角色和负责范围来筛选，可以来自代码里的 TODO、FIXME 注释，文档里的待办清单，被跳过的测试，也可以来自你能访问的 issue 跟踪工具，比如 GitHub Issues、Linear、Jira。
      - 找不到合适的待办时，根据这个项目的产品定位和现状，以及我的职责，提出两个小改动来代替。

      完成标准：
      计划写到 docs/plans/two-small-changes.md（文件已存在时直接覆盖），分为“第一项”和“第二项”两节，每节写明：
      - 目标：要做成什么，一两句话。
      - 涉及的文件：要修改或新增的文件路径，包括测试文件。
      - 完成标准：怎样算完成，包括要先写的最小测试，以及运行这些测试的命令。

      约束：
      - 除了这份计划，不新建、不修改任何文件。

  - id: 2
    title: 实现第一项
    dependencies: [1]
    agent: claude
    mode: bypassPermissions
    prompt: |
      目标：
      实现 docs/plans/two-small-changes.md 中“第一项”描述的待办。

      上下文与必读材料：
      - docs/plans/two-small-changes.md 是上一个任务写的计划，“第一项”一节写明了目标、涉及的文件和完成标准。

      完成标准：
      - 达到“第一项”写明的完成标准：先写出最小的测试，再实现到测试通过。

      约束：
      - 只修改“第一项”列出的文件，不修改计划文件，也不实现“第二项”的内容。

      注意事项：
      - 另一个会话正在另一条分支上同时实现“第二项”，你看不到它的改动；两边的结果之后由 CodeDAG 合并。

  - id: 3
    title: 实现第二项
    dependencies: [1]
    agent: claude
    mode: bypassPermissions
    prompt: |
      目标：
      实现 docs/plans/two-small-changes.md 中“第二项”描述的待办。

      上下文与必读材料：
      - docs/plans/two-small-changes.md 是上一个任务写的计划，“第二项”一节写明了目标、涉及的文件和完成标准。

      完成标准：
      - 达到“第二项”写明的完成标准：先写出最小的测试，再实现到测试通过。

      约束：
      - 只修改“第二项”列出的文件，不修改计划文件，也不实现“第一项”的内容。

      注意事项：
      - 另一个会话正在另一条分支上同时实现“第一项”，你看不到它的改动；两边的结果之后由 CodeDAG 合并。

maxConcurrency: 2

tasks:
  - id: 1
    title: 挑选两个待办
    agent: codex
    mode: yolo
    prompt: |
      目标：
      在这个项目里找出两个最快能完成的待办，为每一项写一份简短的实施计划，交给后续两个会话分别实现。

      详细说明：
      - 待办要按我的角色和负责范围来筛选，可以来自代码里的 TODO、FIXME 注释，文档里的待办清单，被跳过的测试，也可以来自你能访问的 issue 跟踪工具，比如 GitHub Issues、Linear、Jira。
      - 找不到合适的待办时，根据这个项目的产品定位和现状，以及我的职责，提出两个小改动来代替。

      完成标准：
      计划写到 docs/plans/two-small-changes.md（文件已存在时直接覆盖），分为“第一项”和“第二项”两节，每节写明：
      - 目标：要做成什么，一两句话。
      - 涉及的文件：要修改或新增的文件路径，包括测试文件。
      - 完成标准：怎样算完成，包括要先写的最小测试，以及运行这些测试的命令。

      约束：
      - 除了这份计划，不新建、不修改任何文件。

  - id: 2
    title: 实现第一项
    dependencies: [1]
    agent: codex
    mode: yolo
    prompt: |
      目标：
      实现 docs/plans/two-small-changes.md 中“第一项”描述的待办。

      上下文与必读材料：
      - docs/plans/two-small-changes.md 是上一个任务写的计划，“第一项”一节写明了目标、涉及的文件和完成标准。

      完成标准：
      - 达到“第一项”写明的完成标准：先写出最小的测试，再实现到测试通过。

      约束：
      - 只修改“第一项”列出的文件，不修改计划文件，也不实现“第二项”的内容。

      注意事项：
      - 另一个会话正在另一条分支上同时实现“第二项”，你看不到它的改动；两边的结果之后由 CodeDAG 合并。

  - id: 3
    title: 实现第二项
    dependencies: [1]
    agent: codex
    mode: yolo
    prompt: |
      目标：
      实现 docs/plans/two-small-changes.md 中“第二项”描述的待办。

      上下文与必读材料：
      - docs/plans/two-small-changes.md 是上一个任务写的计划，“第二项”一节写明了目标、涉及的文件和完成标准。

      完成标准：
      - 达到“第二项”写明的完成标准：先写出最小的测试，再实现到测试通过。

      约束：
      - 只修改“第二项”列出的文件，不修改计划文件，也不实现“第一项”的内容。

      注意事项：
      - 另一个会话正在另一条分支上同时实现“第一项”，你看不到它的改动；两边的结果之后由 CodeDAG 合并。

文件里没有写 executionMode，所以使用默认的隔离分支模式。其中有几处值得留意：

• maxConcurrency: 2 允许最多两个任务同时执行。实际能同时执行的任务数还不会超过可用的工作区数，这里是主仓库加一个 worktree，正好两个，见maxConcurrency。
• 任务 2 和任务 3 都写了 dependencies: [1]。 它们都要等任务 1 完成并被接受才开始，彼此之间却没有依赖，所以任务 1 一被接受，两者就同时启动。
• 任务 2 和任务 3 直接去读 docs/plans/two-small-changes.md。 这个文件是任务 1 在它自己的分支上写的，任务 1 被接受后，CodeDAG 先把它的结果合并进任务 2、3 的任务分支，再启动这两个任务，所以它们一开始就能在各自的工作区里读到它。依赖为什么同时是传递信息的通道，见依赖。
• 两个并行任务的改动范围可以重叠。 任务 2 和任务 3 各在自己的任务分支上修改，执行时互不影响；两边的结果合并时碰到同一处代码，冲突由 CodeDAG 先交给 Agent 解决，见汇聚节点的合并与冲突。所以任务 1 挑待办时不用避开会改到同一处的两项，任务 2、3 的约束也只把各自的工作限定在自己那一项之内。

校验并提交

先校验工作流文件：

cdg dag validate two-small-changes

✔ Validation passed: .codedag/dags/two-small-changes.yaml

通过之后提交，并让当前终端跟随日志：

cdg dag submit two-small-changes --attach

✔ Submitted successfully: .codedag/dags/two-small-changes.yaml

Queue position:
  #1  .codedag/dags/two-small-changes.yaml (now running in background)

📊 Following logs... (Ctrl+C to detach logs, Ctrl+\ to kill current workflow)

任务 1 先在主仓库里运行；它结束并被自动接受后，日志里会接连出现任务 2 和任务 3 的开始行：

[Task   1] [2026-09-30 10:39:32] END: 挑选两个待办
[Task   2] [2026-09-30 10:39:36] START: 实现第一项
[Task   3] [2026-09-30 10:39:36] START: 实现第二项

此后两个任务的日志交替滚动。和快速开始时一样，按 Ctrl+C 只是让终端不再跟随日志，工作流会在后台继续执行。

观察两个任务并行

另开一个终端，进入主仓库，查看这个工作流的看板：

cdg dag status two-small-changes --watch

任务 2 和任务 3 执行期间，看板是这样的：

[TZ: -04:00] 2026-09-30 10:39:39

Workflow: .codedag/dags/two-small-changes.yaml
  Phase: 📤 submitted
  Queue Position: 1
  Status: 🟢 in-progress
  Substatus: working

Submitted Tasks (2):
  🟢 [in-progress] [working]  Task 2: 实现第一项
  🟢 [in-progress] [working]  Task 3: 实现第二项

Reviewed Tasks (1):
  🤖☑️ [auto-accepted]  Task 1: 挑选两个待办

Progress: 1/3 tasks completed (33%), 1 reviewed

任务 1 已经被自动接受，移到了 Reviewed Tasks；任务 2 和任务 3 同时处于 [in-progress] [working]，各占一个工作区。想确认它们分别在哪里执行，可以看每个工作区当前检出的分支：

git worktree list

/Users/you/my-app       9a2b3bc [cdg/two-small-changes/t2-实现第一项]
/Users/you/my-app-wt-1  9a2b3bc [cdg/two-small-changes/t3-实现第二项]

主仓库被切到了任务 2 的分支，worktree 被切到了任务 3 的分支。任务分支按 cdg/<工作流名>/t<任务 ID>-<标题> 命名。两行的提交相同，都是 CodeDAG 接受任务 1 时为它留下的提交，也就是说，两个任务都从任务 1 的结果开始工作。

检查结果并合入主分支

两个任务都完成后，CodeDAG 自动接受它们，把两条任务分支合并到集成分支，整个工作流随即被自动接受。跟随日志的终端会随之结束，最后一行是：

✔ Workflow auto-accepted: .codedag/dags/two-small-changes.yaml

如果两个任务改到了同一处代码，合并到集成分支时会发生冲突，CodeDAG 会先交给 Agent 解决；三轮仍未解决时，工作流停在 on-hold 等你处理，而不会出现上面这一行，处理方法见合并冲突。

工作流结束后，主仓库停在集成分支上，git branch --show-current 会显示 cdg/two-small-changes/integration。先看集成分支比 main 多了哪些提交：

git log --oneline main..HEAD

ba8ab12 Merge task 3 into cdg/two-small-changes/integration
b99fcd0 实现第一项
d6077f1 实现第二项
9a2b3bc 挑选两个待办

CodeDAG 接受一个任务时，把它留下的改动提交到它的任务分支上，提交说明就是任务标题；最上面的合并提交，是 CodeDAG 把任务 3 的分支并入集成分支时留下的。再看具体改了哪些文件：

git diff main...HEAD --stat

合入之前，逐个文件读一遍改动，再在集成分支上运行项目的测试。CodeDAG 判断任务完成的依据是任务 Agent 结束了工作，自动接受也不看测试结果，改动是否正确，要由你来确认。任务 1 写的 docs/plans/two-small-changes.md 也在这些改动里，不想让它进入主分支，就先删除它并提交。

确认之后，就可以把结果合入主分支了。团队协作时通常要经过 PR：集成分支是从 main 开出的，带着这次的全部改动，从它新建一条你自己的分支，推送到远程，再照常开 PR。分支名按团队的约定取，这里用 feat/two-small-changes：

git checkout -b feat/two-small-changes cdg/two-small-changes/integration
git push -u origin feat/two-small-changes
git checkout main

推送要由你来做，CodeDAG 自己从不向你的远程仓库推送，也不从中拉取。最后一条命令让主仓库回到 main，它还决定了下一个工作流从哪里开始：工作流以开始执行时主仓库检出的提交为起点，主仓库还停在集成分支或这条新分支上时，下一个工作流会接着这次的结果做，见任务分支、集成分支与起点。

不需要代码审查时，比如在个人项目里，也可以在本地直接合入：运行 git checkout main 切回主分支，再运行 git merge cdg/two-small-changes/integration。main 在这期间没有新的提交时，这是一次快进合并。其他合入方式见合入主分支。