用 Claude Code 帮我填工时,一行命令搞定

每周五下午填工时,真的贼烦。

打开网页,登录,点进去,一个个项目填数字,保存…一套流程下来至少 10 分钟。而且每次都要想"这周这个项目填多少小时合适",还得保证每天 8 小时,每周 40 小时。填错了还得重来。

后来发现 Claude Code 的 MCP Chrome DevTools 服务器可以操控浏览器,就想:能不能让 AI 帮我填?

试了一下,还真行。

现在每周只要在终端输入 /fill-workhours,剩下的全自动。

技术方案

用到了这几个东西:

  • Claude Code: Anthropic 官方 CLI,就是命令行版的 Claude
  • MCP Chrome DevTools Server: 让 AI 能操控浏览器的工具
  • Slash Command: Claude Code 的自定义命令功能

思路很简单:写一个 Slash Command,告诉 Claude “打开工时系统,分析当前状态,按规则填写,保存”。

Claude 会调用 MCP 工具去操作浏览器,就像你在手动操作一样。

配置 MCP Server

在 Claude Code 的配置文件中加几行:

1
2
3
4
5
6
7
8
9
10
11
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "@cline/mcp-server-chrome-devtools@latest"
      ]
    }
  }
}

这会启动一个 MCP 服务器,提供一堆浏览器操作工具(点击、填表单、截图等)。

配置好了就不用管了,每次 Claude Code 启动会自动加载。

写 Slash Command

在项目根目录创建 .claude/commands/fill-workhours.md,这就是自定义命令的配置文件。

完整内容挺长的,核心是告诉 Claude 三件事:

1. 怎么操作浏览器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1. **打开页面并导航**
   - new_page 打开工时系统网址
   - wait_for("我的工时填报") 等页面加载完
   - 点击"我的工时填报"菜单

2. **进入填报页面**
   - wait_for("填报") 等列表加载完
   - 点击"填报"按钮

3. **分析和填写工时**
   - wait_for("工时填报") 等弹窗打开
   - take_snapshot 获取当前工时表状态
   - 分析数据,算出要填的内容

4. **保存**
   - 用 fill_form 批量填写
   - 点"保存"
   - 等 2-3 秒让系统保存
   - 按 ESC 关闭弹窗

2. 工时填写规则

这是业务规则,得写清楚:

1
2
3
4
5
6
7
8
9
10
11
**约束条件:**
- 每天 8 小时(周一到周五)
- 每周 40 小时
- 每个项目每周至少 2 小时
- 每个项目每周最多 10 小时
- 不新增项目,只在已有项目上补

**填写策略:**
1. 先看哪些项目工时是 0,优先给它们分配至少 2 小时
2. 剩下的均匀分配,但每个项目不超过 10 小时
3. 确保每天恰好 8 小时

3. 出问题了咋办

1
2
3
- 找不到元素 → 立即截图分析
- 页面改版了 → 回退到逐步截图模式
- 没登录 → 告诉用户先登录

完整的 Slash Command 配置可以参考初稿,里面写得很详细。

几个优化技巧

最开始我写的版本,每一步都截图确认。结果特别慢:

  • 截图 10 次
  • 执行时间 60 秒
  • Token 消耗 50K

后来优化了一下:

减少截图

优化前: 打开页面 → 截图 → 点菜单 → 截图 → 点按钮 → 截图…

优化后: 打开页面 → wait_for 等关键元素出现 → 直接操作 → 只在必要时截图

为啥?因为截图很贵(Token 消耗大),而且慢。

wait_for 等元素出现就继续,不需要截图确认。

用 wait_for 替代 sleep

别写 sleep 5,写 wait_for("填报", timeout: 10000)。

前者固定等 5 秒,后者元素出现就继续,最多等 10 秒。省时间。

批量操作

别一个个填:

1
2
3
fill(uid1, "2")
fill(uid2, "2")
fill(uid3, "2")

用批量填写:

1
2
3
4
5
fill_form([
  {uid: uid1, value: "2"},
  {uid: uid2, value: "2"},
  {uid: uid3, value: "2"}
])

一次搞定,省工具调用次数。

优化后效果:

  • 截图 2-3 次
  • 执行时间 15 秒
  • Token 消耗 30K

快了 4 倍,省了不少 Token。

MCP 工具速查

这个项目用到的主要工具:

工具 用途 示例
new_page 打开新页面 new_page(url)
wait_for 等待元素出现 wait_for(“填报”, timeout: 10000)
take_snapshot 获取页面文本快照 take_snapshot()
take_screenshot 截取页面图片 take_screenshot()
click 点击元素 click(uid)
fill 填写单个表单 fill(uid, “2”)
fill_form 批量填写表单 fill_form([{uid, value}])
press_key 按键操作 press_key(“Escape”)

take_snapshot 返回的是基于可访问性树的文本内容,不是图片,所以很快。适合分析页面结构。

怎么用

配置完成后,在 Claude Code 终端输入:

1
/fill-workhours

Claude 会自动:

  1. 打开浏览器访问工时系统
  2. 导航到填报页面
  3. 分析当前工时数据
  4. 根据规则填写
  5. 保存

整个过程 15 秒左右,完全不用管。

我现在每周五下午就敲一下这个命令,然后该干嘛干嘛去。

能用在哪些场景

这个方案本质上是"用自然语言描述浏览器操作流程",Claude 负责执行。

所以理论上任何重复的网页操作都能自动化。

我试过的:

  • 批量生成周报(每周一自动生成)
  • 定期检查服务器状态(每小时跑一次)
  • 自动化测试某个功能(发布前跑一遍)

理论上能做的:

  • UI 自动化测试
  • 数据采集(定期抓网页数据)
  • 批量表单填写(批量报名、批量提交)
  • 监控告警(页面有变化就通知)
  • 复杂的 RPA 流程

关键是 Slash Command 要写清楚:

  1. 操作步骤(一步步怎么做)
  2. 业务规则(什么能做,什么不能做)
  3. 异常处理(出问题了咋办)

踩过的坑

1. 页面元素定位不准

如果页面结构复杂,Claude 可能找不到元素。

解决办法:

  • 在 Slash Command 里多给点提示(比如"点击文本为’填报’的按钮")
  • 或者用 CSS 选择器

2. 网络延迟

如果页面加载慢,wait_for 的 timeout 要设长一点。

我设的是 10 秒,对于慢网络可能不够。

3. 登录态失效

如果工时系统需要登录,得先手动登录一次,保持 Cookie。

不然 Claude 打开页面会跳到登录页。

我的做法是:浏览器保持登录状态,每次跑脚本前确认下还没过期。

4. 页面改版

如果工时系统改版了,可能需要调整 Slash Command。

不过一般小改动 Claude 能自己适应,大改版可能得重新写。

为啥值得做

填工时每次 10 分钟,一年 52 周,就是 520 分钟 ≈ 8.7 小时。

花 1 小时写个自动化脚本,一年省 8 小时。这笔账划算。

更重要的是,这个思路可以复用到其他重复劳动上。我后来又写了几个 Slash Command,每个都省不少时间。

而且配置真的简单。不用写 Python 或 JavaScript,纯文本描述流程,Claude 自己理解。维护成本也低,页面小改动基本不用改脚本。

和传统脚本的区别

用 Claude Code 做自动化,和传统的 Selenium/Playwright 脚本比:

优点:

  • 不用写代码: Slash Command 是纯文本描述
  • AI 处理变化: 页面小改动,Claude 可能自己适应
  • 自然语言调试: 出问题了直接看日志,不用调试代码
  • 配置快: 从零到能跑,半小时搞定

缺点:

  • 不如代码稳定: AI 有时会理解偏差,偶尔需要重跑
  • Token 有成本: 虽然不贵(一次大概 0.01 元),但不是完全免费
  • 需要环境: 得装 Claude Code,不能直接丢到服务器上定时跑

所以我的用法是:

  • 偶尔用的任务 → 用 Claude Code(比如填工时,每周一次)
  • 高频稳定的任务 → 还是写传统脚本(比如每分钟跑一次的监控)

参考

展开全文 >>

从K2灵感到折腾3.13：用Kimi CLI管理服务器的故事

一个突然的想法

最近看到Kimi K2的新闻，感觉特别牛逼。我就研究了一下，发现除了网页版，还出了CLI工具。

那一刻我想到：如果能把Kimi当成服务器的AI运维助手，会咋样？

不只是查命令，而是直接让Kimi帮我搞定一切服务器操作。

