Agent 在写代码，你在切 tab——IDE 伺候了你的手二十年，现在该伺候脑子了
你每天开的 IDE，到底在为谁设计？
为代码吗？为你吗？还是为”你的手”？
这个问题以前不用问。答案太明显：执行器就是你自己。你盯着光标，一行行写，一个参数一个参数改，一个文件一个文件过。
IDE 所有能力，从语法高亮到 refactor，从跳转定义到 diff，都在服务这个动作链。
可今天不一样了。Copilot coding agent 在后台接活，Codex 在云上并行跑任务，Claude Code 拿到一个 issue 就能自己开 worktree 干活。
你发出的是目标，回来的是 PR。中间那层微操作，开始不在你手里了。
旧 IDE 优化的是手的动作；新 IDE 要优化的是脑的编排。
旧世界里，IDE 为什么必须小粒度？
粒度就是你一次能稳定处理、表达、验证的工作单位。
旧模式里这个单位很薄：一行、一个函数、一次局部修改。
你当然也会想架构、想模块边界、想半年后的维护成本。但宏观思考再大，落地接口仍然是微观编辑。
脑子想”重构支付链路”，手做的是”把这个参数从 nullable 改成 non-null”。翻译损耗常年存在。
IDE 围绕小粒度设计，不是设计师保守，是执行器就是人手。
马车时代最好的工具不会先优化高速公路，它会先优化缰绳和车轮。动力单元就是马，你再有战略眼光也得尊重这个物理现实。
过去二十年 IDE 的进化很一致：从字符和行，到 symbol 和结构，再到跨文件语义操作。
很强，但主战场始终在 code-level。那是那个时代唯一能跑通的路径。
Agent 接手微操作后，变了什么？
谁在执行微操作。
以前你把宏观目标拆成几十个小编辑动作，自己挨个做。
现在这层翻译可以外包给 agent。你说”修这个 bug，补测试，给我 PR”，系统能跑起来，而且是异步跑。
Copilot coding agent 的文档写得很直白：后台工作，改代码，开 PR，再请你 review。Codex 和 Claude Code 也是类似的路径。
当微操作被外包，你盯的东西就变了：哪个任务在跑、哪个卡住、哪个结果能审、哪个得回滚。
关心的不再是”这行写在哪”，而是”这个目标怎么被分配、隔离、验证、合并”。
说白了就是控制面上移了。你还是那个做决定的人，只是决定的颗粒度变了。
这是新想法吗？不算
“高层意图驱动底层实现”这事很多人试过。
从早期的程序综合研究，到微软的 Intentional Programming，再到各种 DSL 和 low-code 平台。每一代都在尝试把人从微操作里解放出来。
结果呢？”你说想要什么”这一步确实越来越容易了。但”出了事谁负责”这一步，从来没有被工具接走过。
test 挂了谁看？安全漏洞谁背？线上事故谁扛？不管你用什么工具生成代码，最后签字的还是你。
这就是以前每一轮尝试最终卡住的地方：意图可以往上抬，责任抬不动。
那今天有什么不一样？
不是某个单点突破，是三样东西第一次同时到位了：agent 能干活了、异步执行的摩擦足够低了、PR 流程能让人审计和兜底了。
以前这三个总缺一个——要么 agent 太弱，要么异步执行太重，要么没有可审计的出口。现在至少能把”你提目标 → agent 干活 → 你审结果”这条线跑通了。
那为什么会指向 Kanban？
主操作单位变成了任务，界面该围绕什么组织？
文件树？聊天记录？还是任务状态？
我倾向任务状态。也就是 Kanban 这一路。
先别往”项目管理”那边想。在 agent 场景里，Kanban 更像是你的外部工作记忆。
脑子里最贵的资源不是算力，是注意力。你能同时稳定追踪的东西没你想的那么多——心理学研究给出的数字大概是四五个独立对象，再多就开始掉上下文。
你同时盯四五个活跃 agent，差不多就到边界了。
Kanban 干的事其实很朴素：
把”脑内状态”拖到屏幕上，你不用靠回忆去追踪谁在干啥。
给并行任务加个数量限制，防止你审不过来越欠越多。
把哪个在推进、哪个卡住了摆在明面上，不用挨个窗口去翻。
它不是贴纸板，是你监督一堆异步自动化时的控制台。
那 chat 呢？
chat 擅长局部深聊——提需求、澄清边界，很好用。但你同时跑五六个任务的时候，在聊天记录里翻来翻去找全局状态，就比较痛苦了。
Chat 是前门，Kanban 是总控台。不是谁替代谁，是各管一摊。
为什么要配 worktree？不配会怎样？
Kanban 回答”做什么、做到哪”。
它不回答”这些事怎么彼此不打架”。
这时就需要 worktree。
想象你同时做三道菜。肉丝、番茄、鱼片全堆一块砧板上，手再快也会串味。
每道菜给一块自己的砧板，这就是 worktree 在工程上干的事：每个任务一个隔离的工作目录，有自己的中间状态，互不干扰。
没有隔离会怎样？
短期是代码冲突，长期是注意力税。你会把很多本该交给系统处理的”别串线”问题，又拎回脑子里手动维持。
惨。
Cursor 把并行 agent 和 worktree 直接绑在一起了。Claude Code 有 --worktree 参数，一条命令就能让任务跑在独立目录里。
Cline Kanban 做得更直接：每张卡自带一个 terminal 加一个 worktree。
方向挺一致——worktree 正从”Git 高级技巧”变成 agent 干活时的默认隔离层。
但这个方向也有明显的问题
说了这么多好处，反过来想想：什么情况下 Kanban + worktree 不够用，甚至方向就是错的？
代码级控制永远不可或缺
这条最硬。
Joel Spolsky 很早就讲过：所有非平凡的抽象最终都会漏。你把操作粒度抬高了，底下出了问题还是得钻回代码里调。
ORM 挡不住你最终要写 raw SQL，low-code 平台做到一半总有地方要写脚本。
成立吗？完全成立。但它推不翻 Kanban + worktree。
它推出来的结论是：上层做编排，下层做验证，你要随时能下钻到 diff、日志和 test。两层都得有，不是选一个。
Agent 变强后，Kanban 只是过渡
如果 agent 连任务拆解都包了，人是不是只剩一个”批准”按钮？
那看板还有必要吗？
有可能 Kanban 的角色会变——从执行台退成监督台。但自动化越强，人越要盯优先级、风险和责任归属。
这些不会因为 agent 能力变强就自动消失。
IDE 会被 web、terminal、PR 流程溶解掉
Cursor 在往 web 和 mobile 扩展，Claude Code 的 autonomous 工作流越来越长。
IDE 作为一个桌面窗口可能会退到后台，但你看全局状态、做决策、下约束的那个”面”不会消失。
它可能分散到 PR 页面、web panel、terminal 里去，但功能还在。叫什么名字不重要。
为什么切 tab 会这么累？
大家都有体感：一边盯聊天流，一边看 PR，一边切本地目录，脑子像被碎玻璃刮。
不是你定力差。
心理学管这个叫 task switching cost——切换本身就要时间。
更烦的是注意力残留：你人已经切到新任务了，脑子还黏在上一个没处理完的事上。
你看似在多线程推进，实际在反复”重装上下文”。窗口很多，进度很慢，压力很高。
Kanban + worktree 不会让你变超人。
它们做的事很朴素：让状态可以扫一眼就看到，而不是靠回忆；让任务隔离在系统层面完成，而不是靠你自己记住”这个分支别碰那个文件”。
就像手动挡换自动挡。你还是得看路，但不用每秒踩离合了。
产品证据到哪一步了？
早期共识出现了，标准化还在路上。
Vibe Kanban 和 Cline Kanban 把”一张卡等于一个可执行的工作空间”做成了产品。Cursor、Claude Code、OpenCode 在 worktree 隔离上都有工程化落地。
Copilot coding agent 和 Codex 把异步执行做成了主流入口。
信号挺明确：任务编排层正在往 IDE 旁边长，而且长得很快。
但”零审批、零 review 的全自动协作”，目前我没看到稳定的一手生产证据。
大规模团队还是把人工 review 放在最后关口。这合理。
IDE 该伺候谁？
回到起点。
过去 IDE 伺候你的手。现在该开始伺候你的脑子了。
代码层能力不会消失。Chat 也不会取代所有界面。
Kanban + worktree 大概率不是终局，但很可能是这个阶段最实用的骨架。
你已经在用 agent 了，别只优化 prompt，去优化你的任务控制面。
开始并行了，给每个任务独立的 worktree，把串线问题从脑子里搬走。
担心失控，建双层闭环：上层编排意图，下层验证代码。
过去我们在代码里工作。
接下来，我们会更多在任务之间工作。