标签 Vercel 下的文章

find-skills技能全解析:一键解决AI Agent技能搜索、安装与管理痛点
在AI Agent使用过程中,“找技能、装技能、管技能”是多数用户面临的核心难题——要么四处搜罗技能资源,要么切换平台搜索打断工作流,要么安装后难以统一管理更新。此前在Skills蓝皮书分享过的Skills.sh资源库中,一款名为find-skills的技能异军突起,不仅登顶24h安装榜榜首,长期稳居总榜第二且持续上升,日均安装量突破10k+,与第二名拉开显著差距。

这款由Vercel官方发布的技能,之所以能快速走红,核心在于它完美解决了技能获取与管理的全流程痛点,无需切换平台、无需复杂操作,仅需在单个Agent中运行,就能完成技能搜索、安装、检查、更新的闭环。本文将从核心优势、详细操作步骤、注意事项三个维度,全方位解析find-skills的使用方法,帮助用户高效利用AI Agent技能,提升工作效率。

一、find-skills核心优势:为什么它能成为“技能神器”?

在find-skills出现之前,用户获取技能的方式普遍存在诸多弊端,而它的出现的实现了技能管理的“一站式闭环”,具体优势对比及核心亮点如下:

1.1 解决传统技能获取的核心痛点

传统技能获取主要有两种方式,均存在明显局限:

  • 人工分享/仓库搜索:依赖他人分享,效率低下,且难以精准匹配自身需求,容易找到过时或不适配的技能。
  • 技能搜索平台(如skillsmp.com):搜索体验不佳,中文搜索命中率低,即便使用AI搜索也无法达到理想效果;且需要跳出当前工作任务,打开单独平台搜索,严重打断工作流,影响专注度。

1.2 find-skills的核心亮点

相较于传统方式,find-skills实现了全流程优化,核心亮点集中在3点:

  • 全闭环操作:无需切换平台,在单个Agent中即可完成“搜索→安装→检查→更新”全流程,不打断工作流,提升使用效率。
  • 适配性强:由Vercel官方发布,与Vercel生态完美兼容,支持多种Agent安装,后续管理和更新更便捷。
  • 操作灵活:支持指令搜索和自然语言搜索两种方式,中文提问可同时检索中英文关键词,搜索精度更高,小白也能快速上手。

二、find-skills详细操作教程(以Claude Code为例)

本教程将以Claude Code为操作场景,拆解find-skills从安装、搜索到管理更新的完整步骤,所有操作均无需复杂代码基础,复制指令即可完成,全程适配小白用户。

步骤一:安装find-skills技能(推荐官方最优方式)

find-skills支持多种安装方式,但最推荐使用Vercel官方发布的add-skill指令安装——作为官方同源工具,后续技能的管理、更新更稳定,避免出现适配问题。

  1. 获取项目地址(备用):find-skills的官方项目地址为:https://github.com/vercel-labs/skills/tree/main/skills/find-skills,无需下载,仅作为备用参考。
  2. 执行安装指令:打开Claude Code,输入以下指令并运行,即可启动安装流程:

     npx skills add https://github.com/vercel-labs/skills --skill find-skills
    
  3. 选择安装配置(3个选项依次选择):

  • 安装Agent选择:选择将技能安装到哪个Agent中,可选择“一键安装到全部Agents”(适合多Agent用户),也可选择具体某个Agent,根据个人使用习惯选择即可。
  • 安装范围选择:分为“全局范围”和“项目范围”——全局范围可在所有项目中使用,项目范围仅在当前项目中生效,推荐新手选择“项目范围”,避免影响其他项目。
  • 安装方式选择:提供两种方式,按需选择:
- SymLink(推荐):通过创建符号链接实现集中管理,所有Agent共享一个技能源文件,后续更新时可统一同步,无需逐个Agent更新。

- Copy to all agents:将技能文件直接复制到每个Agent节点,每个节点独立存储,更新时需逐个操作,适合需要个性化修改技能文件的用户。
  1. 确认安装成功:安装完成后,当前项目中会出现适配对应Agent的技能路径,说明安装成功,可进入下一步操作。

补充建议:新手推荐配置为“所有Agent + 项目范围 + SymLink”,兼顾便捷性和后续管理效率。

步骤二:使用find-skills搜索并安装目标技能

安装完成后,即可通过两种方式搜索技能,操作简单,精准匹配需求,具体步骤如下:

  1. 选择搜索方式(两种均可,按需选择):

  • 指令搜索(精准高效):输入以下指令,将“skills关键词”替换为具体需求,即可搜索相关技能:

        npx skills find "skills关键词"示例:搜索SEO标签优化相关技能,指令为:npx skills find "SEO标签优化";搜索YouTube视频下载相关技能,指令为:npx skills find "YouTube视频下载"。
    
  • 自然语言搜索(小白友好):无需输入指令,直接用中文或英文提问即可,例如:“帮我找下SEO meta标签优化的skills”“有没有小红书封面设计相关的Skills”。
  1. 精准搜索技巧(重点):

  • 关键词尽量细化:避免使用宽泛关键词(如“SEO”“小红书”),优先使用具体关键词(如“SEO meta标签”“小红书封面设计”),减少无关搜索结果,提升搜索精度。
  • 语言适配:英文提问仅搜索英文关键词,中文提问会同时搜索中文及相关英文关键词,推荐中文用户使用中文提问,扩大搜索范围。
  1. 安装目标技能:搜索完成后,find-skills会列出所有相关技能,只需告知其需要安装的技能名称,即可自动完成安装,无需额外操作。

