TjSky | 秋风于渭水修改

2026-08-21 12:02:11

memos对于图片附件默认是直接原样上传的，如果直接给自己当笔记用，倒是个优点，因为可以保留最原始的图片状态。但是我是放到博客首页当说说用的，首页基本是排在流量前3的页面，我算了下，就算图片只有2MB大，发个带图的说说，一个月为这张图都要额外支出5GB的流量了，要知道正常博客整站一个月流量也就60GB不到。虽说距离机器的流量上限还远着呢，但这可不是啥好消息。于是写了个简单的JS脚本，实现：拖拽，Ctrl+V，使用+号添加图片的时候，自动把图片转码为 webp 格式，并按 0.90 压缩率做压缩。

// A1. 压缩图片为webp，0.90 兼顾画质与体积
(function() {
    const WEBP_QUALITY = 0.90;
    // 异步转码为 WebP
    function convertToWebP(file, quality) {
        return new Promise((resolve, reject) => {
            const img = new Image();
            const url = URL.createObjectURL(file);

            img.onload = () => {
                URL.revokeObjectURL(url);
                const canvas = document.createElement('canvas');
                canvas.width = img.naturalWidth;
                canvas.height = img.naturalHeight;

                const ctx = canvas.getContext('2d');
                ctx.drawImage(img, 0, 0);

                canvas.toBlob((blob) => {
                    if (blob) {
                        const newName = file.name.replace(/\.[^/.]+$/, "") + ".webp";
                        const webpFile = new File([blob], newName, { type: "image/webp" });
                        resolve(webpFile);
                    } else {
                        reject(new Error("Canvas toBlob failed"));
                    }
                }, "image/webp", quality);
            };

            img.onerror = (err) => {
                URL.revokeObjectURL(url);
                reject(err);
            };

            img.src = url;
        });
    }

    // 辅助函数：批量转换文件列表
    async function processFiles(files) {
        const dataTransfer = new DataTransfer();
        for (const file of files) {
            if (file.type.startsWith('image/') && file.type !== 'image/webp') {
                try {
                    const converted = await convertToWebP(file, WEBP_QUALITY);
                    dataTransfer.items.add(converted);
                } catch (err) {
                    console.error('[Memos WebP] 转码失败，保留原图:', err);
                    dataTransfer.items.add(file);
                }
            } else {
                dataTransfer.items.add(file);
            }
        }
        return dataTransfer;
    }

    // 1. 拦截剪贴板粘贴 (Ctrl + V)
    window.addEventListener('paste', async (e) => {
        if (e.__memosWebpHandled) return;

        const clipboardData = e.clipboardData;
        if (!clipboardData || !clipboardData.files || clipboardData.files.length === 0) return;

        const files = Array.from(clipboardData.files);
        if (!files.some(f => f.type.startsWith('image/') && f.type !== 'image/webp')) return;

        e.preventDefault();
        e.stopImmediatePropagation();

        const dataTransfer = await processFiles(files);
        const newPasteEvent = new ClipboardEvent('paste', {
            bubbles: true,
            cancelable: true,
            clipboardData: dataTransfer
        });
        newPasteEvent.__memosWebpHandled = true;
        e.target.dispatchEvent(newPasteEvent);
    }, true);

    // 2. 拦截文件拖拽
    window.addEventListener('drop', async (e) => {
        if (e.__memosWebpHandled) return;

        const dataTransfer = e.dataTransfer;
        if (!dataTransfer || !dataTransfer.files || dataTransfer.files.length === 0) return;

        const files = Array.from(dataTransfer.files);
        if (!files.some(f => f.type.startsWith('image/') && f.type !== 'image/webp')) return;

        e.preventDefault();
        e.stopImmediatePropagation();

        const newDataTransfer = await processFiles(files);
        const newDropEvent = new DragEvent('drop', {
            bubbles: true,
            cancelable: true,
            dataTransfer: newDataTransfer
        });
        newDropEvent.__memosWebpHandled = true;
        e.target.dispatchEvent(newDropEvent);
    }, true);

    // 3. 拦截点击「+」号 / 附件按钮的文件选择框
    window.addEventListener('change', async (e) => {
        const target = e.target;
        if (!target || target.tagName !== 'INPUT' || target.type !== 'file') return;
        if (e.__memosWebpHandled) return;

        const files = Array.from(target.files || []);
        if (!files.some(f => f.type.startsWith('image/') && f.type !== 'image/webp')) return;

        e.preventDefault();
        e.stopImmediatePropagation();

        const dataTransfer = await processFiles(files);
        target.files = dataTransfer.files;

        const newChangeEvent = new Event('change', {
            bubbles: true,
            cancelable: true
        });
        newChangeEvent.__memosWebpHandled = true;
        target.dispatchEvent(newChangeEvent);
    }, true);
})();

进入memos、设置、系统、自定义脚本、把上边的代码粘进去，保存。
搞定了，以后无论是使用 Ctrl+V粘贴进来的图片，还是直接拖进来的图片，亦或者使用「+」号 / 附件按钮添加图片时，图片会在你的浏览器里先压缩为0.90压缩率的webp文件再上传到memos了。

本文 给 memos 加个自动压缩图片为 Webp 的功能 最初发表于 秋风于渭水。

2026-08-20 17:20:47

用 Windows 的同学大概都用过 IDM（Internet Download Manager）。这玩意儿让人又爱又恨：

• 爱它：在各种冷门或莫名其妙的网站上，它的浮动条嗅探音视频是真的好使，随便一点就能把切片或流媒体拉下来。而且它的多线程下载速度比浏览器和基于 Aria2 的下载工具要快。为了这个功能，浏览器的 IDM Integration Module 扩展就必须常驻开启。
• 恨它：IDM 的扩展实在太霸道了。它会监听并强行劫持 Chrome 的下载事件。如果你平时和我一样会用到其他带下载功能的扩展，比如用 SingleFile 保存网页、用油猴脚本/扩展批量抓 Pixiv 插画、推特原图或者采集图片，IDM 就横插一脚。结果就是：其他扩展设置的指定存储目录失效、自定义的文件名变成哈希乱码，最后还会全被一股脑扔进浏览器的默认下载路径。

