AI dalam Aliran Kerja Data Analyst: Di Mana Ia Membantu, Di Mana Ia Gagal

VP Jualan menghantar mesej kepada anda di Slack pada pukul 8:47 pagi. Mesejnya satu baris sahaja: "AI kata hasil meningkat 14%, boleh anda semak semula?"

Anda membuka kopilot alat BI, tampal arahan yang sama seperti yang VP gunakan, dan mendapat balik satu pertanyaan yang selesai dalam masa 1.2 saat. Nombor yang dikembalikan ialah 14%. Pertanyaan itu juga silap. Ia mencantumkan (join) jadual orders ke customers menggunakan email dan bukannya customer_id, mengira dua kali sesiapa yang pernah mengemas kini alamat e-mel mereka. Ia menganggap status = 'completed' sebagai hasil tanpa menapis bayaran balik. Angka 14% itu adalah kiraan matematik yang betul pada set data yang salah.

VP tidak tahu perkara itu. Kopilot tidak tahu perkara itu. Anda tahu, kerana anda telah bekerja dalam gudang data ini selama sembilan bulan dan anda pernah terjerumus pada kedua-dua jenis cantuman (join) tersebut sebelum ini.

Inilah tugas sebenar pada tahun 2026. Bukan menulis SQL dengan lebih pantas. Tetapi mengesahkan SQL yang telah ditulis dengan meyakinkan oleh sesuatu yang tidak memahami perniagaan.

Mengapa perkara ini penting sekarang

Setiap vendor BI dan setiap IDE telah mengeluarkan ciri "tanya dalam bahasa biasa". Pihak pengurusan telah menyedarinya. CFO membaca artikel McKinsey tentang produktiviti AI dan kini menjangkakan analitik menghasilkan lebih banyak dengan bilangan kakitangan yang sama. Menolak penggunaan AI menjadikan anda kelihatan lambat. Mempercayainya secara membuta tuli menjadikan anda cop getah manusia pada nombor-nombor berhalusinasi yang dihantar ke paparan lembaga pengarah.

Satu-satunya pendirian yang lestari ialah yang ketiga: gunakan AI sebagai pengganda daya pada bahagian kerja yang bersifat mekanikal, dan jadilah lapisan tadbir urus pada bahagian yang tidak. Analyst yang boleh menerangkan dengan yakin mengapa pertanyaan yang draf oleh AI adalah salah, membetulkannya dalam dua minit, dan menghantar jawapan yang betul adalah lebih bernilai pada tahun 2026, bukan kurang. Analyst yang menampal output kopilot ke dalam papan pemuka (dashboard) dan meninggalkannya begitu sahaja adalah seorang junior dengan langkah tambahan.

Di mana AI sebenarnya membantu

Kita perlu spesifik. "AI membantu produktiviti" adalah jenis ayat yang saya ingin padamkan daripada artikel ini. Berikut adalah tempat ia membuktikan nilainya, secara khusus.

Draf SQL untuk diperhalusi

Cursor dengan Claude sebagai model adalah pilihan selamat semasa untuk analyst yang aktif. Kelebihan utamanya ialah draf kedua, bukan yang pertama. Anda telah menulis pertanyaan 200 baris dengan lima CTE untuk mengira pengekalan kohort (cohort retention) bulan ke bulan. Ia berfungsi, tetapi sukar dibaca. Tampalkan ke dalam Cursor, minta ia diperhalusi dengan menggabungkan CTE dan menambah komen, dan anda akan mendapat sesuatu yang lebih bersih dalam 30 saat. Anda membacanya, menolak dua perubahan yang merosakkan logik, menerima selebihnya, dan anda telah menjimatkan satu petang kerja pembersihan.

Perkara yang sama berlaku untuk fungsi tetingkap (window function) yang anda tulis dua kali setahun, cantuman diri (self-join) yang rumit untuk data hierarki, dan logik pangsi (pivot). Anggap output itu sebagai draf pertama daripada junior yang bijak tetapi tidak pernah melihat gudang data anda. Berguna, tetapi belum siap.

Dokumentasi skema papan pemuka

Bekalkan Claude dengan fail model dbt anda, LookML anda, atau JSON papan pemuka, lalu minta ia menulis entri kamus data (data dictionary). Ia akan menghasilkan prosa yang boleh disemak, 80% daripadanya betul. Anda menyunting 20% di mana ia membuat andaian. Jumlah masa: 10 minit setiap papan pemuka berbanding dua jam, dan mod kegagalan adalah "penerangan yang silap" bukan "nombor yang silap." Jauh lebih mudah dikesan semasa semakan.

