super-mortal

为博客添加 JSON-LD 结构化数据

Wed, 27 May 2026 00:00:00 GMT

TL;DR：本次 SEO 优化只做了一件事——给博客加上 JSON-LD 结构化数据。文章页自动输出 BlogPosting，首页自动输出 WebSite，以后发文无需手动维护

一.为什么要做这次优化

博客基于 Astro + astro-theme-pure，原本已经具备较完整的 SEO 基础：页面 title / description、Open Graph、Twitter Card、canonical 链接、sitemap、RSS、robots.txt 等。

但全站缺少 JSON-LD 结构化数据（application/ld+json）。

JSON-LD 是一段嵌在页面里的 JSON，用 Schema.org 标准告诉搜索引擎：

这是博客文章还是普通网页
标题、作者、发布时间分别是什么
站点名称和 URL 是什么

对 Google 富摘要、AI 搜索引用都有帮助。更重要的是：只要在布局里配置一次，每篇新文章都会自动生成，不用在 Markdown 里重复写。

二.我具体做了什么

1. 文章页：BlogPosting

新建组件 src/components/BlogPostingJsonLd.astro，在 src/layouts/BlogPost.astro 中挂载。

组件会读取文章 frontmatter 里已有的字段，自动拼出 JSON-LD：

| JSON-LD 字段 | 数据来源 | | ---------------------- | ----------------------------------------- | | headline | frontmatter title | | description | frontmatter description | | datePublished | publishDate | | dateModified | updatedDate（没有则用 publishDate） | | author.name | 站点配置 config.author | | image | heroImage 或默认 socialCard | | mainEntityOfPage.@id | https://supermortal.cn/blog/{文章 slug} |

最终页面 <head> 中会出现类似：

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "文章标题",
    "author": { "@type": "Person", "name": "Mortal" },
    ...
  }
</script>

2. 首页：WebSite

新建组件 src/components/WebSiteJsonLd.astro，在 src/pages/index.astro 中挂载。

自动读取 site.config.ts 里的站点名、描述、作者、语言，输出：

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "WebSite",
    "name": "super-mortal",
    "url": "https://supermortal.cn",
    ...
  }
</script>

3. 布局改造：head 插槽

JSON-LD 需要放在 <head> 里。为此改动了两个布局文件：

src/layouts/BaseLayout.astro：在 <head> 中增加 <slot name="head" />
src/layouts/ContentLayout.astro：把 head 插槽转发给 BaseLayout

文章页走 BlogPost → ContentLayout → BaseLayout，首页直接走 BaseLayout，两条路径都能把 JSON-LD 注入到 head

三.附 Cloudflare近一个月流量统计

服务器 Docker 和 SSL 证书清理

Mon, 04 May 2026 00:00:00 GMT

服务器 Docker 和 SSL 证书清理

一.删除指定 docker

1.查看所有容器

docker ps -a

输出说明：可清晰看到每个容器的 CONTAINER ID（容器唯一ID）、IMAGE（所用镜像）、NAMES（容器名称），记录要删除的容器的名称或ID

2.执行容器删除操作

删除单个容器

docker rm -f -v 容器名或容器ID

删除多个容器

docker rm -f -v 容器1名/ID 容器2名/ID 容器3名/ID

命令解释

-f：强制停止并删除目标容器（即使容器处于运行中，也能直接删除）
-v：删除容器自带的内部存储、临时缓存及专属数据卷，确保容器相关缓存彻底清理
此操作仅删除 Docker 容器及内部关联缓存，不会删除服务器本地的项目文件（如挂载的代码目录）
仅删除指定容器，不影响服务器上其他正在运行或已停止的容器

3.挂载目录一起删除

# 查看挂载路径

docker inspect 容器名 | grep -E 'Source|Destination'

# 输出举例

"Source": "/root/devhome/mysql-data",
"Destination": "/var/lib/mysql"
Source：你服务器本地的真实目录（数据库数据存在这里）
Destination：容器内部目录（不用管）

# 删除容器

docker rm -f -v 容器名/ID

# 删数据库数据

rm -rf 服务器本地Source路径

二.删除对应镜像

1.查看所有镜像

docker images

输出说明：通过第一步记录的容器所用镜像（IMAGE 字段），对应找到需要删除的镜像，记录镜像名或镜像ID

2.执行镜像删除操作

删除单个镜像

docker rmi 镜像名或镜像ID

删除多个镜像

docker rmi 镜像1名/ID 镜像2名/ID 镜像3名/ID

3.清理 Docker 无用残留缓存

删除镜像后，执行以下命令，清理 Docker 系统中无用的残留缓存（如悬空镜像、废弃网络、临时构建产物等），不影响其他在用容器和镜像

docker system prune -f

4.注意事项

必须先删除容器，再删除镜像（若镜像仍被容器引用，直接删除镜像会失败）
docker system prune \-f 仅清理“无人引用”的垃圾缓存，不会误删正在使用的镜像、容器或网络

三.删除目标项目绑定的 SSL 证书

此步骤仅针对目标项目绑定的域名 SSL 证书（由 acme.sh 申请），彻底删除证书及相关配置，不影响其他域名的证书。

1.查看所有 SSL 证书（定位目标证书）

执行以下命令，查看服务器上所有由 acme.sh 申请的 SSL 证书，找到目标项目绑定的域名

acme.sh --list

2.注销 SSL 证书

通知证书颁发机构（如 Let's Encrypt），该域名的证书不再使用，执行注销命令：

acme.sh --revoke -d 目标域名

补充：若证书为 ECC 类型，需在命令后添加 --ecc，即：acme\.sh \-\-revoke \-d 目标域名 \-\-ecc

3.从 acme.sh 管理列表删除证书

将目标域名的证书从 acme.sh 的管理列表中删除，避免后续自动续期：

acme.sh --remove -d 目标域名

4.彻底删除证书文件及缓存

acme.sh 申请的证书文件默认存储在 ~/.acme.sh/ 目录下，执行以下命令删除对应域名的所有证书文件、私钥及缓存：

rm -rf ~/.acme.sh/目标域名
rm -rf ~/.acme.sh/目标域名_ecc

5.删除 Nginx 中对应域名的配置

目标域名的反向代理、SSL 配置文件一般存储在 /usr/local/nginx/conf/ssl/ 目录下，执行以下命令删除

具体路径说明可以查看往期文章: 理解服务器中的Nginx)

6.重载 Nginx 使配置生效

nginx -t  # 检查配置语法，输出 test is successful 即为正常
systemctl reload nginx  # 重载 Nginx

四.重新构建容器时无缓存方法

此步骤适用于删除旧项目后重新构建，或更新项目代码后重新构建，全程不产生缓存，确保构建的容器为最新版本，避免缓存导致的旧代码残留。

1.先删除旧容器

若重新构建的是原有项目，需先删除旧的容器（避免端口冲突、缓存残留）

docker rm -f 旧容器名或ID

2.进入项目目录

切换到存放项目 Dockerfile 的目录（必须进入该目录，否则构建会失败）

cd /服务器上的项目目录

3.无缓存构建镜像

执行无缓存构建命令，确保不使用任何旧缓存，完全基于最新代码构建镜像：

docker build --no-cache -t 镜像名 .

注意⚠️： --no-cache 是核心参数，用于禁用缓存；-t 用于指定镜像名称（自定义，与后续启动容器时的镜像名一致）；末尾的 . 表示当前目录（即 Dockerfile 所在目录）。

4.启动新容器

镜像构建完成后，执行启动命令，启动新容器（使用自己的启动参数，如端口映射、目录挂载等）

docker compose up -d --build

5.清理构建残留缓存

构建完成后，执行以下命令，清理构建过程中产生的无用缓存（如中间构建层），节省磁盘空间

docker image prune -f

6.注意事项

--no-cache 必须添加，否则 Docker 会复用旧缓存，导致构建的镜像不是最新代码
启动容器时，确保端口、目录挂载等参数正确，避免与其他容器冲突
docker image prune -f 仅清理构建残留的无用缓存，不影响正在使用的镜像和容器
若构建失败，需先检查 Dockerfile 是否正确，再重新执行构建命令

GPT 充值漏洞解析

Mon, 27 Apr 2026 00:00:00 GMT

GPT 充值漏洞解析

最近这段时间，网络上各种 GPT Plus 和 Pro 的代充层出不穷，并且只需要15-30块，可要知道官方充值 Plus 需要20刀，而 Pro 更是高达200刀，更离谱的是，部分不良商家 Plus 代充更是需要100-120块。多数人只看到低价优势，却不了解背后的核心原理：这类低价代充，本质是利用了 OpenAI iOS 内购的收据验证漏洞，本文仅从理论上进行实操讲解，仅作为技术学习参考，禁止商用牟利

一.正常官方订阅无漏洞流程

以 iOS 内购为例：

你用自己的土区 Apple ID → 绑定土区信用卡 / 礼品卡
在 ChatGPT App 点订阅 → Apple 扣款 → Apple 生成加密收据（receipt-data）
App 把：收据 + 你当前登录的 OpenAI Token 发给 OpenAI 后端
OpenAI 验证：
- 收据是 Apple 签名、真实有效 ✅
- 收据所属 Apple ID = 当前账号的购买 Apple ID ✅
验证通过 → 给你账号开 Plus/Pro

关键点：收据和 Apple ID、OpenAI 账号三者绑定，一收据只能用一次

二.核心漏洞简介

目前市面上所有所谓的 “土耳其正规代充” 本质都是利用了 OpenAI 对 iOS 内购收据的校验逻辑漏洞

2026年4月17日，匿名开发者 BugstoOai 在 OpenAI 官方社区（ChatGPT Bugs 板块）发布了一篇安全报告，标题为《[Security Report] Apple Pay receipt validation does not bind to purchaser Apple ID》，这是该漏洞首次在公开渠道被披露，也是唯一一次出现在 OpenAI 官方相关渠道的记录
报告核心结论清晰明确：OpenAI 对 iOS 版 ChatGPT Plus 的订阅验证流程，仅验收获据（receipt-data）的加密真实性（即是否有苹果官方签名），不验证购买该收据的 Apple ID，与接收 Plus 订阅的 OpenAI 账号是否存在绑定关系，这一逻辑缺陷直接导致 “一张真实有效的收据，可无限次给任意 OpenAI 账号开通 Plus 订阅”
通俗易懂的来讲，就好比你拿一张小票去兑换礼品，商家只要核验这张小票是真的，就把对应的礼品给你，紧接着你的七大姑八大姨都拿这张小票去兑换礼品，商家继续核验小票是真的就又把礼品给你，而不会去核验这张小票是否已经领取礼品了
总结下来就是 OpenAI 只验收据真假，不验 “收据是谁买的、给谁用的” 也就是：

只看：收据有效 + Token 有效 = 直接开 Plus/Pro
不看：这张收据是不是你的 Apple ID 买的
不看：收据和 OpenAI 账号是否一一对应

漏洞原文地址

三.完整流程

1. 前置准备

环境：确保电脑已安装 Python（3.7 及以上版本），打开终端/命令提示符，输入 python -version 验证是否安装成功
硬件：一台 iPhone/iPad（用于购买内购、抓包）和一台电脑（用于运行抓包工具）
软件：抓包工具二选一（Charles 简单易上手，适合新手；mitmproxy 适合开发者，跨平台）
安装命令：在终端输入 pip install mitmproxy，等待安装完成（Mac/Linux 可能需要用 pip3 替代 pip）
验证安装：输入 mitmproxy，若终端出现 mitmproxy 交互界面，即安装成功
其他：余额充足的土耳其区 Apple ID（用于购买 GPT Plus 内购）、已登录 OpenAI 账号的浏览器

2.拦截并导出苹果内购收据

这一步是所有操作的基础，只要拿到有效的 receipt-data，就可以实现无限复用，具体步骤如下：

配置手机代理：电脑和手机连接同一个 WiFi，打开 Charles，查看电脑的局域网 IP；打开 iPhone，进入 WiFi 设置，点击已连接的 WiFi，选择“配置代理”，输入电脑 IP 和默认端口号
安装信任证书：手机浏览器打开地址 chls.pro/ssl，下载并安装 Charles 根证书；进入手机设置 → 通用 → 证书信任设置，完全信任该证书（目的是解密 HTTPS 流量，否则无法看到加密的收据数据）
购买内购并抓包：手机登录土耳其区 App Store，打开官方 ChatGPT iOS 客户端，进入升级 Plus 页面，完成付款（土耳其区价格 499 里拉，约 85 元）；付款瞬间，在 Charles 中过滤域名 chatgpt.com，找到 POST 请求 /backend-api/subscription/upgrade
导出收据：点开该请求的 Request Body，会看到一段 JSON 数据，其中 "receipt_data" 对应的长串 base64 字符串，就是苹果内购收据，全选复制，保存到记事本即可——这条收据是 加密二进制 + base64 永久有效，可无限复用

补充：除了 Charles，也可以用 mitmproxy 抓包，操作逻辑一致：启动 mitmproxy 后，配置手机代理（IP 为电脑 IP，端口默认 8080），安装 mitmproxy 根证书，购买内购后，在 mitmproxy 终端找到对应请求，提取 receipt-data 即可，抓包核心是“拦截 ChatGPT 向 OpenAI 提交收据的请求”，两种工具均可实现

3. 获取 OpenAI 账号 session token

token 是账号的授权凭证，兑换 CDK 时必须提供，获取步骤非常简单：

第一种

用浏览器打开 chatgpt.com，登录自己的 OpenAI 账号
按 F12 打开开发者工具，切换到 Application 选项卡
左侧找到 Cookies → 选中 chatgpt.com，找到键为 __Secure-next-auth.session-token 的值，复制完整字符串，就是该账号的 session token

第二种

浏览器登录 ChatGPT，访问

https://chatgpt.com/api/auth/session

全选复制里面的 access oken（也叫会话 Token）

4. CDK 与 token 的兑换流程

CDK 本质是收据的“核销凭证”，经过自定义加密/编码 打包成了CDK，

将session token 和 CDK 一并提交
后端验证 CDK 并取出绑定的 **receipt-data ** 组装 OpenAI 升级 API 请求，带上用户的 token 鉴权，提交给 OpenAI 后端
OpenAI 校验收据和 token 有效后，给用户账号开通 Plus 订阅，返回开通成功提示

5. 核心 API 原始请求

如果想直接测试收据和 token 的有效性，可以用 Postman 或 curl 调用 OpenAI 官方升级接口，具体请求如下：

POST https://chatgpt.com/backend-api/subscription/upgrade
Header:
Authorization: Bearer 【用户的session-token】
Content-Type: application/json

Body:
{
  "receipt_data": 【你抓包保存的base64收据】
}

四.为什么是土耳其而非其他国家

最根本的原因——价格全球最低，套利空间最大

OpenAI 采用 “购买力平价（PPP）” 的本地化定价策略，会根据不同国家的经济水平、货币汇率，制定差异化的 ChatGPT Plus/Pro 订阅价格，而非全球统一定价。其中，土耳其区的定价是目前全球最低的，2026年 ChatGPT Plus 月费约为499土耳其里拉，折合人民币仅77-85元，相比美区19.99美元（约137元）、欧区22.99欧元（约181元），价格直接减半，甚至比印度（1999卢比≈145元）、菲律宾（999比索≈113元）等其他低价地区还要低

