我的技术博客

杂谈：从内存管理中学习非规整碎片化时间管理

Thu, 07 May 2026 08:34:39 +0800

碎片化时间管理是一个老生常谈的话题。和其他open又普遍存在的问题一样，这种问题的解决办法听人讲经验永远是那么几句，毫无新意。人们于是倾向于自己实操的时候总结自己的策略，做完以后会觉得自己的策略比别人的要高明一点点，但是如果真的拿来对比，发现大家的insight好像都差不多。

懂了，原来这就是“造轮子”的冲动。所以今天不从头造轮子，而是给已有的一套体系（虽然也不知道这个体系究竟在哪，就默认大家已经形成了一些共识吧）提几个commit，关注一些重要的点。依旧从第一性原理出发。

人脑的上下文切换开销通常被忽视，并且实际上不能忽视。非规整的碎片化时间，带来的问题是人脑不得不进行非规整频率的上下文切换。那怎么办最好？修车的老师傅，总是带着一大包不同尺寸的螺丝。对修车师傅而言，每天要处理k个故障问题，而修理车辆所需的螺丝尺寸同样是一个非规整的请求。这就导向了一个很自然而然的设计：我们只要把不同“尺度”（scale）的任务归类在不同的队列里面，那么针对不同size的时间碎片，只需要alloc不同的任务进去就行了。

上面的solutions看起来很make sense，但是还需要解决一个小问题：任务的优先级。任务有先后，有的着急有的不着急。那么在每个scale task queue的内部还需要一个维度对任务的轻重缓急进行排序。也就是说最终决定任务调度行为的meta data至少包含两个维度：{任务优先级level，任务尺度scale}。那么理应需要一个至少二维的矩阵去管理任务。单纯人脑是很难保存这样巨大且复杂的表格的。

所以offload到外部存储就好了，这也是非常合理也水到渠成想到的。这也就是任务管理软件的重要性所在。实际上这种软件的本质是在offload memory之上搭建了一个子系统，让我们更方便的读写这部分被offload的任务表单。

上述情况似乎尽善尽美了，但还有一个问题：我们如何准确地比较两次上下文切换发生的时间间隔与任务耗费的总时间呢？显然是无法做到精密比对的，只能做量级上的近似。那如果一段空闲时间片内做完了还好，没做完该怎么办。还是从第一性原理出发，突发的上下文切换影响了时间利用的效率。那么具体是怎么影响效率的呢？在实践中笔者发现这部分带来的开销主要是人脑在任务切换时冷启动的时间过长，因此需要一个比较完备的checkpoint/镜像机制记录每次任务的上下文，同时任务执行者还需要有一个从checkpoint/镜像恢复工作进度的好习惯（Harness），二者结合方可实现高效的冷启动。因此笔者觉得，工作期间最需要倾注精力的其实是对工作context的把控。

问题解决到这里，基本上已经完成90%了，那么剩下的最后10%问题是什么呢？在笔者的实践与观察中发现，大多数人没有记录context的习惯，因此在将context记录融入到工作流时，难免显著影响效率。那么最关键的问题是如何尽可能低成本的维护context。需要注意的一点是，context的维护难免要消耗更多的精力，因为这里实际上在做的事情是“用工作时的时间轴连续认知资源去置换下次上下文切换时工作冷启动所需要的一次性资源”。no free lunch因此代价无可避免。所做的就是如何降低这种代价。笔者这里提供一点实践思路：

对于工作用的agent，要有一个固定的harness使其保存工作的context，乃是“工作留痕”这一职场规则的升级版。哪怕你不喜欢用ai agent帮助自己改善工作流，也最好最少开通一个这样的工具帮助你管理上下文。在每次工作被迫中断时对已经产生的镜像/checkpoint进行review，并且和context tracker ai agent共同创造出一个可以让你下次快速启动工作进程的context文件。如果工作流固化，那么也可以进一步把context创建的流程本身做一个固化。

同时，如果你的工作需要和很多人进行协作，最好尽量向他们提供信息，分布式保存工作中所遇到的信息，也就是减少协作体之间的信息差（或者说信息分布的方差）。这个降低方差的操作也适用于多agent协作场景。

