最近不少朋友问我，为啥突然搞了一个这么奇怪名字的站，叫《竹内的旅程》。今天我就把这整个瞎折腾的过程，原原本本摊开来，给大伙儿分享一下。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.me
起因：被公司流程逼疯了
我跟大家说，这个站能生出来，完全是被老东家的破流程给逼的。我们公司有个系统，每次项目搞完一点小小的更新，哪怕只是改了两个字，都得走一遍所谓的“更新日志发布流程”。
我这人最烦这些形式主义。光是打开那个超级慢的系统，填上十几二十个不痛不痒的格子，发起审批，挨个儿等那几个领导点完“同意”，一套下来，半小时就没了。我寻思着，我就想记录一下自己干了至于这么费劲吗？
那阵子我是真被磨得没脾气了，就下定决心，我要搞一个自己的、完全由我说了算的记录站。这就是“竹内的旅程”这个名字的由来——记录我自己默默折腾的那些事儿。
第一次拍板：要快、要糙、要能跑
我的要求很简单，第一，必须快，不能比公司的系统还慢；第二，必须糙，我不想把精力耗在什么花里胡哨的设计上；第三，要能跑，部署一次就别再管它了。
我立马就开始动手。
- 选技术： 我果断放弃了所有大型框架，什么Java、Python的后端我看都不看。我瞄准了最简单的静态生成器。我决定所有内容都用Markdown写完，扔上去就完事儿。
- 域名和主机： 钱不能多花。我花钱挑了一个还算顺口的域名，然后弄了一台最便宜的轻量云服务器。我当时就想着，这站要是将来火了，再考虑升级的事情。现在就先凑合着。
- 排版定型： 我扒拉了一个开源的、看着还算清爽的模板，抄过来，删掉所有多余的JS和特效。我坚持只保留最基础的HTML和CSS，保证它在任何地方打开都是秒开。
最核心的“更新日志”是如何自动化实现的
我的核心需求是“更新日志”，这部分我花时间好好琢磨了一番，决定用一个“笨”办法来实现自动化。
我规划了一个简单的流程：
- 我在本地用Markdown文件写完一条日志，文件名就是日期，比如`2025-12-07_*`。
- 我把这个文件用Git推到我的私人代码库里（我用了Gitea，自己在服务器上搭了个私有的）。
- 服务器这边配置好了一个Gitea的Webhook。它一收到推送，就马上触发一个Shell脚本。
这个脚本才是真正的幕后黑手。它负责做下面这些事：
- 它把最新的代码从库里拉下来。
- 然后，它跑起来一个我用Go写的小程序（不到五百行代码），这个小程序就干一件事：扫描所有Markdown文件，按照文件名里的日期给它们排个序。
- 它把所有Markdown内容转换成HTML片段。
- 它把这些HTML片段塞进一个主页面模板里，生成一个全新的、包含所有历史记录的`*`静态文件。
- 大功告成，Nginx直接把这个新的`*`文件扔出去，用户看到的就是最新的内容了。
整个过程，从我按下“推送”那个按钮，到网站更新完毕，不超过五秒钟。我完全跳过了公司那套拖拖拉拉的审批流程。我坐那儿看着它自己跑，感觉真是痛快。
实现与反思
从我决定要搞这个站，到第一版“更新日志”正式发布上线，我连续折腾了大概三个周末的晚上。我投入的精力，主要是花在处理那些琐碎的自动化配置上，保证这个流程能一键跑通。
这个站现在跑得稳稳当当，虽然它长得不咋地，访问量也基本可以忽略不计。但它实现了我的诉求：高效、私密、自由地记录我的实践。它证明了一件事：很多时候，你不需要一个复杂的系统，只需要一个能解决你个人痛点的简单工具。自己动手，丰衣足食，这话真没错。
每当公司内部又出现更新流程卡住、审批走不下去的问题时，我都会庆幸，还好我当时“一气之下”搞了这么一个能自己说了算的地方。