1. 先说清楚：QwenPaw 到底是个什么东西

最近有不少人在讨论 QwenPaw 的安装，但说实话，我翻了一圈评论，发现很多人对这个工具的理解是模糊的。有人把它当成普通的聊天客户端，有人以为它只是某个模型的封装壳，还有人直接拿它跟 Codex CLI 对标。这些说法都不太准确，所以我想在一开始就把定位讲清楚。

QwenPaw 本质上是一个跑在终端里的 AI 代理工具，核心工作方式是“你给我一句话，我帮你拆解成若干步骤，去读文件、改代码、执行命令、看回报，再继续推进”。它和你平时用的网页版对话不一样。网页版是你敲一句它回一段，来回切换浏览器，手动复制粘贴，效率很低。QwenPaw 是直接驻留在你的工作目录里，能感知你项目的文件结构，能调用系统命令，能连续多轮自主完成一个相对完整的任务。说得直白一点，它更像一个坐在你旁边、能动手帮你干活的实习生，而不是一个只会回消息的客服。

为什么叫 Paw，我个人的理解是它强调“动手”能力，Paw 就是爪子，代表它可以直接触及你的文件系统和终端命令。这种设计思路和 Anthropic 的 Claude Code、OpenAI 的 Codex CLI 是一路的，区别在于 QwenPaw 背后接入的是通义千问系列模型，参数配置、模型切换逻辑、上下文处理方式都有自己的一套。

这篇手册我是按照“从零开始装到能顺手上路”的顺序来写的。如果你是在 Windows、macOS 还是 Linux 上安装，都能找到对应的路径；如果你卡在 API Key 配置、网络连接、权限这类经典问题上，后面也有专门节帮你排查。最关键的几个坑我都踩过了，会直接告诉你避开的方法，不让你在同一个地方耗两个小时。

2. 安装之前：环境要求与依赖清单

2.1 操作系统与运行时环境

先说结论：QwenPaw 目前对三大主流桌面系统都支持，Windows 10/11、macOS 12 及以上、主流 Linux 发行版（Ubuntu、Debian、CentOS 系都能跑）。但有个容易被忽略的点——它本质上是一个 Node.js 应用，所以你的机器上必须要有可用的 Node.js 运行时。

这里我想展开说一个很多教程没强调的坑：版本版本版本。QwenPaw 对 Node.js 的版本有要求，官方建议是 Node.js 18 以上，最好是 20 LTS 或更新的 22 LTS。如果你装的是 Node 16，安装过程大概率会在编译依赖的某个环节报错，而且报错信息并不友好，比如突然冒出个gyp ERR!或者node-gyp相关的提示。新手一看就懵，其实根因就是 Node 版本太旧，和项目依赖的原生模块不兼容。

所以我强烈建议你在正式安装之前，先打开终端确认一下自己的环境。Windows 用户打开 PowerShell，macOS 和 Linux 用户打开 Terminal，分别输入：

node -v npm -v

如果没反应或者报错，说明 Node 还没装。别急着装 QwenPaw，先把 Node.js 装好。这里我不想推荐那种复杂的手动编译方式，直接用官方安装包就行。Windows 和 macOS 用户去 Node.js 官网下载 LTS 版本，一路下一步。Linux 用户用包管理器更省事：

sudo apt update sudo apt install nodejs npm

装完再验证一次node -v，输出类似v20.x.x就说明没问题。整个过程大概十分钟，别嫌慢，这十分钟省得你后面折腾一下午。

2.2 Git 与终端环境

第二个前置依赖是 Git。为什么需要它？因为 QwenPaw 的很多功能都建立在“能够理解代码变更”的基础上。它需要读取你的 Git 仓库状态，知道哪些文件改过、哪些是新加的，才能在你让它“优化一下最近改的代码”这类任务里做出合理动作。你就算不把它当 Git 工具用，它自身的一些安装和更新机制也会依赖 Git 拉取最新版本。

