文明雷达全球文明进程重大事件日报
China AI Builders · Real Cases · Workflows · Business

AI极客实战案例日报

China AI Builders · Real Cases · Workflows · Agents · Open Source · Business
日报日期
2026-10-03
生成时间
2026-10-08（补做）
精选案例
2 个（宁缺毋滥）
数据窗口
10-02 12:00 → 10-03 12:00
关于本期的生成方式：这是一份补做的日报。2026-10-03 当天的定时任务未执行，故在 2026-10-08 按当日应有的数据窗口回溯补做。数据窗口严格限定为 2026-10-02 12:00 → 2026-10-03 12:00（北京时间），所有时间戳均由 GitHub API 原始数据换算，未把窗口外的旧内容包装成「新案例」。当期无法二次核实的平台热度数据，本文一律标注为作者自述或未验证。
今日一句话

今天的两个案例都在做同一件事——把「内容消费」变成「可沉淀的资产」：一个把 Agent 的长回答从终端文字变成一页能读的 HTML，一个把网页、视频、播客变成 Obsidian 里可检索的笔记。它们共同的判断是：AI 时代最贵的不是生成，而是生成之后没人愿意再看第二眼。

01

用一个 Agent Skill + 自带渲染 CLI，把 Agent 的复杂回答从「一屏终端文字」变成「一页可读的 HTML」

Agent Skill AI + 知识呈现 Token 经济学 仓库创建 10-02 17:57（北京时间） 开源 MIT 性能数据均为作者自测
一句话结论：它把「排版」这件重复劳动从模型手里拿走交给程序，于是模型只需要写 1/8 的内容——这是 Skill 真正该有的样子。

01｜案例是什么？

中文开发者 QingYunA 开源了一个 Agent Skill：Answer me with HTML（MIT）。装进 Claude Code、Codex、Cursor、OpenCode 等 Agent 之后，你照常提问——「解释 TCP 三次握手」「把这个仓库的模块关系画出来」「Redis 还是 Memcached」——Agent 不会把答案糊成一屏终端文字，而是先写一份简短的 Markdown 草稿，交给 skill 自带的命令行工具，约 50 毫秒后输出一页单文件 HTML：带 SVG 示意图、排版和配色，离线也能打开。它不是让模型手写网页，而是让模型只写内容、把渲染交给确定性程序。

02｜为什么今天值得关注？

  • 窗口内的事实（可用 API 核实）：该仓库创建于 2026-10-02T09:57:40Z，即北京时间 10-02 17:57，正落在本期窗口（10-02 12:00 → 10-03 12:00）之内。窗口之后它持续高频迭代——从 10-05 的 v0.4.8 到 10-08 的 v0.4.15，几乎每天数个版本。
  • 它回答了一个具体问题：「既然模型能写 HTML，为什么还要一个 skill？」作者的答案是用 token 计数证明的——他统计了模型手写 9 个页面的用量，平均 4,893 token，其中 SVG 坐标 47% + CSS 15% + HTML 标签 17% = 79% 都不是内容。
  • 为什么以前不容易做：过去要「好看的答案」，要么请人做前端模板，要么让模型自己写 HTML——后者又贵又不稳定（坐标算错、样式崩）。这不是能力问题，是经济学问题。
  • 为什么现在变得容易：Agent Skills 规范在 2025–2026 年成为事实标准，一个 skill 可以打包 SKILL.md + 脚本 + 模板；Node CLI 让「渲染」变成一条命令。于是「模型写内容、程序管呈现」的分工第一次变得可以随手安装。

03｜案例的前世今生

前世。最早期的做法是让模型直接输出 Markdown——终端里能看，但没有图、没有排版，长回答依然难读。进阶做法是要求模型「用 HTML 回答」，模型确实写得出来，但代价是每一页都要重新算一遍 SVG 坐标、写一遍 CSS、补一遍标签，绝大多数 token 花在「搬砖」上。

发展。两条线慢慢成熟：① Agent Skills 把「可复用的作业规范」变成可安装的包（SKILL.md 定义何时触发、怎么用）；② 本地 CLI 的普及让「确定性计算」可以随时被 Agent 调用。两者一合，就出现了「模型只产出内容、程序负责呈现」的分工。

今生。本项目把这个分工做成了一个可安装的 skill：模型只写约 612 token 的 Markdown 草稿，其余交给自带 CLI。作者并给出了可复现的基准：仓库里带 bench/corpus/tokens.json 与 bench/corpus.mjs，同一份计数脚本可以跑出同样的数字。

下一步可能怎么发展（分析 / 推演）。「模型只写内容、程序负责呈现」很可能从单点 skill 扩散成一类基础设施：PPT、图表、报告、周报都可能出现同样的分工——模型产出结构化内容，渲染器负责美化。更进一步，可能出现「组织内统一的呈现规范 skill」，让全公司的 AI 输出长得像一个团队做的。以上为推演，非事实。

04｜原始资料

05｜作者是谁？

GitHub 账号 QingYunA（显示名 Cyan），公开资料显示 40 个仓库、39 个关注者。除此之外没有可核实的身份信息（公司、所在地、职业）。本文不猜。可以确认的是：这是一个长期在 GitHub 上活跃、且把「用中英双语写 README」当默认习惯的独立开发者。

06｜解决了什么真实问题？