其次——漏洞适配性强，无额外风控阻碍

结合本次 OpenAI iOS 内购收据漏洞来看，土耳其区的收据适配性极强，没有额外的风控阻碍：

收据通用性高：土耳其区 iOS 内购生成的 receipt-data，和其他地区的收据格式完全一致，均可直接调用 OpenAI 的升级接口，无需额外破解或适配，只要收据真实有效，就能无限复用。
前期风控宽松：在漏洞公开初期，OpenAI 对土耳其区的收据复用行为没有专门的风控拦截，同一张收据可批量给成千上万个账号开通；即便目前进入灰度封堵阶段，土耳其区收据的成功率依然高于其他低价地区，这也是代充不愿更换地区的原因之一

五.常见疑问

1.CDK 和 receipt-data 是什么关系

receipt-data 是底层真实凭证，是苹果返回的真实内购收据（base64 长串），OpenAI 真正认的凭证，永久有效、可无限复用。而 CDK 是上层兑换码，是生成的随机兑换码（如 16 位字符串），是为了让 receipt-data 不直接售卖导致泄露，核心关系是商家卖 CDK 给你，你去商家提供的网站充值时，系统后端经过两层处理，第一验证 CDK 是否还是未使用的有效的，防止卖给你一个 CDK 你自己可以去充值无数个会员了。第二，如果是未使用的有效，就调出这个 CDK 对应的 receipt-data 发送给 OpenAI 后端进行验证充值Plus/Pro

2.为什么一个 receipt-data 可以有多个 CDK

原始苹果支付收据只有 1 份二进制原始数据，是固定不变的，不会自己变，商家把同一份原始收据 Base64 字符串做一层自定义加密 / 编码生成无数个随机字符串（CDK），然后回到第一个疑问，你去用这个 CDK 充值的时候，验证有效之后才会调出 receipt-data 发生给 OpenAI 后端进行校验充值

DeepSeek V4 终于发布！

Fri, 24 Apr 2026 00:00:00 GMT

DeepSeek-V4 终于发布!

前几天OpenAI发布的GPT-image-2，其生图能力真的刷新了我的认知，并且在昨天GPT-5.5也正式发布，同时，腾讯混元还发布了新的开源模型腾讯混元 Hy3 preview ，而在今天 DeepSeek 正式发布并且开源了 DeepSeek-V4，这也意味着从今天开始，1M上下文是 DeepSeek 所有官方服务的标配 身为湛江人，由衷为梁文锋与 DeepSeek 感到骄傲，特地写篇文章记录一下

一.DeepSeek-V4 是什么

DeepSeek-V4是深度求索（DeepSeek）于2026年4月24日正式发布的新一代旗舰大模型，分为V4-Pro与V4-Flash两个版本，同步开源并开放API，支持本地部署、云端调用、IDE插件接入等多种方式

其核心定位的核心特点的：

纯国产算力训练，全栈适配华为昇腾生态
开源开放、可自由接入工具链，无平台绑定
百万token超长上下文，强推理、强代码生成能力
全平台开源：同步上线Hugging Face、魔搭社区，权重、代码、文档完全开放，开箱即用

二.版本对比

DeepSeek-V4-Pro：对标顶级闭源模型，1.6T，49B激活，上下文长度1M；
DeepSeek-V4-Flash：更小更快的经济版，284B，13B激活，上下文长度1M

官方原话是：在Agent能力、世界知识和推理性能上均实现国内与开源领域的领先

并且目前DeepSeek-V4已经成为公司内部员工使用的Agentic Coding模型，据评测反馈使用体验优于Sonnet 4.5，交付质量接近Opus 4.6非思考模式，但仍与Opus 4.6思考模型存在一定差距

官方很坦诚的直接说了 V4 跟Opus 4.6 的思考模式还有一定差距，但不急着否定，看看价格方面

DeepSeek V4 的 API 定价是输入 0.3美元，输出是 0.5美元每百万 token，缓存命中后输入甚至低到 0.03美元。而 GPT-5.5 是输入 5美元、输出 30美元。也就是说，GPT-5.5 的输出价格是 DeepSeek V4 的 60 倍！你用 GPT-5.5 花 60 块钱干的活儿，用 DeepSeek V4 只要 1 块钱。还是很让人兴奋的，并且 DeepSeek 还提到了，在下半年会大幅度降价

而且 DeepSeek V4 专门针对 Claude Code、OpenClaw、OpenCode 等主流 Agent 产品进行了适配和优化，AI 编程用户可以直接切换使用。

三.行业测评反馈

DeepSeek-V4发布后，国内外AI领域专家、机构及技术博主纷纷开展测评，核心反馈如下，供参考

1.李沐

在MMLU（多任务语言理解）、GSM8K（数学推理）数据集上，V4-Pro得分分别达88.7分、92.3分，超越Llama 3 70B、Qwen 2.5 14B，接近GPT-4o水平，中文推理、代码生成表现优于GPT-5.5。

2.梁文锋

V4全程采用国产算力训练，未依赖国外GPU，后续将重点优化多模态能力（图文、语音），对标GPT-4o图片模型，同时降低部署门槛，普惠更多开发者。

3.Hugging Face官方团队

V4-Pro综合性能超越Llama 3 70B，代码生成能力领先5.2分，接近GPT-5.5水平；开源友好度高，支持一键调用，发布3天Hugging Face仓库下载量突破10万次

四.DeepSeek 近期融资动态

自 DeepSeek 成立以来，一直都是由母公司幻方量化孵化并持续“自我供血”，多次拒绝头部VC及科技巨头投资，保持财务独立，但在 2026年4月17日，其首次启动外部融资，核心信息如下

估值：超100亿美元，最近有传闻已上调至200亿美元
融资规模：计划募集不少于3亿美元（约20.5亿元人民币）

DeepSeek 最圈粉的特质，从来不止是强悍的模型性能，更是极致开放、中立独立、无绑定、普惠开发者的姿态，而这次融资，可以给 DeepSeek 带来更强的算力储备、人才扩张、多模态研发投入，加速模型迭代与商业化落地，让国产顶尖大模型更快普及、降低调用成本，对于我们普通开发者和行业而言都是利好! 同时我也相信， DeepSeek 不会因为资本入局而丢掉原本的初心，我们不想看到一个纯粹靠技术出圈的国产黑马，最终被巨头生态裹挟、走向封闭、限制开源

五.相关链接

OpenCode 介绍及使用教程

Tue, 21 Apr 2026 00:00:00 GMT

OpenCode 介绍及使用教程

在 Claude code 源码没有被泄露之前，OpenCode 一直是我使用的核心编程工具，相当于是 Claude code 的平替，4.1号 Claude code 源码被意外泄露之后，我逐渐转向了 Claude code，但仍偶尔使用到OpenCode （主要是简单的任务，直接让 OpenCode 的免费模型进行处理）因此写了篇文章总结一下

一.OpenCode 简介

OpenCode 是一款开源的 AI 编码代理工具，包含CLI，客户端，IDE插件，云端四种形态，它完全开源，并且内置四大免费模型，开箱即用，用户还可以自行接入第三方自定义模型，无需被单一平台绑定，同时 OpenCode 以隐私为首要原则，不存储任何代码或上下文数据，可适配隐私敏感环境

二.核心功能亮点

LSP 支持：自动加载适合大语言模型（LLM）的语言服务器协议（LSP），提升编码体验
多会话并行：可在同一个项目中同时启动多个代理，高效处理多任务
会话分享：可生成会话链接，用于参考或协作调试，方便团队协作
多模型兼容：支持 75+ 种 LLM 提供商，包括本地模型，选择灵活
编辑器适配：运行于终端，可与任意集成开发环境（IDE）搭配使用，不局限于特定工具

三.安装方法

OpenCode 支持多种安装方式，可根据自身系统和习惯选择

一键安装（推荐）

curl -fsSL https://opencode.ai/install | bash

其他安装方式

# npm 安装
npm i -g opencode-ai@latest

# 适用于bun
bun add -g opencode-ai

# brew 安装（适用于 macOS）
brew install opencode

# paru 安装（适用于 Arch Linux）
paru -S opencode

安装验证

安装完成后，可通过以下命令验证是否安装成功

opencode -v

四.快速使用教程

1) 基础操作流程

启动 OpenCode：在项目目录下，输入命令 opencode，启动工具并进入终端交互界面
初始化项目：输入命令 /init，AI 会自动分析项目结构，并生成 AGENTS.md 配置文件，完成项目初始化
接下来就可以用自然语言和 OpenCode 进行对话，让 OpenCode 干活了

2) 常用命令

# 查看或选择会话和模型
ctrl+p

# 查看当前模型
/models

# 生成当前会话的分享链接（取消分享是/unshare）会自动复制链接到剪切板
/share

# 把对话记录导出成文件
/export

# 查看对话记录,选中某次对话后，回车选择 Revert 功能可以把代码跟聊天记录一起回退到这次对话之前的状态
/timeline

# 压缩上下文，生成简洁摘要
/compact

# 撤销上一步操作
/undo

五.自定义模型

OpenCode 自定义模型接入，核心是通过 opencode.json 配置文件对接任意兼容 OpenAI 格式的模型

1.在 ~/opencode 目录下创建opencode.json文件

2.不同提供商不同模型

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "openrouter": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "第一个模型提供商Base URL",
        "apiKey": "第一个模型提供商的密钥"
      },
      "models": {
        "模型ID": { "name": "模型显示名称，自定义" }
      }
    },
    "openrouter2": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "第二个模型提供商Base URL",
        "apiKey": "第二个模型提供商的密钥"
      },
      "models": {
        "模型ID": { "name": "模型显示名称，自定义" }
      }
    }
  },
  "model": "openrouter2/模型ID"
  // 默认模型，实际配置的时候要把这行注释删掉
}

3.同提供商不同模型

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "openrouter": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "提供商Base URL",
        "apiKey": "提供商的密钥"
      },
      "models": {
        "第一个模型ID": {
          "name": "模型显示名称，自定义"
        },
        "第二个模型ID": {
          "name": "模型显示名称，自定义"
        },
        "第三个模型ID": {
          "name": "模型显示名称，自定义"
        }
      }
    }
  },
  "model": "openrouter/默认模型ID"
}

4.安装依赖

npm install @ai-sdk/openai-compatible --save

学习如何使用Link-Navigator

Fri, 10 Apr 2026 00:00:00 GMT

Link-Navigator使用说明

一.项目定位

Link-Navigator 是一个自托管书签管理系统，用于保存、分类、搜索和整理网页链接。

核心特点：

数据自托管（SQLite 本地存储）
支持标签分类与嵌套标签
支持导入浏览器/Pocket/Raindrop 书签
支持书签封面图（可手填、自动抓取、随机图）

二.快速部署

一键部署命令

git clone https://github.com/super-mortal/Links-Navigator.git
cd Links-Navigator
docker compose up -d --build

部署完成后访问：

HTTP：http://你的服务器IP:4124
HTTPS：https://你的服务器IP:4125

三.首次初始化说明

首次进入系统时，会进入初始化流程：

创建数据库
创建登录账户
可选设置集成/导入

四.日常使用逻辑

1.添加书签

进入首页后，点击右上角“添加”。

建议填写字段：

网址（必填）
标题
描述
图片网址（可选）
备注（可选）
标签（强烈建议）

辅助功能：

网址输入后可点抓取按钮，自动获取标题/描述/图片
图片区域右侧有“随机”选项，勾选后保存时自动调用随机图片 API

保存后，书签会出现在列表中

2.编辑书签

在书签条目右侧操作菜单中可进行：

编辑
刷新元数据
删除

编辑页可修改标题、描述、图片、标签和备注

3.书签分类

本项目以“标签”作为分类核心。

一个书签可以打多个标签
标签支持父子层级（嵌套）
左侧栏可按标签筛选

4.批量操作

在列表中勾选多个书签后，可进行：

批量打标签
批量删除
批量刷新元数据

5.导入已有书签

在设置 -> 导入页面可导入：

浏览器导出的 HTML 书签
Raindrop.io 导出的数据
Pocket 导出的ZIP

6.数据存储与备份

数据库类型：SQLite

容器内数据库路径：

/var/www/html/storage/link_navigator.db

宿主机默认永久存储路径（Docker Volume）：

/var/lib/docker/volumes/link-navigator_link-navigator-storage/_data/link_navigator.db

建议定期备份该 .db 文件与 img 目录。

五.更新部署

进入项目目录后执行：

git pull
docker compose up -d --build

说明：

代码会更新并重新构建镜像
数据卷不删除，历史数据会保留

六.发展规划

按先后顺序排序

新增所有书签导出功能
新增便签板块

七.常见问题

1.为什么看不到“安装应用”图标？

常见原因：

使用了 IP + HTTP（非 HTTPS）
浏览器不支持或未触发安装条件
页面停留时间与交互未满足条件

简化结论：

localhost 场景下 HTTP 通常可安装
IP:端口 场景一般需要 HTTPS 才会显示安装入口

2.为什么重建容器后数据还在？

因为使用了 Docker Volume 持久化，重建容器不会清空数据

八.致谢🙏

- 原开源项目：denho/faved

- 为本项目提供免费图片接口：LoliAPI

- 为本项目提供部署托管支持：狐蒂云

Astro框架中相对路径在URL拼接时的不确定性问题

Thu, 09 Apr 2026 00:00:00 GMT

Astro框架中相对路径在URL拼接时的不确定性问题

一.问题发现

偶然之间，我发现网络爬虫在抓取我的博客页面时，生成的 Open Graph (OG) 图片地址显示为：

https://localhost/images/social-card.png

# 而不是https://supermortal.cn/images/social-card.png，导致图片无法显示，下图为修复之后的截图

二.问题排查过程

第一步：检查配置文件

首先，我检查了项目中的所有配置文件：

astro.config.ts（第 28 行）：

site: 'https://supermortal.cn',

这里已经正确配置了正式域名

src/site.config.ts（第 14 行）：

socialCard: '/images/social-card.png',

这里使用的是相对路径

第二步：分析代码逻辑

在 src/components/BaseHead.astro 中，找到生成 meta 标签的关键代码（第 14 行）：

const socialImageURL = new URL(ogImage ? ogImage : config.socialCard, Astro.url).href

这里的问题是使用了 new URL(..., Astro.url) 方法。

第三步：理解关键概念

我意识到这里涉及两个不同的 URL：

astro.config.ts 的 site 配置：定义网站在互联网上的正式域名（用于 RSS、sitemap 等元数据）
Astro.url：在运行时由框架根据浏览器实际请求的 URL 提供的当前请求地址

在开发环境中，浏览器请求 http://localhost:3000/，所以 Astro.url 就是 http://localhost:3000。
但是网络爬虫的工作环境可能与本地浏览器不同，在某些情况下，Astro.url 可能被错误识别为 https://localhost

第四步：URL 拼接验证

当使用 new URL('/images/social-card.png', Astro.url) 时：

如果 Astro.url 是 http://localhost，结果就是 http://localhost/images/social-card.png
如果 Astro.url 是 https://supermortal.cn，结果就是 https://supermortal.cn/images/social-card.png

三.解决方案

使用绝对 URL