验证 Git 是否安装：

git --version

没有输出就先去装 Git。Windows 用户我建议直接下载 Git for Windows 的官方安装包，安装过程中有一个选择编辑器、调整 PATH 的步骤，保持默认推荐项即可，但有一个选项务必注意：“Git from the command line and also from 3rd-party software”那一项，这决定了你在 PowerShell 里能不能直接用git命令。如果你之前装过 Git 但发现终端里敲git没反应，大概率就是这一步没选对，重装一次勾上就好了。

macOS 用户有两种方式：如果你的 Xcode Command Line Tools 已经装过，git一般已经可用；如果不行，最简单的办法是安装 Homebrew 后执行brew install git。

终端环境方面，Windows 用户请默认使用 Windows Terminal + PowerShell，别用老的 cmd.exe。QwenPaw 的彩色输出、交互式表格、快捷键绑定在 Windows Terminal 下表现最稳定，在 cmd 里可能会出现某些字符渲染错位的问题，虽然不影响功能，但体验确实差一截。macOS 用户用系统自带 Terminal 或者 iTerm2 都可以，Linux 桌面用户装个 GNOME Terminal 即可。

2.3 预留资源与网络条件

最后说两个看似不起眼但实际很影响体验的点：磁盘空间和网络。

QwenPaw 本体安装完成后约占 300MB 左右的空间，但它运行时会缓存模型相关信息、会话文件、日志数据，长期使用下来缓存目录会缓慢增长。我自己的机器上跑了大概两个多月，缓存目录接近 1.5GB。所以建议你至少预留 2GB 可用磁盘空间，免得用着用着忽然报“磁盘空间不足”。缓存目录的具体位置和清理方法，我后面在排查章节会细讲。

网络方面，QwenPaw 需要访问模型服务的 API 接口。如果你在国内使用，正常直连通义千问的服务是没有问题的，不用做任何特殊处理。但如果你的网络环境本身存在一些限制，或者你用了某些代理工具，反而可能产生问题——最常见的是代理把 API 请求拦截了，导致连接超时。我见过不少用户装好了却连不上，最后发现是系统代理设置太激进。所以遇到网络类报错时，先试试关掉所有代理和加速工具，等确认问题原因后再决定是否调整。关于这块的排查思路，我放到后面专门展开。

3. 安装全流程：从拉取到跑通的每一步

3.1 方式一：通过 npm 直接安装

当你把 Node.js 和 Git 都准备好、并确认环境没问题后，上手安装 QwenPaw 的方式其实很简洁。官方提供的是 npm 全局安装命令：

npm install -g qwenpaw

全局安装意味着你可以在任何目录下直接输入qwenpaw启动它，不用每次都在安装目录里找脚本。在 Windows 上，这一步可能会遇到“权限不足”的报错，常见提示是类似EPERM或者EACCES。很多教程会让你去改 npm 的全局目录权限，我不推荐直接修改系统目录的 ACL 权限，那会给后面其他包的管理埋雷。

更稳妥的 Windows 做法是使用管理员身份的 PowerShell 运行 install 命令。你可以在开始菜单里右键 Windows PowerShell，选择“以管理员身份运行”，然后再执行npm install -g qwenpaw。如果还报错，再考虑检查 npm 的全局路径是否指向了系统保护目录之外。查看当前全局路径：

npm config get prefix

Windows 上正常应该指向C:\Users\你的用户名\AppData\Roaming\npm这类用户目录，如果指向了C:\Program Files\nodejs这种系统目录，建议改回用户目录。一个相对省心的处理方式：

npm config set prefix "$env:APPDATA\npm"

改完后再重新执行安装命令。这样以后全局安装的包都会落在用户目录里，不会再碰到权限问题。

