Plan Mode dalam Claude Code: Panduan Langkah demi Langkah dan 4 Fasa pada 2026

Arahan tambahan terdapat dalam dokumentasi Ailoot.

Apakah Plan Mode, dan mengapa ia tidak mencukupi jika digunakan sendirian?#

Dalam mod biasa, Claude Code terus menulis kod dan jika anda tidak memantau kerjanya, anda mungkin tiba-tiba mendapat diff merentasi banyak fail. Plan Mode menyusun semula langkahnya: kajian dan perancangan dahulu, kemudian kelulusan, kemudian perubahan.

Anthropic menerangkan Plan Mode dalam dokumentasi rasminya seperti berikut:

Bunyinya mudah, tetapi di sebaliknya terdapat perubahan utama. Plan Mode mengubah rentak kerja: capai persetujuan dahulu, kemudian bertindak. Ini perubahan mod, bukannya pengubahsuaian kosmetik. Masalah bagi mereka yang menulis kod secara spontan ialah ejen AI cenderung bertindak tergesa-gesa. Jika anda meminta, “Tambah pengesahan Google,” dalam mod biasa Claude akan menulis kod dalam seminit, tetapi separuh daripada fail yang diubah mungkin salah. Dalam Plan Mode, permintaan yang sama menjadi pelan teks yang boleh anda baca dalam dua minit dan betulkan sebelum sebarang kod disentuh.

Inilah perangkap yang tidak ditulis dalam panduan antarabangsa. Plan Mode sahaja ialah alat yang lemah: pelan hanya wujud dalam perbualan semasa. Tutup tetingkap dan pelan itu hilang. Anda tidak boleh menyerahkannya kepada ejen lain. Tiada versi atau sejarah. Jika tugasan itu besar (memfaktorkan semula modul 30 fail, berpindah ke pangkalan data baharu), pelan itu akan cepat mencapai had tetingkap konteks dan mula merosot.

Sebab itulah Plan Mode berfungsi dengan baik bersama folder plans/ dalam repositori. Pelan disimpan sebagai plans/2026-05-21-google-oauth.md, dibahagikan kepada fasa dengan kotak semak, dan ejen seterusnya boleh menyambung kerjanya. Begitulah kejuruteraan konteks berfungsi—mengurus konteks sebelum prompt, bukan semasa prompt.

Bagaimanakah cara mengaktifkan Plan Mode dalam Claude Code?#

Cara terpantas semasa sesi ialah menggunakan papan kekunci:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

Selepas dua kali menekannya, penunjuk ⏸ plan mode on akan muncul di bahagian bawah terminal. Kali ketiga akan mengembalikan mod biasa. Ini cara yang paling mudah—aktifkan dengan pantas apabila anda melihat tugasan semakin besar.

Cara kedua ialah menambah awalan sebelum satu prompt:

/plan write a plan to migrate the database from MySQL to Postgres

Pilihan ini berguna apabila anda berada dalam mod auto-accept dan tidak mahu mengubahnya untuk seluruh sesi. Satu permintaan dalam Plan Mode, kemudian kerja diteruskan seperti biasa.

Cara ketiga ialah semasa melancarkan sesi:

claude --permission-mode plan

Gunakannya apabila anda tahu lebih awal bahawa sesuatu tugasan memerlukan perancangan. Contohnya, sebelum pemfaktoran semula besar atau migrasi.

Cara keempat ialah menetapkan mod lalai dalam .claude/settings.json dalam projek:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Bilakah cara ini berguna? Apabila pasukan bekerja pada sistem kompleks yang mana sebarang perubahan boleh menjejaskan modul bersebelahan. Plan Mode lalai melindungi semua orang daripada perubahan tidak sengaja.

Trik kelima yang sering terlepas pandang: Ctrl+G membuka pelan dalam editor teks. Gunakannya apabila pelan itu hampir tepat, tetapi anda perlu menyusun semula 2-3 perkara atau menambah kekangan. Edit secara manual, simpan, dan Claude akan meneruskan dengan versi anda.

