上篇讲了为什么要把散装的 AI 工具拼成一支小队。这篇是落地篇：任务卡到底长什么样、怎么派下去、怎么验收，以及真正跑起来之后踩过的坑。

一、一张图看懂全流程

先放全貌，后面逐段拆：

flowchart TD
    A[需求/缺陷/新功能] --> B{能派 AI 做吗?}
    B -- 否 --> B1[自己直做或等条件]
    B -- 是 --> C[写任务卡入收件箱]

    C --> C1{写卡前四查}
    C1 --> C1a[工作区是否干净]
    C1 --> C1b[编号防撞]
    C1 --> C1c[现状核实 防重复派卡]
    C1 --> C1d[文件锁]

    C1 --> D[卡结构六要素]
    D --> E{选派发通道}
    E -- 有 CLI --> E1[headless / 直发]
    E -- 无 CLI --> E2[驱动桌面窗口 / 手动话术]

    E1 --> F[执行者: 领卡→做→回填]
    E2 --> F

    F --> G{验收: 不信自报}
    G --> G1[核对文件锁]
    G --> G2[编译/测试/产物亲跑]
    G --> G3[验收标准逐条过]

    G -- 通过 --> H[归档 + 统一提交]
    G -- 不通过 --> I[退回+写原因] --> F

    H --> J[沉淀日志 + 汇报]

一句话：写卡的人只负责把任务说清楚，执行的人只负责改，验收的人只认证据。 三个角色互相不信任，靠的是卡和证据链。

二、任务卡六要素

一张卡就是一个任务。写卡的人（管家）要保证：执行者不看聊天记录、不看项目文档，只看这张卡就能干活。所以卡上固定六段：

要素	写什么	为什么
状态	⬜待领 / 🔄进行中 / ✅完成 / ❌受阻	项目进度看卡状态就行，不用问人
分发给	哪个工具	多工具并行时防串
任务	现状 + 要改成什么样	卡自包含，执行者不猜
文件锁	只许改哪几个文件	多 AI 同时改同一个文件 = 互相覆盖
红线	不许动什么、不许越什么界	边界写死，防越权
验收标准	怎么证明做完了	可机检优先，别写”看着差不多”

一个脱敏示例（真实卡改的）：

# Q032: 首页几个 MORE 按钮点击无反应
状态: ⬜待领
分发给: qoder
优先级: P1

## 现象（用户真机验证）
首页顶部多个区块的 "More" 按钮点了没反应：
- My circles / Manage
- Hot discussions / View all
- Featured / See all

## 任务
把三个 More 按钮分别绑定跳转目标页；
跳转目标页已存在（Circles 页），复用即可，禁新建页面。

## 文件锁
只许改：Features/Home/HomeViewController.swift（+新增跳转方法）
禁改：其他任何文件

## 红线
- 不 commit 不 push，完成回填卡状态即可
- 禁改 UI 布局（用户明确只要按钮生效）

## 验收标准
- [ ] 三个按钮真机点击都能跳到对应页
- [ ] 编译零 error

注意最后一行验收标准——**”真机点击”这条管家自己验不了**（管家没有真机），所以验收标准里凡是依赖环境的项，要么写清”谁验、怎么验”，要么换成可机检的等价项。这是后来才学到的，见第六节。

三、写卡前的四查

写卡不是想到就写。四件事不查，后面必翻车：

1. 查编号：收件箱里已经有几张卡？编号有没有撞？——同一编号两张卡，两个执行者各做各的，合并时对不上账。
2. 查工作区：git 干不干净？——上一个执行者没提交的代码，会卷进下一个人的提交里，验收时说不清谁改的。
3. 查现状：这个活是不是已经有人做完了？——最经典的翻车：卡面基于过期的文档，执行者吭哧吭哧做完，复测才发现功能早就有了。建卡前必须用代码/git 核实现状，不是信文档。
4. 查文件锁：目标文件有没有其他执行者正在改？——有就换文件或排队，别硬塞。

四查的本质：写卡的人要承担”任务真实存在”的责任。执行者不背这个锅，他只需要执行。

四、派发：三种通道

卡写好了，怎么送到执行者手里？取决于工具的”接口形态”：

通道	适用	代价
CLI / 命令行直发	有正经 CLI 的工具（如 Kimi、ZCode 系）	最稳，可脚本化
驱动桌面窗口	没有 CLI 的桌面工具（如 Qoder、WorkBuddy）	要适配窗口定位、输入框识别，脆弱
手动投递	前两条都不通时	人把卡复制过去，最慢但零风险

桌面窗口驱动是最折腾的：先得找到它的窗口、定位输入框、把指令注入进去、再验证”真的发出去了”（输入框清空了才算）。这套东西今天能跑，明天工具改个版式可能就断——上篇预告里说的”没啃下的骨头”，主要就是它。

五、执行者的纪律

卡派下去之后，执行者要遵守一套状态纪律：

• 领卡：先把状态从 ⬜ 改成 🔄（告诉所有人”这活我接了”）
• 干活：随做随写进度（PROGRESS 段），不是做完才写——卡中途断了，下一个人能接上
• 完成：状态改 ✅，填产出段（改了哪些文件、验证了什么）
• 红线内的延伸：发现卡外问题，先报备，等管家裁决，不擅自扩大范围

这套纪律看着简单，实际是踩出来的——执行者最常犯的错不是不会写代码，是”擅自动了卡外的东西”。

六、验收：为什么”自报完成”不算数

执行者说”完成了”，管家不能直接信。这一节是整篇最值钱的部分，全部来自真实事故：

1. 编译通过 ≠ 代码入库：执行者说”编译双绿”，但 git 一看，改动根本没提交。自报是自报，仓库是仓库。
2. 验收先列 commit，逐笔问授权：执行者自己 commit 了一堆东西，混着没授权的卡外改动——不逐笔确认就合入，等于默认他越权。
3. “完成”要过真实门禁：编译绿只是及格线，交互类改动要真机/环境实跑。曾经出现”generic 编译过、真机一跑就崩”的经典事故——签名、设备家族这些坑，只有真实目标环境暴露。
4. 文件锁要核对 diff：执行者改的文件必须和卡面文件锁一致，多改了就是越权，哪怕改得好。
5. 证据链可回放：日志、截图、测试输出要留痕。出了问题能复盘，不是黑盒。
6. 退回要说清原因：验收不通过退回时，把不合格点写进卡里，执行者才知道改什么。

一句话总结验收：绿灯亮不亮，看证据链，不看嘴。

七、没啃下的骨头（续）

上篇留了个尾巴，跑了几周，新的骨头也冒出来了：

• 视觉类验收绕不开人：图标、截图、UI 效果这类”好不好看”的判断，执行工具没有可靠的眼睛，只能管家（或人）来把关——这条链路目前是人工环节。
• 额度断供比想象的频繁：免费额度是消耗品，一个工具进入冷却期就得立刻轮转，轮转逻辑本身也要维护。
• 多工具并发时，文件锁是唯一防线：它防住了互相覆盖，但也意味着调度变复杂——同一文件的活必须排队，谁先谁后要管家排。

写在最后

上篇说”AI 负责生成，人负责裁决”。这篇把”生成”这一层拆开了：拆卡是判断，派活是调度，验收是裁决——这三件事管家能做，但裁决的最终责任永远在人。

后续还会整理：额度轮转怎么自动判断、怎么驯服没有 CLI 的桌面工具。大概率会继续共享，欢迎拍砖。

（文中项目信息已脱敏；提及的工具均为公开产品；未包含任何私密配置与凭据。）

---