Kantor AI Lokal: Panduan Karyawan Virtual 2D, Aset, dan Demo Interaktif

Penulis Tumbas.in 18 Oct 2026 36 views

Kantor AI Lokal: Panduan Karyawan Virtual 2D, Aset, dan Demo Interaktif

Ilustrasi kantor AI lokal dengan empat karyawan virtual, meja kerja, dan laptop
Ilustrasi konseptual dibuat dengan ImageGen. Tampilan aplikasi sebenarnya ditunjukkan pada screenshot demo di dalam artikel.

Kantor AI lokal adalah rancangan aplikasi yang menampilkan asisten AI sebagai karyawan virtual dengan peran berbeda, sementara pemrosesan tugas dijalankan pada komputer sendiri. Pengguna memilih karyawan, memberikan brief, melihat status pekerjaan, dan meninjau hasil melalui antarmuka kantor. Tampilan visualnya dapat berupa karakter 2D isometrik, bubble chat, meja kerja, dan panel riwayat.

Proyek Ruang Kerja memperlihatkan bentuk awal pengalaman tersebut. Ada empat karakter, empat divisi, furnitur kantor, galeri aset, serta interaksi dasar yang bisa dicoba melalui browser. Rancangan pengembangan berikutnya adalah menghubungkan antarmuka ini dengan model lokal dan sistem pengelolaan tugas.

Status yang perlu diketahui: demo versi pertama masih berupa simulasi visual. Tugas contoh tidak dikirim ke model AI, riwayat belum tersimpan permanen, dan animasi tidak membuktikan bahwa AI sedang mengerjakan sesuatu. Artikel ini menjelaskan apa yang sudah tersedia, bagaimana mencobanya, serta langkah membangun versi lokal yang benar-benar memproses pekerjaan.

Buka Demo Kantor AI

Tautan tersebut merupakan alamat penempatan demo yang disiapkan pengelola. Apabila halaman belum tersedia, berkas demo perlu diunggah terlebih dahulu sesuai petunjuk hosting pada artikel ini.

1. Apa yang dimaksud dengan karyawan AI dalam kantor virtual?

Istilah karyawan AI pada proyek ini berarti profil asisten dengan tanggung jawab, instruksi, dokumen, dan izin alat tertentu. Nama serta karakter membantu pengguna membedakan peran. Sistem tetap berupa perangkat lunak yang memerlukan arahan dan pemeriksaan manusia.

Contohnya, asisten riset diberi instruksi untuk mengambil informasi dari dokumen yang dipilih. Asisten penulis menerima ringkasan tersebut untuk menyusun draf. Asisten pemeriksa menandai bagian yang belum memiliki dasar. Koordinator membantu mengatur urutan pekerjaan dan mengumpulkan hasil.

Empat peran tidak harus menggunakan empat model yang dimuat bersamaan. Dalam rancangan untuk laptop dengan sumber daya terbatas, satu model dapat dipakai bergantian. Aplikasi menyusun konteks yang sesuai ketika giliran suatu peran tiba. Perbedaan tugas berasal dari instruksi dan bahan yang diterima, bukan semata-mata dari nama avatarnya.

Pemisahan ini penting karena tampilan kantor dapat membuat proses terasa sangat hidup. Semua karakter bisa bergerak ketika hanya satu permintaan model yang aktif. Status yang benar harus menjelaskan apakah seorang agen sedang mengantre, membaca berkas melalui program, menjalankan inferensi, atau menunggu keputusan pengguna.

2. Apa saja yang sudah tersedia dalam demo Ruang Kerja?

Demo pertama berfokus pada antarmuka dan pemakaian aset. Pengunjung dapat melihat susunan kantor, memilih anggota tim, membuka tab panel, mencoba menu aksi, dan memasukkan brief contoh. Galeri membantu melihat gambar yang digunakan tanpa harus membuka sprite sheet satu per satu.

Bagian Tersedia pada demo Masih perlu dikembangkan
Kantor visual Ruangan isometrik dan objek kantor Editor layout dan navigasi karakter
Karyawan Empat karakter dengan pose berbeda Hubungan status dengan pekerjaan nyata
Menu aksi Tombol tugas contoh, riwayat, dan aset Validasi aksi berdasarkan status backend
Bubble chat Pesan contoh di dekat karakter Pembaruan berdasarkan event pekerjaan
Brief Form dan penyimpanan sementara dalam sesi Database, antrean, dan pemrosesan model
Riwayat Aktivitas contoh selama sesi Riwayat permanen dan versi hasil
Model lokal Belum tersambung Integrasi runtime dan pengujian perangkat

Pada pemeriksaan lingkungan pengembangan, galeri menampilkan 118 entri visual dan alur penyimpanan brief contoh berhasil dijalankan. Tidak muncul error JavaScript pada pemeriksaan tersebut. Hasil ini terbatas pada demo dan lingkungan pengembangan, bukan pengukuran performa laptop pengguna atau jaminan kompatibilitas semua browser.

