涅普智可的个人小站

针对VRD程序骨的小记录

Tue, 15 Sep 2026 00:00:00 GMT

今年春季的时候开始在用Blender做VRC模型向Garry's Mod模型的转模，遇到了一些VRD程序骨不自然的问题，然后一直没修明白

最近重新研究了一下别人做VRD的思路，这里记一记吧

以后有机会的话可能会考虑把我学的整个工作流都做个记录（？），毕竟中文区这方面的文字是真少的可怜了。。。我自己就是对着一篇英文教材走完的全流程

程序化骨骼

虽然我们平时都会用==VRD防穿模==这种简单的叫法来称呼这个东西，但其实它的学名应该叫==程序化骨骼==来着，下文为了方便，我就称其为==程序骨==了

程序化骨骼的定义

在V社官方文档中，程序骨被定义为：

程序化骨骼（在其他地方也被称为骨骼“驱动器”（Blender）或“驱动关键帧”（Maya））通过一个骨骼的旋转来驱动另一个骨骼的旋转和位移。第一个骨骼——称为驱动或控制骨骼——通常由人类动画师进行操作，而第二个骨骼——称为程序化或辅助骨骼——根据驱动骨骼的旋转，自动旋转和/或位移。特殊的旋转关键帧，在VRD文件中被称为“触发器”，用于将驱动骨骼的运动范围映射到程序化骨骼的运动范围。

带有沿轴扭转骨骼的人的前臂，是Source中程序化骨骼的典型示例。当手部骨骼顺时针旋转时，前臂中的扭转骨骼也会自动顺时针旋转。当手部骨骼逆时针旋转时，扭转骨骼同样会逆时针旋转。这两种旋转的范围都可以在VRD文件中轻松控制。

简单来说，在Source引擎的定义里，程序骨就是一种==“由程序控制的骨骼”==。通过一定的驱动配置，程序骨跟随驱动骨的移动而移动，从而在不手动指定程序骨动画的情况下，实现程序骨的移动

而VRD文件，就是记录程序骨驱动内容的文件，所以它也就经常被叫做==VRD防穿模==

程序化骨骼的实例

那么程序骨在哪里有用呢？对于我们这种做~啥比二次元~的模型作者来说，最显然的一种用法当然就是裙摆了

在现代游戏和模型中，裙摆经常由不同的方法来驱动防止其与大腿穿模。我们暂且不讨论“把裙摆跟裤子一样当成一个不会飘动的固定的物体”这种很抽象但是最简单的实现，我们来看看能让裙子自己飘动的写法：

比如MMD使用的VRM，以及VRC模型本身，都是设定一个针对骨骼的“碰撞体”，用“碰撞体”控制骨骼之间是否碰撞，来实现“裙子被大腿顶着”的效果

而起源作为一款老引擎，自然没有这么方便的方法来防穿模，所以我们就需要学会去使用程序骨了。

以下是两个例子，左边是没有配置程序骨的裙子，右边是配置了的，相信一眼就可以看出不一样：

:::grid{columns="2" aspect="16/9"}

:::

~感谢被薅出来的智可的演示（x）~

除了裙子这种以外，程序骨还有另外的~不那么啥比二次元~的用法

在转模的制作中，由于我们是将原有的模型骨架迁移到游戏的角色骨架上的，所以不可避免的遇到不适配的情况

比如说，在Garry's Mod的PM中，玩家右手的根骨骼都是ValveBiped.Bip01_R_Hand

但是在Eku/Milfy的素体中，有一根Wrist_support.R，是用来修正右手臂动作的

如果不使用这跟骨骼修正，有些比较极端的动作就可能让Eku/Milfy的素体出现穿模

:::grid{columns="2" aspect="4/3"}

:::

所以，我们就需要把这跟Wrist_support.R设置为由ValveBiped.Bip01_R_Hand驱动的程序骨，才能解决问题，这个问题在制作C-Hand手模的时候还挺容易遇见的

:::tip 小tips 手腕和手，其实可以映射到现实世界人类的骨骼关系

记住这点，在做程序骨的时候，尤其是在做人形模型的时候，最好还是把你要做的模型看成你，考虑好骨骼关系 :::

VRD文件的构成

V社在在线文档中为我们提供了VRD的写法，如下：

