Claude Sering Salah Tulis Kode? 12 Aturan Ini Turunkan Error Rate ke 3%

marsbitDipublikasikan tanggal 2026-05-14Terakhir diperbarui pada 2026-05-14

Abstrak

Klode sering membuat kesalahan saat menulis kode? Templat CLAUDE.md asli dari Andrej Karpathy (diadaptasi oleh Forrest Chang) dengan 4 aturan berhasil menurunkan tingkat kesalahan dari ~40% menjadi di bawah 3% untuk tugas tertentu. Namun, seiring evolusi pemrograman AI menuju alur kerja multi-langkah dan kolaborasi agen, pola kegagalan baru muncul. Artikel ini menambahkan 8 aturan baru ke dalam CLAUDE.md, menghasilkan total 12 aturan untuk mengatasi masalah kontemporer. Aturan baru mencakup: mencegah model mengambil keputusan non-bahasa (seperti logika bisnis), menetapkan anggaran token yang ketat, mengekspos konflik alih-alih menengahi, memahami kode sebelum menulis, memastikan kualitas pengujian yang bermakna, menggunakan checkpoint untuk tugas panjang, mengutamakan konvensi kode yang ada, dan memastikan kegagalan dilaporkan secara eksplisit. Pengujian selama 6 minggu di 30 basis kode menunjukkan aturan 12 ini mengurangi tingkat kesalahan menjadi 3% tanpa membebani tingkat kepatuhan. Kuncinya adalah menjaga CLAUDE.md tetap ringkas (di bawah 200 baris) dan berfokus pada aturan yang secara langsung menjawab pola kegagalan spesifik yang dialami dalam proyek.

Catatan Editor: Januari 2026, kritikan Andrej Karpathy terhadap cara Claude menulis kode, memunculkan satu file yang tampaknya kecil, namun sangat krusial dalam alur kerja pemrograman AI: CLAUDE.md. Forrest Chang kemudian merangkum masalah-masalah tersebut menjadi 4 aturan perilaku, mencoba membatasi kesalahan umum Claude saat mengoding: asumsi diam-diam, over-engineering, mengganggu kode yang tidak relevan, dan kurangnya standar kesuksesan yang jelas.

Tapi beberapa bulan kemudian, skenario penggunaan Claude Code sudah tidak lagi sekadar "membuat model menulis sepotong kode". Seiring dengan normalnya penggunaan multi-step Agent, trigger berantai hook, konflik loading skill, dan kolaborasi multi-repositori, mode kegagalan baru juga mulai muncul: model kehilangan kendali dalam tugas panjang, tes lolos tanpa memvalidasi logika sebenarnya, migrasi selesai tapi diam-diam melewati error, pencampuran gaya kode yang salah.

Penulis artikel ini menguji 30 repositori kode dalam 6 minggu, dan menambahkan 8 aturan baru di atas 4 aturan asli Karpathy, mencoba menjangkau masalah baru dalam pemrograman AI yang bergerak dari penyelesaian sekali jadi menuju kolaborasi yang ter-Agent-kan.

Berikut teks aslinya:

Pertengahan Januari 2026, Andrej Karpathy membagikan untaian tweet, mengeluhkan cara Claude menulis kode. Dia menyoroti tiga masalah tipikal: membuat asumsi salah tanpa penjelasan, terlalu kompleks, dan menyebabkan kerusakan yang tidak relevan pada kode yang seharusnya tidak disentuh.

Forrest Chang melihat untaian tweet itu, merangkum keluhannya menjadi 4 aturan perilaku, menuliskannya ke dalam file terpisah CLAUDE.md, dan merilisnya ke GitHub. Proyek ini mendapat 5,828 Star di hari pertama, disimpan 60,000 kali dalam dua minggu, dan sekarang telah mencapai 120,000 Star, menjadi repositori kode file tunggal dengan pertumbuhan tercepat di tahun 2026.

Setelahnya, saya mengujinya selama 6 minggu dengan 30 repositori kode.

Keempat aturan ini memang efektif. Kesalahan yang sebelumnya muncul dengan probabilitas sekitar 40%, pada tugas-tugas yang cocok untuk aturan ini, turun menjadi di bawah 3%. Namun masalahnya, template ini awalnya dibuat untuk mengatasi kesalahan Claude menulis kode di bulan Januari.

Menjelang Mei 2026, masalah yang dihadapi ekosistem Claude Code sudah berbeda: konflik antar Agent, trigger berantai hook, konflik loading skill, dan interupsi alur kerja multi-step antar sesi.

Jadi, saya menambahkan 8 aturan lagi. Berikut adalah versi lengkap CLAUDE.md dengan 12 aturan: alasan masing-masing aturan layak ditambahkan, dan 4 poin di mana template asli Karpathy akan gagal diam-diam.

Jika ingin melewatkan penjelasan dan langsung menyalinnya, file lengkapnya ada di akhir artikel.

Mengapa Ini Penting

CLAUDE.md Claude Code, adalah file paling diremehkan di seluruh teknologi stack pemrograman AI. Kebanyakan pengembang biasanya melakukan tiga kesalahan:

Pertama, menganggapnya sebagai tempat sampah preferensi, memasukkan semua kebiasaan mereka sendiri, akhirnya membengkak hingga lebih dari 4000 token, dengan tingkat kepatuhan aturan jatuh ke 30%.

Kedua, tidak menggunakannya sama sekali, selalu memulai prompt dari awal. Ini menyebabkan pemborosan token 5 kali lipat, dan kurangnya konsistensi antar sesi.

Ketiga, menyalin sebuah template dan tidak pernah memperbaruinya lagi. Mungkin efektif selama dua minggu, tetapi seiring perubahan repositori kode, ia akan gagal tanpa Anda sadari.

Dokumentasi resmi Anthropic menjelaskan dengan jelas: pada dasarnya, CLAUDE.md hanya bersifat saran. Claude akan mengikutinya sekitar 80% dari waktu. Begitu melebihi 200 baris, tingkat kepatuhan akan turun nyata, karena aturan penting akan tenggelam dalam kebisingan.

Template Karpathy menyelesaikan masalah ini: satu file, 65 baris, 4 aturan. Ini adalah baseline minimum.

Tapi batas atasnya bisa lebih tinggi. Dengan menambahkan 8 aturan di bawah ini, cakupannya bukan hanya masalah penulisan kode yang dikeluhkan Karpathy di Januari 2026, tetapi juga masalah pengaturan Agent yang baru muncul di Mei 2026 — masalah yang belum ada saat template asli ditulis.

4 Aturan Asli

Jika Anda belum melihat repositori Forrest Chang, lihat dulu versi dasarnya:

Aturan 1: Berpikir sebelum mengkode.

Jangan membuat asumsi diam-diam. Jelaskan asumsimu, ekspos titik-titik trade-off. Tanyakan dulu sebelum menebak. Ketika ada solusi yang lebih sederhana, aktifkan untuk mengajukan keberatan.

Aturan 2: Sederhana itu prioritas.
Gunakan kode paling sedikit yang bisa menyelesaikan masalah. Jangan tambahkan fungsi yang dibayangkan. Jangan rancang lapisan abstraksi untuk kode sekali pakai. Jika seorang insinyur senior akan menganggapnya terlalu rumit, itu harus disederhanakan.

