摘要
生成式 AI 把"軟件操作"這一延續了四十年的圖形界面範式推到了範式更替的臨界點。本文基於一個一人軟件公司（FengProj 生態，含投資研究、內容生產、私有雲產品三個真實系統）的完整審查與重構實踐，提出並檢驗兩層界面原則：任何軟件系統只應保留兩個交互層次——(1) 對話層：人與 AI 的自然語言交流（Skill 即其腳本化形態），承載全部日常操作；(2) 觀景層：只讀的圖形界面，僅為"不參與操作的人"提供可視化確認。資料恆存本地文件，交互產出納入可備份管道。本文將該原則與業界三條並行脈絡——YC 的 “Chat is the interface”、生成式界面（Generative UI）、OpenAI Apps SDK 的 MCP-UI 架構——做對位分析，指出三者在結構上收斂於同一命題；並進一步論證：當 AI 成為第一操作者時，文檔（AGENTS/MISSION/todo/日誌）本身構成了第三個界面——面向 AI 的治理界面，從而把"界面"概念從人機兩端擴展為"人—AI—文檔"三元結構。案例部分給出五個系統的符合度審計與收束改造路徑，證明該原則在個人生產系統與對外商業產品上均可落地。
一、問題的提出
經典軟件的交互模型是"客户端中心"的：用户在圖形界面裏點擊、填表，操作結果沉澱在客户端的數據庫裏，界面既是操作入口又是數據容器。這一模型隱含了兩個 2026 年已不再成立的前提：
- 操作必須由人發起。當 AI Agent 可以受託執行選題、寫稿、研究、發佈、診斷等全流程操作時，“人點按鈕"從必需品降格為選項。
- 結果必須留在客户端。數據一旦以本地文件（Markdown/JSON/SQLite）為真理源，客户端就退化為一個視圖，備份與遷移成為文件級操作而非數據庫工程。
筆者由此重新構想整個軟件形態：我只需要跟 AI 説話——因為大部分工作本來就是文字交流；UI 只為兩類時刻存在：讓不懂的人看懂，以及讓看的人方便。 本文將這一直覺形式化為可審計的工程原則，並用一個真實的多系統生態驗證它。
二、兩層界面原則
原則（Two-Layer Interface Principle, 2LIP）：一個面向 AI 時代的軟件系統，其交互面只保留兩層——
| 層 | 服務對象 | 形態 | 職責 | 反模式 |
|---|---|---|---|---|
| 對話層（L1） | 操作者（人）與 AI | 自然語言 + Skill（腳本化指令） | 承載全部日常操作：增刪改查、流程觸發、異常處置 | 把操作埋進按鈕讓 AI 夠不着 |
| 觀景層（L2） | 觀看者（人，通常不操作） | 只讀 Web UI / 儀表盤 | 展示狀態與結果，供理解、驗收與對外演示 | 在觀景層開發寫操作 |
外加兩條資源約束：
- C1（資料本地）：真理源恆為本地文件或本地庫；任何客户端/雲服務只持有副本或視圖。
- C2（結果可備份）：一切交互產出落入可版本化、可多副本同步的管道（git 雙推、多設備同步）。
判別一個系統是否符合 2LIP，只需四問：數據在不在本地？日常操作走不走對話？UI 是否只讀？產出能否備份？
三、業界對位：三條脈絡的收斂
3.1 “Chat is the interface”
2026 年，Y Combinator 的 Gary Tan 與 Jared 公開修正了此前的立場，確認"對話即界面"是 AI 應用的正確形態（Pete Koomen 相關討論廣泛傳播）。產品側同聲相應：neww.ai 的口號 “Chat is the interface. The operating system is the product."；arg.ai 乾脆取消全部功能頁面，Agent 經聊天直接讀寫文件；面向承包商的 XBuild 讓"對話就是估算流程本身”。這説明 2LIP 的 L1 層已被業界接受為主通道，而非聊天機械人式的附加件（bolted-on chatbot）。
3.2 Generative UI：觀景層也無需預建
進一步的問題是：L2 觀景層要不要"精心開發”？生成式界面（Generative UI）給出否定回答——界面由 Agent 針對當前問題按需拼裝（卡片、圖表、整頁 HTML），而非設計師預定義的固定佈局（Google Cloud、CopilotKit、Decagon 諸家的定義趨同）。其論證是：儀表盤要求人去翻篩選器找答案，而 GenUI 把"界面變成一次回應，而不是一個目的地"。但 2026 年的實踐反思（如 r/UXDesign 社區）同樣指出：一眼掃全局的固定儀表盤在可預期性與可掃視性上不可替代。二者恰好合成 2LIP 的立場：觀景層保留，但不必精裝修——固定視圖管"日常掃一眼"，生成視圖管"臨時看細節"。
3.3 MCP Apps / OpenAI Apps SDK：給客户的 Skill 長出可視化
2LIP 在對外產品上的對應物已經平台化：OpenAI Apps SDK 讓 MCP server（即"給客户用的 Skill"）返回 UI 資源，在聊天流內以 React 組件渲染（如 Zillow 房源卡片）。這正是"Web UI 裏要有 Skill"的官方形態：Skill 是主體，UI 是 Skill 返回的可視化附件，而非獨立門戶。對桌面/移動端自有產品而言，等價推論是：客户對話入口內嵌於產品，操作走對話，面板退居展示與兜底。
3.4 Local-first：資源約束的業界共識
C1/C2 兩條資源約束對應 local-first AI Agent 脈絡：Agent 讀寫本地數據優先、異步同步備份（fast.io）；本地索引 + 按需上雲的分層數據策略（數據去向由敏感性而非"本地"教條決定）；個人 Agent 的運行時/記憶/技能/定時任務全棧本地化（r3zz.io 的"無聊架構"）。共識性結論是：完全離線不現實，關鍵在數據分級——敏感數據不出本地。2LIP 採納同一結論，且在單機個人生態下走得更遠：真理源可以 100% 本地。
四、第三個界面：文檔作為 AI 的治理面
2LIP 解決"人怎麼操作軟件"，但留下一個問題：AI 怎麼被操作？ 答案在實踐裏早已長出：不是 API，不是配置中心，而是文檔。
筆者的多機開發生態（FengASNI）對 70 份治理文檔做過共性分析，收斂出一套"督促文檔範式"：AGENTS.md（規則，唯一真源）、MISSION.md（北極星目標與 DoD）、todo.md（任務賬本）、FENGMEM.md（會話日誌）四件套，輔以 Skill（SKILL.md）作為可復用的操作封裝。其運行機制是：AI 開工先讀文檔獲得身份、規則與任務；行動結果回寫賬本與日誌；規則變更回寫 AGENTS。文檔即控制平面——這正是文檔驅動開發（Docs-as-Code）與 Agent 原生開發合流後的新角色：文檔的讀者從"人"擴展為"人與 AI"，且 AI 是更嚴格的讀者（它真的逐字執行）。
由此得到本文的核心擴展命題：AI 時代的軟件交互是三元結構——
人 ──自然語言──> AI ──工具調用──> 系統
│ ↑
└──文檔（規則/目標/賬本/日誌）──────┘
文檔 = 面向 AI 的界面（治理面）
- 對話層是"人操作 AI"的界面；
- 文檔層是"（人經 AI）治理 AI 與系統"的界面；
- 觀景層是"人確認系統狀態"的界面，為前兩層的結果提供可視化。
三層的關係不是並列：文檔層約束對話層（Skill 必須符合 AGENTS 鐵律），對話層驅動系統，觀景層只反映前兩者的產出。這一結構解釋了為何 2LIP 系統不需要複雜的權限後台——治理已經由文檔層的規則與賬本承擔。
五、案例研究：一個真實生態的審計與收束
以下為筆者個人生態（全部為本地優先的真實生產系統）按 2LIP 四問的審計結果：
| 系統 | 領域 | UI 現狀 | 審計判定 | 改造動作 |
|---|---|---|---|---|
| FengInvest | 投資研究（62 工具、2.7GB 本地行情庫） | 只讀報告瀏覽器（fengweb） | ✅ 標杆：數據本地 gitignored、操作全走對話、UI 純觀景、產出 git 雙推 | 不動 |
| FengMedia | 內容生產 | 作戰地圖 + 選題庫/打卡（有寫操作） | ⚠️ UI 混入操作 | 寫操作收進對話（“記一個選題"即落 JSON），UI 退為只讀 |
| FlyGo | 私有雲產品（對外商業） | 面板+APK 即產品本體 | ➖ 特殊：UI 是交付物，不適用 L2"退居"條款；但缺客户對話層 | 借 MCP Apps 模式嵌"客户 Skill”，面板退居展示 |
| FengOS | 項目指揮中心 | 3D 星系總覽+系統探針 | ✅ 即生態級"觀景台"本體 | 升級為統一觀景入口（聚合各系統只讀視圖，不搬數據） |
| 純工具（TTS-UI 等） | 桌面小工具 | GUI 即交互本體 | ➖ 不適用（無 AI 層需求） | 不動 |
審計揭示出一條普適的判定序：先分清系統是"自用生產系統"還是"對外產品"。前者嚴格適用 2LIP；後者的 UI 是產品本體，2LIP 的應用方式變為"在產品內增加對話層，而非取消 UI"。同時，生態級觀景台（FengOS）應收束各系統的查看入口，但堅持"iframe/連結聚合、不搬數據"，以守住 C1 的單一真理源。
六、討論：邊界與代價
2LIP 不是"消滅 UI"。 反對證據真實存在：可掃視性（glanceability）場景——監控大屏、駕駛艙、給投資人演示——固定視圖優於對話；無歧義操作的效率（調音量不該靠打字）。2LIP 的正確讀法是操作權轉移而非 UI 消亡：操作權歸對話層，UI 保留確認權。
對話層的可復現性依賴文檔層。 純對話交互的風險是"説過就丟"。文檔範式（任務入賬、日誌追加、DoD 驗收語句）正是對此的補全：每一輪對話的指令與結果都落為機器可讀的賬本，這使對話層獲得了傳統 GUI 所沒有的可審計性——操作歷史不是點擊流日誌，而是結構化文本。
成本結構的變化。 2LIP 將開發重心從"前端界面工程"轉向"Skill 工程 + 文檔治理 + 觀景頁按需生成"。對一人公司，這意味着此前最大的不可外包資產（界面）貶值，而最難複製的資產（領域規則文檔、人設、判斷標準）增值。
七、結論
兩層界面原則把 AI 時代的軟件形態收束為一句話：對話層負責"做"，觀景層負責"看"，文檔層負責"管"，資料留在本地，產出交給備份。 業界三條脈絡（chat-first、Generative UI、MCP Apps）與 local-first 實踐在結構上與該原則收斂，説明這不是個人偏好而是範式方向的提前卡位。對個人與小型組織，2LIP 提供了一條可立即執行的重構路徑：審計現有系統的 UI 寫操作並收進對話，把查看入口聚合為單一觀景台，為對外產品嵌入 Skill 形態的客户對話層——而這一切的地基，是把文檔當作面向 AI 的第一公民來建設。
參考文獻（2026-09 檢索）
- YC “chat is the interface” 立場轉向：Pete Koomen 訪談報道，biggo.com
- Google Cloud, What is Generative UI?
- CopilotKit, Generative UI; Decagon, What is Generative UI?
- Thesys, From Static Dashboards to Generative UI
- Open Data Science, Generative UI: When the Agent Builds the Interface for You
- OpenAI, Apps SDK / Add UI to your MCP server（developers.openai.com）
- Render, Building with the OpenAI Apps SDK: A Field Guide
- r3zz.io, The Boring Architecture Behind a Useful Personal AI Agent
- fast.io, How to Implement Local-First Storage for AI Agents
- Medium/Data Science Collective, My Local-First AI Agent Stack
- Reddit r/UXDesign, Generative UI feels like the next “voice will replace screens”
- 內部實踐：FengASNI DocsParadigm（70 份治理文檔共性分析與範式提案）；FengOrchestrator 五層架構總綱與 TTS-UI 艦隊實戰覆盤