<helper> hlp_forearm_L   bip_lowerArm_L   bip_lowerArm_L   bip_hand_L
<basepos> -0.0003 -4.7578 -0.000685692
<trigger> 90 	-0.140879 -7.0729 0.923253 		2.05439e-06 -0.00011566 -0.0109454 	0 0 0
<trigger> 90 	-157.919 -89.6281 158.827 		0.101044 -61.3622 -0.505184 		0 0 0
<trigger> 90 	-0.905463 81.1157 0.0128013 	-1.79037e-05 49.6029 -0.0109647 	0 0 0

<helper> hlp_forearm_R   bip_lowerArm_R   bip_lowerArm_R   bip_hand_R
<basepos> -0.0502548 4.76207 -0.0109539
<trigger> 90 	-0.116485 -7.07782 0.923253 	-26.1455 -71.739 -60.6497 		0 0 0
<trigger> 90 	-0.288436 72.9621 0.610626 		-72.1773 -44.2586 -20.2743 		0 0 0
<trigger> 90 	-179.149 -81.8242 -179.905 		81.3212 -37.0352 -157.273 		0 0 0

在编写完成之后，VRD通过以下代码，从模型编译文件中调用，进入编译生产：

$proceduralbones <configuration file>

我们可以看到，标准的VRD由多个<helper>构成，每一个<helper>块构成了一组VRD的驱动块

一组VRD的驱动块，需要一个<basepos>，作为程序化骨骼在其父骨骼的本地坐标系中的参考平移位置，然后就是若干个<trigger>，<trigger>会作为关键帧，用来实现姿态的参考

:::warning 注意第一个<trigger>必须是驱动骨骼和程序骨的参考姿态旋转，以裙子的例子，就是人站立着，裙摆自然下垂的模样 :::

不过，在现在，我们完全可以不使用人工编写的方法来编写VRD，下面，我们将介绍利用NekoMDL进行VRD编写的操作

NekoMDL与程序骨自动生成

更好更快更强的mdl编译器 - nekomdl

——Starfelll佬如是介绍NekoMDL

NekoMDL是什么？

NekoMDL是Starfelll大佬开发的一款模型编译器，Starfelll大佬是做L4D2工具开发的（顺带一提，大佬最近的作品就是L4N框架和NekoToon渲染器，恐怖如斯），但是由于Source 1的模型编译器的通用性，使得此工具也可兼容到Garry's Mod模型开发

目前NekoMDL的官方获取方式仅为L4D2创意工坊，如要获取，请：

:::steps{title="安装NekoMDL"}

通过Steam创意工坊订阅NekoMDL
启动L4D2
等待L4D2完成创意工坊缓存工作
前往/Left 4 Dead 2/left4dead2/addons/workshop，寻找3142607978.vpk
解压，在Crowbar配置NekoMDL为模型编译器

:::

为什么要使用NekoMDL？

NekoMDL在v0.4.0就引入了命令$NekoDriverBone，可以从Blender导出的动画关键帧直接作为参考生成VRD的<trigger>

从我们刚刚的介绍也可以看出，一个<trigger>本质就是一个动画的关键帧，这也是为什么$NekoDriverBone可以实现这个效果

如何利用NekoMDL生成程序骨？

我懒了，这个等以后如果真的要写完整流程记录再说吧。。。

大家可以参考下面这个视频，我们后面来给它的流程纠纠错：

::bilibili{bvid="BV1iZ421M7rx" title="由“CCCrino”大佬制作的MMD模型转GMod模型视频教程" p=8 preload="none"}

关于我最近研究的想法

手腕和手，其实可以映射到现实世界人类的骨骼关系

记住这点，在做程序骨的时候，尤其是在做人形模型的时候，最好还是把你要做的模型看成你，考虑好骨骼关系

——涅普智可刚刚如是写到

发生了什么

好了，为什么我要在这里重新强调这么一句话呢？

在我之前按照视频的教程完成模型之后，我发现了这么一个问题：

因为我此前就是按照教程完成的程序骨，所以我当时没考虑这么多，这个问题就一直被我丢在这丢了好几个月

解决方法

最近搜了一些资料，发现了一个运行在==Blender 4.5+==上的==BlenderSourceTools==魔改分支：==PulseSrcOps==

::github{repo="ToppiOfficial/PulseSrcOps"}

