OpenClaw + Claude Code 超强教程：一个人就能搭建完整的开发团队！

今天分享一个很炸裂的实践案例。（文末附教程）

一个独立开发者，用 OpenClaw + Codex/CC 搭了一套 AI Agent系统，实现了什么效果呢？

一天 94 次提交，30 分钟完成 7 个 PR，而且这一天他还开了 3 个客户会议，编辑器都没打开过。

这是真实发生在 2026 年 1 月的事。作者把整个系统的架构、工作流、代码配置都公开了，看完觉得这个思路太值得学习了，所以整理成这篇文章分享给你。

如果你也在用 Codex 或 Claude Code，或者对 OpenClaw 感兴趣，这篇文章会给你很多启发。

一个人，一天 94 次代码提交

先看几个数据，感受一下这套系统的威力：

• 单日最高 94 次提交（平均每天 50 次提交）
• 30 分钟内完成 7 个 PR
• 从想法到上线的速度快到可以"当天交付客户需求"

作者用这套系统在做一个真实的 B2B SaaS 产品，配合创始人直销，大部分功能需求都能当天搞定。速度快到什么程度？客户提需求，当天就能看到效果，直接转化成付费用户。

成本呢？每月 $190（Claude $100 + Codex $90），新手起步 $20 就能跑起来。

你可能会问：这是不是堆了一堆 AI 工具，然后疯狂生成垃圾代码？

不是的。作者的 Git 历史看起来像是"刚招了一个开发团队"，但实际上只有他一个人。关键变化是：他从"管理 Claude Code"变成了"管理一个 AI 管家，这个管家再去管理一群 Claude Code"。

• 1 月之前：直接用 Codex 或 Claude Code 写代码
• 1 月之后：用 OpenClaw 作为编排层，让它调度 Codex/Claude Code/Gemini

这个转变带来的效果是：系统能自动完成几乎所有小到中等复杂度的任务，不需要人工介入。

为什么 Codex 和 Claude Code 单独用不够好？

这时候，你可能会想：Codex 和 Claude Code 已经很强了，为什么还要加一层编排？

作者给出的答案很直接：Codex 和 Claude Code 对你的业务几乎一无所知。它们只看到代码，看不到完整的业务图景。

这里有个根本性的限制：上下文窗口是固定的，你只能二选一。

你必须做选择往里面塞什么：

• 塞满代码 → 没空间放业务上下文
• 塞满客户历史 → 没空间放代码库

所以单独用 Codex 或 Claude Code 时，你会遇到这些问题：

• 它不知道这个功能是为哪个客户做的
• 它不知道上次类似需求为什么失败了
• 它不知道你的产品定位和设计原则
• 它只能根据当前的代码和你的 prompt 来工作

OpenClaw 改变了这个等式。

它充当编排层，位于你和所有 AI 工具之间。它的角色是：

• 持有所有业务上下文（客户数据、会议记录、历史决策、成功/失败案例）
• 把业务上下文翻译成精确的 prompt，喂给具体的 Agent
• 让这些 Agent 专注做它们擅长的事：写代码

类比一下：

• Codex/Claude Code = 专业厨师，只管做菜
• OpenClaw = 主厨，知道客人口味、食材库存、菜单定位，给每个厨师下达精确指令

这就是为什么需要双层系统：通过上下文的专业化分工，而不是换更强的模型。

双层系统的具体架构：编排层 + 执行层

来看看这套系统的具体架构。

နှစ်အဆင့်၊ တာဝန်ကိုထမ်းဆောင်သည်။

OpenClaw (စီမံခန့်ခွဲမှုအဆင့်) ဘာတွေလုပ်နိုင်သလဲ?