小建议:若搜索结果中能显示技能安装量,可优先选择安装量较高的技能,安全性和适配性更有保障(后续版本可能优化该功能)。

步骤三:技能管理与更新(易忽略但关键步骤)

find-skills不仅能搜索安装技能,还提供了3个实用的管理指令,解决技能过多难以管理、版本过时等问题,具体使用方法如下(重点注意局限性):

  1. 查看已安装技能:当安装的技能过多时,可通过以下指令快速查看所有已安装技能,清晰掌握自身技能储备:

     npx skills list⚠️ 注意(重点):该指令仅能识别通过“npx skills add”指令安装的技能,若通过其他方式(如手动下载、第三方工具)安装的技能,无法被识别。
    
  2. 检查可更新技能:定期检查技能版本,避免使用过时技能,指令如下:

     npx skills check运行后,会列出所有可更新的技能及当前版本、最新版本,方便用户判断是否需要更新。
    
  3. 更新所有已安装技能:若确认需要更新,可通过以下指令一键更新所有可更新技能:

     npx skills update⚠️ 注意(慎用):更新前需确认所有技能均为可信任来源,避免更新后出现技能适配异常、功能失效等问题;建议更新前备份相关项目文件,降低风险。
    

三、find-skills使用注意事项(避坑必看)

虽然find-skills操作简单、实用性强,但在使用过程中仍有4点注意事项,避免出现操作失误、功能异常等问题,新手必看:

  • 安装方式优先选官方同源:尽量使用“npx skills add”指令安装,避免使用其他第三方安装方式,否则可能出现后续管理、更新失败,或与Agent适配异常的问题。
  • 搜索关键词决定搜索精度:宽泛关键词会导致搜索结果杂乱、无关信息过多,务必细化关键词,可观察搜索输出过程,了解关键词拓展逻辑,优化搜索词。
  • 技能管理指令的局限性:牢记“npx skills list”仅识别官方指令安装的技能,手动安装的技能需单独记录管理,避免遗漏。
  • 更新技能需谨慎:“npx skills update”会一键更新所有可更新技能,若部分技能与当前项目适配度较低,更新后可能出现功能异常,建议按需更新,而非盲目一键更新。

四、补充说明与实用建议

4.1 find-skills的局限性

find-skills并非万能,需理性看待其功能边界:

  • 仅能搜索开源技能:无法搜索未开源的私有技能,若需使用特定私有技能,仍需通过手动安装方式添加。
  • 搜索结果不一定完全适配:找到的技能可能无法完全满足当前任务需求,此时可基于现有技能进行改造,比从零开发全新技能效率更高。

4.2 实用搭配建议

若仅需保留两个核心技能,实现“技能获取+技能开发”的闭环,推荐搭配:

  • find-skills:负责技能的搜索、安装、管理,解决“找技能难”的问题。
  • skill-creator:负责基于现有技能改造或从零开发全新技能,解决“技能适配”的问题。

4.3 资源补充

find-skills已正式收录到《Skills蓝皮书-实用Skills篇》,若需了解更多技能相关知识(概念、局限、制作方法等),可移步查看《做了份Skills蓝皮书,从概念、局限到使用、制作,一次讲清》,系统学习技能相关内容。

五、总结

find-skills的走红,本质上是解决了AI Agent用户“找技能、装技能、管技能”的核心痛点——无需切换平台、无需复杂操作,小白也能快速上手,大幅提升AI Agent的使用效率。无论是日常使用AI Agent处理简单任务,还是需要大量技能支撑复杂工作,find-skills都能成为高效助手。

需要注意的是,它并非万能工具,需理性看待其局限性,合理搭配其他技能使用;同时严格遵循使用注意事项,避免出现操作失误。希望本文的解析的操作教程,能帮助大家快速掌握find-skills的使用方法,充分发挥AI Agent的核心价值。

本文由mdnice多平台发布

Vercel 最近发布了 React 最佳实践库,将十余年来积累的 React 和 Next.js 优化经验整合到了一个指南中。

其中一共包含8 个类别、40 多条规则

这些原则并不是纸上谈兵,而是 Vercel 团队在 10 余年从无数生产代码库中总结出的经验之谈。它们已经被无数成功案例验证,能切实改善用户体验和业务指标。

以下将是对你的 React 和 Next.js 项目影响最大的 10 大实践。

1. 将独立的异步操作并行

请求瀑布流是 React 应用性能的头号杀手。

每次顺序执行 await 都会增加网络延迟,消除它们可以带来最大的性能提升。

❌ 错误:

async function Page() {
  const user = await fetchUser();
  const posts = await fetchPosts();
  return <Dashboard user={user} posts={posts} />;
}

✅ 正确:

async function Page() {
  const [user, posts] = await Promise.all([fetchUser(), fetchPosts()]);
  return <Dashboard user={user} posts={posts} />;
}

当处理多个数据源时,这个简单的改变可以将页面加载时间减少数百毫秒。

策略1:并行异步操作

2. 避免桶文件导入

从桶文件导入会强制打包程序解析整个库,即使你只需要其中一个组件。

这就像把整个衣柜都搬走,只为了穿一件衣服。

❌ 错误:

import { Check, X, Menu } from "lucide-react";

✅ 正确:

import Check from "lucide-react/dist/esm/icons/check";
import X from "lucide-react/dist/esm/icons/x";
import Menu from "lucide-react/dist/esm/icons/menu";

更好的方式(使用 Next.js 配置):

// next.config.js
module.exports = {
  experimental: {
    optimizePackageImports: ["lucide-react", "@mui/material"],
  },
};

// 然后保持简洁的导入方式
import { Check, X, Menu } from "lucide-react";

直接导入可将启动速度提高 15-70%,构建难度降低 28%,冷启动速度提高 40%,HMR 速度显著提高。

策略2:避免桶文件导入

3. 使用延迟状态初始化

当初始化状态需要进行耗时的计算时,将初始化程序包装在一个函数中,确保它只运行一次。

❌ 错误:

function Component() {
  const [config, setConfig] = useState(JSON.parse(localStorage.getItem("config")));
  return <div>{config.theme}</div>;
}

✅ 正确:

function Component() {
  const [config, setConfig] = useState(() => JSON.parse(localStorage.getItem("config")));
  return <div>{config.theme}</div>;
}

组件每次渲染都会从 localStorage 解析 JSON 配置,但其实它只需要在初始化的时候读取一次,将其封装在回调函数中可以消除这种浪费。

策略3:延迟状态初始化

4. 最小化 RSC 边界的数据传递

React 服务端/客户端边界会将所有对象属性序列化为字符串并嵌入到 HTML 响应中,这会直接影响页面大小和加载时间。

❌ 错误:

async function Page() {
  const user = await fetchUser(); // 50 fields
  return <Profile user={user} />;
}

("use client");
function Profile({ user }) {
  return <div>{user.name}</div>; // uses 1 field
}

✅ 正确:

async function Page() {
  const user = await fetchUser();
  return <Profile name={user.name} />;
}

("use client");
function Profile({ name }) {
  return <div>{name}</div>;
}

只传递客户端组件实际需要的数据。

策略4:最小化RSC边界

5. 动态导入大型组件

仅在功能激活时加载大型库,减少初始包体积。

❌ 错误:

import { AnimationPlayer } from "./heavy-animation-lib";

function Component() {
  const [enabled, setEnabled] = useState(false);
  return enabled ? <AnimationPlayer /> : null;
}

✅ 正确:

function AnimationPlayer({ enabled, setEnabled }) {
  const [frames, setFrames] = useState(null);

  useEffect(() => {
    if (enabled && !frames && typeof window !== "undefined") {
      import("./animation-frames.js").then((mod) => setFrames(mod.frames)).catch(() => setEnabled(false));
    }
  }, [enabled, frames, setEnabled]);

  if (!frames) return <Skeleton />;
  return <Canvas frames={frames} />;
}

typeof window 可以防止将此模块打包用于 SSR,优化服务端包体积和构建速度。

策略5:动态导入组件

6. 延迟加载第三方脚本

分析和跟踪脚本不要阻塞用户交互。

❌ 错误:

export default function RootLayout({ children }) {
  useEffect(() => {
    initAnalytics();
  }, []);

  return (
    <html>
      <body>{children}</body>
    </html>
  );
}

✅ 正确:

import { Analytics } from "@vercel/analytics/react";

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <Analytics />
      </body>
    </html>
  );
}

在水合后加载分析脚本,优先处理交互内容。

策略6:延迟加载脚本

7. 使用 React.cache() 进行请求去重

防止服务端在同一渲染周期内重复请求。

❌ 错误:

async function Sidebar() {
  const user = await fetchUser();
  return <div>{user.name}</div>;
}

async function Header() {
  const user = await fetchUser(); // 重复请求
  return <nav>{user.email}</nav>;
}

✅ 正确:

import { cache } from "react";

const getUser = cache(async () => {
  return await fetchUser();
});

async function Sidebar() {
  const user = await getUser();
  return <div>{user.name}</div>;
}

async function Header() {
  const user = await getUser(); // 已缓存,无重复请求
  return <nav>{user.email}</nav>;
}

策略7-8:缓存去重

8. 实现跨请求数据的 LRU 缓存

React.cache() 仅在单个请求内有效,因此对于跨连续请求共享的数据,使用 LRU 缓存。

❌ 错误:

import { LRUCache } from "lru-cache";

const cache = new LRUCache({
  max: 1000,
  ttl: 5 * 60 * 1000, // 5 分钟
});

export async function getUser(id) {
  const cached = cache.get(id);
  if (cached) return cached;

  const user = await db.user.findUnique({ where: { id } });
  cache.set(id, user);
  return user;
}

这在 Vercel 的 Fluid Compute 中特别有效,多个并发请求共享同一个函数实例。

9. 通过组件组合实现并行化

React 服务端组件在树状结构中按顺序执行,因此需要使用组合对组件树进行重构以实现并行化数据获取:

❌ 错误:

async function Page() {
  const data = await fetchPageData();
  return (
    <>
      <Header />
      <Sidebar data={data} />
    </>
  );
}

✅ 正确:

async function Page() {
  return (
    <>
      <Header />
      <Sidebar />
    </>
  );
}

async function Sidebar() {
  const data = await fetchPageData();
  return <div>{data.content}</div>;
}

这样一来,页眉和侧边栏就可以并行获取数据了。

10. 使用 SWR 进行客户端请求去重

当客户端上的多个组件请求相同的数据时,SWR 会自动对请求进行去重。

❌ 错误:

function UserProfile() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch("/api/user")
      .then((r) => r.json())
      .then(setUser);
  }, []);

  return <div>{user?.name}</div>;
}