这里面带了一个能在Blender内部编写VRD的功能（虽然最后我是觉得还是用NekoMDL好点），而且最关键的，它支持从VRD中导入程序骨约束定义，并且生成在Blender动作编辑器里

我去，还有这种好事？

然后我就用这个工具导入了几位佬的模型，看看人家的VRD是怎么编写的

然后就发现：先前的教程教了错的东西，也不一定说是错的吧，但是一定是容易出问题的方法

先前的教程的关键帧为：==腿向前90°、向侧90°、向后90°==

这肯定是最符合编写直觉的操作，但是，如果您现在自己站起来，这样子蹬蹬腿，您平时会有意的让侧向和后向蹬腿到90°吗？

所以，几位佬的方案都是：==腿先向前90°、然后维持向前，向侧转30°、最后复位腿，再向侧30°==

这就是为什么我刚刚莫名其妙的强调骨骼关系这件事，也就是我这次研究搞明白的

然后我就站起来向后蹬了蹬腿，想了想，又加了一条向后30°的约束，大概像下面这样：

:::grid{columns="2" aspect="16/9"}

:::

弄好，然后导入游戏，搞定！

问题成因

其实我也不是很清楚为什么会发生这种事情，所以我就来猜猜吧：

我的猜想是，程序骨是根据关键帧生成的，但是根据关键帧参考生成的结果的不急会很怪异

简单来说就是，我们肯定是假设程序是根据关键帧的结果，平滑的生成程序骨映射嘛

但可能实际程序上的映射会更激进一点，导致出现裙子被诡异的支撑起来的样子

不过，这样映射之后，裙子肯定还是会有没被映射到的地方

所以我建议，如果显然不是人类能做出的动作，我们就专门做一个不含有飘骨的模型，然后用Overhauled Bone Tool手动接管所有骨骼参数，摆出我们要的动作

总结

这次发现的东西简单来说就是，用下面这个步骤设置关键帧动作：

:::steps{title="关键帧的设置"}

先设置腿向前转90°
在上一帧的基础上，腿向外侧转30°
把腿恢复到原状态，设置腿向侧转30°
把腿恢复到原状态，设置腿向后转30°

:::

然后编译的模型的裙子就正常啦，可喜可贺可喜可贺

SteamDB的简单指南

Sun, 13 Sep 2026 00:00:00 GMT

::: warning 提示本文于2023年开始创作，且时至今日仍未完成
本文的内容可能已经过期（最新消息是，SteamDB即将加入Nexus Mods，而非独立运营），请谨慎阅读 :::

创建 SteamDB 是为了更深入地了解 Steam 数据库. 我们跟踪 APP 和 SUB 的更新, 我们保留对 APP 和 SUB 做的所有更改的历史记录. 我们还提供一些其他工具, 例如: 计算器可以让人们深入了解他们(本人或他人)的 Steam 帐户, 在这之前是根本做不到的.
SteamDB 是一个纯粹的数据库网站, 它不提供任何下载, 也不支持盗版.

——SteamDB官方FAQ，由@Chr_及其翻译脚本贡献者翻译

SteamDB，一个Steam的民间数据库，由xPaw开发，由其本人和社区用户共同贡献数据内容，旨在帮助Steam用户了解Steam中App和Sub的更新，以及更加了解自己的Steam账户本身
网站本身为开源项目，其GitHub项目链接如上

由于实在感觉国内某些平台（不说，都懂> <）能查询的功能实在太基础，所以慢慢写了这个小指南，希望能帮到有时有类似需求的大家

0.SteamDB主界面及民间汉化脚本

SteamDB的URL为 https://steamdb.info/ ，访问后主页如下图

由于开发者应该不会为其添加中文，所以可以下载由@Chr_大佬制作的汉化脚本（需使用Tampermonkey），使用后，可将大部分平时需要使用的内容汉化
汉化后页面如下

为方便期间，本文后面大部分的专有名词将使用汉化脚本的译名

1.Steam商店与库中的重要概念

在正式介绍Steam功能之前，需要介绍Steam商店和我们下载到的游戏运行的基本框架
简单来说，Steam以Sub（Subscription）记录所有购买，Sub下含有App（Application）和资产（Depot），用户在游戏库中访问App，App通过调用与其关联的资产完成下载操作，随后用户进行启动游戏操作，经过DRM验证，游戏运行

1.1.Sub

