【Cloud Summit Observation】Model Semakin Kuat, Mengapa Context Justru Semakin Bernilai — Cloud Summit 02

Dalam ajang Cloud Summit kali ini, Qoder mengemukan sebuah pandangan yang intinya:

Model power is a commodity. Context is the asset.

Perlu dicatat bahwa pernyataan ini bukan slogin resmi Qoder, melainkan gagasan arah yang sampaikan dalam sesi berbagi pengalaman di lokasi (dirangkum oleh vendor; ucapan asli merujuk pada pernyataan di tempat kejadian, tidak perlu ditafsirkan berlebihan). Namun,的观点戳中了一个越来越普遍的趋势：model semakin kuat, hambatan untuk mendapatkan model semakin rendah, bagian yang truly langka dari sebuah produk AI semakin bergeser ke lapisan yang lebih tinggi. Bagi perusahaan dan aplikasi yang kompleks, lapisan ini semakin menyerupai Context.

在之前一篇「Cloud Summit Observation」（Cloud Summit 01）第三节已经把这层判断的方向点过一遍——Qoder 把代码仓库做成 Wiki、Memory 与 Knowledge Cards，QwenWork 强调 Enterprise Context，OpenSearch 强调长期记忆与上下文压缩，三家厂商在 Cloud Summit 都在往同一个方向收敛。本篇把 Context 单独拆开，看清楚它怎么从一次性 Prompt 附件，升级成 AI 系统的长期资产，又会带出哪些新的工程、治理与组织问题。

一、Model Sudah Mengenal Dunia, Tapi Belum Tahu “Bagaimana Cara Kerja di Tempat Kami”

Model-model umum memang telah menguasai banyak pengetahuan publik dan mampu menyelesaikan penalaran yang semakin kompleks. Namun hal-hal yang sebenarnya ingin ditangani oleh enterprise往往高度依赖局部信息 oleh enterprise往往高度依赖局部信息，往往高度依赖局部信息。

一个 Coding Agent 需要知道当前仓库的架构、约定、历史 Bug、模块关系和发布流程。一个企业 Agent 需要知道组织结构、权限、SOP、项目状态、客户信息、内部文档和业务规则。一个电商内容 Agent 需要知道 Brand Guideline、SKU 信息、商品真实性约束、目标市场、历史广告表现和平台规则。一个 Research Agent 需要知道过去搜索过什么、哪些来源可信、哪些判断已经被推翻、当前研究任务的证据标准是什么。

这些信息不会因为模型升级自动补齐。

所以大量 Agent 产品开始把重点放到”如何建立持续可用的 Context”上。Context 不再是一次性 Prompt 的附件，而是一个长期维护的系统。

Mode kegagalan yang paling sering kita jumpai saat menjalankan pilot AI perusahaan adalah这点正好印证了：模型每次都很聪明，但系统整体很笨。 File harus diunggah ulang, permintaan brand harus dijabarkan ulang, latar belakang proyek harus dijelaskan ulang, dan keputusan historis harus diulang juga. Hilangkan saja gesekan ini, baru kemampuan model benar-benar mulai terealisasi.

二、Qoder Merancang Ulang Context Engineering: Knowledge Engine yang Mendefinisikan Ulang “Codebase”

Codebase tradisional dipahami terutama sebagai kumpulan file dan direktori. Di era AI Coding, codebase mulai memerlukan satu lapisan tambahan berupa semantik yang dapat dibaca mesin.

Beberapa komponen yang diperkenalkan Qoder secara现场 masing-masing memegang tanggung jawab berbeda dalam rekayasa Konteks (dirangkum oleh vendor, lihat dokumentasi vendor sebagai acuan): Repo Wiki membentuk struktur proyek dan penjelasan modul, Knowledge Graph mengekspresikan dependensi dan kontrak antar modul, Memory menyimpan batasan, preferensi, dan riwayat lintas Sesi, dan Knowledge Cards mengatur informasi yang relevan dengan tugas saat ini menjadi paket Konteks yang bisa langsung diberikan ke Agen.

更值得迁移的是这四件事背后的判断——Context 工程化以后，每一次新任务都从一个高信噪比的 Context 包开始，而不是从一份被反复读取的源代码仓库开始。

如果一个 Agent 每次接任务都重新扫描全部代码、重新阅读所有文档、重新猜测架构，模型能力再强也会浪费大量计算，而且结论非常不稳定。更合理的结构是：

