CHATGPT: 7 FITUR DAN KAPAN KEPAKAI

Kebanyakan orang berhenti di kolom chat, padahal enam surface lainnya kepakai buat hal yang beda-beda.

Panduan ini disusun dari masalah yang lagi kamu hadapi, bukan dari daftar fiturnya. Soalnya masalah itu yang bikin kamu inget pas lagi butuh, dan daftar fitur ga pernah nyangkut lama di kepala.

Sebelum masuk satu-satu, ini peta cepatnya. Cari situasi yang paling mirip sama kamu sekarang, terus lompat ke bagian itu.

Stuck dan butuh mikir bareng atau ngerangkum sesuatu, itu Chat. Butuh visual tapi kamu ga bisa desain, itu Images. Ada kerjaan yang kamu ulang tiap minggu, itu Scheduled. Datanya ada di Drive, Canva, atau Notion kamu, itu Plugins.

Tugas panjang yang hasil akhirnya harus bisa direview, itu Work. Lebih gampang ngomong daripada ngetik, itu Voice. Ada bug atau codebase yang mau kamu ngerti, itu Codex.

Yang paling sering dipakai, dan yang paling sering dipakai setengah-setengah. Bedanya jawaban bagus sama jawaban generik itu hampir selalu ada di seberapa spesifik kamu ngasih konteks di awal.

Pola yang selalu jalan: kasih perannya, kasih konteksnya, kasih batasannya, terus bilang bentuk output yang kamu mau.

Aku lagi [situasi kamu, 1-2 kalimat konteks].
Yang aku butuhin: [hasil yang kamu mau].
Batasannya: [waktu, budget, panjang, tingkat kesulitan pembaca].
Kasih jawabannya dalam bentuk [bullet / tabel / draft jadi], maksimal [panjang].
Kalau ada yang kurang jelas dari brief aku, tanya dulu sebelum jawab.

Kalimat terakhir itu yang paling ngaruh. Tanpa itu dia bakal nebak konteks yang hilang, dan kamu baru sadar tebakannya salah setelah baca satu halaman.

Yang sering salah: minta “tolong perbaiki” tanpa bilang perbaikan ke arah mana. Bilang mau lebih pendek, lebih formal, lebih konkret, atau lebih gampang dipahami orang awam.

Buat bikin gambar dari deskripsi, dan buat ngedit gambar yang udah ada. Deskripsi yang bagus urutannya: subjek, gaya, komposisi, cahaya, rasio, terus hal-hal yang kamu ga mau ada.

[Subjek dan apa yang lagi terjadi]. Gaya [editorial / ilustrasi flat / foto realistis].
Komposisi [close-up / wide, subjek di kiri / tengah]. Cahaya [pagi hangat / studio lembut].
Rasio [9:16 / 1:1 / 16:9]. Tanpa teks, tanpa watermark, tanpa [yang kamu ga mau].

Dari gambar ini, ganti [bagian spesifik] jadi [yang kamu mau].
Pertahankan komposisi, warna, dan pencahayaan yang sekarang.

Yang kedua itu buat ngedit. Jangan generate ulang dari nol, sebutin bagian yang mau diubah dan biarin sisanya.

Yang sering salah: nulis deskripsi panjang yang isinya adjective semua. Yang bikin gambarnya berubah itu subjek, komposisi, dan cahaya, bukan tambahan kata “indah” atau “estetik”.

Buat tugas yang kamu ulang terus dengan pola yang sama. Kamu setup sekali, terus hasilnya masuk sendiri sebagai chat baru pas waktunya.

Yang cocok itu tugas yang outputnya pendek dan berulang, misalnya rekap mingguan, checklist pagi, atau draft yang formatnya selalu sama.

Setiap [hari] jam [waktu], [tugas yang harus dia kerjain].
Formatnya: [bentuk output, dibuat persis sama tiap kali].
Maksimal [panjang]. Kalau ga ada yang berubah dari minggu lalu, bilang tidak ada perubahan.

Baris terakhir itu yang bikin kamu beneran baca hasilnya. Tanpa itu, tiap minggu kamu dikirimin rekap yang isinya keliatan penuh padahal ga ada yang baru.

Yang sering salah: ngejadwalin tugas yang butuh data yang dia ga punya aksesnya. Cek dulu sumber datanya kebaca atau engga sebelum kamu jadwalin.

Buat nyambungin ChatGPT ke aplikasi lain yang kamu udah pakai, misalnya Canva, Google Drive, atau Notion. Kamu connect sekali dari plugin directory, terus kepakai di semua chat setelahnya.