Aturan 3: Modifikasi ala bedah.
Hanya ubah bagian yang harus diubah. Jangan "mengoptimalkan" kode, komentar, atau format yang berdekatan secara sembarangan. Jangan refaktor sesuatu yang tidak rusak. Pertahankan konsistensi dengan gaya yang ada.

Aturan 4: Eksekusi berorientasi tujuan.
Definisikan standar kesuksesan dulu, lalu lakukan iterasi secara siklus hingga verifikasi selesai. Jangan beri tahu Claude langkah demi langkah apa yang harus dilakukan, tapi beri tahu seperti apa seharusnya hasil yang sukses, biarkan dia sendiri yang mengulang.

Keempat aturan ini bisa menyelesaikan sekitar 40% mode kegagalan yang saya lihat dalam sesi Claude Code tanpa pengawasan. Sekitar 60% masalah lainnya, tersembunyi di area kosong di bawah ini.

8 Aturan Baru Saya, dan Alasannya

Setiap aturan, berasal dari momen nyata: 4 aturan asli Karpathy sudah tidak cukup. Di bawah ini saya akan ceritakan dulu skenarionya, baru berikan aturan yang sesuai.

Aturan 5: Jangan biarkan model mengerjakan tugas non-bahasa

Aturan Karpathy tidak mencakup ini. Akibatnya model mulai memutuskan hal-hal yang seharusnya ditangani oleh kode deterministik: apakah harus mencoba ulang panggilan API, bagaimana merutekan pesan, kapan harus mengeskalasi penanganan. Hasilnya, keputusan setiap minggu berbeda-beda. Yang Anda dapatkan adalah if-else yang tidak stabil, dibayar per token $0.003.

Momen itu seperti ini: ada sepotong kode yang memanggil Claude untuk "menentukan apakah harus mencoba ulang saat mendapatkan 503". Awalnya berjalan baik, bertahan dua minggu, lalu tiba-tiba menjadi tidak stabil, karena model mulai menganggap body request sebagai konteks penilaian. Strategi percobaan ulang menjadi acak, karena prompt itu sendiri memang acak.

Aturan 6: Tetapkan anggaran token yang ketat, tanpa pengecualian

CLAUDE.md tanpa batasan anggaran, sama dengan cek kosong. Setiap loop bisa lepas kendali, berubah menjadi pembuangan konteks 50,000 token. Model tidak akan berhenti sendiri.

Momen itu seperti ini: satu sesi debugging berlangsung selama 90 menit. Model terus mengulang-ulang iterasi di sekitar pesan error 8KB yang sama, dan perlahan lupa solusi apa yang sudah dicoba. Pada akhirnya, dia mulai mengusulkan solusi yang sudah saya tolak 40 pesan sebelumnya. Jika ada anggaran token, proses ini seharusnya dihentikan di menit ke-12.

Aturan 7: Ekspos konflik, jangan berkompromi rata-rata

Ketika dua bagian di repositori kode saling bertentangan, Claude akan mencoba memuaskan kedua belah pihak, menghasilkan kode yang tidak koheren.

Momen itu seperti ini: satu repositori kode memiliki dua pola penanganan error, satu async/await dengan try/catch eksplisit, yang lain adalah global error boundary. Kode baru yang ditulis Claude menggunakan kedua pola tersebut. Akibatnya penanganan error dilakukan dua kali. Saya butuh 30 menit untuk memahami, mengapa error ditelan dua kali.

Aturan 8: Baca dulu, baru tulis

"Modifikasi ala bedah" Karpathy memberi tahu Claude untuk tidak mengubah kode yang berdekatan. Tapi dia tidak memberi tahu Claude: pahami dulu kode yang berdekatan itu. Tanpa ini, Claude akan menulis kode baru yang bertentangan dengan kode yang sudah ada 30 baris sebelumnya.

Momen itu seperti ini: Claude menambahkan fungsi baru di sebelah fungsi yang sudah ada dengan fungsi yang persis sama, karena dia tidak membaca fungsi aslinya terlebih dahulu. Kedua fungsi melakukan hal yang sama. Tapi karena urutan import, fungsi baru menimpa fungsi lama, padahal fungsi lama sudah menjadi standar de facto selama 6 bulan.

Aturan 9: Tes bukan opsi, tetapi tes itu sendiri bukan tujuan

"Eksekusi berorientasi tujuan" Karpathy mengisyaratkan tes bisa menjadi standar kesuksesan. Tapi dalam praktik, Claude akan menganggap "tes lolos" sebagai satu-satunya tujuan, sehingga menulis kode yang lolos tes dangkal, tapi merusak hal lain.

Momen itu seperti ini: Claude menulis 12 tes untuk sebuah fungsi autentikasi, semuanya lolos. Tapi logika autentikasi di lingkungan produksi rusak. Tes-tes itu hanya memverifikasi fungsi "mengembalikan sesuatu", bukan memverifikasi apakah itu mengembalikan hal yang benar. Fungsi bisa lolos tes karena mengembalikan sebuah konstanta.

Aturan 10: Operasi berjalan lama perlu checkpoint

Template Karpathy mengasumsikan interaksi itu sekali jadi. Tapi pekerjaan Claude Code yang sebenarnya seringkali multi-step: refaktor di 20 file, membangun fitur dalam satu sesi, debugging di banyak commit. Tanpa checkpoint, satu langkah salah, semua kemajuan sebelumnya bisa hilang.

Momen itu seperti ini: tugas refaktor 6 langkah error di langkah ke-4. Saat saya sadar, Claude sudah melanjutkan dan menyelesaikan langkah 5 dan 6 di atas status yang salah. Waktu untuk membongkar dan memperbaikinya, lebih lama daripada mengulangi seluruh tugas. Jika ada checkpoint, masalah akan terdeteksi di langkah ke-4.

Aturan 11: Konvensi lebih diutamakan daripada kebaruan

Di repositori kode yang sudah memiliki pola matang, Claude suka memperkenalkan gaya tulisannya sendiri. Meskipun gaya tulisannya "lebih baik", memperkenalkan pola kedua itu sendiri, lebih buruk daripada pola tunggal mana pun.

Momen itu seperti ini: Claude memperkenalkan hooks di repositori React yang berbasis class component. Memang bisa berjalan. Tapi sekaligus merusak pola tes asli repositori, karena tes-tes itu bergantung pada componentDidMount. Akhirnya butuh setengah hari untuk menghapusnya dan menulis ulang.

Aturan 12: Gagal secara eksplisit, jangan gagal diam-diam

Kegagalan Claude yang paling mahal, seringkali adalah yang terlihat seperti kesuksesan. Sebuah fungsi "bisa jalan", tapi mengembalikan data yang salah; sebuah migrasi "selesai", tapi melewatkan 30 catatan; sebuah tes "lolos", tapi hanya karena assertion-nya sendiri yang salah.

Momen itu seperti ini: Claude mengatakan migrasi database "berhasil selesai". Tapi sebenarnya, dia diam-diam melewatkan 14% catatan yang memicu konflik constraint. Perilaku melewatkan itu masuk ke log, tapi tidak diekspos secara jelas. 11 hari kemudian, saat data laporan mulai tidak normal, barulah kita menemukan masalah.