function UserAvatar() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch("/api/user")
      .then((r) => r.json())
      .then(setUser);
  }, []);

  return <img src={user?.avatar} />;
}

✅ 正确:

import useSWR from "swr";

const fetcher = (url) => fetch(url).then((r) => r.json());

function UserProfile() {
  const { data: user } = useSWR("/api/user", fetcher);
  return <div>{user?.name}</div>;
}

function UserAvatar() {
  const { data: user } = useSWR("/api/user", fetcher);
  return <img src={user?.avatar} />;
}

SWR 只发出一个请求,并将结果在两个组件之间共享。

11. 总结

这些最佳实践的美妙之处在于:它们不是复杂的架构变更。大多数都是简单的代码修改,却能产生显著的性能改进。

一个 600ms 的瀑布等待时间,会影响每一位用户,直到被修复。

一个桶文件导入造成的包膨胀,会减慢每一次构建和每一次页面加载

所以越早采用这些实践,就能避免积累越来越多的性能债务。

总结:立即行动

现在开始应用这些技巧,让你的 React 应用快如闪电吧!

我是冴羽,10 年笔耕不辍,专注前端领域,更新了 10+ 系列、300+ 篇原创技术文章,翻译过 Svelte、Solid.js、TypeScript 文档,著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”,关注我的公众号:冴羽(或搜索 yayujs),每天分享前端知识、AI 干货。

大家好,我是 Immerse,一名独立开发者、内容创作者、AGI 实践者。

关注公众号:沉浸式AI,获取最新文章(更多内容只在公众号更新)

个人网站:https://yaolifeng.com 也同步更新。

转载请在文章开头注明出处和版权信息。

我会在这里分享关于编程独立开发AI干货开源个人思考等内容。

如果本文对您有所帮助,欢迎动动小手指一键三连(点赞评论转发),给我一些支持和鼓励,谢谢!


Vercel 开源了一个项目,叫 agent-skills。

他们把团队积累的 React、Next.js 开发经验,打包成了 AI 可以直接调用的技能包。

写代码时,AI 会自动检查性能问题、可访问性、最佳实践。相当于自动 Code Review。

3 个技能包

react-best-practices:40 多条规则,分 8 个类别。

包括消除请求瀑布流、优化包体积、服务端性能、客户端数据获取。每条规则标注优先级(Critical、High、Medium)。

web-design-guidelines:100 多条规则。

涵盖可访问性、焦点状态、表单处理、动画、排版、图片、性能、导航、暗黑模式、触控交互、国际化。

vercel-deploy-claimable:在聊天窗口直接部署到 Vercel。

支持 40 多种框架,部署完给预览地址和认领地址。

安装和使用

npx add-skill vercel-labs/agent-skills

装完不需要配置,AI 自动检测使用场景。写 React 组件时自动检查性能,说要部署时自动调用部署功能。

工具支持

这个思路的价值

把经验和最佳实践结构化,让 AI 能理解和执行。

比文档好用,AI 会在写代码时主动提醒你。这些技能遵循 Agent Skills 标准,是开放格式。


项目地址:https://github.com/vercel-labs/agent-skills

部署到 Cloudflare Workers

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 Cloudflare 凭证

  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secrets:
      • CLOUDFLARE_API_TOKEN:你的 API 令牌
      • CLOUDFLARE_ACCOUNT_ID:你的 Account ID
  4. 触发部署

    • 推送代码到 main 分支会自动触发部署
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 Cloudflare Workers 控制台中绑定你的自定义域名

部署到 Cloudflare Pages

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 Cloudflare 凭证

  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secrets:
      • CLOUDFLARE_API_TOKEN:你的 API 令牌
      • CLOUDFLARE_ACCOUNT_ID:你的 Account ID
  4. 触发部署

    • 存储库会自动将 Workers 代码转换为 Pages 兼容格式并同步到 pages 分支
    • 推送代码到 main 分支会自动触发同步和部署工作流
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 Cloudflare Pages 控制台中绑定你的自定义域名

注意pages 分支是从 main 分支自动生成的。请勿手动编辑 pages 分支,因为它会被同步工作流覆盖。

部署到 EdgeOne Pages

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 EdgeOne Pages API Token

  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secret:
      • EDGEONE_API_TOKEN:你的 API Token
  4. 触发部署

    • 存储库会自动将 Workers 代码转换为 Pages 兼容格式并同步到 pages 分支
    • 推送代码到 main 分支会自动触发同步和部署工作流
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 EdgeOne Pages 控制台中绑定你的自定义域名

注意pages 分支是从 main 分支自动生成的。请勿手动编辑 pages 分支,因为它会被同步工作流覆盖。

部署到 Vercel

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 Vercel 凭证

    • 访问 Vercel Account Settings 创建并记录 Access Token
    • 访问 Team Settings 记录 Team ID
    • 新建项目后访问项目的 Settings 记录 Project ID
  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secrets:
      • VERCEL_TOKEN:你的 Access Token
      • VERCEL_ORG_ID:你的 Team ID
      • VERCEL_PROJECT_ID:你的 Project ID
  4. 触发部署

    • 存储库会自动将 Workers 代码转换为 Functions 兼容格式并同步到 functions 分支
    • 推送代码到 main 分支会自动触发同步和部署工作流
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 Vercel 控制台中绑定你的自定义域名