macOS 和 Linux 用户情况好一些，只要当前用户对全局 node_modules 目录有写权限，直接装就行。如果你之前是用 Homebrew 安装的 Node.js，全局目录通常在/usr/local/lib/node_modules，普通用户一般有写权限；如果是手动安装到/usr下的，没权限时报错会明显，出现EACCES时先sudo执行或调整目录归属。

3.2 方式二：通过源码安装

如果你需要用到一些尚未发布到 npm 的最新功能，或者你想基于 QwenPaw 做自己的二次开发，源码安装会更合适。方式也很简单，先用 Git 把仓库拉下来：

git clone https://github.com/qwenpaw/qwenpaw.git cd qwenpaw npm install npm run build npm link

这里我提个醒：源码安装前请确认 Node.js 版本不低于 18，否则在npm install这一环就很容易报错。报错信息里如果出现node-gyp、python、make等字样，说明某些原生模块需要本地编译环境。Windows 用户碰到这种情况最头疼，因为没有 mingw 或者 Visual Studio Build Tools 的话，编不过去。一条解决办法是安装 Windows 的构建工具链，在管理员 PowerShell 里运行：

npm install --global windows-build-tools

这个包会自动装好 Python 和 VS Build Tools，但耗时较长。如果你只是日常使用，不是做二次开发，我建议优先走 npm 方式安装，别一上来就源码装，省点是点。

3.3 安装验证与版本检查

装完之后的验证步骤非常关键，很多人装完以为没反应就是装失败了，其实是没找到正确的验证方式。第一步，直接运行：

qwenpaw --version

能输出版本号就说明主程序已经可用。第二步，运行一下帮助命令看看整体菜单：

qwenpaw --help

这时候你会看到子命令列表，比如chat、run、config、doctor等不同系统的版本可能略有差异，但结构都差不多。我特别想提醒你关注的是doctor这个子命令——它是 QwenPaw 内置的环境自检工具，会检查 Node 版本、Git 配置、API Key 是否设置、依赖是否缺失等等。刚装完最好跑一次：

qwenpaw doctor

看到类似All checks passed的输出，就可以放心进入下一步了。如果某项检查报错，先别急着找客服，读数提示基本就能定位问题。这个自检工具是我认为 QwenPaw 做得比较好的一点，很多同类工具不给你这种提前暴露问题的机会，都是等你用到一半才炸雷。

4. API Key 配置：最容易卡住的一关

4.1 API Key 从哪里获取

我第一次装 QwenPaw 的时候，卡得最久的不是安装本身，而是不知道去哪里拿 API Key。这个环节如果你没有经验，很容易一头雾水。

QwenPaw 自身不是一个模型提供方，它只是一个客户端和代理框架，真正回答问题的是通义千问的大模型服务。因此你需要先有一个通义千问的 API Key。这里区分一下：通义千问有面向消费者的网页版 App 和面向开发者的 API 平台，你要的 Key 是在阿里云百炼大模型服务平台（也叫 DashScope）上创建的，不是在千问 App 里找。

具体步骤我拆开说：

1. 打开阿里云百炼平台，登录你的阿里云账号。没有账号就注册一个，实名认证是必须的，这一步绕不过去。
2. 进入“API-KEY 管理”页面，一般在控制台首页就能看到入口，或者通过“模型服务”菜单找到。
3. 点击“创建新的 API-KEY”，系统会生成一串以sk-开头的密钥。这个密钥只在创建当时完整显示一次，建议立刻复制保存到本地密码管理器里。
4. 如果你之前创建过 Key 但找不到了，平台不提供“查看完整 Key”的功能，只能删除旧的重新创建。这个设计是为了安全，别嫌麻烦。

拿到 Key 后，要注意新用户一般会有一定的免费调用额度，够你试用几天的，但正式使用前一定要确认账号下已经开通了对应的模型服务权限。有些用户拿了 Key 却提示 403 或者InvalidApiKey，就是因为没开通对应模型的调用权限，或者选错了模型名。

4.2 在配置文件中写入 Key