从需求侧看，不是「AI 不会画图」，而是「开发者的 AI 回答用完即弃」：

  • 需求一（个人开发 / 学习者）。用 CLI Agent 问一个稍复杂的问题（协议原理、架构关系、技术选型），得到的是一大坨 Markdown。当时读得懂，第二天回看就找不到重点，也没法直接发给别人。
  • 需求二（要交付的人）。技术评审、方案说明、给非技术同事的解释——都需要一页能直接看的材料，而不是抄一段聊天记录。
  • 两者的共同点：不是不会问 AI，而是 AI 的输出形态不适合被「保存、回看、转发」。

07｜完整技术栈

模型项目本身不绑定模型。作者给出的基准使用 Claude Sonnet 5.5（评测环境为「一个普通的 Claude Code 环境」），但项目可装进 Claude Code / Codex / Cursor / OpenCode / Pi 等 Agent，也就是说用哪个模型由你正在用的 Agent 决定。本文不编造未出现的型号。
形态Agent Skill（SKILL.md 定义行为）+ 内置 Node CLI（负责渲染）
运行环境Node.js 20 或更新；无 npm install 步骤（CLI 打包在 skill 内）
安装器vercel-labs/skills（npx skills add），官方称支持 70+ 种 Agent；Claude Code 另有官方插件市场方式
输出物单文件 HTML（内含 SVG 与 CSS，离线可读）
语言JavaScript
许可MIT

08｜完整 Workflow

① 用户提问　「解释 TCP 三次握手」/「Redis 还是 Memcached」——用平时的方式提问
↓
② Agent 判定触发　skill 的 description 匹配「需要一页可读回答」的场景，加载 SKILL.md 规范
↓
③ 模型只写 Markdown 草稿　约 612 token——只写内容，不写 SVG 坐标、不写 CSS、不写标签
↓
④ 自带 CLI 渲染　约 50 毫秒，把草稿套进模板，生成 SVG 图、样式与语义标签
↓
⑤ 产出单文件 HTML　一页可滚动、可离线打开、可转发的答案
↓
⑥ （可选）always-on 模式　让「一页 HTML」成为默认输出形态，而不是每次手动触发

09｜它到底是怎么实现的？

剥掉包装，这套东西的技术内核只有一条，但它被量化得很干净：

机制：把「非内容」的部分从模型手里拿走。作者统计了模型手写 HTML 一页的 token 构成：

SVG 图（坐标与路径）47% —— 交给 CLI 生成
CSS15% —— 交给 CLI 生成
HTML 标签17% —— 交给 CLI 生成
正文文字21% —— 只有这块由模型写，且写的是 Markdown

结果是同一批问题，模型要写的量从平均 4,893 token 降到 612 token（约 1/8），作者给出的耗时中位数是 31 秒 → 12 秒（约 2.6× 快）。

一条容易被忽略的诚实之处：作者明确写了「账单降幅小于写作降幅，大约只降 15%」——因为每一轮对话无论用不用这个 skill，都要读系统提示、你的问题和历史对话。这句话本身就是很好的工程素养示范：优化输出 token ≠ 优化总成本。

为什么它可以工作？因为网页的「好看」本来就不是靠模型的创造力，而是靠固定的模板、间距、配色和图形语法。这些是确定性知识，应该由程序承担；模型的价值在于「读懂问题、组织内容」。把两者分开，双方都变强。

10｜手把手复现

以下 Step 1–4 整理自项目 README / INSTALL.md 明确写出的做法；Step 5–6 为原文推荐的验证与开启方式；Step 7 为本文补充建议，已单独标注。

Step 1（原文）。准备环境：安装 Node.js 20 或更新版本。项目不需要 npm install，CLI 已打包在 skill 里。

Step 2（原文·推荐）。让 Agent 自己装：把这句话粘给你常用的 Agent——「Install Answer me with HTML: read https://raw.githubusercontent.com/QingYunA/answer-me-with-html/main/INSTALL.md and follow it.」INSTALL.md 是专为 Agent 写的，会自动区分 Claude Code 插件与其它 Agent 的 skill 安装，不向你提问。

Step 3（原文·备选）。一条命令安装：npx skills add QingYunA/answer-me-with-html（会询问装进哪个 Agent）。Claude Code 用户还可以走官方插件市场：/plugin marketplace add QingYunA/answer-me-with-html。

Step 4（原文）。手动安装：把仓库里的 skills/answer-me-with-html 目录复制进你所用 Agent 的 skills 目录（Claude Code 为 ~/.claude/skills/）。

Step 5（原文）。验证：问一句「Explain the TCP three-way handshake」，按 INSTALL.md 的说法，安装流程最终会以这一页作为自检。

Step 6（原文）。开 always-on 模式，让「一页 HTML」成为默认形态，而不是每次手动召唤。

Step 7（本文补充的建议）。把它接到国产模型上：Skill 与渲染 CLI 都和具体模型无关，只要你的 Agent 能读写文件、能执行命令即可。国内用户可以在 TRAE / 通义灵码 / CodeBuddy / Qoder 这类客户端里挂国产模型，再把该 skill 装进去。此路径为本文推导，未经作者确认。

11｜Prompt / Code / Config

原作者公开的内容（可直接引用）：

  • SKILL.md——定义触发条件与使用方式（仓库 skills/answer-me-with-html/ 下）
  • INSTALL.md——面向 Agent 的安装说明（含 Claude Code 插件路径与通用 skill 路径）
  • bench/corpus/tokens.json 与 bench/corpus.mjs——token 计数数据集与可复现脚本，node bench/corpus.mjs 可跑出同样的数字
  • bench-corpus-2026-10-07.zip——基准用的页面成片（随 Release v0.4.14 分发）