Yang bikin hasilnya beda itu nyebut sumbernya persis.

Dari [aplikasi], buka [nama file atau folder persis].
Ambil [bagian yang kamu butuhin], terus [apa yang harus dia lakuin sama data itu].
Sebutin nama file dan bagian mana yang kamu pakai buat tiap poin.
Kalau file yang aku sebut ga ketemu, bilang, jangan pakai file lain yang mirip.

Yang sering salah: bilang “ambil dari Drive aku” doang. Kalau namanya ga disebut, dia bakal milih file yang menurutnya paling relevan, dan kamu ga tau dia baca yang mana.

Buat tugas panjang yang jalan beberapa langkah sampai ada hasil yang bisa kamu review, misalnya riset, analisis file, atau nyusun deck. Ini yang paling ngaruh kalau brief-nya rapi, dan paling berantakan kalau brief-nya asal.

Tugas: [hasil akhir yang kamu mau, sespesifik mungkin].
Bahan: [file yang kamu lampirin, sebutin isinya apa].
Sebelum mulai, kasih rencana langkahnya dulu dan tunggu aku approve.
Selama ngerjain, tandai setiap tempat yang butuh keputusan aku, jangan diputusin sendiri.
Hasil akhirnya dalam bentuk [format file], plus daftar asumsi yang kamu pakai.
Kalau ada data yang bentrok antar file, berhenti dan tanya, jangan dipilih salah satu.

Dua kalimat soal keputusan dan data bentrok itu inti dari fitur ini. Yang bikin hasil kerjaan panjang ga kepakai biasanya satu asumsi salah di tengah yang kebawa sampai akhir, dan kualitas tulisannya sendiri jarang jadi masalah.

Yang sering salah: ngasih tugas besar tanpa minta rencana dulu. Lima menit baca rencana jauh lebih murah daripada baca hasil jadi yang arahnya salah.

Buat diskusi dan ngarahin tugas lewat suara. Paling kepakai pas kamu lagi mikir dan belum tau mau nulis apa, atau pas tangan kamu lagi ga bebas.

Tiga cara pakai yang beneran ngaruh:

Aku mau ngomong sekitar 2 menit soal [topik]. Dengerin dulu sampai selesai.
Abis itu tanya 3 pertanyaan yang paling nunjukin lubang di argumen aku.
Jangan kasih saran sebelum aku jawab ketiganya.

Aku lagi latihan presentasi. Kamu jadi audiens yang skeptis tapi sopan.
Dengerin, terus kasih satu keberatan yang paling mungkin muncul beneran.

Aku lagi jalan dan ga bisa ngetik. Aku diktein poin-poinnya, kamu rapiin jadi
[email / outline / to-do list], terus bacain ulang biar aku bisa koreksi.

Yang sering salah: dipakai kayak ngetik, cuma pakai mulut. Kelebihannya itu di bolak-balik cepat dan mikir sambil ngomong, bukan di ngedikte perintah panjang.

Buat baca codebase, debug, nulis kode, sampai review perubahan. Yang bikin jawabannya kepakai itu kamu bilang apa yang kamu harapin terjadi dan apa yang beneran terjadi.

Masalahnya: [apa yang kamu lakuin] -> harusnya [yang kamu harapin],
tapi yang terjadi [yang beneran terjadi].
File yang kemungkinan terkait: [path kalau kamu tau].
Cari penyebabnya dulu dan jelasin ke aku sebelum ngubah apa-apa.
Abis diperbaiki, jelasin kenapa itu yang bikin error, bukan cuma nunjukin kodenya.

Minta penjelasan itu bukan formalitas. Bug yang kamu ngerti penyebabnya ga bakal kamu bikin lagi bulan depan.

Yang sering salah: nempel error message doang tanpa konteks apa yang lagi kamu jalanin. Error yang sama bisa punya tiga penyebab beda.

Ambil satu kerjaan yang minggu ini kamu ulang, terus pindahin ke Scheduled. Itu yang paling cepat kerasa bedanya karena kamu langsung dapet waktunya balik, dan setup-nya cuma sekali.

Abis itu baru Work, pas ada tugas yang kamu tunda-tunda soalnya kebayang panjangnya. Sisanya nyusul sendiri begitu kamu kebiasa mikir dari masalah dulu, baru milih fiturnya.

Ga harus pakai semuanya, dan yang ga kepakai buat kerjaan kamu ya emang ga usah dipakai.