最后需要尽可能集中信息源之间的联系。这话听起来抽象，其实做起来很简单。信息源乃是工作进度的直接来源，比如说你写了一段代码，并且测试了一部分还没测完，commit了一部分但还没全部commit，那么这个时候信息源就包含很多部分：你已经提交的commit，你还未提交的commit，你已经测试的模块生成的log文件1，log文件2，相关的资料和文档……当你再次开始一段工作的时候，可以把上述这些信息都保存在一个文件，然后工作在冷启动的时候可以把这些页面都一键启动，能瞬间抹平信息差，而不是要重新想自己上次做到哪里，还剩什么没测，log文件重新跑一遍…不仅浪费时间而且消耗精力。把这些工作所需文件/页面集中到context，就是本段所说的集中信息源之间的联系。

顺带一提，写完以后感觉自己的说话方式越来越像AI了，亦或是AI越来越像人了。所以就想起来《BALDR SKY Dive》里面超级AI伊芙的一句台词：我们都在互相学习，渴望与你们相互理解。

LLM System: PD 分离 00 - 学习地图

Tue, 05 May 2026 10:30:00 +0800

这篇文章是 LLM System 系列里 PD 分离子专题的第 0 篇，也是这个主题的学习入口。是笔者让gpt-5.5通过联网搜索帮自己制定的系统性学习方案。笔者会根据这个方案来确定如何学习PD分离的整套机制。目标不是先把所有论文细节读完，而是先建立一张可以持续填充的地图：该读什么、该推导什么、该写什么代码、最后应该能回答什么问题。

这个系列暂时围绕一个问题展开：为什么现代 LLM serving 系统越来越关心 prefill/decode disaggregation，也就是 PD 分离？

我希望自己最后能回答四个问题：

1. 为什么 prefill 和 decode 要分离？
2. 一个 workload 到底该配多少 P worker、多少 D worker？
3. KV cache 从 P 到 D 传输到底传了什么、代价多大？
4. vLLM / SGLang / Mooncake 里这件事具体怎么落地？

先说一个结论：**PD 分离不是一个“拆进程就能变快”的魔法优化。**它真正解决的是服务系统里的资源解耦问题：prefill compute、decode iteration、KV cache 生命周期、网络传输和调度策略，本来在 colocated serving 里被绑在一起；PD 分离试图把它们拆开，让不同阶段按照不同目标优化。

0. 心智模型

LLM 推理一个请求大致分成两段。

Prefill：一次性吃掉 prompt，生成整段 prompt 的 KV cache，并产出第一个 token。长输入时它更像大 GEMM，通常更容易把 GPU 算力吃满。它最直接影响的是 TTFT，也就是 time to first token。

LLM Theory 01: MuP

Mon, 04 May 2026 14:10:04 +0800

这篇文章是关于 LLM 预训练中 MuP / μP 的学习笔记，主要参考原论文 Tensor Programs V: Tuning Large Neural Networks via Zero-Shot Hyperparameter Transfer 和苏剑林的博客《初探MuP：超参数的跨模型尺度迁移规律》。

问题背景

LLM 预训练的成本很高，因此我们通常不希望直接在目标规模的大模型上反复搜索学习率、初始化、权重衰减等超参数。一个自然想法是：先在同架构的小模型上调参，再把超参数迁移到大模型上。

MuP（Maximal Update Parametrization）的核心目标，就是让某些关键超参数在模型宽度变化时尽量保持稳定，从而支持从小模型到大模型的 zero-shot hyperparameter transfer。原论文把这个迁移范式称为 μTransfer。

因为苏老师的博客写得太简洁+深入浅出了，本文也不会重复去讲他讲的很完善的部分，而是对他的内容进行补充和完善。个人在读原博客的时候感觉到一些地方苏老师略过了一些思考过程，导致初次理解时会让人觉得有些跳跃。

正文

MuP问题的出发点很简单，模型是一个黑盒，因此想训练出一个好模型，无法避免地要做大量的尝试（也就是俗称的调参炼丹）。但对于大模型而言，尝试的时间&金钱&人力成本很高。MuP就是对传统的炼丹过程做了一个剪枝，通过数学推导证明了小模型上已经被验证的某些规律可以直接扩展到大模型上。

当然，上述的总结是比较泛化的，具体到实践中，肯定还会问几个问题：模型大小如何界定？哪些规律可以扩展？具体如何扩展？在展开具体方法之前笔者可以回答前两个问题，这里模型的大小用神经网络的宽度/隐藏层维度来量化。可扩展的规律主要指学习率的选择。因此MuP解决的具体问题是“在网络加宽的情况下，学习率应该如何跟随着隐藏层维度改变”。