更头疼的是，IDM 主程序的排除机制太难用了，看似一堆规则，却连 blob:、data: 这种内存临时对象都不认——你想给抓图站放行？门都没有。以前为了抓某站图片，我得先手动去关 IDM，抓完再开，一天折腾好几次。

既然 IDM 自己管不住自己，那我就只能在它”捣乱”前把它关掉。扩展市场里倒是有能按规则启停扩展的管理器，但都是综合性的，就为了管一个 IDM 去装个大家伙，属实没必要。于是抽空写了一个没啥技术含量的超轻量级的 Chrome 扩展（Manifest V3），专门用来按需控制 IDM 的启停。

这个小扩展解决了什么？

它通过 Chrome 的 management API 管理 IDM 扩展的开关，实现了以下功能：

规则匹配：打开特定网站时自动关闭 IDM 扩展

在选项页里可以填入由其他扩展负责批量抓取或存档的域名（如 pixiv.net、x.com 等，我都有更专业更好用的下载扩展/脚本，没必要调用 IDM 下载）。只要浏览器中有任意标签页打开了这些网址，扩展就会在后台静默禁用 IDM，保证抓图/打包扩展正常走浏览器原生下载机制并保留文件名与路径。当关掉所有相关标签页后，IDM 会被自动重新开启。说白了，这功能适合固定站点——像 Pixiv、推特这种你常年要抓且你有比 IDM 更好的抓取扩展的地方，配一次规则就再也不用管了。

快捷键与单击切换：应对随手存网页

我习惯用 SingleFile 扩展把看到的有意思的文章原样抓下来存档，因为这种抓取情况会在随机网站上发生，不适合用规则匹配。所以设计了一个手动快捷启动机制，遇到这种场景，可以直接按快捷键 Alt + Shift + D（快捷键可以在 chrome://extensions/shortcuts 里修改），或者鼠标左键直接点一下固定在工具栏的扩展图标，就能一键关闭 IDM；存档完毕再点一下就能切回去。比手动去 chrome://extensions/ 页面折腾一整套——找到 IDM、关掉、切回存档页、存档、再切回来打开——要方便不少。

图标状态实时反馈

为了不让工具栏多一个毫无信息量的静态图标，扩展在后台用 Canvas 动态渲染图标状态（最近刚学会的技巧，必须用一下）：

• 开启状态：绿底 + 白色下载箭头，代表 IDM 正在全局接管。
• 禁用状态：绿底白箭头 + 红色禁止圆环与 45° 斜杠（🚫），悬停图标时，提示还会直接显示是哪个标签页触发了自动禁用。

极简部署与代码结构

整个扩展就 4 个文件：

idm-smart-controller/
├── manifest.json   # 扩展必须的声明文件
├── background.js   # 标签页监听、动态图标绘制、IDM 状态自动切换
├── options.html    # 设置页
└── options.js      # 设置保存与同步机制

Chrome/Edge 扩展本地安装方法

1. 去「蓝奏云」或者「GitHub Release」下载打包好的扩展

2. 把文件解压放在一个本地文件夹内（比如 D:\Extensions\idm-smart-controller，这个文件夹以后别删，删了扩展就失效了）。

3. 打开 Chrome 地址栏访问 chrome://extensions/，打开右上角 “开发者模式”。

4. 点击 “加载未打包的扩展程序”，选中文件夹即可。

5. 右键点击扩展图标 -> “选项”，配置你的抓图/白名单域名。

Firefox 扩展本地安装方法

1. 去「蓝奏云」下载打包好的扩展

2. 把文件解压放在一个本地文件夹内（比如 D:\Extensions\，这个文件夹以后别删，删了扩展就失效了）。

3. 找到 Firefox 的安装目录（默认通常为 C:\Program Files\Mozilla Firefox\）

4. 在该目录下新建一个名为 distribution 的文件夹：C:\Program Files\Mozilla Firefox\distribution\，把刚才解压的压缩包里的policies.json文件复制进去

5. 打开policies.json文件，把"install_url": "file:///D:/Extensions/idm-smart-controller-firefox.xpi"改成你实际把xpi文件放置的位置，注意这里用的是/，而不是window是下常见文件路径\

6. 重启Firefox浏览器，点击扩展图标 -> “选项”，配置你的抓图/白名单域名。

7. 没办法，Firefox规定只有使用企业扩展安装的签名后的扩展才有权限控制其他扩展的开关，所以只能整的如此复杂。

PS：因为最初设计就是为了应对 IDM，所以叫「IDM 智能管理器」，但其实你可以在设置页里选择其他扩展，让「IDM 智能管理器」根据规则管理其他扩展的开关。至于为什么不上架商店——要过审核还得配隐私政策、商店截图，就这么个解决小痛点的小扩展，不值得折腾。你看我连扩展的图标都没做，工具栏图标是直接用代码生成的。

扩展的代码量非常小，纯粹是为了解决浏览器下载扩展间互相打架的”小问题”。如果你也经常被 IDM 乱截胡导致抓图、网页存档时文件名乱码，不妨一试「IDM 智能管理器」这个小扩展。

本文 IDM 扩展老劫持下载、下载文件名乱码？我写了个小扩展让它按需开关 最初发表于 秋风于渭水。

2026-08-18 18:18:06

最近估计不少用宝塔面板的小伙伴，升级到 13.0.0 之后，发现「Nginx 免费防火墙 8.3」突然故障了。表现为：无法查看网站日志，无法查看封锁历史，webshell 查杀结果显示异常。

省流：直接点「这里」看如何修复

升级宝塔面板 13.0.0 后，Nginx 免费防火墙为什么全是 undefined

基本 Nginx 免费防火墙面板里所有涉及日志显示部分的功能都会是类似上图的效果，一堆 undefined，涉及对应项的按钮一点就报错。

