> ## Documentation Index
> Fetch the complete documentation index at: https://cli.fuxicode.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Praktik Terbaik untuk Fuxi Code
> Tips dan pola untuk memaksimalkan Fuxi Code, dari mengonfigurasi lingkungan Anda hingga menskalakan di seluruh sesi paralel.
Fuxi Code adalah lingkungan pengkodean yang bersifat agentic. Tidak seperti chatbot yang menjawab pertanyaan dan menunggu, Fuxi Code dapat membaca file Anda, menjalankan perintah, membuat perubahan, dan bekerja secara mandiri melalui masalah sambil Anda menonton, mengarahkan, atau sepenuhnya menjauh.
Ini mengubah cara Anda bekerja. Alih-alih menulis kode sendiri dan meminta Fuxi untuk meninjau, Anda menjelaskan apa yang Anda inginkan dan Fuxi mengetahui cara membangunnya. Fuxi mengeksplorasi, merencanakan, dan mengimplementasikan.
Namun otonomi ini masih datang dengan kurva pembelajaran. Fuxi bekerja dalam batasan tertentu yang perlu Anda pahami.
Panduan ini mencakup pola yang telah terbukti efektif di seluruh tim internal Anthropic dan untuk insinyur yang menggunakan Fuxi Code di berbagai basis kode, bahasa, dan lingkungan. Untuk cara loop agentic bekerja di balik layar, lihat [Cara Fuxi Code Bekerja](/id/how-fuxi-code-works).
***
Sebagian besar praktik terbaik didasarkan pada satu batasan: jendela konteks Fuxi terisi dengan cepat, dan kinerja menurun saat terisi.
Jendela konteks Fuxi menyimpan seluruh percakapan Anda, termasuk setiap pesan, setiap file yang dibaca Fuxi, dan setiap output perintah. Namun, ini dapat terisi dengan cepat. Sesi debugging tunggal atau eksplorasi basis kode mungkin menghasilkan dan mengonsumsi puluhan ribu token.
Ini penting karena kinerja LLM menurun saat konteks terisi. Ketika jendela konteks hampir penuh, Fuxi mungkin mulai "lupa" instruksi sebelumnya atau membuat lebih banyak kesalahan. Jendela konteks adalah sumber daya paling penting untuk dikelola. Untuk melihat bagaimana sesi terisi dalam praktik, [tonton panduan interaktif](/id/context-window) tentang apa yang dimuat saat startup dan berapa biaya setiap pembacaan file. Lacak penggunaan konteks secara berkelanjutan dengan [baris status khusus](/id/statusline), dan lihat [Kurangi penggunaan token](/id/costs#reduce-token-usage) untuk strategi mengurangi penggunaan token.
***
Berikan Fuxi cara untuk memverifikasi pekerjaannya
Berikan Fuxi sesuatu yang dapat dijalankannya: tes, build, tangkapan layar untuk dibandingkan. Ini adalah perbedaan antara sesi yang Anda saksikan dan sesi yang dapat Anda tinggalkan.
Fuxi berhenti ketika pekerjaan terlihat selesai. Tanpa pemeriksaan yang dapat dijalankannya, "terlihat selesai" adalah satu-satunya sinyal yang tersedia, dan Anda menjadi loop verifikasi: setiap kesalahan menunggu Anda untuk menyadarinya. Berikan Fuxi sesuatu yang menghasilkan lulus atau gagal, dan loop akan menutup dengan sendirinya. Fuxi melakukan pekerjaan, menjalankan pemeriksaan, membaca hasilnya, dan melakukan iterasi hingga pemeriksaan lulus.
Pemeriksaan adalah apa pun yang mengembalikan sinyal yang dapat dibaca Fuxi dalam percakapan: rangkaian tes, kode keluar build, linter, skrip yang membedakan output terhadap fixture, atau [tangkapan layar browser](/id/chrome) dibandingkan dengan desain.
| Strategi | Sebelum | Sesudah |
| ----------------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Sediakan kriteria verifikasi** | *"implementasikan fungsi yang memvalidasi alamat email"* | *"tulis fungsi validateEmail. contoh kasus uji: [user@example.com](mailto:user@example.com) adalah true, invalid adalah false, [user@.com](mailto:user@.com) adalah false. jalankan tes setelah mengimplementasikan"* |
| **Verifikasi perubahan UI secara visual** | *"buat dashboard terlihat lebih baik"* | *"\[tempel tangkapan layar] implementasikan desain ini. ambil tangkapan layar hasilnya dan bandingkan dengan yang asli. daftar perbedaan dan perbaiki"* |
| **Tangani penyebab akar, bukan gejala** | *"build gagal"* | *"build gagal dengan kesalahan ini: \[tempel kesalahan]. perbaiki dan verifikasi build berhasil. tangani penyebab akar, jangan tekan kesalahan"* |
Setelah pemeriksaan ada, putuskan seberapa ketat pemeriksaan tersebut membatasi penghentian:
* **Dalam satu prompt**: minta Fuxi menjalankan pemeriksaan dan melakukan iterasi dalam pesan yang sama, seperti dalam tabel di atas.
* **Sepanjang sesi**: atur pemeriksaan sebagai [kondisi `/goal`](/id/goal). Evaluator terpisah memeriksa ulang setelah setiap giliran dan Fuxi terus bekerja sampai kondisi terpenuhi.
* **Sebagai gerbang deterministik**: [hook Stop](/id/hooks#stop) menjalankan pemeriksaan Anda sebagai skrip dan memblokir giliran dari berakhir sampai lulus. Fuxi Code menimpa hook dan mengakhiri giliran setelah 8 blok berturut-turut.
* **Dengan pendapat kedua**: [subagent verifikasi](/id/sub-agents) atau [alur kerja dinamis](/id/workflows) yang memeriksa temuannya sendiri memiliki model segar yang mencoba menyangkal hasil, sehingga agen yang melakukan pekerjaan bukan yang menilainya.
Setiap langkah menukar setup untuk perhatian. Versi prompt berfungsi pada tugas apa pun hari ini. Versi `/goal` dan Stop hook adalah yang memungkinkan run tanpa pengawasan selesai dengan benar tanpa Anda.
Biarkan Fuxi menunjukkan bukti daripada menegaskan kesuksesan: output tes, perintah yang dijalankannya dan apa yang dikembalikannya, atau tangkapan layar hasilnya. Meninjau bukti lebih cepat daripada menjalankan kembali verifikasi sendiri, dan ini berfungsi untuk sesi yang tidak Anda saksikan.
***
Jelajahi terlebih dahulu, kemudian rencanakan, kemudian kode
Pisahkan penelitian dan perencanaan dari implementasi untuk menghindari menyelesaikan masalah yang salah.
Membiarkan Fuxi langsung melompat ke pengkodean dapat menghasilkan kode yang menyelesaikan masalah yang salah. Gunakan [plan mode](/id/permission-modes#analyze-before-you-edit-with-plan-mode) untuk memisahkan eksplorasi dari eksekusi.
Alur kerja yang direkomendasikan memiliki empat fase:
Masukkan plan mode. Fuxi membaca file dan menjawab pertanyaan tanpa membuat perubahan.
```txt fuxi (plan mode) theme={null}
read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.
```
Minta Fuxi untuk membuat rencana implementasi terperinci.
```txt fuxi (plan mode) theme={null}
I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.
```
Tekan `Ctrl+G` untuk membuka rencana di editor teks Anda untuk pengeditan langsung sebelum Fuxi melanjutkan.
Beralih keluar dari plan mode dan biarkan Fuxi kode, memverifikasi terhadap rencananya.
```txt fuxi (default mode) theme={null}
implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.
```
Minta Fuxi untuk melakukan komit dengan pesan deskriptif dan membuat PR.
```txt fuxi (default mode) theme={null}
commit with a descriptive message and open a PR
```
Plan mode berguna, tetapi juga menambah overhead.
Untuk tugas di mana cakupannya jelas dan perbaikannya kecil (seperti memperbaiki typo, menambahkan baris log, atau mengganti nama variabel) minta Fuxi untuk melakukannya secara langsung.
Perencanaan paling berguna ketika Anda tidak yakin tentang pendekatannya, ketika perubahan memodifikasi beberapa file, atau ketika Anda tidak terbiasa dengan kode yang dimodifikasi. Jika Anda dapat menjelaskan diff dalam satu kalimat, lewati rencana.
***
Berikan konteks spesifik dalam prompt Anda
Semakin tepat instruksi Anda, semakin sedikit koreksi yang Anda butuhkan.
Fuxi dapat menyimpulkan niat, tetapi tidak dapat membaca pikiran Anda. Referensikan file spesifik, sebutkan batasan, dan tunjukkan pola contoh.
| Strategi | Sebelum | Sesudah |
| ------------------------------------------------------------------------------------------------ | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Batasi tugas.** Tentukan file mana, skenario apa, dan preferensi pengujian. | *"tambahkan tes untuk foo.py"* | *"tulis tes untuk foo.py yang mencakup kasus tepi di mana pengguna logout. hindari mock."* |
| **Tunjukkan sumber.** Arahkan Fuxi ke sumber yang dapat menjawab pertanyaan. | *"mengapa ExecutionFactory memiliki api yang aneh?"* | *"lihat melalui riwayat git ExecutionFactory dan ringkas bagaimana api-nya menjadi seperti ini"* |
| **Referensikan pola yang ada.** Tunjukkan Fuxi pola dalam basis kode Anda. | *"tambahkan widget kalender"* | *"lihat bagaimana widget yang ada diimplementasikan di halaman beranda untuk memahami pola. HotDogWidget.php adalah contoh yang baik. ikuti pola untuk mengimplementasikan widget kalender baru yang memungkinkan pengguna memilih bulan dan paginate maju/mundur untuk memilih tahun. bangun dari awal tanpa perpustakaan selain yang sudah digunakan dalam basis kode."* |
| **Jelaskan gejala.** Berikan gejala, lokasi yang mungkin, dan apa "diperbaiki" terlihat seperti. | *"perbaiki bug login"* | *"pengguna melaporkan bahwa login gagal setelah timeout sesi. periksa alur auth di src/auth/, terutama penyegaran token. tulis tes yang gagal yang mereproduksi masalah, kemudian perbaiki"* |
Prompt yang samar dapat berguna ketika Anda mengeksplorasi dan dapat mengubah arah. Prompt seperti `"apa yang akan Anda tingkatkan dalam file ini?"` dapat mengungkap hal-hal yang tidak akan Anda pikirkan untuk ditanyakan.
Berikan konten kaya
Gunakan `@` untuk mereferensikan file, tempel tangkapan layar/gambar, atau pipa data secara langsung.
Anda dapat memberikan data kaya kepada Fuxi dalam beberapa cara:
* **Referensikan file dengan `@`** alih-alih menjelaskan di mana kode berada. Fuxi membaca file sebelum merespons.
* **Tempel gambar secara langsung**. Salin/tempel atau seret dan lepas gambar ke dalam prompt.
* **Berikan URL** untuk dokumentasi dan referensi API. Gunakan `/permissions` untuk allowlist domain yang sering digunakan.
* **Pipa data** dengan menjalankan `cat error.log | fuxi` untuk mengirim konten file secara langsung.
* **Biarkan Fuxi mengambil apa yang dibutuhkan**. Beri tahu Fuxi untuk menarik konteks sendiri menggunakan perintah Bash, alat MCP, atau dengan membaca file.
***
Beberapa langkah setup membuat Fuxi Code jauh lebih efektif di semua sesi Anda. Untuk gambaran lengkap fitur ekstensi dan kapan menggunakan masing-masing, lihat [Perluas Fuxi Code](/id/features-overview).
Tulis FUXI.md yang efektif
Jalankan `/init` untuk menghasilkan file FUXI.md pemula berdasarkan struktur proyek Anda saat ini, kemudian perbaiki seiring waktu.
FUXI.md adalah file khusus yang dibaca Fuxi di awal setiap percakapan. Sertakan perintah Bash, gaya kode, dan aturan alur kerja. Ini memberikan Fuxi konteks persisten yang tidak dapat disimpulkan dari kode saja.
Perintah `/init` menganalisis basis kode Anda untuk mendeteksi sistem build, kerangka kerja tes, dan pola kode, memberikan Anda fondasi solid untuk disempurnakan.
Tidak ada format yang diperlukan untuk file FUXI.md, tetapi tetap singkat dan mudah dibaca manusia. Sebagai contoh:
```markdown FUXI.md theme={null}
# Code style
- Use ES modules (import/export) syntax, not CommonJS (require)
- Destructure imports when possible (eg. import { foo } from 'bar')
# Workflow
- Be sure to typecheck when you're done making a series of code changes
- Prefer running single tests, and not the whole test suite, for performance
```
FUXI.md dimuat setiap sesi, jadi hanya sertakan hal-hal yang berlaku secara luas. Untuk pengetahuan domain atau alur kerja yang hanya relevan kadang-kadang, gunakan [skills](/id/skills) sebagai gantinya. Fuxi memuat mereka sesuai permintaan tanpa membengkak setiap percakapan.
Tetap ringkas. Untuk setiap baris, tanyakan: *"Apakah menghapus ini akan menyebabkan Fuxi membuat kesalahan?"* Jika tidak, potong. File FUXI.md yang membengkak menyebabkan Fuxi mengabaikan instruksi aktual Anda!
| ✅ Sertakan | ❌ Kecualikan |
| ------------------------------------------------------------- | ---------------------------------------------------------------- |
| Perintah Bash yang tidak dapat ditebak Fuxi | Apa pun yang dapat diketahui Fuxi dengan membaca kode |
| Aturan gaya kode yang berbeda dari default | Konvensi bahasa standar yang sudah diketahui Fuxi |
| Instruksi pengujian dan test runner pilihan | Dokumentasi API terperinci (tautkan ke dokumen sebagai gantinya) |
| Etiket repositori (penamaan cabang, konvensi PR) | Informasi yang berubah sering |
| Keputusan arsitektur khusus untuk proyek Anda | Penjelasan panjang atau tutorial |
| Keanehan lingkungan pengembang (variabel env yang diperlukan) | Praktik yang jelas sendiri seperti "tulis kode yang bersih" |
| Gotcha umum atau perilaku yang tidak jelas | Deskripsi file demi file dari basis kode |
Jika Fuxi terus melakukan sesuatu yang tidak Anda inginkan meskipun memiliki aturan melawannya, file mungkin terlalu panjang dan aturan hilang. Jika Fuxi mengajukan pertanyaan yang dijawab di FUXI.md, frasenya mungkin ambigu. Perlakukan FUXI.md seperti kode: tinjau saat ada yang salah, pangkas secara teratur, dan uji perubahan dengan mengamati apakah perilaku Fuxi benar-benar bergeser.
Anda dapat menyesuaikan instruksi dengan menambahkan penekanan (misalnya, "PENTING" atau "ANDA HARUS") untuk meningkatkan kepatuhan. Periksa FUXI.md ke dalam git sehingga tim Anda dapat berkontribusi. File ini meningkat nilainya seiring waktu.
File FUXI.md dapat mengimpor file tambahan menggunakan sintaks `@path/to/import`:
```markdown FUXI.md theme={null}
See @README.md for project overview and @package.json for available npm commands.
# Additional Instructions
- Git workflow: @docs/git-instructions.md
- Personal overrides: @~/.fuxi/my-project-instructions.md
```
Anda dapat menempatkan file FUXI.md di beberapa lokasi:
* **Folder home (`~/.fuxi/FUXI.md`)**: berlaku untuk semua sesi Fuxi
* **Root proyek (`./FUXI.md`)**: periksa ke dalam git untuk dibagikan dengan tim Anda
* **Root proyek (`./FUXI.local.md`)**: catatan khusus proyek pribadi; tambahkan file ini ke `.gitignore` Anda sehingga tidak dibagikan dengan tim Anda
* **Direktori induk**: berguna untuk monorepo di mana `root/FUXI.md` dan `root/foo/FUXI.md` ditarik secara otomatis
* **Direktori anak**: Fuxi menarik file FUXI.md anak sesuai permintaan saat bekerja dengan file di direktori tersebut
Gunakan [auto mode](/id/permission-modes#eliminate-prompts-with-auto-mode) untuk membiarkan classifier menangani persetujuan, `/permissions` untuk allowlist perintah spesifik, atau `/sandbox` untuk isolasi tingkat OS. Masing-masing mengurangi gangguan sambil membuat Anda tetap mengendalikan.
Secara default, Fuxi Code meminta izin untuk tindakan yang mungkin memodifikasi sistem Anda: penulisan file, perintah Bash, alat MCP, dll. Ini aman tetapi membosankan. Setelah persetujuan kesepuluh Anda tidak benar-benar meninjau lagi, Anda hanya mengklik. Ada tiga cara untuk mengurangi gangguan ini:
* **Auto mode**: model classifier terpisah meninjau perintah dan memblokir hanya apa yang terlihat berisiko: eskalasi cakupan, infrastruktur yang tidak dikenal, atau tindakan yang didorong konten bermusuhan. Terbaik ketika Anda mempercayai arah umum tugas tetapi tidak ingin mengklik setiap langkah
* **Allowlist izin**: izinkan alat spesifik yang Anda tahu aman, seperti `npm run lint` atau `git commit`
* **Sandboxing**: aktifkan isolasi tingkat OS yang membatasi akses sistem file dan jaringan, memungkinkan Fuxi bekerja lebih bebas dalam batas yang ditentukan
Baca lebih lanjut tentang [permission modes](/id/permission-modes), [permission rules](/id/permissions), dan [sandboxing](/id/sandboxing).
Beri tahu Fuxi Code untuk menggunakan alat CLI seperti `gh`, `aws`, `gcloud`, dan `sentry-cli` saat berinteraksi dengan layanan eksternal.
Alat CLI adalah cara paling efisien konteks untuk berinteraksi dengan layanan eksternal. Jika Anda menggunakan GitHub, instal CLI `gh`. Fuxi tahu cara menggunakannya untuk membuat masalah, membuka pull request, dan membaca komentar. Tanpa `gh`, Fuxi masih dapat menggunakan GitHub API, tetapi permintaan yang tidak diautentikasi sering kali mencapai batas laju.
Fuxi juga efektif dalam mempelajari alat CLI yang tidak diketahuinya. Coba prompt seperti `Use 'foo-cli-tool --help' to learn about foo tool, then use it to solve A, B, C.`
Hubungkan server MCP
Jalankan `fuxi mcp add` untuk menghubungkan alat eksternal seperti Notion, Figma, atau database Anda.
Dengan [server MCP](/id/mcp), Anda dapat meminta Fuxi untuk mengimplementasikan fitur dari pelacak masalah, query database, menganalisis data pemantauan, mengintegrasikan desain dari Figma, dan mengotomatisasi alur kerja.
Atur hooks
Gunakan hooks untuk tindakan yang harus terjadi setiap kali tanpa pengecualian.
[Hooks](/id/hooks-guide) menjalankan skrip secara otomatis pada titik tertentu dalam alur kerja Fuxi. Tidak seperti instruksi FUXI.md yang bersifat penasihat, hooks bersifat deterministik dan menjamin tindakan terjadi.
Fuxi dapat menulis hooks untuk Anda. Coba prompt seperti *"Tulis hook yang menjalankan eslint setelah setiap pengeditan file"* atau *"Tulis hook yang memblokir penulisan ke folder migrasi."* Edit `.fuxi/settings.json` secara langsung untuk mengonfigurasi hooks dengan tangan, dan jalankan `/hooks` untuk menjelajahi apa yang dikonfigurasi.
Buat skills
Buat file `SKILL.md` di `.fuxi/skills/` untuk memberikan Fuxi pengetahuan domain dan alur kerja yang dapat digunakan kembali.
[Skills](/id/skills) memperluas pengetahuan Fuxi dengan informasi khusus untuk proyek, tim, atau domain Anda. Fuxi menerapkannya secara otomatis saat relevan, atau Anda dapat menginvokannya secara langsung dengan `/skill-name`.
Buat skill dengan menambahkan direktori dengan `SKILL.md` ke `.fuxi/skills/`:
```markdown .fuxi/skills/api-conventions/SKILL.md theme={null}
---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints
- Version APIs in the URL path (/v1/, /v2/)
```
Skills juga dapat mendefinisikan alur kerja yang dapat digunakan kembali yang Anda panggil secara langsung:
```markdown .fuxi/skills/fix-issue/SKILL.md theme={null}
---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.
1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Ensure code passes linting and type checking
7. Create a descriptive commit message
8. Push and create a PR
```
Jalankan `/fix-issue 1234` untuk menginvokannya. Gunakan `disable-model-invocation: true` untuk alur kerja dengan efek samping yang ingin Anda picu secara manual.
Buat subagent khusus
Tentukan asisten khusus di `.fuxi/agents/` yang dapat didelegasikan Fuxi untuk tugas terisolasi.
[Subagents](/id/sub-agents) berjalan dalam konteks mereka sendiri dengan set alat yang diizinkan mereka sendiri. Mereka berguna untuk tugas yang membaca banyak file atau memerlukan fokus khusus tanpa mengacaukan percakapan utama Anda.
```markdown .fuxi/agents/security-reviewer.md theme={null}
---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling
Provide specific line references and suggested fixes.
```
Beri tahu Fuxi untuk menggunakan subagent secara eksplisit: *"Gunakan subagent untuk meninjau kode ini untuk masalah keamanan."*
Instal plugins
Jalankan `/plugin` untuk menjelajahi marketplace. Plugins menambahkan skills, alat, dan integrasi tanpa konfigurasi.
[Plugins](/id/plugins) menggabungkan skills, hooks, subagents, dan server MCP menjadi satu unit yang dapat diinstal dari komunitas dan Anthropic. Jika Anda bekerja dengan bahasa yang diketik, instal [plugin code intelligence](/id/discover-plugins#code-intelligence) untuk memberikan Fuxi navigasi simbol presisi dan deteksi kesalahan otomatis setelah pengeditan.
Untuk panduan memilih antara skills, subagents, hooks, dan MCP, lihat [Perluas Fuxi Code](/id/features-overview#match-features-to-your-goal).
***
Berkomunikasi secara efektif
Cara Anda berkomunikasi dengan Fuxi Code secara signifikan mempengaruhi kualitas hasil.
Tanyakan pertanyaan basis kode
Tanyakan Fuxi pertanyaan yang akan Anda tanyakan kepada insinyur senior.
Saat onboarding ke basis kode baru, gunakan Fuxi Code untuk pembelajaran dan eksplorasi. Anda dapat mengajukan Fuxi pertanyaan yang sama seperti yang Anda tanyakan kepada insinyur lain:
* Bagaimana cara logging bekerja?
* Bagaimana cara membuat endpoint API baru?
* Apa yang dilakukan `async move { ... }` pada baris 134 dari `foo.rs`?
* Kasus tepi apa yang ditangani `CustomerOnboardingFlowImpl`?
* Mengapa kode ini memanggil `foo()` alih-alih `bar()` pada baris 333?
Menggunakan Fuxi Code dengan cara ini adalah alur kerja onboarding yang efektif, meningkatkan waktu ramp-up dan mengurangi beban pada insinyur lain. Tidak ada prompt khusus yang diperlukan: tanyakan pertanyaan secara langsung.
Biarkan Fuxi mewawancarai Anda
Untuk fitur yang lebih besar, biarkan Fuxi mewawancarai Anda terlebih dahulu. Mulai dengan prompt minimal dan minta Fuxi untuk mewawancarai Anda menggunakan alat `AskUserQuestion`.
Fuxi menanyakan tentang hal-hal yang mungkin belum Anda pertimbangkan, termasuk implementasi teknis, UI/UX, kasus tepi, dan trade-off.
```text theme={null}
I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.
Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.
Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.
```
Setelah spesifikasi selesai, mulai sesi segar untuk menjalankannya. Sesi baru memiliki konteks bersih yang fokus sepenuhnya pada implementasi, dan Anda memiliki spesifikasi tertulis untuk direferensikan.
Spesifikasi yang paling berguna adalah mandiri: mereka menamai file dan antarmuka yang terlibat, menyatakan apa yang berada di luar cakupan, dan diakhiri dengan langkah verifikasi end-to-end yang membuktikan fitur berfungsi. Waktu yang dihabiskan untuk membuat spesifikasi presisi memberikan hasil lebih banyak daripada waktu yang dihabiskan untuk menonton implementasi.
***
Kelola sesi Anda
Percakapan bersifat persisten dan dapat dibalik. Gunakan ini untuk keuntungan Anda!
Perbaiki arah dengan cepat dan sering
Perbaiki Fuxi segera setelah Anda melihatnya keluar jalur.
Hasil terbaik datang dari loop umpan balik yang ketat. Meskipun Fuxi kadang-kadang menyelesaikan masalah dengan sempurna pada upaya pertama, memperbaikinya dengan cepat umumnya menghasilkan solusi yang lebih baik lebih cepat.
* **`Esc`**: hentikan Fuxi di tengah-tindakan dengan tombol `Esc`. Konteks dipertahankan, jadi Anda dapat mengarahkan kembali.
* **`Esc + Esc` atau `/rewind`**: tekan `Esc` dua kali atau jalankan `/rewind` untuk membuka menu rewind dan mengembalikan percakapan dan status kode sebelumnya, atau ringkas dari pesan yang dipilih.
* **`"Undo that"`**: biarkan Fuxi mengembalikan perubahannya.
* **`/clear`**: atur ulang konteks antara tugas yang tidak terkait. Sesi panjang dengan konteks yang tidak relevan dapat mengurangi kinerja.
Jika Anda telah memperbaiki Fuxi lebih dari dua kali pada masalah yang sama dalam satu sesi, konteks penuh dengan pendekatan yang gagal. Jalankan `/clear` dan mulai segar dengan prompt yang lebih spesifik yang menggabungkan apa yang Anda pelajari. Sesi bersih dengan prompt yang lebih baik hampir selalu mengungguli sesi panjang dengan koreksi terakumulasi.
Kelola konteks secara agresif
Jalankan `/clear` antara tugas yang tidak terkait untuk mengatur ulang konteks.
Fuxi Code secara otomatis mengompaksi riwayat percakapan saat Anda mendekati batas konteks, yang mempertahankan kode dan keputusan penting sambil membebaskan ruang.
Selama sesi panjang, jendela konteks Fuxi dapat terisi dengan percakapan yang tidak relevan, konten file, dan perintah. Ini dapat mengurangi kinerja dan kadang-kadang mengalihkan Fuxi.
* Gunakan `/clear` sering antara tugas untuk mengatur ulang jendela konteks sepenuhnya
* Ketika auto compaction dipicu, Fuxi meringkas apa yang paling penting, termasuk pola kode, status file, dan keputusan kunci
* Untuk kontrol lebih, jalankan `/compact `, seperti `/compact Focus on the API changes`
* Untuk mengompaksi hanya bagian dari percakapan, gunakan `Esc + Esc` atau `/rewind`, pilih checkpoint pesan, dan pilih **Summarize from here** atau **Summarize up to here**. Yang pertama mengondensasi pesan dari titik itu maju sambil menjaga konteks awal tetap utuh; yang kedua mengondensasi pesan awal sambil menjaga pesan terbaru tetap lengkap. Lihat [Restore vs. summarize](/id/checkpointing#restore-vs-summarize).
* Sesuaikan perilaku compaction di FUXI.md dengan instruksi seperti `"When compacting, always preserve the full list of modified files and any test commands"` untuk memastikan konteks kritis bertahan dari ringkasan
* Untuk pertanyaan cepat yang tidak perlu tetap dalam konteks, gunakan [`/btw`](/id/interactive-mode#side-questions-with-%2Fbtw). Jawabannya muncul dalam overlay yang dapat ditutup dan tidak pernah memasuki riwayat percakapan, jadi Anda dapat memeriksa detail tanpa menumbuhkan konteks.
Gunakan subagents untuk investigasi
Delegasikan penelitian dengan `"use subagents to investigate X"`. Mereka mengeksplorasi dalam konteks terpisah, menjaga percakapan utama Anda bersih untuk implementasi.
Karena konteks adalah batasan fundamental Anda, subagents adalah salah satu alat paling kuat yang tersedia. Ketika Fuxi meneliti basis kode, ia membaca banyak file, semuanya mengonsumsi konteks Anda. Subagents berjalan dalam jendela konteks terpisah dan melaporkan kembali ringkasan:
```text theme={null}
Use subagents to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse.
```
Subagent mengeksplorasi basis kode, membaca file yang relevan, dan melaporkan kembali dengan temuan, semuanya tanpa mengacaukan percakapan utama Anda.
Anda juga dapat menggunakan subagents untuk verifikasi setelah Fuxi mengimplementasikan sesuatu:
```text theme={null}
use a subagent to review this code for edge cases
```
Rewind dengan checkpoints
Setiap prompt yang Anda kirim membuat checkpoint. Anda dapat mengembalikan percakapan, kode, atau keduanya ke checkpoint sebelumnya.
Fuxi secara otomatis membuat snapshot file sebelum setiap perubahan sehingga checkpoint dapat mengembalikannya. Tekan Escape dua kali atau jalankan `/rewind` untuk membuka menu rewind. Anda dapat mengembalikan percakapan saja, mengembalikan kode saja, mengembalikan keduanya, atau meringkas dari pesan yang dipilih. Lihat [Checkpointing](/id/checkpointing) untuk detail.
Alih-alih merencanakan setiap langkah dengan hati-hati, Anda dapat memberi tahu Fuxi untuk mencoba sesuatu yang berisiko. Jika tidak berhasil, rewind dan coba pendekatan berbeda. Checkpoints bertahan di seluruh sesi, jadi Anda dapat menutup terminal dan masih rewind nanti.
Checkpoints hanya melacak perubahan yang dibuat melalui alat pengeditan file Fuxi. Perubahan yang dibuat melalui perintah Bash atau proses eksternal tidak ditangkap. Ini bukan pengganti git.
Lanjutkan percakapan
Beri nama sesi dengan `/rename` dan perlakukan mereka seperti cabang: setiap alur kerja mendapatkan konteks persisten sendiri.
Fuxi Code menyimpan percakapan secara lokal, jadi ketika tugas mencakup beberapa sesi Anda tidak harus menjelaskan ulang konteksnya. Jalankan `fuxi --continue` untuk melanjutkan dari sesi terbaru, atau `fuxi --resume` untuk memilih dari daftar. Berikan sesi nama deskriptif seperti `oauth-migration` sehingga Anda dapat menemukannya nanti. Lihat [Manage sessions](/id/sessions) untuk set lengkap kontrol resume, branch, dan naming.
***
Otomatisasi dan skalakan
Setelah Anda efektif dengan satu Fuxi, kalikan output Anda dengan sesi paralel, mode non-interaktif, dan pola fan-out.
Semuanya sejauh ini mengasumsikan satu manusia, satu Fuxi, dan satu percakapan. Tetapi Fuxi Code skalakan secara horizontal. Teknik di bagian ini menunjukkan bagaimana Anda dapat melakukan lebih banyak.
Jalankan mode non-interaktif
Gunakan `fuxi -p "prompt"` di CI, pre-commit hooks, atau skrip. Tambahkan `--output-format stream-json --verbose` untuk output JSON streaming.
Dengan `fuxi -p "your prompt"`, Anda dapat menjalankan Fuxi secara non-interaktif, tanpa prompt interaktif. Jalankan masih membuat sesi yang dapat dilanjutkan kecuali Anda melewatkan `--no-session-persistence`. [Mode non-interaktif](/id/headless) adalah cara Anda mengintegrasikan Fuxi ke dalam pipeline CI, pre-commit hooks, atau alur kerja otomatis apa pun. Format output memungkinkan Anda mengurai hasil secara terprogram: teks biasa, JSON, atau JSON streaming.
```bash theme={null}
# One-off queries
fuxi -p "Explain what this project does"
# Structured output for scripts
fuxi -p "List all API endpoints" --output-format json
# Streaming for real-time processing
fuxi -p "Analyze this log file" --output-format stream-json --verbose
```
Jalankan beberapa sesi Fuxi
Jalankan beberapa sesi Fuxi secara paralel untuk mempercepat pengembangan, menjalankan eksperimen terisolasi, atau memulai alur kerja kompleks.
Pilih pendekatan paralel yang sesuai dengan seberapa banyak koordinasi yang ingin Anda lakukan sendiri:
* [Worktrees](/id/worktrees): jalankan sesi CLI terpisah dalam checkout git terisolasi sehingga edit tidak bertabrakan
* [Aplikasi desktop](/id/desktop#work-in-parallel-with-sessions): kelola beberapa sesi lokal secara visual, masing-masing dalam worktree-nya sendiri
* [Fuxi Code di web](/id/fuxi-code-on-the-web): jalankan sesi pada infrastruktur cloud yang dikelola Anthropic dalam VM terisolasi
* [Tim agen](/id/agent-teams): koordinasi otomatis dari beberapa sesi dengan tugas bersama, pesan, dan pemimpin tim
Selain paralelisasi pekerjaan, beberapa sesi memungkinkan alur kerja yang berfokus pada kualitas. Konteks segar meningkatkan tinjauan kode karena Fuxi tidak akan bias terhadap kode yang baru saja ditulisnya.
Sebagai contoh, gunakan pola Writer/Reviewer:
| Sesi A (Penulis) | Sesi B (Peninjau) |
| ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Implementasikan rate limiter untuk endpoint API kami` | |
| | `Tinjau implementasi rate limiter di @src/middleware/rateLimiter.ts. Cari kasus tepi, kondisi race, dan konsistensi dengan pola middleware yang ada.` |
| `Berikut adalah umpan balik tinjauan: [output Sesi B]. Tangani masalah ini.` | |
Anda dapat melakukan sesuatu yang serupa dengan tes: biarkan satu Fuxi menulis tes, kemudian yang lain menulis kode untuk lulus.
Fan out di seluruh file
Loop melalui tugas memanggil `fuxi -p` untuk masing-masing. Gunakan `--allowedTools` untuk cakupan izin untuk operasi batch.
Untuk migrasi besar atau analisis, Anda dapat mendistribusikan pekerjaan di seluruh banyak invokasi Fuxi paralel:
Biarkan Fuxi membuat daftar semua file yang perlu dimigrasikan (misalnya, `list all 2,000 Python files that need migrating`)
```bash theme={null}
for file in $(cat files.txt); do
fuxi -p "Migrate $file from React to Vue. Return OK or FAIL." \
--allowedTools "Edit,Bash(git commit *)"
done
```
Perbaiki prompt Anda berdasarkan apa yang salah dengan 2-3 file pertama, kemudian jalankan pada set lengkap. Bendera `--allowedTools` membatasi apa yang dapat dilakukan Fuxi, yang penting ketika Anda menjalankan tanpa pengawasan.
Anda juga dapat mengintegrasikan Fuxi ke dalam pipeline pemrosesan/data yang ada:
```bash theme={null}
fuxi -p "" --output-format json | your_command
```
Gunakan `--verbose` untuk debugging selama pengembangan, dan matikan dalam produksi.
Jalankan secara otonom dengan auto mode
Untuk eksekusi tanpa gangguan dengan pemeriksaan keamanan latar belakang, gunakan [auto mode](/id/permission-modes#eliminate-prompts-with-auto-mode). Model classifier meninjau perintah sebelum dijalankan, memblokir eskalasi cakupan, infrastruktur yang tidak dikenal, dan tindakan yang didorong konten bermusuhan sambil membiarkan pekerjaan rutin berjalan tanpa prompt.
```bash theme={null}
fuxi --permission-mode auto -p "fix all lint errors"
```
Untuk run non-interaktif dengan bendera `-p`, auto mode membatalkan jika classifier secara berulang memblokir tindakan, karena tidak ada pengguna untuk kembali. Lihat [kapan auto mode kembali](/id/permission-modes#when-auto-mode-falls-back) untuk ambang batas.
Tambahkan langkah tinjauan adversarial
Sebelum menganggap tugas selesai, biarkan subagent meninjau diff dalam konteks segar dan melaporkan kesenjangan.
Semakin lama Fuxi bekerja tanpa pengawasan, semakin penting pemeriksaan independen sebelum Anda menghitung pekerjaan sebagai selesai. Peninjau yang berjalan dalam konteks [subagent](/id/sub-agents) segar hanya melihat diff dan kriteria yang Anda berikan, bukan penalaran yang menghasilkan perubahan, sehingga mengevaluasi hasil berdasarkan istilahnya sendiri.
Untuk pemeriksaan kebenaran, jalankan skill [`/code-review`](/id/commands) yang disertakan, yang meninjau diff saat ini untuk bug dalam subagent segar dan mengembalikan temuan ke sesi. Untuk memeriksa diff terhadap rencana Anda, tulis prompt tinjauan sendiri. Beri nama pekerjaan untuk diperiksa, rencana untuk memeriksanya, dan apa yang dihitung sebagai temuan:
```text theme={null}
Gunakan subagent untuk meninjau diff rate limiter terhadap PLAN.md. Periksa bahwa
setiap persyaratan diimplementasikan, kasus tepi yang terdaftar memiliki tes, dan
tidak ada yang di luar cakupan tugas yang berubah. Laporkan kesenjangan, bukan preferensi gaya.
```
Karena peninjau berjalan sebagai subagent, sesi implementasi menerima kesenjangan secara langsung dan dapat memperbaikinya dan meninjau ulang tanpa Anda menyalin temuan antar jendela. Untuk run otonom yang lebih lama, [tim agen](/id/agent-teams) dapat menjaga loop ini berjalan di seluruh banyak tugas sementara Anda spot-check temuan yang dicatat.
Peninjau yang diminta untuk menemukan kesenjangan biasanya akan melaporkan beberapa, bahkan ketika pekerjaan itu solid, karena itulah yang diminta untuk dilakukan. Mengejar setiap temuan menyebabkan over-engineering: lapisan abstraksi ekstra, kode defensif, dan tes untuk kasus yang tidak dapat terjadi. Beri tahu peninjau untuk menandai hanya kesenjangan yang mempengaruhi kebenaran atau persyaratan yang dinyatakan, dan perlakukan sisanya sebagai opsional.
***
Hindari pola kegagalan umum
Ini adalah kesalahan umum. Mengenalinya lebih awal menghemat waktu:
* **Sesi kitchen sink.** Anda mulai dengan satu tugas, kemudian meminta Fuxi sesuatu yang tidak terkait, kemudian kembali ke tugas pertama. Konteks penuh dengan informasi yang tidak relevan.
> **Perbaikan**: `/clear` antara tugas yang tidak terkait.
* **Mengoreksi berulang kali.** Fuxi melakukan sesuatu yang salah, Anda memperbaikinya, masih salah, Anda memperbaiki lagi. Konteks tercemar dengan pendekatan yang gagal.
> **Perbaikan**: Setelah dua koreksi yang gagal, `/clear` dan tulis prompt awal yang lebih baik menggabungkan apa yang Anda pelajari.
* **FUXI.md yang terlalu spesifik.** Jika FUXI.md Anda terlalu panjang, Fuxi mengabaikan setengahnya karena aturan penting hilang dalam kebisingan.
> **Perbaikan**: Pangkas tanpa ampun. Jika Fuxi sudah melakukan sesuatu dengan benar tanpa instruksi, hapus atau ubah menjadi hook.
* **Kesenjangan kepercayaan-kemudian-verifikasi.** Fuxi menghasilkan implementasi yang terlihat masuk akal tetapi tidak menangani kasus tepi.
> **Perbaikan**: Selalu berikan verifikasi (tes, skrip, tangkapan layar). Jika Anda tidak dapat memverifikasinya, jangan kirimkan.
* **Eksplorasi tak terbatas.** Anda meminta Fuxi untuk "menyelidiki" sesuatu tanpa membatasinya. Fuxi membaca ratusan file, mengisi konteks.
> **Perbaikan**: Batasi investigasi secara sempit atau gunakan subagents sehingga eksplorasi tidak mengonsumsi konteks utama Anda.
***
Kembangkan intuisi Anda
Pola dalam panduan ini bukan batu loncatan. Mereka adalah titik awal yang bekerja dengan baik secara umum, tetapi mungkin tidak optimal untuk setiap situasi.
Kadang-kadang Anda *harus* membiarkan konteks terakumulasi karena Anda mendalam dalam satu masalah kompleks dan riwayat berharga. Kadang-kadang Anda harus melewati perencanaan dan membiarkan Fuxi mengetahuinya karena tugas bersifat eksplorasi. Kadang-kadang prompt yang samar adalah tepat karena Anda ingin melihat bagaimana Fuxi menafsirkan masalah sebelum membatasinya.
Perhatikan apa yang berhasil. Ketika Fuxi menghasilkan output yang hebat, perhatikan apa yang Anda lakukan: struktur prompt, konteks yang Anda berikan, mode yang Anda gunakan. Ketika Fuxi berjuang, tanyakan mengapa. Apakah konteksnya terlalu bising? Prompt terlalu samar? Tugas terlalu besar untuk satu pass?
Seiring waktu, Anda akan mengembangkan intuisi yang tidak dapat ditangkap oleh panduan apa pun. Anda akan tahu kapan harus spesifik dan kapan harus terbuka, kapan harus merencanakan dan kapan harus mengeksplorasi, kapan harus menghapus konteks dan kapan harus membiarkannya terakumulasi.
* [Cara Fuxi Code Bekerja](/id/how-fuxi-code-works): loop agentic, alat, dan manajemen konteks
* [Perluas Fuxi Code](/id/features-overview): skills, hooks, MCP, subagents, dan plugins
* [Alur kerja umum](/id/common-workflows): resep langkah demi langkah untuk debugging, pengujian, PR, dan lainnya
* [FUXI.md](/id/memory): simpan konvensi proyek dan konteks persisten