折腾“凪光”这个官网，纯粹是被逼的。我们团队最早做东西，都是散兵游勇，项目代码放在私有库里，需求文档扔在共享盘里，更新日志？那玩意儿根本不存在，口头说一下就算数。
起心动念：为何非要搞个官网？
我记得是去年年初，一个大客户来谈合作，他们看了我们之前零零碎碎的Demo和文档，摇了摇头。客户原话是：“你们这不像是公司，更像是一群在地下室里瞎搞的学生。” 这话虽然难听，但句句戳中要害。我们缺乏正规感，所有的努力都因为信息渠道太乱而打了折扣。
那次谈崩之后，我回去立刻拍了板：必须把官网立起来，哪怕只是个门面，也要把我们所有的产品和动态整合到一个地方。核心目的就两个：一是给客户看，二是给自己人看，拉齐对项目进展的认知。
定下基调：技术选型与工具链的挣扎
我当时的想法是，能用最简单的技术，就绝不用复杂的。我们不是互联网大厂，没必要搞什么分布式微服务。我当时看了几个方向，差点陷进去：
- 第一个想的是用现成的CMS，比如WordPress。但那东西太重了，光维护环境就够我喝一壶的。
- 第二个是想用Vue或者React做个单页应用（SPA）。界面肯定漂亮，但是SEO怎么办？而且我只是想发点文字，杀鸡焉用牛刀。
我决定用最土的办法：前端用一套简洁的静态模板，然后想办法让“更新日志”这块内容可以快速迭代。 官网其他部分是死的，唯独“更新日志”必须是活的。
于是我把技术栈压到了最低配：纯HTML+CSS负责展示，然后用了一个极其轻量级的Node脚本，专门用来处理Markdown文件。我把每一篇更新日志都写成一个简单的Markdown文件，脚本运行一下，自动生成对应的HTML片段，然后塞到主页的“更新日志”专栏里。说白了，就是自己造了一个简陋到极致的静态内容注入系统。
硬着头皮：从零开始建构日志模块
真正的苦日子是开始干活的时候。我花了三天时间把官网的基本骨架搭产品介绍、关于我们、联系方式，这些都是一次性的。最耗费心力、最魔怔的就是这个《凪光_官网_更新日志》模块。
我必须定下一个规矩：更新日志的格式要统一，时间、类别、内容摘要，一个都不能少。我不是什么专业的UI设计师，界面排版差点没把我逼疯。一会儿觉得列表太密集，一会儿觉得字体不好看。我记得为了找一个合适的行间距，我对着浏览器调试面板磨了整整一个下午，发现，原来是我的CSS文件里有一个隐藏的全局样式冲突了，搞得我头皮发麻。
解决完前端的展示问题，后端那个自动转换脚本又开始给我找事。最初的代码写得太粗糙，它不能识别图片路径，导致日志里插入的截图全都裂开了。我不得不又花了半天时间，重写了图片路径的正则匹配逻辑。那段时间，我每天晚上都对着屏幕骂娘，感觉自己不是在写代码，而是在跟一堆字符打架。
但必须承认，当第一次敲下`npm run publish:log`，然后看到新的日志条目秒速出现在官网上的那一刻，成就感爆棚。这种自己掌控一切的感觉，比用什么大厂框架舒服多了。
长期主义：更新日志的坚持与意义
网站上线了，问题又来了：如何保持更新的频率？如果日志几个月不更新，那这个“更新日志”模块不就成了最大的笑话了吗？
刚开始的几周，我非常有激情，甚至把换个图标、优化一个按钮的体验都写进去了。但是人的热情总是有限的。有一次，我因为手头一个大项目赶工，连续四天没顾得上写日志。第五天早上，我打开官网，看到最新日志还是四天前的，突然感到一阵心虚。
那天下班回家，虽然已经晚上十一点了，但我还是强迫自己，把这四天所有零碎的改动都梳理了一遍，硬是凑出了两条日志。我当时坐在电脑前，看着窗外的万家灯火，心里在想：我这到底图个图的就是那份承诺，告诉所有人，我们一直在跑。
这个《凪光_官网_更新日志》对我来说，已经不光是一个对外的公示了。它成了一种鞭策，一种内部项目管理的工具。每当我们发布一次日志，就意味着我们完成了一个小阶段的交付。它把那些看不见的努力，转化成了实实在在的文字记录。
到这个日志已经积累了几十条。每一次打开文件，看到那些密密麻麻的条目，我就知道，这条路我们走得是踏实的。虽然过程很糙，代码很土，但它管用，而且完全在我的掌控之中。实践证明，搞技术，有时候土办法才是最长久的办法。