其实造成这个 Bug 的原因非常简单：Nginx 免费防火墙 8.3 是基于 Python 3.8 写的，宝塔面板升级到 13.0.0 后，系统运行环境从 Python 3.8 升级到了 Python 3.13。而 Python 3.13 完全移除了整个 cgi 标准库，导致了 Nginx 免费防火墙 8.3 的日志解析崩溃和日志格式越界报错。于是我就拉着 Gemini 3.7 Flash 一起把这个 Bug 修了一下，把整个防火墙都改成了 Python 3.13 兼容版。

宝塔 Nginx 免费防火墙 8.3 修复补丁：下载与安装

• 补丁下载地址：蓝奏云
• 安装步骤：
  1. 先备份 /www/server/panel/plugin/free_waf 路径下的 free_waf_main.py 与 fail2ban_main.py 文件。
  2. 用压缩包里的 free_waf_main.py 与 fail2ban_main.py，替换掉 /www/server/panel/plugin/free_waf 路径下的同名文件。
  3. 刷新宝塔面板的 Nginx 免费防火墙页面，确认日志不再显示 undefined，封锁历史和 webshell 查杀结果恢复正常。

搞定，收工，Nginx 免费防火墙 8.3 已经可以在 Python 3.13 环境下正常工作了。

修复补丁到底修了什么东西

这些全是代码，如果不关心到底怎么改，只想修复问题的，可以关闭浏览器标签页了（当然要是能留言给个好评就更好啦）

1. 替换 Python 3.13 已移除的 cgi 模块（free_waf_main）

• 原始代码：

  import cgi
  text2 = cgi.escape(str_convert, quote=True)
  tmp_data = json.loads(cgi.escape(line))
  

• 补丁代码：

  import html
  text2 = html.escape(str_convert, quote=True)
  tmp_data = json.loads(html.escape(line, quote=False))
  

• 修了什么：

  Python 3.13 彻底移除了整个 cgi 标准库，原版代码依赖 cgi 解析日志数据，所以在系统环境升级到 Python 3.13 后就开始大量报错。（这就是最开始截图中故障现象的成因）补丁给它改成用标准库 html.escape了，并在解析 JSON 数据前指定 quote=False，避免双引号被转义破坏 JSON 数据结构。

2. 修复二进制读取日志末尾换行符判断失效（free_waf_main）

• 原始代码：

  fp = open(path, 'rb')
  buf = ""
  try:
    fp.seek(-1, 2)
  except:
    return []
  if fp.read(1) == "\n":
    fp.seek(-1, 2)
  

• 补丁代码：

  fp = open(path, 'rb')
  buf = ""
  try:
    fp.seek(-1, 2)
  except:
    fp.close()
    return []
  if fp.read(1) == b"\n":
    fp.seek(-1, 2)
  

• 修了什么：作者一开始就写错了，在 Python 3 中以二进制模式（'rb'）读取返回的是 bytes 字节类型，所以 b'\n' == "\n" 永远都是 False，导致程序在倒序解析日志时，对末尾换行的判断是无效的，会导致日志出现一个莫名其妙的空行。补丁改为 b"\n"。

3. 规范正则表达式 Raw 字符串前缀（fail2ban_main & free_waf_main）

• 原始代码：

  # fail2ban 与 free_waf 中都包含大量类似这样的反斜杠转义的正则表达式字符串
  rep_ip = "^(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}($|[\/\d]+$)"
  rep = "\nPort\s+(\d+)"
  if re.search("\d+.\d+.\d+.\d+-\d+.\d+.\d+.\d+$", i):
  

• 补丁代码：

  rep_ip = r"^(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}($|[\/\d]+$)"
  rep = r"\nPort\s+(\d+)"
  if re.search(r"^\d+\.\d+\.\d+\.\d+-\d+\.\d+\.\d+\.\d+$", i):
  

• 修了什么：其实原来我也喜欢他这样写，直到 Python 3.12 开始对无效转义序列（如 \d、\s）抛出 SyntaxWarning: invalid escape sequence 警告，我才不得不乖乖用正规写法。什么意思？就是 \d、\s、\w 是正则表达式的语法，不是 Python 字符串的语法。对 Python 语法而言，这些都是非法的转义字符，只不过之前 Python 不会直接报错，而是进入容错回退机制，原样保留反斜杠和后面的字符继续传递，所以之前不会显式报错。补丁统一增加了 r"" 前缀，告知解析器（后面的正则）是个 Raw 字符串。

4. 修复 SSH 默认端口解析的空指针崩溃（fail2ban_main）

• 原始代码：

  def _check_ssh_port(self):
      rep = "\nPort\s+(\d+)"
      c_file = "/etc/ssh/sshd_config"
      c = public.readFile(c_file)
      if not c:
          return False
      result = re.search(rep, c)
      if not c:
          return "22"
      return result.group(1)
  

• 补丁代码：

  def _check_ssh_port(self):
      rep = r"\nPort\s+(\d+)"
      c_file = "/etc/ssh/sshd_config"
      c = public.readFile(c_file)
      if not c:
          return "22"
      result = re.search(rep, c)
      if not result:
          return "22"
      return result.group(1)
  

• 修了什么：如果 SSH 配置文件未显式配置自定义端口（即 Port 字段被注释掉了，SSH 按默认规则使用 22），那 result 就为 None，这时候调用 result.group(1) 会直接触发报错，导致模块崩溃。

5. 去除对第三方库 IPy 的依赖（free_waf_main）

• 原始代码：

  from IPy import IP
  ip2 = IP("{}/{}".format('.'.join(ip), ip_ddd))
  return self.is_ip_zhuanhuang(str(ip2[0]), str(ip2[-1]))
  

• 补丁代码：

  import ipaddress
  net = ipaddress.ip_network(ip, strict=False)
  return self.is_ip_zhuanhuang(str(net.network_address), str(net.broadcast_address))
  