• Obsidian မှတ်စုထဲရှိ အားလုံးသော အစည်းအဝေးမှတ်တမ်းများကို ဖတ်ရှုသည် (အလိုအလျောက် အဆက်အသွယ်)
• ထုတ်လုပ်မှုဒေတာဘေ့စ်ကို (ဖတ်ရန်ခွင့်သာ) ဝင်ရောက်ရယူသည်
• အုပ်ချုပ်သူ API ခွင့်ပြုချက်ရှိသည်၊ ဖောက်သည်ကို တိုက်ရိုက် အားဖြည့်ခြင်းနှင့် အတားအဆီးဖျက်ခြင်းလုပ်နိုင်သည်
• အလုပ်အမျိုးအစားအရ သင့်လျော်သော ကိုယ်စားလှယ်ကို ရွေးချယ်သည်
• ကိုယ်စားလှယ်အားလုံး၏ တိုးတက်မှုကို ကြည့်ရှု၊ မအောင်မြင်ပါက အကြောင်းရင်းကို ချုပ်ချယ်ပြီး prompt ကို ပြန်လည်စမ်းသပ်သည်
• အပြီးသတ်ပြီးနောက် Telegram မှာ ရေးသားသူအား သတင်းပို့သည်

Agent (အကောင်အထည်ဖော်အဆင့်) ဘာတွေလုပ်နိုင်သလဲ?

• ကုဒ်စာကြည့်တိုက်ကို ဖတ်ရေးလုပ်သည်
• စမ်းသပ်မှုများနှင့် တည်ဆောက်မှုများကို လည်ပတ်သည်
• ကုဒ်ကို တင်ပြပြီး PR ဖန်တီးသည်
• code review ၏ အကြောင်းပြန်ချက်များကို တုံ့ပြန်သည်

အရေးကြီးချက်များ: အကောင်အထည်ဖော်အဆင့်ရှိ Agent များသည် ထုတ်လုပ်မှုဒေတာဘေ့စ်ကို မတွေ့ပါ၊ ဖောက်သည်၏ အထူးသဖြစ် အချက်အလက်များကိုလည်း မတွေ့ပါ။ ၎င်းတို့သည် "ဤအလုပ်ကို ပြီးမြောက်ရန် သိရန် လိုအပ်သော အနည်းဆုံး အကြောင်းအရာ" ကိုသာ ရယူသည်။

ဤဒီဇိုင်းသည် ဂရုစိုက်မှုရှိသည်: လုံခြုံရေးနယ်နိမိတ်သည် ရှင်းလင်းပြီး ထိရောက်မှုကို အာမခံသည်။

ပြည့်စုံသော အလုပ်စဉ်: ဖောက်သည်၏ လိုအပ်ချက်မှ PR ပေါင်းစည်းခြင်းအထိ ၈ အဆင့်

ယခု အဓိပ္ပါယ်ရှိ အပိုင်းသို့ ဝင်ရောက်ပါ။ စာရေးသူ၏ မနေ့က ဖြစ်ရပ်မှန်ကိစ္စတစ်ခုကို အသုံးပြု၍ ပြည့်စုံသော လုပ်ငန်းစဉ်ကို လမ်းညွှန်ပါမည်။

နောက်ခံ: ကုမ္ပဏီဖောက်သည်တစ်ဦးက ဖုန်းခေါ်ပြီး သူတို့သည် အရင်က သတ်မှတ်ထားသော ဆက်စပ်မှုများကို အသုံးပြုနိုင်ရန် အဖွဲ့အတွင်း မျှဝေရန် လိုချင်ကြောင်း ပြောကြားခဲ့သည်။

၁ ရှုထောင့်: ဖောက်သည်၏ လိုအပ်ချက် → OpenClaw သဘောပေါက်ပြီး ခွဲခြမ်းစိတ်ဖြာခြင်း

ဖုန်းခေါ်ဆိုမှုပြီးဆုံးပြီးနောက်၊ စာရေးသူနှင့် Zoe (သူ၏ OpenClaw) သည် ဤလိုအပ်ချက်အကြောင်း ဆွေးနွေးခဲ့သည်။

ဤနေရာတွင် အံ့ဩစရာကောင်းသောအချက်မှာ: ရှင်းလင်းချက်ကုန်ကျစရိတ်မရှိ။ အစည်းအဝေးမှတ်တမ်းများသည် Obsidian သို့ အလိုအလျောက် အဆက်အသွယ်ဖြစ်ပြီး၊ Zoe သည် ဖုန်းခေါ်ဆိုမှုအကြောင်းအရာကို ဖတ်ပြီး၊ ဖောက်သည်သည် ဘယ်သူလဲ၊ ၎င်းတို့၏ စီးပွားရေးအခြေအနေ၊ ရှိပြီးသား ဆက်စပ်မှုများကို သိရှိခဲ့သည်။