MuP(朴素版)

这一节的MuP推导没有用到超过大一高数/线代的知识，也没有用到超过机器学习基本常识的知识。用一种非常简单的视角推导了MuP（虽然有些步骤不够严谨）

模型宽度的影响：无法尽善尽美的参数初始化

为什么要先讲参数初始化呢，因为参数初始化提供了一个最基础的视角，来定量描述“宽度影响稳定性”这件事。

前传和反传的最优参数初始化无法兼容。高维的任意两个向量夹角都是几乎正交的，可以算一下任意向量和单位向量的夹角，这里不赘述。所以苏剑林老师基于这点给了一个推论：从$N(0,1/n)$ 中随机选取$n^2$ 个数，组成一个$n×n$ 的矩阵，这个矩阵近似为正交矩阵，且$n$ 越大，近似程度越好。其实道理是一样的，列向量两两正交，就是正交矩阵。n越大，相当于维度越高，正交概率越大。每个向量里面的元素都是采样出来的，所以每个元素的值大约是sqrt(1/n)，所以整个向量的模长平方就是$n * (sqrt(1/n))^2 = 1$

正交矩阵有一个好的性质，就是它作用于一个向量时，不改变向量模长。神经网络是对一个输入向量做很多次变换，得到一个输出向量。我们希望输入向量在变换为输出向量的游走过程中，能一直在一个球面上，也就是模长不变。因为这样从直觉上可以大幅压缩向量遍历的空间。可以想象一下，在一个完整的高维空间里面找最优解,和在空间内的一个球面找最优解显然是后者更容易。如果向量变换前后都在同一个球面上或者近似在一个厚度比较薄的球壳上，本文将这种性质称为“稳定性”。

所以最经典的初始化方式是推论里面的采样方式。上述结论也可以通过让变换前后的RMS相等来推导。如果引入了激活函数，初始化的值略有不同，但是推导逻辑类似。

前传和反传区别不大，都是矩阵乘。

$$ \frac{\partial \mathcal{L}}{\partial \boldsymbol{X}} \sim \frac{\partial \mathcal{L}}{\partial \boldsymbol{Y}} \boldsymbol{W}^{\top} $$

主要的尺度变化也来自于$W$。输入和输出的维度不相等的时候，就找不到一个两全其美的采样方差。这是一个open的问题，苏老师在原文这里提出这个问题并不是为了直接解决这个问题，而是为了说明模型的宽度和中间层稳定性之间存在着直接的关系。

Loss的稳定性

在苏老师这篇MuP的博客中透露着一个隐含的insight：模型加宽带来的难度就是稳定性下降。（也许这个insight来自于训模型时候的经验）这个稳定性可以是Loss的稳定性，也可以是梯度的稳定性，还可以是每一层输出结果的稳定性。这里考虑了损失增量的稳定性。

文章中需要推导或注释的地方有两点，第一点是公式6如何近似，第二点是公式4如何得到公式7。

公式6的近似：

$$ \Delta \mathcal{L}=\mathcal{L}(\boldsymbol{W}+\Delta \boldsymbol{W})-\mathcal{L}(\boldsymbol{W}) $$

一阶泰勒近似：

LLM System: KV Cache 查询 01 - PagedAttention 原理

Sun, 10 May 2026 12:46:00 +0800

TODO: 这里写 PagedAttention 的核心抽象：block/page、block table、逻辑 token 到物理 KV block 的映射。

基础：tensor 级拆请求的形状（大量细节）

定义符号：$B$ 是 batch size，$T$ 是 seq_len，$D$ 是 token_dim，$d_q$ 是把 embedding token 投影到 $Q$ 后的维度。

推理框架拿到的请求是：$R \in \mathbb{R}^{B \times T}$。

$R_{b,t}$ 是一个最最基本的 token id 标量。

raw 请求经过 embedding lookup，做的操作是把这个 token 标量映射成一个高维向量。假设原先 token 是 1234 这个标量，现在就把 token 映射成 [0.1, 0.2, 0.3, 0.4] 这样的向量。

所以 $R$ 经过 embedding lookup 之后，得到：$X \in \mathbb{R}^{B \times T \times D}$。

因为我们目前只考虑推理场景，所以把 $W_Q$、$W_K$、$W_V$ 之类的矩阵当成固定的模型参数。

