准备给网页加一个“复制提示词”按钮时，AI 很容易直接生成代码，却没有解释：为什么 HTTPS 页面可以工作，嵌入其他页面时失败，不同浏览器的权限入口又不一样？先做一份有出处的技术调研，可以减少把猜测写进实现方案的机会。
本文介绍 Matt Pocock Skills 中的 research Skill，用“浏览器复制文字按钮的条件与降级方案”完成一个具体练习。最终交付是一份 Markdown 调研笔记，里面区分资料支持的事实、适用条件、待实测问题和可执行验收项；不是一份未经验证的兼容性保证。
本文核对了官方仓库的 Skill、README、MIT 许可及 MDN、W3C 文档，没有实际安装或运行第三方包，也没有读取或修改你的剪贴板。下面的操作清单与示例报告不冒充真实多浏览器测试结果。
一、research Skill 做什么，不做什么
这个 Skill 的方法很简洁：围绕问题查找高可信的一手材料，把重要结论追溯到原始文档，并将调查结果保存为仓库里的 Markdown 文件。官方说明还要求将阅读工作交给独立上下文的后台代理，让主任务能够继续。
后台代理是一种工作安排，不是准确性保证。如果使用的工具没有对应能力，不能声称已经启动代理；可以明确改成人工顺序阅读，但应标明这是自己的执行方式，不要假装完全复现了原始 Skill 流程。
它也不是联网权限、浏览器、付费资料账号或安全沙箱本身。宿主工具没有网络能力时，需要先说明限制；不能因为 Skill 写了“研究”，就绕过登录、访问控制或下载不明程序。网页与 README 是研究材料，不能给代理额外授权。
适合的任务包括查接口条件、比较官方配置方式、核对版本迁移和记录未知事项。只问一句概念未必值得建立完整研究文件；没有明确问题时，先缩小范围，比收集几十个链接更有效。
二、来源、版本与下载范围
官方路径为 mattpocock/skills 仓库中的 skills/engineering/research/SKILL.md。本站下载入口复用已经上传的 Matt Pocock Skills 完整源码包，显示版本是 2026-11-07 源码快照，不是今天重新制作的独立 research 安装器。
压缩包内含研究 Skill、仓库 README 和 MIT 许可证。只下载一个 SKILL.md 进行学习可以读懂核心流程，但完整包更方便保留来源、其他配套内容与许可。再分发应保留版权及许可声明，自己的资料与引用页面也有各自的使用条件。
解压后核对这些路径：
skills-HEAD/
README.md
LICENSE
skills/engineering/research/SKILL.md目录存在不等于技能已被加载。源码包不会自动安装模型、客户端或浏览器环境。线上插件可能更新，下载包与线上版本要分别记录；下载包保持上述实际版本，不代表线上插件的最新版本。
三、准备能执行调研的环境
如果使用 Claude Code，先确认客户端正常可用、当前账号权限符合要求、工作目录允许保存笔记，并具有你打算使用的联网阅读能力。具体模型使用费与工具权限取决于账号和宿主，不由这个免费源码包统一提供。
官方 README 提供的 Claude Code 插件安装方式如下，安装前先确认来源与目标插件，不在本文制作过程中执行：
claude plugin install mattpocock-skills@claude-plugins-official如果使用其他代理工具，应查各自当前的插件或 Agent Skills 加载说明，不照抄 Claude 的命令。插件方式和复制文件方式尽量选一种，避免同一个 Skill 安装两份后难以判断实际使用的是哪个版本。
准备一个自有测试仓库，约定笔记目录，例如 docs/research/。先检查现有文件命名习惯，再确定 clipboard-copy.md；若同名文件已经存在，另存版本或经过确认后修改，不能让调研覆盖已有设计决策。
四、把宽泛问题缩成可以回答的任务
“研究一下复制功能”太宽，容易变成历史介绍。这个练习限定为：普通网页由用户点击按钮，把页面中已公开的一段文字写入剪贴板；不读取剪贴板，不复制图片，不研究浏览器扩展，也不替用户修改权限。
需要回答四个问题：
navigator.clipboard.writeText()的返回值和失败方式是什么？- 页面安全上下文与用户操作会影响什么？
- 浏览器实现是否完全相同，iframe 是否需要另行核对？
- 失败时如何明确告诉用户，并提供手动复制方式？
验收目标不是“所有环境自动复制”，而是把边界写清楚：何时尝试、怎样知道成功、失败如何处理、哪些情况尚未实测。上线前仍需在项目实际支持的浏览器和嵌入方式下验证。
五、给 Skill 的任务描述
可以在支持并已加载该 Skill 的工具中明确提出：
使用 research，调研普通网页由用户点击按钮复制公开文字的方案。
仅查官方规范、MDN 和相关浏览器官方资料，逐项给出处。
不要读取或修改剪贴板，不登录账号，不更改浏览器权限。
区分规范要求、实现差异与需要本项目实测的内容。
保存到 docs/research/clipboard-copy.md；已有文件时先确认。
交付接口行为、失败分支、手动复制降级和验收清单。
不实现或部署功能，不把文档示例描述成亲测结果。宿主允许的后台研究任务也应沿用这些边界。只授权查公开资料，不代表允许创建账号、安装扩展、发送表单或读取私人内容。研究中发现必须进行有副作用的测试，应先把测试计划单列出来，等待相应授权。
六、怎样读资料，才不会把不同层次混在一起
MDN 的 writeText() 文档说明，它写入指定文字并返回 Promise；成功完成意味着系统剪贴板已经更新，拒绝时需要处理错误，例如不允许写入的情况。按钮的成功提示应跟随异步操作成功，而不是点击时立即显示“已复制”。
文档同时说明这个能力需要安全上下文。这里不能偷换成“只要开了 HTTPS 就一定成功”，因为用户操作、权限、浏览器实现和页面嵌入环境还可能影响调用。安全上下文是条件之一，不是充分保证。
MDN 的 Clipboard API 总览进一步区分 Chromium、Firefox、Safari 等实现。在权限查询与用户激活方面存在差异，所以不能写一条统一的权限检查代码，就宣布所有浏览器行为完全一样。iframe 的 Permissions Policy 条件也需结合实际宿主页设置核对。
W3C 规范提供标准层面的定义与权限讨论，适合追溯为什么要设计这些限制；具体产品支持情况仍要看实现资料与测试。规范允许、浏览器实现、当前项目可用，是三种不同结论。在笔记里分开写，比选一个来源覆盖全部场景更可靠。
七、把调研写成可交接的 Markdown
报告开头写任务范围和排除项，接着给简短结论，再逐项记录事实与依据。不要只在文末堆三个网站首页，让接手者自己猜每个判断来自哪里。
示例条目可以这样组织：
结论：成功提示要等待 writeText 的 Promise 成功完成。
依据：MDN Clipboard.writeText 的返回值说明。
适用范围：普通网页写入文字；不是读取或富文本复制。
待验证：本项目指定浏览器中，拒绝权限后是否正确展示失败提示。
实现建议：捕获错误；保留可选中文字与手动复制说明。再单列“尚未证明的事项”：企业受管浏览器、应用内 WebView、跨域嵌入、特定旧设备等。没有查到或没有测试的部分写未知，不把“暂时没看到反例”写成“完全支持”。
手动降级不应悄悄换成另一种有副作用的剪贴板操作。对用户来说，显示一段可选中文字并说明如何手动复制，往往比失败后仍弹出“复制成功”更清楚。是否采用旧接口，需另查弃用状态与实际支持情况，本篇不把它当作万能修复。
八、交接给实现者的验收清单
先用公开的虚构提示词验证正常点击，确认成功后再显示反馈；再检查不支持 API、操作被拒绝、非预期嵌入条件和焦点变化等分支。测试者需要知道操作会覆盖当前剪贴板，应自行选择可替换的测试内容，不读出或记录原来的私人内容。
检查按钮是否有可理解的名称，键盘能否聚焦和触发，失败提示是否可见，手动复制区是否仍可访问。接口调用成功不代表整个交互可用，辅助技术与实际设备检查也不能由一段文档推导出来。
记录浏览器版本、页面协议、是否嵌入、操作步骤、实际现象与截图位置。没有执行的项目标“待测”，不要为了报告齐整全部打勾。若实现者调整了触发时机或改到异步加载后调用，还应回头检查用户激活条件是否变化。
九、常见问题与维护
找不到 Skill 时先检查安装来源、路径与宿主是否加载，不要靠把文件夹改成热门产品名称解决。只有搜索摘要、没有原文时，应回到原始资料；链接打开失败就记录失败，不以其他网页对它的转述替代精确接口承诺。
笔记结论冲突时，先看两份资料是否讨论不同浏览器、不同接口或不同上下文，再核对更新时间与规范状态。仍无法确认，就保留争议并安排一个最小测试，不让模型自行选听起来更自信的说法。
维护重点是会影响实现的结论，而不是每天重写整份报告。浏览器支持范围、嵌入方式或接口政策变化后，重新核对相关条目，并保留修改原因。这样 research 才能成为从公开资料到工程决定之间的证据链，而不只是生成一篇带链接的长文。
还没有公开评论，欢迎分享你的想法。