鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长：程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
6
3
3

别急着装 Hermes Agent：Windows 上这 7 个坑，我替你踩完了

兮动人
兮动人
2026-08-24 01:43
阅读 1625
兮动人
2026-08-24 01:43
阅读 1625

欢迎关注我的公众号【兮动人】，每天分享一些技术文章和实战经验。

从安装目录、安全软件、GitHub 代理，到 402 额度、模型列表和“只会说英文”的真相。这不是一份照着官网抄的教程，而是一份真实的排错复盘。

公众号封面

我原本以为，这件事最多十分钟：下载一个 Windows 安装包，填入 API Key，然后开始聊天。

结果整整绕了一大圈。

安装器默认往 C 盘写，界面又没有选择目录；GitHub 在浏览器里明明能打开，安装脚本却一直超时；腾讯电脑管家已经加了信任区，uv 生成的临时程序还是运行失败；好不容易装完，Hermes 的模型列表里只有一个 Hy3；手动切到一个仍有额度的模型后，它倒是不报错了，却无论我说什么都只回一句英文：

I'm ready to help! What would you like me to assist you with?

最后真正跑通时，Hermes 被完整安装在 E:\Hermes，模型接入腾讯 TokenHub，并且可以在 qwen3.5-plus 和 qwen3.5-flash 之间切换。

回头看，最浪费时间的并不是报错本身，而是几个很容易混在一起的概念：安装包的位置不等于安装目录；浏览器能访问 GitHub 不等于 Git 能访问；账号有额度不等于当前服务有额度；配置文件改了不等于当前会话已经切换。

这篇文章就把这几个坑一次讲清楚。

一、Windows 安装包和 PowerShell 安装，到底有什么区别？

Hermes 官网同时提供 Windows 安装包和 PowerShell 安装方式。

Hermes 官方安装说明

Hermes Windows 下载入口

表面上看，它们像是两套完全不同的安装方案。实际跑过日志后会发现，Windows 安装包更像一个图形化的 bootstrapper（引导安装器）：

  1. 下载 install.ps1；
  2. 安装或检测 uv、Python、Git、Node.js；
  3. 获取 Hermes 仓库；
  4. 创建虚拟环境并安装依赖；
  5. 构建桌面应用；
  6. 写入配置并启动后端。

所以，两者安装出来的核心 Hermes 并没有本质区别。差异主要在体验：安装包有进度界面，PowerShell 更透明，也更容易传入环境变量和观察报错。

我的建议是：

  • 想省事，可以用 Hermes-Setup.exe；
  • 想改安装目录、配置代理或排错，最好从 PowerShell 启动安装包；
  • 普通用户权限通常就够了，不必一开始就用管理员 PowerShell。

二、第一个坑：安装包放在 E 盘，不代表 Hermes 会装在 E 盘

我的安装包位于：

▼
text
复制代码
E:\浏览器下载\Hermes-Setup.exe

但直接双击，Hermes 仍会使用默认目录。真正决定数据、配置、运行时和仓库位置的，是环境变量 HERMES_HOME。

我最后成功安装到 E 盘时，实际执行的是下面这组完整命令。它不只指定了 Hermes 的安装目录，还把安装过程中用到的临时文件放到了 E 盘，并让 Git/Python、npm 和 Electron 下载器都走同一个代理：

▼
powershell
复制代码
$proxyUrl = 'http://127.0.0.1:7897'
$targetPath = 'E:\Hermes'
$tempPath = 'E:\HermesTemp'

New-Item -ItemType Directory -Path $tempPath -Force | Out-Null

$env:HERMES_HOME = $targetPath
$env:TEMP = $tempPath
$env:TMP = $tempPath

# Git、Python 和普通网络请求
$env:HTTP_PROXY = $proxyUrl
$env:HTTPS_PROXY = $proxyUrl
$env:ALL_PROXY = $proxyUrl
$env:NO_PROXY = 'localhost,127.0.0.1'

# npm
$env:npm_config_proxy = $proxyUrl
$env:npm_config_https_proxy = $proxyUrl

# Electron 下载器
$env:ELECTRON_GET_USE_PROXY = '1'
$env:GLOBAL_AGENT_HTTP_PROXY = $proxyUrl
$env:GLOBAL_AGENT_HTTPS_PROXY = $proxyUrl
$env:GLOBAL_AGENT_NO_PROXY = 'localhost,127.0.0.1'

Start-Process -FilePath 'E:\浏览器下载\Hermes-Setup.exe' -Wait