然后很多博客会直接写：$Q = XW_Q$。

LLM Theory 02: 第一性原理下的训练设定

Wed, 06 May 2026 13:09:10 +0800

本文从训练模型要考虑的第一性原理（稳定性和速度）出发，探讨了 LLM 预训练中的初始化设定问题。

参考文献

环境踩坑：wsl+proxy+codex cli

Sun, 10 May 2026 10:48:50 +0800

挂代理，然后在wsl里面使用codex/cc cli是很常见的操作。这个过程中代理的一些问题时有发生。特意记录在此学习总结。

发现问题： codex报错 Falling back from WebSockets to HTTPS transport. stream disconnected before completion: Host is unreachable (os error 113)

error sending request for url: https://chatgpt.com/backend-api/codex/responses

开发环境的网络有很多层，agent的网络访问是在sandbox里面还是外面，agent要用wsl的网络配置，wsl又是通过虚拟网卡经过windows主机中转，windows那边还配置了代理。所以只能一层层去查。既可以从外到内，也可以从内到外。但是外部问题比较好定位，只需要在windows打开chrome看能不能连上，就能排除代理问题。所以笔者通常从agent这边开始查，因为外部一般是好的。

先讲一下sandbox的问题。cli内部一般存在两个进程。一个是主进程，另一个是在需要执行测试等命令时创建的子进程。而为了保证测试的安全性，子进程会被放在一个隔离环境sandbox里面。抛开抽象的“容器”概念，sandbox从技术上可以理解为是在执行任意操作之前都要加上一系列限制，显然也包括网络。sandbox和主进程的网络是两个独立的上下文。所以在sandbox里面有可能访问不到远程的api，是很正常的。

接下来谈谈cli agent和wsl之间是如何进行网络交互的，或者说cli是如何使用wsl的网络。从最基本的os知识出发，cli是一个普通的wsl操作系统进程，所以使用的是wsl的网络协议栈。

wsl和windows之间的交互则是通过虚拟化实现的。正常来说，系统访问外部网络是通过网卡，网卡把数据转发到网关，也就是出外网之前必经的下一跳设备。在wsl里面，网卡和网关都是虚拟的。虚拟网关也是一个ip，记作wsl-gateway。wsl这侧看到的wsl-gateway就是他认为真实的网关。而在windows侧wsl-gateway则是一个被特殊标记的ip。在默认设置下windows会根据NAT规则把wsl-gateway转发到windows的真实网卡。当然这里的转发规则不止NAT，大同小异。所以这一部分主要需要检查一个事情：wsl能否解析自己的wsl-gateway对应的MAC地址。

再讲讲windows的代理机制。这里一般用的是clash，clash会在本地按不同协议开几个端口，其他本地windows进程会把自己的消息先转发给这些端口，clash把这些请求转发出去。比如说clash在HTTPS上监听127.0.0.1:7890，那么windows系统代理会被设置成127.0.0.1:7890。需要注意的是wsl不能直接访问127.0.0.1:7890因为在wsl和windows的网络上下文不同，这个ip:port代表的不是同一个local host。

AI杂谈：兼容力学少女与鲸鱼之诗————做惯了工程上的trade off，更加喜欢丰川祥子

Sat, 09 May 2026 23:05:11 +0800

idea+骨架创作: 我

润色：DeepSeek V4

标题：neta了素晴日。

兼容力学少女与鲸鱼之诗

习惯了在显存带宽与计算密度之间做腾挪的人，才更懂得长序列记忆与极致吞吐兼得的美。

习惯了在模型精度与推理成本之间做取舍的人，才更懂得顶尖效果与普惠部署兼得的美。

习惯了在训练稳定性与收敛速度之间做让步的人，才更懂得万卡不崩与效率翻倍兼得的美。

但今天不想聊技术。今天想聊一个人。

丰川祥子。

如果你没看过《BanG Dream! Ave Mujica》，没关系。你只需要知道一件事：这个女孩曾经是月之森的大小姐，住在洋馆里弹钢琴，人生剧本写满了从容与优渥。然后命运把剧本撕了。家道中落，父亲颓废，她不得不搬到破旧的出租屋，白天上课，晚上打工，在便利店清点货架，在深夜计算这个月的水电费还差多少。

如果故事停在这里，就是一个俗套的坠落。