注意functions 分支是从 main 分支自动生成的。请勿手动编辑 functions 分支,因为它会被同步工作流覆盖。

部署到 Netlify

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 Netlify 凭证

    • 访问 Netlify User Settings 创建并记录 personal access token
    • 新建项目后访问 Project configuration 记录 Project ID
  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secrets:
      • NETLIFY_AUTH_TOKEN:你的 personal access token
      • NETLIFY_SITE_ID:你的 Project ID
  4. 触发部署

    • 存储库会自动将 Workers 代码转换为 Functions 兼容格式并同步到 functions 分支
    • 推送代码到 main 分支会自动触发同步和部署工作流
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 Netlify 控制台中绑定你的自定义域名

注意functions 分支是从 main 分支自动生成的。请勿手动编辑 functions 分支,因为它会被同步工作流覆盖。

部署到 Deno Deploy

  1. fork 本存储库Fork xixu-me/Xget

  2. 切换默认分支

    • 进入你的 GitHub 存储库 → Settings → General → Default branch
    • 将默认分支从 main 切换到 functions
  3. 部署到 Deno Deploy

  4. 绑定自定义域名(可选):在 Deno Deploy 控制台中绑定你的自定义域名

注意functions 分支是从 main 分支自动生成的。请勿手动编辑 functions 分支,因为它会被同步工作流覆盖。

自托管部署

如果你希望在自己的服务器上运行 Xget,可以使用 Docker 或 Podman 部署:

使用预构建镜像

从 GitHub Container Registry 拉取并运行预构建的镜像:

使用 Docker:

# 拉取最新镜像
docker pull ghcr.io/xixu-me/xget:latest

# 运行容器
docker run -d \
  --name xget \
  -p 8080:8080 \
  ghcr.io/xixu-me/xget:latest

使用 Podman:

# 拉取最新镜像
podman pull ghcr.io/xixu-me/xget:latest

# 运行容器
podman run -d \
  --name xget \
  -p 8080:8080 \
  ghcr.io/xixu-me/xget:latest

本地构建

从源码构建容器镜像:

使用 Docker:

# 克隆存储库
git clone https://github.com/xixu-me/Xget.git
cd Xget

# 构建镜像
docker build -t xget:local .

# 运行容器
docker run -d \
  --name xget \
  -p 8080:8080 \
  xget:local 

使用 Podman:

# 克隆存储库
git clone https://github.com/xixu-me/Xget.git
cd Xget

# 构建镜像
podman build -t xget:local .

# 运行容器
podman run -d \
  --name xget \
  -p 8080:8080 \
  xget:local 

使用 Docker Compose / Podman Compose

创建 docker-compose.yml 文件:

version: '3.8' services: xget:  ghcr.io/xixu-me/xget:latest container_name: xget ports: - "8080:8080" restart: unless-stopped 

使用 Docker Compose:

docker compose up -d

使用 Podman Compose:

podman compose up -d

部署完成后,Xget 将在 8080 端口运行。

注意:自托管部署不包括全球边缘网络加速,性能取决于你的服务器配置和网络环境。


📌 转载信息
原作者: xixu-me
转载时间: 2026/1/25 23:15:14

由于大厂研发出身,技术选型上我还是有些追求,目前我的项目使用 cloudflare/vercel 部署前端接入层,用 GKE 部署后端服务,很多人也会用到 redis ,如果从网络延迟来考虑服务之间的部署,应该首选 google 的 redis 服务,然后通过内网直连达到最低的延迟,但是 google 太贵了光是 GKE 就已经有一笔成本了,还没赚到钱就不想花这么高的成本再去一个边缘的服务上去,推荐一家几乎免费的 redis 服务商 upstash 首先他们提供了免费额度:存储 256 MB 的数据,每月可以发出 500 000 次命令,默认最大数据库数量是 1 个。这免费的门槛可能就够你用了,如果你有多个服务,之间需要隔离的话,需要注意的一点是他们不支持 redis db 的选择,默认只有一个 db ,要薅羊毛你可以用多个账号,每个账号创建一个 redis 实例。付费的话也很目前我从 GKE 的 us-central1 通过公网链接到 upstash 的实例在首次链接建立后,通过长连接执行 command 的延迟是 1ms ,几乎和内网没什么区别。upstash 首先他们提供了免费额度:

存储 256 MB 的数据,每月可以发出 500 000 次命令,默认最大数据库数量是 1 个。

这免费的门槛可能就够你用了,如果你有多个服务,之间需要隔离的话,需要注意的一点是他们不支持 redis db 的选择,默认只有一个 db ,要薅羊毛你可以用多个账号,每个账号创建一个 redis 实例。

付费的话也很便宜,如果你也嫌管理太多账号太麻烦,可以选择按使用量计费( PAY AS YOU GO ):

1 、按每 100 000 次约 0.20 美元计费(这个价格是读写命令总和,不包括某些内部操作命令)

2 、存储空间按每 GB 大约 0.25 美元计费(每个数据库第一个 GB 通常免费)

3 、带宽月度前 200 GB 免费,之后按每 GB 大约 0.03 美元收费

我的服务使用 redis 量很小,这么算几乎一个月只需要不到 10 块钱人民币,这个成本比起 google 要低太多了,它还有其他高阶套餐这里留给大家自己去探索吧。

目前我从 GKE 的 us-central1 通过公网链接到 upstash 的实例的 us-central1 地区,在首次链接建立后,通过长连接执行 command 的延迟是 1ms ,几乎和内网没什么区别。