直接在 src/site.config.ts 中使用完整的域名 URL：

socialCard: 'https://supermortal.cn/images/social-card.png'

修改之后可以看到爬虫正确抓取了我的博客信息，同时QQ分享链接时也正确显示了元数据信息

未修改之前无法正确抓取只能显示如下图所示的纯链接

四.问题根源总结

配置分离的问题：astro.config.ts 的 site 配置和运行时的 Astro.url 是两个不同的概念
URL 拼接的不确定性：new URL(相对路径, Astro.url) 依赖于 Astro.url 的实际值，不可控
开发环境与爬虫环境的差异：本地开发和爬虫访问的 URL 环境可能不同

五.经验踩坑

踩到的坑 1：相对路径在某些环境下失效

最初使用相对路径 /images/social-card.png 是因为：

静态资源部署简单
不需要关心域名变化

但实际上，在 URL 拼接时，相对路径仍然会依赖当前页面的 URL，这带来了不可预知的行为。

踩到的坑 2：依赖 `Astro.url` 的不确定性

Astro.url 在不同运行环境下表现可能不同：

开发环境：http://localhost:3000
生产环境：https://supermortal.cn
爬虫环境：可能不一样

依赖这个值进行 URL 拼接是危险的

一文搞懂 AI 编程的核心术语

Mon, 06 Apr 2026 00:00:00 GMT

一文搞懂 AI 编程的核心术语

以前我对AI的认知很简单，以为不过是像豆包那样聊天问答、查资料的工具。直到今年一月偶然接触到Kiro、Cursor这类AI IDE，才真正见识到AI的强大。在AI编程的实战中，我不仅学到了大量知识，也熟悉了许多核心技术术语，于是想写篇文章好好总结一番

AI 基础概念

人工智能（AI）

人工智能（Artificial Intelligence）是让计算机模拟人类智能的技术。简单来说，就是让机器能像人一样思考、学习和解决问题。
在 Vibe Coding 中，AI 就是你的编程助手。你只管告诉它要做什么，它就会嘎嘎帮你做方案、写代码、修 Bug，就像你有一个 24 小时在线的程序员朋友，随时可以帮你干活。

大语言模型（LLM）

大语言模型（Large Language Model）是一种能够理解和生成人类语言的 AI 系统，ChatGPT、Claude、Gemini、DeepSeek 都是大语言模型。
为什么叫 “大” 模型呢？因为这些模型的参数量非常庞大，动则几十亿甚至上万亿个参数，参数越多，模型通常越聪明，但也越消耗计算资源。
你可以把大语言模型理解成一个读过海量书籍和代码的超级学霸，它见过无数的编程案例，所以能帮你写代码、解释代码、修复 Bug。
除了文本大语言模型之外，AI 领域还有专门处理图片的视觉模型（比如 Stable Diffusion），处理语音的音频模型（比如 Whisper）、以及能同时处理文字、图片、音频的多模态模型（如Gemini），在 AI 编程时，我们主要和文本大语言模型打交道。

Token

Token是 AI 模型处理文本的基本单位，现在中文名官方叫词元
Token 是必须掌握的核心概念，因为 AI 服务通常按照 Token 收费，你输入的文字和 AI 输出的文字都会消耗 Token，Token 用得越多，花的钱就越多。
在英文中，一个 Token 大约是一个单词或单词的一部分，在中文中，一个汉字通常是 1 ~ 2 个 Token
目前很多 AI 编程工具（比如 Cursor、Claude Code）都自带了 Token 消耗量的实时统计和展示，方便随时掌握用量和成本。

输入 Token 和输出 Token

AI 服务在计费时，一般会分别计算输入和输出的 Token。

输入 Token：你发给 AI 的内容，比如提示词、代码、文件等
输出 Token：AI 返回给你的内容，比如回答、生成的代码、工具调用指令等

一般来说，输出 Token 比输入 Token 更贵，以 Claude Sonnet 4为例，输入价格是 3 美元/百万 Token，输出价格是 15 美元/百万 Token，贵了 5 倍。这是因为生成内容比理解内容更消耗算力
最简单的一个省 Token 小技巧是：用心编写简洁清晰的提示词，让 AI 一次就能理解你的需求，减少反复对话

模型参数

参数是模型在训练过程中学到的 “知识点”，用数字的形式存储在模型中。
举个好理解的例子，模型在训练时读到了大量 “天空是蓝色的” 这类内容，它就会在参数中记住 “天空” 和 “蓝色” 之间的关联关系。参数越多，模型能记住的知识和关联就越丰富。
参数量直接影响模型的能力和使用成本。参数越多，模型越聪明，但运行时消耗的算力（GPU 计算资源）也越多，所以价格也越贵。
目前主流大模型中，明确公开参数量的有：

DeepSeek-V3：6710 亿参数（采用 MoE 混合专家架构，实际激活 370 亿）
Qwen3-235B：2350 亿参数（通义千问系列，激活 220 亿）
Llama 4 Scout：1090 亿参数（Meta 开源模型，激活 170 亿）

值得一提的是，即使是同一系列的大模型，厂商也会提供不同参数量的版本供你选择

模型训练和推理

训练（Training）是让 AI 模型从大量数据中学习知识的过程。这个过程需要海量的计算资源和时间，一般由 AI 公司完成。绝大多数情况下，你不需要自己训练模型，直接用训练好的成品就行。
推理（Inference）是模型训练完成、具备了知识之后，用学到的知识来回答问题、生成内容的过程。我们日常使用 AI 工具，比如和 ChatGPT 对话、让 Cursor 写代码，本质上都是 AI 模型在进行推理

打个比方，训练就像学生上学读书，推理就像学生参加考试答题。

模型微调（Fine-tuning）

微调是在已有模型的基础上，用特定领域的数据继续训练，让模型在某个领域表现更好。
比如，你可以用大量的医学资料微调一个模型，让它成为医学专家。或者用你公司的代码库微调，让它更了解你的项目风格。
对于普通用户来说，微调成本较高，一般不需要自己做，直接使用现成的模型就够了。不过，很多大模型应用开发平台（比如阿里云百炼、火山引擎等）都提供了模型微调的能力，降低了微调的门槛。

上下文窗口

上下文窗口（Context Window）是指 AI 模型一次能 “记住” 的最大内容量，用 Token 来衡量。
不同模型的上下文窗口大小不同：

GPT-4o：128K Token（约 10 万中文字）
Claude Opus 4.6：标准 200K Token，支持扩展到 1M Token（约 75 万中文字）
Gemini 3.1 Pro：1M Token（约 75 万中文字），且支持同时处理文字、图片、音频、视频

上下文窗口越大，AI 能处理的代码量就越多，能记住的对话历史就越长。如果你的项目代码很多，或者你不确定 AI 能否在一次对话中完成任务，选择上下文窗口大的模型会更合适。

但要注意，上下文窗口越大，每次请求消耗的 Token 也越多，成本也会更高。比如在 Cursor 中使用 Claude Sonnet 模型时，单次请求超过 20 万 Token，输入价格就会翻倍。

API访问核心配置

使用 AI 编程工具对接大模型时，需配置三个基础参数完成接口访问：

Base URL：大模型 API 的基础请求地址，决定了工具向哪个服务器发起请求

官方默认 Base URL：如 GPT 为 https://api.openai.com/v1、DeepSeek 为 https://api.deepseek.com/v1；
自定义场景：私有部署模型、第三方代理、本地模型服务均需修改 Base URL 适配

API Key：接口访问的身份凭证，由大模型厂商生成。

获取方式：在对应厂商的开发者平台/控制台创建应用后生成；
成本关联：API Key 绑定计费账户，接口调用产生的 Token 消耗会自动计费；
安全建议：使用环境变量或工具内置密钥管理，切勿明文写在代码或提示词中。

Model ID（模型ID）：指定要调用的具体大模型版本

作用：明确告诉服务器使用哪一款模型（不同参数、不同能力）；
示例：qwen3-14b-instruct、gpt-4o-mini、deepseek-chat；

三者关系：Base URL 决定“连到哪”，API Key 决定“你是谁”，Model ID 决定“用什么模型”

提示词相关

提示词（Prompt）

提示词是你给 AI 的指令或问题。在 AI 编程中，提示词就是你用自然语言描述的需求。
提示词的质量直接决定了 AI 输出的质量。一个好的提示词应该：

具体明确
包含必要的背景信息
说明期望的输出格式

比如，“做一个网站” 是一个模糊的提示词，而 “用 React 做一个记账网站，包含添加支出、查看列表、统计总额三个功能，界面用蓝色调” 就是一个更好的提示词

在 AI 对话中，消息一般分为 3 种角色：

系统提示词（System）：设置 AI 的角色和行为规则，对用户不可见
用户提示词（User）：你发送给 AI 的消息
助手提示词（Assistant）：AI 回复给你的消息

解这 3 种角色有助于你更好地使用 AI。比如很多 AI 编程工具允许你设置系统提示词来定义 AI 的行为规则，而你在对话框中发送的内容就是用户提示词。

系统提示词

系统提示词（System Prompt）是在对话开始前给 AI 设置的指令，用来定义 AI 的角色、行为和限制。

比如，你可以设置系统提示词：“你是一位资深的 Java 后端开发专家，请用简洁清晰的代码风格回答问题。”

系统提示词在整个对话过程中都会生效，是定制 AI 行为的重要方式。

提示词工程

提示词工程（Prompt Engineering）是设计和优化提示词的技术，目的是让 AI 更好地理解你的意图，生成更符合预期的结果。
这是 Vibe Coding 的核心技能之一。好的提示词工程师能用更少的对话轮次、更低的 Token 成本，让 AI 生成更高质量的代码。

零样本提示（Zero-shot）

零样本提示是指在给 AI 下达任务时，不提供任何示例，直接描述你的需求让 AI 去完成。

如：“请把这段英文翻译成中文。”

AI 会根据自己的训练知识来完成任务,对于简单任务，零样本提示一般就够用了，不需要提供额外的示例内容，还能节约一些 Token 成本。

少样本提示（Few-shot）

少样本提示是指在给 AI 下达任务时，额外提供几个输入输出的示例，让 AI 通过这些示例学习你想要的格式或风格，从而更准确地完成任务。

比如：

请按以下格式翻译：
英文：Hello → 中文：你好
英文：Thank you → 中文：谢谢
英文：Good morning → 中文：

通过提供示例，AI 能更准确地理解你的需求，输出更一致的结果。

思维链提示（Chain-of-Thought）

思维链提示（Chain-of-Thought，简称 CoT）是一种引导 AI 展示推理过程、一步一步思考问题的提示技术，而不是让 AI 直接给出答案。这对于复杂的推理任务特别有效，比如多步骤的数学计算、代码逻辑分析、系统架构设计等。
触发思维链提示的方法很简单。很多推理模型（比如 DeepSeek-R1）和 AI 编程工具天然内置了思维链能力，会自动展示推理过程。你也可以在提示词中手动加上 “请一步一步思考”，AI 就会展示它的推理过程，一般能得到更准确的答案。
在 AI 编程中，涉及复杂业务逻辑、多模块交互、或者需要权衡多种技术方案的项目，特别适合利用推理模型和思维链提示能力，让 AI 想清楚再动手。

Markdown 语言

Markdown 是一种轻量级的文本标记语言，用简单的符号来表示格式。比如用 # 表示标题，用 **文字** 表示加粗，用 - 表示列表。
在 AI 编程中，Markdown 非常重要，因为：

AI 生成的回答大多数都是 Markdown 格式
项目文档（如 README）采用 Markdown 编写
定义 AI 智能体的规则文件也是 Markdown 格式
包括我现在写的文章也是用Markdown 来写

学会 Markdown 能让你更好地跟 AI 交流，也能写出更规范的项目文档。更重要的是，结构化的内容（标题层级、列表、代码块等）有助于 AI 更准确地理解你的意图，同时也能培养你自己的结构化思维能力，这对写好提示词非常有帮助，更多markdown语法查看我的往期文章Markdown基础语法

AI 编程模式

Vibe Coding 氛围感编程

Vibe Coding 是由计算机科学家 Andrej Karpathy 在 2025 年 2 月提出的概念。它描述了一种全新的编程方式：通过自然语言和 AI 对话，让 AI 帮你写代码，你只需要描述需求、测试结果、指导方向。
你不需要精通编程语法，只需要能清楚表达你的想法，AI 负责把你的想法变成可运行的代码。
所以说，Vibe Coding 的重点不是写代码，而是明确需求并清晰表达。你描述得越清楚，AI 给你的结果就越靠谱。

这就像点外卖一样，你告诉外卖平台你想吃什么，餐厅帮你做好送到手上。你不需要会做饭，但要知道自己想吃什么。

Agentic Engineering 智能体工程

Agentic Engineering（智能体工程）是 2026 年 2 月由 Andrej Karpathy（也就是提出 Vibe Coding 的那位大佬）提出的新概念，可以理解为 Vibe Coding 的规范版。
Vibe Coding 就是跟着感觉写代码：你给 AI 一句话，AI 吐出代码，能跑就行，跑不了就把报错粘回去让 AI 再改。做个小工具贼拉快，但项目一大就容易翻车。
而 Agentic Engineering 的思路是：你先想清楚要干嘛、写好方案、拆好任务，再把活交给 AI 去执行，它干完了你还得验收，质量不行再打回去重做。

打个比方，Vibe Coding 的时候你是个 DJ，放什么歌全凭感觉；Agentic Engineering 里你是包工头，流程、质量、验收都得你说了算。一个跟着感觉走，一个按流程来。

当然，不是说 Vibe Coding 已经过时了。Vibe Coding 负责让你看到可能性，Agentic Engineering 负责把可能性变成真正能用的东西。二者适用于不同的场景，做小工具时可以用 Vibe Coding，做企业级项目就需要 Agentic Engineering 的思维。

Agentic Coding 智能体编程

Agentic Coding 智能体编程是指让 AI 像一个自主的 “智能体”（Agent）一样工作，能够自己规划任务、执行操作、验证结果，而不只是被动地回答问题。
它和前面提到的 Agentic Engineering 的区别在于，Agentic Coding 强调的是 AI 的自主执行能力（AI 能干什么），而 Agentic Engineering 强调的是人对 AI 的管理方法论（人该怎么管）。
如今，几乎所有主流 AI 编程工具都提供了智能体编程的能力。比如在 Cursor 的 Agent 模式中，AI 可以：

自动读取和分析多个文件
规划实现方案
执行代码修改
运行测试验证
自动修复问题

这比传统的问答式 AI 更强大，因为它能自主完成复杂的多步骤任务。可以说，AI 不再只是辅助编程的配角，而是正在成为项目开发的核心驱动力。

多智能体协作

多智能体协作（Multi-Agent）是指多个 AI 智能体分工合作，共同完成复杂任务。
比如，一个智能体负责设计架构，一个负责写前端代码，一个负责写后端代码，一个负责代码审查。它们像一个软件开发团队一样协作。
这两年，多智能体系统正在成为 AI 编程的重要趋势。它的优势不仅仅是能处理更复杂的项目，还能通过并行工作大幅提升效率，让原本需要几小时的任务在几分钟内完成。

智能体编排