之前的方式是：我得学Linux、记命令、碰到问题自己调试。现在呢？我只需要告诉Kimi"我要什么"，它帮我搞定。

听起来很简单，但这背后是整个服务器管理范式的转变。

而且是Kimi，国内方便，CLI最高效。

说干就干。结果呢？坑比我想象的多。

坑1：Kimi需要3.13，老系统装不了

一看Kimi CLI的文档，才知道必须Python 3.13。

我的服务器跑的是Ubuntu 18.04，系统自带Python 3.6。我当时想得很简单：直接装3.13，强行安装Kimi不就行了？

1
pip install kimi-cli

结果各种报错。编译的时候，依赖库用不了。3.6那时代的包，到了3.13直接瘫痪。

我试着在系统级别装3.13。Ubuntu 18.04的repo里根本没有，得手动编译。编译一个Python？一两小时起步，还得折腾一堆依赖库。

我坐在电脑前想：有没有办法，不动系统，就能在Ubuntu 18.04上跑3.13？

答案是：用uv。

坑2：网络和Tabby的背刺

uv不仅能管包，还能隔离环境。我可以在当前机器上创建一个隔离的虚拟环境，里面跑3.13，系统还是3.6。两个世界互不干扰。

但装uv又遇到问题：网络。

uv的源在国外，从服务器连过去，慢到绝望，或者直接超时。我试了好几种方法，都不行。最后只能在本地（Windows）下载好，上传到服务器。

本地下载了uv的二进制文件，用Tabby上传。结果上传到一半就中断了。重试好几次，还是中断。

行吧，Tabby这东西在大文件上不太靠谱。

换个办法：scp。

1
scp -r "C:\local\path\uv" ubuntu@server:/home/ubuntu/

虽然听起来很"老气"，但scp真的靠谱。

坑3：终于能问Kimi了

uv装上了，隔离环境创建了，3.13跑起来了，Kimi CLI也装上了。

中间还有些小麻烦，但都不值一提。

最后学会怎么用也很简单：

1
2
3
kimi "怎么查看内存，怎么清理？"
kimi "怎么创建2GB的swap分区？"
kimi "怎么看当前正在运行的所有服务？"

Kimi直接给答案、给命令、给解释。不用打开浏览器，不用翻文档，不用记命令。

就这样：想到 → 问 → 得到答案 → 直接用。

服务器管理的范式变了

装完以后，我才意识到发生了什么。

之前的服务器管理是这样的：

  • 要装个新东西？得先学，翻文档、看教程、试着跑命令
  • 命令怎么写？得记，或者每次都得查
  • 出问题了？得自己调试，一步步排查
  • 整个流程：学习 → 尝试 → 失败 → 调整 → 成功

很多时候，花在"学"和"记"上的时间，反而比实际操作的时间还多。

现在呢？流程彻底变了：

  • 我决定要做什么（比如"装Python 3.12"）
  • 我直接吩咐Kimi去搞
  • Kimi给我完整的步骤和命令
  • 我照着跑，或者Kimi直接执行了，完成

就这样。我不需要理解为什么要这么装，也不需要记这个命令，更不需要担心出了问题咋办。我只需要描述我的需求，剩下的交给AI。

这不是"用AI来帮我记命令"，这是整个管理模式的转变。

从"我是管理者，我得懂Linux"，变成了"我是决策者，我只需要告诉AI要什么"。

体会

这个转变有多彻底？看看最近用Kimi做的事就知道了。

之前的我：

  • 装个隔离的Python环境？得查文档、学uv、折腾一上午
  • 清理内存？要记"free -m"、“sync; echo 3 > /proc/sys/vm/drop_caches”
  • 创建Swap？手动分配、格式化、挂载，一个步骤出错就重来
  • 评估服务？手工"ps aux"、“top”、“systemctl status”，还怕遗漏
  • apt冲突？自己调试、查日志、试各种解决方案

现在的我：

  • 直接问Kimi：“我要一个隔离的Python 3.13环境”，它给我完整方案
  • 问Kimi：“怎么清理内存？”，3秒钟得到答案
  • 问Kimi：“创建2GB swap”，照着做，完成
  • 问Kimi：“服务器现在什么状况？”，它告诉我
  • apt有问题？问Kimi，它知道哪些包冲突

从"我得会"到"我只需要会问"。时间省了，压力也小了。

这意味着什么？

这个转变其实暗示了一个更大的问题：以后还需要学Linux吗？

不是说不用学，而是学的内容变了。之前的Linux学习是"记命令、记原理、记排查思路"。现在呢？更重要的是"清楚地理解你想要什么状态"、“能够描述问题”、“知道什么时候信任AI的答案”。

换句话说，学习的重点从"掌握工具"转变成了"理解需求和结果"。

有个现象特别明显：我现在甚至不怕装一些从来没装过的东西。比如之前不敢乱动的Docker、K8s之类的，现在就敢问Kimi"怎么在我的服务器上快速跑起来一个Docker环境"，然后照着做。

之前呢？得先看一周教程，搞懂原理，再自己一步步装。代价太大了。

后话

这就是为什么我说"想法比坑更值钱"。

坑本身不重要。重要的是，这个想法让我看到了服务器管理的一个新可能：AI不是辅助工具，而是成为了你的运维小助手。你不再需要是个Linux高手，你只需要知道"我的服务器应该是什么样的"。

Kimi K2给了我这个机会。

以后新人入职？不用先花一个月学Linux。直接告诉他们"用Kimi"。经验丰富的运维？可以解放时间，专注在架构设计、系统优化这种更高层的问题上。

这是个很小的发现，但用起来，感觉像换了个工作方式。

展开全文 >>

从零到一：搭建 Gitee WebHook 自动部署系统

问题的起源

用 Hexo 博客，源代码放在 Gitee，每次发完文章都要手动跑 npm run deploy 才能上线。后来进入了Mac生态，有多个电脑都要维护这个博客，"push 代码"和"deploy 代码"的两步就特别烦。容易忘，也容易出错。

我就想：为什么不能 push 到 Gitee 就自动部署了？

于是折腾了一套 Gitee WebHook + Node.js 服务 + systemd 的自动化系统。前两天在云端完整验证了一遍，现在把整个过程和坑都记录下来。以后参考用。

整体架构：四个关键组件

先理解这套系统的工作流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
本地编辑 markdown
     ↓
push 到 Gitee (git push origin master)
     ↓
Gitee 发送 WebHook 通知
     ↓
云端 WebHook 服务接收 (Node.js)
     ↓
自动执行：git pull + npm install + npm run build
     ↓
部署到 /var/www/html
     ↓
网站更新

四个关键组件：

  1. Gitee 仓库 - 事件源（push 时触发 WebHook）
  2. 云端 WebHook 服务 - 事件处理器（接收通知，执行部署）
  3. systemd - 服务管理（保证 WebHook 服务持久运行）
  4. 裸仓库 + post-receive hook - 可选的备用方案（冗余保险）

第一个坑：npm 版本冲突（最烦人）

用的腾讯云服务器，系统自带 Node.js 8.10.0，npm 3.5.2。年代太久。

在云端跑 npm install 时：

1
2
3
4
5
6
npm ERR! Linux 4.15.0-54-generic
npm ERR! argv "/usr/bin/npm" "install"
npm ERR! node v8.10.0
npm ERR! npm  v3.5.2
npm ERR! code EMISSINGARG
npm ERR! typeerror Error: Missing required argument #1

这错误特别烦。npm 3.5.2 自身有 bug，没法装新包。而且新的 npm 要 Node.js 20+ 才行。系统自己的 npm 也升级不了。

原因：系统 Node.js 太老，新的包管理工具没法用。

怎么办：用 NVM（Node Version Manager）装新版本 Node.js。别改系统的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 用国内镜像安装 NVM（腾讯云会很慢，用镜像快很多）
export NVM_DIR="$HOME/.nvm" && (
  git clone https://gitee.com/mirrors/nvm.git "$NVM_DIR"
  cd "$NVM_DIR"
  git checkout `git describe --abbrev=0 --tags`
) && \. "$NVM_DIR/nvm.sh"

# 配置 npm 用淘宝镜像
npm config set registry https://registry.npmmirror.com

# 让 NVM 生效
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# 安装 Node.js 16
nvm install 16

# 验证
node -v  # 应该显示 v16.20.2
npm -v   # 应该显示 8.19.4

验证成功，问题搞定。

教训：服务器系统包太老别费劲升级，直接 NVM 装新版本。这样也不会把系统其他依赖搞坏。

第二个坑：systemd 中的 PATH 环境变量问题