这段命令可以整段复制到 PowerShell 运行，不要求管理员权限。7897 是我当时本机代理软件监听的端口，其他人照着操作时，要换成自己代理软件显示的端口；如果网络可以直接访问 GitHub，也可以删掉所有代理相关的环境变量，只保留安装目录、临时目录和最后一行启动命令。

安装成功后，目录大致会变成：

▼
text
复制代码
E:\Hermes\
├─ bin\
├─ node\
├─ logs\
├─ sessions\
├─ config.yaml
├─ .env
└─ hermes-agent\

日志也证明，便携版 Node.js、uv、Python 虚拟环境和 Hermes 仓库都被放进了这个根目录。

可以用下面的命令检查用户级环境变量是否已经保存：

▼
powershell
复制代码
[Environment]::GetEnvironmentVariable('HERMES_HOME', 'User')

这里最容易产生的误解是：安装包在哪个盘，和软件最终安装在哪个盘，没有必然关系。

三、第二个坑：浏览器能打开 GitHub，安装器照样可能连不上

安装日志里先后出现了三种情况：

▼
text
复制代码
git@github.com: Permission denied (publickey)
Could not resolve host: github.com
Failed to connect to github.com port 443

Hermes 安装器会先尝试 SSH，再尝试 HTTPS，失败后还可能退回 ZIP 下载。因此，你可能看到浏览器能打开仓库，但安装器仍然卡在“Cloning Hermes repository”。

原因很简单：浏览器、Git、PowerShell、Node/Electron 不一定共用同一套代理设置。

如果本机代理监听在 127.0.0.1:7897，可以在启动安装器前设置：

▼
powershell
复制代码
$proxy = 'http://127.0.0.1:7897'
$env:HTTP_PROXY  = $proxy
$env:HTTPS_PROXY = $proxy
$env:ALL_PROXY   = $proxy

git config --global http.proxy  $proxy
git config --global https.proxy $proxy

一个很反直觉的细节：HTTPS_PROXY 的值仍然可以是 http://127.0.0.1:7897。前面的 http:// 描述的是“如何连接本地代理”，不是目标网站只能使用 HTTP。

如果以后不再需要 Git 全局代理，可以清理：

▼
powershell
复制代码
git config --global --unset http.proxy
git config --global --unset https.proxy

这次安装过程中，Git 仓库最终能拉取，Electron 依赖也能继续下载，才算真正解决了网络问题。

四、第三个坑：信任了安装目录，安全软件仍可能拦截临时 EXE

真正让我反复重装的是这段错误：

▼
text
复制代码
Failed to update Windows PE resources
uv-trampoline-xxxxx.exe
系统无法打开指定的设备或文件

它先发生在创建虚拟环境阶段，后来又发生在安装 Python 包阶段。共同点是：失败对象都是 uv 临时生成的 uv-trampoline-*.exe。

一开始我把 E:\Hermes 和 E:\HermesTemp 加进腾讯电脑管家的信任区，以为这样就够了。

但信任区并不一定覆盖所有临时目录、进程行为和实时防护策略。更麻烦的是，电脑管家的实时防护服务并不好直接停止。

腾讯电脑管家实时防护服务无法直接停止

最终，在完全退出乃至卸载电脑管家后，同一阶段顺利通过。后续日志显示：

▼
text
复制代码
Creating Python virtual environment ... Succeeded
Installed 100 packages
All dependencies installed

这并不意味着所有人都必须卸载安全软件。更稳妥的排查顺序是：

  1. 先退出实时防护；
  2. 同时信任 Hermes 根目录和系统临时目录；
  3. 重试并观察是否仍卡在同一个 uv-trampoline 文件；
  4. 如果依旧失败，再考虑临时卸载，安装完成后重新启用系统防护。

还有一点：失败后不必立刻手工删除整个目录。Hermes 安装器会把不完整的仓库移动为类似：

▼
text
复制代码
hermes-agent.broken-20260803-154541

保留这些目录，反而有助于回看失败现场。盲目清空目录，会把日志和证据一起删掉。

五、别猜，先看这四份日志

这次排错最有价值的经验，是把问题按层次拆开，而不是盯着弹窗猜。

Hermes 排错流程图

Windows 版 Hermes 的关键日志位于：

▼
text
复制代码
E:\Hermes\logs\bootstrap-installer.log
E:\Hermes\logs\agent.log
E:\Hermes\logs\errors.log
E:\Hermes\logs\desktop.log

