diff --git a/discussions/agents/GitHub助手GPT/2026-06-27-知乎、x文章.md b/discussions/agents/GitHub助手GPT/2026-06-27-知乎、x文章.md
new file mode 100644
index 0000000..551e770
--- /dev/null
+++ b/discussions/agents/GitHub助手GPT/2026-06-27-知乎、x文章.md
@@ -0,0 +1,327 @@
+# 1
+
+我现在有一个诉求，我提供URL，一般是知乎、小红书或者公众号和X上的，都是文章的链接，我需要把文章下载成md，带图。
+
+这个有没有现成的skill，我就不用重复造轮子了。
+
+你除了评估外，能否先做检索呢？
+
+可以，**以后你给 URL / GitHub 项目名时，我可以先做检索，再做评估**。
+针对你这个“知乎 / 小红书 / 公众号 / X 链接 → 下载成 Markdown，带图”的诉求，我刚检索了一轮，结论是：
+
+# 快速结论
+
+**不用从零造轮子。**
+
+但也不要期待一个工具完美覆盖四个平台。更现实的方案是：
+
+**主方案：OpenCLI 作为统一入口**
+**补充方案：微信公众号用专门工具兜底，小红书 / X 根据场景用专用 Skill 或插件兜底**
+**最后再做一个你自己的轻量 wrapper Skill：只负责识别 URL 域名、调用不同工具、整理输出目录。**
+
+这比自己重写爬虫、处理登录、图片懒加载、防盗链、反爬、X API 变化要划算很多。
+
+---
+
+# 1. 最值得先试的现成方案：OpenCLI
+
+## 一句话判断
+
+**OpenCLI 是目前最接近你需求的“统一型工具底座”。**
+
+它明确支持把多个网站变成 CLI，并且内置知乎、小红书、Twitter/X、微信公众号等适配器。README 里写到它可以用内置 adapter 处理 Bilibili、Zhihu、Xiaohongshu、Twitter/X 等站点，也可以通过 Chrome 登录态让 AI Agent 操作网页。([GitHub][1])
+
+它的下载支持页明确列出了这些能力：
+
+| 平台        | OpenCLI 官方说明里的能力       |
+| --------- | ---------------------- |
+| 小红书       | 下载 note 的图片、视频         |
+| Twitter/X | 下载用户媒体或单条 tweet 的图片、视频 |
+| 知乎        | 导出文章为 Markdown，可选下载图片  |
+| 微信公众号     | 导出公众号文章为 Markdown      |
+
+这些都出现在 OpenCLI 的 Download Support 文档里。([OpenCLI][2])
+
+## 对你这个需求的适配度
+
+**匹配度：高，但不是完全无脑。**
+
+OpenCLI 对知乎和公众号最贴近你的原始目标：
+知乎文档里有 `opencli zhihu download`，示例支持 `--download-images` 导出知乎文章为 Markdown 并下载图片。([GitHub][3])
+微信公众号文档里有 `opencli weixin download --url ... --download-images`，输出包含 Markdown frontmatter 和 images 目录。([GitHub][4])
+
+小红书这边，它更偏“下载 note 内容 / 图片 / 视频”，文档里有 `opencli xiaohongshu note` 读取完整笔记内容，有 `opencli xiaohongshu download` 下载图片和视频，但要注意它还提示很多小红书场景需要带 `xsec_token` 的完整 URL，裸 note ID 不可靠。([GitHub][5])
+
+X 这边，OpenCLI 有 `twitter thread`、`twitter article`、`twitter download` 等命令，其中 `download` 明确是下载 profile 媒体或单条 tweet 媒体；如果你的目标是“线程正文 + 图片 → Markdown”，可能需要组合 `thread/article + download`，或者交给一个 wrapper Skill 做整合。([GitHub][6])
+
+## 环境适配
+
+对你的 Windows 本地环境很友好：你有 Node.js 常用环境，且无 Docker / 无 WSL；OpenCLI 要求 Node.js >= 20，通过 `npm install -g @jackwener/opencli` 安装，并需要 Chrome/Chromium Browser Bridge 扩展。([GitHub][1]) 这比 Docker 化爬虫更适合你的本地环境。
+
+不太适合优先放 CentOS 远程，因为它依赖 Chrome 登录态和 Browser Bridge。你的远程 CentOS 虽然能 Docker、有公网 IP，但无 GPU不是问题，真正问题是远程浏览器登录态、Cookie、账号风控、端口暴露和会话隐私。你的本地 Windows + Chrome 登录态更自然，也符合你常用 Python/Node、Codex/Claude Code 的习惯。
+
+---
+
+# 2. 第二个值得看：web2md Skill
+
+## 一句话判断
+
+**web2md 是一个更像“正好为你这个诉求写的 Claude/Codex Skill”，但项目很新，成熟度低。**
+
+它的 GitHub README 写得很直接：把微信公众号文章和网页转成 Markdown，下载所有图片到本地，保留格式，并添加 YAML frontmatter。([GitHub][7])
+
+它的工作方式是：
+
+1. 用 Playwright 打开页面；
+2. 滚动触发懒加载图片；
+3. 抽取标题、作者、日期等元数据；
+4. 清理广告和非正文区域；
+5. 下载图片到本地 images 目录；
+6. HTML 转 Markdown；
+7. 写入带 frontmatter 的 `.md` 文件。([GitHub][7])
+
+这套逻辑非常接近你想要的“URL → md + images”。
+
+## 但问题也很明显
+
+它现在只有 0 stars、0 forks、2 commits、无 release。([GitHub][7])
+所以我不会建议你把它当成熟工具长期依赖。更合理的定位是：
+
+**可以收藏、试跑、借鉴 Skill 结构，但不建议直接当主力。**
+
+它要求 Python 3.9+ 和 Google Chrome。([GitHub][7]) 这对你的 Windows 本地没问题；但 Playwright / Chrome 自动化在不同网页上失败概率不低，尤其是公众号、小红书、X 这种强平台页面。
+
+---
+
+# 3. 微信公众号专用：wechat-article-to-markdown
+
+## 一句话判断
+
+**如果你的公众号文章保存需求很高，这个比通用工具更值得单独试。**
+
+`jackwener/wechat-article-to-markdown` 明确支持：
+
+* 抓取微信公众号文章；
+* 提取标题、账号名、发布时间、来源 URL；
+* 转 Markdown；
+* 下载图片到本地 `images/` 并重写链接；
+* 处理微信代码块。([GitHub][8])
+
+安装方式也比较友好：推荐 `uv tool install wechat-article-to-markdown`，也支持 `pipx install`。([GitHub][8])
+输出结构正好是 `<article-title>.md + images/`。([GitHub][8])
+
+## 对你的价值
+
+**公众号方向：值得本地试跑。**
+
+它比 web2md 更聚焦，输出结构也符合知识库归档。主要风险是它使用 Camoufox 做 anti-detection fetching，这意味着依赖浏览器自动化/反检测能力，后续微信页面结构或风控策略变化时可能失效。([GitHub][8])
+
+---
+
+# 4. 小红书专用方案
+
+小红书比公众号和知乎更麻烦，因为很多“有价值内容”其实在图片里，不只是 HTML 正文。
+
+我检索到几个方向：
+
+## A. OpenCLI 小红书 adapter
+
+OpenCLI 支持 `xiaohongshu note` 读取笔记正文、作者、描述、点赞、收藏、评论、标签，也支持 `xiaohongshu download` 下载图片和视频。([GitHub][5])
+
+这是我建议你优先试的方案。
+
+## B. xhs-note-to-md
+
+`DrErwin/xhs-note-to-md` 明确是“小红书帖子转 Markdown 文档”，支持正文、图片、OCR、评论区，并且说明适合把小红书知识帖、长图笔记、截图文章整理成本地文档。([GitHub][9])
+
+但它依赖 `xiaohongshu-skills`、浏览器插件桥接、小红书账号登录，以及至少一个 OCR 引擎。([GitHub][9])
+这说明它更像“Codex Skill 拼装工作流”，不是一个独立成熟 CLI。
+
+对你来说：**可以作为 Skill 候选，但建议先交给 Codex/Claude Code 体检，不建议直接盲装。**
+
+## C. xiaohongshu-importer
+
+这是 Obsidian 插件，能从小红书分享链接导入标题、正文、图片、视频和标签，并可选择把媒体下载到 Obsidian vault。([GitHub][10])
+
+如果你最终目标是 Obsidian 知识库，这个值得试；如果你想做通用 URL → Markdown 自动化，它不如 OpenCLI 或自定义 wrapper 灵活。
+
+---
+
+# 5. X / Twitter 方案
+
+X 是四个平台里最不稳定的，因为登录态、GraphQL、风控、API 变化都比较频繁。
+
+## A. OpenCLI X adapter
+
+OpenCLI 有 `twitter thread`、`twitter article`、`twitter download` 等命令。`twitter download` 文档明确支持从用户媒体页或单条 tweet URL 下载媒体。([GitHub][6])
+
+但我没有看到它直接承诺“一条 X 链接 → Markdown + 图片完整归档”。所以它更像底层能力，而不是成品归档工具。
+
+## B. baoyu-danger-x-to-markdown
+
+这个是一个 X to Markdown Skill，描述里说可以把 tweets / threads 转 Markdown，也能提取 X Articles，并生成 YAML frontmatter。([LobeHub][11])
+
+但它自己也强调使用 reverse-engineered X API，并且需要用户同意后才继续。([LobeHub][11])
+这类工具我会谨慎放入长期系统：能用，但容易因为 X 改接口而失效，也存在账号风控和合规风险。
+
+---
+
+# 6. 通用网页兜底：MarkDownload
+
+MarkDownload 是浏览器扩展，可以把网页剪藏成可读 Markdown，并支持 Chrome、Firefox、Edge、Safari。([GitHub][12])
+
+优点是成熟度高，GitHub 上约 3.9k stars，浏览器插件形态也适合人工快速保存。([GitHub][12])
+
+但它自己也提醒“不保证所有网站都能工作”。([GitHub][12])
+对你这个诉求，它适合做：
+
+**人工兜底工具，不适合做自动化主力。**
+
+尤其小红书、X、公众号这类登录态/动态加载/反爬较多的平台，不应该指望普通 Readability + Turndown 一把梭。
+
+---
+
+# 7. 推荐路线
+
+## 我建议你不要造完整爬虫
+
+你真正该做的是一个很薄的 **URL Router Skill**：
+
+```text
+输入：URL
+↓
+识别域名
+↓
+调用对应工具
+↓
+统一输出目录结构
+↓
+生成 article.md + images/ + metadata.json
+↓
+可选：写入 Obsidian / 知识库 / Dify / OpenClaw
+```
+
+推荐路由：
+
+| URL 类型                             | 优先工具                                     | 兜底工具                                  |
+| ---------------------------------- | ---------------------------------------- | ------------------------------------- |
+| `mp.weixin.qq.com`                 | OpenCLI weixin download                  | wechat-article-to-markdown / web2md   |
+| `zhuanlan.zhihu.com` / `zhihu.com` | OpenCLI zhihu download --download-images | MarkDownload                          |
+| `xiaohongshu.com` / `xhslink.com`  | OpenCLI xiaohongshu note + download      | xhs-note-to-md / xiaohongshu-importer |
+| `x.com` / `twitter.com`            | OpenCLI twitter thread/article/download  | baoyu-danger-x-to-markdown            |
+| 普通网页                               | web2md / MarkDownload                    | 自己用 Readability + Playwright          |
+
+---
+
+# 8. 评分表
+
+| 方案                         | 覆盖你的需求 | Skill/Agent 价值 | Windows 本地可行性 |   成熟度 | 风险 | 结论                |
+| -------------------------- | -----: | -------------: | ------------: | ----: | -: | ----------------- |
+| OpenCLI                    |  4.5/5 |            5/5 |           4/5 |   4/5 |  中 | **主推，先试**         |
+| wechat-article-to-markdown |    4/5 |          3.5/5 |           4/5 | 3.5/5 |  中 | **公众号专用首选**       |
+| web2md                     |    4/5 |          4.5/5 |           4/5 |   2/5 | 中高 | **适合借鉴/试跑，不宜主力**  |
+| xhs-note-to-md             |    4/5 |          4.5/5 |           3/5 |   2/5 |  高 | **Skill 候选，需体检**  |
+| xiaohongshu-importer       |  3.5/5 |          2.5/5 |           4/5 |   3/5 |  中 | **Obsidian 用户可试** |
+| baoyu-danger-x-to-markdown |  3.5/5 |            4/5 |           3/5 |   3/5 |  高 | **X 兜底，不宜长期依赖**   |
+| MarkDownload               |    3/5 |            2/5 |           5/5 |   4/5 | 低中 | **人工兜底很好**        |
+
+---
+
+# 9. 我的明确建议
+
+## 主动作
+
+**先试 OpenCLI。**
+
+原因很简单：它同时覆盖你提到的四类平台，并且已经有 Claude/Codex Skill 化方向；它不是单纯爬虫，而是“浏览器登录态 + CLI adapter + Agent 可调用”的工具底座，和你的 AI Skill / Agent / 自动化工作流方向最匹配。([GitHub][1])
+
+## 次动作
+
+把 `wechat-article-to-markdown` 作为公众号专用兜底工具。
+公众号文章的保存需求如果频繁，这个项目更直接，输出目录也很符合你的 Markdown 知识库归档需求。([GitHub][8])
+
+## 不建议做的事
+
+不要一开始就自己写：
+
+* 小红书解析器；
+* X GraphQL 解析器；
+* 微信图片防盗链下载器；
+* 通用反爬浏览器自动化框架。
+
+这些都是维护黑洞。你要做的是**整合层 Skill**，不是平台爬虫内核。
+
+---
+
+# 10. 最小试跑路径
+
+你可以先按这个顺序试：
+
+```bash
+# 1. 安装 OpenCLI
+npm install -g @jackwener/opencli
+
+# 2. 检查 Node >= 20
+node --version
+
+# 3. 安装/启用 OpenCLI Browser Bridge 扩展
+opencli doctor
+
+# 4. 试公众号
+opencli weixin download --url "https://mp.weixin.qq.com/s/xxx" --download-images --output ./articles/weixin
+
+# 5. 试知乎
+opencli zhihu download "https://zhuanlan.zhihu.com/p/xxx" --download-images --output ./articles/zhihu
+
+# 6. 试小红书
+opencli xiaohongshu download "https://xhslink.com/..." --output ./articles/xhs
+
+# 7. 试 X 单条媒体
+opencli twitter download --tweet-url "https://x.com/user/status/xxx" --output ./articles/x
+```
+
+然后再让 Codex/Claude Code 做一个 wrapper：
+
+```text
+给定任意 URL：
+1. 判断域名；
+2. 调用对应 opencli 命令；
+3. 如果失败，切换到专用兜底工具；
+4. 输出统一目录：
+   /saved_articles/
+     /{platform}/
+       /{date}-{slug}/
+         article.md
+         images/
+         metadata.json
+         raw.html 可选
+5. 不自动批量抓取，不绕过登录，不保存 cookie/token。
+```
+
+---
+
+# 项目卡片
+
+* **一句话定位**：URL 到 Markdown + 图片的需求已有现成工具，OpenCLI 最适合做统一底座。
+* **适用场景**：知乎文章、公众号文章、小红书笔记、X thread/article/media 的个人归档与知识库输入。
+* **不适用场景**：大规模采集、绕登录、绕风控、批量抓私域内容、商业爬取。
+* **对你的价值**：高，适合做成长期 Skill / Agent 工具节点。
+* **运行要求**：Windows 本地优先；Node.js >= 20；Chrome/Chromium；部分平台需要登录态；公众号兜底可用 Python/uv 工具。
+* **主要风险**：平台反爬、登录态失效、X 接口变化、小红书链接 token 失效、图片防盗链、版权和合规。
+* **推荐动作**：先试 OpenCLI；公众号单独试 `wechat-article-to-markdown`；再写一个轻量 URL Router Skill。
+* **是否进入 Codex 深挖**：是。
+* **后续动作**：让 Codex 检查 OpenCLI 的四个平台 adapter，并实现一个统一输出的 wrapper Skill。
+
+[1]: https://github.com/partme-ai/opencli/blob/main/README.md "opencli/README.md at main · partme-ai/opencli · GitHub"
+[2]: https://opencli.info/docs/advanced/download.html "Download Support | OpenCLI"
+[3]: https://github.com/partme-ai/opencli/blob/main/docs/adapters/browser/zhihu.md "opencli/docs/adapters/browser/zhihu.md at main · partme-ai/opencli · GitHub"
+[4]: https://github.com/partme-ai/opencli/blob/main/docs/adapters/browser/weixin.md "opencli/docs/adapters/browser/weixin.md at main · partme-ai/opencli · GitHub"
+[5]: https://github.com/partme-ai/opencli/blob/main/docs/adapters/browser/xiaohongshu.md "opencli/docs/adapters/browser/xiaohongshu.md at main · partme-ai/opencli · GitHub"
+[6]: https://github.com/partme-ai/opencli/blob/main/docs/adapters/browser/twitter.md "opencli/docs/adapters/browser/twitter.md at main · partme-ai/opencli · GitHub"
+[7]: https://github.com/AllenZenghuge/web2md "GitHub - AllenZenghuge/web2md: 微信公众号/网页转 Markdown skill，自动下载图片、生成 frontmatter · GitHub"
+[8]: https://github.com/jackwener/wechat-article-to-markdown "GitHub - jackwener/wechat-article-to-markdown: 微信公众号文章抓取 & Markdown 转换工具 · GitHub"
+[9]: https://github.com/DrErwin/xhs-note-to-md "GitHub - DrErwin/xhs-note-to-md: `xhs-note-to-md` 用于把小红书帖子转换成 Markdown 文档。  它依赖 `xiaohongshu-skills` 获取帖子内容，也可以配合 OCR 识别图片里的文字。适合把小红书知识帖、长图笔记、截图文章整理成本地文档。 · GitHub"
+[10]: https://github.com/bnchiang96/xiaohongshu-importer "GitHub - bnchiang96/xiaohongshu-importer: An Obsidian plugin to import Xiaohongshu (小红书) notes into your vault. Extract titles, content, images, videos, and tags from share links, with customizable categories and optional local media downloads. · GitHub"
+[11]: https://lobehub.com/skills/jimliu-baoyu-skills-baoyu-danger-x-to-markdown "baoyu-danger-x-to-markdown | Skills ... · LobeHub"
+[12]: https://github.com/deathau/markdownload "GitHub - deathau/markdownload: A Firefox and Google Chrome extension to clip websites and download them into a readable markdown file. · GitHub"
+
diff --git a/discussions/agents/Suno共创助手/在路上讨论.md b/discussions/agents/Suno共创助手/在路上讨论.md
index dd6ec67..42df850 100644
--- a/discussions/agents/Suno共创助手/在路上讨论.md
+++ b/discussions/agents/Suno共创助手/在路上讨论.md
@@ -554,3 +554,90 @@ Acoustic indie road rock, close mic singing, intimate male vocal, conversational
 泥泞里
 有星空
 