Ini adalah penggunaan AI yang paling berimpak yang pernah saya temui. Dokumentasi adalah perkara yang setiap pasukan analitik berkata akan dilakukan "suku berikutnya" dan tidak pernah dilakukan. AI menghilangkan halangan untuk memulakannya.

Persediaan temu bual keperluan

Sebelum anda bertemu pihak berkepentingan (stakeholder) tentang papan pemuka baharu, tampal utas Slack mereka, rantaian e-mel, dan permintaan kasar ke dalam Claude. Berikan arahan: "Apakah lima soalan yang harus saya jelaskan sebelum menulis SQL untuk permintaan ini?" Anda akan mendapat senarai. Separuh soalan akan jelas. Dua daripadanya akan menangkap kekaburan yang anda terlepas pandang. Satu daripadanya tidak berguna. Manfaat bersih dalam 90 saat.

Intinya bukan bahawa AI mengetahui perniagaan anda. Intinya ialah AI adalah bebek getah (rubber duck) yang cekap dan mengemukakan soalan susulan yang lebih baik daripada yang anda kemukakan pada pukul 9 pagi hari Selasa.

Naratif pengesanan anomali

Anda telah menemui lonjakan itu. Kadar penukaran (conversion rate) turun 23% di wilayah tenggara, minggu ke minggu. Anda tahu ia disebabkan oleh ujian penetapan harga baharu. Kini anda perlu menulis mesej Slack dalam suara pasukan anda, dengan bahasa lindung (hedge) yang tepat, langkah seterusnya yang betul, dan seruan kepada pihak berkepentingan yang terjejas. AI merangka mesej itu dalam 15 saat. Anda menyunting nada, menghantarnya, dan meneruskan kerja.

Perhatikan susunannya. Anda melakukan analisis. AI melakukan penulisan. Balikkan susunan itu dan anda kembali kepada "AI kata hasil meningkat 14%."

Penyelenggaraan kamus data

Kebanyakan pasukan tidak mempunyai penerangan lajur dalam gudang data mereka. Tiada langsung. Rentetan kosong. Penjanaan penerangan secara automatik daripada nama lajur ditambah nilai sampel ditambah jadual induk bukanlah sempurna, tetapi "penerangan tidak sempurna" mengatasi "tiada penerangan" setiap kali. Jalankannya sebagai tugas kelompok sekali suku tahun, sunting secara manusia yang jelas silap, hantar.

Di mana AI gagal

Ini adalah mod kegagalan yang menghantar nombor salah kepada pihak eksekutif. Hafalkan semuanya.

Semantik data

orders.status = 'completed' tidak bermakna "hasil" dalam gudang data anda. Ia mungkin mengecualikan pesanan yang dikembalikan, atau mungkin tidak. Ia mungkin mengira pembaharuan langganan sebagai pesanan berasingan, atau menggabungkannya. Ia mungkin menggunakan gross_amount atau net_amount atau amount_after_tax_and_discount. AI tidak tahu mana satu. AI akan meneka. Tekaan itu akan kelihatan munasabah. Tekaan itu sering kali silap, dan ia akan silap dengan cara yang hampir mustahil untuk dikesan dari pertanyaan sahaja. SQL itu sempurna dari segi sintaks, cantuman dikompilasi, nombor dikembalikan. Anda perlu mengetahui gudang data untuk mengesannya.

Pengendalian NULL

COUNT(column) mengecualikan NULL. COUNT(*) tidak. SUM ke atas lajur dengan NULL mengembalikan NULL jika setiap nilai adalah NULL, tetapi nombor jika mana-mana nilai bukan NULL. LEFT JOIN pada hubungan satu-ke-banyak memperbesarkan bilangan baris (row count) anda jika anda terlupa untuk mengagregat. AI tersilap dalam perkara-perkara ini lebih kurang separuh masa pada skema sebenar, kerana separuh masa data latihan awam turut mengandungi pepijat yang sama. Jika papan pemuka anda tiba-tiba menunjukkan 4x jumlah pelanggan berbanding semalam, semak cantuman (join) anda.

Logik perniagaan