编排（Orchestration）是指协调和管理多个 AI 智能体或 AI 任务的过程，确保它们按正确的顺序和方式工作。
如果说多智能体协作关注的是 “有哪些角色参与”，那编排关注的是 “谁先干、谁后干、结果怎么汇总”，它是多智能体系统的指挥中枢。

就像乐队指挥一样，编排器决定哪个智能体在什么时候做什么事情、如何传递信息、如何汇总结果。

Subagents 子代理

Subagents（子代理）是指主 AI 智能体将部分任务分派给独立的子智能体来并行处理的机制。
你可以把它理解成 AI 的下属，就像一个经理把活分给手下的几个员工同时干一样。当主 AI 遇到一个大任务时，它可以把独立的小任务分给几个子代理同时干，自己继续处理其他工作。
Subagents 的好处是：

并行处理多个独立任务，效率翻倍
主代理的上下文保持干净，不会被子任务的细节污染
每个子代理可以专注于自己的任务，结果更准确

比如你可以让几个子代理同时审查代码库的不同模块，速度会快很多。
在 Claude Code 中，AI 会通过内置的 Task 工具自动生成子代理来处理子任务，你不需要做额外配置。你也可以在 .claude/agents/ 目录下创建自定义的子代理（用 Markdown 文件定义），给它指定专属的角色描述、工具权限和行为规则
不过子代理也有局限，每个子代理的上下文是独立的，它们之间无法直接共享信息，所以不适合有强依赖关系的任务。另外，多个子代理同时运行会消耗更多 Token，成本会相应增加。就像公司招人一样，多招几个人确实能干得更快，但工资支出也得跟着涨，而且人多了沟通协调的成本也会上来

Agent Teams 智能体团队

Agent Teams（智能体团队）是 2026 年兴起的多智能体编程新模式，由 Claude Code 率先推出。它让 3 ~ 5 个独立的 AI 智能体组成团队，在同一个项目上并行工作。
和传统的单 AI 对话不同，Agent Teams 中有一个 Team Lead（队长）负责拆解任务和协调工作，其他 Teammates（队员）各自领取任务独立执行，还能通过消息系统互相沟通。
打个比方，以前用 AI 编程就像你一个人带一个实习生干活，现在 Agent Teams 相当于你直接管了一个小团队，前端、后端、测试同时干，效率翻了好几倍。Anthropic 的工程团队曾用 16 个 Agent 同时工作，产出了 10 万行 Rust 代码！把原本需要数天的工作压缩到了几小时。

当然，代价就是花费的 Tokens 可能会更多，不是什么时候都建议使用 Agent Teams

Background Agent

后台 Agent（Background Agent）是让 AI 在后台自主运行、完成任务后再通知你结果的能力。
传统的 AI 编程需要你盯着屏幕等 AI 一步步做完，电脑还不能关。而后台 Agent 允许你把任务交给 AI 后，就去做别的事情，AI 会在云端独立完成工作，你甚至可以关掉电脑！
比如让 AI 在后台修复一批 Bug、跑一轮代码审查、或者完成一个完整的功能模块，做完了会通知你来验收。
目前 Claude Code、Cursor 等工具都已经支持后台 Agent 能力。以后 AI 编程可能就像发微信一样，你在手机上把需求发过去，该干嘛干嘛，等 AI 做完了来找你验收就行。

Agent Loop 智能体循环

Agent Loop（智能体循环）是 AI 智能体的核心工作机制，简单来说就是 AI 通过不断重复 “感知-思考-行动-观察” 的循环来一步步完成任务。
一个典型的 Agent Loop 包括：

感知：获取当前环境信息（读取文件、查看错误等）
思考：分析情况，决定下一步行动
行动：执行具体操作（写代码、运行命令等）
观察：检查行动的结果
循环：根据结果决定是否继续

这个循环会一直进行，直到任务完成或达到终止条件。
理解 Agent Loop 能帮你更好地规划任务和管理 AI 的工作过程。需要特别注意的是，AI 编程时 Agent Loop 的循环次数不要太多，很多工具都有最大循环次数限制，循环太多不仅效果不好，还会疯狂烧 Token！有人一觉醒来发现额度用光了，就是因为让 AI 陷入了无限循环……

ReAct 推理与行动

ReAct（Reasoning and Acting）是一种让 AI 智能体交替进行推理和行动的技术范式。它的核心思想很简单：让 AI 先想清楚再动手，动完手再看看效果，然后继续想下一步怎么做。
传统的 AI 要么只思考不行动，要么只行动不思考。而 ReAct 让 AI 能够：

先推理：思考当前情况，制定计划
再行动：执行具体操作
观察结果：看看行动效果如何
继续推理：根据结果调整策略

这种 “思考 - 行动 - 观察” 的循环让 AI 能更可靠地完成复杂任务，是现代 AI 编程工具的核心技术之一

深度思考

深度思考（Deep Thinking）是让 AI 在回答之前先进行一段内部推理的能力，也叫 “扩展思考” 或 “思考模式”。

它和前面提到的思维链提示（CoT）有什么区别呢？

思维链提示是一种提示词技巧，通过提示词引导 AI 展示推理过程；而深度思考是模型内置的能力，AI 会在内部自动进行深度推理，不需要你在提示词中特别要求。
普通模式下，AI 收到问题后会直接生成回答。而开启深度思考后，AI 会先在内部进行一系列推理步骤，比如分析问题、考虑多种方案、评估利弊，然后才输出最终答案。你有时能在 AI 的回复中看到一个 “思考中...” 的过程，那就是深度思考在工作。
深度思考特别适合复杂的编程任务，比如设计系统架构、排查难以定位的 Bug、优化算法等。代价是速度更慢、Token 消耗更多。
目前主流 AI 模型和 AI 编程工具都支持深度思考，并且你可以选择是否开启思考模式。

自适应思考

自适应思考（Adaptive Thinking）是深度思考的智能化版本，让 AI 自动判断当前问题需要多深的思考程度。
以前深度推理模式只能手动开关，开了的话简单问题也慢吞吞地想半天、还浪费钱，关了的话复杂问题又容易出错。
AI 有了自适应思考能力后，可以做到简单问题秒回，复杂问题会自动进入深度思考模式。这样既保证了质量，又节省了时间和成本。
Anthropic 在 Claude Opus 4.6 中率先引入了自适应思考能力，开发者可以设置不同的思考力度级别来平衡质量和成本。

工具调用

工具调用（Tool Use / Function Calling）是让 AI 能够使用外部工具和功能的技术。
AI 本身只能生成文字，但通过工具调用，它可以读写文件、搜索网页、执行命令和脚本、调用 API、操作数据库等等。
工具调用的工作流程分为 4 步：

识别需求：AI 判断当前任务需要使用工具
选择工具：从可用工具中选择合适的
执行调用：用正确的参数调用工具
整合结果：将工具返回的结果融入回答，继续完成任务

举个例子，用户想要获取编程导航网站的热门文章，下面这张图清晰地展示了工具调用的完整流程：

需要注意的是，AI 模型本身并不直接执行工具，而是生成 “我想调用这个工具，参数是这些” 的指令，由外部系统执行后把结果返回给 AI。
有了工具调用，AI 就从 “只会说” 变成了 “能动手”。如果没有工具调用，AI 只能告诉你该怎么改代码，你还得自己去复制粘贴；而有了工具调用，AI 可以直接帮你读取文件、修改代码、运行命令，一条龙搞定。比如 Cursor 的 Agent 模式就是通过工具调用来实现自主编程的。

MCP 模型上下文协议

MCP（Model Context Protocol）是 Anthropic 在 2024 年底推出的开放标准，用于让 AI 模型安全地连接外部数据源和工具。
你可以把 MCP 理解成 AI 世界的 “USB 接口”。就像 USB 接口让各种设备（键盘、鼠标、U 盘）都能用同一种方式连接电脑一样，MCP 让各种外部工具（文件管理、数据库、搜索引擎等）都能用同一种方式连接 AI，不用为每个工具单独写一套对接代码。
MCP 的核心价值在于 标准化。开发者不需要为每个 AI 工具单独开发连接器，只需要按照 MCP 标准开发一次，就能被所有支持 MCP 的 AI 工具使用。目前 Claude Code、Cursor、Windsurf 等主流 AI 编程工具，以及各种网页 AI Agent 应用都已经支持 MCP 协议。
在 Vibe Coding 中，MCP 让 AI 能够连接更多外部工具和数据源，大大扩展了 AI 的能力边界。比如通过 Figma MCP，AI 可以直接读取设计稿并生成对应的网页代码；通过 GitHub MCP，AI 可以直接操作代码仓库、创建 PR；通过数据库 MCP，AI 可以查询和分析业务数据。

Agent Skills 智能体技能

Agent Skills（智能体技能）是 Anthropic 在 2025 年 10 月推出的一套开放标准，目的是让 AI 能够学习使用各种专业技能，快速扩展特定领域的专业能力。
简单来说，Agent Skills 就是给 AI 准备的 技能包。技能包里有精心设计的提示词、代码脚本、还有各种资源文件。
把 AI 想象成一个职场小白，给他装上 文档处理技能，它就立刻知道怎么生成 PPT、处理 Excel 表格；装上 代码规范技能，它就知道怎么按照公司标准写代码。
Skill 的本质是一个包含 SKILL.md 文件的文件夹，里面可以放置指令说明、脚本代码、参考资料等。当 AI 遇到相关任务时，会自动加载对应的 Skill 来增强自己的能力。
Skills 的核心设计是 渐进式披露，AI 只在需要时才加载相关内容，不会一次性把所有信息都塞进上下文，既节省 Token 又保持灵活性

斜杠命令

斜杠命令（Slash Commands）是在 AI 编程工具的对话框中输入 / 触发的快捷指令，可以快速执行常用操作。
你可以把斜杠命令理解成操作 AI 的快捷键。Cursor、Claude Code 等主流 AI 编程工具都支持斜杠命令，比如 Claude Code 内置了这些常用的斜杠命令：

/help：查看可用命令
/compact：压缩当前对话的上下文
/config：修改配置
/skills：查看已安装的技能

你可以自定义斜杠命令，把常用的工作流封装起来复用。比如创建一个 /commit-push-pr 命令，一次性完成代码提交、推送和创建 PR；或者搞个 /techdebt 命令，每次会话结束跑一下清理重复代码。
自定义命令的本质其实就是一个 Markdown 文件，在 Cursor 中，只需要在项目的 .cursor/commands/ 目录下创建 .md 文件，里面写上你想要 AI 执行的指令，这个文件名就会变成一个斜杠命令。还可以用 Git 版本控制工具来管理自定义命令的文件，跨项目复用。

A2A（Agent-to-Agent）

A2A（Agent-to-Agent）是指 AI 智能体之间相互通信和协作的协议或方式，是多智能体系统的基础技术。
就像人和人之间需要语言来沟通，AI 智能体之间也需要标准化的方式来交换信息、分配任务、汇报结果。
A2A 协议让不同的 AI 智能体能够组成团队，分工合作完成复杂任务。这个协议由 Google 在 2025 年推出，目前已有超过 150 家企业加入支持。

不要把 A2A 和 MCP 搞混！二者是互补关系，MCP 解决的是 AI 连接工具的问题，A2A 解决的是 AI 之间沟通协作的问题

BMAD 敏捷 AI 开发方法

BMAD-METHOD（Breakthrough Method of Agile AI-Driven Development，突破性敏捷 AI 驱动开发方法）是一套系统化的 AI 智能体开发框架，目标是将原本混乱的 AI 编程过程变得结构化、可复用。
BMAD 使用 角色化智能体 的方式组织开发流程，每个智能体扮演特定角色：

Analyst Agent 分析师：创建项目简报，包含市场分析和用户画像
PM Agent 产品经理：将简报转化为详细的产品需求文档（PRD）
Architect Agent 架构师：设计技术实现方案和系统架构

BMAD 中的智能体分为两种类型：

Simple Agents 简单智能体：单文件、自包含，适合代码审查、文档生成等聚焦任务
Expert Agents 专家智能体：具有跨会话持久记忆，配有专属文件夹存放资源，适合复杂的多步骤工作流

每个智能体都有标准化的组成部分，包括人设（角色、身份、沟通风格、原则）、能力列表、交互菜单，以及可选的关键行动。
BMAD 在 GitHub 上获得了几万+ Star，说明这种结构化的 AI 开发方法正在被越来越多的开发者认可

Browser Use 浏览器使用

Browser Use（浏览器使用）是让 AI 智能体能够自主操控网页浏览器的技术能力。通过 Browser Use，AI 可以像人类一样浏览网页、点击按钮、填写表单、提取数据。
Browser Use 的典型应用场景：

自动化研究：让 AI 在多个网站上搜索、整理信息
数据采集：从网页中提取结构化数据
表单填写：自动完成繁琐的在线表单
跨平台操作：在不同网站间完成多步骤任务

比较知名的开源项目是 Browser-Use，支持通过 Python 调用多种大模型来控制浏览器。此外，Cursor、Claude Code 等主流 AI 编程工具也内置了 Browser Use 能力，可以在开发过程中自动打开浏览器预览效果、执行测试等操作

Computer Use 计算机使用

Computer Use（计算机使用）是 Anthropic 公司在 2024 年推出的 AI 能力，让 Claude 大模型能够像人类一样操作整个计算机桌面。
和 Browser Use 只能操作浏览器不同，Computer Use 可以操作任何桌面应用程序，比如：

查看屏幕截图，理解界面元素
移动鼠标光标，点击按钮
使用键盘输入文字
执行命令行操作

Computer Use 的工作原理是一个持续的反馈循环：

截图分析：AI 捕获并分析当前屏幕
决策规划：根据任务目标确定下一步操作

执行操作：发送鼠标/键盘输入
观察结果：检查操作效果，调整策略
💡 为了安全起见，Computer Use 一般需要在虚拟机或容器中运行，不会直接控制你的真实电脑。
Computer Use 代表了 AI 从 “只能生成文字” 到 “能够操作软件” 的重大跨越，彻底改变人机交互方式。
基于 Computer Use 技术，Anthropic 在 2026 年推出了 Claude Cowork，这是一个桌面端 AI 助手，可以直接访问你电脑上的文件和文件夹，帮你整理下载目录、从截图中提取数据到表格、准备品牌报告等日常办公任务。

上下文管理

上下文（Context）

上下文是 AI 在回答问题时能够参考的所有信息，包括：

当前对话的历史
你打开的代码文件
项目的结构和配置
你提供的参考资料

上下文越丰富、越和当前任务相关，AI 生成的代码就越符合你的需求。这就像给一个新同事交接工作，你给的背景信息越多，他上手就越快。
在 Cursor 中，你可以通过对话框附近的 Token 用量指示器来大致了解当前上下文的大小；在 Claude Code 中，可以使用 /context 命令查看上下文占用情况。

上下文工程

上下文工程（Context Engineering）是有策略地管理和优化提供给 AI 的上下文信息的技术。
核心目标是 让 AI 拥有恰到好处的信息。既不能太少（导致 AI 不了解情况），也不能太多（导致信息过载、成本上升）。
好的上下文工程包括：

选择最相关的文件
提供必要的背景说明
使用规则文件定义项目规范
适时清理无关的对话历史

