我的多 AI 助手分工：总管、运维、研究、微信

同时用好几个 AI 助手之后，我发现最重要的不是哪个模型更聪明，而是分工清楚。一个助手什么都管，上下文会越来越乱；按职责拆开，每个助手只关心自己那一摊事，出了问题也好排查。

分工的思路

我现在大致按四类职责来分：

角色	负责什么	不负责什么
总管	日常对话、拆解任务、把活派给对应的助手	不直接处理微信消息
运维	服务器、部署、保活脚本、排查故障	不做业务决策
研究	查资料、读文档、对比方案	不改线上环境
微信	收发微信消息、维护微信通道	不把微信内容同步到其他对话

总管

总管是我说话最多的那个。它的价值在于「派活」：需求进来先判断归谁，运维类的事交给运维助手，微信相关的交给微信助手，自己只跟进结果。

运维

运维助手处理所有「机器上的事」：部署、看日志、拉起挂掉的进程。比如微信桥接的轮询进程，就是由一个保活脚本加一个定时检查来守着的。

研究

需要查资料、读 API 文档、对比几种方案时，交给研究类的助手，让它带回来源和结论，而不是直接动手改东西。

微信

微信消息有自己的通道和节奏，单独交给一个助手：它负责收信、回信、凭证过期时提醒重新扫码。其他助手不碰这条通道，避免重复回复。

几条实践规则

1. 一个通道只归一个助手。 两个助手同时轮询同一个消息源，就会出现重复处理。我遇到过一次「两个轮询进程同时在跑」的问题，原因就是手动重启和保活检测叠在了一起。
2. 每个应用用独立的密钥。 不同项目各用各的 API Key，出问题时能快速定位，也方便单独停用。
3. 重要动作先确认。 发消息、删除、花钱这类不可逆的操作，助手先给草稿，我确认后再执行。
4. 写代码先写测试。 让助手按 TDD 来，测试就是验收标准。

小结

把 AI 助手当成一个小团队来管理：职责单一、边界清楚、关键操作有人把关。这样即使某个助手出错，影响也局限在它自己的范围里。