Hasil Data

Saya melacak 50 tugas perwakilan yang sama selama 6 minggu, mencakup 30 repositori kode, menguji tiga konfigurasi.

Tingkat error mengacu pada: tugas perlu dikoreksi atau ditulis ulang agar sesuai dengan niat aslinya. Error yang dihitung termasuk: asumsi salah diam-diam, over-engineering, kerusakan tidak relevan, kegagalan diam-diam, pelanggaran konvensi, kompromi konflik, melewatkan checkpoint.

Tingkat kepatuhan mengacu pada: ketika suatu aturan berlaku, seberapa besar kemungkinan Claude akan menerapkan aturan itu secara eksplisit.

Hasil yang benar-benar menarik, bukan hanya tingkat error turun dari 41% ke 3%. Lebih penting lagi, memperluas dari 4 aturan menjadi 12 aturan, hampir tidak menambah beban kepatuhan, tingkat kepatuhan hanya turun dari 78% menjadi 76%, tetapi tingkat error turun lagi 8 poin persentase. Aturan baru menangani mode kegagalan yang tidak ditangani oleh 4 aturan asli, mereka tidak memperebutkan anggaran perhatian yang sama.

Di Mana Template Karpathy Akan Gagal Diam-diam

Bahkan tanpa menambahkan aturan baru, template 4 aturan asli setidaknya tidak memadai di 4 tempat ini.

Pertama, tugas Agent yang berjalan lama.
Aturan Karpathy terutama ditujukan untuk saat Claude sedang menulis kode. Tapi apa yang terjadi ketika Claude menjalankan pipeline multi-step? Template asli tidak memiliki aturan anggaran, aturan checkpoint, atau aturan "gagal dengan keras". Akibatnya pipeline akan perlahan bergeser.

Kedua, konsistensi multi-repositori.
"Sesuaikan gaya yang ada" secara default hanya mengasumsikan satu gaya. Tapi dalam monorepo yang memiliki 12 layanan, Claude harus memilih gaya mana yang akan disesuaikan. Aturan asli tidak memberi tahu cara memilih. Akibatnya dia memilih secara acak, atau mencampur rata beberapa gaya.

Ketiga, kualitas tes.
"Eksekusi berorientasi tujuan" akan menganggap "tes lolos" sebagai kesuksesan, tapi tidak menjelaskan bahwa tes itu sendiri harus bermakna. Hasilnya, Claude menulis tes yang hampir tidak memverifikasi apa pun, tapi tes ini membuatnya merasa yakin.

Keempat, perbedaan lingkungan produksi dan tahap prototipe.
Keempat aturan yang sama, bisa mencegah kode produksi dari over-engineering, tapi juga bisa memperlambat pengembangan prototipe. Karena tahap prototipe kadang memang membutuhkan 100 baris scaffolding eksplorasi, untuk menemukan arah dulu. "Sederhana itu prioritas" Karpathy mudah terpicu berlebihan pada kode tahap awal.

Kedelapan aturan baru ini bukan untuk menggantikan 4 aturan asli Karpathy, melainkan memperbaiki kekosongannya: template asli sesuai dengan skenario penulisan kode yang cenderung otomatis-lengkap di Januari 2026; sedangkan di Mei 2026, Claude Code sudah memasuki lingkungan kolaborasi multi-step, multi-repositori yang digerakkan oleh Agent, masalah yang dihadapi keduanya berbeda.

Metode Apa yang Tidak Berhasil

Sebelum menetapkan 12 aturan ini, saya juga mencoba beberapa skema lain.

Menambahkan aturan yang saya lihat di Reddit / X.
Kebanyakan dari mereka, hanya mengulangi 4 aturan asli Karpathy dengan kata-kata berbeda, atau aturan spesifik domain yang tidak bisa digeneralisasi, seperti "selalu gunakan class Tailwind". Semua akhirnya dihapus.

Lebih dari 12 aturan.
Saya menguji sampai 18 aturan. Setelah melebihi 14 aturan, tingkat kepatuhan turun dari 76% menjadi 52%. Batas 200 baris itu nyata. Setelah melebihi panjang ini, Claude akan mulai mem-pattern match menjadi "ada aturan di sini", daripada benar-benar membaca aturan satu per satu.

Aturan yang bergantung pada keberadaan alat tertentu.
Misal "selalu gunakan eslint", begitu proyek tidak menginstal eslint, aturan ini akan gagal, dan gagal diam-diam. Akhirnya saya mengubahnya menjadi ekspresi yang tidak bergantung pada alat tertentu, seperti mengubah "gunakan eslint" menjadi "ikuti gaya yang sudah diberlakukan di repositori kode".

Meletakkan contoh di CLAUDE.md, bukan aturan.
Contoh mengambil lebih banyak konteks daripada aturan. Tiga contoh mengonsumsi konteks yang hampir sama dengan 10 aturan, dan Claude mudah overfitting pada contoh. Aturan itu abstrak, contoh itu spesifik. Jadi, gunakan aturan.

"Hati-hati", "berpikir matang", "fokus".
Ini semua adalah noise. Tingkat kepatuhan instruksi seperti ini turun menjadi sekitar 30%, karena tidak bisa diperiksa. Akhirnya saya menggantinya dengan aturan perintah yang lebih spesifik, seperti "jelaskan asumsi secara eksplisit".

Menyuruh Claude agar seperti "insinyur senior".
Ini tidak berguna. Claude memang sudah merasa seperti insinyur senior. Masalah sebenarnya bukan pada apakah dia berpikir begitu, tapi apakah dia melaksanakannya. Aturan perintah dapat memperkecil kesenjangan ini, petunjuk identitas tidak bisa.

CLAUDE.md Versi 12 Aturan Lengkap

Berikut adalah versi lengkap yang bisa langsung disalin dan ditempel.

Konten ini untuk sementara tidak dapat ditampilkan di luar Dokumen Feishu

Simpan sebagai CLAUDE.md di direktori root repositori. Di bawah 12 aturan ini, tambahkan aturan khusus proyek, seperti tech stack, perintah tes, mode error, dll. Total jangan melebihi 200 baris, setelah itu tingkat kepatuhan aturan akan turun nyata.

Cara Instalasi

Dua langkah saja:

1. Tambahkan 4 aturan dasar Karpathy ke CLAUDE.md Anda
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md


2. Tempelkan aturan 5–12 dari artikel ini di bawahnya

Simpan file di direktori root repositori. >> di sini penting, fungsinya untuk menambahkan ke CLAUDE.md yang sudah ada, bukan menimpa aturan khusus proyek yang sudah Anda tulis.

Model Mental

CLAUDE.md bukan daftar keinginan, melainkan kontrak perilaku, untuk memblokir mode kegagalan spesifik yang sudah Anda amati.

Setiap aturan harus menjawab pertanyaan: kesalahan apa yang dicegahnya?

4 aturan Karpathy, mencegah mode kegagalan yang dilihatnya di Januari 2026: asumsi diam-diam, over-engineering, kerusakan tidak relevan, standar kesuksesan yang lemah. Itu adalah dasar, jangan dilewatkan.