本文根据原文总结的结构：「模型写 Markdown 草稿 → CLI 套模板渲染 → 单文件 HTML」三段式；以及 README 给出的安装命令。系统提示词全文、模板库的完整实现细节，作者未在 README 中逐行公开，本文不编造。

12｜踩坑

以下为项目 README / ISSUE 层面已公开的已知限制与注意事项，本文未独立复现：

  • 必须有 Node.js 20+。版本不够会让 CLI 起不来；项目没有 npm install 兜底，环境是硬门槛。
  • Agent 必须能读链接或能执行 npx。若你的 Agent 既打不开网页、也不允许执行命令，就无法自动安装，只得手动复制目录。
  • 去重成本别算错。作者自己提醒：省的是「输出 token」，读系统提示与对话上下文的那部分成本照旧，「账单只降约 15%」。把 1/8 直接当成成本降到 1/8 是误读。
  • 「作者自测」不等于普遍结论。8× token、2.6× 速度均来自作者自己的一小组基准（3 个主题 × 3 次运行），换模型、换问题类型结果可能不同。
  • 仓库在窗口后仍高速迭代。核实窗口内（10-02 至 10-03）该仓库只有创建事件；v0.4.x 的密集发布发生在 10-05 之后。本文引用的是后续公开内容，已在文中标注时间。

13｜中国用户能不能直接做？

  • 国内访问：有限制——仓库、Release、raw 文档均托管在 GitHub，直连不稳定，通常需要加速或镜像。
  • 注册：无需注册，纯本地 skill，无账号体系。
  • API：项目本身不需要额外的 API Key；成本发生在你使用的 Agent 模型上，用国产模型即可绕开境外 API。
  • 成本：skill 本体免费开源；实际成本 = 所用模型开销，用国产模型可压到很低。
  • 技术门槛：有一定门槛 需要 Node.js 20+、会用命令行、理解 Agent 的 skills 目录。

14｜国产替代方案

原方案Claude Code / Codex / Cursor / OpenCode / Pi + 该 Skill + Node CLI
中国用户方案DeepSeek / Qwen / GLM / Kimi 作为背后模型，装入 TRAE / 通义灵码 / CodeBuddy / Qoder / OpenClaw 等支持 skills 的客户端；渲染 CLI 与模型无关，理论上完全可用
替代性质理论替代（本文推导）。Skill 与模型解耦是项目自身设计（可装 5+ 种 Agent），但作者未验证过国产客户端；不能写成「已验证兼容」。

15｜中国企业可以怎么用？

  • 企业场景 1｜内部技术文档。让工程 Agent 把「模块关系」「调用链」「变更说明」直接输出成一页 HTML，贴进内部 Wiki 或发群，比截图和聊天记录都清楚。
  • 企业场景 2｜评审与决策材料。产品评审、方案选型、故障复盘——把「AI 给的结论」变成一页可以拿去开会的材料，减少「口头传达 → 二次整理」的损耗。
  • 企业场景 3｜数据分析结论页。把数据分析 Agent 的结论渲染成带图的一页，供运营、销售这类非技术角色直接阅读。

16｜中国消费者可以怎么用？

  • 学习笔记：把「解释一下某个概念」变成一页带图的说明页，存进本地，考前回看。
  • 决策对比：选手机、选课程、选保险——把 AI 的对比分析渲染成一页，和家人一起看。
  • 内容素材：自媒体作者可以先让 AI 生成一页「知识点图谱」，作为图文或视频的结构底稿。

17｜如何变成一个赚钱的项目？

产品化：把「呈现规范」做成可订阅的模板库——行业模板（财报解读、体检报告、教育讲义）+ 一键输出，卖模板而不是卖 skill 本身。

服务化：给企业做「AI 输出标准化」的落地服务：定义一套公司统一的 HTML 呈现规范，包装成内部 skill，交付后按月维护模板。

咨询化：帮企业判断「哪些 AI 输出值得被沉淀成资产」，属于 AI 工作流咨询的一个细分切口。

培训化：「从会问到会被记住：用 Skill 把 AI 输出变成资产」——半天工作坊即可交付一个可运行的模板。

内容化：拆解 token 经济学（79% 不是内容）本身就是极好的图文/视频选题，适合 B 站、公众号、掘金。

18｜变现路径

路径客户 ｜ 产品/服务 ｜ 收费方式 ｜ 难度
模板订阅个人/企业 ｜ 行业 HTML 呈现模板库 ｜ 订阅 ｜ 中
企业服务企业 ｜ AI 输出标准化 + 内部 skill 交付 ｜ 项目制 ｜ 中
咨询企业 ｜ AI 输出资产化咨询 ｜ 项目制 ｜ 高
培训企业/个人 ｜ 半天 Skill 工作坊 ｜ 按场/按人 ｜ 低
内容开发者 ｜ 拆解文章/视频/Newsletter ｜ 广告/付费 ｜ 低

注意：以上是基于案例结构的潜在商业模式分析，不是已验证的商业成功。作者本人未公开任何收入信息。