Screenshot demo Ruang Kerja dengan empat karyawan dan panel tugas di sisi kanan
Screenshot demo yang dirender di browser. Status dan pekerjaan yang terlihat merupakan contoh.

3. Empat karyawan dan pembagian divisinya

Versi awal menggunakan empat nama yang mudah dibedakan: Raka, Sari, Bima, dan Naya. Nama dan tampilannya dapat diganti saat pengembangan. Yang perlu dipertahankan adalah kejelasan tanggung jawab dan keluaran setiap peran.

Nama Divisi Peran yang direncanakan Contoh hasil
Raka Koordinasi & Operasional Menerima brief, membagi pekerjaan, merangkum status Daftar tugas dan ringkasan progres
Sari Riset & Administrasi Membaca dokumen dan menyusun bahan Ringkasan sumber dan daftar fakta
Bima Konten & Marketing Mengubah bahan menjadi draf komunikasi Artikel, caption, dan materi promosi
Naya Pemeriksaan Kualitas Memeriksa kesesuaian hasil dengan brief Catatan revisi dan daftar kekurangan

Raka: memastikan pekerjaan memiliki arah

Raka menjadi titik masuk ketika pengguna memiliki pekerjaan yang melibatkan beberapa tahap. Brief “buat artikel promosi” masih terlalu luas. Koordinator perlu mengidentifikasi produk, pembaca, panjang tulisan, sumber, serta batas klaim. Bila informasi penting belum ada, hasil yang benar adalah permintaan klarifikasi, bukan mengarang detail.

Sari: menyiapkan bahan yang dapat dilacak

Sari dirancang untuk mengolah dokumen yang diberikan pengguna. Hasilnya sebaiknya mencantumkan asal informasi, bagian yang relevan, dan hal yang belum ditemukan. Dalam mode offline, Sari bekerja dengan berkas lokal. Pencarian internet harus menjadi kemampuan terpisah yang diaktifkan secara sadar.

Bima: menyusun draf berdasarkan bahan

Bima mengubah brief dan bahan menjadi tulisan. Contohnya artikel UMKM, deskripsi produk, atau ringkasan kegiatan. Draf tetap perlu diperiksa, khususnya untuk angka, nama, tanggal, harga, dan janji promosi. Antarmuka sebaiknya menyediakan tombol revisi terhadap versi tertentu agar perubahan dapat dilacak.

Naya: membantu pemeriksaan, bukan memberi jaminan

Naya memeriksa apakah draf memenuhi instruksi dan konsisten dengan bahan. Pemeriksaan oleh agen lain bisa berguna, tetapi tidak otomatis membuat informasi benar. Apalagi bila penulis dan pemeriksa memakai model dasar yang sama, keduanya masih dapat mengulangi kesalahan serupa. Keputusan publikasi tetap berada pada pengguna.

4. Mengapa memilih tampilan 2D isometrik terlebih dahulu?

Tampilan isometrik menggambarkan ruang dari sudut miring sehingga lantai, meja, dan karakter terlihat memiliki kedalaman. Dalam paket ini, gambar yang tampil seperti render 3D sebenarnya dipakai sebagai aset 2D. Tidak ada model GLB, rig tulang, atau kamera bebas yang dapat mengelilingi setiap objek.

Keputusan memulai dari 2D merupakan pilihan desain untuk membatasi kompleksitas. Pengembang dapat memusatkan perhatian pada penugasan, status, laporan, dan penyimpanan data. Penempatan sprite juga lebih mudah diperiksa sebelum menambahkan pencahayaan dinamis atau gerakan kamera.

Pertimbangan Pendekatan 2D awal Opsi 3D lanjutan
Karakter Gambar pose dan frame Model, rig, dan klip animasi
Kamera Sudut tetap Dapat dikembangkan menjadi kamera bergerak
Aset PNG dan SVG Mesh, material, tekstur, dan animasi
Penyuntingan ruang Menempatkan gambar pada koordinat Menempatkan objek dalam ruang tiga dimensi
Fokus validasi Keterbacaan dan workflow Workflow ditambah beban render 3D

2D tidak otomatis ringan dalam semua implementasi. Tekstur terlalu besar, efek berlebihan, atau pembaruan antarmuka yang tidak terkendali tetap dapat membebani perangkat. Keberhasilan harus dilihat saat tampilan kantor dan model lokal berjalan bersamaan, bukan ketika demo grafis diuji sendirian.

5. Aset karyawan: pose, arah, dan animasi yang tersedia

Setiap karakter memiliki 20 pose atau frame. Enam belas berasal dari empat arah untuk empat baris dasar: diam, langkah berjalan pertama, langkah berjalan kedua, dan meminta perhatian. Empat lainnya adalah pose mengetik, membaca, selesai, dan gagal yang disiapkan untuk satu arah tampilan.

Jumlah seluruh karakter adalah 80 pose/frame, bukan 80 orang. Frame tersebut disimpan dalam atlas atau sprite sheet, yaitu satu gambar besar yang memuat beberapa bagian kecil. Aplikasi membaca koordinat bagian yang diperlukan dari manifest, lalu menampilkannya sebagai karakter.