WebHook 脚本写好，想用 systemd 开机自启。配置很简单。

启动后，看日志：

1
ERROR: npm is known not to run on Node.js v8.10.0

奇怪啊，我明明装了 Node.js 16，怎么还在用 8.10.0？

原因：systemd 环境隔离得特别彻底。执行命令时的 PATH 变量不包含 NVM 的 node 路径。所以 npm 找到的还是系统旧版本（/usr/bin/npm）。

怎么办：在 WebHook 脚本中，显式设置 PATH 环境变量。

先创建一个启动脚本 /home/ubuntu/start-webhook.sh：

1
2
3
4
5
6
7
8
9
#!/bin/bash

# 加载 NVM
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# 启动 webhook
cd /home/ubuntu
node webhook.js

然后在 webhook.js 中，明确指定环境变量：

1
2
3
4
5
6
7
8
9
10
const env = Object.assign({}, process.env, {
  PATH: `/home/ubuntu/.nvm/versions/node/v16.20.2/bin:${process.env.PATH}`
});

// 执行命令时传入这个环境变量
execSync('npm install && npm run build', {
  stdio: 'inherit',
  shell: '/bin/bash',
  env: env
});

这样 npm 就用 NVM 的新版本了。

教训：systemd 隔离环境特别彻底，一定要检查 PATH。不止 npm，其他命令也容易掉坑。

完整的配置步骤

下面说怎么从零开始搭。分成 4 步：

步骤 1：云端准备源代码库

假设云端服务器是 [某个域名]，用户名是 ubuntu。

1
2
3
4
5
6
7
8
9
10
11
12
ssh ubuntu@[某个域名]

# 创建源代码目录
mkdir -p /home/ubuntu/blog-src
cd /home/ubuntu/blog-src

# 初始化 git 并配置 Gitee 远程
git init
git remote add origin https://gitee.com/[你的用户名]/[你的博客仓库].git

# 拉取代码（第一次会要求输入密码，后面可以配 SSH key 免密）
git pull origin master

步骤 2：编写 WebHook 接收服务

创建 /home/ubuntu/webhook.js：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
const http = require('http');
const { execSync } = require('child_process');

const PORT = 8912;
const NVM_PATH = '/home/ubuntu/.nvm/versions/node/v16.20.2/bin';

http.createServer((req, res) => {
  if (req.method === 'POST' && req.url === '/webhook') {
    let body = '';

    req.on('data', chunk => {
      body += chunk.toString();
    });

    req.on('end', () => {
      try {
        console.log(`[${new Date().toISOString()}] WebHook received from Gitee`);

        // 关键：设置环境变量，使用 NVM 的 node/npm
        const env = Object.assign({}, process.env, {
          PATH: `${NVM_PATH}:${process.env.PATH}`
        });

        // 1. 拉取最新代码
        console.log(`[${new Date().toISOString()}] Pulling latest code from Gitee...`);
        execSync('cd /home/ubuntu/blog-src && git pull origin master', {
          stdio: 'inherit',
          shell: '/bin/bash',
          env: env
        });

        // 2. 清理旧的构建
        console.log(`[${new Date().toISOString()}] Cleaning old build...`);
        execSync('cd /home/ubuntu/blog-src && rm -rf public', {
          stdio: 'inherit',
          shell: '/bin/bash',
          env: env
        });

        // 3. 构建 Hexo
        console.log(`[${new Date().toISOString()}] Building Hexo...`);
        execSync('cd /home/ubuntu/blog-src && npm install && npm run build', {
          stdio: 'inherit',
          shell: '/bin/bash',
          env: env
        });

        // 4. 部署到 Web 根目录
        console.log(`[${new Date().toISOString()}] Deploying to /var/www/html...`);
        execSync('cp -r /home/ubuntu/blog-src/public/* /var/www/html/', {
          stdio: 'inherit',
          shell: '/bin/bash',
          env: env
        });

        console.log(`[${new Date().toISOString()}] Deploy completed successfully!`);

        res.writeHead(200, { 'Content-Type': 'application/json' });
        res.end(JSON.stringify({ success: true }));
      } catch (error) {
        console.error(`[${new Date().toISOString()}] Deploy failed:`, error.message);
        res.writeHead(500, { 'Content-Type': 'application/json' });
        res.end(JSON.stringify({ success: false, error: error.message }));
      }
    });
  } else {
    res.writeHead(404);
    res.end();
  }
}).listen(PORT, () => {
  console.log(`[${new Date().toISOString()}] WebHook server listening on port ${PORT}/webhook`);
});

注意关键部分：环境变量的设置。这是解决第二个坑的核心。

步骤 3：配置 systemd 自启动

创建 /etc/systemd/system/blog-webhook.service：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[Unit]
Description=Blog WebHook Service
After=network.target

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu
ExecStart=/home/ubuntu/.nvm/versions/node/v16.20.2/bin/node /home/ubuntu/webhook.js
Restart=always
RestartSec=10
StandardOutput=append:/home/ubuntu/webhook.log
StandardError=append:/home/ubuntu/webhook.log

[Install]
WantedBy=multi-user.target

然后启用和启动服务：

1
2
3
4
5
6
7
8
9
sudo systemctl daemon-reload
sudo systemctl enable blog-webhook
sudo systemctl start blog-webhook

# 查看状态
sudo systemctl status blog-webhook

# 查看日志
journalctl -u blog-webhook -f

步骤 4：在 Gitee 配置 WebHook

进入你的 Gitee 仓库 → 管理 → WebHooks → 新增 WebHook

填写：

  • URL: http://[某个域名]:8912/webhook
  • 事件: 选择 “Push” 事件

保存后，Gitee 就会在你 push 时自动发送通知给你的服务器。

测试流程

配置完了，验证一下是否真的工作：

  1. 本地修改一个文章文件
  2. 提交并 push：git push origin master
  3. 登录云端，查看 webhook 日志：journalctl -u blog-webhook -f

看到这样的日志说明成功了：

1
2
3
4
5
6
[2025-11-08T13:30:57.210Z] WebHook received from Gitee
[2025-11-08T13:30:58.134Z] Pulling latest code from Gitee...
[2025-11-08T13:30:58.147Z] Cleaning old build...
[2025-11-08T13:30:58.651Z] Building Hexo...
[2025-11-08T13:31:02.567Z] Deploying to /var/www/html...
[2025-11-08T13:31:02.890Z] Deploy completed successfully!

坑的总结和避免方法

我遇到的两个主要坑：

坑 原因 避免方法
npm 版本冲突 系统 Node.js 太老 用 NVM 安装新版本，不要升级系统包
systemd PATH 问题 环境隔离，找不到新的 npm 显式设置 PATH 环境变量，或用完整的二进制路径

这两个坑其实指向一个核心问题：开发环境和运行环境要一致。

本地用新版 Node.js，服务器也得用新版。不能因为"系统默认有"就将就着用，要主动管理版本。

后续维护

配置完了，日常用特别简单：

  1. 本地编辑文章，push 到 Gitee
  2. 服务器自动部署（5-10 秒）
  3. 刷新网站，新内容上线了

再也不用想起来还要手动 deploy。

唯一要注意的：定期看日志，确保部署没出错。

1
2
3
4
5
# 查看最近 50 条日志
journalctl -u blog-webhook -n 50

# 如果发现错误，可以手动重启服务
sudo systemctl restart blog-webhook

为什么选这个方案，不选 CI/CD？

为什么没选 Gitee Actions、GitHub Actions？

主要原因：

  • 完全自主：不依赖第三方平台（平台故障就完蛋）
  • 简单直接：就一个 Node.js 脚本，好理解好维护
  • 成本低：没有额外的配额限制
  • 好扩展：以后可以加签名验证、多分支部署等

当然，要是用 GitHub，GitHub Actions 更方便。但 Gitee 这个方案够用。

总结

从"手动 deploy"到"push 自动部署"，只是多了几个组件，但减少了日常维护的脑子消耗。

更重要的是，过程中理解了一些运维的关键概念：

  • 版本管理（NVM 的用处）
  • 环境隔离（systemd 的设计）
  • 事件驱动（WebHook 思路）
  • 持久化服务（systemd 的自启和自恢复）

这些概念在其他运维场景也能用。

如果你也想搭类似系统，按上面步骤逐步来，碰到坑时对照我的解决方案。应该能少走弯路。

参考资源

展开全文 >>

你有顶级武器，但可能不会用

你有顶级武器，但可能不会用

最近和同事交流，发现个有意思的现象：公司给大家配了 Coding Copilot，人人都能用，但产品经理们普遍不知道怎么"说话"才能让 AI 生成好结果。