Apakah 4 fasa kanonik Anthropic dalam Plan Mode: Explore, Plan, Implement, Commit?#

Banyak panduan menerangkan 3 fasa (Explore-Plan-Execute) atau hanya 2 (Plan-Implement). Itu semua penyederhanaan. Dalam panduan amalan terbaik rasmi, Anthropic menerangkan tepat 4 fasa. Perbezaan ini penting: menjadikan Commit fasa berasingan mendorong anda merekodkan hasil, bukannya membiarkannya dengan “saya buat beberapa pembetulan lagi, nanti saya commit”—punca paling lazim kerja hilang.

Semakin tepat pelan, semakin sedikit iterasi yang diperlukan untuk pelaksanaan. Jika anda meluangkan 10 minit untuk pelan, pelaksanaannya mengambil satu prompt. Jika anda melakarkan pelan dalam seminit, pelaksanaannya akan mengambil masa sejam untuk pembetulan.

Begini rupa 4 fasa tersebut apabila menambah Google OAuth (contoh daripada Anthropic Docs):

Prompt juga berbeza bagi setiap fasa. Dalam Explore: “baca /src/auth dan fahami cara kita mengendalikan sesi dan log masuk”. Dalam Plan: “Saya mahu menambah Google OAuth. Fail manakah yang perlu diubah? Cipta pelan”. Dalam Implement: “laksanakan aliran OAuth daripada pelan anda, tulis ujian, jalankan suite dan baiki kegagalan”. Dalam Commit: “buat commit dengan mesej deskriptif dan buka PR”.

Satu nuansa penting: Plan Mode tidak menghalang Claude daripada menjalankan arahan untuk membuat kajian. Read, LS, Glob, Grep, web fetch dan arahan shell untuk penerokaan dibenarkan. Hanya Edit, Write dan sebarang operasi sistem fail yang mengubah keadaan dilarang. Ini bermakna Claude boleh membaca struktur projek, menjalankan git log dan melihat ujian—tetapi tidak boleh mengubah apa-apa secara tidak sengaja.

Bagaimanakah anda membaca pelan Claude dan memutuskan sama ada hendak meluluskannya?#

Selepas selesai mencipta pelan, Claude memaparkan pilihan tindakan seterusnya:

• Luluskan dan mulakan dalam mod auto
• Luluskan dan benarkan edit
• Luluskan dan semak setiap edit secara manual
• Teruskan perancangan dengan maklum balas
• Perhalus dengan Ultraplan (semakan dalam pelayar)

Mengetahui sama ada hendak meluluskan pelan ialah kemahiran utama dalam Plan Mode. Mudah untuk menekan “Approve” secara automatik, kemudian terpaksa membatalkan commit. AI penjilat mahu memberikan jawapan pantas, dan anda mahu cepat sampai ke kod. Kedua-duanya silap.

Pelan yang baik memenuhi 7 kriteria:

1. Nama fail yang khusus. Bukan “Saya akan kemas kini pengesahan”, tetapi “Saya akan mengubah src/auth/login.ts:42-58, mencipta src/auth/oauth-callback.ts dan mengemas kini src/auth/session.ts:103.”
2. Turutan dinyatakan. Pelan dibahagikan kepada fasa atau langkah, bukannya “saya akan buat semua ini entah bagaimana”.
3. Kebergantungan luaran dinamakan. Jika tugasan memerlukan pustaka baharu, nyatakannya. Jika pemboleh ubah persekitaran diperlukan, senaraikannya.
4. Risiko disenaraikan. Pelan yang baik menyatakan, “Migrasi mungkin merosakkan sesi sedia ada; X perlu diperiksa.” Pelan yang buruk berdiam diri tentang kesan sampingan.
5. Kriteria kejayaan dinyatakan. “Ujian test/auth lulus, linter bersih, dan pelayan dev bermula tanpa ralat.”
6. Tiada andaian yang direka-reka. Jika Claude berkata “Saya akan menggunakan pustaka Z”, semak: adakah anda memasangnya dalam projek? Jika AI mereka-rekanya, anda akan nampak pustaka itu tidak disebut dalam package.json.
7. Pelan muat pada skrin. Jika pelan untuk ciri mudah mengambil 200 baris, tugasan itu mungkin terlalu besar untuk satu pelan. Bahagikannya kepada beberapa bahagian.