+---
+
+# 5
+
+这首歌我做出来了，效果不错。
+
+我希望再做一个纯音乐的，下面是当时用的风格：
+
+```md
+Acoustic indie road rock, warm folk rock, intimate male vocal, warm low register, acoustic guitar upfront, steady mid-tempo beat, linear build-up, strophic form, delayed explosive chorus, cinematic wide soundstage, unhurried pacing, -shout singing
+```
+
+保持`Acoustic indie road rock`，改成纯音乐，且情绪递进。这个风格帮我改一下。
+
+另外歌词部分，我选中`instrumental`，还是需要一个音乐的lyrics.
+
+太棒了，很高兴上一版的人声版本达到了您的预期！
+
+针对纯音乐（Instrumental）版本，虽然您在 Suno 中勾选了 `Instrumental` 开关，但**在歌词框（Lyrics）中提供纯音乐的结构化控制文本，是顶级玩家用来引导 AI 情绪起伏、乐器进出以及实现“线性递进（Linear build-up）”的关键技巧**。
+
+我们将去掉之前所有关于人声的标签，并强化器乐的层次感与电影级的递进张力。
+
+### 🎛️ 纯音乐版 Styles 提示词 (Instrumental Styles)
+
+**【全英文提示词】**(请直接复制并替换原有的 Styles)
+
+> Acoustic indie road rock, Instrumental, no vocals, acoustic guitar upfront, steady mid-tempo beat, linear build-up, layered acoustic textures, slow-burn crescendo, cinematic wide soundstage, deep reverb, unhurried pacing
+
+**【核心改动解析】**
+
+* **Instrumental, no vocals**（纯器乐，无人声）：强化底层逻辑，确保系统绝对不生成任何杂音或呢喃。
+* **layered acoustic textures**（层叠的原声质感）：替代原先的人声位置，提示 AI 用不同频段的乐器（如木吉他、贝斯、原声打击乐）来填补旋律线。
+* **slow-burn crescendo**（慢热型渐强爆发）：完美契合您想要的“线性递进（linear build-up）”，让情绪像是在旷野中行驶，逐渐走向开阔。
+
+---
+
+### 📝 纯音乐结构控制文本 (Instrumental Lyrics Structure)
+
+*(注：请将以下带括号的提示文本完整复制到 Suno 的 Lyrics 框中。Suno 会识别方括号 `[ ]` 中的段落标签来控制曲式，同时会识别圆括号 `( )` 中的英文动作指令来增减乐器与调度情绪。)*
+
+```text
+[Intro]
+(Gentle acoustic guitar picking)
+(Subtle ambient wind sound)
+(Unhurried pacing)
+
+[Verse 1]
+(Steady mid-tempo beat enters)
+(Warm folk rock bassline joins the guitar)
+(Melodic acoustic guitar playing)
+
+[Verse 2]
+(Adding subtle harmonica and soft strings)
+(Linear build-up, rhythm driving forward)
+(Layered acoustic textures expanding)
+
+[Pre-Chorus]
+(Music swells)
+(Tempo slightly pushing)
+(Deep reverb applied to drums)
+
+[Chorus]
+(Cinematic wide soundstage)
+(Full instrumental crescendo)
+(Emotional and powerful acoustic rock arrangement)
+
+[Bridge]
+(Stripped-down arrangement)
+(Deep spatial reverb)
+(Solitary acoustic guitar melody)
+
+[Guitar Solo]
+(Emotional acoustic rock guitar solo)
+(Building up the tension again)
+
+[Chorus]
+(Explosive instrumental return)
+(Grand and expansive feeling)
+(Wide stereo field, soaring melodies)
+
+[Outro]
+(Instruments gradually stripping away)
+(Acoustic guitar slowly fading out)
+(Lingering unresolved chord, ending in the wind)
+
+```
+
diff --git a/discussions/agents/Suno共创助手/在路上风格系列.md b/discussions/agents/Suno共创助手/在路上风格系列.md
new file mode 100644
index 0000000..282acde
--- /dev/null
+++ b/discussions/agents/Suno共创助手/在路上风格系列.md
@@ -0,0 +1,5 @@
+# 1
+
+`Acoustic indie road rock, warm folk rock, acoustic guitar upfront, subtle harmonica, steady mid-tempo beat, cinematic wide soundstage, deep reverb, unhurried pacing, emotional build-up, studio quality, ‑belting vocals, ‑aggressive projection`
+
+
diff --git a/discussions/technology/Codex/2.重构知识库/4.下载文章.md b/discussions/technology/Codex/2.重构知识库/4.下载文章.md
new file mode 100644
index 0000000..e1a527c
--- /dev/null
+++ b/discussions/technology/Codex/2.重构知识库/4.下载文章.md
@@ -0,0 +1,159 @@
+# 1
+
+由于skill-vault和CCPE来做skill和Agent，你可以阅读`C:\Users\wangq\Documents\Codex\video-workbench\requirements\`下的readme了解其他库如何向这两库提需求。
+
+我现在的目标是下载文章，将下载后的文章放到`C:\Users\wangq\Documents\Codex\knowledge-vault\sources\web-archives\`下面。
+一般我会给URL，可能是知乎、公众号或者x上的URL，需要你下载后，最好能做个分类，放到`web-archives`，做个简单分类。
+我之前在别的机器上做了这个skill，参见`D:\article-download\`。
+
+我的计划是，你作为需求方，提出需求单，我让skill-vault参考`D:\article-download\`完成skill的开发，然后在这里做试运行下载。
+
+那么你提需求的话，
+1. 参考`D:\article-download\`的功能能力
+2. 向我提问
+
+由于`D:\article-download\`做的比较早，比较麻烦的是，我得提供cookie；现在Codex本身有browser或者Chromeskill，这个之前也做了调研：`C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\3.Codex Browser与Chrome技能调研.md`
+
+或者本身有其他skill也行。这是我和ChatGPT交流，它给的建议：`C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\GitHub助手GPT\2026-06-27-知乎、x文章.md`
+
+总之，你作为需求方，和我讨论完具体需求后，写skill的需求单，不用太关注实现细节。
+我拿着skill需求单到skills-vault中打造这个skill。
+你更关心的应该是如何存到哪里，怎么命名，考虑到md+图片，应该建立一个文件夹；分类划分这些。
+
+---
+
+现在提出问题，谈谈你的建议。
+
+我建议这个需求不要叫“文章下载爬虫”，而叫“网页文章归档 Skill”。核心不是重写各平台抓取器，而是：给定 URL，识别平台，选择合适采集方式，把结果稳定落到 `knowledge-vault/sources/web-archives/`，并保留来源、图片、失败记录和可追溯元数据。
+
+**我的建议**
+
+目录结构用“平台优先”，不要一开始按主题建深目录。主题分类容易误判，平台和日期是稳定事实；主题可以写进 metadata/frontmatter，后面再整理。
+
+建议默认结构：
+
+```text
+C:\Users\wangq\Documents\Codex\knowledge-vault\sources\web-archives\
+  zhihu\
+    2026\
+      2026-06-27--文章标题slug--urlhash\
+        article.md
+        images\
+          img-001.jpg
+        metadata.json
+        capture-log.md
+  wechat\
+  x\
+  xiaohongshu\
+  general\
+  inbox\
+```
+
+`article.md` 固定命名，比“文章标题.md”更稳，避免 Windows 路径过长和图片链接迁移问题。标题放在 frontmatter 和正文 H1。文件夹名用 `发布日期或抓取日期 + 标题slug + URL短hash`，可以天然防重复。
+
+每篇至少保留：
+
+```text
+article.md        # 正文 Markdown，图片链接改成本地相对路径
+images/           # 本地图片
+metadata.json     # url、canonical_url、platform、title、author、published_at、captured_at、tool、login_surface、image_count、failed_assets、topics
+capture-log.md    # 本次抓取过程、失败项、是否用了登录态、是否有人工确认
+```
+
+`raw.html` 和截图我建议作为可选项：公众号、知乎长文可以留 `raw.html`；X、小红书这类动态平台至少留截图或 capture-log，方便以后知道当时看到的是什么。
+
+旧 `D:\article-download\` 值得继承的能力是：URL 路由、微信/知乎/X 平台适配、标题/作者/日期抽取、图片本地化、成功后报告路径和图片数。不要继承的是硬编码路径、cookie 文件依赖、输出到 `temp/downloads`、以及覆盖旧目录的习惯。
+
+浏览器能力上，我建议需求单这样写：默认优先公开页面/干净 browser；需要真实登录态时才用 Chrome/Edge profile；不读取或保存 cookie/token/localStorage；遇到 CAPTCHA、风控、付费墙、私密内容、批量下载媒体时暂停确认。X 和小红书尤其应该先做“低频、用户可见页面归档”，不要把需求写成反爬工具。
+
+**我需要先确认的关键问题**
+
+1. 你希望“简单分类”主要按什么来分？
+
+我建议默认选 A：
+
+A. `平台 / 年份 / 单篇文件夹`，主题只进 metadata  
+B. `主题 / 平台 / 单篇文件夹`，更像知识管理但需要更多人工判断  
+C. `平台 / 主题 / 年份 / 单篇文件夹`，折中但目录会更复杂
+
+后续还需要确认几个点：是否默认保存 `raw.html`，是否保存页面截图，X/小红书是否只归档图文不下载视频，遇到已存在 URL 是跳过、覆盖还是新建版本，以及是否需要维护一个 `web-archives/index.md`。我建议先把第 1 个目录原则定下来，再写正式 skills-vault 需求单。
+
+# 2
+
+其实，对我来说，我不关心平台。
+`C:\Users\wangq\Documents\Codex\knowledge-vault\sources\clipped-articles\文章参考`是从旧的知识库移植过来的，没有分类，那就日期加标题简称也行。
+
+这个是个轻量的，我不希望有抓取的文章内容之外的，log，json这些。
+这些抓取的文章，是我之后要进行讨论的素材；讨论后，就失去了它的意义。
+讨论，沉淀观点；沉淀的观点，有可能会进入后续的写作。对我来说，核心是沉淀的观点。
+而抓取的文章，讨论后，甚至可以删掉了；这个只是省我一些复制粘贴的工作，而有些网站会防止复制粘贴，我会麻烦一些，F12，看源码来复制粘贴。
+
+了解了这些后，你对这个有什么想法？
+
+我会把需求明显收轻：
+
+这不是“网页归档系统”，而是“临时文章剪藏器”。平台只作为内部路由，不进入目录分类；也不需要 `metadata.json`、`capture-log.md`、`raw.html`、截图、审计记录。成功标准就是：给 URL，生成一个文章文件夹，里面有一篇 `.md` 和本地图片，能用于后续讨论。
+
+我建议输出结构直接模仿旧的 `sources\clipped-articles\文章参考`：
+
+```text
+sources\web-archives\
+  20260627-标题简称\
+    标题.md
+    img_1.jpg
+    img_2.jpg
+```
+
+或者如果你想延续旧知识库语义，也可以直接放到：
+
+```text
+sources\clipped-articles\文章参考\
+```
+
+这点我现在反而倾向于后者：它的含义更接近“抓取的文章原文素材”。`web-archives` 听起来更长期、更可追溯，而你现在明确说这些素材讨论后可以失去意义，甚至可删。
+
+需求单里我会这样定边界：
+
+- 不做平台分类目录。
+- 不生成 log/json。
+- 不做长期索引。
+- 不做主题分类。
+- 不保留 cookie/token。
+- 不追求完整网页存证。
+- 不批量采集。
+- 只做“URL -> Markdown + 图片本地化”。
+- 文件夹命名：优先 `发布日期-标题简称`；拿不到发布日期就用抓取日期。
+- 图片命名：`img_1.jpg` 这种简单序号即可。
+- 重复 URL 或重名时，只追加 `-2` 或短 hash，别引入复杂版本系统。
+
+唯一还需要你拍板的是：`.md` 里要不要额外加一行原文链接。我的建议是加，因为以后讨论时还能回源；但如果你坚持“只要文章内容”，那就连这行也不加。
+
+# 3
+
+可以，还是放到`clipped-articles\文章参考`
+`.md`不需要原文链接。
+我用于讨论，大部分讨论是批判性讨论，这些文章的作用，就是当个靶子。
+因为，自媒体平台的帖子，大部分质量不高，一篇里面漏洞很多，能借用的，就一两个观点。
+
+现在可以准备这个需求单了吧。
+
+已准备好需求单：[lightweight-web-article-clipper.md](C:/Users/wangq/Documents/Codex/knowledge-vault/requirements/skills-vault/lightweight-web-article-clipper.md)。
+
+我把它写成轻量“文章剪藏器”需求，而不是归档系统：输出到 `sources/clipped-articles/文章参考`，不按平台分类，不生成 `json/log/raw.html/screenshot/index`，`.md` 里默认不放原文链接，只保留标题、正文和本地图片。也写清楚了边界：不保存 cookie/token，不绕 CAPTCHA/付费墙/风控，不做批量爬取，不把这些自媒体文章提升成长期知识资产。
+
+检查过内容和 git 状态；当前除了这个新 `requirements/` 目录外，仓库里还有一些原本已存在的未跟踪/修改文件，我没有碰它们。未运行测试，因为这次只新增需求文档。
+
+# 4
+
+这个`clipped-articles`技能已经做好了。
+你了解下这个技能，它也支持批处理。所以我给你本次需要下载的URL就好。
+
+* `https://www.zhihu.com/question/1998112125915267964/answer/2052741315209831340`
+* `https://www.zhihu.com/pin/2042210955053065858`
+* `https://x.com/dotey/status/2069632132431929651`
+* `https://mp.weixin.qq.com/s/TApHplXcBONvmVXgDKUUOg`
+
+---
+
+我以后说“下载文章”，然后给你链接，或者一组链接。你就调用这个技能。
+
diff --git a/discussions/technology/Codex/4.Skills/article-clipper.md b/discussions/technology/Codex/4.Skills/article-clipper.md
new file mode 100644
index 0000000..5213095
--- /dev/null
+++ b/discussions/technology/Codex/4.Skills/article-clipper.md
@@ -0,0 +1,231 @@
+# 1
+
+这个是新的技能需求，[lightweight-web-article-clipper.md](C:/Users/wangq/Documents/Codex/knowledge-vault/requirements/skills-vault/lightweight-web-article-clipper.md)
+
+这个是我以前的在其他机器上的类似技能，`D:\article-download\`。这个缺点是，每次我得提供cookie。
+
+这是我和ChatGPT交流，它给的建议：`C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\GitHub助手GPT\2026-06-27-知乎、x文章.md`
+
+---
+
+关于这个技能，有什么问题和想法？
+
+我倾向于做，但不要按“爬虫平台包”来做。
+
+核心判断：`clip-web-article` 应该是一个轻量 Skill，默认保存“当前可见文章材料”，然后做统一输出规整；旧的 `D:\article-download` 只能作为参考，不能直接迁移。旧实现里最大的问题不只是 cookie，而是硬编码机器路径、输出到 `temp/downloads`、平台子目录、部分脚本会删除已有输出目录，并且把作者/日期/分隔线等塞进正文，和这次需求相反。
+
+主要问题有几个：
+
+1. **OpenCLI 可作为底座，但不能直接等于成品。** 它当前文档确实覆盖知乎、微信公众号、小红书、Twitter/X 等下载能力，也要求 Node >= 20 和 Browser Bridge；本机 Node 是 `v24.14.1`，但还没有 `opencli` 命令。它的输出通常会带 frontmatter、images 子目录或平台语义，需要 wrapper 再清洗。参考：[OpenCLI docs](https://opencli.info/docs/)。
+
+2. **cookie 不应该再进入默认路径。** 正确边界是：公开页能抓就直接抓；需要登录时，让用户在连接的 Chrome/Edge 里打开页面，Skill 只读可见 DOM/页面内容，不读、不保存 cookie/localStorage/token。OpenCLI 的 Browser Bridge 思路比“粘贴 cookie”更接近这个方向。
+
+3. **小红书和 X 要降级预期。** 小红书很多价值在图片里，OCR 不应默认做；X 的 thread/article/media 抽取很容易混入回复、引用、时间线内容。初版应接受“正文 + 可见图”而不是完整平台归档。
+
+4. **脚本部分应只做确定性工作。** 我建议内置脚本负责：标题清洗、非覆盖目录创建、Markdown 清洗、图片下载/重命名、相对链接重写、失败图片保留可读内容。平台登录和可见页面获取交给 OpenCLI 或浏览器自动化，不在脚本里实现绕风控。
+
+5. **依赖要补。** 当前 `skills-vault` conda 环境没有 `requests`、`bs4`、`markdownify`、`playwright`。如果做 Python 实现，要更新 `environment.yml` 并验证；如果 OpenCLI-first，则要把 Node/OpenCLI/Browser Bridge 作为外部依赖检查，而不是悄悄假设存在。
+
+推荐方案：**Hybrid thin wrapper**。
+
+- Skill 名用 `clip-web-article`。
+- 默认输出到 `knowledge-vault\sources\clipped-articles\文章参考`。
+- 优先用公开页面或已连接浏览器获取可见内容。
+- OpenCLI 可用时优先借它处理知乎/公众号等成熟路径。
+- 统一后处理成：一个文件夹、一个 `.md`、同级 `img_1.jpg` 这类图片。
+- 不写 metadata、log、raw html、原始 URL、frontmatter。
+- 单元测试只测本地 fixture 和后处理；真实平台只做手动 smoke。
+
+我唯一想先确认的决策是：初版是否接受 **OpenCLI 作为可选/优先底座**？我的建议是接受，但 Skill 必须能在 OpenCLI 不存在时给出清楚失败原因或走浏览器可见页面兜底，而不是把 OpenCLI 变成隐形硬依赖。
+
+# 2
+
+**我更不希望重新造轮子。**
+
+接受 **OpenCLI 作为可选/优先底座**，可以把这个 OpenCLI 变成硬依赖。OpenCLI我已经装了。
+
+或者你基于`article-download`改造也行，只要别让我手工提供cookie就行。`article-download`是我之前用Openclaw打造的，更贴合我的使用。你照着`article-download`做，只要能测试通，反而会少了很多后续的调整。
+
+---
+
+这个技能本身就很轻，意义对我来说也是，只是替代我日常的手工，下面是和knowledge-vault讨论需求时，我说的：
+
+```txt
+这个是个轻量的，我不希望有抓取的文章内容之外的，log，json这些。
+这些抓取的文章，是我之后要进行讨论的素材；讨论后，就失去了它的意义。
+讨论，沉淀观点；沉淀的观点，有可能会进入后续的写作。对我来说，核心是沉淀的观点。
+而抓取的文章，讨论后，甚至可以删掉了；这个只是省我一些复制粘贴的工作，而有些网站会防止复制粘贴，我会麻烦一些，F12，看源码来复制粘贴。
+```
+
+---
+
+需要注意的是：
+* 知乎分两种，讨论与文章。
+* X也做了处理
+* 另外是翻译，保留英文和中文
+
+这些在旧的`article-download`中都处理了。
+
+---
+
+下面给些测试的URL，可供你测试用。
+
+知乎讨论URL：`https://www.zhihu.com/question/1998112125915267964/answer/2052741315209831340`
+知乎文章URL：`https://www.zhihu.com/pin/2042210955053065858`
+
+x的，`https://x.com/dotey/status/2069632132431929651`
+
+公众号的：`https://mp.weixin.qq.com/s/TApHplXcBONvmVXgDKUUOg`
+
+小红书的可以忽略。
+
+---
+
+你根据以上判断下，有问题提出，没问题可以去做这个skill了。
+
+已做成 `clip-web-article` Skill，并安装到：
+
+`C:\Users\wangq\.agents\skills\clip-web-article`
+
+实现上按你的取舍走：OpenCLI 是硬依赖，旧 `article-download` 的行为只保留为参考取向。新脚本不读 cookie 文件、不要求手工粘贴 cookie，最终输出只保留 `标题.md` 和同级 `img_N.ext` 图片；OpenCLI 产物里的 frontmatter、原文链接、`images/` 子目录会被压平成你要的轻量形态。
+
+主要文件：
+- [SKILL.md](C:/Users/wangq/Documents/Codex/skills-vault/skills/clip-web-article/SKILL.md)
+- [clip_web_article.py](C:/Users/wangq/Documents/Codex/skills-vault/skills/clip-web-article/scripts/clip_web_article.py)
+- [test_clip_web_article.py](C:/Users/wangq/Documents/Codex/skills-vault/skills/clip-web-article/tests/test_clip_web_article.py)
+- [skills-index.md](C:/Users/wangq/Documents/Codex/skills-vault/registry/skills-index.md)
+
+验证结果：
+- 源码测试：`5/5 OK`
+- 源码 `quick_validate.py`：通过
+- 安装面 `quick_validate.py`：通过
+- 安装目录测试：`5/5 OK`
+- 真实 URL smoke：已尝试公众号 URL，但 `opencli doctor` 显示 daemon 正常、Browser Bridge 扩展未连接，所以真实抓取被 OpenCLI 连接层阻断，不是脚本或 cookie 问题。
+
+后续你连上 OpenCLI Chrome 扩展后，可直接用：
+
+```powershell
+conda run --no-capture-output -n skills-vault python -B "C:\Users\wangq\.agents\skills\clip-web-article\scripts\clip_web_article.py" "URL"
+```
+
+::git-create-branch{cwd="C:\Users\wangq\Documents\Codex\skills-vault" branch="codex/clip-web-article"}
+
+# 3
+
+我已经装了OpenCLI Chrome 扩展后
+你能继续完成测试么？
+
+可以，测试已经完成了。
+
+`opencli.cmd doctor` 现在正常：
+
+```text
+[OK] Daemon: running on port 19825
+[OK] Extension: connected (v1.0.20)
+Everything looks good!
+```
+
+我用已安装的 `clip-web-article` 跑了你给的 4 个 URL，未手工提供 cookie，全部通过。烟测输出放在 [tmp\clip-smoke](C:/Users/wangq/Documents/Codex/skills-vault/tmp/clip-smoke)，没有写入 `knowledge-vault` 默认目录，避免污染正式素材目录。
+
+结果：
+
+| 来源 | 结果 |
+|---|---|
+| 公众号 | 1 个 Markdown，9 张图 |
+| 知乎讨论 | 1 个 Markdown，13 张图 |
+| 知乎 pin/文章 | 1 个 Markdown，10 张图 |
+| X status/thread | 1 个 Markdown，2 张图 |
+
+输出形态也检查过：每个目录只有 `.md` 和 sibling `img_N.*` 图片，没有 JSON/log/raw/html，没有子目录；公众号正文里的 `---` 是文章内容里引用 Skill 片段，不是 frontmatter。
+
+常规验证也重新跑过：
+
+```text
+source tests: 5/5 OK
+source quick_validate: Skill is valid
+installed tests: 5/5 OK
+installed quick_validate: Skill is valid
+```
+
+这轮没有再改代码。当前剩下的可提交变更还是这个 Skill 本身、安装说明、registry 和计划文档。
+
+# 4
+
+我看了几个帖子，问题：
+
+* `英文的时候，同时保留英文文档，然后翻译出来一份中文`，这个是通用规则，不仅仅是针对X
+* 我只要原始文章，不要评论
+* 对于讨论稿，我只要当前讨论，不要其他人的，比如`为什么感觉一年比一年过得快，是因为年龄增长的原因吗？`还有其他人的回复
+* 格式很凌乱，我还得做清理工作。
+* 文件夹和文件名字太长
+
+`C:\Users\wangq\Documents\Codex\knowledge-vault\sources\clipped-articles\文章参考`这些都是原`article-download`抓的
+
+已按你反馈的问题改完并重新安装到 `.agents\skills`。
+
+主要改动：
+- 知乎回答 URL 改用 `opencli zhihu answer-detail`，只抓当前 answer，不再抓同问题下其他回答。
+- X 改为只保存目标 status 那一行，不再保存评论/回复。
+- 知乎 pin 保留正文图片，但裁掉作者卡片、点赞评论区、编辑/评论 UI。
+- 文件夹名压短，文件名 stem 限制到 32 字符。
+- 英文规则改成通用规则：任何英文来源都保留英文原文，并由执行 Skill 的 agent 在同目录生成中文译文，不再只针对 X。
+
+改动文件核心在：
+[clip_web_article.py](C:/Users/wangq/Documents/Codex/skills-vault/skills/clip-web-article/scripts/clip_web_article.py)
+[SKILL.md](C:/Users/wangq/Documents/Codex/skills-vault/skills/clip-web-article/SKILL.md)
+[test_clip_web_article.py](C:/Users/wangq/Documents/Codex/skills-vault/skills/clip-web-article/tests/test_clip_web_article.py)
+
+最终真实烟测输出在：
+[C:\Users\wangq\Documents\Codex\skills-vault\tmp\clip-smoke-v4](C:/Users/wangq/Documents/Codex/skills-vault/tmp/clip-smoke-v4)
+
+结果：
+- 公众号：1 md，9 图
+- 知乎讨论：1 md，0 图，只含目标回答
+- 知乎 pin：1 md，4 图，无评论/UI
+- X：1 md，1 图，无回复评论
+
+验证也跑完了：
+- source tests：6/6 OK
+- source quick_validate：valid
+- installed tests：6/6 OK
+- installed quick_validate：valid
+- 输出形态检查：无 json/log/html/raw，无子目录；其他回答/X 评论/知乎 UI 命中数都是 0。
+
+# 5
+
+我看了最后冒烟，格式基本ok。原来的遗留问题就一个，
+X的，我打开URL默认是英文。你的冒烟测试里，只有一个中文md；是因为你打开是中文的，还是bug。
+
+另外，补3个逻辑：
+1. 支持批处理，调用方可以一次性传入多个URL
+2. 你打开browser 爬完后，应该在本次任务结束后/批任务的话，应该在批完成后，关闭browser
+3. 默认路径`C:\Users\wangq\Documents\Codex\knowledge-vault\sources\clipped-articles\文章参考`，但是调用方可以传入新的目标路径
+
+已补完这轮逻辑，并重新安装到 `.agents\skills`。
+
+关于 X 那个语言问题：我核对了 `opencli twitter thread` 的返回，`text` 字段本身就是中文。也就是说这次烟测不是因为我打开了中文页面，而是 OpenCLI adapter 拿到的是原帖原文；如果你浏览器里默认看到英文，大概率是 X/浏览器侧的翻译展示，不是当前抓取结果的来源。
+
+这次新增了三点：
+
+- 支持批处理：一次可以传多个 URL。
+- 支持自定义目标目录：继续用 `--output-root "目标路径"`，默认仍是 `C:\Users\wangq\Documents\Codex\knowledge-vault\sources\clipped-articles\文章参考`。
+- OpenCLI 命令都加了 `--keep-tab false`，释放本次抓取打开的 tab lease；不会关闭你的 Chrome 进程。
+
+批处理示例：
+
+```powershell
+conda run --no-capture-output -n skills-vault python -B "C:\Users\wangq\.agents\skills\clip-web-article\scripts\clip_web_article.py" "URL1" "URL2" --output-root "D:\target\folder"
+```
+
+验证结果：
+
+- source tests：9/9 OK
+- source quick_validate：valid
+- installed tests：9/9 OK
+- installed quick_validate：valid
+- 真实批处理烟测：知乎 answer + X 一次调用成功
+- 批处理输出检查：无 json/log/html/raw，work dir 已清理，知乎其他回答/X 回复命中数都是 0
+
+烟测输出在：
+[C:\Users\wangq\Documents\Codex\skills-vault\tmp\clip-batch-smoke](C:/Users/wangq/Documents/Codex/skills-vault/tmp/clip-batch-smoke)
+
diff --git a/requirements/skills-vault/lightweight-web-article-clipper.md b/requirements/skills-vault/lightweight-web-article-clipper.md
new file mode 100644
index 0000000..41b22f9
--- /dev/null
+++ b/requirements/skills-vault/lightweight-web-article-clipper.md
@@ -0,0 +1,277 @@
+# Lightweight Web Article Clipper Skill Request
+
+## Status
+
+Requested by `knowledge-vault` on 2026-06-27.
+
+This is a client-side requirement record for a reusable Skill to be built in:
+
+```text
+C:\Users\wangq\Documents\Codex\skills-vault
+```
+
+## Requesting Project
+
+`knowledge-vault`
+
+## Needed Capability
+
+Create a lightweight Skill that takes a user-provided article URL and saves the visible article content as local Markdown plus local images.
+
+The saved article is discussion material, not a durable archive. In the user's workflow, these articles usually serve as temporary targets for critical discussion. The downstream value is not the article itself, but the viewpoints distilled after discussion. After discussion, the clipped article may lose most of its value and can be deleted.
+
+The Skill should therefore optimize for quick capture and low clutter, not auditability, platform taxonomy, or long-term preservation.
+
+## Primary Output Location
+
+Save results under:
+
+```text
+C:\Users\wangq\Documents\Codex\knowledge-vault\sources\clipped-articles\文章参考
+```
+
+Do not use platform-based subfolders by default. The user does not care whether the article came from Zhihu, WeChat, X, Xiaohongshu, or another platform once it is saved as discussion material.
+
+## Expected Output Shape
+
+Each clipped article should be saved as one folder:
+
+```text
+sources/clipped-articles/文章参考/
+  20260627-标题简称/
+    标题.md
+    img_1.jpg
+    img_2.jpg
+```
+
+This follows the existing migrated material style in:
+
+```text
+sources/clipped-articles/文章参考
+```
+
+Current examples include folders such as:
+
+```text
+AI真能自己-0418
+为什么创业失-0504
+20260506-王煜全竟然熬夜养龙虾
+```
+
+## File And Folder Naming
+
+Default folder naming:
+
+```text
+YYYYMMDD-标题简称
+```
+
+Where:
+
+- Use article publish date when it is easy to extract.
+- Use capture date when publish date is unavailable or unreliable.
+- `标题简称` should be short enough for Windows paths and human scanning.
+- If the folder already exists, append a simple suffix such as `-2`, `-3`, or a short URL hash.
+
+Markdown file naming:
+
+```text
+标题.md
+```
+
+Image naming:
+
+```text
+img_1.jpg
+img_2.jpg
+img_3.png
+```
+
+Keep image links in the Markdown relative to the article folder, for example:
+
+```markdown
+![](img_1.jpg)
+```
+
+## Markdown Content Requirements
+
+The Markdown file should contain only the useful article material:
+
+- Article title as the top heading.
+- Article body text.
+- Local image links in the right positions when possible.
+- Minimal author or date text only if it is already part of the article extraction and does not add clutter.
+
+Do not add an original URL line to the `.md` file by default.
+
+Do not add YAML frontmatter by default.
+
+Do not add clipping notes, provenance blocks, capture logs, comments, or tool diagnostics to the `.md` file.
+
+## Required Behaviors
+
+### Single URL Capture
+
+The normal user request is:
+
+```text
+下载文章 <URL>
+```
+
+The Skill should:
+
+1. Identify the URL type internally only as needed for routing.
+2. Capture the article's visible content.
+3. Convert it to Markdown.
+4. Download article images when possible.
+5. Rewrite image references to local relative paths.
+6. Save the folder under `sources/clipped-articles/文章参考`.
+7. Report the saved path and image count.
+
+### Platform Scope
+
+Initial priority platforms:
+
+- Zhihu articles and answers.
+- WeChat public account articles.
+- X / Twitter posts, threads, or long-form articles when capture is feasible.
+- Xiaohongshu notes when capture is feasible.
+- Ordinary web articles as a best-effort fallback.
+
+The Skill should not expose platform taxonomy in the output folder structure unless the user explicitly asks for it.
+
+### Existing Tool Reference
+
+Use the previous local implementation as a capability reference:
+
+```text
+D:\article-download
+```
+
+Relevant behaviors to preserve:
+
+- URL routing for WeChat, Zhihu, and X.
+- Markdown output.
+- Local image download.
+- Simple article folder.
+- Simple image names such as `img_1.jpg`.
+- User-facing success report with saved path and image count.
+
+Behaviors not to preserve:
+
+- Hardcoded old machine paths.
+- Cookie-file workflow as the default user experience.
+- Output to `temp/downloads`.
+- Platform-based output folders as the default.
+- Deleting or overwriting existing output folders.
+
+## Browser And Login Boundary
+
+The Skill may use available browser automation when needed, but should keep the workflow low-risk.
+
+Default preference:
+
+- Use public-page or clean browser capture when enough.
+- Use the user's connected Chrome/Edge profile only when the page requires real login state or the content is only visible there.
+
+Do not:
+
+- Read or save raw cookies, localStorage, passwords, session stores, or tokens.
+- Ask the user to paste cookies as the normal path.
+- Bypass CAPTCHA, access controls, paywalls, age gates, DRM, or platform restrictions.
+- Perform account side-effect actions such as posting, liking, following, commenting, collecting, or sending messages.
+- Batch scrape feeds or accounts.
+
+If a page cannot be captured without login, verification, or anti-bot interaction, the Skill should stop and ask the user to open the page in a connected browser or provide the content manually.
+
+## Non-Goals
+
+- No metadata JSON.
+- No capture log.
+- No raw HTML archive.
+- No screenshots by default.
+- No long-term source index update.
+- No topic classification.
+- No platform classification in output folders.
+- No content evaluation, critique, summarization, or viewpoint distillation.
+- No durable provenance or citation system.
+- No batch crawler.
+- No attempt to make saved articles canonical knowledge.
+
+## Suggested Skill Name
+
+Preferred:
+
+```text
+clip-web-article
+```
+
+Acceptable alternatives:
+
+```text
+lightweight-web-article-clipper
+article-to-markdown-clipper
+```
+
+## Suggested User-Facing Behavior
+
+On success, the agent should respond tersely:
+
+```text
+已保存到:
+C:\Users\wangq\Documents\Codex\knowledge-vault\sources\clipped-articles\文章参考\20260627-标题简称
+
+Markdown: 标题.md
+Images: 5
+```
+
+On partial success:
+
+```text
+正文已保存，部分图片下载失败，已保留可用内容。
+```
+
+On failure:
+
+```text
+未能抓取正文。原因: <short reason>
+建议: 在已登录浏览器中打开该页面后重试，或手动提供正文。
+```
+
+## Suggested Tests
+
+Minimum fixtures or smoke cases:
+
+1. A simple HTML article with text and two images.
+2. An article title containing Windows-invalid filename characters.
+3. A duplicate-title capture that must create a non-overwriting folder.
+4. A Markdown rewrite case where remote image URLs become `img_1.jpg` style local links.
+5. A failed image download case where the Markdown remains usable.
+
+Manual smoke tests after implementation:
+
+1. Save one existing public web article into `sources/clipped-articles/文章参考`.
+2. Save one WeChat public account article if accessible.
+3. Save one Zhihu article or answer if accessible.
+4. Try one login-dependent page through the connected browser path without saving cookies.
+
+## Acceptance Criteria
+
+The Skill is acceptable when a future Codex session can:
+
+1. Receive one article URL from the user.
+2. Save the article under `sources/clipped-articles/文章参考`.
+3. Produce one article folder containing a `.md` file and local images only.
+4. Avoid creating metadata JSON, logs, raw HTML, screenshots, or index entries by default.
+5. Keep the Markdown free of original URL lines and frontmatter by default.
+6. Preserve existing outputs by creating a new non-colliding folder.
+7. Report the saved path and image count.
+8. Stop rather than bypassing login, CAPTCHA, paywall, DRM, anti-bot, or account side-effect boundaries.
+
+## Rationale
+
+The user's article-clipping workflow is intentionally lightweight. The saved article is only a convenient substitute for manual copy-paste or F12-based extraction from sites that make copying difficult.
+
+Most self-media posts are not trusted source material. They often contain many flaws and only one or two usable prompts for discussion. The repository's durable value comes later, after critical discussion turns useful observations into distilled viewpoints and possible writing material.
+
+Therefore, this Skill should minimize archival overhead and avoid turning low-value source posts into heavy, canonical records.
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_1.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_1.png
new file mode 100644
index 0000000..2b64133
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_1.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_2.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_2.png
new file mode 100644
index 0000000..52359d2
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_2.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_3.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_3.png
new file mode 100644
index 0000000..9d8ac6d
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_3.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_4.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_4.png
new file mode 100644
index 0000000..dd56090
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_4.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_5.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_5.png
new file mode 100644
index 0000000..6e10061
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_5.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_6.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_6.png
new file mode 100644
index 0000000..2344342
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_6.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_7.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_7.png
new file mode 100644
index 0000000..ad22682
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_7.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_8.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_8.png
new file mode 100644
index 0000000..cb91483
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_8.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_9.png b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_9.png
new file mode 100644
index 0000000..bfaaa4c
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/img_9.png differ
diff --git a/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/我写了半年skill，直到上周才意识到自己从一开始就搞错了方向.md b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/我写了半年skill，直到上周才意识到自己从一开始就搞错了方向.md
new file mode 100644
index 0000000..34bb133
--- /dev/null
+++ b/sources/clipped-articles/文章参考/20260512-我写了半年skill，直/我写了半年skill，直到上周才意识到自己从一开始就搞错了方向.md
@@ -0,0 +1,298 @@
+# 我写了半年skill，直到上周才意识到自己从一开始就搞错了方向
+
+事情是这样的。
+
+前阵子我又一次在重构公司内部那几个Claude Code的skill，写着写着开始觉得有点不对劲。
+
+我发现我这半年写的那些skill，从定位上就错了。
+
+不是语法错，不是内容写得不好，是我对skill这个东西到底是什么，整个想法都错了。
+
+![Anthropic 官方文档对 Agent Skills 的定义](img_1.png)
+
+Anthropic 官方文档对 Agent Skills 的定义
+
+> 图源：Claude API Docs「Agent Skills」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview\[1\]
+
+这事说起来挺丢人的。skill去年10月出来之后我就跟着开始写，把它当成一种「更长的prompt」在用。就是那种你每次都要复制粘贴一大段的指令，包装一下起个名字，往`~/.claude/skills/`里一丢，感觉自己整挺明白。后来CLAUDE.md、AGENTS.md这些东西陆陆续续冒出来，我的理解依然停留在「这些都是提示词文档，只是放的位置不一样」。
+
+这个错觉持续了三四个月。
+
+中间踩了不少坑，但都没让我跳出来。我会觉得「这次skill没触发，是我description没写好」，会觉得「Claude忽略了CLAUDE.md，是我没强调够」，会觉得「这个流程跑得不稳，是模型今天状态不好」。所有问题在我脑子里都是「执行细节」的问题，不是「定位」的问题。
+
+第一次真正撼动我的是今年1月Vercel那篇评测，《AGENTS.md outperforms skills in our agent evals》。它测出skill默认情况下有56%的case根本没被触发，一份压缩过的AGENTS.md却能做到100%。这个数字当时在HN上吵了好几天，我看完心里咯噔了一下，但那会儿还没完全想通，只是觉得「哦，skill的触发可能没我想的那么可靠」。
+
+真正让我放不下的是2月Snyk发的那份ToxicSkills审计，我在后面还会讲这个。看到那份审计的那一刻，我意识到我一直在错误的抽象层级上理解这件事。
+
+那段时间我手边正好有一份挺硬核的deep research，是我让一个agent帮我梳理从2025年下半年到2026年春天这段时间，各种官方文档、工程博客、Hacker News讨论和实测文章的共识。我本来只是想拿它来打磨我自己的skill怎么写得更好。但看到后半段我突然反应过来，这些讨论的共同指向，从来就不是「哪种格式最好」或者「skill该怎么写」。
+
+真正的共识是。
+
+**skill根本就不是一份提示词文档，它是你agent运行时架构的一部分。**
+
+这个判断落到我这儿的时候，我坐在椅子上想了很久。因为它翻译过来意味着一件事，就是这半年所有聊「prompt engineering」的讨论，在agent这个场景里已经不够用了。你正在面对的不是「怎么写一段好提示词」，而是「怎么设计一套可以长期演进的agent操作系统」。
+
+![Agent Skills Quickstart 里展示的 skill 包结构](img_2.png)
+
+Agent Skills Quickstart 里展示的 skill 包结构
+
+> 图源：Claude API Docs「Get started with Agent Skills in the API」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/quickstart\[2\]
+
+这句话有点大。先别急，顺着往下走，我把我自己的路径走一遍你就懂了。
+
+回到skill到底是个什么机制这块。
+
+大家也都知道，Claude Code是每次会话都从空的上下文开始的。这件事其实挺反直觉的，因为你用着用着会产生一种错觉，以为这个东西「记得」你的项目。其实它不记得，它每次都是新人来上班。
+
+那为什么它看着像记得呢？因为有两套跨会话的东西在顶着。
+
+第一套是`CLAUDE.md`，你自己写的规则和指令，每次会话启动都整个加载进去。这个东西的特点是，**每次都进上下文**。所以它是一个杠杆极高的点，你放进去什么，就等于你给每次会话都付了那份token的成本。
+
+第二套是auto memory，模型根据你反复纠正的内容自动攒的notes，也会跟着会话加载。
+
+到这儿为止，听着还是「提示词文档」的感觉对吧。
+
+skill的机制就完全不一样了。
+
+skill里面其实是一个文件夹，有`SKILL.md`正文、有`scripts/`脚本、有`references/`引用材料、有`assets/`素材。但关键在于，**它不是每次会话都进上下文的**。
+
+每次会话启动的时候，Claude只会先看到所有skill的`name`和`description`，正文它看不到。只有当agent判断当前任务跟某个skill匹配了，它才会主动去把那个skill的正文整个读进来，挂到会话里。
+
+听着很简单对吧。但这里拐了个弯。
+
+你想想看，skill就有了一套自己的**发现、调用、挂载、保持、压缩管理**机制。它不是一个被动的文本，它是一个会被agent按需触发的过程模块。你写skill的时候，`description`字段写得好不好，直接决定了这个skill能不能被触发；里面的脚本写不写得对，决定了agent能不能真的执行动作；引用文件组织得合不合理，决定了在长会话里上下文被压缩之后它还能不能挂回来。
+
+![官方最佳实践把 skill 写作放在工程流程里讨论](img_3.png)
+
+官方最佳实践把 skill 写作放在工程流程里讨论
+
+> 图源：Claude API Docs「Skill authoring best practices」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices\[3\]
+
+这已经不是「文字」的范畴了。这是一个**可部署单元**。
+
+官方文档里有一句话我印象特别深。它说，如果你发现`CLAUDE.md`里的某一段已经长成了「procedure而不是fact」，就应该把它迁到skill。翻译过来就是，如果这段东西是「多步流程、分支判断、校验顺序」，它就不该常驻在上下文里，它应该是一个可以在需要的时候被加载、不需要的时候就不占token的模块。
+
+这句话触动我挺深。因为我过去的写法正好相反，凡是我觉得重要的，我都往CLAUDE.md里塞。塞到后来那个文件两百多行，每次对话一开始就要烧一大堆token，而且因为太长，Claude自己都经常不看细节。
+
+这就是我说「我一开始就搞错了」的意思。我在用一个高杠杆的常驻层，放了一堆只有在特定任务里才需要的专题流程。
+
+那正确的心智模型该长什么样？
+
+我自己也还在摸索，但这套分层基本稳了，可以先分享给你。
+
+你在给agent搭建知识和行为的时候，不要再想「我该往哪个文件里塞」，要想**层**。agent有好几层不同性质的层，每一层要放的东西性质完全不一样。
+
+**第一层是memory，解决agent失忆问题。** 你对agent的长期偏好、它反复被纠正出来的经验、跨项目通用的那些东西，放这一层。对Claude来说是auto memory，对Cline来说是Memory Bank那套结构化项目档案。这一层的核心特征是，它不是你手动写的，是agent自己在用的过程中沉淀的。
+
+**第二层是CLAUDE.md或AGENTS.md，项目级默认行为和地图。** 每次会话都会加载，所以它要短、要普适、要高价值。放什么？放项目地图、默认流程、关键gotchas、你不想每次重新解释的那些基础约束。Anthropic官方建议控制在200行以内；Augment那篇评测更具体，建议100到150行主文件加少量引用文档。数字不一定通用，但原则是稳的，**常驻层只放高价值、广适用、低歧义的东西，其他都下沉。**
+
+**第三层是nested CLAUDE.md或path-scoped rules，模块级约束。** 这一层是我后来才重视起来的，效果意外地好。你可以在子目录里放一个小的CLAUDE.md，Claude会按目录层级懒加载，只有读到那个目录下的文件时才会注入。path rules还能用`paths`字段精确限定，比如只在`.ts`文件或者`/api/`路径下生效。HN上有条评论说得很准，「multiple good AGENTS.md is even better」，因为它把上下文注入做了空间上的隔离，agent不会被无关约束污染。
+
+**第四层就是skill，可复用的专题工作流。** 多步流程、分支判断、注意事项、校验顺序、脚本入口、专题知识，都在这一层。它的核心特点是**按需加载**，所以它不消耗常驻token，你可以放得很厚。
+
+**第五层是tools、MCP、CLI，动作层和数据层。** skill负责「什么时候用、按什么顺序用、成功标准是什么」，工具负责真正执行。很多人把这两者混在一起写，结果skill里塞了一堆curl命令，其实应该拆开。
+
+**第六层是hooks，确定性约束。** 这一层我以前完全没用过，后来才发现它解决了一类我原来解决不了的问题。Anthropic官方有一句非常关键的区分，`CLAUDE.md`是advisory，hooks是deterministic。翻译成人话就是，CLAUDE.md是「建议」，hooks是「强制」。凡是「必须每次发生、零例外」的事情，应该下沉为hook，不要再寄希望于模型自觉看文档。
+
+**第七层是subagents，隔离上下文的专门执行者。** 适合研究、审查、验证这种高读文件量的任务。它的价值在于能把主对话从上下文污染里解放出来。某些skill甚至可以通过`context: fork`直接运行在subagent里。
+
+**第八层是eval和review，让所有资产持续变好的反馈回路。** Anthropic工程文章里建议从评估开始，Agent Skills官方最佳实践甚至把「给LLM看eval signals和当前SKILL.md，让它提出修改，再由人复核并迭代」写成了标准循环。
+
+![把 agent 经验分层管理，而不是都写进同一个提示词文件](img_4.png)
+
+把 agent 经验分层管理，而不是都写进同一个提示词文件
+
+> 图源：作者整理，基于 Claude Code 与 Agent Skills 官方文档
+
+这套东西第一眼看上去有点吓人，八层啊。但你真的把它用起来之后会发现一个特别重要的价值。
+
+**它把「这次经验该放到哪里」从模糊的直觉，变成了一个有层级的工程决策。**
+
+说到这个，最关键的其实不是搭好这套层，而是经验的迁移原则。
+
+我自己的感受是，搭建这套分层不难，官方文档都写着呢。真正难的是后面这个动作。**每次真实工作流跑完之后，这次学到的东西到底该进哪一层？**
+
+你想想看，这才是你作为人类真正需要做判断的地方。agent自己也判断不出来。这是你的活。
+
+我自己琢磨了几条判断规则，分享出来你看看能不能用。
+
+**1\. 凡是「每个会话都应该知道」的东西，进CLAUDE.md或AGENTS.md。**比如你们公司代码库用的是pnpm不是npm，比如所有API都要先过auth中间件，比如commit message必须符合conventional commits。这种东西就算你今天不用，下次别人用也要用，就应该常驻。
+
+**2\. 凡是「多步流程、专题检查、分支决策」，进skill。**比如「发版前的checklist」、「写一个新React组件的标准流程」、「接入一个新的第三方API时的安全审查流程」。这些东西只在特定任务里才需要，常驻浪费，按需加载刚刚好。
+
+**3\. 凡是「只对某目录或某类文件生效」，进nested CLAUDE.md或path-scoped rules。**比如你的`/legacy/`目录里代码风格跟主项目不一样，就应该在那个目录里放一个小的CLAUDE.md，只影响那个目录。不要把这种局部约束放在顶层，会污染所有对话。
+
+**4\. 凡是「必须每次执行、不能靠模型自觉」，进hook。**比如提交前必须跑lint，比如修改数据库schema前必须备份。这种东西写进CLAUDE.md你会发现Claude有时候就是会忘，写成hook就是强制执行，逃不掉。
+
+**5\. 凡是「模型需要真实执行或查询」，进CLI、MCP或scripts。**不要在skill里写一堆「你应该这样这样调用API」，直接把调用包成一个脚本，让skill调用脚本。skill负责决策，脚本负责执行。
+
+**6\. 凡是已经从「专题经验」变成「所有相关任务都应该遵守的通用约束」，从skill上移到CLAUDE.md。**这一条特别重要。HN上有条评论讲得很精辟，说「很多review skill里的反模式，不是应该在写代码阶段就避免吗？」作者的回应也基本承认了，这些规则确实应该进CLAUDE.md。所以skill不是终点，它只是经验的中转站，好的经验会从skill上升到项目级规则。
+
+![Claude Code memory 文档说明 CLAUDE.md 如何作为项目记忆入口](img_5.png)
+
+Claude Code memory 文档说明 CLAUDE.md 如何作为项目记忆入口
+
+> 图源：Claude Code Docs「How Claude remembers your project」，https://docs.claude.com/en/docs/claude-code/memory\[4\]
+
+这套迁移原则我前前后后跑了两三个月，现在公司那几个项目的agent表现明显稳定了。最大的变化是，**我的CLAUDE.md从两百多行缩回了一百行左右，但agent行为反而比以前更准了。**
+
+原因很简单，之前那一百多行的冗余都是专题流程，它们挤占了真正重要规则的注意力。迁移到skill之后，CLAUDE.md里只剩下真正每次都该知道的东西，agent反而更容易抓住重点。
+
+但说句实话，以上这些都还远没到「写好就稳」的阶段。我得坦白。
+
+现在这套体系最大的问题，是**agent到底能多可靠地读取和调用这些资产**，还没有标准答案。
+
+回到开头说的Vercel那篇评测，把数据完整摆出来你就更能体会它扎心在哪。它用Next.js 16的文档检索作为测试场景，skill默认情况下56%的case根本没被触发，必须加上明确的调用指令，通过率才能从53%拉到79%。而一份压缩过的AGENTS.md docs index，同样场景下能做到100%。
+
+这个数据传出去之后，HN上吵了很多天。有人说AGENTS.md赢麻了，也有人说这只是特定harness下的特定场景，不能外推。我比较倾向于后者，因为Vercel这个测试说到底是一个「文档检索」任务，skill的优势不在这种任务上，skill的优势在「多步流程和专题决策」。用一个不适合skill的场景去测skill，结果当然难看。
+
+但这件事说明一个更深的问题，**今天的agent能不能稳定地按照你设计的分层去工作，很大程度上还依赖harness、依赖模型能力、依赖skill描述字段写得多好、甚至依赖运气。**
+
+![Vercel 用 agent evals 对比 AGENTS.md 与 skills 的文档检索效果](img_6.png)
+
+Vercel 用 agent evals 对比 AGENTS.md 与 skills 的文档检索效果
+
+> 图源：Vercel Blog「AGENTS.md outperforms skills in our agent evals」，https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals\[5\]
+
+HN上最长寿的一条抱怨是，「长会话之后agent会漂移」、「它就是有时候不看CLAUDE.md」、「skill调用不稳定」。这些都是真实存在的问题。我自己也遇到过，同一个skill在早上能触发，下午就不行了，你想破头也不知道为什么。
+
+所以我想说的是，分层心智模型本身是成立的，但具体到每一天的使用上，你还是会踩到一些「玄学」级别的坑。这不是你的错，也不是文档的错，是这个领域本身还在演进。
+
+顺着上面再聊聊，这是我以前完全没想到的维度，治理和安全。
+
+回到开头我说的那份Snyk的`ToxicSkills`审计。它真正让我停下来的，不是skill写得不好，而是skill已经有了被恶意利用的样本。
+
+他们在3984个公开的skill里做了一轮安全扫描，结果你猜怎么着。13.4%含critical issue、36.8%含至少一种安全问题、并确认了76个恶意skills。
+
+？？？
+
+这组数字我反复看了两遍。后来想想，也合理。skill本身可以捆绑脚本，可以注入上下文，可以在被触发时执行真实动作，所以它天然就是一个供应链入口，也是一个权限扩展点。
+
+恶意skill能干什么？可以诱导Claude把你的代码外传，可以在看起来正常的文件处理流程里塞一条偷偷上传你env的命令，可以在agent执行某些动作的时候往命令里插参数。
+
+想想就觉得后背发凉。
+
+因为我这半年，下载了一堆别人写的skill往自己电脑上丢。
+
+![Snyk ToxicSkills 研究把 agent skills 当作供应链风险入口分析](img_7.png)
+
+Snyk ToxicSkills 研究把 agent skills 当作供应链风险入口分析
+
+> 图源：Snyk Blog「ToxicSkills」研究，https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/\[6\]
+
+所以skill这个东西，现在已经不只是「帮agent变聪明」的文本资产。它同时是一个需要治理的代码资产。你用别人的skill，就相当于在你的agent里运行了别人的一段代码。这跟你往node\_modules里装npm包是一个性质的事情，但很多人还没意识到。
+
+如果你所在的公司正在推agent工程化，这块一定要提上日程。**skill的审计、签名、白名单、沙箱执行权限**。这些东西今天看着可能还早，但等到agent真的深度进入生产系统的时候，这就是下一波供应链安全问题的前线。
+
+讲到这儿，回到最开头那个转折。从prompt engineering走到agent operating system，这件事其实比看上去要重要得多。
+
+我说「我这半年写skill的定位都错了」，不是谦虚，是真话。
+
+我真正错的地方，是我一直把agent当成一个「更聪明的搜索引擎」或者「更厉害的copilot」在用，所以我把我的工作重心放在「怎么让它每一轮回答都更好」上。这套思路对应的，就是prompt engineering，你写一段好话术，模型回你一段好答案。
+
+但skill、CLAUDE.md、hooks、subagents、MCP这套东西合起来在暗示一个完全不同的场景。**你面对的不是一次对话，你面对的是一个长期运行的、会反复被调用的、会渐进式积累经验的、需要和真实工具链交互的、需要被验证和治理的运行时系统。**
+
+这跟一次对话的优化不是一个量级的事情。
+
+我偶尔会想起2008年iPhone出来之后，做网页的那一波人怎么适应到做App的。那时候大家一开始都在问「App跟网页有啥区别，不就是做个页面吗」。但真做下去发现，App有生命周期、有状态管理、有权限模型、有供应链、有签名、有发布渠道、有崩溃日志、有用户留存。这些东西任何一个拎出来，都跟「写一个网页」不是一个量级的工程。
+
+今天我们在agent这个事情上，站在类似的位置。
+
+![Claude Code hooks 文档把 hooks 定义为自动执行 shell 命令的机制](img_8.png)
+
+Claude Code hooks 文档把 hooks 定义为自动执行 shell 命令的机制
+
+> 图源：Claude Code Docs「Hooks reference」，https://docs.claude.com/en/docs/claude-code/hooks\[7\]
+
+你写一段prompt让agent做事，这是「网页时代」。你设计一套可以长期演进、有分层、有治理、有反馈回路的agent架构，这是「App时代」。
+
+这两件事看着好像都是「跟模型说话」，其实完全不同。
+
+我自己说实话还远远没跑通，我今天分享的这些东西也是从Vercel那份评测到现在这几个月里踩坑、推翻、重构来的。但我能很清楚地感觉到一件事。**接下来真正拉开差距的，不是谁的prompt写得漂亮，而是谁的agent架构搭得稳。**
+
+说到这儿，我知道讲了这么多概念可能有点闷。具体今天能做什么，我把最关键的行动点拎出来，你如果今天就想动手的话，可以照着做。
+
+**第一件事，今晚把你的CLAUDE.md打开，数一下行数。**如果超过200行，就要开始考虑拆了。把里面那些「多步流程、专题checklist、分支判断」标出来，准备迁到skill。
+
+**第二件事，给你最常用的几个专题流程，各写一个skill。**比如「发版前流程」、「接新API的审查流程」、「写新React组件的标准流程」。重点不是正文多完美，重点是把`description`字段写好，让agent能在需要的时候识别并触发。
+
+**第三件事，如果你有一个`/legacy/`或者风格特殊的目录，放一个nested CLAUDE.md。**让那个目录的规则只影响那个目录，不污染全局。
+
+**第四件事，找一件你反复提醒Claude还是会忘的事情，考虑写成hook。**比如「提交前必须跑lint」、「写数据库迁移前必须dry-run」。hook不优雅，但它deterministic，这个特性在关键场合无可替代。
+
+**第五件事，开始养成一个习惯。每次完成一个真实任务之后，问自己一句，这次学到的东西该进哪一层？**进memory？进CLAUDE.md？进skill？进hook？进一个新脚本？这一问就是最重要的治理动作。
+
+![Claude Code subagents 文档展示如何创建专门执行者](img_9.png)
+
+Claude Code subagents 文档展示如何创建专门执行者
+
+> 图源：Claude Code Docs「Create custom subagents」，https://docs.claude.com/en/docs/claude-code/sub-agents\[8\]
+
+写到这里我突然想到一个挺有意思的事。
+
+文章里我一直在讲，多步判断流程就该写成skill。那「判断这次的经验该进哪一层」这件事本身，是不是也应该是一个skill？
+
+是的。所以我顺手把它写出来了。
+
+我把它叫做`experience-triage`，经验分诊。它的逻辑很简单，你每次跑完一个真实任务，触发这个skill，它会带你走完一套问答，最后告诉你这次的经验该进哪一层、用什么模板写、放在哪个文件里。
+
+skill的完整内容长这样，你可以直接复制粘贴到`~/.claude/skills/experience-triage/SKILL.md`里使用。
+
+```
+---name: experience-triagedescription: 用于在完成一个真实任务之后，把这次学到的经验、坑、约束、流程分诊到agent架构的正确层级。当用户说「这次学到的xxx该写到哪」、「我刚踩了一个坑想沉淀」、「帮我判断这条规则该进CLAUDE.md还是skill」、「我有个新流程不知道放哪」时触发。---# 经验分诊流程你的任务是带用户完成一次经验分诊，输出明确的「该放在哪一层 + 应该怎么写 + 放到哪个文件」的建议。## 第一步，问清楚要分诊的经验是什么请用户用一句话描述这次想沉淀的内容。如果用户描述太泛，要追问具体场景，比如：- 这是一条什么样的规则？是「每次都要做」还是「特定情况下要做」？- 这条经验只对某个项目有用，还是跨项目通用？- 它需要执行动作，还是只是约束模型行为？## 第二步，按下面的判断树走一遍依次问这五个问题，第一个匹配上的就是答案：**Q1：这件事是不是「必须每次执行、零例外、不能靠模型自觉」？**是 → 推荐放进 `hook`。给出一个hook配置示例。否 → Q2**Q2：这件事是不是「需要真实执行命令、查询接口、读取数据」？**是 → 推荐写成 `script` 或 `MCP tool`，再在相应skill里调用。否 → Q3**Q3：这件事是不是「只对某个目录、某类文件、某个模块生效」？**是 → 推荐放进对应目录的 `nested CLAUDE.md` 或 `path-scoped rule`。否 → Q4**Q4：这件事是不是「多步流程、专题checklist、需要分支判断的过程」？**是 → 推荐写成新的 `skill`，给出 description 字段建议（必须写到能被触发的程度）。否 → Q5**Q5：这件事是不是「每个会话都应该知道的高频默认行为或约束」？**是 → 推荐加到 `CLAUDE.md` 或 `AGENTS.md`，并提示用户检查当前文件是否已超过200行。否 → 这条经验可能太私人、太一次性，不建议沉淀。直接告诉用户。## 第三步，给出可直接执行的写作建议根据Q1-Q5的答案，输出一个可以直接写入对应文件的草稿。草稿要：- 格式正确（YAML frontmatter、Markdown标题、代码块等）- 言之有物，不要写「请遵守xxx规则」这种空话- 包含至少一个具体例子或反例## 第四步，提示上移可能性如果用户最近在多次任务里都触发了同一个skill里的同一类经验，提醒用户考虑把这部分经验从skill「上移」到CLAUDE.md，从专题流程升级为通用约束。## 输出格式【分诊结论】xxx层【推荐位置】~/.claude/xxx 或 项目根目录/xxx【写作模板】（直接给出可复制的Markdown草稿）【后续提醒】（如果适用，提示上移可能性或学习成本）
+```
+
+这玩意我自己跑了一两个月，最大的好处是它逼着我在每次任务结束的时候认真做这一步，而不是凭感觉一塞了之。
+
+举一个真实场景。上个月我搞清楚了我们项目的 Tailwind config 自定义颜色不能直接用 hex，必须走变量。我当时第一反应是写个CLAUDE.md规则。但触发了 experience-triage 之后，它走完Q3直接判断这是「只对前端代码生效」的局部约束，建议我放到 `/src/styles/CLAUDE.md` 里。后来证明这个判断是对的，因为我的后端代码里根本不需要知道前端颜色规则。
+
+再举一个反例。再往前一点，我想把「写新组件时要先跑 storybook」这条流程沉淀下来。我以为是skill，跑完分诊发现不对，它问我Q1「这件事是不是必须每次执行、零例外」，我想了想确实是，所以最后写成了一个 pre-tool-use hook。比写成skill靠谱多了，因为skill还会被忽略，hook根本逃不掉。
+
+说实话，这个分诊skill本身就是这篇文章的一个隐喻。它在说，**当你能把一个判断流程写成skill，你就在用agent来扩展agent**。
+
+你的agent架构开始能帮你维护它自己。这是分层心智模型里最让我觉得有意思的地方，它有自指性。
+
+你也可以基于这个原型改造它。比如加一个Q0判断「这条经验是不是其实不该沉淀」，过滤掉一些过度记录的冲动；或者根据你公司的实际目录结构，把推荐位置写得更精确；又或者你团队还有自己的资产层级比如 wiki 或 notion，加一条规则进去。这个skill不是终点，是你这套架构的一个入口。
+
+如果你跑出了什么有意思的变体，欢迎回来告诉我。
+
+我自己也还没完全跑通整个体系，可能有些判断还不成熟。但这套分层至少给了我一个不一样的工作方式。我不再把agent当成一个「要哄它好好干活的员工」，我开始把它当成一个「需要我设计操作系统的平台」。
+
+这两种心态完全是两回事。
+
+前者你永远在想「这次prompt写好没有」；后者你会开始想「这件事发生在哪一层、下一次怎么让它自动发生、它需要什么工具、它的失败场景是什么、它的经验怎么沉淀、怎么让下一个项目也受益」。
+
+这是两个时代的工作。
+
+一个在过去，一个在未来。
+
+写到这儿，回看开头那句话，「我这半年写的所有skill，可能从一开始就写错了」。
+
+其实也不完全是错。这半年的试错让我最后能走到今天这套分层。agent这个领域现在还在疯狂演进，今天我的判断六个月后可能又要被颠覆一次。
+
+但有一个方向我基本确定。
+
+**技能不是沉淀物，是agent运行时架构的一部分。**
+
+**CLAUDE.md不是说明书，是系统的总入口、索引和默认行为层。**
+
+**真正决定agent稳定性的，不是你写了多少文档，而是你把经验放到了正确的层。**
+
+技术本身在快速变化，但这套分层的心智模型，我觉得至少能稳一两年。
+
+磨平一些信息差，希望对你有用。
+
+以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
+
+谢谢你看我的文章，我们，下次再见。
+
+#### References
+
+1.  https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
+2.  https://platform.claude.com/docs/en/agents-and-tools/agent-skills/quickstart: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/quickstart
+3.  https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
+4.  https://docs.claude.com/en/docs/claude-code/memory: https://docs.claude.com/en/docs/claude-code/memory
+5.  https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals: https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals
+6.  https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/: https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/
+7.  https://docs.claude.com/en/docs/claude-code/hooks: https://docs.claude.com/en/docs/claude-code/hooks
+8.  https://docs.claude.com/en/docs/claude-code/sub-agents: https://docs.claude.com/en/docs/claude-code/sub-agents
diff --git a/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/OpenAI内部是怎么使用Codex？ 最近OpenAI公布了其.md b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/OpenAI内部是怎么使用Codex？ 最近OpenAI公布了其.md
new file mode 100644
index 0000000..497289e
--- /dev/null
+++ b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/OpenAI内部是怎么使用Codex？ 最近OpenAI公布了其.md	
@@ -0,0 +1,33 @@
+# OpenAI内部是怎么使用Codex？ | 最近OpenAI公布了其内部是如何使用Codex。为了方便大家阅读，我基于OpenA…
+
+最近OpenAI公布了其内部是如何使用Codex。为了方便大家阅读，我基于OpenAI公布的英文原版进行整理，并把这份材料整理成了一组信息图。
+看完以后我最大的感受是：Codex 的价值，不只是“帮你写代码”。
+更重要的是，它已经开始进入真实工程协作流程里。
+比如：读陌生代码库、扫重构影响面、找性能瓶颈、补测试、生成 PR、处理碎片任务、做方案探索。
+这些场景其实都很工程化。
+
+尤其对程序员来说，最值得借鉴的是这几点：
+第一，先让 AI 理解系统，再让它改代码。
+不要一上来就丢一个大需求。
+第二，重构和迁移类任务，适合先扫影响面，再拆成小 PR。
+节奏可控，比一次性大改更靠谱。
+第三，测试不要只追覆盖率数字。
+边界条件、失败路径、历史 bug，才是真正能挡住回归的地方。
+第四，把 Codex 任务队列当成轻量 backlog。
+碎片时间把任务丢进去，专注时间再回来 review。
+第五，长期看，AI 编程的核心能力会从“单次生成代码”，变成“沉淀可复用的工程工作流”。
+这也是我觉得普通开发者最应该关注的地方。
+AI 会越来越会写代码。
+但真正拉开差距的，还是谁能把上下文、流程、验证方式和团队规则沉淀下来。
+
+这组图适合收藏，后面做 AI 编程工作流时可以直接对照用。
+
+[#AI编程](https://www.zhihu.com/topic/28322950) [#CODEX](https://www.zhihu.com/topic/28425489) [#OpenAI](https://www.zhihu.com/topic/20083046) [#软件工程](https://www.zhihu.com/topic/19557552) [#AI提效](https://www.zhihu.com/topic/28837039) [#AI工具推荐](https://www.zhihu.com/topic/27828704) [#AI 工具技巧](https://www.zhihu.com/topic/27158399) [#效率](https://www.zhihu.com/topic/19556677)
+
+![cover](img_1.jpg)
+
+![cover](img_2.jpg)
+
+![cover](img_3.jpg)
+
+![cover](img_4.jpg)
diff --git a/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_1.jpg b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_1.jpg
new file mode 100644
index 0000000..81b23f5
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_1.jpg differ
diff --git a/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_2.jpg b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_2.jpg
new file mode 100644
index 0000000..f2589a1
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_2.jpg differ
diff --git a/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_3.jpg b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_3.jpg
new file mode 100644
index 0000000..23a39b1
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_3.jpg differ
diff --git a/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_4.jpg b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_4.jpg
new file mode 100644
index 0000000..03124aa
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260525-OpenAI内部是怎么使/img_4.jpg differ
diff --git a/sources/clipped-articles/文章参考/20260623-为什么感觉一年比一年过得/为什么感觉一年比一年过得快，是因为年龄增长的原因吗？.md b/sources/clipped-articles/文章参考/20260623-为什么感觉一年比一年过得/为什么感觉一年比一年过得快，是因为年龄增长的原因吗？.md
new file mode 100644
index 0000000..0dc6c15
--- /dev/null
+++ b/sources/clipped-articles/文章参考/20260623-为什么感觉一年比一年过得/为什么感觉一年比一年过得快，是因为年龄增长的原因吗？.md
@@ -0,0 +1,33 @@
+# 为什么感觉一年比一年过得快，是因为年龄增长的原因吗？
+
+答案是：并不是年龄增长了，是你惊讶的次数少了。
+
+如果让你坐在图书馆一天看《资治通鉴》一个月，看信息论一个月，或者学习一门枯燥的理论一个月，或者想想大学上的高数课、高中老师讲的电磁理论、相对论的场景，这时候你的感觉是什么？是时间过得太慢了，真是度日如年。
+
+所以，一段时间在你主观上有多长，约等于你为它存下的信息量，也就是这段记忆“压缩之后的文件大小”。跟客观上物理时间没多少关系。
+
+打个最直观的比方，视频编码： 你拍一面静止的白墙一小时，文件可以压到几乎为零。因为每一帧都和上一帧一样，编码器只需记“和前一帧相同 ×90000 帧”。 你拍一小时风景各异的旅行，文件巨大，因为帧帧不同，无可压缩。
+
+童年是什么？ 每天都是新帧，几乎不可压缩，存成了一个巨大的文件。回望时这段时间长得惊人，这个时段的每天都是新的信息。 成年之后呢？ 今年和去年帧帧高度雷同，信息被压成一句“同去年，×365”，压缩之后整年塌缩成一个极小的文件。文件小，那么主观上时间也就短。
+
+所以“这一年怎么这么快就过去了”，翻译成信息论就是：这一年的记忆压缩文件太小了，根本没占多少存储。 这就解释了开头那种学习枯燥理论时度日如年的感觉——因为高质量的信息在流过你，你的大脑这台压缩器忙得不可开交，所以产生度日如年的感觉。
+
+信息论对“信息”的精确定义
+
+一个事件的信息量 = 它的意外程度（surprisal = −log p）。也可以说，信息就等于惊讶。越是出乎意料的事，信息量越大（很多 bit）。越是固定的、平常的、流水账式的、完全可预测的事，信息量越接近零 bit。
+
+如果我们把上面推到极致，就会发现： 精通 = 惊讶归零 = 时间归零。 你越是把生活经营得熟练、可控、舒适、毫无意外，你的信息密度就越低，你的时间就流失得越快。这解释了我们为什么要跳出舒适区。因为你在舒适区就相当于主观上你少活了10年， 这也解释了一个悖论：那些看起来“稳定幸福、岁月静好”的人生，在信息论看来，实际上短得可怜。而有的人经历丰富，人生起起伏伏，波澜壮阔，他的人生主观时间可能都有200年了
+
+那么我们如何让自己的时间变长？
+
+第一，深度社交。 浅社交（寒暄、客套）高度可压缩，近乎零 bit；而真正深的关系是无法压缩的，因为另一个意识是不可预测、深不见底的。列维纳斯说，他者的面孔是“无限”。 所以要和人往深里走，不要泛泛之交。一次真正交心的深谈，信息密度远超一百场点头之交。爱、亲密、被另一个灵魂持续地“出乎你意料”，是这世上密度最高、最取之不尽的时间来源。
+
+第二，记录与复盘。 一条孤立的记忆会被大脑当垃圾回收掉；一条被接入了意义、叙事、自我认同的记忆，才能在压缩中存活。 这就是为什么写日记、做复盘会字面意义上延长你的主观寿命——你在事后把流过的经历重新捞起来、加工成故事、嵌进“你是谁”的叙事里，这个二次编码让原本要被压掉的东西沉淀了下来。
+
+第三，做真实的自己。 神经科学上，带强烈情绪的事件被编码的保真度高得多（杏仁核会增强海马的记忆固化，这就是“闪光灯记忆”）。你为之心动、心碎、愤怒、敬畏的时刻，会被存成多帧数；而被你情感上“略过”的，等于没存到你的时间脑海里。 于是有一个你看不到的“时间杀手”，就是我们常说的情感麻木。 用酒精、刷手机、过度理智化、把所有感受都防御和屏蔽的人，正在亲手抹掉自己的时间。因为他活过，但没记下任何东西，因为他不许自己真的感到。变得很麻木，所以去流泪、感动、大哭、大笑吧。
+
+第四，读一些信息量很长的文字或者枯燥的理论书籍。 西蒙娜·薇依说：“注意力是最稀有、最纯粹的慷慨。” 这里要提醒一下大家，我们要区分“刺激”和“信息”。 短视频是高刺激、近乎零信息。它疯狂激发你的多巴胺，但内容高度同质、可压缩成垃圾，所以刷完一下午，记忆文件几乎是空的（这正是它让人感觉“时间没了”的原因）。它甚至更恶心：它训练你的注意力变成扫描而非凝视，扫描对信息的刻录能力远低于凝视，从此连真正高信息的东西你也存不进去了。这解释了为什么看短视频的人很难看一些长的文章。
+
+第五，换地图或者换角色。 惊讶量（surprisal）取决于你的模型。所以提高它有两条路：换世界，或者换你这个看世界的人。 有人说是旅行吗？不是，因为旅行是换输入。移民才是换世界。 罗蒂的“重新描述”：获得一套新词汇，旧世界就重新变得可惊讶、可读。这也就解释了为什么很多人给出的建议是学一门新的语言，因为语言是思维的边界，用不同的语言看世界得到的信息量是不一样的。还有一种就是你学会了从另一个角度看世界，比如一开始是从心理学角度看人，后来可以从社会学和经济学角度分析，这个时候就相当于“换人”了。
+
+第六，往深度挖。 这个简单点：意思是不去经历更多新事物，而要把你已经在经历的某件事，看得无限精细。一个品酒师喝同一口酒，他尝到的是单宁、酸度、橡木、产区、年份；我尝到的只有“酒味”。因为他的感知分辨率高。 在一个领域成为行家（咖啡、音乐、围棋、写作、看人），你眼前那个早已看腻的世界，瞬间会突然重新变得信息爆炸。
diff --git a/sources/clipped-articles/文章参考/20260624-分享一下我管理Skil/img_1.jpg b/sources/clipped-articles/文章参考/20260624-分享一下我管理Skil/img_1.jpg
new file mode 100644
index 0000000..6dece8c
Binary files /dev/null and b/sources/clipped-articles/文章参考/20260624-分享一下我管理Skil/img_1.jpg differ
diff --git a/sources/clipped-articles/文章参考/20260624-分享一下我管理Skil/分享一下我管理 Skills 的方式，偏极客风格，不一定适合所有.md b/sources/clipped-articles/文章参考/20260624-分享一下我管理Skil/分享一下我管理 Skills 的方式，偏极客风格，不一定适合所有.md
new file mode 100644
index 0000000..1e130c7
--- /dev/null
+++ b/sources/clipped-articles/文章参考/20260624-分享一下我管理Skil/分享一下我管理 Skills 的方式，偏极客风格，不一定适合所有.md	
@@ -0,0 +1,68 @@
+# 分享一下我管理 Skills 的方式，偏极客风格，不一定适合所有人，但可以给大家
+
+分享一下我管理 Skills 的方式，偏极客风格，不一定适合所有人，但可以给大家提供一个思路。
+
+一、Skills 只装在项目里，不装全局
+
+Agent 的 Skills 可以装在全局（所有项目共享）或者项目内（只有当前项目能用）。我选择只装在项目内，最主要的原因是节约上下文空间。
+
+Agent 在工作时有一个上下文窗口，你可以把它想象成 Claude 的工作台——台面大小是有限的。虽然 Skill 默认只会加载名称、描述等摘要信息（不会把完整内容全部摊开），但积少成多——全局装了几十个 Skill，光是这些摘要加在一起也会占掉不少工作台空间。而且一旦 Claude 判断某个 Skill 跟当前任务相关，就会把它的完整内容加载进来，全局 Skill 越多，被误触发的概率也越大，白白浪费空间。
+
+只在项目内安装真正需要的 Skills，工作台上就只摆当前用得到的资料，把宝贵的空间留给更重要的内容，Claude 干活也更高效。
+
+二、用软链接来安装 Skills
+
+这是我管理方式的核心，先解释一下什么是软链接。
+
+你可以把软链接理解成 Windows 的快捷方式——文件本体只有一份，但你可以在很多地方创建快捷方式指向它。改了本体，所有快捷方式指向的内容都会同步变化。
+
+我的具体做法分三步：
+
+第一步：把开源 Skills 项目下载到统一的目录
+
+我在电脑上有一个专门存放 GitHub 项目的文件夹 ~/GitHub，所有下载的开源项目都放在这里面，比如：
+
+~/GitHub/baoyu-skills      ← 存放各种 Skills 的开源项目
+~/GitHub/baoyu-design      ← 另一个开源项目
+
+这个文件夹就像一个仓库，所有 Skills 的原件都保存在这里。
+
+第二步：在自己的项目中创建软链接
+
+假设我有一个写作项目 ~/GitHub/baoyu-writing，里面需要用到好几个 Skills。我不会把 Skills 复制进来，而是创建软链接，让项目指向仓库里的原件：
+
+项目内的路径                         →  实际指向的位置（原件）
+.agents/skills/baoyu-comic          →  ~/GitHub/baoyu-skills/skills/baoyu-comic
+.agents/skills/baoyu-design         →  ~/GitHub/baoyu-design/skills/baoyu-design
+
+第三步：给 Claude Code 建一个入口
+
+最后再创建一个软链接，让 Claude Code 能找到这些 Skills：
+
+.claude/skills  →  .agents/skills
+
+这样 Claude Code 就能顺着这条链找到所有需要的 Skills 了。
+
+三、不用记命令，让 Agent 帮你干
+
+看到这里你可能会想：软链接的命令我记不住怎么办？
+
+完全不用记。直接用自然语言告诉 Codex/Claude Code 你要做什么就行了，比如：
+
+> 帮我把 ~/GitHub/baoyu-skills/skills/baoyu-comic 软链接到 .agents/skills/baoyu-comic
+
+甚至更简单：
+
+帮我把 baoyu-skills 项目里的 baoyu-comic 这个 skill 链接到当前项目
+
+Agent 会自动帮你创建软链接，后续的维护、添加、删除也都可以交给它。你只需要说清楚要把哪个 Skill 链到哪，剩下的脏活累活让 Agent 干就好。
+
+四、为什么值得这么折腾？
+
+初次设置确实比直接复制粘贴多花几分钟，但后续维护特别省心，主要有两个好处：
+
+好处一：更新只需一次。因为所有项目都是通过软链接指向同一份原件的，所以当开源项目有更新时，我只需要去 ~/GitHub/baoyu-skills 拉取最新代码，所有用到这个 Skill 的项目就自动变成最新版了。
+
+好处二：修了 bug 可以直接反哺。比如我在写作项目里用漫画 Skill 画漫画时发现了一个问题，直接让 Agent 修复就好。因为是软链接，Agent 修改的其实是仓库里的原件（~/GitHub/baoyu-skills/skills/baoyu-comic），我可以直接把修复提交到开源项目，相当于顺手给开源社区做了贡献。
+
+![](img_1.jpg)