典型场景是这样的：

产品经理：“帮我做个登录页面。”
AI：“好的。”（然后生成了一堆代码，但和你想要的完全不一样）

为啥会这样？因为 AI 不是人，看不到你脑中的原型图，也猜不出你的技术栈和设计规范。

最近我帮团队小伙伴做了个实验：用 AI 生成原型设计。结果发现关键是要先建立结构化框架，就像教 AI 玩乐高——给对说明书，它就能搭出像样作品；说不清楚，它只能瞎搭。

为什么你需要学会"和 AI 说话"

罗振宇在 2023-2024 跨年演讲里讲过一段话：AI 就像是一群无限数量的大学生，真正挑战的是你能指挥多少这样的大学生做事，把事情分解下去并得到可控结果的能力。

这话说到点子上了。

数据不会骗人

看几个关键数据：

什么意思？你会不会写 prompt，直接决定了 AI 工具是帮手还是累赘。

本质：Prompt = 产品决策

有个认知很重要：每次写 prompt，你都在做产品决策。

  • 你描述的功能需求 → 定义了产品边界
  • 你给出的样式要求 → 定义了用户体验
  • 你列出的技术栈 → 定义了实现方案

这和写 PRD 是一个道理。区别是，PRD 写给人看，prompt 写给 AI 看。人能脑补，AI 不能。

吴恩达（Andrew Ng）说过："数据即 PRD。"AI 时代，你需要用具体的数据示例而非冗长抽象的文档来定义产品。

现实：掌握技巧变成核心竞争力

团队人人有 Copilot，但为啥有的人生成的代码能直接用，有的人生成的代码一堆 bug？

差距就在 prompt 技巧上。

这就像当年 Excel 刚普及时，会用 VLOOKUP 的人效率高 10 倍。现在，会写 prompt 的产品经理，协作效率也是数量级的差距。

而且更重要的是：**你能自己改 prompt 迭代，不用等工程排期。**这意味着你可以快速验证想法、快速试错、快速调整方向。

五要素框架：结构化需求描述的套路

好消息是：写好 prompt 是有套路的，不是玄学。

有个现成的套路叫"五要素框架"（5-Pillar Framework），特别好用。

1. Role（角色）：明确 AI 的身份

告诉 AI 它是谁，它就能切换到对应的"人设"。

示例：

  • “你是一名资深前端工程师，擅长 React 开发。”
  • “你是 XX 公司的 UI/UX 设计师，熟悉 Material Design 规范。”

为什么重要：
不同角色的思维方式不一样。你让 AI 扮演前端工程师，它会关注代码实现；你让它扮演设计师，它会关注视觉效果。

2. Goal（目标）：清晰说明要解决什么问题

别绕弯子，直接说你要什么。

好的表达：

  • “为电商网站创建一个商品列表页”
  • “实现一个支持搜索和筛选的用户管理后台”

不好的表达：

  • “帮我做个页面”（什么页面？）
  • “优化一下这个功能”（怎么优化？）

3. Context（上下文）：提供背景信息

这是最容易被忽略，但最关键的一环。

上下文包括：

  • 技术栈：React？Vue？用什么 UI 库？
  • 设计规范：遵循什么设计系统？
  • 业务场景：用户是谁？在什么情况下使用？
  • 已有代码：是新项目还是在现有项目上改？

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
我们的技术栈：
- 前端框架：React 18
- 语言：TypeScript
- 样式方案：Tailwind CSS
- 组件库：Ant Design
- 状态管理：Zustand

设计规范：
- 遵循 XXUI 规范
- 主色调：#13493F（深绿色）
- 辅助色：#C9B037（暖金色）
- 圆角：8px
- 间距：8 的倍数

4. Template（模板）：定义输出结构

告诉 AI 你想要什么格式的输出。

示例：

  • “生成 React 函数组件，使用 TypeScript”
  • “返回完整的 HTML + CSS 代码”
  • “提供组件代码 + 使用示例 + Props 说明”

5. Specifics（具体要求）：明确细节和约束

把你能想到的细节都列出来：

  • 功能需求列表
  • 交互行为（点击、hover、滚动等）
  • 响应式要求（移动端、平板、桌面端）
  • 数据格式（API 返回什么结构）
  • 边界情况（空数据怎么显示、loading 状态、错误提示）

框架总结公式：

1
2
3
4
5
我是谁（Role）
要做什么（Goal）
+ 在什么环境下（Context）
+ 输出什么格式（Template）
+ 具体要求（Specifics）

记住这个套路，你的 prompt 质量能提升一个档次。

好 Prompt vs 差 Prompt：一看就懂的差距

光说理论不够，直接看对比案例。

案例 1：登录页面

❌ 差 Prompt（模糊、抽象）

1
做一个登录页面。

问题：

  • 没说用什么技术
  • 没说要什么功能
  • 没说长什么样
  • AI 只能瞎猜

结果：
可能给你生成个 jQuery + Bootstrap 的老式页面，或者 Vue 3 的组合式 API，完全看心情。

✅ 好 Prompt（具体、结构化）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
使用 React + TypeScript 创建一个登录组件

【技术要求】
- 使用 functional component 和 hooks
- 使用 Tailwind CSS 样式
- 表单验证逻辑独立到 utils/validation.ts

【功能需求】
- 包含邮箱和密码字段
- 邮箱需要格式验证（正则匹配）
- 密码长度至少 8 位，必须包含数字和字母
- 支持"记住我"复选框
- 显示验证错误提示（红色文字，字段下方）
- 登录按钮在表单验证通过前禁用

【样式要求】
- 整体居中布局（垂直水平都居中）
- 卡片式设计，白色背景，带阴影（shadow-lg）
- 遵循 XXUI 规范：
  - 主色调：#13493F（深绿色，用于主按钮）
  - 辅助色：#C9B037（暖金色，用于强调元素）
- 输入框高度 48px，圆角 8px
- 响应式设计：
  - 桌面端：卡片宽度 400px
  - 移动端：卡片宽度占满屏幕（左右留 16px 边距）

【数据交互】
- 点击登录按钮后调用 POST /api/auth/login
- 请求格式：{ email: string, password: string, remember: boolean }
- 成功后跳转到 /dashboard
- 失败显示错误提示

改进点：

  • ✅ 明确技术栈
  • ✅ 功能需求列表化
  • ✅ 验证逻辑说清楚了
  • ✅ 样式具象化（数值都给出了）
  • ✅ 说明了API交互逻辑

结果：
AI 能生成基本可用的代码，改几个细节就能上线。

案例 2：数据表格组件

❌ 差 Prompt

1
生成一个表格，显示用户数据。

问题：

  • 用户数据有哪些字段？
  • 要支持什么功能？（排序？筛选？分页？）
  • 用什么 UI 库？

✅ 好 Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
使用 React + TypeScript + Ant Design 创建用户管理表格组件

【数据结构】
用户对象包含以下字段：
- id: number（用户 ID）
- name: string（姓名）
- email: string（邮箱）
- role: 'admin' | 'user' | 'guest'（角色）
- status: 'active' | 'inactive'（状态）
- createdAt: string（创建时间，ISO 格式）

【表格功能】
- 显示所有字段，列宽自适应
- 支持按姓名搜索（输入框实时筛选）
- 支持按角色筛选（下拉选择：全部/管理员/普通用户/访客）
- 支持分页（每页 10 条，显示总数）
- 状态列显示标签：
  - active 显示绿色标签
  - inactive 显示灰色标签
- 操作列包含：编辑按钮、删除按钮

【样式要求】
- 使用 Ant Design Table 组件
- 搜索框和筛选器在表格上方，左右布局
- 操作按钮使用图标（EditOutlined、DeleteOutlined）

【数据交互】
- 数据从 props 传入（userList: User[]）
- 编辑/删除操作通过回调函数触发：
  - onEdit: (user: User) => void
  - onDelete: (userId: number) => void

改进点：

  • ✅ 明确数据结构（AI 不用猜）
  • ✅ 功能列表详细（搜索、筛选、分页都说清楚了）
  • ✅ 样式有依据（用 Ant Design 组件）
  • ✅ 交互逻辑完整

案例 3：Dashboard 布局

❌ 差 Prompt

1
Make a dashboard.

（英文也一样，模糊就是模糊）

✅ 好 Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Create a React admin dashboard layout

【技术栈】
- React 18 + TypeScript
- Material-UI components
- Responsive design

