教程二：任务、工作树、验证与人工审查

没有真机复现，也不承诺更快。 线程和 worktree 的界面名称按官方提交 6d35d09060a901d15e31ab7ccdeedfe6696c23c5 核对。本站 线程译文 是旧提交 d2c25950。Theo 的视频只提供 查阅入口，时间标签来自第三方自动转录，不是已核实的操作打点。Y2

在一个练习仓库里完成一项小改动，并留下别人能复核的证据。适合常把需求、实现和排错堆在同一个目录、同一个长线程里的人。

这里采用 Nimrod 的“一个项目主线程组织其他线程”、FRFlo 的 worktree 隔离，以及 Escoffier Labs 的验证记录思路。W1W3 这些作者没有证明一套对所有项目都更快的流程。容器、Brigade 和 fleet 不是 T3 内建，本课不安装它们。

对照

原流程里的问题	本课的调整
需求、实现和排错堆在一个长线程	主线程记录目标和决策，独立任务新开线程
多个 agent 同时改同一目录	需要独立改动的任务选 New worktree，并写明基线
看到“测试通过”就接受	保存实际命令、环境、退出码、失败和未运行项
只看最后一条回复或单轮 diff	最终检查相对基线的完整分支差异
agent 改完就自动发布	本地修改、commit、push、创建 PR、merge 分开决定
每台电脑重复解释规则	先沉淀可审查的非敏感约定，再考虑 规则练习

前提

使用一个你有权操作的 Git 练习仓库。先确认主工作目录没有解释不了的本地改动，基线已经确认，provider 能运行，并且找得到仓库自己的检查说明。

人确认任务与边界
    → 主线程只读制定计划
    → 实现线程使用 New worktree
    → 执行仓库已有验证
    → 人工检查完整分支 diff
    → 决定本地提交
    → 单独决定是否推送和创建 PR

工作树只隔离工作目录和分支，不是权限沙箱。不同工作树仍可能共享主机凭据、网络和外部服务。整个练习保持 Supervised。官方文档的初始默认仍是 Full access，所以要明确选 Supervised，不能靠默认。D5 不要拿生产服务当测试目标。

如果任务要在另一台主机上跑，先完成 教程一。自动均衡默认关闭，只影响合适的新线程选择，不迁移已经在跑的线程。第一次练习手动选主机更容易排查。D1

步骤 1：选一个能验收的小任务

例如修正文档里的一处错误链接，或改一个已有测试覆盖的小行为。不要第一次就让 agent 重写架构。

在主线程提交这段整理建议：

先做只读计划，不修改仓库。
目标：<写清楚一项改动及预期行为>。
边界：不更换技术栈，不改部署，不读取密钥，不提交或推送。
请从现有仓库找出相关文件、测试入口和项目约定。
给出最小实施步骤、风险与验收条件。
把已知事实和需要我确认的假设分开。

这里的“计划”是任务约定，不依赖所有 provider 都有同一种 Plan 模式。看到改文件或装依赖的请求时，先停下来，把范围收窄。

预期是文件线索、最小步骤和待确认项，不是补丁。

步骤 2：为实现新建独立工作树

1. 人工确认计划和基线分支。
2. 新建线程，选择同一项目和正确主机。
3. 选择 New worktree。新线程的分支和工作区模式来自你配置的默认值，不能默认假设新线程就有新目录。D3
4. 检查界面显示的分支和工作目录。
5. 把确认后的任务、允许修改的范围和验收条件交给实现线程。

要留在同一个目录，用分支工具栏的 New thread in this worktree。那不提供独立修改隔离。D3

按已经确认的计划完成这一项任务：<任务>。
只在当前独立 worktree 修改允许范围内的文件。
如需扩大改动、安装依赖或变更配置，先解释原因并申请批准。
使用仓库已有检查，不编造测试通过结果。
完成后报告改动文件、实际执行的验证、失败与未运行项。
不要 commit、push、创建 PR 或部署。

新 worktree 不保证带有依赖和构建产物。让 agent 读这个项目自己的初始化说明，再由人批准必要步骤。不要从别人的教程复制和你的项目无关的 npm test。

步骤 3：只并行互不踩文件的任务

第一次只开一个实现线程。流程确认之后，再增加第二个独立任务，例如互不依赖的文档修改和小修复。

每个要独立改代码的任务各建 worktree。两个线程要改同一核心接口时，先定依赖顺序，不要把冲突留到最后。