• 修了什么：移除对外部第三方模块 IPy 的依赖，改用 Python 内置的 ipaddress 标准库，避免在面板独立虚拟环境升级或重置时因缺失依赖包导致 ModuleNotFoundError。

其他次要修改点

• 解禁黑名单类型匹配错误修复：修正 fail2ban_main.unban_ip 读取黑名单配置时漏传 l=1 参数导致空文件被初始化为字典类型、进而引发 conf.remove() 异常的问题。
• 统一 API 返回方法大小写：将 fail2ban_main._check_get_args 中混用的 public.ReturnMsg 统一纠正为标准的 public.returnMsg，避免高版本基础库抛出方法不存在错误。
• 安全性重构：将 fail2ban_main.set_anti 中的 eval() 动态拼接执行重构为更安全的 getattr() 反射调用。
• 升级构建指令兼容：将 fail2ban_main.update_fail2ban 中已在 Python 3.12+ 废弃的 python setup.py install 升级为 python3 -m pip install .。
• 日志返回容错与防白屏：在 free_waf_main.get_safe_logs 捕获异常时统一返回空列表 []（而非错误字符串），防止前端 JavaScript 遍历报错引发面板页面白屏。
• 文件读写编码与文件描述符保护：将源码扫描与蜘蛛日志的裸读统一改为 with open(..., encoding='utf-8', errors='ignore') 上下文管理器，规避编码异常与文件描述符泄漏风险。

本文 宝塔面板升级 13.0.0 后 Nginx 免费防火墙全是 undefined？替换两个文件就好 最初发表于 秋风于渭水。

2026-08-17 18:16:03

DeepSeek 8 月 17 号开始全面涨价，最高涨了 12 倍，以前每个月是几杯瑞幸的钱，现在直接变成外面一顿正经饭。看大家也都发了很多文章，我也谈谈我这个业余个人开发者的感受吧。最近在 Agent 场景下对比了一圈 V4 Pro、Gemini 3.7 Flash、Hy3 还有 Qwen3.7 Plus，发现未来我大概率要把 DeepSeek 换掉了。

先算笔账：DeepSeek 涨价后个人开发者的 API 成本

价格单位均为 ¥/百万 tokens。

五款大模型 API 价格横向对比

Agent 场景里，模型到底该怎么选

DeepSeek 这个价格吧，倒也不是说用不起，我估计一个月也就大几十块到一百多的量，但是两位数和三位数的心理预期可就差远了，之前就几杯瑞幸的钱，现在直接上升到外面正经的一顿饭了。

涨价一出来，对比自然就来了

• DeepSeek V4 Pro：在 Agent 工具里的表现（自动浏览、PPT、Web 前后端、文案制作），也就和 Gemini 3.7 Flash 差不多。但白天 DeepSeek V4 Pro 比 Gemini 3.7 Flash 还要贵，晚上空闲期的价格，也没拉开差距。我算了一下，我用北美豆包的 Gemini 3.7 Flash 反而比 DeepSeek V4 Pro 好很多，不但更加便宜，任务完成的速度也快很多。

• DeepSeek V4 Pro：不如去用 Hy3，DeepSeek V4 Flash 现在的综合成本是 Hy3 的 2 倍，但实际体验并不值这 2 倍的价差。除非我把任务全扔到晚上去跑，但这不现实啊。

个人 Agent 场景下对”成本和速度”是极其敏感的，借用小众软件的对比图

速度才是 Agent 的命门：TPS 与 TTFT

Agent 工作起来是串行依赖的（调用工具 → 等待回复 → 规划下一步），跑完一个工作流往往就是几次、几十次的循环请求。如果模型生成速度（TPS）或首字延迟（TTFT）不够快，整个交互过程的等待时间是直线飙升。一轮交互慢20秒，10轮就是3分钟多钟了，复杂任务几十轮交互是常态，速度是 Agent 的命门啊——北美豆包的 Gemini 3.7 Flash 在整体能力略超 DeepSeek V4 Pro 的前提下，Gemini 3.7 Flash 的生成速度（TPS）几乎是 DeepSeek V4 Pro 的 4 倍，首字延迟（TTFT）更是只有 DeepSeek V4 Pro 的三分之一（以上都是思考开到高的情况）。而且价格还比 DeepSeek V4 Pro 综合成本便宜一点。北美豆包还是原生支持多模态的，用DeepSeek V4 Pro还不如去用 Gemini 3.7 Flash 了。

日常小活儿，便宜比聪明更重要

到了日常琐碎小任务的范畴，之前 DeepSeek V4 Flash 几毛钱做出来和现在 1 块多做出来，看似就涨了 2 倍不到，但感觉上完全不一样了。而且很多重复性任务并不需要模型具备顶尖的能力，只要模型智商合格，能遵循指令、结构化输出稳定、够便宜、速度还行就可以了。我他喵的不如去用腾讯的 Hy3 或者阿里的 Qwen3.7 Plus，大部分小任务这俩也能搞出满足需求的结果。现在 Hy3 在 WordBuddy 里免费，但他就算收费也比 DeepSeek V4 Flash 便宜。Qwen 虽然贵了点，但是 Qwen3.8-27B 量化后可在单张消费级 GPU 跑，成本就等于只剩电费了（况且这电费是公司掏也不是我掏）。

我的结论：DeepSeek 暂且出局，主力先切到 Hy3 和 Gemini 3.7 Flash。

感觉 DeepSeek 未来要么再搞个低价模型，要么出订阅套餐，不然大模型 API 性价比在 Agent 工具领域完全没竞争力。很多日常任务其实不需要 AI 那么聪明，只需要一个智商合格、够快够便宜的模型。反正我现在已经把主力切到 Hy3 和 Gemini 3.7 Flash 了，这俩搞不定的任务晚上交个打折的GLM5.2和Kmi-K3，实在搞不定的任务还有claude-opus-4-8和GPT-5.6呢是不。

本文 DeepSeek 涨价后，业余个人开发者的 API 成本开始肉疼了 最初发表于 秋风于渭水。

2026-08-13 21:41:13