Jika pelan gagal dalam semakan, terdapat tiga pilihan:

• Teruskan perancangan dengan maklum balas—berikan Claude ulasan khusus tentang perkara yang tidak disukai, kemudian Claude akan menulis semula pelan.
• Ctrl+G—buka pelan dalam editor, edit secara manual dan simpan. Claude akan meneruskan dengan versi anda.
• Perhalus dengan Ultraplan—pelan dibuka dalam mod pelayar Claude Code di web, tempat anda menyemak bahagian dan memberi komen, kemudian menjalankannya secara setempat atau di cloud.

Jika ada yang tidak kena semasa pelaksanaan, jangan paksa. Kembali ke Plan Mode dan tulis semula pelan. Kosnya 10 kali lebih rendah berbanding membatalkan 40 commit kemudian.

Plan Mode + folder plans/: gabungan untuk konteks panjang#

Plan Mode ialah mod Claude Code. Folder plans/ ialah metodologi yang dibina di atasnya. Jika anda menggunakan Plan Mode tanpa folder, anda akan mencapai had selepas sejam bekerja.

Beginilah logiknya. Tetingkap konteks Claude ialah ingatan sesi. Tetingkap itu boleh memuatkan 1 juta token dalam Opus 4.7, tetapi itulah jumlah keseluruhan perbualan anda. Jika anda merancang tugasan kompleks dalam satu perbualan, kemudian meminta pelaksanaan, membincangkan pepijat dan kemudian perkara lain, tetingkap itu akan “mengembang”. Claude mula melupakan keputusan awal, mengelirukan konteks dan bertanya semula.

Penyelesaiannya ialah peraturan emas: satu tugasan—satu perbualan.

Begini caranya:

1. Perbualan 1—bentuk pelan. Aktifkan Plan Mode, terangkan tugasan dan Claude akan mencipta pelan. Simpan pelan di plans/2026-05-21-feature-name.md. Tutup tetingkap.
2. Perbualan 2—bahagikannya kepada fasa. Buka sembang baharu. Minta: “ambil plans/2026-05-21-feature-name.md dan bahagikannya kepada fasa.” Simpan fail yang dikemas kini.
3. Perbualan 3—laksanakan fasa 1. Buka sembang baharu. Minta: “laksanakan Fasa 1 daripada plans/2026-05-21-feature-name.md, dan tandakan kotak apabila item selesai.” Tutup tetingkap.
4. Perbualan 4—laksanakan fasa 2. Buat perkara yang sama.

Apakah manfaatnya? Tetingkap konteks setiap perbualan kekal segar. Claude dalam fasa 3 tidak mengetahui butiran fasa 1, tetapi mengetahui pelan kerana fail plans/ berada dalam repositori. Mana-mana ejen seterusnya (sama ada subejen, sesi baharu atau pelaksanaan melalui /goal) boleh menyambung pelan itu.

Perbandingan pendekatan:

Setiap ciri mempunyai fail pelan tersendiri. Apabila anda perlu mengingati tiga bulan kemudian sebab memilih satu penyedia pembayaran berbanding alternatif, anda boleh membuka pelan berkaitan dan membaca sejarah keputusan: perkara yang dibincangkan, pilihan yang dipertimbangkan dan sebab laluan itu dipilih.

Ini ialah pelan kerja yang hidup; dokumentasi statik menjadi lapuk dalam beberapa bulan.

Bagaimanakah anda boleh meminta Claude bekerja semasa anda tidur dengan Plan Mode dan /goal?#

Had utama sesi AI yang panjang bukanlah model itu sendiri, tetapi orang yang menekan Enter. Setiap kali Claude sampai ke penghujung giliran, ia menunggu respons anda. /goal menghapuskan penantian itu.