Raw Data → Structured Knowledge → Task-specific Context → Agent

Task-specific Context 只抽取当前任务真正需要的内容，并且带着来源、版本、约束。

高德团队把百万行代码里的领域知识做成可召回资产后，任务一次性通过率从 37.3% 提升到 61.5%。这是 Context-as-Asset 的工程证据（数据来自厂商案例，是 Qoder 知识引擎在该客户上的实测结果，行业基准慎引；同样的论据在上一篇「云栖观察 01」第六节组织层判断里也出现过）。

三、QwenWork Menggerakkan Context dari Codebase Menuju Enterprise

Demonstrasi QwenWork di Cloud Congress (konferensi teknologi tahunan Alibaba) semakin mendorong Context dari codebase menuju seluruh enterprise.

Legal Document Fill Out dan Marketing Content Generation adalah dua tugas yang tampak biasa. Yang benar-benar layak disimak adalah bagaimana Agent mengetahui aturan dan sumber daya khas enterprise itu sendiri.

Jika sebuah Agent dokumen hukum tidak memahami template enterprise, aturan persetujuan, kolom kontrak, dan hak akses, ia hanya mampu menghasilkan dokumen yang terlihat masuk akal. Demikian pula, jika sebuah Agent Marketing tidak mengetahui materi merek, Campaign historis, pasar target, suara merek, dan informasi produk, maka ia akan terus-menerus meminta pengguna menjelaskan ulang konteksnya.

Inilah gesekan paling mencolok yang dihadapi banyak alat AI saat ini: pengguna berulang kali harus menyediakan Context dari awal (observasi strategis vendor, dengan teks asli sesuai rilis resmi Cloud Congress).

Sebuah AI Workspace yang benar-benar bernilai jangka panjang seharusnya secara bertahap mengubah penjelasan berulang ini menjadi aset yang persisten. File tidak perlu diunggah berulang kali, persyaratan merek tidak perlu dijabarkan ulang, latar belakang proyek tidak perlu dijelaskan kembali, dan keputusan historis tidak perlu diulang. Model bisa diganti, tetapi sistem tidak seharusnya dimulai dari nol setiap kali.

Context Bukan Tentang Memuat Lebih Banyak, Tapi Akumulasi Berkelanjutan

Ketika kami membantu klien mengimplementasikan AI Coding, kami selalu bertanya: “Jika tiga tahun kemudian Anda beralih ke platform lain, bisakah aset Context Anda dipindahkan?”—pertanyaan yang sama juga berlaku untuk platform Context enterprise seperti QwenWork. Bagian keenam nanti akan membahas lebih detail tentang cara mengevaluasi Anti-lock-in.

Empat, Nilai Context Berasal dari “Akumulasi Berkelanjutan”, Bukan “Memuat Lebih Banyak”

Membahas Context很容易掉进另一个误区：上下文窗口越大越好，把所有资料都塞进去。

实际系统里，Context 越多并不一定越好。大量无关信息会增加 Token 成本，也会降低注意力密度。不同版本文档同时存在时，模型甚至无法判断哪一份规则仍然有效。

所以 Context Engineering 真正要解决的是两类问题：保留什么与忘掉什么。

保留什么——聊天记录并不天然等于长期记忆。应该保存的是决策、约束、证据、失败原因、稳定偏好、可复用方法。支付系统改动不需要整个营销知识库，SEO Research 也不需要所有服务器日志。

Yang Harus Dilupakan — Context harus memiliki versi, waktu, sumber, dan status. Ketika sebuah keputusan arsitektur yang sudah tidak digunakan lagi terus dipanggil oleh Agent, memori jangka panjang justru akan memperbesar kesalahan. Tugas yang panjang memerlukan pen总结 dan reorganisasi context secara berkelanjutan, menyimpan state kunci, dan membuang detail yang sudah tidak bernilai.

Inilah mengapa forum Task Memory, Long-term Memory, dan Context Compression menjadi sorotan khusus dalam Task Memory, Long-term Memory, dan Context Compression yang diselenggarakan oleh Alibaba Cloud OpenSearch. Kerangka kerja self-loop “retrieval—action—memory—knowledge” yang dippresentasikan oleh Alibaba Cloud OpenSearch di forum tersebut (dirangkum oleh vendor, merujuk pada rilis resmi dari Cloud Town/Yunqi), pada esensinya menjawab pertanyaan yang sama: Memory mana yang harus dipertahankan untuk jangka waktu lama, mana yang harus dikompresi di akhir tugas, dan mana yang sudah kadaluarsa sehingga harus dilupakan secara aktif.

