山门声望系统 · 设计与落地稿 v1 IDLE WUXIA · SYSTEM DESIGN
山门声望系统
两进两出 · 门派名望决定山门规模
声望是山门的名望总量：人丁越旺、闯荡越远，名望越高。 名望到档位，才盖得起新的厢房和资源田 —— 它是所有建造上限的唯一那把尺子。
版本 v1 状态 待评审 声望 零存储 · 纯推导 厢房上限 3 → 15 资源田 每种 1 → 5
🔴 限制出口已改制（2026-10-10）：声望现在管「建筑等级上限」，不再管「建筑数量」
老大 2026-10-10：「限制机制变更：根据关卡进度，把原来的数量限制改成建筑的等级限制。」声望总分的推导一字未变（stagePrestige + 门派声望 + 总公式）； 变的是「限制」的出口：
- 新：
LEVEL_TIERS（5 档 → 建筑最高等级） —— 升级接口的唯一上限判据：
| 等级上限 | 所需总声望 | 大致进度 |
|---|---|---|
| 1 级（开局） | 0 | 青石村起步 |
| 2 级 | 260 | 黑风岭全通（= 旧档 3） |
| 3 级 | 980 | 碧云涧全通（= 旧档 6） |
| 4 级 | 2350 | 落星谷全通（= 旧档 9） |
| 5 级（满） | 4800 | 黄泉道全通 + 门派声望（= 旧档 12） |
- 旧：
TIERS（13 档 → 厢房 / 资源田数量上限） —— 数据保留、
Sign out限制作用：建造机制整体关闭（POST /api/buildings 返回 400）， rooms / fields 不再被任何服务端逻辑消费；快照字段照旧输出供前端展示。
- 「关卡进度仍是同一把尺子」：总声望 = 历练 + 门派，没有另造第二套进度度量。
- 已升到的等级不因声望下退被追缴 —— 与「已建建筑不追缴」同一条口径。
现行口径与建筑等级效果表见 建筑与等级。 本文 §3~§6 中一切「到档 → 能多盖 N 间 / N 块」的表述，请按上述新出口理解。
需求两进两出
1 声望从哪来（两进）
- Jianghu历练 —— 通关关卡累积，只增不减
- 门派人员 —— 当前门人的人数与等级之和
老大原话：「声望是要看我们的Jianghu历练进度，这是累积的；还有当前在门派里的门人数量和等级之和。」
2 声望花在哪（两出）
- 资源田 / 仓库 / 武器铺 / 厢房…… —— 提高该类建筑的等级上限：
声望越高、能升到的等级越高，产能 / 容量 / 门人名额跟着涨
声望不是消耗品：达到档位就永久解锁该档位的等级上限，花掉不会扣。
⚠️ 名额口径更新（2026-10-11）
- 门人名额 = 1（开局那间厢房）+ 厢房等级 × 5 —— 1 级 1 人、5 级 21 人
（每级 +5；此前为每级 +1）。
- 本文里"多盖一间 = 多一个名额"的旧口径作废：建造已退役，名额只随 厢房等级 涨。
公式与验收细节见《厢房系统设计》。
1 闯关 + 养人 历练进度累积 门人数量 / 等级提升
2 声望上涨 总声望 = 历练 + 门派 实时推导，不落盘
3 跨过档位 读档位表 得到两组上限
4 扩建山门 升资源田 → 资源涨 升厢房 → 名额涨
5 反哺 更多门人 → 门派声望再涨 兵力更强 → 闯更远的关
一声望的构成与公式
总声望 = 历练声望 + 门派声望
prestige = stagePrestige(stageIdx) + hallsPrestige(heroes)
两项都是当前状态的纯函数：不写档、不落账、不消耗。任何一次读接口现算就得到最新值 —— 与项目「产出纯函数推导」的铁律同一条口径。
1.1 历练声望：按区域递增
每关给的声望 = 10 + 5 × 区域序号（区域序号 0 起）。越往后的区域，每关更值钱 —— 让"推进度"始终有回报，而不是前期刷关收益最高。
| 序 | 区域 | 关卡数 | 每关声望 | 本区合计 | 累计 |
|---|---|---|---|---|---|
| 0 | 青石村 | 6 | 10 | 60 | 60 |
| 1 | 落霞镇 | 6 | 15 | 90 | 150 |
| 2 | 黑风岭 | 6 | 20 | 120 | 270 |
| 3 | 雁回关 | 6 | 25 | 150 | 420 |
| 4 | 苍梧山 | 6 | 30 | 180 | 600 |
| 5 | 碧云涧 | 6 | 35 | 210 | 810 |
| 6 | 赤沙泽 | 6 | 40 | 240 | 1050 |
| 7 | 铁佛寺 | 6 | 45 | 270 | 1320 |
| 8 | 落星谷 | 6 | 50 | 300 | 1620 |
| 9 | 孤云城 | 6 | 55 | 330 | 1950 |
| 10 | 玄冰崖 | 6 | 60 | 360 | 2310 |
| 11 | 黄泉道 | 5 | 65 | 325 | 2635 |
71 总关卡数（= TOTAL_STAGES）
2635 全通累积历练声望
65 最后一关单关声望
1.2 门派声望：人数 + 等级
公式：门派声望 = Σ [ 20 + 4 × (等级 − 1) ]，对每一位在场门人求和（含主角）。
拆开看更清楚：= 20 × 门人数 + 4 × Σ(等级 − 1)。
| 门派状态 | 人数 | Σ(等级−1) | 门派声望 | 说明 |
|---|---|---|---|---|
| 开局（只有主角） | 1 | 0 | 20 | 刚落地，名望只有 20 |
| 3 人 · 平均 5 级 | 3 | 12 | 108 | 青石村－黑风岭阶段 |
| 6 人 · 平均 12 级 | 6 | 66 | 384 | 地图过半 |
| 10 人 · 平均 30 级 | 10 | 290 | 1360 | 与历练声望同量级 |
| 15 人 · 平均 40 级 | 15 | 585 | 2640 | 满员，门派声望反超全通历练 |
⚠️ 门派声望是「当前值」，会掉
- 历练只增不减；门派声望随遣散门人而下降（等级不会降，但人会走）。
- 所以声望档位可能下退。处理策略见第五节 —— 已建的建筑一律不追缴。
二档位表：声望 → 建造上限
13 个档位（0..12）。一张表同时管厢房和资源田 —— 只有一把尺子，才不会出现"资质涨了但厢房没涨"这类两套账。
| 档 | 声望门槛 | 厢房上限 | 资源田（每种） | 田总数 | 首次可达时机 |
|---|---|---|---|---|---|
| 0 | 0 | 3 | 1 | 4 | 开局 |
| 1 | 50 | 4 | 2 | 8 | 青石村全通（历练 60） |
| 2 | 130 | 5 | 2 | 8 | 落霞镇全通（150） |
| 3 | 260 | 6 | 3 | 12 | 黑风岭全通（270） |
| 4 | 440 | 7 | 3 | 12 | 雁回关全通（420 + 门派） |
| 5 | 680 | 8 | 3 | 12 | 苍梧山全通（600 + 门派） |
| 6 | 980 | 9 | 4 | 16 | 碧云涧全通（810 + 门派） |
| 7 | 1350 | 10 | 4 | 16 | 赤沙泽全通（1050 + 门派） |
| 8 | 1800 | 11 | 4 | 16 | 铁佛寺全通（1320 + 门派） |
| 9 | 2350 | 12 | 5 | 20 | 落星谷全通（1620 + 门派） |
| 10 | 3000 | 13 | 5 | 20 | 孤云城全通（1950 + 门派） |
| 11 | 3800 | 14 | 5 | 20 | 玄冰崖全通（2310 + 门派） |
| 12 | 4800 | 15 | 5 | 20 | 黄泉道全通（2635 + 门派 2165） |
厢房上限（间） 声望 →
3 5 7 10 13 15
0 1000 2000 3000 4000 5000
0 260 980 1800 2350 3800 4800 历练全通 2635 → 12 间
末 3 间 靠门派声望
图 1 · 声望门槛 → 厢房上限（阶梯）。“历练全通 2635”只能推到 12 间，最后 3 间必须靠把门派养大。
为什么最后一档要"卡一下"
如果全通历练就能拿满 15 间，那门派声望这一项就形同虚设 —— 玩家跑完图就再也不需要招人了。把末档门槛放在 4800，等于说：「想住满 15 人？先证明门派真的起来了。」
反过来看也安全：15 人 · 平均 40 级就有 2640 门派声望，2635 + 2640 = 5275 > 4800，正常养人一定有富余。
三不倒退：与现有"3 + 区域数"对照
现在厢房上限是 3 + 已完成区域数（3 → 15）。改由声望驱动后，要看清一件事：只带主角一路推图，是追不上旧上限的；缺的那部分必须靠门派声望补。下表把"要补多少"算成精确数字。
| 已通区域 | 历练声望 | 旧上限 3 + 区域 | 裸主角（20） → 新上限 | 追平旧上限 还需门派声望 | 折算成门派规模 |
|---|---|---|---|---|---|
| 0 | 0 | 3 | 20 → 3 | 0 | 一致（开局） |
| 1 | 60 | 4 | 80 → 4 | 0 | 一致 |
| 2 | 150 | 5 | 170 → 5 | 0 | 一致 |
| 3 | 270 | 6 | 290 → 6 | 0 | 一致 |
| 4 | 420 | 7 | 440 → 7 | 0 | 一致 |
| 5 | 600 | 8 | 620 → 7 | 60 | 3 位 1 级门人 |
| 6 | 810 | 9 | 830 → 8 | 150 | 8 位 1 级门人 |
| 7 | 1050 | 10 | 1070 → 9 | 280 | 满员 10 位 · 平均 3 级 |
| 8 | 1320 | 11 | 1340 → 9 | 460 | 满员 11 位 · 平均 8 级 |
| 9 | 1620 | 12 | 1640 → 10 | 710 | 满员 12 位 · 平均 11 级 |
| 10 | 1950 | 13 | 1970 → 11 | 1030 | 满员 13 位 · 平均 16 级 |
| 11 | 2310 | 14 | 2330 → 11 | 1470 | 满员 14 位 · 平均 22 级 |
| 12 | 2635 | 15 | 2655 → 12 | 2145 | 满员 15 位 · 平均 32 级 |
这把表怎么读
前 4 行「需补 0」—— 开局到雁回关，只带主角也追得平旧上限，老玩家不会觉得被削。
第 5 行开始出现缺口，但缺口是用"多招人 / 多升级"就能补上的量：苍梧山时要补 60（3 个人就行），到黄泉道时要补 2145（满员 15 位、平均 32 级）。
注意"折算"列的门槛并不苛刻 —— 门人等级上限是 99，32 级在后期是很轻松的数字。
⚠️ 如果老大希望"任何进度下都不落后"
- 把第 5～7 档门槛各降 60 点即可：
680 → 620、980 → 900、1350 → 1290。改的是TIERS一张表，一行数值的事。
- 代价是：门派声望那一路的"存在感"会变弱（更容易只靠推图拿满），这正好是本系统想避免的。
厢房上限（间） 已通区域 →
369 1215
036 912
旧口径 = 3 + 区域数（到 15 封顶）
新口径（只带主角）
缺口 3 间 缺口靠门派声望补
图 4 · 蓝虚线 = 旧口径；红实线 = 新口径下的"裸主角"。两条线的缺口就是"门派声望要补的量"，从第 5 个区域开始出现。
四资源田：从 4 块到 20 块
现在铁/石/木/粮四种田每种只能建 1 块（共 4 块）。改由声望解锁后，每种最多 5 块（共 20 块）。
| 档 | 门槛 | 每种 | 总块数 | 单种产量 / 真实小时 | 四种合计 |
|---|---|---|---|---|---|
| 0 | 0 | 1 | 4 | 600 | 2400 |
| 1 | 50 | 2 | 8 | 1200 | 4800 |
| 3 | 260 | 3 | 12 | 1800 | 7200 |
| 6 | 980 | 4 | 16 | 2400 | 9600 |
| 9 | 2350 | 5 | 20 | 3000 | 12000 |
4.1 产出量级核算（防止数值崩掉）
现参数：CYCLE_SEC = 3600 作品秒 = 60 真实秒；每块每轮 10 个；仓容 100（满仓自动收集）。
- 单块田 = 600 个 / 真实小时
- 门人口粮 =
50 / 人 / 作品天，作品天 = 24 真实分钟 ⇒ 125 / 人 / 真实小时
| 阶段 | 粮食产出 | 门人消耗 | 盈余 |
|---|---|---|---|
| 开局 4 块田 · 3 人 | 600 | 375 | +225 |
| 8 块田 · 8 人 | 1200 | 1000 | +200 |
| 12 块田 · 12 人 | 1800 | 1500 | +300 |
| 20 块田 · 15 人（满） | 3000 | 1875 | +1125 |
结论：粮食线始终为正，且不会溢出
因为田的上限跟着厢房名额一起涨（都读同一张档位表），人越多田越多，口粮压力自然被吃掉。20 块田比 15 人需求高出 60% —— 留了余量给"多囤一点做装备材料"。
铁/石/木三种材料的需求量靠装备鉴定与加工消耗（IDENTIFY_MATS / REFINE_MATS），产量翻 5 倍后如果材料过剩，优先调加工消耗表而不是往回砍田的上限 —— 砍上限会同时砍掉"扩建"这个玩法动机。
五声望会掉：只拦新建，不追缴
规则一句话
上限只用于判断"能不能再建"，已经建好的建筑一律保留。
具体到三种情形：
| 情形 | 声望变化 | 上限变化 | 处理 |
|---|---|---|---|
| 遣散门人 | 门派声望下降 | 可能降档 | 已建厢房/田全部保留；只是暂时不能再建。空出的名额随厢房还在，可再招人 |
| 拆除厢房 | 门派声望下降（住的人少） | 可能降档 | 沿用现有 409 规则：住着人就拆不掉，先遣散 |
| 重新开始 | 归零（换世界） | 回到档 0 | 建筑一并清空，无冲突 |
⚠️ 必须挡住的死循环
- 不能让"声望掉档"回删建筑。否则玩家遣散一个门人 → 上限降 1 → 系统拆掉一间厢房 → 厢房里的门人被赶走 → 声望再降 → 再拆。这是死循环。
- 不能让上限为 0。档 0 保底 3 间厢房 + 每种 1 块田 —— 与现状完全一致，新号开局不会锁死。
- 前端要在遣散确认框里提前提示："遣散后门派声望 −X，将降为 N 档（厢房上限 N 间）"。
六界面
6.1 顶部资源条：加第 6 项
声望跟金币并列，放在资源条末尾。悬停展开明细 —— 让玩家知道这一项是怎么算出来的。
铁 1,240
石 860
木 2,010
粮 945
金 38,400
望 1,194 第 6 档 9 间 门派声望明细
Jianghu历练+810 门人 6 位+120 等级之和 66+264 合计 1,194 图 2 · 顶栏第 6 项 + 悬停明细浮层。数字由后端算好，前端只负责印。
6.2 建设面板：显示"当前 / 上限 / 下一档"
山门建设 声望 1,194 · 第 6 档
农田 占 1 格 · 每 60 秒产 10 粮 3 / 4 再建 1 块需第 9 档（+1,156）
铁矿 占 1 格 · 每 60 秒产 10 铁 3 / 4 再建 1 块需第 9 档（+1,156）
厢房 占 1 格 · 1 间 = 1 个门人名额 7 / 9 再建 1 间需第 7 档（+156）
图 3 · 每个建筑行右侧显示「已建 / 上限」；到顶时把下一档还差多少声望直接写出来，否则玩家不知道卡在哪。
6.3 键值口径
| 位置 | 显示 | 数据来源 |
|---|---|---|
| 顶栏第 6 项 | 1,194 总数 | GET /api/resources → prestige.total |
| 悬停浮层 | 历练 / 门人数 / 等级和 明细 | prestige.breakdown |
| 建设面板 | 3 / 4、7 / 9 | limitFor() 读后端的 fieldLimit / roomLimit |
| 到顶提示 | 再建 1 间需第 7 档（+156） | prestige.next / prestige.nextIn |
🔴 上限值一律由后端算，前端不许自己再算一遍
- 档位表只有一处定义（
server/prestige.mjs）。前端写死阈值 = 以后调数值时两边打架且静默。
- 前端只留一份带注释的兜底（后端没答话时按档 0 显示 3 / 1），与现有
FALLBACK_DEFS同一套做法。
七实现方案
7.1 新增 server/prestige.mjs（纯函数，无 Store、无存档）
声望零存储：不建 prestige.json，不加 world.prestige。理由 —— 它是 stageIdx + heroes 的纯推导，落盘只会制造"存档与推导值不一致"的风险。这也免掉"加 Store 必改两处"的成本。
| 导出 | 签名 | 作用 |
|---|---|---|
| STAGE_GAIN(k) | (区域序号) → number | 10 + 5k，每关声望 |
| stagePrestige(stageIdx) | (number) → number | 历练累积声望（复用 ranks.REGIONS 分区） |
| hallsPrestige(heroes) | (Hero[]) → {value, count, levelSum} | Σ[20 + 4×(lv−1)] |
| prestigeOf(stageIdx, heroes) | → 完整快照 | 含 breakdown / tier / roomLimit / fieldLimit / next |
| TIERS | 常量表 | 13 档 { at, rooms, fields } —— 唯一真源 |
7.2 改动清单
| 文件 | 改动 | 类型 |
|---|---|---|
| server/prestige.mjs | 新建：公式 + 档位表 + 快照 | 新增 |
| server/index.mjs | roomLimit(stageIdx) → roomLimit(prestige)；hallEconomy 加 prestige；GET /api/resources 加 prestige；POST /api/buildings 对资源田也传 opts.limit；新增 GET /api/prestige | 改动 |
| server/buildings.mjs | 导出 FIELD_DEFS（哪 4 个是资源田）；add() 逻辑不动（已支持 opts.limit） | 改动 |
| src/api.js | 加 prestige() | 新增 |
| src/resources.js | 顶栏追加第 6 项（非库存型，取 prestige.total）+ 悬停明细 | 改动 |
| src/buildings.js | limitFor() 支持 limitFrom:'fields'，读后端 fieldLimit；面板显示"下一档差多少" | 改动 |
| src/hall.js | 遣散确认框补一句"将降为 N 档" | 改动 |
| tools/verify_prestige.mjs | 验收脚本 | 新增 |
不新增 Store ⇒ 不碰 world.mjs / makeCtx()
项目铁律说"加后端 Store 两个必改点"。这次一个都不需要：prestige 是模块级纯函数，路由层直接 import 调用即可。
7.3 接口契约
| 接口 | 变化 |
|---|---|
| GET /api/prestige 新 | { ok:true, total:1194, stage:810, halls:384, breakdown:{ heroes:6, levelSum:66, perHero:20, perLevel:4 }, tier:{ index:6, at:980, rooms:9, fields:4 }, next:{ index:7, at:1350, need:156, rooms:10, fields:4 }, nextField:{ index:9, at:2350, need:1156, fields:5 }, nextRoom:{ index:7, at:1350, need:156, rooms:10 }, progress:0.578 } |
| GET /api/resources | 顶层加 prestige（同上结构）—— 顶栏跟资源同一拍刷新，不用多一个请求 |
| GET /api/hall | economy 加 prestige；maxRooms 来源由 3+区域数 换成声望档位 |
| POST /api/buildings | 资源田也走 opts.limit；超限 409 文案带"需第 N 档（还差 X 声望）" |
⚠️ POST /api/buildings 是 STARTER_GATED 成员
新建的写接口不需要额外登记（本方案没新增写接口）。但 roomLimit() 签名变了，两个调用点必须同步改（hallEconomy + POST /api/buildings），漏一个就会静默退回默认 3 间。
八验收与风险
8.1 tools/verify_prestige.mjs 检查项
| # | 断言 | 为什么 |
|---|---|---|
| 1 | 新号：total = 20、档 0、厢房上限 3、每种田 1 | 开局不锁死（保底三间/一块田） |
| 2 | 用 POST /api/time/advance…（不需要）改 stageIdx → 声望微增，且 ≠ 跳档 | 声呐与关卡同步，且门槛真的在拦 |
| 3 | 招一个人 → 声望 +20；遣散 → 声望 −20 | 门派声望双向可验证 |
| 4 | 遣散导致降档后，已建厢房数不变（不被回删） | 防"不追缴"规则被绕过 |
| 5 | 建资源田到上限 → 成功；再建一块 → 409，文案含"第 N 档" | 权威在后端，不靠前端禁用 |
| 6 | 后端算出的 roomLimit 与前端面板显示的 / N 相等 | 防前端自己算一套 |
| 7 | 4 种田分别建到 每种 5 块，全成功；总数 = 20 | 上限确实按"每种"而不是"总数" |
| 8 | 廂房建到 15 间全成功（声望推满时） | 满档可达 |
| 9 | 顶栏声望数字 = 接口 prestige.total | 打印≠断言，这里真断言 |
8.2 风险表
| 风险 | 等级 | 处置 |
|---|---|---|
| 老存档厢房数 > 新上限 | 中 | 不追缴，只拦新建；前端面板显示"已超上限（旧档遗留），不再可建" |
| roomLimit() 漏改调用点 → 静默退回 3 间 | 中 | 验收项 6 会抓到（面板数与后端不一致） |
| 另一条开发线同时在改 buildings.js / index.mjs | 中 | 逐块暂存（拆 hunk），不整文件 git add |
| 材料产量翻 5 倍后过剩 | 低 | 调加工消耗表，不动田上限 |
| 门槛数值需要复调 | 低 | TIERS 是单一常量表；验收脚本不写死阈值，从接口读 |
验收动作（老大确认后执行）
- 实现 §7 全部改动
- 跑
node tools/verify_prestige.mjs→ 全绿
- 跑无头截图：顶栏第 6 项 + 建设面板「3 / 4」+ 悬停明细 → 不看图不算完成
- 回归跑
verify_xuanfang.mjs/verify_recruit_cap.mjs（厢房上限口径变了，这两个必受影响）
山门声望系统 · 设计稿 v1.1 · idle-wuxia · 已实现并通过 133 条断言（39+37+57）
实现期修正：v1 的 progress 示例手误（0.463 → 0.578）；§3 对照表原用拍脑袋的"正常养人"值、逐行对不齐，v1.1 换成精确可算的「追平旧上限还需门派声望」。
待老大定夺（都不阻断上线）：1 末档门槛 4800 是否偏严（末 3 间必须靠门派）2 「裸主角跑图从第 5 区起落后 1~3 间」是否接受 3 资源田每种档位分布（1/2/3/4/5 落在档 0/1/3/6/9）4 降档后 已建数 > 上限 时，建筑行/409 文案还没提示"是旧档遗留"，要不要补