“我的笔记本是 16G 内存的 M3 Pro ,为什么我还需要一台只有 4 核 8G 的服务器?”

在 Reddit 的 r/indiehackers 板块,这是新手最常问的问题之一。在 Serverless (如 Vercel )和 PaaS (如 Supabase )横行的今天,VPS ( Virtual Private Server ,虚拟专用服务器)似乎显得有些“老派”。

但现实是:真正能跑通商业闭环、实现长期盈利的独立开发者,手里一定攥着几台 VPS 。

本文将从独立开发的 7 个核心痛点出发,深度解析为什么 VPS 是你迈向专业化、摆脱“代码玩具”的必经之路。


1. 摆脱“本地焦虑”:解决 node_modules 与 Docker 的空间黑洞

独立开发者最昂贵的资产是笔记本,而最廉价的则是笔记本硬盘。这波 AI 编程大部分都是 NextJS ,这也就带来了 node_modules 灾难。其实还有 cc 居然也喜欢拉 bb 。如果观察 cc 的执行过程,会发现它一直要写东西去 /tmp 目录

  • 痛点:硬盘与性能的双重榨干


    • node_modules 爆炸:同时维护 10 个项目,node_modules 能吃掉 50GB 以上的 SSD 。
    • Docker 镜像堆积:在本地运行容器会让系统响应迟滞,风扇咆哮。
    • 计算占用:本地运行 PostgreSQL 或 Redis 等中间件会显著拖慢 IDE 的响应速度。
  • 解决方案:VPS 作为“重型计算中心”
    你只需在本地保留一个轻量的 VS Code + Cursor,通过 Remote SSH 连接 VPS 。所有的重型依赖和环境都在云端运行,笔记本只负责显示 UI 。

图 1:本地开发负载 vs. VPS 远程卸载对比

2. 拒绝“SaaS 账单勒索”:从商业逻辑看成本控制

独立开发最怕的不是没用户,而是用户还没付钱,SaaS 账单先爆了。最近几年做 AI 编程,难免会接触到 supabase ,clerk 等工具,其实包括 vercel 也一样,用下来会发现一开始很爽,然后爽着爽着,账单就爆炸了。vercel 有个很有意思的坑,就是 Image 组件,编译的时候会提示最好用 <Image 组件,听起来很贴心对吧?但这个组件默认走 Vercel 的图片优化服务——每优化一张图就计费一次。流量大的站点,光图片优化费用就能超过主机费用。

Vercel 的 Hobby 免费套餐非常诱人——部署、CDN 、SSL 全包。但一旦你的项目有了流量,噩梦就开始了。

超额收费一览

资源 Pro 套餐包含 超出后收费
带宽 1 TB/月 $0.15/GB(即 $150/TB )
Edge Requests 1000 万/月 $2/百万
Serverless 执行时间 40 小时/月 $5/小时
图片优化 5000 张/月 $5/1000 张
  • 痛点:被绑架的扩展成本


    • PaaS 陷阱:Firebase 的免费额度诱人,但一旦涉及复杂备份或高并发,价格呈指数级增长。
    • 身份验证收费:Clerk 等按月活用户收费,对高频低客单价应用是噩梦。
  • 解决方案:全栈自建( Self-hosting )
    在 $5/月 的 VPS 上,你可以利用 Docker 跑满性能,同时运行:数据库( PostgreSQL )、验证系统( PocketBase )和统计系统( Umami )。

图 2:SaaS 订阅 vs. VPS 固定成本曲线对比

💡 公平地说:自建服务确实需要一定的运维能力。但最近很多海外开发者分享了自己维护 PostgreSQL 的经验——比想象中简单得多,尤其是有了 Docker 和自动备份脚本之后。后面我会详细讲怎么做。

3. 真正的 CI/CD:构建“一人 IT 部门”的自动化流水线

独立开发者的核心竞争力在于迭代速度。部署到 vercel 、cloudflare 、Netfily 等 servless 平台在早期验证需求的时候,是非常好的,但是这些平台的问题是,它们的 node 实现是不完备的,一些长时间的任务就没法跑。以前本地打包机器就开始呼啸,通过 github 的 action ,这个事不用操心了,弄好就是 docker 镜像,然后,起飞了。

  • 执行时间限制:Serverless 函数通常有 10-60 秒的超时限制,一般默认是 10s

  • 无持久进程:WebSocket 、长连接、后台任务都很别扭

  • 冷启动延迟:首次请求可能需要等待数秒

  • 痛点:手动部署的低效与错误
    如果你还在用手动执行 git pull,你不仅在浪费生命,还在增加生产事故的概率。

  • 解决方案:基于 VPS 的轻量自动化
    利用 VPS 运行 GitHub Actions Runner


    1. Git Push 触发流水线。
    2. VPS 自动拉取代码并构建 Docker 镜像。
    3. Docker Compose 自动重启容器,实现零停机更新。

图 3:基于 VPS 的自动化 CI/CD 流水线示意图

不知道是不是这个原因,现在 cloudflare 也不咋推 pages 了,又回到 worker ,感觉挺难用的,你怎么看?

4. 解决“网络壁垒”:从静默爬虫到跨境访问