在 Web 或桌面端，官方写的是在新线程的模型选择器里 Shift-click 模型来加入或去掉。每个选择会启动独立线程和 worktree，并且需要一个 Git 项目。普通点击会回到单个模型。D3 这适合比较候选方案，不表示可以把几个候选补丁自动合并。比较时使用相同的任务、基线和验收标准。

步骤 4：记录真正执行的验证

检查命令必须来自这个仓库的说明、脚本或团队约定。让 agent 给出来源，人审核后再运行。找不到可靠入口就记下缺口，不要编造“测试已通过”。

下面的记录格式借鉴 W3 的验证回执，不依赖 Brigade，也不是 T3 自动生成的审计证明。

任务：
目标环境与工作目录：
基线分支与基线提交：
当前工作分支与最终提交，尚未提交则写“未提交”：
验证命令及其仓库依据：
实际运行时间和时区：
退出码：
关键输出或日志保存位置：
失败、未运行项及原因：
人工检查结论：

文档改动至少检查链接、渲染和差异范围。代码行为运行项目已有的相关检查。没有测试的项目，写明替代检查和覆盖不到的风险。人工看过不等于自动测试。

步骤 5：人工审查完整差异

1. 看实现线程的文件列表，先确认有没有任务以外的改动。
2. 打开相对基线的分支比较，审查完整 diff。
3. 对照验收条件和验证记录。
4. 查找意外的凭据、配置、锁文件、生成文件或部署改动。
5. 需要返工时，只把具体问题交回原来的实现线程。

T3 的单轮改动视图只显示这一轮自己的工作。拉取、合并或 rebase 带进来的部分可能不在单轮文件列表里，所以它不能代替最终的分支审查。D4

可以让另一条线程提供审查意见。如果它位于同一个可写 worktree，就不能把它当成隔离的审核环境。“只读”是任务约束，仍要有合适权限和人工监督。

步骤 6：提交和发布分成独立决定

线程里的 Git 动作可以 commit、push 和创建 PR，也可以生成说明。D4 本课只在你核对之后继续：

1. 先决定是否本地 commit。核对具体文件和提交说明。
2. 再决定是否 push。核对目标账号、远端仓库、分支和仓库可见范围。
3. 再决定是否创建 PR。核对标题、正文、基线分支、验证说明和风险。
4. merge 按团队审查、分支规则和 CI 单独处理。

生成的 PR 说明不证明测试跑过。只写步骤 4 里实际做过的检查，没做的明确标成未运行。

源码托管认证要配在该项目所在的那台 T3 服务器上。浏览器或手机能看线程，不等于那台主机已经有 Git 推送权限。不要从另一台电脑复制 token。D4

步骤 7：收束，不急着清理

主线程记下接受的结果、未解决的问题和下一步。可以把线程 settle 来整理任务。settle 不是代码已经合并或部署。

先确认工作树里的改动已按你的决定保存，再处理磁盘清理。T3 有工作树自动清理规则，是否触发取决于设置。练习期间先看规则，不用删除线程来测试会不会自动备份。D3

验收

完成不是“agent 说完成”，而是有这些材料：

• 一个范围明确的任务，以及人工确认过的计划。
• 一个能追溯到基线的独立实现 worktree。
• 实际验证记录，失败和未运行项没有藏起来。
• 人工审查过的完整分支 diff。
• 明确的发布状态，例如“仅本地未提交”“已本地提交未推送”或“已按授权创建 PR”。

练习不要求必须创建 PR。停在本地审查完成也算完成。

常见失败

问题	处理
新线程改到了主工作目录	停下来核对工作区模式。不要用 reset 盖掉已有工作，先分清每一处改动属于谁
新 worktree 跑不了测试	看这个项目的初始化说明、运行时和依赖。跨机且低于 full-access 的链接还会跳过 setup scripts，见 跨机委派
两个实现互相冲突	回到任务边界，按依赖顺序重排。worktree 不会自动消除逻辑冲突
“验证通过”没有命令或输出	要求补实际记录。没跑过就标未运行
单轮 diff 很小，分支改动很大	审查分支比较，查清 merge、rebase 或其他轮次带入的改动
远端能跑 agent，但不能 push	检查项目主机的源码托管认证和远端，不要从另一台电脑复制 token
代理要求更高权限才能继续	先看是不是任务超出边界，或环境还没准备好。不要用 Full access 代替定位问题

来源：D1、D2、D3、D4、D5、D6。方法来自 W1 的主线程组织、W2 的远端与 worktree 边界、W3 的精确 revision 与验证记录。提示词和记录表是本章整理的，不是博主原文。视频线索见 Y2 与 Y2a。