Sintaksnya mudah:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

Syarat itu boleh mengandungi sehingga 4000 aksara. Satu matlamat bagi setiap sesi. Selepas setiap giliran, model mini Haiku meneliti transkrip dan memutuskan: “syarat dipenuhi—tamatkan” atau “belum dipenuhi—giliran seterusnya”. Penilai tidak memanggil alat; ia hanya membaca.

Alias untuk mengosongkannya: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Gabungannya dengan Plan Mode begini:

1. Aktifkan Plan Mode (tekan Shift+Tab dua kali).
2. Minta: “cipta pelan untuk memindahkan pangkalan data daripada MySQL kepada Postgres, simpan di plans/2026-05-21-postgres-migration.md bersama fasa dan kriteria.”
3. Semak pelan, edit dan luluskan.
4. Keluar daripada Plan Mode (tekan Shift+Tab sekali lagi).
5. Tetapkan matlamat: “lengkapkan semua fasa dalam plans/2026-05-21-postgres-migration.md, tandakan kotak, semua ujian lulus, atau berhenti selepas 50 giliran.”
6. Tutup komputer riba dan tidur.

Pada waktu pagi, semak hasilnya: sama ada “✓ matlamat selesai” atau “◎ dihentikan selepas 50 giliran”, bersama sejarah perkara yang telah dilakukan.

Terdapat tiga peraturan penting untuk /goal; tanpa aturan ini, anda akan membazirkan token:

Peraturan 1: Keadaan akhir yang boleh diukur. “Jadikan ia kelihatan cantik” ialah arahan yang buruk. “npm test memulangkan 0, npm run lint memulangkan 0, dan satu entri telah ditambah pada CHANGELOG.md” ialah arahan yang baik.

Peraturan 2: Pengesahan yang jelas. Syarat itu harus merujuk kepada sesuatu yang boleh disahkan: arahan, fail atau endpoint. Bukan “semuanya berfungsi”, tetapi “curl localhost:3000/api/users memulangkan 200”.

Peraturan 3: Hadkan bilangan giliran. Sentiasa tambah “atau berhenti selepas N giliran”. Anthropic secara jelas mengesyorkannya dalam dokumentasi:

Jika anda mengaktifkan /goal tanpa had “atau berhenti selepas”, bajet anda boleh habis semalaman.

Apakah kitaran 4 langkah yang menjadikan Plan Mode suatu proses kejuruteraan?#

Kesilapan biasa ialah bertanya “bagaimana saya membaikinya?”: Claude memberikan penyelesaian, anda melaksanakannya, tetapi tiada apa yang berfungsi atau keadaan menjadi lebih buruk. Inilah “AI penjilat”: ia dilatih untuk menjawab dengan pantas, sementara anda mahu cepat sampai kepada kod. Kitaran 4 langkah menangani masalah ini.

Kitaran 4 langkah ini menghalang mod tersebut. Ia digunakan secara berurutan dalam satu sesi Plan Mode:

Langkah 1. Tetapkan fakta tanpa penyelesaian.

Prompt: “Saya mengalami perkara berikut: [penerangan gejala]. Tugas anda sekarang ialah menetapkan fakta. Sebarang penyelesaian, idea dan nasihat adalah dilarang. Hanya: perkara yang saya perhatikan, langkah yang boleh dihasilkan semula, data yang tersedia dan data yang tiada. Syarat henti tegas: JANGAN cadangkan penyelesaian; catat diagnosis sahaja.”

Ini menghalang dorongan pertama AI: “inilah penyelesaiannya”. Claude perlu berhenti pada “perkara yang diketahui dan yang tidak diketahui”.

Langkah 2. Bangunkan pilihan berdasarkan contoh.

Prompt: “Memandangkan diagnosis telah ditetapkan, cari contoh penyelesaian masalah serupa dalam talian. Sekurang-kurangnya 3 pendekatan berbeza. Bagi setiap pendekatan, sertakan pautan ke sumber primer, penerangan ringkas serta kelebihan dan kekurangannya untuk situasi kita.”