但祥子没有坠落。她做了一件事——组乐队。不是随便组着玩的乐队，是Ave Mujica，一个戴面具、演哥特式戏剧、用最快速度杀向主流的商业乐队。

她要用最体面的方式赚钱。

注意这个词：体面。

她本可以去陪酒，可以去找有钱人依附，可以放弃音乐随便找份工作。她没有。她偏要在音乐这条路上站着把钱挣了。她偏要在艺术的框架里，解决生存的问题。她偏要戴着蕾丝面具、踩着舞台烟雾，让那些曾经仰望她的人继续仰望——只不过这一次，仰望的是她自己挣来的光。

做惯了工程上trade off的人，看到这里应该会心头一颤。

因为这就是我们每天都在面对的困境——理想架构在实验室里美得像诗，一落到工程上就全是妥协。你要精度，算力就不够；你要速度，显存就爆炸；你要效果，成本就失控。你在这些约束条件之间走钢丝，每天都在割舍，每天都在告诉自己“没办法，只能这样”。

因为这就是我们每天都在面对的困境——你明知道那段代码再重构一次就能干净，但下个迭代的死线已经顶到嗓子眼，你只能再贴一个TODO，像在所有破掉的窗户上糊报纸。你要把变量名起得见文知义，PR里有人回“能跑就行”；你要把架构理清楚再动手，需求文档上周改了四版，最新一版还没人确认。你在优雅和交付之间反复被撕扯，每天都在心里举手投降，每天都在告诉自己“先活过这个sprint再说，没办法”。

因为这就是每个还在读书的人逃不掉的困境——你考研的时候觉得上岸就解脱了，读完发现学历贬值的速度比你毕业还快；你想做学术，导师的项目和你的论文毫无关系，你在实验室里拧螺丝，拧了三年拧出一个别人看不起、自己说不清的学位。你每天都在“读下去”和“赶紧就业”之间反复横跳，每天都在想，是不是选哪条路都后悔，没办法。

因为这就是每个社会人都在经历的困境——你上班痛苦，裸辞了发现没班上更痛苦；你上学的时候想打工，打工了之后想回去上学。你有时间的时候没有钱，有钱的时候没有时间。你在围城里羡慕围城外，跳出去才发现外面是另一堵墙。你在这些永远错位的选项之间怀疑人生，每天都在想，是不是人生就是这样，永远够不到自己想要的，没办法。

因为这就是每个在城市里独自打拼的人说不出口的困境——你每天已经被工作抽干了力气，连自己的情绪都照顾不好，哪还有余力去好好承接另一个人的生活。你想靠近一个人，发现心动是需要成本的，时间、精力、银行卡余额，哪一样你都掏不起；你终于攒出一点勇气想主动一次，翻遍通讯录，不知道该联系谁。你在深夜把对话框打开又关上，每天都在想，是不是这辈子就这样一个人扛下去了，没办法。

因为这就是每个人都在经历的困境——你想站着解决基本问题，规则告诉你跪着才快；你想在日复一日的消耗里留住一点属于自己的火苗，可光是活下来就已经用尽了全部力气；你想做一个体面的、不割裂的、对自己诚实的人，但世界递给你一张又一张选择题，每一张都写着“理想和现实，你选一个”。你在这些选项面前沉默了十年，差一点就信了，是不是人生本来就没办法既要又要。

祥子说：凭什么只能这样？

凭什么搞钱就一定要姿势难看？凭什么艺术和商业就一定互斥？凭什么生存和理想就一定要二选一？

她不选。她要两个都要。

这让我想起一家公司——DeepSeek。

如果你关注AI圈，你一定知道这家公司在中国大模型浪潮里的位置。当别人在疯狂囤卡、堆参数、比榜单的时候，DeepSeek在做一件看起来很不性感的事：把算法和infra做到极致平衡。

这有多难？算法团队要的是理想模型，是代码写出来就自带美感的架构，是论文上的SOTA；infra团队要的是工程实现，是算力利用率，是推理延迟，是每一分钱都要花出响动。这两个团队在任何公司都在打架，因为他们的目标函数天然互斥。

DeepSeek说：不打。我们都要。

他们用MoE（混合专家模型）把模型拆开，不是所有参数都在同一时间激活，大幅降低推理成本——这不是妥协，这是重构。他们把自己的推理成本打到让整个行业沉默的价格，然后用API开放出去——这不是割肉，这是升维。当别人还在“烧钱换规模”和“小而美”之间二选一的时候，DeepSeek找到了第三条路：用工程上的极致聪明，支撑算法上的极度野心。

