我现在的「AI 工作台」：codex + Cindy + openclaw + kilo

最近被朋友反复问同一个问题：你这四个 AI 工具到底是怎么分工的？codex、Cindy、openclaw、kilo，光听名字确实都像"AI 助手"，凭什么不全用同一个？我自己也花了不少时间才把这套组合理顺。这篇文章只讲一件小事：在我手里，这四个工具分别占住了不同的工作位，缺谁我都会别扭。

我写代码的"主驾"是 codex。这里的"主驾"很具体：跨多文件、需要持续迭代、上下文一旦断了就接不回去的那一类项目。我把 codex 一直挂着，它不像一个"一次性问答工具"，更像一个能跟项目同呼吸的搭档——它看过的文件、改过的 diff、跑过的命令，会变成下一轮决策的依据。规矩只有三条：把 codex 当"项目主驾"而不是"问答工具"，给它持续的事实而不是一次性的提示；用里程碑切会话，长会话里它会慢慢漂移，里程碑一过就 reset，让它从干净的事实开始；看 diff 而不是看回答，它给的"通过"只是参考，最终那一下"合不合"必须人来定。

Cindy 站的是另一个位。她不只是"另一个 AI"，更像是四个工具之间的调度位。一半的时间我在做办公——写周报、整会议纪要、做汇报材料、起草对外的邮件——这摊事她是我的主力。但更让我离不开的，是她无缝衔接 Pi、codex、Claude的能力。我经常是这样跑工作流的：先用 Cindy 把需求讲清楚、列好要点；遇到需要长链路推理的，把上下文接力给 Pi；进入真正的工程实施阶段，再接力给 codex；想换一个视角听反馈或做对照，再回到 Cindy 或转 Claude 跑一遍。整条链路的纪律是：办公是基本盘，周报、会议纪要、对外邮件这一摊她是主力；调度是放大器，她和 Pi / codex / Claude 接力，让上下文在工具之间流动，我不用复制粘贴、不用重新解释背景；接力链路过长是陷阱，两到三跳最舒服，再多，信息的损耗就会显出来，必须切回 Cindy 重整。

再往下是 openclaw。它在我这里干的是"不入主线"的杂活。什么叫杂活？一次性脚本、临时数据清洗、批量改个文件名、跑个不痛不痒的小爬虫、把一段音频转成文字、给一张图换个尺寸、临时翻译一段不要求精度的文字——这些事不会上 GitHub、不会进生产、也不会被任何会议引用，但不做又会卡住主线进度。openclaw 就是这种"轻骑兵"，打开就能用、用完就走。规矩是：任务的边界是"不入主线"，都是它的活；价值在"快"和"不打断心流"，不在"严谨"和"可追溯"，别把它的输出直接当交付物；用完就走，它不占心智位，也不抢主线位。

kilo 的角色最简单：在 VSCode 里用的那个。很多写代码的时间是碎片化的——我在 IDE 里写到一个函数、卡住、想问一下；改到一半想确认某个 API 的用法；review 一段刚写的逻辑想找人挑刺。这时候我不想切窗口、不想开新 tab、不想跳出当前文件，kilo 就在侧栏里直接接住。规矩也很简单：位置在 VSCode 侧栏，随手就能用，不切窗口；任务是碎片化的"边写边问"，卡住的函数、API 用法、刚写完的逻辑想挑刺，kilo 就在手边；不要在 kilo 里跑长链路任务，它的定位是"边写边问"，不是"项目级搭档"，那个位是 codex 的。