拿到 Key 之后，接下来就是告诉 QwenPaw 怎么用这个 Key。QwenPaw 支持两种方式：环境变量和配置文件。

最直接的方式是设置环境变量。在 Windows PowerShell 中：

$env:QWENPAW_API_KEY="sk-你的密钥"

在 macOS 和 Linux 中：

export QWENPAW_API_KEY="sk-你的密钥"

这种方式的优点是快，缺点是建立在当前终端会话里，关闭终端后变量就没了，下次还要重新设置。如果你只是临时测一下，用环境变量没问题。

长期使用建议写到配置文件里。QwenPaw 的配置文件位置在不同系统上有差异，Windows 在C:\Users\你的用户名\.config\qwenpaw\config.json，macOS 和 Linux 在~/.config/qwenpaw/config.json。如果文件不存在，运行过一次qwenpaw后会自动创建目录结构。你可以手动创建并编辑：

{ "apiKey": "sk-你的密钥", "baseUrl": "https://dashscope.aliyuncs.com/compatible-mode/v1", "model": "qwen-plus" }

这里要特别说明baseUrl字段。QwenPaw 那边默认配置的模型服务地址，如果是通义千问官方兼容接口，就是这个地址。别自己去网上抄一些杂七杂八的第三方中转地址，不稳定不说，还可能有隐私风险。你如果确认用的是官方模型服务，填官方地址即可。如果连不上，先检查网络而不是换地址。

把 API Key 写入配置文件后，运行qwenpaw doctor或qwenpaw config list验证一下，项目会显示 Key 是否已配置成功，但不会回显完整 Key（只会显示后四位），这是正常的，别慌。

4.3 Key 的安全和治理问题

既然讲到 API Key，我必须多说几句安全方面的体会。密钥是跟着账号走的，相当于你云资源的通行证。如果有人拿到你的 Key，他可以拿它去调用模型，产生的费用都算在你头上，更严重的还可能读取你账号下绑定的服务信息。

我见过最典型的错误是把 Key 直接写进了项目代码里，然后项目推到了公开仓库。复制粘贴的时候很顺手，但 GitHub 的爬虫工具能扫到这类密钥。所以我强烈建议：

• 不要把 Key 写在任何会进入 Git 版本管理的文件里。配置文件如果你放在项目目录下，记得在.gitignore里加上忽略规则。
• QwenPaw 的全局配置目录默认就在用户主目录下，不跟项目走，这是比较安全的设计，让它保持这样。
• 如果怀疑 Key 泄露，立即去百炼平台删除并重新生成一个新 Key。旧 Key 作废只需要几秒钟，比你事后补救强得多。
• 如果你有多台设备或多个项目，建议给不同场景创建不同的 Key，方便在产生异常消耗时快速定位问题来源。

这些不是矫情。API Key 的管理习惯决定你之后用各种 AI 工具时的底子是否稳，早养成早省心。

5. 上手实操：从第一句对话到完成一个真实任务

5.1 进入交互模式

配置好 Key 之后，接下来就是验证它的实际效果。在任意目录下运行：

qwenpaw chat

你会看到终端切换成一个交互式会话界面，带输入提示符，可以开始对话。第一次进去我建议先别急着扔任务，先跟它随便聊两句，确认模型能正常响应。你可以问“你现在使用的是哪个版本的模型”，它会告诉你背后的模型信息。

输入/help可以看到内置的斜杠命令列表。我简单列几个高频命令：

• /model：查看或切换当前使用的模型
• /clear：清空当前会话的上下文
• /compact：压缩当前会话上下文，适合长对话后继续操作
• /exit或Ctrl+C两次：退出会话

交互界面里支持多行输入，如果你要粘贴一段代码或一段长文本，记住大多数终端里多行粘贴不会触发立即发送。Widows Terminal 和一些终端工具在粘贴时会把多行内容一次性带入输入框，这时候直接敲回车确认发送。