上下文工程是目前 AI 领域非常热门的研究方向。2026 年的趋势正在从简单的上下文管理，演进到更复杂的 记忆架构 —— 让 AI 拥有短期记忆（当前对话上下文）、长期记忆（跨会话的知识积累）和外部记忆（向量数据库、知识图谱等）。
比如 Claude Opus 4.5 就引入了 Memory Tool，能让 AI 在超出上下文窗口的情况下，通过文件系统式的持久化存储来记住重要信息。根据 Anthropic 官方数据，这项技术在长时间工作流中减少了 84% 的 Token 消耗！

可以说，谁能更好地解决上下文和记忆的问题，谁就能在 AI 编程领域占据优势

上下文压缩

上下文压缩（Context Compaction）是 AI 自动压缩和总结之前对话内容的技术，解决的是长时间运行任务中上下文溢出的问题。
以前跑长任务的时候，AI 经常会撞到上下文长度的天花板，前面聊过的内容被挤掉后 AI 就失忆了，导致生成的代码和之前的约定对不上。有了上下文压缩，AI 会在上下文快要满的时候，自动把前面的对话总结成更精简的形式，保留关键信息的同时释放空间，这样就能持续工作更久而不会失忆。
你可以把它想象成项目经理写会议纪要。已经开了 3 小时的会，不可能把每句话都记下来，但关键决策、待办事项、重要结论都会被记录。AI 的上下文压缩也是类似的思路，把冗长的对话历史浓缩成关键信息。
Claude Opus 4.6 已经内置了上下文压缩能力，搭配它的 100 万 token 上下文窗口，可以让长时间运行的编程任务更加稳定。

规则文件

规则文件（Rules File）是放在项目中的配置文件，用来告诉 AI 你的项目规范、技术栈、代码风格等信息。有了规则文件，AI 每次生成代码时都可以参考这些规则，生成的代码更符合你的项目风格，省去了反复强调的麻烦。
不同 AI 编程工具使用不同的规则文件格式：

Cursor：早期使用 .cursorrules 单文件格式，现在推荐使用 .cursor/rules/*.mdc 多文件格式
Claude Code：使用 CLAUDE.md 文件
GitHub Copilot：使用 .github/copilot-instructions.md 文件

以 Cursor 为例，.mdc 规则文件支持 YAML 元数据（frontmatter），可以指定规则的适用范围。根据 Cursor 官方文档，其格式如下：

---
description: React 组件开发规范
globs: src/components/**/*.tsx
alwaysApply: false
---

# React 规范

- 使用函数式组件
- 优先使用 hooks

规则文件的激活方式有多种，比如：

始终生效：设置 alwaysApply: true
模式匹配：当引用匹配 globs 的文件时自动激活
手动调用：在对话中用 @规则名 引用
AI 自主决定：AI 根据任务相关性自动加载

💡 值得注意的是，随着工具版本的更新，这些文件的名称和标准可能会发生改变，一切以工具官方文档为主

AGENTS.md

AGENTS.md 是一种开放的文件格式，专门用于给 AI 编程智能体提供项目指令。它本质上也是一种规则文件，只不过是跨工具通用的开放标准。
传统的 README.md 是写给人看的，主要介绍项目是什么、怎么用。而 AGENTS.md 是写给 AI 看的，包含 AI 工作时需要的技术细节：

项目的构建和启动命令
测试运行方式
代码风格和规范
项目结构说明

一个典型的 AGENTS.md 文件大概长这样：

# 项目设置

- 安装依赖：npm install
- 启动开发：npm run dev
- 运行测试：npm test

# 代码规范

- 使用 TypeScript 严格模式
- 组件文件使用 PascalCase 命名
- 工具函数使用 camelCase 命名

AGENTS.md 的优势在于它是一个开放标准，被数万个开源项目采用。当你使用支持该标准的 AI 编程工具（比如 Claude Code、Codex、Cursor、GitHub Copilot 等）时，AI 会自动识别项目根目录下的 AGENTS.md 文件，并将其中的指令发送给 AI，不需要你手动引用。

RAG 检索增强生成

RAG（Retrieval-Augmented Generation 检索增强生成）是一种让 AI 能够先检索外部知识库、再基于检索结果生成回答的技术，目标是让 AI 的回答更准确、更有依据。
普通的 AI 只能依赖训练时学到的知识，而这些知识可能已经过时了。RAG 能让 AI 在回答问题时，先从你的文档、代码库、知识库中检索相关信息，然后基于这些信息生成回答。
这对于 Vibe Coding 特别有用，因为 AI 可以参考你项目中的已有代码，生成风格一致的新代码。
RAG 检索增强生成的工作流程如下图所示，做 AI 应用开发的程序员朋友们可以深入了解一下：

向量数据库

向量数据库是专门用来存储和查询 “向量”（一种数字表示形式）的数据库。在 AI 领域，它常用来存储文本的语义表示。
什么是向量呢？简单来说，向量就是一串数字组成的数组，比如 [0.1, 0.5, 0.3, 0.8]。每个数字代表一个特征维度。AI 可以把一段文字、一张图片、一段代码转换成这样的向量，语义相似的内容转出来的向量也会很接近。
当你把代码或文档存入向量数据库后，AI 就能快速找到语义相似的内容，即使搜索词和原文不完全一样。
比如，你搜 “用户登录”，它能找到叫 "handleAuth" 的函数，因为它们在语义上是相关的。
随着 AI 的爆发，市面上涌现了非常多支持向量存储的数据库：

嵌入 Embedding

嵌入是把文本、代码等内容转换成数字向量的过程。这些向量能够捕捉内容的语义信息。
在向量空间中，语义相似的内容会靠得更近。这就是为什么向量数据库能进行语义搜索的原理。
你不需要深入理解嵌入的技术细节，只需要知道它是 RAG 和代码语义搜索的基础技术就好

AI 输出相关

AI 幻觉

AI 幻觉（Hallucination）是指 AI 输出了不符合事实的内容，可能是编造了不存在的 API、给出了错误的函数用法、推荐了根本不存在的库，甚至胡编乱造一些看起来很合理但完全错误的信息。
这是大语言模型的固有问题，因为它们是基于概率生成内容的，有时会 “脑补” 不存在的东西。
在 AI 编程时，我们可以通过以下方法尽量减少幻觉带来的影响：

要求 AI 提供文档链接验证
自己查官方文档确认
换个模型试试
开新对话重新描述问题
利用 Context7 等获取到最新技术文档的 MCP 扩展

对于做 AI 应用开发的程序员来说，如何消除幻觉是一个需要重点攻克的挑战。前面提到的 RAG（检索增强生成）技术就是目前最主流的解决方案之一，通过让 AI 先检索真实数据再回答，大幅降低幻觉的概率。

温度

温度（Temperature）是控制 AI 输出随机性的参数，取值一般在 0 ~ 2 之间（不同大模型和 AI 编程工具的设置范围可能会有区别）

温度低（如 0.1）：输出更确定、更保守，适合写代码
温度高（如 1.0）：输出更随机、更有创意，适合头脑风暴

在编程场景中，一般使用较低的温度，让 AI 生成更稳定、更可预测的代码。而在需要 AI 发挥创意的场景（比如起名字、写文案、头脑风暴产品方案），可以适当调高温度，让 AI 给出更多样化的建议。

流式输出

流式输出（Streaming）是指 AI 一边生成内容，一边实时显示给用户，而不是等全部生成完再显示

这就像看直播而不是看录播，你能实时看到 AI 的输出过程和生成的内容，如果发现方向不对，可以及时中断，避免浪费 Token

大多数 AI 编程工具都支持流式输出，让交互体验更流畅，包括我做的项目，AI相关的输出，都采用流式输出，体验感更好

在技术实现上，流式输出一般基于 SSE（Server-Sent Events，服务器推送事件）技术，服务端通过持续推送数据片段给客户端，做到实时展示

开发工具概念

IDE 集成开发环境

IDE（Integrated Development Environment 集成开发环境）是程序员用来写代码的综合软件，一般包含代码编辑器、调试器、终端、插件扩展市场等。
VS Code 是目前最流行的轻量级 IDE，由微软开发并开源，Cursor 和 Windsurf 都是基于 VS Code 开发的 AI 代码编辑器，继承了 VS Code 的界面风格和功能，同时大幅扩展了 AI 能力。

代码编辑器

代码编辑器是用来编写和修改代码的工具，提供语法高亮、代码补全、错误提示等功能，帮助你更高效地写代码。
常见的代码编辑器有 Sublime Text、Vim 等。区别于 IDE 集成开发环境，它们相对轻量、启动快速，适合快速编辑单个文件；而 IDE 的功能更全面，集成了调试器、终端、版本控制等工具，适合专业开发者和大型项目开发。
在 Vibe Coding 时代，代码编辑器集成了 AI 能力，可以根据你的提示词自动生成代码、解释代码、修复错误。比如早期的 Cursor 虽然功能强大，但它的核心还是一个 AI 增强的代码编辑器。

零代码平台

零代码平台（No-Code Platform）是不需要写代码就能创建应用的平台。与之相近的还有低代码平台（Low-Code Platform），它允许通过少量代码加上可视化拖拽来构建应用，自由度更高一些。
在 AI 时代，像 Bolt.new、Lovable、v0.dev、百度秒哒这样的平台结合了零代码和 AI，你可以用自然语言描述需求，平台自动生成完整可在线访问的应用。
零代码平台特别适合完全没有编程经验的新手，或者想快速做原型的场景。不过缺点也很明显，出了问题不好调试，也很难深度定制，项目做大了容易遇到瓶颈。

代码补全

代码补全（Code Completion）是指 AI 根据你当前的代码上下文，自动预测你接下来要写的内容并提供建议。
当你写代码时，AI 会根据上下文推测你的意图，提供代码片段供你选择。按下 Tab 键就能接受建议，大大提高编码速度。

代码审查

代码审查（Code Review）是检查代码质量、发现问题、提出改进建议的过程。
没有代码审查的项目，Bug 往往要等到上线之后才被发现，修复成本很高。而有了代码审查，很多问题在代码合并之前就能被提前发现和修复。
在传统开发中，代码审查一般由同事或上级来做。在 Vibe Coding 中，你可以让 AI 帮你审查代码，它会指出潜在的 bug、安全问题、性能问题，并提供修改建议。

但要注意，AI 的审查不能完全替代人工审查！特别是对于重要的生产代码。

Debug 调试

调试（Debug）是找到并修复代码中错误的过程。当代码运行结果不符合预期时，你需要调试来定位问题。
调试的常用方法包括：

设置断点，逐步执行代码
查看变量的值
阅读错误信息和堆栈跟踪
添加日志输出

在 AI 编程时，你可以直接把错误信息发给 AI，让它帮你分析原因并提供修复方案，甚至是自主修复。

项目管理概念

MVP 最小可行产品

MVP（Minimum Viable Product 最小可行产品）是指用最少的功能满足核心需求的产品版本，简单来说就是一个 “能跑起来、核心功能能用” 的最简版本。
很多人刚开始做产品的时候会有各种奇思妙想，恨不得一口气把所有功能都做出来，结果花了大量时间在不必要的功能上，越做越复杂，最后觉得太难就直接放弃了，属于是自己把自己吓跑了。而做 MVP 的思路正好相反，先用最少的功能把核心价值跑通，快速验证想法是否可行，拿到用户反馈后再逐步迭代。这是我在B站上的一个视频看到的，做产品的时候先把基本的功能写完，能上架才是最重要的，后续再根据用户的反馈进行持续的迭代，根据用户的需求去发展，而不是自己写了一堆自认为很好的功能，结果根本不符合用户的需求

比如做一个记账 APP，MVP 版本可能只有记录支出、查看列表两个功能，其他高级功能以后再加

迭代开发

迭代开发是把大项目分成多个小周期，每个周期完成一部分功能的开发方法。
每个迭代周期包括：计划 => 开发 => 测试 => 发布 => 反馈 => 改进。
这种方法特别适合 Vibe Coding，因为你可以让 AI 先实现核心功能，测试没问题后再逐步添加新功能。

重构

重构（Refactoring）是在不改变功能的前提下，改进代码结构和质量的过程。
重构的目的是让代码更清晰、更易维护、更高效。常见的重构包括：

提取重复代码为函数
改进变量和函数命名
简化复杂的逻辑
拆分过长的文件

在 Vibe Coding 中，你可以让 AI 帮你重构代码，但要小步进行，每次重构后都要测试。

值得注意的是，如果你只是用 AI 快速做个小工具，代码能跑就行，没必要花时间重构。但如果是长期维护的企业级项目，代码质量直接决定了后续迭代的效率和稳定性，定期重构就非常有必要了

版本控制

版本控制是记录代码变更历史的系统，让你能追踪每次修改、对比不同版本、回退到之前的状态。
Git 是最流行的版本控制工具，注意别把它和 GitHub 搞混了，Git 是在你电脑上运行的工具，GitHub 是在线的代码托管平台，用来存放和分享你用 Git 管理的代码。
在 Vibe Coding 中，版本控制特别重要。因为 AI 可能会生成有问题的代码，有了版本控制，你随时可以回退到之前正常的版本

我在实战中，AI有时候生成了有问题的代码，同时产生了许多新的bug，我直接让AI撤销本次修改回到正常的版本的话，有时候AI记忆混导致无法正常恢复，会越改越乱，此时版本控制就显得特别重要

部署

部署（Deployment）是指把开发好的应用发布到服务器上，让用户能够访问并使用。
最原始的部署方式是自己登录服务器，把代码文件打包上传后手动运行，又麻烦又容易出错。好在现在有很多自动化的部署平台，傻瓜式操作，点几下就能部署项目，常用的有：

Vercel：适合前端和全栈应用
Netlify：适合静态网站和前端应用
Railway、Render：适合后端服务

很多零代码平台（如 Bolt.new）都支持一键部署，点个按钮就能上线

此外，还可以利用 MCP 来实现更智能的部署。比如通过 EdgeOne Pages MCP，你只需要跟 AI 对话，AI 就能帮你自动完成网站的打包和部署，连部署平台都不用自己登录

前端

前端（Frontend）是用户能直接看到和交互的部分，包括网页界面、按钮、表单、动画等。说得粗暴一点，你在浏览器里看到的一切，都是前端！
前端技术栈通常包括：

HTML：页面结构
CSS：样式和布局
JavaScript：交互逻辑
React/Vue/Next.js：现代前端框架

在 Vibe Coding 中，前端是 AI 最擅长生成的部分，因为效果可以直接看到，方便验证和调整。你还可以利用 Agent Skills 和精心编写的提示词来美化 AI 生成的前端页面，去掉那股子 AI 味儿

后端

后端（Backend）是用户看不到的部分，负责处理业务逻辑、数据存储、用户认证等。
比如你在电商网站上点击 “下单” 按钮，前端把你的订单信息发给后端，后端负责校验库存、计算价格、扣款、生成订单，然后把结果返回给前端展示。
后端技术栈通常包括：

Node.js/Python/Java：编程语言
Express/FastAPI/Spring：Web 框架
MySQL/PostgreSQL/MongoDB：数据库

后端比前端更复杂，需要考虑安全性、性能、数据一致性等问题。因此 AI 生成的后端代码需要更仔细地审查。

全栈

