Dragon Q6A 远程开发环境（下）：DeepSeek 接入 Copilot Chat 与命令生成准确率评测

[azouyana]

平台：Qualcomm QCS6490（瑞莎 Dragon Q6A）
定位：一个开发者的学习记录，不是官方教程
一句话：AI 接进来确实省"查"的时间。
分篇：上篇解决了 Remote-SSH 远程窗口，下篇只谈 AI 辅助与实测数据。

---

1. 起点：远程窗口已经在跑

上篇结束时，VS Code 已经通过 Remote-SSH 连进板端，左下角显示 SSH: q6a。这篇不重复配连接，只做两件事：把 DeepSeek 接进 Copilot Chat，然后用 5 条真实任务测它到底靠不靠谱。

环境与上篇一致：Ubuntu 24.04.4 LTS / 内核 6.18.2-3-qcom / aarch64 / 5.1 GiB 内存，板端用户名 radxa，主机名 radxa-dragon-q6a。

2. 扩展安装与两项配置

扩展市场搜 DeepSeek V4 for Copilot Chat 装上（名称以市场实际显示为准）。然后全靠命令面板：

1. Ctrl+Shift+P → 输入 deepseek → 选 DeepSeek: Open Settings，把 Base Url 填成官方地址：

   https://api.deepseek.com
   

   如果界面上明确要求带版本号，就填 https://api.deepseek.com/v1。

2. Ctrl+Shift+P → 选 DeepSeek: Set API Key，粘贴自己的密钥，回车保存。

密钥在 DeepSeek 开放平台自助创建：https://platform.deepseek.com/usage。这个 Key 不要写进任何仓库文件、不要出现在截图里。

3. 连通性验证

在 Chat 里丢一句和板子相关的问题，比如"这台 aarch64 的板子上，nmcli 显示已连接但 ping 不通网关，按可能性从高到低列排查命令"。能正常回、命令能直接跑，就算接通了。

![Copilot Chat 在 DeepSeek V4 Pro 模型下正常应答]

图 1：接通后的样子——Chat 里能正常应答，输入框下方的模型选择显示 DeepSeek V4 Pro

一句话发出去，回复能带着当前工作区的上下文回来，说明 Key 和 Base Url 都到位了。如果这里报 401，是 Key 的问题；报连接超时或解析失败，先看下一节。

4. 前置条件：模型 API 需公网可达

Base Url 是公网地址，所以请求必须能出公网。板子只连局域网、PC 走公司代理的现场，这一条直接决定 AI 能不能用。

先测板子自己的出口能力：

code=401 dns=0.005073 conn=0.031235 tls=0.101483 total=0.206399

401 是没带 Key 时的正常响应，说明 TCP/TLS 全通，**这块板可以直连 api.deepseek.com**，全程 0.206 s（DNS 5 ms / 建连 31 ms / TLS 101 ms）。

但「板子能直连」不等于「请求就是从板子发出去的」。Remote-SSH 场景下模型请求到底由 PC 侧客户端发出、还是由板端扩展宿主发出，我还没测出来，所以这行数据只能证明两个出口都具备条件。真要区分，发消息的同时在板上跑一句 ss -tnp | grep :443 看有没有 node 进程往外建连，或者干脆临时切断板子出网，看 Chat 还能不能正常回答。

5. 命令生成准确率：5 条任务一次跑通 2 条

判定标准：命令粘到板上直接跑通、无需人工改任何参数 = 一次跑通。

任务	一次跑通	AI 给的东西到底错在哪
A 列出除 lo 以外的 IPv4	✅	ip -4 -o addr show scope global | awk '{print $2, $4}'，零改动可用
B 读 SoC / CPU 温度	❌	给的是 thermal_zone0，而本板 zone0 是 aoss0-thermal；要取 cpuss1-thermal 等并按 /1000 换算
C 查 openssh-server 版本	✅	dpkg -s openssh-server | grep -i version；输出会串到 Description，有噪声但可用
D 改 hostname（未执行）	⚠️	只给 hostnamectl / /etc/hostname，漏掉 /etc/hosts 里的 127.0.1.1 行
E PC 侧端口转发	⚠️	板端 8080 根本没进程在听，转发前得先起服务；且默认用户名写成 ubuntu@，本板是 radxa@

一次跑通率：2 / 5。

三个错点值得展开：

B 题最典型。 高通平台有 34 个 thermal zone，zone0 的 type 是 aoss0-thermal，根本不是 CPU。AI 给的是 x86 / 树莓派世界里通行的写法，在这块板上读出来的是另一个传感器的温度——命令能跑、结果错，这比报错更危险。

D 题是"漏一步"。 hostnamectl set-hostname 只改了当前状态，/etc/hostname 管开机，/etc/hosts 里的 127.0.1.1 行管本机解析。漏掉第三处，sudo 会变慢、hostname -f 会异常。

E 题是"前提不成立"。 它直接给了 ssh -L 转发命令，但板端 ss -tlnH | grep :8080 是空的——没有服务在听，转发过去也没用。顺带把默认用户名写成 ubuntu，本板实际是 radxa。

6. 常见问题与排错

现象	原因	解决
填了 Base Url，对话仍报连接失败	请求需出公网；若从板端发出，板子必须能访问 api.deepseek.com	先确认地址与 /v1，再用 curl 验板端出网
报 401	Key 无效或已失效	重新 DeepSeek: Set API Key
AI 给的命令能跑但结果不对劲	它按通用发行版/通用硬件写，不知道这是高通平台	先把 thermal_zone*/type、ip a、用户名等事实贴给它，再让它写
改主机名后 sudo 变慢	只改了 /etc/hostname，漏了 /etc/hosts 的 127.0.1.1 行	两处一起改，改完 hostname -f 验证

7. 结论：先采集事实，再让 AI 写命令

• **远程窗口解决"能不能干活"，AI 解决"查得快不快"**。上篇的三组数字（1.2 G 磁盘、约 1/4 内存、24 MB/s 写入）说明基础设施有成本；这一篇的 2/5 说明加速器有上限。
• AI 出错的地方，全是对这块板子的具体事实假设，不是语法或逻辑。它默认用户名是 ubuntu、默认 thermal_zone0 就是 CPU、默认只改 /etc/hostname。
• **所以顺序应该是"先采集事实，再让 AI 写命令"**。把 ip a、thermal_zone*/type、真实用户名这类事实先抓出来贴给它，比让它猜快得多——这一轮里最快的两次都是我把输出贴给它之后。