19｜如果我是一个中国独立开发者（7 天 MVP）

  1. Day 1：装 Node 20+，把 skill 装进国产 Agent（TRAE / CodeBuddy 等），用国产模型跑通「一页 HTML」。
  2. Day 2：选定一个垂直场景（建议：给中小企业做「经营数据周报页」），把默认模板改成该场景的排版。
  3. Day 3：把数据入口做小：一个 CSV / Excel 丢进去 → 一页经营周报（用国产模型做文字解读）。
  4. Day 4：封装成一条命令（脚本 + 模板目录），让别人无需懂 skill 也能跑。
  5. Day 5：找 3 个真实小企业主试用，记录他们最想改的 3 个地方。
  6. Day 6：按反馈改模板，加「导出 PDF / 分享链接」这两个最刚需的出口。
  7. Day 7：做一个落地页，写清「输入什么、输出什么、多少钱」，开始接触第一批付费意向。

20｜如何迁移到其他行业

① 教育培训把任意一节课的知识点渲染成「一页讲义」，学生可打印、可离线看。
② 医疗/体检解读把化验指标解读成一页带图说明，降低患者理解门槛（须严守合规）。
③ 电商运营把竞品对比、卖点分析渲染成一页，直接给主播或客服当话术底稿。

21｜培训课程设计

课程名称《让你的 AI 输出被记住：Agent Skill 与 token 经济学》
适合人群用 AI 写代码/写文档的职场人、独立开发者、企业效率负责人
建议时长半天（3 小时）
30 分钟 Demo同一个问题用「直接问」和「用 skill」各输出一次，现场对比可读性与耗时
60 分钟 Workshop学员把自己最常问的 3 个问题，做成自己的呈现模板
半天课程上午讲 Skill 机制与 token 经济学，下午各自产出一个可交付的行业模板
课程目标学员能够解释「为什么 79% 的 token 不该由模型写」，并独立装好、改好一个 Skill
现场 DemoTCP 三次握手 → 一页 HTML
学员练习为「本周工作汇报」做一个专属模板
课后作业把过去一个月最有价值的 AI 回答，全部沉淀成一页 HTML 档案
企业迁移为企业定义一套统一的「AI 输出呈现规范」并交付内部 skill

22｜培训师点评

这个案例真正值得教的是什么？不是「怎么装 skill」，而是「把可确定的事从模型手里拿走」这条判断。79% 的 token 花在了本该由程序做的事上——学会提这个问题，比学会任何一个工具都值钱。

23｜最终判断

落地性
高
中国市场相关性
中
商业价值
中
复现难度
中
变现潜力
中

说明：以上是案例属性描述，不是排名。「中国市场相关性中」是因为它更偏开发者工具而非直接的中国本地场景；但它的方法论（确定性交程序、不确定性交模型）对中国开发者迁移价值很高。

02

用「浏览器扩展 + 本地 helper」把网页、视频、播客变成 Obsidian 笔记：一条从「消费」到「沉淀」的完整链

AI + 内容 个人知识库 浏览器扩展 仓库创建 10-02 18:02（北京时间） 开源 MIT Star 266，热度中等
一句话结论：它押注的是一个正在成形的共识——AI 时代的内容消费必须「读的时候就顺手存下来」，而不是「先收藏，以后再整理」。

01｜案例是什么？

中文开发者「向阳乔木」（GitHub ID joeseesun）开源的浏览器扩展 乔木剪藏 · Qiaomu Clipper（Chrome Manifest V3，MIT）：它把「内容消费」和「知识沉淀」压进同一条链路。读文章时按 aaa 进阅读页、划线、向 AI 提问，按 eee 编辑 Markdown 后剪藏；看 YouTube / B站 / TED / 小宇宙时进学习播放器，加载或生成字幕、做双语对照、点时间戳回看；随时按 N 记下自己的理解，通过可选的本地 helper 直接追加进 Obsidian 的当日日记。界面完整支持简体中文、繁体中文、英文。

02｜为什么今天值得关注？

  • 窗口内的事实（可用 API 核实）：该仓库创建于 2026-10-02T10:02:23Z，即北京时间 10-02 18:02，落在本期窗口内；此后持续高频迭代（10-07 的 1.14.4 到 10-08 的 1.15.6）。
  • 为什么以前不容易做：「网页剪藏」是老赛道（Readwise、简悦、Obsidian 官方 Web Clipper 都做过），但过去它只解决「正文转 Markdown」这一件事——视频、播客、字幕、AI 问答、日记追加这几段是断的。
  • 为什么现在变得容易：① 浏览器扩展可以调本地进程（native messaging / helper），让「静默写入笔记库」成为可能；② 本机 ASR（MLX Whisper / Qwen3-ASR / faster-whisper）让「没有字幕的视频也能变成文稿」不再需要云端；③ LLM 让「围绕当前内容提问」变成随手可做。
  • 为什么值得花时间：「AI + 个人知识库」是中国用户需求密度极高、但一手开源作品稀缺的方向。这个项目把「读—看—听—问—记—存」串成了一条完整的工程链，而不是又一个收藏夹。

03｜案例的前世今生

前世。第一代剪藏工具（2013–2019）解决的是「网页正文怎么干净地变成 Markdown」，本质是「HTML 解析 + 模板」。它假设：你要保存的内容是文字，而且你有时间后来整理。

发展。三件事改变了前提：① 内容形态变了——大量知识在视频和播客里，而不是在网页里；② ASR 成本崩了——本机小模型就能把音频转文字；③ Obsidian 这类「本地优先」的笔记工具流行，让「笔记属于我自己」成为刚需，同时也带来了「怎么把东西写进去」的工程问题。