V. Memory Bukan Hanya tentang “Mengingat Apa yang Dikatakan Pengguna”

Banyak produk AI memahami Memory sebagai preferensi pengguna—misalnya mengingat bahasa, nama, atau format yang sering digunakan. Memang hal ini bermanfaat, tetapi untuk Agent, itu masih jauh dari cukup.

Memory yang benar-benar mampu menghasilkan compounding effect lebih mendekati Task Memory.

Setelah tugas kompleks selesai, sistem seharusnya memahami: bagaimana tugas tersebut dipecah; jalur pencarian mana yang efektif; инструмент mana yang pernah gagal; data mana yang bisa diandalkan; hasil mana yang diterima pengguna; mengapa hasilnya diterima; langkah mana yang bisa dioptimalkan menjadi Skill; dan kesalahan mana yang perlu dihindari di masa depan.

Jika hanya menyisipkan seluruh riwayat percakapan ke dalam Embedding, lalu mengambilnya kembali di ronde berikutnya, Memory akan mudah berubah menjadi gudang teks sejarah yang sangat besar. Potongan “relevan” yang diambil kembali belum tentu benar-benar relevan, dan kemungkinan model justru semakin terganggu.

Yang sebenarnya dibutuhkan Memory adalah proses ekstraksi, evaluasi, dan pengorganisasian yang terstruktur. Jika tidak, Context akan menumpuk terus-menerus, dan pengambilan keputusan di iteration berikutnya justru akan semakin tidak pasti.

Enam, Context Juga Dapat Menciptakan Lock-in Baru — Checklist Lima Pertanyaan untuk Anti-lock-in dalam Pemilihan Vendor

Semakin penting Context, semakin perlu kita mewaspadai lock-in platform yang baru.

Jika semua keputusan historis perusahaan, Workflow, Agent Memory, Skill, dan umpan balik pengguna tersimpan dalam platform tertutup, migrasi model mungkin mudah dilakukan, namun memindahkan Context akan sangat sulit. Ini adalah biaya jangka panjang yang lebih tersembunyi dibandingkan dengan perpindahan model.

Ketika kami mendampingi klien dalam pemilihan teknologi, kami selalu mengajukan pertanyaan spesifik: “Jika tiga tahun lagi platform ini diganti, bisakah aset Context kalian dibawa pergi?” Solusi yang tidak bisa menjawab pertanyaan ini sebaiknya dihindari.

Untuk menilai apakah sebuah platform AI akan mengunci perusahaan, Anda bisa memulainya dari lima pertanyaan berikut:

Pertama, soal ekspor. Task History, Decision Log, Knowledge Base, Skill Definition, Evaluation Result, Tool Configuration, Permission Mapping — dapatkah aset Context ini diekspor dalam format standar? Ini menentukan apakah saat berganti platform Anda bisa langsung migrasi, atau justru harus membangun ulang dari nol.

Kedua, soal versi. Apakah Context yang diekspor menyertakan informasi versi, waktu, sumber, dan status? Sebuah Knowledge Card tanpa timestamp tiga tahun kemudian akan sulit dijelaskan mengapa ia dibuat pada saat itu.

Ketiga, soal independensi model. Apakah Context dapat diproses oleh model yang berbeda? Jika sebuah Context hanya bisa dibaca oleh model tertentu, pada hakikatnya ia masih terikat pada satu vendor.

Keempat, soal lintas batas data dan kepatuhan. Apakah Context yang tersimpan di layanan luar negeri akan memicu proses persetujuan lintas batas data, serta kewajiban yang berkaitan dengan regulasi perlindungan data pribadi seperti GDPR/CCPA/PIPL dan persyaratan data center lokal untuk industri dengan regulasi ketat? Jika ini tidak terpenuhi, empat poin sebelumnya menjadi sia-sia.

Lima Pertanyaan tentang Tanggung Jawab Tata Kelola. Siapa yang bertanggung jawab atas kualitas Context? Siapa yang memiliki hak untuk memodifikasi? Siapa yang memutuskan untuk menonaktifkan konten yang sudah kadaluarsa? Tanpa kejelasan tanggung jawab tata kelola, akumulasi Context yang terus bertumpuk justru akan berubah menjadi beban organisasi yang baru.