5.2 让它帮你处理真实项目任务

光会聊天没有意义，核心价值在于让它干活。我举一个自己的实际例子：有一次我需要把项目里所有 Python 文件的print调试语句统一替换成logger.info，还要保留原有的打印内容。手动改大概要打开十几个文件，很枯燥。在 QwenPaw 里我直接说：

把当前项目所有 Python 文件中用 print 输出调试信息的地方，统一改成 logger.info，保持原有输出内容不变，改完告诉我一共改了哪些文件。

它会先扫描当前项目结构，然后逐个文件定位匹配位置，修改后用 diff 方式展示改动内容。这个过程中我唯一需要关注的是它的改法是否符合预期，如果觉得某处改得不对，我可以直接说“刚才 XX 文件不要改，回退一下”，它能基于上下文理解回退对象。

这里有一个非常实用的经验：给它任务的时候，把背景和约束条件说清楚，比让它自由发挥可靠得多。例如你让它“优化这个函数”，它可能给你重写一套实现，甚至换掉你原本依赖的外部接口，那样反而会让你手忙脚乱。更合理的说法是“保持对外接口不变，仅优化函数内部实现，不要改动依赖关系”。这是高手和新手使用 AI 代理最大的差异。

5.3 会话管理、项目隔离与长期记忆

QwenPaw 默认会在你启动它的目录下创建.qwenpaw目录（也有可能是全局会话记录，不同版本行为略有不同），用来存储会话上下文。这带来一个使用习惯上的取舍：如果你希望不同项目之间完全隔离，建议在每个项目目录下单独启动 QwenPaw，不要在一个大目录里处理所有项目的事情。因为它读取的是启动目录下的文件结构，你在错误的目录里干别的项目的活，很可能误改文件。

多会话管理方面，你可以通过/sessions查看历史会话列表，切换到旧会话继续工作。这个能力很有用，因为 AI 代理的上下文窗口是有限的，一旦对话过长，早期信息会丢失，模型表现可能变差。此时不用重新开一个空白会话从头解释一遍，直接/compact压缩上下文，保留核心信息，继续往下聊。

我还想提一下run模式。如果你已经有一个明确的命令式任务，不想进入交互界面，可以直接用：

qwenpaw run "读取 src 目录下所有测试文件，找出失败的用例并说明原因"

这种模式适合用在脚本化、自动化场景里，比如配合 CI 流程做代码审查、生成变更摘要等。输出结束后会自动退出，不会一直挂着。

6. 高频问题与排查经验：照着这个思路排雷

6.1 安装阶段的权限报错

安装时最常见的报错就是权限问题。抛开我们在安装章节里提到的方案，我想再补充一个容易被忽略的细节：Windows 上的 npm 缓存目录可能也被系统保护了。如果你遇到报错信息里包含 npm 的缓存目录路径（通常在C:\Users\你的用户名\AppData\Local\npm-cache），可以尝试手动清理缓存后重装：

npm cache clean --force

有一种情况是缓存目录里存在损坏的缓存包，导致安装过程中解压失败。这个问题用--force清缓存通常就能解决。

macOS 上权限问题的表现不同，更多地发生在全局安装后运行qwenpaw提示“command not found”。这其实不是没装好，而是 npm 的 bin 目录没进 PATH。检查目录路径：

npm config get prefix

如果显示/usr/local，但qwenpaw在/usr/local/bin/qwenpaw下找不到，可以用which qwenpaw看有没有查到路径。查不到就把/usr/local/bin加进 PATH。这里有个小经验：装完新工具出现 command not found，第一反应别是重装，先检查 PATH，十有八九是路径问题。

6.2 连接超时与请求失败

这是仅次于权限的第二大问题人群重灾区。报错形式五花八门，有的提示connect ETIMEDOUT，有的提示ECONNREFUSED，有的直接是fetch failed，但本质都一样：QwenPaw 到模型服务之间的网络连接出了问题。

