一个做外包的工程师,工作日常态是 6 个 Claude Code session 并行,9 个不算稀奇。他说写代码早就不是瓶颈了,他自己才是。于是他花了大半年时间,修的全是人这一侧的东西。
✦ ✦ ✦
开篇
先看两个数字。
6,和 99。
6 是他一个普通工作日同时开着的 Claude Code session 数量,9 个的时候也有。99 是秒——他想做一个"最近哪些文件被改过"的面板,最早的方案是扫整棵目录树的文件修改时间,结果在一个 158 万个文件 的项目上跑了 99 秒。方案当场作废。
写这篇东西的人叫 Daichi Kudo,在 Cognisant LLC 做 LLM 系统开发的合同工程师。工程他自己做,客户沟通也他自己做。9 月 4 日他在 dev.to 上发了一篇长文,把自己这套并行工作法从头到尾摊开了。
我读完最大的感受不是"哇好高产",是另一句话:
写代码已经不再是约束了。约束是我,一个人,消化这些输出、然后发出下一条指令。
这句话听着像鸡汤,但他后面写的全是硬东西——具体到某条 git 命令为什么必须写成一行、某条规则为什么放在 memory 里就等于没写。
并行多个 AI 编程 session 时人成为瓶颈
✦ ✦ ✦
他把"读代码"这件事整个扔了
第一条最反直觉。
他不读 AI 写的代码了。
不是偷懒。他换了两个验证动作:跑起来,看实际行为;然后让 Claude 把整体情况写成一份文档,他读文档。
理由不是"这样快"。他的原话是,在当前的模型水平上,这样比他自己 review 代码抓到的错更多,而且质量和方向上的漂移会更早暴露出来。
这点我一开始不信。想了两天,有点信了。你自己 review 一个 800 行的 diff,注意力是均匀铺开的,越往后越糊。但你把程序跑起来,行为对不对是二值的,一眼就知道。文档更狠——AI 要是把一个功能的边界理解错了,它写出来的文档会自己露馅,比代码露得早。
还有个附带好处:他为了验证而做的文档,和交给客户、交给同事的文档,是同一份东西。一份东西两个用途,少做一遍。
但文档得能读。所以他把版式做成了 skill 里的模板,不允许从空白页开始写:
而且开工之前,session 得先写六行"读者动线简报":谁读、从哪儿打开、第一屏要决定什么、决定在哪儿发生、下一步做什么、什么情况下这份文档作废。
六行。写完再开始做。
Excel 也一样:列宽、换行、行高、缩放全部设好,导成 PDF,先在屏幕上检查有没有截断和重叠,再送到他面前。
这套东西的价值在于,他每次拿到的文档,同一类信息永远在同一个位置。扫一眼就知道该看哪儿。9 个 session 的产出要在一个人脑子里过,靠的就是这个。
文档模板让同类信息永远出现在同一位置
✦ ✦ ✦
一个只回答"刚才改了什么"的窗口
6 到 9 个 session 同时跑,每隔几分钟就有新文件冒出来。
挨个终端问"你刚才写了啥"?比自己去找还慢。
他要的东西很具体:一块屏幕,显示最近哪里动了,点一下就能打开,而且不在终端里。他用 Sublime Text 很多年了,所以这个面板就做在 Sublime 里,叫 Recent Activity。
代码是 Claude Code 设计并实现的。他只决定了两件事:放在哪、显示什么。现在开源了,Cognisant-llc/sublime-claude-code,MIT 协议,非官方社区插件。
面板长这样:
24h · docs & media ▼ data-platform 5 ●2 ● dataplat-tiles * 14:52 STATUS.md 14:51 …/status_archive/2026-09.md ○ dataplat-seo 14:50 …/snapshots/state.json ⟨.wt-x⟩ ×3 ▶ manufacturing-client 1224 小时内改动的文件,按 项目 → session → 文件 三层分组,新的在上,点开即读。默认只显示文档和媒体(md、txt、html、pdf、xlsx、docx、pptx、csv、图片、视频),按 c 才把代码文件加进来。不想看的项目按 h 藏掉。
底下是两条信息流做 join:文件系统 watcher 告诉你"什么被改了",Claude Code 的 hook 告诉你"哪个 session 改的"。
他老老实实写了这东西的缺陷:同一个项目里两个 session 同时跑 shell 命令的时候,文件归属不了。没解决。
还有个反方向的通道我觉得挺妙。session 手里有个小命令行工具,能自己在 Sublime 里打开一个文件,CLAUDE.md 里写死了规矩:产出了需要我看的东西,就用它。
所以不是他去找交付物,是交付物被送到他跟前。
一块只显示最近改动的面板,按项目和 session 分组
✦ ✦ ✦
✦ ✦ ✦
别再用散文解释修改
光有感知还不够。
每一处修改都用句子解释一遍,这件事本身就是新的瓶颈。他的解法是:按领域换通道。
前端走 Tweak。直接在浏览器里选中元素,手调字号、间距、位置、文案,把这个 diff 导成 JSON 扔给 session。session 负责翻译成 Tailwind class 或者 design token 落到源码里,再用改动前后的截图自己验一遍。
文档和幻灯片走批注。在文档上点任意位置贴一条注,注导成 JSON,那就是修改请求本身。不用再写"第 3 页那张图的右上角"这种话——这句话我以前写过太多遍了,每次写完还得担心对方理解错。
后端没有工具能替。他写得很干脆:设计、边界、契约先定死,测试先写,修的时候一层一个变量地改,每一类的前后差异都要量出来。判断留在人这边。
基建只能看监控和日志。他把一条成本检查点写进了运维规矩:请求数除以人类页面浏览数,超过 100 就说明结构错了。
前两个是"尽量别用词解释",后两个是"人的判断和观察不可替代"。都叫指令,但用的家伙什完全不一样。
还有一条小的,我觉得可以直接抄:
session 不确定的时候,不许发开放式问题。先给假设,再给选项,推荐的那个放第一个;如果答案可能分叉,两个分支的答案都预先给出。
目标是把他的回复压缩成一次点击。
我自己被 agent 那种"请问您希望我用方案 A 还是方案 B?"打断过太多次了,每次都得重新加载上下文。改成多选题 + 预答分支,确实是两码事。
四个领域各用不同的指令通道
✦ ✦ ✦
并行会在三个地方裂开
加 session 之后,缺陷集中在三个地方:身份、git、共享的机器状态。
第一,名字。用 claude --name - 启动,绝对不用自动生成的名字跑并行。名字同时是 session 之间发消息的地址。
第二,git 用 worktree 隔离。任何可能并行的项目,先 git worktree add,在 worktree 里改、在 worktree 里提交。
他给这条的评价是整篇文章里最重的一句:
自从隔离变成默认,git 侧的缺陷基本就没了。这是整套设置里最有效的一条规则。
配套的两个细节:提交和分支检查串在同一条命令里;git add 只接受显式路径,不许 .。
第三,共享的机器状态必须在一条命令里切换。这条是我看完全文最想抄下来的:
gh auth switch --user … && gh pr create …必须写成一行。
拆成两条会怎样?另一个 session 可能在这两条命令的缝隙里把账号切走了,你的 PR 就以错误的身份开出去了。
而且不会报任何错。
这种 bug 是最恶心的一类——没有异常、没有红字,只有三天后某个人问你"这个 PR 怎么是他提的"。
还有第四条,不算坑,算能力:让 session 之间直接说话。Claude Code 的 session 可以互发消息。他拿来干三件事:动共享 worktree 之前先声明意图、宣布什么东西进了 main、另一个 session 空闲了给他一条通知。
文章里举了个例子,我读的时候笑了一下。写这篇文章的那个 session,是从另一个 session 手里接过一份开源工作的。他本人只说了一句话:去请求交接。交接内容是两个 session 自己谈的——仓库 HEAD 在哪、有没有未提交的东西、按优先级排好的下一步、任务追踪 ID。
他在旁边看着。
git worktree 隔离与共享状态的原子切换
✦ ✦ ✦
那个复发了三次的裂图 bug
这一节最短,但可能是全文最有用的。
有一天,同一个缺陷在他这儿复发了三次。
PR 里的截图链接掉了 ?raw=true,渲染出来是一张裂图。
规则是存在的。他早就写过这条规则。写在 memory 里。
问题是 —— memory 在"创建 PR"这个动作发生的那一刻,不会被查。
于是他重新定了规则该住哪:
-
跨项目通用的规则 → 放 CLAUDE.md -
绑在某个具体动作上的规则 → 放那个动作的 skill 自检里,在建 PR、在对外发送之前立刻读 - memory 只用来做 session 之间的交接,不放规则
-
项目自己的设计决策 → 留在项目的设计文档、决策记录、状态文件里,不往全局提
一句话:规则放在哪儿,决定了它是不是真的生效。
还有一条配套的。对话里只要他说了"以后""总是""绝不"这类词,session 不能把"你说过了"当成记录——必须在同一轮之内决定这条规则归哪个文件、写进去,然后在回复末尾附上写入的路径。
session 结束时还有个脚本做交叉核对:对话日志里出现的指令词,对上实际被更新的文件。对不上就报。
他管这叫"防止指令蒸发在聊天里"。
说实话这条我看完直接去改自己的配置了。我以前也是靠 memory 存规则,然后每隔一阵子就纳闷:明明说过啊,怎么又犯。
规则该住在哪一层才会被真正读到
✦ ✦ ✦
这套东西是要定期修的
不是装好就完事。他列了四条维护节奏:
- 01skill 和 CLAUDE.md 审计
,一年两次,对着写好的评分表,过一遍所有 skill 和 agent 定义。有没有哪个"唯一位置"现在重复了?每个 front-matter 的 description 还对得上它实际做的事吗? - 02memory 审计
,盘点所有项目的 memory,跨项目的提到全局,项目专属的设计决策送回它该在的项目 - 03索引维护
,一个 hub 页面映射所有资产,项目增减就更新 - 04术语账本
,session 用了别扭的直译就加一行:避免用哪个词,该说什么
然后是他最诚实的一句话:
这里面每一条,都是某个 session 做错事之后才加上去的。单个 diff 都很小。叠起来,才是"跟得上"这件事成立的原因。
没有蓝图,全是补丁。这个我信。
这套配置由一次次事故后的小补丁叠成
✦ ✦ ✦
有人正在往反方向走
写到这儿得说个不太一样的声音,不然这篇就成了单向宣传。
同一周,AI 编程工具 Kilo 的团队拿 GPT-6 Astra 跑了一轮实测,结论里有这么一段:
它需要的 AGENTS.md 脚手架少得多。我们花了一年攒起来、用来把模型摁在轨道上的那些指令,结果发现大部分没必要。如果你的 agents 文件很臃肿,试着删掉一半,再让 Astra 跑一遍。
一边在加脚手架,一边在删脚手架。
我想了一会儿,觉得这俩其实不打架,它们修的是不同的层。
Kilo 删的是 模型侧的护栏 ——那些"别乱改无关代码""记得写类型""按现有模式来"的碎碎念。模型自己变强了,这些确实可以退役一批。
Kudo 加的是 人机之间的接口 ——他修的是感知通道和指令通道。这两条通道跟模型多聪明没关系,跟你要同时看住几个 session 有关系。
Kilo 那篇里还有一句正好接上:"监督从'指挥模型'转向'审查它决定了什么'。"
审查它决定了什么——那你就得先能看见它决定了什么。绕回来了。
✦ ✦ ✦
写在最后
他文章的最后一段是这么写的:
"开更多 session 就有更高产出"是个常见说法。在我这儿,只有先把人这一侧的感知和指令修好,多开才变得容易。否则找东西的时间和解释的时间,会把收益抵消掉。
这句话我认。
我自己开三个 session 就开始乱,不是因为 AI 写得不好,是因为我不知道刚才哪个改了什么,也懒得挨个去问。到最后要么串行回去,要么开着开着就不看了——那还不如不开。
真要抄的话,我觉得优先级是这样:
- 01
git worktree隔离,今天就能配,收益最大 - 02
共享状态用 &&串成一条命令,五分钟的事 - 03
把规则从 memory 挪到动作发生的地方 - 04
确认改成多选题 - 05
再考虑做那个"最近改了什么"的面板
前四条不用写代码。
哦对,还有第五条之外的一件事——他文章里那句声明我挺喜欢:实现、git 操作、脚本、那个面板,全是 Claude session 写的,不是他写的。他做的是验证交付物,以及维护这些 session 工作时依据的指令。
指令住在哪儿?CLAUDE.md 里、skill 里、memory 里。
所以他真正在维护的,是一套写给 AI 看的规矩。代码是副产品。
这个转变,可能比"一天开 9 个 session"这个数字重要得多。