作为一个技术博主，虽然我只要出了新的 Agent 工具都会去试试，却一直没写文章给大家介绍过，一个是因为懒，另一个是这些工具要么功能不够用不值得介绍，要么好用是好用但是入门门槛有点高，能用爽的人都是技术大佬，也犯不上我来介绍。

月初被腾讯家 WorkBuddy 的广告再一次刷屏（我 5 月初曾经短暂体验过 2 天，当时体验不太好就又卸载了），于是就重新装回来体验了一下，高强度用了这么一周多。发现这是目前最适合普通人用的本地办公 Agent 工具。

先说清楚这不是软文，腾讯的软文推广活动早结束了，以及这几个定语每个都有限定意义：目前（AI 目前迭代太快了）、普通人（不是技术大佬）、本地（本地运行为主，不是云端）、办公（也能用来写代码，但软件界面完全不适合写代码）。

WorkBuddy 是什么：腾讯的 AI 办公智能体

腾讯官方的定义：WorkBuddy 是腾讯云推出的 AI 办公智能体（AI Office Agent）。给定一个指令，它会编排虚拟专家、技能和工具团队，把研究、文档、数据等日常工作从策略到交付一站式完成。

也就是腾讯给出的核心能力是”执行并交付结果”，不只是回答问题。

一、核心功能

知识库 / RAG

这是我觉得 WorkBuddy 比别家强最多的地方。能把行业规范、法律文本、工作总结这类文档直接传进去，向量化固化成一个随时可调用的知识库（说白了就是 RAG），写东西时自动引用，出来的文案既符合规范又准确。好处是不用每次重新教 agent 一遍规则，也不用把规范硬塞进 agent 里把体积撑爆。我自己传了 30G 的 PDF 进去（默认 WorkBuddy 的知识库只有 5G 空间，我是利用 IMA 的50GB 空间实现的），攒了个行业规范和标准图库，给部门搭了一套文档合规性审查工具——咋说呢，AI 比很多审图公司看得都准……而且它跟 IMA 知识库原生打通，腾讯文档、乐享的资料也能直接接进来。

IMA 团队堪称腾讯良心产品，知识库免费给 50GB ，学生/教师认证可以免费 100GB。别家这么大的文档量化库，一月起码收你 20、30 块，可能还要额外掏调用费用，腾讯直接免费给了。而且 IMA 提供了 免费的 GLM 5.2，智谱家的 Coding Plan 官方订阅名额有多难抢懂得都懂。

专家团

其实就是“子代理”，允许多个智能体 agent （腾讯这里叫“专家”）分工一起干活，把复杂任务自动拆成多个子任务，派不同专长的子代理同时干，最后汇总。比如让他写一份报告 PPT ，一个 agent 查资料、一个 agent 分析数据、一个 agent 写稿，比自己来回折腾快得多，也比做一个多面手 agent 效果要好。软件直接内置了据说几百个专家，什么运营、设计、数据、开发、财务都有，技能市场据说有上万个现成技能。

模型随便切+可用自己的模型

内置混元 Hy3、GLM-5.2、MiniMax-M3、Kimi-K3、DeepSeek-V4 等国产主流模型，一键切换；还支持自定义模型接入自己的 API（调用自定义模型不消耗订阅积分）。不锁死自家模型，在国产工具里属实少见。（不过可能很大一部分原因是：腾讯自己的混元确实太不行）

本地文件操作 + 沙箱

直接读写你电脑上的文件，批量重命名、格式转换、表格处理都能交代给它。Ask/Plan/Craft 三种模式控制 AI 介入深度，工作空间限定在指定文件夹，删除文件这类高危操作弹窗二次确认，你也可以直接关了联网权限。

定时任务

后台自动化和等待会走的是本地 cron 激活——到点唤醒、跑完收工，不是让模型一直挂在后台循环执行，省 token。

多模态兜底

内置的模型支持多模态兼容，你选的模型不认图（比如 deepseek-v4-flash），它会自动调其他支持的模型帮忙，不用自己来回切。

二、和别的 Agent 比：WorkBuddy 对比 Kimi Work、扣子 3.0

按”普通人 + 办公”这个标准，说一下友商的热门 Agent 工具。

OpenClaw：开源自托管，跑自己设备上，自带 API key，主打连各种聊天软件当私人管家，GitHub 35 万 star。但装环境、配 key、走 onboarding、找 Agent 和 Skill 这一套下来，能用爽的都是开头说的那类技术大佬。（主打长任务、多渠道接入）

Hermes Agent：Nous Research 出的开源 Agent，MIT 免费。特点是”越用越聪明”，每次任务后自动总结经验、生成技能，下次直接复用。学习闭环确实牛逼，但同样也是自托管、偏终端和开发者场景，非技术用户不太好玩转。（主打长期记忆、技能沉淀）

Kimi Work：看名字就知道是谁家旗下的，得益于 kimi 模型本身给力，Kimi Code 用来写代码还是很爽的，但是用于 Work 的话，主要是 Agent 和 Skill Hub 做得不太行，对于技术博主没问题，对一般人没那么好用，以及你只能用 Kimi 自家的模型。（更像是 Kimi Code 换了一个特化的 GUI）

千问办公：看名字就知道是谁家旗下的，跟 WorkBuddy 很像，功能够用，最大问题点是，模型你只能选 「Qwen3.8-Max/高级/基础/经济」。但是现在 Qwen 大模型的能力，哎，一言难尽啊。（是 QoderWork、悟空、MuleRun 三款产品合并后的产物，目前开发更侧重已经在用钉钉的企业，价格也略贵，而且目前居然没多智能体协同功能）

扣子 3.0。字节的，但我感觉它更偏向是一个”造 Agent 的平台”和”AI 短剧制造机”而不是”帮你干活的平台”，你可以写一个 Agent，然后同步到云端的 Claude Code、Codex CLI、OpenClaw、Hermes 里面做实际测试和调整，可以在字节全家桶里实现从文案到 AI 短剧到发布的全流程。它是非常强调云端的，套餐阶层会限制你的本地能力。以及模型只能用它给你的豆包、GLM、Kimi、MiniMax 这几款模型，不能用你自己的。（不适合拿来办公，除非你是搞抖音自媒体运营相关的）

