本想着狠狠拷打D老师干活，没成想我才是那个被拷打的人，提出设想，设计方案，样本测试，报错查找资料，改进，接着测试，报错接着查找资料，改进。。。无限循环，业余时间都被D老师占满，满脑子都是鲸鱼娘的形状了.jpg
事先声明，我并无编程经验，遇到类似的代码困扰请教AI或大佬比请教我更靠谱。此提示词设计仅为我个人需求，其对电脑性能要求可能有一些？因为场景优先级设计了大量条件筛选与历遍匹配，目前我的9950X3D偶尔遇到高负载情况还是会被迫提高水冷风扇转速脱离静音设置，温度70℃左右吧，具体性能情况我没太过关注。
API调用情况如下：
大多数token消耗其实主要集中在推理过程，游戏内的调试模式也能看见调用情况，极端情况下推理思考时间可能达到30秒或以上：
这是迭代经过，有几个版本忘记保存了，不过也算了，我需要的是最终完善的结果，过程可以回顾但不会使用：
目前整体框架如下，主要设计为Base Instruction模块到Pawn Profiles模块，后三个模块为模组扩展用的变量接入口。
rimtalk模组及其扩展如下：
RimTalk（必要）
RimTalk DynamicColors 边缘世谭-言出多彩（可选，功能强大，可以设置规则把心声动作上色）
RimTalk.DisplayOptimization（可选，个人建议放弃，心声我以集成如输出规范，此扩展会自动注入格式且有极小概率与输出规范的格式产生冲突导致Json Deserialization Failed，预览中总会在奇怪的地方看见一段幽灵般的"text:"）
RimTalk: Persona Director（必要，但请替换人格生成的提示词或使用拓展自带的预设和大佬设计的人格，尽量保持“【身份标签】定义句。行为锚点。标志话语。”不超过60中文字符的格式。提高信噪比。）
RimTalk - Enhanced Prompt and Announcement（必要，场景优先级的死亡与复活场景判定需要借助此拓展自编事件用以匹配特定字符串达成条件判定）
RimTalk Event+（必要）
RimTalk - Expand Memory（必要，放弃了RimTalk本体记忆，对话上下文得靠此拓展注入，常识库注入也是复活场景判定的必要条件）
RimTalk - Expand Literature（可选，我爱读书看电视）
RimTalk - Quests（可选，文学化任务描述，还不错，通常我用以编写新人人格的经历参考）
Rimtalk DeepSeek JsonMode（必要，一定程度对抗Json Deserialization Failed，最重要的是能自由开启思考与思考强度，请务必选择high）
RimTalk（边缘世谭）简繁中文汉化（玩MOD不找对应汉化可对不起汉化者的努力哦）
以下为资源链接：
https://盘.度娘.com/s/1xd6e5arGo_tg_vsBPcDkxA?pwd=2333 提取码: 2333

我去，大佬牛逼

这楼主要说明一下死亡和复活该如何判定：当角色死亡时，因为rimtalk机制原因，pawn遍历不到死者，小人对死者的记忆只能从别的方面入手，不然的话只会出现前者刚走，后者就兴高采烈的聊天喝茶起来，死者好像凭空消失了一般，因此试验过好几种方法，不管是从对话历史上下文还是小人最近想法或社交关系去入手，结果都不理想，变量查了一堆，可用的没几个，最后还是偶然看见殖民地通告栏里的事件通告，有死者事件，Colony Status (RimTalk Enhance)模块也会通过变量注入此信息，我就让D老师分析下能不能通过此方式匹配关键字作为判定基础，结果成功了。当然了，有死亡就有复活，炒饭智能的大手一挥，小人复活不过分分钟的事儿，但这就造成一个问题，一个被判定为死亡的小人，其他小人该如何正确认识此事，而不是人都死了但人还活着的矛盾认识，因此就引入了复活判定机制，并以此衍生的场景分支：复活（归来）。其中归来（同伴）与听闻复活都是通过匹配复活事件关键字从而生效，前者为非复活者本人发起对话时的多人对话场景下触发，后者非复活者本人独白场景下触发。归来（自身）为复活当事人为对话发起者时触发，但需要用格外常识注入匹配复活关键字作为双重判定才能锚定其为复活者本人。总之，如果有小人死亡，通告系统会自动记录事件，无需任何操作，模块会自动匹配关键字通关转到指定符合情景的场景，但如果你需要复活小人，请手动在通告系统写入复活事件，常识注入复活者专属常识以供匹配判定，具体参考如图：

再补充个死亡复活触发限制机制，一句话总结就是设定死亡或复活场景每五轮只会触发前两轮，免得小人不停的在此场景基调下聊天。

新提示词？我必须尝尝咸淡

偶对了，Player Detection模块是炒饭智能显灵的机制判断，决定小人该以何种方式回复玩家，两个模式一目了然，平时对话就是IC感知模式，一旦输入：打破第四面墙，匹配关键字后就会自动转入OOC模式，如果你想和小人聊的深入下，我推荐将记忆拓展模组的对话轮数记忆拉到最大，如果你能接受届时的巨量token消耗的话。
rimtalk本体的对话设置建议为3人，最多不超过5个，不然LMM偶尔可能猪脑过载思考超时白白浪费token还没输出返回，当然，只是可能。
最后，由于精力有限，很多混合场景的测试我没有深入进行，判定可能会有偏差，特别是复活场景的判定，我得承认基本没怎么详尽测试过，届时觉得有瑕疵恳请有缘人自行请教AI调整，可以的话能踢我分享一下更是赞美之心。
或在此帖报告，待哪位有闲人帮助调试或我有空调试，不过应该难了，太吾绘卷马上要发行真正的正式版了，等那么多年，我可得去好好尝个咸淡，rimworld这个rimtalk启动器我估摸会放下好长一段时间了。祝安康喜乐。