今生。乔木剪藏的做法是「把断掉的每一段都补上」：内容侧补齐视频/播客/字幕，理解侧补上 AI 问答与双语翻译，落库侧用本地 helper 直接写进 Obsidian。作者甚至在 README 里给出安装建议，直言「Chrome 商店公开版仍是 1.7.1，1.15.6 已提交审核，想现在就体验就把安装 prompt 交给有终端权限的 Agent」——这是一种很务实的开源交付姿态。

下一步可能怎么发展（分析 / 推演）。这类工具的走向大概率是「从剪藏到理解」：不只是把内容存下来，而是自动生成结构化笔记（要点、疑问、与已有笔记的关联），让「读过的」真正变成「记住的」。同时「local-first + 本地 ASR + 本地模型」的组合，会让它天然适合对数据外流敏感的行业用户。以上为推演，非事实。

04｜原始资料

05｜作者是谁？

GitHub 账号 joeseesun，显示名「向阳乔木」，自我描述为「爱钓鱼、喜欢听摇滚乐、每天洗冷水澡的 PM」，Twitter/X ID vista8；公开资料显示 225 个仓库、2,126 个关注者，属于长期活跃的中文独立开发者。README 里出现的是简体中文、繁體中文、English 三语界面，且附带自建文档站——开发者即可作者本人。除此之外的身份信息（公司、团队规模、是否商业化）未公开，本文不猜。

06｜解决了什么真实问题？

从需求侧看，痛点是「知识消费过剩 + 沉淀缺失」：

  • 需求一（学习者）。一篇文章读完了，收藏进浏览器书签就再也没打开；一个两小时的访谈视频看完，想回到「刚才那句话」却找不到时间点。
  • 需求二（外语内容消费者）。外语视频看得慢，需要原文与译文对照，但字幕工具和笔记工具是两套系统，来回切。
  • 需求三（本地优先的笔记用户）。用 Obsidian 的人最在意「数据在我手里」，但大多数剪藏工具要求登录云端账号、把内容先上传再同步。
  • 共同点：不是「没有工具」，而是工具之间是断的——阅读一个、字幕一个、问答一个、笔记一个。

07｜完整技术栈

模型不绑定模型。AI 提问与翻译使用「用户自己的服务与凭证」，需在 AI 模型设置中自行配置（可保存多套服务）。原文未点名具体模型厂商。
载体Chrome / Chromium 浏览器扩展（Manifest V3）；界面支持简体中文 / 繁體中文 / English
本地助手可选 helper（native 进程）：负责静默写入笔记库、追加学习日记、获取音频并生成字幕。macOS 版打包为带签名的 .pkg，自带 Python，无需另装环境；Windows / Linux 需按文档源码安装
ASR 引擎本机识别：Apple 芯片可选 MLX Whisper 或 Qwen3-ASR，其他环境可用 faster-whisper；云端识别：在设置里配置 ASR 服务与 Key，可保存多套并覆盖
目标平台文章类网页；视频：YouTube / B站 / TED；音频：小宇宙、SoundCloud 等；另支持粘贴媒体链接或本地音视频
笔记出口Obsidian（URI 方式或 helper 直接写入）；日记要求数字日期格式，且需开启 Obsidian「日记」核心插件
语言TypeScript（扩展本体）
许可MIT

08｜完整 Workflow

① 消费内容　打开文章 / 视频 / 播客页面，连按三次 A（或点扩展弹窗「阅读」）
↓
② 阅读 / 学习　文章进阅读页（调字体、划线）；视频进学习播放器（字幕栏、时间戳、双语对照）
↓
③ 获取字幕（如需）　优先读官方字幕；没有则调 helper 取音频 → 本机 ASR 或云端 ASR → 带时间的文稿
↓
④ AI 问答　围绕全文或选中段落提问；AI 回答可一并加入笔记卡片
↓
⑤ 记录自己的理解　学习页按 N、任意网页按 iii，打开笔记卡片（可带摘录与来源、时间点）
↓
⑥ 编辑与剪藏　按 eee 进整页 Markdown 编辑器，改标题/属性/正文，再复制、下载或剪藏
↓
⑦ 落库　helper 将笔记追加到今天的 Obsidian 日记；不提交到 RSS（作者明确说明）
↓
⑧ 回看　在 Obsidian 中检索、链接、形成自己的知识网络

09｜它到底是怎么实现的？

这个案例的技术含量不在「剪藏」，而在把四段原本互不相干的工程拼成了一条链：

① 内容侧的形态适配。文章、视频、播客三种内容，走的是同一条抽象：先拿到「可读的文本」（正文 / 字幕 / 转写文稿），再统一进入阅读或学习界面。所以同一个 aaa 快捷键在文章页进阅读器、在媒体页进学习播放器。

② 音频侧的本地优先。没有字幕时，helper 取音频交给所选引擎。作者特意区分了「本机识别（不上传云端）」与「云端识别（按服务计费）」两条路，并支持把标题、作者、简介作为识别背景来改善人名与术语的准确率——这是一个很实际的工程细节。

③ 落库侧的 native 通道。浏览器扩展本身受沙箱限制，无法静默写本地文件；helper 作为本地进程补上这个能力。作者还在 macOS 上把它打成自带 Python、已签名并通过 Apple 公证的 .pkg——「让不懂 Python 的人也能装」本身就是产品决策。

④ 数据边界的克制。README 明确写了「学习笔记追加到 Obsidian 日记，不会提交到 RSS」。在一个普遍默认「上云同步」的赛道里，主动划清数据边界，是 local-first 用户最在意的信号。

10｜手把手复现

