做一个可发布的 Record & Replay macOS App

原文：https://indieseek.co/zh/blogs/record-replay-macos-app-technical-plan/

做一个可发布的 Record & Replay macOS App

Codex Record & Replay 指向了一个很有意思的产品方向：很多时候，用户并不想从零解释一个工作流。他已经知道怎么做，只是想演示一次，然后把这次演示变成以后可复用的东西。

这个想法很强。但如果要做成一个独立产品，它不能只是浏览器录制器，也不能只是鼠标坐标宏。别人要安装、信任、反复使用，它就必须能记录真实浏览器和真实桌面，保护敏感数据，并且回放工作流意图，而不是机械复读像素。

我会把它做成一个本地优先的 Mac App：

录制一次浏览器 + 桌面工作流 -> 复查记录了什么 -> 编译成可编辑 routine -> 带验证地回放

它相对 Codex 的优势，不是“做一个更强的通用 agent”。更现实的优势是产品控制权：本地存储、自带模型设置、routine 库、运行历史、计划任务、日志，以及可导出的 workflow 文件。

核心产品判断

一个有用的 Record & Replay App，应该把一次演示变成以后可以重复运行的 routine。

演示 -> 采集证据 -> 编译 routine -> 运行 routine -> 验证结果

这里最重要的词是“编译”。原始事件是证据，不是最终自动化。

如果用户点击了一个按钮，产品不应该只记住 x=1040, y=72。它应该记住 app、窗口、可访问性目标、周围文本、浏览器 DOM、必要时的截图，以及这一步为什么重要。

这就是工作流系统和脆弱宏录制器的区别。

第一版必须覆盖浏览器和桌面

只做浏览器自动化当然有价值，但对这个产品来说不够。

真实工作流经常跨边界：

  • 在 Chrome 打开一个页面；
  • 下载一个文件；
  • 在 Finder 里找到它；
  • 上传到另一个地方；
  • 从 Notes 或 Slack 复制一个值；
  • 确认一个 macOS 弹窗；
  • 回到浏览器提交。

如果产品只能看见浏览器，就错过了 Record & Replay 最有价值的部分。

所以第一版可信产品至少需要两条 surface：

flowchart LR User["用户演示工作流"] --> App["Mac App"] App --> Browser["浏览器 Surface\nExtension + Native Messaging"] App --> Desktop["桌面 Surface\nAccessibility + 输入事件 + 截图"] Browser --> Trace["本地 Trace\nsession.json\nevents.jsonl\nkeyframes"] Desktop --> Trace Trace --> Review["复查和脱敏"] Review --> Compile["Routine Compiler"] Compile --> Routine["workflow.json\nroutine.md\nassets"] Routine --> Runtime["Replay Runtime"] Runtime --> Verify["Verification"]

浏览器侧应该记录 URL、标题、DOM target、ARIA role/name、selector 候选、输入变化、导航和关键截图。

桌面侧应该记录前台 app、窗口标题、Accessibility role/name/value、焦点、选区、输入事件和截图。

两边都写进同一条时间线。编译器看到的应该是一段完整工作流，而不是两份断开的日志。

Trace 是证据，不是产品

Trace 格式应该无聊，但明确。

每个事件都要说明：

  • 来自哪个 surface；
  • 当时哪个 app 和窗口处于前台；
  • 用户做了什么；
  • 操作对象是什么；
  • 捕获了哪些上下文；
  • 哪些字段已经脱敏；
  • 哪张截图、DOM 或 Accessibility 快照能支撑这个事件。

一个简单事件可以长这样：

{ "eventId": "evt_001", "surface": "browser", "app": "Chrome", "windowTitle": "Dashboard", "type": "input", "target": { "role": "textbox", "label": "Search", "selector": "[aria-label='Search']" }, "value": { "kind": "text", "redacted": false, "preview": "invoice 2026" }, "contextRefs": ["dom_001", "frame_001"] }

产品不应该把所有内容都当普通文本永久保存。原始内容、摘要、截图和准备发给模型的上下文应该分层。任何内容离开本机前，用户都应该能看见。

Compiler 才是真正的产品核心

Compiler 负责把嘈杂证据变成可编辑 routine。

flowchart TD Raw["Raw events"] --> Clean["清洗噪声"] Clean --> Segment["切分步骤"] Segment --> Anchor["生成稳定锚点"] Anchor --> Params["识别变量"] Params --> Verify["写入验证方式"] Verify --> Routine["routine.md + workflow.json"]

