Scrawl：把「我看到什么」直接拍给智能体

一、凌晨两点，你在跟一个 bug 死磕

你盯着一个按钮，它不响应。你能想到的最省事的做法是什么？截图、拖进聊天框、然后打一大段字："这个按钮点了没反应，我在设置页第二栏，它右边有个小箭头，我以为是折叠菜单，点了整个页面卡住……"

这段描述至少有 60% 是猜的。真正省事的做法是：按下快捷键，一边操作一边把话说完，把按钮圈出来，然后把这一段「屏幕 + 声音 + 红圈」一起丢给 AI。

Scrawl（仓库 kitlangton/scrawl，作者 Kit Langton）就是干这一件事的。它的 README 第一行写得很直接：Show an agent a problem instead of describing it——给智能体看问题，而不是描述问题。

二、它到底产出了什么

按 ⌥⇧S 开始录屏，再按一次结束。这期间你说话、点击、拖拽、按住 Shift 在屏幕上画红色标记。每一次落点都会变成一个关键帧，帧上带着当时你说的那句话。

最终产物不是一段 mp4，而是一个 .scrawl 素材包：

智能体拿到这份素材包，等于同时拿到了画面、你的原话和操作顺序。配套的 scrawl CLI 还能让它「凑近看」：scrawl zoom <bundle> --at 0:12 抽出某一刻的密集帧网格，--at "你说的那句话" 直接按语义定位，--mark 2 定位到文本里标为 ✎② 的那个圈重点。

三、这不是录屏软件，是「交接协议」

真正值得琢磨的是 Scrawl 的设计取向——它把「给人看」和「给 Agent 看」当成两件不同的事。

给人看：正常录屏软件给你一条视频，你还得自己拖进度条找问题。Scrawl 自动做「关键帧化」——只在画面发生变化、你说「look」「now」、或者你画了标记时才截帧，并自动把每一帧裁剪到你实际操作的窗口区域（auto-crop），避免智能体在 4K 截图里找那个 20 像素的错误提示。

给 Agent 看：素材包旁挂了一份 skills/scrawl/SKILL.md，装上后 Claude Code、Codex、OpenCode 这类工具就知道怎么读这个格式：先看拼贴图和转写，文字只说明「说了什么、做了什么」，问题可能只出现在某一帧画面上；回答时用 #3 (0:10) 这样的编号引用瞬间，对方能直接在拼贴图上找到。

它甚至内置了一条「路由」逻辑（src/web.rs + src/routing）：如果录制时前台是某个本地开发站的浏览器标签页，Scrawl 会通过 127.0.0.1:47777 上的 SDK 脚本自动查到这个项目对应的 OpenCode 会话，然后把素材包直接投递过去，而不是只丢进剪贴板。

四、部署：它根本不是一个「能部署的服务」

Scrawl 是一款 macOS / Windows 原生桌面应用，Rust 写的核心（GPUI 框架做 UI），Swift 写 iOS 侧的 ScrawlKit 和 macOS helper，TypeScript 只用于官网。

• 平台门槛：macOS 需要 Apple silicon + macOS 15（实时转写和 Liquid Glass 需要 macOS 26）；Windows x64 是预览版且未签名；Linux 标注「Soon」。
• 系统权限是硬门槛：屏幕录制、麦克风、辅助功能（全局按键监听）、摄像头（接有线 iPhone 时）四类 macOS TCC 权限缺一不可，作者专门写了几千字处理授权后 App 不自动重启、用户拒绝授权等边界情况。
• 容器化：没有 Dockerfile、没有 compose、没有 K8s manifest，全仓库 0 处匹配。它是装在用户机器上的桌面程序，不是服务。

因此服务端部署可行性为「不支持」；但对最终用户而言，安装成本极低——官网 DMG 或 brew install --cask kitlangton/tap/scrawl，约 5 分钟，真正的时间花在第一次授权上。

五、代码与工程

Rust 代码约 259 万字节，Swift 68 万，TypeScript 29 万。源码按能力域切分得很干净：capture/（采集）、transcribe.rs / live_transcribe.rs / command_transcriber.rs（转写三选一）、autocrop.rs（自动裁剪）、keyframes.rs、feature_map.rs、routing/、export/、ui/（macos / windows / lab / motion 四套实现）。

转写有三条路径：macOS 走 Apple SpeechAnalyzer 端侧模型；Windows 走 transcribe-cpp（whisper.cpp 的 ggml 后端，按 CPU 指令集动态加载 haswell/skylakex 等 DLL）；另有 Hex 与 Command 两种外部转写器可配。端侧模型缺失时会打 .transcript-pending 标记，装好模型后原地重转写并重写 summary.md 与 scrawl.json。

工程质量上：有 Tests/ 目录与 GitHub Actions（check.yml 跑 fmt/clippy/test，另有 Windows 发布流水线），16 个 scripts 覆盖安装、发布、Sparkle 更新、CA 根证书检查，docs/ 下 9 篇专题文档，README 长达 5.7 万字符，逐条覆盖安装、权限、快捷键、CLI、设置、恢复流程。但项目 2026 年 10 月 14 日才创建，作者主导色彩明显，测试覆盖率未公开量化，Windows 版仍是未签名预览。

六、争议与局限

1. 权限面太重。屏幕录制 + 麦克风 + 辅助功能 + 摄像头，这一整套授权对普通用户是相当重的信任要求，也让它在企业环境里推进困难。
2. 平台绑定。Apple silicon 独占，Linux 尚不可用，Windows 未签名会被 Windows Defender 拦。
3. 本质是「输入方式」而非「模型能力」。它不做推理，不调用任何大模型，AI 含量集中在端侧 ASR 和「给智能体准备上下文」这一层，价值高度依赖下游 Agent 的能力。
4. 隐私是双刃剑。素材包默认留在本地 ~/Library/Application Support/scrawl/captures/，不上传；但一旦「发送到 OpenCode 会话」，内容就进了 Agent 的上下文——这是用户想要的，也正是需要团队自己评估的部分。
5. 项目太新。仓库创建不到三周，API、素材包格式、CLI 子命令都还在快速变动，当作稳定基础设施引入有风险。

七、行业意义

Scrawl 指向一个正在成形的变化：人机交互的瓶颈不再在模型，而在「如何把现实世界的状态低成本、结构化地喂给模型」。截图 + 一段语音是老办法，Scrawl 做的是把它工程化成一份带时间轴、带语义定位、带标注的素材包，再配上让 Agent 主动「凑近看」的 CLI。

作者本人就是 Agent 工具链的重度用户（repo 里同时提供 Claude Code / OpenCode / Codex 用的 skill），这让它更像一份「Agent 原生输入协议」的实验样本，而不是又一个录屏 App。827 star、84 fork、18 位贡献者、开源社区对这类「让人少打字」的交互层需求正在形成共识。

分析基于 GitHub 仓库 kitlangton/scrawl @ 2026-11-01 快照（830★ / 84 fork / MIT / Rust + Swift）。