看到一篇好文章，别急着复制：这个 Skill 会帮你收成 Markdown
我写公众号时，经常不是卡在写正文。
更常见的是，材料散得到处都是。
一篇网页文章，两个 X 上的帖子，一段 YouTube 视频字幕，再加上 Hacker News 下面几条有意思的评论。
这些东西都看过。真要写的时候，又找不到了。
以前我的做法很笨：打开网页，复制一段，粘到笔记里；再打开另一个页面，又复制一段。遇到图片、引用、标题层级，还要自己慢慢收拾。
收完以后，笔记看起来像一堆刚搬进屋的纸箱。
东西都在，但很难用。
baoyu-url-to-markdown 解决的就是这个问题：把网页内容抓下来，整理成干净的 Markdown。
它不是写作 Skill。
它更像写作前的收纳箱。
1. 它解决什么问题：材料先进屋
很多人让 AI 写文章，上来就是：
帮我写一篇关于某某主题的公众号文章。
AI 可以写。
但如果你没有给它材料，它只能凭通用知识写一篇通用文章。
通用文章最容易有一种毛病：句子顺，内容空。
你真正需要的是先把材料收进来。
比如你看到一篇英文教程，想把里面的思路拆成中文文章；或者看到一个 X thread，里面有几个很好的判断；又或者你想把 YouTube 视频字幕整理成读书笔记。
这时候，问题不是“AI 会不会总结”。
问题是：这些材料能不能先变成一个干净、可引用、可改写的文件。
baoyu-url-to-markdown 做的就是这一步。
它把 URL 变成 Markdown。对 X、YouTube、Hacker News 这些内容，还有专门的适配逻辑。遇到需要登录或验证码的页面，也有等待交互的模式。
这听起来像小事。
但写作里很多小麻烦，都是从这里开始的。
2. 直接看效果：网页变成可用材料
你可以给 AI 一个网页地址，然后说：
请用 baoyu-url-to-markdown 把这个网页保存成 Markdown，图片也尽量下载到本地。
它会做几件事：
- 打开页面，读取正文。
- 判断这个页面适合用哪种抓取方式。
- 把标题、正文、链接、图片整理成 Markdown。
- 保存到本地文件，后面可以继续总结、翻译、改写。
最后得到的是一个文件，不是一段临时复制出来的文字。
这点很实在。
文件意味着后面可以继续加工。
你可以让 AI 基于这个文件写摘要，可以提取观点，可以翻译，可以做成选题卡片，也可以把几篇材料合在一起，变成一篇自己的文章。
材料一旦落成文件，后面就不容易丢。
3. 怎么使用：最短上手路径
这个 Skill 在宝玉的 Skills 仓库里：
https://github.com/JimLiu/baoyu-skills
把这个 GitHub 地址扔给 AI，然后说：
帮我安装这个仓库里的 baoyu-url-to-markdown Skill。
装好以后，使用方式也不用复杂。
你给它一个 URL，再说你想保存成 Markdown 就行。
比如：
请把这个网页保存成 Markdown，放到我的资料目录里。
如果页面里有图片，可以补一句：
图片也下载到本地，和 Markdown 放在一起。
如果页面需要登录，也直接说：
如果需要登录或验证码，请打开浏览器等我处理。
普通读者不用记参数。
你要记住的只有一句话：把网页交给 AI，让它用这个 Skill 收成 Markdown。
4. 为什么好用：它把“抓网页”写成了流程
这个 Skill 好用，不在于它能打开网页。
能打开网页的工具很多。
它真正值得学的是三层设计。
第一，触发条件很清楚
只要用户说“保存网页”“URL 转 Markdown”“把这个帖子存下来”，它就该出场。
好的 Skill 不能等用户说出准确命令。
普通人不会说“请调用网页抓取适配器并输出 Markdown”。普通人只会说：“这篇文章帮我存一下。”
它的 description 写得很实在：看到 URL、保存网页、转 Markdown，就触发。
这很适合学习。
写 Skill 的时候，别只写能力名称。要写用户会怎么开口。
第二，它给不同来源留了不同处理方式
这一点其实不神奇，就是正常的工程处理。
普通网页、X thread、YouTube 字幕、Hacker News 评论，内容结构本来就不一样。
硬用同一种方式抓，当然也能抓出点东西，但后面总要人再收拾。
baoyu-url-to-markdown 这里比较实在：能识别的来源，就走对应的适配器；识别不了的，再走通用页面处理。
对用的人来说，这样就够了。
不用关心它背后怎么分流，只要最后拿到的 Markdown 别太乱。
第三，它把质量检查写进了 Skill
这个 Skill 里有一个提醒：默认的无头浏览器抓取，只能算临时结果。抓完以后要检查 Markdown。
这句话很值得学。
它没有假装工具永远可靠。
有些网站会给无头浏览器返回残缺页面。有些页面看起来抓到了，实际正文不完整。一个好 Skill 要把这种风险写出来。
Skill 不是只教 AI 怎么做。
也要教 AI 什么时候怀疑自己做得不够好。
5. 它到底是怎么实现的
这里要说清楚一件事。
baoyu-url-to-markdown 不是纯靠提示词，也不是让大模型自己打开网页、复制内容、整理成 Markdown。
真正干活的是一个 CLI：
skills/baoyu-url-to-markdown/scripts/baoyu-fetch
这个 CLI 是 Bun / TypeScript 写的。Skill 本身更像一份操作说明，告诉 AI 什么时候调用它、怎么生成输出路径、要不要下载图片、抓完以后怎么检查质量。
所以它实际是两层结构：
Skill：负责调度和规则
baoyu-fetch：负责抓取、解析、转换和保存
这里别讲错。
如果只写一个 Skill，让大模型“帮我保存网页”，效果不会稳定。网页抓取这种事，还是要靠浏览器、解析器和脚本。
我们拿一个具体场景看。
你丢给 AI 一个链接，说：
帮我把这篇文章保存成 Markdown，图片也下载到本地。
真正发生的事情，大概是这样。
第一步：AI 先决定怎么用这个工具
用户没有说文件名，也没有说用什么命令。
这时候 Skill 起作用。
它告诉 AI：只要用户想“保存网页”或“URL 转 Markdown”，就应该调用 baoyu-fetch。
AI 会先做几件很小但很实际的事：
1. 看这个输入是不是 URL。
2. 给输出文件取一个合理路径。
3. 判断用户要不要下载图片。
4. 组装出真正要执行的 CLI 调用。
比如最后会变成类似这样的动作：
baoyu-fetch https://example.com/article --output url-to-markdown/example/article/article.md --download-media
普通读者不用记这行命令。
但你要知道：AI 不是自己在网页上复制粘贴，它是在按 Skill 的说明去调用底层工具。
第二步：baoyu-fetch 用 Chrome 打开网页
接下来就是 CLI 干活。
它不会只做一个简单的 fetch(url)。
现在很多网页是前端渲染的。直接请求 HTML，可能只能拿到一个空壳，正文要等浏览器运行 JavaScript 后才出现。
所以 baoyu-fetch 会用 Chrome CDP 打开网页。
你可以把 CDP 理解成“脚本遥控 Chrome”：
打开网页
等待加载
滚动几次
观察网络请求
拿到页面 HTML
如果页面卡在登录、验证码、Cloudflare 检查，它也能检测出来，然后告诉 AI：这次不能硬抓，需要用户在浏览器里处理一下。
第三步：先看这个链接该交给谁处理
这里的 adapter，可以先理解成“某一类网站的专门处理器”。
为什么要有这个东西？
因为不同网站的内容藏在不同地方。
普通文章的正文，通常在页面 HTML 里。
YouTube 的重点不在页面正文，而在字幕和视频元数据里。
Hacker News 的重点是楼层评论。
X / Twitter 的重点常常在网页加载过程中返回的 JSON 数据里。
所以它不是拿到 URL 后都做同一件事。
它会先看这个链接属于哪类页面，再交给对应的处理器：
X / Twitter：走 x adapter
YouTube：走 youtube adapter
Hacker News：走 hn adapter
其他网页：走 generic adapter
比如你给的是 YouTube 链接，它就不会傻傻地把整个 YouTube 页面当文章抓。
它会优先拿字幕、章节、封面、视频信息。
你给的是 Hacker News，它就会保留评论层级。
你给的是普通文章，它才走通用网页处理。
这就是 adapter 的作用：不是“把 HTML 变 Markdown”的那一步，而是先决定“这个链接应该怎么取内容”。
第四步：普通文章怎么从网页变成 Markdown
如果是普通网页，就进入 generic adapter。
这一类最接近我们平时说的“网页转 Markdown”。
流程可以拆成三步。
第一步，先拿到浏览器里已经渲染出来的页面。
注意，不是把 HTML “转成网页”。
网页本来就在 Chrome 里打开了。脚本做的是从 Chrome 里把当前页面的 DOM 拿出来。
你可以把 DOM 理解成浏览器眼里的页面结构。
脚本会把这个结构复制一份，顺手做几件清理：
把相对链接改成完整链接
把懒加载图片的真实地址补上
把 Shadow DOM 里的内容展开
得到一份比较完整的 HTML
到这里，它拿到的是 HTML，还不是 Markdown。
第二步，从 HTML 里找正文。
网页 HTML 里有很多东西不是正文：
导航栏
广告
推荐阅读
评论区
页脚
登录弹窗
这些不能都塞进 Markdown。
所以它会先用 Defuddle 试着提正文。
如果效果不好，再用 Mozilla Readability 这类工具兜底。
你可以把它们理解成“正文过滤器”：从整页 HTML 里尽量挑出真正的文章主体。
第三步，把正文 HTML 转成 Markdown。
这一步用的是 Turndown。
比如网页里原本是：
<h2>标题</h2>
<p>正文第一段</p>
<img src="cover.png">
转出来大概会变成：
## 标题
正文第一段
所以普通网页的核心链路其实是：
Chrome 打开网页
-> 拿到渲染后的 DOM/HTML
-> Defuddle / Readability 提正文
-> Turndown 把正文 HTML 转 Markdown
-> 保存到本地文件
这里没有什么神秘的“AI 理解网页”。
AI 不负责把 HTML 一行行改成 Markdown。
真正转换格式的是脚本和库。
第五步：如果要下载图片，就把链接改成本地路径
如果你说“图片也下载到本地”，它会多做一步。
它会把 Markdown 里引用到的远程图片下载下来，放在文章旁边：
article.md
imgs/
image-1.png
image-2.png
videos/
video-1.mp4
然后把 Markdown 里的图片链接改成本地路径。
这样以后你整理材料、迁移文件、发给 AI 继续处理时，不会因为原网页图片失效而丢东西。
第六步：AI 再检查结果是不是靠谱
脚本跑完，不代表一定成功。
有些网站会返回登录页。
有些网站会返回一堆导航和广告。
有些页面正文很短，明显没抓完整。
这时候又轮到 AI 出场。
Skill 要求 AI 抓完后看一眼 Markdown：
标题是不是目标文章？
正文是不是够长？
有没有全是导航、登录、报错？
图片链接有没有处理好？
如果发现抓到的是登录页，AI 就应该换一种方式：
打开可见 Chrome
让用户登录或过验证码
再继续抓取
所以这套流程不是“AI 替代脚本”，也不是“脚本替代 AI”。
更准确地说：
脚本负责确定性的抓取和转换。
AI 负责把脚本用对、把异常看出来、把结果交给用户。
这才是 baoyu-url-to-markdown 真正值得学的地方。
如果你要实现类似的东西
可以参考它的分层，而不是只照抄一段提示词。
最小版本可以这样做：
1. 写一个 CLI，接收 URL 和输出路径。
2. 用 Chrome CDP 或 Playwright 打开网页。
3. 等页面加载完成，必要时滚动页面。
4. 用 Readability / Defuddle 提取正文。
5. 用 Turndown 把 HTML 转 Markdown。
6. 把 Markdown 写入文件。
7. 再写一个 Skill，告诉 AI 什么时候调用这个 CLI、怎么检查结果、失败时怎么重试。
如果要支持特殊网站，再加 adapter：
YouTube：单独提取字幕。
评论区：保留楼层结构。
社交帖子：处理 thread、引用、图片和视频。
普通网页：走通用正文提取。
这才是这类 Skill 真正值得学的地方。
不是“写一个很长的 Prompt”。
而是把大模型放在调度层，把确定性的抓取和转换交给脚本。
6. 可以怎么改
我最想改的版本，是“公众号选题资料箱”。
它不只是保存网页，还会在保存以后多做一步：
这篇材料适合写成什么选题？
里面有哪些可引用的判断？
有哪些地方需要二次核实？
这样一来，它就不只是资料抓取工具。
它会变成写作前的第一道整理工序。
对内容创作者来说，这一步很值。
因为很多文章不是缺表达，是缺材料。
材料都没进屋，别急着装修。
7. 最后给一个可复制的行动步骤
如果你只是想用：
下次看到一篇想收藏的网页，别先复制。直接把链接给 AI，说：
请用 baoyu-url-to-markdown 把它保存成 Markdown，图片也放到本地。
如果你想学着写：
记住这个设计：先判断材料类型，再选择处理方式，最后检查输出质量。
好 Skill 不只是跑通一步。
它要把容易丢、容易乱、容易抓残的地方，提前管起来。