8 aturan tambahan saya, mencegah mode kegagalan baru yang muncul setelah Mei 2026: loop Agent tanpa batasan anggaran, tugas multi-step tanpa checkpoint, tes yang sepertinya menguji tapi sebenarnya tidak menyentuh logika kunci, dan masalah yang mengemas kegagalan diam-diam sebagai kesuksesan diam-diam. Ini adalah patch tambahan.

Tentu saja, efek spesifiknya bervariasi per orang. Jika Anda tidak menjalankan pipeline multi-step, Aturan 10 tidak terlalu penting bagi Anda. Jika repositori kode Anda hanya memiliki satu gaya seragam, dan sudah diberlakukan oleh lint, Aturan 11 adalah redundan. Setelah membaca 12 aturan ini, pertahankan aturan yang benar-benar sesuai dengan kesalahan yang pernah Anda buat, hapus sisanya.

Versi CLAUDE.md dengan 6 aturan yang disesuaikan dengan mode kegagalan nyata, lebih baik daripada versi dengan 12 aturan, di mana 6 aturan tidak pernah Anda gunakan.

Penutup

Tweet Karpathy di Januari 2026, pada dasarnya adalah keluhan. Forrest Chang mengubahnya menjadi 4 aturan. Akhirnya, 120 ribu pengembang memberikan Star pada hasil ini. Dan kebanyakan dari mereka, hari ini masih hanya menggunakan 4 aturan itu.

Model sudah berkembang, ekosistem juga sudah berubah. Multi-step Agent, trigger berantai hook, loading skill, kolaborasi multi-repositori — semua ini belum ada ketika Karpathy menulis tweet itu. Keempat aturan asli tidak menyelesaikan masalah ini. Aturan-aturan itu tidak salah, hanya tidak lengkap.

Tambahkan 8 aturan baru. Waktu 6 minggu, pengujian mencakup 30 repositori kode. Tingkat error turun dari 41% menjadi 3%.

Malam ini juga simpan artikel ini, tempelkan 12 aturan ini ke CLAUDE.md Anda. Jika ini membantu Anda menghindari jalan berliku Claude selama seminggu, silakan bagikan.

Pertanyaan Terkait

QApa yang menjadi alasan utama penambahan 8 aturan baru ke dalam CLAUDE.md, di luar 4 aturan asli dari Karpathy?

AAlasan utamanya adalah karena ekosistem Claude Code telah berkembang sejak Januari 2026. Masalah baru muncul seperti konflik antar-Agent, rantai pemicu hook, konflik pemuatan skill, dan alur kerja multi-langkah antar-sesi yang terputus. 8 aturan baru ini dirancang untuk menutupi kegagalan mode baru ini yang tidak ditangani oleh 4 aturan asli.

QMenurut artikel, apa tiga kesalahan umum yang dilakukan pengembang terkait penggunaan file CLAUDE.md?

ATiga kesalahan umum adalah: 1) Menjadikannya tempat sampah preferensi sehingga membengkak hingga ribuan token dan tingkat kepatuhan turun. 2) Tidak menggunakannya sama sekali dan selalu memulai prompt dari awal, yang boros token dan tidak konsisten. 3) Hanya menyalin templat dan tidak pernah memperbaruinya, sehingga menjadi tidak efektif seiring perubahan basis kode.

QApa contoh konkret 'Kegagalan Diam' (Silent Failure) yang disebutkan dalam aturan 12, dan mengapa berbahaya?

AContoh konkretnya adalah ketika Claude melaporkan migrasi basis data 'berhasil selesai', tetapi diam-diam melewatkan 14% catatan yang memicu konflik batasan. Bahayanya adalah kegagalan ini tidak dilaporkan secara eksplisit, hanya masuk ke log. Kesalahan terdeteksi 11 hari kemudian ketika data laporan mulai tidak normal, menyebabkan waktu dan upaya debug yang besar.

QBerapa penurunan tingkat kesalahan yang dicapai setelah menerapkan 12 aturan dibandingkan tanpa aturan, berdasarkan pengujian dalam artikel?

ABerdasarkan pengujian selama 6 minggu pada 30 basis kode, tingkat kesalahan turun dari 41% (tanpa aturan CLAUDE.md) menjadi 3% setelah menerapkan 12 aturan. Aturan 4 Karpathy saja menurunkan kesalahan menjadi sekitar 11%.

QApa batas praktis yang disarankan untuk jumlah baris dalam file CLAUDE.md, dan apa akibatnya jika melampaui batas tersebut?

ABatas praktis yang disarankan adalah 200 baris. Jika melampaui batas ini, tingkat kepatuhan Claude terhadap aturan akan turun secara nyata karena aturan penting tenggelam dalam kebisingan dan Claude mulai melakukan pencocokan pola dangkal ('di sini ada aturan') alih-alih membacanya secara detail.

Bacaan Terkait

Saham AS Semakin Naik, Semakin Berbahaya? Goldman Sachs: Mekanisme Perlindungan Downturn Hampir Tidak Efektif

Pasar saham AS terus meroket, namun mekanisme perlindungan terhadap penurunan hampir tidak berfungsi, menurut laporan terbaru Goldman Sachs. Strategis derivatif Brian Garrett mencatat bahwa kemiringan volatilitas (Skew) opsi S&P 500 berada pada level terendah dalam 18 bulan, menunjukkan pasar memberi harga probabilitas yang hampir sama untuk kenaikan dan penurunan 10%. Indeks Panik Goldman juga mencapai level terendah dua tahun, menandakan permintaan lindung nilai risiko ekor sangat rendah. Tiga sinyal utama menjadi perhatian: (1) Peningkatan pasar yang sangat sempit, didorong oleh 10 saham terbesar; (2) Kinerja terkonsentrasi pada tema AI; (3) Pola harga yang mirip dengan periode 1998-1999. Meski ada kekhawatiran, hal ini tidak tercermin dalam harga opsi. Goldman mencatat bahwa biaya lindung nilai penurunan saat ini sangat rendah. Mereka memberikan rekomendasi strategi, termasuk membeli opsi RSP untuk mengantisipasi rotasi sektor, opsi panggil VIX, opsi jual S&P 500, dan meningkatkan eksposur volatilitas pada ETF Bitcoin. Data aliran dana menunjukkan hedge fund melakukan pembelian bersih dua minggu berturut-turut, dengan perputaran ke sektor keuangan. Aset dalam ETF leverage dan invers untuk saham tunggal global telah melampaui $60 miliar, berlipat ganda dalam dua bulan.

marsbit12m yang lalu

Saham AS Semakin Naik, Semakin Berbahaya? Goldman Sachs: Mekanisme Perlindungan Downturn Hampir Tidak Efektif

marsbit12m yang lalu

Gagalnya Strategi DAT? Perusahaan Publik yang Bertaruh pada HYPE Meraup Keuntungan Mengambang USD 12,5 Miliar