"Pelanggan aktif" bermakna sesuatu yang berbeza di setiap syarikat. Di syarikat B2B SaaS ia mungkin bermakna "log masuk dalam tempoh 30 hari." Di pasaran ia mungkin bermakna "melengkapkan transaksi dalam 90 hari yang lalu." Di syarikat fintech ia mungkin bermakna "baki melebihi $0 dan tiada bendera penipuan." AI lalai kepada definisi yang paling biasa dalam data latihannya, yang hampir pasti bukan definisi anda. Begitu juga dengan "MRR," "peralihan pelanggan," "penglibatan," "pengekalan." Setiap metrik mempunyai lima definisi yang munasabah. Pasukan anda menggunakan salah satu daripadanya. AI tidak tahu yang mana.

Tadbir urus dan salasilah data

AI dengan senang hati menulis pertanyaan terhadap customers_legacy_v2, jadual yang telah lapuk dan tidak disegarkan sejak November. AI tidak mengetahui SLA kesegaran dbt anda. AI tidak tahu bahawa pasukan pemasaran memisahkan jadual pelanggan pada hari Selasa untuk eksport kempen dan pemisahan itu mempunyai logik yang sedikit berbeza. AI tidak tahu bahawa anda berhijrah ke jadual hasil baharu enam minggu yang lalu dan yang lama adalah baca sahaja.

Ini adalah mod kegagalan yang paling teruk apabila ia meluas. Apabila gudang data anda berkembang, model mental AI tentangnya semakin jauh kebelakang, dan pertanyaan yang dirangkanya semakin tersilap dengan penuh keyakinan dari masa ke masa.

Perangkap "AI menghasilkan pertanyaan ini"

Inilah garisan keras. Jangan sekali-kali menampal pertanyaan yang dijana oleh AI ke dalam papan pemuka, laporan pihak berkepentingan, atau paparan eksekutif tanpa melakukan kesemua empat pemeriksaan ini:

1. Jalankannya terhadap hasil yang diketahui. Pilih hirisan yang telah anda sahkan sebelum ini (nombor bulan lalu yang telah CFO tandatangani persetujuan) dan sahkan bahawa pertanyaan AI menghasilkan semula hasilnya.
2. Periksa bilangan baris. Jika anda menjangkakan lebih kurang 10,000 pelanggan dan pertanyaan mengembalikan 47,000, anda mempunyai penggandaan baris (fanout). Jika ia mengembalikan 12, anda mempunyai penapis yang terlalu ketat.
3. Semak cantuman untuk penggandaan baris. Periksa setiap JOIN. Adakah sisi kanan dijamin unik pada kunci cantuman? Jika tidak, anda memerlukan DISTINCT atau pengagregatan.
4. Sahkan bahawa penapis tarikh melakukan apa yang ia dakwa. "Bulan lalu" dalam alat BI A mungkin bermakna "30 hari yang lalu." Dalam alat B ia mungkin bermakna "bulan kalendar sebelumnya." Dalam SQL yang ditulis oleh AI, ia boleh bermakna salah satu daripadanya, ditambah kesilapan satu hari.

Pola yang perlu dihayati ialah: AI menulisnya, saya mengesahkannya, saya memilikinya. Bukan: AI kata nombor itu adalah X. Jika anda tidak boleh mempertahankan pertanyaan baris demi baris di hadapan VP Kewangan, anda tidak boleh menghantar jawapan. Jika anda menghantarnya dan ia silap, "AI yang menulisnya" bukan pembelaan. Anda yang menulisnya, dengan menerimanya.

Tadbir urus dan kawalan versi

Perlakukan SQL berbantuan AI seperti mana-mana kod lain. Komitkannya ke repo dbt atau GitHub analitik anda. Gunakan semakan pull request (pull request review), walaupun satu-satunya penyemak ialah anda sendiri 24 jam kemudian dengan pandangan segar. Tag model dan arahan dalam mesej komit jika ia membentuk logik secara material, supaya anda di masa hadapan tahu dari mana struktur CTE yang pelik itu berasal.

Bina fail forbidden_patterns.md yang kecil dalam repo pasukan anda. Sepuluh hingga dua puluh entri, setiap satu adalah perangkap yang pernah anda sendiri alami:

• Cantuman yang kelihatan betul tetapi tidak (contoh email berbanding customer_id di atas)
• Lajur yang telah berubah makna (status dahulu merangkumi "shipped," kini tidak)
• Jadual yang tidak boleh dicapai secara langsung (raw.events adalah firehose, gunakan analytics.sessions)
• Definisi metrik yang berbeza daripada lalai awam (definisi "pengguna aktif" anda)
• Jadual yang sensitif SLA (yang ini mempunyai kelewatan 24 jam, yang itu adalah masa nyata)

Bekalkan fail itu ke dalam konteks Cursor untuk setiap sesi SQL. Ini adalah alat tadbir urus yang paling murah dan paling berimpak yang pernah saya temui. AI jauh lebih kurang berkemungkinan untuk terjerumus ke dalam perangkap yang diketahui jika anda telah memberitahunya di mana perangkap itu berada.

Rancangan 30 hari untuk mengintegrasikan AI tanpa kehilangan kemahiran anda

Jangan cuba mengubah keseluruhan aliran kerja anda dengan AI pada hari pertama. Lakukan secara berperingkat.

Minggu 1, kalibrasi. Pilih satu alat. Cursor ditambah Claude adalah pilihan lalai yang selamat; jika syarikat anda telah menggunakan Copilot, gunakan itu. Gunakannya hanya untuk penghalusan SQL pada pertanyaan yang sudah anda faham dan telah anda sahkan. Bandingkan setiap output dengan apa yang akan anda tulis sendiri. Bina pemahaman tentang di mana ia boleh dipercayai dan di mana ia berhalusinasi. Matlamatnya ialah kalibrasi, bukan produktiviti.

Minggu 2, dokumentasi. Tambah tugas berisiko rendah dan berimpak tinggi. Hasilkan entri kamus data secara automatik. Jana README papan pemuka. Tulis draf buku panduan (runbook) untuk permintaan berulang pasukan anda. Mod kegagalan di sini ialah ayat yang perlu anda tulis semula, bukan nombor yang silap di meja CFO.

Minggu 3, persediaan keperluan. Sebelum setiap mesyuarat pihak berkepentingan, jalankan AI pada utas terlebih dahulu. Minta lima soalan penjelasan. Jejak yang mana daripadanya sebenarnya menyelamatkan anda daripada kerja semula. Selepas dua minggu ini, anda akan mempunyai corak tentang apa yang AI tangkap dan apa yang ia terlepas.

Minggu 4, kodkan. Tulis ai-usage.md pasukan anda. Tiga bahagian: apa yang AI dibenarkan untuk merangka secara autonomi, apa yang manusia mesti sahkan sebelum cantum (merge), dan apa yang dilarang sama sekali. Titik permulaan yang munasabah:

• Dibenarkan: draf dokumentasi, cadangan penghalusan, draf naratif anomali selepas analisis manusia, soalan penjelasan keperluan.
• Sahkan sebelum cantum: mana-mana SQL yang menyentuh papan pemuka pengeluaran, mana-mana perubahan definisi metrik, mana-mana model dbt baharu.
• Dilarang: menjalankan SQL yang dirangka AI secara automatik terhadap pengeluaran tanpa LIMIT 100 dan semakan manusia, menampal mana-mana lajur dengan PII ke dalam alat AI pihak ketiga yang tidak mempunyai Perjanjian Pemprosesan Data (DPA) yang ditandatangani, menggunakan AI untuk menulis SQL dalam dialek yang anda tidak boleh baca dengan lancar.

Yang terakhir itu adalah yang kebanyakan orang terlepas pandang. Jika anda tidak boleh membaca sintaks fungsi tetingkap (window function) khusus Snowflake, anda tidak boleh menyemak apa yang Cursor tulis. Anda mempercayainya atas dasar iman. Jangan.

Pilihan: sudut pandang ACE Framework

Jika syarikat anda sedang melancarkan Model Operasi AI berdasarkan ACE Framework, aliran kerja analyst dipetakan dengan bersih ke dalamnya. AI mengendalikan Hasilkan (Generate) (merangka SQL, merangka dokumen, merangka kemas kini Slack) dan membantu Analisis (Analyze) (ringkasan anomali, cadangan penghalusan). Manusia memiliki Ingest (semantik data, apa yang setiap lajur sebenarnya bermakna dalam perniagaan ini), Ramalan (Predict) (tafsiran sebab metrik bergerak), dan Laksana (Execute) (menghantar jawapan kepada pihak berkepentingan dengan keyakinan dan jejak logik yang boleh dipertahankan).