全栈（Full-stack）是指同时包含前端和后端的完整应用。全栈开发者是能同时处理前端和后端工作的程序员。
在 Vibe Coding 中，像 Cursor、Bolt.new 这样的 AI 编程工具可以一次性生成全栈应用，前后端代码都帮你写好。

API

API（Application Programming Interface）是不同程序之间通信的接口。
你可以把 API 理解成餐厅的菜单。菜单告诉你有什么菜可以点，怎么点，点了之后会得到什么。你不需要知道厨房怎么做菜，只需要按菜单点餐。
在 Web 开发中，前端通过 API 和后端通信，获取数据或提交操作。

数据库

数据库是存储和管理数据的系统。应用中的用户信息、内容、设置等都存在数据库里。
常见的数据库类型有：

关系型数据库（MySQL、PostgreSQL）：数据以表格形式存储
文档数据库（MongoDB）：数据以 JSON 文档形式存储
键值数据库（Redis）：适合缓存和快速查找

在 Vibe Coding 中，你可以用 Supabase、Firebase 等现成的云数据库服务，不用自己搭建和管理数据库。

BaaS 后端即服务

BaaS（Backend as a Service 后端即服务）是提供现成后端功能的云服务，包括数据库、用户认证、文件存储等。
以前没有 BaaS 的时候，你得自己买服务器、装数据库、写后端接口、处理各种运维问题，光是搭环境就得折腾好久。而现在使用 BaaS，这些都是现成的，你不需要自己写后端代码和管理服务器，注册个账号就能直接用，能大大加快开发速度，特别适合 Vibe Coding 的场景。
常用的 BaaS 服务有：

Supabase：开源的 Firebase 替代品
Firebase：Google 的 BaaS 平台
PlanetScale：托管的 MySQL 服务

端口冲突引发的服务无限重启

Sat, 04 Apr 2026 00:00:00 GMT

端口冲突引发的服务无限重启

今天在服务器上部署智慧教育项目后端服务时，发现CPU占用异常飙升，初步检查发现3001端口有服务陷入无限重启循环。经过排查，发现是旧服务进程没有完全清理干净，导致新部署的服务无法绑定端口，PM2不断尝试重启形成了死循环。本文将详细记录这次问题的发现、排查和解决过程。

一.问题现象

服务器宕机 ：在部署项目后端服务时，前端页面原本能打开过一会突然又挂了
CPU占用异常：CPU占用率飙升到95%并且居高不下

二.发现问题

使用 top 命令查看系统资源时，发现一个Node.js进程占用95%的CPU
检查3001端口（后端服务端口）时发现异常
查看PM2服务状态显示重启次数高达6991次
服务日志中不断重复出现端口被占用的错误

三.问题根源分析

问题的根本原因是端口冲突：

旧进程残留：之前的 smart-education-backend 服务被删除后，其进程（PID 23372）没有完全终止
端口占用：旧进程仍然占用着3001端口
PM2无限重启：新部署的服务通过PM2管理，尝试绑定3001端口失败
死循环形成：PM2检测到服务启动失败，自动重启，但每次重启都因端口冲突失败，形成无限重启循环

四.详细排查步骤

1.检查端口占用情况

netstat -tulpn | grep :3001

输出结果：

tcp6 0 0 :::3001 :::\* LISTEN 23372/node

发现3001端口被PID 23372的Node进程占用。

2.查看CPU占用最高的进程

ps aux --sort=-%cpu | head -20

关键发现：

PID 23372：占用0.1% CPU（旧进程）
PID 115121：占用95.0% CPU（PM2不断重启的新进程）

3.查看进程详细信息

lsof -i :3001

输出：

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
MainThrea 23372 root 21u IPv6 142407 0t0 TCP \*:3001 (LISTEN)

确认PID 23372确实在监听3001端口。

4.检查PM2服务状态

pm2 list
pm2 show smart-education-backend

关键信息：

服务名称：smart-education-backend
重启次数：6991次
运行时间：1秒（刚启动就崩溃）
状态：online（但实际上无法正常工作）

5.查看服务日志

pm2 logs smart-education-backend --lines 50

错误日志关键内容：

Error: listen EADDRINUSE: address already in use :::3001
    at Server.setupListenHandle [as _listen2] (node:net:1948:16)
    at listenInCluster (node:net:2005:12)
    at Server.listen (node:net:2110:7)

日志明确显示端口3001已被占用。

五.问题原因总结

| 问题环节 | 具体原因 | 影响 | | ---------------- | ------------------------------------------- | ---------- | | 旧服务清理不彻底 | 删除服务时只停止了PM2管理，没有终止实际进程 | 端口被占用 | | 部署流程不规范 | 新部署前没有检查端口占用情况 | 直接冲突 | | PM2配置问题 | 重启策略过于激进，没有设置合理的重启间隔 | 无限循环 |

六.解决方案

第一步：终止占用端口的旧进程

kill -9 23372

第二步：验证端口已释放

netstat -tulpn | grep :3001
# 没有输出，表示端口已释放

第三步：重启PM2服务

pm2 restart smart-education-backend

第四步：验证服务正常运行

pm2 list
# 查看重启次数是否重置，状态是否稳定

netstat -tulpn | grep :3001
# 确认新进程正常监听端口

ps aux --sort=-%cpu | head -10
# 查看CPU占用是否恢复正常

七.经验教训

服务清理要彻底
- 停止服务后要检查进程是否真正终止
- 使用 ps aux | grep <服务名> 确认没有残留进程
部署前做好检查
- 检查目标端口是否被占用
- 检查相关进程是否完全停止
合理配置进程管理工具
- PM2的重启策略要设置合理限制
- 添加重启延迟避免无限循环
- 设置最大重启次数限制
加强监控和告警
- 监控服务的重启次数
- 设置CPU占用率告警
- 定期检查服务日志

八.常用命令速查

| 操作 | 命令 | 说明 | | ------------ | ----------------------------------- | ------------------------------ | | 检查端口占用 | netstat -tulpn \| grep :<端口> | 查看指定端口被哪个进程占用 | | 查看进程信息 | lsof -i :<端口> | 查看占用端口的进程详细信息 | | 终止进程 | kill -9 <PID> | 强制终止指定进程 | | 查看CPU占用 | ps aux --sort=-%cpu \| head -20 | 查看CPU占用最高的20个进程 | | PM2服务列表 | pm2 list | 查看PM2管理的所有服务 | | PM2服务详情 | pm2 show <app-name> | 查看指定服务的详细信息 | | PM2服务日志 | pm2 logs <app-name> --lines 50 | 查看服务最近50行日志 | | 重启PM2服务 | pm2 restart <app-name> | 重启指定服务 | | 检查服务健康 | curl http://localhost:3001/health | 检查服务是否正常响应 | | 清理占用端口 | lsof -ti :<端口> \| xargs kill -9 | 一键清理占用指定端口的所有进程 |

通过Cloudflare加速个人网站

Tue, 31 Mar 2026 00:00:00 GMT

通过Cloudflare加速个人网站

我的博客搭建完成后，发现加载速度很慢，于是在网上搜索了一下教程，看到几乎都是用Cloudflare来进行免费加速，但有个问题，教程大多数为2024年的，没有新教程了，Cloudflare页面以及功能发生了很大的变化，不过好在琢磨了一下之后，也是成功使用Cloudflare提供的免费CDN来加速我的个人博客了

一.基础知识

1.什么是 Cloudflare？

Cloudflare 是一家提供内容分发网络（CDN）、DDoS 防护、SSL/TLS 加密等服务的公司。它通过全球分布的服务器网络，将你的网站内容缓存到离用户更近的位置，从而加速访问。

Cloudflare 的主要优势：

🚀 全球加速：通过 200+ 个数据中心加速网站访问
🛡️ 安全防护：DDoS 攻击防护、Web 应用防火墙
🔒 SSL/TLS 加密：免费 SSL 证书，自动 HTTPS
📊 分析统计：详细的流量分析和安全报告
💰 免费计划：个人网站完全够用
🌐 中文界面：支持中文控制面板

2.什么是 CDN？

CDN（Content Delivery Network，内容分发网络）是一个由多个服务器组成的网络，这些服务器分布在全球各地。当用户访问你的网站时，CDN 会自动选择离用户最近的服务器来提供内容，从而：

减少延迟：缩短数据传输距离
提高速度：更快加载网页内容
降低负载：减轻源服务器压力
增强可用性：即使某个服务器宕机，其他服务器仍可提供服务

二.详细配置步骤

访问 Cloudflare 官网，注册 Cloudflare 账号
注册完成后登录进入首页，在下方域中点击添加，输入你的域名点击下一步，选择Free计划之后确定

然后划到最底部，查看Cloudflare分配的DNS服务器信息，通常类似：lily.ns.cloudflare.com 和 moe.ns.cloudflare.com，然后到域名服务商的控制台更改DNS服务器信息
以腾讯云为例，进入域名管理页面后，点击需要加速的域名右侧的更多点击修改DNS服务器

弹出的页面选择“使用非腾讯云 DNS”，将第3步中获取到的信息填写在下面两个框框中然后点击提交即可，等待一会会就可以生效
最后回到cloudflare中你的这个域名，进入DNS解析，然后按照vercel中提供的信息进行解析即可，最后记得开启代理（代理状态栏下显示橙色云朵已代理）

三.优化配置建议

1.SSL/TLS 设置

进入 "SSL/TLS" → "概述"
将加密模式设置为 完全（严格）
这样 Cloudflare 和你的服务器之间也会加密，提高安全性

2. 缓存配置

进入 "缓存" → "配置"
Always Online：启用（即使源服务器宕机，访问者也可以看到临时错误提示页面）

四.效果对比

加速前：

全球访问速度不一致
国内用户访问慢
服务器直接暴露
无 DDoS 防护

加速后：

✅ 全球访问速度提升 30-50%
✅ 国内用户访问显著改善
✅ 服务器 IP 隐藏，增强安全
✅ 免费 DDoS 防护
✅ 自动 HTTPS

云服务器手动部署OpenClaw指南

Wed, 25 Mar 2026 00:00:00 GMT

云服务器手动部署OpenClaw指南

写在前面：我之前手动部署的openclaw有两个问题。第一是在root用户下直接部署，一开始我是觉得这样最大权限，龙虾可以做的东西多一点，但是到了后来我发现很少情况需要用到root权限；第二是我允许通过公网访问，是因为我想浏览器也可以操作，但是实际运用起来发现，对接了通讯渠道之后再也用不到Web ui了，所以为了安全考虑，重新部署了我的”龙虾“，于是做了这个笔记，方便日后回顾和帮助同样想手动部署的人

一.概念解释

1.什么是 Root 用户？

root 是 Linux 系统的超级管理员，拥有最高权限。用 root 运行程序不安全，万一被攻击，攻击者就能控制整台服务器。

2.为什么要用专用用户？

把 OpenClaw 装在一个专门的"抽屉"里运行：

OpenClaw 只能访问自己的文件
不会影响系统其他部分
更安全，即使被攻击也有限制

3.什么是 systemd

systemd 是 Linux 系统的"自动管家"，可以：

开机自动启动程序
程序崩溃自动重启
统一管理所有服务

二.登录 VPS

使用MobaXterm（Windows 推荐）

下载 MobaXterm
点击左上角 Session → SSH

Remote host：你的 VPS IP地址

Specify username：填 root
点击 OK，输入密码

三.确认工作

1.确认你的系统

连接服务器后，执行：

cat /etc/os-release

# 应该看到 `Ubuntu` 或 `Debian` 字样

2.确认你是 Root

执行以下命令，输出必须是 root

whoami

如果不是，执行下面命令输入密码就会切换到root

sudo -i

四.创建专用用户

1.执行创建用户命令

在 root 用户下执行：

useradd -r -s /usr/sbin/nologin -m -d /opt/openclaw openclaw

| 命令部分 | 含义 | 说明 | | ---------------------- | -------------- | --------------------------------- | | useradd | 创建新用户 | Linux 添加用户的命令 | | -r | 系统账户 | 创建系统用户，不占用户编号 | | -s /usr/sbin/nologin | 禁止登录 | 用户不能 SSH 登录，但程序可以运行 | | -m | 创建 home 目录 | 自动创建用户的主目录 | | -d /opt/openclaw | 指定 home 目录 | 用户的主目录放在这里 | | openclaw | 用户名 | 给这个用户起个名字 |

2.设置目录权限

在 root 用户下执行：

chown -R openclaw:openclaw /opt/openclaw

| 命令部分 | 含义 | | ------------------- | ---------------------------- | | chown | 改变文件/目录的所有者 | | -R | 递归，即包含所有子目录和文件 | | openclaw:openclaw | 用户名:用户组名 | | /opt/openclaw | 要修改权限的目录 |

意思是：把 /opt/openclaw 这个目录以及里面的所有东西都给 openclaw 用户。

3.验证用户创建成功

在 root 用户下执行：

id openclaw

成功的输出类似这样：

uid=998(openclaw) gid=998(openclaw) groups=998(openclaw)

# 能看到 uid、gid、groups 就说明用户创建成功了

五.安装 Node.js

1.安装 Node.js 24

在 root 用户下执行：

第一步：安装 NodeSource 仓库

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -

| 命令部分 | 含义 | | --------------------------------------- | --------------------------- | | curl | 下载文件的命令 | | -fsSL | 安静模式，失败跟随重定向 | | https://deb.nodesource.com/setup_24.x | NodeSource 官方安装脚本地址 | | sudo -E bash - | 用 root 权限执行下载的脚本 |

第二步：安装 Node.js

apt-get install -y nodejs

| 命令部分 | 含义 | | ----------------- | -------------------- | | apt-get install | apt 包管理器安装命令 | | -y | 自动确认，不再询问 | | nodejs | 要安装的包名 |

2.验证安装成功

在 root 用户下执行：

node --version
npm --version

# 成功的输出：

v24.0.0
10.9.0

六.安装 OpenClaw

1.执行官方安装脚本

在 root 用户下执行：

sudo -u openclaw bash -c 'curl -fsSL https://openclaw.ai/install.sh | bash'

| 命令部分 | 含义 | | -------------------------------- | ---------------------------------- | | sudo -u openclaw | 以 openclaw 用户身份执行后面的命令 | | bash -c '...' | 执行引号里的 bash 命令 | | curl -fsSL | 下载文件 | | https://openclaw.ai/install.sh | OpenClaw 官方安装脚本 | | \| bash | 把下载的内容作为脚本执行 |

2.为什么要加 sudo -u openclaw？

因为 OpenClaw 的配置文件和程序要装在 /opt/openclaw 目录里，这个目录属于 openclaw 用户。所以要用 openclaw 的身份来安装，这样所有文件都自动归 openclaw 用户。

3.等待安装完成

安装过程大约需要 3-5 分钟，看到程序开始运行安装向导就行，

向导选择可以点击查看教程 Gateway bind部分保持默认就行

4.找到 OpenClaw 安装位置

安装脚本会自动把 OpenClaw 装到 openclaw 用户的目录下。找到它：

find /opt/openclaw -name "openclaw" 2>/dev/null

会输出类似：

/opt/openclaw/.npm-global/bin/openclaw
/opt/openclaw/.npm-global/lib/node_modules/openclaw

这就是 OpenClaw 命令的实际位置

创建命令快捷方式

