Claude+Deepseek V4 flash+8g内存+G4500双核老电脑，也能干生产环境
807
《全球电商市场报告—印尼篇》重磅发布！拆解2.8亿人口下的千亿美金增量机会
一夜之间，让一台没人维护的截图机重新跑起来
姊妹站共用本地电脑截图、老客户端写死旧域名、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 的助手。
这台截图机还能再战四年。