以下 Step 1–5 整理自项目 README 明确写出的做法；Step 6–7 为原文给出的完整体验路径；Step 8 为本文补充建议。

Step 1（原文）。准备 Obsidian：安装 Obsidian 并创建或打开一个笔记库；若要用日记功能，需启用 Obsidian「日记」核心插件。

Step 2（原文·当前推荐）。让 Agent 帮你装：把 README 顶部那段安装 prompt 复制给 Codex、Claude Code 等有本机终端权限的 Agent，它会按仓库文档同时装扩展与 helper。

Step 3（原文·备选）。手动安装：下载最新 Release 里的 -chrome-local.zip 解压，在 chrome://extensions 开启「开发者模式」→「加载已解压的扩展程序」；macOS 再双击安装 qiaomu-clipper-helper.pkg。

Step 4（原文·源码构建）。开发者路径：git clone → npm ci → npm run build:local，然后加载 dist_local 目录。

Step 5（原文）。连接笔记库：扩展设置 →「剪藏与保存」→「笔记保存到」，从下拉列表选择 Obsidian 库（列表读取 Obsidian 已记录的库，也可选其他文件夹）。

Step 6（原文）。配 AI：在「AI 模型设置」里配置自己的服务与模型（提问、翻译）；如需云端字幕识别，在「ASR 语音识别」里配置服务与 Key。

Step 7（原文·完整流程演练）。打开文章按 aaa 阅读并提问 → 打开一个视频进学习页搜索字幕、点时间戳 → 按 N 写下理解并保存到日记。

Step 8（本文补充的建议）。先把默认 ASR 引擎设成本机识别（如 Qwen3-ASR / MLX Whisper），确认「音频不上传」；确认整条链路满意后，再决定是否切换云端引擎追求更高质量。此建议为本文推导。

11｜Prompt / Code / Config

原作者公开的内容（可直接引用）：

  • 安装 prompt（README 顶部完整文本）：指示 Agent 先读 README.md 与 native/README.md，按系统与浏览器下载 Release 的 -chrome-local.zip 与对应版本 helper，最后检查扩展与助手连接。
  • 源码构建命令：git clone / npm ci / npm run build:local / npm run build:chrome（作者并明确说明：build:chrome 产物不含本地版音视频下载功能）。
  • 快捷键约定：aaa 阅读、eee 编辑、N 记笔记、iii 任意网页记笔记。
  • 编辑器/落库约束：日记要求数字日期格式，且未配置日记模板。

原作者未公开的内容：扩展的完整源码结构说明、native helper 的内部实现细节、AI 提示词模板。本文不编造。

12｜踩坑

以下均为项目 README 自述的已知限制，本文未独立复现：

  • 升级扩展必须同时升级 helper。「仅重新加载扩展不会更新 helper」——这是最容易踩的坑，表现为「功能明明写了却没用」。
  • 商店版与源码版功能不一致。Chrome 商店公开版仍是 1.7.1，不含 1.15.x 的全部功能；且新版本用了新扩展 ID，旧 ID 的数据不会自动迁移，升级前要先备份。
  • 平台兼容不保证。B站字幕通常需要登录；抖音、TikTok、X、Vimeo 等的解析「取决于网站、登录状态和网络」；直播、DRM 与部分流媒体不保证可用。
  • Windows 助手尚待真机验证。作者明确写了「Windows 助手已有实现和自动测试，尚待真机验证」——这是很坦诚的自述。
  • 日记约束。需要 helper + Obsidian「日记」核心插件，且要求数字日期格式、未配置日记模板。

13｜中国用户能不能直接做？

  • 国内访问：扩展与 helper 从 GitHub Release 下载，直连不稳定；但项目本身定位中文用户（含简体/繁體界面、B站与抖音入口），并非为国内访问设置的障碍。
  • 注册：无需注册，无账号体系；笔记落在本地 Obsidian 库。
  • API：AI 提问/翻译与云端 ASR 需自备 Key；不配也能用——阅读、复制正文、复制已有字幕无需 AI。
  • 成本：扩展与 helper 免费开源；本机 ASR（如 Qwen3-ASR）不产生 API 费用，只吃本地算力；云端 ASR 与 LLM 按所用服务计费。
  • 技术门槛：普通用户可上手（走商店或 pkg 安装）／开发者级（源码构建与 Windows/Linux 助手）。

14｜国产替代方案

原方案浏览器扩展 + 本地 helper + 自带 ASR 引擎（MLX Whisper / Qwen3-ASR / faster-whisper）+ Obsidian
中国用户方案本项目本身就面向中国用户：默认支持简体中文界面、B站/小宇宙/抖音入口；ASR 已内置 Qwen3-ASR（阿里通义系）；AI 问答可接 DeepSeek / Qwen / GLM / Kimi
替代性质ASR 侧的 Qwen3-ASR 为项目 README 明示支持；LLM 侧为用户自行配置的通用 OpenAI 兼容接口，可指向国产模型（属社区/通用能力，作者未逐一点名验证）

15｜中国企业可以怎么用？

  • 企业场景 1｜行业情报与竞品监测。运营/市场人员每天看大量文章与访谈视频，用扩展把它们变成统一格式的笔记库，团队共用一套 Obsidian 库做沉淀（本地库，数据不出内网）。
  • 企业场景 2｜培训素材加工。把内部培训录播、公开课视频转成带时间戳的文稿并剪藏，作为课件底稿或知识库素材。
  • 企业场景 3｜访谈与会议复盘。访谈录音 / 会议音频 → 本机 ASR 转写 → 结构化笔记，避免敏感内容上传云端（须评估合规）。