Animasi berjalan versi pertama menggunakan dua frame per arah. Geraknya cukup untuk memperlihatkan konsep pada demo, tetapi masih memerlukan penyempurnaan jika ingin gerakan lebih halus. Pose mengetik dan membaca masih gambar tunggal. Untuk membuat tangan benar-benar mengetik, diperlukan frame tambahan atau pendekatan animasi lain.

Atlas empat karakter kantor dengan pose mengetik, membaca, selesai, dan gagal
Aset karakter dibuat dengan ImageGen. Setiap baris menampilkan satu karakter; pose aktivitas pada atlas ini masih statis.

Aset generatif perlu melalui pemeriksaan konsistensi. Ukuran kepala, posisi telapak kaki, arah pandang, dan tinggi tubuh dapat sedikit berubah antarpose. Sebelum dipakai dalam produk, periksa perpindahan frame pada ukuran tampil sebenarnya. Karakter yang terlihat bagus sebagai gambar besar belum tentu memiliki baseline stabil saat berjalan.

6. Aset ruangan, furnitur, dan elemen antarmuka

Paket visual terdiri dari tujuh PNG utama, delapan tile SVG modular, dan tiga belas elemen UI berbentuk SVG. Tujuh PNG tersebut mencakup empat atlas karakter, satu atlas aktivitas, satu atlas furnitur, dan satu gambar ruangan.

Atlas furnitur memuat 16 jenis objek: meja kerja, kursi, komputer, laptop, lemari arsip, rak buku, papan tugas, tanaman tinggi, sofa, meja kopi, dispenser, lampu lantai, server, baki dokumen, meja rapat, dan tanaman berdaun lebar. Sebagian gambar merupakan kelompok objek, misalnya monitor beserta keyboard atau meja rapat beserta kursinya.

Enam belas aset furnitur kantor isometrik termasuk meja, komputer, rak, sofa, dan server
Atlas furnitur ImageGen dengan latar transparan untuk penempatan objek secara terpisah.

Ruangan raster merupakan satu gambar yang menggabungkan lantai dan dinding belakang. Ini cocok untuk contoh kantor dengan susunan tetap. Jika diperlukan editor ruangan, tersedia tile geometri untuk lantai, dinding, jendela, pintu, dan karpet. Tile SVG dapat diedit, tetapi teksturnya tidak identik dengan ruangan raster.

Jumlah 118 entri pada galeri berasal dari 80 frame karyawan, 16 objek furnitur, satu ruangan, delapan tile, dan tiga belas elemen UI. Angka itu merupakan jumlah bagian visual yang dapat dipakai, bukan jumlah berkas PNG terpisah.

7. Cara mencoba demo dari laptop dan HP

Buka demo kantor AI di Tumbas.in setelah pengelola mengunggah berkasnya. Versi online memudahkan pengunjung melihat tampilan tanpa mengekstrak paket aset. Pada ponsel, membuka tautan melalui browser seperti Chrome umumnya lebih praktis daripada membuka HTML melalui penampil berkas.

Urutan mencoba yang disarankan adalah sebagai berikut:

  1. Buka tab Kantor untuk melihat ruangan dan daftar anggota tim.
  2. Pilih Raka, Sari, Bima, atau Naya melalui tombol nama. Pada desktop, karakter di dalam ruangan juga dapat dipilih.
  3. Perhatikan nama, divisi, dan status contoh pada panel detail.
  4. Buka tab Tugas, Riwayat, dan Aset untuk membandingkan informasi yang ditampilkan.
  5. Pilih Beri tugas contoh, tuliskan brief pendek, lalu simpan.
  6. Gunakan Semua aksi untuk membuka menu tanpa klik kanan.
  7. Coba Jeda gerak jika ingin memeriksa gambar tanpa animasi.
  8. Buka Galeri aset untuk melihat susunan komponen kantor.

Brief yang disimpan hanya hidup dalam sesi demo. Memuat ulang halaman akan mengembalikan contoh awal. Jangan memasukkan dokumen rahasia atau menganggap form tersebut sudah menjadi tempat penyimpanan pekerjaan.

Tampilan vertikal demo kantor AI di ponsel dengan tombol nama karyawan dan panel tugas
Screenshot viewport ponsel dari lingkungan pengembangan. Tombol nama dan Semua aksi menjadi alternatif interaksi pada layar sentuh.

Untuk akses keyboard, tombol nama dapat dipilih dengan Tab dan diaktifkan dengan Enter. Menu pada tombol anggota tim dapat dibuka melalui Shift+F10. Akses alternatif semacam ini perlu dipertahankan ketika backend ditambahkan, sehingga fitur inti tidak bergantung pada klik kanan atau ketepatan menyentuh karakter kecil.

8. Bubble chat dan menu aksi: apa yang seharusnya ditampilkan?

Bubble chat berfungsi sebagai ringkasan pendek. Isi yang berguna adalah tahap pekerjaan, kebutuhan input, atau pemberitahuan hasil. Laporan panjang, sumber, dan catatan revisi sebaiknya ditempatkan pada panel detail agar pengguna tidak perlu membaca paragraf kecil di atas kepala karakter.