Ini menghalang dorongan kedua AI: “reka penyelesaian berdasarkan fikiran sendiri”. Kita menyuruhnya melihat ke luar dan membawa pulang pendekatan yang boleh diperiksa.

Langkah 3. Pelan terperinci dengan risiko.

Prompt: “Ambil pilihan terbaik daripada Langkah 2 dan sediakan pelan terperinci: fail khusus yang perlu disentuh, perkara yang perlu ditambah atau dibuang, ujian yang perlu ditulis, perkara yang mungkin rosak dan risiko yang mungkin timbul 2-3 langkah kemudian.”

Inilah fasa Plan yang biasa, tetapi dengan satu perbezaan: pelan ini berasaskan pilihan yang disahkan daripada Langkah 2, bukannya tekaan Claude.

Langkah 4. Semak pelan kendiri.

Prompt: “Sekarang lakukan semakan kendiri wajib. Semak semula pelan anda dengan jujur: adakah terdapat bahagian yang direka-reka dan tidak disahkan berdasarkan kod, dokumentasi atau contoh daripada Langkah 2? Jika ada, tandakannya dan semak semula pelan.”

Inilah penapis terakhir. Claude perlu memeriksa penaakulannya sendiri dan mengakui bahagian yang dihalusinasikannya. Biasanya sekurang-kurangnya 2 item pelan disemak semula pada langkah ini.

Selepas 4 langkah, pelan itu sedia untuk diluluskan. Anda boleh beralih kepada pelaksanaan dengan yakin bahawa tugasan telah difahami, pilihan telah ditimbang dan risiko telah dipertimbangkan.

Metodologi ini bertujuan untuk mendiagnosis pepijat sukar dan membuat keputusan seni bina—situasi yang mempunyai kos kesilapan tinggi. Apabila digunakan dalam Plan Mode, ia menghapuskan masalah utama mereka yang menulis kod secara spontan: “AI memberikan penyelesaian, saya melaksanakannya dan semuanya rosak.”

Apakah 5 prompt sedia guna yang sesuai untuk tugasan biasa dalam Plan Mode?#

Templat 1. Memfaktorkan semula modul.

Saya mengaktifkan Plan Mode. Tugasan: refaktor modul {module-name}.

Langkah 1: Kaji struktur semasa modul {module-path}. Huraikan:
- fail yang menjadi sebahagian daripada modul
- kebergantungan luar yang dimilikinya
- bahagian yang berulang
- fungsi yang terlalu rumit

Langkah 2: Cari 2-3 contoh refaktor modul serupa dalam talian.
Sekurang-kurangnya 1 sumber mestilah dokumentasi rasmi Anthropic atau dokumentasi framework berkaitan.

Langkah 3: Cipta pelan refaktor dalam plans/YYYY-MM-DD-refactor-{module}.md:
- fail yang perlu dinamakan semula
- fungsi yang perlu diasingkan ke dalam modul berasingan
- ujian yang perlu dikekalkan dan ditulis semula
- risiko: perkara yang mungkin menjejaskan pengguna

Langkah 4: Semak kendiri. Adakah pelan ini mengandungi sebarang andaian yang "direka-reka"?
Tulis semula atau buangkannya.

Templat 2. Migrasi pangkalan data.

Saya mengaktifkan Plan Mode. Tugasan: pindahkan pangkalan data daripada {old} kepada {new}.

Langkah 1: Kaji skema pangkalan data semasa menggunakan {schema-reading-command}. Huraikan:
- jadual yang wujud dan saiznya
- hubungan, indeks dan kekangan yang ada
- lokasi penyimpanan migrasi
- data yang kritikal

Langkah 2: Cari contoh migrasi {old → new} dalam projek produksi.
Sekurang-kurangnya 3 pendekatan berbeza: pg_dump, dual-write, blue-green.
Senaraikan kelebihan dan risiko setiap pendekatan untuk saiz data kita.

