一、我是谁，我遇到了什么问题
我是嵌入式行业的测试工程师，日常工作之一是维护一套跑了很久的自动化压测工程：通过私有 TCP 协议给被测设备下发指令，让设备执行完整的“升级 → 重启 → 版本校验”流程，两个版本之间反复切换，默认跑 3000 轮统计成功率——一轮约 11 分钟，全跑完要二十多天。
这次的问题是：压测产能不够，想在一台工控机上同时压多台设备提效。 但有个绕不开的约束——所有设备的 IP 都是同一个固定内网地址，保密要求不允许修改。多台同 IP 设备接到一个网络里必然冲突，而这套工程有 15+ 个文件，IP、日志路径、抓包、结果文件全是硬编码的，我需要：
- 搞清楚网络层怎么隔离（工控机有多个网口）；
- 改造整套脚本支持多实例并行，日志、结果、抓包互不干扰；
- 顺带解决一个长期痛点——每轮测试设备侧产生的日志，以前要人工登上去翻，想让它自动增量拉回本地，还要按轮次归档。
网络隔离的几种做法我隐约知道，但对这套陌生代码的改造量没底，估计要摸好几天。
二、我是怎么用 TraeCode 解决这件事的
全程用的 IDE 模式——这种改造要动核心压测脚本，每一步我都想自己确认过再落地。
第一步：让它先理解工程，再给方案
我没急着让它改代码，先丢了一个整体问题：
「这个工程脚本需要支持多个固定同 IP 的设备接同一台工控机做压测，设备 IP 不允许修改，工控机有多个网口。需要怎么压测？要什么设备？是否要网口隔离？脚本要怎么适配？怎么区分不同设备的日志？」
它先用探索智能体把整个工程扫了一遍（主流程、配置集中点、日志系统、通信连接方式），然后给了我一份完整分析：确认必须做二层隔离、对比了「策略路由」和「network namespace」两种方案的优劣、列出设备清单、IP 规划、需要改哪几个文件。我看完选了 netns 方案——每台设备独占一个网口和一个 netns，这样每个实例的网络参数完全一致，脚本里的 IP 一行都不用改。
第二步：让它落地代码修改
核心改动很克制：配置文件里用环境变量注入实例标识，不注入时行为和原来完全一样——单设备向后兼容这点我特意确认过；日志/结果/抓包目录按实例隔离；还有一个它主动提醒的坑：pkill tshark 会跨 netns 误杀其他实例的抓包，因为 netns 只隔离网络不隔离 PID，改成了按网卡名定向终止。
第三步：迭代新功能——日志增量拉取
接着我提了新需求：把日志拉取整合进压测主循环，每轮增量拉取、记录读取位置、不阻塞主循环、按轮次归档到独立文件夹。它新建了一个日志拉取模块：状态文件记录每个日志文件已读字节数，用 ssh tail -c +偏移 只传新增字节，后台线程执行，正好利用主循环等待重启的 60 秒空闲窗口。
中间我纠正过它一次：它把拉取触发点放在每轮开始，我指出设备在流程中段就已经重启完毕、后续阶段都在线了，放到每轮结束更好——它认了错还顺手补了退出时等待在途线程的收尾逻辑。AI 的方案不是全都对，但它接受纠偏的速度很快。
第四步：真实跑测，进入排障循环（这部分最值钱）
上机跑起来后连踩了五个 Bug，全是把日志粘给它定位的：
| 现象 | 根因 | 修复 |
|---|---|---|
| 列远程文件失败且报错为空 | ssh 远程命令没整体加引号，&& 和 $() 被本地 shell 解释了，for 循环在本地跑还返回了错误码 |
远程命令整体 shlex.quote |
| 轮末 pkill 直接把压测崩了 | tshark 没起来时 pkill 返回 1，check=True 抛异常 |
降级为告警 + 启动后早期检测 |
脚本报 SyntaxError: Non-UTF-8 code |
新加的中文注释被以 GBK 编码落盘，Python 按 UTF-8 解析必炸 | 注释改英文，文件变纯 ASCII |
某类日志拉不到，报 1/: No such file or directory |
文件夹名 test 1 带空格，scp 目标路径被 shell 分词成两截 |
路径加引号，后来干脆把命名改成 test_1 |
| 拉下来的日志目录 permission denied | scp -r 把设备端 root:700 的目录权限原样带了回来 | 拉完自动 chmod a+rX |
每一个都是「贴日志 → 定位根因 → 修复 → 下机验证」的循环，一般一两轮对话就收敛。像 GBK 编码那种问题，如果不是它当场把字节级原因（\xc5 是哪个字的 GBK 首字节）讲清楚，我可能还在怀疑是环境问题。
三、成果展示
最终交付的东西都在日常使用了：
- 多设备并行压测能力：一条命令拉起一个实例，N 台并行，日志/结果/抓包按实例 + 轮次双重隔离；
- 自动日志归档：每轮结束后台增量拉取设备侧日志到对应轮次文件夹（按字节续传不重不漏，另一类系统日志整夹快照），还能自动清理设备端滚动日志防止写满设备磁盘；
- 健壮性修复：抓包失败不再中断压测、进程任何方式退出都会收尾、netns 配错网口启动即报错并提示可用网口。
现在压测从「一次一台、二十多天」变成「几台并行、时间除以 N」，中途不用人盯着日志，跑完直接按轮次文件夹对账。
四、效率对比
- 以前：接手一个陌生工程，先花一两天通读代码理清链路；netns 这类运维知识要现查现试；像「ssh 引号转义」「GBK 编码落盘」这类 Bug，定位全靠手感，一个半天起步很正常。
- 这次：方案对比和改造点清单 20 分钟出来；五轮排障每轮基本「贴一次日志 → 拿到根因和修复」，整个多实例改造 + 日志系统 + 排障，一个工作日内闭环。粗算从原来的 3~4 天压到 1 天以内，而且每处修改都有注释说明「为什么」，后续接手的人能看懂。
五、经验和技巧总结
- 先要方案，再要代码。第一轮对话我只问「怎么做、要什么设备、改哪些文件」，不给它改代码的机会。拿到全局方案、自己拍板技术路线之后再放行，避免 AI 在错误方向上狂奔。
- 日志原样贴过去，比自己描述现象快得多。五次排障我一次都没转述，直接粘终端输出，它从
1/: No such file or directory里的「1/」反推出是路径空格分词，这个我自己可能都要瞪一会儿。 - AI 的时序判断要拿业务事实去校验。它把日志拉取放在每轮开头（误以为轮末设备在重启），我指出后续阶段设备已在线，它立刻改到轮末——更优的方案。你比 AI 懂业务，它比你懂代码细节，两边互补才是正确用法。
- 涉及编码和文件同步的事后验证别省。让它在修改后跑
py_compile验证，也让我在同步文件到 Linux 机器后花 10 秒再验一次——真帮我拦住过一次编辑被 IDE 缓冲区回滚的坑。