能力对比

价格对比：免费额度与套餐

按连续包年、连续包月等最便宜的订阅价格，折算到每月对比。

价格上补五个关键优点：

1. Hy3 限时免费： 8 月 31 日前不要钱。混元 Hy3 代码水平大概相当于 Kimi-K2.7 和 GLM5.1，Agent 水平和老 DeepSeek-V4-Pro 差不多，但不如新的 DeepSeek-V4-Flash，数学能力就只能说不行，整体和北美豆包坐一桌，不是顶尖，对 Agent 和腾讯自身产品有优化训练，对一般人够用。免费的模型就别客气了，使劲蹬。

2. 内置模型 ≈ 官方价格： GLM-5.2/5.1/5、MiniMax-M3、Kimi-K3/K2.7/K2.6、DeepSeek-V4 这些算下来基本等于对应模型的官方价。不能算贵，也不能算便宜（不算活动送的积分的话），在同类订阅 Agent 里算中等。（发文时的更新：今晚 DeepSeek 大涨价，但发文时内置还是原价）

3. 唯一可以接自己 API 的国产工具： 腾讯也知道自家的混元模型属于主打 Agent 和均衡，你可以自己接自己的模型，而不像国内其他家的，基本只能用内置好的模型。（阿里和 Kimi 只让用自家的，字节知道豆包拉跨但也只内置了 3 个其他模型给你，还他喵的不给最新的版本）意味着你可以用自己的白嫖/低价模型。

4. 内置 DeepSeek 比自定义的便宜： 这里 Pro 是 Flash 的 2.6 倍价格（积分），而 DeepSeek 官方 Pro 是 Flash 的 3 倍价格。这只是个人观察加猜测。用订阅积分调内置 DeepSeek，比直接用自己 API key 的算下来便宜了一点点（大概 3~5%），可能是有针对的上下文压缩和缓存特化。内置的 DeepSeek 更划算。（发文时的更新：今晚 DeepSeek 大涨价，但发文时内置还是原价，这不是划算，是太划算了😂）

5. 套餐价格横比算合适的： 各家这些套餐最低那档基本没法用，纯属锚定心理价格用的，基本真要用都需要开次高那一档，腾讯的 112 这一档是目前各家给得最多的。

三、为什么说适合”普通人””办公”

回到开头的定语。

“普通人”：开箱即用，下载安装登录完事，不用配环境、不用写代码、不用懂 Prompt，连什么是 Skill、什么是 Agent 都不用懂，整理桌面文件、汇总 Excel、写周报、排日程，这些办公自动化的活，全是自然语言直接交代，HR、行政、运营都能上手。

“办公”：这是跟那些开源 Agent 最大的区别。开源那批是给程序员和折腾党用的，办公场景的活是真不熟；WorkBuddy 从设计上就冲着办公来：

• 腾讯生态全家桶。毕竟是腾讯亲儿子嘛，企业微信、微信、腾讯会议、腾讯云、QQ、IMA、腾讯文档、腾讯乐享全部原生打通。要是办公用的就是腾讯系的，你让它去腾讯文档改东西、把会议纪要给企业微信同事、用 IMA 知识库的资料回答问题，都是很好实现。

• 专家团 = 现成的虚拟团队。运营、设计、财务、法务、开发每个角色都有对应专家，任务拆开并行干，最后汇总成报告。

• 定时任务不烧钱。日报周报、竞品监控、数据汇总这类固定跑的活，用本地 cron 激活，跑完收工，成本敏感的场景很实在。

• 本地：桌面应用，跑在你电脑上，数据不出域，能直接操作本地文件。办公场景这点还是很重要的，文件在本地，干活的脚本也在本地，隐私和可控性都好。

• 目前：Agent 工具迭代太快了，今天好用的明天可能被超，今天贵的明天可能降价。我只能说目前它最适合普通人办公用，未来啥样可打不了包票。

四、泼点冷水：但是硬伤也很突出

为了防止被说是软文，下边要说说硬伤了。

1. 价格不算便宜：中等价位（指整体价格），不贵但也不便宜，想白嫖只能靠活动和限免。而且加赠积分一个月有效，中重度使用要算好账。

2. 起步套餐不便宜：如果你只用内置模型的话，开 56 那一档套餐是不太够用的，中重度使用起码需要 112 这个档位，虽然相似额度下 112 的价格比友商的要便宜不少，但 56 这档是绝对不够用的，除非你接自己的模型。但这样 56 那一档给的积分很可能用不完，又显得有些浪费了。

3. 腾讯生态是把双刃剑：你用腾讯办公全家桶，体验起飞；不用的话，那堆”生态优势”跟你一毛钱关系没有，就剩个普通桌面 Agent，而且会被束缚在这个体系内（这些国产办公工具的 Agent 和 Skill 都互相有壁垒，不像开源的可以无缝迁移）。

4. 用起来还是有些小问题：桌面 Agent 生态还在早期，边角功能偶尔抽风，技能市场鱼龙混杂，装技能时睁大眼睛。好在腾讯出品，突然跑路的概率比小厂还是低得多。

5. 高消耗任务烧积分：生成 PPT、解析大文件这种，积分烧得飞快，一个完整的 30 页 PPT，你要是全自动可能需要几百积分。重活建议留到夜间（GLM 目前 23 点到 8 点有错峰折扣）或者用免费的 Hy3 先跑，到关键任务再用收费模型。

从图里可以看出，你要是用 GLM 或者 Kimi 的话，改一次PPT需要的积分还是挺多的。

6. 不确保未来免费功能的范围：自动任务数量、项目成员数量、项目数这些都写的是”限免”。

五、总结：办公 Agent 工具怎么选