先说修复顺序：

1. 退出所有代理工具。我个人遇到十次超时，八次是代理拦截，或者代理节点本身不稳定，导致请求被挂起。
2. 检查防火墙是否放行了 Node.js 进程。Windows 的防火墙有时会弹窗询问是否允许 Node 访问网络，如果你误点了“禁止”，之后所有请求都会失败。去防火墙设置里找到 Node.js，放行即可。
3. Ping 一下模型服务地址，确认你的网络到目标服务器基本连通。当然 ping 通不代表 API 就一定能通，但至少能排除一些低级网络故障。
4. 试一下在浏览器里直接访问 API 地址，如果能打开说明网络没问题，问题多半在代理或本地配置。

如果以上都没解决，再看配置文件里的baseUrl拼写是否正确。别笑，这个问题我真的见过好几次——有人把https写成了http，或者最后多了一个斜杠/，看起来没大问题，但请求就是发不出去。

6.3 输出乱码、文字编码问题

在中文环境下，偶尔会遇到终端输出乱码。在 Windows 上概率最高，原因是 PowerShell 或 Windows Terminal 的默认编码和 QwenPaw 输出的 UTF-8 内容不一致。

解决方式有几种：

• 在启动 QwenPaw 前，先执行chcp 65001切换活动代码页到 UTF-8。
• 在 Windows Terminal 的“设置”里，把默认配置文件为 PowerShell 时，把“使用旧版控制台”选项关掉。
• 或者在 PowerShell 里设置$OutputEncoding = [System.Text.Encoding]::UTF8。

macOS 和 Linux 上乱码问题相对少，主要是终端字体不支持某些特殊符号，比如渲染框线字符时会错位。解决办法是更换终端字体，推荐 Nerd Font 系列，或者直接建议用--no-color模式运行，减少颜色和特殊字符渲染带来的干扰：

qwenpaw --no-color chat

顺带说一句，如果你是在 SSH 远程服务器上使用 QwenPaw，乱码概率会更高，因为本地终端的编码和远端环境的编码如果不一致，就会各自为政。最简单的方式是确保本机和服务器都使用 UTF-8 编码。

7. 进阶配置：把它调成真正趁手的工具

7.1 模型选择与参数调整

QwenPaw 背后可选的模型不止一个，阿里云百炼平台上 qwen-turbo、qwen-plus、qwen-max 等不同规格的模型在性能和成本上差异明显。通关配置里的model字段可以切换：

• qwen-turbo：速度最快，成本最低，适合简单问答、代码风格统一、批量文本处理。
• qwen-plus：均衡型，日常开发任务足够，我长期默认使用这个。
• qwen-max：最强推理能力，适合复杂架构设计、多步骤代码重构、长文档分析，但响应速度和成本也更高。

我建议刚上手先用qwen-turbo跑通流程，确认一路顺畅再切到qwen-plus。有些用户一上来就选 max 模型，然后抱怨“好慢”，其实不是 QwenPaw 的问题，是模型规格选高了。

交互界面里也支持/model命令随时切换，不用退出会话。这个设计贴心，因为实际使用中你可能上午用 turbo 处理大量琐碎任务，下午碰到一个复杂问题想用 max 深度思考，随时切换的体验会顺畅很多。

温度参数、最大 Token 数这类参数在配置文件也能调，我会建议大多数人不乱动，默认值已经是官方调校过的。如果你要调整，配置格式大概是：

{ "temperature": 0.3, "maxTokens": 4096 }

温度值越低输出越保守稳定，适合代码任务；越高越有创造性，但离题概率也变大。我自己在普通任务上固定用 0.3，只有在写文案或头脑风暴时才调到 0.7。这个参数因人而异，没有绝对的“最佳值”。

7.2 与 Git 和编辑器的配合习惯

我实际项目里最有用的工作流之一是让 QwenPaw 配合 Git 做代码评审。流程很简单：