【布局结构】
1. 左侧边栏（固定宽度 240px）
   - Logo（顶部，高度 64px）
   - 导航菜单（垂直）：Dashboard、Users、Orders、Settings
   - 用户信息卡片（底部）

2. 顶部导航栏（固定高度 64px）
   - 汉堡菜单按钮（移动端显示）
   - 搜索框（居中，宽度 400px）
   - 通知图标 + 用户头像（右侧）

3. 主内容区
   - 顶部统计卡片（4 个，横向排列）：
     - 总用户数
     - 今日订单数
     - 收入统计
     - 增长率
   - 中间数据图表（2 列布局）：
     - 左：订单趋势折线图（Chart.js）
     - 右：用户分布饼图
   - 底部表格：最近订单列表（显示 5 条）

【响应式要求】
- 桌面端（> 1024px）：侧边栏固定显示
- 平板端（768px - 1024px）：侧边栏可收起
- 移动端（< 768px）：
  - 侧边栏默认隐藏，通过汉堡菜单打开
  - 统计卡片改为垂直堆叠
  - 图表改为上下布局

【配色方案】
遵循 XXUI 规范：
- 主色：#13493F（深绿色）
- 辅助色：#C9B037（暖金色）
- 背景：#f5f5f5（浅灰）
- 卡片：白色 + shadow

改进点：

  • ✅ 布局拆解清晰（左中右、上中下）
  • ✅ 每个区域的内容都列出来了
  • ✅ 响应式行为说明白了（不同屏幕宽度怎么显示）
  • ✅ 有配色方案

实战模板：拿来就用的 Prompt 公式

把上面的方法提炼成模板，复制粘贴改改就能用。

UI 组件生成通用模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
使用 [React/Vue] + [TypeScript/JavaScript] 创建 [组件名称] 组件

【背景】
产品类型：[电商/SaaS/内容平台]
使用场景：[用户在什么情况下使用这个组件]
目标用户：[用户特征]

【技术要求】
- 框架：[React/Vue]
- 语言：[TypeScript/JavaScript]
- 样式：[Tailwind/CSS Modules/Styled Components]
- 组件库：[Ant Design/Material-UI/Shadcn]（如果用）

【功能需求】
1. [需求1]
2. [需求2]
3. [需求3]
...

【UI 要求】
- 布局：[描述布局方式，如卡片式、列表式]
- 颜色：[主色调/配色方案]
- 交互：[hover/focus/点击效果]
- 响应式：
  - 桌面端（> 1024px）：[行为描述]
  - 移动端（< 768px）：[行为描述]

【数据结构】（可选）
  interface ComponentProps {
    // 定义 props 类型
  }

【数据交互】（可选）
- API 地址：[URL]
- 请求方式：[GET/POST/PUT/DELETE]
- 请求格式：[JSON 结构]
- 响应格式：[JSON 结构]
- 成功/失败处理：[描述]

【特殊要求】（可选）
- 性能：[加载优化/懒加载要求]
- 无障碍：[ARIA 标签/键盘导航要求]
- 测试：[需要单元测试吗？覆盖哪些场景？]

前端页面生成模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
创建 [页面名称] 页面

【页面功能】
[一句话描述这个页面是干什么的]

【页面结构】
1. [区域1]：[功能描述]
2. [区域2]：[功能描述]
3. [区域3]：[功能描述]

【技术栈】
- 框架：[Next.js/Create React App/Vite]
- 路由：[React Router/Next.js Router]
- 状态管理：[Redux/Zustand/Context API]
- 样式：[Tailwind/Styled Components]

【详细需求】
[按照组件模板，拆解每个区域的需求]

【路由和导航】
- 页面路由：[/path]
- 来源页面：[从哪里跳转过来]
- 目标页面：[点击什么跳转到哪里]

【数据流】
- 初始化时加载：[API 列表]
- 用户操作时调用：[API 列表]
- 数据缓存策略：[是否需要缓存？用什么方案？]

使用技巧：

  1. 先填模板，再微调

    • 不要一上来就自己写，先用模板结构化你的需求
    • 填完模板再根据具体情况删减或补充

  2. 迭代优化，不要期望一次完美

    • 第一次生成的代码不满意？没关系
    • 看看哪里不符合预期，补充具体要求，让 AI 再生成一次

  3. 保存你的常用模板

    • 把团队常用的技术栈、设计规范固化到模板里
    • 每次用的时候只需要改具体需求部分

  4. 建立团队 Prompt 库

    • 好用的 prompt 分享给团队
    • 就像你们有组件库一样，也可以有 Prompt 库

环境配置：让 Copilot 更懂你

除了每次写完整的 prompt，还有个更高效的办法：配置 Custom Instructions（自定义指令）。

这就像给 AI 配了一个"记忆芯片"，让它永远记住你的技术栈和偏好。

什么是 Custom Instructions？

说白了，就是一段固定配置，告诉 AI：

  • 我们用什么技术
  • 代码规范是啥
  • 我希望你怎么输出

配置一次，以后 AI 都记得。

怎么设置？

GitHub Copilot 设置路径（以 VS Code 为例）：

  1. 打开 VS Code
  2. 左下角齿轮图标 → Settings
  3. 搜索 “Copilot Instructions”
  4. 在文本框里填入你的配置

Cursor 设置路径：

  1. Cmd/Ctrl + Shift + P → 输入 “Cursor Settings”
  2. 找到 “Rules for AI” 或 “Custom Instructions”
  3. 填入配置

配置模板示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# 团队技术栈

## 前端框架
- React 18（优先使用函数组件 + Hooks）
- TypeScript（严格模式）

## 样式方案
- Tailwind CSS（优先使用）
- 不使用内联样式
- 响应式设计：移动优先

## 组件库
- Ant Design 5.x（数据展示类组件）
- Headless UI（交互类组件）

## 状态管理
- Zustand（全局状态）
- React Query（服务端状态）

## 代码规范

### 命名规则
- 组件文件：PascalCase（如 UserProfile.tsx）
- 工具函数：camelCase（如 formatDate.ts）
- 常量：UPPER_SNAKE_CASE

### 组件结构
  // 固定顺序
  1. imports
  2. types/interfaces
  3. constants
  4. component
  5. exports

### Props 定义
- 使用 interface 而非 type
- Props 必须明确类型，避免 any
- 可选 props 使用 ? 而非默认值

### 函数组件
- 使用箭头函数
- Props 解构在参数位置
- 早返回（early return）处理边界情况

## 输出要求

- 生成代码时包含必要的注释
- TypeScript 类型完整
- 考虑错误处理（try/catch 或 error boundary）
- 考虑 loading 状态
- 考虑空数据状态

## 不要做的事

- 不要使用 class 组件
- 不要使用 var，只用 const/let
- 不要使用 any 类型（除非真的必要）
- 不要生成超过 200 行的单个文件（建议拆分）

配置后的效果

配置前：

1
2
3
你："创建一个按钮组件"
AI："好的"（生成 Vue 2 的按钮，或者 jQuery 的按钮，看心情）

配置后：

1
2
3
你："创建一个按钮组件"
AI："好的"（自动生成 React 18 + TypeScript + Tailwind 的按钮，符合团队规范）

一次配置，终身受益。

常见问题 Q&A

Q1：Custom Instructions 和每次写 prompt 有啥区别？

A：Custom Instructions 是"全局规则"，适合放技术栈、代码规范这种不变的东西。具体的功能需求还是要每次单独写 prompt。

Q2：配置太长会不会影响性能？

A：会占用一些 token，但影响不大。建议控制在 500-1000 字以内。

Q3：团队成员的配置能统一吗？

A：可以。把配置文件存到项目的 .github/copilot-instructions.md，然后让大家复制粘贴到自己的设置里。

（注：有些工具支持项目级配置，但 GitHub Copilot 目前还不支持，需要手动同步）

3 个认知转变 + 4 个落地关键点

3 个认知转变

1. 从"模糊表达"到"结构化描述"

以前：

  • “帮我做个好看的登录页”
  • “优化一下这个功能”
  • “改改样式”

现在：

  • 用五要素框架拆解需求
  • 功能列表化、样式数值化
  • 技术栈明确、交互逻辑完整

就像从"我想吃好吃的"变成"我要一份麻辣小龙虾（中辣、去虾线、配米饭）"。

2. 从"期望完美"到"迭代优化"

以前：

  • 写一次 prompt，期望 AI 生成完美代码
  • 结果不满意就觉得 AI 不行

现在：

  • 第一次生成 60 分，正常
  • 看看哪里不对，补充需求，让 AI 再改
  • 几轮迭代后达到 90 分

