Apakah aturan bisa meningkatkan kualitas tulisan AI? — Mengubah “editor profesional” menjadi alur TypeScript

Saat tulisan AI terasa biasa saja, reaksi paling mudah adalah mengganti model dengan yang lebih pintar.

Ada pilihan lain: taruh meja redaksi super cerewet yang tidak pernah tidur di samping model.

Redaksi itu memeriksa judul, mencocokkan janji judul dengan isi, mencari istilah yang belum dijelaskan, mendeteksi pengulangan, memastikan 12 bahasa lengkap, lalu meminta penulisan ulang hanya pada bagian yang gagal.

TypeScript tidak punya bakat menulis. Namun ia bisa membangun proses editorial yang menolak menerbitkan naskah lemah.

1. Jawaban 5 detik: jangan mengodekan bakat menulis; kodekan proses editorial

Aturan bersama memang dapat memperbaiki tulisan AI. Namun peningkatan terbesar datang saat aturan menjadi alur: hasilkan → periksa → nilai makna → revisi kegagalan → periksa lagi.

OpenAI menjelaskan eval sebagai siklus untuk menentukan seperti apa hasil yang baik, mengukurnya, lalu memperbaiki sistem dengan memasukkan pola kegagalan baru.[1]

Dalam pabrik artikel, satu kesalahan seharusnya tidak hanya memperbaiki satu artikel. Kesalahan itu harus menjadi pemeriksaan untuk seratus artikel berikutnya.

2. TypeScript bukan penulis; ia adalah lini produksi

Kode sangat kuat untuk pemeriksaan yang pasti:

• Apakah ada lebih dari satu H1?
• Apakah title dan og:title bertentangan?
• Apakah salah satu dari 12 bahasa hilang?
• Apakah judul bagian terduplikasi?
• Apakah format tanggal atau URL salah?
• Apakah naskah harus kembali ke tahap revisi?

Namun pertanyaan seperti “apakah pembukaan menarik?”, “apakah metafora ini perlu dipertahankan?”, “apakah judul menjawab pertanyaan pembaca?”, atau “apakah riset menenggelamkan pengamatan asli?” membutuhkan pemahaman makna.

Pembagian yang berguna adalah: TypeScript untuk pemeriksaan mekanis, editor AI untuk penilaian semantik.

3. “Editor profesional” lebih mudah diterapkan jika dibagi menjadi peran

Editor struktur

Memeriksa kebutuhan pembaca, urutan, ritme, dan seberapa cepat jawaban muncul.

Editor naskah

Merapikan judul, pembukaan, pengulangan, pilihan kata, dan ritme.

Editor fakta

Memeriksa angka, tanggal, kutipan, tingkat kepastian, dan sumber.

Editor pintu masuk pencarian

Memeriksa apakah bagian awal judul sudah menjelaskan isi halaman.

Google Search Central menyatakan bahwa judul hasil pencarian membantu pengguna memahami isi dan relevansi dengan cepat. Google menyarankan judul yang deskriptif, ringkas, khas, dan tidak menjejalkan kata kunci.[2]

Riset kegunaan NN/g juga menunjukkan bahwa pengguna sering memindai halaman web, sehingga kata-kata awal pada judul dan tautan membawa banyak sinyal informasi.[4][5]

Ini bukan trik “taruh kata SEO ajaib di kiri”, melainkan membuat topik cepat dikenali.

4. Sebelum / sesudah: pindahkan lelucon, jangan bunuh lelucon

Sebelum

Nama keluarganya tidak salah; kamusnya yang kecelakaan — Manko, Wang, Chin dan “nama berbahaya di bahasa lain”

Lucu, tetapi topik utamanya datang terlambat.

Sesudah

Nama yang terdengar canggung dalam bahasa lain — Manko, Wang, Chin dan tabrakan lintas bahasa

Lalu buka artikel dengan:

Nama keluarganya tidak salah. Kamusnya yang kecelakaan.

Humornya tetap hidup, bahkan lebih mudah dipahami karena konteks sudah jelas.

Panduan people-first Google juga meminta penulis memastikan judul memberi ringkasan yang berguna dan deskriptif, bukan sekadar mengejar trafik pencarian dengan sensasi.[3]

5. Aturan yang baik mencegah kecelakaan berulang; bukan membuat semua artikel kembar

