OpenClaw + Claude Code Tutorial yang Sangat Kuat: Satu Orang Boleh Membangunkan Pasukan Pembangunan Lengkap!

Hari ini saya ingin berkongsi satu kes praktikal yang sangat mengagumkan.（Tutorial di akhir artikel）

Seorang pembangun bebas, menggunakan OpenClaw + Codex/CC, telah membangunkan satu sistem AI Agent. Apa kesan yang dicapai?

94 kali penghantaran dalam sehari, 7 PR disiapkan dalam 30 minit, dan pada hari itu dia juga mengadakan 3 mesyuarat pelanggan, tetapi tidak pernah membuka editor.

Ini adalah kejadian sebenar yang berlaku pada Januari 2026. Penulis telah mendedahkan keseluruhan seni bina sistem, aliran kerja, dan konfigurasi kod, dan setelah membacanya, saya rasa idea ini sangat berharga untuk dipelajari, jadi saya menyusunnya menjadi artikel ini untuk dikongsi dengan anda.

Jika anda juga menggunakan Codex atau Claude Code, atau berminat dengan OpenClaw, artikel ini akan memberi anda banyak inspirasi.

Satu Orang, 94 Kali Penghantaran Kod dalam Sehari

Mari kita lihat beberapa data untuk merasakan kuasa sistem ini:

• Penghantaran tertinggi dalam sehari adalah 94 kali (purata 50 kali penghantaran setiap hari)
• 7 PR disiapkan dalam masa 30 minit
• Kelajuan dari idea hingga pelancaran sangat cepat sehingga boleh "menyampaikan keperluan pelanggan pada hari yang sama"

Penulis menggunakan sistem ini untuk membangunkan produk B2B SaaS yang sebenar, bersama dengan penjualan langsung oleh pengasas, kebanyakan keperluan fungsi dapat diselesaikan pada hari yang sama. Seberapa cepat? Apabila pelanggan mengemukakan keperluan, mereka dapat melihat kesan pada hari yang sama, dan terus menukar kepada pengguna berbayar.

Kosnya? $190 sebulan (Claude $100 + Codex $90), pemula boleh mula dengan $20.

Anda mungkin bertanya: Adakah ini hanya mengumpulkan sekumpulan alat AI, kemudian menghasilkan kod sampah secara gila-gila?

Tidak. Sejarah Git penulis kelihatan seperti "baru sahaja mengupah satu pasukan pembangun", tetapi sebenarnya hanya dia seorang. Perubahan utama adalah: dia beralih dari "mengurus Claude Code" kepada "mengurus seorang pengurus AI, yang seterusnya mengurus sekumpulan Claude Code".

• Sebelum Januari: Menulis kod secara langsung menggunakan Codex atau Claude Code
• Selepas Januari: Menggunakan OpenClaw sebagai lapisan pengaturcaraan, membolehkannya menjadwalkan Codex/Claude Code/Gemini

Kesan perubahan ini adalah: sistem dapat menyelesaikan hampir semua tugas kecil hingga sederhana secara automatik, tanpa memerlukan campur tangan manusia.

Mengapa Codex dan Claude Code Tidak Cukup Baik Jika Digunakan Secara Terpisah?

Pada ketika ini, anda mungkin berfikir: Codex dan Claude Code sudah cukup kuat, mengapa perlu menambah satu lapisan pengaturcaraan?

Jawapan penulis sangat langsung: Codex dan Claude Code hampir tidak tahu apa-apa tentang perniagaan anda. Mereka hanya melihat kod, tidak melihat gambaran keseluruhan perniagaan.

Di sini terdapat satu batasan asas: tetingkap konteks adalah tetap, anda hanya boleh memilih satu daripada dua.

Anda mesti membuat pilihan tentang apa yang ingin dimasukkan:

• Penuh dengan kod → Tiada ruang untuk konteks perniagaan
• Penuh dengan sejarah pelanggan → Tiada ruang untuk repositori kod