Langkah 3: Cipta pelan migrasi dalam plans/YYYY-MM-DD-db-migration.md:
- fasa (sandaran, migrasi, pengesahan, pertukaran)
- kriteria kejayaan bagi setiap fasa
- pelan undur jika berlaku masalah
- gangguan atau tiada gangguan

Langkah 4: Semak kendiri. Adakah semua angka disokong oleh dokumentasi?
Adakah semua langkah telah disemak berdasarkan persekitaran pembangunan?

Templat 3. Menambah ciri baharu.

Saya mengaktifkan Plan Mode. Tugasan: tambah ciri {description} pada projek.

Langkah 1: Kaji cara ciri serupa berfungsi dalam projek.
Khususnya, lihat:
- {file-1}
- {file-2}
- corak seni bina yang digunakan
- ujian yang ditulis untuk ciri serupa

Langkah 2: Cari cara ciri ini dilaksanakan dalam projek sumber terbuka
yang mempunyai seni bina serupa. Sekurang-kurangnya 2 pendekatan berbeza.

Langkah 3: Cipta pelan dalam plans/YYYY-MM-DD-feature-{name}.md:
- senarai fail baharu
- senarai fail yang diubah berserta baris khusus
- urutan pelaksanaan
- ujian yang perlu ditambah
- perkara yang perlu ditambah kepada CLAUDE.md sebagai peraturan untuk sesi akan datang

Langkah 4: Semak kendiri. Adakah pelan ini mengikut seni bina projek?
Adakah ia mengandaikan penggunaan pustaka yang belum dipasang?

Templat 4. Menulis ujian.

Saya mengaktifkan Plan Mode. Tugasan: uji modul {name}.

Langkah 1: Kaji modul {path}. Kenal pasti:
- fungsi awam dan tandatangannya
- fungsi dalaman yang TIDAK akan kita uji (butiran pelaksanaan)
- kes pinggir: input kosong, ralat, akses serentak

Langkah 2: Cari contoh ujian bagi kelas tugasan serupa
dalam projek sumber terbuka popular yang menggunakan framework yang sama.

Langkah 3: Cipta pelan ujian dalam plans/YYYY-MM-DD-tests-{module}.md:
- senarai ujian bagi setiap fungsi awam
- mock yang diperlukan
- fixtures yang diperlukan
- pendekatan pengesahan (gaya assertion)

Langkah 4: Semak kendiri. Adakah semua ujian menyemak tingkah laku dan bukannya pelaksanaan?
Adakah kes pinggir telah diliputi?

Templat 5. Menyahpepijat ralat kompleks.

Saya mengaktifkan Plan Mode. Tugasan: fahami punca ralat {symptom-description}.

Langkah 1: TETAPKAN FAKTA. Penyelesaian dan idea dilarang. Hanya:
- perkara yang saya perhatikan (teks ralat yang tepat)
- langkah yang boleh menghasilkannya semula
- data yang tersedia (log, trace, versi pustaka)
- data yang tiada (perkara tambahan yang perlu dikumpulkan)

Langkah 2: Cari contoh ralat ini.
Sekurang-kurangnya 3 sumber: isu GitHub, dokumentasi.
Bagi setiap sumber, berikan pautan dan ringkasan penyelesaian.

Langkah 3: Cipta pelan diagnostik dalam plans/YYYY-MM-DD-bug-{name}.md:
- hipotesis yang perlu diperiksa (mengikut kebarangkalian)
- arahan/skrip untuk memeriksa setiap hipotesis
- hasil jangkaan bagi setiap pemeriksaan

Langkah 4: Semak kendiri. Adakah terdapat hipotesis dalam pelan yang "direka-reka"?
Adakah semua hipotesis berpaut pada fakta daripada Langkah 1?

Salin setiap templat, gantikan {parameters} dengan nilai anda sendiri, kemudian tampalkannya ke Claude Code dalam Plan Mode. Hasilnya ialah pelan kerja dalam plans/ yang boleh anda luluskan dan gunakan untuk pelaksanaan.

