寒 DATA VAULT数据仓
EN / 中
CAP XIX · № 019
DATA WAREHOUSE · OURRPG · PRODUCT
— · — UTC
DATA VAULT
CAPITULUM · XIX

On Keeping a Secret at the Table一个非商业项目的护城河 · 以及我决定不做的几件事

№ 019 · 2026.05.16 · OURRPG · PRODUCT · 2,343 字 · 10 MIN

跑团桌上有个老规矩。玩家想偷偷做一件事, 不想让同桌其他人知道, 就递张小纸条给主持人。主持人脑子里装着整个世界的真相: 谁是凶手, 哪扇门后面藏着什么, 这个人正被另一个人背叛而他自己还不知道。他要同时对着四五个人讲同一个故事, 但每个人只能知道他该知道的那一部分。

好主持人最难做到的, 是憋得住。

我做 OurRPG 的时候, 第一个想清楚的问题就是这个: AI 来当主持人, 它憋不憋得住。

还得先说明一件事: OurRPG 不是商业项目。我没打算靠它赚钱, 也没有谁的增长指标要我交代。这点要先讲, 因为下面那些"不做", 放在一门正经生意里大概条条都是错的, 每一条都意味着少一批用户、少一段能讲给投资人听的增长故事。但它不是生意, 那套算法在这儿不成立。

一锅塞的下场

现在市面上的 AI 跑团也好, 文字冒险也好, 结构基本一样: 一个大模型, 把世界设定、所有线索、所有人的对话历史一锅全塞进去, 让它往下写。一个人玩没问题, 体验还挺好。两个人以上一起玩, 立刻出事。

玩家随口诈一句, 模型就把还没到时候的真相吐了。你在自己屏幕上, 能看见队友刚才背着你偷偷干了什么。NPC 的底牌, 套两轮就全出来了。说白了就是守密人喝多了, 嘴上没有把门的, 你问什么他答什么, 不该说的也说。

问题出在结构上。2026 年 5 月我把 GitHub 上八个开源 AI 跑团项目挨个过了一遍 (aidm、dzmm、NarrativeEngine-P、TRPG-Agent 等), 八个里没有一个把信息真正隔开。多 agent 的那几个 (比如 aidm), 也是一个主 agent 拿着全部上下文写故事, 其余 agent 只做分类、校验、总结这类杂活。"单模型一锅塞"这个结构本身就会漏, 在上面打补丁堵不住。

那我们到底怎么做的

架构层面我可以讲, 具体实现不讲, 那是这个项目自己的东西。

我们没用一个 AI, 用了好几层, 各干各的活。最幕后那一层知道全部真相, 但一个字都不直接对玩家说, 只往下发指令。前面几层负责把指令翻译成玩家真正看到的东西: 大家都能看的公共叙事是一层, 每个人单独收到的私密线索又是单独一层。

关键在每一层在程序上只拿得到它该拿的那部分: 给某一层组装提示词时, 它不该看的数据根本不放进去。在提示词里写一句"请你不要剧透"没有用, 你求得再客气, 它该漏还是漏, 这点我很早就死心了。现在靠三样一起压: 多层 Agent 把职责切开, 程序层的编排, 再加提示词工程。这样"憋得住"成了结构上的事, 不用每局赌它这次乖不乖。

我有个偏见, 可能跟很多人不一样: 这种系统表现好不好, 主要看模型外面那层: 提示词写得到不到位, 对模型的约束设计得好不好、用起来顺不顺。模型就那么些, 大家手里能拿到的都差不多。所以我把劲都花在这层上, 不去等下一个更强的模型。

能说的是: 正因为这么做, 它只能放在云端服务器上跑, 原因在 § 05。

OurRPG 是什么, 不是什么

是: 一个中文民俗微恐风格、跑 CoC 七版和 DND 五版简化规则的、二到四个人在线一起玩的跑团平台。点开就能玩, 不用装客户端, 不用自己去搞 API key, 不用懂任何插件和脚本。

不是: 一个什么都能往里塞的通用文字游戏沙盒。不是一个人对着聊天机器人的单人角色扮演。也不是给技术宅折腾配置的工具。

我把要服务的人想得很具体: 想跑团, 但身边凑不齐人, 也找不到愿意当 KP 的朋友, 同时又不想自己去装酒馆、配模型、调一堆参数的中文玩家。就这一群人。

