摘要
生成式 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 Friedman 公开修正了此前的立场，确认"对话即界面"是 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 舰队实战复盘
