Mobility的 RSS 预览

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

2026-06-16 13:20:05

<blockquote>“解决的办法不是压制 AI，而是让它变成一种更平权的能力，让每个人都知道如何借 AI 创造更多。这也是我们公司很重要的愿景，让世界级的 AI 属于每一个人。”</blockquote>这是 Agnes AI 创始人 Bruce Yang 接受采访时说的一段话。现在很多国内的AI厂商，无论deepseek还是智谱，都在把AI的价格往下压。坦率的讲，像文字、代码的处理价格，确实已经被压到了一个相当低的价格。但视频不一样，现在做AI视频，门槛确实高得离谱——国外的 Runway、Pika 按月订阅几十美元，国内的即梦、可灵免费额度用完就按秒计费，想本地跑开源模型？一张能跑视频的显卡轻松上万。但如果 AI 模型本身可以免费，那这道门就不该关着。这个项目就是想证明这一点。 <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>给它一句话描述，它还你一条视频。根据你想偷懒的程度，有四个档：最省事的——简单视频。 写句话，选分辨率和时长，点生成，等一会就出来了。支持文生视频、图生视频和关键帧模式。最好玩的——创意视频。 你写一个故事创意，比如”暗黑版青蛙王子”，AI全包：扩展故事→生成角色参考图→拆分场景→写分镜提示→逐段生成视频→配音→上字幕→拼接成片。全程10步自动跑完，你只需要等着看成片。我第一次跑通的时候还挺惊喜的，整体完成度比预期高不少。最实用的——文稿视频。 贴一篇长文章进去，自动按语音时长分段，每段生成画面，用一条完整的TTS旁白和字幕串起来。做知识区内容的可以试试。最新的——数字人口播。 AI 生成一个虚拟主播形象（也可以上传你自己的），动态口播片段配上 TTS 配音和字幕，循环拼接成完整口播视频。做产品介绍、新闻播报之类的挺合适。各模式的详细参数和玩法，可以到<a href="https://video.lichuanyang.top/">官网</a>上看，这里就不展开了。<h2 id="几个值得说的细节"><a href="#几个值得说的细节" class="headerlink" title="几个值得说的细节"></a>几个值得说的细节</h2>配音、字幕、场景衔接这些，官网上都有详细的说明和参数介绍，这里只聊几个我觉得值得一提的设计：字幕是逐词对齐的。 Edge TTS 能拿到每个词的精确时间戳，字幕大概每2到3个字切一条，跟语音精准同步。长字幕会自动在标点处换行，不会出现”的”字被挤到下一行的情况。场景之间不是硬切。 关键帧模式下，每个场景的最后一帧自动变成下一个场景的第一帧，视觉上平滑过渡。demo 里的青蛙王子就是用的这个模式。另外还有过渡帧和独立模式可选。断点续传。 创意视频要跑10个步骤，万一中间断了不怕——每步完成后状态自动落盘，重启后点”继续”就行，不会重复调API。音频是整条铺的。 不是给每个场景单独配音再拼接（那样静音会累积），而是先把视频拼好，再整体铺一条旁白。技术栈是 Python FastAPI + 单文件 Tailwind 前端，代码量不大但该有的都有。对实现细节感兴趣的可以直接看 <a href="https://github.com/lcy362/agnes-video-generator">GitHub 源码</a>，README 和 AGENTS.md 里写得很全。<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> 会自动帮你建虚拟环境、装依赖、启动服务。唯一的前置要求是 Python 3.10+ 和 ffmpeg。启动后打开 <code>http://localhost:8765</code>，在页面顶部填上你的 Agnes AI API Key，选个模式，写你的创意，点生成，然后去泡杯咖啡等结果就行。用 Cursor 或者 Claude 这些AI编程助手的话更方便，项目里有个 <code>AGENTS.md</code>，直接让你的Agent读这个文件，它自己就能把环境搞好、把服务跑起来。<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 的电脑。MIT 协议开源，代码在 <a href="https://github.com/lcy362/agnes-video-generator">GitHub</a>，官网在 <a href="https://video.lichuanyang.top/">video.lichuanyang.top</a>。有问题提 issue，也欢迎 PR。反正免费的，试试呗。

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。原文地址：<a href="https://lichuanyang.top/posts/65500/">https://lichuanyang.top/posts/65500/</a>