就像测试软件一样测试 prompt。没有一次过的产品，也没有一次过的 prompt。

3. 从"工具使用"到"战略思维"

以前：

  • 把 Copilot 当"代码补全工具"
  • 遇到问题就问 AI，随机应变

现在：

  • Prompt Engineering 是产品方法论的延伸
  • 把需求结构化本身就是产品能力
  • 能指挥 AI 干活 = 能指挥团队干活

罗振宇那句话说得对：AI 就像是一群无限数量的大学生，真正挑战的是你能指挥多少这样的大学生做事，把事情分解下去并得到可控结果的能力。

4 个落地关键点

1. 结构化 > 随意描述

  • ✅ 使用模板和框架（五要素）
  • ✅ 分点列举而非大段文字
  • ✅ 功能、样式、交互分开描述

2. 具体 > 抽象

  • ✅ 用数据、案例、示例
  • ✅ 避免"优化"、“改进”、"好看"等模糊词
  • ✅ 给出具体数值（宽度、颜色、字号）

对比：

  • ❌ “这个按钮要大一点”
  • ✅ “按钮宽度 120px，高度 40px”

3. 拆分 > 一次完成

  • ✅ 复杂任务拆成小步骤
  • ✅ 每步验证后再继续
  • ✅ 先要结构，再要细节

示例：
不要说：“帮我做一个完整的电商网站”
应该拆分成：

  1. 先做首页布局（header + 商品列表 + footer）
  2. 再做商品卡片组件
  3. 再做购物车功能
  4. …

4. 配置 > 每次重复

  • ✅ 设置 Custom Instructions（技术栈、代码规范）
  • ✅ 建立团队 Prompt 模板库
  • ✅ 常用需求固化成可复用模板

类比：
就像你不会每次做菜都从买锅买碗开始，工具和调料要常备。Prompt 模板也是一样。

回到开头那个问题

还记得文章开头说的场景吗？

产品经理：“帮我做个登录页面。”
AI：“好的。”（然后生成一堆不对的代码）

现在你知道问题出在哪了：不是 AI 不行，是你没说清楚。

掌握 Prompt Engineering，本质是掌握"需求结构化"的能力。
这能力你本来就有，只是没用对地方。

从明天开始，用五要素框架重写一个需求。
你会发现，AI 突然"变聪明"了。

其实不是 AI 变了，是你学会了和它说话。

参考资源

官方文档

社区资源

中文资源

展开全文 >>

webdav是个啥

什么是WebDAV协议？

WebDAV(Web-based Distributed Authoring and Versioning)是一种基于HTTP协议的通信协议，它扩展了HTTP/1.1协议，在标准的HTTP协议上添加了一些新的方法，使应用程序可以直接对Web服务器上的文件进行读写操作。简单来说，WebDAV协议允许用户直接在服务器上创建、修改和移动文档，就像在本地硬盘上操作文件一样。

你可以把它理解为一个能让 HTTP 协议变身为文件管理器的协议：

核心功能：超越简单的读写

普通的 HTTP（比如你浏览网页）主要是 GET（获取资源）和 POST（提交数据）。
WebDAV 在 HTTP 的基础上增加了一系列新的 方法 (HTTP Methods)，使得你可以像操作本地文件一样去操作远程服务器上的文件和目录。

关键方法包括：

  • PROPFIND：检索文件或目录的属性（如创建时间、作者、大小等元数据）。
  • PROPPATCH：修改文件或目录的属性。
  • MKCOL：创建新目录（相当于本地文件系统的 mkdir）。
  • COPY：拷贝文件或目录到另一个位置。
  • MOVE：移动或重命名文件或目录（相当于 mv 或 rename）。
  • LOCK：锁定文件（防止多人同时编辑造成冲突）。
  • UNLOCK：解锁文件。

当然，它也支持 GET（下载文件）、PUT（上传文件）、DELETE（删除文件或目录）。

WebDAV的主要特点包括:

  1. 支持文件的上传、下载、复制、移动、删除等基本操作
  2. 支持文件锁定机制，防止多人同时编辑同一文件
  3. 支持文件属性的读写，如创建时间、修改时间等
  4. 支持命名空间管理
  5. 支持版本控制
  6. 基于HTTP协议，可以穿透防火墙

由于WebDAV是HTTP协议的扩展，它继承了HTTP的所有优点，包括:

  • 跨平台性好，几乎所有操作系统都支持
  • 可以通过HTTPS进行加密传输
  • 配置简单，使用方便
  • 支持断点续传
  • 可以通过Web浏览器直接访问

主要用途：分布式文件管理和协作

远程文件管理： 用户可以直接使用操作系统自带的文件资源管理器（如 Windows 的文件资源管理器、macOS 的访达、Linux 的各种文件管理器）或支持 WebDAV 的专用客户端软件，像访问本地磁盘一样访问、打开、编辑、创建、删除、移动、复制服务器上的文件。不需要特殊的 FTP 软件。
在线存储和同步： 许多网盘和云存储服务（如 Nextcloud, ownCloud, Seafile, Box 等）后端都支持 WebDAV。同步客户端或直接挂载就是利用 WebDAV 协议来实现的。微软的 OneDrive 和 Apple 的 iCloud Drive 也通过 WebDAV 提供了兼容性。
协作编辑： 结合 LOCK/UNLOCK 机制，允许多人协作编辑同一个文档库中的文件（避免冲突），常用于 Wikis（如 MediaWiki）、内容管理系统（CMS）等需要远程更新内容的场景。这也是其名称中“分布式创作”的由来。
挂载网络驱动器： 可以通过 WebDAV 将远程服务器上的目录映射为本地的一个网络驱动器盘符（例如在 Windows 上“映射网络驱动器”）。
应用程序集成： 很多应用程序（如 Microsoft Office, Adobe Photoshop, Apple 的 iWork 套件、文本编辑器等）原生支持通过 WebDAV 打开和保存文件到远程服务器。

重要特性和优势：

基于 HTTP(S)： 可以直接穿越标准防火墙（80/443端口），无需额外开放特殊端口，安全性可通过 HTTPS 和用户认证（Basic, Digest）保障。
平台无关： 几乎所有主流操作系统和应用软件都支持。
类文件系统操作： 提供文件操作（上传、下载、删除、移动、复制、创建目录）的标准化接口。
锁机制： 支持文件锁定，防止编辑冲突。
属性管理： 可以读写自定义或标准的文件元数据。

WebDAV 的局限性

性能瓶颈 (尤其在高延迟、大文件场景)：

请求/响应模式臃肿： WebDAV 在底层基于 HTTP(S)，是一种纯文本的请求/响应协议。操作文件（特别是目录遍历、属性查询）需要发送复杂的 XML 请求体 (PROPFIND)，并解析同样复杂的 XML 响应。相较于二进制协议（如 SFTP、SMB v3/v4、专用同步协议），这在大量小文件操作或网络延迟高时（跨国同步）效率低下。

大文件传输风险： PUT/GET 大文件是单次 HTTP 请求。网络不稳定容易导致传输中断，需要完全重传（缺乏有效的增量传输或断点续传机制）。虽然 HTTP 本身有 Range 头部支持断点续传，但很多客户端和服务器的实现不够健壮，需要开发者做额外工作。
文件锁定机制问题:

协议定义复杂，实现困难： 锁定机制 (LOCK, UNLOCK) 是协作编辑的核心，但其实现细节复杂（锁类型、范围、超时、所有者判定、深度锁等）。不同服务端/客户端的实现往往存在兼容性问题。
“固执”的锁： 如果客户端崩溃或忘记解锁，文件可能被长时间锁定，妨碍他人编辑，直到锁超时（如果服务端设置了超时）。
分布式系统挑战： 在大型分布式存储系统中，保证锁状态在所有节点间的一致性和即时性非常困难，与追求高可用性和最终一致性的现代云存储架构存在冲突。很多服务实际不实现或禁用文件锁。
元数据（属性）操作效率低：

PROPFIND/PROPPATCH 方法使用 XML 格式处理属性。查询或修改少量文件的少数属性是可行的。但在涉及大量文件或复杂属性查询时，XML 的解析和生成会成为性能瓶颈，远不如数据库查询或专用的元数据管理接口高效。
协议复杂性高：

WebDAV 规范庞大复杂（核心协议+多个扩展）。完整的、兼容性好的服务器和客户端实现难度大、维护成本高。容易出现不同厂商实现之间的互操作性问题。
认证与安全：