Itulah versi satu perenggan. Intinya ialah bahagian kerja yang memerlukan kepercayaan tinggi dan konteks perniagaan yang mendalam kekal bersama manusia untuk jangka masa yang lama. Bahagian mekanikal diserahkan kepada AI. Kerjaya anda dibina atas separuh yang pertama.

Perangkap biasa

Beberapa perangkap yang saya lihat analyst terjatuh ke dalamnya, mengikut kekerapan kasar:

• Membenarkan pihak berkepentingan untuk layan diri (self-serve) dengan kopilot BI dan menganggap semakan analyst sebagai pilihan. Kopilot menghantar nombor yang silap; analyst tetap dipersalahkan.
• Menampal skema pengeluaran dengan PII ke dalam alat AI pihak ketiga yang tidak mempunyai DPA. Ini adalah kesalahan yang boleh menyebabkan pemecatan di kebanyakan syarikat. Semak sebelum anda menampal.
• Menggunakan AI untuk menulis SQL dalam dialek yang anda tidak boleh baca dengan lancar. ARRAY_AGG BigQuery bukan Postgres, QUALIFY Snowflake bukan Redshift. Anda tidak boleh menyemak apa yang anda tidak boleh baca.
• Melangkau langkah "bandingkan dengan hasil yang diketahui" kerana pertanyaan itu "kelihatan betul." Beginilah cara pertumbuhan hasil 14% dihantar apabila pertumbuhan sebenar hanya 3%.
• Menganggap keyakinan kopilot BI sebagai bukti ketepatan. Ia akan berkata "hasil meningkat 14%" dengan nada yang sama sama ada pertanyaan itu betul atau tersilap secara bencana.

Templat dan alat

Tiga artifak untuk dibina dalam 30 hari pertama anda. Simpan dalam repo analitik pasukan anda.

1. forbidden_patterns.md: mulakan dengan sepuluh entri dari gudang data anda. Cantuman sebenar yang pernah membakar seseorang. Tambah satu setiap bulan apabila anda menemuinya.
2. Senarai semak semakan SQL: lapan perkara untuk dijalankan pada mana-mana pertanyaan yang dirangka AI sebelum cantum: semakan hasil yang diketahui, kesahihan bilangan baris, semakan penggandaan baris, semakan penapis tarikh, semakan pengendalian NULL, semakan logik perniagaan (adakah "aktif" bermakna apa yang kita maksudkan?), semakan tadbir urus (adakah jadual ini terkini?), semakan kebolehbacaan.
3. Arahan persediaan temu bual pihak berkepentingan: arahan Claude tersimpan yang anda tampal utas Slack ke dalamnya, mendapat balik lima soalan penjelasan. Perhalusi setiap bulan.
4. ai-usage.md: dasar pasukan anda. Dokumen hidup. Semak setiap suku tahun.

Mengukur kejayaan

Anda akan tahu ia berjaya apabila tiga perkara adalah benar. Anda menghantar lebih pantas pada bahagian dokumentasi dan penghalusan, dan anda boleh menunjuk kepada hasil kerja tertentu yang tidak wujud sebelum ini. Pihak berkepentingan mempercayai nombor anda lebih, bukan kurang, kerana anda secara rutin menangkap kesilapan kopilot BI sebelum ia mendarat di Slack. Dan anda boleh menyatakan, dalam satu ayat per pertanyaan, mengapa draf pertama AI adalah silap.

Ayat terakhir itulah yang menjadikan anda lebih senior pada tahun 2026, bukan lebih boleh diganti. "Ia mencantumkan menggunakan e-mel dan bukannya customer_id." "Ia terlepas penapis bayaran balik." "Ia menggunakan jadual hasil yang lapuk." Setiap ayat adalah sebahagian daripada pertimbangan khusus gudang data yang tidak dimiliki oleh AI dan tidak boleh dimilikinya tanpa anda. Itulah benteng pertahanan. Binalah.

Tugas sebenar bukan lagi menaip pertanyaan. Tugas sebenar ialah memiliki jawapan. AI menulisnya, anda mengesahkannya, anda memilikinya. Itulah garisannya. Itulah keseluruhan artikel ini.

Ketahui Lebih Lanjut

• Sehari dalam Kehidupan Data Analyst
• 30/60/90 Hari Pertama Anda sebagai Data Analyst Baharu
• Templat Penerangan Kerja Data Analyst
• ACE Framework