စာရေးသူနှင့် Zoe သည် လိုအပ်ချက်ကို ခွဲခြမ်းစိတ်ဖြာပြီး၊ အသုံးပြုသူများသည် ရှိပြီးသား ဆက်စပ်မှုများကို သိမ်းဆည်းပြီး တည်းဖြတ်နိုင်သော အထုပ်စနစ်တစ်ခု ဖန်တီးရန် လုပ်ဆောင်ခဲ့သည်။

ထို့နောက် Zoe သည် သုံးခုလုပ်ဆောင်ခဲ့သည်။

• ဖောက်သည်အား အားဖြည့်ခြင်း - အုပ်ချုပ်သူ API ကို အသုံးပြု၍ ဖောက်သည်၏ အသုံးပြုမှုကန့်သတ်ချက်ကို ချက်ချင်း ဖျက်သည်
• ဖောက်သည်၏ ဆက်စပ်မှုကို ဆွဲယူသည် - ထုတ်လုပ်မှုဒေတာဘေ့စ်မှ (ဖတ်ရန်သာ) ဖောက်သည်၏ ရှိပြီးသား ဆက်စပ်မှုကို ရယူသည်
• prompt ကို ဖန်တီးပြီး ကိုယ်စားလှယ်ကို စတင်သည် - အားလုံးသော အကြောင်းအရာကို ထုပ်ပိုးပြီး Codex သို့ ထည့်သွင်းသည်

၂ ရှုထောင့်: ကိုယ်စားလှယ်ကို စတင်သည်

Zoe သည် ဤအလုပ်အတွက် ဖန်တီးခဲ့သည် -

• သီးခြား git worktree (ခွဲခြားထားသော အရပ်ပတ်ဝန်းကျင်)
• tmux အစည်းအဝေး (Agent ကို နောက်ခံတွင် လည်ပတ်စေသည်)

# worktree ဖန်တီးခြင်း + ကိုယ်စားလှယ်ကို စတင်ခြင်း 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 ကို ဘာကြောင့် အသုံးပြုသနည်း? အကြောင်းက အလယ်မှာ အထောက်အကူပြုနိုင်ပါသည်။

AI သည် လမ်းမှ လွှဲသွားပါက၊ ပြန်လည်စတင်ရန် မလိုအပ်ပဲ tmux တွင် အမိန့်ပေးနိုင်သည် -

# ကိုယ်စားလှယ်၏ လမ်းကြောင်းမှားနေသည် tmux send-keys -t codex-templates "ရပ်ပါ။ API အဆင့်ကို ပထမဦးစွာ လုပ်ပါ၊ UI ကို မစဉ်းစားပါ။" Enter

ကိုယ်စားလှယ်သည် အခြားအကြောင်းအရာများကို လိုအပ်သည်

tmux send-keys -t codex-templates "အမျိုးအစား သတ်မှတ်ချက်သည် src/types/template.ts တွင်ရှိသည်၊ ၎င်းကို အသုံးပြုပါ။" Enter အတူတူ၊ အလုပ်သည် 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}

အဆင့် ၃: အလိုအလျောက် စောင့်ကြည့်ခြင်း

Cron အလုပ်တစ်ခုသည် ၁၀ မိနစ်တိုင်း အားလုံးသော အေးဂျင့်များ၏ အခြေအနေကို စစ်ဆေးသည်။

အရေးကြီးချက်: ၎င်းသည် "အေးဂျင့်ကို မေးခြင်း" မဟုတ်ပါ (token များကို အလွန်ကုန်ကျစေသည်)၊ သို့မဟုတ် အထောက်အထားအဖြစ် စစ်ဆေးသည်။

• tmux အစည်းအဝေးသည် အလုပ်လုပ်နေပါသလား?
• PR ဖန်တီးခဲ့ပါသလား?
• CI အခြေအနေက ဘယ်လိုလဲ?
• အောင်မြင်မှုမရှိခဲ့ပါက ပြန်လည်စတင်ရန် လိုအပ်ပါသလား? (အများဆုံး ၃ ကြိမ်သာ ပြန်လည်စမ်းသပ်ပါ)

ဤစောင့်ကြည့်မှု စာရေးစက်သည် ၁၀၀% သေချာသော ဖြစ်စဉ်ဖြစ်ပြီး token များကို အလွန်သက်သာစေသည်၊ လူသားများ၏ အထောက်အကူလိုအပ်သော အခါမှသာ စာရေးသူကို သတိပေးပါမည်။

