你一天要听几次"已完成"？
我数过，多的时候二三十次。开个会话把活扔过去，回来瞄一眼日志尾巴：测试全绿，工作完成。然后我自己跑一遍，红的。
烦的不是它骗人。它没骗人，它是真以为自己干完了。烦的是每次都得自己再验一遍，那我要它干嘛。
上个月还踩了个更阴的。一个跑了整晚的会话，日志里写着提交哈希，我顺手复制出来敲 git cat-file，返回成功。差一点就信了。回头细看，我在 shell 里敲的是个短哈希，日志文件里躺着的那串跟它对不上，压根解析不出来。⚡这一下我才明白，问题不是它会不会写错代码，是"检查"这个动作本身可以是假的——命令跑绿了，但它检的东西和你想检的东西，根本不是同一个。
有篇文章讲给长时间跑的 Claude Code 会话做编排，一个会话协调、其他会话干活、状态放外面。名字叫 Chief of Staff，作者自己都说了这名儿不是既有术语，orchestrator-worker、maker-checker 指的都是同一个东西，换了个包装。整套架子挺重，cmux 加 Plan Desk，我没上——太重，我手上就 tmux 加一个 tasks/ 目录。但里面三个小动作我当天就抄了，不问架构，直接能落到自己机器上。
第一个：让验证器先失败。
最便宜，也最容易被跳过。任何"实现之前先跑的检查"，你得亲眼看见它红了，再去写实现。
pytest tests/test_export.py
# 此刻应该是 FAILED。要是绿的，说明这检查根本没在检查东西
理由傻得有点好笑：它一开始就是绿的，你就分不出"实现写对了"和"这检查压根没跑起来"。空断言、正则匹配不到任何东西、命令报错被吞掉、断言的其实早就是真的——全都给你一个绿。坏工具和好工具，输出一模一样。
顺手还能捡个便宜：跑一遍红门，队列里不少卡会发现早就做完了，或者是被后面某次改动顺带做掉的。清卡比做卡省事多了。
第二个：验证的时候，读产物本身。
就是上面那个哈希的教训。别拿你手里那个变量去验，别拿你刚打印出来的那个字符串去验，回文件里读。
# 别这么干：拿 shell 里的短哈希去验
git cat-file -t $SHORT_ID
# 这么干：从日志文件里抠出来再验
grep '^commit' work.log | cut -d' ' -f2 | xargs git cat-file -t
差别看着就一行，可这类错全藏在缝里。会话名也一样——你上次读到的那个名不一定是个能用的地址，消息层未必拿工作区名寻址，发之前重新列一遍活动会话，别复用上回读到的那个。日志条目的标题通常只是写入方给这段活起的概括，不一定是卡片真实的标签，搜标签，别搜你脑子里的转述。
第三个：状态活在文件里，不活在会话里。
这条我改得最彻底。会话是可以扔的，看板不是。
不用上那套看板服务。一个 tasks/ 目录塞几个 md 就够，每张卡写清楚：要解决什么、动哪些接口、怎么算验过了、明确不做什么。然后一条纪律——任务状态跟工作原子翻转，开始就进 in_progress，验过才进 done，绝对不能等会话结束批量刷一遍。
批量刷出来的状态就是骗自己。中间那几个小时里，你问一句"现在什么情况"，得到的答案和真相对不上。
一次只开一个工作项，一次只派一次。这条我理解起来最慢，但真省事。
沾这条还有个小坑：几个会话共享同一棵工作树的时候，别裸 git commit。它会把你整个索引都提交进去，包括隔壁会话刚暂存的东西。我现在一律：
git commit -- path/to/file
只提交点名的路径。（上回我还写过一条绑键位的，后来发现跟另一个软件撞了快捷键，那个我回头得更正——这条 git 的不用，它只解决它该解决的。）
这套值不值得上，看你这活跑多久。单个范围明确的小改动，两个会话协调的开销比活本身还大，一个会话干完拉倒。但要是活会跨好几个上下文窗口、还非得做对不可，那这套开销买的是"我敢信这个结果"。
说个我自己守得最死的一条：那个负责协调的会话，不能碰实现。上周手痒，顺手把一个小 bug 自己改了，然后那天剩下所有东西全是它自己报的，我一条没核。第二天全返工。它一旦开始写代码，就再也没人验了，整套退化成一个超载的大会话。
红门每次多花十秒，一天按二十来次算，体感多花三五分钟，省下的是我一天里那一小时自己复跑验证的时间——这周用下来，这笔账怎么算都划算。老实说这招在"我赶时间先把功能糊上"的场景不灵，那种时候你会本能地跳过红门，然后第二天还回来。
你们要是有更狠的核法，教教我！