Sub,全称Subscription，Steam记录购买的单元
你的每一次购买和激活，其实都是为账户添加了一个（或多个）Sub，你可以在你的账户明细->查看许可和产品序列号激活界面下查看你账户中登记的所有Sub包的名称
在安装SteamDB浏览器拓展插件后，你在SteamDB页面对应分页将可以看到你持有的对应Sub记号

1.2.App

App，全称Application，Steam记录产品的单元
你的Steam库中所有的“游戏”“软件”，和在它们下面的“DLC”，本质上都是一个App，都拥有其独立的AppID
对你库中的游戏右键，选择“属性”，在“更新”分页下，你将看到此游戏的AppID

或者，访问一个产品的商店页面，在其URL中，你也可以知晓此产品的AppID（URL中间的数字）

在安装SteamDB浏览器拓展插件后，你在SteamDB页面对应分页将可以看到你持有的对应App记号

1.3.资产

资产，Depot，Steam记录文件信息的单元
一次安装操作，通常会调用多个资产，在SteamDB的App页面中，我们可以看到一个App对应的资产
通常，部分Sub中只含有了部分语言（或者不同语言的配音文件）的资产，所以也就有“锁语言”的说法

例：赛博朋克2077的资产列表，不同语言配音的文件是分在不同资产下的

在安装SteamDB浏览器拓展插件后，你在SteamDB页面对应分页将可以看到你持有的对应资产记号

1.4.捆绑包

捆绑包，Bundle，一种特殊的Steam购买单位
捆绑包由多个Sub捆绑而成，并加上厂商设置的捆绑包折扣。在购买时可分为“可以补齐”和“不可补齐”两中
一般情况下，捆绑包会在商店里排列在其中包含的App的购买选项的下方，作为一种补充的购买选项存在
在购买或补齐一个捆绑包后，此捆绑包含有的所有Sub将加入你的库存

2.SteamDB基础模块：App页面

App页面，是SteamDB的最基础的模块，也是大家在使用SteamDB的时候最常用的页面
App页面的URL为：==https://steamdb.info/app/<你查询的AppID>==，将你需要查找的AppID键入SteamDB的搜索栏后回车，也会将你自动定向至对应的App页面

（为什么我要查询的App显示为“SteamDB Unknown App”？）

下面是App页面的一个例子

在一个App页面的最上端，会有一个列表，显示此App所有基本信息，以及它的快捷操作链接

一般情况下，我们最常用到的是一个App的价格、图表、Sub、资产页面，不过下面还是一一介绍

2.1.价格

价格分页，SteamDB最常用的分页，在此分页下，所有Steam定价区域的价格都会在上面显示
下面是一款游戏的价格分页例

右上角的按钮，可以选择一个基准货币，基准货币默认以你使用的IP对应的区域在Steam中使用的货币为准
基准货币的价格信息，会置顶于列表顶部，其余的每一行为一种货币
列表的第二列，为此App当前在Steam商店（默认为此App在商店页面的第一个购买选项）的价格，以本地货币显示，百分数代表此购买选项目前的折扣力度
列表的第三列，为第二列的数据换算为基准货币的价格（以今日汇率换算），百分数代表换算后与基准货币售价的差距，“-”表价格低于基准货币区域，“+”表价格高于基准货币区域
列表的第四列，为此App历史的最低价格，换算为基准货币价格显示，右边的灰字为原货币的史低价格，百分数表示史低时的折扣力度

如果有App针对某一区域没有定价（即锁区），那对应区域的价格将显示为“N/A”

列表的底部，是历史价格图表，默认显示的是基准货币的价格图表，最多默认显示三年的价格信息
使用鼠标滚轮，可以缩放图表，或是使用鼠标左键按住并拖拽，框选一部分时段放大显示

将鼠标悬停在某一时间段，可以显示此时间段的价格信息与折扣力度，近年的折扣如果是大型特卖活动中的折扣，对应的活动名同样会显示

列表上的虚线，是从史低的价格延长的线，用以大致对校史低
如果有需要的话，在上方的列表中单击需要查询的区域的价格的行，价格历史图表会自动切换为你选择的区域的价格历史

::: tip 一点你可能想知道的。。。 2023年11月20日，Steam正式取消了阿根廷比索与土耳其里拉的定价
如果需要查询此区域曾经的价格历史图表，请选择价格列表底部的"Removed: ARS TRY" :::