Contoh pesan yang jelas adalah “Menunggu giliran”, “Dokumen belum dipilih”, atau “Draf siap ditinjau”. Dalam aplikasi yang sudah terhubung, setiap pesan harus memiliki dasar dari status backend. Hindari persentase buatan yang bertambah karena timer, sementara model belum memulai pekerjaan.

Menu aksi juga perlu menyesuaikan kondisi. Tugas yang sudah selesai dapat menawarkan lihat hasil atau revisi. Tugas gagal dapat menawarkan coba lagi dengan penjelasan. Pembatalan perlu menampilkan “Pembatalan diminta” sampai proses benar-benar mengonfirmasi penghentian. Menyembunyikan animasi tidak sama dengan menghentikan pekerjaan.

Screenshot menu aksi pada karyawan Bima yang memuat tugas contoh, riwayat, aset, dan perubahan status demo
Menu aksi pada demo. Tombol perubahan status masih untuk simulasi, bukan kontrol worker AI.

Jika implementasi berikutnya memakai PixiJS, dokumentasinya menyediakan sistem interaksi pointer dan pengaturan area klik objek. Ini membantu membuat karakter bergerak tetap dapat dipilih. Namun, demo awal yang dibahas di sini memakai Canvas 2D dan elemen HTML biasa, sehingga tidak perlu mengklaim bahwa PixiJS sudah terpasang. Lihat dokumentasi interaksi PixiJS untuk opsi pengembangan tersebut.

9. Contoh alur kerja nyata yang akan dibangun

Bayangkan pemilik UMKM ingin menyiapkan artikel tentang produk baru. Ia memiliki dokumen spesifikasi dan catatan promosi yang sudah disetujui. Alur berikut merupakan contoh rancangan, belum dijalankan otomatis oleh demo.

Raka menerima brief dan mengubahnya menjadi pekerjaan dengan keluaran yang jelas. Sari membaca dokumen, merangkum fakta, serta mencatat bagian yang tidak ditemukan. Bima menyusun draf berdasarkan ringkasan dan tujuan komunikasi. Naya memeriksa apakah angka, klaim, dan gaya tulisan sesuai bahan. Pemilik meninjau versi akhir sebelum menerbitkan.

Contoh brief yang lebih mudah diproses adalah: “Susun draf artikel 800 kata untuk calon pembeli pertama. Gunakan hanya dokumen produk yang saya pilih. Jangan menambahkan harga, sertifikasi, atau testimoni. Tandai informasi yang masih kurang. Hasilkan judul, pembukaan, isi, dan ajakan menghubungi toko.”

Contoh tersebut memberikan batas yang dapat diperiksa. Sebaliknya, perintah “buat artikel terbaik yang pasti viral” tidak menyediakan ukuran keberhasilan yang jelas. Kualitas instruksi, kecukupan bahan, dan proses review lebih menentukan daripada banyaknya karakter yang ditampilkan.

Setiap tahap sebaiknya menghasilkan artefak tersimpan. Ringkasan Sari, draf Bima, catatan Naya, serta persetujuan pemilik memiliki identitas dan versi sendiri. Dengan begitu, revisi dapat ditelusuri tanpa menghapus hasil sebelumnya.

10. Arsitektur lokal yang direncanakan

Versi penuh memerlukan beberapa komponen dengan tugas terpisah. Antarmuka menangani interaksi manusia. Backend mengelola aturan. Antrean mengatur giliran. Runtime model menjalankan inferensi. Penyimpanan mencatat pekerjaan dan hasil.

Komponen Tanggung jawab dalam rancangan
Antarmuka kantor Memilih agen, menulis brief, membuka hasil
Backend lokal Memvalidasi permintaan, izin, dan status
Antrean pekerjaan Mengatur satu pekerjaan inferensi aktif
Runtime model Menjalankan model yang tersimpan lokal
Database Menyimpan tugas, riwayat, dan versi
Folder dokumen Menyimpan sumber serta hasil yang disetujui
Kanal pembaruan status Mengirim perubahan keadaan ke browser

Pilihan awal dalam PRD adalah backend Python, database SQLite, dan runtime Ollama. Ini merupakan rancangan implementasi, bukan komponen yang otomatis hadir setelah ZIP aset diekstrak. Demo HTML tidak menyertakan backend tersebut.

Alur pemrosesan yang diinginkan adalah: pengguna mengirim brief, backend menyimpan tugas, antrean memberikan giliran, worker memanggil model, hasil divalidasi, lalu status diperbarui pada panel. Animasi mengikuti perubahan tersebut. Gerakan menuju meja tidak boleh menjadi syarat backend mulai bekerja.

Jika browser ditutup, perilakunya harus jelas. Dalam rancangan yang worker-nya berjalan sebagai proses terpisah, menutup tab tidak otomatis menghentikan tugas. Saat dibuka kembali, antarmuka mengambil status terbaru dari penyimpanan, bukan memutar ulang timer seolah pekerjaan baru dimulai.