因为实际路径很长，给它创建一个短名字的快捷方式：

ln -s /opt/openclaw/.npm-global/bin/openclaw /usr/local/bin/openclaw

| 命令部分 | 含义 | | ---------------------------------------- | ------------------------ | | ln -s | 创建软链接（快捷方式） | | /opt/openclaw/.npm-global/bin/openclaw | 实际的 openclaw 程序位置 | | /usr/local/bin/openclaw | 快捷方式放在哪里 |

⚠️ 为什么这一步必不可少

安装脚本把 OpenClaw 装到了 openclaw 用户的 npm 全局目录里：

/opt/openclaw/.npm-global/bin/openclaw

这个路径不在系统的 PATH 环境变量中，所以 shell 直接打 openclaw 会报 command not found

在执行这一步之前，如果想运行 openclaw 命令，必须用完整路径：

/opt/openclaw/.npm-global/bin/openclaw plugins install @tencent-connect/openclaw-qqbot@latest

创建快捷方式后，相当于在 /usr/local/bin/openclaw 放了一个指向真实程序的链接，而 /usr/local/bin 是在 PATH 里的，所以现在直接打 openclaw 就能找到命令了。

本质就是：npm 把程序装到了一个不在 PATH 的自定义路径里，软链接这一步就是帮命令链接到系统 PATH 目录，让全系统都能直接调用。

验证安装成功

openclaw --version

# 显示版本号即为成功

七.配置环境变量

1.什么是环境变量？

环境变量就像"程序的环境设置"，告诉程序：

配置文件在哪里
状态文件在哪里
工作目录在哪里

2.官方推荐的环境变量

OpenClaw 官方文档推荐在非 root 部署时设置以下环境变量：

| 变量名 | 作用 | 我们的设置 | | ---------------------- | ---------------------------- | --------------------------------------- | | OPENCLAW_HOME | 程序的主目录，所有路径的基准 | /opt/openclaw | | OPENCLAW_STATE_DIR | 状态目录，存配置和会话 | /opt/openclaw/.openclaw | | OPENCLAW_CONFIG_PATH | 配置文件路径 | /opt/openclaw/.openclaw/openclaw.json | | NODE_COMPILE_CACHE | Node.js 编译缓存，加速启动 | /var/tmp/openclaw-compile-cache | | OPENCLAW_NO_RESPAWN | 避免重复启动开销 | 1 |

3.创建环境变量文件

在 root 用户下执行：

第一步：创建目录

sudo -u openclaw mkdir -p /opt/openclaw/.openclaw

| 命令部分 | 含义 | | ------------------------- | ---------------------------- | | sudo -u openclaw | 以 openclaw 用户执行 | | mkdir -p | 创建目录（如果已存在不报错） | | /opt/openclaw/.openclaw | 要创建的目录路径 |

第二步：创建并编辑环境变量文件

sudo -u openclaw nano /opt/openclaw/.openclaw/.env

第三步：输入以下内容

把下面 5 行内容复制粘贴进去，完事后Ctrl+O保存内容**（注意是字母O不是数字0）**，再按Enter确认保存，最后Ctrl+X退出编辑

OPENCLAW_HOME=/opt/openclaw
OPENCLAW_STATE_DIR=/opt/openclaw/.openclaw
OPENCLAW_CONFIG_PATH=/opt/openclaw/.openclaw/openclaw.json
NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
OPENCLAW_NO_RESPAWN=1

4.设置缓存目录权限

mkdir -p /var/tmp/openclaw-compile-cache
chown openclaw:openclaw /var/tmp/openclaw-compile-cache

八.接入QQ机器人

前往QQ开放平台（openclaw）注册并创建自己的机器人

1.安装插件

sudo -u openclaw bash -c "cd /opt/openclaw && openclaw plugins install @tencent-connect/openclaw-qqbot@latest"

| 命令部分 | 含义 | | ---------------------------------------- | ------------------------------------------------ | | sudo -u openclaw | 以 openclaw 用户身份执行后面的命令 | | bash -c "..." | 打开一个新的 bash shell，执行引号里的命令 | | cd /opt/openclaw | 切换到 openclaw 安装目录 | | openclaw plugins install | openclaw 的插件安装命令 | | @tencent-connect/openclaw-qqbot@latest | QQ Bot 插件的 npm 包名，@latest 表示安装最新版本 |

2.添加 QQ 机器人账号

sudo -u openclaw bash -c "cd /opt/openclaw && openclaw channels add --channel qqbot --token '你的AppID:你的AppSecret'"

| 命令部分 | 含义 | | -------------------------------- | ----------------------------------------------------- | | sudo -u openclaw bash -c "..." | 同上，以 openclaw 用户执行命令 | | cd /opt/openclaw | 切换到 openclaw 目录 | | openclaw channels add | 添加频道账号的命令 | | --channel qqbot | 指定频道类型为 qqbot | | --token 'AppID:AppSecret' | QQ 机器人的凭证，格式是 AppID:AppSecret，用冒号分隔 |

3.重启服务

sudo systemctl restart openclaw-gateway

| 命令部分 | 含义 | | ------------------ | -------------------------------------------------- | | sudo | 以 root 身份执行（systemd 服务管理需要 root 权限） | | systemctl | systemd 服务管理工具 | | restart | 重启服务 | | openclaw-gateway | openclaw 网关服务的名称 |

4.验证网关状态

ss -tlnp | grep 18789

# 如果显示 LISTEN，说明正在运行，即成功

九.创建开机自启服务

1.第一步：检测你的环境支持哪种方式

在 root 用户下执行：

systemctl list-units --type=service --state=running 2>/dev/null | head -5

如果有输出（列出了一些服务名）→ systemd 可用，用 方案 A
如果报错或无输出（如 Failed to connect to bus）→ systemd 不可用，用 方案 B

方案 A：systemd 服务（推荐，适合完整 Linux 系统）

1.什么是 systemd 服务？

systemd 是 Linux 的"服务管理器"。创建服务后，OpenClaw 可以：

开机自动启动
崩溃后自动重启
不需要人工干预

2.创建服务配置文件

在 root 用户下执行：

nano /etc/systemd/system/openclaw-gateway.service

3.粘贴以下内容

把下面的内容完整复制，粘贴进去

[Unit]
Description=OpenClaw Gateway
Documentation=https://docs.openclaw.ai
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/opt/openclaw
ExecStart=/opt/openclaw/.npm-global/bin/openclaw gateway --port 18789
Restart=always
RestartSec=5
TimeoutStartSec=90

Environment="OPENCLAW_HOME=/opt/openclaw"
Environment="OPENCLAW_STATE_DIR=/opt/openclaw/.openclaw"
Environment="OPENCLAW_CONFIG_PATH=/opt/openclaw/.openclaw/openclaw.json"
Environment="NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache"
Environment="OPENCLAW_NO_RESPAWN=1"

NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=read-only
PrivateTmp=true
ReadWritePaths=/opt/openclaw

[Install]
WantedBy=multi-user.target

配置解释

| 配置项 | 含义 | | -------------------------------- | -------------------------- | | Description | 服务的描述名称 | | After=network-online.target | 等网络准备好再启动 | | User=openclaw | 以 openclaw 用户身份运行 | | Group=openclaw | 以 openclaw 用户组身份运行 | | WorkingDirectory=/opt/openclaw | 工作目录 | | ExecStart=... | 启动时执行的命令 | | Restart=always | 崩溃后自动重启 | | RestartSec=5 | 崩溃后等 5 秒再重启 | | TimeoutStartSec=90 | 启动超时 90 秒 | | Environment="..." | 环境变量设置 | | NoNewPrivileges=true | 不提升权限（安全） | | ProtectSystem=strict | 限制访问系统目录（安全） | | ProtectHome=read-only | 禁止访问 home 目录（安全） | | PrivateTmp=true | 私有临时目录（安全） | | ReadWritePaths=/opt/openclaw | 允许读写的目录 | | WantedBy=multi-user.target | 开机在多用户模式下启动 |

4.重新加载 systemd

在 root 用户下执行：

systemctl daemon-reload

5.设置开机自启

在 root 用户下执行：

systemctl enable openclaw-gateway.service

6.立即启动服务

在 root 用户下执行：

systemctl start openclaw-gateway.service

7.验证是否成功

在 root 用户下执行：

systemctl status openclaw-gateway.service

# 成功的标志：

- 看到 `Active: active (running)` ✅
- 不是 `inactive` 或 `failed`

方案 B：Crontab 开机任务

1.编写启动脚本

在 root 用户下执行：

sudo -u openclaw tee /opt/openclaw/start-gateway.sh > /dev/null <<'EOF'
#!/bin/bash
source /opt/openclaw/.openclaw/.env
exec /opt/openclaw/.npm-global/bin/openclaw gateway --port 18789
EOF
chmod +x /opt/openclaw/start-gateway.sh
chown openclaw:openclaw /opt/openclaw/start-gateway.sh

2.添加开机任务

在 root 用户下执行：

crontab -e

# 如果是第一次用 crontab，选 `1` 用 nano 编辑

在文件最后添加这一行

@reboot /opt/openclaw/start-gateway.sh >> /var/log/openclaw-gateway.log 2>&1

按 Ctrl + O，回车保存，Ctrl + X 退出

3.立即启动 Gateway

在 root 用户下执行：

/opt/openclaw/start-gateway.sh &

4.查看是否启动成功

sleep 3 && sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw gateway status'

看到 Listening: 127.0.0.1:18789 说明成功。

十.常用命令速查

| 操作 | 方案 A（systemd） | 方案 B（crontab） | | ------------ | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | 查看状态 | systemctl status openclaw-gateway.service | sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw gateway status' | | 启动 | systemctl start openclaw-gateway.service | /opt/openclaw/start-gateway.sh & | | 停止 | systemctl stop openclaw-gateway.service | pkill -f "openclaw gateway" | | 重启 | systemctl restart openclaw-gateway.service | pkill -f "openclaw gateway" && /opt/openclaw/start-gateway.sh & | | 查看日志 | journalctl -u openclaw-gateway.service -n 50 | tail -50 /var/log/openclaw-gateway.log | | 实时日志 | journalctl -u openclaw-gateway.service -f | tail -f /var/log/openclaw-gateway.log | | Gateway 状态 | sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw gateway status' | 同左 | | 健康检查 | sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw health' | 同左 | | 查看版本 | openclaw --version | 同左 | | 初始化向导 | sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw onboard' | 同左 | | 创建备份 | sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw backup create' | 同左 | | 健康诊断 | sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw doctor' | 同左 |

十一.常见问题

Q1: 安装脚本报 `command not found`

说明 OpenClaw 安装到了非标准路径。找到它：

find /opt/openclaw -name "openclaw" 2>/dev/null

然后创建快捷方式：

ln -s /opt/openclaw/.npm-global/bin/openclaw /usr/local/bin/openclaw

Q2: 服务启动失败？

先查看 Gateway 状态：

sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw gateway status'

方案 A 用户查看 systemd 日志：

journalctl -u openclaw-gateway.service -n 50

方案 B 用户查看日志：

tail -50 /var/log/openclaw-gateway.log

Q3: 怎么完全卸载？

# 1. 停止服务

systemctl stop openclaw-gateway.service 2>/dev/null || pkill -f "openclaw gateway"
systemctl disable openclaw-gateway.service 2>/dev/null

# 2. 删除 systemd 服务文件（如有）

rm /etc/systemd/system/openclaw-gateway.service 2>/dev/null
systemctl daemon-reload 2>/dev/null

# 3. 删除 crontab 开机任务（如有）

crontab -l 2>/dev/null | grep -v "start-gateway.sh" | crontab - 2>/dev/null
rm /opt/openclaw/start-gateway.sh 2>/dev/null

# 4. 卸载 OpenClaw（保留配置和会话）

sudo -u openclaw bash -c 'source /opt/openclaw/.openclaw/.env && openclaw uninstall' 2>/dev/null

# 5. 删除用户和目录（谨慎，会删除所有数据！）

userdel openclaw 2>/dev/null
rm -rf /opt/openclaw
rm -rf /var/tmp/openclaw-compile-cache

为网站配置SSL证书

Tue, 24 Mar 2026 00:00:00 GMT

为网站配置SSL证书

在同一个服务器上部署两个项目时，宝塔面板一键申请SSL证书的时候，会因为重定向问题导致验证失败，所以我学习了手动部署SSL证书的方法，做了这个笔记，以docker部署的项目为例（本文的Nginx是在主机上，监听的是主机端口），通过本文，可以确保申请的证书独立对应域名，让Nginx正确处理域名分流

一.确定docker映射到宿主机的端口

理解端口映射

127.0.0.1:8088->80/tcp
        ↓       ↓  ↓
   主机端口 →  容器  协议
              端口

含义：访问主机的 8088 端口 => 转发到容器的 80 端口

找到需要代理的端口，终端执行以下命令

docker ps --format "table {{.Names}}\t{{.Ports}}"

找到要对外访问的容器，记下它的主机端口（冒号左边的数字）

二.创建 Nginx 配置文件

假设：

你的域名：yourdomain.com
Docker 容器映射的主机端口：8088

创建配置文件

nano /usr/local/nginx/conf/conf.d/yourdomain.com.conf

粘贴以下内容**（只需要把 yourdomain.com 和 8088 改成实际的值即可）**