Artikel ini membandingkan kinerja tiga perusahaan publik yang mengadopsi strategi "treasury crypto" dengan fokus pada token HYPE (Hyperliquid), mencatat keuntungan mengambang kolektif lebih dari $12,5 miliar, sementara MicroStrategy (disebut sebagai "Strategy") menghadapi kerugian dan tekanan untuk menjual Bitcoin. Tiga perusahaan HYPE treasury yang dibahas adalah: 1. **Hyperliquid Strategies Inc. (PURR):** Menguasai sekitar 22,3 juta HYPE (nilai ~$16,36 miliar) dengan keuntungan ~$12,2 miliar. Sepenuhnya beralih dari bioteknologi menjadi perusahaan treasury crypto asli. 2. **Hyperion DeFi (HYPD):** Memegang sekitar 2 juta HYPE dan aktif berpartisipasi dalam ekosistem seperti operasi validator dan kolaborasi DeFi. 3. **Lion Group Holding (LGHL):** Memegang jumlah HYPE yang lebih kecil (~194 ribu), bersama dengan aset crypto lainnya. Artikel menyoroti bahwa strategi treasury HYPE tidak hanya bergantung pada apresiasi harga tetapi juga pada partisipasi ekosistem yang mendalam (seperti staking dan validator) untuk menghasilkan pendapatan tambahan. Ini dibandingkan dengan model MicroStrategy yang lebih bergantung pada leverage dan apresiasi harga Bitcoin. Kesimpulannya, memilih aset yang tepat (seperti HYPE yang dianggap tangguh) dan keterlibatan aktif dalam ekosistemnya mungkin menjadi faktor kunci kesuksesan saat ini dibandingkan hanya memegang aset saja. Masa depan HYPE dan perusahaan-perusahaan treasury-nya dinilai optimis.

marsbit32m yang lalu

Gagalnya Strategi DAT? Perusahaan Publik yang Bertaruh pada HYPE Meraup Keuntungan Mengambang USD 12,5 Miliar

marsbit32m yang lalu

DAT Gagal? Perusahaan Terbuka yang Bertaruh pada HYPE Catat Keuntungan Tidak Realisasi $12.5 Miliar

**Ringkasan Artikel: Perusahaan Terbuka yang Bertaruh pada HYPE Raup Keuntungan Mengambang $12.5 Miliar** Strategi "treasury crypto" yang dipelopori oleh MicroStrategy (disebut "Strategy" dalam artikel) ternyata mengalami kesulitan, dengan kerugian bersih $125 miliar pada Q1 2026 dan kemungkinan besar harus menjual aset Bitcoin-nya untuk membayar dividen. Di sisi lain, perusahaan-perusahaan terbuka yang mengadopsi strategi serupa tetapi berfokus pada token **HYPE** (asli ekosistem Hyperliquid) justru menuai keuntungan besar, dengan keuntungan mengambang kolektif melebihi **$12.5 miliar**. Tiga perusahaan treasury HYPE utama yang dibahas adalah: 1. **Hyperliquid Strategies Inc. (Kode saham: PURR)**: Hasil merger SPAC, sepenuhnya bertransformasi dari perusahaan bioteknologi. Memegang sekitar **22.3 juta HYPE** (nilai ~$16.36B) dengan keuntungan mengambang **$12.2B**. Harga sahamnya meroket dari $3-$4 menjadi **$9.99**, didorong kinerja HYPE. Perusahaan kini fokus pada staking, pengoptimalan hasil, dan partisipasi ekosistem melalui validator. 2. **Hyperion DeFi (Kode saham: HYPD)**: Perusahaan treasury HYPE pertama yang tercatat di AS, bertransformasi dari perusahaan mata. Memegang **~2 juta HYPE** (nilai ~$1.47B) dengan keuntungan ~$49.4 juta. Aktif membangun "roda penerus DeFi" dengan kerja sama lending pool dan vault volatilitas untuk menghasilkan pendapatan tambahan dari aset HYPE-nya. 3. **Lion Group Holding (Kode saham: LGHL)**: Platform perdagangan sekuritas tradisional yang beralih fokus ke HYPE. Memegang **193,775 HYPE** (nilai ~$14.14 juta), serta beberapa SOL dan SUI. Kapitalisasi pasarnya relatif kecil ($4.47 juta). **Kesimpulan:** Keberhasilan relatif treasury HYPE dibandingkan Strategy terletak pada **partisipasi ekosistem yang mendalam**. Alih-alih hanya menyimpan aset, mereka terlibat dalam staking, penghasilan validator, dan protokol DeFi dalam ekosistem Hyperliquid, menciptakan "roda penerus" pendapatan yang dikombinasikan dengan apresiasi harga HYPE. Dengan Hyperliquid sebagai pemain utama perdagangan derivatif on-chain dan tokenomics-nya yang mendukung pembelian/burning HYPE, prospek perusahaan-perusahaan ini dinilai positif. Token HYPE, sebagai aset tangguh di pasar bearish saat ini, diprediksi oleh beberapa pihak seperti Arthur Hayes berpotensi naik hingga $150, yang akan semakin mengangkat nilai treasury perusahaan-perusahaan ini.

Odaily星球日报37m yang lalu

DAT Gagal? Perusahaan Terbuka yang Bertaruh pada HYPE Catat Keuntungan Tidak Realisasi $12.5 Miliar

Odaily星球日报37m yang lalu

Pembongkaran Rack Nvidia Membuka Peluang Baru, Nilai MLCC Melonjak 182%

Analis Goldman Sachs dan Morgan Stanley menyoroti potensi lonjakan besar pada pasar MLCC (Multi-layer Ceramic Capacitor), komponen pasif kunci dalam server AI. Mereka memproyeksikan pasar MLCC untuk server AI akan tumbuh lebih dari empat kali lipat antara tahun fiskal 2025 dan 2030, didorong oleh lonjakan permintaan dari infrastruktur AI seperti rak server Nvidia generasi baru (Vera Rubin). MLCC berfungsi sebagai "jantung tak terlihat" untuk menstabilkan arus dan menyaring noise bagi chip berperforma tinggi. Analisis Morgan Stanley terhadap rak Nvidia Vera Rubin menunjukkan nilai MLCC per rak melonjak 182% dibandingkan generasi sebelumnya. Sektor ini menghadapi ketidakseimbangan pasokan-permintaan yang mendasar. Pertumbuhan kapasitas produksi tahunan industri hanya sedikit di atas 10%, jauh lebih rendah dari lonjakan permintaan yang diproyeksikan. Sinyal ketatnya pasar sudah terlihat: siklus pengiriman untuk MLCC high-end melebihi 20 minggu, dan raksasa Jepang seperti Murata dan Taiyo Yuden telah menaikkan harga sebesar 15-35% mulai April/Mei 2024. Data ekspor Jepang pada April menunjukkan kenaikan harga dan volume yang kuat. Para analis menekankan elastisitas laba yang signifikan dari kenaikan harga MLCC. Kenaikan harga 5% saja dapat meningkatkan laba operasional Taiyo Yuden hingga 37%. Siklus harga untuk MLCC dianggap tertinggal dibandingkan komponen AI lainnya seperti memori, menandakan ruang dan durasi kenaikan yang potensial lebih panjang. Kesimpulannya, MLCC, komponen yang sebelumnya kurang diperhatikan, kini berada di titik awal siklus super yang digerakkan oleh AI, ditandai dengan kenaikan volume dan harga yang kuat akibat permintaan dari server AI dan kendaraan listrik yang menghadapi kendala pasokan yang ketat.

