从零到英雄：我是怎么发现自己不需要睡觉也能写代码的
兄弟们姐妹们，今天我要给你们讲一个真实的故事。一个关于我如何从一个每天熬夜改Bug的程序员，变成了一个躺在沙发上喝咖啡、遛狗、接客户电话，然后回来发现代码已经写完了的神奇故事。
这事要从上个月说起。那天我正在刷Twitter，突然看到有人说："我用AI写代码，一天能写50个commit"。我当时就想："吹牛吧？我手动写一天都写不了50个commit，你AI能行？"
然后我看了看自己的Git历史：嗯，好家伙，那一天我写了94个commit。而且那天我还开了三个客户会议，从头到尾没碰过编辑器。我的Git历史看起来就像是突然招了一整个开发团队，实际上就我一个人，只不过我学会了怎么指挥一群AI小弟干活。
今天就给你们扒一扒，我是怎么从一个对着Claude Code喊"给我写个登录页面"的萌新，变成了一个用OpenClaw管理着一群Codex和Claude Code智能体的"包工头"。
为什么直接指挥AI就像让猫去遛狗
首先咱们得明白一个道理：直接让Codex或者Claude Code干活，就跟让你家二哈去遛猫一样，不是不能做，但结果往往很魔幻。
为什么？因为这些AI小弟们有个致命的缺陷：它们对你的业务一无所知。
它们能看到代码，但它们看不到你客户的邮件记录，看不到你上周开会时客户说"我想要个蓝色按钮"的笔记，看不到你三天前尝试过某个方案结果失败的惨痛教训。它们就是一群只懂代码不懂业务的码农，你给什么需求，它们就写什么代码，完全不考虑"客户真正想要的是什么"。
这就是问题所在。你的上下文窗口是固定的，往里塞代码就没空间放业务背景，塞业务背景就装不下代码。这是个零和游戏，你必须做出选择。
所以我搞了个骚操作：两层架构。上面一层是OpenClaw，我叫它Zoe，它掌握所有业务上下文；下面一层是一群Codex和Claude Code小弟，它们只管写代码。Zoe负责把业务需求翻译成精准的编程指令，小弟们负责执行。
从客户需求到代码上线：一个真实的奇迹诞生记
让我给你们还原一下上周的真实场景，让你们感受一下这套系统有多变态。
那天下午，我接了个客户电话。是个代理商客户，他们想在系统里复用已经配置好的模板，让团队其他人也能直接用。聊了半小时，挂了电话。
这时候神奇的事情发生了。我打开和Zoe的对话（对，我和我的智能体聊天），因为所有会议笔记都自动同步到了我的Obsidian笔记库，Zoe完全知道刚才发生了什么。我们俩一起分析需求，最后确定了要做个模板系统，让客户能保存和编辑已有的配置。
然后Zoe干了三件事：
第一，给客户账户充值，让他们能立即用上（是的，Zoe有API管理权限，能直接操作后台）。
第二，从生产数据库把客户的现有配置拉出来（注意，只有Zoe有生产数据库只读权限，下面写代码的小弟永远碰不到这些敏感数据）。
第三，启动一个Codex智能体，把包含所有上下文的详细提示词扔给它。
整个过程中，我干了什么？我什么都没干。我起来倒了杯咖啡，顺便看了看窗外的云。
智能体军团是怎么被生出来的
你可能好奇这些智能体小弟是怎么被"生"出来的。让我给你看看后台的操作：
bash
# 创建独立工作区 + 启动智能体
git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
cd ../feat-custom-templates && pnpm install
tmux new-session -d -s "codex-templates" \
-c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \
"$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"
看到没？每个智能体都有自己的独立工作区，有自己的分支，有自己的tmux会话。它们就像一个个独立的开发人员，各自在角落里默默干活，互相不干扰。
启动命令也很直接：
bash
# Codex智能体
codex --model gpt-5.3-codex \
-c "model_reasoning_effort=high" \
--dangerously-bypass-approvals-and-sandbox \
"这里是详细的提示词"
# Claude Code智能体
claude --model claude-opus-4.5 \
--dangerously-skip-permissions \
-p "这里是详细的提示词"
以前我傻傻地用codex exec或者claude -p，后来发现tmux才是王道。为啥？因为可以在智能体跑偏的时候直接介入纠正：
bash
# 错误示范：智能体在写UI，但应该先搞API层
tmux send-keys -t codex-templates "停！先搞API层，别碰UI" Enter
# 需要更多上下文的时候
tmux send-keys -t codex-templates "schema在src/types/template.ts里，用那个" Enter
这就像你站在一个程序员后面，看他写代码，发现他走偏了，就拍拍他肩膀："嘿，哥们儿，方向错了"。只不过现在这个"程序员"是AI，而"拍肩膀"是通过tmux发指令。
任务跟踪系统：比项目经理还靠谱
这么多智能体同时跑，怎么管理？当然要用系统。
每个任务启动的时候，都会在.clawdbot/active-tasks.json里创建一个记录：
json
{
"id": "feat-custom-templates",
"tmuxSession": "codex-templates",
"agent": "codex",
"description": "代理商客户的自定义模板功能",
"repo": "medialyst",
"worktree": "feat-custom-templates",
"branch": "feat/custom-templates",
"startedAt": 1740268800000,
"status": "running",
"notifyOnComplete": true
}
任务完成后，记录会更新，带上PR号和所有检查结果：
json
{
"status": "done",
"pr": 341,
"completedAt": 1740275400000,
"checks": {
"prCreated": true,
"ciPassed": true,
"claudeReviewPassed": true,
"geminiReviewPassed": true
},
"note": "所有检查通过，可以合并了"
}
这比很多公司的Jira面板都好用，关键是完全自动化，不用任何人手动更新状态。
保姆式监控：智能体也需要有人看着
你以为启动完就完事了？天真。智能体也会犯错，也会卡住，也会跑偏。所以必须有个保姆一直盯着。
我的解决方案是每10分钟跑一次的cron任务。它会运行一个脚本：
bash
.clawdbot/check-agents.sh
这个脚本100%确定性，极端节省token，它只做几件事：
检查tmux会话是否还活着
检查跟踪的分支有没有创建PR
通过gh命令行检查CI状态
如果CI失败或者收到严重评审意见，自动重启智能体（最多尝试3次）
只有真正需要人工介入的时候才发通知
所以我不是盯着终端看，而是系统告诉我什么时候该看。就像你请了个保姆，她会告诉你："孩子哭了，该喂奶了"，而不是让你每10分钟去婴儿房看一眼。
什么叫做"完成"？比甲方要求还严格
这里有个非常重要的点：智能体必须知道什么叫做"完成"。在我的系统里，光创建个PR不算完，必须满足以下所有条件：
PR创建成功
分支和主分支同步，没有合并冲突
CI全部通过（lint检查、类型检查、单元测试、端到端测试）
Codex评审通过
Claude Code评审通过
Gemini评审通过
如果是UI改动，PR描述里必须有截图
第七条是我上周刚加的，如果改了UI但没有截图，CI直接报错。这大大缩短了我的评审时间，因为我一眼就能看出改了啥，不用点开预览环境去翻。
三堂会审：让AI评审AI
每个PR创建后，会有三个不同的AI模型同时进行代码评审。它们各有所长：
Codex评审员是我最喜欢的一个。它对边缘情况的把握简直变态，能发现逻辑错误、遗漏的错误处理、潜在的竞态条件，而且误报率极低。它就像那种经验丰富的老程序员，一眼就能看出你代码里的坑。
Gemini代码评审员是免费的，但超级有用。它擅长发现安全问题和扩展性问题，其他评审员没注意到的地方它都能揪出来。而且它不光指出问题，还会给出具体的修复建议。这种白嫖的好事上哪找去？
Claude Code评审员说实话有点鸡肋。它过于谨慎了，整天提一些"考虑添加..."的建议，大部分都是过度设计。我现在基本只关注它标记为"严重"的评论，但说真的，它很少自己能发现严重问题，最多就是给其他评审员找到的问题点个赞。
这三个评审员会在PR下面发评论，就像真的同事在做代码评审一样。然后PR会自动更新状态，等待所有评审通过。
最后的5分钟：人类老板的终极验收
终于，所有检查都通过了，这时候我会收到Telegram通知："PR #341 可以评审了"。
这时候的PR是什么状态？
CI全部通过
三个AI评审员都点了赞
如果有UI改动，截图清清楚楚放在PR描述里
所有边缘情况和实现细节都在评审评论里有记录
我评审这样一个PR需要多久？5到10分钟。很多PR我甚至不看代码，直接看截图就够了。如果截图显示的UI正是客户想要的，那代码怎么写的重要吗？不重要。
然后我点一下合并按钮，功能就上线了。整个过程，我真正动手的时间不超过10分钟。从客户打电话到功能上线，总共不到两小时。
Zoe的魔法：为什么她比普通的智能体调度器强
你可能听说过Ralph Loop，就是那种"从记忆中提取上下文→生成输出→评估结果→保存经验"的循环。但大多数实现的问题是，每次循环都用同样的提示词。
我的系统不一样。当一个智能体失败的时候，Zoe不是简单地重启它然后用同样的提示词再试一次。她会带着完整的业务上下文去分析失败原因，然后想办法解决问题：
智能体跑出上下文窗口了？"现在只关注这三个文件，别的不看。"
智能体方向错了？"停，客户要的是X不是Y，这是他们在会议上说的。"
智能体需要澄清？"这是客户的邮件，这是他们公司的情况，你看明白了吗？"
Zoe就像一个真正的项目经理，她会一直"哄着"这些智能体直到任务完成。她有智能体们没有的上下文——客户历史、会议笔记、我们之前尝试过什么、为什么失败了。她用这些上下文在每次重试时写出更好的提示词。
但这还不是最变态的。Zoe不会等我分配任务，她会主动找活干：
早上：扫描Sentry错误日志→发现4个新错误→启动4个智能体去调查和修复
会议后：扫描会议笔记→发现客户提到了3个功能需求→启动3个Codex智能体
晚上：扫描Git日志→启动Claude Code去更新更新日志和客户文档
所以我经常是这样的：开完客户会议，出去遛个弯，回来收到Telegram消息："7个PR等评审，3个新功能，4个Bug修复。"
智能体各有特长：选对工具很重要
不是所有智能体都一样，你得知道谁擅长干什么。
Codex是我的主力干将。后端逻辑、复杂Bug、跨文件重构，任何需要在整个代码库里推理的任务都交给它。它慢但细致，我用它处理90%的任务。
Claude Code速度快，前端工作做得好。而且它的权限问题少，适合做Git操作。以前我用它做日常驱动多些，但Codex 5.3出来后，Codex更快更强了。
Gemini有个特殊技能——设计感。如果要写漂亮的UI，我会先让Gemini生成HTML/CSS设计规范，然后交给Claude Code用我们的组件系统去实现。Gemini负责设计，Claude负责建造，完美配合。
Zoe负责为每个任务选择最合适的智能体，并在它们之间路由输出。计费系统的Bug找Codex，按钮样式调整找Claude Code，新仪表盘设计从Gemini开始。
给自己打工：复制粘贴就能拥有这套系统
看到这里，你是不是也想拥有这套系统？好消息是，你不用从头造轮子。
把这篇文章整个复制下来，扔给OpenClaw，告诉它："给我的代码库实现这套智能体军团系统"。它会读懂整个架构，创建所有脚本，设置好目录结构，配置好cron监控。10分钟搞定。
我没课程卖给你，纯粹分享经验。
当前最大的坑：内存不够用
我得诚实告诉你们，这套系统目前有个瓶颈：内存。
每个智能体需要独立的工作区，每个工作区有自己的node_modules，每个智能体跑的时候要跑构建、类型检查、测试。同时跑5个智能体意味着同时跑5个TypeScript编译器、5个测试运行器、5套依赖全加载进内存。
我那台16GB内存的Mac Mini，最多同时跑4-5个智能体就开始用交换分区了，还得祈祷它们不要同时开始构建。
所以我刚剁手买了台Mac Studio M4 Max，128GB内存，3500美刀。这月底到货，到时候再给你们分享值不值得。
2026年：一个人百万美元公司的元年
我觉得从2026年开始，我们会看到大量一人百万美元公司出现。这套系统的杠杆作用太大了，特别是对那些懂得如何构建能自我进化的智能体的人来说。
想象一下：一个AI协调者作为你自己的延伸（就像Zoe对我来说），把工作委派给处理不同业务职能的专业智能体。工程、客服、运营、市场，每个智能体专注于自己擅长的领域。而你保持专注和完全控制。
下一代创业者不会招10个人的团队来做一个人配合合适系统就能做的事。他们会像我这样搭建系统——保持小规模，快速迭代，每天发货。
少点炒作，多点实干
现在网上有太多AI生成的垃圾内容了，太多关于智能体和"控制中心"的炒作，却没做出任何真正有用的东西。全是花哨的演示，没有实际的商业价值。
我想做相反的事：少点炒作，多点记录真正在做的生意。真实客户、真实收入、真实的上线提交，还有真实的失败。
我在做什么？Agentic PR——一个一人公司，挑战企业PR领域的传统巨头。用智能体帮助初创公司获得媒体报道，不需要每月1万美金的顾问费。
如果你想看看这条路能走多远，那就关注我吧。我们一起见证一个人怎么干翻一个行业。