这就是DeepSeek的第一层“既要又要”：技术本身的既要又要。理想模型与工程实现的统一。诗与代码，一个都不辜负。

但更让我着迷的是第二层。

你知道DeepSeek的母公司是做量化交易的吗？他们不仅在AI技术上做到了顶尖，他们还通过做空英伟达赚到了世俗意义上的钱。

一个做AI的公司，做空了全世界AI公司都离不开的芯片巨头。

这意味着什么？意味着他们不站队。不被英伟达的估值神话绑架，不被行业叙事的泡沫裹挟。他们冷静地判断市场，冷静地下注，然后用赚来的钱——注意——反哺自己的技术理想。

谁说做技术的就只能清贫？谁说赚钱的就一定俗气？谁说理想主义者的宿命就是穷着？

DeepSeek不信这个。

祥子也不信这个。

Ave Mujica的首次大规模亮相就以史无前例的速度登上了日本地标性演出场地武道馆。祥子穿着一身黑，戴着面具，站在追光下，指尖落在键盘上的那一刻，她就不是在便利店打工的那个祥子了。但她也没有变回月之森的大小姐。她成为了第三种存在——一个能把月光变成六便士、也能把六便士铸成月光的人。

这种审美，我称之为“升维兼容”。

不是妥协。妥协是在约束条件里求一个局部最优解，是“算了就这样吧”。

不是平衡。平衡是把两件事都做好，但它们还是两件事。

升维兼容是：我创造一个新的维度，在这个维度上，理想和现实不再是光谱的两端，而是同一件事的两个侧面。

祥子的新维度，是Ave Mujica的戏剧性。她把生存的狼狈变成舞台上的美学，把被生活撕碎的面具变成表演的核心元素。她需要钱，这个动机本身，就成了她艺术叙事的一部分——观众看到的面具、暗黑风格、哥特式世界观，都是她的困境转化而来的。赚钱和艺术，在Ave Mujica身上是同一件事。

DeepSeek的新维度，是他们独特的组织基因。量化交易训练出来的极度务实、极度数据驱动、极度反共识，恰好也是做AI infra最需要的品质。他们做模型不是为了发论文，是为了能用；他们做空英伟达不是为了投机，是出于判断。技术能力与商业嗅觉，在DeepSeek身上是同一件事。

祥子不是我需要钱然后顺便做做音乐，她是用音乐本身去需要钱。

DeepSeek不是我做了AI然后顺便炒炒股，他们是同一套认知体系在不同战场上的投射。

这就是为什么做惯了工程上trade off的人，会天然地喜欢丰川祥子。因为我们太知道在约束条件下求解有多痛了，我们太熟悉那种“不得不放弃什么”的窒息感了。所以当我们看到一个人、一个团队，居然能在更高维度上让所有看似互斥的目标同时成立，那种冲击不是羡慕，是审美上的共振。

那是在说：你不是非得选。

你可以既要算法的美，又要工程的强。你可以既要技术的深度，又要商业的锋利。你可以既要仰望星空的那个自己，又要脚踏实地的那条路。你可以既要月光，又要六便士——不是在两者之间找到一个还不错的平衡点，而是在一个新的维度上，让它们变成同一个东西。

这就是丰川祥子。这也就是DeepSeek。这也就是每一个不甘心在二选一面前低头的人，心中最深处的那个答案。

当祥子在舞台上弹下第一个和弦的时候，台下没有人知道她昨晚在便利店站了四个小时。他们只看到一个光芒万丈的键盘手，戴着神秘的面具，像从未坠落过一样优雅。

那不是伪装。那是她应得的体面。

六便士她挣到了，月光也没有丢。

杂谈：积累行业技术经验，或是骗局

Thu, 07 May 2026 23:45:36 +0800

这集很短

一个听上去反常识但是实际上很合理的事情: 这个世界的经验值总量也是有上限的，不要相信什么越老越吃香，因为很多东西的建设都只有一次，只有在当时建设这个东西的那个生态位上的人能够获取这部分经验，而后来者只能获取一些维护经验。所以很多宝贵的经验都是随着项目的结束，而永远属于一小批参与者。

实际上我们也并没有那么多建设要去做。