文件管理器里的 Copilot 按钮：一个 48 小时就能被 hack 的入口

这篇文章最有价值的信息是：微软在文件管理器里加的 Copilot 按钮，本质上是一个上下文感知的 RAG 调用入口，真正值得关注的是它暴露的 API 路由和权限边界——这决定了我们能在 48 小时内用这个“玩具”做出什么 demo。

今天凌晨刷到这条新闻，IT 之家报道微软在 Win11 Release Preview 频道给文件管理器 Home 主页加了一个 Copilot 按钮，用来 AI 分析/摘要文件。我第一反应不是“哇，好用”，而是“这个按钮的触发逻辑是什么，它能不能被右键菜单劫持，以及它调用的模型是不是本地的”。

技术实现：不是按钮，是管道

先把新闻里的信息拆开看。微软这个功能不是简单的“选中文件-点按钮-出摘要”，它涉及文件管理器前端、Copilot 后端、文件内容解析三个层。根据过往经验，文件管理器里的 Copilot 集成大概率走的是 WinUI 3 的交互框架，底层调用 Windows Copilot Runtime API。这个 Runtime 在 Canary 频道已经存在一段时间，支持本地 slm（小语言模型）和云端大模型混合推理。

关键点在于：文件管理器是用户接触文件最频繁的入口，但也是数据泄露风险最高的地方。微软在 RP 预览版里放这个按钮，说明他们对本地模型推理的准确率有了信心——至少对常见文档（PDF、TXT、Office 文件）的摘要质量不会太差。但如果是图片、视频、压缩包，大概率还是会 fallback 到云端，或者干脆报错。

我在今年 Build 大会的 session 里看到过演示：文件管理器选中一个 PDF，右键菜单可以“Quick Summary”，底层调用 phi-3 本地模型，1 秒内输出摘要。当时 demo 用的是 7B 量化版，跑在 Surface Pro 上，风扇没转。

所以这个按钮背后的技术栈可以这么猜：

组件	可能的技术选型	备注
前端控件	XAML Island + WinUI 3	复用现有文件管理器 Ribbon 架构
文件解析管道	Windows.Data.Pdf / Office Interop / 自定义解析器	只支持常见格式，非全部
推理引擎	ONNX Runtime + DirectML	本地模型优先，云端补充
上下文传递	文件路径 + 内容片段（最大 8K token）	避免一次加载整个大文件

对开发者来说，最值得关注的是这个按钮是否会暴露一个可编程的 COM 接口或者 WinRT API。如果微软聪明一点，他们会把“文件摘要”做成一个服务契约，这样第三方文件管理器（如 Files App）也能调用。但从目前 RP 版的行为看，大概率是硬编码的，只有 Windows 自带文件管理器能用。

一个 48 小时能做的 demo：用文件管理器作为 AI 批处理入口

假设我们想 hack 这个功能，无非两种思路：

1. 劫持 Copilot 按钮的事件，替换成自己的模型调用

2. 利用文件管理器选择文件后的上下文，从外部触发 AI 操作

第一种思路需要 hook Win32 消息或修改 Explorer 的 Ribbon 资源，风险高且不稳定。第二种思路更现实：写一个后台服务，监听文件管理器当前选中的文件路径，当用户按下 Copilot 按钮时，用自己的 API 替换原始请求。

真正的技术价值不是用这个按钮本身，而是用它作为“文件选择器”的触发器，把文件路径传给自定义的 AI 工作流。

举个例子：我在黑客松里做过一个“批量合同比对”的 demo。技术栈是这样的：

• 文件选择：还是用 Windows 原生文件对话框，但用户选中多个 PDF 后，自动触发一个 Python 脚本
• 解析：PyMuPDF 提取文本，用 LangChain 做 chunking
• 推理：本地跑一个 Qwen2-7B 量化版，或者用 OpenAI API 做对比摘要
• 输出：生成一个 Markdown 报告，直接替换文件管理器里的选中文件（或者新建一个 report 文件夹）

如果微软的 Copilot 按钮能提供“选中文件列表”的 API，我们就能省去文件选择对话框这一步，直接在文件管理器里完成“选中-处理-输出”的闭环。**48 小时

原文链接：https://www.ithome.com/0/979/968.htm