marsbit50m yang lalu

Pembongkaran Rack Nvidia Membuka Peluang Baru, Nilai MLCC Melonjak 182%

marsbit50m yang lalu

Komik Panduan: Membantu Anda Memahami Peraturan Baru Investasi Luar Negeri China

Penulis: Liu Honglin, Mankun Blockchain Pemerintah China telah mengumumkan "Peraturan tentang Investasi Luar Negeri" yang akan berlaku mulai 1 Juli 2026. Intinya bukan melarang investasi ke luar negeri, tetapi mengingatkan perusahaan dan individu untuk meningkatkan kesadaran akan aturan. Berikut poin-poin kunci: 1️⃣ Cakupan luas: Peraturan ini berlaku tidak hanya untuk perusahaan, tetapi juga organisasi lain dan individu yang berdomisili di China. 2️⃣ Bentuk investasi beragam: Tidak hanya transfer modal, tetapi juga investasi aset, perolehan hak, pembiayaan, penjaminan, serta perolehan hak langsung/tidak langsung atas perusahaan atau aset di luar negeri. 3️⃣ Perusahaan perlu persiapan lengkap: Selain struktur kepemilikan, harus memperjelas entitas utama, proses persetujuan/pendaftaran, jalur dana, serta terkait teknologi, data, dan tinjauan keamanan. 4️⃣ Individu harus teliti: Jangan hanya lihat keuntungan. Pertimbangkan kelayakan, cara pengiriman dana, jenis aset yang dibeli, dan perlindungan hukum jika ada masalah. 5️⃣ Sanksi cukup berat: Selain denda, pelanggar bisa dibatasi untuk melakukan investasi luar negeri di masa depan. Kesimpulannya: Investasi luar negeri masih bisa dilakukan, tetapi tidak boleh hanya berdasarkan peluang bisnis semata. Patuhi aturan yang berlaku. *Catatan: Ini adalah informasi umum, bukan nasihat hukum atau investasi.*

marsbit51m yang lalu

Komik Panduan: Membantu Anda Memahami Peraturan Baru Investasi Luar Negeri China

marsbit51m yang lalu

Trading

Spot
Futures

Artikel Populer

Apa Itu $S$

Memahami SPERO: Tinjauan Komprehensif Pengenalan SPERO Seiring dengan perkembangan lanskap inovasi, munculnya teknologi web3 dan proyek cryptocurrency memainkan peran penting dalam membentuk masa depan digital. Salah satu proyek yang telah menarik perhatian di bidang dinamis ini adalah SPERO, yang dilambangkan sebagai SPERO,$$s$. Artikel ini bertujuan untuk mengumpulkan dan menyajikan informasi terperinci tentang SPERO, untuk membantu para penggemar dan investor memahami dasar-dasar, tujuan, dan inovasi dalam domain web3 dan crypto. Apa itu SPERO,$$s$? SPERO,$$s$ adalah proyek unik dalam ruang crypto yang berusaha memanfaatkan prinsip desentralisasi dan teknologi blockchain untuk menciptakan ekosistem yang mendorong keterlibatan, utilitas, dan inklusi finansial. Proyek ini dirancang untuk memfasilitasi interaksi peer-to-peer dengan cara baru, memberikan pengguna solusi dan layanan keuangan yang inovatif. Pada intinya, SPERO,$$s$ bertujuan untuk memberdayakan individu dengan menyediakan alat dan platform yang meningkatkan pengalaman pengguna dalam ruang cryptocurrency. Ini termasuk memungkinkan metode transaksi yang lebih fleksibel, mendorong inisiatif yang dipimpin komunitas, dan menciptakan jalur untuk peluang finansial melalui aplikasi terdesentralisasi (dApps). Visi mendasar dari SPERO,$$s$ berputar di sekitar inklusivitas, bertujuan untuk menjembatani kesenjangan dalam keuangan tradisional sambil memanfaatkan manfaat teknologi blockchain. Siapa Pencipta SPERO,$$s$? Identitas pencipta SPERO,$$s$ tetap agak samar, karena ada sumber daya publik yang terbatas yang memberikan informasi latar belakang terperinci tentang pendiriannya. Kurangnya transparansi ini dapat berasal dari komitmen proyek terhadap desentralisasi—sebuah etos yang banyak proyek web3 bagi, memprioritaskan kontribusi kolektif di atas pengakuan individu. Dengan memusatkan diskusi di sekitar komunitas dan tujuan kolektifnya, SPERO,$$s$ mewujudkan esensi pemberdayaan tanpa menonjolkan individu tertentu. Dengan demikian, memahami etos dan misi SPERO tetap lebih penting daripada mengidentifikasi pencipta tunggal. Siapa Investor SPERO,$$s$? SPERO,$$s$ didukung oleh beragam investor mulai dari modal ventura hingga investor malaikat yang berdedikasi untuk mendorong inovasi di sektor crypto. Fokus investor ini umumnya sejalan dengan misi SPERO—memprioritaskan proyek yang menjanjikan kemajuan teknologi sosial, inklusivitas finansial, dan tata kelola terdesentralisasi. Fondasi investor ini biasanya tertarik pada proyek yang tidak hanya menawarkan produk inovatif tetapi juga memberikan kontribusi positif kepada komunitas blockchain dan ekosistemnya. Dukungan dari investor ini memperkuat SPERO,$$s$ sebagai pesaing yang patut diperhitungkan di domain proyek crypto yang berkembang pesat. Bagaimana SPERO,$$s$ Bekerja? SPERO,$$s$ menerapkan kerangka kerja multi-faceted yang membedakannya dari proyek cryptocurrency konvensional. Berikut adalah beberapa fitur kunci yang menekankan keunikan dan inovasinya: Tata Kelola Terdesentralisasi: SPERO,$$s$ mengintegrasikan model tata kelola terdesentralisasi, memberdayakan pengguna untuk berpartisipasi aktif dalam proses pengambilan keputusan mengenai masa depan proyek. Pendekatan ini mendorong rasa kepemilikan dan akuntabilitas di antara anggota komunitas. Utilitas Token: SPERO,$$s$ memanfaatkan token cryptocurrency-nya sendiri, yang dirancang untuk melayani berbagai fungsi dalam ekosistem. Token ini memungkinkan transaksi, hadiah, dan fasilitasi layanan yang ditawarkan di platform, meningkatkan keterlibatan dan utilitas secara keseluruhan. Arsitektur Berlapis: Arsitektur teknis SPERO,$$s$ mendukung modularitas dan skalabilitas, memungkinkan integrasi fitur dan aplikasi tambahan secara mulus seiring dengan perkembangan proyek. Kemampuan beradaptasi ini sangat penting untuk mempertahankan relevansi di lanskap crypto yang selalu berubah. Keterlibatan Komunitas: Proyek ini menekankan inisiatif yang dipimpin komunitas, menggunakan mekanisme yang memberikan insentif untuk kolaborasi dan umpan balik. Dengan memelihara komunitas yang kuat, SPERO,$$s$ dapat lebih baik memenuhi kebutuhan pengguna dan beradaptasi dengan tren pasar. Fokus pada Inklusi: Dengan menawarkan biaya transaksi yang rendah dan antarmuka yang ramah pengguna, SPERO,$$s$ bertujuan untuk menarik basis pengguna yang beragam, termasuk individu yang mungkin sebelumnya tidak terlibat dalam ruang crypto. Komitmen ini terhadap inklusi sejalan dengan misi utamanya untuk memberdayakan melalui aksesibilitas. Garis Waktu SPERO,$$s$ Memahami sejarah proyek memberikan wawasan penting tentang trajektori dan tonggak perkembangannya. Berikut adalah garis waktu yang disarankan yang memetakan peristiwa signifikan dalam evolusi SPERO,$$s$: Fase Konseptualisasi dan Ideasi: Ide awal yang membentuk dasar SPERO,$$s$ dikembangkan, sangat selaras dengan prinsip desentralisasi dan fokus komunitas dalam industri blockchain. Peluncuran Whitepaper Proyek: Setelah fase konseptual, whitepaper komprehensif yang merinci visi, tujuan, dan infrastruktur teknologi SPERO,$$s$ dirilis untuk menarik minat dan umpan balik komunitas. Pembangunan Komunitas dan Keterlibatan Awal: Upaya jangkauan aktif dilakukan untuk membangun komunitas pengguna awal dan investor potensial, memfasilitasi diskusi seputar tujuan proyek dan mendapatkan dukungan. Acara Generasi Token: SPERO,$$s$ melakukan acara generasi token (TGE) untuk mendistribusikan token asli kepada pendukung awal dan membangun likuiditas awal dalam ekosistem. Peluncuran dApp Awal: Aplikasi terdesentralisasi (dApp) pertama yang terkait dengan SPERO,$$s$ diluncurkan, memungkinkan pengguna untuk terlibat dengan fungsionalitas inti platform. Pengembangan Berkelanjutan dan Kemitraan: Pembaruan dan peningkatan berkelanjutan terhadap penawaran proyek, termasuk kemitraan strategis dengan pemain lain di ruang blockchain, telah membentuk SPERO,$$s$ menjadi pemain yang kompetitif dan berkembang di pasar crypto. Kesimpulan SPERO,$$s$ berdiri sebagai bukti potensi web3 dan cryptocurrency untuk merevolusi sistem keuangan dan memberdayakan individu. Dengan komitmen terhadap tata kelola terdesentralisasi, keterlibatan komunitas, dan fungsionalitas yang dirancang secara inovatif, ia membuka jalan menuju lanskap keuangan yang lebih inklusif. Seperti halnya investasi di ruang crypto yang berkembang pesat, calon investor dan pengguna dianjurkan untuk melakukan riset secara menyeluruh dan terlibat dengan perkembangan yang sedang berlangsung dalam SPERO,$$s$. Proyek ini menunjukkan semangat inovatif industri crypto, mengundang eksplorasi lebih lanjut ke dalam berbagai kemungkinan yang ada. Meskipun perjalanan SPERO,$$s$ masih berlangsung, prinsip-prinsip dasarnya mungkin benar-benar mempengaruhi masa depan cara kita berinteraksi dengan teknologi, keuangan, dan satu sama lain dalam ekosistem digital yang saling terhubung.

