做技术这行聊天时绕不开三个词工具、测试、部署。工具是手里的武器测试是质量的门禁部署则是把东西真正送到用户面前的最后一步。这几年我从写脚本、做自动化测试到给团队搭 CI/CD、搞本地大模型部署发现很多新手最容易在这三件事上踩坑——不是缺资料而是缺一条能把它们串起来的实践主线。这篇文章我就把自己在这三条线上反复验证过的方法整理出来想到哪写到哪都是干活时重新趟过的顺序适合正在做运维、测试、后端或者想入门 AI 工程化的朋友。1. 工具篇先把手里的武器盘清楚1.1 终端与远程连接Tabby、SSH 与日常效率先说终端。很多新手装了 Windows 后习惯用 PowerShell 官方窗口但一旦要同时管五六台 Linux 服务器就会意识到多标签、会话保存、SFTP 内嵌这些功能有多重要。Tabby 是我现在主力用的开源终端Windows、macOS、Linux 都能装界面好看还支持插件。它可以直接在右侧打开 SFTP 面板拖文件上去就完成上传省掉来回切换 WinSCP 的时间。日常连接 Linux 时我会在~/.ssh/config里维护主机别名比如把数据库服务器、应用服务器、跳板机都配好 Host 别名这样打开终端敲一行别名就能连上不用记长串 IP。端口的配置也能写进去例如Host web-prod HostName 10.x.x.x User ubuntu Port 2222 IdentityFile ~/.ssh/web-prod.pem配完之后直接ssh web-prod就能连不用每次输入密码或指定私钥路径。这个习惯能节省大量时间尤其是环境一多、IP 经常变的时候配置文件比脑子靠谱。密钥权限也要注意私钥文件权限太高会直接导致连不上Linux 上一般是chmod 600。如果你不想用命令行Tabby 的图形界面里也可以把会话分组按照环境分目录管理恢复断线会话同样方便。总之终端工具的选型没有绝对标准但 Tabby 这类工具能让你把精力集中在任务本身而不是折腾连接。SSH 工具还有很多比如 Xshell、FinalShell、MobaXterm选一个用熟就好。1.2 抓包与网络排查Wireshark 和 Fiddler 的正确用法搞网络的人桌面上至少得有一个抓包工具。我用得最多的是 Wireshark 和 Fiddler。Wireshark 适合看底层流量比如 TCP 重传、TLS 握手过程能帮你判断是带宽问题、MTU 问题还是服务端响应慢Fiddler 则更擅长看 HTTP/HTTPS 请求和响应体接口联调时非常顺手。第一次用 Fiddler 抓 HTTPS 会有一个明显的坑抓到的内容全是乱码。这是因为你没装它生成的根证书浏览器或 App 不信任这个中间人。解决办法是在 Fiddler 的 Tools 菜单里导出证书并安装到系统根证书库如果是手机抓包还需要让手机流量经过 Fiddler 监听的端口并安装同样的证书。这里要特别提醒一句抓包只能针对自己有权限测试的系统和设备拿抓包工具去分析别人的服务无论在公序良俗还是行业规范上都不合适。实际排障时我建议先用 Fiddler 过滤域名快速定位是哪个接口超时再结合 Wireshark 看网络层的表现两层配合基本能覆盖大部分接口问题。1.3 U盘与系统维护Rufus、量产工具、C盘清理工具不只是软件U盘相关硬件维护也经常出现在日常里。Rufus 是我见过最省心的 Windows 启动盘工具。制作系统安装盘时只需要选择 ISO 文件确定分区类型是 GPT 还是 MBR写入方式保持默认点开始就行。这里有两个容易翻车的点第一写盘会清空 U盘所有内容操作前一定要确认没有需要保留的数据第二如果你的主板是 UEFI 模式建议选 GPTUEFI 的组合如果是老机器可能要选 MBR。做好的启动盘如果无法引导换个 USB 2.0 接口往往就能解决。除了做启动盘U盘用久了容量突然变小、写数据报错通常是主控的固件或闪存映射出了问题这时可以用对应主控的量产工具恢复比如 SM2258XT 这种慧荣主控的量产工具。操作思路是先读取主控型号再找匹配版本的量产软件重新扫描并量产。这个过程有一定风险刷错固件会直接变砖所以量产前要确认主控版本并做好数据备份。C盘清理相对简单得多Windows 自带的磁盘清理和存储感知一般够用清理完临时文件后再用 WizTree 这种按目录看占用大小的工具找大户。有些清理软件会顺手清理注册表我建议新手别碰注册表清理收益有限还容易出问题。1.4 开发辅助工具分词、微信开发者工具、TFTP处理日志和文本时Python 中文分词工具几乎是标配。日志分析、搜索关键词提取、舆情系统都会用到。最简单的例子是装一个 jiebapip install jieba然后jieba.cut(中文分词测试)会直接返回切分好的词。如果要做词性标注或句法分析HanLP 会更专业但学习成本更高。我的原则是快速处理用 jieba需要模型能力再上 HanLP。微信开发者工具做小程序调试时必不可少它的模拟器、真机预览、网络面板能直接定位小程序接口问题。嵌入式调试还经常要用到 TFTP 工具比如在开发板上通过 tftp 命令把固件拉到内存里运行TFTP 服务端可以用 Open TFTP Server 或 dnsmasq 的 tftp 模块。小工具容易被忽略但关键时刻能救命。比如批量改文件名、文本编码转换写个 Python 脚本或者用 Notepad 的插件都能解决。工具的价值在于顺手而不是追求数量。我见过有人收藏了几十个工具最后用得最多的还是那三五个所以工具清单一定要定期做减法。2. 测试篇从功能测试到 AI 测试的完整路径2.1 自动化测试入门接口优先还是 UI 优先测试这部分我先说一个自己的观点自动化测试不要一上来就做 UI。UI 自动化维护成本极高页面上一个按钮位置变了脚本就挂排错的性价比很低。更稳的顺序是先做接口测试。接口是系统的骨架接口可靠了上层 UI 一般也不会出大问题。日常工作中我会先用 Apifox 或 Postman 把接口的请求、响应、鉴权方式调试通然后写 pytest 脚本自动化断言。一段最基础的接口测试大概是这样的import requests def test_login(): resp requests.post(http://127.0.0.1:8080/api/login, json{ username: admin, password: 123456 }, timeout5) assert resp.status_code 200 assert token in resp.json()注意这里断言不能只检查状态码还要检查关键字段、响应时间和数据格式。比如登录失败时要断言错误信息列表接口为空时也要断言结构正常。接口测试跑通后再考虑用 Playwright 做关键路径的 UI 冒烟。Playwright 的好处是自带自动等待不用像早期 Selenium 那样写一堆显式等待的代码录制的脚本还能自动生成选择器。实际项目里我一般把接口测试放进 CI每天定时跑UI 冒烟只覆盖注册、登录、主流程这类核心场景。这个取舍不是偷懒而是让测试投入产出比最高的方式。如果是音视频类的接口还可以准备公共的 RTMP 测试地址来验证推流和拉流链路这类资源在流媒体社区里比较容易找到。2.2 测试思维边界值、Linux 面试题和“鹈鹕测试”测试做到后面工具都是次要的思维方式才重要。你看到一个 Linux 命令会不会下意识去测它的边界比如 grep 在空文件、超大日志、乱码文件里表现如何比如df -h看到的磁盘空间和实际可写空间不一致是不是有文件被删除但进程仍然占用。这些就是测试思维的日常训练。网上最近流行各种测试方法比如鹈鹕测试表面上是拿一些反直觉的提示词去考验大模型能不能绕过常见思维误区本质和传统软件测试里的边界值分析是一回事输入域不只是正常的合法值还有空值、超长值、非法编码和语义陷阱。我自己在本地模型上试过类似做法把同一个问题换五种表达方式问一遍答案一致性差得离谱这就说明模型的边界比你想象的窄。Linux 面试题其实也是这个思路。比如查看某个端口被谁占用ss -lntp、统计日志里重复最多的十行sort | uniq -c | sort -nr | head、找出消耗 CPU 最高的进程top或ps aux --sort-%cpu。这些题刷起来不是目的真正有用的是让你形成一种“系统会怎样表现”的判断力这样出了问题才能凭直觉快速缩小范围。2.3 AI 测试怎么做大模型输出的验证与评测AI 相关的测试这两年变化非常大。传统接口测试靠断言和预期值就能判断通过与否但大模型输出是概率性的同样的问题每次回答可能都不一样。所以 AI 测试的断言不能硬比对而要分几层第一层检查格式比如要求 JSON 输出时能不能被解析第二层检查关键实体或关键词比如要求返回部署命令时必须包含 docker compose 或 ollama 这类词第三层是语义相似度把模型回答和标准答案做向量化计算余弦相似度低于阈值再人工介入。语义相似度可以用 bge-m3 这类本地向量模型完成不需要调用外部接口。除了自动化断言还要建立评估数据集。我的做法是每个功能准备 20 到 50 条样本包含正例、反例和边界输入每次调整提示词后都批量跑一遍把结果记录到 CSV 里做回归对比。这相当于给 prompt 做版本管理不然你根本说不清是哪次修改让效果变好了还是变差了。另外模型本身的温度参数也要纳入测试范围低温输出更稳定适合做规则类任务高温输出更发散适合做头脑风暴但测试用例里要固定参数否则结果不可比。大模型测试没有银弹但它本质上还是测试把不确定性变成可观测、可统计的指标就成功了一大半。2.4 安全测试与渗透测试学习路线再聊一聊渗透测试。这个话题很容易被误解我必须先把底线说清楚没有授权就绝对不能碰任何不属于自己的系统这是行业红线和职业底线碰了就是自毁前程。想学习渗透测试正确路径是在本地搭靶场比如 DVWA、Vulhub或者注册一些公开的漏洞测试平台在授权范围内练习。学习路线大致是先扎实 HTTP 基础搞明白请求头、Session、Cookie然后了解常见漏洞类型比如 SQL 注入、XSS、CSRF、文件上传、越权访问再学工具Burp Suite 用来改包和观察流量nmap 用来做端口扫描sqlmap 用来验证注入点。注意工具只是辅助关键是要能看懂漏洞的本质原理。一个标准的渗透测试流程包括信息收集、端口探测、漏洞扫描、人工验证、输出报告。报告中要写清楚危害等级、复现步骤和修复建议帮助开发团队堵住漏洞。渗透测试工程师的价值不是“能黑进去”而是能提前发现并修复问题让系统更安全。我见过不少新手一上来就翻工具教程对漏洞原理完全不了解这是本末倒置。安全测试的核心依然是测试思维找到系统没有预期到的输入验证它会不会产生危害。3. 部署篇从 Docker 到本地大模型的一线实践3.1 Docker 安装与容器化部署的最小闭环部署环节我强烈建议先掌握 Docker。它解决的是环境一致性问题本地能跑服务器上也能跑不用再为依赖冲突浪费半天。以 Ubuntu 22.04 为例安装 Docker 最简单的方式是apt update后安装docker.io和docker-compose-plugin然后systemctl enable --now docker让它开机自启。装完后跑一个最小例子验证环境docker run -d -p 8080:80 nginx:alpine。浏览器访问http://服务器IP:8080能看到 nginx 默认页就说明容器化链路通了。这条命令里-d表示后台运行-p 8080:80把宿主机的 8080 端口映射到容器内的 80 端口nginx:alpine是官方镜像的精简版本。新手容易踩的坑有三个不用挂载卷就把数据写在容器里容器一删数据全没了镜像名不固定版本而用 latest升级后行为无法预期还有容器以 root 身份运行权限过大。我的习惯是启动时用-v把数据目录挂到宿主机尽量用具体版本号的镜像需要控制权限的动态指定--user。当服务数量多起来就别一条条docker run了用 docker compose 编写服务编排。配置文件里定义容器、端口、依赖关系一条docker compose up -d全部拉起这才是工程化的起点。3.2 大模型本地部署Ollama 与 DeepSeek 的选型现在热度最高的部署场景非大模型本地化莫属。Ollama 是我目前用得最多的引擎安装简单一条命令就能把模型跑起来。装好 Ollama 后执行ollama run deepseek-r1:7b就能下载并启动 7B 参数的 DeepSeek R1 模型。这里要注意选型模型参数不是越大越好而是要看硬件。7B 模型的量化版本大约需要 4 到 6 GB 显存CPU 也能跑但速度慢14B 建议至少有 16GB 内存且还是明显吃力32B、70B 级别的模型普通个人电脑基本跑不满速需要多卡或者纯 CPU 长时间推理。选择模型时还要关注量化方式。常见的 Q4_K_M 在显存占用和效果之间比较均衡如果显存吃紧就选更小的量化。如果运行中报显存不足先在模型对话里把上下文长度调小比如num_ctx设置成 4096上下文窗口缩短能显著降低显存占用。Ollama 启动后默认只监听本机 127.0.0.1想让局域网内其他机器访问需要设置OLLAMA_HOST0.0.0.0再启动服务。它的 API 兼容 OpenAI 格式用 curl 就能测试curl http://127.0.0.1:11434/api/chat -d { model: deepseek-r1:7b, messages: [{role: user, content: 你好}] }本地部署大模型的好处是数据不出内网特别适合企业做知识库问答和敏感数据场景。我建议有 GPU 的先用 7B 起步没 GPU 的用 1.5B 版本先把流程跑通再考虑加机器。3.3 Dify 与数据库集群把服务真正发布出去本地大模型跑起来后下一步是给它加应用层。Dify 是开源的大模型应用平台支持知识库、工作流、Agent 和模型管理。部署 Dify 通常用 Docker Composegit clone官方仓库进入docker目录复制.env.example为.env然后docker compose up -d它有完整的 Web 界面可以在里面把 Ollama 或 DeepSeek 作为模型供应商接进来再上传文档搭建知识库实现基于本地大模型的 RAG 问答。这里最容易忽略的是向量化模型的选择。Dify 默认的向量模型可能来自外部服务如果网络状况不佳或数据敏感建议改用本地向量模型比如 bge-m3。说完应用层再聊数据库集群。很多企业级系统需要高可用比如 Apache Doris 这类分析型数据库推荐三节点部署架构三个 FE 节点组成 Follower 集群三个 BE 节点负责数据存储和计算前端访问通过负载均衡器接入。部署前要检查几点各节点时间是否同步、SSH 互信是否配置好、端口是否被占用。Doris 的数据目录建议放 SSD存储路径要预留足够空间大表导入失败很多时候就是磁盘不够。国产数据库如 GoldenDB 的三节点部署思路也类似先规划管理节点和数据节点再做节点初始化。集群部署最忌讳的是按文档一步步敲命令但不理解导致出了问题不知道从哪查起。我的建议是先把单机版部署成功再扩展成集群这样排查范围会小很多。另外最近做 AI Agent 时常常会听到 MCP简单理解就是给大模型配一套标准化的工具接口。比如把 neo4j-cypher 这个 MCP Server 下载并部署好后大模型就能通过自然语言生成 Cypher 查询直接操作图数据库。部署方式通常是npm install后按文档配置回调地址不算复杂但要求本地能连通目标数据库。这个方向很有意思值得关注。3.4 边缘设备部署RK3588 上的 YOLOv8部署的另一个趋势是边缘 AI。RK3588 是瑞芯微的一款高性能 SoC内置 6T 算力的 NPU可以拿来跑 YOLOv8 目标检测。在 RK3588 上部署 YOLOv8 的流程和普通服务器不太一样普通 GPU 上装 PyTorch 就能跑但 NPU 上需要用 RKNN 格式的模型。典型流程是先在 x86 机器上安装 rknn-toolkit2把 YOLOv8 导出成 ONNX 格式再转换为 RKNN 格式最后部署到板卡上运行。转换时要注意 YOLOv8 导出 ONNX 的 opset 版本要与 RKNN 支持范围匹配否则会报算子不支持。还有输入输出节点的名称要对齐转出来后可以用 rknn-toolkit2 自带的模拟器先做精度验证确认 mAP 没有明显下降再部署到真实设备。量化方面如果对精度要求高优先用 FP16如果追求速度且精度损失可接受再用 INT8 量化。实际运行中如果发现 NPU 占用率上不去可以先检查模型是不是真的被加载到 NPU还是退化成了 CPU 推理如果帧率不够可以考虑多线程方式把多路视频流分给不同核处理。边缘部署的命令和配置不复杂但对硬件规格、驱动版本、模型格式的匹配度要求很高做好环境记录和版本对齐能少踩很多坑。4. 实战中的坑与排查经验4.1 工具类问题的快速定位先整理一下工具类最常见的坑。Rufus 做启动盘失败首先确认 ISO 文件完整性下载后可以比对 SHA256 校验值其次尝试更换 USB 口尤其是台式机前置口容易供电不足最后把杀毒软件临时退出写盘工具经常被误拦截。Fiddler 抓不到 HTTPS 流量90% 的原因是根证书没有正确安装到系统信任区或者手机没有经过 Fiddler 监听的端口。U盘容量变小先用 Windows 磁盘管理看是不是分区剩余空间如果不是再考虑量产工具。量产的过程有点像手机刷机先确认主控型号找到匹配的量产工具版本设置好固定容量再开始中途断电基本就废了。C盘莫名其妙满了用 WizTree 按文件大小排序往往能发现是休眠文件、Windows.old 或者某个软件的缓存日志在作怪别上来就删 System32。4.2 测试执行中的典型报错测试脚本在本地能跑一到 CI 就挂这种问题我遇到太多次了。最常见的原因是脚本里硬编码了本地绝对路径比如C:/Users/xxx/test.csv。解决办法是把路径都改成相对项目根目录的路径或者用环境变量传入。UI 自动化报元素找不到先别急着加 sleep。sleep 是最不稳定也是最慢的等待方式正确做法是用 Playwright 的自动等待或者用显式等待条件等待元素可点击。接口测试中文乱码多半是响应编码没设置正确resp.encoding utf-8就能解决。大模型输出测试不稳定前面也提到了固定温度参数、增加抽样次数用统计结果而不是单次结果下结论。还要养成分层测试的习惯单元测试、接口测试、端到端测试各自承担不同的职责别指望一层测试覆盖所有问题。4.3 部署过程中的显存、端口与依赖冲突部署环节常见的坑按出现频率排个序端口冲突、依赖版本不一致、磁盘和显存不足。端口冲突的排查很简单ss -lntp看看谁占用了端口如果是 Docker 启动的容器可以docker ps查看端口映射后修改 compose 文件中的端口。显存不足时先看nvidia-smi确认是模型太大还是上下文太长。我踩过一个很典型的坑模型明明只有 7B但加载时把 num_ctx 调到了 8192结果显存直接爆掉把上下文降到 2048 就好了。RKNN 转换失败时检查 ONNX 是否包含动态尺寸RKNN-toolkit2 对动态输入支持有限导出时建议固定 batch 为 1 或 1x3x640x640。数据库集群部署同步失败先看各节点时间时间偏差超过一定范围会导致同步链路异常。日志永远是最重要的线索直接看docker logs 容器名、journalctl -u 服务名、tail -f 应用日志看日志比乱猜高效十倍。4.4 我的排查三板斧最后分享一套我自己的排查方法论不管工具、测试还是部署都能套用。第一板斧是看日志。绝大多数问题的线索都写在日志里包括报错堆栈、超时时间、数据库连接失败原因。服务用 Docker 跑就看 docker logs系统服务用 journalctl应用自己写日志就去 logs 目录。第二板斧是看资源。磁盘满了、内存溢出、CPU 跑满、GPU 显存耗尽这些都能通过htop、df -h、nvidia-smi一眼看出来优先排除资源瓶颈。第三板斧是最小化复现。把问题场景简化到最小比如绕过复杂业务逻辑只调用一个最简单接口看看是不是还能复现。如果能说明问题出在基础环境如果不能说明与上层业务有关。我个人的体会是遇到问题最忌讳上来就东改西改改完也不知道有没有关系。按照日志、资源、最小复现这三步走至少能避开 80% 的无用功。这个方法我用了很多年不管是排查本地大模型部署还是线上数据库底层思路都一样观察现象、收集证据、缩小范围最后再做变更。