11. Apakah laptop RTX 3050 4 GB dan RAM 16 GB dapat digunakan?

Perangkat acuan proyek ini adalah Intel Core i5 generasi ke-12, RTX 3050 dengan VRAM 4 GB, RAM 16 GB, serta ruang HDD kosong sekitar 150 GB. Spesifikasi itu menjadi dasar membatasi lingkup awal. Belum ada hasil benchmark inferensi proyek pada laptop tersebut, sehingga artikel ini tidak menjanjikan kecepatan token atau waktu penyelesaian tertentu.

Pendekatan awal adalah mencoba satu model kecil terkuantisasi dengan konteks terbatas dan satu antrean inferensi. Kandidat harus diuji memakai tugas yang benar-benar akan dipakai, misalnya merangkum dokumen Indonesia atau menyusun draf singkat. Nama model dan konfigurasi akhir ditentukan setelah mengukur penggunaan memori serta kualitas hasil.

Sumber daya Hal yang perlu diperhatikan
VRAM 4 GB Model, konteks, dan render dapat bersaing untuk memori GPU
RAM 16 GB Sistem operasi, browser, backend, dan model berbagi memori
CPU i5 generasi ke-12 Performa dipengaruhi varian CPU, daya, suhu, dan beban lain
HDD Pemuatan berkas dan model perlu diukur terpisah dari inferensi
Ruang kosong 150 GB Sisakan ruang kerja; hindari mengunduh banyak model sekaligus

Lakukan perbandingan tampilan daftar, kantor tanpa animasi, dan kantor dengan animasi. Jalankan tugas yang sama pada ketiganya. Catat respons tombol, pemakaian RAM, indikasi kekurangan memori, waktu pemuatan model, serta waktu menghasilkan keluaran. Pilihan 2D seharusnya dibuktikan lewat pengukuran semacam ini.

12. Apa pengaruh Wi-Fi 200 Mbps dan apakah bisa tanpa API berbayar?

Koneksi internet terutama membantu mengunduh perangkat lunak, model, pembaruan, dan bahan daring. Kecepatan 200 Mbps setara dengan batas teoritis sekitar 25 MB per detik sebelum overhead. Kecepatan unduh nyata tetap dipengaruhi server sumber, jaringan, serta perangkat penyimpanan.

Setelah model dan dependensi tersedia secara lokal, kecepatan internet bukan penentu utama inferensi offline. Kualitas GPU, RAM, konfigurasi model, panjang konteks, dan beban sistem lebih langsung memengaruhi proses di komputer. Menambah paket internet tidak menambah VRAM laptop.

Tidak memakai API AI berbayar tetap memungkinkan sebagai rancangan runtime lokal. Namun, API sendiri hanya berarti antarmuka komunikasi antarprogram. Backend dapat berkomunikasi dengan layanan model di komputer yang sama melalui API lokal tanpa membeli layanan cloud. Biaya listrik, perangkat, penyimpanan, atau hosting demo tetap merupakan hal terpisah.

Ollama mendokumentasikan mode lokal serta opsi menonaktifkan fitur cloud dengan OLLAMA_NO_CLOUD=1, kemudian me-restart aplikasi. Dokumentasinya juga menjelaskan penggunaan ollama ps untuk melihat model yang dimuat dan pembagian CPU/GPU. Rujuk FAQ Ollama ketika mengatur lingkungan. Setelah persiapan selesai, uji alur kerja dengan koneksi internet diputus untuk memastikan dependensi yang diperlukan benar-benar tersedia lokal.

Demo online membutuhkan koneksi untuk memuat halaman. Itu tidak berarti versi lokal harus selalu online. Keduanya melayani tujuan berbeda: demo untuk memperlihatkan pengalaman, aplikasi lokal untuk memproses tugas pada perangkat pemilik.

13. Tahapan menghubungkan GUI dengan model lokal

Menyambungkan model bukan sekadar mengganti teks bubble. Pengembangan perlu menghasilkan pekerjaan yang tersimpan, dapat dipantau, dan dapat diperiksa. Urutan berikut membantu membangun fungsi inti sebelum memperluas dekorasi.

Tahap pertama: jalankan runtime model secara terpisah

Pasang Ollama mengikuti panduan Windows resmi. Dokumentasi menjelaskan bahwa aplikasi berjalan di latar belakang dan menyediakan layanan pada http://localhost:11434. Siapkan model lokal yang sudah dipilih untuk pengujian. Pastikan respons dapat dihasilkan tanpa GUI kantor terlebih dahulu, sehingga masalah model tidak tercampur dengan masalah tampilan.

Tahap kedua: bangun satu alur tugas

Mulai dari satu jenis tugas, misalnya ringkasan teks. Form harus mengirimkan brief dan identitas peran ke backend. Backend membuat identitas tugas, menyimpan status antre, kemudian mengirimkannya ke worker. Antarmuka menampilkan hasil berdasarkan respons yang tersimpan, bukan berdasarkan jeda waktu yang ditentukan di JavaScript.

Tahap ketiga: tambahkan profil dan bahan