Inti dari lima pertanyaan ini adalah: Model dapat diganti, Runtime dapat diganti, namun aset Context harus tetap berada dalam kendali sendiri. Hal ini berpotensi menjadi batas arsitektur baru bagi perangkat lunak enterprise yang bersifat AI-native.

Tujuh, Bentuk Akumulasi Context Sangat Berbeda di Empat Jenis Industri

Pembahasan sebelumnya menjelaskan链路 umum. Sekarang, mari kita terapkan判斷 ini ke dalam skenario konkret.

Operator Telekomunikasi — Kebutuhan seperti perubahan paket layanan,专线 perusahaan-pemerintah, dan tagihan lintas wilayah, setiap kali harus melewati empat hingga lima domain seperti BSS/OSS/CRM dan审计 kepatuhan. Mungkin aplikasi yang ditulis oleh AI bisa duas kali lebih cepat, namun适配 middleware, logika reconciliasi, dan persetujuan kepatuhan tidak berkurang sedikit pun. Fokus akumulasi Context di sini bukan pada basis kode, melainkan pada anomali tagihan historis, standar kepatuhan, dan aturan reconciliasi — Context semacam ini hampir tidak ada contoh datanya di资料 publik, menjadikannya pembeda utama (moat) sesungguhnya bagi perusahaan.

Perbankan — sistem inti, manajemen risiko, anti pencucian uang, audit yang dapat dijelaskan. Karakteristik dari alur kerja ini adalah setiap perubahan harus dapat dijelaskan, diaudit, dan ditelusuri. AI dapat menulis seperangkat aturan manajemen risiko dengan cepat, namun untuk memasuki mesin aturan diperlukan validasi model, pengujian explainability, peninjauan standar regulasi, dan persetujuan internal. Akumulasi Context di sini harus memenuhi kepatuhan pelepasan data lintas batas (kontrak standar untuk transfer data pribadi lintas batas, evaluasi perlindungan data pribadi) dan persyaratan pusat data lokal. Tanpa kedua hal ini, semua aset Context yang telah dibangun sebelumnya tidak akan dapat digunakan.

Industri Manufaktur — MES, ERP, QMS, sistem pelaporan. Seperti yang disebutkan di bagian sebelumnya, dalam rantai manufaktur, AI Coding paling sering mengalami masalah “berjalan lancar di lingkungan uji, tetapi gagal saat diintegrasikan ke sistem produksi”. Pertimbangan yang sama berlaku untuk Context: pengetahuan lantai produksi, parameter perangkat, standar pengumpulan data, antarmuka PLC, versi sistem visi — sebagian besar Context ini tersembunyi di benak para teknisi senior, dalam PDF usang, atau di spreadsheet yang belum sepenuhnya diperbarui. Jika tidak ada tim yang bertanggung jawab atas “kualitas akumulasi pengetahuan domain”, Context yang diterima AI akan cepat kedaluwarsa atau saling bertentangan. Ini adalah implementasi paling konkret dari daftar pertanyaan Lima Poin di bagian sebelumnya untuk industri manufaktur.

Informasi Context yang diperoleh AI dalam sektor ini mencakup standar merek, materi historis, aturan platform, dan evaluasi aktivitas promosi. Context bersifat paling sensitif terhadap waktu—strategi konten produk laris dari tiga bulan lalu bisa menjadi tidak relevan sama sekali untuk promo besar berikutnya. Oleh karena itu,治理 Context dalam skenario e-commerce bukan sekadar “akumulasi”, melainkan lebih kepada “menentukan ritme pengabaian/ pembaruan”.

Empat kategori industri memiliki bentuk Context yang berbeda, namun berbagi satu kesimpulan: Governance aset Context lebih bersifat precondition daripada pemilihan tools.

Delapan, Yang Benar-Benar Layak Diakumulasi Adalah Informasi yang Dapat Meningkatkan Kualitas Keputusan dan Eksekusi di Masa Mendatang

Jika kita mendorong lebih jauh pernyataan “Context adalah aset”, maka akan muncul kriteria yang lebih ketat: bukan semakin banyak yang disimpan, semakin banyak pula asetnya.

Hanya informasi yang mampu mengurangi ketidakpastian tugas berikutnya, meminimalkan eksplorasi berulang, meningkatkan stabilitas hasil, dan memperbaiki kualitas keputusan yang benar-benar membentuk aset.

Karenanya, ketika kami mendampingi klien dalam architecture review untuk desain produk AI, kami selalu mempertanyakan beberapa hal:

