一、开篇：再也不需要亲自写代码了

我现在几乎不碰代码编辑器了。

不是我不想写，而是真的没那个必要。过去四周，我干了一件有点疑狂的事：我把所有的 Claude Code 和 Codex 都塞进了一个叫 OpenClaw 的编排系统里，让一个叫 Zoe 的“虚拟主管”去调度它们。这套系统的核心理念很简单：把业务理解和代码生成彻底分层，让专门的“人”干专门的活。

效果如何？说几个吓人的数据：

现在看我的 Git 提交记录，就像我背后藏了一个开发团队。其实只有我一个人，只不过我从“亲自写代码”，变成了“管理一个会写代码的系统”。

二、痛点：你也在当“高级打字员”吗？

很多人用 Claude Code 或者 Codex，其实还是在当“高级打字员”或者“提示词保姆”。你肯定遇到过这种情况：它们懂代码，但不懂你的生意。上下文窗口就那么大，你塞满了代码库，它就没地方装业务逻辑；你跟它聊了一堆客户背景，它转头又看不懂你的底层结构了。

这就导致你永远在“纠正它”、“教它做人”。你花在提示词调优和上下文管理上的时间，甚至比自己写代码还多。这个问题的根源在于：你试图用一个工具解决所有问题，但任何单一的 AI 编码助手都有其局限性——它们不是为“理解你的整个生意”而设计的。

真正的解法不是找一个更强的模型，而是建一套系统，让多个 AI 各司其职，同时有一个“大脑”来统筹全局。这就是我搭建 Zoe 的初衷。

三、解法：彻底分层的编排架构

我的解法是彻底分层。我把 Zoe 当成真正的大脑，它连着我的 Obsidian 知识库，里面全是会议纪要、客户抱怨、以前踩过的坑。具体写代码的脏活累活，Zoe 会拆解成一个个小任务，精准投喂给底下的 Codex 或 Claude 代理。

干活的人只管写代码，统筹的人只管业务方向。互不干扰。这种架构的核心优势在于：每个 AI 代理都只需要关注自己最擅长的领域，而 Zoe 作为中枢负责把业务上下文、客户需求、技术约束等信息精准地分发给它们。这就像一个真实的开发团队：产品经理负责理解需求，技术主管负责拆解任务，开发者负责写代码。

在这套架构中，Obsidian 知识库扮演了至关重要的角色。它不仅存储会议纪要和客户反馈，还记录了每次技术决策的背景和原因。当 Zoe 需要做决策时，它能够回溯历史记录，避免重蹈覆辙，真正做到了“知道为什么这么做”。

四、真实案例：一通电话到上线，全程自动

拿上周的一个真实例子来说。客户打完电话提了个需求，我根本不用去整理什么需求文档，Zoe 已经自动同步了我的会议纪要。它自己干了三件事：

第一，调 API 给客户充了积分，解除限制。这是一个即时的、不需要写代码的操作，Zoe 直接调用相应的接口就完成了。这个动作让客户在等待技术团队响应的同时，已经能够继续使用产品，极大地提升了用户体验。

第二，去生产数据库把客户现在的配置拉了出来。这个步骤的意义在于，当代理开始写代码时，它已经知道客户的当前配置状态、业务规则和数据结构，不需要反复确认和补充信息。

第三，直接在后台拉起一个 Codex 代理，把前因后果交代得清清楚楚，让它开干。这个代理拿到的不仅仅是“改个配置”这样的简单指令，而是包含了客户业务背景、历史决策、技术约束的完整任务描述。

代码全跑在独立的隔离环境里。如果跑偏了怎么办？我不用杀掉进程重头来，直接敲一行命令让它转向：“别管 UI 了，先去改 API 层。”这种实时纠偏的能力，让整个开发流程变得极其灵活。

五、自动巡检：每 10 分钟一次的后台拉网

我设了个后台脚本，每 10 分钟自动巡检一次。只要 PR 没过测试，或者被审查员挑出毛病，Zoe 会自动重新派单，最多重试三次。我不盯屏幕，有事它才叫我。

这套自动巡检机制的精妙之处在于，它不是简单地重复执行同样的操作。每次重试时，Zoe 会根据上一次失败的原因调整策略。如果是因为代码逻辑错误，它会让代理重新分析需求；如果是因为测试用例不全，它会先让另一个代理补充测试用例。这种智能重试机制让成功率大幅提升。