ဤသည်သည် Ralph Loop ၏ တိုးတက်မှုဖြစ်ပြီး နောက်ပိုင်းတွင် အသေးစိတ် ရှင်းလင်းပါမည်။

အဆင့် ၄: အေးဂျင့် PR ဖန်တီးခြင်း

အေးဂျင့်သည် ကုဒ်ကို ရေးပြီး၊ တင်ပြပြီး၊ ပို့ပြီး၊ gh pr create --fill ကို အသုံးပြု၍ PR ဖန်တီးသည်။

မှတ်ချက်: ဤအချိန်တွင် စာရေးသူသည် သတိပေးမှု မရရှိပါ။ အကြောင်းမှာ PR တစ်ခုသည် "ပြီးဆုံး" ဖြစ်သည်ကို ကိုယ်စားပြုမည်မဟုတ်ပါ။

"ပြီးဆုံး" ၏ အဓိပ္ပါယ်မှာ:

• ✅ PR ဖန်တီးပြီး
• ✅ ဘရိတ်ခ်သည် main သို့ အဆင်ပြေစွာ ထပ်ဆင့်ထားသည် (တိုက်ဆိုင်မှု မရှိ)
• ✅ CI အောင်မြင် (lint၊ အမျိုးအစား စစ်ဆေးခြင်း၊ ယူနစ် စမ်းသပ်ခြင်း၊ E2E စမ်းသပ်ခြင်း)
• ✅ Codex reviewer အောင်မြင်
• ✅ Claude Code reviewer အောင်မြင်
• ✅ Gemini reviewer အောင်မြင်
• ✅ UI ပြောင်းလဲမှုများရှိပါက၊ စာရင်းတွင် ရုပ်ပုံများ ပါဝင်ရမည်

အားလုံးကို ဖြည့်ဆည်းရင်သာ အမှန်တကယ်ပြီးဆုံးသည်ဟု သတ်မှတ်သည်။

အဆင့် ၅: အလိုအလျောက် ကုဒ် ပြန်လည်သုံးသပ်ခြင်း

PR တစ်ခုစီကို အေးဂျင့် သုံးဦးက ပြန်လည်သုံးသပ်မည်။

• Codex Reviewer — အကောင်းဆုံးသော ပြန်လည်သုံးသပ်သူ - အစိတ်အပိုင်းများကို ရှာဖွေရန် ကျွမ်းကျင်
• အတွင်းပိုင်း အမှားများ၊ အမှားကို ကိုင်တွယ်မှု မရှိခြင်း၊ ယှဉ်ပြိုင်မှု အခြေအနေများကို ဖမ်းဆီးနိုင်သည်
• အမှားများနှုန်းသည် အလွန်နိမ့်သည်

• Gemini Code Assist Reviewer — အခမဲ့နှင့် အသုံးပြုရလွယ်ကူ - အခြားပြန်လည်သုံးသပ်သူများ လွတ်လပ်သော လုံခြုံရေး ပြဿနာများနှင့် အဆက်အသွယ် ပြဿနာများကို ရှာဖွေနိုင်သည်
• သေချာသော ပြုပြင်မှု အကြံပြုချက်များ ပေးမည်
• အခမဲ့ဖြစ်လျှင် အသုံးပြုပါ

• Claude Code Reviewer — အထူးသဖြင့် မသုံးစွဲနိုင် - အလွန်ဂရုစိုက်ပြီး "ထည့်သွင်းရန် စဉ်းစားပါ..." ဟု အကြံပြုသည်
• အကြံပြုချက်များ၏ အများစုသည် အလွန်ဒီဇိုင်းဖြစ်သည်
• "critical" ဟု အမှတ်ပေးမထားပါက တိုက်ဆိုင်မှုကို ကျော်လွှားပါ

သုံးဦးသော ပြန်လည်သုံးသပ်သူများသည် PR တွင် တိုက်ရိုက် မှတ်ချက်ပေးမည်။

အဆင့် ၆: အလိုအလျောက် စမ်းသပ်ခြင်း

CI ပိုက်လိုင်းသည် လည်ပတ်မည်:

• Lint နှင့် TypeScript စစ်ဆေးခြင်း
• ယူနစ် စမ်းသပ်ခြင်း
• E2E စမ်းသပ်ခြင်း
• Playwright စမ်းသပ်ခြင်း (ထုတ်လုပ်မှု ပတ်ဝန်းကျင်နှင့် တူညီသော ကြိုတင်ကြည့်ရှု့ပတ်ဝန်းကျင်တွင် လည်ပတ်)

ပြီးခဲ့သောအပတ်တွင် ထည့်သွင်းခဲ့သော စည်းမျဉ်း: PR သည် UI ကို ပြောင်းလဲခဲ့ပါက၊ ဖော်ပြချက်တွင် ရုပ်ပုံများကို ထည့်သွင်းရမည်၊ မဟုတ်ပါက CI သည် တိုက်ရိုက် မအောင်မြင်ပါ။

ဤစည်းမျဉ်းသည် ပြန်လည်သုံးသပ်မှု အချိန်ကို အလွန်တိုတောင်းစေသည် - စာရေးသူသည် ရုပ်ပုံကို တစ်ကြည့်ကြည့်ပြီး ပြောင်းလဲမှုကို သိရှိနိုင်သည်၊ ကြိုတင်ကြည့်ရှု့ပတ်ဝန်းကျင်သို့ ဝင်ရောက်ရန် လိုအပ်မည်မဟုတ်။

အဆင့် ၇: လူသား ပြန်လည်သုံးသပ်ခြင်း

ယခု၊ စာရေးသူသည် Telegram သတိပေးမှုကို ရရှိသည်: "PR #341 သည် ပြင်ဆင်ပြီး၊ ပြန်လည်သုံးသပ်ရန် အသင့်ဖြစ်သည်။"

ဤအချိန်တွင်:

• CI သည် အပြုံးဖြစ်သည်
• သုံးဦးသော AI ပြန်လည်သုံးသပ်သူများသည် အတည်ပြုထားသည်
• ရုပ်ပုံသည် UI ပြောင်းလဲမှုကို ပြသထားသည်
• အားလုံးသော အစိတ်အပိုင်းများကို ပြန်လည်သုံးသပ်မှတ်ချက်တွင် မှတ်သားထားသည်

စာရေးသူ၏ ပြန်လည်သုံးသပ်မှုသည် ၅-၁၀ မိနစ်သာ လိုအပ်သည်။ PR များစွာတွင် သူသည် ကုဒ်ကို မကြည့်ဘဲ ရုပ်ပုံကိုသာ ကြည့်ပြီး တိုက်ရိုက် ပေါင်းထည့်သည်။

အဆင့် ၈: ပေါင်းထည့်ခြင်း

PR ကို ပေါင်းထည့်သည်။ နေ့စဉ် cron အလုပ်တစ်ခုသည် လွတ်လပ်သော worktree နှင့် အလုပ်မှတ်တမ်းများကို သန့်ရှင်းသည်။完整流程走完，从客户需求到代码上线，可能只用了 1-2 小时，而作者的实际投入可能只有 10 分钟。

## 三个让系统更聪明的机制

### 机制 1：改进版 Ralph Loop — 不只是重复，而是学习

你可能听过 Ralph Loop：从记忆拉取上下文 → 生成输出 → 评估结果 → 保存学习。

但大多数实现有个问题：每次循环用的 prompt 都一样。学习到的东西改善了未来的检索，但 prompt 本身是静态的。

这套系统不一样。

当 Agent 失败时，Zoe 不会用同样的 prompt 重启。她会带着完整的业务上下文，分析失败原因，然后重写 prompt：

❌ 坏例子（静态 prompt）：
{
"实现自定义模板功能"
}

✅ 好例子（动态调整）：
{
"停。客户要的是 X,不是 Y。这是他们在会议里的原话:
我们希望保存现有配置,而不是从头创建新的。
重点做配置复用,不要做新建流程。"
}
Zoe 能做这种调整，因为她有执行层 Agent 没有的上下文：

- 客户在会议里说了什么
- 这家公司是做什么的
- 上次类似需求为什么失败了

更进一步，Zoe 不会等你分配任务，她会主动找活干：

