46. 维护一个世界
第 44 章按了 Build & Publish for Windows，世界进了 Community Labs。第一波访客从自己的 Discord、推特、朋友圈来。前三天访问数据涨得很快，看着挺像那么回事。
第一周末访客数开始回落，只有少数人会回来第二次、第三次。Discord 群里冒出来几条「我刚才进世界，有个 bug……」。
这是几乎所有 VRChat 世界都会经过的状态。区别在于：
- 一类创作者把头几周当作世界的「最终版本」，bug 不修、反馈不接，世界很快滑出 Community Labs，再也没人提起。
- 另一类创作者把头几周当作世界的真正第一版本，把反馈做进 v0.2，做进 v0.3。一年后这座世界还有稳定常驻群体在玩。
差距不在 bug 数量上（每座世界发布时都有 bug），在于上线之后是否还在持续做事。这一章把「上线之后还做点什么」拆开。
第一节：头一周的反馈浪
Section titled “第一节：头一周的反馈浪”世界上线后头一周会出现这几类反馈，按出现频率粗排（以下比例是社区经验估计，不是 VRChat 官方统计）：
| 类型 | 大致占比 | 例子 |
|---|---|---|
| 平台兼容问题 | 偏多 | Quest 上某个材质是粉红色 / 某个交互按了没反应 / 视频播放器在 Quest 上不动 |
| 出生点和动线 | 中等 | 出生点朝墙了 / 找不到主活动区在哪 / 走错路掉出地图 |
| 小 bug | 中等 | 某盏灯不亮 / 某扇门卡住 / Pickup 物体掉到地下捡不回来 |
| 性能 | 偏少但很影响体验 | 进世界一瞬间帧率掉到 20 / 多人时玩家头像让世界卡到不能动 |
| 设计建议 | 偏少 | 「能不能加个 X」「这里要是有 Y 就好了」 |
| 赞美 | 不固定 | 「做得好棒，我会推荐给朋友」 |
前四类是要修的。第五类是设计判断，不一定要听（第三节会讲）。第六类是奖赏，记下来当下次没动力时翻翻。
Quest 兼容问题占比尤其高，原因是 Quest 玩家多（接近一半），但开发者多数主用 PC 测试，Quest 端的 bug 漏出概率自然高。第 39 章讲的「PC 跑通之后 Quest 单独再 Build 一次」流程在这里收割：跳过这一步发布的世界，第一周里 Quest 玩家会立刻打出来一堆兼容性问题。能在上线前自己用 Quest 头显走一遍世界，或者拉一个 Quest 玩家朋友单独测一遍，能把这一类反馈砍掉一大半。
第二节：搭反馈渠道
Section titled “第二节：搭反馈渠道”「让玩家能反馈 bug」这件事如果不主动搭，多数玩家会选择直接退出，不告诉创作者。VRChat 玩家整体对世界 bug 的容忍度不高，发现问题第一反应是换世界。
主动搭反馈渠道的几个常见选择：
在世界里挂一个反馈牌
Section titled “在世界里挂一个反馈牌”最低成本：在世界角落放一个写着「Found a bug? Join our Discord」的板子，板子前有一个 Pickup 名片或者 OpenURL 按钮（用 Networking.OpenURL），按了之后跳到 Discord 邀请链接。
这是覆盖率最高的方式：玩家在世界里就能找到反馈入口，不用回头自己搜创作者。
Discord 服务器
Section titled “Discord 服务器”VRChat 创作者的标配。一个简单的 Discord 服务器结构：
#公告 ← 创作者发布更新公告#反馈 ← 玩家发 bug 报告和建议#闲聊 ← 常驻群体日常聊天#活动 ← 定期活动通知50 人以下的小群体就够用了。规模大了之后再分细。
Twitter / Bluesky / 推特
Section titled “Twitter / Bluesky / 推特”VRChat 创作者圈子在英文区主用 Twitter，日文区也用 Twitter，中文区是 Bilibili / 小红书。
主要功能：发版本更新公告 + 接 @ 反馈。比 Discord 触达更广（不用加群就能看），但 bug 反馈不容易在 Tweet 评论里展开。
VRChat 网站的 World Description
Section titled “VRChat 网站的 World Description”最低维护成本：World Description 里写一行「问题反馈：[Discord 链接 / Twitter handle]」。玩家看世界详情页时能看到。
实战推荐组合
Section titled “实战推荐组合”新世界刚上线时不需要全部搭起来。建议：
最低配置：World Description 里写联系方式 ↓有 30 人常驻：建一个 Discord 服务器 ↓有 100 人常驻：在世界里挂一块「Join Discord」反馈牌 ↓开始跑活动：考虑 Twitter / Bluesky按这个梯度走，避免一开始就搭一堆没人用的渠道。
第三节：哪些反馈要听，哪些不用
Section titled “第三节：哪些反馈要听，哪些不用”不是所有反馈都该照单全收。从「修不修」的角度大致分四类：
必修：技术 bug
Section titled “必修：技术 bug”- 平台兼容（Quest 的粉红材质、视频播放器不动）。
- 致命 bug（穿地、卡死、出生点崩溃）。
- 严重性能问题（单人 30 FPS）。
这类反馈无条件修。这些 bug 会让玩家直接退出，不修就是放任世界滑出 Community Labs。
应修：体验摩擦
Section titled “应修：体验摩擦”- 出生点朝向、动线引导不清。
- 镜子默认开着、UI 文字看不清。
- 关键交互没反应。
这类反馈第二轮修。它们不会立刻让玩家退，但会让人不愿意再来第二次。
看情况：设计建议
Section titled “看情况：设计建议”- 「能不能加一个 XX 区」「为什么不能 YY」。
- 「希望你能换个 BGM」。
- 「我觉得这里应该是 ZZ 风格」。
这类反馈要回到自己的创作意图判断。没有义务接受。
判断方法：
建议跟世界的核心定位是否一致？├─ 一致 → 加进 backlog（待处理清单），下个版本考虑├─ 不一致但能挂在边角 → 看精力是否允许└─ 跟核心冲突 → 礼貌拒绝VRChat 上有个常见反模式：创作者根据热心玩家的建议不断添加新功能，世界从一个 Chill 小屋变成功能堆成的大杂烩，原本的常驻群体反而被赶走。这件事跟 Feature Creep（功能膨胀）在游戏开发里遇到的问题一样。
可拒绝：跟核心冲突
Section titled “可拒绝：跟核心冲突”- 「能不能让我管理整个世界」（要求高权限）。
- 「能不能屏蔽某某用户」（要求做世界级别黑名单）。
- 「这地方应该有 NSFW 区」（违反 VRChat TOS）。
- 「能不能让我永久占用某个房间」（要求私有化公共空间）。
这类直接说不。理由是「世界的定位决定的」「平台规则不允许」「跟其他玩家公平」。
第四节：版本更新不破坏玩家收藏
Section titled “第四节：版本更新不破坏玩家收藏”第 44 章讲过 World ID 一旦发出来不会变。同一个 World ID 上传新版本，玩家收藏不丢、World URL 不变、所有外部链接（推特、Discord 公告里贴的链接）都还有效。
这是 VRChat 设计上对创作者的友好：发版本不影响存量玩家。
VRChat 后台没有内置版本号系统。版本号是创作者自己写在 Description 里的：
v0.1 - 初版上线v0.2 - 修 Quest 端粉红材质 / 修出生点朝向v0.3 - 加一只猫更新版本时把 Description 末尾的版本号刷一下，玩家看到 Description 变了就知道动过。
更精细的做法：在世界里某个角落放一块「更新日志」板子，每次发版本的简要说明刻在上面。常驻群体进世界时会扫一眼，新玩家也能看出这世界还在维护。
大改另开一座新世界
Section titled “大改另开一座新世界”「大改」指的是：移除某个房间、改变核心玩法、删除常驻玩家熟悉的物件。
这一类改动让常驻群体失去信任：他们昨天还在的房间今天没了、之前能玩的玩法现在不能玩了。VRChat 创作者圈里多个反面案例都是这样：上线半年的世界突然大改，第二天 Discord 群里一半人不再来。
要做大改的话：
- 上线一个新世界。新 World ID，新场景。老世界继续保留。
- 在老世界里挂一个「新版本在这里」的传送门到新世界。
- 让玩家选择留在老版本还是去新版本。
这样常驻群体的收藏不丢、新版本可以跟老版本完全不同。VRChat 上一些长寿世界都是按这个思路：「v1 / v2 / v3 」是三个独立世界，互相之间用传送门连接。
紧急修 bug 的快速循环
Section titled “紧急修 bug 的快速循环”线上版本出了致命 bug（玩家穿地、Quest 完全打不开）的紧急修复流程：
- 在 Discord / Twitter 公告：「世界目前有 bug，正在修，预计 N 小时内更新」。让常驻群体知道你在处理。
- 在本地修。改完先
Build & Test验证。 - 切到正确平台
Build & Publish覆盖更新。 - 自己在 VRChat 客户端启一个新实例验证修好了。
- 再发一条公告：「已更新 v0.X，请退实例重进」。
VRChat 实例不会自动加载新版本。已经在世界里的玩家继续用老版本（包含 bug）直到他们退出实例。新进的实例才是新版本。这是为什么修完之后要让大家「退实例重进」。
第五节：VRChat 后台数据怎么读
Section titled “第五节：VRChat 后台数据怎么读”VRChat 网站（vrchat.com）登录之后，自己的世界页面上能看到一些基础数据。具体字段会随网站改版变化，常见的几项是：
- 总访问量 / Visits：从世界上线到现在的累积访客。
- 当前在线 / Active：此刻有多少实例在跑、加起来多少玩家。
- 收藏数 / Favorites：有多少人把这座世界加进收藏。
- 每日访问量曲线：按天统计的访客折线。
要看更细的数据（比如分平台访客、完整历史曲线、留存率、平均会话时长），VRChat 官方后台不一定直接给。社区第三方工具（vrcw.net、vrclist.com 等）从 VRChat 公开 API 抓出了不少补充数据，可以作为参考。
三个值得关注的数
Section titled “三个值得关注的数”第一个月里关注（下面的具体阈值是社区经验线，不是平台标准。VRChat 官方没给「合格世界」的硬指标）：
| 指标 | 看什么 |
|---|---|
| 留存率（粗算） | 总收藏数 / 总访问量。> 5% 算不错，> 10% 是好世界 |
| 平均会话时长 | 跟世界类型有关：Chill 通常 30+ 分钟，Game 15-30 分钟，Tool 10 分钟以下都正常。VRChat 后台不一定直接给会话时长，多数靠第三方站点或自己估 |
| 访客曲线 | 上线第一周一般是峰值，第二周回落到 30-50%，之后稳定。如果第二周回落到 10% 以下，说明吸引不住二次访问 |
如果第一个月数据明显低于预期，多数情况问题不在世界质量，在「让人发现」上：缩略图不够吸引、Description 写得不清、Tags 选错、没在合适的社群发公告。这些问题第 44 章都讲过，可以回去对一遍。
月活 50 跟月活 5000 不一定差 100 倍
Section titled “月活 50 跟月活 5000 不一定差 100 倍”VRChat 不是流量平台。一座世界月活 50 人和月活 5000 人，单看数字差 100 倍，但作为创作者的体验不一定差 100 倍。
50 人但都是常驻、互相熟悉、每周进来玩两次的世界，体验上跟 5000 人但人均停 3 分钟就走的世界完全两回事。
第六节：什么时候是「该停更」的合理节点
Section titled “第六节：什么时候是「该停更」的合理节点”不是所有世界都要永远维护。给一座世界设一个生命周期是合理的事。
三种自然停更场景
Section titled “三种自然停更场景”- 完成型世界：剧情类、谜题类、限时活动型世界。剧情走完了、活动结束了，停更是设计的一部分。
- 维护成本超过收益：世界本身仍然有人来，但每月维护几小时跟当前的访客量、社群价值不成比例了。可以转成「保持上线但不主动开发」状态。
- 创作者重心转移：创作者开始做下一座世界。前作维持上线、修偶发严重 bug，但不再主动加新功能。
健康的停更操作
Section titled “健康的停更操作”不是直接消失，是告知：
- 在 Discord / Twitter 公告：「这座世界从某月某日起进入维护模式，仍然能玩，但不再主动加新内容。如果有严重 bug 仍会修。」
- 在世界内某个角落（比如更新日志板上）写明「v1.0 - 最终版本」。
- 如果有继任作品，挂一个传送门到新世界。
「维护模式」是一种正式的状态，跟「弃坑」不一样。前者让常驻群体有心理准备、能继续来玩，后者让人觉得创作者跑路了，常驻群体也散掉。
反模式：拖着不更新但不公告
Section titled “反模式：拖着不更新但不公告”最差的状态是：世界明显有 bug，创作者半年没回 Discord，但世界仍然挂在 Public 上。常驻群体进来玩到 bug 没人修，慢慢散。
宁愿明确说「我现在不维护这个了」，也比无声拖着好。
第七节：怎么避免世界变成「废墟」
Section titled “第七节：怎么避免世界变成「废墟」”VRChat 上「废墟世界」是指：曾经有过几千上万访客、现在常驻 0、creator 也消失。这种世界在 Public 列表里仍然能搜到，但进去就是空房间。
变成废墟的世界通常踩了几个共同陷阱：
- 上线即终点。把上传当作目标，没规划维护。第一波热度过去之后世界就停滞了。
- 没搭反馈渠道。玩家有 bug 但没法报，只能默默退出。
- 被 Feature Creep 拖垮。每次更新加一堆新东西，老内容反而坏了，世界越改越乱，常驻群体被赶走。
- 跟创作者的真实热情脱节。一开始是热爱做的，慢慢变成「不得不维护」，然后一边焦虑一边拖延。
- 大改伤害收藏。一次改动让常驻群体失去熟悉感，集体迁移走。
避免这些的几条参考线：
- 上线前就规划维护节奏：每周看一次反馈、每月发一个小版本、每三个月评估一次是否继续。
- 接受「世界会衰退」是常态：不是每座世界都能成为长寿空间。让几座世界自然进入维护模式、专心做下一座，比硬撑着所有世界更健康。
- 保留对自己创作意图的诚实：当某座世界变成「应付」时，承认它，公告进入维护模式。拖着对常驻群体伤害更大。
- 把创作者关系跟世界关系分开：常驻群体认的是创作者，不只是某座世界。维持 Discord / Twitter 活跃，下一座世界出来时大家还会跟过来。
自己跟踪两件事
Section titled “自己跟踪两件事”世界上线之后做这两个简单的小练习：
- 每周固定时间扫一次反馈。比如每周日晚上花 30 分钟把 Discord 反馈、Twitter @、世界内反馈牌全扫一遍。把要修的写到一个 Notion / 笔记本里，按「必修 / 应修 / 看情况」分类。这是一个习惯，不是一次性任务。
- 每月做一次轻评估。打开 VRChat 网站看世界数据，记三个数：当月访客数、收藏数变化、常驻群体规模（自己的 Discord 活跃用户数）。不需要做漂亮报表，三个数字记到同一个文档里，几个月后能看出趋势。
这两个动作加起来每周不超过一小时，是维护一座世界长期所需的最小投入。
这一章的脑子里留下来的
Section titled “这一章的脑子里留下来的”世界上线之后头几个月的几条主路：
- 头一周会有反馈浪，主要是 Quest 兼容、出生点和动线、小 bug、性能、设计建议。
- 主动搭反馈渠道（Discord 起步），不搭的话玩家默认是「直接退出不告知」。
- 反馈分四档：技术 bug 必修、体验摩擦应修、设计建议看情况、跟核心冲突可拒绝。
- 不被 Feature Creep 拖垮：常驻群体的「能不能加 X」每个版本最多花 30% 精力。
- 同一个 World ID 上更新版本玩家收藏不丢；要做大改请另开新世界、用传送门连接。
- 紧急修 bug 后让玩家「退实例重进」才会加载新版本。
- VRChat 后台只给基础数据；关注留存率、会话时长、访客曲线，比单看月活有意义。
- 给世界设生命周期是合理的事；进入维护模式时公告，比无声拖着对常驻群体公平。
- 创作者关系跟世界关系分开：维持 Discord / Twitter 活跃，下座世界出来时社群会跟过来。
世界进入稳定期之后，下一个问题就出现了：「下一座世界做什么？」「书读完了我接下来去哪学？」最后一章答这个。