Mobility的 RSS 预览

把笔记、微信读书、知乎装进 Obsidian：我基于llm-wiki知识中枢搭建实录

2026-06-26 16:18:13

前段时间，偶然看到karpathy大神提出的llm-wiki, 有种相见恨晚的感觉。我一直是很喜欢写些东西的，但是写完之后，问题就是大量内容散落在各个地方，一直没有精力对它们进行有效的管理。而看到了llm-wiki后，我就意识到，之前写的那些东西，要开始发挥作用了。<h2 id="为什么需要知识中枢"><a href="#为什么需要知识中枢" class="headerlink" title="为什么需要知识中枢"></a>为什么需要知识中枢</h2>首先, llm-wiki是什么。llm-wiki 是 Andrej Karpathy 在最近提出的一个概念：把你过往积累的所有文字材料——笔记、博客、读书摘录、工作日志——作为”语料库”，让 LLM 自动从中提取概念、建立页面、编织交叉引用，最终形成一个结构化的、可持续迭代的个人 Wiki。它的核心前提很简单：每个人在日常工作和学习中已经产生了大量有结构、有见解的文字，只是它们散落在各处，缺乏关联。llm-wiki 要做的就是用一个 LLM 驱动的流程，把这些散落的珍珠串起来。你负责持续产生和收集内容，LLM 负责组织和管理。和传统的手动 Wiki 维护不同——建页面、写摘要、加链接，枯燥且难以坚持——llm-wiki 把组织成本降到了几乎为零。你只需要告诉 LLM 你的知识库结构和维护规则（即一个 AGENTS.md 文件），它就能反复执行摄入、更新、审计等操作。我自己实践下来的感受是，看着 AI 把零散笔记变成结构化的交叉引用网络，有一种”债务清零”的快感。<h2 id="数据接入"><a href="#数据接入" class="headerlink" title="数据接入"></a>数据接入</h2>我做的第一件事，就是把之前在notion里写的各种笔记，有开发知识、投资知识，还有各种各样零碎的记录，都导出然后放到了obsidian里。如何将 Notion 内容导入 Obsidian？实际操作并不复杂，核心步骤如下：<ol><li>导出 Notion 数据：在 Notion 的”设置与成员 → 设置”中，选择”导出所有工作区内容”，格式选 Markdown & CSV。导出后会得到一个 ZIP 包，解压后每个 Notion 页面对应一个 <code>.md</code> 文件，数据库则额外附带 CSV。注意：Notion 免费版每次只能导出一个工作区，如果你有多个工作区，需要分别操作。</li><li>安装 Obsidian Importer 插件：在 Obsidian 社区插件市场搜索”Importer”并安装。这个插件支持从 Notion、Bear、Evernote、OneNote 等多种工具一键导入，会自动处理图片附件和内部链接。启用插件后，用 <code>Cmd+P</code> 打开命令面板，搜索”Importer: Open Importer”，选择 Notion 格式，选中刚才解压的文件夹即可。</li><li>手动导入（备选方案）：如果不使用 Importer 插件，直接将解压后的文件夹放入 Obsidian vault 目录即可。Obsidian 原生支持 <code>[[wiki-link]]</code> 格式的内部链接，Notion 导出的 Markdown 中的链接通常已经转换为该格式。</li><li>后续处理：导入后建议将原始文件放入一个专门的子目录（比如 <code>raw/notion-export/</code>），标记为”不可修改”。这样保留了原始数据的完整性——这是 llm-wiki 方法论中很重要的一环：原始素材永不可改，LLM 在此基础上生成结构化知识。如果你的 Notion 中有数据库，CSV 文件可以作为参考保留；如果某些页面嵌入了 Notion 特有的 Block（如日历、看板），导出后这些会丢失交互性，但文本内容会保留。</li></ol>整个流程走下来，我几千条分散的笔记就这样汇入了 Obsidian，成为了知识中枢的第一批”原料”。然后将karpathy那篇gist喂给AI, 生成出项目的AGENTS.md文档，AI能够自然的写出llm-wiki所需的摄入、审计等操作。接着就可以执行了。看着AI不停的生成wiki内容，把我之前的积累分类整理，还是非常舒适的。再往后，我又做了几件事，就是把知乎的创作和微信读书的笔记也纳入进来。知乎上我写了上千篇回答，微信读书几年读了上百本书，除了笔记之外，这些也是我知识体系的重要组成部分。正好，差不多那段时间，微信读书发布了官方的skill, 我也就顺手用了起来。<h2 id="知乎收藏导入"><a href="#知乎收藏导入" class="headerlink" title="知乎收藏导入"></a>知乎收藏导入</h2>如何将知乎创作同步到 Obsidian？知乎没有提供官方的数据导出 API，这里我用 Playwright 做了浏览器自动化。操作步骤：<ol><li>安装 Playwright：<code>pip install playwright && playwright install chromium</code></li><li>首次运行脚本，在打开的 Chromium 浏览器中扫码或密码登录知乎</li><li>登录成功后脚本自动遍历个人主页，抓取所有回答、文章和想法</li><li>登录状态持久化保存到本地，后续通过 <code>--reuse</code> 参数静默执行，无需再次登录</li></ol>特点：增量同步，每次只抓取新内容，已有文件不重复处理；按回答/文章/想法分类存放。<h2 id="微信读书笔记同步"><a href="#微信读书笔记同步" class="headerlink" title="微信读书笔记同步"></a>微信读书笔记同步</h2>如何将微信读书笔记同步到 Obsidian？微信读书开放了 Agent API Gateway，申请 API Key 后即可调用。操作步骤：<ol><li>调用 <code>/user/notebooks</code> 接口获取有笔记的书籍列表</li><li>对每本新书，分别拉取划线和想法内容</li><li>按章节分组，输出为规范的 Markdown 文件</li></ol>输出格式：书名和作者作为标题，每章划线以引用块形式列出（附带日期），笔记和想法附在对应原文下方。特点：完全增量同步，脚本维护已同步书籍 ID 的状态文件，每次运行只处理新增的书籍。151 本书的笔记就这样悄无声息地流入了 Obsidian，成为了知识中枢最丰富的一批原料。<h2 id="LLM-Wiki-智能检索"><a href="#LLM-Wiki-智能检索" class="headerlink" title="LLM Wiki 智能检索"></a>LLM Wiki 智能检索</h2>到此，内容层的准备基本就完成了。然后我又想，既然我大部分的知识和创作都在这儿了，是不是可以开始蒸馏我这个人了？这块先搞了一版简单的，就是把拆分出一个和wiki类似的personal流程，也有ingest、lint等流程，区别就是wiki的重点是知识，而personal的重点是我这个人。知识库 vs 人格蒸馏：两种不同的 AI 处理逻辑这里有必要解释一下两者的区别——它们共享同一套原始素材，但目标和产出完全不同。知识库（Wiki）：回答”我知道什么”从笔记、博客和读书摘录中提取客观知识，生成概念页面（如”分布式一致性”）、实体页面（如”Raft 算法”）、来源摘要页面（如”《数据密集型应用设计》读书笔记”），并在它们之间建立密集的交叉引用。目标是让知识变得可查询、可复用，像一个外部化的第二大脑。人格蒸馏（Personal Model）：回答”我是谁”从创作和阅读中反向推导认知模式、表达风格和价值取向。例如，通过分析技术博客，可以归纳出”论点先行、案例驱动”的表达风格；通过分析知乎回答，可以发现”第一性原理还原”和”量化思维”等反复出现的认知特征。产出不是知识条目，而是一个人的认知图谱——擅长什么、怎么思考、看重什么。两者的异同<table><thead><tr><th>维度</th><th>知识库</th><th>人格蒸馏</th></tr></thead><tbody><tr><td>核心问题</td><td>我知道什么</td><td>我是谁</td></tr><tr><td>输入</td><td>笔记、博客、读书摘录</td><td>一切个人创作和阅读记录</td></tr><tr><td>产出</td><td>概念/实体/来源页面 + 交叉引用</td><td>领域深度/认知特征/表达风格/价值观</td></tr><tr><td>方向</td><td>向外看：结构化外部知识</td><td>向内看：建模个人认知</td></tr><tr><td>流程</td><td>摄入 → 查询 → Lint → 审计</td><td>摄入 → 查询 → Lint → 审计（同构）</td></tr></tbody></table>两者在流程上高度相似，但一个是向外看，结构化和整理你拥有的知识；一个是向内看，蒸馏和建模你作为个体的认知特征。这种”一体两面”的设计，是我觉得整个系统最有意思的地方。这块最近还在看网上的女娲等项目，想看看有没有更好的蒸馏人格的方法。<h2 id="效果与心得"><a href="#效果与心得" class="headerlink" title="效果与心得"></a>效果与心得</h2>以上就是近期关于知识库的一些实录，有想法欢迎交流。<h2 id="常见问题"><a href="#常见问题" class="headerlink" title="常见问题"></a>常见问题</h2><h3 id="Q-Obsidian-适合程序员做知识管理吗？"><a href="#Q-Obsidian-适合程序员做知识管理吗？" class="headerlink" title="Q: Obsidian 适合程序员做知识管理吗？"></a>Q: Obsidian 适合程序员做知识管理吗？</h3>非常适合。Obsidian 的核心理念——本地 Markdown 文件、双向链接、图谱可视化——天然契合程序员的使用习惯。Markdown 语法你本来就会，文件存储在本地意味着数据完全可控、可以用 Git 做版本管理，双向链接让你能像管理代码依赖一样管理知识之间的引用关系。加上 llm-wiki 的思路，AI 可以自动帮你从散落的笔记中提取概念、建立页面和交叉引用，把零散文档变成结构化的知识网络。<h3 id="Q-LLM-Wiki-需要-GPU-吗？"><a href="#Q-LLM-Wiki-需要-GPU-吗？" class="headerlink" title="Q: LLM Wiki 需要 GPU 吗？"></a>Q: LLM Wiki 需要 GPU 吗？</h3>不需要自己部署 GPU。LLM Wiki 的核心理念是让 LLM 处理你的文本，而不是让你自己跑模型。你只需要调用大模型的 API（云端推理），用它来读取你的 Markdown 文件、提取概念、生成页面和交叉引用。这个过程走的是云端 API，不需要本地 GPU。实际上整个流程的”硬件”只需要 Obsidian 和一个能调用 LLM API 的工具（如 WorkBuddy 等 Agent）。<h3 id="Q-llm-wiki-和传统-Wiki-有什么区别？"><a href="#Q-llm-wiki-和传统-Wiki-有什么区别？" class="headerlink" title="Q: llm-wiki 和传统 Wiki 有什么区别？"></a>Q: llm-wiki 和传统 Wiki 有什么区别？</h3>传统 Wiki 需要你手动创建页面、写摘要、添加内部链接，维护成本高且难以坚持。llm-wiki 把组织成本降到了几乎为零——你只需要继续产生和收集文字内容，LLM 自动读取你的 AGENTS.md 规则，反复执行摄入、更新、审计等操作，生成结构化的交叉引用网络。换句话说，传统 Wiki 是”你组织知识”，llm-wiki 是”AI 帮你组织知识”。<h3 id="Q-知识蒸馏和人格蒸馏有什么不同？"><a href="#Q-知识蒸馏和人格蒸馏有什么不同？" class="headerlink" title="Q: 知识蒸馏和人格蒸馏有什么不同？"></a>Q: 知识蒸馏和人格蒸馏有什么不同？</h3>两者共享同一套原始素材，但目标和产出完全不同。**知识库（Wiki）**回答”我知道什么”——从笔记和读书摘录中提取客观知识，生成概念页面和交叉引用。**人格蒸馏（Personal Model）**回答”我是谁”——从创作和阅读记录中反向推导你的认知模式、表达风格和价值取向。一个向外看（结构化知识），一个向内看（建模个人认知），流程相似但方向相反。<h2 id="快速上手步骤"><a href="#快速上手步骤" class="headerlink" title="快速上手步骤"></a>快速上手步骤</h2><ol><li>安装 Obsidian：从 <a href="https://obsidian.md/">obsidian.md</a> 下载客户端，创建本地 Vault（知识库），即为一个本地文件夹。</li><li>配置 LLM Wiki：在 Vault 根目录创建 <code>AGENTS.md</code>，参照 karpathy 的 llm-wiki 思路编写知识维护规则，包括摄入（ingest）、更新、审计（audit）等流程定义。让 AI 工具读取该文件，自动从原始笔记中提取概念、建立交叉引用。</li><li>导入 Notion 笔记：在 Notion 设置中导出为 Markdown + CSV 格式，使用 Obsidian Importer 插件一键导入，或将解压的 Markdown 文件夹直接放入 Vault 目录。</li><li>接入微信读书：申请微信读书 API Key，调用 <code>/user/notebooks</code> 接口获取书籍列表，拉取划线和笔记，按章节分组输出为 Markdown 文件存入 Vault。</li><li>导入知乎与博客：使用 Playwright 脚本自动抓取知乎回答和文章；将博客 Markdown 源文件复制到 Vault。完成后让 AI 执行一次全量 wiki 摄入，生成完整的知识交叉引用网络。</li></ol>原文地址：<a href="https://lichuanyang.top/posts/18804/">https://lichuanyang.top/posts/18804/</a>