很多项目在本地跑不通,不是代码问题,而是网络环境问题。开发用都的很多 npm 包,或者其他的资源,常常会因为网络,把人给气死,累死,折腾死,烦死。

  • 痛点:变动的 IP 与受限的出口


    • 固定 IP 需求:对接 Stripe 、PayPal 或银行 API 时,通常需要固定的公网 IP 做白名单。家庭宽带的动态 IP 根本没法用。
    • 网络环境问题:开发时用到的很多 npm 包、Docker 镜像、GitHub 资源,经常因为网络问题把人折腾得够呛。
    • 反爬虫封禁:如果你在做数据采集相关的项目,家庭宽带 IP 极易被反爬策略封禁。
  • 解决方案:VPS 作为全局网络枢纽


    • 固定身份标识:为业务提供永久的公网 IP ,Stripe Webhook 、OAuth 回调都能稳定工作。
    • 反向代理中心:一个 VPS 配合 Nginx 或 Caddy ,可以管理 10+ 个域名并映射到不同的本地端口。
    • 开发环境加速:npm install 、docker pull 都在 VPS 上执行,下载速度飞快,不再受本地网络限制。

image.png

和 nginx proxy manager 有仇,已经好几次了,弄它的 Docker ,能占 10 来 G 的空间,完全不理解,caddy 就小巧很多。

5. 守护“睡后收入”:24/7 监控与容灾

独立开发最痛苦的时刻,是早上醒来发现服务已经挂了一整晚,而你毫无察觉。(希望是伪命题,真来钱的项目,还是很上心的!)

痛点:缺乏哨兵

  • 本地电脑会休眠,没法做持续监控
  • 免费的外部监控工具检测频率太低(如 5 分钟/次),发现问题时用户早就流失了
  • 很多问题是"偶发性"的,等你手动检查时一切正常

解决方案:自建监控站

在 VPS 上部署 Uptime Kuma(或类似工具),每 30-60 秒检测一次全球访问状况。一旦挂掉,立即通过 Telegram 、Discord 或邮件通知。

监控清单建议

监控项 检测频率 告警方式
HTTP 状态码 60 秒 Telegram 即时通知
SSL 证书到期 每天 提前 14 天预警
服务器资源 5 分钟 CPU/内存超 80% 告警
数据库连接 60 秒 连接失败立即通知

进阶玩法

  • Uptime Kuma 做可用性监控
  • BezelNetdata 做服务器资源监控,Bezel 还挺好用的。Netdata 稍微重点。
  • 两者结合,形成完整的监控闭环

图 4:全天候监控与即时告警闭环

6. 数据主权:独立开发的“最后防线”

  • 痛点:平台依赖风险

    如果你的数据全在 Firebase ,某天账号因为合规问题被封,你的所有努力将瞬间清零。

  • 解决方案:VPS 本地化存储 + 异地备份


    • 数据隔离:数据库文件完全属于你。
    • 自动化备份:编写一个简单的 Cron 任务,每天定时将数据加密并同步到 S3 或你的本地存储。

image.png

7. 独立开发者的资源规划:“1 + N” 策略

针对 2026 年的典型开发场景,我们建议采用以下阵列:

类型 规格建议 核心作用
1 台主领地 2 核 4G 或 4 核 8G 运行 Nginx 、核心数据库、核心产品。
N 台哨兵机 1 核 1G 或更低 运行 Uptime Kuma 监控、小型爬虫、测试环境。
为什么需要分开?
  • 监控服务不应该和被监控的服务在同一台机器——否则机器挂了你也收不到告警
  • 测试环境和生产环境隔离,避免误操作
  • 多台小机器比一台大机器更有弹性

image.png

Reddit 上 Hetzner 被反复提及为"性价比之王":同样的价格,配置通常是美国云服务商的 2-3 倍。缺点是机房主要在欧洲,亚洲访问延迟较高。

咋说呢? 数据库还是很重要的,如果精力有限,就还是用 neon 或者 supabase 之类的。

总结:从“玩票”到“专业”的入场券

拥有 VPS 的那一刻起,你就不再只是一个“写代码的人”,而是一个 “系统的掌控者”。它为你提供了:

  • 确定性:不再受本地环境变化的干扰。
  • 连续性:产品 24 小时独立生存。
  • 商业性:以最低的边际成本支撑业务增长。

正如独立开发圈子里流传的一句话:“你的第一个服务器 IP ,就是你产品的第一张名片。”(我编的)

VPS 入门:为什么独立开发者需要一台 VPS ?( 2026 深度版)

我再来说一次 vercel 自动部署问题。之前发过两个帖子,也有热心的网友帮我想办法,能自动部署后,我还是不甘心,想办法找出原因。今天问题终于找到了。也许对于高手来说,是个很弱智的错误。简单说一下怎么发现问题的。
我又做了个项目,https://www.cluesbysam.net/ ,这次提交到 git 后没自动部署。但是发现了问题。
在创建 git 项目的时候,选择 Private ,就不会自动部署。我之前能自动部署的那个项目,https://dreamyroomlevel.org/ 在 git 创建的时候,默认是 public ,我没改,结果就能自动部署。后来这个项目,我改成 Private ,更新代码后就不会自动部署。唉,太丢人了。

把之前一直用的 ob 插件 webpage-html-export 魔改了一下,更适合作为个人知识库网站。
用的是 vercel 部署的
插件仓库地址:GitHub - Ryanu9/Obsidian_webpage_export_pro
示例库:
https://myblog-livid-iota.vercel.app/
https://c1trus.top/

感兴趣的佬友可以看看


📌 转载信息
原作者:
ryanu
转载时间:
2026/1/12 10:15:26