六、严苛标准：三个 AI 交叉审代码

关于什么叫“做完了”，我定了个极其严苛的死规矩：不是你写完代码就算完。PR 建好了没？跟主分支冲突没？CI 全过没？最狠的是，我让三个不同的 AI 交叉审代码。

三个 AI 审查员的分工如下：

如果改了 UI，PR 里没放截图，直接判失败，不用过。等这套流程全部跑完，我的 Telegram 才会弹消息：“PR 准备好了。”这时候我点开一看：测试全绿，三个 AI 审核员没意见，截图一目了然。我花个三五分钟扫一眼，点个合并，完事。

七、智能重试：不是无脑重复，而是复盘复盘

市面上很多教搞 AI Agent 的，失败就是无脑用同样的提示词重试。我没这么干。Zoe 如果发现底下的小弟卡住了，它会去翻旧账：“上次这个需求我们为什么没这么做？因为客户嫌贵。”然后把这个信息直接怕到新提示词里去纠正它。

这种“复盘式重试”的思路来源于真实的团队管理经验。一个成熟的项目经理在解决问题时，不会只是简单地让人重做，而是会回顾之前的决策背景、客户反馈和技术约束。Zoe 正是模仿了这种思维模式，把它应用到了 AI 代理的协作中。

Zoe 甚至会主动找活儿干。早上扫一眼报错日志，自动派单修 Bug；晚上扫一眼代码记录，自动让 Claude 写变更日志。我散个步回来，7 个 PR 就在那等我了。

八、模型分工：各司其职的赛博员队

经过这段时间的折腾，我对这几个模型的脾气摸得很透。干重活、搞后端重构、查疑难杂症，Codex 是绝对的主力，包揽了我 90% 的活儿，虽然慢点但稳。搞前端或者 Git 操作，Claude Code 响应快，不容易扯皮。要是画新界面，我干脆让 Gemini 出 HTML/CSS 的草图，再丢给 Claude 去套组件。

各模型的核心优势对比：

Zoe 就是根据活儿的性质，当包工头去分派。它不是简单地轮询三个模型，而是根据任务类型、复杂度、紧急程度和成本考量来做最优分配。简单的 UI 调整可能直接派给 Claude，而复杂的后端重构则一定会留给 Codex。

九、现实瓶颈：内存告急

别以为全自动化了就没烦恼。我现在最大的瓶颈，你绝对猜不到——是内存。

每个代理跑起来都要拉一堆依赖，还要跑编译、跑测试。五个代理一齐上阵，就是五个编译器在狂转。我那台 16G 内存的 Mac Mini 直接被干到爆内存卡死。没辄，上周我直接咬牙下单了一台 128G 内存的 M4 Mac Studio。为了这群赛博员工，老板也是拼了老命买设备。

这个瓶颈说明了一个重要的现实：AI 代理编排系统的硬件成本不容忽视。每个并行运行的代理都需要独立的运行环境，包括依赖包、编译器、测试框架等。随着代理数量的增加，内存需求会呈指数级增长。如果你计划搭建类似的系统，建议从一开始就预留充足的硬件资源。

十、未来展望：一人百万美元公司的时代

从明年开始，你会看到大量“一人百万美元公司”冒出来。但前提是，你得懂怎么建一套能自我进化的系统，而不是天天跟着 AI 的屁股后面擦屁股。

现在的圈子里，吹 Agent 概念的太多，拿真实流水说事的太少。我反其道而行之，不整虚的，只记录真实踩坑。每一次失败的自动化尝试、每一次审查被拒绝的 PR、每一次因为上下文不足导致的重做，都是宝贵的经验。

核心心得是：别把 AI 当成一个超级工具，要把它当成一个需要管理的团队。工具需要你亲自操作，而团队需要你定清楚规则、提供资源、建立流程，然后让它们自己跑。这两者的思维模式截然不同，后者的上限远高于前者。

十一、关于 Agentic PR

顺便说一句，我拿这套系统正在搞一个叫 Agentic PR 的生意，专帮初创公司搞媒体发稿，一个人干翻传统公关公司，客户也不用再交智商税。有兴趣的，咱们可以聊聊。