Setiap kali sistem menyelesaikan satu tugas, apa yang tersisa? Apakah sekadar hasil, ataukah metode yang dapat digunakan ulang beserta rekam jejak kegagalan?

Bisakah informasi ini langsung digunakan ulang di kesempatan berikutnya? Jika setiap kali harus dijelaskan ulang, penggunaan ulang hanya menjadi slogan semata.

Kesimpulan mana yang sudah diverifikasi? “Pengalaman” yang belum diverifikasi akan terakumulasi, dan lain kali membuat AI mengulangi kesalahan yang sama.

Kegagalan mana yang sudah tercatat dalam sistem? Context tanpa catatan kegagalan adalah sesuatu yang tidak lengkap.

Jika model diganti, apakah nilai yang terakumulasi sebelumnya masih bisa dimanfaatkan? Ini adalah perluasan dari lima pertanyaan Anti-lock-in di bagian sebelumnya: hanya jika Context tetap utuh saat pergantian model, barulah itu bisa dianggap sebagai aset sejati.

Model akan terus berkembang, harga penggunaan akan terus menurun, dan kapabilitas yang terlihat sangat kuat saat ini bisa saja segera menjadi infrastruktur dasar. Bagian yang benar-benar bisa menghasilkan keuntungan berkelanjutan justru biasanya berada di luar model itu sendiri: Context unik milik perusahaan sendiri, Workflow yang sudah terverifikasi, serta penilaian dan umpan balik yang terakumulasi dalam jangka panjang.

Implikasi bagi Pengambil Keputusan: 3 Hal untuk Kuartal Ini

Untuk CFO——Pindahkan fokus dari “berapa jam kerja yang dihemat oleh AI” ke “berapa banyak Context yang dapat digunakan kembali yang benar-benar terakumulasi dari setiap tugas yang diterima.” Untuk jenis tugas yang sama di tiga platform berbeda, tingkat penggunaan ulang Context yang terakumulasi bisa berbeda 3-5 kali lipat. Angka ini lebih mendekati ROI nyata dibandingkan dengan “jumlah panggilan,” dan lebih langsung menunjukkan aset jangka panjang.

Untuk CIO/CDO — Quartal depan, ubah kriteria pemilihan platform AI dari sekadar “benchmark model / harga Token” menjadi Daftar Lima Pertanyaan Anti-lock-in (ekspor / versi / agnostik model / kepatuhan / tanggung jawab tata kelola). Setelah kriteria ini diterapkan selama 1-2 kuartal, organisasi secara alami akan mulai menuntut Context yang terkontrol; jika kriterianya tidak berubah, biaya terbesar tiga tahun dari sekarang bukan biaya model, melainkan jam kerja untuk migrasi Context.

Untuk Pemimpin Bisnis — Tunjuk satu orang atau satu tim yang bertanggung jawab atas “kualitas akumulasi pengetahuan domain”. Inti dari kasus Gaode di bagian sebelumnya bukan sekadar peluncuran alat, melainkan adanya seseorang yang bertanggung jawab atas “kualitas akumulasi Context”. Jika hanya melempar alat ke tim tanpa ada yang menjamin kualitas Context, efektivitasnya kemungkinan besar akan berkurang setengahnya.

Pertanyaan yang Mungkin Anda Punya

Q1: Aset Context terdengar bagus, tapi bagaimana dengan perusahaan kecil dan menengah yang tidak punya tenaga khusus untuk akumulasi?

Bukan soal membuat tim khusus, melainkan mengintegrasikan akumulasi ke dalam proses yang sudah ada. Setiap kali Issue ditutup, setiap kali review kebutuhan, setiap kali post-mortem insiden — tambahkan saja dua kalimat tentang “mengapa这样做、踩过什么坑”. Dalam setahun, itu akan menjadi puluhan ribu kata ingatan organisasi. Kuncinya bukan di jam kerja, tapi di kesediaan untuk memperlakukan hal-hal ini sebagai deliverable resmi, bukan sekadar “kebersihan dokumentasi”.

Q2: Apakah Agent platform yang mempromosikan Memory dan Knowledge Cards hanyalah“新瓶装旧酒”(membungkus barang lama dengan kemasan baru)?