免费AI视频生成器：我如何用零成本做出带旁白字幕的多场景AI视频

2026-06-16 13:20:05

<blockquote>“解决的办法不是压制 AI，而是让它变成一种更平权的能力，让每个人都知道如何借 AI 创造更多。这也是我们公司很重要的愿景，让世界级的 AI 属于每一个人。”</blockquote>这是 Agnes AI 创始人 Bruce Yang 接受采访时说的一段话。现在很多国内的AI厂商，无论deepseek还是智谱，都在把AI的价格往下压。坦率的讲，像文字、代码的处理价格，确实已经被压到了一个相当低的价格。但视频不一样，现在做AI视频，门槛确实高得离谱——国外的 Runway、Pika 按月订阅几十美元，国内的即梦、可灵免费额度用完就按秒计费，想本地跑开源模型？一张能跑视频的显卡轻松上万。客观来讲，视频的生成，现阶段确实成本较高，让工业级的视频生成能力属于每一个人，确实不现实。但普通人也应该有一些途径能更多的去尝试、去创作，感谢Agnes开放自己的视频模型，让大家有这个机会。而这个项目只是想为了这个做一些微不足道的贡献。 <a href="https://github.com/lcy362/agnes-video-generator">Agnes Video Generator</a>（<a href="https://video.lichuanyang.top/">官网</a>）。说白了就是一个免费的AI视频生成器，不是那种”免费试用3次”的套路，是从写文案到出片、配音、上字幕，全程不花一分钱。只需要去 <a href="https://platform.agnes-ai.com/">Agnes AI</a> 注册个免费API Key就行。Agnes的视频模型，目前确实称不上完美，但我想用这么一个项目，和Agnes一起成长，为AI平权，贡献上一点微不足道的力量。<h2 id="多种玩法"><a href="#多种玩法" class="headerlink" title="多种玩法"></a>多种玩法</h2>给它一句话描述，它还你一条视频。分几种类型：简单视频。 纯粹对API的封装，用来测试效果的，接口的各种参数，基本都做成了配置。创意视频。 你写一个故事创意，比如”暗黑版青蛙王子”，AI全包：扩展故事→生成角色参考图→拆分场景→写分镜提示→逐段生成视频→配音→上字幕→拼接成片。全程10步自动跑完，你只需要等着看成片。通过预生成尾帧，可以最大限度的保障场景间视频的连贯性。文稿视频、数字人口播。 贴一篇长文章进去，自动按语音时长分段，每段生成画面，或者放一个数字人在那里念稿。用一条完整的TTS旁白和字幕串起来。做知识区内容的可以试试。各模式的详细参数和玩法，可以到<a href="https://video.lichuanyang.top/">官网</a>上看，这里就不展开了。<h2 id="跑起来很简单"><a href="#跑起来很简单" class="headerlink" title="跑起来很简单"></a>跑起来很简单</h2><figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>git clone https://github.com/lcy362/agnes-video-generator.git cd agnes-video-generator ./start.sh </pre></td></tr></table></figure>就这三步。<code>start.sh</code> 会自动帮你建虚拟环境、装依赖、启动服务。启动后打开 <code>http://localhost:8765</code>，在页面顶部填上你的 Agnes AI API Key，选个模式，写你的创意，点生成，然后耐心等结果就行。用 Cursor 或者 Claude 这些AI Agent的话更方便，我专门为Agent做了使用说明，直接让你的Agent读项目里的Agents.md文件，它自己就能把环境搞好、把服务跑起来。<h2 id="看看效果"><a href="#看看效果" class="headerlink" title="看看效果"></a>看看效果</h2>做了几个demo,可以看看效果：<ul><li><a href="https://v.douyin.com/L4F6KdGnD6U/">暗黑版《青蛙王子》无旁白版</a> — 5个场景用关键帧衔接，全自动生成</li><li><a href="https://v.douyin.com/l2FlbF1Jdz0/">同一个故事加了旁白字幕</a> — AI配音 + 自动字幕，可以看看字幕的效果</li><li><a href="https://v.douyin.com/eSGE9KENWVU/">文稿视频</a> — 贴了篇长文进去自动分段，每段配不同画面</li></ul><h2 id="最后"><a href="#最后" class="headerlink" title="最后"></a>最后</h2>回到开头 Bruce Yang 说的那句话——「让世界级的 AI 属于每一个人」。这个项目不是什么宏大的事业，就是想让 AI 视频创作这道门开着。不用订阅、不用好显卡、不用花一分钱，你只需要一个免费的 API Key 和一台能跑 Python 的电脑。代码在 <a href="https://github.com/lcy362/agnes-video-generator">GitHub</a>，官网在 <a href="https://video.lichuanyang.top/">video.lichuanyang.top</a>。欢迎提bug。原文地址：<a href="https://lichuanyang.top/posts/22470/">https://lichuanyang.top/posts/22470/</a>