Oleh itu, apabila menggunakan Codex atau Claude Code secara terpisah, anda akan menghadapi masalah ini:

• Ia tidak tahu fungsi ini untuk pelanggan mana
• Ia tidak tahu mengapa permintaan serupa sebelum ini gagal
• Ia tidak tahu penentuan produk dan prinsip reka bentuk anda
• Ia hanya dapat bekerja berdasarkan kod semasa dan prompt anda

OpenClaw mengubah persamaan ini.

Ia berfungsi sebagai lapisan pengaturcaraan, terletak di antara anda dan semua alat AI. Peranannya adalah:

• Memegang semua konteks perniagaan (data pelanggan, catatan mesyuarat, keputusan sejarah, kes kejayaan/kegagalan)
• Menterjemahkan konteks perniagaan menjadi prompt yang tepat, memberi kepada ejen tertentu
• Membolehkan ejen ini fokus pada apa yang mereka mahir: menulis kod

Perbandingan:

• Codex/Claude Code = Koki profesional, hanya memasak
• OpenClaw = Ketua koki, tahu selera pelanggan, inventori bahan, penentuan menu, memberi arahan tepat kepada setiap koki

Inilah sebabnya mengapa sistem dua lapisan diperlukan: melalui pembahagian kerja profesional dalam konteks, bukan hanya menggantikan dengan model yang lebih kuat.

Seni Bina Sistem Dua Lapisan: Lapisan Pengaturcaraan + Lapisan Pelaksanaan

Mari kita lihat seni bina sistem ini.

Dua lapisan, masing-masing menjalankan tugasnya:

Apa yang boleh dilakukan oleh OpenClaw (Lapisan Penyelarasan)?

• Membaca semua rekod mesyuarat dalam nota Obsidian (synchronisasi automatik)
• Mengakses pangkalan data pengeluaran (hak akses baca sahaja) untuk mendapatkan konfigurasi pelanggan
• Mempunyai hak akses API pentadbir, boleh terus menambah nilai kepada pelanggan dan membatalkan sekatan
• Memilih ejen yang sesuai berdasarkan jenis tugas
• Memantau kemajuan semua ejen, jika gagal akan menganalisis sebab dan menyesuaikan prompt untuk mencuba semula
• Setelah selesai, memberitahu penulis melalui Telegram

Apa yang boleh dilakukan oleh Ejen (Lapisan Pelaksanaan)?

• Membaca dan menulis dalam repositori kod
• Menjalankan ujian dan membina
• Menghantar kod dan membuat PR
• Menjawab maklum balas semakan kod

Poin penting: Ejen di lapisan pelaksanaan tidak akan pernah mengakses pangkalan data pengeluaran, dan tidak akan melihat maklumat sensitif pelanggan. Mereka hanya mendapatkan "konteks minimum yang perlu diketahui untuk menyelesaikan tugas ini".

Reka bentuk ini sangat bijak: sempadan keselamatan yang jelas, sambil memastikan kecekapan.

Aliran Kerja Lengkap: 8 Langkah dari Permintaan Pelanggan ke Penggabungan PR

Kini kita memasuki bahagian inti. Menggunakan kes sebenar penulis minggu lalu, membawa anda melalui proses lengkap.

Latar belakang: Seorang pelanggan korporat menelefon, mengatakan mereka ingin menggunakan semula tetapan yang telah mereka konfigurasi, untuk dikongsi dalam pasukan.

Langkah 1: Permintaan Pelanggan → OpenClaw Memahami dan Memecahkan

Selepas panggilan, penulis dan Zoe (OpenClaw-nya) berbincang tentang permintaan ini.

Keajaiban di sini: kos penjelasan sifar. Kerana semua rekod mesyuarat diselaraskan secara automatik ke Obsidian, Zoe sudah membaca kandungan panggilan, tahu siapa pelanggan, senario perniagaan mereka, dan konfigurasi sedia ada.