Sebagian memang“新瓶装旧酒”, tetapi sebagian arahnya memang baru — Task Memory mengubah riwayat eksekusi menjadi aset yang dapat dicari, Knowledge Cards menstrukturkan pengetahuan domain, ini adalah sesuatu yang tidak diselesaikan oleh Prompt Library sebelumnya. Cara membedakannya adalah melihat apakah ia bisa menjawab: “Memory ini上次(di penggunaan terakhir) oleh siapa, di task apa, dan mengapa diterima/ditolak?” Jika tidak bisa menjawab, kemungkinan besar itu adalah“旧酒”(barang lama).

Q3: Dalam lima pertanyaan Anti-lock-in, apakah“model-agnostic”(kebebasan dari ketergantungan model) terlalu idealis? Dalam kenyataan, kapabilitas model yang berbeda sangat bervariasi, dan更换(ganti) model pasti menurunkan kualitas.

Ya, dalam jangka pendek pasti menurunkan kualitas. Tapi yang ditanyakan bukan”apakah切换(switch) bisa tanpa biaya”, melainkan”apakah biaya切换(switch) dikunci secara eksklusif oleh satu vendor”. Jika bisa ekspor, bisa konversi format, bisa simpan versi, maka biaya切换(switch) adalah masalah rekayasa yang dapat dihitung; jika tidak bisa ekspor, biaya切换(switch) adalah risiko bisnis yang tidak可控(tidak dapat dikendalikan). Keduanya完全不同(benar-benar berbeda).

反向自检 (Refleksi Diri Terbalik)

Jangan mempercantik artikel ini sampai tingkat yang tidak ada. Tiga hal需要(perlu) jujur:

别把这一篇美化到不存在的程度。三件事需要诚实：

Jangan mempercantik artikel ini sampai tingkat yang tidak ada. Tiga hal perlu untuk jujur:

Jangan mempercantik artikel ini sampai tidak ada yang tidak ada. Tiga hal yang perlu kejujuran:

Pertama, artikel ini memiliki overlap arah yang signifikan dengan「Yunqi Observation 01」sebelumnya—Qoder Knowledge Engine, QwenWork Enterprise Context, OpenSearch Task Memory, peningkatan tingkat keberhasilan sekali coba tim AutoNavi dari 37,3% menjadi 61,5%, serta penilaian terkait assetisasi Context semuanya muncul di kedua artikel. Pada artikel ini telah dilakukan penataan ulang struktur (lima pertanyaan Anti-lock-in dipindahkan ke Bagian Keenam, dengan penambahan dimensi tanggung jawab tata kelola dan kepatuhan, serta penambahan perspektif empat industri), namun pembaca yang membaca kedua artikel secara berurutan mungkin merasa familiar. Saat menulis「Yunqi Observation 03」kali berikutnya, overlap seperti ini akan dihindari.

Kedua, proporsi kasus vendor dalam artikel ini cukup tinggi. Tiga argumen kunci—Qoder Knowledge Engine, QwenWork Legal Document Fill Out, dan OpenSearch Agentic Search—semuanya berasal dari rangkuman vendor di lokasi Yunqi atau dokumentasi vendor, sehingga sudut pandang cenderung condong ke sisi vendor. Hal ini telah ditandai satu per satu pada paragraf kutipan penjelasan, dan saat berargumen telah dicoba untuk dilakukan cross-validation dengan tinjauan akademis pihak ketiga (Memory in the Age of AI Agents arXiv:2512.13564).

Ketiga, Lima Pertanyaan Anti-lock-in saat ini masih berupa desain, bukan sistem indikator yang sudah divalidasi. Untuk benar-benar diterapkan, masih perlu ditambahkan: metrik spesifik untuk setiap pertanyaan, ambang batas minimum industri, dan arah yang jelas dari ketentuan kepatuhan. Artikel ini memberikan arah penilaian, bukan daftar kepatuhan. Akan dilengkapi pada saat kolaborasi berikutnya dengan klien.

Catatan Sitasi (sumber per item + tingkat bukti + posisi)

#	Pernyataan dalam Artikel	Sumber	Tanggal	Pihak yang Menyatakan	Tingkat Bukti	Posisi
1	“Model power is a commodity. Context is the asset.” (inti makna)	Sesi berbagi langsung Qoder (dirangkum oleh vendor, kata-kata aktual merujuk pada konteks presentasi)	2026-09-24	Tim Qoder	Klaim vendor	Posisi vendor
2	Qoder Knowledge Engine mencakup Repo Wiki / Knowledge Graph / Memory / Knowledge Cards	Halaman pengenalan Qoder Knowledge Engine + verifikasi silang dengan Bagian 3 artikel observasi Cloud Village sebelumnya	2025-2026	Tim Qoder	Klaim vendor	Posisi vendor