我个人体验来说，在面向普通人的办公 Agent 工具这块，WorkBuddy 确实是目前最好用的，不过到底好不好用，主要还是看具体情况：

• 用腾讯办公生态的人：值得试试，这是目前腾讯系办公体验最丝滑的 AI 中枢。

• 一人公司/小团队：专家团 + 自动化，相当于多了个跨职能虚拟团队。

• 技术玩家：可玩，毕竟能自定义模型 + 沙箱 + 本地操作都有，唯一缺点就是做出来的 Skill 和 Agent，不能无缝迁移到开源路线（ OpenClaw / Hermes ）（比如做 Agent 时，如果 Skill Hub 有的技能，不会被主动内置到 Agent 里，导致你分享出去的 Agent 无法在那俩开源框架里直接用，不过你可以写个记忆让他未来都生成通用的版本就行了）。

• 偶尔用的：先蹭免费的 Hy3 呗，别急着交钱，每月送 500 积分，再签签到啥的，省着点用，也够每周写一次文案和 PPT 了。

• 一点点邀请奖励：点这个→邀请链接←注册，并在 7 天内使用 3 天，可以额外获取 50+100 的积分，其实……也没多少积分，所以不想走要积分的也可以点这里的直达链接。

• 咋用就不用教了吧：国产的 AI 工具基本都是开箱即用的，下载，安装，有啥不知道的直接问面前的AI就行。我一直不知道怎么教人用AI，毕竟我感觉，只要会提问，任何人都没 AI 自己教的有耐心和清楚了。

• 如果真要用啊，其实我建议你去 opencode 开个Go订阅接过来用……

本文 WorkBuddy 一周体验：目前最适合普通人的本地办公 Agent 工具 最初发表于 秋风于渭水。

2026-08-10 17:12:31

相信大家可能都听过下边这个经典段子：

语文试卷中问：“窗帘为什么是蓝色的？”

阅读理解答案：“蓝色代表忧郁，窗帘遮住阳光暗讽封建统治下人民生活在黑暗中，作者借此表达对现实社会的不满。”

文章作者本人：“因为窗帘就他妈是蓝色的！”

这个段子通常用来讽刺语文阅读理解中过度解读作者意图的现象——出题人往往将自己的主观解读作为正确答案，并且强迫所有答题者认同其解读才是唯一的。

然而，尽管“窗帘就他妈是蓝色的”是一个客观事实，但仅凭这个事实本身，还并不足以构成作者特意在文章中写下“蓝色的窗帘”这几个字的充分理由。

试想一下：一个人真的会仅仅因为“窗帘本身是蓝色的”，就专门多费笔墨去描写它吗？

• 对于作者来说：写下“蓝色的窗帘”，可能是为了营造某种特定氛围，这是他想主动塑造出的画面细节的一部分；也可能是出于审美偏好，觉得蓝色比绿色或没有窗帘更和谐；甚至可能他就是想要给读者炫耀自家的蓝色窗帘好看。但无论如何，作者绝不可能仅仅因为蓝色窗帘的客观存在，就无理由地将其变成文字。

• 对于读者来说：文章中给读者看到的一切文字都是作者主动选择并展示给读者的。作者是可以选择告诉或不告诉读者窗帘颜色的，甚至选择不写窗帘也可以，比如只写一个“窗台上的那条鱼眼里还闪着一丝诡异的光”也不是不可以嘛。读者的脑子会在现有已知的细节中填补那些未被作者写出的细节。

  当一个作者选择特意告知读者一个细节、特意使用某个词的时候，必然是其写作经验在发挥作用——在作者当时的意识里，只有“蓝色的窗帘”这样的词，才最契合他写下这几个字时的思考，才能精准传达他想表达的意象。

这就引发了一个极具思辨价值的问题：文学作品中的文字，其最终解释权到底属于作者，还是属于读者？

解释权归作者：意图主义与创作初衷

文学批评传统中，通常遵循意图主义（Intentionalism，也有称“作者意图论”），他们认为：文字的含义完全等同于作者在创作时所预期的含义。

这一立场的逻辑根基在于：作者是文字的创造者，创作意图是理解文本的基石，文字不过是作者当下思想的凝固与投影。如果脱离了作者的原始创作意图，文字就只是纸上的墨迹，无法产生确定且唯一的含义。

文字本身是没有意识的符号组合。同样的三个字“你好啊”，可以是真诚的问候，也可以是讽刺的挖苦，甚至只是敷衍的客套。决定这三个字究竟代表什么的，是作者写下这三个字时的创作动机。因此，作者写下这句话时的个人遭遇、时代背景与创作动机，是还原文字”本意”的重要线索。

读者是历史的侦探——阅读的过程，就是排除各种干扰，去还原那个在特定历史时空中手握笔杆或键盘的作者，究竟想向公众传递什么信息。作为最了解创作初衷的人，作者理所当然拥有对其文字最高、最权威的解释权。

解释权归读者：文字的独立宣言与“作者之死”

然而，随着现代文学批评的发展，解释权的重心开始大幅向读者倾斜了。

20世纪中叶的现代文学理论提出：一部作品一旦创作完成，便获得了独立的生命，其含义应由文本自身的结构与语言逻辑决定。

进行文学评论时把作者创作时的意图当成衡量和解释文学作品含义的唯一标准是错误的。因为作品进入公共领域后，作者作为”含义唯一掌控者”的身份就宣告死亡了。也就是罗兰·巴特在《作者之死》中提出的核心观点：文字的诞生是以作者的死亡为代价的。文字含义是在读者的阅读过程中被重新构建的。

而且，如果作者的意图已经成功融入文本，它自然会留在文字中；如果没有体现或体现得不明显，那么事后无论是读者去追问作者“原本想写什么”，还是作者跳出来补充“原本想写什么”，都毫无意义，已不再是文本本身所传达的原意了。

作者与读者各自的认知局限

但是将解释权绝对地归属于作者或读者，在实际应用中都会陷入困境。

作者并非自身意图的全知主宰