Penulis dan Zoe bersama-sama memecahkan permintaan menjadi: membuat sistem templat, membolehkan pengguna menyimpan dan mengedit konfigurasi sedia ada.

Kemudian Zoe melakukan tiga perkara:

• Menambah nilai kepada pelanggan — menggunakan API pentadbir untuk segera membatalkan sekatan penggunaan pelanggan
• Mengambil konfigurasi pelanggan — mendapatkan tetapan sedia ada pelanggan dari pangkalan data pengeluaran (baca sahaja)
• Menghasilkan prompt dan memulakan ejen — membungkus semua konteks, memberi kepada Codex

Langkah 2: Memulakan Ejen

Zoe mencipta untuk tugas ini:

• satu git worktree yang berdiri sendiri (persekitaran cabang yang terasing)
• satu sesi tmux (membolehkan Ejen berjalan di latar belakang)

# 创建 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 Mengapa menggunakan tmux? Kerana boleh campur tangan di tengah jalan.

Jika AI tersasar, tidak perlu membunuh dan memulakan semula, terus beri arahan dalam tmux:

# 代理方向错了 tmux send-keys -t codex-templates "停一下。先做 API 层,别管 UI。" Enter

代理需要更多上下文

tmux send-keys -t codex-templates "类型定义在 src/types/template.ts,用那个。" Enter Sementara itu, tugas akan direkodkan dalam fail JSON:[[HTMLPLACEHOLDER0]] [[HTMLPLACEHOLDER1]] [[HTMLPLACEHOLDER2]] [[HTMLPLACEHOLDER3]] [[HTMLPLACEHOLDER4]] [[HTMLPLACEHOLDER5]] [[HTMLPLACEHOLDER6]] [[HTMLPLACEHOLDER7]] [[HTMLPLACEHOLDER8]] [[HTMLPLACEHOLDER9]] [[HTMLPLACEHOLDER10]] [[HTMLPLACEHOLDER11]] [[HTMLPLACEHOLDER12]] [[HTMLPLACEHOLDER13]] [[HTMLPLACEHOLDER14]] [[HTMLPLACEHOLDER15]] [[HTMLPLACEHOLDER16]] [[HTMLPLACEHOLDER17]] [[HTMLPLACEHOLDER18]] [[HTMLPLACEHOLDER19]] [[HTMLPLACEHOLDER20]] [[HTMLPLACEHOLDER21]] [[HTMLPLACEHOLDER22]] [[HTMLPLACEHOLDER23]] [[HTMLPLACEHOLDER24]] [[HTMLPLACEHOLDER25]] [[HTMLPLACEHOLDER26]] [[HTMLPLACEHOLDER27]] [[HTMLPLACEHOLDER28]]Proses lengkap selesai, dari permintaan pelanggan hingga kod dilancarkan, mungkin hanya mengambil masa 1-2 jam, sementara penglibatan sebenar penulis mungkin hanya 10 minit.

Tiga Mekanisme untuk Menjadikan Sistem Lebih Pintar

Mekanisme 1: Ralph Loop Versi Diperbaiki — Bukan Hanya Mengulang, Tetapi Belajar

Anda mungkin pernah mendengar tentang Ralph Loop: Mengambil konteks dari ingatan → Menghasilkan output → Menilai hasil → Menyimpan pembelajaran.

Tetapi kebanyakan pelaksanaan mempunyai satu masalah: setiap kali gelung, prompt yang digunakan adalah sama. Apa yang dipelajari memperbaiki pengambilan di masa depan, tetapi prompt itu sendiri adalah statik.

Sistem ini berbeza.

Apabila Agent gagal, Zoe tidak akan memulakan semula dengan prompt yang sama. Dia akan membawa konteks perniagaan yang lengkap, menganalisis sebab kegagalan, dan kemudian menulis semula prompt:

❌ Contoh Buruk (prompt statik): { "Melaksanakan fungsi templat tersuai" }

✅ Contoh Baik (penyesuaian dinamik): { "Berhenti. Apa yang pelanggan mahu adalah X, bukan Y. Ini adalah kata-kata mereka dalam mesyuarat: Kami ingin menyimpan konfigurasi sedia ada, bukan mencipta yang baru dari awal. Tumpukan pada penggunaan semula konfigurasi, jangan buat proses baru." }Zoe dapat melakukan penyesuaian ini kerana dia mempunyai konteks yang tidak dimiliki oleh Agent:

• Apa yang pelanggan katakan dalam mesyuarat
• Apa yang syarikat ini lakukan
• Mengapa permintaan serupa sebelum ini gagal

Lebih jauh lagi, Zoe tidak akan menunggu anda mengagihkan tugas, dia akan secara proaktif mencari kerja:

• Pagi: Mengimbas Sentry → Menemui 4 kesalahan baru → Memulakan 4 Agent untuk menyiasat dan membetulkan
• Selepas mesyuarat: Mengimbas catatan mesyuarat → Menemui 3 keperluan fungsi yang disebut oleh pelanggan → Memulakan 3 Codex
• Malam: Mengimbas log git → Memulakan Claude Code untuk mengemas kini changelog dan dokumen pelanggan

Penulis pulang dari berjalan-jalan, Telegram menunjukkan: "7 PR sudah siap. 3 fungsi baru, 4 pembetulan bug."

Corak kejayaan akan direkodkan:

• "Struktur prompt ini sangat berkesan untuk fungsi bil"
• "Codex perlu mendapatkan definisi jenis lebih awal"
• "Sentiasa perlu menyertakan laluan fail ujian"

Isyarat ganjaran adalah: CI lulus, tiga semakan kod lulus, penggabungan manual. Apa-apa kegagalan akan mencetuskan gelung.

Semakin lama, prompt yang ditulis oleh Zoe semakin baik, kerana dia ingat apa yang boleh berjaya.

Mekanisme 2: Strategi Pemilihan Agent — Cari Pakar Berbeza untuk Tugas Berbeza

Tidak semua Agent sama kuat. Penulis merumuskan strategi pemilihan:

• Codex(gpt-5.3-codex) — Pemain utama- Logik belakang, bug kompleks, pengubahsuaian pelbagai fail, tugas yang memerlukan inferens merentasi repositori kod
• Perlahan tetapi menyeluruh
• Mengambil 90% tugas

• Claude Code(claude-opus-4.5) — Pemain berkelajuan- Kerja depan
• Masalah kebenaran kurang, sesuai untuk operasi git
• (Penulis sebelum ini lebih sering menggunakannya, tetapi setelah Codex 5.3 keluar, dia beralih)

• Gemini — Pereka- Mempunyai estetika reka bentuk
• Untuk UI yang cantik, biarkan Gemini menghasilkan spesifikasi HTML/CSS terlebih dahulu, kemudian serahkan kepada Claude Code untuk melaksanakannya dalam sistem komponen
• Reka bentuk Gemini, bina Claude

Zoe akan secara automatik memilih Agent berdasarkan jenis tugas, dan menyampaikan output di antara mereka. Bug sistem bil diberikan kepada Codex, pembetulan gaya butang diberikan kepada Claude Code, reka bentuk papan pemuka baru diberikan kepada Gemini terlebih dahulu.

Mekanisme 3: Di Mana Kelemahan? RAM

Di sini terdapat batasan yang tidak dijangka: bukan kos token, bukan kadar API, tetapi memori.

Setiap Agent memerlukan:

• Worktree sendiri
• nodemodules sendiri
• Menjalankan binaan, pemeriksaan jenis, ujian

5 Agent berjalan serentak = 5 penyusun TypeScript selari + 5 pelari ujian + 5 set kebergantungan dimuatkan ke dalam memori.