75 Total TayanganDipublikasikan pada 2024.12.17Diperbarui pada 2024.12.17

Apa Itu $S$

Apa Itu AGENT S

Agent S: Masa Depan Interaksi Otonom di Web3 Pendahuluan Dalam lanskap Web3 dan cryptocurrency yang terus berkembang, inovasi secara konstan mendefinisikan ulang cara individu berinteraksi dengan platform digital. Salah satu proyek perintis, Agent S, menjanjikan untuk merevolusi interaksi manusia-komputer melalui kerangka agen terbuka. Dengan membuka jalan untuk interaksi otonom, Agent S bertujuan untuk menyederhanakan tugas-tugas kompleks, menawarkan aplikasi transformasional dalam kecerdasan buatan (AI). Eksplorasi mendetail ini akan menyelami seluk-beluk proyek, fitur uniknya, dan implikasinya untuk domain cryptocurrency. Apa itu Agent S? Agent S berdiri sebagai kerangka agen terbuka yang inovatif, dirancang khusus untuk mengatasi tiga tantangan mendasar dalam otomatisasi tugas komputer: Memperoleh Pengetahuan Spesifik Domain: Kerangka ini secara cerdas belajar dari berbagai sumber pengetahuan eksternal dan pengalaman internal. Pendekatan ganda ini memberdayakannya untuk membangun repositori pengetahuan spesifik domain yang kaya, meningkatkan kinerjanya dalam pelaksanaan tugas. Perencanaan Selama Rentang Tugas yang Panjang: Agent S menggunakan perencanaan hierarkis yang ditingkatkan pengalaman, pendekatan strategis yang memfasilitasi pemecahan dan pelaksanaan tugas-tugas rumit dengan efisien. Fitur ini secara signifikan meningkatkan kemampuannya untuk mengelola beberapa subtugas dengan efisien dan efektif. Menangani Antarmuka Dinamis dan Tidak Seragam: Proyek ini memperkenalkan Antarmuka Agen-Komputer (ACI), solusi inovatif yang meningkatkan interaksi antara agen dan pengguna. Dengan memanfaatkan Model Bahasa Besar Multimodal (MLLM), Agent S dapat menavigasi dan memanipulasi berbagai antarmuka pengguna grafis dengan mulus. Melalui fitur-fitur perintis ini, Agent S menyediakan kerangka kerja yang kuat yang mengatasi kompleksitas yang terlibat dalam mengotomatisasi interaksi manusia dengan mesin, membuka jalan untuk berbagai aplikasi dalam AI dan seterusnya. Siapa Pencipta Agent S? Meskipun konsep Agent S secara fundamental inovatif, informasi spesifik tentang penciptanya tetap samar. Pencipta saat ini tidak diketahui, yang menyoroti baik tahap awal proyek atau pilihan strategis untuk menjaga anggota pendiri tetap tersembunyi. Terlepas dari anonimitas, fokus tetap pada kemampuan dan potensi kerangka kerja. Siapa Investor Agent S? Karena Agent S relatif baru dalam ekosistem kriptografi, informasi terperinci mengenai investor dan pendukung keuangannya tidak secara eksplisit didokumentasikan. Kurangnya wawasan yang tersedia untuk umum mengenai fondasi investasi atau organisasi yang mendukung proyek ini menimbulkan pertanyaan tentang struktur pendanaannya dan peta jalan pengembangannya. Memahami dukungan sangat penting untuk mengukur keberlanjutan proyek dan potensi dampak pasar. Bagaimana Cara Kerja Agent S? Di inti Agent S terletak teknologi mutakhir yang memungkinkannya berfungsi secara efektif dalam berbagai pengaturan. Model operasionalnya dibangun di sekitar beberapa fitur kunci: Interaksi Komputer yang Mirip Manusia: Kerangka ini menawarkan perencanaan AI yang canggih, berusaha untuk membuat interaksi dengan komputer lebih intuitif. Dengan meniru perilaku manusia dalam pelaksanaan tugas, ia menjanjikan untuk meningkatkan pengalaman pengguna. Memori Naratif: Digunakan untuk memanfaatkan pengalaman tingkat tinggi, Agent S memanfaatkan memori naratif untuk melacak sejarah tugas, sehingga meningkatkan proses pengambilan keputusannya. Memori Episodik: Fitur ini memberikan panduan langkah demi langkah kepada pengguna, memungkinkan kerangka untuk menawarkan dukungan kontekstual saat tugas berlangsung. Dukungan untuk OpenACI: Dengan kemampuan untuk berjalan secara lokal, Agent S memungkinkan pengguna untuk mempertahankan kontrol atas interaksi dan alur kerja mereka, sejalan dengan etos terdesentralisasi Web3. Integrasi Mudah dengan API Eksternal: Versatilitas dan kompatibilitasnya dengan berbagai platform AI memastikan bahwa Agent S dapat dengan mulus masuk ke dalam ekosistem teknologi yang ada, menjadikannya pilihan menarik bagi pengembang dan organisasi. Fungsionalitas ini secara kolektif berkontribusi pada posisi unik Agent S dalam ruang kripto, saat ia mengotomatisasi tugas-tugas kompleks yang melibatkan banyak langkah dengan intervensi manusia yang minimal. Seiring proyek ini berkembang, aplikasi potensialnya di Web3 dapat mendefinisikan ulang bagaimana interaksi digital berlangsung. Garis Waktu Agent S Pengembangan dan tonggak Agent S dapat dirangkum dalam garis waktu yang menyoroti peristiwa pentingnya: 27 September 2024: Konsep Agent S diluncurkan dalam sebuah makalah penelitian komprehensif berjudul “Sebuah Kerangka Agen Terbuka yang Menggunakan Komputer Seperti Manusia,” yang menunjukkan dasar untuk proyek ini. 10 Oktober 2024: Makalah penelitian tersebut dipublikasikan secara terbuka di arXiv, menawarkan eksplorasi mendalam tentang kerangka kerja dan evaluasi kinerjanya berdasarkan tolok ukur OSWorld. 12 Oktober 2024: Sebuah presentasi video dirilis, memberikan wawasan visual tentang kemampuan dan fitur Agent S, lebih lanjut melibatkan pengguna dan investor potensial. Tanda-tanda dalam garis waktu ini tidak hanya menggambarkan kemajuan Agent S tetapi juga menunjukkan komitmennya terhadap transparansi dan keterlibatan komunitas. Poin Kunci Tentang Agent S Seiring kerangka Agent S terus berkembang, beberapa atribut kunci menonjol, menekankan sifat inovatif dan potensinya: Kerangka Inovatif: Dirancang untuk memberikan penggunaan komputer yang intuitif seperti interaksi manusia, Agent S membawa pendekatan baru untuk otomatisasi tugas. Interaksi Otonom: Kemampuan untuk berinteraksi secara otonom dengan komputer melalui GUI menandakan lompatan menuju solusi komputasi yang lebih cerdas dan efisien. Otomatisasi Tugas Kompleks: Dengan metodologinya yang kuat, ia dapat mengotomatisasi tugas-tugas kompleks yang melibatkan banyak langkah, membuat proses lebih cepat dan kurang rentan terhadap kesalahan. Perbaikan Berkelanjutan: Mekanisme pembelajaran memungkinkan Agent S untuk belajar dari pengalaman masa lalu, terus meningkatkan kinerja dan efektivitasnya. Versatilitas: Adaptabilitasnya di berbagai lingkungan operasi seperti OSWorld dan WindowsAgentArena memastikan bahwa ia dapat melayani berbagai aplikasi. Saat Agent S memposisikan dirinya di lanskap Web3 dan kripto, potensinya untuk meningkatkan kemampuan interaksi dan mengotomatisasi proses menandakan kemajuan signifikan dalam teknologi AI. Melalui kerangka inovatifnya, Agent S mencerminkan masa depan interaksi digital, menjanjikan pengalaman yang lebih mulus dan efisien bagi pengguna di berbagai industri. Kesimpulan Agent S mewakili lompatan berani ke depan dalam pernikahan AI dan Web3, dengan kapasitas untuk mendefinisikan ulang cara kita berinteraksi dengan teknologi. Meskipun masih dalam tahap awal, kemungkinan aplikasinya sangat luas dan menarik. Melalui kerangka komprehensifnya yang mengatasi tantangan kritis, Agent S bertujuan untuk membawa interaksi otonom ke garis depan pengalaman digital. Saat kita melangkah lebih dalam ke dalam ranah cryptocurrency dan desentralisasi, proyek-proyek seperti Agent S pasti akan memainkan peran penting dalam membentuk masa depan teknologi dan kolaborasi manusia-komputer.