教你薅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>

教你薅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>

用 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>

Vercel封禁163邮箱后，我是怎么恢复博客的

2026-05-11 19:30:00

前几天写了篇新文章，照常往 Vercel 部署，结果 pipeline 直接报错了。一开始以为是构建问题，折腾了一会儿才发现不对——是 Vercel 账号出了状况。用 163 邮箱注册的账号怎么都登不上去了。后来才搞清楚，Vercel 把整个 163.com 邮箱根域给封禁了。<h2 id="先说说-Vercel-是什么"><a href="#先说说-Vercel-是什么" class="headerlink" title="先说说 Vercel 是什么"></a>先说说 Vercel 是什么</h2>如果你是搞独立博客的，大概率听过或者正在用 Vercel。简单说，它是一个前端部署平台，支持自动从 GitHub 仓库拉代码、构建、部署，给你的网站分配一个域名，还自带 CDN 加速。很多人的博客就是 GitHub Pages + Vercel 的组合——代码放在 GitHub，用 Vercel 来部署和托管。我自己的博客也是这么搞的。GitHub Pages 本来也能直接部署静态页面，但 Vercel 在自定义域名、HTTPS、CDN 这些方面用起来更方便，所以就选了它。<h2 id="163-邮箱被封禁的来龙去脉"><a href="#163-邮箱被封禁的来龙去脉" class="headerlink" title="163 邮箱被封禁的来龙去脉"></a>163 邮箱被封禁的来龙去脉</h2>大概在 2026 年 5 月 4 号左右，大量使用 163 邮箱注册 Vercel 的用户发现，自己的账号突然无法登录了。我在网上搜了一下，发现不只是我一个人遇到这个问题。NodeSeek、V2EX 这些论坛上都有人在讨论。根据网上的信息，Vercel 在 2026 年 4 月中旬遭遇了一次比较严重的安全事件。黑客团伙 ShinyHunters 通过一个第三方 AI 工具入侵了 Vercel 的内部系统，窃取了员工数据、企业后台权限和一些部署凭证，还索要了 200 万美元的赎金。这次封禁 163 邮箱，大概率是安全事件后的应对措施之一。可能是因为 163 邮箱在此次事件中被大量用于恶意注册或攻击行为，也可能只是 Vercel 对某些邮箱域名做了更严格的风控。具体原因 Vercel 没有公开说明，但结果就是：整个 163.com 邮箱域名被一刀切了。影响范围不小。很多国内开发者和独立博客作者都是用 163 邮箱注册的 Vercel，这次封禁直接导致这些人的博客全部无法访问。不过如果你现在 Vercel 账号还处于登录状态（比如工作电脑的浏览器还保持着登录），其实是可以抢救一下的：进账号设置，添加一个新邮箱（Outlook、Gmail 都行），然后把 163 邮箱去掉。这样账号就能继续正常使用，不需要重新部署。网上有人分享了这个方法，能省不少事。但如果你跟我一样，发现的时候已经完全登不上去了，那就只能走下面的重建流程了。<h2 id="回忆我的博客部署架构"><a href="#回忆我的博客部署架构" class="headerlink" title="回忆我的博客部署架构"></a>回忆我的博客部署架构</h2>账号被封了，博客打不开了，第一件事就是得搞清楚自己的博客到底是怎么部署的。说实话，这个博客配置的时间已经比较久了，当时配完之后就没怎么动过，具体流程已经记不太清了。花了不少功夫才回忆起来，大概的链路是这样的：<ol><li>博客源码放在 GitHub 仓库里</li><li>Vercel 连接 GitHub 仓库，负责构建和部署</li><li>域名解析这块，分了两层：阿里云的 DNS 指向 Cloudflare，Cloudflare 再指向 Vercel</li></ol>为什么要搞这么复杂？主要是为了用 Cloudflare 的 CDN 和安全防护能力。阿里云做域名注册商，Cloudflare 做中间层的 DNS 管理和 CDN，Vercel 做最终的静态页面托管。当年配的时候也是参考了网上的一些教程，虽然链路长了点，但稳定运行了很久，也就没再动过。<h2 id="恢复过程：新账号-重新部署"><a href="#恢复过程：新账号-重新部署" class="headerlink" title="恢复过程：新账号 + 重新部署"></a>恢复过程：新账号 + 重新部署</h2>搞清楚部署架构之后，恢复操作其实并不复杂。第一步：注册新的 Vercel 账号这次学聪明了，不用 163 邮箱了，用 Outlook 重新注册了一个 Vercel 账号。其实 Gmail 也行，但考虑到这次是 Vercel 封禁了特定邮箱域名，用国外主流的邮箱服务会更稳妥一些。第二步：重新部署 GitHub 项目登录新账号后，连接 GitHub，把博客仓库导入 Vercel。Vercel 自动识别了项目类型，构建和部署都是自动完成的，跟之前的操作基本一样。第三步：重新配置域名这一步是关键。因为之前域名解析是阿里云 → Cloudflare → Vercel 的链路，重新部署后需要把域名绑定到新的 Vercel 项目上。让我惊喜的是，现在 Vercel 在添加自定义域名的时候，已经支持自动修改 Cloudflare 的 DNS 配置了。以前我记得需要手动去 Cloudflare 后台添加 CNAME 记录，现在 Vercel 直接通过 API 帮你搞定，点几下就完事了。整个恢复过程，从注册新账号到博客重新可以访问，大概花了不到半小时。<h2 id="几点经验"><a href="#几点经验" class="headerlink" title="几点经验"></a>几点经验</h2><ol><li>不要用国内邮箱注册海外服务。163、QQ 邮箱这类国内邮箱，在海外服务的风控体系里天然就是高风险对象。这次是 Vercel，下次可能是别的服务。建议主力账号用 Gmail 或 Outlook。</li><li>记录好自己的部署架构。这次最浪费时间的环节就是回忆部署链路。当时配置完觉得都记住了，结果过了这么久早就忘得差不多了。建议把部署架构和关键配置写在笔记里，哪怕只是几句话。</li><li>Vercel 现在对 Cloudflare 的集成做得不错。以前手动配 DNS 的时候容易出错，现在自动化程度高了很多，重新部署的成本降低了不少。</li><li>有条件的话，做好备份和多平台准备。这次运气好，恢复起来比较快。但如果 GitHub 仓库也出了问题，或者 Vercel 彻底封了项目而不只是账号，恢复就会麻烦很多。重要的博客内容，建议在本地或者别的平台也有一份。</li></ol><h2 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h2>这次 Vercel 封禁 163 邮箱的事，算是给所有用国内邮箱注册海外服务的人提了个醒。平台侧的安全措施我们控制不了，但自己的账号安全和部署架构，还是可以提前做好准备的。如果你也遇到了 Vercel 163 邮箱被封、Vercel 账号无法登录的问题，希望这篇文章能帮到你。恢复的核心思路就是：换一个邮箱重新注册，把项目重新部署一遍，域名重新绑定一下。操作不复杂，但前提是你得记得自己的部署链路。原文地址: <a href="https://lichuanyang.top/posts/39648/">https://lichuanyang.top/posts/39648/</a><hr>

Mobility修改

Mobility的 RSS 预览

该作者的社会化媒体

Mobility 修改