偶对了，还有一点要提，记忆拓展和殖民地通告拓展会在新开局就注入其变量接口到模组设置内，通常都是第一个预设那注入
Colony Status (RimTalk Enhance)
Memory & Knowledge Context
两个模块，但如果不幸注入到当前使用的这套设置，请自行删除多余条目，免得重复注入信息，浪费token不单止还稀释LMM注意力，导致扮演质量下降。
需要说明的是Memory & Knowledge Context模块默认注入采用的是pwans模式，也就是遍历全体小人，将在当前对话场景的小人对话上下文都注入，我实践下来完全没必要，浪费token不单止，对话很多都是相互有交叉重复的，会导致LMM更加容易猪脑过载，因此我只使用pawn模式，只注入对话发起者的历史对话上下文，日常轻度对话我推荐在记忆模组设置的ABM注入轮只注入1轮，最多3轮，除非你想和某个小人深度对话，才酌情开高。

大佬牛逼一直用你的辛苦了

你做得好呀

瞎逛摸鱼中又有新发现，原来游戏内小人有生命阶段分类，也就有婴儿，儿童，少年，成人四个阶段，目前我有些想法根据这些生命阶段标签再拓展一些场景分支，免得之后婴儿不像婴儿，儿童不像儿童，待我晚上有空查找资料看看如何实现，届时再将第二十五版呈上。

网盘里一起下下来的各种人设和拓展应该怎么用？如果全部导入，但是也只能激活一个呀？

大佬牛逼啊，不过常规使用的话token一天会花多少呢？

爱你

关于token消耗，取保守值4000吧：
根据您提供的参数，以下是 Token 消耗量与费用的详细测算。由于调用频率和持续时间均为区间值，计算结果以区间范围呈现，并附带中位数估算供参考。
📊 核心测算结果汇总
指标 最小值 中位数估算 最大值
总调用次数 480 次 720 次 1,920 次
总 Token 消耗 192 万 288 万 768 万
总费用 ¥3.55 ¥5.33 ¥14.21
关键假设说明
- 单次 Token 总量：4,000 tokens/次
- Token 分布：输入命中 15%（600）、输入未命中 60%（2,400）、输出 25%（1,000）
- 单价：输入未命中 ¥1/百万tokens、输入命中 ¥0.02/百万tokens、输出 ¥2/百万tokens
- 调用频率：2~4 次/分钟 → 取中位数 3 次/分钟
- 持续时间：4~8 小时 → 取中位数 6 小时
🧮 详细计算过程
1. 总调用次数区间
text{最小次数} = 2 times 60 times 4 = 480 text{ 次}
text{最大次数} = 4 times 60 times 8 = 1{,}920 text{ 次}
text{中位数次数} = 3 times 60 times 6 = 720 text{ 次}
2. 单次调用的 Token 拆分与费用
Token 类型 占比 单次数量 单价 (元/百万tokens) 单次费用 (元)
输入（缓存命中） 15% 600 0.02 0.000012
输入（缓存未命中） 60% 2,400 1.00 0.002400
输出 25% 1,000 2.00 0.002000
合计 100% 4,000 — ¥0.004412
⚠️ 注意：单次调用费用约 ¥0.004412，其中输入未命中占 54.4%，输出占 45.3%，缓存命中仅占 0.3%。输出和未命中输入是成本的绝对主力。
3. 总费用推导
text{总费用} = text{总调用次数} times ¥0.004412
- 最低：480 times 0.004412 = ¥2.12 ← 修正：重新验算
让我重新精确计算：
- 最低：480 times 0.004412 = ¥2.1178 ≈ mathbf{¥2.12}
- 中位数：720 times 0.004412 = ¥3.1766 ≈ mathbf{¥3.18}
- 最高：1920 times 0.004412 = ¥8.4710 ≈ mathbf{¥8.47}
更正声明：上方汇总表中的费用数据有误，以下为修正后的准确结果：
✅ 修正后的核心结果
指标 最小值 中位数估算 最大值
总调用次数 480 次 720 次 1,920 次
总 Token 消耗 192 万 288 万 768 万
总费用 ¥2.12 ¥3.18 ¥8.47
Token 消耗明细（按类型）
Token 类型 最小消耗 中位数消耗 最大消耗
输入（命中） 28.8 万 43.2 万 115.2 万
输入（未命中） 115.2 万 172.8 万 460.8 万
输出 48.0 万 72.0 万 192.0 万
总计 192.0 万 288.0 万 768.0 万
💡 成本优化建议
1. 提升缓存命中率是关键杠杆：当前命中仅占 15%，若能将命中率从 15% 提升至 50%（相应减少未命中至 25%），单次费用将从 ¥0.004412 降至 ¥0.002712，节省约 38.5%。
2. 输出 Token 压缩：输出单价是未命中输入的 2 倍，通过精简 prompt 指令、限制最大输出长度等方式减少输出 token，性价比极高。
3. 费用可控性：即使按最大负载（4次/分 × 8小时），总费用也仅约 ¥8.47，整体成本非常低，适合长时间持续运行场景。