| 5 | OpenSearch Agentic Search “Pencarian—Aksi—Memori—Pengetahuan” Siklus Mandiri + Task Memory / Long-term Memory / Context Compression | https://xie.infoq.cn/article/163b700cba024c8adb326ec5c（InfoQ 云栖 2026 报道）+ https://docs.opensearch.org/3.6/vector-search/ai-search/agentic-search/agentic-memory + https://opensearch.org/blog/unpacked-at-open-source-summit-na-2026-inside-opensearchs-massive-leap-into-the-agentic-era/ | 2026-09 | Tim OpenSearch Alibaba Cloud / Proyek OpenSearch | Fakta terverifikasi (rilis vendor + laporan pihak ketiga) | Vendor /联合 |

| 9 | Transfer Data Lintas Batas / UU Perlindungan Informasi Pribadi / Persyaratan Data Center Lokal untuk Industri dengan Regulasi Ketat | Pasal 38-39 UU Perlindungan Informasi Pribadi + Metode Evaluasi Keamanan Transfer Data Lintas Batas + Persyaratan Regulasi Ketat Industri Keuangan (regulasi publik) | 2021-2026 | Kantor Siber Nasional / Bank Rakyat Tiongkok / Administrasi Regulasi Keuangan Nasional | Fakta Terverifikasi (regulasi) | Posisi Regulator |
| 10 | Perbedaan Bentuk Context di Empat Jenis Industri (Telekomunikasi / Keuangan / Manufaktur / E-commerce) | Observasi Industri Artikel Ini (berdasarkan kasus klien yang dianonimkan + kasus vendor publik) | 2026 | Penulis Artikel + Kompilasi | Observasi Industri (anonim) | — |
| 11 | “Jika tiga tahun kemudian platform ini diganti, bisakah aset Context Anda dibawa pergi?” | Pertanyaan Penilaian Artikel Ini (berdasarkan pengalaman migrasi platform AI multi-industri) | 2026 | Penulis Artikel | Inferensi Penulis | — |
| 12 | Fenomena “Berjalan Lancar di Lokasi, Gagal Saat Integrasi” di Industri Manufaktur | Bagian 6「Cloud栖 Observation 01」+ Kasus Hisense/Wens (kasus vendor publik) | 2025-2026 | Qoder / Alibaba Cloud Lingma / Hisense / Wens | Fakta Terverifikasi (kasus vendor, ekstensi anonim) | Vendor / Klien Bersama |

Titik Lokalisasi (perbandingan terjemahan multibahasa, perjanjian strategi multibahasa IAIUSE · 2026-08-09)

Ketika menerjemahkan ke dalam 19 bahasa, konten berikut dilokalkan untuk pasar bahasa target, dengan struktur/visual yang tetap tidak berubah:

Konten naskah bahasa Mandarin	Versi bahasa Inggris	Versi bahasa Jepang	Versi bahasa Jerman	Versi bahasa Arab
Qoder / produk Alibaba Cloud	Qoder / Alibaba Cloud (nama produk dipertahankan)	Qoder / アリババクラウド	Qoder / Alibaba Cloud	Qoder / علي بابا كلاود
Feishu / DingTalk	Slack / Teams	Slack / Teams / Lark	Slack / Teams	Microsoft Teams
China Telecom / China Mobile / China Unicom	AT&T / Verizon / T-Mobile	NTT / KDDI / 소프트뱅크	Deutsche Telekom / Vodafone	STC / Etisalat

招商银行 / ICBC	JPMorgan Chase / Bank of America	Mitsubishi UFJ / Sumitomo Mitsui	Deutsche Bank / Commerzbank	National Commercial Bank (Saudi) / QNB
BYD / CATL	Tesla / Ford / GM	Toyota / Nissan	Volkswagen / BMW	Saudi Aramco (representative manufacturer) / Tawuniya
Studi kasus Gaode Maps	Studi kasus Google Maps / Mapbox	Studi kasus Rakuten Mobile / Yahoo! Maps	Studi kasus Here Technologies	Studi kasus Careem / Google Maps MENA
QwenWork / Tongyi Qianwen	Tongyi / Qwen (nama produk dipertahankan)	Tongyi / Qwen	Tongyi / Qwen	Tongyi / Qwen

