启动：为什么要做这个“更新日志”官网？
我这人有个毛病，玩游戏要是没个干净利落的更新日志看，心里就膈应。官方那个日文站，做得跟上世纪的论坛似的，点进去看个公告，得滚半天，效率低得要命。加上《哥布林杀手》这个手游，更新又快又碎，我就琢磨着，不如自己撸一个，专门搞个中文的更新日志聚合站。
最初的想法很简单，就是想找个现成的模板，套上去，再用爬虫把官方发在推特或者Discord上的更新内容抓下来，自动发布。结果一上手，就被喂了一嘴的屎。
抓取与放弃：被API卡死的两周
我盯上的是Discord的公告频道。想着，消息结构统一，解析起来应该不难。我用了Python的requests和BeautifulSoup，信心满满地开始写爬虫脚本。
结果？Discord的防机器人机制卡得死死的，就算我伪装了User-Agent，它时不时还是给我弹验证码，而且更新日志这玩意儿，大部分是图片或者格式复杂的嵌套文本，BeautifulSoup根本解不动结构。
我转头去研究官方推特。推特API倒是能用，但免费额度那点东西，跑一次就没了，而且推特上夹杂着大量的抽卡广告和玩家互动，想从中筛选出纯粹的更新日志，需要投入大量的自然语言处理功夫，我立马就怂了。
我算了算时间成本，光是搞定数据源这块，我起码浪费了两周，进度条纹丝不动。当时我就下定决心：放弃自动化，回归最原始但最可靠的方式：手动输入，但必须配一个我自己能掌控的后台。
技术栈抉择与现实妥协
既然要手动录入，那后台系统就要舒服。我手边正好在练*和*。我决定用一个轻量级的Express后端配上一个简单的MongoDB来存数据。为什么选MongoDB？主要是因为更新日志的内容结构五花八门，有纯文本，有表格，有图片集，用MongoDB的Schema-less特性存起来最灵活。
我搭好了基础框架，写好了API接口，开始搞后台管理界面。这才是噩梦的开始。
我的目的是快速实现，但设计一个数据录入界面，让我能舒服地粘贴、格式化日文公告，再进行翻译，这个前端工程量比我想的大太多了。我只是想记个日志，不是想重写一个Word编辑器！
我当时看着满屏的代码，脑子里突然想起了一件让我辞职的事。
我的前一份工作：手动录入的阴影
我之前在一家做电商ERP的公司做运维。那公司的核心产品，就是一套十年前写的管理系统。那套系统，别说前后端分离了，连个像样的用户界面都没有，用的还是那种老掉牙的Swing界面。我们的核心工作，就是每天早上打开各种客户的FTP，下载他们昨天的销售数据，然后手动录入到ERP里。
我当时就问我们主管，为啥不能写个脚本，跑个定时任务自动导入？主管就怼我，说：“你以为不想？那系统接口乱七八糟，写脚本比你手动输还麻烦，而且公司请你来就是干这个的，自动化了你干”
那段时间，我每天的工作就是盯屏幕，复制粘贴，改格式，感觉自己就是一个活体数据接口。后来公司业务调整，说要“拥抱云服务”，但新的系统接口依然是一坨屎。我实在受不了那种被老旧系统和人力消耗绑架的感觉，直接拍屁股走人了。
最终实践：拥抱“土办法”的胜利
这段经历，让我对“复杂但不可靠”的系统产生了极大的抵触情绪。我立刻砍掉了Express和MongoDB。
我回归了最简单的静态网站生成器，用一个Markdown编辑器作为内容来源。我写了一个简单的Python脚本，只做一件事：监控一个特定的文件夹，只要我把新的更新日志（Markdown格式）扔进去，它就自动解析，生成标准的HTML页面，然后通过FTP（对，就是最土的FTP）推到服务器上。
具体流程变成了：
- 获取官方日文公告。
- 翻译，并整理成结构清晰的Markdown文本。
- 命名文件，例如
20231225_v1_5_new_*。 - 丢进本地文件夹。
- 脚本自动运行，生成网站，同步到线上。
虽然这听起来很“手工业”，但整个过程完全可控，我不需要担心任何API被封，不需要担心数据库崩溃。网站访问速度飞快，因为它是纯静态的。我只用了两天时间，就把从游戏开服到现在所有的更新日志，一条不落地补齐了。
这个“哥布林杀手_更新日志”官网，现在就是我的一个成就，它证明了，有时候最简单的“土办法”，比那些大公司砸钱堆砌的复杂技术栈，更稳定，更有效率。