Simon Willison 做了一个小工具，叫 Pasted File Editor。

小到只复刻 Claude 的一个交互：你往输入框里粘贴一大段内容，它不把正文撑爆，而是把这段内容变成附件。

这事不大。但它戳中了 AI 产品里一个长期被低估的问题：用户不是缺一个更会聊天的输入框，而是缺一个能接住材料的工作台。

Pasted File Editor 具体做了什么

Pasted File Editor 发布于 2026 年 6 月 2 日。按 Simon Willison 的说法，这是他让 Codex desktop 辅助构建的一个原型。

别误会。它不是 Claude 官方功能扩展，也不是 OpenAI 或 Codex 的官方发布。更不是成熟商业产品。

它复刻的灵感来自 Claude.ai，以及 Claude 桌面端、移动端里的“大段粘贴转附件”体验。

核心机制很清楚：

功能具体做法对用户的影响
大段粘贴粘贴 1000 字符以上内容时，自动作为附件加入编辑器正文保持不变，不被长文本冲掉
文件进入支持直接打开文件、拖拽文件、剪贴板粘贴日志、文档、代码、截图更容易放进来
图片处理图片显示缩略图不用只靠文件名猜内容
附件管理可预览、查看全文、移除上下文从一坨文本变成可管理对象

这里的 1000 字符不是行业标准，只是这个原型里的规则。

重点也不在这个数字。重点是它把“输入内容”和“工作材料”分开了。

对 AI 重度用户来说，这个差别很实际。你粘贴一段报错、一份需求、几段代码，原本输入框会立刻变成垃圾场。现在它们被放到附件区，正文还可以继续写你的指令。

这就是小交互的价值。它不炫，但省心。

真痛点不是模型，而是材料怎么进来

现在很多 AI 产品讲能力，喜欢盯着模型：上下文窗口多大，推理多强，代码准不准。

这些当然重要。但一到真实工作流，麻烦经常先出在入口。

开发者要塞日志、堆栈、源码片段。产品经理要塞需求文档和用户反馈。写作者要塞素材、提纲、旧稿。它们都不是一句聊天内容，而是一组上下文材料。

硬塞进输入框，有三个问题：

  • 正文被淹没，指令和材料混在一起；
  • 材料不好删，也不好回看；
  • 图片、文件、长文本没有统一管理方式。

Pasted File Editor 的判断很朴素：别把一切都当成“要发送的一句话”。

AI 对话框最早像搜索框。问一句，答一句。可一旦进入编程、审阅、写作、分析，它更像一个临时项目桌面。材料要摆开，能看，能删，能换。

这也是我觉得它值得写的原因。

模型再强，如果上下文入口乱，用户照样要在复制、粘贴、整理、改格式里耗时间。产品越喊智能，越不能让用户在输入框里做手工活。

“工欲善其事，必先利其器。”这句话放到 AI 产品上，不是鸡汤，是约束。工具不好，智能会被入口磨损掉。

谁该看这个小原型

最该看的是两类人。

一类是 AI 工具重度用户，尤其是每天处理代码、日志、文档、截图的人。对他们来说，Pasted File Editor 不是一个必须迁移的新工具，更像一个观察样板：以后挑 AI 产品，别只看模型名，也要看材料怎么进入、怎么预览、怎么移除。

采购和团队选型也会受这个逻辑影响。短期内，很多团队未必会因为一个附件交互换工具。但在同等模型能力下，低摩擦工作流会影响留存。谁能少让团队整理一次材料，谁就更容易被留下。

另一类是做 AI 产品和开发者工具的人。

可借鉴的不是“超过 1000 字符就转附件”这条规则本身，而是背后的产品分层：输入框负责意图，附件区负责材料，上下文管理负责秩序。

这比继续把输入框做大更重要。

当然，也别把这个原型吹过头。它目前只是原型。我们看不到性能数据、用户规模、商业计划，也看不到它如何处理复杂项目、权限、同步、版本和多轮引用。

接下来真正该观察的变量有两个：

观察变量为什么关键
附件能否进入多轮对话的稳定上下文如果每轮都要重新解释，工作台就退回临时剪贴板
文件、图片、文本能否被清楚引用和撤销不能追踪材料来源，就会增加误用和误判成本

这才是 AI 产品下一段竞争的细处。

早期 PC 从命令行走向图形界面时，改变普通用户的不是某个单点性能，而是“看得见、拖得动、能撤回”。今天的 AI 不完全一样，但入口逻辑相似：谁把复杂操作变成顺手动作，谁就占住日常使用。

Pasted File Editor 只是一个小样板。它没有证明谁赢，也没有证明模型路线变了。

它至少说明一件事：AI 产品不能再把输入框当万能容器。真实工作不是一句 prompt。真实工作是一堆材料、一串修改、几次反悔，以及用户希望少折腾一点的耐心。