Agnes免费模型真能白嫖视频？我改造了ViMax来试试

2026-06-11 22:00:00

前阵子我在薅各种免费AI token，写了一篇关于”哪里免费去哪里薅”的文章。当时提到过，各家平台会不定期放出免费模型。结果没等多久，Agnes AI 就给了我一个惊喜：视频模型也免费了。不是文字，不是图片，是视频。<code>agnes-video-v2.0</code>、<code>agnes-image-2.1-flash</code>、<code>agnes-2.0-flash</code>，三个模型全免费，注册就送API Key，不要信用卡，不要GPU。其中 Agnes-Video-V2.0 是目前免费 agnes video 生成方案里能力最强的一个，支持多种生成模式，质量相当能打。这谁忍得住？我直接把开源框架 ViMax 改造成了 Agnes 全家桶方案，顺便把原来一些反人类的用法都优化了一遍。<h2 id="Agnes免费模型：到底给了什么"><a href="#Agnes免费模型：到底给了什么" class="headerlink" title="Agnes免费模型：到底给了什么"></a>Agnes免费模型：到底给了什么</h2>先说 Agnes 这波免费到底给了啥。在 <a href="https://platform.agnes-ai.com/">Agnes AI 平台</a> 注册之后，拿到一个 API Key，就能用三个模型：<ul><li>agnes-2.0-flash（对话模型）：写故事、编剧本、生成prompt，标准的chat接口</li><li>agnes-image-2.1-flash（图片模型）：text-to-image，生成角色参考图、关键帧</li><li>agnes-video-v2.0（视频模型）：支持 text-to-video、image-to-video、keyframes 三种模式</li></ul>API 走的是 OpenAI 兼容格式，base URL 在 <code>https://apihub.agnes-ai.com/v1</code>，对接起来非常丝滑。视频模型是异步的——提交任务拿task_id，然后轮询结果，跟大多数云端视频生成服务一个套路。关键是：这三个模型串起来，刚好覆盖了”创意 → 故事 → 图片 → 视频”的完整链路。 不需要混用别家服务，一个 API Key 搞定所有事。<h2 id="改造思路：从多供应商到-Agnes-一把梭"><a href="#改造思路：从多供应商到-Agnes-一把梭" class="headerlink" title="改造思路：从多供应商到 Agnes 一把梭"></a>改造思路：从多供应商到 Agnes 一把梭</h2>原版 ViMax 是港大开源的 Agentic 视频生成框架，设计得很通用——LLM 用一家的、图片生成用一家的、视频生成又是一家的。好处是灵活，坏处是你要管三套 API、三套认证、三套错误处理。我的改造思路很简单：既然 Agnes 三个模型全免费，那就全部换成 Agnes，一个 API Key、一个 base URL，省事。具体改了什么：编剧模块：把原来的 LLM 调用全换成 <code>agnes-2.0-flash</code>。它负责从你的一句话创意出发，生成完整故事、拆分场景、写每场景的视觉prompt，还要给每个场景生成尾帧描述。用的是 OpenAI 兼容的 chat/completions 接口，temperature 0.7，够用了。图片生成器：换成 <code>agnes-image-2.1-flash</code>（t2i）和 <code>agnes-image-2.0-flash</code>（i2i）。前者生成角色参考图，后者做场景间的过渡帧图片编辑。视频生成器：换成 <code>agnes-video-v2.0</code>，这是核心。支持三种模式——纯文字生成视频（t2v）、图片引导视频（ti2vid）、关键帧插值（keyframes）。每场景支持5到20秒，帧率24fps。改完之后，整个项目只依赖一个 API 服务商。<code>.api_key</code> 文件里写一个 key，完事。<h2 id="易用性优化：别让用户想太多"><a href="#易用性优化：别让用户想太多" class="headerlink" title="易用性优化：别让用户想太多"></a>易用性优化：别让用户想太多</h2>原版 ViMax 的用法比较”研究项目风”——参数硬编码在代码里，改个创意得改源码。这不太行，所以我在易用性上做了一堆改进。<h3 id="YAML-创意配置"><a href="#YAML-创意配置" class="headerlink" title="YAML 创意配置"></a>YAML 创意配置</h3>最大的改动是引入了 YAML 创意文件。在 <code>creatives/</code> 目录下，一个创意就是一个 <code>.yaml</code> 文件：<figure class="highlight yaml"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 </pre></td><td class="code"><pre>name: "frog" idea: | 暗黑童话版青蛙王子，公主亲了青蛙之后， 青蛙变成了一个更可怕的怪物 user_requirement: | 5个场景，每个10秒，哥特暗黑风 style: "哥特暗黑童话风格" chaining_mode: keyframes video_width: 768 video_height: 1152 </pre></td></tr></table></figure>想拍新视频？写个 YAML，跑一条命令，完事。不用再碰 Python 源码了。<h3 id="一键启动脚本"><a href="#一键启动脚本" class="headerlink" title="一键启动脚本"></a>一键启动脚本</h3><code>start.sh</code> 做了一键封装：自动加载 <code>.api_key</code>、自动激活虚拟环境、自动列出可用创意、自动跑 pipeline。不传参数就列出所有创意，传个名字就直接跑：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>./start.sh # 列出所有创意 ./start.sh frog # 跑"青蛙王子" </pre></td></tr></table></figure><h3 id="智能缓存与断点续跑"><a href="#智能缓存与断点续跑" class="headerlink" title="智能缓存与断点续跑"></a>智能缓存与断点续跑</h3>这个必须说，因为视频生成是真的慢。每个中间结果——故事文本、场景脚本、角色参考图、每场景视频——全部持久化到磁盘。跑到一半断了？重新跑同一个创意，已完成的步骤直接跳过，只生成缺失的部分。最细粒度的是视频缓存：5个场景跑了3个断了，重跑只生成剩下2个。不会从头来。<h3 id="多模态图片分析"><a href="#多模态图片分析" class="headerlink" title="多模态图片分析"></a>多模态图片分析</h3>你可以自己提供角色参考图，也可以给每个场景自定义尾帧图片。系统会通过多模态 LLM 分析这些图片的内容，把视觉信息融入故事和 prompt 生成。比如你提供一张自己画的卡通人物，系统会自动识别它的外貌特征，在后续所有场景里保持一致。<h2 id="角色一致性：两阶段锁定"><a href="#角色一致性：两阶段锁定" class="headerlink" title="角色一致性：两阶段锁定"></a>角色一致性：两阶段锁定</h2>AI视频最大的坑就是角色一致性——第一个场景是黑发妹子，第二个场景突然变成金发了。ViMax-Agnes 用了一个两阶段方案：第一阶段：先生成（或你提供）一张角色参考图。编剧模块会从故事里提取角色的详细外貌描述——体型、发型、服装、配色、标志性特征——然后让图片模型生成一张全身参考图。第二阶段：每个场景视频都以这张参考图为起始帧，通过 <code>ti2vid</code> 模式生成。视频模型从同一个视觉锚点出发，自然保持了角色的一致性。实测下来，卡通/风格化画风的一致性效果最好。写实风格的话，建议直接提供自己的参考图，比 AI 生成的更可控。<h2 id="三种场景串联模式"><a href="#三种场景串联模式" class="headerlink" title="三种场景串联模式"></a>三种场景串联模式</h2>这是我觉得改造最有意思的部分。原版 ViMax 有场景串联的概念，但我在 Agnes API 上做了三种模式的适配：<code>none</code>（独立模式）：每个场景独立生成，共用同一张角色参考图。速度最快，但场景之间没有过渡，硬切。<code>ti2vid</code>（过渡帧模式）：顺序生成，每个场景结束后提取尾帧，用 img2img 生成一张”过渡帧”，作为下个场景的起始帧。过渡比较自然，但误差会累积——前面场景的瑕疵会传到后面。<code>keyframes</code>（关键帧模式）：这是推荐方案。每个场景同时指定首帧和尾帧，让视频模型在两个关键帧之间做插值。尾帧由 AI 根据场景描述自动生成（你也可以手动指定）。这样每个场景的起点和终点都是确定的，过渡最平滑。三种模式在 YAML 里一个字段切换，不用改代码。<h2 id="实战效果"><a href="#实战效果" class="headerlink" title="实战效果"></a>实战效果</h2>跑几个创意试了一下：<ul><li>青蛙王子：5场景暗黑童话，keyframes模式，全自动生成</li><li>女孩扣篮：3场景运动主题，角色一致性保持得不错</li><li>海边舞蹈：4场景MV风格，场景过渡比较丝滑</li><li>温泉机器人：3场景治愈风，卡通风格一致性最好</li></ul>每个创意从提交到出片，主要瓶颈在视频生成——每场景大概需要几分钟等待。但因为有缓存，调试成本其实不高。<h2 id="一些-Agnes-Video-V2-0-技术细节"><a href="#一些-Agnes-Video-V2-0-技术细节" class="headerlink" title="一些 Agnes-Video-V2.0 技术细节"></a>一些 Agnes-Video-V2.0 技术细节</h2>给想深入玩的朋友补充几个实现细节：视频参数：帧数遵循 <code>8n+1</code> 规则，上限441帧。5秒121帧、10秒241帧、15秒361帧、18秒和20秒都是441帧（帧率分别是24和22fps）。图片上传：视频API需要图片URL而不是base64，所以本地图片会通过图片生成API”上传”——用 <code>agnes-image-2.1-flash</code> 做一次 prompt 为”保持图片不变”的 i2i 转换，拿到一个托管URL。如果上传失败，回退到 inline base64。重试机制：视频提交遇到429（限流）或5xx（服务端错误），会自动指数退避重试，最多5次。轮询没有超时——视频生成就是这么慢，你得等。最小依赖：整个项目只依赖5个Python包：requests、pydantic、PyYAML、moviepy、tenacity。不需要PyTorch，不需要CUDA，纯API编排层。<h2 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h2>Agnes 这波免费模型的诚意还是挺足的。agnes免费模型覆盖了文字、图片、视频全链路，API格式兼容OpenAI，注册门槛极低。对于想玩AI视频生成但不想烧钱的朋友来说，是个不错的入门选择。ViMax-Agnes 的改造也让我验证了一件事：当免费模型的质量够用的时候，”哪里免费去哪里薅”的策略完全可以从文本扩展到视频。 一个 API Key、一条命令、一个 YAML 文件，就能从一句话生成一个完整的多场景视频。项目开源在这里：<a href="https://github.com/lcy362/vimax-agnes">github.com/lcy362/vimax-agnes</a>，欢迎 star 和提 issue。<blockquote>2026年6月更新：本文工具已迭代为 <a href="https://github.com/lcy362/agnes-video-generator">Agnes Video Generator</a>，支持 Web UI 和多语言，功能更完善，推荐使用新版本。</blockquote>原文地址：<a href="https://lichuanyang.top/posts/65500/">https://lichuanyang.top/posts/65500/</a><h2 id="快速上手步骤"><a href="#快速上手步骤" class="headerlink" title="快速上手步骤"></a>快速上手步骤</h2><ol><li>环境准备：注册 <a href="https://platform.agnes-ai.com/">Agnes AI 平台</a> 账号，获取 API Key。确保本地已安装 Python 3.8+ 和 Git。</li><li>克隆项目：<code>git clone https://github.com/lcy362/vimax-agnes && cd vimax-agnes</code>，将 API Key 写入 <code>.api_key</code> 文件。</li><li>创建创意配置：在 <code>creatives/</code> 目录下新建 YAML 文件，定义 <code>name</code>、<code>idea</code>、<code>style</code>、<code>chaining_mode</code> 等参数。</li><li>一键生成视频：运行 <code>./start.sh <创意名称></code>，系统自动执行编剧生成、图片生成、视频生成全流程，中间结果自动缓存，支持断点续跑。</li><li>查看效果：视频输出在 <code>output/</code> 目录下，检查角色一致性、场景过渡流畅度和整体视频质量。如需调整，修改 YAML 配置后重新运行即可。</li></ol>

