[开源推广] 10年开发经验融入的windows/mac/linux多 Agent 分屏编排桌面应用，Claude Code / Codex / OpenCode 同屏并行派工，更新v0.14.3，顺便说说这半年心路历程。（一）

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是


• 我的开源项目完整开源，无未开源部分： 是


• 我的开源项目已链接认可 LINUX DO 社区： 是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是


• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

---

慢慢来讲，这半年我做了多少更新吧。

ccpane的首次提交时间在2026年2月16日，刚好是我生日那天我立项了，算是比较早一批做多agent分屏编排应用的一批人吧。

但是这个项目基本上都是由我个人进行开发的，所以很多时候，方向是对的，但是bug用起来特别特别多。

当然战绩也是很辉煌的。

半年，971 次提交，34 万行代码，88 个版本，103 个开发日。一个人。

我不懂rust，甚至代码也一次没看过。彻头彻尾的headlesscoding。

现在比较火的orca，最早提交时间也要比我晚一个月，但是我的更新速度却完全比不过他。这没办法，能力有限。

等我了解到orca的时候，我发现很多时候，我方向正确，但是个人的开发速度，完全完全跟不上。

这其实侧面证实了一件事情，不看代码，不懂某个语言，到底能不能搓出一个可以商业化的使用的代码。

项目总共501star ，但是14h前更新的release版本，已经有69人下载了。

用git查了下更新次数，全仓库84个人发布，真实安装包下载 7842次。Windows 占 89%，真的有人用，我无疑是非常非常开心的。

为什么要做cc-pane这个这个工具呢？

因为AI 是新的生产工具，而 IDE 是旧生产关系的固化形态——它把「一个人、一个项目、一个页面」这套协作方式焊死在了界面里。

生产工具变了，生产关系就得跟着变。

而我本质上是自己开软件公司的，看过我之前帖子的人也知道，我基本上独自一人扛着80%售前售后交付软件开发的任务，公司算上销售，也就3个人，其他人基本上不懂代码。

所有的ide都无法解决一个问题，内存占用问题。

就比如现在的我，我同时跑 19 个 Claude 会话、7 个项目并行，编排壳只占 1.9GB，agent 自己占 7.1GB。同样的活给 IDE，光开7个项目内存就要占用20g以上，而那20g买到的能力，我一整天可能都没用到一次。

我可以随时通过ccpane来查询自己的项目启动日志。

比如下面这样。

近30天内，我在80个不同的项目推进过（含worktree）

当前同时在线，9个布局，33个标签，19个claude对话（今天的codex太难用了）

至于产生的经济效益，大概在150w上下。

未来的软件时代，真的才是服务大于一切。

别人做不了的我能做，别人做的了的我用ai做的更好。需求就是这样产生的。

最开始，我也是用终端编写代码，只是为了解决ide的占用内存问题，因为我同时还兼职直播（详见之前抖音直播的收益），96g内存在多开项目编译的情况下，也完全不够用。

所以我开始用终端编写代码，但是终端编写代码有个很大的问题，那就是，我可能在使用的过程中，不小心把他关掉。哪怕我还能再继续把他resume回来，但是我还是需要从新进到那个文件夹，然后开启claudecode才能resume（claudecode后续版本好像支持了不在那个文件夹resume）。

而windows的资源管理器，实在是，太卡卡卡卡卡卡卡了。

早期windows下根本没有什么好用的分屏终端，想了想，干脆自己写，然后也学ccswitch一样，干脆叫做ccpane。

基础终端，很快就写好了。我借鉴了vscode跟idea的工作空间，我觉得工作空间是最最最适合vibecoding的形式了。

众所周知，Claude 也好、Codex 也好，都喜欢在项目文件夹底下塞 .claude、.codex。项目做到一半你会发现，GitHub

仓库里全是这些点目录——而且它们混了两种完全不同的东西：skills、agents、commands

