这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
6.2 循环时长与反馈密度
给核心循环装上时钟与密度：用配置把每一次可感知反馈数成一个事件，算出《合成小岛》每秒反馈次数，再用整数匹配函数把它映射到一条单峰心流曲线，并用 B 层基准做循环时长参数的敏感性分析，讲清为什么反馈不是越多越好、以及怎么判断当前落点偏冷还是偏热。
posts
文章归档
PlumePHP 全站文章的归档入口，按时间倒序汇总各专题的技术文章，并提供按主题浏览的专题分类入口。
6.1 主界面框架与信息层级
把 SLG 主界面写成一张有向图：节点是界面、边是一次跳转、层级决定信息深度。本节用脚本从主城做 BFS，算出每个功能的跳转深度、可达性与没有入口的孤儿界面，并给出主界面扇出与层级规范怎么定的可量化依据，附可跑脚本与 SVG 图。只谈信息架构，不谈视觉与美术。
6.1 一句话玩法与核心循环拆解
把「一句话玩法」拆成可判定的核心循环：用配置驱动《合成小岛》的动作 → 资源 → 反馈 → 再投入链条，再用 S 层脚本算出每个动作的时长与占整轮循环的比例，产出 CSV 与 SVG 时长条形图，并讲清占比读出来的三个设计结论与可检验自检表。
5.3 跨模块契约与接口约定
状态归属解决了「谁有权写」，这一节解决「一个模块怎么请求另一个模块去写」：用 TypeScript 接口把每个模块的写状态、读状态、命令与事件写死，再用 node --test 断言「同一份状态被两个模块写」「写了不属于自己的状态」一定被检出，让模块契约变成可执行的边界。
5.3 生命周期阶段与留存结构
把「玩家会留下来多久」从一句愿望变成一条可递推的留存曲线：用 D1 起点加早晚两段整数衰减参数，递推出《合成小岛》0–30 天留存，输出 D1 / D7 / D30 与逐日序列，产 JSON + CSV + SVG，并用 B 层做衰减参数的敏感性扫描与软告警。
5.2 数据流与状态归属
功能树钉死了「功能归谁」，这一节钉死「状态归谁」：每份状态有且只有一个写者，可被多个模块读。用《王朝纪元》9 份状态的归属表校验单写者、归属一致与引用有效，再用耦合度基准把「活动模块读了四个模块的状态」这类越界软告警出来，让模块边界真正稳固。
5.2 动机模型与付费意愿分层
把「谁愿意花钱」从一句运营直觉变成一条可仿真的意愿轴：按动机把《合成小岛》用户切成五层，每层给出整数付费率与整数 ARPPU，用同一份配置算出总体付费率、总体 ARPPU 与总体 ARPDAU，产 JSON + CSV + SVG，并显式暴露整数地板除的 1 分钱缺口。
5.1 小游戏用户画像与使用场景
把「谁在玩」从一句口号拆成一张可仿真的画像表：定义《合成小岛》五类示例画像（通勤碎片族 / 睡前放松族 / 排队等待族 / 亲子陪伴族 / 深度成就族），给出各自的占比、日打开次数、单次时长、D1 留存与人均日广告次数，再用千分比占比加权出一组总体指标，产出 JSON + CSV + SVG，全程整数地板除，不含浮点。
5.1 功能树与模块职责
把 SLG 的功能清单变成一棵可校验的树：模块是产品侧的职责单元，功能是玩家可感知的最小交付点。用《王朝纪元》8 模块 22 功能的配置，校验唯一归属、无悬空引用、无环、无孤儿与模块覆盖，把「模块职责」从口头分工变成每次改配置都会报警的有守卫的不变量。
4.3 耦合与解耦：什么时候不该拆
前置依赖只是耦合的一层：本节把系统之间「读写了谁的数据」写成非结构耦合边，用 S 层脚本合并结构边与数据、时序边，算出每个系统的扇入、扇出、耦合分与变更影响半径，再用 B 基准给出软告警，最后讨论解耦为什么不是越多越好、什么时候该留着耦合不拆。
4.3 平台能力矩阵与审核红线
包体和加载定完之后，最后一关是平台能力与审核。本节把账号、支付、广告、分享、云存档、录屏、排行榜这八项能力在六个平台上的支持情况写成一份可校验的矩阵，再用一段 S 层脚本断言设计案用到的能力在目标平台都可用，并校验每条审核红线都写下了可执行的缓解措施。
4.2 首包加载与冷启动约束
首包体积定下来之后，真正决定流失的是它要加载多久。本节用整数递推把体积折算成下载耗时，再叠一个随体积增长的冷启动初始化开销，套进一个带下限的线性进入率模型，产出三条带宽档位的曲线；B 层反过来算，给出目标进入率下各档位允许的首包上限与带宽敏感性告警。
4.2 解锁节奏与前置链
解锁节奏不是拍脑袋定天数：本节把每个系统的前置链与天数门槛写成一张门槛表，用 S 层脚本逐日推进，算出「第 N 天解锁第几个系统」的时间轴与累计曲线，再用 TypeScript 原型测试断言它与 Python 侧逐位一致，并解释为什么「前置满足」不等于「当天就能开」。
4.1 系统清单与依赖图
把《王朝纪元》的 18 个系统写成结构化 JSON 清单，用 S 层脚本对依赖图做四问校验：悬空依赖、环、孤儿、根可达。脚本一次跑清并产出拓扑序 CSV 与分层 SVG，再用一段故意造环的坏数据确认校验器真的会报错，为后续的解锁节奏与耦合判断立好可复用的底座。
4.1 主包与分包体积预算
包体上限是小游戏最硬的一条平台约束，也是立项阶段就必须定下的裁剪依据。本节先把主包、单分包、总包、分包数量四条限额写成一份可校验的配置表，再用一段 S 层脚本把资产清单折算成各包体积、逐条比对限额，并对超限的主包算出最小迁出集合，让分包方案由约束反推出来。
3.3 长线目标与追求感
把 SLG 的长线目标做成可校验的台阶刻度：给定每日发展度收入，算出《王朝纪元》8 级目标的达成日与相邻间隔，用「追求感带」判定每个台阶是太密还是太疏，并让 Python 与 TypeScript 两侧算出逐位一致的结果，把追求感从口头判断变成可回归的断言。
3.3 品类选择加权评分与敏感度分析
给 8 条商业特征维度配上可调权重，把 8 个品类算成加权总分并排名，再做单权重 ±20% 敏感度分析与排名稳定性基准，回答哪些品类的名次对权重最敏感、哪些结论可以放心采信，是本章核心一节，也是卷一里第一个把 S 层仿真与 B 层基准并排给出的地方。
3.2 日/周/赛季三级节奏
把 SLG 的节奏拆成日、周、赛季三层时钟：用 24 小时行为密度曲线与行为锚点算出峰均比 266%，用周权重找到峰值日，用赛季相位划开荒到结算共 70 天，并给一个 B 层基准把设计曲线与均匀基线对照，说明为什么日峰均比可以高、周峰均比却要克制。
3.2 品类的商业特征矩阵
给 8 个小游戏品类在开发成本、变现效率、留存天花板等 8 条商业特征维度上打分，做成一张 8×8 矩阵，并用 S 层脚本把矩阵算成可横向比较的分数：综合强度分与偏科极差，并指出均值能排序但不能替代决策，为下一节可调权重的加权评分与敏感度分析打底。
3.1 资源循环与行为闭环
把 SLG 的核心循环从「一张画着箭头的示意图」变成可判定的有向图：用配置驱动的《王朝纪元》行为闭环（7 节点 9 边），校验弱连通、强连通分量、最短回环与悬空汇点，并讲清为什么闭环的定量仿真要留到第 12 章再做，Python 与 TypeScript 两侧判定逐位一致。