- 早上：扫描 Sentry → 发现 4 个新错误 → 启动 4 个 Agent 去调查和修复
- 会议后：扫描会议记录 → 发现 3 个客户提到的功能需求 → 启动 3 个 Codex
- 晚上：扫描 git log → 启动 Claude Code 更新 changelog 和客户文档

作者散步回来，Telegram 上显示："7 个 PR 准备好了。3 个新功能，4 个 bug 修复。"

成功的模式会被记录下来：

- "这种 prompt 结构对账单功能很有效"
- "Codex 需要提前拿到类型定义"
- "总是要包含测试文件路径"

奖励信号是：CI 通过、三个 code review 通过、人工合并。任何失败都会触发循环。

时间越长，Zoe 写的 prompt 越好，因为她记得什么能成功。

### 机制 2：Agent 选择策略 — 不同任务找不同的专家

不是所有 Agent 都一样强。作者总结的选择策略：

- Codex(gpt-5.3-codex) — 主力- 后端逻辑、复杂 bug、多文件重构、需要跨代码库推理的任务
- 慢但彻底
- 占 90% 的任务

- Claude Code(claude-opus-4.5) — 速度型选手- 前端工作
- 权限问题少，适合 git 操作
- （作者以前更常用，但 Codex 5.3 出来后就换了）

- Gemini — 设计师- 有设计审美
- 对于漂亮的 UI，先让 Gemini 生成 HTML/CSS 规范，再交给 Claude Code 在组件系统里实现
- Gemini 设计，Claude 建造

Zoe 会根据任务类型自动选择 Agent，并在它们之间传递输出。账单系统 bug 给 Codex，按钮样式修复给 Claude Code，新仪表盘设计先给 Gemini。

### 机制 3：瓶颈在哪？RAM

这里有个意外的限制：不是 token 成本，不是 API 速率，而是内存。

每个 Agent 需要：

- 自己的 worktree
- 自己的 nodemodules
- 运行构建、类型检查、测试

5 个 Agent 同时跑 = 5 个并行的 TypeScript 编译器 + 5 个测试运行器 + 5 套依赖加载到内存。

作者的 Mac Mini(16GB RAM）最多同时跑 4-5 个 Agent，再多就开始 swap，而且得祈祷它们不要同时构建。所以他买了一台 Mac Studio M4 Max(128GB RAM,$3500)，3 月底到货。他说到时候会分享值不值。

## 你也可以搭建：从零到运行只需 10 分钟

想试试这套系统？

最简单的方法：

把这整篇文章复制给 OpenClaw，告诉它："按照这个架构，给我的代码库实现一套 Agent 集群系统。"

然后，它就会：

- 读取架构设计
- 创建脚本
- 设置目录结构
- 配置 cron 监控

10 分钟搞定。

你需要准备：

- OpenClaw 账号
- Codex 和/或 Claude Code 的 API 访问
- 一个 git 仓库
- （可选）Obsidian 用于存储业务上下文

## 2026：一个人的百万美元公司

作者在文末说了一段话，我觉得很有启发性：

"我们会看到大量一个人的百万美元公司从 2026 年开始出现。杠杆是巨大的，属于那些理解如何构建递归自我改进 AI 系统的人。"
这就是它的样子：

- 一个 AI 编排者作为你的延伸（就像 Zoe 之于作者）
- 把工作委派给专门的 Agent，处理不同的业务职能
- 工程、客户支持、运营、营销
- 每个 Agent 专注于它擅长的事
- 你保持专注和完全控制

下一代创业者不会雇 10 个人去做一个人加一套系统就能做的事。他们会这样构建——保持小规模，快速行动，每天发布。

现在 AI 生成的垃圾内容太多了。各种炒作，各种"任务控制中心"的花哨 demo，但没有真正有用的东西。

作者说他想做相反的事：少炒作，多记录真实的构建过程。真实的客户，真实的收入，真实的提交发布到生产环境，也有真实的失败。

这篇文章就到这里。

核心要点回顾：

- 双层架构：编排层持有业务上下文，执行层专注代码
- 完整自动化：从需求到 PR 的 8 步流程，大部分任务一次成功
- 动态学习：不是重复执行，而是根据失败原因调整策略
- 成本可控：起步 $20/月，重度使用 $190/月

如果你也在探索 AI 自动化的实践应用，希望这个案例能给你一些启发。

参考地址：[[HTMLPLACEHOLDER_0]]