WitNote 智简笔记 · 05 · UI 收口：把工作台从功能堆叠变回安静桌面

AI 工具常见问题是功能入口越来越多：模型、角色、知识库、历史、预览、导出、设置全部想抢注意力。WitNote 的 UI 收口目标是让用户一眼知道自己正在写什么。

设计不是把按钮做小，而是决定哪些能力应该常驻，哪些能力应该折叠，哪些能力只在上下文需要时出现。真正高级的桌面工具通常不是显得复杂，而是让复杂性有位置。

开发细节补充：这篇记录放在 WitNote 智简笔记 的产品日记里，不是为了把一个功能包装成故事，而是把“05 · UI 收口：把工作台从功能堆叠变回安静桌面”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 macOS / Swift 原生 / 本地 MLX AI / Ollama / 自配 API，当前公开状态是 Mac App Store / 2.0.3 / 本地优先 / 模型可选，所以文案不能脱离真实发布进度。

对应的 docs 线索主要来自 WitNote docs/superpowers 计划、MAS 与 DMG 开发记录、本地文件和写作工作台迁移记录、多语言与上架文档。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。WitNote 的开发记录反复围绕本地文件夹、Markdown、预览、角色库和模型接入展开，说明它不是聊天壳，而是写作者长期工作台。 原生版本多次 spike 选择、格式化、HTML 导出、文件 IO、可折叠面板和当前文件搜索，说明核心难点在编辑体验和本地文件状态一致。 MAS 与 DMG 记录把收费墙、构建 SOP、多语言 README、隐私政策和发布包串在一起，证明它不是单页 Demo，而是完整桌面产品。 2025-12-30 WitNote 1.2.4 曾因 macOS 主窗口关闭后没有重新打开菜单被 Guideline 4 拒绝；1.2.8 用 Window 菜单、Dock 激活和快捷键修复后通过。 设计规格强调安静、克制、可回到原稿，让 AI 能力服务写作，而不是把作者的资料和草稿交给不可控黑箱。

从产品功能看，WitNote 智简笔记 关联的能力包括：Swift 原生 macOS Markdown 工作台、Markdown 文件夹与本地知识库、本地 MLX、Ollama 与自配 OpenAI 兼容 API、PDF / Word / EPUB 转换、双语阅读和写作辅助。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。

从工程推进看，这篇日记对应的检查点是：2.0.3 在 Swift 原生工作台中补齐本地模型、Ollama 与自配云端 API 三种模型来源；云端 API Key 仅存于此 Mac 的 Keychain；文稿附加发送需要针对接口单独授权；本地文件、模型选择、格式转换、StoreKit 和 App Store 隐私披露按同一条发布链验收。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。

从隐私和合规看，当前约束是：用户选择的文件夹、Markdown 文稿和导出结果默认保留在本地；本地 MLX 与本机 Ollama 不默认上传文稿。只有用户配置自己的云端 API 并主动发送提示词，或为该接口开启“允许发送已附加的文稿内容”后，相关文本才会直接发送到该用户指定的服务。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。

从课程和复用看，这篇内容可以沉淀到 Swift 原生 macOS、本地 AI、Ollama 与 API、Markdown 知识工作区、App Store 合规上架。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。

本地优先 AI 工具要先保护用户资产和写作节奏，再谈模型能力、补全效果和商业化。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是在 AI 能力、文件系统、编辑器体验和上架表达之间保持同一个本地优先承诺。

所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。

验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。

交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。

把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。