夜深了,诚邀佬们听广播

可以自己部署玩玩,一个电台

100% 完全由 AI agent 驱动,需要自己填接口,自备 ai 和 tts。(不过里面还是内置了一个我自己部署的微软大声朗读 tts 接口,是免费用,有条件的建议可以自己 vercel 也部署一个)

做了两天的小玩具,感觉目前 bug 真的还是很多而且来不及重构代码了准备回校住宿一周了

什么节目形式都有可能,很随机,主题的话看时段,可以通过观众来信来调整节目的方向形式(看你是什么要求)

还是决定提前分享一下想法,以后正式版出来了再开一个主贴

目前的问题包括但不限于:

音乐播放时好时坏(api 接口网络和音频调度都有可能,暂未明)

ai 搜索选歌曲不知道为什么尤其钟爱 "陈绮贞"" 房东的猫 " 这两个歌手,只会在这里面选。来不及排查了。

部分音频内容衔接不流畅,比如在节目首次生成完成后到播放音频有真空期。

还有来信功能目前不知道怎么样,也还没来得及再次测试

….

直接体验也可以,我部署了


📌 转载信息
原作者:
CJackHwang
转载时间:
2026/1/12 10:15:20

CLIProxyAPI 是一个非常优秀 cli2api 工具,不过作者明确提过,不会提供对目前保存在内存中的使用数据持久化支持。(每次更新或重启都会丢失使用数据)

咱又刚好对自己的用量比较感兴趣,就试着搓了一个仪表盘。

纯 Vercel + Postgres 部署,无需拥有服务器。

每天定时持久化上游使用数据,每次打开看板也都会更新一次。
(该策略未经压测,个人使用应该不会有性能问题)

预览图如下,算是把毕生统计所学都用上了:


希望这个项目能对各位有所帮助,也欢迎任何建议。

祝元旦快乐!


📌 转载信息
转载时间:
2026/1/2 12:34:46

背景

看过 afimory 这样的开源项目,更多像是纯粹的的照片展览了,与我的需求稍微有点不一样

Mo Gallay

mo gallary 是一个基于 nextjs​honojs 的项目,由于 honojs 的特性,可以直接部署在 vercel,专为摄影爱好者打造的照片博客平台。

类似于博客,但其更偏向于照片叙事,生活分享,个人展示方面

功能

  • 使用 postgreSQL(supabase)
  • 支持评论,精选照片
  • 支持 github,r2 存储源
  • 照片故事
  • 照片 exif 信息参数,色卡盘
  • 画廊多视图切换
  • 夜间模式切换

当前存在博客菜单,感觉和其本质有点出入,未来可能会将博客砍掉

特点 & 未来(目标)

  • 支持文件路径调整
  • 存储源迁移(如 github 迁移到 r2)
  • 照片集锦
  • 组图查看

全部 vibe coding 的项目,bug 有点多,就不便直接开源,待我再打磨打磨

预览地址:

移动端访问问题较多,建议 pc 访问

欢迎提供建议

首页



画廊




管理页面





📌 转载信息
原作者:
shaioo
转载时间:
2025/12/30 10:13:20

关联上一个帖子 —:
V1.1 中文字修复大幅增强!更新年终汇报救星!忍不了 NotebookLM 生成的 PPT(中文错乱 + 分辨率低)的我,搓了一个高清修复工具



修复前 (Original)

修复后 (Restored)

前几天发的那个 NotebookLM 幻灯片修复工具,很多佬友反馈说:“虽然好用,但是要自己搞 Gemini Key,重点是要绑信用卡,太麻烦了!”

必须安排啊!

熬了几个大夜,V2.1 版本终于赶在年前发出来了!这次不整虚的,直接解决大家最头疼的两大门槛

核心更新 (V2.1)

1. 免 Key、免梯子,开箱即用(最重要!) 之前的版本虽然免费,但你得自己去申请 Google 的 API Key,主要是要绑定信用卡麻烦。 这次我直接重构了后端,加了一个 “Access Code (口令)” 模式

  • 以前:找梯子 → 去 Google AI Studio → 绑定信用卡申请 Key → 填进去
  • 现在:打开网站 → 输入口令 → 直接跑
  • 后端自动走 Vercel 代理,国内网络直连,速度飞快。

2. 画质史诗级提升:

  • 分辨率:从 2K 提升到 4K
  • 工程:优化汉字修复效果,肉眼可见,比上个版本修复效果更好了!
  • 效果:那种密密麻麻的流程图文字,现在修复出来跟矢量图一样锐利。

3. 体验升级

  • 这回真不仅是修图了,把 UI 也重新撸了一遍,加了类似 Apple 的 Shimmer 扫光加载动图,等待的时候不无聊了。
  • 修正了之前有佬友反馈的 “中文引号识别错误” bug。


还是要对比一下

特性AI Studio 模式 (自己填 Key)新版 Access Code 模式
上手难度高 (需会申请 Key)极低 (填码即用)
网络要求需魔法国内直连
画质上限2K4K (独占)
隐私Key 在你本地更安全 (不用存 Key)

(我是真心推荐大家试下新模式,虽然 API 成本我得肉疼一下…)


传送门


当然,如果你还是喜欢用自己的 API Key,完全兼容,完全免费,没有任何限制!

(主要是一个人开发维护不易,如果有 bug 轻喷,欢迎 issue!)


📌 转载信息
原作者:
aonong
转载时间:
2025/12/29 12:31:24