Plan Mode berbanding mod biasa: yang manakah patut anda pilih?#

Anthropic menyatakannya secara terus dalam dokumentasi:

Langkau pelan berasingan hanya apabila diff sebenar kecil, difahami dan berisiko rendah. Gunakan perancangan apabila perlu mencari pendekatan atau menyelaraskan perubahan berisiko merentas komponen. Mengetahui nama fail atau meringkaskan matlamat dalam satu ayat tidak menghapuskan risiko migrasi, pengesahan atau integriti data.

Jadual keputusan:

Sebelum memilih mod, tanya sama ada pendekatan, kesan sampingan dan pengesahan difahami. Kerjakan terus perubahan kecil setempat berisiko rendah dengan pemeriksaan jelas. Rancang dahulu apabila terdapat ketidakpastian, kod belum biasa, migrasi, pengesahan atau penyelarasan merentas komponen—walaupun anda sudah boleh menamakan semua 3-5 fail terjejas.

Bagaimanakah Plan Mode + CLAUDE.md + subejen digabungkan untuk kerja yang boleh diharap?#

CLAUDE.md ialah fail yang dibaca Claude pada permulaan setiap sesi, termasuk Plan Mode. Jika CLAUDE.md menyatakan “jangan sekali-kali hardkod tarikh; sentiasa dapatkannya daripada pangkalan data”, pelan tidak akan mencadangkan hardkod. Jika tiada peraturan itu, pelan boleh mencadangkan apa sahaja.

Begini cara gabungan ini berfungsi:

Lapisan 1. CLAUDE.md menetapkan peraturan.

Fail itu menyatakan stack projek, prinsip seni bina, larangan (“jangan gunakan API yang sudah lapuk”) dan keperluan (“semua e-mel mesti menggunakan susun atur bersama”). Panduan terperinci: Cara mengkonfigurasi CLAUDE.md.

Lapisan 2. Plan Mode menggunakan peraturan pada tugasan.

Apabila anda mengaktifkan Plan Mode dan meminta “tambah OAuth”, Claude membaca CLAUDE.md, melihat peraturan (“simpan token dalam Redis, bukan pangkalan data”) dan terus mengambil kira peraturan itu dalam pelan. Pelan tersebut mematuhi seni bina projek.

Lapisan 3. Subejen membahagikan kerja.

Jika pelan dibahagikan kepada fasa, setiap fasa boleh diserahkan kepada subejen yang berbeza. Setiap subejen bekerja dalam tetingkap konteksnya sendiri tanpa memenuhi tetingkap utama. Pelan dalam plans/ kekal sebagai sumber rujukan utama: subejen membacanya, melaksanakan fasanya dan mengemas kini kotak semak.

Apakah 7 kesilapan yang merosakkan Plan Mode?#

Kesilapan 1. Pelan hanya wujud dalam sembang.

Gejala: anda menulis pelan, menutup tetingkap dan perlu kembali keesokan harinya—tetapi tiada apa-apa di sana; konteks sudah hilang. Penyelesaian: sentiasa simpan pelan dalam repo di plans/YYYY-MM-DD-feature-name.md. Sembang ialah meja kerja; fail ialah arkib.

Kesilapan 2. Semua tugasan berada dalam satu sembang.

Gejala: dalam satu sesi, anda membincangkan pengesahan, kemudian migrasi, reka bentuk UI dan pepijat. Tetingkap konteks “mengembang” dan Claude melupakan perkara terdahulu. Penyelesaian: satu tugasan—satu perbualan. Pelan selesai? Tutup tetingkap. Mahu mula melaksanakan? Buka tetingkap baharu.

Kesilapan 3. Satu pelan 3000 baris tanpa fasa.

Gejala: pelan wujud, tetapi tiada kotak semak atau pembahagian. Sukar untuk mengetahui perkara yang sudah selesai dan yang belum. Kerja tidak boleh diserahkan. Penyelesaian: bahagikan setiap pelan kepada 3-7 fasa. Setiap fasa ialah senarai kotak semak dengan tindakan khusus.