906 Total TayanganDipublikasikan pada 2025.01.14Diperbarui pada 2025.01.14

Apa Itu AGENT S

Cara Membeli S

Selamat datang di HTX.com! Kami telah membuat pembelian Sonic (S) menjadi mudah dan nyaman. Ikuti panduan langkah demi langkah kami untuk memulai perjalanan kripto Anda.Langkah 1: Buat Akun HTX AndaGunakan alamat email atau nomor ponsel Anda untuk mendaftar akun gratis di HTX. Rasakan perjalanan pendaftaran yang mudah dan buka semua fitur.Dapatkan Akun SayaLangkah 2: Buka Beli Kripto, lalu Pilih Metode Pembayaran AndaKartu Kredit/Debit: Gunakan Visa atau Mastercard Anda untuk membeli Sonic (S) secara instan.Saldo: Gunakan dana dari saldo akun HTX Anda untuk melakukan trading dengan lancar.Pihak Ketiga: Kami telah menambahkan metode pembayaran populer seperti Google Pay dan Apple Pay untuk meningkatkan kenyamanan.P2P: Lakukan trading langsung dengan pengguna lain di HTX.Over-the-Counter (OTC): Kami menawarkan layanan yang dibuat khusus dan kurs yang kompetitif bagi para trader.Langkah 3: Simpan Sonic (S) AndaSetelah melakukan pembelian, simpan Sonic (S) di akun HTX Anda. Selain itu, Anda dapat mengirimkannya ke tempat lain melalui transfer blockchain atau menggunakannya untuk memperdagangkan mata uang kripto lainnya.Langkah 4: Lakukan trading Sonic (S)Lakukan trading Sonic (S) dengan mudah di pasar spot HTX. Cukup akses akun Anda, pilih pasangan perdagangan, jalankan trading, lalu pantau secara real-time. Kami menawarkan pengalaman yang ramah pengguna baik untuk pemula maupun trader berpengalaman.

1.3k Total TayanganDipublikasikan pada 2025.01.15Diperbarui pada 2025.03.21

Cara Membeli S

Diskusi

Selamat datang di Komunitas HTX. Di sini, Anda bisa terus mendapatkan informasi terbaru tentang perkembangan platform terkini dan mendapatkan akses ke wawasan pasar profesional. Pendapat pengguna mengenai harga S (S) disajikan di bawah ini.

活动图片

Kategori Populerright-arrow

Tag Populerright-arrow