2.2.图表

图表分页，用以记录一款游戏的玩家数据，包括同时在线人数、历史在线人数峰值等
由于这个分页的图表操作与价格历史图表类似，且易于理解，所以不多介绍（实际上是这个分页的截图截下来实在是太长了TvT）

2.3.APP信息

APP信息，用于记录一个APP在Steam的数据库中所有的信息
因为大部分信息作为用户不需要太了解，且如果使用汉化脚本，这一页的信息的内容基本上都有汉化，所以不详细介绍

2.4.Sub

Sub分页，会记录所有SteamDB已知的（为什么我想查询的SubID不在此分页上？）与此App关联的Sub与捆绑包信息，并列成表呈现
一般情况下，一个App会有多个Sub（基本上没有少于3个Sub的App），下面是一个Sub分页的例子

这个页面，主要用于引导用户前往Sub页面和捆绑包页面，对应页面的详细介绍将在下文进行

2.5.DLC

DLC分页，用以显示SteamDB已知的（为什么我要查询的DLC显示为“SteamDB Unknown App”？）DLC信息
由于DLC本质是一种App，所以DLC分页下的所有内容，与本节基本一致

2.6.资产

资产分页，会记录所有SteamDB已知的（为什么我想查询的DepotID不在此分页上？）与此App关联的资产信息，并列成表呈现
一般情况下，一款App会关联一个或多个资产，并带有不同种类，下面是一个资产分页的例子

这个的第一个列表，主要用于引导用户资产页面，对应页面的详细介绍将在下文进行
而“分支”列表，会显示一款App所有为SteamDB已知的测试的分支信息
所有游戏的默认分支均为Public，在Steam库的属性->测试版中，可以选择一款游戏不同的分支
注意，此表中所有带有锁头符号的分支，都属于私密测试分支，需要输入测试密码（有的开发者会主动提供，如Unturned与2.0版本时的3.0版本测试，或者P社游戏的版本回退）才可访问

2.7.配置

配置页面，用以存储一款App在启动时Steam执行的操作，支持多种操作系统的游戏还会分操作系统版本储存启动信息
例如：《以撒的结合：重生》的Windows启动项为==可执行文件名：‘isaac-ng.exe’==，Steam就会自动在App安装目录里找到此exe并运行
再如：《看门狗2》的Windows启动项为==可执行文件名：‘bin\WatchDogs2.exe’==，并传入参数==-uplay_steam_mode==，则Steam则会以App安装目录的根目录为相对目录的起点("./")，并进入对应的目录找到此exe，并传入参数==-uplay_steam_mode==启动
又如：《双人成行》的Windows启动项为：==link2ea://launchgame/1426210?platform=steam&theme=it2==，则Steam会向系统发送此运行命令，启动游戏

2.8.云存档

云存档分页，用以存储一款App向Steam请求的云空间大小，有时也含有此App的存档目录与存档结构

2.9.本地化

本地化分页，用以记录一款App的本地化字符串
简单来说，就是记录某些游戏显示在你的游戏中状态下面的小字该怎么显示的，下面是个例子（游戏：==十字军之王3==）：

2.10.成就

成就分页，记录此App在Steam中所有已知成就

2.11.社区

社区分页，记录此App在Steam中所有已知社区物品（社区市场中Steam分类下的物品）和点数商店可兑换的物品

2.12.截图

截图分页，记录此App在Steam商店页面中所有的截图与视频资产

2.13.关联App

关联App分页，记录所有与此App在Steam中有关联的AppID
一般情况下，此页面会包含一个主App的所有DLC、Muisc、Tool等类别的与主App有关联的App，或者一个次级App的主AppID

3.SteamDB基础模块：Sub页面

Sub页面，是SteamDB区别于其它数据区平台最重要的模块之一
Sub页面的URL为：==https://steamdb.info/sub/<你查询的SubID>==

（为什么我要查询的Sub没有提供更多信息？）

下面是Sub页面的一个例子

一般来说，我们最主要接触Sub有两种，一种是在商店售卖的Sub，一种是只能使用激活码激活的Sub（但除此外还有FOD、免费周的Sub等），他们直接除了部分分页的区别之外，并无特别的区别
在一个Sub页面的最上端，会有一个列表，显示此Sub的基本信息

3.1.价格

