# AI memadam pangkalan data: pelan pemulihan 7 minit > Perkara yang perlu dilakukan selepas data dipadam: hentikan ejen, dokumentasikan insiden dan gunakan git reflog, PITR, syot kilat dan pemulihan fail. Contoh dan langkah perlindungan. Source: https://ailoot.ai/blog/ms/ai-deleted-database-recovery/ Canonical: https://ailoot.ai/blog/ms/ai-deleted-database-recovery/ Language: ms Publisher: Ailoot (https://ailoot.ai/) Translation: guide-032 Revision: sha256-5508fdf2af89ad2d0ae559a9ff778255518ffc3b78c3c2a3dcb23c05e19c31cf
Inti pati utama Ejen AI baru sahaja memadam pangkalan data, fail atau seluruh persekitaran pengeluaran anda. 7 minit pertama menentukan sama ada anda dapat memulihkan data atau kehilangannya selama-lamanya. Panduan ini memberikan arahan khusus bagi setiap minit. Mula-mula hentikan ejen, kemudian dokumentasikan insiden, lalu pulihkan data. Jangan panik—ikuti senarai semak.
[Maklumat praktikal tentang cara bekerja dengan Ailoot tersedia dalam dokumentasi](https://ailoot.ai/docs/). ## Perkara yang perlu dilakukan pada minit pertama: BERHENTI, jangan panik
Inti pati utama Hentikan penulis pemusnah serta-merta, termasuk proses anak yang terus berjalan selepas ejen berhenti. Jangan but semula atau tamatkan proses tidak berkaitan yang mungkin masih membuka fail dipadam. Kebolehpulihan tidak dijamin: penindihan dan discard/TRIM SSD boleh menjadikan pemulihan mustahil. Simpan bukti dan data terselamat pada peranti berasingan disahkan sebelum mengubah salinan rosak.
Apabila perkara ini berlaku kepada anda, **perkara pertama yang perlu dilakukan ialah menghentikan ejen**. Jangan cuba membatalkan tindakannya sendiri, jangan suruhnya “pulihkan semuanya”, dan jangan berikan arahan baharu. Setiap tindakan ejen yang seterusnya boleh menimpa blok cakera tempat data anda mungkin masih tersimpan. 1. ### Tutup terminal ejen Ganggu arahan berbahaya serta-merta dengan Ctrl+C; jangan tunggu pemadaman selesai. Menghentikan ejen tidak semestinya menghentikan arahan anak, tugas jauh atau pertanyaan pangkalan data. Kenal pasti penulis sebenar dan hentikan atau batalkan operasi itu; tingkatkan penamatan jika ia terus memusnahkan data. Kekalkan proses tidak berkaitan dengan fail terbuka yang mungkin boleh dipulihkan. 2. ### JANGAN but semula komputer riba Data dipadam mungkin masih boleh dipulihkan, tetapi storan, tingkah laku pangkalan data, discard/TRIM SSD dan tulisan berikutnya menentukannya. Minimumkan tulisan pada volum terjejas; jangan anggap bait masih wujud. 3. ### JANGAN tutup proses yang masih terbuka Kekalkan proses tidak berkaitan yang membuka fail dipadam kerana pemulihan mungkin boleh dilakukan melalui deskriptor failnya. Ini tidak terpakai pada penulis pemusnah: hentikannya dahulu. Jangan biarkan pemadaman berjalan hanya untuk mengekalkan pemegang terbuka. 4. ### Mula merakam skrin Rekod masa tepat, laluan terjejas dan output arahan kelihatan. Jika merakam atau menyalin log, simpan pada peranti berasingan disahkan, bukan volum rosak. Simpan fail dijejaki, tidak dijejaki, diabaikan serta metadata Git di situ sebelum mencuba pemulihan. Seterusnya, 6 minit untuk pemulihan. Mari kita mulakan. ## Minit 2–3: dokumentasikan perkara yang berlaku dengan tepat
Inti pati utama Buat diagnosis sebelum pemulihan. Tanpa pemahaman tepat tentang “apa yang dipadam, oleh siapa, bila dan dengan arahan apa”, anda akan memulihkan secara membuta tuli dan mungkin memusnahkan data yang masih utuh. Buka tetingkap terminal baharu (bukan tetingkap yang menjalankan ejen), kemudian jalankan `git status`, `git log --since` dan `ps aux | grep claude`. Salin folder `~/.claude/projects/` dengan segera—folder itu mengandungi log sesi ejen yang lengkap dan mungkin membantu pemulihan.
Buka tetingkap terminal baharu. Bukan tetingkap yang menjalankan ejen—tetingkap yang lain. Jalankan tiga arahan ini mengikut turutan. **1. Catat dengan tepat perubahan dalam repositori git:** ```bash git status git log --since="30 minutes ago" --all --oneline ``` Fail dijejaki yang dipadam mungkin masih wujud dalam indeks atau commit. Simpan pepohon kerja semasa, termasuk fail tidak dijejaki dan diabaikan, sebelum sebarang pemulihan; memulihkan pada tempat asal boleh menindih suntingan terselamat. Periksa dan pulihkan dalam salinan berasingan. **2. Semak proses ejen yang sedang berjalan:** ```bash ps aux | grep -i claude ps aux | grep -i cursor ``` Kenal pasti proses yang masih melakukan tulisan berbahaya; padanan nama sahaja tidak mencukupi. Hentikan penulis itu dan sahkan ia berhenti. Kekalkan proses tidak berkaitan dengan fail terbuka berguna; jika penamatan biasa gagal dan pemusnahan berterusan, penamatan paksa mungkin diperlukan. **3. Simpan log sesi ejen:** Claude Code menyimpan sesi JSONL dalam `~/.claude/projects/`. Cursor menyimpannya dalam `~/.cursor/`. Buat salinan **sekarang juga**: ```bash cp -r ~/.claude/projects /external/incident-evidence/claude-projects ``` Gantikan `/external/incident-evidence/` dengan direktori bukti sedia ada pada peranti berasingan yang disahkan dipasang. Jangan tulis sandaran pada volum terjejas atau tindih bukti sedia ada. Folder ini mengandungi perbualan verbatim dengan ejen—arahan yang dijalankannya, jawapannya dan urutan tindakannya. Inilah sumber utama anda untuk menyiasat insiden dan mungkin memulihkan fail yang dipadam daripada konteks yang dilihat ejen (lihat langkah 4). ## Minit 4: git reflog—peluang terbaik anda
Inti pati utama Reflog boleh mencari commit yang hilang daripada sejarah cabang, tetapi tidak menyimpan fail pepohon kerja belum dikomit. Selepas menyimpan data terselamat dan metadata Git pada peranti berasingan, periksa repositori disalin serta pulihkan commit disahkan ke worktree berasingan. Jangan mulakan dengan reset pepohon kerja rosak.
`git reflog` merekod pergerakan rujukan setempat selagi entri disimpan. Tempoh luput dan pemangkasan berbeza, serta objek tidak boleh dicapai boleh dibuang; ia bukan arkib dijamin setiap commit lalu. Jalankan langkah pemulihan di bawah daripada salinan repositori disimpan pada peranti berasingan. **Langkah 1. Lihat log:** ```bash git reflog --all ``` Anda akan mendapat senarai seperti ini: ``` 1a2b3c4 HEAD@{0}: reset: moving to HEAD~3 9z8y7x6 HEAD@{1}: commit: working version of the dashboard 5w4v3u2 HEAD@{2}: commit: added admin panel ``` Cari titik **sebelum** ejen menyebabkan kerosakan. Setiap entri ialah “syot kilat” keadaan repositori pada waktu itu. **Langkah 2. Pulihkan ke pepohon kerja berasingan:** Selepas menyalin repositori dan semua kerja terselamat ke peranti berasingan, jalankan ini daripada salinan repositori disimpan. Gantikan nilai dengan SHA commit tepat yang diperiksa dalam reflog, dan pilih cabang serta destinasi belum digunakan: ```bash RECOVERY_COMMIT='replace-with-verified-commit-sha' git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT" ``` Periksa fail dipulihkan dalam `../recovery-check` dan bandingkan dengan fail belum dikomit yang disimpan sebelum menyalin kembali apa-apa. Arahan checkout commit dipilih secara berasingan; ia tidak mereset pepohon kerja rosak. Worktree berpaut berkongsi stor objek Git repositori disalin, jadi ini ruang kerja pemulihan, bukan sandaran bebas. Lihat [dokumentasi git-worktree rasmi](https://git-scm.com/docs/git-worktree). **Jika reflog juga sudah dibersihkan (ejen sempat menjalankan `git gc`):** ```bash git fsck --lost-found ``` Arahan ini mencari commit dan blob (objek fail) “hilang” yang tidak lagi dikaitkan dengan mana-mana cabang. Objek tersebut akan muncul dalam `.git/lost-found/commit/` dan `.git/lost-found/other/`. Untuk memulihkan fail daripadanya: ```bash git cat-file -p > recovered-file.ext ``` **Keadaan apabila git reflog TIDAK membantu:** - Fail itu hanya berada dalam pepohon kerja, tanpa commit atau stash → reflog tidak dapat mengesannya - Lebih 90 hari telah berlalu (nilai `gc.reflogExpire` standard) dan `git gc` telah dijalankan - Seluruh repositori telah dipadam (`rm -rf .git`)—dalam keadaan itu, anda perlukan Time Machine atau syot kilat ## Minit 5: pulihkan pangkalan data daripada sandaran
Inti pati utama Pemulihan Titik Masa (PITR) PostgreSQL memulihkan pangkalan data ke mana-mana saat dalam tempoh 7–35 hari. Ia berfungsi dengan Yandex Cloud Managed Postgres, AWS RDS, Supabase Pro dan melalui tugas cron `pg_dump` tempatan dalam Coolify. Syarat utamanya ialah PITR mesti telah diaktifkan **sebelum** insiden; anda tidak boleh mengaktifkannya secara retrospektif. Sentiasa pulihkan ke tika baharu, jangan sekali-kali menindih pangkalan data yang sedang digunakan, supaya undur semula itu tidak memusnahkan lebih banyak data. Jika PITR tidak diaktifkan, gunakan syot kilat terkini.
Pangkalan data dipadam menggunakan `DROP DATABASE`, `DROP TABLE` atau `DELETE FROM ... WHERE ...` (tanpa klausa WHERE). Apakah yang patut anda lakukan? **Langkah 1. Ketahui sama ada penyedia anda menawarkan PITR:** | Penyedia | Tempoh PITR | Arahan pemulihan | |----|----|----| | AWS RDS | 1–35 hari (boleh dikonfigurasi) | `aws rds restore-db-instance-to-point-in-time --restore-time 2026-05-28T14:30:00Z` | | Yandex Cloud Managed Postgres | 7 hari (secara lalai) | Pulihkan daripada sandaran dalam konsol + nyatakan masa | | Supabase Pro | 7 hari (Pro+ sahaja) | UI: Database → Backups → Restore | | Coolify + pg_dump tempatan | Mengikut jadual cron | `pg_restore -d new_db backup.dump` | **Langkah 2. Pulihkan ke tika baharu, bukan tika lama:** Jangan sekali-kali memulihkan dengan menindih pangkalan data yang sedang digunakan. Cipta tika baharu daripada sandaran, kemudian tukar aplikasi untuk menggunakannya. Jika berlaku masalah, anda boleh menukar DNS kembali. **Langkah 3. Jika PITR tidak diaktifkan, gunakan syot kilat terkini:** ```bash # AWS RDS, senaraikan syot kilat: aws rds describe-db-snapshots --db-instance-identifier my-db # Pulihkan daripada syot kilat: aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier my-db-restored \ --db-snapshot-identifier rds:my-db-2026-05-28-12-00 ``` **Perhatian tentang Supabase**, yang mengejutkan ramai orang pada 2026: apabila PITR diaktifkan, sandaran harian **berhenti dicipta**. Tingkah laku yang berlawanan dengan jangkaan ini boleh menyebabkan anda langsung tiada sandaran. Semak Dashboard → Database → Backups untuk memastikan PITR aktif DAN anda mempunyai syot kilat untuk dipulihkan. ## Minit 6: Time Machine, lsof dan syot kilat cakera
Inti pati utama Jika fail dipadam daripada cakera—bukan daripada git atau pangkalan data—terdapat tiga kaedah pemulihan yang praktikal. Pada macOS, gunakan Time Machine dengan syot kilat setiap jam (jika komputer riba disambungkan kepada Time Capsule atau pemacu luaran). Pada Linux, jalankan `sudo lsof | grep deleted`—arahan ini boleh mendapatkan fail yang masih dibuka oleh sesuatu proses (peluang 95%); salinnya melalui `/proc/PID/fd/N`. Untuk kes kritikal, cipta syot kilat seluruh sekatan menggunakan `dd`, kemudian pulihkan dengan `extundelete` atau `photorec`.
**macOS—Time Machine:** ```bash # Senaraikan syot kilat: tmutil listbackups # Pulihkan fail daripada sandaran terkini: tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx ``` Time Machine membuat syot kilat setiap jam, menyimpan syot kilat setiap jam selama sehari, syot kilat harian selama seminggu dan syot kilat mingguan selama-lamanya. Jika komputer riba anda disambungkan kepada Time Capsule atau pemacu luaran, projek anda tersedia di situ dengan butiran setiap jam. **Linux—fail telah dipadam, tetapi proses masih membukanya:** ```bash # Cari semua fail “dipadam” yang masih dibuka oleh proses: sudo lsof | grep deleted # Anda akan mendapat baris seperti ini: # node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted) # Salin fail terus daripada /proc/PID/fd/N: sudo cp /proc/12345/fd/24 ~/recovered-file.txt ``` Peluang berjaya ialah ~95% jika proses itu belum ditutup. Berfungsi pada ext4, xfs dan btrfs. **macOS—cara yang setara menggunakan `lsof`:** ```bash lsof | grep deleted ``` Menyalin fail lebih sukar (tiada `/proc/`), tetapi anda boleh melakukannya dengan `lldb`: ```bash lldb -p 12345 (lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE ``` **Syot kilat seluruh cakera (Linux, pilihan terakhir):** ```bash sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress ``` Arahan ini menyimpan seluruh sekatan sebagai imej. Kemudian pulihkan dengan `extundelete` atau `photorec`. Peluang pemulihan bergantung pada jumlah data yang telah ditulis ke cakera sejak pemadaman. Jika tiada apa-apa ditulis, peluangnya 80–90%. Jika sistem sudah berjalan selama sejam, peluangnya 20–30%. ## Minit 7: bagaimana jika tiada sandaran
Inti pati utama Tiada sandaran, reflog kosong dan cakera sudah ditindih dengan data baharu. Dua pilihan terakhir masih ada: hubungi sokongan penyedia anda (AWS, Yandex Cloud dan Google Cloud memulihkan data daripada storan dalaman mereka secara berkala) atau pulihkan melalui pemversian S3 (jika diaktifkan, semua versi masih wujud secara fizikal).
**Pilihan 1—sokongan penyedia:** AWS, Yandex Cloud, Google Cloud dan DigitalOcean memulihkan data daripada storan dalaman mereka secara berkala, walaupun selepas bencana yang menimpa pelanggan, khususnya pada pelan berbayar. Buka tiket sokongan, berikan masa tepat insiden dan sertakan tangkapan skrin keadaan tersebut. Kaedah ini paling kerap berjaya dengan penyedia utama yang menyimpan sandaran automatik di pihak mereka. Peluangnya 40–60%; tempoh respons ialah 24–72 jam. **Pilihan 2—pemversian S3:** Jika fail berada dalam S3 (atau Yandex Object Storage) dan pemversian diaktifkan, semua versi **wujud secara fizikal**; versi tersebut hanya ditandakan sebagai “dipadam”. ```bash # AWS—senaraikan versi: aws s3api list-object-versions --bucket my-bucket --prefix files/ # Pulihkan satu versi: aws s3api copy-object \ --bucket my-bucket \ --copy-source my-bucket/files/data.json?versionId=ABC123 \ --key files/data.json ``` **Perhatian penting:** Claude Code tidak menyimpan sesi selama-lamanya—fail JSONL lama dipadam secara automatik selepas beberapa minggu. Untuk memastikan anda mempunyai sejarah JSONL selama sebulan sekiranya berlaku bencana, salin `~/.claude/projects/` ke pemacu luaran sekali seminggu menggunakan tugas cron ringkas: ```bash # Dalam crontab, setiap Ahad pada 03:00: 0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/ ``` Percuma dan menyelamatkan anda apabila “semuanya sudah hilang, tiada sandaran dan reflog kosong”. ## 7 peraturan untuk mengelakkan kejadian ini berulang
Inti pati utama Tujuh peraturan yang menghalang ejen AI daripada memadam pangkalan data atau kod anda. Gunakan Plan Mode sebelum operasi yang memusnahkan data. Gunakan hook diuji untuk mengesan rentetan arahan berbahaya terpilih, bersama had kebenaran dikuatkuasakan. Berikan ejen pengguna pangkalan data baca sahaja. Buat commit secara automatik selepas setiap suntingan fail. Gunakan folder sandbox terpencil untuk eksperimen. Ambil syot kilat cakera dengan `restic` setiap jam. Arkibkan sesi JSONL ke pemacu luaran.
**1. Plan Mode sebelum sebarang operasi yang memusnahkan data.** Dalam Claude Code: ```bash claude --plan ``` Ejen membina pelan **sebelum** bertindak. Anda membacanya, melihat `DROP TABLE users` lalu membatalkannya. Tanpa Plan Mode, ejen membuat keputusan sendiri dan melaksanakannya dalam milisaat. Ketahui lebih lanjut dalam [panduan Plan Mode dalam Claude Code](https://ailoot.ai/blog/ms/claude-code-plan-mode/). **2. Hook sebagai pengesan tambahan.** Gunakan hook PreToolUse diuji yang membaca JSON peristiwa daripada stdin dan keluar 2 bagi tindakan berisiko tinggi dikesan. Contoh lengkap di bawah meliputi Bash, Write dan Edit; ia bukan sempadan keselamatan dan boleh terlepas operasi tidak langsung. Kekalkan keistimewaan pangkalan data serta sandbox terhad. **3. Pengguna DB baca sahaja untuk ejen.** Cipta pengguna berasingan untuk ejen yang **tidak mempunyai** kebenaran `DROP`, `TRUNCATE` atau `DELETE`: ```sql CREATE USER claude_readonly WITH PASSWORD 'xxx'; GRANT CONNECT ON DATABASE myapp TO claude_readonly; GRANT USAGE ON SCHEMA public TO claude_readonly; GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly; ``` Apabila ejen benar-benar perlu menulis, tukar secara manual kepada pengguna lain. Pengguna baca sahaja mencukupi untuk tugasan harian (analisis data, laporan, papan pemuka). **4. Simpan perubahan yang telah disemak dalam Git.** Hook `PostToolUse` dalam `.claude/settings.json` boleh memaparkan peringatan selepas operasi `Write` dan `Edit`: ```json { "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "printf '%s\\n' 'Semak diff dan buat commit secara manual untuk fail yang dipersetujui sahaja.' >&2" } ] } ] } } ``` Contoh ini hanya memaparkan peringatan; ia tidak menambah fail ke staging atau membuat commit. Semak diff dan buat commit secara manual untuk fail yang dipersetujui sahaja. Reflog tidak menyimpan perubahan yang belum di-commit. **5. Projek sandbox untuk eksperimen.** Jangan biarkan ejen bekerja dalam projek yang mengandungi data pelanggan sebenar. Cipta folder `~/sandbox-projects/` yang berasingan, dengan salinan projek dan data sintetik. Gunakannya untuk mencuba arahan, ejen atau pelayan MCP baharu. Jika sesuatu rosak, tiada mudarat berlaku. **6. Syot kilat cakera dengan `restic` setiap jam.** ```bash # Pasang: brew install restic # macOS sudo apt install restic # Linux # Cipta repositori: restic init --repo /external/backups # Sandarkan projek semasa: restic --repo /external/backups backup ~/projects # Jadualkan cron setiap jam: crontab -e # Tambah: 0 * * * * restic --repo /external/backups backup ~/projects ``` Tujuh hari sandaran setiap jam, empat minggu sandaran harian—dan anda sentiasa boleh kembali ke mana-mana titik pada masa lalu. Percuma dan mengambil masa 10 minit untuk disediakan. **7. Arkibkan sesi JSONL Claude Code.** Perkara ini sudah disebut di atas, tetapi diulangi sebagai peraturan berasingan: jadualkan `rsync` mingguan bagi `~/.claude/projects/` ke pemacu luaran. Percuma dan hanya memerlukan satu baris dalam crontab. ## Hooks sedia guna untuk menyekat arahan berbahaya
Inti pati utama Contoh di bawah ialah pengesan PreToolUse bagi rentetan arahan Bash terpilih dan laluan Write/Edit sensitif. Ia membaca JSON stdin dan memulangkan kod keluar 2 bagi padanan. Ia boleh terlepas tindakan tidak langsung atau dikaburkan, maka melengkapkan sandbox serta kelayakan terhad daripada menggantikannya. Gabungkan hook ke konfigurasi sedia ada dan uji tingkah lakunya sebelum digunakan.
Gabungkan entri ini ke `.claude/settings.json` tanpa menggantikan hook sedia ada: ```json { "hooks": { "PreToolUse": [ { "matcher": "Bash|Write|Edit", "hooks": [ { "type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\"" } ] } ] } } ``` Cipta `.claude/hooks/check-risk.py` dengan skrip Python 3 berikut: ```python import json import re import sys from pathlib import Path try: event = json.load(sys.stdin) tool = event["tool_name"] data = event["tool_input"] blocked = False if tool == "Bash": command = data["command"] blocked = bool(re.search( r"drop\s+(database|table)|truncate\s+table|" r"delete\s+from.*where\s+1|rm\s+-rf|" r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|" r"chmod\s+-R\s+777", command, re.IGNORECASE | re.DOTALL)) elif tool in ("Write", "Edit"): path = Path(data["file_path"]).resolve() blocked = (".git" in path.parts or path.name.startswith( (".env", "credentials", "secrets"))) except (ValueError, KeyError, TypeError, OSError): print("BLOCKED: invalid hook input", file=sys.stderr) sys.exit(2) if blocked: print("BLOCKED: high-risk command or sensitive path", file=sys.stderr) sys.exit(2) sys.exit(0) ``` Hook membaca peristiwa JSON didokumenkan daripada **stdin**, memeriksa `tool_input.command` atau `tool_input.file_path` dan keluar 2 apabila sepadan. Ia memeriksa Write dan Edit. Uji contoh tidak berbahaya dibenarkan serta contoh disekat sebelum bergantung padanya, dan sahkan Python serta skrip dikonfigurasikan benar-benar bermula. Ini pengesan leksikal: ia boleh terlepas bendera disusun semula, skrip, alias, arahan dikaburkan, alat lain dan tulisan tidak langsung; ia juga boleh menolak contoh berpetik yang tidak berbahaya. Ia tidak memberikan atau membuang kebenaran OS/pangkalan data. Simpan kelayakan produksi di luar persekitaran ejen, gunakan peranan pangkalan data baca sahaja serta sandbox dikuatkuasakan, dan lindungi konfigurasi hook daripada perubahan. Lihat [rujukan rasmi input hook dan kod keluar](https://code.claude.com/docs/en/hooks). Untuk operasi pengecualian disengajakan, semak dan jalankan di luar ejen dengan akaun terhad sesuai. Pemboleh ubah persekitaran shell bukan antara muka penyahaktifan hook didokumenkan, dan hook tidak mengawal arahan terminal biasa. ## Bila perlu memberikan kebenaran kepada AI (dan bila tidak)
Inti pati utama JANGAN sekali-kali memberikan bendera `--dangerously-skip-permissions` kepada ejen untuk projek dengan data sebenar. Dalam mod YOLO ini, semua perlindungan dimatikan, ejen menjalankan sebarang arahan Bash dan menulis fail tanpa pengesahan, manakala subejen yang dilancarkan mewarisi mod YOLO tanpa cara untuk mengatasinya. Gunakan YOLO hanya dalam folder sandbox untuk eksperimen dengan pelayan MCP atau arahan baharu menggunakan data olok-olok. Untuk perkara lain, gunakan kebenaran tepat melalui `.claude/settings.json` dengan peraturan `allow` dan `deny` yang jelas.
Anthropic mendokumenkan bendera `--dangerously-skip-permissions` (juga dikenali sebagai mod YOLO) sebagai pilihan untuk “persekitaran yang dipercayai”. Dalam realiti 2026, ini ialah **jalan terus menuju bencana**. Apabila ejen tidak perlu meminta kebenaran, ejen akan: - Menjalankan sebarang arahan Bash tanpa pengesahan - Menulis fail tanpa bertanya - Memanggil subejen yang **mewarisi** YOLO dan tiada cara untuk membatalkannya Perkara ketiga paling berbahaya. Jika anda memulakan ejen utama dengan YOLO, subejennya juga menggunakan YOLO dan anda tidak boleh mengatasinya. Satu arahan—dan rangkaian 10 ejen selari boleh melakukan apa-apa sahaja pada sistem anda. **Peraturan:** | Situasi | Adakah YOLO boleh diterima? | |--------------------------------------------------|--------------------| | Bereksperimen dengan pelayan MCP baharu dalam folder sandbox | ✅ Ya | | Menguji arahan baharu menggunakan data olok-olok | ✅ Ya | | Bekerja dengan fail projek sebenar | ❌ Tidak | | Sebarang arahan yang menyentuh pangkalan data | ❌ Jangan sekali-kali | | Melaksanakan ke persekitaran pengeluaran | ❌ Jangan sekali-kali | | Mengurus infrastruktur (AWS, Yandex Cloud) | ❌ Jangan sekali-kali | **Alternatif—kebenaran tepat.** Dalam `.claude/settings.json`: ```json { "permissions": { "allow": [ "Bash(git status:*)", "Bash(git log:*)", "Bash(npm run build:*)", "Read(*)", "Edit(src/**)" ], "deny": [ "Bash(rm:*)", "Bash(git push:*)", "Edit(.env)", "Edit(prisma/migrations/*)" ] } } ``` Ejen dapat melihat perkara yang dibenarkan dan dilarang. Anda tidak perlu mengklik “ya” atau “tidak” setiap kali—ejen bekerja dengan pantas dan anda mengawal sempadannya. ## Seterusnya: senarai semak 7 minit untuk disimpan dalam penanda buku
Inti pati utama Simpan panduan ini dalam penanda buku sekarang juga. Apabila bencana berlaku, buka halaman ini dan ikuti senarai semak 10 perkara mengikut turutan. Ia menjimatkan 30 minit kepanikan dan menghalang anda daripada menimpa data yang mungkin masih boleh dipulihkan secara tidak sengaja. Selepas pemulihan, kembali ke sini dan konfigurasikan 7 peraturan pencegahan supaya bencana tidak berlaku lagi minggu depan.
**Senarai semak: “AI memadamnya—apa yang perlu saya buat?”** 1. Hentikan penulis pemusnah sebenar serta-merta; sahkan operasi anak atau jauh berhenti 2. Jangan but semula; kekalkan proses tidak berkaitan yang membuka fail dipadam 3. Rekod masa insiden dan bukti arahan pada peranti berasingan disahkan 4. Salin fail terselamat, metadata Git dan log sesi relevan ke peranti berasingan itu 5. Dalam salinan repositori disimpan, periksa `git reflog --all` dan pulihkan commit disahkan ke worktree berasingan 6. Jika git tidak membantu—`git fsck --lost-found` 7. Pangkalan data: PITR (AWS/Yandex/Supabase) atau syot kilat terkini 8. Fail: Time Machine pada Mac, lsof pada Linux 9. Pilihan terakhir: sokongan penyedia + pemversian S3 10. Selepas pemulihan, konfigurasikan 7 peraturan pencegahan dalam panduan ini **Seterusnya—perlindungan sistematik:** - [Plan Mode dalam Claude Code](https://ailoot.ai/blog/ms/claude-code-plan-mode/)—supaya ejen menyediakan pelan **sebelum** operasi yang memusnahkan data - [Hooks dalam Claude Code](https://ailoot.ai/blog/ms/claude-code-hooks/)—templat sedia guna untuk menyekat arahan berbahaya - [Cara mengundurkan perubahan dalam Claude Code](https://ailoot.ai/blog/ms/claude-code-undo-changes/)—panduan terperinci tentang `/rewind`, git dan 5 kaedah undur semula standard - [Semakan keselamatan dalam Claude Code](https://ailoot.ai/blog/ms/claude-code-security-review/)—semakan keselamatan kod secara berkala
### Sumber - [Dokumentasi Hooks Claude Code Anthropic](https://code.claude.com/docs/en/hooks-guide) - [Dokumentasi Plan Mode Claude Code Anthropic](https://code.claude.com/docs/en/common-workflows) - [Dokumentasi PostgreSQL Point-In-Time Recovery (PITR)](https://www.postgresql.org/docs/current/continuous-archiving.html) - [AWS RDS—Pulihkan tika DB ke titik masa tertentu](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) - [Yandex Cloud Managed PostgreSQL—Sandaran dan pemulihan](https://yandex.cloud/ru/docs/managed-postgresql/concepts/backup) - [Dokumentasi Git reflog](https://git-scm.com/docs/git-reflog) - [Git fsck—mod `--lost-found`](https://git-scm.com/docs/git-fsck)
[Buka Ailoot](https://ailoot.ai/). ## Soalan lazim: AI memadam pangkalan data: pelan pemulihan 7 minit ### Patutkah saya menunggu arahan semasa ejen selesai? Tidak. Hentikan penulis pemusnah serta-merta dan sahkan operasi anak, jauh atau pangkalan datanya berhenti. Kekalkan proses tidak berkaitan yang mungkin memegang fail dipadam boleh dipulihkan; menghentikan ejen sahaja mungkin meninggalkan penulis lain berjalan. ### Bolehkah saya memulakan pemulihan dengan git reset --hard? Simpan dahulu fail dijejaki, tidak dijejaki dan diabaikan yang masih ada serta metadata Git pada peranti berasingan. Periksa repositori disalin dan pulihkan commit disahkan ke worktree berasingan; hard reset pada tempat asal boleh memusnahkan suntingan belum dikomit yang terselamat. ## Ailoot · Syarikat dan portfolio projeknya Ailoot berteraskan pengalaman operasi yang mantap, pangkalan pelanggan yang besar, perkhidmatan yang stabil dan pemantauan KPI berterusan. Syarikat dan portfolio projeknya: jutaan pelanggan; jualan bernilai berbilion setiap bulan. Ailoot menggunakan pengalaman operasi ini untuk akses API kepada ciri AI dalam produk pelanggan, ejen, aplikasi dan automasi.