它们分别回答不同问题：

  • bootstrap-installer.log：安装卡在哪个阶段；
  • agent.log：请求实际用了哪个 provider、model 和 endpoint；
  • errors.log：接口错误、堆栈和 HTTP 状态码；
  • desktop.log：桌面后端是否正常启动。

常用查看方式：

▼
powershell
复制代码
Get-Content 'E:\Hermes\logs\bootstrap-installer.log' -Tail 120
Get-Content 'E:\Hermes\logs\agent.log' -Tail 160
Get-Content 'E:\Hermes\logs\errors.log' -Tail 120

只要抓住四个字段，很多问题会立刻变简单：

▼
text
复制代码
stage=
provider=
model=
HTTP xxx

六、第四个坑：腾讯账号“有额度”，不等于当前模型服务有额度

安装完成后，我在 Hermes 中配置了腾讯 TokenHub：

▼
yaml
复制代码
model:
  provider: tencent-tokenhub
  base_url: https://tokenhub.tencentmaas.com/v1
  api_mode: chat_completions

API Key 应保存在 Hermes 设置或本地 .env 中，不要贴进聊天记录，也不要写进截图。

当时 Hermes 默认只显示 Hy3，发送消息后返回 HTTP 402：

▼
text
复制代码
The free trial quota for the service has been exhausted

我第一反应是：腾讯 TokenHub 的免费额度是不是全部用完了？

打开控制台才发现并不是。hy3 服务已经停止且额度为 0，但其他服务仍在运行，并且各自拥有独立额度。

腾讯 TokenHub 各在线推理服务的额度相互独立

所以，HTTP 402 不能只看“账号”两个字，必须结合日志里的具体模型：

▼
text
复制代码
Provider: tencent-tokenhub
Model: hy3-preview

这次耗尽的是 hy3-preview 对应的服务，不是整个 TokenHub 账户。

七、第五个坑：腾讯控制台有模型，Hermes 下拉列表里却没有

腾讯控制台里明明有：

▼
text
复制代码
hy-mt2-pro
hy-mt2-lite
qwen3.5-flash
qwen3.5-plus

但 Hermes 模型列表最初只有一个 Hy3。

Hermes 当时只列出了 Hy3

点击“刷新模型”也没有用。原因是 Hermes 的下拉列表依赖自己的 provider 模型目录和缓存，并不会完整枚举腾讯控制台里所有自定义在线推理服务。

这时不要被下拉列表卡住，可以直接在 Hermes 消息框输入：

▼
text
复制代码
/model qwen3.5-flash --provider tencent-tokenhub --global

切换到 Plus：

▼
text
复制代码
/model qwen3.5-plus --provider tencent-tokenhub --global

这里有两个细节特别重要。

第一，正确语法是“模型名”和“提供方”分开写：

▼
text
复制代码
/model <服务ID> --provider <提供方> --global

不要写成：

▼
text
复制代码
/model tencent-tokenhub:qwen3.5-flash --global

Hermes 可能会把整段 tencent-tokenhub:qwen3.5-flash 当成模型名，结果提示模型不存在。

第二，--global 会更新全局默认配置，但已经打开的会话可能仍固定在旧模型。判断是否真的切换成功，不要只看 config.yaml，还要看右下角当前会话的模型标签。

如果右下角仍是旧模型，就在这个会话里再执行一次 /model 命令。

直接编辑配置文件当然也可以：

▼
yaml
复制代码
model:
  default: qwen3.5-flash
  provider: tencent-tokenhub
  base_url: https://tokenhub.tencentmaas.com/v1
  api_mode: chat_completions

直接修改 config.yaml 中的默认模型

但要记住：改配置文件解决的是“以后默认用什么”，/model 命令解决的是“当前会话现在用什么”。

八、第六个坑：接口返回 200，不代表这个模型适合 Hermes Agent

在 hy-mt2-pro 还有大量额度时，我成功把 Hermes 切了过去。接口不再报 402，也没有鉴权错误。

可聊天结果非常奇怪：

hy-mt2-pro 对中文指令反复返回固定英文

无论输入“你好”“说中文”还是“中文回答我的问题”，它都只返回几乎相同的英文欢迎语。

这不是语言设置，也不是前端缓存。

日志显示，三次请求都成功发给了：

▼
text
复制代码
provider=tencent-tokenhub
model=hy-mt2-pro
finish_reason=stop