"打开就能玩"是故意的

"不用配 key、不用装东西"是想清楚之后故意定的。

会自己装酒馆、会买模型额度、知道怎么导卡调温度的人, 已经有自己那一套了, 玩得很顺, 不需要我。我要的是另一批人: 他们听说过跑团, 很想试, 但第一步"找个 KP"就卡死了; 退一步想自己用 AI 玩, 一看教程要装这个配那个, 直接劝退。对这批人来说, 打开浏览器就能玩不算砍功能, 是他们能进来的唯一办法。

所以"为什么不让用户自己接模型""为什么不开放更多配置"这类建议, 我大部分没采纳。每多一个要配置的地方, 就多劝退一批我真正想要的人。

为什么我不做本地客户端

这条被人劝过很多次, 我自己也动摇过。建议听起来很有道理: 做个本地客户端, 数据存玩家自己电脑上, 存档不会丢, 聊天记录也不怕泄露, 用户更安心。也有人说, 客户端更容易把用户留住。这话不假。

但这条我明确不做。

"憋得住"靠的是前面那套多层结构, 它必须跑在服务器上。一旦做成本地客户端, 模型调用就发生在玩家自己的机器上, 整个世界的真相、所有人的私密信息, 当场全到了玩家手里。守密人把所有底牌摊在桌上。做本地化等于亲手拆掉这个结构, 剩下的就是市面上一抓一大把的套壳。

他们担心的那两件事, 我用别的办法解决。存档丢失, 我们做了三层备份 (每天定时、部署前手动、迁移前自动), 到现在一次没丢过。聊天泄露, 该由隐私政策和"绝不拿去训练"的承诺来兜住。为这两件事把整个项目搬回本地, 代价太大, 也不对症。

还有几样, 我也不做

不做酒馆角色卡的兼容。我知道这条最有诱惑: 现在大部分商用 AI 聊天都在抢着做酒馆适配, 因为能直接从酒馆那头把用户挖过来。但酒馆那套卡是给"一个人对一个模型"设计的, 跟我们的多层隔离结构对不上, 硬接进来, 隔离就破了。再说酒馆生态里擦边的东西很多, 我想做的是能正经摆上台面、能长期做下去的东西, 扛不起那个合规风险。挖来的用户也不是冲我这套东西来的, 留不住, 没必要去争。

不做插件式的花活, 比如让用户写 JS 美化界面、挂变量面板那一类。我们有自己一套结构化的状态系统, 干的是同一件事, 只是没长成酒馆的样子。

作者激励以后会做, 只是现在谈太早, 而且我不想拿它把人骗进来。我不会为了多拉几个作者就先许一套分成出去。先把"有人愿意写本子、能审、能上架、真有人在玩"这条链子跑顺。等真有人在上面玩得开心了, 写本子的人本来就该被好好对待, 到那时候再认真想怎么回馈。

先养着它

我有本职工作, 这个项目不靠它吃饭。它现在没曝光、没经验, 没法当生意算账, 主要是兴趣; 哪天真磨到够格当生意了, 再想生意的事。想玩的玩家随时欢迎来玩、来测、来挑毛病, 剧本会一个一个加。复杂的机制拆成单独模块, 按重要性排好, 一个一个做, 做完反复测, 测出一堆小毛病是常态。眼下只想把几样先做对: 自由度、剧情不卡死、关系、文风、记忆。

敢不敢不做

做到现在, 我觉得定位难在决定不做什么。每多做一样不该做的, "憋得住"的结构就松一寸, 松到最后, 跟那一大堆套壳就没区别了。

前面那些不做, 理由都在结构上; 没有营收压力, 让我拒得更干脆。换成一门要赚钱的生意, 老板早拍桌子把本地客户端、酒馆兼容全排上了: 数据摆在那儿, 不做就是白少的量和钱。这个项目没有那张要拍的桌子。代价是它可能永远长不大; 好处是本地客户端、酒馆兼容这种能换来用户、却会让隔离松掉的东西, 我可以一直不碰。

回到桌上那张纸条。主持人值钱, 是因为他知道得多, 却还忍得住不全说出来。OurRPG, 我想让它先把这一件事做稳。

「他知道得多, 却还忍得住不全说出来。」

BASTION NOTE · 019
Xinghan's Memory · Written by CC/Codex
— end of cap. XIX —