雪之湖畔 - SnowyLakeSide

过去软件行业有一句很有名的话： Text1Talk is cheap. Show me the code. 这句话代表了前 AI 时代非常典型的工程文化。空谈没有意义。能跑的代码才是真东西。不要只讲想法，把实现拿出来。 但站在 2026 年的角度看，这句话背后的价值结构正在发生反转。现在越来越像是：Code is cheap. Show me the idea. 在过去很长一段时间里，“Talk is cheap. Show me the code.” 是成立的。因为从想法到可运行代码之间，存在巨大的实现成本。很多人可以描述一个系统，但真正能把它稳定实现、接入工程、处理边界条件、修完 Bug，最终交付的人要少得多。 编程正在从脑力 + 体力劳动，变成近乎纯粹的脑力劳动 如果把程序开发粗略分成两部分： Text1设计 + 实现 那么在前 AI 时代，一个功能的大多数工时往往都消耗在实现上。 越是复杂的功能，工程实现越像一种体力活。你要写代码、改接口、接系统、补边界、调试、测试、修 Bug，再调试，再测试。即使最初的想法并不复杂，真正把它落地到生产环境里，也常常要付出大量时间。 ...

这次改的是一个很小，但看着很别扭的地方：Butterfly 首页文章卡片里，tags 默认跟日期、分类挤在同一行。信息是对的，视觉上却有点吵。 我原本只是想在首页显示文章 tag。打开 post_meta.page.tags 以后，第一眼就发现问题：日期、更新日期、分类、tag 全堆在标题下面，像把文章详情页的元信息直接搬到了首页列表。首页是让人扫一眼文章的地方，不适合塞太多碎片。 起因 Butterfly 的配置项很直接。在 _config.butterfly.yml 里把首页 tags 打开： 123post_meta: page: tags: true 主题会在首页文章卡片的 .article-meta-wrap 里渲染 tags。这个位置本来放日期和分类还行，继续追加 tag 就显得拖沓了。分类已经告诉读者文章属于哪个大方向，tag 更像补充索引，应该低一层，放在摘要后面更自然。 我还顺手把 date_type 调成了 both。既然首页已经显示元信息，我想让创建日期和更新日期都能看见。这个需求跟 tags 位置调整是同一次小改动，所以一起提交了。 为什么不...

这篇文章记录一次很小但挺实用的工作流改造：让 Codex 在修改 Hexo 博客之后，可以自己启动本地预览，拿到 http://localhost:4000/，继续做页面验证，而不是卡死在前台 hexo server 里。 问题本身不复杂。很多开发命令本来就是给人坐在终端前用的。人启动它，看完页面，按 Ctrl+C 退出。可 Agent 不一样，它需要在命令结束之后继续工作。如果命令永远不返回，后面的构建检查、页面截图、结果汇报就都没了。 一开始的问题 Hexo 的本地预览一般是： 1hexo server 或者项目里封装过的： 1npm run server 它们的行为都很正常：启动一个本地服务，然后一直挂在前台，等用户手动停止。 这对人来说没问题。对 Codex 来说就很尴尬。执行器会一直等命令结束，可 hexo server 正常情况下不会自己结束。于是一个本来只是想看页面的步骤，会直接把整个任务流程堵住。 之前的规则只能退一步：Codex 修改完站点后运行 npm run clean 和 npm run build，本地预览交给我手动开。能用，但不顺。每次改完都要人接...

这篇文章记录本站最近对 Butterfly 标签云做的一点小改造：通过自定义脚本重写主题的 cloudTags helper，让标签云直接显示每个标签下的文章数量；再通过自定义 CSS 把标签云从默认的活泼展示压成更克制的浅蓝色 pill 风格。 这事不算大功能，更像一次顺手把站点打磨舒服的小维护。不过它刚好碰到 Hexo helper、Butterfly 模板、自定义 CSS、选择器权重和可访问性标记几个点，还是值得记一下。以后再改主题，至少不用重新翻一遍。 为什么要改标签云 Butterfly 默认的标签云会根据标签文章数量给标签设置不同字号。这个设计很直观：文章越多的标签越大，视觉权重也越高。 但放到本站现在的规模里，它有点太“云”了。文章数量不多，标签也不多，单靠字号表达权重时，实际阅读体验并没有变得更清楚。 读者能看出 Cpp 比 Plugin 大，但到底多多少，还得猜。侧栏空间又窄，标签字号一跳，整个区域就会比旁边的分类和归档更抢眼。这个抢眼没有太多收益。 我想要的效果更朴素一点： 每个标签后面直接显示文章数量。 /tags/ 主标签页保持统一字号，减少视觉噪声...