但每次输入都恰好记为 4096 tokens，输出只有 15～18 tokens。也就是说，Hermes 没有偷偷替换回复，腾讯接口确实正常结束了请求，只是模型没有正确理解 Hermes 的长系统提示和 Agent 上下文。

MT 很容易让人联想到 machine translation。无论它的内部实现如何，这次实际表现已经足以说明：它不适合作为 Hermes 的通用 Agent 主模型。

换成面向通用对话的 qwen3.5-plus 后，中文对话和任务执行恢复正常；Plus 额度用完后，再用同样的方法切到 qwen3.5-flash 即可。

所以，选模型不能只看“额度还剩多少”，还要看它是否适合：

  • 多轮对话；
  • 长系统提示；
  • 工具调用；
  • Agent 工作流。

九、第七个坑：当前会话、全局默认和模型列表，是三套状态

这是最后一个、也是最容易反复踩的坑。

Hermes 里至少存在三种“模型状态”：

  1. 模型下拉列表：Hermes 当前能展示的目录；
  2. 全局默认模型：config.yaml 里的 model.default；
  3. 当前会话模型：右下角实际显示并用于下一次请求的模型。

它们可能不一致。

例如：

  • 配置文件已经写成 qwen3.5-flash；
  • 下拉列表仍然没有 Flash；
  • 当前旧会话仍显示 qwen3.5-plus。

这不是配置失效，而是会话仍保留旧的固定模型。

最省事的处理方式，还是在目标会话中执行：

▼
text
复制代码
/model qwen3.5-flash --provider tencent-tokenhub --global

看到下面这类提示才算完成：

▼
text
复制代码
Model switched: qwen3.5-flash
Provider: Tencent TokenHub
Saved to config.yaml

十、最终可复用的检查清单

如果让我重新装一次，我会严格按下面的顺序来。

安装前

  • 确定 HERMES_HOME，不要只看安装包所在位置；
  • 确认 GitHub 能被 Git/PowerShell 访问，不只是浏览器能打开；
  • 同时设置 HTTP_PROXY 和 HTTPS_PROXY；
  • 暂停可能拦截临时 EXE 的安全软件。

安装失败时

  • 优先查看 bootstrap-installer.log；
  • 先找失败的 stage；
  • 如果出现 uv-trampoline.exe，优先检查实时防护；
  • 如果出现 github.com:443、DNS 或 ETIMEDOUT，优先检查代理；
  • 不要上来就删除整个 Hermes 目录。

模型接入时

  • TokenHub 地址使用 https://tokenhub.tencentmaas.com/v1；
  • 模型名使用腾讯控制台中的“服务 ID”；
  • HTTP 402 要确认究竟是哪个服务额度耗尽；
  • 下拉列表没有模型时，直接使用 /model；
  • 右下角标签才代表当前会话实际使用的模型；
  • 优先选择适合通用对话和工具调用的模型。

写在最后

这次经历最有意思的地方，是每一个报错都很像另一个问题。

安装目录不对，看起来像安装器设计问题；GitHub 超时，看起来像代理没开；uv 失败，看起来像 Python 环境坏了；HTTP 402，看起来像账号没钱；固定英文回复，看起来像中文设置没生效；模型列表为空，看起来像服务没创建成功。

但真正解决问题的方式始终只有一个：确认请求走到了哪一层，再用日志里的路径、阶段、服务 ID、模型名和状态码说话。

如果你也准备在 Windows 上部署 Hermes Agent，希望这篇复盘能帮你少走几小时弯路。

注：本文记录的是一次真实安装和排错过程。Hermes 与腾讯 TokenHub 都可能更新界面、模型目录和命令行为，实际使用时请以当前版本为准；API Key 请始终保存在本地配置中，不要发布到文章或截图里。

AI
6
3
分享
操作
评论
相关内容
0个评论
全部评论
点击登录，快来和大家讨论吧～
表情
图片
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题

目录

