Showing Posts From

Cursor

AI 工作台设计手记：从 7 款工具里学到的 4 个模式

AI 工作台设计手记：从 7 款工具里学到的 4 个模式

我正在设计一款面向故事创作和影视前期制作的 AI 原生工作台，内部代号 StoryCanvas。 我不是设计师出身。所以在动手画界面之前，我需要先搞清楚一个问题：市面上的 AI 工作台是怎么做的？它们是怎么组织上下文、怎么管理生成产物、怎么支持协作的？ 于是我花了一周时间研究了 7 款产品。下面是我的第一阶段学习笔记——不是竞品分析报告，而是一个正在做产品的人，把学到的东西摊开来看。欢迎拍砖。 研究问题 动手之前先给自己列了几个问题：AI 工作台和「AI 功能」到底有什么区别？ 项目状态、AI 状态、协作状态三者之间应该是什么关系？ 在设计界面之前，我应该先验证哪些工作台模式？从 7 款产品里学到的 4 个模式 模式一：工作台即上下文容器 Notion AI 在页面、文档、任务、数据库和已连接的应用内运作。Cursor 在一个代码库内运作，能访问文件、终端、规则文件和 diff。Figma AI 在设计文件内运作，能访问组件库、设计令牌、评论和组件实例。 从这些产品里我学到的最重要的一课是：有用的 AI 工作发生在持久的工作台内部，而不是在脱离上下文的聊天里。一个全局聊天框如果不了解你当前在看什么、选中了什么，它的回答就像一个新同事没看你的文档就开始提建议——敬业但没用。 放在我的场景里，这意味着 StoryCanvas 需要一个持久的项目容器：让 AI 能访问已选定的故事上下文、已采纳的参考素材、已生成的资产，以及过往的决策记录。不是一个聊天窗口，而是一个有记忆的工作空间。 模式二：工作台即共享视觉状态 Figma、Higgsfield、Lovart、Milanote 和 Obsidian Canvas 都用了空间状态来帮助用户组织复杂素材。画板不只是装饰——它是协作和记忆的载体。 这让我想到一个问题：StoryCanvas 的画布布局是一个重要视图，但它不能是唯一的真相来源。如果用户把角色卡从画布左上角拖到右下角，后台数据里这个角色所属的剧本、场景、关系仍然应该可以查询。空间表达服务于视觉思维，但项目数据本身应该保持结构化、可查询。 模式三：工作台即操作面板 Cursor 的 Agent 可以搜索、读取、编辑、执行命令、调用 MCP 工具和应用变更。Figma 的 Agent 可以生成和优化设计，并连接设计库。Higgsfield 的画布让用户可以串联模型输出、重跑工作流。 观察这些产品后，我开始思考 StoryCanvas 的 AI 应该能做什么——不是「能做任何事情」，而是有明确权限边界的操作。我目前清单上的候选操作包括：提议场景重写、生成镜头变体、提取角色设定表、整理参考素材、创建分镜分支、更新资产元数据。每个操作都应该有清楚的作用域和审查机制。AI 可以提议，但不能静默修改。 模式四：工作台即协作记录 Higgsfield 强调实时协作和附着在节点上的评论。Figma 强调可分享的 AI 对话线程和团队评审。Milanote 强调在画板上收集团队和客户的反馈。 这是我在设计 StoryCanvas 时最想避免掉进的一个坑：让决策消失在聊天里。一个导演说「这个场景不太对」，AI 重新生成了一个版本——三个月后，没人记得为什么要改。所以我在考虑：AI 运行记录、评论、审批和被否决的替代方案，都应该附着在它们所影响的对象上。不是聊天记录的 scrollback，而是对象附带的设计历史。后续要研究的能力清单 在进入原型阶段之前，我列了一个待验证的能力列表——都来自这次调研的启发：项目级上下文索引：覆盖剧本、场景、角色、参考素材和已生成的媒体。 对象级 AI 操作：从选中和检查器面板中暴露出来，而不是藏在聊天框里。 生成队列：包含状态、成本/额度可见性、失败恢复和重试。 版本历史和分支：针对故事和媒体资产，不是简单的 undo/redo。 可复用的配方/模板：用于重复的视觉风格和镜头类型。 审查模式：在提交前查看 AI 提议的变更。 协作锚点：附着在对象上的评论、线程和审批。5 个必须避免的反模式 以下是从调研里总结的 5 个设计陷阱——每一条背后都有反例产品：一个看不到画布选中上下文的全局聊天框。 AI 不知道用户在做什么，只能给泛泛的回答。 一堆没有来源追溯的生成资产文件。 这张角色概念图是哪个版本的剧本生成的？没人知道。 一个要求用户先选模型、再描述意图的工作流。 用户不是 AI 工程师，他们只想说「帮我画一个雨中的东京街头」。 AI 静默修改项目状态而不告知用户。 「咦，这个角色的设定什么时候被改了？」 仅靠画布存储数据，导致搜索、自动化和导出变得困难。 当画布上有一百多个节点时，你不想一个个去找。下一步 这篇笔记是一个开端。我从 7 款产品里看到了清晰的模式，也知道了我需要避开哪些坑。 接下来我会把这些观察变成 StoryCanvas 的低保真原型——不是追求好看，而是验证一个假设：AI 原生工作台的核心设计问题不是「提示框放哪里」，而是项目上下文、空间组织、生成溯源、审查和协作如何拼装在一起。 如果你也在做 AI 工具的产品设计，或者对 StoryCanvas 的方向有兴趣，欢迎在评论区聊聊。Build in public 这件事，一个人想容易走偏。参考来源Notion AI: https://www.notion.com/en-gb/product/ai Cursor overview: https://docs.cursor.com/chat/overview Cursor tools: https://docs.cursor.com/en/agent/tools Figma AI: https://www.figma.com/ai/ Figma AI agent: https://www.figma.com/solutions/ai-design-agent/ Higgsfield Canvas: https://higgsfield.ai/canvas-intro Lovart ChatCanvas launch: https://www.lovart.ai/news/lovart-design-agent-public-launch-chatcanvas Milanote: https://milanote.com/ Obsidian Canvas: https://obsidian.md/canvas