Kesilapan 4. Tiada kajian mendalam sebelum membuat pelan.

Gejala: Claude mencadangkan penyelesaian sendiri kerana anda tidak memintanya mencari contoh. Seminggu kemudian, anda mendapati sumber terbuka sudah lama mempunyai pendekatan yang lebih baik. Penyelesaian: Langkah 2 kitaran 4 langkah—minta Claude mencari 2-3 contoh dalam talian sebelum mencipta pelan.

Kesilapan 5. AI penjilat memberikan penyelesaian tanpa diagnosis.

Gejala: anda bertanya “bagaimana membaiki ralat X?”, Claude memberikan penyelesaian, anda melaksanakannya, tetapi tiada apa yang berfungsi atau keadaan bertambah buruk. Penyelesaian: sentiasa mulakan dengan “tetapkan fakta; penyelesaian dilarang”. Selepas diagnosis sahaja, barulah beralih kepada pilihan.

Kesilapan 6. Melangkau semakan kendiri.

Gejala: pelan nampak munasabah, tetapi mengandungi 2-3 andaian yang direka-reka (pustaka rekaan, API yang tidak wujud atau versi yang salah). Pelaksanaan gagal pada perkara tersebut. Penyelesaian: Langkah 4 kitaran 4 langkah—minta Claude menyemak semula pelannya dengan jujur dan menandakan andaian.

Kesilapan 7. Syarat kabur dalam /goal.

Gejala: anda menetapkan /goal make it look nice, membiarkannya semalaman, kemudian bangun dan mendapati kuota $200 telah digunakan. Penyelesaian: gunakan hanya syarat yang boleh diukur, dengan arahan pengesahan dan or stop after N turns yang wajib. Jangan gunakan “jadikannya bagus” atau “kemaskan lagi”.

Kesilapan kelapan, yang paling kerap dilakukan oleh mereka yang menulis kod secara spontan, ialah mengabaikan konsep folder plans/. Plan Mode tanpa folder plans/ bukan metodologi; ia mainan. Jika anda menggunakan Plan Mode tetapi tidak mencipta fail, anda hanya mendapat 10% daripada keupayaannya.

Apakah yang perlu dilakukan selepas pengalaman pertama dengan Plan Mode?#

Tiga langkah konkrit mengikut tahap kesukaran yang meningkat:

Langkah 1. Konfigurasikan CLAUDE.md jika anda belum memilikinya.

Tanpa CLAUDE.md, Plan Mode berfungsi “dalam vakum”—Claude tidak mengetahui peraturan projek dan mencadangkan pelan yang melanggar seni bina. Panduan lengkap: Cara mengkonfigurasi CLAUDE.md. CLAUDE.md minimum terdiri daripada 50-80 baris yang menerangkan stack, peraturan dan larangan. Panjangnya perkara kedua. Kekhususan yang penting.

Langkah 2. Cipta folder plans/ dalam repo.

Tambah folder plans/ ke akar projek. Tetapkan format penamaan: YYYY-MM-DD-feature-name.md. Setiap pelan mempunyai fail tersendiri. Selepas sebulan, anda akan mempunyai 20-30 fail; selepas enam bulan, lebih daripada 100. Itulah sejarah keputusan projek yang hidup.

Langkah 3. Cuba /goal untuk satu tugasan.

Pilih tugasan yang biasanya mengambil masa 30-40 minit jika dilakukan secara manual. Aktifkan Plan Mode, cipta pelan dan simpan di plans/. Keluar daripada Plan Mode. Tetapkan /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns. Tutup komputer riba selama sejam dan lakukan perkara lain. Kembali dan semak hasilnya.

Tiga langkah ini ialah minimum. Ini dibina secara beransur-ansur; jangan cuba menyatukan semuanya dalam satu malam. Mulakan dengan CLAUDE.md, tambah plans/ selepas seminggu, dan cuba /goal semalaman selepas sebulan.

Apabila anda bersedia, kenali Ailoot.