教你薅token（二）：构建agent无关的skills管理工作流

2026-06-04 22:00:00

上篇文章最后说了句：Agent只是工具，文档才是核心。这话说了之后，有人问我：道理都懂，但文档具体怎么管？总不能每个项目都复制粘贴一遍吧？确实不能。我后来写了个工具来解决这事——<a href="https://github.com/lcy362/personal-skills-manager">pks</a>（Personal Skills Manager），408行纯bash，零依赖。它干的事很简单：把你的AI工作流文档打包成skill，按需装到项目里，不绑定任何Agent平台。<h2 id="什么是skill"><a href="#什么是skill" class="headerlink" title="什么是skill"></a>什么是skill</h2>如果你用过OpenCode、Cursor或者其他Agent平台，大概率见过”skill”这个概念。不同平台叫法不一样——有的叫skill，有的叫rules，有的叫custom instructions——但说的都是同一件事：你给Agent的结构化指令，告诉它怎么处理特定类型的任务。比如”调用我们的API网关时，参数必须平铺在body顶层，不要嵌套在params里”，这是一条skill。”commit消息必须用中文，格式是type(scope):描述”，这也是。”数据库表名用snake_case，字段必须有注释”，还是。Agent的底层模型提供了通用推理能力——它知道怎么写代码、怎么调API。但你的API网关有什么坑、你们团队的命名习惯是什么、你们项目为什么选了这个架构——这些知识模型不知道，得你告诉它。skill就是你告诉Agent这些东西的方式。各平台管理skill的方式各不相同。OpenCode用<code>.opencode/skills/</code>目录，Cursor用<code>.cursorrules</code>，Claude Code读<code>CLAUDE.md</code>。格式不同，机制不同，但本质没区别：都是一份文档，Agent读到就按里面的规则干活。skill本身不依赖任何平台。一个用Markdown写好的skill文件夹，丢进任何项目里，任何Agent找到了都会读、都会用。纯Markdown，谁来都能读。<h2 id="问题出在哪"><a href="#问题出在哪" class="headerlink" title="问题出在哪"></a>问题出在哪</h2>skill是个好东西，但问题来了：你手上有好几个项目。一份团队编码规范，项目A要用，项目B要用，项目C也要用。你怎么管？常见的做法是，把这些配进agent本身的配置里，也就是常规的“安装skill”操作，比如给opencode装个微信读书skill, 这样，所有的项目用opencode打开，就都能用上。这本来是没啥问题的，除非你看了我上一篇文章.. 在我们想打造agent无关的工作流的情况下，这么干问题就大了。哪天你看到有个新agent在送免费token, 下来一用，发现一堆skill都得自己迁移，这不就傻了吗。所以我开发pks的初衷，就是把这一层抽出来，解套。让对这些不通用skill的管理，独立于所有的agent和项目，单独成一个体系。<h2 id="pks怎么解决"><a href="#pks怎么解决" class="headerlink" title="pks怎么解决"></a>pks怎么解决</h2>pks最适合管理那些非通用的、项目或团队特有的指令：你的编码风格偏好和commit规范、团队的代码规范和CI/CD流程、项目的架构决策记录和API设计约束等。pks要解决的就是一件事：在一个地方管理所有skill，按需装到任何项目里。然后，所有skill集中存在一个全局仓库里。项目需要哪些，装哪些。全局操作就三个核心命令：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>pks new my-skill # 基于模板创建skill骨架 pks list # 看看你有哪些skill pks delete my-skill # 删掉不要的 </pre></td></tr></table></figure>项目操作也很简单：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 4 5 </pre></td><td class="code"><pre>cd your-project pks init # 初始化（只执行一次） pks install my-skill # 装一个skill进来 pks status # 看看装了哪些 pks uninstall my-skill # 不想要了就卸掉 </pre></td></tr></table></figure>装好之后，skill会被复制到项目的<code>.skills/</code>目录：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 </pre></td><td class="code"><pre>your-project/ ├── .skills/ │ ├── INDEX.md # 自动生成的索引 │ └── my-skill/ │ └── SKILL.md # 你的skill内容 └── ... </pre></td></tr></table></figure><h2 id="Agent怎么发现这些skill"><a href="#Agent怎么发现这些skill" class="headerlink" title="Agent怎么发现这些skill"></a>Agent怎么发现这些skill</h2>这其实是个很自然的流程。每次install或uninstall，pks会自动重建<code>.skills/INDEX.md</code>。这个索引文件列出所有已安装的skill，附带描述和版本，并且包含一句话：<blockquote>Agents: read the <code>SKILL.md</code> file in each skill directory below for relevant instructions.</blockquote>任何Agent进到项目都会看到这个目录，读INDEX.md，然后按需加载具体的SKILL.md。最多你就在项目的AGENTS.md里再加一句去skill目录下找技能。按我的经验，对大部分agent来说，都没这个必要，它们都很自然的就找到这些技能了。<h2 id="什么时候会用到"><a href="#什么时候会用到" class="headerlink" title="什么时候会用到"></a>什么时候会用到</h2>说个最常见的场景：你负责一个项目，新人要加入开发。传统做法是什么？甩一份README，口头交代几句”我们commit要这么写”、”那个内部库要那么调”、”数据库字段别随便改”。剩下的全靠悟。用Agent辅助也差不多——你把规则塞进CLAUDE.md或AGENTS.md，Agent每次对话都吃一遍，不管这次任务跟这些规则有没有关系。换个思路。把这些知识拆成几个skill：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 </pre></td><td class="code"><pre>skills/ ├── team-coding-style/ # 团队编码规范、命名约定、commit格式 │ └── SKILL.md ├── internal-api-gateway/ # 内部API网关：参数平铺、鉴权方式、踩坑记录 │ ├── SKILL.md │ ├── pitfalls.md # 常见坑点（比如参数不能嵌套在params里） │ └── fields.md # 回包字段含义速查 ├── project-architecture/ # 架构决策：模块划分、目录结构、为什么这么设计 │ └── SKILL.md └── db-conventions/ # 数据库规范：命名、索引策略、迁移流程 └── SKILL.md </pre></td></tr></table></figure>新人入职？<code>pks init</code>，<code>pks install team-coding-style</code>，<code>pks install project-architecture</code>，几分钟装好。Agent读到这些skill，立刻知道这个项目的规矩。换一个人、换一台机器、换一个Agent平台，同样的skill装上去，效果一样。而且只有装了才消耗token。一个纯前端项目不需要装数据库规范的skill，一个老项目不需要装新人引导的skill。相比把所有规则塞进一个巨大的配置文件让Agent每次对话都吃一遍，按需安装能省下不少无用token——这本身就是在薅自己的token。这种非通用类的指令才是pks的主场。通用能力Agent自己就有，但你的团队规范、你的项目约定、你踩过的坑——这些东西只对你有用，也只该在需要的时候才出现。<h2 id="为什么是纯bash"><a href="#为什么是纯bash" class="headerlink" title="为什么是纯bash"></a>为什么是纯bash</h2>pks整个CLI是408行bash脚本。不用Python，不用Node.js，不用任何运行时。git clone下来就能跑。为什么这么极端？因为skill管理工具本身不应该引入任何负担。你的工作流已经够复杂了，管理它的工具应该尽可能简单——简单到不会因为某个运行时版本升级而挂掉。bash在macOS和Linux上开箱即用，十年前的脚本今天还能跑。这就是零依赖的好处：你的工作流文档比任何框架都长寿。<h2 id="设计上的几个小心思"><a href="#设计上的几个小心思" class="headerlink" title="设计上的几个小心思"></a>设计上的几个小心思</h2>pks有几个设计细节值得提一嘴。语义化版本：每个skill的YAML front matter里有version字段。skill迭代了，版本号跟着涨，项目里装了哪个版本一目了然。全局管理，按需安装：所有skill集中在一个仓库里维护，项目里只装需要的。模板保护：以<code>_</code>开头的skill（比如<code>_template</code>）不会出现在列表里，也不能被删除。<code>pks new</code>创建新skill时自动基于模板生成骨架，不用从零写起。路径无关：pks通过符号链接解析和相对路径定位，在任何位置调用都能正确找到skills目录。不管你从哪个路径执行命令，它都知道自己的家在哪。<h2 id="回到那句话"><a href="#回到那句话" class="headerlink" title="回到那句话"></a>回到那句话</h2>上篇说”Agent只是工具，文档才是核心”。这篇把它往前推了一步：文档化的工作流，是可以被管理的。pks不是什么高深的东西，408行bash而已。但它代表了一个态度：你的工作流是你的资产，不是任何平台的附属品。该薅token薅token，该管skill管skill。钱要省，活要干好，这两件事不矛盾。原文地址：<a href="https://lichuanyang.top/posts/26061/">https://lichuanyang.top/posts/26061/</a><h2 id="常见问题"><a href="#常见问题" class="headerlink" title="常见问题"></a>常见问题</h2><h3 id="Q-Skills-管理和-Agent-管理有什么区别？"><a href="#Q-Skills-管理和-Agent-管理有什么区别？" class="headerlink" title="Q: Skills 管理和 Agent 管理有什么区别？"></a>Q: Skills 管理和 Agent 管理有什么区别？</h3>Skills 管理是独立于 Agent 平台的，你把所有 skill 统一放在一个全局仓库里，项目需要什么就装什么。Agent 管理则是把 skill 配进某个 Agent 的内部配置中（如 OpenCode 的 <code>.opencode/skills/</code> 或 Cursor 的 <code>.cursorrules</code>），绑定到具体平台。前者的好处是换平台时不需要迁移任何 skill，后者虽然集成度高，但一旦切 Agent 就需要重新配置。<h3 id="Q-跨平台兼容性怎么保证？"><a href="#Q-跨平台兼容性怎么保证？" class="headerlink" title="Q: 跨平台兼容性怎么保证？"></a>Q: 跨平台兼容性怎么保证？</h3>关键是 纯 Markdown。pks 安装 skill 后生成的都是 <code>.md</code> 文件，放在项目的 <code>.skills/</code> 目录下，附带一个自动维护的 <code>INDEX.md</code> 索引文件。任何 Agent 扫描项目目录时都会发现这个结构，读 INDEX.md 就知道有哪些 skill，再按需加载具体的 SKILL.md。不需要特定格式，不需要平台 SDK，纯 Markdown 是最大的公约数。<h3 id="Q-pks-和直接在-Agent-里配置-skill-有什么不同？"><a href="#Q-pks-和直接在-Agent-里配置-skill-有什么不同？" class="headerlink" title="Q: pks 和直接在 Agent 里配置 skill 有什么不同？"></a>Q: pks 和直接在 Agent 里配置 skill 有什么不同？</h3>直接配在 Agent 里方便，但 skill 会”绑定”到那个 Agent。pks 的做法是从 Agent 中解耦 skill 管理——skill 存在全局仓库，按需安装到任何项目中。最大的实际好处：按需安装意味着只有装了的 skill 才消耗 token。一个纯前端项目不需要装数据库规范的 skill，一个老项目不需要装新人引导的 skill。相比把所有规则塞进一个大配置文件让 Agent 每次对话都吃一遍，pks 能省下大量无用 token。<h3 id="Q-为什么用-bash-而不是-Python-或-Node-js？"><a href="#Q-为什么用-bash-而不是-Python-或-Node-js？" class="headerlink" title="Q: 为什么用 bash 而不是 Python 或 Node.js？"></a>Q: 为什么用 bash 而不是 Python 或 Node.js？</h3><h2 id="零依赖。skill-管理工具本身不应该引入任何运行时负担——你的工作流已经够复杂了。408-行-bash-脚本在-macOS-和-Linux-上开箱即用，不需要安装解释器、不需要管理虚拟环境、不会因为某个运行时版本升级而挂掉。bash-十年前的脚本今天还能跑，这保证了你的工作流文档比任何框架都长寿。"><a href="#零依赖。skill-管理工具本身不应该引入任何运行时负担——你的工作流已经够复杂了。408-行-bash-脚本在-macOS-和-Linux-上开箱即用，不需要安装解释器、不需要管理虚拟环境、不会因为某个运行时版本升级而挂掉。bash-十年前的脚本今天还能跑，这保证了你的工作流文档比任何框架都长寿。" class="headerlink" title="零依赖。skill 管理工具本身不应该引入任何运行时负担——你的工作流已经够复杂了。408 行 bash 脚本在 macOS 和 Linux 上开箱即用，不需要安装解释器、不需要管理虚拟环境、不会因为某个运行时版本升级而挂掉。bash 十年前的脚本今天还能跑，这保证了你的工作流文档比任何框架都长寿。"></a>零依赖。skill 管理工具本身不应该引入任何运行时负担——你的工作流已经够复杂了。408 行 bash 脚本在 macOS 和 Linux 上开箱即用，不需要安装解释器、不需要管理虚拟环境、不会因为某个运行时版本升级而挂掉。bash 十年前的脚本今天还能跑，这保证了你的工作流文档比任何框架都长寿。</h2>原文地址：<a href="https://lichuanyang.top/posts/26061/">https://lichuanyang.top/posts/26061/</a>