这篇文章用于记录本站从 NeXT 主题迁移到 Butterfly 主题的过程，也顺便记录这次由 Codex 辅助完成的整理，排查，配置和验证工作。 这不是一篇从零开始的 Hexo 建站教程，而是一篇迁移复盘。对我来说，这次迁移最重要的目标不是把站点一次性改得多花哨，而是保证已有文章，图片，公式和页面结构都能在新主题下继续正常工作。 迁移目标 最开始的需求很明确：把当前使用的 NeXT 主题换成 jerryc127/hexo-theme-butterfly，同时尽量降低风险。 具体约束主要有几条： 已有博客内容必须继续正常渲染。 已有文章图片必须继续正常显示。 公式文章必须继续渲染正确，尤其不能被 Markdown 渲染器提前破坏。 优先使用 Butterfly 官方推荐方案。 移除 NeXT 主题和它的自定义残留。 使用 npm 安装主题，不再把主题 vendored 到 themes/ 下。 不迁移 NeXT 时代的外观自定义细节，先保证内容正常。 所以这次迁移不是简单把 _config.yml 里的 theme 从 next 改成 butterfly，而是围绕内容兼容...

整理了下近期以及过去做过的这方面的一些功能, 挑出点有意思的东西或思路谈谈. 这篇没有什么代码之类的东西, 就纯是碎碎念. UI 分辨率分离 这年头在移动端做 3D 游戏, 分辨率基本是没可能拉满的, 最高基本也就八九百这样子, 低配下甚至六百多都有可能. 虽然场景怎么低分辨率怎么糊都好说, 但 UI 是万万不能糊的, 一糊这游戏也别玩了. 所以场景&UI 分辨率分离就成了一个项目必需的 feature. 最简单也是最直接的方案就是给 UI 单独来一张 RT, 我们叫他 UITarget. 场景在低分辨率的 CameraAttachment 上渲完后 Blit 到高分辨率的 UITarget 上, 再交给 UI 相机绘制 UI. 听着很美好, 但实际并不能用. 因为这个方案对于带宽本就不富裕的移动端打击是致命的, 多一张 1080p 的 RT 简直是要了手机的老命. 于是就有了优化方案, 借用系统提供的 Backbuffer 作为 UITarget. Backbuffer 默认为手机硬件的原生分辨率, 无论任何情况下渲染管线的最终目标都会是它, 在 URP 正常的流程...

UE 渲染开发一直以来都是个很蛋疼的话题, 拜屎山一般的渲染系统所赐, 想要加点什么东西基本就只有改源码一条路可走, 以至于网上搜十个改源码的文章可能九个都是教你怎么加 ShadingModel 或 MeshPass. 我自己也曾在这类重复且枯燥的工作上花费大量的时间, 深切感受到这玩意到底有多恶心. 而且源码修改一时爽, 后续维护火葬场, 将来如果要升级引擎版本, 面对茫茫多的 diff 那才叫一个痛不欲生. 所以这个系列从 UE 的插件系统(Plugin)入手, 尝试探索在不改动源码的情况下, 如何最大限度的自定义渲染. 虽说不改 C++ 源码, 但 Shader 该改还是要改. 不过直接去引擎路径下改 Shader 就很恶心, 可能我只想为当前项目改动某部分 Shader, 但引擎路径下 Shader 的改动却会影响到本地的所有项目. 如果能像 Unity 那样每个项目自己有一份 Shader 就好了——正确的, 我们就先来把这个功能做了. 在动工之前, 需要先理解 UE Shader 的路径引用原理. UE shader 代码中 include 的文件路径并非真实的路径...

众所周知，C++一直没有一个官方提供的string split用于分割字符串，在过去（C++20之前）我们可能需要使用std::regex、std::string::find系列方法、甚至是继承自C的strtok函数来自行封装一个split，非常繁琐与不便。 然而，这一切都在C++20中发生了变化。C++20引入了范围库ranges，其中提供的两个范围适配器std::split、std::lazy_split可以使我们以一种更为优雅的形式实现split。 12345678910111213141516171819202122232425262728293031#include <concept>#include <ranges>#include <algorithm>#include <format>#include <iostream>#define stdr std::ranges#define stdrv std::ranges::viewstemplate<template<typename>...

待搬运, 内容详见原文链接. 原文链接: https://zhuanlan.zhihu.com/p/577239276

待搬运, 内容详见原文链接. 原文链接: https://zhuanlan.zhihu.com/p/575618981