Pisahkan instruksi setiap peran dari brief pengguna. Tentukan jenis dokumen yang boleh dibaca dan berapa banyak konteks yang diberikan. Gunakan bahan yang diperlukan untuk tugas tersebut. Mengirim seluruh arsip kantor pada setiap permintaan akan menyulitkan kontrol kualitas dan penggunaan memori.

Tahap keempat: simpan riwayat dan versi

Simpan waktu dibuat, peran penerima, brief, status, hasil, serta sumber yang digunakan. Revisi membuat versi atau percobaan baru. Uji refresh halaman dan restart aplikasi. Hasil yang sudah selesai harus tetap dapat ditemukan, termasuk ketika animasi dimatikan.

Tahap kelima: hubungkan status ke visual

Baru setelah alur tersebut bekerja, petakan status ke karakter. Antre berarti menunggu. Membaca berarti tahap pengolahan dokumen. Inferensi berarti runtime benar-benar sedang menjalankan permintaan. Selesai berarti hasil tersedia. Koneksi UI terputus harus ditampilkan sebagai masalah sinkronisasi, bukan dianggap pekerjaan gagal.

Tahap keenam: uji alur empat peran

Gunakan satu tugas contoh yang sama dari awal sampai hasil akhir. Periksa apakah sumber Sari terbawa ke draf Bima dan catatan Naya tersimpan. Pastikan koordinator tidak membuat rangkaian tugas tanpa batas. Batasi jumlah revisi otomatis, lalu minta pengguna memutuskan bila hasil belum memenuhi kriteria.

14. Cara mengunggah demo ke Tumbas.in

Alamat yang ditetapkan untuk preview adalah https://tumbas.in/demo/kantor-ai/index.html. Untuk mencapai alamat itu, berkas demo harus berada di folder demo/kantor-ai pada document root situs. Nama document root bergantung pada konfigurasi hosting; jangan menganggap semua server menggunakan direktori yang sama.

Gunakan paket aset/demo yang sudah dibuat sebelumnya, bukan ZIP artikel ini. Paket artikel berisi tulisan dan gambar editorial, sedangkan demo memerlukan HTML, CSS, JavaScript, dan gambar sumbernya sendiri.

Lokasi relatif dari folder kantor-ai Fungsi
index.html Halaman utama demo
style.css Tata letak dan tampilan responsif
app.js Interaksi dan rendering
data.js Data aset yang dibaca langsung oleh demo
assets/ PNG, tile, dan ikon yang digunakan

Langkah penempatannya:

  1. Ekstrak paket demo pada komputer atau melalui pengelola berkas hosting.
  2. Buka document root domain Tumbas.in yang benar.
  3. Buat folder demo, lalu folder kantor-ai di dalamnya jika belum ada.
  4. Salin isi folder demo ke kantor-ai. Hindari menambahkan satu tingkat folder ekstra secara tidak sengaja.
  5. Pastikan index.html, style.css, app.js, dan data.js berada pada tingkat yang sama.
  6. Salin seluruh folder assets tanpa mengubah nama atau susunannya.
  7. Buka URL tujuan melalui browser dan periksa tampilan kantor serta galeri.
  8. Coba di HP menggunakan koneksi biasa, lalu uji tombol nama dan Semua aksi.

Demo memakai referensi relatif sehingga struktur direktori perlu dipertahankan. Prinsip hubungan antarfile situs dijelaskan dalam panduan pengelolaan berkas MDN. Jangan hanya mengunggah HTML, karena browser masih memerlukan stylesheet, skrip, serta gambar yang dirujuk halaman.

Petunjuk ini menjelaskan proses yang harus dilakukan pengelola. Artikel tidak menyatakan bahwa berkas sudah diunggah ke server Tumbas.in. Status URL tujuan perlu diperiksa kembali setelah proses tersebut selesai.

15. Mengatasi tampilan polos, gambar hilang, dan masalah lain

Tampilan yang hanya berisi teks, tombol standar, dan ikon gambar rusak biasanya menunjukkan bahwa sebagian berkas pendukung tidak berhasil dimuat. Gejalanya berbeda dengan model AI yang gagal menjawab. Pada tahap demo visual, periksa pemuatan aset terlebih dahulu.

Gejala Kemungkinan yang perlu diperiksa Tindakan awal
Halaman tanpa gaya style.css tidak ditemukan atau tidak terbaca Periksa lokasi dan URL stylesheet
Nama tampil tetapi karakter hilang PNG atau data aset gagal dimuat Pastikan folder assets lengkap
Tombol tidak merespons Skrip tidak terbaca atau terjadi error Periksa app.js, data.js, dan console
Berfungsi di komputer, gagal dari ZIP HP Penampil berkas tidak memuat file relatif Ekstrak seluruh paket atau gunakan URL hosting
URL menjadi lebih panjang dari rencana Folder paket tersalin sebagai lapisan tambahan Pindahkan isi ke folder tujuan yang tepat
Perubahan belum terlihat Browser masih memakai cache lama Muat ulang dan periksa berkas yang diunggah
Demo terbuka, AI tidak menjawab Backend memang belum ada pada demo Lanjutkan integrasi, bukan menunggu animasi