教你薅token：构建agent无关的AI工作流

2026-06-03 22:00:00

目前大家使用AI的最大或者唯一痛点，是什么？可能就是账单了。无论是Claude、CodeX、Cursor，还是qoder或是mimo、minimax，基础套餐基本都要奔着20刀以上去，这还得省着用，很多时候用以来会很不爽。要想量大管饱，那就会更贵。而同时，很多平台会有试用装，或是常规的免费模型。比如OpenCode里的deepseek flash长期免费。我们怎么才能好好的薅一下这些免费模型呢？我长期在各种不同的项目用Agent，有代码，有个人博客，有笔记知识库，有小说，还有我和AI完的小游戏。用着用着发现一个事：Agent的所有操作，本质上是：读你文档 → 拼prompt → 发给模型 → 按结果改文件。文档在哪里，智能就在哪里。你自己拼prompt，跟平台帮你拼，其实没差那么多。所以我后来干脆不再纠结用哪个Agent平台了。文档维护好，哪里有免费token就去哪薅。<h2 id="Agent到底干了什么"><a href="#Agent到底干了什么" class="headerlink" title="Agent到底干了什么"></a>Agent到底干了什么</h2>不管哪家Agent，流程都差不多：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>用户说需求 → Agent看项目文档 → 读相关文件 → 拼prompt → 问模型 → 处理返回 → 改文件 → 循环上述流程 </pre></td></tr></table></figure>比如让它帮你修个bug，它：<ol><li>先读你项目里的 <code>AGENTS.md</code>、<code>README.md</code>，知道这项目是啥、目录在哪</li><li>再找到bug涉及的几个文件，读源码</li><li>把”项目上下文 + 相关代码 + bug描述 + 修改要求”拼成一个prompt</li><li>发给大模型</li><li>把返回的结果写成代码修改</li></ol>这些步骤，agent硬有差别，能有多大差别？别误会，这里不是要全盘否定一些公认的好Agent。好的Agent在上下文管理、流程控制、工具集成上确实做得顺手，不然也不会流行。但，“人的智能”，完全可以补上这些差距。比如上下文管理，Agent能定位到”这个bug涉及用户认证模块，需要读这三个文件”——可前提是它已经看过了你的AGENTS.md。那些文件路径、模块职责、约定俗成的写法，本来就是你自己写进去的。文档不好的时候，好的agent能有效率更高的方式找到需要的信息。但在文档完备的情况下，agent的差距就微乎其微了。总之，好的Agent在某些场景下，确实是方便，但是，不值这个价格。省下的那点维护文档、切窗口的时间，换每个月几十上百刀订阅费，性价比太低了。对我个人来说，维护一份完备的agent指南，性价比高多了。何况，这些指南文档，也完全可以让AI自己写。<h2 id="文档才是关键"><a href="#文档才是关键" class="headerlink" title="文档才是关键"></a>文档才是关键</h2>想明白上面那段之后，你还得接受一个反直觉的事实：真正值钱的，不是Agent平台，甚至不是模型，而是你自己的工作流。大模型谁都能调，Agent平台也大多只是编排层，功能都差不多。但你的项目文档和你对项目流程的管理，是唯一的，里面记着项目结构、设计决策、踩过的坑、你偏好的写法。同样的文档换个Agent平台，效果基本没差；可文档写得垃圾的话，放哪个平台都救不回来。我在代码项目里是这么维护的：<ul><li>项目概述文档：技术栈、目录结构、关键模块说明</li><li>工作流文档：”新增功能怎么走”、”修bug步骤”、”发布流程”</li><li>规则文档：命名规范、注释要求、踩坑记录</li></ul>同一个项目目录，用不同的agent打开，效果几乎没区别。小说创作项目同理。世界观、角色档案、章节大纲、写作规范，这些文档不变，换不同模型产出的风格都能保持一致。文档的样子定了，内容质量就定了。包括模型这一层，差别也没那么大。deepseek-v4-flash, 足够处理绝大多数问题。就算你真的要花钱买时间，该投资的也是文档本身，不是挑平台。<h2 id="薅token实战"><a href="#薅token实战" class="headerlink" title="薅token实战"></a>薅token实战</h2>工作流搬到文档之后，最大的好处就是：平台随便切。哪家有免费token用哪家，用完换下一家。比如这些：<ul><li>OpenCode：每天有免费DeepSeek Flash</li><li>Qoder：新用户送一些试用credits，还有免费模型额度</li><li>Codex：试用套装，我其实到现在都还没轮到去薅他，总想着遇到一些复杂场景再去用它的免费额度，免得浪费了。但实际上根本遇不到这种场景。</li><li>Hermes：不定期放出免费模型，有时候能意外捡到好模型，比如前阵子有免费的deepseek flash</li><li>trae: 完全免费，只是要排队，有时候真有些任务觉得免费模型搞不动了，临时去trae跑一下，也完全没问题</li></ul>除此之外还有不少路子：<ul><li>大模型API的新用户赠金：OpenAI、Anthropic、DeepSeek等，新号通常送几美元。直接调API比走Agent平台更便宜</li><li>开源模型的免费托管：HuggingFace、Together AI有免费推理额度，小任务完全够用</li><li>学生优惠：GitHub Student Pack之类的，送一堆平台credits</li><li>一些社区活动：经常有AI平台送额度</li></ul>所以这篇要说的结论其实挺简单：Agent只是工具，文档才是核心。 把文档维护好，平台随便换，哪里免费去哪薅。一个月省几十刀，换一顿火锅，不香吗？ 至于那些每个月烧几百刀token的重度用户——我只能说，你们的钱花得值，但我的token没花钱，效果也差不多。原文地址：<a href="https://lichuanyang.top/posts/26060/">https://lichuanyang.top/posts/26060/</a><h2 id="常见问题"><a href="#常见问题" class="headerlink" title="常见问题"></a>常见问题</h2><h3 id="Q-Agent-和-Skill-是什么关系？"><a href="#Q-Agent-和-Skill-是什么关系？" class="headerlink" title="Q: Agent 和 Skill 是什么关系？"></a>Q: Agent 和 Skill 是什么关系？</h3>Agent 是”干活的人”，Skill 是”教它怎么干活的说明书”。Agent 的底层模型提供了通用推理能力，但它不知道你的项目结构、编码规范、API 设计约束——这些知识需要通过 Skill（结构化指令文档）告诉它。两者的关系可以这样理解：Agent = 通用推理引擎 + 按需加载 Skill。把 Skill 维护好，换不同的 Agent 平台也能保持一致的输出质量。<h3 id="Q-Token-优化最有效的方法是什么？"><a href="#Q-Token-优化最有效的方法是什么？" class="headerlink" title="Q: Token 优化最有效的方法是什么？"></a>Q: Token 优化最有效的方法是什么？</h3>不是换更便宜的模型，而是写好文档。一份完备的 AGENTS.md 或 SKILL.md，能让 Agent 精准定位到需要读取的文件，避免每次做任务都全量扫描项目。相比之下，在不完备的文档上折腾模型选择或 prompt 精简，省下的 token 远远小于文档带来的提升。先花时间把文档写清楚，再去薅免费 token，这是效益最高的路径。<h3 id="Q-文档维护和-Agent-订阅哪个更值？"><a href="#Q-文档维护和-Agent-订阅哪个更值？" class="headerlink" title="Q: 文档维护和 Agent 订阅哪个更值？"></a>Q: 文档维护和 Agent 订阅哪个更值？</h3>文档维护更值。Agent 订阅每月花几十上百美元，本质上是为平台帮你”找文件、拼 prompt”的便利性付费。但如果你的项目文档已经足够完备——技术栈、目录结构、设计决策、编码规范都写清楚了——那么换个免费 Agent 效果几乎没差。文档是你自己的资产，可以跨平台复用；Agent 订阅是消耗品，换了平台就得重新来。<h3 id="Q-免费模型真的够用吗？"><a href="#Q-免费模型真的够用吗？" class="headerlink" title="Q: 免费模型真的够用吗？"></a>Q: 免费模型真的够用吗？</h3>对绝大多数日常任务够用。作者的经验是 DeepSeek Flash 级别的免费模型就能处理大部分代码修改、文档生成、知识整理等任务。遇到确实搞不动的复杂场景，可以临时切到有免费试用额度的平台（如 Trae、Codex 试用套装）。真正的瓶颈通常不是模型能力，而是你给它的上下文（文档）够不够好。<h2 id="快速上手步骤"><a href="#快速上手步骤" class="headerlink" title="快速上手步骤"></a>快速上手步骤</h2><ol><li>理解 Agent 与 Skill 的关系：Agent 是执行引擎（负责调模型、读文件、改代码），Skill 是结构化指令文档（告诉 Agent 你的项目结构、编码规范、操作流程）。文档质量直接决定 Agent 的输出质量，好的文档可以让不同 Agent 平台的产出高度一致。</li><li>编写项目文档：在项目根目录创建 <code>AGENTS.md</code>，至少包含：项目概述（技术栈、目录结构、关键模块）、工作流说明（新增功能怎么做、修 bug 步骤、发布流程）、规则文档（命名规范、注释要求、踩坑记录）。</li><li>让 AI 辅助写文档：将 karpathy 的 llm-wiki gist 或已有的项目规范喂给 AI，让它自动生成 AGENTS.md 和各模块的 SKILL 文档，人工审核后放入项目目录。</li><li>切换平台验证：用不同的免费 Agent 平台（OpenCode、Qoder、Hermes 等）打开同一个项目，执行相同任务（如修 bug、加功能），对比输出质量。如果文档完备，差异应该很小。</li></ol>原文地址：<a href="https://lichuanyang.top/posts/26060/">https://lichuanyang.top/posts/26060/</a>