好的编译应该做到：

  • 把连续输入合并成一个输入步骤；
  • 去掉误点和空闲时间；
  • 识别哪些值每次会变；
  • 优先使用语义目标，而不是坐标；
  • 给关键步骤写验证；
  • 标记风险和敏感字段；
  • 只有意图不清时才问用户。

好的 routine 应该像这样：

打开报告页。 选择日期范围。 上传指定文件。 提交草稿。 确认成功提示出现。

而不是这样：

移动鼠标到 1040,72。 点击。 等待 500ms。 按 Tab。

Replay 必须有验证闭环

回放应该是状态机，不应该是逐行盲跑脚本。

stateDiagram-v2 [*] --> LoadRoutine LoadRoutine --> CollectInputs CollectInputs --> Preflight Preflight --> ExecuteStep ExecuteStep --> VerifyStep VerifyStep --> ExecuteStep: 通过且还有下一步 VerifyStep --> Recover: 未通过 Recover --> ExecuteStep: 自动恢复成功 Recover --> HumanTakeover: 需要用户介入 HumanTakeover --> ExecuteStep: 用户修复后继续 VerifyStep --> Done: 全部通过 Done --> [*]

执行时应该按稳定性排序：

  • 先用最稳定的语义路径：API、MCP、Apple Events、浏览器 DOM action 或 Accessibility action。
  • 再用结构定位：selector、ARIA label、可见文本、Accessibility role 或窗口层级。
  • 结构不足时用视觉匹配。
  • 坐标只能作为最后手段，并且要绑定到已知窗口和截图。

    • 危险动作必须确认。删除数据、提交付款、改密码、上传私人文件、安装软件、发送敏感信息，都不应该无人值守运行。

    BYOK 是真实优势

    Bring your own key 不是一个普通设置项，而是产品优势。

    它让用户选择成本、隐私和模型能力。App 至少应该支持：

    • OpenAI-compatible base URL + API key + model；
    • Anthropic；
    • Gemini；
    • OpenRouter；
    • Ollama 或兼容本地服务。

    API key 应该放在 Keychain。设置页需要有连接测试、模型能力提示、上下文预览和大致成本估算。

    便宜模型可以做文本清洗和 trace 摘要。更强的多模态模型留给歧义屏幕和视觉恢复。

    分发也要提前设计

    这种 App 第一版更适合走 Mac App Store 之外的分发。

    它需要 Accessibility、Screen Recording、Input Monitoring，部分场景还需要 Apple Events、helper 进程和浏览器扩展安装。Developer ID 签名和公证是更现实的第一路径。

    用户体验里也必须清楚解释权限。工作流录制器会看见很多东西。如果它讲不清记录了什么、数据存在哪里、什么会发给模型，它就不值得被信任。

    一个现实的 v1

    第一版可售卖产品应该窄，但完整。

    它应该支持：

    • Chrome 或 Brave 工作流录制；
    • macOS app/window 追踪和 Accessibility 目标；
    • 一条本地 trace 时间线；
    • 支持删除和脱敏的 trace review；
    • 编译生成 routine.md 和 workflow.json；
    • 浏览器 + 桌面回放，并带步骤验证；
    • 不确定时允许人工接管；
    • 本地优先存储和上下文预览；
    • 签名、公证后的安装包。

    适合第一版的场景应该故意无聊：后台表单、浏览器 + Finder 上传下载、Finder/Notes/Mail/Calendar/Slack 里的简单稳定流程。

    第一版不适合承诺银行、支付、政府、医疗、游戏、复杂设计工具，或完全无人值守的敏感操作。

    最终判断

    这个方向可以做，但定位必须诚实。

    它不是“自动化所有 app”。它不是“录制像素再回放像素”。它也不是“套一个漂亮 UI 的浏览器自动化”。

    更强的承诺是：

    录制一次浏览器 + Mac 工作流，把它变成可编辑 AI routine，并用你自己的模型反复执行。

    这个定位让它在 Codex 旁边仍然有存在价值：本地优先、模型可选、routine 可迁移，并且有一个专门为真实重复运行设计的产品界面。

    来源和相关资源

    posted @ 2026-07-07 20:16  IndieSeek  阅读(2)  评论(0)    收藏  举报