Pada server yang membedakan huruf besar dan kecil, Assets dan assets dapat menjadi lokasi berbeda. Pertahankan penamaan asli. Pastikan pula bahwa URL berkas JavaScript tidak justru mengembalikan halaman HTML dari aturan routing situs.

Saat menguji, periksa satu lapisan pada satu waktu. Jika CSS tidak terbaca, selesaikan itu sebelum menilai skala karakter. Jika gambar sudah tampil tetapi tombol tidak bekerja, periksa JavaScript. Pendekatan ini membuat masalah lebih cepat dilokalisasi daripada mengganti seluruh paket tanpa mengetahui penyebabnya.

16. Plugin dan alat apa yang benar-benar diperlukan?

Plugin ChatGPT dapat membantu proses desain atau pengembangan, tetapi bukan syarat aplikasi lokal berjalan. GitHub dapat dipakai untuk pengelolaan kode, Figma untuk perancangan layar, dan ImageGen untuk konsep visual. Pemeriksaan dokumentasi dapat dibantu alat pencarian saat tahap riset.

Aset yang sudah dihasilkan kemudian menjadi berkas biasa di dalam proyek. Demo tidak perlu memanggil ImageGen ketika menampilkan karakter. Begitu pula, aplikasi lokal tidak memerlukan koneksi ke plugin desain untuk menggambar meja atau membuka menu.

Kebutuhan Alat atau komponen yang relevan Dipakai kapan
Menyusun kebutuhan Dokumen PRD Sebelum dan selama pembangunan
Mendesain layar Figma atau editor desain pilihan Tahap desain
Membuat konsep aset ImageGen dan editor aset Tahap produksi visual
Mengelola perubahan Git dan layanan repository pilihan Tahap pengembangan
Menjalankan tampilan Browser dan berkas aplikasi Saat demo/aplikasi digunakan
Menjalankan AI lokal Runtime model dan model terunduh Setelah integrasi backend

Tidak ada kebutuhan API key OpenAI pada rancangan runtime lokal ini. Jika kemudian memilih layanan cloud, itu merupakan perubahan arsitektur dan biaya yang harus dijelaskan tersendiri. Jangan menganggap semua kemampuan plugin atau layanan pihak ketiga otomatis gratis hanya karena demo tidak membutuhkan API berbayar.

Screenshot galeri aset demo dengan kartu furnitur dan komponen kantor
Galeri aset membantu memeriksa komponen visual sebelum digunakan dalam aplikasi.

17. Keamanan, kualitas laporan, dan batas otomatisasi

Menjalankan model lokal memberi kesempatan mengendalikan lokasi pemrosesan, tetapi keamanan tetap bergantung pada desain aplikasi. Peran perlu memiliki akses terbatas pada folder dan alat yang diperlukan. Instruksi di dalam dokumen harus diperlakukan sebagai isi bahan, bukan perintah yang boleh mengubah izin sistem.

Untuk versi awal, batasi aksi pada membaca dokumen yang dipilih dan menulis hasil ke folder keluaran. Penghapusan berkas, perubahan sistem, pengiriman pesan, atau publikasi membutuhkan kontrol terpisah. Antarmuka harus menjelaskan apa yang akan terjadi sebelum pengguna menyetujui tindakan yang berdampak di luar aplikasi.

Riwayat sebaiknya menyimpan informasi yang dapat diperiksa: brief, sumber, tahapan, hasil, revisi, dan persetujuan. Pengguna tidak memerlukan pemikiran internal model untuk memahami progres. Pesan seperti “dua dokumen selesai dibaca” lebih berguna bila berasal dari proses yang benar-benar tercatat.

Hosting demo juga tidak otomatis menghubungkannya dengan laptop. localhost pada perangkat pengunjung menunjuk perangkat pengunjung itu sendiri. Jangan membuka layanan model ke internet hanya agar contoh visual terlihat aktif. Akses lintas perangkat membutuhkan rancangan autentikasi, jaringan, dan izin yang terpisah dari hosting halaman statis.

Keluaran AI tetap harus diperiksa sesuai tujuan penggunaannya. Untuk artikel, periksa fakta dan sumber. Untuk administrasi, cocokkan data dengan dokumen asli. Untuk keputusan penting, gunakan peninjauan manusia dengan pengetahuan yang sesuai. Memiliki agen pemeriksa tidak menghapus kebutuhan tersebut.

18. Roadmap dari demo menuju kantor AI yang dapat dipakai

Roadmap yang paling mudah dievaluasi dimulai dari alur kecil dengan hasil nyata. Jangan menambah sepuluh divisi ketika satu tugas belum bisa diselesaikan dan disimpan dengan benar. Setiap tahap perlu memiliki kriteria selesai yang dapat diamati.