默认认证弱： 传统基于 HTTP Basic 的认证是明文传输用户名密码，非常不安全。HTTPS (SSL/TLS) 是强制安全传输的要求。
现代认证集成难： 难以无缝集成 OAuth 2.0 等现代、更安全的认证授权协议。集成通常需要通过 Web 代理层（如 Nginx）处理，增加架构复杂性。
缓存与状态问题：

HTTP 在概念上是无状态的，而 WebDAV 的锁机制 (LOCK) 引入了状态（有状态的锁）。这与 HTTP 的无状态设计理念存在矛盾，使得缓存（特别是代理缓存）的处理变得复杂和容易出错。

小结

基于以上的讨论，WebDAV一般是适用于一些工具类软件（如 Zotero, GoodNotes, Notability, KeePass, MarginNote, 以及一些离线笔记软件）用户必不可少的工具。

实操篇

搭建WebDav服务器

在群辉上搭建WebDAV服务器非常简单,主要需要完成以下几个步骤:

  1. 在套件中心安装WebDAV Server软件包
  2. 设置访问凭证:
    • 配置用户名
    • 配置密码
  3. 配置网络参数:
    • 设置服务IP地址
    • 设置服务端口号

注意：

其实不用管理路径。这个路径，就是这个用户可以访问的全部路径。

客户端软件

Mac & Windows

  • CyberDuck
    这个真心不错，跨平台版本的，mac和Windows都可以使用，无广，只是关闭的时候会提示是否Donate。

IOS & Android & 鸿蒙

Linux

  • Filezilla

Windows

  • RaiDrive
    挂载不错，就是有太多广告了。

关于猫头鹰文件：

猫头鹰文件盒FE File Explorer是一个公司的产品，只是国内外市场不同。
猫头鹰：包月会员10/月；包年80/月；终身VIP 198元
FE File Explorer：需要Google Play，收费38；在IOS App Store 上 买断也是38元。

总结

WebDAV作为一个基于HTTP协议的文件传输协议,具有以下几个特点:

  1. 简单易用 - 搭建和使用都相对简单,无需复杂配置
  2. 跨平台兼容 - 支持各种操作系统和设备
  3. 安全可靠 - 可以使用HTTPS加密传输
  4. 功能实用 - 满足文件同步、备份等基本需求

对于个人用户来说,WebDAV是一个不错的文件共享解决方案:

  • 可以实现跨设备的文件访问和同步
  • 支持众多常用软件和工具
  • 自建服务器可以保护隐私数据
  • 成本较低,维护简单

不过也要注意一些局限性:

  • 传输速度不如专用文件传输协议
  • 功能相对基础,缺乏高级特性
  • 需要自行维护服务器安全
  • 部分软件可能需要付费使用

总的来说,WebDAV是一个实用的文件共享工具,适合有一定技术基础的用户搭建使用。选择合适的客户端软件,可以满足日常的文件同步和管理需求。

展开全文 >>

重新认识Cursor：我的AI生产力新伙伴

为什么我们需要本地化的AI工作台？

最近用飞书文档时又被网络延迟搞崩溃了，这让我突然意识到：即使在云时代，本地编辑器仍然是刚需。就像你永远需要一双合脚的拖鞋，虽然不常穿出门，但在家办公时没有它真的不行！

那么问题来了：在AI时代，什么样的工具才能称得上真正的生产力神器？我总结了几个关键特征：

从代码编辑器到智能创作中枢

  • 闪电响应不卡顿：本地运算+存储就像给编辑器装上了涡轮增压，告别云端加载的"转圈圈焦虑"
    • 当然，缺钱小白跑不起本地，也可以使用飞机场的模式来应对，同时接入多家，哪个快用哪个。一个不行了，就另一个定期做延时测试。
  • AI副驾驶深度整合：既能陪你头脑风暴，又能直接上手改代码，真正实现"想到即做到"
  • 效率革命3.0版：智能补全+语义搜索+上下文感知，传统编辑器就像从诺基亚升级到iPhone
  • 离线生存保障：网络罢工时，核心功能依然坚挺，就像办公室常备的应急电源

说到文字创作效率，最近发现个神器——豆包语音输入。实测用它写文字，速度比键盘快2倍！当然前提是你能在咖啡馆找到个安静角落（建议自带"请勿打扰"表情）

DeepSeek带来的平民AI革命

原本给程序员用的Cursor，现在被我开发出新玩法：Markdown写作神器！虽然图片排版还在摸索中，但纯文字创作已经爽到飞起。

人人都能用上顶级AI

  • 技术平权进行时：DeepSeek让小白也能调用顶尖模型，就像突然拥有个工程师团队

  • 成本低到想笑：对比视频网站会员，这些AI API简直是白送（某云平台1元=10万字生成）

  • 真实体验差异：用过才知道大模型的边界在哪，就像学游泳必须下水扑腾

  • 自由调用顶尖AI模型（类比拥有私人工程师团队）

    • deepseek 模型的出现，而且广泛的 API 调用。使得平民也可以自用调用顶尖的 AI 模型。越早的使用这些 AI 模型。就能够越快地体会到效率的提升。你用大模型和不用大模型感受是不一样的。你会清晰的知道大模型的边界是什么，它返回的特征是什么。如果你不用，你可能不知道这件事到底用大模型怎么做？如何去调用大模型本身的能力？你的工具链是什么？

  • 成本可控的商用方案（对比传统API调用模式）

    • 由于 deepseek 已经被广泛的各大云平台变成了 API，可以随意调用。而且成本只要十几块钱，非常之便宜了，已经相当于不要钱了，视频网站充个会员还要那么贵呢？所以这是一个非常成本可用的商用方案，几乎可以无缝的嵌入到所有的服务中。从密塔科技在过年的时候就已经接入了 R1 模型，Perplexity 也接入了 R1 模型。这两个工具有，原来我用刚刚使用的时候我还是挺惊艳的，但是用了一段时间发现原本的模型水平还是有点垃圾。能给出的答案水平达不到我的要求。但是现在接入了 R1，已经达到能用的水平了。

知识库：你的私人AI外挂

我发现大模型+私有知识库才是王炸组合！比如把公司内部文档喂给AI，瞬间变身行业专家。不过收集整理这些知识的过程…（默默打开待办清单）

本地化智能三件套

  • 实时索引黑科技：写代码的同时就在训练专属AI助手
  • 项目级上帝视角：不再局限单个文件，真正理解项目架构
  • 数据安全红绿灯：敏感资料不出本地，老板再也不用担心泄密

工作流改造实战

最近帮产品团队做了个实验：用AI生成PRD文档模板。结果发现关键是要先建立结构化框架，就像教AI玩乐高——给对说明书，它就能搭出像样作品。

开发者新姿势

  • 代码秒懂功能：选中即解释，比问同事快10倍（还不会翻白眼）
  • 项目级搜索：找代码像用Ctrl+F那么简单，但能搜整个项目
  • 个性化调教：把代码规范喂给AI，从此告别风格检查

文字工作者的春天

  • 20+格式通吃：Word/PDF/Markdown随意切换，本地处理更安心
  • 素材库智能联想：写方案时自动关联历史资料，真·温故知新
  • 离线创作自由：飞机高铁上也能AI协作，灵感不等人！

未来值得期待

  • 轻量微调：1GB显存就能训练专属模型（显卡厂商哭晕）
  • 多模态突破：本地跑语音/图像模型指日可待
  • 国产化方案：期待看到更多中国芯+中国造的组合

最后说句大实话：Cursor最让我惊艳的不是某个功能，而是那种"AI就在手边"的踏实感。它正在重新定义什么叫做趁手的工具——就像从瑞士军刀进化到钢铁侠战衣，你值得拥有！

展开全文 >>

我用AI做了个播客

在研究 AI 的语音模型时，我突发奇想，能否用 AI 的声音做些什么。

正好最近在 github 上看到一本不错的书，就想让孩子也看看。但由于长期在外地出差，和孩子所在的城市时间总是对不上，所以我就产生了用 AI 做播客的念头。

结构

做播客的第一步是研究其结构。

通常，播客包括开场白或介绍的部分，这可能是每一期节目的Intro。

与Intro相对的是Outro，是在节目结束时，会有一句欢迎大家转评赞的话。

Intro&Outro:

一沉，你好呀，欢迎来到《人人都能用英语》！我是爸爸制作的机器人哥哥，今天将带你一起阅读这本在git hub上发行的开源书。希望你能通过听完这本书，以后能轻松地学习英语。准备好了吗？让我们开始吧！