16｜中国消费者可以怎么用？

  • 学一门新课：把网课、播客做成可检索、可回看的文稿，用 N 随手记自己的理解。
  • 追一个领域：长期把看过的文章剪藏进 Obsidian，慢慢长出属于自己的知识网络。
  • 外语内容：用双语字幕对照看外语视频，剪藏时选「原文 / 译文 / 双语」。

17｜如何变成一个赚钱的项目？

产品化：把「读—看—听—记」这套流程做成面向特定人群的垂直版：例如「考研党版」「自媒体选题版」「行业研究员版」，卖的是预设的笔记模板与工作流，而不是剪藏功能本身。

服务化：为企业做「内部知识库搭建」服务：部署一套自托管的笔记库 + 剪藏工具链 + 标签体系，交付规范与培训。

咨询化：帮团队设计「信息输入 → 加工 → 复用」的流程，属于知识管理咨询在 AI 时代的新形态。

培训化：《用 AI 搭建你的个人知识库》——目标明确、见效快，适合 2 小时的公开课。

内容化：「我怎么把三年读的东西变成能查的知识库」是天然的内容选题（B站/小红书/公众号）。

18｜变现路径

路径客户 ｜ 产品/服务 ｜ 收费方式 ｜ 难度
垂直模版包个人/学生 ｜ 行业笔记模板与工作流 ｜ 一次性/订阅 ｜ 低
企业部署企业 ｜ 本地知识库搭建与交付 ｜ 项目制 ｜ 中
知识管理咨询团队 ｜ 信息流程设计 ｜ 项目制 ｜ 高
培训个人/企业 ｜ 个人知识库工作坊 ｜ 按场/按人 ｜ 低
内容知识工作者 ｜ 方法论内容与社群 ｜ 会员/广告 ｜ 低

注意：以上为基于案例结构的潜在商业模式分析，非已验证的商业成功；作者未公开任何收入信息。

19｜如果我是一个中国独立开发者（7 天 MVP）

  1. Day 1：装好扩展 + helper + Obsidian，把默认 ASR 设为本机 Qwen3-ASR，跑通「视频 → 文稿 → 剪藏」。
  2. Day 2：选一个垂直人群（建议：考研 / 考公人群），设计一套「听课笔记模板」。
  3. Day 3：把模板固化成 Obsidian 的目录结构 + 模板文件，写一份「五步上手」文档。
  4. Day 4：录一条 3 分钟实操视频（从打开视频到笔记落库），作为获客素材。
  5. Day 5：在目标人群的社群免费发 10 份模板，收 3 个真实反馈。
  6. Day 6：按反馈改模板；加上「周复习清单」这个高粘性功能。
  7. Day 7：把「模板包 + 上手文档 + 社群答疑」打包定价，开始小范围收费。

20｜如何迁移到其他行业

① 企业培训把培训录播转成可检索文稿，剪藏进内部知识库，新人可自助查。
② 内容创作把竞品视频、行业访谈全部转文稿并归档，作为选题与金句素材库。
③ 法律 / 咨询把听证、访谈、会议录音本机转写后结构化归档，兼顾效率与数据边界。

21｜培训课程设计

课程名称《把看过的变成拥有的：用 AI 搭建个人知识库》
适合人群学生、知识工作者、需要长期跟进某领域的人
建议时长半天（3 小时）
30 分钟 Demo一条 B站视频 → 文稿 → 划线提问 → 笔记落进 Obsidian 日记
60 分钟 Workshop学员各自把自己最近读的 3 篇内容剪藏入库并建立链接
半天课程上午搭环境与工作流，下午设计自己的笔记结构与标签体系
课程目标学员能够独立搭建「阅读—字幕—提问—落库—复用」的完整闭环
现场 Demo外语视频双语对照 + 时间戳回看
学员练习为本周读到的一篇长文写一张「三句话 + 一个问题」的笔记卡
课后作业连续 7 天，每天剪藏一条内容并写下自己的理解
企业迁移为企业设计团队共用的输入—加工—复用知识流程

22｜培训师点评

这个案例真正值得教的是什么？不是「怎么装扩展」，而是「把消费和沉淀放到同一个动作里」。所有「先收藏、以后整理」的设计最终都会失败，因为这个案例把那条从内容到知识的断链，一段一段焊上了。

23｜最终判断

落地性
高
中国市场相关性
高
商业价值
中
复现难度
低
变现潜力
中

说明：以上是案例属性描述，不是排名。「复现难度低」指普通用户走商店/安装包即可用；「商业价值中」是因为它是一个优秀工具而非商业产品，变现要靠在其之上做垂直方案。

今日 AI 实战观察

从 10-03 这一天的两个案例看，中文开源圈正在出现的不是「更强的模型」，而是一组关于「AI 输出该怎么被消化」的工程共识。

第一，AI 的瓶颈正在从「生成」转向「接收」。案例 01 的用户痛点是「问到了但读不下去、存不下来」，案例 02 的痛点是「看过了但记不住、找不回」。两个项目都不是在提升模型能力，而是在优化「人怎么接收 AI 与世界给的信息」。这是一条非常中国化的主线——中国用户不缺工具，缺的是「用得下去」的工具。