在 macOS 上用 oMLX 跑本地大模型：Apple Silicon 专属推理服务器完全指南

在 macOS 上用 oMLX 跑本地大模型：Apple Silicon 专属推理服务器完全指南

如果你在用 Apple Silicon 的 Mac（M1/M2/M3/M4），想跑本地大模型来辅助编程或写作，大概率试过 Ollama 或 LM Studio。它们能用，但都有同一个痛点：上下文一长，响应就慢得让人想放弃。 oMLX 就是为了解决这个问题而生的。oMLX 是什么？ oMLX 是一款专为 Apple Silicon Mac 优化的本地 LLM 推理服务器，基于 Apple 官方的 MLX 框架构建。它的核心亮点是 智能 SSD KV 缓存——把推理过程中的 KV 缓存持久化到磁盘，让 Claude Code、Cursor、OpenClaw 等 AI 编程工具在长上下文场景下的响应时间从 30–90 秒缩短到 5 秒以内。✅ 开源协议：Apache 2.0 ✅ 运行平台：Apple Silicon + macOS 15+ ✅ GitHub：https://github.com/jundot/omlx（15k+ Stars）核心特性 1. 分页 SSD KV 缓存（最核心的差异化功能） 这是 oMLX 区别于 Ollama / LM Studio 的根本原因。 传统推理服务器的 KV 缓存在内存中，一旦上下文变化或服务器重启，缓存全部丢失，需要重新计算。oMLX 将所有 KV 缓存块以 safetensors 格式持久化到 SSD，并通过 LRU 策略在内存热层和磁盘冷层之间智能调度： 热层（RAM）←→ 冷层（SSD，safetensors 格式）实际效果：即使你切换了对话话题、或者重启了服务器，之前算过的上下文前缀不需要重新计算，TTFT（首 Token 响应时间）从 30–90 秒降至 5 秒以内。 2. 连续批处理（高吞吐） 通过 mlx-lm 的 BatchGenerator 处理并发请求，不再因单个请求阻塞整个队列。 实测数据（M3 Ultra 512GB，Qwen3.5-122B-A10B-4bit）：并发数 Token/s 加速比1× 56.6 1.00×2× 92.1 1.63×4× 135.1 2.39×8× 190.2 3.36×Qwen3-Coder-Next-8bit 在 8× 并发下最高可达 4.14× 加速。 3. 原生 macOS 菜单栏应用oMLX 提供了一个非 Electron的原生 macOS 菜单栏应用（用 PyObjC 实现），可以从菜单栏直接启动/停止/监控服务器，无需开着终端窗口。 应用已签名并公证，支持应用内自动更新。 4. OpenAI + Anthropic 双协议兼容 这是 oMLX 对 AI 编程工作流最友好的地方：提供 /v1/chat/completions（OpenAI 兼容端点） 提供 /v1/messages（Anthropic 原生端点） 兼容 Claude Code、Cursor、OpenClaw 及所有 OpenAI 兼容客户端Web 仪表盘可以一键生成各工具的配置命令，直接复制粘贴即可使用。5. 多模型同时服务 可以同时加载 LLM、VLM（视觉语言模型）、Embedding、Reranker 多种模型。内存不足时自动按 LRU 策略淘汰，也可以手动固定常用模型始终保持加载。系统要求配置 最低要求 推荐配置芯片 Apple Silicon（M1 或更新） M 系列 Pro/Max系统 macOS 15.0+（Sequoia） macOS 15+内存 16GB RAM 64GB+存储 视模型大小而定（30GB+ 推荐） —安装方式 方式一：Homebrew（推荐，含 CLI） 如果你需要通过命令行启动服务，或者用 Claude Code 等工具集成，Homebrew 方式最方便： # 添加 tap brew tap jundot/omlx https://github.com/jundot/omlx# 安装 brew install omlx# 升级到最新版本 brew upgrade omlx安装完成后可以直接用 omlx 命令，也可以作为后台服务运行（崩溃自动重启）： # 启动为后台服务 brew services start omlx# 查看服务状态 brew services info omlx# 停止服务 brew services stop omlx服务日志位置：服务管理日志：$(brew --prefix)/var/log/omlx.log 服务器运行日志：~/.omlx/logs/server.log💡 如果需要 MCP 工具支持，额外执行： /opt/homebrew/opt/omlx/libexec/bin/pip install mcp方式二：macOS App（最适合非技术用户）前往 GitHub Releases 下载 .dmg 文件 拖拽到 Applications 文件夹 启动后，欢迎界面会引导你完成：设置模型目录 → 启动服务器 → 下载第一个模型⚠️ 注意：macOS App 版本不包含 omlx CLI 命令。如果需要命令行控制，请选择 Homebrew 或源码安装方式。方式三：从源码安装（开发者） git clone https://github.com/jundot/omlx.git cd omlx# 仅安装核心功能 pip install -e .# 含 MCP 支持 pip install -e ".[mcp]"快速开始：启动你的第一个本地模型 第一步：准备模型目录 oMLX 需要从 HuggingFace 下载 MLX 格式的模型。你可以：直接用 oMLX 内置的模型下载器（推荐） 手动下载后放到指定目录 直接复用 LM Studio 的模型目录（无需重新下载）模型目录结构示例： ~/models/ ├── Qwen3.5-122B-A10B-4bit/ ├── Qwen3-Coder-Next-8bit/ ├── Step-3.5-Flash-8bit/ └── bge-m3/ ← Embedding 模型第二步：启动服务 Homebrew / 源码安装方式： omlx serve --model-dir ~/models启动后：API 端点：http://localhost:8000/v1 管理仪表盘：http://localhost:8000/admin 内置聊天界面：http://localhost:8000/admin/chatmacOS App 方式： 直接从 Applications 启动 oMLX，菜单栏会出现图标，点击即可管理服务器状态。 第三步：下载模型 打开管理仪表盘（/admin），在模型下载器里搜索并下载你需要的模型：仪表盘支持搜索 HuggingFace 上的 MLX 模型，查看模型卡片和文件大小，一键下载。与 Claude Code / Cursor 集成 这是 oMLX 最有价值的使用场景。配置完成后，你的 Claude Code 或 Cursor 就可以直接调用本地模型，所有数据都在本地运行，完全不依赖外网。 一键生成配置打开 oMLX 管理仪表盘 选择你要使用的模型 点击「一键生成配置命令」 复制命令，粘贴到终端执行oMLX 支持一键配置以下工具：工具 说明OpenClaw 一键生成配置OpenCode 一键生成配置Codex 一键生成配置Hermes Agent 一键生成配置GitHub Copilot 一键生成配置Pi 一键生成配置手动配置示例 如果你需要手动配置，只需要将 API 端点指向本地： # OpenAI 兼容客户端 export OPENAI_API_BASE="http://localhost:8000/v1" export OPENAI_API_KEY="dummy" # oMLX 默认不需要 key# Anthropic 兼容客户端（Claude Code） export ANTHROPIC_API_KEY="dummy" export ANTHROPIC_BASE_URL="http://localhost:8000"支持的模型 oMLX 支持所有来自 HuggingFace 的 MLX 格式模型，包括：模型系列 说明Qwen 含 Qwen3.5 MoE、Qwen3-Coder，推荐日常使用LLaMA Meta 系列Mistral Mistral AI 系列Gemma Google 系列DeepSeek 自动处理 <think> 标签GLM 智谱系列MiniMax 自动处理 <think> 标签VLM 视觉语言模型（v0.2.0+ 支持，含 SSD 缓存）Embedding / Reranker 可同时加载，用于 RAG 场景💡 模型选择建议：如果你主要用本地模型辅助编程，优先选择 Qwen3-Coder 或 Qwen3.5 系列，工具调用支持最好，速度也最快。管理仪表盘详解 oMLX 的管理仪表盘（/admin）是一个功能完整的 Web UI，所有 CDN 依赖均已本地化，完全离线可用。主要功能：实时监控：Token/s、并发数、内存占用等实时指标 模型管理：加载/卸载模型、设置每模型参数、固定常用模型 内置聊天：支持对话历史、模型切换、深色模式、VLM 图像上传 基准测试：一键测试预填充和生成速度 配置生成器：为各工具生成配置命令 多语言支持：英语、中文、日语、韩语、法语、俄语进阶配置 启用 SSD KV 缓存 omlx serve \ --model-dir ~/models \ --paged-ssd-cache-dir ~/.omlx/cache \ --hot-cache-max-size 20%--paged-ssd-cache-dir：指定 SSD 缓存目录 --hot-cache-max-size：热缓存占系统 RAM 的最大比例限制内存使用 # 限制单个模型最大内存 omlx serve --model-dir ~/models --max-model-memory 32GB# 限制进程总内存（默认：系统 RAM - 8GB） omlx serve --model-dir ~/models --max-process-memory 80%调整并发数 # 最大并发请求数（默认 8） omlx serve --model-dir ~/models --max-concurrent-requests 16启用 MCP 工具 omlx serve --model-dir ~/models --mcp-config ~/mcp.jsonAPI 密钥认证 omlx serve --model-dir ~/models --api-key your-secret-keyoMLX vs Ollama vs LM Studio对比项 Ollama LM Studio oMLXKV 缓存存储 仅内存 仅内存 内存 + SSD 持久化缓存失效后 全量重新计算 全量重新计算 从 SSD 毫秒级恢复TTFT（长上下文） 30–90 秒 30–90 秒 < 5 秒并发处理 单请求队列 单请求队列 连续批处理Anthropic 端点 不支持 不支持 原生支持菜单栏管理 无 有 有（原生非 Electron）适合场景 简单推理 图形化交互 AI 编程工作流架构概览 如果你对技术架构感兴趣，oMLX 的核心设计如下： FastAPI Server (OpenAI / Anthropic API) │ ├── EnginePool（多模型、LRU 驱逐、TTL） │ ├── BatchedEngine（LLM，持续批处理） │ ├── VLMEngine（视觉语言模型） │ ├── EmbeddingEngine │ └── RerankerEngine │ └── Cache Stack ├── PagedCacheManager（GPU，基于块，CoW，前缀共享） ├── Hot Cache（内存热层） └── PagedSSDCacheManager（SSD 冷层）这套架构的核心思路是：把 KV 缓存当作操作系统的虚拟内存来管理——热块在 RAM，冷块在 SSD，按需换入换出，服务器重启后缓存不丢失。总结 如果你在用 Mac 做 AI 辅助编程，oMLX 是目前最值得尝试的本地模型方案。它的 SSD KV 缓存设计真正解决了长上下文场景下的实用性问题，而原生菜单栏应用和一键工具集成也让日常使用变得非常顺手。 最重要的是：数据完全本地，不需要联网，不需要 API Key，不需要担心隐私泄露。 获取方式：官网：https://omlx.ai GitHub：https://github.com/jundot/omlx Homebrew 一键安装：brew tap jundot/omlx && brew install omlx参考资料：oMLX 官方文档（https://omlx.ai）及 GitHub 仓库（https://github.com/jundot/omlx）