感谢你的聆听，这一期的《人人都能用英语》到这里就结束啦。希望在这短短的时间里，你能有所收获。别忘了，每一天的进步都是你通往流利英语的重要一步。听众朋友们，如果你喜欢我的节目，请关注我，把节目分享给更多的朋友。我们下期再见，再会！

正文

然后就是阅读书籍本身正文的内容了。

Shownotes

如果不做播客，你可能不知道还有个东西叫 shownotes，它以文本形式简介节目内容，里面有时间轴，用时分秒的方式制作热链接到音频的对应位置，方便快速跳转到相应位置听取这一段内容的简介。制作时间轴的步骤叫做“打轴”，如果没有AI，这是一个很费时费力的工作。

Show notes 中也会包含图片以及不方便用语音介绍的内容，方便听众根据补充信息拓展节目以外的内容。

我的Shownotes长这样：

题图

还有就是每一集的题图。这里我都是用同一个风格的AI生成的。

播音员

再就是搞定播音员说话啦。我用了两个平台的主播。

  • 魔雨晴@出门问问/魔音工坊

  • 云龙@腾讯智影

别问我为啥要换平台，魔音工坊的收费模式太坑了，令人吐槽。

发布

最后就是把对应的所有信息发布到平台上就好了。

你看，东西也不是很多，挺简单的不是嘛。

体会

纸上得来终觉浅，绝知此事要躬行。

很多事情，只有做过，才能感受到很细节的东西。

做播客的感觉是，即便是写好的书，在一些地方上也需要修改才能适合口语化表达。并不是简单的文字稿出来，就是成品的，那样的作品品质太差，是经不起时间推敲的。比如，为了让品质看得过去，我就做了下面这些编辑：

  1. 所有的“罢”要替换成“吧”，不然AI读起来怪怪的
  2. 注意数值的发音，例如99.99%，要针对性的修正，不然会读成99.99百分号
  3. ——要替换成句号，以获得停顿。
  4. （参见《通往财富自由之路》）一些括号参见的内容，要注意去掉，语音表达不需要。
  5. 图片的格式![]()要去掉，不然会把括号叹号读出来
  6. 超链接的格式去掉，不然就会念：https…
  7. 音标等通过插入音效解决，暂时只能口语录
  8. 一定要校对，逐字听，检查多音字发音正确，断句正确
  9. 用来加粗的**都去掉，一些AI播音员会读成“星号”
  10. github要加上空格，否则发音有时候不对
  11. …

保证交付质量，即使有了AI也要不少人工的。

从某种角度来说，播客是另一种载体，它是一种特殊的传播形式，这种载体更口语化，只占用耳朵一个输入器官，更适合一边做其他事情一边听，更具有陪伴的特性。 这种特性反而更符合我选择用播客的方式来陪伴不在同一时空的家人的需求。

当然，这里也有AI带来的福利。播客有一个要素是播音员。我选择的是 AI 播音员，因为我的嗓子不太好，而且使用 AI 播音员只要搞定文字稿，读稿子的速度很快，可以极大地节省录制节目的时间。 毕竟错读重录稿子还是很浪费时间的。

原来录制播客要录好几遍，中间有口误还要反复重来，做一期播客可能需要很长时间，有了 AI 真的很好，做个播客也可以轻装上阵了。但现在只要解决了文案，很快就可以出一篇播客。

AI让生活更美好！

播客在这里：https://namecard.xiaoyuzhoufm.com/86knu

展开全文 >>

解决 SSL 证书过期问题的记录

今天在整理网站的时候，我发现 SSL 证书过期了。ACME原本的默认证书提供商从 Let’s Encrypt 变成了 ZeroSSL。

https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA

update一下ACME客户端。

我注册了 ZeroSSL 账号，并使用 QQ 邮箱进行了验证。不过似乎好像没用上。

然后，我发现 ACME 客户端还要使用 EAB 凭证进行配置。

1
2
acme.sh  --register-account  -m example@qq.com --server zerossl
acme.sh --register-account --server zerossl --eab-kid aaa --eab-hmac-key bbb

由于我的域名是阿里云的，所以我又在阿里云注册了一个 Access Key ID，并将其提供给 ACME 客户端进行授权和认证。

https://github.com/acmesh-official/acme.sh/wiki/dnsapi#dns_ali

1
2
acme.sh --server zerossl --issue -d example.com --dns dns_cf
acme.sh --issue --dns dns_ali -d example.com -d *.example.com

于是，证书搞定了。以后默认这个ca：

1
acme.sh --set-default-ca --server zerossl

下面就是把证书弄到nginx的配置文件里面。

1
2
3
:~$ vim /etc/nginx/sites-available/default
:~$ sudo vim /etc/nginx/sites-available/default
:~$ sudo nginx -s reload

刷新网页，成功~~

目前，似乎没有自动更新证书的方法，所以当证书到期时，我可能需要注册一个 EAB 文件并重新跑一遍流程来申请证书。

希望这篇博客能对有类似问题的朋友们有所帮助。如果大家有任何其他问题或建议，欢迎随时联系我。

展开全文 >>

一本你可能想象不到的书《dirty chinese》

《Dirty Chinese》：揭秘真实的街头汉语

嘿，小伙伴们晚上好！今天我想跟大家分享一本非常有趣的书——《Dirty Chinese》。你们猜怎么着？是在小宇宙播客里无意中听到有这么一本神奇小书，简直是深夜冲动的完美伴侣！晚上正好有空，不想睡，我就满世界找这本书，结果还真就找到了。而且，让我眼前一亮的是，这本书不仅有中文语言的版本，还有各种其它语言的版本呢，比如《Dirty Japanese》、《Dirty French》之类的，看来“脏话无国界”，颇有些国际范儿。

这本书的封面设计得很吸引人，一眼望去就知道里面藏着的肯定是些街头生活的精髓。别看书名里有“脏”字，其实这书可是真材实料地展现了中国当代口语，你要是个外国人，并且对中文感兴趣，或者计划深入中国的大街小巷，那你绝对不能错过。

《Dirty Chinese》里面的内容，包罗万象，从逛街、派对、夜店到体育赛事，甚至连浪漫和性爱的场合都有对应的地道表达方式。书中的短语，既有撩人的甜言蜜语，也有让热情过头的街头小贩知难而退的言辞。更别提，如果你需要说服当地警察“时间不早了，小费也给够了”，书里面还有那些直接了当到可能会让人脸红的表达方式。

读《Dirty Chinese》，不仅能学到实用的汉语，还能体会到作者的幽默风趣。书里的内容，足够让你在中国引起一场小小的“文化冲击”，而且还特别附上了发音指南和样例对话。甚至连香港那些臭名昭著的“一夫一妻”服务业都能让你有足够的词汇去尴尬地交流。

总之，这本《Dirty Chinese》可以说是走心又走肾的实用指南，无论你是要“脏话”交流的达人，还是对中国街头文化好奇的旅行者，都绝对值得一读。当然啦，记得带着点幽默感去理解书中的内容，不要真的在大庭广众之下尝试哦！这种书，就是要在那些欢乐又放松的时刻，偷偷拿出来，给自己增加点跨文化的情趣。让我们在轻松愉快中，体验一下中文里那些“不为人知”的另一面吧！

展开全文 >>

GitHub SSH 连接配置指南

GitHub SSH 通过端口 443 连接

GitHub 支持通过端口 443 上的 SSH 连接，这对于绕过限制了标准端口 22 的网络环境特别有用。

配置 .ssh/config

为了使用端口 443 连接到 GitHub，你需要在你的 ~/.ssh/config 文件中添加如下配置：

1
2
3
4
5
Host github.com-ssh
  HostName ssh.github.com
  User git
  Port 443
  IdentityFile ~/.ssh/id_rsa

这段配置会创建一个别名 github.com-ssh，你可以通过这个别名使用 SSH 连接到 GitHub。

测试连接

完成配置后，你可以通过以下命令测试连接：

1
ssh -T git@github.com-ssh

如果一切设置正确，这将通过端口 443 建立与 GitHub 的 SSH 连接。

解释 .ssh/config 配置

  • Host 是你给服务器设置的别名，用于在 SSH 命令中引用。
  • HostName 是服务器的真实主机名，在这里是 ssh.github.com。
  • Port 指定了 SSH 连接应使用的端口，这里设置为 443。
  • User 设置为 git，因为这是大多数 Git 服务器的标准用户名。
  • IdentityFile 声明了你的私钥文件的位置，它是 OpenSSH 格式的身份验证密钥。

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

很惭愧<br><br>只做了一点微小的工作<br>谢谢大家