• 潜意识与时代局限：作者在创作时会不可避免地受到潜意识、时代背景及自身认知水平的制约，其文字表达的效果往往会超出其主观设想。
• 时间流逝与记忆偏差：作者在作品发表后给出的“补充设定”，并不是必然能凌驾于已成型的文本之上。毕竟时间是往前走的，作者的记忆会随时间模糊，未来的作者不一定能准确还原过去自己创作时的真实心态。
• 动机污染与事后包装：面对后来的环境变迁、利益考量、舆论压力或形象维护需求，作者可能会在事后“撒谎”或“重新包装”创作初衷，甚至以此反咬读者“过度解读”或“抠字眼”。
• 丧失客观分析价值：若允许作者随心所欲地解释自己过去写下的文字（“我现在说它是什么，它就是什么”），那他写下的文字便失去了被客观分析与逻辑讨论的基础。

“一千个哈姆雷特”与过度解读的风险

• 失去客观评价基准：若纯粹以读者的主观感受为最终标准，那么任何断章取义、强行拉踩的行为都可以用“这是我的个人理解”来正名，导致文学批评失去最起码的公共基准。
• 确认偏误与动机污染：读者在解读时也不可避免地会带入自身的经历、立场、偏见乃至当下的热门议题，陷入“拿着锤子看什么都是钉子”的陷阱，强行将文本塑造成自己的代言工具或批判靶子。
• 公共讨论环境的崩塌：当解读彻底沦为“我觉得是，那就是”时，会导致公共讨论与批评体系崩塌，文学评论就只是无意义的纯主观掐架了。

边界在哪：以文字本身为”最大公约数”

对于面向公共领域的文学作品，解读存在三个维度：作者维度、读者维度与文本维度。

1. 作者拥有”创作解释权”与”原始语境权”，但无法垄断文本含义的最终解释权；
2. 读者拥有”再创造解释权”与”体验理解权”，但这种自由必须受到文本字面含义与结构关系的约束；
3. 文本拥有”事实锚定权”与”自身独立性”，其客观存在才是协调作者与读者解释权边界的最大公约数。

解读的客观边界示例

读者解读的边界：

读者的解读固然可以自由，但必须以文本提供的证据为出发点。

假设文章中明确交代窗帘是蓝色的，是因为主角买的时候这个颜色最便宜——从上下文可以看出，作者写下这一笔是为了塑造主角贫寒的背景。

此时，若读者硬要解读为“蓝色代表忧郁，暗讽封建统治的黑暗”，甚至说，这是因为我的立场是蓝营的，在植入狗哨词蓝色，且全文找不到任何逻辑佐证，这就越过了“合理解读”的边界，落入了“过度解读”，乃至“文字狱”的范畴。

作者解释的边界：

作者可以补充文本的遗漏，但也必须基于文本自身的证据，而不能随意篡改或否认已写下的文字。

如果文章中明确写出了沉重的时代背景、压抑的阴影描写以及主人公窒息的心理状态，客观上构建了一个完整的隐喻修辞。

而面对读者精准的分析，作者出于政治安全或形象维护的考量，在公开场合“反咬”读者：“因为窗帘就他妈是蓝色的！没有任何其他意思！你们这群人就是在过度解读！”此时，作者事后的自保性否认并不能抹去文本客观呈现的效果。

延伸：现实语境中的”解释权逃避术”

从文学批评延伸到现实生活，文本解释权的博弈在公共舆论中同样屡见不鲜。

在社论、政论及脱口秀等自媒体传播中，创作一方往往占据着天然优势——因为他们不仅握有作者的初始解释权，还能随时切换为“读者”视角（将自己的观点输出重新包装为”对现实现象的客观观察”）。

这种双重身份使得部分创作者频繁运用各种自媒体话术与语言诡辩技巧：

• 可合理否认性：特意留下模糊空间，以便在遭遇批评时随时退守到最无害的字面解释；
• 狗哨玩法：向特定受众传递隐秘信息，面向公众时则坚决否认该意图，并反咬一口说对方敏感了/过度反应了/文字狱了；
• 视角滑移与概念转换：在客观事实与主观解读之间随意穿梭，将文字中具体的逻辑错误偷换为抽象的哲学探讨或主观观察视角的差异；
• 动机投毒：把“对该观点的反驳”提前定义为“被说中的人才会气急败坏”或“某利益集团被揭露后的洗地”；
• 选择展示事实（断章取义）：只呈现符合自己预设结论的部分事实，隐去关键的前因后果，利用“部分事实”来达成本质上的“整体谎言”；
• 身份双标：在输出观点时扮演“深刻的社会观察者/正义发声者”；一旦面临逻辑打脸、事实核查或舆论风险，瞬间缩回“只是开玩笑/只是个段子/只是戏剧化表达/只是文学修辞手法”的壳子里；
• 单向豁免权：对自己“你不能因为一个人在不同阶段有不同的想法，就说他是不真诚的，或者说他在打自己的脸。”对别人狠狠出击；

通过利用信息不对称与语言天然的模糊性，发言者得以巧妙地在讨论争议性话题时一边用煽动性极强的语言来博取流量、建立人设，一边利用诡辩技巧规避自身言论应承担的公共责任。文本解释权的归属问题，也由此从纯粹的文学理论探讨，变为了现实传播中关于文字责任与诚信的深刻博弈。
正如大家常调侃的：“科学家的前后不一致叫修正假说，商人的前后不一致叫利益驱动，自媒体的前后不一致叫防御策略。”如果未来有新的机缘的话，再展开说说利用了这些诡辩技巧的经典案例吧。（新建md文档……）

PS：搓了一个新的改错字/语法Skill，以免让AI改错字和语法时自作主张的修改我原有的语义，好消息：这玩意确实不再瞎改我的语义了（之前会在修改语法错误时有可能把语义改了）。坏消息：这玩意会把我所有的中文引号全替换为英文单/双引号。

本文 “窗帘为什么是蓝色的？”：文学作品的最终解释权，到底归谁？ 最初发表于 秋风于渭水。