🔥 热门文章
1
离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？
430
2
DeepSeek 全新模型发布，性价比最高的一集！
390
3
B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！
380
4
自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?
360
5
又一个国产版 Codex 神器，也来卷办公了！
330
6
day3-如何写出一个高质量的 Skill（组内分享） 高质量 Skill 不是“一个调得很顺的巨型 Prompt”，而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”，再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子，但方法是通用的。 --- 一、先想清楚：Skill 到底是什么 一个 Skill 至少包含四部分： 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做，每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办，而不是硬编一个看似合理的结果 高质量 Skill 的共同点：职责单一、接口清晰、规则可定位、输出可验证。 反例：把几十条经验全塞进一个主 Prompt，改一条规则要重调整个 Prompt，评估时也不知道是哪条规则退化。 --- 二、核心方法：先建评估，再写 Skill 不要先写转换器再补测试。正确顺序是： 1. 定义输出契约：什么算合法、什么算合格； 2. 建金标准集：一小批人工认可“可放行”的样本； 3. 先写评估 Skill：让它在金标准集上跑出基线； 4. 再迭代生成 Skill：每次修改跑同一套评估，无退化且目标维度提升才算正向。 这就是评估驱动开发：评估是 Skill 的单元测试，金标准集是回归锚点。 --- 三、评估 Skill：三层门禁，逐层递进 前一层不过，后一层不跑。每层留可追溯证据。 第 1 层：确定性硬门禁 用解析器、Schema、校验器完成，不消耗模型成本。 · 输出可解析； · 必填字段齐全，类型/枚举合法； · 引用目标存在，无悬空引用、无不可达节点； · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层：语义断言 用脚本 + 结构遍历检查“逻辑对不对”，仍然保持确定性。 通用检查项： · 覆盖率：源材料里的关键步骤、分支、条件，输出里是否都有对应？ · 完整性：每个判断节点是否都有明确出口？有没有死胡同？ · 可达性：每条路径是否都能到达预期终点？有没有无出口循环？ · 顺序与依赖：有先后依赖的操作，是否保留了顺序？有没有被拍平成无序列表？ 例子：故障诊断转换中，检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层：LLM-as-Judge 只处理解析器表达不了的维度：忠实度、完整性、可执行性。 但 Judge 会漂移，不能单独放行，必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化，换模型必须用金标准集重新校准。 通用 Judge 维度： 维度 问什么 忠实度 输出是否忠实源材料意图？有没有自行发明内容？ 完整性 关键步骤、条件、证据是否保留？隐式知识有没有被压成空话？ 收敛性 输出是否仍指向原目标，而不是发散？ 可执行性 下游不依赖源材料能否直接使用？ --- 四、金标准集：回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子，扩到 15～30 份，覆盖失败模式而非随机抽样： · 完整正例：典型流程； · 边界/异常分支：异常路径、循环、前置失败回退； · 已知易错模式：实际踩过的坑； · 留出集：不参与调优，只用于最终验收，防过拟合。 金标准不需要完美，只需要当前标准下认可可放行。 回归指标：关键路径用 pass^k（k 次全过），稳定性用 pass@k。 --- 五、工程约束：让批量产出可重放 · 幂等：同输入 + 同 Skill 版本 + 同规则 → 输出一致，否则无法判断变好是 Skill 改了还是随机波动； · 隔离不阻断：单份失败进隔离队列，记录失败层和原因，不阻塞其余； · 版本绑定：规则、rubric、金标准集进 Git；每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”； · 抽样人工复核：Judge 临界样本 + 易错模式，人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅，写清：输入约定、输出契约、分步流程、硬规则、降级策略； · 经验规则放 references/ 或 rules/，按失败模式分类，不要全塞进主 Prompt； · 不确定时标 needs_review: true，不要硬编看似合理的结果； · 迭代由评估报告驱动：报告告诉你哪层挂了、哪类失败模式，你改对应规则文件，而不是漫无目的调 Prompt。 --- 七、落地顺序（不要反过来） 1. 固化输出契约：Schema + 结构约束； 2. 建金标准集：从已认可的 + 最易出错的样本开始； 3. 先写评估 Skill：跑出基线报告； 4. 再迭代生成 Skill：每次修改对比逐项通过率，无退化且目标提升才算正向； 5. 批量运行 + 隔离回放：失败进队列，结束后人工抽检； 6. 评估 Skill 自身版本化：换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”：每次修改必须附评估报告对比，逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数：前两层挂了，Judge 分数没有意义。 3. 不许把规则堆进主 Prompt：规则按失败模式分文件，评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”，评估 Skill 决定“敢不敢用”。 先让评估体系站稳，再让生成器迭代。这样交付的不是一堆“看起来还行”的产出，而是一套可证明、可回归、可交接的 Skill 质量体系。
310
7
AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。
310
8
什么是LLM
300
9
我的第一个出海产品！7 天 2 万
290
10
WorkBuddy 本地 API 桥 + dsh 插件：把你的 WorkBuddy 额度，变成手边随手可用的模型
290