諮詢顧問們在 PPT 裡耗盡了前半生的精氣神，現在終於有人意識到，既然 Claude 能寫出幾千行的 React 組件，為什麼我們還要忍受那個沈重的 .pptx 格式？最近 Bento 這種「單文件 HTML 投影片」在技術圈引起不小的騷動，表面上是極簡主義的復興，實則揭示了一個尷尬的技術斷層：當代的大型語言模型已經能寫出複雜的前端邏輯，卻始終處理不好那些瑣碎的、需要反覆對齊像素的視覺調整。你讓 Claude Code 幫你寫一個帶有無縫動畫的展示頁面，它能在幾秒鐘內吐出完美代碼，但如果你想把某個標題往左挪動三個像素，或是改個顏色，你卻得重新喚醒那個動輒消耗幾千個 token 的對話進程。這種「用大砲打蚊子」的循環，正是當前 AI 輔助開發中最荒謬的景觀。
這類 Single-File Web Apps 的核心技術邏輯，是將所有的 JSON 數據與渲染引擎、編輯器邏輯全部塞進一個不到 1MB 的 HTML 裡。在 Claude 的 Context Window 持續擴張的今天，這種做法顯得極其聰明。你可以直接把整個 HTML 丟進對話框，告訴它「基於目前的數據結構增加三個圖表」，它不會因為找不到 CSS 路徑或依賴包缺失而胡言亂語。這與 ChatGPT 處理代碼的方式如出一轍，後者更偏好於給你一個完整的、自包含的解決方案，而不是散落在各個目錄下的模組。然而，問題也隨之而來，當一個 HTML 文件裡充斥著 Base64 編碼的圖像和混淆後的二進位數據時，即便是最強大的模型也會開始在長文本的深處迷失，注意力機制的權重分配在面對非語義化的長字串時，效率低得令人髮指。
在這種「一文件即應用」的範式下，不同模型的工程化性格被放到了顯微鏡下。Claude 在處理這類包含複雜狀態管理的單文件任務時，展現出了一種近乎偏執的嚴謹，它生成的代碼結構通常更易於被後續的人工微調。相較於 Kimi K3，Claude 在處理超長 HTML 內嵌 JSON 數據時的定位精度明顯更高。而 ChatGPT 則顯得有些急躁，它傾向於覆蓋掉你原本精心調校的 CSS 樣式，只為了完成你提出的那個微小功能需求。Gemini 的表現則更像是一個博而不精的圖書館管理員，它能理解你在 HTML 裡塞進去的各種奇怪格式，但在執行 Function Calling 來修改特定 Slide 數據時，偶爾會出現邏輯上的斷點，導致整份投影片在瀏覽器裡直接白屏。
這種技術演進其實在嘲諷某種現狀：我們擁有最強大的計算能力，卻回頭擁抱最原始的文件格式。當人們在討論 Kimi K3 的長文本處理能力時，真正核心的競爭力依然回到了四大平台對代碼語義的深度解析上。Grok 在這方面顯得有些游離，它的生成風格更偏向於直接與奔放，對於這種需要細膩處理 DOM 結構的工具開發，目前還看不出它有超越前三者的潛力。我們在這些模型之間切換，本質上是在尋找一種平衡，既要 AI 的高效率生成，又要保留人類對結果的微觀控制權。
如果未來所有的生產力工具都變成了一個個可以被 AI 隨意揉捏的 HTML 文件，那我們還需要複雜的 SaaS 平台嗎？當數據、邏輯與視圖完全合一，傳統的軟體架構是否會被這種由 AI 驅動的「自給自足式」應用徹底瓦解？更進一步說，如果一個模型能寫出一個包含編輯器的投影片工具，它是否也正在定義一種新的、不再需要後台伺服器的「私有化軟體」時代？我們究竟是在利用 AI 簡化工作，還是在為了遷就 AI 的生成偏好，而強行將數位世界退化回那個只有 HTML 的純真年代？