Memaksa semua artikel selalu tiga kalimat, selalu memakai subjudul pertanyaan, dan selalu dua contoh akan menghasilkan teks cetakan.

Lebih baik mendefinisikan kegagalan:

• Jangan kubur pertanyaan utama di belakang slogan.
• Jangan janjikan hal yang tidak dijawab isi.
• Jangan ulangi keberatan yang sama berkali-kali.
• Jangan lempar jargon tanpa penjelasan.
• Buat subjudul bisa dipahami sendiri.
• Gunakan riset untuk mendukung pengamatan asli, bukan menggantikannya.
• Jangan menerjemahkan susunan bahasa Jepang secara mekanis ke 11 bahasa lain.

6. P0 / P1 / P2 mencegah sistem menjadi penjara aturan

P0: tidak boleh gagal

Fakta, angka, tanggal, kutipan, kecocokan judul-isi, privasi, kelengkapan bahasa, dan larangan klaim tanpa dasar.

P1: sangat penting

Jawaban cepat, satu gagasan utama per paragraf, penjelasan sederhana sebelum jargon, subjudul yang jelas, dan pengulangan lebih sedikit.

P2: rasa tulisan

Humor, metafora, nada percakapan, ritme, dan hook kuat.

Menjaga P0 tidak berarti membunuh P2. Jika tidak, kontrol kualitas hanya menghasilkan teks seperti surat peringatan resmi.

7. Aset sebenarnya adalah lingkar evaluasi yang tumbuh dari kegagalan

1. Buat draf.
2. Jalankan pemeriksaan mekanis.
3. Minta editor AI membaca makna.
4. Kembalikan alasan gagal dalam bentuk terstruktur.
5. Revisi hanya bagian yang gagal.
6. Periksa lagi.
7. Jika kegagalannya baru dan umum, jadikan kandidat aturan permanen.

Pendekatan eval OpenAI menekankan perbaikan berkelanjutan dari kegagalan nyata seperti ini.[1]

Jika hanya judul yang gagal, jangan hasilkan ulang dua ribu kata yang sudah bagus.

8. Implementasi TypeScript bisa tetap sederhana

const draft = await writeArticle(input);
const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);

if (!hardCheck.ok || editorial.hasCriticalIssue) {
  const revised = await reviseOnlyFailures(draft, { hardCheck, editorial });
  return verifyAgain(revised);
}
return draft;

Yang pasti dinilai masuk ke kode; yang membutuhkan makna masuk ke editor AI; alasan gagal diubah menjadi instruksi revisi yang spesifik.

9. Otomasi tetap punya kelemahan: editor AI juga bisa salah

AI bisa menghapus lelucon bagus karena dianggap berulang, meratakan gaya minoritas, menghilangkan humor budaya saat lokalisasi, atau memberi nilai terlalu tinggi pada tulisannya sendiri.

Karena itu skor semantik hanyalah sinyal inspeksi, bukan kebenaran. Fakta kembali ke sumber primer atau resmi, kasus berisiko tinggi naik ke manusia, dan setiap bahasa dinilai sebagai bahasa yang hidup.

10. Pada 100 atau 1000 artikel, yang paling berharga adalah efek majemuk dari perbaikan

Satu artikel menunjukkan slogan menutupi pertanyaan utama: tambahkan pemeriksaan.

Artikel lain menunjukkan terlalu banyak “namun” mengaburkan kesimpulan: tambahkan pemeriksaan.

Versi Jerman ternyata benar secara tata bahasa tetapi terasa diterjemahkan: buat pemeriksaan khusus Jerman.

Kesalahan berubah dari pekerjaan revisi satu kali menjadi infrastruktur editorial.

11. Kesimpulan: bangun meja redaksi yang tidak tidur, bukan gunung aturan

Tujuannya bukan memindahkan bakat sastra ke TypeScript.

Yang perlu direkayasa adalah penilaian editor bagus: “pembaca tidak tahu ini tentang apa”, “judul menjanjikan sesuatu yang tidak dibayar isi”, “jangan hapus lelucon itu; pindahkan”, “klaim ini butuh sumber”.

Saat penilaian itu menjadi pemeriksaan, review semantik, revisi lokal, dan verifikasi ulang, model yang sama pun bisa menghasilkan artikel akhir yang jauh lebih baik.

Karena yang belajar adalah sistem editorial di sekitar model.

---