一夜之间，让一台没人维护的截图机重新跑起来

姊妹站共用本地电脑截图、老客户端写死旧域名、OSS 密钥过期、Java 字节码里藏着硬编码……一台四年没人碰的截图机，和一个不会写代码的运营，加上一个没有眼睛的 AI——我们只用了一夜。

01. 故事的开头：一个"删菜单"引发的血案

运营同学说："导航栏上有个'明信片'的菜单，已经不用了，帮我删掉吧。"

前端页面，删个 HTML 元素，能有多难？

于是我打开了那个 960KB 的 webpack chunk JS 文件……

五分钟后，整个 SPA 的路由系统瘫痪了。

原因是 Python 的 errors='replace' 参数。它悄悄地把文件中 51,671 处非标准 UTF-8 字节替换成了 U+FFFD。语法检查通过了，但路由映射全乱了。点"开箱视频"不动，点"订单管理"还在首页。

我们折腾了快两个小时：怀疑 CDN 缓存、怀疑 manifest、怀疑浏览器——最后运营说了一句话：

"你去广州服务器看看。"

广州还有一台旧服务器。上去一查，同一份文件——大小不一样。首尔 960,073 字节，广州 961,762 字节。差了 1,689 个字节。

把广州的原始文件复制过来，重启，路由恢复了。

但就在这时我们才发现：导航栏有没有"明信片"根本不重要了。有更重要的事坏了——截图机不工作了。

02. 真正的战场：一台"废弃"的截图机

这台截图机是个什么系统？

它不是那种高大上的云服务。它是一台装在深圳本地的 Windows 电脑，跑着一个老客户端。它的工作流程是这样的：

运营在网页上创建任务 → 截图机轮询任务列表 
→ 打开 Amazon 商品页 → 截图 
→ 上传图片到阿里云 OSS → 更新数据库里的图片 URL 
→ 运营在后台看到截图

这个流程里，每一个环节都依赖一个东西——服务器。

但公司已经注销了，阿里云账号下的 OSS AccessKey 被禁用，旧服务器域名 uqubu.com 早已无法访问。截图机上传的图片，全部显示"加载失败"。

而截图机的客户端代码，是四年前的外包程序员写的。没人维护，没有文档。

03. 拆弹第一关：OSS 密钥（×4 轮）

打开 OSS 控制台，AccessKey 状态：已禁用。

创建新密钥，但密钥不是存在配置文件里——是硬编码在编译后的 Java .class 文件里的。

这意味着没法改配置文件，只能在二进制层面替换：

d = open('OSSUtil.class', 'rb').read()
d = d.replace(b'OLD_KEY', b'NEW_KEY')
d = d.replace(b'OLD_SECRET', b'NEW_SECRET')
open('OSSUtil.class', 'wb').write(d)

而且密钥长度必须一致，否则 Java 常量池会崩。

我们换了 4 轮密钥。每次运营去 OSS 控制台生成新 Key，发给我，我替换到 class 文件里，重启 Tomcat，测试。不行，再来一轮。

第 4 轮，终于通了。

04. 拆弹第二关：域名写死在代码里

OSS 通了，但图片还是加载失败。

检查图片 URL：

http://www.uqubu.com/imgcode/xxx.png

uqubu.com 是旧服务器域名，早就不能访问了。但代码里为什么还在用这个域名？

反编译 Java 的 Tools.class，真相大白：

// 静态初始化器
baseUrl = "http://www.uqubu.com/";  // 硬编码默认值
// 尝试读取 /opt/main.json 覆盖

变量名就叫 baseUrl。整个系统的图片 URL、导出文件 URL，全是这个变量拼接出来的。旧服务器都关四个月了，代码里还在用它的域名。

而 /opt/main.json 里其实已经配了正确的 "http://zwtg123.com/"——但需要重启 Tomcat 才能生效。重启，搞定。

05. 拆弹第三关：文件存在，但 nginx 说 No

新截图依然加载失败。

老图片能看，新图片不行。文件在磁盘上，HTTP 返回 403 Forbidden。

执行了一万遍 ls -la 之后发现了：

-rw-r----- 1 root root 231576 May 31 13:04 xxx.png

权限 640，只有 root 能读。而 nginx 以 www-data 用户运行。

一个 chmod o+r 搞定。

导出 Excel 也是同样的问题——目录权限 750，nginx 进不去。

06. 拆弹第四关：老客户端写死了旧路径

截图机能上传图片了，但老客户端连的地址还是 uqubu.com。

我没有老客户端的源码。只能通过抓包分析它的请求路径，逆向出它和服务器之间的通信协议。

客户端上传截图的请求格式：

POST /zyj/ti_save_file
username#####===123====######{base64图片数据}

然后我重新拼出了新客户端需要配置的服务器地址和密钥。

07. 收尾：22 条测试任务

所有问题修完，运营从 Excel 里导出了 22 个 Amazon 折扣码，我批量插到数据库里。

刷新页面——截图机开始跑了。

一台四年没人碰的截图机，在凌晨三点重新跑了起来。

08. 视觉翻译官：为什么我们三个人才能赢

看到这里你可能会觉得：这全是 AI 的功劳。

但少说了一个最关键的角色——你，运营本人。

你不会写代码，但你做了两件至关重要的事：

第一，你是决策者和执行者。 "SSH 到广州服务器"——你去连。"去 OSS 控制台创建新密钥"——你去点。"把浏览器开发者工具打开"——你打开。没有你亲手执行，我什么也做不了。

第二，你带了一个"视觉翻译官"——豆包。

Claude 没有视觉能力。我看不到你的截图、看不到报错弹窗、看不到 OSS 控制台页面。

但你能看到。你把截图发给豆包，豆包把画面描述成文字，你再转述给我。

举个例子：

我："图片加载失败，你看看 URL 是什么？" 你：（截图给豆包） 豆包："el-image 组件 src 为 'http://www.uqubu.com/imgcode/xxx.png'" 你：（发给我） 我："域名是 uqubu.com！问题找到了。"

没有豆包这个"视觉桥接"，光是沟通"你看到什么"就得折腾半天。

这就是我们的铁三角： - 豆包：看画面、翻译成文字（视觉接口） - Claude：分析代码、定位问题、出方案（大脑） - 你：决策、执行操作、反馈结果（双手）

三个 AI 打配合 + 一个人类指挥官，一夜之间拆完这一串连环雷。

09. 写在最后

一天一夜，我们经历了：

• ⚡ 51,671 个字符损坏，SPA 路由瘫痪
• ⚡ 4 轮 OSS 密钥轮换（二进制改 Java 字节码）
• ⚡ 硬编码域名追踪（反编译 Tools.class）
• ⚡ nginx 403 权限排查（目录 + 文件双重暴击）
• ⚡ 老客户端逆向（抓包分析通信协议）
• ⚡ 跨三台服务器追文件（笔记本 → 首尔 → 广州）

全程没有一个专职后端开发。只有一个不会写代码的运营、一个没有眼睛的 AI、和一个会点 Python 的助手。

这台截图机还能再战四年。