拥有商店页面的Sub的独占页面，功能与App分页的价格分页类似，但有所不同的是，此分页会提供此产品的Steam推荐定价（以美元为标准）
这里有个提示，Steam允许发行方隐藏任何Sub，但绝对不会在数据库中删除它，所以所有被发行方下架的Sub，在这里都是可以找到当时的价格等信息的

3.2.信息

此分页会显示一个Sub拥有的附加信息，包括其Sub类型、Sub可用状态、以及最重要的：已知限制
在Steam的激活码交易中，一直有个词，叫锁区。而如果在激活Key前能查阅到SteamDB的锁区状态，你就可以提前判断你是否买到了锁区Key
一般来说，所有有激活区域限制的Sub，都会在信息分页的最开始提供如下的提示信息：

其中，==This package can only be activated in specified countries==一栏表示此Sub只能使用在下列的国家/地区中的账户激活Key
==This package can only be run in specified countries==一栏表示在此Key激活后的3个月内，只有Steam认定你此时的IP为下列国家/地区的，此游戏才允许允许，三个月后，限制解除
这也是我们常说的锁激活和锁运行
当然，这个列表有时又写作==can NOT be activated==，就表示下列出的国家/地区是不能激活此Sub的

3.3.App

前面说过，“Steam以Sub（Subscription）记录所有购买，Sub下含有App（Application）和资产（Depot）”，这个分页，也就是记录此Sub下含有的所有App
这个页面，可以引导您前往对应的App分页

3.4.资产

与上面类似，此分页展示此Sub下含有的所有资产
这个页面，可以引导您前往对应的资产分页

3.5.捆绑包

此分页展示所有含有此Sub的捆绑包（一般是在商店有售的Sub独有的一个分页）
这个页面，可以引导您前往对应的捆绑包分页

4.SteamDB基础模块：捆绑包页面

捆绑包页面，相对于上面的其他页面较为特殊，因为它的所有信息都在“价格”分页下有集中显示，所有基本不用切换分页
捆绑包页面下的“Sub”、“价格”、“App”都和其它页面下的分页大差不差，起到判定与跳转作用
下面是一个捆绑包页面的例图

一个捆绑包，最值得我们注意的是上面的信息中的两条，一条是“Type”，分==Complete The Set==与==Must Purchase Together==两种
若为==Complete The Set==，则此捆绑包可以补全，而==Must Purchase Together==的捆绑包无法补全
还有一条是“Gifting”，有==Allowed==和==Restricted==两中，即可送礼和不可送礼

5.SteamDB基础模块：资产页面

（写的很糙，以后再加，现在主要赶冬促把基础的写好）（现在也没加，等以后真的有空了加）

前面说过，Steam的所有下载，都是下载一个或多个“资产”并组合为一整个游戏的，也就是说，资产代表的真正下载的东西
资产分页下，有两个分页是值得注意的，一个是“文件”，一个是“清单”
“文件”，顾名思义，是这个资产下的所有文件的列表，会显示所有文件的类型、大小、相对位置
而“清单”，是这个资产的所有更新记录，Steam不会删除每次更新的资产文件，也就是说，这些“清单”下的历史版本都是可以访问的
在Steam控制台下，输入download_depot <AppID> <Depot ID> <Manifest ID>，Steam就会在后台下载对应版本的资产文件，随后即可访问此版本的资产文件

6.SteamDB进阶：SteamDB浏览器拓展

（写的很糙，以后再加，现在主要赶冬促把这东西的基础介绍写了）

SteamDB浏览器拓展，是SteamDB官方发布的用于增强Steam使用的浏览器插件

安装后，可在：
SteamDB的网页下使用快捷关注、忽略产品功能，并可同步已登录账户上拥有和处于愿望单中的Sub、App、资产，并以蓝标在SteamDB中显示，同时，可使用SteamDB的快速添加免费产品包功能
在Steam的商店中，此浏览器插件可显示某一产品的预估拥有人数、当前在线情况、史低、史低近一次时间、近两年史低（当已经两年此产品没有达到史低时），并显示此产品每一个购买选项对应的SubID、BundleID，并提供跳转功能

最后再次提醒，本文其实尚未完成，等待维护（也有可能不会维护了）

本站建设中。。。

Sun, 13 Sep 2026 00:00:00 GMT

本站建设中。。。测试一下博客内页