Tahap Fokus Bukti selesai yang dicari
1 Demo dan aset Tampilan serta interaksi dasar dapat dicoba
2 Satu tugas lokal Brief menghasilkan keluaran dari model lokal
3 Penyimpanan Hasil bertahan setelah refresh dan restart
4 Empat peran Bahan dan hasil berpindah dengan jejak yang jelas
5 Review dan pembatalan Persetujuan serta status batal mengikuti backend
6 Optimasi perangkat Beban model dan UI diukur bersama
7 Perluasan visual Animasi atau 3D ditambahkan setelah fungsi stabil

Prioritas pertama setelah demo adalah menghubungkan satu workflow yang bermanfaat, misalnya ringkasan dokumen. Setelah itu, barulah menambah penulisan artikel atau pemeriksaan draf. Ukur berapa sering hasil perlu diperbaiki, apakah pengguna memahami status, dan apakah riwayat mudah ditemukan.

Perluasan ke 3D layak dipertimbangkan apabila ada manfaat yang jelas, seperti kebutuhan melihat tata ruang dari beberapa sudut. Jika tujuan utama adalah memberikan tugas dan membaca laporan, tampilan daftar yang baik tetap perlu tersedia sebagai alternatif.

19. Pertanyaan yang sering muncul

Apakah empat karyawan berarti empat model AI?

Tidak harus. Rancangan awal menggunakan empat profil peran yang dapat bergantian mengakses satu model. Menambah karakter tidak otomatis menambah kapasitas pemrosesan. Antrean dan penggunaan memori tetap perlu dikelola.

Apakah demo dapat langsung membuat artikel atau laporan?

Belum. Demo saat ini memperlihatkan antarmuka, aset, dan interaksi contoh. Form tugas belum menjalankan inferensi. Kemampuan membuat hasil nyata memerlukan backend, runtime model, penyimpanan, dan pengujian kualitas.

Apakah asetnya bisa dipakai offline?

Aset berupa file PNG dan SVG yang disimpan dalam paket. Demo disiapkan tanpa ketergantungan CDN. Untuk mencoba secara lokal, ekstrak seluruh paket dan pertahankan struktur file. Perilaku penampil HTML pada HP dapat berbeda, sehingga URL hosting menjadi pilihan praktis untuk melihat preview.

Apakah ini kantor 3D penuh?

Belum. Ini kantor 2D isometrik dengan gambar bergaya render 3D. Paket tidak memuat model GLB atau rig. Pengembangan 3D merupakan tahap terpisah dan tidak bisa diperoleh hanya dengan mengganti ekstensi gambar.

Apakah nama dan divisinya bisa diubah?

Bisa direncanakan demikian. Identitas peran sebaiknya disimpan sebagai konfigurasi, terpisah dari logika pekerjaan. Namun, mengganti label “Marketing” menjadi “Keuangan” tidak otomatis memberi kemampuan baru. Instruksi, alat, sumber, dan pemeriksaan hasilnya juga harus disesuaikan.

Mengapa koneksi cepat tidak otomatis mempercepat AI lokal?

Karena inferensi lokal berlangsung pada CPU/GPU dan memori perangkat. Internet membantu unduhan atau akses sumber online, sedangkan pemrosesan setelah model tersedia ditentukan oleh kondisi perangkat dan konfigurasi tugas.

Apakah artikel dan paket demo adalah berkas yang sama?

Tidak. ZIP artikel berisi naskah HTML, metadata, sumber, serta gambar untuk publikasi blog. Paket demo berisi aplikasi visual yang perlu ditempatkan di folder hosting. Mengunggah artikel.html ke alamat demo tidak akan menghasilkan kantor interaktif.

20. Mulai dari pengalaman visual, lalu bangun alur kerja nyata

Kantor AI lokal dapat menjadi antarmuka yang lebih mudah dipahami ketika peran, status, dan hasil ditampilkan dengan jelas. Nilai praktisnya berasal dari pekerjaan yang dapat diselesaikan serta ditinjau, bukan dari banyaknya karakter atau gerakan di layar.

Demo Ruang Kerja menyediakan dasar untuk mengevaluasi pengalaman tersebut: empat karyawan, empat divisi, aset kantor, bubble chat, menu aksi, dan galeri. Langkah berikutnya adalah menghubungkan satu tugas lokal, menyimpan hasil, lalu mengembangkan alur lintas peran secara bertahap.

Lihat Tampilan dan Coba Demo Kantor AI

Gunakan demo untuk menilai kenyamanan memilih karyawan, membaca status, dan menemukan aksi. Setelah alur tersebut sesuai, pengembangan dapat difokuskan pada integrasi model dan kualitas hasil yang benar-benar dibutuhkan.


Komentar (0)

Belum ada komentar. Jadilah yang pertama berkomentar!

Tinggalkan Komentar
Email tidak akan dipublikasikan.

Node Terkait

Cara Membuat Karyawan AI Lokal per Divisi Tanpa API Berbayar
18 Oct 2026
Profil SMA Negeri 2 Semarang: Alamat, Fasilitas, Ekstrakurikuler, dan Pendaftaran
17 Oct 2026
Profil SMP Suster Pontianak: Sejarah, Alamat, Akreditasi, dan Informasi Pendaftaran
17 Oct 2026