Catatan: Selain item lokalisasi yang disebutkan di atas, produk/konsep global dalam artikel (Repo Wiki, Knowledge Graph, Task Memory, Skill, Context Engineering, Anti-lock-in Lima Pertanyaan) dipertahankan seperti aslinya tanpa diterjemahkan. Untuk 15 bahasa lainnya, IAIUSE menerapkan tiga梯队 berdasarkan prioritas:

梯队一 (Lima bahasa utama — Tiongkok/Inggris/Jerman/Jepang/Arab): Lokalisasi penuh sesuai tabel di atas.

梯队二 (Sembilan bahasa tambahan — Spanyol/Prancis/Portugis/Korea/Rusia/Italia/Belanda/Polandia/Turki): Pertahankan nama asli Qoder/QwenWork + ganti perusahaan-perusahaan representatif lokal.

梯队三 (Lima bahasa opsional — Swedia/Thai/Vietnam/Ukraina/Indonesia): Pertahankan nama asli sebagai placeholder.

Jika Anda sedang mengevaluasi di mana perusahaan sebaiknya memulai implementasi AI, aset Context mana yang layak diprioritaskan untuk akumulasi, dan Prompt sekali pakai mana yang akan tenggelam oleh peningkatan model, silakan berdiskusi dengan kami. Kami menyediakan tiga layanan utama—Pelatihan Korporat (transformasi tim研发 dan operasional di era AI, lokakarya selama 2-3 hari, dilengkapi dengan盘点 aset Context, Anti-lock-in Lima Pertanyaan, dan sistem metrik yang dapat dibawa pulang), Konsultasi Khusus (dari盘点 aset Context, perancangan ulang Workflow hingga sistem metrik, membantu mengubah “kapabilitas model” menjadi “kapabilitas organisasi”), serta Sesi Sharing Eksekutif dan Pidato Industri (kebenaran tentang AI Context dari perspektif pengambil keputusan dan pemilihan vendor Anti-lock-in). Jika Anda hanya ingin berdiskusi selama 90 menit untuk melihat arahnya terlebih dahulu, silakan jadwalkan konsultasi ringan. Email kerja sama: [email protected].

Bacaan Lanjutan: 《Kerangka Tujuh Langkah Transformasi AI》, menjelaskan secara sistematis jalur lengkap implementasi AI di perusahaan.

Tentang Seri Ini

「，慢慢学AI」 adalah seri observasi lapangan industri dari IAIUSE, yang berangkat dari Cloud栖 Conference 2026, mengupas perubahan nyata yang sedang terjadi di industri AI dari perspektif peneliti—tanpa mengejar热点, hanya melihat arah став dan kekuatan bukti.

Seri ini membahas layer sistem di atas model, implementasi Agent, aset Context, desain organisasi AI enterprise, hingga migrasi unit kompetitif produk AI, dengan total sekitar 10 artikel.

Pustaka riset seri ini mencakup lebih dari 200 studi publik dan kasus industri. Artikel ini didukung oleh bukti dari tiga tingkatan: presentasi vendor lapangan (Qoder / QwenWork / OpenSearch), riset independen pihak ketiga (Memory in the Age of AI Agents, arXiv:2512.13564, dan tinjauan akademis lainnya), serta kasus klien mitraham yang telah dianonimkan. Perlu dicatat bahwa proporsi kasus vendor relatif tinggi; kami telah menandai posisi tersebut pada bagian kutipan untuk menjaga transparansi.

Pengalaman saya meliputi hampir 8 tahun konsultasi enterprise berskala besar dan analisis bisnis, dengan penugasan di IBM dalam proyek-proyek yang berkaitan dengan telekomunikasi, keuangan, asuransi, dan manufaktur. Setelah itu, saya terus berkecimpung di lini depan produk operator, produk internet, dan pengembangan aplikasi AI—mulai dari analisis kebutuhan, desain produk, hingga implementasi lintas-tim. Sebenarnya di balik publikasi ini ada tim kecil: saya dan 1-2 kolega yang telah lama bekerja sama, masing-masing bertanggung jawab atas riset alat pemrograman AI, pengumpulan kasus tata kelola organisasi, dan sesi coaching. Sebagian besar proyek “kami dampingi perusahaan melaluinya” dalam artikel adalah hasil kolaborasi kami.

Kesimpulan dalam seri ini berasal dari observasi lapangan dan verifikasi silang industri saya, dengan perspektif автор yang jelas, dan tidak mewakili pandangan vendor mana pun.