1. 在项目里改完代码，不要直接提交。
2. 运行qwenpaw run "帮我 review 当前未提交的改动，重点关注潜在的 bug、边界问题和风格问题"。
3. 它会读取git diff的输出并逐项分析，给你列出问题清单。
4. 你根据它的建议决定要不要手动调整，再提交。

这个流程比让它全权代劳要稳得多。AI 代理帮你发现问题，你做决策，最终改动还是自己掌握，出问题的概率会大幅降低。

和编辑器的配合方面，QwenPaw 本身是终端工具，不太需要和 VS Code 这类编辑器深度绑定。但它处理文件后，编辑器如果检测到外部文件变更，可能会弹窗提示“文件已被修改，是否重新加载”，别嫌烦，直接允许重载就行。某些编辑器还支持终端内直接打开文件，如果你在 QwenPaw 里让它修改了某个文件，可以让它返回文件的完整路径，然后在编辑器里按快捷键跳转。

7.3 几个长期使用下来的实用技巧

最后分享几条我在实际使用中积累的操作习惯，这些东西官方文档未必会写，但确实能提升使用体验。

第一，每次开会话先给它一个“角色设定”。比如开头加一句“你是一个严谨的 Python 后端工程师，接到任务后先分析再动手，每个改动都要解释理由”。这看似简单，实际上能显著提高它后续输出的稳定度，减少随意发挥。

第二，任务中途随时插入新要求是允许的，但要尽量具体。比如它在改代码，你发现方向不对，直接说“停一下，这一处不要用正则表达式，改成字符串方法处理”，它会基于上下文调整方案，不需要从头开始。

第三，长时间会话记得定期/compact。上下文越长，模型的指令跟随能力下降越明显。我发现大约每聊到 20 轮左右压缩一次上下文，回答质量会保持在一个可靠的水平线上。

第四，阶段性地把它的成果让 Git 接管。不要让它连续改一大堆文件后才想起来看一眼，每完成一个批次就查看 diff、做一次提交。这样既能在每个小阶段保底，出了问题也能通过 Git 快速回滚，不至于一地鸡毛。

第四点其实是我从一次惨痛教训里总结出来的。有一回我让它一口气优化整个工具目录下的十几个脚本，它改得很起劲，我看它一直没报错就没打断，结果改完后发现公共函数里依赖关系被破坏了一半，跑了半天测试才恢复。从那之后我就坚持小步快跑，一段任务一提交，再没出过类似问题。

8. 写在最后：关于这类工具的一点个人体会

QwenPaw 这类终端 AI 代理工具，这几年发展很快，使用方法也一直在迭代。我写的这份手册尽量覆盖了从安装到日常使用再到排错的完整闭环，但具体到你的机器环境、项目类型和网络情况，总会有些细节出入。遇到文档没覆盖到的问题，我的建议是先把qwenpaw doctor跑一遍，再配合报错信息的关键词去搜，比盲目重装有效得多。

我个人的使用体会是：AI 代理的定位是放大器，不是替代品。它能把你会做的事做得更快，能帮你在不熟悉的领域快速铺出一条路，但最终判断力还是你自己的。用它 review 代码，你得能看懂它说的每一条；让它重构代码，你得能验证每一处改动。如果哪天它帮你做了一堆你看不懂的修改，那不是可以高枕无忧的信号，而是需要拉响警报的时候。

最后再分享一个小技巧：如果你要在多台设备间同步 QwenPaw 的配置，直接把~/.config/qwenpaw/config.json里的非密钥部分拷贝过去就行。API Key 建议每台设备单独申请生成，不要一份 Key 到处复制。多花一分钟做配置分离，后面会省掉很多账号安全的隐患。

希望这篇手册能帮你少走点弯路。装好之后别急着跑复杂任务，先从一个简单的请求开始，慢慢熟悉它的脾气和表达方式，你会越来越顺手。