第二，「确定性交给程序、不确定性交给模型」正在成为默认设计。案例 01 把 79% 的 token（SVG 坐标、CSS、标签）从模型手里拿走，只让模型写 21% 的内容；案例 02 把「写入文件」交给 native helper，把「理解内容」交给模型。两个案例都不约而同地做了同一件事：让模型只做它真正不可替代的部分。这比「换个更强的模型」务实得多。

第三，Agent Skill 正在变成一个真实的软件形态。案例 01 是纯 skill（SKILL.md + CLI），这说明 2025 年出现的 skill 规范已经从「提示词技巧」进化成「可分发的软件包」——它可以带二进制、带模板、带基准测试。这对中国开发者的意义是：你不需要做一个 App，也能做一个可安装的能力。

第四，本地优先重新变得重要。案例 02 的内置 ASR 用 Qwen3-ASR 且强调「本机识别不上传」，笔记落在本地 Obsidian。在云服务普及十年之后，「数据在哪里」再一次成为产品差异点——这对做企业侧 AI 的团队是明确信号。

今日商业机会雷达

机会 1｜AI 输出的「呈现标准化」服务

  • 客户：已大量使用 AI 但输出散乱的中小企业（研发、咨询、SaaS）
  • 实现方式：企业内部 Skill + 统一 HTML/文档模板库（基于案例 01 的方法）
  • 可能商业模式：一次性交付 + 模板维护订阅

机会 2｜个人 / 团队知识库搭建服务

  • 客户：知识密集型团队（研究、咨询、内容、培训）
  • 实现方式：本地优先笔记库 + 剪藏/转写工具链 + 标签与模板体系（基于案例 02）
  • 可能商业模式：项目制部署 + 后续培训与维护

机会 3｜「AI 输出资产化」培训

  • 客户：个人职场人、企业内训
  • 实现方式：半天工作坊，交付一个可直接用的模板与工作流
  • 可能商业模式：按场 / 按人收费，配合社群复购

以上均是基于案例结构的商业模式分析，不代表已验证的商业成功。

今日「个人变现机会」

如果一个人每天投入 2–4 小时，这两个案例可以这样长出个人业务：

  • 做垂直模板包。案例 01 的「呈现规范」和案例 02 的「笔记结构」都是「一次做好、长期复用」的资产。选定一个人群（考研、外贸、研究员），做一套模板定价出售。
  • 接知识库搭建单。帮小团队把「看的东西」变成「能查的库」，交付期 3–5 天，是典型的低资本、单人可启动的服务。
  • 做内容产品。把这两个案例的方法论写成系列文章或短视频（token 经济学、消费即沉淀），长期积累个人品牌，再转化咨询与课程。
  • 做行业解决方案。把「视频转文稿 + 结构化归档」打包成某个行业的固定交付（如律师访谈归档、培训课件加工）。

提醒：以上是低资本、单人可启动的机会方向，不构成收益承诺，也不代表一定能赚钱。真正的分水岭在于「你选的垂直场景是否有人愿意付钱」。

原始资料

案例 01 · Answer me with HTML

案例 02 · 乔木剪藏

明确排除的来源

本期检索过程中，以下站点的内容经核实为 SEO 内容农场（同一批模板化文章在多域名重复分发，无一手作者、无可验证项目），全部剔除，未作为任何案例或引用的来源：mhpq.cn、tzjp.cn、xxmr.cn、hqwc.cn、mwwr.cn、kwkr.cn、qwbw.cn、lpqz.cn（统称「尧图系」）。

数据真实性说明

已核实的事实（可通过 GitHub API 复核）

  1. 案例 01：QingYunA/answer-me-with-html 创建于 2026-10-02T09:57:40Z（北京时间 10-02 17:57），MIT 许可，主语言 JavaScript；Releases 在窗口后持续发布（v0.4.8 于 10-05 起）。
  2. 案例 02：joeseesun/qiaomu-clipper 创建于 2026-10-02T10:02:23Z（北京时间 10-02 18:02），MIT 许可，主语言 TypeScript；Releases 在窗口后持续发布（1.14.4 于 10-07 起）。
  3. 两案例的窗口内事件均为「仓库创建」；文中的 Release 版本号与时间均来自 GitHub API 原始数据，已换算为北京时间。

来自作者自述、本文未独立验证

  • 案例 01：「模型手写平均 4,893 token / 用 skill 后 612 token / 约 1/8」「31 秒 → 12 秒」「账单只降约 15%」——均为作者自测（自述为 3 个主题 × 3 次运行、Claude Sonnet 5.5 环境下的中位数），本文按原文口径转述，未独立复现。
  • 案例 02：各项功能的能力边界（B站需登录、部分流媒体不保证可用、Windows 助手尚待真机验证等）均为作者 README 自述，未在本文中逐项实测。

本文的分析与推演

  • 「前世今生」「下一步可能怎么发展」「企业/消费者场景」「迁移方向」「7 天 MVP」「课程设计」等，均为基于公开资料的分析与推演，已逐处标注；不代表项目作者的观点或计划。
  • 商业与变现部分的全部内容均为潜在模式分析，不是已验证的收入事实。

已做与未做的验证

  • 原作者账号存在（API 可查）
  • 仓库创建时间已核实
  • Release 时间线已核实
  • 许可类型已核实
  • README 原文已逐段核对
  • 未伪造作者未提供的步骤
  • 已区分事实 / 自述 / 推演
  • 已剔除内容农场来源
  • 未实测功能效果
  • 未核实 Star 增长曲线
  • 未联系作者求证
  • 窗口内仅创建事件，无社区反馈