是团队资产，该入库；settings.local.json、plans/、worktrees/ 是个人运行时垃圾，该忽略。CLI

厂商把生命周期完全不同的两类东西塞进了同一个目录。

作空间的思路我借鉴的是 Linux 文件链接——引用，而不是复制。项目不搬家，工作空间只存一行指向它的路径。落地时我没用 symlink，用的是一张 CSV 清单：

▎ path,alias,branch,status

▎ D:\01_workspace_ai\erp-workspace\yunzhu-ui-admin-vben,ERP 前端,erp,dirty

▎ D:\01_workspace_ai\erp-workspace\yunzhu-erp,ERP 后端,feature/erp,dirty

这样，当你在工作空间打开项目的时候，他自然就能一个终端同时修改前后端开发了。

而启动项目更简单了，右键直接claude、codex，甚至你能自由编辑每次启动的provider，甚至甚至现在还能自己决定每次启动你需要开什么skills，什么mcp。

但是我又有了新的idea。

如果每个终端，能够看到其他终端的对话过程，那不是一件很酷的事情嘛？

2026 年 3 月 10 日，我通过 MCP 让 AI 能读到彼此的对话，然后在对方的输入框里打字、按回车。

再完成这一步后，因为cc出了一点问题，我每日的cc量减少了（要优先给客户用），我被迫使用codex5.4.

5.4 是真的不说人话。你跟它讲一个意图，它这里拿一刀、那里砍一刀，回来给你一个能编译但不是你要的东西。同样一句话给Claude，它会顺着你的思路往下想；给 Codex，它只会顺着字面执行。

而且他的方案，你还看不懂。

思索再三，我们写了一个skill，第一个编排skills诞生，/plantocodex

claude不写代码，只负责把事情想清楚——写成一份显式到不需要任何背景知识就能照做的 plan。

Codex 不做判断，只负责按 plan实现。两个模型各自干自己擅长的那件事，中间那份 plan 就是它们之间的契约。

对的 我放弃了当时很火的spec。

我并不是没引进过。

而是发现，实际上有点鸡肋。

立项那天我就引进了 spec——当时最火的多 agent协作方案。给项目建一棵规范树：前端怎么写、后端怎么写、跨层怎么想，全部落成文档；再用一个 hook 在每个子 agent启动时把这份 spec 注入进去。让所有 agent 读同一份规范。

用了一个半月。四月四号，我把整棵规范树删了，21 个文件。

问题不在规范写得好不好，而是在于，这些规范是吃上下文的。真的有必要吗？规范，在opc，或者个人的项目中，真的是那么重要的嘛？

我觉得不是，我觉得，功能先产出，后续在烧token去改，也是完全来得及的！

直接原因很朴素：规范是吃上下文的。 而且吃法很难看——每个 agent、每次会话都要读一遍，成本按 agent数乘会话数线性涨，可其中绝大部分内容跟这次要干的事没关系。

我付的是常驻费用，买到收益则是少的可怜。

（后续superpower的崩溃也是这个原因）

过度的规范对于我来说，就是污染ai的上下文的罪魁祸首。

上下文不该花在永远为真的知识上，该花在这一次要做什么上。

这句话是后来所有编排设计的地基。

ai时代，不要去害怕返工。也不要害怕垃圾代码。你把自己当成老板，agent是你的员工，你想想，你的真正的老板，是否在意过你代码的质量？后续想要提升质量，随时安排个agent去修改就行了。

随着ai的进步，ai自然而然又或者说claude or codex cli，自然会增加很多很多的规范类提示词，又或者炼为大模型的自带的能力。

在ccpane里面，我还增加了很多有意思的的小功能。

比如跨项目记忆，比如wsl兼容，比如好看的壁纸，比如可爱的宠物（

当然这些很多都是我的个人爱好，有些写了是为了直播效果。咳咳咳。

先说到这里，期待能得到您的star。(话说我500star未免也太少了吧）