用 AI Agent 完成 Hexo 主题迁移：从 Next 到 Butterfly 的全自动化实践

2026-05-28 22:00:00

<h2 id="背景：一个繁琐到让人崩溃的任务"><a href="#背景：一个繁琐到让人崩溃的任务" class="headerlink" title="背景：一个繁琐到让人崩溃的任务"></a>背景：一个繁琐到让人崩溃的任务</h2>最近想给自己的 Hexo 博客换个主题。用了好几年的 Next 主题，虽然经典，但想换个更现代的风格。看起来很简单对吧？但实际操作过的朋友都知道，Hexo 主题迁移是一个极其繁琐的过程：<ol><li>配置文件长达 1000+ 行，需要逐项对比新旧主题的配置格式</li><li>功能映射复杂：Next 的 <code>leancloud_visitors</code> 对应 Butterfly 的 <code>busuanzi</code>，Next 的 <code>reading_progress</code> 对应 Butterfly 的 <code>preloader</code></li><li>两个站点要同步：中英文站都要改，而且配置略有不同</li><li>Font Awesome 版本兼容：Butterfly 默认配的 FA 7.1.0 根本不存在于 cdnjs</li><li>YAML 格式敏感：缩进、换行符都可能导致配置失效</li></ol>如果手动操作，估计要花一整天，而且很容易出错。<h2 id="解决方案：让-AI-Agent-来干"><a href="#解决方案：让-AI-Agent-来干" class="headerlink" title="解决方案：让 AI Agent 来干"></a>解决方案：让 AI Agent 来干</h2>这次我尝试了一个不同的方式：让 AI Agent（Hermes）全程接管这个任务。<h3 id="AI-Agent-的工作流程"><a href="#AI-Agent-的工作流程" class="headerlink" title="AI Agent 的工作流程"></a>AI Agent 的工作流程</h3>整个过程，AI Agent 自主完成了以下工作：<ol><li>环境分析：检查当前 Hexo 版本（7.0.0）、Node.js 版本（v24.14.0）、两个站点的配置差异</li><li>版本调研：查询 GitHub API，获取最新 Hexo 版本（8.1.2）和 breaking changes</li><li>依赖升级：批量更新 hexo 及所有插件到最新版本</li><li>主题对比：分析 Next 和 Butterfly 的功能覆盖度，生成对比表格</li><li>配置迁移：将 Next 的 1000+ 行配置逐项映射到 Butterfly 格式</li><li>问题排查：<ul><li>发现 FA 7.1.0 在 cdnjs 上 404，降级到 6.7.2</li><li>发现知乎图标需要 <code>fab</code> 前缀</li><li>发现英文站菜单路径错误</li><li>发现 GA、百度统计、站长验证等关键配置丢失</li></ul></li><li>测试验证：构建测试、本地预览服务器、检查 HTML 输出</li><li>代码提交：自动生成 commit message 并 push</li></ol><h3 id="关键技术点"><a href="#关键技术点" class="headerlink" title="关键技术点"></a>关键技术点</h3><h4 id="1-Font-Awesome-版本兼容性问题"><a href="#1-Font-Awesome-版本兼容性问题" class="headerlink" title="1. Font Awesome 版本兼容性问题"></a>1. Font Awesome 版本兼容性问题</h4>这是最隐蔽的一个 bug。Butterfly 主题的 <code>plugins.yml</code> 配置了 FA 7.1.0：<figure class="highlight yaml"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>fontawesome: name: '@fortawesome/fontawesome-free' version: 7.1.0 </pre></td></tr></table></figure>但 cdnjs 上根本没有这个版本！导致所有品牌图标（GitHub、StackOverflow、知乎）都不加载。AI Agent 通过以下步骤定位问题：<ul><li>检查生成的 HTML，发现加载的是 FA 7.1.0</li><li>请求 cdnjs API，确认 7.1.0 返回 404</li><li>测试 FA 6.7.2，确认包含所有需要的图标</li><li>在配置中覆盖 CDN 地址</li></ul><h4 id="2-YAML-配置迁移的陷阱"><a href="#2-YAML-配置迁移的陷阱" class="headerlink" title="2. YAML 配置迁移的陷阱"></a>2. YAML 配置迁移的陷阱</h4>Hexo 的配置文件是 YAML 格式，对缩进和换行符非常敏感。AI Agent 在迁移过程中遇到了几个问题：<ul><li>CRLF vs LF：Butterfly 默认配置是 CRLF 换行，用 sed 替换时匹配失败</li><li>重复键：patch 工具导致 <code>scroll_percent</code> 出现两次</li><li>值丢失：YAML 缩进不对导致配置值没有正确写入</li></ul>最终用 Python 直接操作文件内容才解决了这些问题。<h4 id="3-多站点同步"><a href="#3-多站点同步" class="headerlink" title="3. 多站点同步"></a>3. 多站点同步</h4>中英文站的配置大部分相同，但有几处差异：<ul><li>英文站的 <code>language</code> 需要改为 <code>en</code></li><li>英文站的菜单需要指向中文站</li><li>英文站的 Valine placeholder 需要用英文</li></ul>AI Agent 自动识别这些差异并分别处理。<h2 id="效果对比"><a href="#效果对比" class="headerlink" title="效果对比"></a>效果对比</h2><table><thead><tr><th>指标</th><th>手动操作</th><th>AI Agent</th></tr></thead><tbody><tr><td>耗时</td><td>4-8 小时</td><td>30 分钟</td></tr><tr><td>出错率</td><td>高（容易遗漏配置）</td><td>低（系统化检查）</td></tr><tr><td>问题排查</td><td>需要逐个 Google</td><td>自动定位根因</td></tr><tr><td>代码提交</td><td>手动写 commit message</td><td>自动生成</td></tr></tbody></table><h2 id="AI-Agent-的优势"><a href="#AI-Agent-的优势" class="headerlink" title="AI Agent 的优势"></a>AI Agent 的优势</h2>这次实践让我深刻体会到 AI Agent 在这类繁琐、重复性工作中 的巨大优势：<h3 id="1-系统化思维"><a href="#1-系统化思维" class="headerlink" title="1. 系统化思维"></a>1. 系统化思维</h3>AI Agent 不会像人一样”想到哪改到哪”。它会：<ul><li>先分析当前状态</li><li>制定完整计划</li><li>逐步执行并验证</li><li>发现问题及时修复</li></ul><h3 id="2-跨领域知识"><a href="#2-跨领域知识" class="headerlink" title="2. 跨领域知识"></a>2. 跨领域知识</h3>主题迁移涉及多个技术领域：<ul><li>Hexo 配置</li><li>Font Awesome 版本管理</li><li>YAML 格式处理</li><li>Git 工作流</li><li>前端资源加载</li></ul>AI Agent 能够在这些领域之间自由切换，而人类开发者通常只精通其中一两个。<h3 id="3-持久注意力"><a href="#3-持久注意力" class="headerlink" title="3. 持久注意力"></a>3. 持久注意力</h3>人类在处理 1000+ 行配置文件时，注意力会逐渐下降，容易遗漏。AI Agent 不会疲劳，每个配置项都会被检查到。<h3 id="4-自动化验证"><a href="#4-自动化验证" class="headerlink" title="4. 自动化验证"></a>4. 自动化验证</h3>AI Agent 不仅会修改配置，还会：<ul><li>运行构建测试</li><li>启动本地服务器验证</li><li>检查 HTML 输出</li><li>确认关键配置生效</li></ul><h2 id="适用场景"><a href="#适用场景" class="headerlink" title="适用场景"></a>适用场景</h2>基于这次经验，我认为 AI Agent 特别适合以下类型的工作：<ol><li>配置迁移：不同系统之间的配置格式转换</li><li>依赖升级：批量更新多个包并处理兼容性问题</li><li>代码重构：大规模的代码格式调整</li><li>文档整理：从多个来源整合信息</li><li>环境搭建：新项目的初始化配置</li></ol><h2 id="局限性"><a href="#局限性" class="headerlink" title="局限性"></a>局限性</h2>当然，AI Agent 也有局限：<ol><li>创意性工作：UI 设计、文案撰写等仍需人类主导</li><li>业务决策：是否升级、选择哪个主题等决策需要人类判断</li><li>复杂调试：某些运行时问题需要人工介入</li></ol><h2 id="总结"><a href="#总结" class="headerlink" title="总结"></a>总结</h2>这次用 AI Agent 完成 Hexo 主题迁移的实践，让我看到了 LLM（大语言模型）在软件工程领域的巨大潜力。AI Agent 不是来取代开发者的，而是来增强我们的能力。它把我们从繁琐、重复的工作中解放出来，让我们能够专注于更有价值的事情。如果你也有类似的”体力活”，不妨试试让 AI Agent 来帮忙。你会发现，AI 辅助开发 不是未来，而是现在。<h2 id="相关技术栈"><a href="#相关技术栈" class="headerlink" title="相关技术栈"></a>相关技术栈</h2><ul><li>AI Agent：Hermes Agent</li><li>LLM：DeepSeek V4 Pro / MiMo v2.5</li><li>静态站点生成器：Hexo 8.1.2</li><li>主题：Butterfly 5.5.4</li><li>图标库：Font Awesome 6.7.2</li><li>评论系统：Valine (LeanCloud)</li><li>统计分析：Google Analytics / 百度统计</li></ul><hr>本文由 AI Agent 辅助撰写，记录了一次真实的主题迁移实践。原文地址：<a href="https://lichuanyang.top/posts/48979/">https://lichuanyang.top/posts/48979/</a>

Mobility修改

Mobility的 RSS 预览

该作者的社会化媒体

Mobility 修改