Mac Mini penulis (16GB RAM) paling banyak dapat menjalankan 4-5 Agent serentak, lebih banyak daripada itu akan mula bertukar, dan perlu berdoa agar mereka tidak membina pada masa yang sama.Jadi dia membeli sebuah Mac Studio M4 Max (128GB RAM, $3500), yang akan tiba pada akhir bulan Mac. Dia berkata akan berkongsi sama ada ia berbaloi atau tidak.\n\n## Anda juga boleh membina: Dari kosong hingga beroperasi hanya dalam 10 minit\n\nIngin mencuba sistem ini?\n\nCara yang paling mudah: \n\nSalin keseluruhan artikel ini kepada OpenClaw, beritahu ia: "Mengikut seni bina ini, laksanakan satu sistem kumpulan Agent untuk repositori kod saya."\n\nKemudian, ia akan: \n\n- Membaca reka bentuk seni bina\n- Membuat skrip\n- Menetapkan struktur direktori\n- Mengkonfigurasi pemantauan cron\n\nSelesai dalam 10 minit.\n\nAnda perlu menyediakan: \n\n- Akaun OpenClaw\n- Akses API Codex dan/atau Claude Code\n- Satu repositori git\n- (Pilihan) Obsidian untuk menyimpan konteks perniagaan\n\n## 2026: Syarikat juta dolar seorang\n\nPenulis di akhir artikel menyatakan satu perkara yang saya rasa sangat memberi inspirasi: \n\n> "Kita akan melihat banyak syarikat juta dolar seorang muncul mulai 2026. Leverage adalah besar, dimiliki oleh mereka yang memahami cara membina sistem AI yang meningkatkan diri secara berulang."\nIni adalah cara ia berfungsi: \n\n- Seorang pengaturcara AI sebagai lanjutan anda (seperti Zoe kepada penulis)\n- Mengagihkan kerja kepada Agent khusus, mengendalikan fungsi perniagaan yang berbeza\n- Kejuruteraan, sokongan pelanggan, operasi, pemasaran\n- Setiap Agent fokus pada apa yang mereka mahir\n- Anda kekal fokus dan mempunyai kawalan penuh\n\nUsahawan generasi seterusnya tidak akan mengupah 10 orang untuk melakukan apa yang boleh dilakukan oleh seorang dengan satu sistem. Mereka akan membina seperti ini - kekal kecil, bertindak cepat, dan menerbitkan setiap hari.\n\nKini terdapat terlalu banyak kandungan sampah yang dihasilkan oleh AI. Pelbagai gembar-gembur, pelbagai demo "pusat kawalan tugas" yang mewah, tetapi tiada apa yang benar-benar berguna.\n\nPenulis berkata dia ingin melakukan perkara yang bertentangan: kurang gembar-gembur, lebih banyak merekod proses pembinaan yang sebenar. Pelanggan sebenar, pendapatan sebenar, penyerahan sebenar ke persekitaran pengeluaran, juga terdapat kegagalan yang sebenar.\n\nArtikel ini sampai di sini.\n\nUlasan poin utama: \n\n- Seni bina dua lapisan: lapisan pengaturcaraan memegang konteks perniagaan, lapisan pelaksanaan fokus pada kod\n- Automasi lengkap: proses 8 langkah dari keperluan hingga PR, kebanyakan tugas berjaya dalam satu percubaan\n- Pembelajaran dinamik: bukan pelaksanaan berulang, tetapi menyesuaikan strategi berdasarkan sebab kegagalan\n- Kos terkawal: bermula dari $20/bulan, penggunaan berat $190/bulan\n\nJika anda juga sedang meneroka aplikasi praktikal automasi AI, saya harap kes ini dapat memberi anda sedikit inspirasi.\n\nRujukan alamat: \n[[HTMLPLACEHOLDER_29]]