server {
    listen 80;
    server_name yourdomain.com;

    location /.well-known/acme-challenge/ {
        root /var/www/acme;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    http2 on;
    server_name yourdomain.com;

    ssl_certificate /usr/local/nginx/conf/ssl/yourdomain.com/fullchain.pem;
    ssl_certificate_key /usr/local/nginx/conf/ssl/yourdomain.com/key.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:!MD5;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    add_header Strict-Transport-Security "max-age=31536000";

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

三.申请 SSL 证书

以 Let's Encrypt 证书为例！Let's Encrypt 是全球最受信赖的免费 CA，浏览器默认信任

mkdir -p /var/www/acme
mkdir -p /usr/local/nginx/conf/ssl/yourdomain.com

申请 Let's Encrypt 证书

/root/.acme.sh/acme.sh --issue -d yourdomain.com -w /var/www/acme --keylength ec-256 --server letsencrypt

参数说明： | 参数 | 含义 | |------|------| | -d yourdomain.com | 要申请证书的域名 | | -w /var/www/acme | HTTP 验证目录（acme.sh 会在这个目录创建验证文件） | | --keylength ec-256 | 使用 ECDSA 256 位加密（更快更安全） | | --server letsencrypt | 指定使用 Let's Encrypt安装证书 |

/root/.acme.sh/acme.sh --install-cert -d yourdomain.com \
  --key-file /usr/local/nginx/conf/ssl/yourdomain.com/key.pem \
  --fullchain-file /usr/local/nginx/conf/ssl/yourdomain.com/fullchain.pem \
  --reloadcmd "nginx -s reload"

四.证书到期更新

Let's Encrypt 的免费证书有效期是 90 天。安装的时候设置了--reloadcmd所以acme.sh 会在证书到期前 30 天自动续期，所以一般情况下不需要手动操作,安装时候就会自动设置定时任务每天检查

确认自动续期已配置

# 终端执行命令

crontab -l | grep acme.sh

# 正常输出，这是每天13点02分自动执行

2 13 \* \* \* "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null

查看证书到期时间

# 查看所有证书

/root/.acme.sh/acme.sh --list

# 查看单个证书详情

/root/.acme.sh/acme.sh --info -d 你的域名

如果没有正确设置到定时任务自动续期，可以手动续期

# 强制续期（忽略是否到期）

/root/.acme.sh/acme.sh --renew -d 你的域名 --force

# 手动续期所有证书

/root/.acme.sh/acme.sh --cron --home "/root/.acme.sh"

五.测试并生效

测试配置

/usr/local/nginx/sbin/nginx -t

看到这些就对了：

nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

重启 Nginx

/usr/local/nginx/sbin/nginx -s reload

六.多个项目如何确保网站不互串

检查现有配置

ls -la /usr/local/nginx/conf/conf.d/

应该看到如下配置文件：

first.top.conf
second.top.conf
third.com.conf

每个配置文件里的关键区别

| 网站 | server_name | proxy_pass | | ---------- | ------------ | ----------------------- | | first.top | first.top | http://127.0.0.1:8317 | | second.top | second.top | http://127.0.0.1:8088 | | third.com | third.com | http://127.0.0.1:8000 |

只要 server_name 不同，Nginx 就会精准匹配，互不干扰！

所以同一个服务器部署多个网站对应多个域名时，只需要在创建配置文件时候，正确填写对应的域名即可

# 1. 创建配置（改域名和端口）
nano /usr/local/nginx/conf/conf.d/实际域名.conf

# 2. 申请证书（改域名，必须加 --server letsencrypt）
/root/.acme.sh/acme.sh --issue -d 实际域名 -w /var/www/acme --keylength ec-256 --server letsencrypt

# 3. 安装证书（改域名）
/root/.acme.sh/acme.sh --install-cert -d 实际域名 \
  --key-file /usr/local/nginx/conf/ssl/实际域名/key.pem \
  --fullchain-file /usr/local/nginx/conf/ssl/实际域名/fullchain.pem \
  --reloadcmd "nginx -s reload"

# 4. 测试并重载
/usr/local/nginx/sbin/nginx -t && /usr/local/nginx/sbin/nginx -s reload

七.一键配置脚本

整个流程相对来说不是很复杂不是很麻烦，但为了更加方便，我写了一键部署脚本，前提是nginx是通过编译安装的，当然里面也包含了一键安装nginx的脚本，目前已经开源，开源地址vps_tools

1.使用方法

# 克隆仓库

git clone https://github.com/super-mortal/vps_tools.git

# 进入目录

cd vps_tools

# 给脚本添加执行权限

chmod +x ssl_cert.sh

# 运行交互式脚本

./ssl_cert.sh

2.注意事项

# 先确认 443 端口真的是 Nginx 在监听
ss -tulnp | grep 443
# 查看 ufw 状态（Debian/Ubuntu）
ufw status
# 放行443端口（TCP协议，HTTPS标准端口）
ufw allow 443/tcp
# 重载防火墙规则，使配置生效
ufw reload
# 再次验证规则是否添加成功
ufw status

八.常见问题

Q: 申请证书报错 "Can't find directory"

mkdir -p /var/www/acme

Q: 申请证书报错 "Domain is not point to this server"

域名 DNS 还没生效，等几分钟再试。或者检查域名 A 记录是否指向当前服务器 IP。

Q: HTTPS 能访问但显示不安全

检查证书是不是 Let's Encrypt：

openssl x509 -in /usr/local/nginx/conf/ssl/你的域名/fullchain.pem -noout -issuer

应该显示 Issuer: C = US, O = Let's Encrypt

如果不是 Let's Encrypt，可能是其他的证书不受浏览器信任所以还是显示不安全，删除重新申请：

/root/.acme.sh/acme.sh --remove -d 你的域名
/root/.acme.sh/acme.sh --issue -d 你的域名 -w /var/www/acme --keylength ec-256 --server letsencrypt

如果是 Let's Encrypt 的证书但仍然显示不安全，可能是浏览器缓存了旧的证书

1. 清除普通缓存

- 菜单 → 隐私和安全 → 清除浏览数据

- 勾选上述两项，清除

2. 清除HSTS（强制HTTPS策略）

**地址栏输入**

- Chrome： chrome://net-internals/#hsts 

- Edge： edge://net-internals/#hsts 

- 找到 Delete domain security policies

- 输入域名（如 example.com ）→ Delete

3. 清除单个网站HTTPS缓存（精准）

- 打开网站 → 地址栏左侧锁图标 → 网站设置 → 清除数据

理解服务器中的Nginx

Mon, 23 Mar 2026 00:00:00 GMT

理解服务器中的Nginx

一.什么是 Nginx？

打个比喻，你去饭店吃饭，前台问你定的哪个包间，这个前台在服务器上就叫Nginx

| 餐厅前台 | 服务器 Nginx | | ---------------- | -------------------- | | 接待来吃饭的顾客 | 接待访问网站的用户 | | 问顾客订哪个包间 | 根据域名区分请求 | | 带顾客到包间 | 把请求转发给后端程序 | | 把菜端给顾客 | 把处理结果返回给用户 |

二.Nginx 在服务器中起什么作用？

先看看没有 Nginx 会怎样

有 Nginx 之后

用户访问网站
           ┌───────────────────────────┐
           │        服务器              │
           │                           │
           │   ┌─────────────┐         │
           │   │  Nginx      │         │
           │   │  (前台)      │         │
           │   └──────┬──────┘         │
           │          │                │
           │          ↓                │
           │   ┌────────────┐          │
           │   │ 后端程序    │          │
           │   │ (厨师)      │          │
           │   └────────────┘          │   ->返回网页给用户
           └───────────────────────────┘

Nginx 专门负责"接待"，后端程序专门负责"做菜"，各司其职！

更深层次理解Nginx 具体干什么

┌──────────────────────────────────────────┐
│                Nginx 的工作               │
├──────────────────────────────────────────┤
│  1️⃣  接收请求                             │
│      用户访问 → Nginx 先收到               │
│                                          │
│  2️⃣  区分域名                             │
│      first.com → A网站                    │
│      second.com → B网站                   │
│      third.com → C网站                    │
│                                          │
│  3️⃣  反向代理                             │
│      把请求转发给后端程序                   │
│                                          │
│  4️⃣  处理 HTTPS                          │
│      加密解密，证书验证                    │
│                                         │
│  5️⃣  提供静态文件                         │
│      图片、CSS、JS                       │
│                                         │
│  6️⃣  返回结果                            │
│      返回结果给用户                       │
└────────────────────────────── ──────────┘

前台可以同时接待很多客人，Nginx也可以同时处理不同的用户请求

一个前台（Nginx），同时接待多个人：

访客1 ──→ 前台 ──→ A网站
访客2 ──→ 前台 ──→ B网站
访客3 ──→ 前台 ──→ A网站    ->高效处理

三.Nginx配置中的核心概念

什么是server？

server = 一家公司/一个网站

server {
    server_name first.com;
    # 这就是 first.com 这个网站
}

server {
    server_name second.com;
    # 这就是 second.com 这个网站
}

同一个服务器上部署多个不同的服务，分别绑定对应的域名时，这里的server_name就是对应的域名，通过这个配置，Nginx就可以清楚的知道用户需要访问的是哪个服务，比如用户输入的是second.com，Nginx就会去找second.com对应的配置文件对应的服务然后返回给用户，而不会返回first.com域名对应的服务，这就是多域名共用一个服务器（域名分流）

什么是 location？

location = URL 路径/部门

server {
    server_name first.com;

    location / {
        # 处理 first.com/ 的请求
    }

    location /api {
        # 处理 first.com/api 的请求
    }
}

什么是 proxy_pass？

proxy_pass = 转交/外包

location / {
    proxy_pass http://127.0.0.1:3000;
    # 这个请求我不处理了
    # 转交给 http://127.0.0.1:3000
}

四.Nginx在服务器中的目录

/usr/local/nginx/                    ← Nginx 安装目录
    │
    ├── conf/                        ← 配置文件目录
    │   │
    │   ├── nginx.conf               ← 主配置文件（不用改）
    │   │
    │   └── conf.d/                  ← ⭐ 网站配置放这里
    │       │
    │       ├── first.top.conf
    │       └── second.top.conf
    │
    ├── logs/                        ← 日志目录
    │   │
    │   ├── access.log               ← 访问日志（谁来过）
    │   └── error.log                ← 错误日志（出过错）
    │
    └── sbin/                        ← 可执行文件
        │
        └── nginx                    ← 启动命令

/usr/local/nginx/conf/ssl/            ← ⭐ SSL 证书放这里
    │
    ├── first.top/                    ← first.top 网站的证书
    │   │
    │   ├── fullchain.pem             ← 完整证书链
    │   └── key.pem                   ← 私钥
    │
    └── second.top/                   ← second.top 网站的证书
        │
        ├── fullchain.pem
        └── key.pem

快速查看命令

# 查看 Nginx 配置文件位置
ls -la /usr/local/nginx/conf/

# 查看所有网站配置
ls -la /usr/local/nginx/conf/conf.d/

# 查看 SSL 证书
ls -la /usr/local/nginx/conf/ssl/

# 查看日志
tail -f /usr/local/nginx/logs/access.log
tail -f /usr/local/nginx/logs/error.log

# 查看正在运行的 Nginx
ps aux | grep nginx

# 重启 Nginx
/usr/local/nginx/sbin/nginx -s stop
/usr/local/nginx/sbin/nginx

五.一个请求的完整旅程

以docker部署的服务为例，当你访问 https://first.top 时：

第1步：DNS 解析
    你输入 https://first.top
    DNS 服务器说：IP 是 1.2.3.4.55

第2步：连接服务器
    浏览器连接到 1.2.3.4.55:443

第3步：Nginx 接待
    Nginx 收到请求
    看看是哪个域名 → first.top
    找对应的配置 → first.top.conf

第4步：处理 HTTPS
    用 first.top 的 SSL 证书加密通信

第5步：反向代理
    把请求转发到 Docker 容器的 8088 端口

第6步：Docker 容器处理
    容器里的 nginx 再转发
    给 nav-site-nodejs 处理

第7步：返回结果
    网页返回给 Nginx
    Nginx 返回给浏览器
    浏览器显示页面

六.总结

所以在服务器中，Nginx主要负责这些工作（仅本文提到）

域名分流：一个服务器对应多个域名多个网站服务，看域名转发给不同的服务
静态资源处理：直接返回图片、JS、CSS，减轻后端压力
反向代理：把请求转给后端服务（如Java、Node.js），隐藏真实端口
HTTPS加密：配置SSL证书，实现安全访问

关键目录速查

| 用途 | 目录 | | ------------ | --------------------------------------- | | Nginx 主配置 | /usr/local/nginx/conf/nginx.conf | | 网站配置 | /usr/local/nginx/conf/conf.d/***.conf | | SSL 证书 | /usr/local/nginx/conf/ssl/域名/ | | Nginx 日志 | /usr/local/nginx/logs/ | | 启动命令 | /usr/local/nginx/sbin/nginx |

Markdown基础语法

Sat, 21 Mar 2026 00:00:00 GMT

Markdown基础语法

Markdown是一种轻量级标记语言，排版语法简洁，让人们更多地关注内容本身而非排版，Markdown 无处不在。StackOverflow、CSDN、掘金、简书、GitBook、有道云笔记、V2EX、光谷社区等。主流的代码托管平台，如 GitHub、GitLab、BitBucket、Coding、Gitee 等等，都支持 Markdown 语法，很多开源项目的 README、开发文档、帮助文档、Wiki 等都用 Markdown 写作。

一.标题

#和标题之间要加一个空格，最多六级标题

# 一级标题

## 二级标题

二. 换行

在一行末尾添加两个空格或使用 HTML的<br> 标签实现段内换行：

这是第一行  
这是第二行

三. 强调

| 语法 | 效果 | | -------------- | ------------ | | **粗体** | 粗体 | | *斜体* | 斜体 | | ***粗斜体*** | 粗斜体 | | ~~删除线~~ | ~~删除线~~ |

四. 引用块

>和引用内容之间需要加一个空格，可以多行引用和嵌套引用

嵌套引用：

> 外层引用
>
> > 嵌套引用

五. 列表

无序列表

可用 -、*、+ 三种符号，效果相同，一样需要加空格

- 项目一
- 项目二
  - 子项目（缩进2个空格）
    - 更深层（缩进4个空格）

项目一
项目二
- 子项目
  - 更深层

有序列表

输出1.然后按空格

1. 第一项
2. 第二项
3. 第三项
   1. 子列表
   2. 子列表

任务列表

- [x] 已完成
- [ ] 未完成
- [ ] 另一个未完成

[x] 已完成
[ ] 未完成
[ ] 另一个未完成

六. 代码

行内代码

左右两个反引号包裹内容

`console.log('hello')`

代码块

使用三个反引号包裹，并可指定语言：

`javascript
function hello() {
  console.log('Hello!');
}
`

七. 分隔线

使用三个或以上的 -、*、_：

---
---

---

八. 链接

[超级凡人](https://supermortal.cn)

超级凡人

九. 图片

![替代文字](图片URL)

十. 表格

| 表头1  | 表头2 |  表头3 |
| :----- | :---: | -----: |
| 左对齐 | 居中  | 右对齐 |
| 内容1  | 内容2 |  内容3 |

| 表头1 | 表头2 | 表头3 | | :----- | :---: | -----: | | 左对齐 | 居中 | 右对齐 | | 内容1 | 内容2 | 内容3 |

对齐说明：

|:---| 左对齐
|:---:| 居中
|---:| 右对齐

十一. 嵌入视频

YouTube

<iframe width="560" height="315" src="https://www.youtube.com/embed/视频ID" frameborder="0" allowfullscreen></iframe>

Bilibili

<iframe src="//player.bilibili.com/player.html?bvid=BV号&page=1" width="560" height="315" frameborder="0" allowfullscreen></iframe>

快速参考

| 功能 | 语法 | | :----: | :--------------: | | 标题 | # - ###### | | 粗体 | **文字** | | 斜体 | *文字* | | 删除线 | ~~文字~~ | | 链接 | [文字](URL) | | 图片 | ![文字](URL) | | 代码块 | ```语言 ``` | | 引用 | > | | 列表 | - 或 1. | | 分隔线 | --- |

我的第一篇博客

Tue, 17 Mar 2026 00:00:00 GMT

关于我的博客

初衷很简单：一是记录自己的成长轨迹，把学习过程、技术笔记沉淀下来，方便日后回顾复盘；二是在跟着各类实战教程学习时，常常发现步骤不够完整、细节缺失，导致实操中频频踩坑。我希望把自己踩过的坑、解决过的问题，用更细致、更易懂的方式整理出来，不仅督促自己深度学习，也能帮到和我一样在学习路上摸索的人，让知识传递更踏实、更有用

这是我的个人博客历程

2026-03-17： 新博客成立，使用Astro框架astro-theme-pure模板构建

2026-01-28： 博客迁移重构，使用Astro框架Firefly模板重新构建

2025-11-24： 博客正式成立，使用typecho框架的wayxz主题构建

博客更新指令

# 添加所有修改
git add .

# 提交更改
git commit -m "内容"

# 推送到 GitHub
git push