卡不等于分支我用 TRAE 宝配合 Hive 跑三张任务卡的一天一、场景一张卡就是一个任务项目组有一套自建的 Hive用来做任务发放与流转网页端就能看板。它的基本单位是卡一张卡就是一个任务卡上写死执行契约——允许修改哪些 paths、verify 命令是什么、租约多久、失败策略怎么走。Hive 通过 MCP 接进了本机的 TraeCode。我这边用 TRAE 宝TraeCode 里的 AI 助手当派活 汇总的角色看契约、开独立会话、收结果、做判断。真正干活的是被派出去的独立会话每张卡一个会话、一个 worktree互不干扰。11 月 2 日这天同时发了三张卡light 仓的 CI、light 的 smoke 脚本、lightmem 的 smoke 脚本。下面按卡讲重点放在踩的坑。二、T-0234让 CI 真跑起来然后它真的红了这张卡的契约很窄只允许改.github/workflows/ci.ymlverify 是test -f .github/workflows/ci.yml60 分钟内没完成就放弃。执行会话在.hive\wt\trae-win\T-0234分支task/T-0234里重写了 workflow。改动都落在同一个文件里补permissions: contents: read、加concurrency、用PYTEST_ADDOPTS让 PR 跳过 slow、把计时起点挪到 setup-python 之后干净 runner 上原来第一步就红、修正 R125 分仓后失效的 lightpub 测试路径、补三道 G9 度量门禁、把预算从 600/1200s 放宽到 1800/3000s。actionlint校验通过GitHub 上确实产生了真实 run。然后 CI 红了unit 层 12 failed 7 errors。拆开看是两层一层是仓库态测试本身的失败一层是 sibling 仓lightharness不在环境里。两者都不在本卡允许的 paths 内按契约不能越界去修。提交也不顺。hive_submit时git push被仓库的 pre-push 门禁拦下假绿断言基线告警、sibling 缺失、worktree 里没有.venv。这里没有用--no-verify绕——绕过去只是把问题推给下一个看日志的人。所以这张卡最后没有硬报 done而是回写了blocked把两层根因写清楚另外开了一张治理卡 T-0241 去治这个真红。真正麻烦的是交付169c7599这个 commit 只存在本地不在任何远端主控拿不到。执行方于是把ci.yml全文逐字贴出来附上字节数、行数、sha256 和 git bloba1395f8cf4daa4263edd19b162c6b95dedf45bf9由主控原样落库。这是这天最有价值的一条经验推不上去的时候我改好了等于零交付全文加指纹才是可验证的交付物。三、T-023552 行脚本和一个 165 秒的钩子契约同样只允许一个文件scripts/smoke.shverify 是test -x scripts/smoke.sh。产物是 52 行 POSIX sh一条命令回答装好了没有版本 Hello World 两条判据成功和失败两路都有明确输出和退出码。commit23b7556推task/T-0235hive_submit成功、状态 done。随后git merge --no-ff合入 main 并推送4be264311..15c5f3d60pre-push 钩子原样跑过、没有冲突。坑在出口。Windows 上 pre-push 门禁里的pytest --collect-only要跑约 165 秒超过 MCP 的 120 秒网络超时push 反复超时Windows cmd 也不认test -x。处理方式不复杂先把钩子里的门禁逐条手工跑一遍确认没问题再用本地垫片完成这次推送事后清理干净。钩子是拿来过的不是拿来关的。四、T-0236卡死在 claim 这一步这张卡和 T-0235 契约一样但备注里特意提醒Windows 上head/grep/awk和!/$()不可用POSIX 判据会 exit 255 造成假失败别先怀疑产物跑不了就换一台内网 FreeBSD 15.1 机器走 ssh密码从.env取尾部带空格要先 strip。结果这张卡根本没领到。hive_claim直接报agent trae-win 没有配置仓库 lightmem 的本地路径。查下来这个 agent 只登记了 hive / lightharness / light 三个仓。不动 agents 配置是明令禁止项所以停在这里没有自作主张去改。卡仍然是 ready、owner 为空——把阻塞原样交回给人。五、踩坑与经验1. 卡不等于分支。分支推上去了、代码写完了都不等于任务完成。done的唯一依据是 verify 真过。判据在本环境下不可达时正确动作是回写blocked并写清根因而不是把文件存在凑成任务完成。T-0234 的 verify 其实只检查文件存在真要硬凑太容易了但这张卡的意义就没了。2. agent 配置的仓库登记是隐性前置条件。缺一行lightmem: ...整张卡就卡在 claim 一步连执行的机会都没有。这类阻塞要快报试一次、看到明确报错、停手别反复重试。3. 跨平台审查会让 POSIX 判据假失败。Windows 上test -x、test -f的语义并不存在exit 255 往往是环境问题而不是产物问题。正确做法是先证明脚本本身 POSIX 兼容再上真 POSIX 机器验最差也要在交付说明里标注未在真 POSIX 验过不许伪装成通过。4. 出口门禁会拦住看似成功的提交。假绿断言、缺 sibling、缺 venv 都可能被 pre-push 拦下。不要用--no-verify绕先人工把门禁跑一遍确认到底是哪一条在响。5. commit 只在本地等于主控拿不到成果。远端推不上去时交付方式是贴全文 给指纹字节数 / 行数 / sha256 / blob让对方原样落库。只给一句我改好了价值为零。6. 失败归因别一顶帽子扣到底。把仓库态失败拆成真回归、环境缺件放大、跨仓漂移、未定四类各自给依据。同一批用例在缺 sibling、缺 venv 的环境里会从 19 条放大到 40 条——环境口径本身就在放大失败面不拆开就永远归错因。7. 并行调度要一卡一会话。三张卡各开独立会话、独立 worktree互不干扰。同一件事的后续比如合并 0235回到原会话不重复开新会话重新摸索——上下文本身就是成本。8. 人的位置。AI 负责执行与汇报判据不可达时的取舍——挂 blocked 还是继续硬推、要不要动配置——留给人一句话决定。这天 T-0236 就是靠这条停住的。六、可复用的工作流阶段要做的事判断点派卡读契约paths、verify、租约、失败策略目标是否在本环境可达领卡确认 agent 是否登记了对应仓库claim 报错即停不重试执行独立会话 独立 worktree只改允许的 paths越界即停先报再问出口手工跑一遍 verify 与 pre-push 门禁不用--no-verify交付verify 过则 done不过则 blocked 根因推不上去就贴全文 指纹合并回原会话做merge --no-ff并再推一次钩子原样跑过才算完七、收尾一整天下来三张卡里只有一张真正 done一张 blocked一张连领都没领到。按完成率看不太好看但三张卡的状态都是诚实的没有假绿没有硬凑的 done也没有绕过门禁的提交。对我来说这套配合真正有价值的地方不是AI 能改代码而是它把每一步的判断都落到了可查的证据上——verify 的输出、门禁的报错、commit 的指纹、卡上的 blocked 理由。人需要做的是在这些证据面前做那一次取舍。本文记录的是 2026-11-02 的真实流水数字与 commit 均来自当天的任务卡和终端输出文中未包含任何密码、token 或具体内网地址。
卡不等于分支我用 TRAE 宝配合 Hive 跑三张任务卡的一天一、场景一张卡就是一个任务项目组有一套自建的 Hive用来做任务发放与流转网页端就能看板。它的基本单位是卡一张卡就是一个任务卡上写死执行契约——允许修改哪些 paths、verify 命令是什么、租约多久、失败策略怎么走。Hive 通过 MCP 接进了本机的 TraeCode。我这边用 TRAE 宝TraeCode 里的 AI 助手当派活 汇总的角色看契约、开独立会话、收结果、做判断。真正干活的是被派出去的独立会话每张卡一个会话、一个 worktree互不干扰。11 月 2 日这天同时发了三张卡light 仓的 CI、light 的 smoke 脚本、lightmem 的 smoke 脚本。下面按卡讲重点放在踩的坑。二、T-0234让 CI 真跑起来然后它真的红了这张卡的契约很窄只允许改.github/workflows/ci.ymlverify 是test -f .github/workflows/ci.yml60 分钟内没完成就放弃。执行会话在.hive\wt\trae-win\T-0234分支task/T-0234里重写了 workflow。改动都落在同一个文件里补permissions: contents: read、加concurrency、用PYTEST_ADDOPTS让 PR 跳过 slow、把计时起点挪到 setup-python 之后干净 runner 上原来第一步就红、修正 R125 分仓后失效的 lightpub 测试路径、补三道 G9 度量门禁、把预算从 600/1200s 放宽到 1800/3000s。actionlint校验通过GitHub 上确实产生了真实 run。然后 CI 红了unit 层 12 failed 7 errors。拆开看是两层一层是仓库态测试本身的失败一层是 sibling 仓lightharness不在环境里。两者都不在本卡允许的 paths 内按契约不能越界去修。提交也不顺。hive_submit时git push被仓库的 pre-push 门禁拦下假绿断言基线告警、sibling 缺失、worktree 里没有.venv。这里没有用--no-verify绕——绕过去只是把问题推给下一个看日志的人。所以这张卡最后没有硬报 done而是回写了blocked把两层根因写清楚另外开了一张治理卡 T-0241 去治这个真红。真正麻烦的是交付169c7599这个 commit 只存在本地不在任何远端主控拿不到。执行方于是把ci.yml全文逐字贴出来附上字节数、行数、sha256 和 git bloba1395f8cf4daa4263edd19b162c6b95dedf45bf9由主控原样落库。这是这天最有价值的一条经验推不上去的时候我改好了等于零交付全文加指纹才是可验证的交付物。三、T-023552 行脚本和一个 165 秒的钩子契约同样只允许一个文件scripts/smoke.shverify 是test -x scripts/smoke.sh。产物是 52 行 POSIX sh一条命令回答装好了没有版本 Hello World 两条判据成功和失败两路都有明确输出和退出码。commit23b7556推task/T-0235hive_submit成功、状态 done。随后git merge --no-ff合入 main 并推送4be264311..15c5f3d60pre-push 钩子原样跑过、没有冲突。坑在出口。Windows 上 pre-push 门禁里的pytest --collect-only要跑约 165 秒超过 MCP 的 120 秒网络超时push 反复超时Windows cmd 也不认test -x。处理方式不复杂先把钩子里的门禁逐条手工跑一遍确认没问题再用本地垫片完成这次推送事后清理干净。钩子是拿来过的不是拿来关的。四、T-0236卡死在 claim 这一步这张卡和 T-0235 契约一样但备注里特意提醒Windows 上head/grep/awk和!/$()不可用POSIX 判据会 exit 255 造成假失败别先怀疑产物跑不了就换一台内网 FreeBSD 15.1 机器走 ssh密码从.env取尾部带空格要先 strip。结果这张卡根本没领到。hive_claim直接报agent trae-win 没有配置仓库 lightmem 的本地路径。查下来这个 agent 只登记了 hive / lightharness / light 三个仓。不动 agents 配置是明令禁止项所以停在这里没有自作主张去改。卡仍然是 ready、owner 为空——把阻塞原样交回给人。五、踩坑与经验1. 卡不等于分支。分支推上去了、代码写完了都不等于任务完成。done的唯一依据是 verify 真过。判据在本环境下不可达时正确动作是回写blocked并写清根因而不是把文件存在凑成任务完成。T-0234 的 verify 其实只检查文件存在真要硬凑太容易了但这张卡的意义就没了。2. agent 配置的仓库登记是隐性前置条件。缺一行lightmem: ...整张卡就卡在 claim 一步连执行的机会都没有。这类阻塞要快报试一次、看到明确报错、停手别反复重试。3. 跨平台审查会让 POSIX 判据假失败。Windows 上test -x、test -f的语义并不存在exit 255 往往是环境问题而不是产物问题。正确做法是先证明脚本本身 POSIX 兼容再上真 POSIX 机器验最差也要在交付说明里标注未在真 POSIX 验过不许伪装成通过。4. 出口门禁会拦住看似成功的提交。假绿断言、缺 sibling、缺 venv 都可能被 pre-push 拦下。不要用--no-verify绕先人工把门禁跑一遍确认到底是哪一条在响。5. commit 只在本地等于主控拿不到成果。远端推不上去时交付方式是贴全文 给指纹字节数 / 行数 / sha256 / blob让对方原样落库。只给一句我改好了价值为零。6. 失败归因别一顶帽子扣到底。把仓库态失败拆成真回归、环境缺件放大、跨仓漂移、未定四类各自给依据。同一批用例在缺 sibling、缺 venv 的环境里会从 19 条放大到 40 条——环境口径本身就在放大失败面不拆开就永远归错因。7. 并行调度要一卡一会话。三张卡各开独立会话、独立 worktree互不干扰。同一件事的后续比如合并 0235回到原会话不重复开新会话重新摸索——上下文本身就是成本。8. 人的位置。AI 负责执行与汇报判据不可达时的取舍——挂 blocked 还是继续硬推、要不要动配置——留给人一句话决定。这天 T-0236 就是靠这条停住的。六、可复用的工作流阶段要做的事判断点派卡读契约paths、verify、租约、失败策略目标是否在本环境可达领卡确认 agent 是否登记了对应仓库claim 报错即停不重试执行独立会话 独立 worktree只改允许的 paths越界即停先报再问出口手工跑一遍 verify 与 pre-push 门禁不用--no-verify交付verify 过则 done不过则 blocked 根因推不上去就贴全文 指纹合并回原会话做merge --no-ff并再推一次钩子原样跑过才算完七、收尾一整天下来三张卡里只有一张真正 done一张 blocked一张连领都没领到。按完成率看不太好看但三张卡的状态都是诚实的没有假绿没有硬凑的 done也没有绕过门禁的提交。对我来说这套配合真正有价值的地方不是AI 能改代码而是它把每一步的判断都落到了可查的证据上——verify 的输出、门禁的报错、commit 的指纹、卡上的 blocked 理由。人需要做的是在这些证据面前做那一次取舍。本文记录的是 2026-11-02 的真实流水数字与 commit 均来自当天的任务卡和终端输出文中未包含任何密码、token 或具体内网地址。
