中枢：从三公九卿到军机处，相权一步步被拆空

秦朝：丞相、太尉、御史大夫，第一次把权力拆成三份

公元前221年，秦始皇并吞六国，天下第一次有了一个真正统一的帝国。疆域大了，过去分封诸侯的路子走不通了。丞相王绾起初主张把子弟封到燕、齐、楚等偏远之地当王，廷尉李斯站出来反对。他说，周朝分封子弟，结果年代一久，诸侯互相攻伐，连周天子都管不住，如今海内一统，应该设置郡县，由朝廷直接任命官员，再也不用封王建国。秦始皇采纳了李斯的建议，中国从此告别分封制，走进郡县制时代。

这一年还发生了一件影响千年的小事：群臣请秦始皇上尊号。此前六国君主都称"王"，秦王觉得自己功过三皇五帝，再称王不足以显示地位，于是取"皇"与"帝"二字，自称"始皇帝"，希望子孙后代二世、三世一直传下去，传之无穷。从这时起，"皇帝"成为国家元首的正式称号，一直用到辛亥革命。皇帝之下，还有一套完整的玺印、避讳、仪仗制度来突出他的至高无上——诏书要加盖皇帝玺，臣民说话写字要避皇帝的名讳，皇帝出行要清道。这些规矩的本质是同一个：帝国只有一位最高决策者，官僚系统再庞大，也只是替他办事的工具。

中央的架子怎么搭？秦朝的设计是三公九卿制。把历代中央中枢机构摆在一起看，演变脉络会更清楚：

从这个表可以读出中国官制史上最重要的一条线索：相权的曲线，从高到低，几乎从未回头。三公九卿时宰相是百官之首，隋唐被拆成三省，宋代被切成二府三司，元代短暂回潮，明代干脆废除，清代只剩一个没有决策权的军机处。相权衰落的每一步，都对应着皇权的一次加强。

三公是三个最高的官：

• 丞相，百官之首，帮皇帝处理全国政务。金印紫绶，秩万石，是秦朝官制里实权最大的职位。李斯后来就当过丞相。
• 御史大夫，副丞相，银印青绶。他的本行是监察百官，掌管文书奏章，是中国古代专门监察官制度的开端。
• 太尉，名义上掌军事。这个职位有点特殊——制度上有，实际上长期空缺，秦始皇在位时似乎从未任命过谁当太尉。出兵打仗时，将领由皇帝临时委派，打完仗兵权就收回。皇帝把军权捏在自己手里。

三公之下是九卿，各管一个领域：奉常管宗庙祭祀，郎中令管宫廷宿卫，卫尉管宫门屯兵，太仆管皇帝车马，廷尉管司法。典客管外交与少数民族事务，宗正管皇族事务，治粟内史管国家财政，少府管皇帝私产。此外还有掌京畿治安的中尉等官，共同组成帝国早期的中枢机构。

这套设计有个关键点：丞相、太尉、御史大夫互相制衡，谁也不能独揽大权。丞相总揽政务，御史大夫监督丞相，太尉管军事却常设空缺。重大事务还要拿到朝堂上廷议，最后由皇帝裁决。

从分封制到郡县制、从世卿世禄到三公九卿，最本质的变化不是官职名称，而是做官的方式。过去，诸侯卿大夫的职位是世袭的，父死子继，爵位土地跟着姓氏走；现在，郡守县令由皇帝任命，拿朝廷俸禄，干不好随时撤换，做官靠的是能力和政绩，而不是出身。历史学家把这称为"官僚政治取代贵族政治"——帝国的管理权第一次完全掌握在职业官僚手里，而职业官僚的效忠对象只有一个，那就是皇帝。三公九卿把权力分给三个人，其实也是要把秦以前的世袭贵族从权力中心请出去。

不过，秦朝中央机构的实际运转，和制度条文并不完全一样。比如廷尉李斯，他原本是管司法的九卿之一，因为才能出众、又深得秦始皇信任，实际权力远超过职位本身，最后升任丞相，成为秦朝实际上的二号人物。在秦朝，职位只是权力的起点，皇帝的信任才是权力真正的来源。谁离皇帝近、谁受信任，谁的权力就大，这个规律贯穿了此后两千年的官制史。

西汉：皇帝身边多了一群"身边人"，尚书台开始掌权

汉朝基本照搬了秦朝的制度，仍设三公九卿，但很快就出现了一个新的动向：皇帝开始不信任外朝的大臣，转而倚重自己身边的近臣。

汉武帝时期，丞相的权力依然很大，汉武帝却不愿事事都经过丞相。他把一些地位不高但亲近可靠的人——尚书、侍中、散骑、常侍等——拉到自己身边，组成所谓的中朝（内朝），帮自己出主意、写诏令、处理机密。以丞相为首的朝廷官员被称为外朝。中朝虽是皇帝身边的小班子，权力却越来越大，史书上说"尚书见任，重于三公"。

这个变化的意义在于：皇权与相权的矛盾，皇帝找到了第一个解法——不撤掉丞相，而是绕过丞相。武帝让外戚卫青、霍去病做大将军，权位在丞相之上；又用霍光为"大司马大将军"，把军权、机要大权一并握在手里。汉昭帝以后，霍光实际上代替皇帝处理国政，连皇帝的废立都由他做主——霍光、后来的王莽，都是借着内朝重臣的身份专权的。内朝本是皇帝制衡丞相的工具，用久了，反而可能成为新的威胁。

中朝官的制度地位也很特殊。尚书本是少府的下属，管文书传达，不过是宫中一名普通办事员。可正因为天天在皇帝身边，负责把各地奏章送进送出，他比任何外朝大臣都更早、更多地接触机密。皇帝把越来越多的政务交给尚书，尚书的实际权力就越来越大。这种"以卑制尊、近水楼台"的用人逻辑，贯穿了整个中国官制史：皇帝总是更信任那些品级不高、却离自己最近的人。汉代的中书、尚书，唐代的翰林学士，明代的内阁大学士，清代的军机大臣，无一例外，都走过从"近臣"到"权臣"的轨迹。

与此同时，丞相的权力则一路下滑。汉武帝用丞相十余人，不少人因失职或猜忌被罢免甚至下狱处死。丞相公孙贺被下狱，李蔡畏罪自杀，石庆虽任丞相却"醇谨而已"，只管签字画押。到了西汉末年，三公的名称干脆改了：丞相改称大司徒，太尉改称大司马，御史大夫改称大司空，名义上并立为三公，实际仍以大司马掌权最重。这为东汉的三公格局埋下了伏笔。

西汉中后期，尚书开始分曹办公。汉成帝时初置尚书五人，其中一人为仆射，其余四人分管四曹事务，后来又增设三公曹，共成五曹。到了东汉光武帝刘秀手里，这套班子被彻底扶正。刘秀要自己乾纲独断，便把政务中心从三公府挪到尚书台，军国大事都先送进尚书台处理，再交三公执行。后人评价说：

"虽置三公，事归台阁。"

意思是说，三公的名位还在，实际权力已经全归尚书台了。东汉的尚书台设尚书令一人总管，下设六曹分管吏治、民政、财政、礼仪、司法等事务。从这时起，皇帝身边的小秘书班子，正式取代了名正言顺的宰相机构，成了帝国真正的政务中枢。

东汉还有一个官制细节值得注意：监察系统的独立。西汉时御史大夫是丞相的副手，二者同属外朝；东汉把御史台从相府系统中分出来，由御史中丞统领，与尚书令、司隶校尉在朝堂上"专席独坐"，地位特殊，史称"三独坐"。监察从行政里分离出来，成为独立的一支，这正是后来历朝监察系统不断壮大的起点。

不过，光武帝把权力收进尚书台，也埋下一个隐患：尚书台离皇帝太近，皇帝年幼或怠政时，谁控制尚书台，谁就控制了帝国。东汉中后期皇帝大多年幼继位，外戚（太后娘家）借着辅政把持朝政，皇帝长大后想夺回权力，又只能依靠身边的宦官，宦官因此掌权。外戚与宦官交替专权，成为东汉政治的顽疾。大臣们一次次试图靠"清议"和党人来对抗，却屡屡失败，东汉的衰落与这套制度的漏洞有直接关系。

隋唐：三省六部制，把宰相一职切成三段

魏晋南北朝时期，门阀士族把持朝政，官制也乱象丛生。真正把中央官制重新理顺的，是隋文帝杨坚。他废除了延续三百多年的九品中正制，又对中央机构动了一次大手术，奠定了三省六部制的基础。唐朝继承并完善了这套制度，把它变成中国古代影响最深远的中央官制。

三省是指三个平行的中央机构：

• 中书省（隋朝称内史省），负责起草皇帝的诏令，长官是中书令。
• 门下省，负责审核诏令，如果觉得不妥，可以封还诏敕，有资格驳回皇帝的意见，长官是侍中。
• 尚书省，负责执行政务，把已定的政策交给下面落实，长官本是尚书令。因为唐太宗李世民即位前当过尚书令，此后尚书令一职基本空缺，由左右仆射实际主持尚书省事务。

一件大事的流程是这样的：先由中书省起草诏令，送交门下省审核，审核通过后再交给尚书省执行，尚书省下设六部来具体经办。

六部的分工后来被宋、元、明、清沿用了上千年，至今仍能在现代国家部门设置中看到它的影子。

三省长官都是宰相，合在一起议事的地方叫政事堂。皇帝如果想增加宰相人选，不必给谁升官，只需给他加一个头衔，让他"同中书门下平章事"或"参知政事"，就能进政事堂参与决策。这样一来，宰相不再是某一个人，而是一个集体，谁也不能单独擅权。中书、门下、尚书三省的相互制衡，加上政事堂的集体议事，把过去由一个人担任的相权，切成了好几份。

三省制在运行中还有一个关键机制：封驳。门下省审核诏令时如果认为不妥，可以涂改后封还给皇帝，这叫"封还"或"涂归"。也就是说，皇帝拟好的诏书，中书省起草、门下省审核，门下省不点头，诏令就发不出去。唐太宗的许多诏令都被门下省大臣纠正过，太宗不但不恼，还夸奖他们尽到了职责。魏征敢在朝堂上当面顶撞皇帝，背后有整套制度撑腰：他是谏臣，职责就是挑毛病。贞观之治能被后世称道，恰恰是因为这套制衡制度还在有效运转。

当然，宰相人数增多也有代价。政事堂的宰相常常多至十几人，人多主意多，遇到大事容易议而不决。唐高宗以后，皇帝开始让品位较低的人用"同中书门下三品"等名号进入政事堂，宰相队伍进一步扩大。到了唐玄宗时，政事堂改称"中书门下"，下设五房，机构越来越像一个正式的行政中枢。盛唐时期的许多制度创新——科举、均田、租庸调、府兵——都是在这套中枢制度下推行的。

唐朝还有一个值得注意的现象，叫使职差遣。三省六部是正儿八经的正式官制。可到了唐中后期，皇帝办具体的事，往往不经过尚书省六部，直接派一个"使"去专管——盐铁使管财政，转运使管漕运，度支使管粮食。这些"使"不是正式官职，没有品级，但握有实权，架空了很多原来的部门。安史之乱后，财政大权实际上都掌握在盐铁使、转运使、度支使这些人手里，三省六部逐渐沦为清闲衙门。官制松弛、实权旁落，是唐代后期政治的一个显著特点，也为后来的藩镇割据提供了土壤——制度管不住事的时候，人就越过制度直接行事。

宋代：二府三司，把权力再切一刀

唐朝亡于藩镇割据，五代十国武将轮流坐庄，宋太祖赵匡胤自己就是靠兵变上台的。他深知兵权和相权的危害，上台后对官制做了更彻底的分割。

宋朝中央实行二府三司制。二府指中书门下和枢密院：

• 中书门下（又称政事堂、东府），掌行政，宰相加"同中书门下平章事"衔，副宰相叫"参知政事"。
• 枢密院（又称西府），掌军事，长官是枢密使，多由文官担任。

三司则管财政，设盐铁、度支、户部三司，长官叫三司使，因为掌管全国的财权，人称计相。

这样，过去集中在宰相手里的政权、军权、财权，被拆成了三个互不统属的系统，各自直接向皇帝汇报。军事上还加了一道保险：枢密院有发兵之权，却没有统兵之权；三衙（殿前司、侍卫亲军马军司、侍卫亲军步军司）有统兵之权，却没有发兵之权。两边的权力都要靠皇帝来协调。

宋朝官制还有个独特的地方，叫官、职、差遣分离。官员的品级俸禄（"官"）、虚衔（"职"）和实际干活的岗位（"差遣"）完全是三回事。有人当的是三品官，实际在地方做知州；有人顶着一堆学士头衔，却闲在家里。这样做的好处是皇帝可以随意安排官员，不怕他坐大；坏处是冗官泛滥、机构重叠。宋代的官僚队伍空前庞大，行政效率却常常低下，这成为北宋后期积贫积弱的一个重要原因。

这个制度的逻辑，其实和汉武帝设内朝一脉相承：让官位与实际权力脱钩，权力就永远攥在皇帝手里。但宋朝把它用到了极端。一个官员的真实职务，要看他的"差遣"是什么，比如"知开封府""知苏州"；而他的"官"只是用来定俸禄品级的符号，比如"尚书""侍郎"这些名号在宋朝只是虚名，与实际的六部事务无关；"职"则是一堆学士、待制、直学士之类的荣誉头衔。结果就是朝廷养着大批"有官无职""有职无事"的人，机构叠床架屋。北宋中期，官员的数量比开国时翻了好几倍，而军费、官俸加起来，几乎耗尽了帝国的财政。

宋神宗时期，王安石变法想给这套臃肿的官制动手术，核心之一是改革科举、整顿学校。元丰年间，宋神宗又亲自推行官制改革，恢复三省六部的大部分职能，裁撤闲散机构，把"官""职""差遣"重新统一起来。但积弊已深，改革只解决了一部分问题，北宋后来的军事失利和财政危机，仍与官僚机构的低效脱不开干系。

元朝：一省独大，宰相权重回潮

元朝由蒙古人建立，官制上有个明显的特点——中央机构设得少而专。最高行政机关是中书省，总揽政务，下面直接管六部；枢密院管军事；御史台管监察。这就成了"一省两院"的格局。中书省的长官是中书令，通常由皇太子挂名，实际主持政务的是右丞相、左丞相和平章政事。元朝以右为尊，右丞相的权位最高。

相比宋代把相权切得粉碎，元朝的中书省权力很大。丞相一度能主持朝政、任免百官，这在中国官制史上是罕见的回潮。权力大了，争夺也就激烈。元朝历史上，阿合马、桑哥、脱虎脱等人先后以"理财"为名专擅朝政，把持中书省，任用自己的亲信，排斥异己。阿合马掌权二十余年，贪赃枉法、势倾朝野，最后被王著刺杀，震动朝野；桑哥当权时也同样横征暴敛。这些权臣一倒台，皇帝又换一批新人上来，如此循环。

为什么元朝的中枢会出现这种反复？一个重要原因是元朝没有像唐宋那样把相权制度化地拆散。三省六部在元朝被压缩成一省六部，制衡机制大大减弱，权力高度集中于中书省；而元朝皇位继承又缺乏严格的制度，皇帝更替频繁，年幼或弱势的皇帝无法驾驭宰相，大权自然旁落。可以说，元朝是在制度上"简化"了中枢，却让权力运行的稳定性变差了。这为明代朱元璋断然废相提供了最直接的教训。

元朝历史上还出现过尚书省的反复置废，更能说明当时权力斗争的激烈。元世祖时曾设尚书省专管财政，由权臣阿合马、桑哥先后主持，以"理财"为名聚敛财富、打压异己，结果政敌弹劾，尚书省被撤；元武宗时又恢复尚书省，脱虎脱掌权，只设了三年，武宗一死，继位的仁宗立刻罢省，把脱虎脱等处死，又回到中书省独大的格局。中书省与尚书省的反复替换，与其说是制度之争，不如说是权臣之间的权力之争——谁掌了中书省或尚书省，谁就握住了帝国的钱袋子与权柄。这样的中枢格局，注定了元朝的政治始终充满震荡，也让它没能像唐宋那样，建立一套稳定高效的官僚运行机制。

明清：丞相被废掉，军机处成为最后的答案

明朝开国皇帝朱元璋对相权的态度最为决绝。其实明初的中央官制，一度是照着元朝的样子搭起来的：设中书省统管政务，中书省长官（丞相）总揽大权，地方则沿用行省制。第一任丞相李善长、胡惟庸都手握重权。洪武十三年（公元1380年），朱元璋以谋反罪名处死丞相胡惟庸，受牵连者达数万人，然后借机宣布永久废除丞相制度，中书省随之撤销，六部直接向皇帝负责。他还在祖训里立下规矩，不许后代再设丞相。秦汉以来运行了上千年的宰相制度，就此终结。

废相之后，六部地位空前提高。吏、户、礼、兵、刑、工六部尚书成为实际上的最高行政长官，直接对皇帝负责，不再受宰相节制。军事上，朱元璋还把大都督府一分为五，设前、中、左、右、后五军都督府，各管一部分卫所军队，有统兵之权而无调兵之权，调兵须凭皇帝的兵符，与兵部相互制约。这样一来，文官系统、武将系统都没有任何人能独揽大权，一切最终都归于皇帝一人。

可皇帝一个人处理不来全国的政务。朱元璋废相后忙得不可开交，据说一天要批几百份奏章，有时处理政务到深夜。他先设了四辅官帮忙，效果不好，又设立殿阁大学士，帮自己处理文书，但大学士品级低、只是顾问，并不参与决策。朱元璋本人在位三十一年，全靠自己日夜操劳，勉强支撑。到明成祖朱棣时，才正式成立内阁，由大学士入阁办事，帮皇帝拟旨、处理文件。内阁大学士起初品级不高（正五品）、只是顾问，后来权力逐渐加大。尤其从明宣宗时期确立"票拟"制度后，内阁先对奏章提出处理意见，再由皇帝审定，内阁首辅俨然成了没有宰相之名的宰相。内阁的权力，是一点一点"长"出来的，不是皇帝一开始就打算给的。

内阁制度的具体运作，有一个很典型的流程。官员递上奏章，先由内阁大学士"票拟"——在一张纸条上写出处理意见，比如"建议照准""建议驳回"，附在奏章后面；然后奏章连同票拟送进宫里，由皇帝过目。皇帝认可，就用红笔照抄票拟的意见，这叫"批红"；不认可，就改几个字或另写意见。明朝许多皇帝懒于政事，几十年不上朝，干脆把批红的活儿交给司礼监的太监代办。这样一来，票拟权在内阁，批红权在司礼监，两个机构一外一内，互相牵制，谁都不能一家独大。

这套"双轨"设计在皇帝勤政时运转良好，皇帝一旦懈怠，大权就落到太监手里。明武宗时，司礼监太监刘瑾权倾朝野，官员找他办事得排队送礼，人称"立皇帝"；明熹宗时，魏忠贤更是把持朝政、遍布党羽，被称为"九千岁"。内阁首辅与司礼监太监之间的明争暗斗，贯穿了整个明代中后期。张居正能推行十年改革，恰恰是因为他与掌权的太监冯保配合默契——一个在内廷批红，一个在外廷票拟，两头联手，政令才能畅通。宦官专权成为明代中后期的顽疾，东厂、西厂、锦衣卫等特务机构横行，很大程度上就是皇帝用内臣制约外朝大臣的结果。

清朝是满洲贵族建立的王朝，中枢机构的演变有它自己的轨迹。清初，军国大政由满族贵族组成的议政王大臣会议决定，皇帝也要受它约束，汉人大臣根本不能参与。康熙帝觉得这班老贵族碍事，十六年（公元1677年）在南书房挑选亲信翰林办事，逐步架空议政王大臣会议。雍正帝更进一步，彻底抛开旧机构，另设军机处。议政王大臣会议直到乾隆五十六年（公元1791年）才被正式取消。真正的转折，是军机处的设立。雍正七年（公元1729年），因为西北用兵，军情紧急，雍正帝在隆宗门内设了一个临时的"军需房"，后来正式改为"办理军机处"，简称军机处。

军机处一改过去中枢机构臃肿的毛病，人员精干，只有几个军机大臣和若干军机章京，由皇帝在满汉大臣中亲自挑选。军机大臣没有品级、没有属员、没有专门的衙门，就在皇帝寝宫旁的一排平房里办公。皇帝早晨召见，当面交代事项，军机大臣领旨出来，当天就得把谕旨拟好。拟好的谕旨分两种：重要的、需要保密的下达给地方的，用纸折叠封好，由驿马直接寄送，叫"廷寄"；常规的则交内阁下发。军机大臣的职责是替皇帝起草谕旨、传达命令，自己不能做主。清代史家赵翼曾在军机处任职，他在《檐曝杂记》里记过一句话：

军机大臣"只供传述缮撰，而不能稍有赞画于其间"。

赵翼的意思是，军机大臣只是把皇帝的意志转述成文字，不能掺进一点自己的想法。这句话道破了军机处的本质：它是皇帝的一个传声筒，不是决策机构。决策权从头到尾都在皇帝手里。也正因如此，军机处没有重蹈内阁的覆辙——内阁后来权力变大，军机处却始终只是个起草班底，因为雍正帝从一开始就没打算让它有任何独立意志。此后一百多年，清朝的一切军国大政，都由这个小小的值班室定夺。

清代官制还有一个显著特点，就是满汉复职、满员优先。中央六部，尚书、侍郎都设满、汉各一人，满汉各占一半。但上奏、议政、用人，处处以满官优先，关键事务常由满员拍板。皇帝还特设理藩院，专门管理蒙古、西藏、新疆等边疆民族事务和对外交涉，长官只能用满、蒙贵族，汉人不能过问；又有内务府管理宫廷事务，把太监的权限压到最低。议政王大臣会议、军机处等核心决策机构，也始终由满洲贵族占主导。清朝一边完整地继承汉人王朝的官制外壳，一边用满族贵族的人事安排控制内核，内外两套逻辑并行，是清代官制区别于历代的一大特色。

皇帝通过军机处，把诏令直接寄给地方大员，叫"廷寄"；地方大员的机密奏章也不再经过内阁，直接进呈皇帝。至此，从中书草诏、门下封驳到政事堂合议，再到内阁票拟、军机处承旨，相权被彻底剥夺，一切决策权都集中到皇帝一人手里。清代君主专制达到了中国历史上的顶点，直到1911年清廷宣布废除军机处，实行责任内阁制，两千多年的帝国官制才走到尽头。

地方：从郡县到行省督抚，中央的手越伸越长

秦朝：郡县两级，官员全部由中央任命

如果说中央官制的核心问题是皇帝怎么分自己的权，地方官制的核心问题就是中央怎么管住辽阔的疆土。秦始皇统一六国后，废除了分封制，在全国推行郡县制。郡和县是两级行政单位，无论哪一级的长官，都由皇帝直接任免，拿了俸禄替朝廷办事，随时可以撤换。这和过去"封邦建国、世代承袭"的贵族统治有本质区别。

地方行政层级的变化，可以先把几个大朝代的框架放在一起看：

表格里能看出一个反复出现的现象：层级少了，地方官权重；层级多了，行政又冗繁。隋唐极力压缩成两级，是为了提高效率；宋元明清又增加层级，是为了分权制衡。帝国就在"简"与"繁"之间不断摇摆。

秦朝初年把天下分成三十六郡，后来随着疆域扩张，又陆续增加到四十多个郡。每个郡设三个主要官员：

• 郡守：一郡的最高长官，秩二千石，管民政、刑狱、赋税。
• 郡尉：掌一郡军事，负责治安与驻防，直属于朝廷，与郡守互相牵制。
• 监御史（又称郡监）：由中央的御史系统派出，专门监察郡守和其他官吏。

郡守、郡尉、监御史三者互不统属，各管一摊，这是秦朝地方官制的精巧之处——长官、军事、监察三权分立，谁也不能独自控制一郡。郡尉、监御史名义上是郡守的下级，实则直接对中央负责，等于在郡守身边安了两个"监工"。

县一级，人口万户以上的县设县令，万户以下设县长，下面是县丞（佐贰官）、县尉（掌治安捕盗）。县以下还有乡、里等基层组织，设三老（掌教化）、啬夫（掌赋役）、游徼（掌治安）等乡官。秦朝还实行编户制度，把百姓按"什伍"编组，十家为什、五家为伍，互相监督、连坐，一家犯法，邻里不报也要受罚。这套从中央到乡里的层层机构，把国家权力的触角一直伸到了每家每户。

这套制度最要紧的地方在于层级清晰、权责分明、官不世袭。郡守、县令都是拿朝廷俸禄的职业官僚，定期考核，干不好就撤换，没有人能像过去的诸侯那样把一郡一县当成自家地盘。中央靠着这一层一层的任命链，把自己的命令从咸阳传到帝国每一个县。秦朝的统一之所以能维持，郡县制功不可没；而它二世而亡，也提醒后人，单靠严密的机构并不能保证一个王朝长久。

秦朝的郡县制运行了不到十五年，王朝就二世而亡。但郡县这种地方治理框架被汉朝完整继承，此后两千多年再也没有被真正推翻过。分封制虽然时不时回潮（比如汉初、西晋、明初），总是迅速被郡县制重新取代。

西汉：先封诸侯，再收诸侯；州从监察区变成行政区

汉初，刘邦认为秦朝不分封宗室、有难无人相救，于是郡县与分封并行，把大片土地封给刘姓诸侯王。这些诸侯王拥有实权，可以自己任命官员、征收赋税、保有军队，地盘加起来比朝廷直辖的郡县还大。隐患很快爆发：汉景帝时期的七国之乱，就是诸侯王联合对抗朝廷的一次大叛乱。叛乱平定后，朝廷不断削减诸侯王的权力，削地、收兵、派朝廷官员去管理王国事务，到汉武帝时，诸侯王已基本失去实权，只剩下享受租税的虚名。郡国并行最终又回到郡县为主。

汉武帝收拾诸侯王，用的手段尤其巧妙。大臣主父偃给他出了个主意，叫推恩令：允许诸侯王把封地分给所有的儿子，而不只是嫡长子继承。这样一来，一个大国自动分裂成几个小国，藩国的土地越分越薄，势力越分越弱，不用朝廷动手，诸侯自己就瓦解了。朝廷还借机派人监督封国，把封国的地方官任免权、司法权逐渐收回。到汉武帝后期，诸侯王只剩一个空名，天下的治理重心，重新回到朝廷直接控制的郡县。

汉朝的地方官制还有一个特点：郡守的权力比秦朝时更大。汉代郡守总揽一郡民政、财政、司法、军政，兼有地方官的行政权和部分军事权，俸禄二千石，是地方最有权势的官员。为了监督郡守，朝廷除了派刺史巡查，还设有司隶校尉，负责监察京师附近地区。可以说，汉代的地方官制是在郡县框架下，一边给郡守实权，一边用监察系统紧盯着他们，权力与监控始终相伴而行。

汉武帝还有一个重要动作：设立十三州部刺史。公元前106年，他把全国划分为十三个监察区，称为州，每州派一名刺史去监察地方。刺史的品级不高，只有六百石，而他们要监察的郡守是二千石。这个"以卑临尊"的设计是故意的：品级低的官更听话、更敢说话，也不容易拉帮结派；反过来说，让一个高官去监察另一个高官，两人容易互相包庇。刺史按"六条问事"来监督郡守，主要检查郡守有没有贪赃枉法、压榨百姓、结党营私之类的问题，一年一度到京城汇报。这六条之外的事，刺史不得多管——朝廷特意划定了刺史的权力边界，就怕他们越权干政。

州起初只是监察区，不是一级政府。刺史只管查，不管治，没有自己的衙门和属官。但随着时间推移，刺史的权力越来越大，特别是东汉中后期，地方战乱频繁，刺史逐渐掌握了实权。到东汉灵帝中平五年（公元188年），朝廷干脆任命重臣出任州牧，兼管一州的军政民政，州由此从监察区正式变成郡县之上的一级行政区。地方行政从郡县两级，变成了州、郡、县三级。

这个转变的影响极其深远。州牧手握一州大权，远离朝廷控制，东汉末年各地州牧拥兵自重，袁绍、刘表、曹操等人都是靠州牧或州郡长官的身份起家的。中央为了加强对地方的监控而设的监察官，最终变成了地方割据的种子。三国鼎立、魏晋南北朝的长期分裂，很大程度上就源于地方权力的又一次坐大。

隋唐：州县两级，道由监察变成藩镇

隋朝重新统一后，为了改变南北朝时期地方机构臃肿的局面，把地方层级压缩回州（郡）、县两级。隋文帝之前，北朝地方上州、郡、县三级并设，一个郡往往只管几个县，官员冗滥。隋文帝下令废除中间的郡一级，把地方精简为州、县两级，州的长官叫刺史。又规定地方官一律由吏部任命，本地的官员不许在本乡本土做官（回避制度），任职期满要轮换。这些做法后来都被唐代继承。

唐朝初期，中央还沿用了汉代派监察官巡视地方的做法。贞观元年（公元627年），唐太宗把全国按山川形势分成十道，比如关内道、河南道、河东道、河北道、山南道、陇右道、淮南道、江南道、剑南道、岭南道。此时的道只是地理上的监察区域，朝廷不定期派人去巡视，并不设固定的官。到唐玄宗开元二十一年（公元733年），十道细分为十五道，把都城所在的长安、洛阳一带单独划出，每道设采访处置使，专管监察地方官吏，后来改称观察处置使。从这里可以看出一个反复出现的模式：中央派出的临时监察官，慢慢变成了固定的地方官，道的性质和汉代州由虚转实如出一辙。

问题出在边疆。为了抵御突厥、吐蕃等外敌，唐朝在边境设置节度使。节度使这个官职，本来是为了方便边境统一指挥而设的军区司令，朝廷授予他调度军队、管理边防的权力。但久而久之，朝廷为了用兵方便，又让他兼任所在州的行政长官，再让他管当地的赋税、财政、民政。一个节度使手握着几个州甚至十几个州的军政财大权，而且可以自己提拔下属，形成私人势力。天宝年间，唐朝沿边有十个节度使，安禄山一人兼任范阳、平卢、河东三镇节度使，手握重兵二十余万，比朝廷的禁军还多，这正是他敢起兵造反的资本。

安史之乱（公元755—763年）之后，中央权威一落千丈，朝廷无力收回节度使的权力，只能承认既成事实。藩镇遍布全国，节度使像过去的州牧一样拥兵自重，有的甚至父子相传、世代割据。唐朝中后期，皇帝的号令出了长安就不好使，各地藩镇各行其是，赋税不上交中央，官员自己任命。安史之乱后的唐朝，实际是中央与藩镇共存的一个脆弱的联合体。最终唐亡于藩镇，五代十国的军阀混战，正是藩镇割据的延续。

宋代：路州县三级，用分权瓦解割据

五代十国武将篡位成风，宋太祖赵匡胤自己也出身武将。他对地方割据的警惕，几乎刻进了宋朝的制度基因里。赵匡胤上台后的第一件大事，就是"杯酒释兵权"，让武将交出兵权，回家享福。从此宋朝实行"强干弱枝"的国策，把地方权力一再切碎。

宋朝地方行政区划实行路、州、县三级制。州的设置继承自唐，县也是一样，关键是中间那层"路"。路不是一个单一的长官领导的一级政府，而是由好几个互不统属的机构共同管理，分头向中央汇报：

• 转运使司（漕司）：掌一路财政赋税，把地方的钱运往中央。
• 提点刑狱司（宪司）：掌一路司法刑狱。
• 提举常平司（仓司）：掌仓储、常平仓等救济事务。
• 经略安抚司（帅司）：掌一路军事，长官是安抚使。

路一级没有一把手，四司各管一摊，谁也不归谁管。下面各州设知州，由中央派文官担任，为了牵制知州，又设一个通判作为副职。通判名义上是副手，实际握有监督知州、直接向中央打报告的特权——州里发一道命令，往往要知州和通判联合签署才有效，知州想独断专行，过不了通判这一关。县一级的长官则叫知县，同样由中央任命。

宋朝收地方财权的力度尤其大。转运使的主要任务，就是把地方的钱财源源不断地转运到中央。地方每年收的赋税、榷卖（专卖）收入，除了留下必要的开支，绝大部分都要上交朝廷，地方几乎不留积蓄。这样做的用意很明显：地方没有钱，就没有力量造反；但代价也很现实——地方一旦遇到灾荒、战事，自己拿不出钱来应对，事事都要等中央拨款，延误了时机。

这样做的效果立竿见影：宋朝的三百多年里，再也没有出现过安史之乱那样的藩镇割据，也没有任何一个地方官能威胁中央。代价是地方行政运转效率低下，机构重叠、多头管理，遇到事情互相推诿。北宋人说"本朝立法，事权皆归朝廷"，正说明地方已经被彻底架空。可"强干弱枝"也有它的反噬：中央把地方压得太死，边防就失去弹性，北宋面对辽、西夏、金的军事压力节节败退，正是这个制度走到极端的代价。

元朝：行省，把大区变成朝廷的派出机构

元朝疆域空前辽阔，在地方治理上做出了一个影响至今的制度创新——行省制度。所谓行省，全称是"行中书省"，本是中央中书省派到地方去的临时办事机构，类似今天的派出机构。因为元朝疆域太大、政务太杂，中央管不过来，就把中书省的一套班子搬到地方去，代行中书省的职权。久而久之，行省从临时的派出机构，变成了一级常设的地方行政区划。

元朝在全国设十个行省：江浙、江西、湖广、陕西、甘肃、云南、四川、河南江北、辽阳、岭北。中书省直辖的"腹里"地区（今河北、山东、山西一带）和宣政院管辖的吐蕃地区，则另成系统。行省之下，还有路、府、州、县等层级，层级比前代更多，行政体系显得层层叠叠。

行省的设置不是简单的划地盘，其中暗含着制衡的用心。十个行省的划分，故意打破了唐宋以来按山川形便划界的传统，比如把汉中划入陕西行省，把淮河两岸跨江分属不同行省，让一个行省难以凭险据守。这种"犬牙相入"的划界方式，目的就是防止地方势力占山为王。行省长官设右丞相、平章政事、左丞相、参知政事等职，多由蒙古人或色目人担任，汉人只能担任副职；各机构之上还有达鲁花赤（蒙古语意为"掌印官"），由蒙古人充任，掌握最终裁决权。

行省的权力很大，掌管一省的军事、民政、财政。但在制度设计上，行省仍只是中央的派出机构：重大事务要上报中书省和枢密院批准，军事调度、赋税征收都受中央节制，还受御史台监察。行省既是地方最高行政机构，又始终没有脱离中央的掌控，这比汉代的州牧、唐代的藩镇要驯服得多。明清两代沿用行省思路，把"省"一直保留到现代，正是从元朝开始的。

支撑行省运转的，还有一套四通八达的交通网络。元朝在全国遍设驿站，蒙古语叫"站赤"。从大都（今北京）通往各行省的驿道纵横交错，沿途设站，备有驿马、驿车、船只，供公文传递和官员往来使用；还专设"急递铺"，负责军事文书的昼夜飞传。站赤由官府统一管理，蒙古人的疆域横跨欧亚，站赤系统一直延伸到岭北、西域，中央的号令因此能迅速送达最偏远的行省，赋税贡物也能沿着驿道源源运往京城。没有这套驿路，行省制度就很难真正运转起来——行政区划解决"怎么划分"的问题，驿站解决"怎么联系"的问题，两者合起来，辽阔的疆土才真正被连成一个整体。

明清：三司分权，督抚坐大，省府县定型

明朝地方治理的开头，和元朝很像。明初沿袭行省制，但在洪武九年（公元1376年），朱元璋觉得行省长官权力太大，干脆把行省撤销，改成三司并立，把一省的大权拆成三份：

• 承宣布政使司：管民政、财政、赋税，长官是左右布政使。
• 提刑按察使司：管司法、刑狱、监察，长官是按察使。
• 都指挥使司：管军事、防务，长官是都指挥使。

三司互不统属，分别向中央汇报，谁也不能独揽一省大权，和宋代路一级的四司分权思路如出一辙。明朝全国共有十三个布政使司，加上南北两京的直隶地区，合称"两京十三布政使司"，也就是常说的十五省。为了防止地方官在本地生根，明初还严格执行回避制度——布政使、按察使等高级地方官，一律不在本省任职，而且定期轮换。

与三司相配的，是明代的卫所制度。朝廷在全国要害之处设卫、所驻军：一府设所，连郡设卫，卫所官兵世袭，平时屯田自养，战时由朝廷命将调兵出征，事毕各归本卫。这套设计把军队的驻地、粮饷和指挥权分开——卫所兵不打仗时就是屯田的农户，将领没有朝廷兵符调不动兵，因此很难像唐代节度使那样拥兵自重。可时间一长，卫所屯田被军官侵吞，士卒逃亡成风，到了明中后期，卫所军制形同虚设，朝廷不得不另募兵员，依靠军饷供养的"募兵"逐渐取代了卫所兵。

三司分权的毛病也很明显：遇到需要跨领域协调的大事，三司谁也做不了主，遇到灾荒、军情、农民起义，往往要来回请示、贻误时机。于是从明朝中期起，中央开始临时派遣官员下去总督、巡抚，协调三司办事。总督管军事边防，巡抚管民政，开始是临时差遣，办完事就回京，后来逐渐变成常设职务，凌驾于三司之上。到明朝后期，督抚已经是事实上的省级最高长官了。清代继承了这套制度，并把它正式制度化，督抚终于成为固定的地方官。

清朝的地方层级是省、道、府、县四级。一省设一个巡抚，统管全省民政军政；两三个省设一个总督，比如直隶总督、两江总督、湖广总督、两广总督，负责跨省事务。巡抚之下，设布政使（藩台）管财政、按察使（臬台）管司法，再下面是管一府之事的知府和管一县之事的知县。"省—府—县"的基本框架，一直延续到辛亥革命以后，今天中国的省级行政区划，仍是元明清三代行省与布政司制度的后代。

清代还有一级特殊的地方官——道。道设于省与府之间，分两种：分守道管民政财政，分巡道管司法监察，长官叫道员。道员起初是临时差遣，后来成为固定的中级官员，介于布政使、按察使与知府之间。在清代官场，还有一个制度外的现象：州县官大多聘请私人幕僚帮办文书、出谋划策，俗称"师爷"，尤其以擅长钱粮、刑名的绍兴师爷最有名。师爷不是朝廷命官，不拿俸禄，却掌握着地方行政的实际操作，成了正式官制之外的一股隐形力量。

清代督抚名为封疆大吏，权限其实一直受到中央严密监控。他们每有重要事务都要上奏皇帝，由军机处传达皇帝的批示，任免调动完全听命于中央。清代的督抚没有固定的任期，皇帝想换就换；朝廷还设有巡按、监察御史等，专门盯着地方大员。康熙、雍正、乾隆几代皇帝都极其重视对督抚的控制，雍正帝甚至把督抚当作自己的耳目，要求他们把地方情况直接密奏上来。督抚看起来权重，实际上不过是皇帝延伸出去的手。

清朝地方官制还有个特点，就是边疆地区另有特殊制度。蒙古地区设盟旗制度，由旗札萨克管理；西藏设驻藏大臣；新疆设伊犁将军；东北有盛京将军、吉林将军等。这些驻防将军和驻边大臣，都由中央直接派驻，体现了清朝对边疆治理的专门设计。理藩院则专门管理蒙古、西藏等少数民族事务和对外交涉。可以说，清朝把两千年来"中央控制地方"的各种手段——监察、回避、轮换、密奏、驻军、专门机构——几乎都用遍了。

清代对边疆的治理，还有一条贯穿始终的主线：改土归流。在云贵川广等西南地区，长期以来由当地土司世袭管理，土司虽接受朝廷册封，却在辖区内有自己的武装和税赋，独立性很强。雍正年间，朝廷在西南大规模推行改土归流，废除世袭土司，改派中央任命的流官治理，或把土司降为普通头人，由府县直接管辖。到乾隆年间，这一过程基本完成，西南边陲与内地渐渐趋同。改土归流是中央集权向边疆延伸的最后一环——从秦代的郡县、到元明的行省、再到清代的改土归流，中央的统治触角终于覆盖了帝国几乎每一寸土地。

从秦朝的郡守到清代的总督，地方官的级别越来越高，地盘越来越大，但有一条主线从未改变：每一级长官的权力都来自中央的任命，也随时能被中央收回。帝国的地方官制，本质上是一张由中央握着线的网，线拉得紧一些，地方就服帖；线一旦松弛，地方就会裂开。

人从哪里来、谁来管住官：选官与监察的两千年

选官制度：从"看门第"到"看考卷"

官制要运转，先得有官。谁来当官，怎么选官，是比官位设置更根本的问题。中国的选官制度，大体走过这样一条路。把几个关键阶段放在一起看，演变的方向一目了然：

从这张表能看出，选官标准从"出身"一路走向"考试"，选拔权力从贵族、门阀逐渐收归中央。每一次选官制度的改变，都对应着政治权力格局的一次大洗牌。世卿世禄对应分封贵族，军功爵对应变法图强的君主，察举对应依靠地方豪强的汉王朝，九品中正对应门阀政治，科举则对应中央集权的成熟帝国。

西周和春秋时期，做官靠出身。诸侯、卿、大夫都是世袭的，父亲是大夫，儿子接着当大夫，这叫世卿世禄制。官职和土地、爵位一样，都是家族财产，普通人根本没有资格过问。

战国时期，各诸侯国变法图强，开始按军功和才能授官。商鞅变法时立下规矩：有军功者才能升爵，砍下敌人首级就能换爵位，贵族没有军功也要降等。这让秦国崛起的武人和士人挤进了官僚队伍，世袭的壁垒第一次被打破。

到了汉代，做官主要靠察举制。汉武帝元光元年（公元前134年），朝廷下令郡国每年举荐孝廉各一人，地方官把辖区内有德行、有才能的人推荐给朝廷，经考核后授予官职。察举科目的名目很多，孝廉、茂才（秀才）、贤良方正、明经、明法等等。这套制度运行了一百多年，解决了帝国初期的用人问题，但弊端也在积累：地方官推荐谁、不推荐谁，慢慢被地方豪强和世家大族操纵。民间流传的两句谚语说透了当时的乱象——"举秀才，不知书；举孝廉，父别居"，意思是推举上来号称有才学的人目不识丁，号称孝廉的人居然把父亲赶出家门。

魏晋时期，世家大族权力膨胀，选官权被门阀士族垄断。魏文帝曹丕采纳吏部尚书陈群的建议，实行九品中正制：由朝廷在各地设置中正官，负责评定本地士人的品第，分成上上、上中、上下等九个等级，作为朝廷授官的依据。中正官评定品第时虽然也说要看德才，实际起决定作用的是家世门第。西晋以后，中正官几乎都被世家大族把持，形成了一种极端的局面。西晋大臣刘毅上疏批评说：

"上品无寒门，下品无势族。"

也就是说，高等的官职永远轮不到寒门子弟，低等的位置也轮不到士族。九品中正制运行了三百多年，把社会等级固化到了极致，"上品无寒门"正是门阀政治的最好写照。这也是为什么隋唐必须用科举制来打破这个僵局。

科举制是这场选官革命的结果。隋文帝杨坚废除了九品中正制，先让各州向朝廷举荐人才、参加考试，隋炀帝时正式设立进士科，用考试来选拔官员。到了唐代，科举逐渐完备，唐太宗增加了科举的科目，武则天时期还首创了殿试和武举，唐玄宗时科举地位进一步提高。

科举和过去选官方式最大的区别，可以用一个词概括：机会向所有人开放。察举要靠地方官推荐，九品中正要看门第出身，科举则允许读书人"投牒自进"——自己去报名，凭考试成绩说话。考试的科目以进士、明经为主，进士科考诗赋策论，明经科考经义。虽然科举的录取率低得可怜，进士科一年通常只录取二三十人，但这条路确实让寒门子弟看到了改变命运的希望。

科举考试的层级和流程，在唐代以后逐渐固定下来：

1. 乡试（地方考试）：读书人在家乡所在的州县参加考试，通过者成为举人。
2. 会试（中央考试）：举人到京城参加礼部主持的考试，通过者称贡士。
3. 殿试（皇帝考试）：贡士到殿廷参加皇帝亲自主持的考试，通过者成为进士，前三名叫状元、榜眼、探花。

唐宋时期科举带来的社会流动是真实存在的。"朝为田舍郎，暮登天子堂"的传奇虽然夸张，却不再是不可能的事——考场上不看出身、只看答卷，寒门子弟第一次有了与世家子弟同场竞争的资格。更重要的是，科举把选官的权力从地方豪族手里夺回到中央。考中进士的官员感激的是皇帝，身份是"天子门生"，进入官僚系统后天然站在中央集权一边。科举制度从隋唐一直延续到清光绪三十一年（公元1905年），存在了大约一千三百年，是中国历史上生命力最顽强的制度之一。

科举的录取规模，在历朝有所不同。唐代进士科一年通常录取二三十人，加上明经等科，每年新入仕的科举出身者不过百人上下，在庞大的官僚队伍中只占很小一部分——唐代的官员，很多仍靠门荫、荐举入仕。到了宋代，科举录取人数大幅增加，一榜进士常有数百人，加上"特奏名"（对年老屡试不第者的安慰性录取），取士人数空前。宋代的科举真正成了普通人进入仕途的主要通道。明清时期，科举制度日益严格，会试三年一次，全国录取进士两三百人，乡试录取举人一二百人。科举的规模大小，也反映了一个王朝对选官渠道的开放程度——开得越宽，社会流动越大；关得越紧，阶层固化越重。

科举在漫长的运行中，也沉淀出许多细节。为了防范作弊，试卷实行糊名（把考生名字糊起来）、誊录（由专人把试卷重抄一遍，防止考官认出笔迹）等制度；会试由礼部主持，殿试由皇帝亲自主持并钦点前三名；除了进士科，还有明经、明法、明算、武举等科目。到明代，科举考试的内容日益程式化，作文必须按照固定格式——八股文。八股文格式严整，便于阅卷，却也把读书人的思想束缚在一定的框架里，成为后人批评科举"禁锢人才"的主要把柄。

不过，科举的影响绝不止于选官。它塑造了中国社会的一种独特秩序：读书、考试、做官，被看作最有出息的出路。"万般皆下品，惟有读书高"，读书人的地位由此抬升，社会围绕考试形成了完整的运作链条——私塾、书院、县学府学、乡试会试殿试，层层选拔，层层筛选。科举的录取率极低，绝大多数读书人一辈子考不上功名。但正是这种"人人有机会、人人都想考"的格局，让社会保持了长期的稳定——心怀不满的年轻人把精力投入考场上，而不是造反上。科举既是选官制度，也是一台社会稳压器。

科举并非完美。它重文才、轻实务，考出来的官员未必懂得治理水患、统兵打仗；它把人才选拔标准化，也把人的发展路径单一化了。到了近代，当西方已经建立起文官考试制度时，中国的科举却日益僵化，最终在1905年被废除。但无论如何，科举是人类历史上第一套系统化的、以考试为核心的文官选拔制度，它对世界的影响——包括现代公务员考试制度——至今仍在延续。

监察制度：皇帝怎么知道官在想什么

选官解决了"谁来做官"，接下来是"谁盯着官"。帝国再大，皇帝也只有一个人，不可能亲自监视全国的郡守知县。于是，一套专门的监察制度从秦朝开始建立起来。

秦朝设御史大夫，执掌监察，后来设立御史台作为专职监察机构。汉代承袭了这套体系，御史大夫（西汉后期称大司空）掌管御史台，负责弹劾百官；皇帝还另设司隶校尉，负责监察京畿地区。前面讲过的刺史制度，就是监察系统向地方的延伸——中央派刺史去监视郡守。

唐宋时期，监察制度进一步细化。唐代的御史台分设台院、殿院、察院：台院的侍御史监察百官，殿院的殿中侍御史纠察朝堂礼仪，察院的监察御史巡察地方。三院各管一摊，分工明确。宋代更进一步，把谏官和御史合并，称为台谏。御史管弹劾百官，谏官管规谏皇帝，台谏官由皇帝直接任命，品级虽低，却能"风闻奏事"——没有确凿证据，只要听到风声就能上章弹劾，连宰相也在其列。北宋名臣范仲淹、欧阳修、包拯都当过台谏官，包拯的"铁面"形象，很大程度上来自他弹劾权贵的御史身份。台谏制度的高明之处在于：它给皇帝提供了一条绕过宰相、直接监督整个官僚系统的通道。宰相再有权势，也怕台谏官参上一本。

明清时期，监察机构的组织达到最完备的形态。明代设都察院，作为全国最高监察机关，长官是左右都御史，下设十三道监察御史，分别对应全国十三个布政使司。都察院之外，还有六科给事中，对口监督六部，六部一道命令、一个人事安排，都要经过给事中审核——吏部要任免官员，得让吏科给事中知道；刑部要审结案件，得让刑科给事中核发。都察院的御史和六科给事中，一个管外，一个管内，合称"科道"，构成明代监察系统的两大支柱。

中央还定期派出巡按御史到地方巡视，号称"代天子巡狩"。巡按御史品级不高，只有正七品，但到地方后权力很大，可以弹劾地方官员、受理百姓控诉，地方官见了他要行礼参拜。清承明制，都察院继续存在，左右都御史、六科给事中、监察御史等职务一应俱全，还允许官员用奏折直接向皇帝密报，皇帝通过奏折掌握各级官员的一举一动。监察系统的规模，在清代达到了历史之最。

这里有一个耐人寻味的地方：古代监察官的品级普遍不高，权力却特别大。刺史六百石监二千石郡守，巡按七品官监督二三品的地方大员，台谏官五六品就能弹劾宰相。这不是设计者的疏忽，而是有意为之。品级低的官，本身没什么可失去的，不容易和地方大员结成利益同盟；反过来，他们的前途全系于皇帝，皇帝让他们弹劾谁他们就弹劾谁，用起来最顺手。监察制度挂着监督官员的名目，实际做的是替皇帝收集信息、打击不听话的大臣。

监察制度帮皇帝管住了官僚系统，也带来了新的麻烦。清代的御史制度虽然完备，但到了后期，御史们反而不敢说话、不愿说话——弹劾权贵怕得罪人，弹劾皇帝近臣怕惹祸上身，许多人沦为摆设，只在朝堂上站站班、举举手。制度再严密，一旦执行的人失去了勇气，也就名存实亡。

官员的定期考核，是监察的另一种形态。明代三年一朝觐，地方官进京述职，接受吏部考核；清代在此基础上形成"大计"与"京察"制度：三年一次大计考核地方官，按才、守、政、年四格评定等次，分出卓异、称职、平常、不谨等第，不合格的罢黜降调；三年一次京察考核京官，办法类似。考核等第直接关系升迁降黜，是悬在官员头上的又一把剑。可考核的尺度终究握在上级手里，实际运作中，走门路、拉关系往往比政绩本身更管用。清代官场流传"三年清知府，十万雪花银"的说法，也从侧面说明，考核对约束贪腐的作用十分有限。

明清两代，监察与特务渐渐混在一起，这是监察制度被扭曲的另一面。明朝的锦衣卫、东厂、西厂都是皇帝控制的侦缉机构，有权逮捕、审讯、用刑，锦衣卫的北镇抚司甚至有自己的诏狱。它们名义上也是"监察"，实际上凌驾于法律之上，制造了大量冤狱。东厂由太监统领，直接向皇帝汇报，权力甚至盖过都察院；锦衣卫则有自己的监狱、法庭，可以绕过正常的司法程序。皇帝用特务监视大臣，大臣也用特务互相倾轧，整个官僚系统笼罩在互相提防的氛围里。到了明末，内阁首辅和大臣们明哲保身、遇事推诿，朝廷上下弥漫着严重的信任危机。

监察制度还有一个更根本的局限：监察官也是官员，也需要被人监督。谁来监督监察官？最后还是皇帝。可皇帝也是人，精力有限、判断可能出错，甚至可能故意纵容。当皇帝自身贤明时，监察是整肃吏治的利器；当皇帝昏聩或故意纵容时，监察就可能沦为排除异己、打击政敌的工具。历史上的每一次党争——东汉党锢、唐代牛李党争、宋代新旧党争、明代东林党争——背后都有御史、给事中的身影。监察制度既可以是皇权的耳目，也可以是权力斗争的工具，这是它无法摆脱的两面性。

官制的两面：让天下听话，也让帝国僵化

把中央、地方、选官、监察四条线索放在一起看，中国大一统王朝的官制演变，有一条贯穿始终的逻辑：皇帝不断把分散的权力收拢到自己手里，又不断把集中的权力下放给官僚去执行，然后靠监察系统盯着他们不要反噬。中央的相权被一步步拆空，地方的郡守被一层层套上锁链，选官从门第世袭走到考试公平，监察从无到有、从简到密。

换个角度看，这套官制的演变其实很像一个反复上演的剧本。每个朝代的开国者都想解决前朝的弊端，于是大刀阔斧地改制度；制度改了，新的漏洞又出现，后人再补。汉朝觉得秦朝不分封宗室、有难无人相救，于是大封诸侯，结果郡国并行引发七国之乱；唐朝为加强中央对地方的控制设道、又因边防设节度使，结果藩镇割据比州牧更厉害；宋朝尝遍五代十国武将专权的苦头，拼命削地方、削兵权，结果把国家的武力也削掉了；明朝吸取元代宰相专权之祸，废丞相、设内阁，结果内阁变成了另一种宰相，还得靠太监来制衡。每一次修补，都是对前一次教训的回应，也都埋下了下一次危机的种子。制度的演进，就在这种"补丁摞补丁"的过程中一步步走到了明清。

这套系统一度运转得非常成功。靠着它，秦能征发数十万民夫修筑长城、动员大军征伐四方；隋能开凿大运河，唐宋能维持庞大的驿路；明清能管理几千万户人家的户籍和赋税。在交通、通讯都极其落后的条件下，一个中央政权能把命令传到千里之外的县城，把赋税从全国各地运到京城，这在世界历史上都是了不起的组织能力。历代王朝正是靠着这套官制，把分散的农业社会拧成一股绳，做出许多单靠地方力量做不成的大工程。隋朝的大运河、元明的海运河运、明代的万里长城防御体系，背后都是高度组织化的官僚系统在调配人力和物资。

官制还塑造了古代中国的社会分层。当官，是最受人尊重的职业。"士农工商"四民中，士排在最前面；读书人即使暂时没考取功名，也比普通农夫商贾高一等。科举更进一步，把"做官"与"读书"绑定起来，形成了中国独特的"士绅"阶层——那些考取过功名、或拥有功名背景的读书人，成了连接官府与乡村的桥梁。地方官要征税、办案、修路，离不开士绅的协助；士绅也借此获得社会地位和实际利益。可以说，官制不仅是一种政治制度，也是一套塑造社会秩序的文化制度，它的影响深入乡村，远不止于京城里的三省六部。

但官制也有它难以克服的另一面。集权带来的效率，往往与制度活力成反比。宋代的冗官、明代的党争、清代的文网，很大程度上都源于对权力的过度控制。皇帝把相权拆得太碎，政务就没人敢拍板；把地方管得太死，地方就失去应变能力；把监察织得太密，官员就只求自保。清代雍正帝设立军机处，把决策权彻底收回自己手里，是帝国集权的顶峰，也是这套官制走到尽头的标志。当一切都系于皇帝一人的能力和勤勉时，皇帝勤政则天下运转，皇帝懈怠则整个系统随之停摆。

中国官制的另一个深层矛盾是：它始终没有解决"谁来监督皇帝"的问题。宰相的废除、尚书台的兴起、军机处的设立，本质都是同一个循环：皇帝建立一套机构治理天下，机构慢慢坐大，皇帝再建立新的近臣班子取而代之，旧机构空壳化，新班子又慢慢坐大。制度的设计者们一次次试图用分权、制衡来约束权力，却始终把皇帝排除在约束之外。两千多年里，官僚制度越来越精密，皇权越来越集中，而集中到极点的权力，终究没能让任何一个王朝长治久安——这或许是这套制度最值得后人思考的地方。

资料来源

本文史实依据历代正史官制篇目，行文时逐条交叉核对；文中三处直接引文的出处已随文注明。主要依据如下：

• 司马迁《史记·秦始皇本纪》：秦确立皇帝制度，置三公九卿，废分封、行郡县
• 班固《汉书·百官公卿表》《汉书·武帝纪》：西汉三公九卿、尚书台、察举孝廉、十三部刺史
• 范晔《后汉书·仲长统传》：东汉尚书台代三公决政，"虽置三公，事归台阁"
• 房玄龄等《晋书·刘毅传》：九品中正流弊，"上品无寒门，下品无势族"
• 魏征等《隋书·百官志》《隋书·高祖纪》：隋废九品中正，草创三省六部之制
• 欧阳修等《新唐书·百官志》《新唐书·选举志》：唐三省六部、政事堂、科举科目
• 脱脱等《宋史·职官志》：宋二府三司、"官、职、差遣"分离与路制监司
• 宋濂等《元史·百官志》：元中书省、枢密院、御史台、行省与宣政院
• 张廷玉等《明史·职官志》《明史·宰辅年表序》：明废丞相、设内阁、地方三司与督抚
• 赵尔巽等《清史稿·职官志》：清内阁、军机处、督抚、理藩院与满汉复职
• 赵翼《檐曝杂记》：军机处"只供传述缮撰，而不能稍有赞画于其间"

通史与专题参考：钱穆《中国历代政治得失》、严耕望《中国地方行政制度史》。

从舍伯恩的理科生到研究计算的数学家

四十一岁去世，多年后才为公众熟知

1954 年 6 月 8 日清晨，英格兰柴郡威姆斯洛，管家在卧室里发现图灵已经去世，床边放着一只吃过的苹果。验尸结果显示死因为氰化物中毒。艾伦·马西森·图灵当时四十一岁。

今天，图灵常被称为“计算机科学之父”，他的肖像也印上了英国五十英镑纸币。1954 年时，公众几乎不知道他做过什么。战时密码工作仍属国家机密，他的理论论文主要在专业圈内流传。普通报纸能够查到的，反而是他两年前因同性性行为受到定罪的记录。

十二年前，图灵还在布莱切利园处理德军密电。他参与设计的密码分析方法和 Bombe，能够快速排除大量错误设置，帮助破译人员找出值得检查的候选。战后，他不能公开谈论这段经历。

半个多世纪后，英国政府才正式为当年的待遇道歉；2013 年，女王签署皇家特赦，2017 年生效的法律又把追溯性赦免扩大到更多因旧法获罪者。媒体把后一套安排称为“图灵法”。

这些经历很容易被压缩成一句话：一位破译密码的天才，后来遭到国家迫害。事实当然包括这两部分，但远不止这些。战争只是图灵工作经历的一部分。他还研究过数理逻辑、电子计算机、机器智能和生物形态。

这些课题表面上相距很远。图灵处理它们时却有一个共同习惯：先把问题说清，再把过程拆成可以检查的步骤。他问“计算”究竟指什么，也问怎样判断机器是否表现出了思考能力。晚年转向生物学后，他又用方程研究均匀组织怎样形成斑点和条纹。

他的故事要从学校讲起。那时还没有密码机和电子计算机，只有一个偏爱数学和实验、又经常不按老师要求写步骤的学生。

在帝国两端长大的孩子

1912 年 6 月 23 日，图灵出生在伦敦麦达维尔。父亲朱利叶斯在英属印度的公务员体系任职，母亲埃塞尔也来自长期与印度殖民行政相连的家庭。两人希望孩子接受英国教育，于是艾伦和哥哥约翰在英国由寄养家庭照料，父母则在英国与印度之间往返。

这种安排在当时的殖民官僚家庭中并不罕见。父母在海外任职，孩子留在英国读书。现有档案可以确认图灵与父母长期分居，却很难说明这段经历对他的性格造成了什么影响。

图灵童年时曾和哥哥寄居在圣伦纳兹滨海的沃德家，早期就读于 Hazelhurst School。留存下来的学校材料已经能看出他的兴趣。他喜欢数学和自然科学，也会自己做小东西。童年信件提到，他曾尝试制作钢笔。这样的细节只能说明他爱动手，不能据此把一个孩子写成已经预见电子计算机的“小发明家”。

图灵在学校里并不是各科成绩都很好的“标准优等生”。他喜欢数学和化学，也热衷自己做实验。拉丁文、整洁的书写和按要求完成作业，对他没有同样的吸引力。老师承认他有能力，也常批评他省略步骤，解释写得太少。

他经常重新推导课上已经讲过的结论。有时这会多花时间，也不符合老师规定的答题方式。但对图灵来说，自己推过一遍，比记住书上的答案更可靠。

1926 年，十四岁的图灵进入多塞特郡舍伯恩学校。开学时正值英国大罢工，铁路交通受到影响。学校后来经常讲到他从南安普敦方向骑自行车赶路、途中投宿，最后按时抵达的故事。不同资料对路线细节的说法略有差异，可以确定的是，他确实没有因为停运而放弃报到。

舍伯恩是一所重视古典教育的公学。图灵把大部分兴趣放在科学上，校方一度担心他学得太偏。把这段经历说成“保守学校压迫天才”并不准确：学校提供了实验条件和升学机会，只是评价学生时更看重古典课程、书写和规范。图灵在这些方面并不出色。

他会自己配制化学药品，也研究钟表、无线电和自然界里的数字关系。他做实验时不太讲究整洁，有时还会留下难闻的气味。比起学校重视的团队运动，他更愿意花时间摆弄这些东西。

在舍伯恩，图灵认识了比他高一级的学生克里斯托弗·莫科姆。这段关系深刻影响了他的少年时代。

克里斯托弗·莫科姆

莫科姆同样喜欢数学和天文，两人既交流功课，也讨论星空。图灵终于遇到一位愿意认真对待这些兴趣的同龄人。他对莫科姆怀有强烈感情，但没有向对方完整表白。

1930 年 2 月，莫科姆因牛结核病引起的并发症去世，年仅十八岁。图灵受到很大打击。此后，他与莫科姆的母亲保持通信，莫科姆之死也多次出现在他的信件和思考中。至于这场死亡如何影响了图灵后来的研究，现有材料不足以给出一条简单的因果关系。

他在信中讨论精神、物质、意识和自然规律。他希望相信人的某些部分能在肉体死亡后继续存在，同时又不愿接受违背科学的解释。人的心智究竟依赖什么，成了他反复思考的问题。

这些思考与他后来讨论机器智能有相通之处。不过，不能据此断言图灵研究计算是为了“把灵魂做成机器”。他的论文和书信都不支持这种戏剧化说法。能够确认的只是，从少年时代起，科学问题和他对死亡、心智的思考便同时存在。

图灵一直珍藏与莫科姆有关的记忆，也努力争取莫科姆原本想获得的奖学金。1930 年 12 月，他获得国王学院数学奖学金；次年秋季进入剑桥大学国王学院。大学的课程和评价方式更适合他的长处，他可以把主要精力用在数学上。

国王学院的学术气氛相对开放。当时，数学家正在争论数学基础问题；量子力学、逻辑和概率论也在迅速发展。图灵不再需要花力气解释自己为什么偏爱科学，只需拿出可靠的论证。

1934 年，他以一等成绩完成数学学位。1935 年 3 月 16 日，他凭一篇关于中心极限定理的论文当选国王学院研究员。他开始这项研究时，并不知道芬兰数学家林德伯格早已得到相近结果。因此，这篇论文不能算“世界首次”，但足以显示他的独立研究能力。

他在没有读过林德伯格论文的情况下，独立完成了相近的推导。这件事也说明，他习惯从问题本身出发，而不是先寻找现成答案。

从奖学金、本科到当选研究员，这条上升路径靠的是概率论和数学基础研究，而非后来使他成名的密码学或计算机；二十出头时，他首先是一名剑桥数学家。

什么叫“照步骤做”

1930 年代，数学界仍在讨论德国数学家希尔伯特提出的一个问题：能否找到一种确定的机械过程？无论输入哪一条形式化数学命题，它都可以判断该命题是否能够证明。这个问题通常被称为 Entscheidungsproblem，即“判定问题”。

十九世纪末到二十世纪初，集合论悖论让数学家重新检查数学基础。集合应当怎样定义？一套公理会不会同时推出某个命题和它的否定？这些争论没有妨碍日常计算，却使人们开始认真研究形式系统是否完备、是否一致。

希尔伯特希望把公理和推理规则写清楚，使证明成为可以逐步检查的符号操作。他在 1930 年演讲中说：“我们必须知道，我们必将知道。”这句话表达了他对形式化方法的信心。

同年，哥德尔的不完备性定理指出：足够强且一致的形式系统中，会有一些真命题无法在系统内部得到证明。不过，判定问题还需要更直接的回答。图灵和阿隆佐·邱奇分别研究了统一的机械判定程序是否存在。

要回答这个问题，必须先给“机械过程”下定义。声称某个问题有通用解法的人，需要把解法写成明确步骤；声称通用解法不存在的人，也需要说明自己谈论的“步骤”包括哪些操作。

图灵从一名正在纸上计算的人入手。他问：这个人一次能看到多少纸面？能记住多少种状态？每一步可以做哪些动作？这些条件一旦写清，“机械过程”就不再只是一个含糊说法。

这也是图灵机结构极为简单的原因。它只有纸带、方格、读写位置和有限状态。多余的机械部件不会帮助定义计算，反而会使论证更复杂。图灵要证明的是，这套简单模型仍能表示范围很广的算法。

这里的“机械过程”不要求真的制造一台金属机器。它更接近今天所说的算法：一名执行者拿着纸笔，只按明确规则一步步操作，不需要临时发挥。

当时，人们经常使用“按规则计算”这个说法，却没有对“计算”作出足够精确的定义。图灵接下来要做的，正是先把纸笔计算的每一步写清楚。

1935 年，拓扑学家马克斯·纽曼在剑桥讲授数学基础和判定问题。图灵没有直接从公式体系出发，而是继续分析一个人在纸上计算时会做什么。

人一次能看到的符号有限，能记住的状态也有限。每一步，他可以读取一个位置，写下一个符号，把注意力移向左边或右边，再根据当前状态决定下一步。图灵把这些动作写进数学模型，使“照步骤做”有了可以分析的形式。

1936 年，二十三岁的图灵提交论文《论可计算数及其在判定问题上的应用》。论文没有从一台真实机器开始，而是想象一条被分成方格的纸带、一个能够读写符号的扫描头，以及一张有限的指令表。后人把这种抽象装置称为图灵机。

这台抽象机器没有屏幕和键盘，一次只处理一个方格。所有操作都必须写进有限的规则表。图灵由此给“可计算”提供了一个精确模型，数学家可以据此讨论哪些任务能够由算法完成。

图灵机不是某台历史设备的施工图，而是一种关于“算法能做什么”的数学模型。

图灵接着证明，可以设计一台特殊机器。它把另一台机器的指令表编码成符号，和输入数据一起读入，然后模拟那台机器的全部动作。后人称它为通用图灵机。

原论文中有一句直接概括了这个想法：

“It is possible to invent a single machine which can be used to compute any computable sequence.”

— 艾伦·图灵，1936 年《论可计算数及其在判定问题上的应用》；论文所说的“一台机器”即通用机

也就是说，只要指令能够编码，同一台机器就能通过读取不同程序完成不同计算。现代电脑可以运行文字处理器、播放器和游戏，变化的是程序，硬件不必为每项任务重新制造。1936 年的论文不是现代电脑的工程图，但它在数学上说明了这种通用性。

图灵还证明，不存在一个通用的机械过程，能够判断任意机器在任意输入下最终是否会停下。原论文使用“circle-free”等术语展开论证。后来，计算理论把相关结果整理为著名的停机问题。

停机问题与机器速度无关，也不会因为硬件进步而消失。它说明，有些一般性问题没有适用于所有输入的判定程序。图灵在同一篇论文中既说明了通用计算的能力，也证明了这种能力有明确限制。

把这篇论文概括成“图灵发明了计算机”，会把它最锋利的部分磨掉。图灵首先给出的不是一台电子设备，而是一条能力边界：凡是能够机械执行的计算，都可以落进纸带、符号、状态和操作次序；同一个模型也能证明，有些问题无论机器多快都没有通用解法。

阿隆佐·邱奇几乎同时用 λ 演算得到相关不可判定结果，图灵提交论文时，邱奇的工作已经出现。两套形式表面差异很大：一套改写抽象表达式，另一套让读写头沿纸带移动，却能完成同样范围的计算。恰恰是这种独立方法的汇合，才让“有效可计算”不再像某位数学家随手挑选的定义。

图灵论文里的“计算者”不是今天坐在电脑前的人。英语里的 computer 原本可以指以纸笔执行计算的人，天文、航海、保险和工程机构都雇用过这样的计算员。他分析的是这类人严格照规则工作时，视线、纸面和记忆能够完成的动作。

“We may compare a man in the process of computing a real number to a machine which is only capable of a finite number of conditions...”

— 艾伦·图灵，1936 年论文第一节；这里比较的是按确定规则进行的纸笔计算

这句话有时被转述成“图灵说人就是机器”，但原文讨论的范围小得多。他分析的是一个人严格按照规则计算时的动作：某一时刻能辨认有限的符号，记住有限的状态，再按局部规则继续。

这个限定不能省略。图灵讨论的是算法能力，没有把爱情、意识和人的全部生活归入有限状态。任何被称为“机械”的计算步骤，都应当能够在模型中得到明确描述；如果不能，就要说明它还依赖什么。

后来的 Church—Turing thesis（邱奇—图灵论题）主张，直觉上能由有效机械过程计算的函数，正好是图灵机、λ 演算等模型能够计算的函数。它不是一条可以在模型外部单独证明的普通定理，而是受到多种独立形式体系支持的论题。

因此，不能把这个论题写成“图灵证明一切思想都能装进电脑”。可计算模型回答的是算法能做什么，不直接回答意识、道德、身体经验和社会关系等问题。

这段历史可以按下面的顺序理解：

1. 图灵把人的纸笔计算抽象为有限规则，为“可计算”建立数学模型；
2. 他再提出通用机，让一台机器能够读取并模拟另一台机器的说明；
3. 电子工程、存储器和程序设计随后把这种通用思想变成可高速运行的实体；
4. 现代计算机由许多理论家、工程师、机构和项目共同发展，图灵的模型是重要的理论来源之一。

把这四步混在一起，就会误以为图灵在 1936 年已经造出现代电子计算机。实际情况是，他先提出理论模型。电子工程师、程序设计者和不同机构随后解决了存储、元件、可靠性和实际编程问题。

在普林斯顿读博士

1936 年秋，图灵前往美国普林斯顿大学，跟随阿隆佐·邱奇攻读博士。普林斯顿当时聚集了许多研究逻辑和数学基础的学者。图灵研究数理逻辑，同时也对密码、电子装置和实际计算过程保持兴趣。

他的博士论文《基于序数的逻辑系统》研究怎样扩展形式系统，并在论证中引入了一种后来称为 oracle machine（神谕机） 的模型。这里的“神谕”不是会预言的机器，而是研究者暂时授予机器的一项答题权限：某一类问题，机器可以直接询问并得到“是”或“否”，至于答案怎样算出来，模型故意不管。

用一个后来常见的例子更容易看懂。普通程序无法写出一套对所有输入都有效的方法，判断另一个程序最终会停下还是永远运行。现在假定机器旁边有一个按钮：把程序和输入交给它，按钮立刻回答“会停”或“不会停”。这个按钮就是关于停机问题的神谕。研究者不是声称现实中已经造出了它，而是把它当成已知条件，再问：拥有这项额外能力后，机器还能解决什么？

答案仍然不是“一切”。对于能够调用这个停机神谕的机器，还可以构造更高一层、同样无法由它普遍判定的问题。神谕模型的用途正在这里：它让研究者比较不同难题的相对位置，说明“普通机器算不出”并不等于“所有不可计算问题同样难”。后来的归约和相对可计算性理论沿着这条路发展。

图灵很少满足于一句“办不到”。他会继续追问限制落在哪里：增加一种外部能力后，哪些问题变得可解，哪些问题仍留在边界之外？

这种研究习惯也适合工程工作。理论研究要求他严格定义“任何算法”，工程任务则要求他明确输入、状态、资源和输出。图灵后来可以在这两类工作之间转换，与这段训练有直接关系。

在普林斯顿，他还动手制作过二进制乘法器，并继续研究密码。1938 年取得博士学位后，他本可以留在普林斯顿，也可以返回剑桥。他最后选择回到英国。欧洲局势正在恶化，密码研究很快有了军事用途。

冯·诺依曼等人认可他的能力，留在美国并非没有前途。不过，也没有证据表明图灵回国时已经预见自己将在战争中承担什么角色。1938 年，他能看到战争风险，却不可能知道 Hut 8、Bombe 和之后的经历。

同年，图灵开始接受英国政府密码与密码学校的训练。不到一年，战争爆发。他此前研究的是抽象的计算步骤，接下来面对的则是转子密码机、每天更换的设置和必须尽快读出的军用电报。

布莱切利园、ACE 与机器智能

1939 年进入布莱切利园

1939 年 9 月 1 日，德国入侵波兰。两天后，英国对德宣战。9 月 4 日，图灵抵达白金汉郡布莱切利园，加入政府密码与密码学校。这里原是一座带有维多利亚式主楼的庄园。战争期间，园区不断扩建，增加了木屋、线路、机器和大量工作人员。

布莱切利园的工作依靠一条很长的流程。拦截站送来密文；登记人员整理呼号和时间；语言人员分析格式；数学家设计检验方法；工程师制造机器；操作员轮班运行设备；情报分析人员再决定哪些结果可以交给军方。图灵在其中负责重要环节，但破译从来不是一个人独立完成的。

这一点需要先说明。不少通俗作品把 Enigma 的破译写成了图灵个人的发明，省略了波兰密码学家、布莱切利园同事、工程师和操作员的贡献。

德军使用的 Enigma 看上去像一台装在木盒里的打字机。按下字母键后，电流经过插线板、多个转子和反射器，点亮另一个字母。每输入一次，至少一个转子会转动，于是同一个字母下一次可能被替换成完全不同的结果。收发双方只要按约定设置机器，就能加密和解密。

Enigma 的难点在于设置组合极多。转子顺序、初始位置、环设置和插线板连接可以产生大量可能性。德军还会更换密钥，海军通信程序又比许多陆空军网络严格。即使能够逐一尝试，速度太慢也没有情报价值。

这是现代博物馆藏品照，不是布莱切利园战时现场；四转子海军 M4 体现了潜艇通信后来增加的复杂度。

不过，密码系统仍有可以利用的规律。机器结构固定，操作员会形成习惯，军用电报也有常见格式，天气报告中还会反复出现一些词。Enigma 的反射器又带来一个重要特性：字母不会被加密成它自身。这些线索合在一起，可以排除大量错误设置。

破译人员不必一次猜中完整答案。他们先根据电报格式和机器特性提出假设，再用逻辑约束排除不可能的设置。图灵的工作，是把其中适合反复执行的检查交给机器。

波兰密码学家的先期工作

英国方面并非从零开始。战前，波兰密码学家马里安·雷耶夫斯基、耶日·鲁日茨基和亨里克·佐加尔斯基已经用数学方法重建军用 Enigma 的关键结构。他们还发展出穿孔纸页和名为 bomba 的机电装置。1939 年 7 月，波兰方面在华沙附近的皮里向英国和法国代表分享了成果。

这次交接为英法两国提供了重要基础。英国后来制造的 Bombe 并非波兰 bomba 的简单复制，面对的操作程序和通信网络也发生了变化。但若删去波兰密码学家的先期成果，直接说图灵一个人“发明了破解 Enigma 的办法”，就不符合史实。

波兰方面早在 1932 年已经读出 Enigma，1939 年又把机器知识和分析方法交给英法。英国早期研究组中，除了图灵和戈登·韦尔奇曼，还有迪利·诺克斯、托尼·肯德里克和彼得·特温等人。布莱切利园在 1940 年 1 月读出首批英国战时 Enigma 电文。这个时间线说明，突破来自多年积累，战争爆发后也没有立刻得到稳定结果。

图灵利用已知明文线索，也就是 crib，设计了新的逻辑搜索方案。破译者根据电报格式、上下文或操作习惯，推测某段密文可能对应哪些明文。天气电报会出现常用词，例行报告也常有固定开头。crib 只是供机器检查的假设，不是已经得到的答案。

Bombe 根据这些字母关系检查转子设置。某个候选一旦产生逻辑矛盾，便可以立即淘汰，无须先解出整封电报。Bombe 不是存储程序的通用计算机，也不会直接打印出完整德文。它是为搜索 Enigma 候选设置制造的机电设备。

剑桥同事戈登·韦尔奇曼提出“对角板”改进，使字母关系能够形成更强的相互约束，大幅提高搜索效率。英国制表机器公司的哈罗德·基恩带领工程团队把逻辑设计变成可以连续运行的设备。第一台英式 Bombe 于 1940 年投入使用，随后又建造更多。大量女性海军人员承担操作和维护轮班。

从截获密文到形成可使用情报，每一步都需要不同岗位；Bombe 负责缩小候选，不负责包办破译。

如果要把这套协作压成一组动作，大致是：

1. 拦截站记录无线电密文、时间、频率与呼号，持续描出德军通信网络；
2. 密码人员根据固定格式、重复习惯和上下文提出可能的明文片段；
3. 数学方法把明密文关系转成约束菜单，Bombe 快速筛除不可能的转子设置；
4. 操作员检查机器停点，用 Enigma 复现候选设置，再确认结果是不是有意义的德文；
5. 情报人员结合其他来源评估可信度，并以不能暴露破译能力的方式分发使用。

这套流程每天都要重复运行。图灵找出了适合机械化的检查步骤，其他岗位则提供密文、crib、机器、人工核验和情报分发。缺少其中任何一项，Bombe 都无法独立完成破译。

密文进入布莱切利园以前，设在不同地点的 Y-stations 已经完成无线电截收。即使某封电报暂时无法解读，这些资料仍可以帮助分析德军通信网络。电文被破译以后，语言人员要判断德文内容，索引人员把人物、地点和部队信息联系起来，情报人员再与其他来源核对。Bombe 只处理这条链上的一段，因此，机器运行次数不能直接等同于可供军方使用的情报数量。

布莱切利园还要控制谁可以看到什么信息。战时保密既防止德军得知密码已被突破，也限制不同部门之间的交流。一个岗位的人可能只了解自己负责的步骤，不知道前后流程的全部内容。战争结束后，这种分隔继续影响参与者的回忆，也使公众很晚才看到完整的协作规模。

读懂还不等于能立刻行动。若盟军每次都精准避开潜艇或截击运输，德军可能反过来判断密码已经失守。情报部门要把 Ultra 与侦察、俘虏口供等其他来源结合，有时还要安排看似独立的侦察行动，为军事决策制造一个不会暴露密码突破的理由。

这种做法称为保护情报来源。并非每条密电都足够可靠，也不是每次都能以最明显的方式采取行动。破译结果提供了重要信息，但指挥官仍需权衡作战目标、保密要求和其他情报。Ultra 并没有让盟军获得可以随意使用的全知视角。

Hut 8 与德国海军密码

图灵最重要的战时岗位之一，是参与建立并早期领导负责德国海军 Enigma 的 Hut 8。海军密码关系着大西洋航线。英国依赖船队运入粮食、燃料、军火和人员，德国 U 型潜艇则试图切断这条生命线。一封潜艇位置电报被及时读出，可能让护航船队改变路线；晚几天，它就只剩历史价值。

海军通信程序严密，密钥材料难得，网络也不断变化。图灵研究消息指示过程、可利用的重复和统计差异，发展出被称为 Banburismus 的方法。它使用打孔纸带比较密文，给某些假设赋予证据权重，帮助判断转子次序等候选，再把最值得检查的部分交给 Bombe。

“ban”以及更小的“deciban”后来被用来表示统计证据的强弱。它们帮助密码分析员决定，在机器时间有限的情况下，哪些候选值得优先检查。

Hut 8 也会利用缴获的密码本和气象船、潜艇上的材料。1941 年，皇家海军从 U-110 等德军舰艇取得密码设备和文件，为解读海军通信创造关键窗口。把一切归功于某台机器，同样会漏掉海上冒险、情报判断和密码材料管理。

1942 年 2 月，德国海军为大西洋潜艇启用四转子 M4 Enigma，盟军一度无法稳定读取相关网络，后来称这段中断为“鲨鱼黑障”。布莱切利园要修改方法和机器，盟军还必须取得新的短气象密码材料。直到当年年底，相关破译能力才得到恢复。

密码突破并非一劳永逸。德军会更换机器和操作程序，布莱切利园也要随之修改分析方法和设备。前一天有效的弱点，第二天可能已经消失。所谓破译能力，依靠的是持续的情报获取、技术调整和日常运行。

1941 年联名写信给丘吉尔

布莱切利园缺的不只机器，还缺熟练打字员、文书、操作员和能够处理特定任务的人员。常规渠道迟迟没有解决这些缺口，1941 年 10 月，图灵、戈登·韦尔奇曼、休·亚历山大和斯图亚特·米尔纳-巴里于是越过行政层级，直接写信给首相温斯顿·丘吉尔。信里催促解决的是人员和资源，而非又一道数学难题。

丘吉尔在信上写下著名批示：

“ACTION THIS DAY. Make sure they have all they want on extreme priority and report to me that this has been done.”

— 温斯顿·丘吉尔，1941 年 10 月对布莱切利园四人联名信的手写指示

“今日行动。确保以最高优先级满足他们的一切需要，并向我报告已经办妥。”资源随后加速到位。这封信说明，密码分析即使有可行方法，也仍然受人员、设备和行政安排限制。

没有操作员，机器无法持续运转；没有可靠 crib，Bombe 无从检查；情报分发若暴露了来源，还可能促使德军修补漏洞。布莱切利园的成果来自数学方法，也来自人员、工程和组织协作。

“拯救两千万人”的说法无法核实

常见文章称图灵“缩短战争两年，拯救两千万人”。这个数字属于反事实估计，无法像实际伤亡统计那样核实。历史学家不能重新进行一次“没有图灵的二战”，因此也无法精确计算战争会延长多久、伤亡会增加多少。

Ultra 情报确实对大西洋战役、北非、诺曼底登陆准备等行动产生重大影响，盟军高层也给予极高评价。图灵的海军 Enigma 方法、Bombe 设计与统计工作是其中的重要部分。但战争结果还取决于苏德战场、美国工业、雷达、护航体系、空中侦察、资源与无数人的行动。

更稳妥的说法是：图灵的工作对盟军密码情报十分重要，他在海军 Enigma 分析和 Bombe 逻辑中发挥了关键作用。与此同时，准确记录其他参与者的贡献，并不会削弱他的地位。

琼·克拉克与一段解除的婚约

图灵在布莱切利园结识了数学家兼密码分析员琼·克拉克。当时，女性的职位和薪酬受到明显限制，但克拉克仍承担了高级密码工作。两人一起下棋、讨论数学，关系很亲密。1941 年，图灵向她求婚，克拉克接受了。

图灵随后告诉克拉克自己会被男性吸引。按克拉克后来回忆，她没有因此立即否定婚姻；最终解除婚约的是图灵，他认为继续结婚并不诚实。两人此后仍保持友谊。这段关系里有感情，也有当时法律和社会禁忌带来的压力，不能简单概括成“骗婚”。

图灵在同事眼中有一些怪习惯。他把茶杯用链子锁在暖气管上，以免再次丢失；花粉季骑车时，他有时会戴防毒面具。他还长期跑步，达到了优秀业余长跑运动员的水平。这些轶事后来广为流传，也留下了他在论文之外的日常样子。

1942 年末，图灵前往美国，与美方密码机构交流海军 Enigma 和 Bombe 方案，也接触安全语音通信。回英国后，他在汉斯洛普公园与工程师唐纳德·贝利合作研制便携式语音加密系统 Delilah。设备能够演示，但没有赶在战争结束前投入实战。

Delilah 可以配合长波、短波无线电或电话线路安全传送语音。图灵与贝利在 1943 至 1945 年间留下了实验笔记，也做出了能够演示的原型；项目最终没有量产，因此不能把它写成战场上广泛使用的保密电话。它的意义在于显示图灵能够从纸面算法走到转子、继电器和电子信号，至于部署，则没有赶上战争结束。

1945 年战争结束，图灵随后因密码工作于 1946 年获授 OBE。授勋说明不能公开写明最重要的细节，他也不能自由地向新同事介绍自己的战时经历。此时，他已经开始考虑怎样制造一台通用电子计算机。

ACE 电子计算机方案

1945 年，图灵加入英国国家物理实验室，负责自动计算机项目。此时，电子计算已经在多条路线上推进。英国有为洛伦兹密码设计的 Colossus，美国有 ENIAC。冯·诺依曼参与整理的 EDVAC 报告讨论存储程序结构，大学、军方和实验室也在探索下一代设备。

图灵提交的 ACE（Automatic Computing Engine，自动计算引擎） 报告，把 1936 年的通用机思想与电子硬件联系起来。程序像数据一样存入高速内存，不必为每项任务重新接线。控制单元读取指令，可以根据中间结果跳转，也可以重复使用子程序。这是一份详细的存储程序计算机设计。

这份 1945 年报告题为 Proposed Electronic Calculator。图灵讨论的不只是机器由哪些部件组成，还包括程序怎样进入存储器、指令怎样安排，以及机器如何处理子程序。1936 年论文证明了一台通用机器在理论上能做什么，ACE 报告则必须面对速度、存储容量和电子元件。两个项目有关联，却处在完全不同的工作层面。

ACE 方案把输入、存储、控制、算术和输出连成通用电子计算流程。

图灵十分重视速度和内存使用。他设想用水银延迟线存储信息，以较小而快速的硬件执行复杂程序，并把一部分功能交给软件。这样一来，硬件不必为每项任务增加专用线路，程序可以通过不同组合完成更多工作。

不过，国家实验室的项目还要考虑工程风险、预算、保密规定和人员安排。NPL 没有按图灵原先设想迅速造出完整 ACE。他对进度感到失望，1947 年休假返回剑桥，1948 年离开 NPL。缩小版的 Pilot ACE 直到 1950 年才首次运行，后来成为当时速度很快的机器之一。

ACE 的延误不能只归结为“官僚毁掉天才”。电子计算机需要解决元件可靠性、采购、人员和保密等实际问题。不过，管理层对设计理解不足也确实拖慢了项目。图灵与 NPL 在工程路线和推进速度上存在明显分歧。

Bombe、Colossus、ENIAC 和 ACE 的区别

通俗叙述经常把同时代的几种设备混在一起。Bombe、Colossus、ACE、Manchester Baby，有时连美国的 ENIAC 也会被统称为“图灵电脑”。实际上，它们解决的问题和采用的结构都不相同，图灵与各项目的关系也有很大差别。

它们回答不同问题，工程结构也不同。分清这些设备，才能准确说明图灵参与了哪些工作。

Colossus 尤其容易被误写成图灵建造的机器。它针对的是德国最高统帅部使用的 Lorenz 电传密码，不是 Enigma。马克斯·纽曼提出把统计分析机械化，邮政研究站工程师汤米·弗劳尔斯带队制造电子设备，操作员负责日常运行。

Colossus 属于 Newman—Flowers 团队针对 Lorenz 的工程成果；它与图灵身处同一密码技术环境，但不能写成“图灵建造”。

图灵的一些统计思想影响了布莱切利园更广泛的工作，他也了解 Colossus 项目。但这些联系不足以支持“图灵发明了 Colossus”的说法。

美国的 ENIAC 使用大量电子管进行高速数值运算。它的体量、功耗和接线方式与 ACE 方案不同，程序最初需要通过插线和开关配置。它证明了电子计算的速度优势，同时也显示出重新设置任务需要付出很高成本。

这是真实 ENIAC 操作场景，用来呈现同代电子计算工程；它不是 ACE，也不是图灵参与建造的设备。

存储程序可以降低这种切换成本。程序编码进内存后，机器可以读取指令、跳转和修改数据，换任务时不必总重新连接大量电缆。EDVAC 报告、曼彻斯特计算机、剑桥 EDSAC 和 NPL ACE 都有各自的理论与工程来源。

现代计算机来自多条研究路线。逻辑学家研究什么可以计算；电子工程师解决开关速度和可靠性；军方项目要求更快制作弹道表；存储技术决定程序和数据怎样保存。把这一历史归于某一位“唯一父亲”，会遗漏大量关键工作。

曼彻斯特的存储程序计算机

1948 年，图灵转到曼彻斯特大学。这里由马克斯·纽曼等人推动的计算机项目已经让 Manchester Baby 在当年 6 月运行了存储程序。图灵到来后担任计算机器实验室副主任，参与后续 Manchester Mark 1 的程序工作，编写程序员手册，也继续研究机器能做什么。

Manchester Baby 的直接工程工作由弗雷迪·威廉斯、汤姆·基尔伯恩、杰夫·图蒂尔等人完成。图灵到校后加入的是已经能够运行程序的团队。他为后续机器编程，也研究数值计算。这段经历使他能在实际设备上检验算法，而不再像 Turochamp 那样完全依靠手算模拟。

时间顺序需要注意：Manchester Baby 在图灵正式到岗前已经运行，因此不能说是他单独造出了这台机器。曼彻斯特团队也不是简单复制 ACE。英国和美国的多个项目彼此交流，同时各自解决存储、可靠性和指令设计问题。

图灵既懂可计算性理论，也熟悉程序和机器结构。他知道，理论上能够完成一项任务，不等于程序很容易写。程序员仍要处理指令格式、内存布局、调试和运行时间。

他与经济学家、数学家大卫·钱珀瑙恩一起设计国际象棋程序 Turochamp。当时没有合适机器完整运行它，图灵就在 1952 年亲自拿纸模拟，每走一步要算很久，最终输给同事阿利克·格伦尼。程序输了棋，这场演示却赢得了另一层意义：算法可以把“选哪一步”写成评估规则，即使硬件暂时追不上。

在 1940 年代，让昂贵的电子计算机下棋看起来不够实用。不过，棋类规则明确，胜负反馈也清楚，适合测试机器能否比较局面、向前搜索并选择行动。图灵把它当作研究机器决策的实验问题。

从《智能机器》到“儿童机器”

1948 年，图灵在内部报告《智能机器》中讨论了神经网络式的“无组织机器”、训练和学习。他设想先构造一个类似儿童的简单系统，再通过教育改变它，而不是一开始就把全部知识写进程序。

二十世纪中叶的媒体常用“电子大脑”形容计算机。图灵的设想更具体。他区分了初始结构、教育过程和其他经验，并问：与其直接编写成人心智，能否先制造一个较简单的“儿童机器”，再训练它？

人类儿童并非出生时就掌握数学、语言和国际象棋规则。这些能力与环境、奖惩、模仿和交流有关。按照图灵的设想，机器的复杂行为也可以在训练中形成。程序设计者不必预先写出最终策略的每一个细节。

图灵还讨论了随机因素。随机变化可以帮助系统尝试不同方案，再通过反馈保留较有效的行为。这个想法会让今天的读者联想到搜索、强化学习和神经网络，但图灵当时并没有写出这些现代方法的完整算法。

他的重点是：机器的能力可以通过训练形成。这与 1936 年的图灵机并不矛盾。底层计算仍由确定的操作组成，程序却可以根据数据和反馈改变内部状态，设计者也未必能提前算出每个具体结果。

针对“机器只能做我们告诉它做的事”这一反对，图灵在 1950 年论文中写道：

“Machines take me by surprise with great frequency.”

— 艾伦·图灵，1950 年回应“机器不能产生新东西”的反对意见

“机器经常使我吃惊”不表示机器违反了程序。复杂规则的运行结果可能超出设计者的即时推演能力，程序错误也可能暴露此前没有意识到的假设。受规则控制的系统，仍然可能产生设计者没有预料到的输出。

今天的大型模型也会给出开发者没有预料到的回答。惊讶本身不能证明机器具有和人相同的意识；“它只是执行代码”也不能说明输出必然没有新信息。两种判断都需要更具体的证据。

“儿童机器”的设想还会引出责任问题。如果系统行为受到初始程序、训练材料、反馈方式和使用环境共同影响，结果就很难只归因于某一行代码。图灵没有使用今天的人工智能治理术语，但训练思想确实使程序设计的责任范围变得更广。

模仿游戏与《计算机器与智能》

1950 年，图灵在哲学期刊 Mind 发表《计算机器与智能》。文章开头直接提出一个问题：

“I propose to consider the question, ‘Can machines think?’”

— 艾伦·图灵，1950 年《计算机器与智能》开篇

“我建议考虑这个问题：机器能思考吗？”紧接着，他指出，“机器”和“思考”都很难通过日常用法得到严格定义。若只调查人们怎样理解这些词，讨论很快会陷入分歧。于是，他提出用一种模仿游戏代替原问题。

在文字通道里，提问者看不见另一端，只能靠回答判断对象。图灵讨论的原始游戏先涉及一男一女，再让机器替换其中一方，问提问者能否同样成功地区分。后来人们把相关思想简化为“图灵测试”。

模仿游戏通过文字对话比较行为表现，不负责测量意识本身。

这项测试没有声称“机器只要骗过人就拥有灵魂”，也不是衡量所有智能能力的统一标准。图灵关心的是可观察的证据。假如机器在文字对话中表现出通常被视为智能的能力，反对者还需要给出理由，才能坚持它完全不会思考。

他在论文中逐项回应了常见反对意见，包括神学观点、数学限制、意识论证、“机器只会照程序做”，以及神经系统连续而计算机离散等问题。有些回答今天仍有参考价值，有些则带有明显的时代局限。

图灵还作出过一个具体预测：大约五十年后，机器在五分钟文字问答中，会使普通提问者难以保持很高的识别准确率。结果会受任务设计、参与者和评判标准影响，因此不能根据今天某次聊天演示就断言预言已经应验。这段预测至少表明，他相信机器能力会随着工程进步而提高。

文章最后，他写下另一句更值得在人工智能热潮里反复读的话：

“We can only see a short distance ahead, but we can see plenty there that needs to be done.”

— 艾伦·图灵，1950 年《计算机器与智能》结尾

“我们只能看见前方一小段，却已经能看见许多必须去做的事。”图灵在这里没有宣布机器智能的问题已经解决。他承认预测能力有限，同时认为眼前已有许多具体研究可以开展。

1951 年，图灵当选英国皇家学会会士。三十九岁时，他已经在可计算性、密码分析、计算机设计和机器智能方面发表了重要成果。第二年，他又发表形态发生论文。也就在 1952 年，他的私人生活进入警方调查，并最终成为刑事案件。

形态发生、1952 年审判与身后平反

用数学研究生物的形状

1950 年发表机器智能论文后，图灵又转向了生物学。他研究的问题是：生物的形状是怎样形成的？ 这项工作与后来的审判同时发生，说明他在生命最后几年仍在开展新的研究。

受精卵不断分裂，早期细胞看上去很相似，后来却会形成头尾、肢体、皮肤纹路和器官。遗传信息本身不能直接说明空间结构怎样出现。图灵想知道，一片接近均匀的组织为什么会产生有规律的差异。

1952 年，图灵在英国皇家学会发表《形态发生的化学基础》。他设想两种或多种被称为 morphogens 的物质在组织中反应并扩散。如果它们扩散速度不同，又以特定方式相互促进或抑制，一个极小的随机扰动就可能被放大，最终形成稳定的斑点、条纹或周期结构。

他还使用曼彻斯特的计算机进行数值试验。机器可以根据方程反复计算不同条件下的浓度变化，帮助研究者观察图样是否出现。这并不表示计算机直接模拟了完整胚胎。图灵把真实发育过程简化为一组变量和方程，用计算结果检查这套机制是否可能成立。

论文摘要的第一句写道：

“It is suggested that a system of chemical substances, called morphogens, reacting together and diffusing through a tissue, is adequate to account for the main phenomena of morphogenesis.”

— 艾伦·图灵，1952 年《形态发生的化学基础》摘要

这里的措辞是“提出”一种机制。图灵没有宣称一组方程已经解释了所有胚胎发育现象。这个限定与今天阅读论文时的理解一致，也能避免把后来的“图灵斑图”宣传成万能公式。

这个结论不太符合日常直觉。扩散通常会减小浓度差，就像墨水进入水中后逐渐散开。图灵证明，在反应与扩散同时发生时，扩散也可能使原本均匀的状态失去稳定，最后出现有规律的空间图样。

反应—扩散模型展示的是形成图样的一种机制，不是对所有生物形态的单一答案。

这项工作与图灵早期研究使用了相似的分析方法。1936 年，他用有限状态和纸带描述计算；在布莱切利园，他把密码约束转成机器可以检查的步骤；1952 年，他又用局部化学反应和扩散解释复杂图样怎样出现。

图灵的兴趣并不限于计算机。他经常研究简单规则经过反复作用后会得到什么结果。计算、下棋、文字对话和胚胎组织属于不同学科，但都可以分析初始状态、局部变化以及一段时间后的结果。

图灵的模型没有直接解释斑马为什么有条纹，也不能替代基因、细胞力学和其他发育过程。后来的研究在一些化学和生物系统中发现了符合图灵机制的现象；另一些图样则由不同机制或多种机制共同形成。这套模型提供了一种可能的解释，不是生物形态的通用答案。

他还准备继续研究植物叶序。向日葵种子、松果鳞片和叶片排列常呈现螺旋，并与斐波那契数列有关。图灵尝试用数学和计算分析植物生长点怎样产生这些排列。他去世时，这部分工作仍未完成。

报案之后成为被告

1951 年末，图灵在曼彻斯特结识十九岁的阿诺德·默里。两人发生关系。1952 年 1 月，图灵位于威姆斯洛的家中遭窃，失去一些物品。他向警方报案，调查后来指向默里认识的人。

警方调查盗窃案时发现了图灵与默里的关系。图灵没有否认，承认两人发生过自愿的同性性行为。盗窃调查随后转向他的私人生活，原本的报案人成了刑事案件的被告。

图灵和默里被依据 1885 年《刑法修正法》第 11 条指控“严重猥亵”。这条法律处罚男性之间的相关性行为，不要求发生暴力，也不以受害者存在为前提。两个成年人是否自愿，在定罪逻辑中不能消除“犯罪”。

通俗文章常写“图灵因为是同性恋而被捕”。更准确的说法是，当时英国法律把男性之间自愿的同性性行为规定为犯罪，警察、检察和法院据此处理了图灵与默里的案件。

1952 年 3 月 31 日，两人在柴郡审判中认罪。图灵被判十二个月缓刑，条件是接受所谓 organo-therapy，也就是激素治疗。后来的文章常说，法官让他在“坐牢”和“化学阉割”之间二选一。这种说法概括了他面对的处境，但容易把量刑程序写得过于简单。

监禁是现实风险。为了避免入狱并继续工作，图灵接受了附带激素治疗条件的缓刑。治疗使用合成雌激素，持续约一年，导致乳房发育和性功能变化。今天常用的**“化学阉割”**一词指出了这种治疗强制改变性功能的性质，但它不是当时判决书使用的医学名称。

当时，这类激素疗程被当作治疗和矫正措施，也被视为监禁之外较“宽缓”的处理。图灵因此免于入狱，代价却是接受国家强制规定的身体干预。案件所涉及的是两个成年人之间自愿且没有受害者的行为。

一条从 1885 年沿用下来的法律

图灵受审所依据的第 11 条，常被称为 Labouchere Amendment。它在 1885 年《刑法修正法》审议后期加入，以含义宽泛的“严重猥亵”处罚男性之间的相关行为。它不仅适用于公开场所，也使私人空间内原本难以由旧条文覆盖的行为进入刑法。

条文没有列出每一种行为，给警察、检察官和法院留下了很大的解释空间。调查可以围绕书信、证人、住所和当事人的承认展开。奥斯卡·王尔德在 1895 年也曾依据这条法律被定罪。五十多年后，同一条文仍适用于图灵。

女性之间的同性性行为没有以同样方式写入这条刑法。这不表示当时社会承认女性的性自由，只说明立法者、医学界和行政机构对女性性行为采取了另一套看法和控制方式。

二战期间，这套法律没有停止执行。军队和情报机构在需要人才时可能对个别情况保持沉默，战后安全体系却越来越倾向于把同性恋者视为“容易受到勒索”的风险。图灵在战争中可以接触 Ultra，1952 年却因私人关系失去安全许可。

1954 年图灵去世后三年，英国政府委托的 Wolfenden 委员会报告建议，成年人私下自愿的同性行为不应继续属于刑法领域。报告提出一个后来影响深远的界线：刑法的任务不是执行全部私人道德。

建议又过了十年才部分进入法律。1967 年《性犯罪法》在英格兰和威尔士实行有限度的非罪化，适用于二十一岁以上男性的私下自愿行为。“私下”等条件仍然严格，苏格兰和北爱尔兰的改革时间也更晚。改革没有自动清除旧定罪，更不可能改变已经发生的人生。

从 1885 年到 1967 年，相隔八十二年。图灵案并非一次偶然的执法错误，而是这项法律长期运行的结果。到了电子计算机已经出现的年代，成年人之间自愿的同性行为仍可能受到刑罚。

写给朋友的三行推理

1952 年 2 月，案件仍在推进时，图灵写信给朋友诺曼·劳特利奇。信中有一段后来被反复引用的黑色幽默：

“Turing believes machines think
Turing lies with men
Therefore machines do not think”

— 艾伦·图灵致诺曼·劳特利奇，1952 年 2 月

“图灵相信机器会思考；图灵与男人同床；所以机器不会思考。”这不是有效的三段论。图灵用这种写法讽刺一种可能出现的反应：人们会因为他的私人生活，而否定他关于机器智能的观点。

图灵没有在信里把自己写成英勇殉道者。他说自己心情不好，也预感案件可能给“机器会思考”的观点带来麻烦。一个刚发表人工智能经典论文的人，已经在想象报纸和同行如何把“同性恋罪犯”与“机器思想”绑在一起。

定罪还影响了图灵的安全许可。战争期间，他可以接触最高等级的密码机密；战后，安全机构却把同性恋者视为容易受到勒索的风险。法律和社会偏见迫使人们隐瞒私人生活，安全机构又把这种隐瞒当成排除他们的理由。

他不能再像过去那样参与政府密码工作，出国也受到更严格注意。但曼彻斯特大学的职位没有因此消失，他继续研究数学与生物学，与同事交往，也出门旅行。把 1952 年到 1954 年写成每天都在绝望中等待死亡，同样缺乏证据。

现有材料表明，图灵承受了痛苦，也继续工作、旅行和安排未来。不能因为他后来去世，就把此前两年的每一次言行都解释成他早已决定自杀。

跑步与治疗带来的身体变化

图灵长期喜欢跑步。战后，他加入沃尔顿田径俱乐部，马拉松最好成绩约为 2 小时 46 分，达到了很高的业余长跑水平。伤病后来影响了他的训练，他没有继续向竞技方向发展。

他有时从布莱切利园跑去开会，也会在长距离训练中思考问题。没有必要把每一次跑步都解释成研究习惯。可以确认的是，跑步是他长期保持的爱好，也是他日常生活的重要部分。

激素治疗带来的身体变化因此对图灵有很直接的影响。他在通信中提到这些变化，有时用自嘲的方式谈论。国家以“治疗”为名干预了他的性功能，也改变了一个长跑者熟悉的身体。

治疗和定罪对图灵造成了严重伤害。不过，他在这段时间仍继续进行形态发生计算，也在规划后续研究。把 1952 年以后的他只写成一个立即崩溃的受害者，同样不符合现有记录。

1954 年 6 月与那只没有检测的苹果

1954 年 6 月 8 日，图灵被发现死于家中。调查确定死因为氰化物中毒，验尸官裁定为自杀，一般认为死亡发生在前一天。房间里有与化学实验相关的设备，床边还有一只吃过的苹果。后来，许多作品把这只苹果与图灵喜欢的《白雪公主》联系起来，称他像电影角色一样咬下毒苹果。

那只苹果没有接受氰化物检测。现有记录不能证明它沾有氰化物，也不能证明它与图灵的死亡方式有关。图灵确实熟悉并喜欢迪士尼《白雪公主》中的一些段落，传记作者也讨论过两者的可能联系。但法医材料没有确认他通过苹果摄入氰化物，更没有确认他有意重演电影情节。

关于死亡，至少要把下面几层证据分开：

• 确定程度较高：图灵死于氰化物中毒，官方调查作出自杀裁定；
• 现场事实：床边有一只吃过的苹果，但苹果没有检测是否含氰化物；
• 家属观点：母亲埃塞尔不接受自杀判断，认为可能是化学实验中的意外；
• 后世推测：《白雪公主》、有意安排象征或具体情绪动机，都缺少直接物证；
• 可以确认的范围：官方结论为自杀，事故说没有推翻这一结论，具体摄入方式仍不确定。

图灵没有留下能够明确解释死亡的遗书。官方调查认为他有意摄入氰化物；他的母亲认为他做电镀等实验时不慎中毒。后来的研究者还讨论房间通风、化学设备和调查标准。没有哪一种替代说法获得足以推翻裁定的新证据。

验尸调查使用了当时关于自杀的法定措辞，称他在“心智失衡”时服下毒物。这是调查结论使用的法律语言，不是对图灵长期精神状态的完整诊断。较稳妥的生卒日期写法是 1912 年 6 月 23 日至 1954 年 6 月 7 日，同时注明遗体在 6 月 8 日被发现。部分简历把发现日期写成去世日期，因而会出现一天差异。

因此，写作时应当保留两层信息：官方调查结论是自杀，死亡的具体过程并不完整。事故说没有足够证据推翻官方裁定，毒苹果的故事也没有足够证据成为确定事实。

毒苹果使这场死亡容易被记住，也很适合电影和海报。但它把尚未查明的细节写成了确定情节。对图灵之死保持谨慎，不是回避悲剧，而是尊重现有证据的范围。

还有一种流行说法称，苹果公司的标志是在纪念图灵。标志设计者 Rob Janoff 已否认这一说法，也没有其他直接证据支持。它与“图灵咬下毒苹果”的故事互相借力，所以很容易传播，但不应作为传记事实写入正文。

1954 年 6 月，图灵仍有尚未完成的形态发生和植物叶序研究。他的工作在四十一岁时突然中止，许多计划没有机会继续。

战时工作解密与公众重新认识图灵

图灵去世后，公众并没有立即了解他的战时作用。Bombe、Hut 8 和 Ultra 长期受到官方保密限制，参与者不能自由讲述，相关档案也未开放。1970 年代以后，随着资料解密和回忆录出版，布莱切利园的工作才逐渐进入大众历史。

保密有战后情报和国家安全方面的理由，也影响了图灵的声誉。他活着时不能公开说明最重要的战时贡献，去世后很多年，公众仍不知道他具体做过什么。相关资料公开时，他已无法亲自纠正误解，也无法说明各项成果来自哪些团队。

1966 年，美国计算机协会设立 A. M. Turing Award，后来成为计算机领域的最高荣誉之一。专业界已经开始确认图灵 1936 年论文的基础地位，但学术纪念并没有改变 1952 年的定罪记录。

1983 年，安德鲁·霍奇斯出版《艾伦·图灵传：谜》。这部传记同时讨论图灵的数学研究、战时工作、同性恋身份和所处时代，显著影响了公众此后对他的认识。

进入二十一世纪，要求官方道歉与平反的呼声不断增长。2009 年，程序员约翰·格雷厄姆-卡明发起请愿，数万人签名。政府道歉、皇家特赦与面向更多历史案件的法定安排，下一节会具体说明。

2009 年道歉、2013 年特赦与 2017 年法律

2009 年政府道歉表达的是今天的国家立场。时任首相戈登·布朗在请愿引发的公开声明中写道：

“So on behalf of the British government, and all those who live freely thanks to Alan’s work, I’m very proud to say: we’re sorry, you deserved so much better.”

— 英国首相戈登·布朗，2009 年 9 月

布朗在声明中说：“我们很抱歉，你本应得到好得多的对待。”道歉承认图灵所受待遇骇人而不公，但政治声明不会自动改变法院档案，也不会撤销历史定罪。

2013 年皇家特赦使用的是 mercy，即宽赦。它修复了定罪造成的部分名誉后果，却不是上诉法院重审案件后认定原判在当时适用法律有误，也不表示案件从未发生。图灵获得的是死后 free pardon，不能简单写成“英国宣布他无罪”。

批评者指出，如果相关行为今天根本不构成犯罪，由王室向死者施以“仁慈”仍把国家放在施恩者的位置。支持者则认为，特赦对图灵的个人名誉和公共教育仍有实际作用。这场争议也推动人们把注意力转向其他历史案件。

2017 年的法律安排覆盖了一类历史案件。符合条件的死者获得法定追认特赦；仍在世者需要通过 disregard 程序，使符合条件的旧定罪在记录和披露中被忽略。适用范围带有条件，因为某些旧罪名包含的行为若发生在今天仍可能违法，例如非自愿行为或涉及未达到现行同意年龄者。

因此，“图灵法”并没有把所有同名罪行的历史档案全部删除。它要根据今天的法律重新判断具体行为是否仍构成犯罪。判断标准是行为本身，不是当事人后来是否取得重大成就。

三次处理各有不同作用：

1. 政府道歉承认国家在道德和政治上的责任；
2. 皇家特赦针对图灵个人，以宽赦方式修复名誉；
3. 法定追认与 disregard面向更多人，在一定条件下处理历史定罪记录。

把这三项措施合称为“英国后来平反了图灵”，容易使人误以为它们具有相同法律效力。实际上，道歉表达立场，特赦处理个人名誉，2017 年法律则为更多案件建立了适用规则。

媒体把 2017 年的这套安排称为**“图灵法”**。一些活动人士仍批评它的适用条件和覆盖范围，但与个人特赦相比，它至少把更多因旧法受到惩罚的人纳入了制度处理。

道歉、个人赦免与面向更多历史案件的法定安排，分别解决了不同层次的问题。

这段变化并不是社会自然进步的结果。它经历了长期倡议、法律改革、请愿和公共讨论。1952 年的法律也曾被许多人视为正常秩序，因此，合法并不能自动证明一项制度没有造成伤害。

五十英镑上的图灵

2021 年，印有图灵肖像的新版英国五十英镑纸币进入流通。纸币上还印有数学公式、早期计算设备的图像，以及他在 1950 年论文结尾写下的那句话。一个曾经因同性性行为留下犯罪记录的人，如今出现在国家货币上。这种变化说明英国社会对他的评价已经完全不同。

纸币能够让更多人知道图灵，却也容易把他的经历处理得过于整齐。公众看到的是严肃的肖像、公式和机器。纸币不会告诉人们，他在学校里经常省略解题步骤，曾把茶杯锁在暖气管上。它也不会提到案件审理期间，他写给朋友的那段三行推理。纪念物保留了一个人的名字，却无法代替完整的传记。

图灵的名字也经常出现在人工智能新闻里。一个聊天系统在短时间内让评委判断错误，报道便称它“通过了图灵测试”，甚至进一步宣布机器已经会思考。1950 年的论文没有提供这样一个简单的认证标准。图灵借助模仿游戏讨论行为证据，又花了大量篇幅回应意识、数学限制、学习和神经系统等反对意见。一次演示不能代替这些问题。

类似的简化也发生在其他成果上。图灵机是数学模型，不是一台早期电脑的实物；Bombe 是搜索 Enigma 候选设置的专用设备，不是自动翻译德军电报的机器；反应—扩散方程提供了形成生物图样的一种机制，也不是可以解释所有条纹和斑点的“斑马公式”。把名称放回原来的问题，才能看清图灵实际完成了什么。

怎样理解他的贡献

“计算机之父”是最常见的称呼。它表达了图灵在计算机史上的重要地位，却容易使人误以为现代计算机由他一人发明。1936 年，他建立了可计算性的数学模型，提出通用机，并证明某些一般性判定问题不存在通用算法。这些成果影响了后来计算机的理论结构，但它们还不是电子计算机的施工图。

图灵后来确实参与了实际机器工作。在布莱切利园，他把密码分析中的一部分逻辑检查交给 Bombe；在 NPL，他提出详细的 ACE 方案；到曼彻斯特后，他又编写程序、程序员手册，并研究机器下棋。理论和工程在他的经历中紧密相连，但每一项工程都由团队完成。

图灵经常把范围很大的问题变成具体的研究对象。他用纸带、符号、状态和操作步骤说明什么是计算。讨论机器思考时，他让参与者比较文字对话中的表现。研究生物图样时，他写下反应和扩散方程。这些做法没有结束原来的争论，但其他研究者可以据此证明、实验和反驳。

他也很少只谈机器能做什么。通用机说明一台机器可以模拟范围极广的计算过程，停机问题同时说明有些判定程序根本不存在。模仿游戏提供了一种观察机器行为的办法，但没有证明意识问题已经结束。形态发生模型能产生图样，却只解释发育过程中的一种可能机制。这些限定本身就是他研究成果的一部分。

布莱切利园的经历还说明，机器总在具体流程中工作。人先提出 crib，Bombe 才能检查候选。操作员随后复核结果，解出的电报还要经过分析和安全分发。自动化会重新安排各岗位的任务，并不会让人的判断和责任一起消失。今天使用人工智能系统时，也要说明训练材料来自哪里、谁复核输出、失败后由谁负责。

不能只把他当作天才或受害者

图灵常被同时称为天才、战争英雄、受害者和人工智能先驱。这些称呼都有事实依据，单独使用时却会漏掉其他部分。只讲天才，会淡化同事和工程团队；只讲战争英雄，会使人误以为他一生只做过密码分析；只讲受害者，又会遗漏他在 1952 年后继续进行的生物学研究。

他的日常生活也不符合一张单一标签。他能完成高度抽象的数学证明，也愿意制作电子装置；会长距离跑步，会下棋，也会在信中开冷笑话。他与克里斯托弗·莫科姆、琼·克拉克和阿诺德·默里的关系各不相同。把这些人全部删去，只留下一个孤独天才，会让传记看起来更戏剧化，却离真实人物更远。

1952 年的案件不应因为被告是一位有功科学家才被认为错误。即使图灵没有参与 Enigma 破译，没有发表 1936 年论文，只是一名普通职员，两个成年人自愿的私人关系也不该受到这样的刑罚。2009 年的道歉和后来的法律改革，最终把问题推向了更多受害者。人们开始讨论的，不再只是国家是否亏待了一位“有用的人”，还有那套法律怎样伤害了所有受它处罚的人。

图灵去世时四十一岁。他已经完成了可计算性论文，参加过战时密码工作，写过 ACE 设计和机器智能论文，也刚开始深入研究形态发生与植物叶序。最后一部分工作没有完成。床边的苹果因为没有接受检测，不能说明他具体怎样摄入氰化物；任何后来补上的象征，都不能使这段记录变得更确定。

他没有机会看到 Pilot ACE 后来的应用，也没有看到机器学习成为独立研究领域。身后的声誉越来越高，未完成的研究却无法继续。

因此，讲述图灵的一生，不需要再为那只苹果安排一个寓意。能够确认的内容已经足够：他提出了一些至今仍在使用的问题和模型，也受到当时法律的严重伤害。前者不该掩盖共同工作的其他人，后者也不该把他余下的生活全部改写成等待死亡。把这两方面同时写清，已经比任何传奇式结尾更接近他真实的四十一年。

资料来源

• Alan Turing, “On Computable Numbers, with an Application to the Entscheidungsproblem”, Proceedings of the London Mathematical Society, 1936.
• Alan Turing, “Computing Machinery and Intelligence”, Mind, 1950.
• Alan Turing, “The Chemical Basis of Morphogenesis”, Philosophical Transactions of the Royal Society B, 1952.
• The Turing Digital Archive, King’s College, Cambridge.
• Alan Turing: The Enigma, Andrew Hodges maintained reference site and archive guide.
• M. H. A. Newman, “Alan Mathison Turing, 1912–1954”, Biographical Memoirs of Fellows of the Royal Society, 1955.
• 10 things to know about Alan Turing, Bletchley Park.
• Enigma 与 6 facts about the Bombe, Bletchley Park.
• Alan Turing and the development of computing, National Physical Laboratory.
• Alan Turing and Manchester, University of Manchester.
• The Papers of Alan Mathison Turing, King’s College Archive Centre catalogue.
• The Turing Papers, The National Archives.
• The strange death of Alan Turing, The National Archives.
• Policing and Crime Act 2017, Part 12, Chapter 1, UK Public General Act.
• Gordon Brown, “Treatment of Alan Turing was ‘appalling’”, UK Government Web Archive, 2009.
• Royal warrant granting Alan Mathison Turing a posthumous free pardon, The London Gazette, 2013.
• The new £50 note, Bank of England.

一间木屋如何变成整个世界

2009 年 5 月，一块草地铺在浏览器窗口里。远处没有主线任务，没有配音，没有过场动画，甚至没有一张正经的新手地图。鼠标按住一个方块，表面裂开，随后消失。地上留下一个规整的洞。再按一下，洞变深。玩家低头，第一次意识到：脚下那片看似固定的地面，其实也可以被编辑。

这就是 Minecraft 最早的魔力：玩家看见世界的同时，也发现它没有焊死。

今天回看，那一幕简陋得近乎寒酸。官方后来开放的 Minecraft Classic 只保留了 32 种方块和早期版本的旧缺陷。它不像一件准备发布的商品，更像程序员 Markus Persson 周末写出的可玩草稿。可正是草稿感，让玩家没有把屏幕当布景，而把它当材料仓库。

先挖一个洞，再把挖出的东西垒成墙。破坏与创造不是两套系统，而是同一个动作的正反面。传统游戏把“世界”放在舞台后面，Minecraft 则把舞台拆成一块块可以搬走的木板。

十七年后，这套动作仍没有过时。Minecraft 官方的十五周年页面把 2023 年的销量里程碑写成 3 亿份；YouTube 在 2024 年公布，与 Minecraft 有关的视频累计观看超过 1.5 万亿次。数字大到失去触感，但它们都起源于同一个小动作：敲掉一块土，再决定把它放到哪里。

这篇文章不是一份入门教程，也不是版本编年史。我们要追问的是：一个画面粗糙、规则松散、长期处于“还可以再加一点”状态的游戏，为什么没有被自己的年代困住？它如何从私人玩具变成一种公共空间？而当越来越多人在里面工作、赚钱、交朋友、上课和长大时，谁有权决定这片世界的规则？

先把几个容易混在一起的节点拆开：

时间线看起来像一路向上的胜利史。实际过程更像一座不断加盖的老城：每次扩建都要绕开旧房子的地基，每次铺设新管线都可能碰到居民自己拉的电缆。Minecraft 一直有冲突，只是多数冲突没有把老城变成无法居住的工地。

先卖一个未完成的世界

Minecraft 并非凭空出现。Persson 在早期访谈里谈到过 Infiniminer 的块状视觉，也谈到 Dwarf Fortress 的世界感。前者让他看到低分辨率立方体的直接，后者让他迷上由系统自行生长的复杂性。它们在 Minecraft 里相遇：一边是孩子也能看懂的积木，一边是深得没有底的规则组合。

Game Developer 的 2010 年访谈记录了一段关键判断：低细节画面会把一部分工作交给玩家的想象，而且适合小团队快速制作。它首先是现实约束，后来才被玩家读成美学。一个人没有能力雕刻每片叶子，于是把树压缩成棕色柱子和绿色方块；没有能力写完宏大剧情，于是让昼夜、怪物和资源自己产生故事。

最初的节省后来变成了优势。高精度画面擅长告诉你“这是什么”，方块画面更擅长问你“你要拿它做什么”。

游戏公开几周后便开始收费。那时它远没有完成，购买更像为一个正在生长的想法投票。早期玩家得到新版本，也在论坛里报告缺陷、展示建筑、提出愿望。开发者则从真实使用中挑选下一块要补的拼图。产品路线并非只从办公室向外发布，也从玩家的洞穴、城堡和抱怨倒流回来。

Persson 后来对《时代》说：

“I designed the game for myself—that’s an audience I know.”

“我为自己设计游戏——至少这个受众，是我了解的。”——TIME，2013

这话听着像独立开发者的真诚，实际也缩短了决策链：作者不必先证明一个抽象市场存在，只要先做出自己愿意反复玩的东西，再让愿意付钱的人靠近。收费因此成了继续开发的燃料，不必等到作品完成后才作奖章。

今天再看，抢先体验、公开路线图、社区投票早已成为行业词汇。但 2009 年的 Minecraft 已提前暴露了这套方法的诱惑与风险。用户愿意宽容粗糙，因为他们能感到自己的意见正在改变产品；参与也会生成所有权感。玩家买的不再只是一个版本，还包括“我们一起把它做出来”的记忆。

后来每一次平台政策变化，都会撞上这份记忆。公司从法律上拥有游戏，玩家却在情感上拥有自己的世界。二者长期重叠，却从不完全相同。

方块不是画风，是一种语法

一棵写实的树，通常只能是树。Minecraft 里的树同时是木板、木棍、工具柄、燃料、房梁、箱子、船和一段通往地底的梯子。它看起来更简单，实际承担的动词更多。

方块首先降低了识别成本。轮廓清楚，材质重复，网格统一。孩子不必理解三维建模里的拓扑、法线和材质节点，只要知道某个立方体能不能挖、会掉出什么、能和什么组合。世界的复杂性被折叠进一套有限词汇，像学习字母，而不是先背整本词典。

其次，方块让尺度可数。两格高能过人，一格宽是门口；九块麦田中间放水，照明要覆盖到哪里，桥要跨多少格，玩家可以用脚步和方块估算。建筑不再只是审美对象，也是一组能被复述的操作：“向前七格，左转，垒三层。”教程因此天然可传播。

更重要的是，世界与编辑器使用同一种材料。很多游戏也附带地图编辑器，但编辑器在主菜单里，创作发生在游玩之外。Minecraft 把编辑器藏进生存：你想建屋，先要砍树；想铺铁路，先要下矿；想让大门自动开合，先要理解红石。创作因此与风险、时间和路线绑在一起，没有无成本的拖拽。

建筑于是有了传记。一座歪斜的木屋之所以珍贵，不是它比网上的宫殿漂亮，而是屋角那两块泥土见证了第一夜材料不够；地下仓库的位置，是当年苦力怕炸出的坑；城墙缺口旁的告示牌，写着某位朋友第一次登录服务器的日期。

低保真也给模仿留下余地。写实城堡把作者技巧暴露得一览无余，容易让新手退缩；方块城堡的窗、墙、垛口都可以拆成小步骤。别人先照着搭，再把塔楼改高，把石头换成木头，最后学会一种自己的比例。可模仿，是大众创作的入口；可变形，才是创作生态的开始。

所以“像积木”只说对一半。现实积木的零件在盒子里，Minecraft 的材料散落在危险的世界中；现实积木不会在夜里长出怪物，也不会因为岩浆烧掉一箱成果。它在积木上叠加了时间、损失和不确定性，才让“摆放”变成“建设”。

第一夜为什么总能成立

新玩家出生时，世界没有礼貌地等他读完说明。太阳已经在移动。树叶沙沙响，羊在坡上走，远处的洞口黑得像没有加载完。白天的颜色很软，时间却在偷偷收紧。玩家很快学到第一条并非写在界面上的规则：黑夜会来。

一场典型的第一夜，往往只有几步：

• 徒手打下一块木头，把原木变成木板，再做出工作台；
• 用木镐挖石头，把效率低得可怜的工具换掉；
• 找煤，或者烧木炭，给黑暗划出一小圈安全边界；
• 在天完全黑之前决定：继续找羊做床，还是挖进山里封门；
• 听见墙外的脚步声，第一次把“自己的房子”与“外面的世界”分开。

短短几步，Minecraft 的基本价值已经露面。资源不是分数，是未来行动的可能；工具不是奖杯，是缩短劳动的杠杆；房子不是装饰，是玩家对空间做出的第一项制度安排——这里由我照亮，这里暂时安全，这个箱子里的东西属于明天。

第一夜的节奏很少见：目标明确，解法不唯一。你可以挖洞、垒墙、爬树、连夜赶路，或者赌一次没有怪物靠近。系统只规定压力，不指定表演。不同玩家会在同一个夜晚暴露不同性格：有人囤积，有人冒险，有人把门做得对称，有人宁愿住土坑也要先找钻石。

第一夜之后，压力并未消失，只是逐渐被玩家转化成秩序。农田解决食物，围墙解决路径，床跳过夜晚，铁甲降低战斗风险。每解决一项麻烦，就会腾出注意力制造更大的麻烦：房子够住了，为什么不盖一座塔？手工收割太慢，能不能让水流代劳？村庄安全了，要不要修一条通往朋友家的铁路？

于是游戏形成四层相互套叠的循环。生存提供紧迫感，建造把资源变成表达，自动化把重复劳动变成系统，联机再把系统变成分工和故事。玩家可以停在任意一层：有人只爱极限生存，有人切到创造模式盖建筑，有人研究每小时产量，有人把服务器当长期社区。

这里没有唯一通关路径，只有一组可自由换乘的生活方式。

官方当然放进了末影龙和字幕意义上的“终末”。但击败它并不会把玩家赶出世界。传送门把你送回出生点，仓库仍在那里，未完工的桥仍缺三组栏杆。结局更像一个逗号：它证明你曾完成一次远征，却没有替你决定什么时候离开。

黑暗为何不只是惩罚

第一夜还有一半机制不在方块里，而在声音里。木镐敲石头的节奏稳定，脚踩草地和碎石的声音不同，熔炉燃烧发出低低的噼啪。然后音乐停了。洞穴深处偶尔响起一段没有明确来源的环境声，玩家明知可能只是系统效果，还是会回头看一眼。

音乐留下的空隙，让独处有了重量。许多游戏用持续配乐指挥情绪：战斗时加速，安全时舒缓，剧情时提醒你该感动。Minecraft 的音乐常在没有通知的时刻进入，又在你意识到之前离开。它不替玩家宣布“这里重要”，反而让挖矿、望海和整理箱子这些无剧情动作获得自己的时间。

昼夜则把视觉与听觉组织成一个呼吸。白天，视野打开，斧头和羊叫构成劳动背景；傍晚，天空变暗，玩家开始数火把、关门、确认床的位置；夜里，箭撞墙和怪物呻吟把屋外变成看不见的压力。清晨到来时，燃烧的僵尸不是一场宏大胜利，只是一种日常秩序重新生效。

正因昼夜和危险存在，创造模式与生存模式即便使用相同方块，建筑的感受仍不同。创造模式里，材料随取随用，飞行让尺度变小，夜晚可以一键跳过；生存模式里，每一叠石头都来自路线和工具损耗，高处施工有坠落风险，照明不足会把作品变成刷怪场。前者像画室，后者像工地。

两种模式没有高下。画室让人把注意力放在比例、颜色和想象，工地让作品携带资源史。许多玩家先在创造模式试样，再回生存服筹料施工；也有人在生存世界完成大工程后复制存档，飞到空中第一次看见全貌。自由创作与有成本的创作并非敌人，它们给同一个念头赋予不同重量。

黑暗还创造了家的概念。若世界始终明亮，墙只是造型；正因为墙外存在看不见的危险，一扇门、一张床和几支火把才构成边界。等玩家装备精良、能够轻易对付怪物后，家不再是生存必需，却已经变成返回坐标。机制先制造避难所，记忆再把避难所变成故乡。

随机世界，私人记忆

Minecraft 的地图依靠程序生成。输入同一个种子，在相同版本与条件下，山脉、河流和村庄可以重现。种子像世界的压缩地址：一个短字符串，展开后却是远超肉眼一次看完的地貌。

程序生成常被宣传为“无限内容”。这个说法太轻巧。随机性本身并不保证有趣，噪声可以生成一万座无人关心的山。地形只有与玩家行动咬合之后才有意义。你家的位置，正是你在一片偶然地貌中做出的选择，并非策划预先布置的主角宅邸。

也许出生点旁有一道峡谷，你用木桥跨过去；也许第一处钻石在熔岩湖边，让你后来每次下矿都多带一桶水；也许朋友执意把主城盖在沼泽，十个月后那片原本不讨喜的灰绿色，反而成了所有人共有的故乡。随机负责制造陌生，劳动负责把陌生变成熟悉。

老存档因此格外敏感。对开发者来说，存档是一批区块数据；对玩家来说，它是按空间排列的时间。新版本若改变地形算法，旧区块与新区块的边界可能像刀切一样突然断开。性能优化若破坏红石时序，机器会停；生物机制若变化，运营几年的农场可能报废。

2021 年，Mojang 把“洞穴与山崖”更新拆成两部分，公开解释质量、性能、技术复杂度与团队健康。公告里有一句很克制的话：

“not wreak havoc on your meticulously crafted worlds.”

不要在那些被你精心塑造的世界里“大搞破坏”。

承诺触及长青游戏最难的一层：更新的对象不是空白硬盘。它必须穿过玩家已有的房屋、机器、路线、模组和回忆。新地形越壮观，兼容旧世界的工程就越沉重。开发团队一边要证明游戏仍在生长，一边又不能让生长像拆迁。

第二部分最终扩展了世界的垂直尺度。以基岩版官方说明为例，建造范围来到 Y=-64 至 Y=320，比过去多出一半垂直空间。新的山更高，洞更深，矿物分布也随之变化。多出的 128 格不只是空间增量，它重新安排了玩家用了十年建立的“地底常识”。

好的更新不会让旧经验全部作废，而会让经验出现新的边缘。你仍知道火把、镐和水桶的价值，却必须重新学习在哪个高度寻找矿物、如何穿过巨大洞穴、怎样在山体间修路。熟悉感给人回来的理由，陌生感给人再住一晚的理由。

红石：把玩具翻到背面

如果建造只关乎外观，Minecraft 可能会成为一款规模更大的数字积木。红石改变了这条命运。它让方块不仅占据空间，还传递状态。

拉下一根拉杆，红石粉亮起，活塞推出，门移开。最初只是一个机关。玩家很快学会加上中继器控制距离，用比较器读取容器状态，用观察者捕捉方块变化，再把信号送往另一组机器。看似神秘的自动农场，其实是传感、逻辑、执行和回收被摆在地上的组合。

官方 Bedrock 开发文档把游戏的一般更新频率写为每秒 20 tick，红石系统通常以每秒 10 次更新理解。玩家未必读过“离散时间系统”这个词，却会在失败中摸到它：两个活塞为何先后错位？信号经过几格延迟？一台机器为何在服务器卡顿时表现不同？抽象的时序变成了能听见的咔哒声。

学习红石通常经历几次身份变化：

1. 使用者：照着教程搭门、灯和简易农场，只关心能否工作；
2. 维修者：知道哪里会卡住，学会分段测试、留检修通道；
3. 设计者：开始计算体积、吞吐量、资源成本和多人服务器的负载；
4. 解释者：把自己的装置拆成模块，画出教程，让陌生人能够复现。

玩家走的这条路很像工程教育，却没有试卷。错误直接出现在世界里：物品堆在传送带末端，村民跑出分配区，活塞把不该移动的墙推走。失败留下现场，玩家必须沿着信号回查。红石最珍贵的不是模拟电路，而是把调试变成可以走进去的空间。

它也改变了资源的意义。铁不再只用来做盔甲，还能变成漏斗；史莱姆不再只是敌人，而是黏性活塞的供应链；一片甘蔗地不再是一片景观，而是一台纸张工厂的上游。自动化让玩家从“我缺什么”转向“这个系统的瓶颈在哪里”。

效率也没有终点。一台农场每小时产出一千件物品之后，玩家会建更大的仓库；仓库装满后，又会设计分类机；分类机太吵，再追求静音与紧凑。自动化看似消灭劳动，实际上不断生产更高层的劳动。Minecraft 在这里显出一种温和的工业宿命：工具帮人摆脱旧麻烦，也帮人发明新欲望。

私人玩具长成了一块公共土地

单人世界里，规则争议通常由一个人结束。你可以作弊找回掉进岩浆的装备，也可以坚持永久死亡；可以复制存档，也可以把事故当历史。服务器一开，决定就不再只影响自己。

最初，几位朋友只是想一起盖房。很快，公共箱子里的钻石少了，出生点附近的树被砍光，某人的高效率农场让服务器卡顿，新玩家找不到可以落脚的空地。于是世界出现领地、交易、道路、税收、封禁和申诉。管理员从提供主机的人，变成了没有工资的市长。

大型服务器把这套制度推到极端。它们编写插件，设计小游戏，维护反作弊，运营虚拟经济，也要处理玩家之间的语言与地域差异。吉尼斯记录显示，Hypixel 在 2017 年 7 月 7 日曾达到 64,533 人同时在线。这样的规模已经接近一座中型城市，只是所有人共用的是登录、匹配和规则系统。

服务器里最稀缺的资源往往是可信任的协作，钻石反而容易解决。大型建筑需要材料供应者、设计者、红石工程师、施工者和记录者。谁能拿公共仓库的东西？谁负责备份？建筑被破坏后按什么证据回滚？当成员离开，他的领地归谁？这些问题没有苦力怕那么醒目，却更决定社区能活多久。

自由服、无政府服、角色扮演服、小游戏服，会给出完全不同的答案：

• 自由服把规则压到最低，风险本身成为卖点；
• 生存社区用白名单、领地插件和行为准则换取稳定；
• 角色扮演服把城市、职业与冲突写成共同剧本；
• 小游戏服把方块世界改造成高频匹配的平台，靠持续运营维持人口。

服务器的分化说明，Minecraft 的“玩法”不是一套封闭菜单。基础游戏更像土地与建筑规范，服务器运营者在上面搭出不同政体。模组改变自然规律，插件改变社会规律。

可这也使商业边界变得棘手。服务器需要机器、带宽、美术、客服和开发者，完全免费很难长期维持；一旦出售强力装备，又会把公平变成价目表。Mojang 的商业使用规范因此不断细化：什么可以收费，什么会造成不公平优势，怎样标明并非官方产品，怎样保护未成年人。

规则并非后来套在自由外面的硬壳。自由产生了人口、财产与收入，规则也随之出现。一个人的木屋不需要宪法；一座城市迟早要讨论谁能改路。

死亡、坐标与共同记忆

服务器最能制造故事的机制，往往是“死亡后物品掉落”。它很简单：角色倒下，背包散在原地；玩家从重生点回来，必须在物品消失前找到现场。可一旦地图巨大、路线复杂，这条规则会迅速把个人事故变成集体行动。

有人在聊天框里报坐标，有人带备用装备出发，有人去地狱交通线接应。掉进岩浆时，救援可能只剩见证；死在远处洞穴，队友要根据模糊描述寻找那根插歪的火把。后来大家谈起那次事故，记住的未必是失去几颗钻石，而是谁在凌晨两点没有下线。

坐标把随机世界变成可以共同讲述的地理。“出生点往北两千格”是方向，“旧沙漠村旁的断桥”才是地方。服务器运行久了，成员会用事件命名空间：第一次打龙的要塞、某人炸穿的山、旧管理员留下的空城。地图上的路并非策划铺设，却像现实道路一样压缩距离，也把历史固定在沿线。

社区历史经常跨出游戏文件。玩家截下建筑进度，录制远征，画地铁图，在群聊里保存仓库规则。服务器关闭后，完整世界也许无人继续维护，几张截图和一段模糊视频却会流传。数字世界的消失并不比现实空间更轻，只是废墟不在原处等待考古，而可能在一次硬盘故障后彻底缺席。

备份于是既是技术动作，也是文化责任。管理员决定备份频率、保留多久、谁能拿到副本，实际上在决定社区的记忆由谁保管。地图太大、模组太旧、隐私关系太复杂时，“把存档发给所有人”未必可行；不发，又意味着一位运营者掌握共同劳动的最后副本。

有些服务器开启 keepInventory，让死亡后物品保留。硬核玩家可能觉得它削弱风险，新手和休闲社区却因此更愿意探索。规则的差别没有统一答案。关键在于成员是否知道自己进入了怎样的社会：这里把损失当冒险成本，还是把共同建造放在惩罚之上？

好的服务器规则不是最严或最自由，而是让成员能够预估行为的后果。 当管理者临时偏袒朋友、回滚标准反复变化、付费玩家拥有秘密特权时，一次死亡并非最大损失；世界失去可理解的因果，才会破坏长期信任。

单人模式教玩家改变环境，联机模式教人接受别人也在改变环境。你能修自己的房，也必须忍受邻居的屋顶配色；能规划公路，也要绕开先到者的农田。公共世界的成熟，常常就发生在这种不完美的妥协里。

YouTube 把游戏变成了摄影棚

Minecraft 的画面并不追求写实，却极适合视频。轮廓在小屏幕上仍能看清，破坏与放置动作有明确反馈，昼夜提供天然场次，角色皮肤又足够简单，观众很快能认出谁是谁。更重要的是，镜头不必等待主线剧情：玩家本身就是编剧。

早期实况把“第一次发现”变成可共享的惊喜。教程把个人摸索压缩成可复现的知识。建筑延时摄影让数十小时劳动在几分钟内从地面长起。挑战视频给旧机制套上新约束：不能离开一个区块、只有一条生命、每过一天边界才扩大。角色扮演服务器再把这些机制变成政治、友情与背叛的舞台。

到这一步，Minecraft 已不只是被直播的游戏，而是一种制作视频的低成本引擎。拍摄者可以控制天气、时间、皮肤、布景和镜位；模组能加入动作与道具；服务器能让演员从不同地点登录。传统动画先制作资产再表演，Minecraft 则拥有一个庞大观众早已认识的资产库。

YouTube 2021 年度文化回顾提到，仅以 Dream SMP 为标题的视频在当年就获得超过 20 亿观看。观众消费的不只是挖矿技巧，而是以方块世界为场景的连续故事。地图成为摄影棚，服务器日志成为史料，直播事故成为剧情转折。

视频又把观众送回游戏。一个从未玩过的人先认识某位主播的房子、口头禅和服务器战争，之后才购买游戏；一个离开多年的老玩家看到新地形或新玩法，又下载旧存档。内容生产者替 Mojang 做了产品演示、教学、赛事和世界观扩写，而且风格多到官方团队不可能统一策划。

这是一种极强的分发飞轮：

• 游戏提供一套可拍摄的通用语法；
• 创作者把语法组合成故事、教程与奇观；
• 视频让新观众不经说明书就学会基本规则；
• 新玩家进入游戏，又产生下一批世界与创作者。

官方使用指南里有一句看似宽松、实则决定生态走向的话：

“We want to empower you to create and share.”

“我们希望让你能够创作并分享。”——Minecraft Usage Guidelines

“能够分享”意味着公司没有把每一段游戏录像都当作未经许可的衍生品去阻拦。它给创作者留出商业空间，也保留商标、误导性宣传、付费墙和官方背书等边界。平台放弃一部分内容控制，换来了自己不可能雇佣出来的文化产量。

交换并非慈善。创作者获得流量与收入，YouTube 获得观看时长，Minecraft 获得持续曝光；所有人都从同一片可识别的草方块上收租。只是在繁荣时期，人们容易忘记，平台规则、推荐算法和授权边界随时可以改变创作者的生计。

模组：玩家开始重写自然法则

服务器改变社会，模组直接改变世界。它可以增加一种矿石，也可以重写能量系统；可以让玩家造机器、施法、探索太空，也可以只把界面里的物品整理得更清楚。对很多 Java 版玩家来说，“原版”是所有分支共同继承的底板，不必被奉为唯一正确的形态。

模组生态的惊人之处，不在于内容数量，而在于它形成了自己的专业分工。有人写加载器，有人维护 API，有人做依赖库，有人画材质、录教程、整理整合包，有人只负责在新版本发布后追踪哪个环节坏了。玩家以为自己下载了一台新机器，背后可能站着几十个彼此并不隶属的维护者。

一轮官方更新会把整个网络推入迁徙。底层映射和接口改变；加载器适配，库更新，模组作者修复，整合包测试，服务器决定何时跟进。新内容越诱人，迁移压力越大。很多社区长期停在旧版本，原因是那里已经积累了稳定的模组组合、地图与运维经验，不能简单归为守旧。

对平台公司而言，模组是一份既便宜又昂贵的资产。便宜在于创意与开发劳动由社区承担；昂贵在于公司必须容忍用户改写体验、分散版本，并在安全、侵权、兼容和商业化之间划线。开放仍然需要管理，只是平台必须接受，自己无法把所有创新装进一条官方管道。

一项针对 Minecraft 模组的实证研究，抽取了 1,114 个流行模组与同量不流行模组，试图分析社区成功与软件特征的关系。这个样本规模表明，模组社区早已超过几位爱好者交换小补丁的范围，成为一个值得用软件工程方法研究的生态。可研究越成熟，维护者的老问题仍在：兴趣劳动如何持续？依赖链断掉由谁接手？玩家的期待为何总比空闲时间增长得快？

模组也提供了一条观察产业创新的窄缝。官方不便冒险的复杂系统，可以先在社区里试验；玩家对背包整理、地图导航、配方查询的普遍需求，会以模组形式暴露出来。后来某些理念进入原版，边界便再次模糊：这是官方吸收社区智慧，还是免费劳动被平台内化？不同参与者会给出不同答案。

答案很难彻底公平。社区靠开放缝隙生长，平台靠统一产品维持亿万用户。模组作者希望接口稳定，开发者又不能承诺永远不改底层；玩家希望旧整合包继续运行，也希望每年看到新东西。一句“尊重社区”消除不了这类冲突；它就是长青软件必须支付的结构性成本。

25 亿美元买到的不是一款游戏

2014 年 9 月，微软宣布以 25 亿美元收购 Mojang。那时 Minecraft 已不需要靠一份收购公告证明成功。令人意外的是买家和价格：为什么一家拥有 Windows、Xbox 与庞大研发体系的公司，要为一家瑞典小工作室和一个满是方块的游戏支付如此巨额的费用？

如果只按传统单机游戏估值，答案很难成立。单机作品有发售峰值、折扣周期和续作风险。Minecraft 却已经表现出另一种形态：它同时存在于电脑、主机和移动设备，孩子把它当玩具，视频创作者把它当生产工具，服务器把它当营业场所，学校开始把它当课堂界面。微软买到的核心，是一个跨设备迁移的社会关系网，而非一条可预测的续作流水线。

微软的官方公告提到，截至当时 Minecraft 在 PC 上已有超过 1 亿次下载，并把保持跨平台可用作为重要方向。这里的“下载”不能等同于销量，却能说明触达范围。收购完成后，微软没有把它从竞争对手的平台撤下。PlayStation、任天堂设备、iOS 和 Android 仍然重要，因为 Minecraft 的价值恰恰来自“朋友在哪里，世界就能延伸到哪里”。

这与微软过去依靠 Windows 锁定开发者和用户的逻辑并不相同。Minecraft 的网络效应不服从单一硬件边界。若把它变成 Xbox 独占，短期也许能卖机器，长期却会切断同学、家庭和创作者之间的连接。平台想拥有 Minecraft，就必须先克制独占 Minecraft 的冲动。

收购也解决了一个个人无法永远承担的问题。一个由作者直觉推动的项目，长到亿级用户后，需要账号安全、跨国支付、本地化、家长控制、内容审核、主机认证、云服务和法律团队。创始人的自由决定曾经是速度来源，后来也会成为单点风险。组织越大，越不可能只靠一个人的兴趣决定明年做什么。

代价同样清楚。早期玩家熟悉的是带着个人口吻的开发者和论坛；收购之后，他们面对的是 Microsoft Account、隐私条款、Marketplace、跨平台服务与品牌治理。哪怕游戏画面没有改变，玩家与它的法律关系、登录关系和支付关系都在变化。土屋仍是土屋，门锁却接进了更大的物业系统。

收购的宿命感正在这里。Minecraft 因为像公共土地而昂贵；它一旦被高价买下，就必须被当作基础设施维护；基础设施一旦承担儿童安全、全球发行和创作者收入，就不可能永远保持早期论坛时代的松散。公司获得增长，也继承了所有无法靠“让玩家自己决定”解决的问题。

从两亿到三亿：规模改变了什么

2020 年，Xbox Wire 宣布 Minecraft 售出超过 2 亿份，月活跃玩家达到 1.26 亿。2021 年的官方事实表把累计销量更新到 2.38 亿。2023 年，官方十五周年资料把里程碑写到 3 亿份。

三组数不能画成精确的年度营收曲线。它们来自不同时点的公开口径，中间年份没有在同一表格里连续披露。把空白补成平滑增长，会制造一种并不存在的财务确定性。但三个台阶足够说明：Minecraft 不只吃到一次首发红利，它在十多年后仍持续进入新设备、新家庭与新用户手中。

普通畅销游戏的困难，是发售后怎样延长注意力。Minecraft 的困难倒过来：怎样让大量新玩家加入，又不把老玩家赖以生活的规则改得面目全非。规模扩大后，任何小决定都会同时落在完全不同的人身上。

表中的利益并非天然一致。对家长友好的严格身份系统，可能让老玩家觉得平台侵入私人服务器；对创作者友好的付费市场，可能让一部分玩家觉得社区分享被商品化；对跨平台用户友好的统一机制，可能压缩 Java 版长期形成的非正式工具链。

规模还改变了更新错误的成本。早期一个漏洞可能只是论坛里的笑话；亿级产品的一次复制漏洞会冲击服务器经济，一次聊天安全失误会牵涉未成年人，一次账号问题会让人失去购买记录和多人功能。快乐按人数累积，边界情况却会彼此组合。

2024 年官方“Year in Blocks”回顾称，玩家一年敲掉超过 3000 亿个方块、探索超过 8500 万个生物群系、驯服超过 1 亿只狼。这类公司遥测数字无法由外部独立审计，也不该被神化；它的意义在于呈现维护对象的尺度。团队每改一条掉落规则，背后都可能有数十亿次重复行为。

Minecraft 的运营由此变得很像管理一门语言：可以增加新词，却不能让旧句子突然失效；可以修正规则，却要考虑人们已经用旧规则写了十年的书。

为什么一直没有 Minecraft 2

传统游戏的增长公式里，续作是最自然的按钮。新引擎、新画面、新定价，再用“从头开始”摆脱旧代码和旧平衡。Minecraft 却迟迟没有走这条路，因为续作首先会破坏它最昂贵的资产：所有人仍站在大致相通的世界语法上。技术上能否做出续作，反而不是主要障碍。

一部彻底重做的 Minecraft 2 可以让树叶更细、物理更真实、代码更整洁，却会立刻产生迁移难题。旧存档能否打开？模组作者是否重写一切？服务器社区要不要搬家？视频教程里的知识还剩多少有效？如果答案大多是否定，新作得到的是技术起点，失去的是十多年累积的共同常识。

长青服务把续作的戏剧性拆散到日常更新里。山变高、洞变深、生物增加、渲染和跨平台能力逐步调整，玩家不需要在某个发售日集体抛弃旧世界。这条路更慢，也更难宣传。每次改造都要在运行中的城市里施工，团队长期背着兼容债务，无法享受“一切推倒重来”的轻松。

版本照样会分裂。Java 与基岩本身就是一场漫长分岔，教育版、主机历史版本和中国版又有各自边界。Minecraft 没有用数字 2 划出断层，却把断层藏进设备、账号和功能差异。没有续作，不等于没有迁移；只是迁移被做成了缓慢、局部、可以争论的过程。

维持同一个入口符合平台产品的利益。卖一部续作可以制造短期收入，旧入口则能保存网络效应、创作者库存和品牌认知。玩家每次回来仍认得工作台，创作者的旧视频仍能教会新人，公司也不必同时经营两个互相争夺人口的主世界。

代价是团队永远无法摆脱历史。早期看似无害的技术决定会被无数装置依赖，一个被玩家当作特性的漏洞很难修，一处手感变化会触发跨代争论。Minecraft 的保守，不只是审美选择，也是成功对开发者施加的限制：越多人把旧行为当成常识，改变常识的自由就越小。

两个 Minecraft，两种社会契约

今天谈 Minecraft，常要先问一句：Java 版还是基岩版？两者共享方块、合成、生物与主要更新主题，看起来像同一个游戏的不同客户端；对深度玩家而言，它们却代表不同的生活方式。

Java 版生长在 PC 与早期社区传统里。文件可见、服务器工具成熟、模组空间大，玩家习惯自己装加载器、调参数、管理版本。它的麻烦也来自同一处：兼容需要知识，整合包会冲突，新版本迁移可能要等待很久，朋友之间必须先对齐环境。

基岩版的使命更像一座交通枢纽。它覆盖主机、移动设备与 Windows，强调跨平台联机、手柄与触屏适配、统一账号和 Marketplace。加入朋友的世界更方便，家长和平台也能通过正式系统管理购买与安全。与此同时，创作和分发更依赖审核入口，玩家可触及的底层边界更清楚。

争论哪一边才算 Minecraft 的正统，会错过更大的问题。Java 版保留了游戏成为创作公共地的历史条件；基岩版让这块地进入更多客厅、校车和家庭平板。没有前者，生态可能变得整齐但贫瘠；没有后者，Minecraft 很难跨过设备壁垒成为代际产品。

2017 年推出的 Marketplace 把皮肤、地图、纹理与世界接入正式商店。官方 2021 年事实表称，Marketplace 创作者累计获得超过 3.5 亿美元收入，内容下载超过 10 亿次。专业团队由此多了一条正式收入渠道，可以直接面对全球基岩版用户结算，不再完全依赖捐助、广告和不稳定的站外支付。

可市场也会改变创作的气味。免费论坛里的作品由兴趣、声望和互助驱动；商店里的作品要经过团队资质、商业计划、审核、排期和定价。前者可能混乱、不安全、难以持续，后者可能让首页位置与转化率左右选题。当社区劳动被正式计价，它获得职业尊严，也开始服从货架逻辑。

两种版本长期并存，说明微软没有找到一条能同时最大化自由、便利、安全与商业效率的完美路线。或许本来就不存在。产品设计常把“统一”视为成熟，Minecraft 却靠保留分岔承认：不同社会契约无法被一个开关化解。

中国版：全球游戏也要穿过本地制度

2016 年，网易与微软、Mojang 宣布合作，把 Minecraft 的 PC 与移动版本带入中国市场。公告中的五年独家协议属于当时安排，不能直接用来描述今天的全部状态；它仍揭示了一件事：全球通用的方块语法，到了具体市场，必须穿过本地发行、账号、网络、内容合规与运营体系。

对于玩家，这种本地化最直观的变化可能是免费进入、中文界面、国内服务器和社交入口。对于平台，它意味着另一套反作弊、实名认证、未成年人保护、支付和内容审核责任。游戏世界可以由种子随机生成，法律环境不会随机生成。

中国版的出现打破了一个浪漫想象：仿佛互联网文化只要足够受欢迎，就能绕过国家、平台与商业制度直接连接所有人。实际上，规模越大，越依赖本地合作伙伴。服务器在哪里，账号由谁维护，创作者怎样分发，活动怎样审批，都会重新塑造玩家看到的“同一个 Minecraft”。

本地化并非只有限制。免费或低门槛入口可能让更多学生第一次接触游戏；本地服务器降低延迟；中文教程、赛事与社群会产生自己的表达。问题在于，便利往往和封闭一起到来：国际版与本地版的账号、内容和社区并不天然互通，玩家可能生活在视觉相同却制度不同的世界。

Minecraft 的视觉词汇太简单，简单到很容易被翻译。草方块、镐、苦力怕轮廓能出现在玩具、文具、短视频和校园手工里，不依赖长篇背景设定。可符号可以全球流通，服务必须在地方落地。这组不对称，正是数字文化产业扩张的真实面貌。

对微软而言，中国版扩大了覆盖，也让品牌的一致性更难。对网易而言，它获得一个强势全球 IP，也要面对原有玩家对版本、更新和国际生态的比较。对玩家而言，最关心的问题往往很朴素：我的朋友在哪个版本？我的世界能不能带走？这些小问题，最终都指向平台间的数据边界。

课堂：不是用游戏包装作业

把热门游戏搬进学校，很容易变成一场误会。老师以为换上方块皮肤，学生就会自动喜欢数学；学生则一眼看出，所谓“游戏化”只是练习题多了一扇木门。Minecraft Education 有价值的地方，不在于它能给作业加糖，而在于它让知识变成可以共同操作的空间。

官方教育站目前称其覆盖 140 个国家的 4 万多个学校系统，并提供 600 多节与课程标准对齐的课例。这是公司自报口径，不等于每个系统都高频使用，也不能单独证明学习效果。数字至少说明，它已从零散教师实验变成一套需要账号、课程、课堂管理和技术支持的教育产品。

一堂好的方块课，不会只让学生“在游戏里答题”。它可能让几组学生按不同预算搭桥，比较材料、跨度和承重假设；也可能要求学生复原历史建筑，解释为什么城门、市场和水源处在那些位置。化学模块把元素与合成放进可操作界面，编程课程则让代理执行重复任务，暴露指令是否清楚。

课堂里的共同世界还有一个纸笔难以替代的优点：错误是公开而具体的。桥断在第七格，空间动线堵在门口，程序里的循环让代理不停转圈。学生不必等老师红笔判定“错”，可以先看见系统如何失败，再和同伴争论该改哪一块。

它也会制造新的课堂问题。熟练玩家可能垄断操作，新手只负责旁观；有人沉迷装修而偏离任务；键鼠、网络和设备差异会变成学习差异。教师若不设计角色分工与评价方式，所谓协作很容易退化成“最会玩的人替大家完成”。媒介降低了表达门槛，却不会自动消除权力差异。

“学生喜欢游戏”解释不了学习效果。更值得保留的是三种学习动作：

• 把抽象概念转成可摆放、可测量的模型；
• 在共同空间里暴露彼此的假设，而不是只交个人答案；
• 让失败留下可检查的现场，促使学生迭代而非猜测标准答案。

三种动作也解释了为什么 Minecraft 能从课堂继续走向城市参与。

Block by Block：让意见变成可以走进去的模型

联合国人居署与 Block by Block 项目把 Minecraft 用于公共空间参与。方法报告汇总了 87 个城市、101 场工作坊、40,050 名直接参与者，并估计影响超过 180 万居民。“联合国也玩游戏”只是表面新闻；城市协商缺少一种普通人能直接修改的共同模型，才是项目要解决的问题。

传统规划图对专业人员高效，对居民却可能像另一种语言。等高线、容积率、剖面和交通符号，把日常经验压缩成技术标记。居民能说“这条路晚上不安全”“老人没地方坐”“孩子过街危险”，却很难把意见放进一张可比较的方案图里。

方块模型做了一次翻译。参与者可以加一盏灯，挪一条路，打开一面围墙，放几棵树，再让别人用角色从入口走到广场。方案不因此变成可直接施工的工程图，但意见获得了位置、尺度和相互关系。讨论从“我觉得不好”走向“如果把摊位移到这里，救护车还能不能通过”。

在这类工作坊里，Minecraft 的低精度反而是一种政治优势。模型若过于逼真，参与者容易把它当专家已经完成的方案；方块的粗糙不断提醒大家：这只是草案，可以拆。低保真不是缺陷，而是邀请修改的礼貌。

当然，工具也会筛选参与。谁熟悉电脑，谁有时间来工作坊，谁的表达被主持人记录，最后谁把方块方案翻译成预算与施工文件，仍然是制度问题。一个漂亮模型不能替代土地权属、财政、维护责任和正式决策程序。它只是把更多人带到谈判桌前，不能保证谈判结果公平。

Minecraft 在这里完成了一次罕见的角色转换：同一套“敲掉、放上”的动作，从私人娱乐变成共同提案。第一夜里，玩家用方块划出“我的安全区”；城市工作坊里，居民用方块争论“我们的公共空间”。动作没有变，主语变了。

方块世界长大以后，谁来制定规则

2016 年，微软研究院把 Project Malmo 作为人工智能实验平台开放。它提供 Minecraft 环境中的观测、行动和任务接口，让研究者不必先造一个完整三维世界，就能测试智能体如何导航、收集、合成与长期规划。

微软研究院用一句简短判断解释选择：

“Minecraft is ideal for artificial intelligence research.”

“Minecraft 很适合人工智能研究。”——Project Malmo

原因和它吸引人类的原因相似。世界视觉结构清楚，动作集合有限，却能组合出长任务。做一把钻石镐，不是点击菜单领取奖励：智能体先要找到树，做工作台和木镐，挖石头，升级工具，寻找铁、熔炉和燃料，再进入更危险的地下寻找钻石。前一步失败，后面全部消失。

做成一把钻石镐，会把几个 AI 难题绑在一起：从像素理解环境，把语言目标拆成子目标，在稀疏奖励下坚持探索，记住物品与地点，并在意外发生时重新规划。迷宫导航只考一段能力，Minecraft 则让“看、想、做、记”相互拖累。

MineRL 数据集进一步把人类演示带进研究。其公开资料描述了超过 6000 万组状态—动作数据，并用“获得钻石”等长序列任务测试样本效率。研究者不能无限试错烧算力，而要从人类如何砍树、转身和选择路线中学习先验。

2022 年，OpenAI 公布 Video PreTraining。研究团队先训练一个逆动力学模型，从视频画面推测人类当时按了什么键、移动了多少鼠标，再给大量没有动作标签的网络视频补上伪标签。VPT 使用约 7 万小时公开视频做预训练；模型能够执行早期游戏技能，微调后还展示了获取钻石镐这一需要两万多次动作、对熟练人类也要二十多分钟的长任务。

这里形成了奇特的闭环。十多年来，玩家上传教程和实况，本意是娱乐、教学或谋生；这些视频后来成为机器学习“人类怎样在世界里行动”的材料。社区生产的不只是文化内容，也是不经意间形成的行为数据集。

2023 年的 Voyager 则把大语言模型、自动课程和技能库接入 Minecraft。论文报告称，相较若干基线，它探索距离达到 2.3 倍，获得独特物品数量达到 3.3 倍，部分关键里程碑最多快 15.3 倍。这些是特定实验条件内的相对结果，不能直接等同于通用智能；它仍说明 Minecraft 提供了一种难得的开放式评估：智能体没有固定关卡答案，必须自己决定下一件值得做的事。

人工智能在 Minecraft 里的进步，也暴露了基准的局限。一个代理会挖钻石，不代表它理解朋友为何珍惜一座破木屋；会优化路线，不代表它知道何时不该拆掉村民的房子。系统能测量任务完成，却很难测量共同生活的分寸。

问题由此回到人类玩家。把方块放对位置只是技术任务；当许多人共享一片世界时，怎样决定什么叫“对”，才是长期难题。

公共空间的门锁：账号迁移与聊天举报

2020 年，Mojang 宣布旧账号将迁移到 Microsoft Account；迁移窗口后来结束。对公司而言，统一账号能提供双重验证、跨服务安全与更一致的身份体系。可在一些老玩家眼里，旧账号承载着十年前的购买凭证和玩家身份，不能只按一笔待处理的技术债来计算。

当迁移从“建议”变成继续使用部分服务的前提，冲突便出现了。平台说的是安全、合规和维护成本，玩家听见的却可能是：我曾经买下的门，现在必须换一把由新物业发放的钥匙。旧世界文件也许仍在本地，登录、皮肤、多人和购买权益却不只由本地文件决定。

2022 年 Java 版推出玩家聊天举报功能，再次触碰相同神经。官方强调，举报会由人工审核，目标是处理严重的有害信息，保护玩家尤其是未成年人。反对者担心，中央平台把处罚权伸进私人服务器，可能无视服务器自己的语境、规则和申诉机制。

Mojang 的说明写道：

“Ensuring the safety of Minecraft players is at the heart…”

“保障 Minecraft 玩家安全，是我们工作的核心……”——聊天举报工具说明

从公司责任角度看，这句话几乎无可反对。问题在“谁来定义风险、用什么证据、处罚影响哪些空间”。一个服务器若只服务几位成年朋友，他们会把聊天看作私人房间；平台看到的却是同一套账号与客户端，无法保证每个房间永远只有熟人。自治的边界，在身份系统统一之后变得模糊。

把争议简化成“玩家反对安全”并不公平；把平台描述成单纯控制欲也不充分。双方在保护不同的东西：玩家保护自己建立的地方秩序，平台保护跨服务器、跨年龄和跨国家服务所必须承担的最低责任。争议的核心是规则能否解释，处罚能否申诉，干预强度能否与风险相称；是否需要规则，反倒不是分歧所在。

长青游戏容易积累一种产权错觉。玩家花几千小时建城，便自然觉得“这是我的世界”；但客户端许可、在线身份、服务器软件和品牌仍处在不同权利层级。平时这些层级安静叠放，政策变化时才突然彼此摩擦。

判断 Minecraft 是否已成为数字公共空间，在线人数并非最重要的标准。它内部的规则争论已经和城市里的争论相似：安全与自由如何交换，地方自治与中央标准怎样衔接，维护成本由谁承担，处罚能否复议。一个纯粹的玩具不会遇到这些问题，只有被人当成生活场所的地方，才会为门锁争吵。

衍生作品：方块外观不是方块语法

一个品牌拥有 3 亿份销量、万亿级视频观看和跨代认知后，扩张几乎不可避免。管理层会问：能否把它做成动作冒险、即时战略、增强现实、电影和更多商品？问题看似是“怎样利用 IP”，实际是“什么部分能够被搬走”。

Minecraft: Dungeons 把方块美术套进地牢动作游戏。它降低建造比重，强化战斗、装备和关卡，最终吸引超过 2500 万独立玩家；2023 年，官方宣布不再计划新的功能或内容更新。它称不上无人问津，却走完了一条更接近传统作品的生命周期。

Minecraft Earth 尝试把方块放进真实街道与手机镜头。产品设计依赖自由移动和现场协作，疫情却让这两个条件突然变得不合时宜。官方在 2021 年结束服务时明确提到，全球环境让核心体验难以实现。品牌再强，也无法替产品补上已经消失的使用场景。

Minecraft Legends 把熟悉生物与资源组织成动作战略。首发数日用户超过 300 万，证明方块符号仍有号召力；但它同样需要用明确任务、战斗节奏和内容供给留住玩家。离开自由建造的核心后，作品必须像所有品类游戏一样接受关卡、平衡与更新速度的审判。

2025 年真人电影上映，全球票房约 9.6 亿美元。影院里，观众会在熟悉的生物、合成动作和台词出现时集体反应。这种热闹说明 Minecraft 已有一套跨地域识别的符号库。观众当然不用真的挖方块；电影把“我认得这件东西”的瞬间变成了共同表演。

可票房成功也不能证明所有衍生方向都成立。核心游戏最强的体验，是玩家对结果负责：房子丑，是我盖的；朋友掉进陷阱，是我们当晚的事故；服务器战争，是参与者共同写出的历史。电影只能把这种所有权换成观看与认同。它能放大文化记忆，无法复制亲手劳动。

所以 Minecraft 的护城河并非绿色草方块，也不是某个角色的脸。视觉可以授权，生物可以跨媒介，音乐与台词可以唤醒回忆；最难搬走的是**“一个普通人能改变世界，并看见改变持续存在”**的感觉。

衍生作品因此必然参差。它们从一个像基础设施的母体出发，却必须落回具体品类。母体靠开放性容纳不同欲望，衍生作靠取舍形成清晰循环。品牌越强，越容易让人误以为取舍可以省略；市场最终会把这份误会结算出来。

为什么它还能继续：长寿飞轮的五条铁律

把 Minecraft 的历史压缩成“自由度高”，仍然太轻。很多沙盒也自由，很多编辑器更强，很多在线游戏更新更勤。它能跨越十七年，是几种机制互相支撑，而开发者没有把其中任何一种榨干。

基础动作必须比内容寿命更长

敲掉、放上、合成、移动，这几个动词从早期版本延续至今。新生物、新地形会带来回流，动词之间不断生出的组合则让玩家长期留下。内容会被看完，语法却能不断造句。

“更新越多越好”在这里并不成立。如果每年都用一套新系统替换旧系统，玩家只能追逐版本攻略，很难形成对世界规律的稳定认识。Minecraft 大多数更新选择给旧语言增加新词，偶尔显得保守，却保住了不同世代玩家之间的共同常识。

低门槛与深上限必须同时存在

孩子能在一分钟内理解方块可以敲掉，工程玩家却能花数月优化红石机器。创造模式允许不付资源成本地表达，生存模式又让同一座建筑拥有劳动重量。单人、联机、地图、模组和服务器通向不同深度，玩家不必在这些入口之间做单选。

低门槛只带来短暂流行，深系统只服务小圈层。二者叠在一起，才会形成老师向学生介绍、孩子拉父母入坑、老玩家给新人看旧城的代际传播。新人不必继承全部历史，也能在第一天贡献一堵墙。

社区必须拥有足够大的剩余空间

如果官方把每种冒险、建筑和故事都做成标准答案，创作者只剩复述。Minecraft 长期保留粗糙边缘：皮肤可以替换，服务器可以改规则，地图可以自制，视频可以商业化，Java 版可以深度模组化。这些缝隙让外部劳动有价值。

“剩余空间”也意味着官方要忍受不整齐。教程质量不一，服务器文化冲突，模组可能不兼容，创作者会把游戏改得认不出来。生态的生命力和平台的控制欲永远拉扯。只想要生命力，不承担风险，是幻想；只想要控制，不损失创造力，也是幻想。

玩家劳动必须被当作历史资产

老存档、服务器建筑、视频系列、模组工具链，都不是版本升级时可以忽略的外部文件。它们构成玩家回来的理由，也构成新版本必须背负的重量。更新要兼容旧区块，商业政策要给过渡期，账号变化要提供恢复与申诉，原因都在这里。

长青产品和新产品最大的区别，是前者的用户已经在里面修了路。开发者不再面对空地，而是面对有人居住的城市。每一项“技术上更正确”的改造，都要先回答会拆掉谁的房子。

平台要承认自己既是地主，也是市政

Minecraft 的法律产权属于公司，文化产量却由玩家共同创造。公司可以写使用条款、控制账号和商店入口，却不能像管理一套普通素材那样管理所有社区。它需要允许自治，也需要在安全、欺诈、未成年人和跨平台身份上设最低线。

成熟并不意味着所有人都喜欢规则，而是规则的对象、证据、处罚和申诉尽可能清楚。平台若只谈“我们的权利”，会透支共同建设的信任；若只谈“玩家自由”，又是在把公共空间的风险推给最弱的人。

五条规律组成飞轮：简单动作带来新人，深系统留下熟练者，社区创作持续制造新入口，旧世界连续性保存记忆，记忆又通过视频、家庭和学校带来下一代。任何一环断裂，Minecraft 都可能退化成一个仍然著名、却不再有人长期生活的品牌。

那间不好看的木屋

多年以后，玩家回到旧存档，通常不会先去看最宏伟的建筑。他沿着早已不用的石路走，穿过后来扩建的仓库和铁路，最后停在出生点附近一间矮小的木屋前。屋顶比例不对，窗只开了一格，火把插得毫无章法。以今天的技术，他几分钟就能盖得更好。

可他没有拆。

那间屋子保存着一个与建筑水平无关的时刻：太阳第一次落下，墙外传来僵尸声，手里只有几块木板；他不知道世界有多大，也不知道自己会在这里住多久。所有后来复杂的东西——红石工厂、服务器制度、视频频道、Marketplace、课堂、AI 实验——都建立在同一种朴素感觉上：只要再放一块，处境就会改变一点。

Minecraft 没有替玩家写完世界，因此玩家把自己的时间写了进去。开发者提供材料，社区提供劳动，平台提供连接与规则；三者彼此依赖，也彼此不完全信任。它们共同维持的，不是一场永不落幕的狂欢，而是一座永远有人修补的老城。

这座城会商业化，会争吵，会换门锁，会有新城区，也会有人怀念旧论坛。它不纯洁，从来没有。早期收费、模组授权、服务器付费、微软收购和创作者市场，都是它历史的一部分。难得的是，商业扩张尚未彻底吃掉那项最初的权利：普通人进入世界后，仍能决定眼前这一块应该挖掉，还是留下。

Minecraft 的终点从来不在地图尽头，而在玩家不再觉得下一块方块与自己有关的那一天。

至少现在，那一天还没有到来。

资料来源

以下来源用于核对时间、规模、公司政策、教育项目与研究数据；正文中的分析和因果判断由作者据此综合。

• About Minecraft：首个版本、正式发布与开放世界说明
• Minecraft 十五周年：2009 年 5 月 17 日与关键节点
• Minecraft Classic：32 种方块的早期版本
• Game Developer：Markus Persson 早期开发访谈
• Ars Technica：Minecraft 创作过程访谈
• TIME：The Mystery of Minecraft
• Microsoft：2014 年收购 Mojang 公告
• Xbox Wire：2020 年销量与月活里程碑
• Minecraft 2021 年事实表 PDF
• Minecraft 十五周年时间线：2023 年 3 亿份里程碑
• YouTube：十五年与 1.5 万亿观看
• YouTube：2021 年内容与 Dream SMP
• Guinness：Hypixel 同时在线纪录
• Minecraft Usage Guidelines
• Minecraft Marketplace 说明
• Minecraft Partner Program
• Caves & Cliffs 拆分公告
• Caves & Cliffs Part II 发布说明
• Microsoft Learn：红石与 tick 机制
• NetEase：2016 年中国版合作公告
• Minecraft Education 官方站
• Minecraft Education：课程与功能说明
• UN Human Security：Block by Block 方法报告 PDF
• Microsoft Research：Project Malmo
• MineRL：基于人类先验的样本高效强化学习
• OpenAI：Video PreTraining
• Voyager 论文
• Mojang：玩家聊天举报工具说明
• Minecraft 帮助：Mojang 账号迁移结束
• Minecraft Earth 结束服务公告
• Minecraft Dungeons：2500 万玩家与更新终止
• Minecraft Legends：首发阶段超过 300 万用户
• The Numbers：A Minecraft Movie 票房数据
• Minecraft：A Year in Blocks 2024

灰色浏览器窗口、现代标签页与 AI 光标，概括浏览器从阅读工具走向 AI Agent 的演变。

浏览器从窗口长成了王座

2026 年夏天，一个普通人打开电脑，通常会直接点击任务栏或 Dock 里的浏览器图标。很少有人会停下来主动选择浏览器，也很少有人追问：为什么默认打开的是这个浏览器，它如何显示网页，地址栏里的搜索会交给哪项服务，又有哪些设置早已替用户选好？

StatCounter 的数据说明浏览器市场已经高度集中。按页面浏览量口径，2026 年 6 月，Chrome 占全球全平台浏览器使用量的 69.65%，Safari 为 15.31%，Edge 为 5.21%，Firefox 为 3.33%。这组数据不等于装机量，也不是不可争辩的真理；追踪器可能被拦截，设备与地区权重也会影响结果。但它足以显示当前格局：一个产品占了接近七成，而排名第三的 Edge 同样建立在 Chromium 之上。StatCounter 的同期数据还列出 Samsung Internet 1.95%、Opera 1.74%。浏览器品牌不少，背后的主流引擎却只有少数几种。

更奇怪的是，普通人几乎不再为浏览器付钱。Chrome 免费，Safari 跟着设备来，Edge 跟着 Windows 来，Firefox 也免费。若把浏览器当作普通商品，这是一门很不讲道理的生意：工程团队庞大，安全更新不能停，网页兼容问题永无止境，直接售价却常年是零。可微软、Google、Apple、Mozilla 和许多后来者仍在上面投入巨资，还招来了几轮反垄断诉讼。

原因在于，浏览器掌握着互联网入口。它决定网页怎样显示，脚本怎样执行，用户能否安装某种扩展，默认使用哪项搜索服务，广告与购物如何归因，密码和身份信息如何保管。进入 AI 时代之后，它还试图理解页面、记住浏览历史、调用登录状态，再替用户点击“购买”“发送”或“预订”。

浏览器战争争夺的远不止启动速度。产品质量决定用户是否愿意使用，默认分发决定产品能接触多少用户，技术标准影响开发者优先适配哪些实现，商业模式则影响厂商的发展方向。等市场高度集中以后，监管者还要判断：这些优势是否妨碍了其他产品参与竞争？

浏览器位于网页标准与用户行为之间，并受到默认预装、搜索广告、开发者兼容和 AI 行动权的共同影响。

这段历史很难简单分配英雄和反派。Netscape 用开放的 Web 挑战封闭的桌面平台，却也曾用私有标签争夺标准；微软用排他分发压制对手，也实打实投入上亿美元把 IE 从劣质产品追到可用；Google 大幅提升了 JavaScript 性能和 Web 应用能力，同时把搜索、广告、浏览器与账号连成一套相互促进的业务系统；Apple 强调隐私和自家设备的使用体验，也长期要求 iOS 上的第三方浏览器使用 WebKit；Mozilla 努力维持引擎多样性，主要收入却长期来自默认搜索合作。

每个参与者都能为自己的选择找到理由。但在商业模式和分发优势的推动下，胜利者往往也会走向市场集中，并开始限制后来者。

从编辑器到大众入口：1990—1993

一台不能关机的 NeXT

故事要从一台 NeXT 电脑讲起。1990 年的 CERN 是一座庞大的粒子物理研究机构，与创业神话里的车库相去甚远。实验团队跨国家协作，人员来去，计算机型号各异，资料散在不同系统里。蒂姆·伯纳斯-李面对的麻烦很朴素：人们创造了大量信息，却很难知道信息在哪里、彼此如何关联。

他把几项技术组合起来：用 URL 指向资源，用 HTTP 传输，用 HTML 表达文档与链接，再用一个程序读取和编辑这些文档。W3C 的官方历史记载，伯纳斯-李在 1990 年 10 月写出第一个 Web 服务器和第一个客户端 WorldWideWeb；这个客户端既是浏览器，也是编辑器。到那年圣诞节前后，第一组服务器、网站和浏览器已经在 CERN 内运行。W3C 对早期历史的回顾把“browser and editor”并列写在一起，点明了这个项目最初同时关心阅读和编辑。

“Vague, but exciting.”

— CERN 主管 Mike Sendall，1989 年写在伯纳斯-李提案封面上的批语；CERN 二十周年回顾

今天，大多数网站把内容发布和阅读分开：平台和作者提供内容，用户负责浏览。早期设计却更强调共同编辑信息。第一个浏览器同时也是编辑器，阅读者也可以成为创作者。

WorldWideWeb 浏览器/编辑器把浏览与编辑放在同一界面中，体现了早期 Web“既可阅读，也可书写”的设计理想。

不过，Web 当时还远未普及。它要和 Gopher、FTP、Usenet 以及商业在线服务争夺注意力。它的优势不只在超文本，还在制度设计：协议公开，链接可以指向任何服务器，建站不必向中央公司申请频道。任何人都可以单独架设服务器并加入 Web，无须得到中央平台批准，也无须改造已有网络。

1993 年 4 月 30 日，CERN 发布声明，把 Web 的核心软件置于公共领域，允许任何人无偿使用和继续开发。CERN 的历史记录说，到 1993 年末，已知 Web 服务器超过 500 台，Web 约占互联网流量的 1%。数字放到今天很小，在当时却意味着 Web 正从 CERN 和研究机构走向更广泛的用户。

1993 年的许可决定，为后来的浏览器竞争创造了前提。若 Web 的底层协议需要向 CERN 逐台收费，后来者很可能把精力花在授权谈判上，而不是改进技术实现。免费、去中心化、免版税并没有消灭商业，反而扩大了商业空间：任何公司都能造浏览器、开网站、卖服务器、投广告。开放标准降低了进入 Web 市场的门槛，也提高了直接接触用户的商业价值。

一个矛盾由此出现：Web 因为没人独占而繁荣；Web 越普及，浏览器公司就越想控制用户访问它的方式。

Mosaic 把“互联网”变成了一个能看懂的地方

Web 要走出研究机构，还需要一款普通人也会用的软件。

1993 年，伊利诺伊大学厄巴纳—香槟分校的 NCSA 发布 Mosaic。它不是最早的图形浏览器，却成了第一款大范围流行的图形互联网浏览器。图片能和文字出现在同一页面，安装包后来覆盖 Unix、Macintosh 和 Windows。过去要记命令、切换工具才能取得的信息，现在可以通过“后退”“前进”“打开”“保存”等图形按钮来访问。

那套界面今天看来粗糙：大片灰色边框，凸起的立体按钮，蓝色链接，页面像一份可以点击的实验室简报。可要理解它当时的吸引力，得回到拨号上网的年代。线路连接时会发出尖锐噪声，图片从上到下一条一条刷出来，一张几百 KB 的图足以让人等上半天。即使如此，图文能在同一页面出现仍让人耳目一新。互联网不再只是一组需要分别操作的远程服务，普通人也可以在页面之间点击浏览。

NCSA Mosaic 将图形界面、文字和图片带进普通用户的网页浏览体验，加速了 Web 走向大众。

NCSA 的官方历史记载，Mosaic 在 1993 年 1 月出现；当年 12 月登上《纽约时报》商业版时，每月下载量已超过 5000 份，NCSA 每周收到数十万封电子邮件咨询。衡量早期软件传播的数字常有口径差异，今天也很难精确还原每一份下载，但趋势毫无疑问：Mosaic 开始把 Web 从研究和技术圈带给大众。

它还培养了一批后来进入硅谷的开发者。马克·安德森和埃里克·比纳等人在 NCSA 完成 Mosaic，随后离开校园，把研究项目积累的界面经验带进商业公司。这也是早期 Web 商业化的典型路径：公共资金和大学实验室承担早期探索，商业资本再把研究成果做成大规模发行的产品。

Mosaic 最重要的遗产是一套产品布局，而不只是某段代码：顶部是工具栏，中间是地址，下面是内容；用户可以后退、收藏、重新加载；图形界面遮住协议的复杂性。三十多年后，按钮变成线性图标，地址栏和搜索框合二为一，标签页挤满屏幕，但浏览器的基本布局没有发生根本变化。

浏览器成为大众访问 Web 的工具后，竞争的重点也从“能不能访问 Web”转向“用户会使用谁的浏览器”。Mosaic 刚让大众学会浏览网页，商业公司已经开始计算软件销售、广告和服务器授权的收入。

1994—1995：Netscape 发现浏览器可以成为新平台

1994 年，硅图公司创始人吉姆·克拉克找到安德森，组建 Mosaic Communications，后来因名称纠纷改为 Netscape Communications。团队吸收了多位 Mosaic 开发者，却没有简单复制原产品。计算机历史博物馆把 Navigator 描述为一次完整重写：更快、更稳定，个人用户可免费下载，商业客户购买盒装版本、企业授权和服务器软件。博物馆的浏览器战争档案也记录了当时的软件发行方式：产品既装在纸盒里销售，也通过互联网免费传播。

这套策略后来成为互联网行业的常见做法，在当时却相当大胆：先让更多个人用户使用客户端，再通过企业服务器、开发工具和商业许可赚钱。浏览器本身不必直接盈利，它可以为其他业务带来用户。Navigator 推出后很快占据主导，Netscape 也从一家小公司变成“互联网公司”的代名词。

Netscape Navigator 代表了商业互联网早期的浏览器入口，也成为第一次浏览器大战的主角。

1995 年 8 月 9 日，成立仅约 16 个月、还没有传统意义上稳定利润的 Netscape 上市。发行前夕，定价从 14 美元提高到 28 美元，开盘一度冲到 71 美元，收盘 58.25 美元。这几个数字后来被反复写进互联网商业史，因为投资者开始把“互联网可能成为下一轮大产业”当成现实预期。Netscape 的 IPO 也常被视为互联网泡沫周期的开端。

市场的兴奋有具体的技术基础。Navigator 不只显示静态文档。Netscape 推动 JavaScript、插件和一系列浏览器 API，让网页获得越来越多的交互能力。Navigator 又跨越 Windows、Mac 和 Unix。开发者开始设想，程序不必只为某一套桌面操作系统开发，也可以在不同系统的浏览器中运行。

这些技术进展对微软构成了直接的商业威胁。Windows 的力量来自所谓应用壁垒：用户因为应用留在 Windows，开发者因为用户继续给 Windows 写应用，两边相互强化。若浏览器提供一套足够通用的接口，让网页应用横跨多个操作系统，Windows 对开发者的重要性就会下降，甚至可能退化成浏览器下面的基础系统。

美国司法部后来整理的法院事实认定，对这种担忧写得很直白：微软担心 Navigator 与 Java 形成“中间件”层，削弱 Windows API 对开发者的控制。浏览器之争的核心因而是应用平台的控制权，而不只是两个浏览器争夺用户。Netscape 希望应用不再依赖特定操作系统，微软则要加强浏览器与 Windows 的绑定。

1995 年 5 月，比尔·盖茨发出著名的“互联网浪潮”备忘录，把互联网提升到公司最高优先级。他在其中写道，互联网的重要性已经达到最高等级。这份备忘录表明，微软已经把互联网和浏览器视为可能削弱 Windows 的新平台。

Netscape 最强盛时拥有约七成甚至更高的浏览器使用份额，具体数字因统计方法不同而变化。但 Navigator 需要用户主动下载，Windows 则会跟随每一台新 PC 进入家庭和办公室。Netscape 拥有受欢迎的产品，微软拥有更强的分发渠道。

第一场大战：IE、默认分发与标准碎片

IE 赢下的关键：产品追赶之后的分发优势

一种常见的讲法需要修正：Internet Explorer 并非只靠捆绑、完全没有产品进步。1995 年 7 月推出的 IE 1.0 确实明显落后于 Navigator，法院也在事实认定里使用了近乎不留情面的描述。微软随后投入的工程资源同样惊人：IE 团队从 1995 年初的五六个人扩张到 1999 年的一千多人，年度研发支出超过 1 亿美元。IE 3 在 1996 年末获得明显好评，IE 4 到 1997 年后，认为它优于 Navigator 的评测数量已经大体能打成平手。

这些数字来自美国司法部发布的法院事实认定。只有产品达到基本可用的水平，分发优势才能充分发挥。若 IE 差到无法打开主流网站，再强的预装也可能迫使用户下载其他浏览器。微软先把产品差距缩小到普通人不容易察觉，再利用桌面预装、合作合同和销售渠道扩大份额。

这里可以想象一位 1997 年第一次买电脑的用户。新机器启动，Windows 桌面上已经有蓝色的 IE 图标；拨号接入软件可能也把 IE 设成首选；系统帮助、Windows Update 和某些文件夹体验又与浏览功能混在一起。若他想用 Navigator，就得听完猫叫般的拨号声，找到下载地址，等待几 MB 文件传完，再做安装和默认设置。继续使用 IE 的成本是零，换浏览器的成本是一连串小麻烦。

微软非常清楚这种默认惰性的价值。法院记录显示，公司决定不向 OEM 或用户收取 IE 的增量价格，并向互联网接入商、软件厂商和 Apple 等合作伙伴提供免费授权、推广资源或其他利益，以换取 IE 的分发和优先位置。IE 被装进 Windows，电脑厂商又受到桌面图标、启动流程等许可限制；在北美，十四家最大的十五家互联网接入商与微软达成的安排覆盖了大多数订阅用户。每一项安排都能找到单独的商业理由，合在一起却让绝大多数新用户首先接触到 IE。

默认预装带来用户规模，规模推动开发者优先适配，兼容性和切换成本又反过来巩固默认地位。

市场份额随即逆转。法院引用 AdKnowledge 的页面访问数据：1997 年 1 月，IE 在被监测网站的访问占比约为 20%，Navigator 为 77%；到 1998 年 8 月，IE 升至 49%，Navigator 降到 48%。AOL 在评估收购 Netscape 时使用的估计也显示，Navigator 从 1996 年末约 80% 降到 1998 年 7 月的“五成多”，IE 到 1998 年末已接近 45%—50%。

产品改进当然贡献了增长，却解释不了增长速度。微软内部在 1998 年仍认为两者对许多用户只是大致相当，没有强到足以让既有 Navigator 用户主动迁移。法院据此判断，如果微软只提高质量而不动用其他渠道措施，IE 的份额会上升得更慢，也不会在三年内拿走如此大的份额。

这就是后来反复出现的入口飞轮。它不是一次性发生，而是按固定顺序自我加强：

1. 预装和默认位置先带来第一批用户；
2. 用户规模让开发者优先测试主流浏览器；
3. 更好的站点兼容性减少用户切换的理由；
4. 更多网站围绕主流实现开发，进一步抬高替代品成本；
5. 更稳固的使用份额，又让默认位置显得更有商业价值。

公司不必公开要求开发者放弃其他浏览器。每个团队只是少测试一个环境，每个用户只是不想多安装一个软件，长期累积便会形成高度集中的市场。

微软的胜利也留下了一个危险先例。微软可以让浏览器免费，因为需要保护的是 Windows 平台；只要控制分发，免费产品同样能成为排挤竞争者的有力工具。

标准战争：网页开发者成了两军之间的翻译

写网页的人最先承受了浏览器大战的代价。

1990 年代的竞争经常遵循同一种模式：浏览器厂商抢先推出新标签、新脚本对象、新布局能力；网站为了做出滚动文字、动态菜单和交互效果，迅速采用；对手再推出不同实现。功能发布比标准协商快，短期内能制造“只有我的浏览器看得到”的差异，长期则造成浏览器之间互不兼容。

W3C 的 Web 历史文档写得毫不客气：微软和 Netscape 忙着增加私有功能，甚至以不兼容方式实现彼此相似的能力；开发者有时必须维护两套功能相同的网站，有时干脆只支持一种浏览器并阻止其他用户访问。到 IE 5 测试版推出一套私有动态 HTML 时，职业开发者可能需要掌握五种不同的 JavaScript 写法。这份 W3C 回顾详细记录了两家公司争推私有实现所造成的兼容问题。

常见的做法是先检查 navigator.userAgent，判断访客用 Netscape 还是 IE，再走不同代码分支。页面上出现“Best viewed with Netscape Navigator”或“请使用 Internet Explorer 浏览”的徽章。开发者必须为两种浏览器分别编写和测试代码，无暇专注于业务。测试矩阵越大，小网站越容易放弃兼容；站点越偏向一种浏览器，另一种浏览器的用户体验越差。浏览器不兼容由此进入自我强化的循环。

Internet Explorer 6 在 Windows 时代占据主流桌面入口，也成为平台捆绑与兼容性锁定的典型。

开放标准组织在这种环境里显得既关键又无力。伯纳斯-李于 1994 年 10 月在 MIT 创立 W3C，CERN、DARPA 和欧盟委员会提供支持，目标是让 HTML、CSS 等技术形成一致架构。W3C 官方历史强调，标准需要由产业、研究者和公共社区共同协调。但 W3C 发布的是推荐标准，对浏览器公司没有直接执法权。用户只关心页面能否打开，很少有人因为“更符合标准”就换浏览器。

于是，标准能否落地仍取决于产品竞争。CSS 的经历很能说明问题：W3C 的历史资料称 IE 3 在 1996 年成为最早支持 CSS 的商业浏览器之一，Netscape 的支持则一度犹疑且不完整。微软并非始终反对标准，Netscape 也并非始终坚持开放；标准是否符合自身商业利益，会影响两家公司的态度。

1998 年，Web Standards Project（WaSP）成立，一批设计师与开发者公开施压，要求浏览器正确实现 W3C 规范。这个民间团体没有监管权，依靠的是集体发声、测试、公开批评与市场教育。他们推动厂商修复兼容问题，也劝 Netscape 推迟 5.0，转向更符合标准的新引擎。这次重写后来为 Firefox 提供了技术基础。

标准写在文档里，到了用户电脑上却要由浏览器引擎执行。若占主导的引擎长期错误实现某个行为，网站为了正常运行就会适配这个错误，错误便可能成为“事实标准”。浏览器不只是按照规范显示 HTML；引擎的实现选择也会反过来影响 Web 的实际规则。

这也是引擎多样性的重要性。两个独立实现对同一规范理解不同，会暴露模糊之处，促使标准和测试写得更清楚；若绝大多数网站只在一种实现上运行，“能在主流引擎里工作”就容易取代“符合开放标准”。统一减少了眼前的测试成本，却可能让同一套代码决定多数网站如何理解和使用标准。

反垄断案判了什么，又没有判什么

1998 年，美国司法部与多个州起诉微软。后来流行叙事常把案件压缩成一句话：“微软把 IE 捆绑进 Windows，被判垄断。”这句话抓住了方向，却忽略了重要的法律细节。

地区法院在 1999 年公布事实认定，2000 年认定微软非法维持操作系统垄断、企图垄断浏览器市场，并以非法搭售方式把 IE 与 Windows 结合，随后下令把微软拆成操作系统与应用两家公司。这是地区法院阶段的结论，后来并未完整保留。

2001 年的上诉结果更复杂。上诉法院维持了微软通过反竞争手段非法维持 PC 操作系统垄断的核心结论，确认多项 OEM 限制、排他安排和技术措施构成排除行为；它推翻了“企图垄断浏览器市场”的认定，并撤销地区法院对捆绑问题直接适用“当然违法”规则的结论，要求使用更完整的合理原则分析。法院也撤销拆分命令，案件交给新的法官处理救济。上诉判决全文明确说，平台软件把新功能整合进旧产品，可能有真实效率，不能机械套用过去对电影放映机和胶片那类搭售的判断。

上诉判决并未为微软开脱。法院明确确认，把 IE 从“添加/删除程序”中排除、混合浏览器与操作系统代码等行为，在当时证据下构成维持垄断的排除性行为。美国司法部随后也公开表示，非法维持操作系统垄断是案件的核心胜诉部分；只是继续追打捆绑指控与谋求拆分，会拖长救济。

2001 年 11 月，司法部与微软达成原则性和解；2002 年 11 月，法院进入最终判决。微软没有被拆开，救济集中于行为约束、接口披露和监督等措施。司法部案件档案至今仍列着 2002 年最终判决、事实认定和后续材料。

法律程序接近结束时，IE 已经占据主导，AOL 也已于 1999 年完成对 Netscape 的收购。诉讼确认了排他分发造成的竞争伤害，却无法自动恢复已经流失的开发者、用户和网站支持。反垄断法可以确定责任并限制未来行为，很难逆转已经形成的网络效应。

案件留下两个需要同时考虑的结论。其一，默认位置、预装合同和平台接口不是无害的产品细节，它们可以成为维护垄断的工具；其二，浏览器与操作系统的技术整合也可能创造真实价值，不能因为产品合并就自动判定违法。二十多年后，监管者审视 Google 的搜索默认协议、Apple 的浏览器选择屏和 AI 助手预装时，仍要在竞争伤害与产品整合的实际价值之间权衡。

市场层面的教训更直接：诉讼往往需要多年，默认设置却会持续影响用户选择和市场份额。

胜利者停下以后，入口搬进了口袋

IE 6 在 2001 年随 Windows XP 到来。此后接近五年，微软没有发布新的浏览器大版本，直到 2006 年 IE 7 才出现。对传统桌面软件来说，五年或许只是一个较长的产品周期；对正在从文档网络变成应用平台的 Web 来说，这段停滞让开发者长期困在兼容问题里。

那时的网站代码里常有专门照顾 IE 的条件注释、CSS Hack 和 ActiveX 控件。企业内部系统把审批、财务、设备管理绑在 IE 特有技术上，政府与学校网站要求用户安装特定插件。最初帮助 IE 获胜的兼容优势逐渐变成包袱：大量客户依赖旧行为，使微软不敢快速改变；浏览器越难升级，客户越会继续按照旧行为开发系统。

把停滞归因于工程师懒惰过于简单。对当时的微软来说，IE 的战略任务已经完成：Navigator 已不足以削弱 Windows 的平台地位。继续把浏览器做得更强、更跨平台，反而可能帮助网页应用替代本地 Windows 软件。对公司最有利的选择，不一定是技术上最激进的选择。微软从追赶者变成市场领先者后，更重视兼容性、企业合同和操作系统地位。

IE 6 的安全问题让停滞显得更严重。浏览器直接处理不可信网页，又能通过 ActiveX 接触本机能力，漏洞与恶意控件的后果远比普通文档阅读器严重。弹窗、工具栏劫持、主页被改、下载器捆绑，成为许多人在 2000 年代早期上网时反复遇到的问题。

与此同时，Netscape 开放的源代码开始发展为 Mozilla 项目和后来的 Firefox。

1998 年 3 月 31 日，Netscape 发布 Communicator 的第一批开发者源代码，Mozilla 项目正式启动。这个决定并没有立刻产生一款成熟产品。旧代码里混杂着商业组件，跨平台架构沉重，团队后来不得不抛弃大量既有实现，重写布局引擎和界面框架。把代码放到网上只是开源的第一步，项目还需要许可证、治理、构建系统、测试、文档和长期维护者。

Mozilla 对“3/31”的回顾记载，团队在短短两个月里清理第三方私有代码，制定 Mozilla Public License，并建立 mozilla.org 作为治理机构。Mozilla Foundation 于 2003 年成立，承接项目的组织与公共使命。Netscape 这家公司已经衰落，它开放的浏览器代码则在非营利组织和开源社区中继续维护。

2004 年 11 月 9 日，Firefox 1.0 正式发布。它没有沿用企业套件的思路，而是专注于提供一款快、清爽、可信、能扩展的浏览器。标签页、弹窗拦截、主题与扩展今天近乎常识，当时却构成了对 IE 体验的鲜明反差。发布前一个月的预览版已经获得超过 800 万次下载；正式版上线两周后，Mozilla 公布 560 万次下载。Firefox 1.0 发布稿强调了产品的开源特征和用户选择。

Firefox 1—4 的界面演化，见证开源浏览器重新挑战 Internet Explorer，并推动浏览器回到标准化竞争。

Firefox 的增长不只靠工程。社区成员自发组织下载活动，在报纸上购买广告，把贡献者名字印进整版页面。对一部分用户来说，安装 Firefox 也意味着拒绝操作系统的默认选择，希望 Web 保持多种实现。2008 年 Firefox 3 发布时，Mozilla 以单日超过 800 万次下载创下吉尼斯软件纪录；到 2009 年前后，它在桌面市场一度逼近三成。

Mozilla 没有重建 Netscape 那样的服务器业务，却迫使微软重新改进 IE。IE 7 加入标签页、反钓鱼和改进的标准支持，IE 8、IE 9 又继续追赶。Firefox 不必长期占据第一，也能通过竞争促使市场领先者改善所有用户的体验。

Mozilla 的资金来源也暴露了独立浏览器的现实困难。维护现代浏览器引擎的成本极高，Mozilla 的主要收入长期来自把某家搜索引擎设为默认的合作协议。一个以保持 Web 独立为使命的组织，需要靠出售默认搜索位置获得资金。用户又不愿直接为浏览器付费，独立浏览器只能在搜索分成、捐赠和订阅服务之间寻找可持续收入。

Firefox 延续了 Netscape 的技术成果，也为 IE 提供了独立竞争者。它同时暴露出另一重限制：没有同等强度的分发渠道和商业支持，优秀引擎可以赢得认可，却未必赢得足够的市场份额。

Safari 与 iPhone：入口从桌面搬到口袋

Firefox 重新挑战 IE 的同时，Apple 也从 Mac 市场进入浏览器竞争。

2003 年 1 月 7 日，Apple 发布 Safari 公测版。它没有沿用微软为 Mac 提供的 IE，也没有直接采用 Gecko，而是以 KDE 社区的 KHTML 与 KJS 为基础开发自家渲染引擎。2003 年 6 月 Safari 1.0 正式发布，Apple 称公测阶段已接近 500 万次下载，并宣布 Safari 将成为新 Macintosh 的默认浏览器。Apple 的 Safari 1.0 发布稿还明确承认其引擎建立在 Konqueror 的开源 KHTML 之上。

这是一种典型的开源软件商业化路径：消费电子公司把桌面 Linux 项目的代码改造成商业操作系统的核心组件。Apple 获得了可控、轻量且能深度优化的引擎，KHTML 社区则要处理大量补丁如何回流、工程目标如何协调的问题。2005 年，Apple 把 WebKit 项目进一步开放。WebKit 博客的时间线把 2005 年 6 月 7 日列为开源节点；随后 Safari 团队开始在公开仓库、邮件列表和博客中与更广泛的开发者协作。

Safari 3.0.1 展示了苹果如何把浏览器纳入操作系统与硬件体验的整体设计。

如果 Safari 只留在 Mac，它可能只是桌面浏览器市场的一种选择。2007 年 1 月 9 日发布的 iPhone 大幅扩大了 Safari 和 WebKit 在移动互联网中的影响。

乔布斯在发布会上把 iPhone 描述为电话、宽屏 iPod 和互联网通信设备的结合。Apple 的官方新闻稿强调，它提供“桌面级”邮件与网页浏览，用户能在手机上看到按原样设计的网页，再用多点触控缩放。WebKit 团队第二天的文章判断，独立、简化的“移动 Web”可能因此逐渐消失：手机不必只访问专为小屏幕制作的简化页面，也可以打开完整网站。

“iPhone is a revolutionary and magical product.”

— Steve Jobs，2007 年 iPhone 发布新闻稿；Apple Newsroom

乔布斯展示第一代 iPhone，浏览器竞争从桌面正式转向移动设备。

移动设备改变了浏览器的竞争规则。桌面时代，默认浏览器主要由 Windows、电脑厂商和互联网接入商影响；移动时代，操作系统、应用商店和主屏幕构成的系统级分发变得更加重要。用户换浏览器不再只是下载一个程序，还受到电池、系统 API、后台限制、默认应用设置以及应用审核规则影响。硬件、操作系统与浏览器的垂直整合更深，体验更顺滑，外部竞争者也更难进入。

WebKit 随 iPhone 和后来的 Android 早期浏览器快速扩散。大量移动网站以 -webkit- 前缀和 WebKit 行为为准，开发者甚至对并非 WebKit 的浏览器也期待同样表现。1990 年代的网站写“只支持 IE”，移动时代的代码则可能默认“有 WebKit 就行”。开放源码没有自动消除实现集中，市场份额仍能把某个引擎的特殊行为变成事实标准。

Apple 在浏览器市场同时促进了技术发展，也限制了引擎竞争。Safari 和 WebKit 推动了触控、移动布局、节能与隐私能力，Apple 又长期要求 iOS 上的第三方浏览器使用 WebKit。用户看见的是 Chrome、Firefox、Edge 等不同品牌，页面渲染却由同一引擎承担。不同品牌仍可在同步、界面与服务上竞争，但不能自由选择引擎。

移动互联网让整个行业看到，掌握浏览器所在的设备和操作系统，比单独掌握一款浏览器更有优势。微软曾借 Windows 控制桌面端分发，Apple 则借 iPhone 把这种优势带到手机上。浏览器从每天使用几次的桌面软件，变成许多人一天打开数百次的移动应用。

2008：Chrome 把网页当成应用，把浏览器当成操作系统

2008 年 9 月 2 日，Google Chrome 测试版上线。它的界面很简单：标签页被放到窗口最上方，地址栏兼任搜索框，菜单被压缩，页面获得更多空间。更重要的变化出现在进程管理、JavaScript 引擎和自动更新机制中。

那时 Gmail、Google Maps、Docs 等应用已经证明，网页不再只是按页阅读的文档。它们持续运行大量 JavaScript，保存状态，响应拖拽，发起异步请求。旧浏览器主要按“打开文档”的需求设计，Google 要解决的却是如何稳定、高效地在浏览器里运行软件。如果一个标签页崩溃就会关闭全部窗口，或者脚本执行长期过慢，Web 应用就很难与桌面软件竞争。

Chrome 的多进程架构把浏览器主体、渲染器和插件拆开。不同网站通常运行在不同渲染进程里，一个页面崩溃不必带走整个浏览器；渲染进程进入沙箱，不能随意访问磁盘、网络或屏幕。Chromium 团队在 2008 年的多进程架构说明里承认这会增加内存开销，却换来响应性、稳定性和安全隔离。今天在 Chrome 任务管理器里结束单个标签页，看似普通的功能，当年代表浏览器从单体程序转向类似操作系统的资源调度器。

V8 则把 JavaScript 直接编译为本机代码，引入高效内存管理、隐藏类和内联缓存，目标是移除限制 Web 应用复杂度的瓶颈。Chromium 的发布记录同时宣布 Chrome、Chromium 和 V8：商业浏览器免费，主要代码以宽松许可证开放，JavaScript 引擎也成为独立开源项目。

Chrome Beta 采用极简界面和多进程架构，在速度、安全与稳定性上带来了明显改进。

Chrome 的商业逻辑与 IE 几乎相反。微软担心浏览器削弱操作系统的价值，Google 则希望 Web 应用强大到足以替代更多桌面软件。用户使用 Web 的时间越长，进行的搜索越多，Google 的广告和在线服务就越有价值。Google 不需要从浏览器许可证赚钱；它需要保证用户能快速访问搜索、广告、地图、邮件和办公套件，并减少其他平台所有者对这些服务的限制。

这套商业模式让 Google 可以长期投入 Chrome。浏览器本身的成本可以由搜索与广告收益承担，工程改进又会增加 Web 的使用量，进而巩固搜索业务。微软用 Windows 收益支持免费的 IE，Google 则用搜索和广告收益支持免费的 Chrome。

分发仍然发挥决定作用。Google 在世界访问量最大的搜索主页上推广 Chrome，把它与其他软件安装包捆绑推荐，又让它在 Android 设备上成为默认或强势预装。性能吸引用户继续使用，搜索主页、软件安装包和 Android 让更多用户接触到它，账号同步与扩展生态则提高了切换成本。只用 V8 解释 Chrome 的成功，会忽略这些分发和服务优势。

自动更新也改变了竞争节奏。旧浏览器大版本常跟随操作系统，企业和用户几年才升级一次；Chrome 在后台自动更新，以更短周期向大量用户发布安全补丁与新功能。开发者可以更快使用新能力，网站又会要求用户使用“现代浏览器”。更新速度本身成为平台优势：新标准先在 Chrome 落地，开发者先围绕它构建，其他浏览器再承受兼容压力。

Chrome 的市场份额增长很快。StatCounter 记录，2011 年 11 月 Chrome 以 25.69% 的全球月度使用份额首次超过 Firefox 的 25.23%，IE 当时仍有 40.63%。到 2012 年 5 月，Chrome 达到 32.43%，第一次在完整自然月里超过 IE 的 32.12%，Firefox 为 25.55%。StatCounter 的当年公告称其从零到世界第一不到四年。

Chrome 的成功不只来自浏览器本身的性能。它把 Web 应用能力、Google 的推广渠道、账号服务和持续更新结合起来。微软曾用操作系统优势保护 IE，Google 则用 Chrome 巩固搜索和云服务。

品牌继续繁荣，引擎开始收敛

Chrome 最初使用 WebKit，但 Google 与 Apple 在进程架构、移植层和项目方向上的需求逐渐不同。2013 年 4 月 3 日，Google 宣布创建 Blink——一个从 WebKit 分叉、服务 Chromium 的开源渲染引擎。官方文章预计，初期就能删除七套构建系统、七千多个文件和超过 450 万行代码。Blink 公告还称，多个独立引擎可以推动创新，并维护开放 Web 的健康发展。

这次分叉在短期内增加了引擎多样性。WebKit 与 Blink 不再受对方的工程需求约束，可以分别针对 Safari 和 Chromium 优化。但此后市场没有出现更多主流引擎，反而有更多浏览器开始采用 Chromium。

Opera 于 2013 年放弃自有 Presto 引擎，转向 Chromium；Samsung Internet、Brave、Vivaldi 等产品也建立其上。2018 年 12 月，微软宣布桌面 Edge 将采用 Chromium，以改善兼容性、减少开发者面对的平台碎片，并把 Edge 更频繁地带到多个操作系统。微软公告写得很务实：与 Chromium 兼容可以简化网站测试矩阵，微软也会向上游贡献 Windows、ARM64、无障碍和硬件相关改进。

浏览器品牌虽多，主流渲染引擎已收敛为 Chromium/Blink、Safari/WebKit 和 Firefox/Gecko 等少数路线。

二十年前，微软通过 Windows 分发和自有引擎击败 Netscape；二十年后，它保留 Edge 品牌、搜索服务和界面能力，却放弃 EdgeHTML，加入由 Google 发起的代码生态。2022 年 6 月 15 日，IE 11 桌面应用在特定 Windows 10 版本上结束支持；部分企业仍可通过 Edge 的 IE 模式维持旧站点。Microsoft 的支持说明标志着 IE 作为独立桌面浏览器退出主流，只保留兼容旧系统的用途。

采用 Chromium 并不等于把一切交给 Google。Chromium 是开源项目，Microsoft、Intel、Igalia、Samsung 等参与者会提交代码，各家浏览器也能修改界面、隐私策略、同步、扩展商店和默认服务。开源降低了共用基础设施的成本，也允许竞争者把精力放到差异化体验。

问题在于，代码允许分叉，不代表新团队有能力长期维护独立版本。现代浏览器引擎包含 HTML/CSS 布局、JavaScript、图形、媒体、网络、安全沙箱、无障碍、字体、开发工具和无数平台适配。分叉后若不能持续合并安全补丁、维护测试和跟进标准，产品很快就无法满足安全与兼容要求。代码可以复制，成熟的维护团队、开发者关系与发布流程却需要长期建立。

网站开发者的测试顺序也会加剧引擎集中。预算有限的团队往往先在 Chrome 测试，再看 Safari，Firefox 和其他环境排在后面。有些网站会使用尚未标准化或支持不均的接口，有些故障只因 User-Agent 字符串不是 Chrome 就触发。独立引擎用户遇到问题后改用 Chromium，网站监测到 Chromium 份额更高，于是投入更少资源测试独立引擎。各团队都在减少当前的测试成本，长期结果却是独立引擎获得的支持越来越少。

截至 2026 年，主流市场还保留三种有分量的引擎：Chromium/Blink、Safari/WebKit、Firefox/Gecko。引擎有三种，浏览器品牌却远不止三个。若把 iOS 上第三方浏览器长期共用 WebKit、桌面大量品牌共用 Chromium 算进去，用户在十几种浏览器之间做选择时，许多产品的渲染和脚本能力其实来自同一套引擎。

2026 年 6 月的全球浏览器使用份额显示，Chrome 的入口优势远高于其他浏览器。

引擎收敛改善了兼容性，降低了开发成本，也让安全更新得以共享，用户不必再面对 1990 年代那种两套网站。与此同时，某一项目的接口决策、扩展政策和性能取舍能影响大多数用户，网站可能把一种实现误当成 Web 本身，独立实现的生存成本也越来越高。

标准之争没有消失，问题只是发生了变化。早期浏览器大战中，两家公司各自推出私有标签，直接造成网页不兼容。今天，Chromium 的高市场份额可能让某些尚未标准化的实现被网站普遍采用，也让只在独立引擎中出现的问题更难被发现和重视。

看不见的工程账单：浏览器为什么很难独立活着

“再造一个浏览器”听上去像一项界面工程：做地址栏、标签页、书签和设置，再选一个渲染引擎。等团队动手，才会发现界面只是维护清单最浅的一层。

浏览器必须处理来源不可控的网络内容。一个普通页面可能同时包含 HTML、CSS、JavaScript、字体、图片、视频、音频、WebAssembly、压缩数据、加密连接和来自几十个域名的嵌入内容。每一种格式都有解析器，每个解析器都可能存在内存错误或边界漏洞。页面还会申请摄像头、麦克风、定位、通知、剪贴板、蓝牙和文件访问。浏览器既要支持复杂应用，又必须把每个页面都当成潜在的不可信内容。

日常维护至少同时覆盖几条看不见的战线：

• 解析与渲染：HTML、CSS、字体、图形和多媒体必须稳定协作；
• 脚本执行：JavaScript 与 WebAssembly 要兼顾性能、调试和隔离；
• 权限与身份：Cookie、密码、支付、摄像头和文件访问不能越界；
• 安全响应：零日漏洞要在多个系统和更新渠道中快速修补；
• 标准兼容：新规范、旧页面和历史 Bug 必须长期共存。

现代安全不再假设所有代码永远没有漏洞，而是用多进程、站点隔离、沙箱和权限系统限制漏洞造成的影响。攻击者即使突破渲染器，还要继续逃出沙箱；一个站点的进程不应随便读取另一个站点的数据；密码、Cookie 和支付信息要与普通页面代码保持边界。这种架构会消耗内存、增加通信开销，也使调试变难，却是浏览器能承载网银、企业后台和个人身份的基础。

安全团队必须全天候响应漏洞。研究者可能在周五晚上报告一个正在被利用的问题，工程师要复现、修补、回归测试，再把更新推到多个操作系统和数亿设备。旧版本仍有人使用，企业策略可能延迟更新，系统商店也有自己的审核周期。新闻往往只写“浏览器发布紧急补丁”，很少提到维护团队为此承担的持续工作。

页面渲染同样复杂。CSS 规范包含布局、动画、字体、颜色、打印、书写方向和响应式规则；JavaScript 引擎需要解释、编译、优化、垃圾回收和调试；图形管线要在不同 GPU、驱动和显示设备上稳定工作；音视频支持牵涉编解码器、硬件加速、数字版权管理与实时通信。一个看似简单的“按钮偏了两像素”，背后可能是字体度量、缩放比例、子像素舍入和旧网页兼容共同作用。

实现标准也不是读完文档照着写。规范存在模糊处，旧页面依赖历史 Bug，不同实现要通过互操作测试对齐。新 API 如果设计错误，一旦网站大规模使用就难以撤回；如果实现太慢，开发者会转向非标准方案；如果某一浏览器抢先上线，其他引擎还要判断是跟进、反对还是等待标准成熟。浏览器工程师既要写代码，也要长期参与标准讨论和兼容协调。

现代浏览器需要同时维护界面、身份权限、标准实现、媒体图形和安全沙箱，用户价格却通常为零。

更难的是，这些成本不会随市场份额同比例下降。Firefox 即使只有几个百分点，也必须正确打开银行、视频会议、在线文档和政府网站；它不能只实现 3% 的 Web。一个新引擎在获得第一个用户前，就要面对近似主流引擎的兼容要求。规模较小意味着测试样本、网站反馈和工程资金更少，需要完成的工作却没有少多少。这是独立引擎必须承担的大量固定成本。

浏览器直接收费又很困难。用户已经习惯免费使用浏览器，系统自带产品也随手可用。若独立浏览器每月收费，它要证明隐私或功能更好，还得说服用户为一种“本来就免费”的基础工具增加开支。企业安全浏览器和订阅服务能找到细分市场，覆盖大众引擎的全部成本仍很难。

于是，几种补贴模式反复出现。操作系统公司用浏览器保护平台与默认服务；搜索和广告公司用它获得查询、数据与流量；硬件公司把它当设备体验的一部分；独立组织出售默认搜索位置，再尝试 VPN、邮箱、密码管理和捐赠。看起来同样免费的产品，资金来源完全不同。资金结构不会直接决定每一项工程选择，却会影响哪些风险更受重视、哪些能力更符合组织利益。

这也解释了为什么“开源一个引擎”无法自动创造竞争。源码解决的是法律可用性，稳定资金、发布渠道、持续安全响应和开发者适配仍要另找来源。Chromium 的存在让许多团队能够造出新浏览器，这是重要的公共价值；同一事实也让维护独立引擎显得更不经济。创业者可以在 Chromium 之上更换界面，加入隐私和 AI 功能，但极少有团队愿意重新实现排版、脚本和沙箱等底层系统。

浏览器引擎的多样性因此具有公共基础设施的性质。市场会奖励规模、默认分发和成本共享，却未必愿意为第二、第三种独立实现付费。只有当主流引擎做出争议决定、扩展政策改变或某类网站失灵时，人们才会意识到独立引擎的重要；等到那一刻再重建一套成熟引擎，往往已经太晚。

一款浏览器能否长期存在，不只取决于发布时的新功能，还取决于几年后是否仍有人出资处理兼容 Bug、零日漏洞和不容易用于宣传的无障碍修复。发布会和市场份额容易获得关注，持续而且难以单独收费的维护工作更能决定产品能否继续发展。

当浏览器开始替人决定世界

早期浏览器争夺怎样显示页面，广告互联网成熟后，竞争又扩展到怎样识别用户。Cookie、本地存储、指纹、跨站脚本和登录状态让网页更好用，也使不同网站上的用户行为可以被关联起来。浏览器处理用户发出的每一次网页请求，因此可以直接决定隐私保护规则。

2017 年，WebKit 推出 Intelligent Tracking Prevention（ITP），使用机器学习和存储限制减少跨站追踪。WebKit 的技术说明用一个第三方域同时出现在新闻站和博客站的例子解释追踪：同一家公司能凭 Cookie 把两个访问连接到同一用户。Safari 改变 Cookie 与存储规则后，广告技术公司必须重新设计归因，网站的登录和嵌入功能也可能受影响。

Mozilla 在 2018 年推出 Enhanced Tracking Protection，2019 年把它默认开放给全球 Firefox 用户，阻止已知第三方跟踪 Cookie 和加密货币挖矿脚本；2022 年又把 Total Cookie Protection 推向全球默认，通过按站点“分罐”限制 Cookie 跨站读取。Mozilla 的公告把这定义为浏览器主动保护用户，而不是要求每个人自己研究复杂设置。

隐私在这里既是道德主张，也是竞争战略。Apple 的收入主要来自硬件和服务，限制跨站广告追踪能强化“隐私设备”的品牌，并削弱依赖外部追踪的广告体系；Mozilla 把隐私作为与 Chrome 区隔的核心；Google 同时经营浏览器、搜索和广告，既需要提升隐私，也必须避免破坏广告业务的经济基础。相同的技术提案，在不同公司的商业模式中会获得不同的优先级。

默认搜索合同是浏览器的重要收入来源。搜索引擎愿意为 Safari、Firefox 或设备上的默认位置支付巨额费用，因为极少数用户会主动修改设置。浏览器获得资金，搜索引擎获得查询，进而产生数据和广告收入，这些收入又可用于购买更多分发渠道。微软案关注“桌面图标在哪里”，移动时代的类似问题则是地址栏默认把搜索请求交给哪项服务。

欧盟《数字市场法》把这种设计细节提升为监管议题。2024 年，欧盟委员会调查 Apple 是否让用户能有效卸载预装应用、改变默认设置并从选择屏中挑选其他浏览器。经过调整，委员会在 2025 年 4 月结束相关调查，称 Apple 已改进 iPhone 的浏览器选择屏，并简化默认应用设置。欧盟委员会公告同时明确表示，委员会还会继续监督这些调整的实际效果。

选择屏不过是一排图标，设计细节却足以左右结果。名单是否随机，何时出现，是否先展示系统浏览器，旧浏览器会不会弹窗挽留，密码和数据能否迁移，第三方引擎能否使用同等系统能力，都会改变选择成本。监管因此开始计算用户要走多少步、换浏览器会失去什么，而不能只看合同里是否写着“用户可以选择”。

浏览器竞争因此转向更细微的系统和界面设计。过去的排他行为容易识别：桌面上不能删除的图标、随机器附带的光盘、与接入商签下的协议。今天，初始设置流程、API 权限、数据迁移、搜索收益分成和默认按钮的颜色都会影响竞争。每个细节都可以单独解释为体验设计，累积起来却能决定一款新产品能否获得最初的一批用户。

从微软到 Google：监管者再次盯上同一条入口飞轮

类似的默认分发争议，后来又出现在 Google 身上。

2020 年，美国司法部起诉 Google 非法维持通用搜索与搜索广告垄断。2024 年，联邦地区法院认定 Google 是垄断者，并通过默认分发协议维持垄断。到了救济阶段，Chrome 成为争议焦点：司法部一度主张剥离 Chrome，因为浏览器是通往搜索的重要入口。2025 年 9 月的救济裁定没有要求出售 Chrome，却禁止 Google 维持若干与 Search、Chrome、Assistant 和 Gemini 分发相关的排他条件，并要求向符合条件的竞争者提供部分搜索数据和搜索、广告联合服务。

美国司法部对救济结果的说明称，Google 多年处理美国约九成搜索查询，通过在数十亿设备和电脑上取得预设默认位置形成自我强化循环。裁定禁止用一个 Google 应用的许可或收益分成，换取另一个应用被预装、摆放或长期保持默认，也不得阻止合作伙伴同时分发其他搜索、浏览器或生成式 AI 产品。最终判决于 2025 年 12 月进入，2026 年案件档案已开始记录技术委员会和合规状态。

这与 1999 年微软案的事实认定有明显相似之处。微软用 Windows 的垄断利润和分发权保护操作系统的应用壁垒；Google 用搜索垄断利润购买默认位置，巩固搜索、广告与数据业务。微软担心浏览器成为新的应用平台，Google 则已经让浏览器成为自家服务的重要入口。两案的产品、时代和法律细节不同，商业循环却相近：上游业务产生利润，利润购买或控制入口；入口带来更多用户与数据，规模改善服务并吸引开发者；服务最终又巩固上游业务。

监管也面对同样难题。Chrome 与 Google 的其他业务高度关联，很难在不影响其他服务的情况下单独剥离。Chromium 是庞大开源项目，浏览器与账号、密码、安全更新、搜索、企业策略、Android 和开发者工具交织。强制剥离可能创造独立的浏览器业务，也可能给安全维护与商业可持续性带来风险；只限制合同更稳妥，却未必足以逆转已经形成的规模优势。

更麻烦的是，消费者确实喜欢许多整合带来的便利。地址栏直接搜索、账号同步密码、恶意网站拦截、地图和日历联动，都能提高使用效率。反垄断并不要求惩罚规模或故意降低产品体验。它要分辨哪些整合来自创新，哪些合同或系统限制使同样有能力的竞争者得不到公平的分发机会。

微软案表明，案件结束时市场可能已经完成迁移；Google 案又遇到 AI 对浏览器功能的改变。若用户不再从十条蓝色链接中选择结果，而是由浏览器里的模型直接给出答案、跨标签页总结并代为操作，那么只审查“默认搜索引擎”已经不够。浏览器内置的助手、记忆功能和 Agent 权限也会影响入口竞争。

2025—2026：AI 浏览器把解释权升级成行动权

2025 年，浏览器行业出现了一批加入生成式 AI 的新产品和新功能。各家宣传口号不同，目标却高度一致：让浏览器从“显示网页的工具”变成“理解上下文并完成任务的助手”。

Perplexity 于 2025 年 7 月 9 日推出 Comet。官方把它描述为从“导航到认知”、从“答案到行动”的转变：用户可以要求助手比较商品、理解当前页面、整理标签页、安排会议、发送邮件或购买物品。Comet 发布文章把浏览器说成人类意识的延伸；到 2026 年的帮助文档里，它仍明确是一款基于 Chromium、整合 Perplexity AI、支持大多数 Chrome 扩展的浏览器。

Google 在 2025 年 9 月宣布把 Gemini 深度放进 Chrome。它能解释当前页面、跨多个标签页比较信息、回忆过去看过的网站，并与 Calendar、YouTube、Maps 等服务联动；Google 还预告 Agent 能力，让 Gemini 代办预约理发、每周买菜等任务。Google 的官方说明把这称为 Chrome 历史上最大的一次升级。

OpenAI 于 2025 年 10 月 21 日推出 ChatGPT Atlas，一款以 ChatGPT 为核心、最初面向 macOS 的浏览器。它引入可选的浏览器记忆、页面可见性控制与 Agent Mode，希望利用用户正在浏览的上下文进行研究、规划和操作。Atlas 发布稿还专门讨论了登录网站、隐藏恶意指令和敏感操作带来的风险。

但 Atlas 很快发生了重大调整。2026 年 7 月，OpenAI 宣布将停用 Atlas，把浏览器 Agent 能力转移到 ChatGPT 与 Codex；Atlas 计划在 2026 年 8 月 9 日停止工作，用户需要提前导出书签和重要页面。官方迁移说明距离 Atlas 上线还不到十个月。

Atlas 的短暂生命周期不等于 AI 浏览器没有前景，却说明维护一款完整浏览器十分困难。加入模型侧边栏只是其中一项功能，团队还要处理安全响应、站点兼容、密码与 Cookie、扩展、企业策略、多系统更新、默认迁移和用户信任。即使拥有强模型与巨额算力，浏览器仍是一项成本很高的基础设施业务。新公司通常借 Chromium 降低引擎成本，再在界面、记忆、Agent 和服务连接上展开竞争。

AI 浏览器可以读取当前页面、理解多个标签页、调用浏览记忆和账号信息，并替用户执行操作；获得的权限越多，相应风险也越高。

AI 不只是给浏览器增加聊天按钮，也扩大了浏览器可以替用户决定的范围。传统浏览器主要有三种控制能力：渲染、导航与存储。AI 浏览器又增加了两种能力：解释能力，决定哪些信息被摘要、排序和呈现；行动能力，代替用户操作登录后的网页。

浏览器的解释能力会改变内容分发和商业模式。用户若只读模型摘要，出版者可能失去访问量和广告收入，搜索结果里的来源也可能被放到答案之后。模型会先摘要和筛选网页内容，再决定向用户展示什么。网页过去争夺搜索排名，未来还要争取被模型引用、被 Agent 采用，以及在答案中保留来源。

浏览器开始替用户执行操作后，风险会更加直接。一个能代替用户下单的浏览器，需要读取页面、知道偏好、访问账号、填写地址，甚至调用支付。它可以省掉几十次点击，也把几十个原本分散的权限集中给一个 Agent。网页里隐藏的 Prompt Injection 可能误导模型，错误理解可能导致真实交易，跨标签页上下文可能把工作与私人信息混在一起。过去浏览器漏洞会让攻击者执行代码，AI 浏览器即使没有被攻破，也可能因为误解指令而执行错误操作。

安全设计因此不能只靠一个总开关。必要的保护应拆成可理解、可撤销的层级：

• 按站点控制页面是否对模型可见；
• 允许用户查看、删除或完全关闭浏览记忆；
• 金融、医疗、发送与购买等敏感操作提交前再次确认；
• 隔离 Agent 会话与普通浏览，限制跨标签页读取；
• 明确区分原页事实、模型摘要与模型推断。

OpenAI 在 Atlas 发布时禁止 Agent 下载文件、安装扩展或访问其他本机应用，并让它在部分敏感网站暂停等待用户；这些限制说明，代替用户操作需要更严格的权限控制。

AI 浏览器还会增加新的默认设置。过去争的是默认浏览器和默认搜索，接下来可能争默认模型、默认 Agent、默认记忆服务与默认支付方式。Google 能把 Gemini 接入 Chrome 与自家服务，Microsoft 能把 Copilot 放进 Edge 与 Windows，Apple 能在设备和 Safari 层整合系统智能，新公司则要说服用户把完整浏览历史和账号信息迁移到陌生产品。除了维护浏览器，新公司还要承担模型运行、权限控制和 Agent 安全等成本。

Atlas 的迅速退场提醒市场：AI 可以扩展浏览器的功能，却不会消除这个行业原有的困难。引擎维护成本高，更换默认浏览器不容易，用户信任需要长期建立，平台所有者仍掌握很强的分发能力。模型可以在几个月内快速迭代，浏览器市场的分发格局却很难在同样短的时间里改变。

谁在编辑 Web：三十六年后，历史回到原点

浏览器历史常按市场领先者的更替来写：Mosaic 推动普及，Netscape 率先占据市场，IE 取代 Netscape，Firefox 重新带来竞争，Chrome 又成为主流，如今 AI 浏览器开始加入竞争。只看排名变化，容易忽略每个阶段反复出现的共同机制。

这些共同机制没有根本变化。图形界面、跨平台脚本、标签页与扩展、移动触控、V8、多进程和 AI Agent 等技术突破，可以让新产品获得关注。产品能否接触大量用户，则取决于 Windows 预装、搜索主页推广、Android 与 iPhone、应用商店、账号同步和企业策略。网站适配、扩展、标准实现、内部系统和用户数据又会提高切换成本。用户规模扩大后，浏览器还要服务于公司更重要的操作系统、搜索、硬件或 AI 业务。

Netscape 希望 Web 应用降低开发者对 Windows 的依赖，于是微软把浏览器变成 Windows 的一部分；Google 希望 Web 应用成为主流，于是 Chrome 成为搜索与云服务的基础；Apple 希望控制设备体验，于是 Safari 与 WebKit 成为移动平台规则的一部分；AI 公司希望获得用户任务的上下文，于是浏览器又被定义为 Agent 的运行环境。各家公司都从自身业务出发作出选择，这些选择共同影响了 Web 的发展方向。

开放与控制可以同时存在。Web 协议开放，浏览器市场可以高度集中；Chromium 代码开放，主要维护力量与分发渠道仍可集中；标准公开，网站的实际兼容性仍可能由主流引擎决定；用户可以选择，默认设置仍会影响绝大多数行为。判断生态是否健康，不能只看许可证，还要看竞争产品能否接触用户、独立引擎是否有资源实现标准、数据是否容易迁移、默认设置是否容易改变。

这段历史也说明，产品质量并不单独决定市场结果。差产品很难长期占据主流，优秀产品也不会自动接触到用户。IE 必须先达到可用水平，分发优势才会生效；Firefox 足够优秀，却缺少同等规模的商业和设备渠道；Edge 换用 Chromium，反映出独立引擎的维护成本和兼容压力；Atlas 拥有强大的模型，仍因浏览器基础设施和分发困难而迅速收缩。

竞争政策也不能只在市场高度集中后检查价格。浏览器常年免费，竞争受损不会以涨价的形式出现，却会留下其他痕迹。技术路线变少，网站只能适配一种引擎，用户数据默认流向某项服务，竞争者为默认位置支付越来越高的费用。AI 助手甚至可能在用户看见来源以前，就完成解释和选择。监管免费产品时，需要关注选择、质量、隐私、互操作性，以及后来者能否接触用户。

回到 1990 年那台 NeXT 电脑，WorldWideWeb 既能读，也能写。伯纳斯-李最初设想的 Web，不是少数平台单向发布内容，而是人们通过链接共同编辑知识。后来，浏览器的阅读和消费功能越来越完善：加载更快，视频更清晰，支付更方便，推荐更准确。现在 AI 又把改写页面、归纳资料、填写表单和连续操作等能力带进浏览器。

“The most important thing about the World Wide Web is that it is universal.”

— Tim Berners-Lee，2002 年纪念演讲；W3C 演讲文本

区别在于，早期编辑器把笔交给人，今天的 Agent 会先替人落笔。

也许下一场浏览器战争最重要的问题，不是谁的跑分最高，不是谁加入的 AI 功能最多，甚至不只是哪个引擎占比更大。更难回答的是：当浏览器能够理解你看过的页面，记住你的需求，并用你的身份在网上操作时，哪些事情可以由它自动完成，哪些事情必须由用户本人确认？

三十六年前，浏览器等待用户输入网址。现在，一些浏览器已经开始等待用户交给它一个任务。这个变化带来的便利、风险和控制权，将成为下一轮竞争的核心。

资料来源

Web 的诞生、Mosaic 与开放标准

• CERN：Web 软件进入公共领域、Web 的诞生
• W3C：W3C 与早期 Web 历史、Web at 25 历史节点与开放原则、浏览器战争与标准化
• NCSA：NCSA 历史与 Mosaic
• Computer History Museum：Browser Wars

Netscape、Internet Explorer 与微软反垄断案

• 美国司法部：微软案法院事实认定、微软浏览器与中间件案件档案、2001 年上诉结果与后续安排
• 美国联邦上诉法院判决镜像：United States v. Microsoft, 253 F.3d 34
• Mozilla：Mozilla 项目历史、“3/31”开源二十周年回顾、Firefox 1.0 发布

Safari、移动互联网、Chrome 与引擎演化

• Apple：Safari 1.0 发布、第一代 iPhone 发布
• WebKit：项目开源早期记录、Safari 与 Web Inspector 时间线、iPhone 上的 Safari
• Chromium：Chrome、Chromium 与 V8 的 2008 年发布记录、多进程架构、Chrome 沙箱、Blink 引擎公告
• StatCounter：Chrome 2011 年首次月度超过 Firefox、Chrome 2012 年首次完整自然月超过 IE、2026 年 6 月全球浏览器使用份额
• Microsoft：Edge 转向 Chromium、IE 11 支持终止

隐私、默认分发、监管与 AI 浏览器

• WebKit：Intelligent Tracking Prevention
• Mozilla：Enhanced Tracking Protection 默认启用、Total Cookie Protection 全球默认
• 欧盟委员会：Apple 浏览器选择屏调查结束与后续监督
• 美国司法部：Google 搜索垄断案救济结果、案件档案与 2026 年合规材料
• Google：Gemini in Chrome 与 agentic browsing
• Perplexity：Comet 发布说明、Comet 2026 使用说明
• OpenAI：ChatGPT Atlas 发布、Atlas 停用与能力迁移说明

数据口径说明：文中当代份额采用 StatCounter 监测网络中的页面浏览量估算，适合观察使用趋势，不应等同于精确装机量或独立用户数。早期浏览器份额来自法院、公司和分析机构在不同时间采用的估计，已在正文中尽量标明来源与口径。

两个约翰把夜班变成了未来

1996 年 8 月 7 日，约翰·罗梅洛在自己的 .plan 文件里公布了一条消息：他决定离开 id Software。

所谓 .plan，原本只是 Unix 系统里一小块供人查看近况的文字。到了九十年代的游戏圈，它差不多成了程序员的个人广播站。玩家会用 finger 命令追踪开发者更新，今天修了什么 bug，服务器出了什么毛病，新游戏做到哪一步，都可能从那几行纯文本里先漏出来。没有精心剪辑的告别视频，没有公关团队替创始人打磨每个标点。罗梅洛写道，他要创办一家目标不同的新公司，不会带走 id 的员工。

第二天，约翰·卡马克也更新了自己的 .plan。他确认罗梅洛已经离开，又说公司以后应该少讲那些宏大的未来计划，多展示真正做出来的东西。字面上没有骂人，甚至克制得像一次普通的人事变动。对一路追着 id 更新的玩家来说，一段时代结束了。

这两个人此前一起做过《Commander Keen》《Wolfenstein 3D》《DOOM》和《Quake》。他们把原本不被主机厂商放在眼里的 PC，变成了速度、暴力、网络对战和玩家改造的实验场。《DOOM》发布后，Doom clone 一度就是整个第一人称射击品类的通称。等到两人分开时，他们都还不到三十岁。

后来流行的剧本把两人压成了一组好记的对照：卡马克是只认代码和工作量的冷酷技术机器，罗梅洛则是沉迷宣传、跑车和死亡竞赛的长发摇滚明星。故事接着按这组性格分配结局：埋头造引擎的工程师赶走忙着做人设的设计师，《Daikatana》的失败与 3D 图形的成功又为两人分别补上惩罚和奖赏。

这个版本特别好记，也特别适合拍成预告片。

问题是，它只对了一半。

卡马克在 2022 年的长访谈里确实承认自己推动罗梅洛离开。他也确实曾因罗梅洛在《Quake》期间没有按自己的期待投入工作而愤怒。可他紧接着又补充，罗梅洛并非什么都没做：他做了若干最好的关卡，处理 Raven 等外部合作，在《DOOM》和《Quake》里留下了极深的印记。谈起两人初识，卡马克甚至说，罗梅洛是自己见过“最酷的程序员”——会写代码，会画图，会做地图，会做声音，几乎什么都能来。

“I did push Romero out of the company.”

— John Carmack，2022 年谈 1996 年 id 分裂；Lex Fridman Podcast #309

三十年后，两人也没有按“宿敌”剧本生活。见面时会聊天，罗梅洛还问过卡马克是否愿意在 AI 与游戏方向合作。2023 年《DOOM》三十周年，他们共同参加直播，讨论当年那些快得来不及想明白的决定。到 2026 年，卡马克又公开承认，《Quake》时自己把所有人逼得太紧，没有理解一家成熟公司必须留出余量。

好人坏人这套分法解释不了这段关系。更麻烦、也更接近现实的解释是：两个能力重叠、性格不同、又恰好互相需要的年轻人，在几年里做出了改变行业的游戏；那套能在创业阶段创造奇迹的合作方式，却无法陪他们走进下一阶段。

别急着把他们叫作“程序员和设计师”

人们回看成功团队时，很喜欢给每个人发一个词。卡马克拿到“技术”，罗梅洛拿到“设计”。这样分工清晰，写起来省事，读者也不容易认错人。

可 1990 年前后的 PC 游戏小团队没有这么豪华。没有一排细分工种等着填，也没有“创意总监只负责愿景”的职位说明。一个人上午改绘图程序，下午摆关卡，晚上处理声音，第二天还得跟发行商解释为什么软盘里有个文件读不出来。所谓职位，往往只是“这件事眼下谁能做”。

罗梅洛早年就在写程序，而非站在程序员身后喊创意。他从 Apple II 时代开始做游戏，长期研究别人的程序怎样实现画面和动作。卡马克回忆，罗梅洛曾给自己定过一个近乎顽固的练习：按照英文字母表，从 A 到 Z，每个字母做一款游戏。作品未必都值得留下，但这套练习让他形成一种全栈直觉。代码、工具、图像和关卡在他眼里并非四个部门，它们是玩家按下一个键以后同时发生的事情。

卡马克同样不是对玩法毫无兴趣的引擎供应商。《DOOM》的武器响应、敌人状态、世界交互，有相当一部分核心代码出自他手。他会为了“这个东西在 386 上能不能跑”删掉昂贵功能，也会为了想要的战斗速度重写系统。具体数值的性格主要由罗梅洛反复调校，卡马克交出的也远远不止一台技术演示机。

两人的差别，后来主要体现在精力投向的层级不同。

卡马克越来越关心底层能力：PC 怎样平滑卷轴，怎样快速绘制有纹理的墙，任意角度的空间怎样在普通机器上保持速度。他还要把两台电脑连起来，再把完整三维世界塞进下一代引擎。问题只要能被测量，他就会持续削掉多余部分，直到机器交出答案。

罗梅洛更在意这些能力到了玩家手里是什么感觉。角色该跑多快？霰弹枪一次开火后，停顿多久才够沉？转过一个墙角应该立刻遇敌，还是先从窗里看见远处的钥匙？什么时候让玩家狂奔，什么时候让他停下来读懂空间？他还很会演示。Dave Taylor 后来回忆，第一次看罗梅洛展示早期《DOOM》引擎时，画面里甚至还没有怪物，可流畅移动和纹理已经足够震撼；而罗梅洛本人带着节奏的讲解，几乎占了冲击力的一半。

可以把卡马克理解为不断扩展游戏能做什么的人，把罗梅洛理解为立刻追问玩家现在能玩到什么的人。两条线在《DOOM》里靠得极近。

也正因为靠得太近，分开时才会扯得那么疼。

罗梅洛的“全面”与卡马克的“深入”

用今天的大公司职级去套两人，很容易误判他们早期的价值。

罗梅洛的强项是完整。他看到一款游戏时，不会只看某个系统有多聪明，而会本能地追踪从按键到画面、从工具到关卡、从文件打包到玩家拿到手的整条链。早年大量小作品训练出的也是这件事：规模可以小，作品必须闭环。能启动，能玩，能结束，最好还有一点让人记住的性格。

卡马克的强项是深入。他会抓住那个阻止作品前进的技术瓶颈，长时间把注意力压在上面。横向卷轴为什么不顺？墙面为什么画不快？网络里的状态怎样同步？他不太在意问题属于哪种职位，只在意是否存在一个更简洁、更高效的解法。

全面型制作者常被误解成“什么都懂一点，所以没有最强项”；深入型制作者又容易被神化成“只要底层问题解决，产品自然会成功”。《DOOM》恰好证明两种判断都不对。罗梅洛把分散能力收成一条玩家体验，卡马克让原本够不到的能力真的可用。少了前者，引擎可能只是一份惊人的技术演示；少了后者，设计者能想象的空间仍被旧机器卡住。

他们还共享一项经常被忽略的能力：两人都能判断“酷不酷”。商业计划书里没有这个指标，它却是早期 id 最快的决策工具。一个原型放到屏幕上，移动是否让人兴奋，武器是否有力量，技术是否带来此前没有的体验，团队很快就能形成判断。

问题也藏在这个词里。“酷”适合筛选原型，不适合处理股权、排期和人员疲劳。等公司从一群朋友变成复杂组织，同一种直觉很难继续回答谁该负责、做多久、何时停止。

什里夫波特：每个月必须交一款游戏的训练营

故事没有从硅谷开始。

两人在路易斯安那州什里夫波特相遇。这里远离九十年代游戏工业中心，Softdisk 也只是一家经营磁盘杂志的普通公司：订户定期收到一张软盘，里面装着软件、工具和小游戏。对编辑部来说，内容要按月出现；对开发者来说，这意味着灵感再伟大，也必须在截止日期前变成能启动的文件。

卡马克后来把这段经历视为极重要的训练。团队每个月都要做游戏。没有几年预研，没有“等引擎成熟”，也没有把一次失败解释为艺术探索的空间。选一个规模可控的点子，写代码，做美术，摆关卡，测试，交付。下个月再来一次。

月度交付把开发压成一条反复运行的生产线：

1. 选一个当月能做完的核心点子；
2. 尽快做出可操作的原型；
3. 用工具、美术和关卡把原型闭环；
4. 在真实机器上测试、删功能、修问题；
5. 按时交付，再把经验带进下一个月。

这套节奏很残酷，却让年轻开发者迅速看见彼此的能力。卡马克第一次遇见罗梅洛和 Lane Roathe 时，惊讶于终于有人知道许多自己不知道的“酷东西”。罗梅洛也很快明白，眼前这个安静、执拗的程序员在图形技术上跑得有多快。

后来 id 内部形成一种被成员称为 productiv-ocracy 的文化：谁持续交付，谁就拥有更大的自由。它不是写在员工手册里的制度，更像一群年轻人自然长出的排序方式。头衔不值多少钱，能在屏幕上拿出东西才值钱。

这种文化在小团队里威力惊人。新主意不靠三小时会议争出胜负，而是尽快做成可玩版本。罗梅洛迅速拼起完整体验，卡马克解决看似做不到的底层问题，Tom Hall 提供大量角色与世界设定，艾德里安·卡马克和其他美术成员再把粗糙原型变成有性格的画面。每个人都能直接看到自己的工作怎样进入成品。

它也埋下一颗延时炸弹。

当“持续交付”成为团队唯一可信的道德标准，工作方式的差别很容易被解释成人品差别。代码和地图容易计数，授权洽谈、对外演示、社区维护和方向思考却很难在同一张表里对齐。创业初期，所有人挤在一个空间里，贡献还能被直接看见；公司长大、项目变复杂后，“谁在真正工作”就成了一场关于计量方式的争论。

Softdisk 教会他们快速做完游戏。它没教会他们怎样经营一家会持续十年、二十年的公司。

治理当时排不到前面。二十出头的年轻人刚发现，自己可能比雇主更懂下一代 PC 游戏。眼前最急的问题，是怎样把公司机器留到晚上，做自己的东西。

每月一款游戏，练的不是手速

月度交付训练的核心，是判断什么值得做完。

开发者总能想到更多功能。角色可以再加动作，敌人可以更聪明，地图可以更长，工具可以更漂亮。截止日期逼着团队把“好点子”与“这一版必须有”分开。删错了，游戏失去趣味；舍不得删，软盘到期仍交不出去。

这种训练后来深刻影响《DOOM》。团队会不断问：分数真的需要吗？有限命数能增加什么？复杂叙事是否值得打断移动？一个系统若不能让跑、射击、探索和恐惧更强，就很难保住位置。删掉这些东西并不代表开发者天生信奉极简，而是他们见过太多项目怎样被没有完成的功能拖死。

月度节奏还缩短了争论。某个成员坚持一种做法，几天后就能在可玩版本里验证。判断错了，下个月修；判断对了，立刻变成团队经验。相比写一份预测玩家反应的长文档，这种反馈粗糙，却异常直接。

《Quake》打破了这个训练环境。底层技术需要很长时间才能稳定，内容决策无法在一个月内看到完整后果。许多争论悬在那里，等几个月后再验证，代价已经变大。早期 id 练成了高速冲刺，却没有练过一场路线持续变化的马拉松。

这也是为什么同一批人在《DOOM》里像心有灵犀，到《Quake》却开始互相怀疑。能力没有一夜消失，反馈周期变了。

夜里“借”来的电脑，滚出了《Commander Keen》

1990 年，PC 在动作游戏面前多少有点抬不起头。

任天堂主机上的《超级马力欧兄弟》能让画面随角色平滑移动，地面、砖块和敌人像一整片世界从屏幕旁边滚进来。DOS PC 的显示和内存结构却不友好，许多同类游戏只能一屏一屏切换，或者滚得磕磕绊绊。玩家当然能在 PC 上玩动作游戏，只是很难得到主机那种顺滑感。

卡马克盯上了这个问题。

他的关键思路后来被称为自适应图块刷新：屏幕移动时，不必把整帧所有像素重新画一遍，只更新新露出来或发生变化的部分。说得通俗些，搬家时没必要每走一步都把整间屋子重新装修。保留没变的，把边缘缺的补上，机器的负担就会小很多。

他和团队做出一个演示，把《超级马力欧兄弟 3》第一关的效果搬到 PC 上。罗梅洛早晨看到屏幕平滑滚动，这段演示很快从技术试验变成新项目：PC 动作游戏的边界被推开了一块，他们能把这块能力做成自己的游戏。

接下来那段经历很有创业神话的味道，也确实不怎么体面。团队在夜间使用 Softdisk 的机器制作新项目，把设备搬去工作，再想办法放回去。卡马克 2022 年回看时毫不浪漫地说，这在法律和商业上是个糟糕计划。你可以佩服年轻人的胆量，但没必要把占用雇主资源包装成纯洁的车库精神。

项目后来变成《Commander Keen》。Tom Hall 提供外星冒险、角色和大量创意，卡马克负责关键技术，罗梅洛横跨程序、关卡、工具与整体制作。他们没有走传统零售发行的路，而是找到 Apogee 的 Scott Miller。

Miller 联系罗梅洛的方式很像低成本谍战剧。他知道直接寄商业邀约可能被 Softdisk 管理层截住，于是用不同假名写了多封“粉丝信”，让罗梅洛误以为各地玩家都在关注作品。等双方建立联系，他抛出 Apogee 的 shareware 模式：把第一部分免费放出去，玩家喜欢，再付钱购买后续章节。

这套模式极适合 id。免费章节不只是缩水试玩版，而要好玩到足以让玩家主动复制给朋友。每个玩家都能成为分发节点，Apogee 负责订单和后续章节，开发团队不必先说服大型零售商把纸盒摆上货架。

《Commander Keen》上线后，收入很快证明路走通了。卡马克多年后回忆，项目一度迅速带来每月约三万美元。这个数字来自当事人口述，不是审计报告，但对几位领固定薪水的年轻人而言，哪怕打个折，也已经足够说明一件事：他们可以离开 Softdisk。

id Software 的早期基因就这样写下了几行：技术突破要立刻变成能玩的东西；免费内容负责传播；小团队不等发行商批准；交付比头衔重要。

后来成就他们的，后来伤害他们的，都在里面。

他们不是从一开始就势均力敌

创业故事喜欢描写两位天才一见如故，仿佛从握手那刻起就知道彼此会改变世界。真实合作没那么整齐。

初识时，罗梅洛的经验更宽。他做过许多完整小型游戏，熟悉从代码到画面的整条链路，也知道怎样让项目按期完成。卡马克在某些技术方向上极强，却没有罗梅洛那么丰富的成品经验。卡马克后来回忆，罗梅洛让他第一次感觉自己遇到了一位“更酷的程序员”。这句话很重要，因为它戳破了后来的倒叙幻觉：卡马克并不是带着“未来图形教父”的铭牌走进办公室，罗梅洛也不是一开始就退居创意岗位。

变化发生得很快。

卡马克把越来越多时间压进纯编程和底层系统，他的优势开始变得异常突出。平滑卷轴之后是更快的伪三维，再之后是网络、BSP 和完整多边形世界。每攻下一个问题，下一道更难的墙已经出现。他愿意长时间独自追踪性能瓶颈，也愿意为了更干净的结构把大段代码推倒重来。

罗梅洛没有在同一条跑道上跟他死磕。他逐渐把位置挪到工具、设计、关卡节奏、项目方向和对外连接上。与其说他“编程比输了，只好改行”，不如看团队当时缺什么：有人必须把卡马克造出的能力转化成可生产内容的系统，再把作品展示给玩家和合作伙伴。

可身份变化也带来一个危险。

底层代码容易留下明确作者，关卡文件也能点名，但“让整个游戏更像它自己”的工作很难拆账。速度数值改了多少，武器反馈试过几轮，哪些规则被删掉，哪场演示让新员工理解目标，哪次对外交流带来合作，这些贡献散在产品里。成功时大家觉得自然，冲突时却容易被压缩成一句：“你最近到底做了什么？”

卡马克和罗梅洛早期互补，并不是因为两人各守一块、互不越界。恰恰是因为他们都懂对方在做什么，又愿意让最擅长的人继续向前。卡马克能理解关卡为何需要技术支持，罗梅洛能理解某种设计为什么在硬件上太贵。讨论可以直接落到可运行版本。

这种默契有一个前提：两人必须对“现在最重要的问题”看法一致。

《Commander Keen》时，问题是 PC 能不能像主机那样滚动。《Wolfenstein 3D》时，问题是能不能让速度压倒复杂性。《DOOM》时，问题是能不能让一个更自由、更凶猛的世界跑在普通 386 上。

到了《Quake》，问题忽然多得没有一个共同答案。

《Wolfenstein 3D》：先把门踹开

在《DOOM》之前，id 先用《Wolfenstein 3D》证明了另一件事：PC 玩家想要的未必是更复杂的规则，也可能是更直接的速度。

第一人称视角并非 id 发明。《Maze War》《Spasim》以及更早的迷宫、模拟作品已经探索过从角色眼睛看世界；id 自己也做过《Hovertank 3D》和《Catacomb 3-D》。这次的变化，是他们把这种视角、纹理墙面、快速移动、即时射击和 shareware 传播压成了一款极容易理解的产品。

《Wolfenstein 3D》的世界受限很大。墙壁沿规则网格排列，空间大多是等高的直角走廊，没有《DOOM》后来那种高低变化、斜向墙面和开阔区域。可限制带来速度。玩家不必研究复杂系统，推门，找钥匙，扫射敌人，听见守卫喊叫，继续往前。

这像一支只会演奏几组和弦、却把音量拧到最大的乐队。

罗梅洛很清楚速度就是作品的性格。他做地图、调节节奏，也负责把成品带到人面前。卡马克则持续删掉不值得机器付费的东西，让渲染足够快。艾德里安·卡马克等美术成员提供敌人、武器与血腥画面，Bobby Prince 的声音和音乐把抽象走廊变成有威胁的空间。

游戏通过 Apogee 在 1992 年发行，免费章节沿公告板和软盘复制扩散。id 的收入与知名度迅速增长，年轻创始人开始买昂贵汽车，办公室文化越来越像一支突然走红的摇滚乐队。罗梅洛的长发、外向性格和对玩家的热情，天然适合站在前台；卡马克更愿意回到电脑前解决下一个问题。

外界常把这种差异写成冲突的起点。其实此时它仍是优势。乐队需要有人写出新声音，也需要有人把舞台点燃。成功来得太快，公司还没学会怎样把个人威望转化成稳定分工，这才是隐患。

《Wolfenstein 3D》还给卡马克留下一个不满。它的设计空间有一堵硬墙。规则网格带来速度，也限制地图。你可以重新安排走廊，却很难创造真正令人迷路的层次、角度和高低落差。卡马克后来形容，《DOOM》跨过了一条“足够自由”的边界：一旦空间表达超过那个阈值，几十年后人们仍能做出开发者从未想过的新关卡。

下一款游戏不能只是更多纳粹、更大迷宫。

他们要把墙拆掉。

一份太丰富的《Doom Bible》

新项目一开始并不叫一套极简规则。

Tom Hall 为它写了厚厚的设计文档，后来被称为《Doom Bible》。里面有人物身份、剧情关系、物品、场景和相对复杂的叙事构想。Hall 擅长创造明亮、古怪、有角色感的世界，《Commander Keen》已经证明了这一点。他希望新游戏也有可理解的主角与故事。

卡马克对故事的态度后来被浓缩成一句流传极广的话：游戏里的故事像色情片里的故事，应该有，但没那么重要。句子够狠，也遮住了一部分实际争论。Hall 与其他成员争的并非“游戏能不能有剧情”这么抽象，而是团队应该把有限时间投到哪里，以及新引擎最能放大什么体验。

早期原型不断告诉他们，速度、武器、恶魔和空间探索比人物设定更有力量。玩家看不见文档里写得很完整的背景，却会立刻感到一扇门打开后怪物从侧面包过来；一项复杂道具系统需要开发和解释，一把霰弹枪的声音与停顿却能在半秒内让人明白它有多凶。

罗梅洛逐渐主张删掉与核心循环无关的东西。命数、分数、没有明确用途的收集物，都可以拿走。玩家跑、看、开火、躲避、寻找钥匙和秘密。每套机制都要帮助这个循环加速或改变节奏。

Hall 的设计与项目实际方向越来越远。到 1993 年，他离开 id。后来讲这段历史的人有时把他写成一个不懂动作游戏的落伍者，这不公平。《Doom Bible》里的不少名字、地点和想法仍以变化后的形式进入成品，Hall 后来也在其他项目里证明了设计能力。冲突的核心是方向，不是智力。

但 id 当时没有一套能让方向冲突被温和消化的机制。

小团队的决定方式很直接：哪个版本玩起来更有力，谁持续做出能用的内容，谁就获得更大话语权。它高效得像一把锋利的刀，也确实会伤人。Hall 的离开让团队失去一位创始成员，同时释放了项目方向。《DOOM》不再试图把科幻角色扮演、叙事冒险和射击一次装进同一张软盘。

他们保留了最有感觉的部分：火星基地、传送实验、地狱生物、一个孤身杀出去的士兵。名字则来自卡马克喜欢的一段电影台词。《金钱本色》里，有人问箱子里装了什么，对方答：“这里面？Doom。”

无需解释太多。门一开，东西自己会说话。

别说《DOOM》发明了 FPS

1993 年 12 月 10 日发布的《DOOM》不是第一款第一人称射击游戏，也不是第一款三维游戏。

把“第一”拿掉，并不会削弱它。反倒能让真正的贡献显出来。

此前的作品已经有第一人称迷宫、射击、纹理墙面和网络实验。id 自己的《Wolfenstein 3D》也早一年半把快速第一人称动作送到大量 PC 玩家手中。《DOOM》做的，是把一组分散存在的可能性压成一个足以改变玩家习惯、开发方式和商业传播的完整整体。

它给空间增加了高低差、斜向墙面、楼梯、升降平台、远处可见的区域和更复杂的光照。它让怪物互相误伤，让不同敌人的移动方式在狭窄空间里产生混战。它把近距离霰弹枪、远处火球、开门声、隐约的怪物吼叫和重金属气质的音乐叠在一起。它让两名或更多玩家通过局域网合作，也允许他们转身互相猎杀。

更关键的是，这些能力没有被做成一段只能在昂贵工作站上播放的演示。《DOOM》瞄准的是办公室和宿舍里真实存在的 386、486 PC。画面不追求几何意义上的完整正确，玩法却要快到让鼠标和键盘像玩家身体的一部分。

它也没有把免费版当成遮遮掩掩的广告。shareware 第一章《Knee-Deep in the Dead》本身就包含九张完整地图，足够让玩家通关、重玩、发现秘密、联机，再把文件复制给下一个人。免费内容越完整，传播越快；传播越快，后续注册版卖得越多。

这套组合把行业词汇改了。此后几年，媒体和玩家不急着说 FPS，而是说“Doom clone”。一个游戏的名字暂时代替了品类名称，这比争论谁在历史上排第一更能说明影响。

“某位天才单独发明一个时代”的叙述，会抹掉《DOOM》得以成立的组合条件。卡马克负责技术取舍，罗梅洛反复调校节奏；艾德里安·卡马克和 Kevin Cloud 制作美术，Bobby Prince 塑造声音，Sandy Petersen 等人完成地图。Dave Taylor 的程序工作、Jay Wilbur 的商业处理，以及玩家愿意复制、联网和改造，同样缺一不可。

两位约翰很重要。

可恶魔不是他们俩凭空画出来的，九张地图也不是引擎启动后自动生成的。

所谓 2.5D，是一连串非常聪明的“不做”

今天打开一个三维引擎，建立楼层、斜坡、可上下看的摄像机，似乎都是基本能力。回到 1993 年，普通 PC 不会免费送你这些东西。

《DOOM》的地图并不是完整三维建筑。设计者主要在平面上画线，用 sector 定义地面、天花板高度、纹理与亮度。房间不能真正垂直叠在另一间房上，墙不能像现代多边形世界那样任意倾斜，玩家也不能自由抬头低头。敌人与物品大多是朝向玩家的二维 sprite。

后来人们用“2.5D”概括这套方法。听起来像少了半维，仿佛是一种不完整版本。其实它体现的正是卡马克擅长的工程判断：只计算玩家此刻会感到的东西。

那套速度来自一组有意识的“不做”：

• 不模拟可以垂直重叠的完整三维建筑；
• 不让墙面和视角拥有任意三维自由度；
• 不把敌人与物品实时画成完整多边形模型；
• 不在运行时反复解决能提前预处理的空间问题；
• 不为玩家当前看不见的区域支付同等绘制成本。

游戏先对地图做预处理，利用二叉空间分割，也就是 BSP，把空间组织成便于排序和裁剪的结构。BSP 不是卡马克发明的，它在计算机图形学里已有历史。卡马克的贡献，是看见它适合解决《DOOM》的可见性与绘制顺序问题，并把论文与研究概念变成能在消费级 PC 上工作的代码。

运行时，引擎沿 BSP 判断哪些区域需要画、哪些能被挡住，墙面按屏幕竖列处理，地面和天花板用另一套 visplane 逻辑填充。定点数和查表减少昂贵的浮点计算。DOS/4G 帮助程序使用 32 位保护模式内存，摆脱一部分传统 DOS 内存限制。

说白了，机器没有模拟一个完整世界，它只把玩家这一刻需要看见的部分做得足够可信。（放心，这篇文章不用考图形学。）

这些名词单独看很像一节不太友好的计算机课。落到玩家手里，结果却很直白：转弯快，开门快，火球飞过来时快，房间可以比《Wolfenstein 3D》复杂得多，帧率却没有立刻趴下。

卡马克牺牲了几何正确性，换来反应速度和空间表达。他没有让机器模拟一个完整世界，再祈祷普通玩家买得起；他从玩家视野反推，哪些错觉足够可信，哪些计算根本不该发生。

《DOOM》技术最值得记住的恰是这份工程克制。伟大引擎不一定把所有功能都做出来，有时它知道哪些功能必须坚决不做。

《DOOM》让他们站上同一座山顶

id 的目标机器是 DOS PC，开发流程却大量依赖 NeXT。

NeXT 工作站由史蒂夫·乔布斯离开苹果后创办的公司推出，价格不便宜，市场规模也远不如普通 PC。可 NeXTSTEP 的开发环境、Objective-C 工具和图形界面对 id 很有吸引力。团队可以在工作站上运行编辑器、游戏和调试器，处理地图，再把代码送到 PC 端用 Watcom 工具编译。

DOOMEd 关卡编辑器和 iBSP 预处理工具都在这套环境里完成。它们把“卡马克写出一个能画新空间的引擎”与“设计者每天稳定产出新地图”连接起来。引擎能力如果只能由原作者手写坐标调用，就很难变成一款有几十张地图、还能被外部玩家继续改造的游戏。工具决定生产速度。

今天展会上仍能看到 NeXT Cube 和 NeXTstation 一类机器。照片里的设备不是 id 当年办公室那几台原机，却能让人理解那种工作场景：黑色方盒子、当时极其先进的软件环境，旁边再摆着真正负责跑游戏的 DOS PC。未来感与大众市场没有装在同一台机器里，团队必须不断来回搬运。

罗梅洛因此不能只被叫作“点子的人”。他参与工具、关卡与制作流程，懂得技术能力怎样变成设计者可以反复试验的东西。卡马克把空间边界推开，罗梅洛等人则需要建立一套语法：墙怎么引导玩家，窗怎么制造欲望，钥匙怎样改变路线，秘密区域如何奖励好奇。

卡马克在 2022 年说，《Wolfenstein 3D》的设计空间像被硬墙围住，而《DOOM》跨过了“足够自由”的边界。这句话背后不只是渲染器。自由还来自编辑器、数据格式和生产习惯。设计者能画出新空间，玩家以后也能替换地图、图像与声音，技术才真正离开作者的电脑。

很多公司把工具视为内部成本，做出游戏就算完成。id 早期更像是先造一种可持续生产游戏的机器，再用第一批内容证明机器有多好玩。

这套基因将给《DOOM》第二次、第三次生命。

它也会诱惑卡马克在《Quake》里一次造太多机器。

罗梅洛怎样把空间变成节奏

引擎允许斜墙、高低差和远处可见的区域，并不等于地图自然会好玩。给设计者一座更大的乐器，他仍得知道何时响，何时停。

罗梅洛后来谈《DOOM》关卡时，提到一个听起来很不像射击游戏的参考：迪士尼乐园。乐园不会把所有景点一进门就塞到游客脸上。它通过转角、远景、门洞和路线，让你先看见一个东西，知道它存在，却暂时到不了。期待感由空间本身制造。

《DOOM》里经常出现类似安排。你隔着窗看见一把武器，或在低处看见某个开关；路径却绕开了。玩家先在脑中记下一笔：“我得回来拿。”等他经过一段战斗，从另一条走廊抵达那个位置，获得的满足不仅来自物品数值，也来自空间被理解了。

罗梅洛还强调战斗与探索的交替。连续几十分钟把怪物往玩家脸上扔，刺激会迅速变成噪声。让玩家短暂安静，听见远处敌人的低吼，观察纹理和门的颜色，再在他建立方向感后改变空间，下一场战斗才有冲击。

这就是“手感”经常被说得很玄的地方。它并非某个神秘参数。角色移动速度、转向、武器伤害、射速、敌人受击、声音、房间尺寸、补给位置、遭遇顺序，全部在几秒钟内叠到一起。WIRED 采访中，卡马克明确把大量核心数值与速度调校归功于罗梅洛。卡马克写出武器和敌人运作的关键逻辑，罗梅洛则不断把它们调到带有《DOOM》性格的位置。

霰弹枪是最好的例子。它不是只在数据表里造成一串伤害值。开火声、枪口动作、敌人被击中的反应、装填间隔与近距离风险，共同让玩家形成节奏。你会在转角前预判，会决定冲近一点还是退一步，会在声音结束前准备下一次移动。

罗梅洛在 2013 年回忆，开发者通常很难被自己的游戏吓到，因为每个东西放在哪里都知道。可当怪物、声音和新地图第一次组合起来，他也曾走进一段未知的黑暗，获得和普通玩家相似的寒意。

那一刻，引擎不再是一套技术。

它开始反过来吓唬制作它的人。

玩家为什么觉得自己像一枚有枪的弹丸

《DOOM》的速度感不只来自帧率。

角色移动很快，转向直接，常用武器不用停下来装填弹匣。玩家可以边跑边射，斜向移动还会形成后来被高手充分利用的速度优势。地图也很少要求你规规矩矩贴着掩体等敌人露头。许多战斗鼓励持续绕行，让火球从身边穿过，再从侧面接近目标。

敌人攻击方式刻意混合。持枪的人类敌人更接近即时命中，迫使玩家处理视线；小恶魔和更强怪物发射可见弹道，给玩家闪避空间；近战敌人负责挤压路线。不同攻击进入同一房间，战斗便从单纯比准度变成位置管理。

怪物还会互相误伤。一个敌人的攻击击中另一种怪物，双方可能转而厮打。玩家于是能利用混战，穿过原本看似无法处理的敌群。这个系统没有弹出教程解释“挑拨关系”，它只是遵守世界规则，结果由玩家自己发现。

地图补给也在调速度。生命值、护甲和弹药放在哪里，会决定玩家是大胆冲入房间，还是沿边缘试探。秘密区域常提供额外资源，让熟悉地图的人获得更激进的路线。难度上升也不只是把敌人血量统一加厚，而会改变敌人数量、位置和资源压力。

这些细节让罗梅洛所谓的“调校”变得具体。若移动慢一点，弹道怪物的威胁会完全不同；若霰弹枪恢复快一点，近距离风险会下降；若房间窄一点，绕行空间又会消失。每个参数都与地图和敌人相互定义。

《DOOM》几乎没有用长篇文字告诉玩家自己是一名凶狠战士。它让你的手在几分钟内学会一种凶狠的移动方式。

速度也是一种人物塑造。

恶魔不是两个约翰凭空做出来的

《DOOM》的故事很容易被压缩成两位约翰，因为名字整齐，冲突鲜明。实际的开发室比海报拥挤得多。

艾德里安·卡马克是首席美术。他与约翰·卡马克同姓，却没有亲属关系。黏土模型、手绘、扫描与数字处理共同形成怪物和武器画面。那些恶魔既有低分辨率的粗糙，也有一种令人不舒服的肉感。技术让 sprite 能快速显示，美术让玩家相信走廊尽头真有东西在等。

Kevin Cloud 参与美术与公司事务。Bobby Prince 负责音乐和大量声音，他此前做过律师，也懂音乐。游戏对重金属气质的借用后来引发许多比较，但进入玩家记忆的不只有旋律，还有门、升降台、怪物活动和武器开火构成的声音地图。你常常在看见敌人以前，先听见它。

Tom Hall 离开后，Sandy Petersen 接手大量关卡。据团队口述，他在大约三个月里完成或重制近二十张地图。Petersen 有桌面角色扮演与《Dungeons & Dragons》经验，他喜欢地牢、诱饵、陷阱和让玩家误判安全的结构。他的地图不总像罗梅洛那样精致地控制线条，却给游戏带来更多怪异、不安和地狱感。

Dave Taylor 做程序、调试和多种杂务。作弊码最初服务测试：开发者要快速穿墙、无敌或获得武器，没必要每次都正常通关。团队后来决定保留这些入口，让玩家也能使用。今天回看，这是很 id 的选择。规则当然重要，但玩家拆开规则同样有趣。

Jay Wilbur 处理商业、发行与外部联系。没有这些工作，shareware 不会自动把收入变成工资，授权也不会凭空完成。罗梅洛本人也承担大量对外演示和合作联系，特别是 Raven Software 等使用 id 技术的项目。

把这些名字写进来，不是为了做一段客气的片尾鸣谢。它们关系到两位约翰为什么后来会吵。小团队成功时，所有工作挤在一起；成功之后，技术、内容、授权、宣传和管理开始分开。谁的贡献最核心，谁应该决定下一款游戏，谁承担了别人没看见的工作，答案越来越不一致。

《DOOM》证明了他们能一起做成大事。

它也让每个人都获得了足以坚持自己判断的证据。

低分辨率画面背后，是一套很“实物”的生产

《DOOM》看起来像纯粹从代码里长出来的数字世界，许多视觉素材却来自非常具体的物件。

团队会制作或使用黏土、乳胶模型，从不同角度拍摄，再把图像数字化、清理成低分辨率 sprite；部分武器来自玩具枪等实物的照片与再加工；墙面和环境纹理也混合了手绘、摄影素材与数字编辑。屏幕里的恶魔当然不是对现实模型的机械复印，像素限制、色板和逐帧修整会把它们再次塑形。

这种方法有一个现实原因。完整三维模型实时渲染对目标 PC 太昂贵，预先拍好不同方向的二维图像便宜得多。怪物转身时，引擎根据视角选择对应画面；距离改变，再做缩放。玩家看见一个有体积、能在空间里活动的生物，机器处理的仍是一组精心准备的平面图。

技术限制和美术风格在这里没有分家。若模型轮廓不清，缩小后会糊成一团；若动作帧太多，内存与制作成本上升；若帧太少，怪物又会僵。美术成员必须理解引擎怎样选图、怎样缩放，程序成员也要理解哪种画面错误最破坏恐惧感。

声音同样承担“补足维度”的任务。看不见的怪物发出活动声，升降平台在墙后运转，门的开启告诉玩家空间发生变化。画面无法展示的远近与威胁，耳朵先补出来。Bobby Prince 的工作因此不只是给枪战配背景音乐，而是帮助玩家读取地图。

说《DOOM》靠技术取胜没有错，只是“技术”不只属于渲染器。素材制作、声音触发、内存限制和关卡布置互相咬合，玩家才会相信那条走廊里真有东西活着。

黑玻璃大楼里没有传奇滤镜

1993 年 8 月，Dave Taylor 来到得州 Mesquite 的 id 办公室。按他多年后的回忆，楼外包着黑色玻璃，看上去颇有科技公司气势；走进去，地毯上留着汽水污渍，天花板漏水后泛黄。

这组细节很适合给传奇降温。《DOOM》没有诞生在洁白无尘、人人佩戴访客证的未来实验室。开发室更像一群年轻人长时间生活过的地方：电脑持续发热，桌边堆着饮料，成员随时从工作切到 deathmatch，再从骂声和笑声里回去调地图。

Taylor 初次看到罗梅洛演示早期引擎时，场景里还没有完整怪物。墙面纹理、空间和移动已经足够让他震惊。罗梅洛不是安静按几下键，他会控制节奏，告诉观看者该注意什么，让尚未完成的技术显出成品潜力。

这种演示能力在小团队里很实际。新成员需要尽快理解大家在做什么，合作方需要看见引擎价值，团队自己也需要在漫长开发中记住目标。罗梅洛把一段运行中的代码讲成一款即将出现的游戏。

办公室很破，机器很贵，项目没有人敢保证会走到哪里。

可当屏幕转起来，屋里的人已经知道旧游戏回不去了。

1993 年 12 月 10 日：先让服务器上的人退出

《DOOM》不是在商场门口排队发售的。

1993 年 12 月 10 日，id 准备把 shareware 版本上传到大学 FTP 服务器。多份团队口述与技术资料把地点指向威斯康星大学麦迪逊分校，也有一篇 WIRED 采访写成华盛顿大学。公开记录在这里并不完全一致。更稳妥的说法是：id 借用大学 FTP 分发，发布前还得让已经占用服务器的用户先退出，文件出现后，蜂拥而来的流量迅速把服务压垮。

不要急着把这个场景改写成今天的“发布即宕机营销”。当时没有弹性云服务器，没有全球 CDN，也没有平台替开发者处理下载。一个备受期待的大文件进入公开 FTP，大量玩家和镜像站同时来取，机器和网络就会直接感到疼。

shareware 第一章很快沿 BBS、校园网、办公室网络和一张张软盘扩散。注册版通过邮购等方式出售。常见估算认为，商业版本到九十年代末售出约数百万份；“前两年可能有两千万人玩过”则是包含复制与安装传播的估算，不能当成销量。付费用户只是玩家的一部分，免费传播本身就是产品策略。

许多单位很快发现，员工和学生不仅在玩，还在联机。游戏会占用网络、机器和工作时间，管理员不得不封堵。DOOM 的网络代码早期还真的制造过麻烦。卡马克回忆，最初的 IPX 方案用广播包组织游戏，在大型校园网络里，每台机器都可能被迫检查数据。发布后接到愤怒管理员的电话，他很快把机制改成广播只负责寻找玩家，正式游戏阶段改用定向通信。

这里能看见卡马克典型的工作方式：先让功能跑起来，问题出现后迅速测量和修正。也能看见罗梅洛式的产品直觉：网络不是菜单里一个技术选项，它要变成玩家能立刻理解的行为。

合作打怪很好理解。

当同事出现在屏幕里，手上也有枪，这套技术才显出全新的用法。

Deathmatch：同事忽然变成了猎物

两台 DOS PC 与一台 NeXT 连起来后，卡马克第一次让两个玩家在《DOOM》世界里看见彼此。那个瞬间的技术意义很大：同一个快速变化的空间，需要在多台机器之间保持足够一致。玩家转身朝对方开枪时，技术演示随即变成了文化事件。

罗梅洛为这种模式起名 deathmatch。

它不需要复杂说明。地图里没有预写剧情，也没有电脑控制的最终魔王。另一个人会埋伏、逃跑、抢武器、记住你的习惯，还会在你刚复活时立刻冲过来。原本通关后会结束的关卡，忽然变成可以无限重演的竞技场。

办公室里的测试很快变成日常对抗。玩家开始讨论路线、出生点、武器控制和反应速度。地图不再只服务单人流程，同一扇门在 deathmatch 里可能是逃生口，也可能是埋伏点。罗梅洛对空间节奏的理解与卡马克的网络系统，在这里形成一种没有剧本的游戏。

今天的在线射击有匹配、段位、反作弊、观战、赛季和庞大服务器集群。早期《DOOM》没有这一整套工业设施。玩家得处理网络设置，局域网最方便，远程连接更麻烦。可核心行为已经成立：真人对手让有限地图不断产生新局面。

这也改变了游戏寿命的计算方式。单人内容做得再多，玩家总会走到尽头；多人对抗把内容生产的一部分交给人类行为。设计者提供空间和规则，玩家负责制造不可预测性。

罗梅洛尤其享受这种竞争。他的外向、表演欲和对速度的偏好，在 deathmatch 里全是优点。后来关于《Quake》时期的冲突，常会把他花在对战上的时间当成“不工作”的证据。这个指控并非毫无来由——长期项目需要有人把关卡与方向真正落地，沉迷内部比赛当然可能挤掉制作时间。

可也不能忘记，玩本身就是 id 的研发方法。团队靠互相射击发现节奏、武器和地图问题。公司需要回答的，是如何区分有效测试、社区展示、个人娱乐和项目责任，并在日程上为这些活动划出清楚边界。

年轻的 id 没有那种制度。

他们只有一个更简单的判断：谁能赢，谁做出的东西更酷，谁就说了算。

WAD：把一部分作者权交给玩家

《DOOM》的数据被组织进 WAD 文件。这个缩写通常解释为 Where's All the Data?，语气很像开发室里的玩笑，影响却一点也不小。地图、纹理、声音等资源能够以相对独立的方式被组织和替换，游戏的核心执行程序与内容数据没有死死焊在一起。

卡马克在 2013 年回忆，他从设计阶段就考虑了可修改性。团队内部并非所有人都赞成立刻开放工具和技术，商业利益与控制权很现实；可 WAD 的结构至少给玩家留出了入口。

玩家很快开始做新地图、替换图像、改变声音，甚至把熟悉的办公室、学校或幻想场景搬进游戏。你不必等 id 每年发一部官方续作。只要有人愿意研究格式、制作工具并分享文件，《DOOM》就能继续长出新内容。

这里要区分两件经常混在一起的事。WAD 可修改，不等于 id 当时把所有东西放进公共领域；1997 年开放源代码，也不等于游戏美术与关卡资产免费。源程序、工具、数据和商业作品拥有不同权利。玩家要运行完整游戏，仍需合法的数据文件。

这条界线没有削弱社区，反而形成一套长期可持续的关系：官方资产继续销售，程序和格式逐步开放，玩家作品不断扩张。后来源端口修复兼容性、增加现代显示和网络能力，老 WAD 仍能被读取。三十多年后，新关卡还在出现。

卡马克追求清楚接口和可复用系统，罗梅洛热爱玩家、工具与关卡作者文化。WAD 同时符合两人的性格。对卡马克来说，数据与代码分离是干净结构；对罗梅洛来说，玩家终于不只是消费者，而能站到设计者这一边。

这可能是《DOOM》最深的影响。它没有只告诉行业“第一人称射击很赚钱”，还展示了另一种关系：开发者造出规则和工具，社区不必等批准就能继续创作。

一个封闭成品会老。

一套仍有人愿意学习的语言，可以活得比公司的人事关系久得多。

模组作者不是免费劳动力

游戏公司谈玩家创作时，很容易落入一种自利叙事：我们提供平台，社区替我们免费生产内容，大家都开心。早期《DOOM》社区的关系比这复杂。

玩家做 WAD，动机通常不是替 id 延长产品寿命。他们想重建熟悉地点，挑战朋友，证明自己的地图比官方更狠，或单纯研究文件里到底装了什么。工具最初也不全来自官方，社区会自行逆向格式、交换编辑器、写教程，再把经验传给下一批作者。

id 从中获得了真实好处。新内容让游戏长期被讨论，玩家为了运行地图继续购买和保留官方数据，优秀作者与工具开发者还扩大了整个人才池。可社区也获得了以前很少有的创作入口。一个普通玩家不用先进入大公司，便能做出自己的关卡，被成千上万人下载和评论。

双方由此形成一份松散契约。开发者尽量保持格式可理解、程序可延续；玩家接受核心资产仍有商业边界，在边界外大胆改造。契约偶尔会争吵，也没有谁签字，却比许多精心设计的“用户生成内容平台”活得更久。

罗梅洛后来发布《SIGIL》时，仍然使用这种关系。他既是原作核心成员，也是一个向社区交付 WAD 的关卡作者。身份绕了一圈，回到最简单的动作：做一组地图，让别人装进去玩。

若只把模组理解成营销，就无法解释为什么三十多年后还有人投入大量时间。如果只把它理解成无条件开放，又会忽略资产权利、商业销售与兼容维护。生态之所以持续，是因为双方都能在其中保留自己的理由。

《DOOM II》没有重写世界，它把世界铺得更宽

1994 年的《DOOM II》没有像前作那样再次制造技术震荡。它沿用同一套基本引擎，把商业发行、地图规模、敌人组合和武器系统向外扩展。最著名的新武器超级霰弹枪尤其能说明 id 的设计品味：它没有增加复杂操作，只把已有的近距离风险与反馈推到更极端。两发弹药，一次爆响，装填时间更长。玩家很快学会围着这段节奏移动。

从今天看，续作没有更换引擎似乎很平常。放在当时的 id，这反而是一种短暂克制。卡马克总想做下一代技术，可公司也需要把已经成熟的能力转化成更稳定的收入。零售版进入传统渠道，shareware 建立的知名度则替它提前完成了市场教育。

引擎授权也开始成为一门重要生意。Raven Software 使用 id 技术制作《Heretic》《Hexen》等作品，又加入自己的内容与系统。罗梅洛参与这类外部关系，帮助合作方理解技术和设计。卡马克多年后特意提起这部分贡献，因为它不容易出现在“谁写了多少关卡”的简单账本里。

移植把《DOOM》送进更多硬件，也逼迫代码接受新的检查。Atari Jaguar 版本由卡马克深度参与。不同主机的处理器、内存、显示和存储限制各不相同，PC 上能跑的实现未必能直接搬过去。因此，移植需要重新判断哪些功能保留、哪些资源压缩、哪些代码整理。

照片里的 Jaguar 是保存下来的产品实物，不是 id 的开发现场。它外形像一台九十年代对“未来”的想象：黑色机身，红色按键，控制器上密密麻麻的数字键。《DOOM》进入这种机器以后，也不再只属于配置声卡、内存管理和网络参数的 PC 玩家。

之后的 PlayStation 版本又用重新处理的声音、彩色光照和主机环境塑造出不同气质。许多移植有删减，有些帧率和地图不如 PC，有些却创造了自己的恐怖感。DOOM 不再是一份固定体验，而是一套可以被不同硬件重新解释的规则。

这给 id 带来两种诱惑。商业上，一套好引擎和一个强品牌可以不断扩张；技术上，旧架构越成功，卡马克越想把它彻底超越。

第二种诱惑更强。

当比尔·盖茨也需要《DOOM》

到 Windows 95 推出时，微软遇到一个形象问题。

Windows 想成为大众软件平台，可真正投入的 PC 玩家仍熟悉 DOS。他们担心新系统会拖慢游戏、增加兼容麻烦，或干脆跑不了最热门的作品。《DOOM》因此成了极有说服力的测试：如果 Windows 能让它好好运行，玩家才会相信这个图形界面不只是办公软件的外壳。

微软团队推动 Windows 版移植，Gabe Newell 等人参与其中。还有一段著名的宣传视频：比尔·盖茨穿着风衣，出现在《DOOM》式场景前，向开发者推销 Windows 95。今天看画面有点滑稽，却准确反映了权力关系的变化。不是 id 借微软证明自己，微软在借《DOOM》证明 Windows 配得上游戏。

当时行业里还流传一种说法：《DOOM》的安装量甚至超过 Windows。它来自微软团队与业界对传播规模的估计，也带有明显宣传色彩，不能当成审计数据。但微软愿意使用这个比较，本身已经足够说明问题。一个由十来人规模团队做出的 shareware 游戏，成了世界最大软件公司必须正视的平台标准。

《DOOM》还改变了办公室网络、大学机房和硬件销售。有人为了更流畅的画面升级处理器，有人购买声卡，有人第一次学会配置局域网，只为下班后打 deathmatch。软件开始反过来拉动硬件需求。

这通常是技术商业史里最危险的时刻：外界把你视为平台，一家公司也会逐渐形成预期，下一次还得重新定义平台。

《DOOM》的成功给每位核心成员不同的证据。卡马克看到技术边界一旦跨过，整个品类会跟着移动；罗梅洛看到速度、关卡人格、玩家社区和公开演示能把技术变成文化；美术与设计成员看到内容足以让一套引擎拥有世界观。每个人都从成功里学到真东西，只是学到的并不是同一件事。

下一款游戏应该更像什么？

更快的《DOOM》？完整三维的技术革命？有近战、魔法和新世界观的冒险？更强的网络平台？一套能让外部作者写逻辑的脚本系统？

id 给出的答案是：都要。

《Quake》：把好几次革命塞进一个项目

卡马克后来回望《Quake》，认为团队本应先做一款 “Doom++”。

所谓 “Doom++” 并非正式产品名，它指的是一条更克制的假想路线：沿用熟悉的视觉与玩法基础，先完成客户端/服务器网络、互联网能力和脚本化等创新；等这些系统稳定，再用下一款游戏攻克完整多边形三维。这样每次只跨一两道大坎，内容团队仍有相对可靠的地面。

他们当年没这么做。

《Quake》要把墙、地面、敌人、物品都送进真正的三维空间。地图可以垂直叠放，视角可以上下看，角色和怪物不再主要依靠始终朝向玩家的二维图像。光照数据、可见性计算、碰撞和动画都要换一套思路。

网络也不满足于局域网里的《DOOM》模式。客户端/服务器架构要支持更广阔的互联网对战，延迟、预测和状态同步成为新问题。QuakeC 又把游戏逻辑的一部分交给脚本，让内容行为不必全部硬编码在引擎里。关卡编辑、模型制作、美术管线同样得重新建立。

任意一项都足够成为一款游戏的核心研发风险。

项目却选择把这些风险同时叠在一起：

• 完整多边形三维世界与新的光照、碰撞；
• 面向互联网的客户端/服务器网络；
• 可由内容作者扩展逻辑的 QuakeC；
• 全新的地图、模型、美术与关卡工具链；
• 尚未收束的玩法、世界观和内容方向。

完整 3D、网络架构、脚本、光照、新工具、新玩法方向一起出现，等于团队一边造路，一边造正在路上行驶的车。罗梅洛在 2026 年公开回顾时用了几乎就是这个意思的比喻。车里还坐着美术、设计、商业和玩家期待，没人能停车等道路全部铺好。

卡马克的工作取得了惊人成果。《Quake》的技术对后续三维游戏、网络射击、引擎授权和电子竞技影响深远。问题不在于这些目标错了。问题是它们彼此依赖：引擎未定，工具就会变化；工具变化，地图和美术返工；玩法方向没落地，技术团队不知道哪些能力最急；发布日期逼近，所有人的时间都被不确定性吃掉。

《DOOM》时期，技术限制帮助团队做减法。《Quake》时期，技术可能性反而不断向项目加东西。

卡马克看到的是必须被攻克的问题。

内容团队感到的，却是脚下地面每天都在动。

引擎先行的账，常由内容团队来付

底层技术变化带来的成本，很少只落在写引擎的人身上。

渲染方式改了，地图结构可能要重做；模型格式改了，美术管线需要重导；光照算法改变，已经完成的场景会突然显得不对；碰撞规则变化，原本能走的楼梯和门口可能卡住；脚本接口调整，敌人行为又得重新测试。技术成员提交了一次更先进的改动，内容团队可能收到几周返工。

这不代表引擎不该改变。《Quake》若过早冻结技术，可能根本无法成为后来那款游戏。团队缺少的，是一套让所有人共同看见代价的决策方式。新能力能带来什么，影响多少现有内容，何时必须停止改接口，若继续推进要删掉哪部分计划，这些都需要有人明确承担。

早期 id 习惯由最强实现说服所有人。卡马克拿出更快、更漂亮的系统，价值摆在屏幕上，争论往往就结束。《Quake》的许多价值却要在完整管线建好后才显现，代价则每天由等待和返工支付。双方感知到的进度自然不同：引擎在跨越障碍，地图却可能仍停在起点。

这类错位后来在无数技术公司重演。平台团队按架构升级衡量进展，产品团队按用户可见功能衡量进展。两边都在工作，也都觉得另一边拖慢自己。若组织不能建立共同账本，技术争论迟早会变成人际冲突。

《Quake》把这张账单放大到整个团队。罗梅洛未能及时收束内容方向，卡马克也没有为技术野心设下足够边界，底层与内容互相等待稳定版本。

大家到底在做一款什么游戏

《Quake》这个名字在项目真正成形前已经承载了许多想象。团队谈过更偏幻想冒险的方向，谈过强力近战、角色与世界设定，也面对一个越来越清楚的现实：卡马克的新引擎需要很长时间，内容无法等到全部完成后再开始。

Tom Hall 已经离开。罗梅洛在《DOOM》里扮演的设计领导角色，此时本该更重要。他需要把技术能力收束成一款具体游戏，帮助地图、美术和程序成员知道哪些东西该做、哪些该删。

卡马克后来批评的重点正是在这里：他认为罗梅洛没有承担足够的《Quake》设计与内容责任，花了太多时间在宣传、对战和公司外部活动上。对一个每天把大量时间压进引擎的人来说，看到同为所有者的伙伴没有维持相似强度，愤怒并不难理解。

罗梅洛的视角不同。他面对的是一个长期不稳定的技术平台，许多内容会随引擎变化重做；他仍在制作关卡、演示产品、处理合作，也通过亲自玩和交流寻找方向。可这种工作分散、可见性低，没有形成一份足以让团队结束争论的设计方案。

两种说法可以同时成立。

罗梅洛在项目期间确实没有交出卡马克期待的领导强度；卡马克也低估了底层系统连续改变给内容生产带来的返工与心理消耗。团队缺少能把技术路线、游戏方向和发布日期绑定在一起的制作机制，于是管理问题被改写成个人品格问题。

这很像一家创业公司从五个人长到几十人后，创始人仍用“我每天看见你在做什么”代替项目管理。早期默契足以同步全部信息，复杂项目却需要稳定里程碑、责任边界和允许休整的日程。id 的文化不信这些。它信原型，信天才，信能把问题硬做出来的人。

罗梅洛擅长点燃一个已能看见轮廓的游戏。

《Quake》很长时间只有不断变化的轮廓。

山顶之后，他们朝相反方向下山

Softdisk 的月度交付、《Commander Keen》的夜间开发、《Wolfenstein 3D》和《DOOM》的高速推进，给 id 形成一种危险经验：只要最强的人继续拼，困难总会被压过去。

在几个月到一两年的爆发期里，这套方法真能创造奇迹。团队小，反馈快，所有人都知道目标，疲惫还能被新鲜感和收入抵消。可长期把创业冲刺当正常速度，人的注意力、健康和关系会开始还债。

《Quake》的技术目标多，方向变化大，开发时间长。成员不仅要做新内容，还要适应新工具和返工。Sandy Petersen 在 2026 年公开表示，游戏的技术与艺术成就都很伟大，工作量却在精神上压垮了团队。卡马克随后承认，自己把所有人逼得过紧，没有理解一家成熟公司需要冗余和余量。短期创业强度可以赢下一场战役，持续多年就会耗尽组织。

这个承认来得很晚，却让两位约翰的冲突有了更完整的因果链。

卡马克并非简单喜欢加班。他追求一种近乎连续的进步状态：当问题存在，就应该被解决；当下一代技术方向清楚，就没有理由停在旧架构。对他个人来说，这种强度长期可维持，他也自然把它当成所有者应有的承诺。

罗梅洛不是突然失去能力。他的工作节奏、兴趣分配和领导方式已与卡马克的标准分开。成功还让他承担更多公开角色，享受玩家文化和公司名声。原本能增加产品影响力的性格，在延期项目里会被同伴看成不够专注。

一家公司如果有成熟治理，会把这种差异变成工作安排：明确谁负责设计收束，谁负责引擎里程碑，外部活动占多少时间，项目延期时砍什么功能，成员何时休息。id 当时主要靠创始人的相互判断。

判断一旦变成失望，就没有缓冲层。

股份把工作分歧变成了道德审判

卡马克多年后谈到早期 id 的股权与买卖安排，认为它制造了错误激励。

公司早期由几位核心成员共同拥有，权力和收益与创始身份紧密绑定。在每个人都坐在同一间办公室、投入相近强度时，这很自然。可一旦成员的工作方式和贡献发生变化，问题就来了：同样持有重要股份，是否意味着必须投入同样长的时间？对外合作算不算和写引擎一样重要？某人没有达到其他所有者期待时，应该调整职责、调整股权，还是离开？

卡马克当年给出的答案越来越接近后者。

他看见自己持续承担最难的技术工作，也看见《Quake》设计方向迟迟不稳。罗梅洛却仍享有创始人的影响力和经济权利。卡马克把这种不对称理解为不公平，愤怒因此不再只指向项目延期，而指向罗梅洛是否履行了伙伴义务。

罗梅洛则有理由认为，自己的贡献被卡马克偏好的计量方式缩小了。他做关卡，处理 Raven 等合作，展示游戏，维持社区影响，也曾在公司最早阶段用自己的全面能力帮助卡马克成长。创始关系不是按当前一周代码行数重新结算的临时合同。

这里没有一套计算器能给出完美答案。

问题出在公司把太多事情绑在一起：友谊、创始人身份、股份、日常管理权、创作方向和个人价值。项目分歧会触发经济冲突，经济冲突又会让每次 deathmatch、每次外出宣传、每张延期地图都带上道德意味。

当年二十多岁的卡马克没有足够管理经验，罗梅洛也没有。卡马克在现代访谈里主动承认不成熟，也承认若干股权条款让人拥有不健康的选择。这个反思并不能取消他当时对交付的合理担忧，却说明“赶走懒惰伙伴”不是完整解释。

这不是两个天才突然互相看不顺眼。

这是公司已经长大，治理方式还停在什里夫波特那间小办公室里。

是谁让罗梅洛走的

1996 年夏天，《Quake》终于发布。它证明卡马克的技术赌注并非幻觉，也证明团队真的被这场赌局耗得厉害。项目结束没有带来轻松，反而让积累的问题失去遮挡。

公开记录里，罗梅洛在 8 月 7 日宣布自己决定离开。他说要成立目标不同的公司，也表示不会带走 id 员工。若只读这封 .plan，可以把事件理解成创始人理念不合后的主动创业。

可卡马克 2022 年的说法更直接，表明这不是一场完全对等、平静的分手。

更准确的还原是，两个动作都发生了。罗梅洛确实想做不同的游戏、建立新公司；在 id 内部，卡马克已经推动其他所有者和管理关系，让他不能再按原来的位置留下。对外形式是罗梅洛宣布离开，权力实质则包含一次创始人驱逐。

这一区分很重要。它让我们不用在“和平辞职”和“被扫地出门”之间二选一。高层分手经常就是这样：当事人也想走，但离开的时间、方式和不可逆程度由内部权力决定。

关于那段冲突，后来还出现许多极具戏剧性的细节。其中最著名的一类说法，是卡马克在罗梅洛电脑上安装程序监控他的工作时间。罗梅洛在后来的回忆录中质疑这个版本，称类似事件发生在另一家公司，并说自己向卡马克确认过。缺少更强档案时，把它当成铁证并不负责。传奇故事喜欢具体道具，一段监控软件比漫长的组织失灵更容易拍出来。

没有争议的部分已经足够尖锐：卡马克认为罗梅洛没有完成应承担的工作；罗梅洛认为自己的方向和价值无法继续在 id 实现；公司没有找到保留两人又重建责任的办法。

他们共同完成的收官作是《Quake》。

一款把空间彻底变成三维的游戏，也把两个人推向了不同方向。

Ion Storm：把“设计就是法律”挂在墙上

罗梅洛离开 id 后，与 Tom Hall 等人创立 Ion Storm。新公司的口号 Design is Law 几乎是对旧生活的公开回应：技术不应一直决定游戏能做什么，设计应该获得最高权力。

这句话听起来痛快，特别适合一个刚离开技术强人主导公司的设计者。可组织不会因为墙上写了口号就自动学会制作。

Ion Storm 获得 Eidos 投资，在达拉斯 Chase Tower 第 54 层建立昂贵办公室。高空景观、定制空间与明星开发者形象，都是为了宣布它不是普通工作室。尴尬的是，游戏美术和程序常需要控制光线，玻璃与景观并不一定适合盯屏幕，员工后来甚至用黑布遮挡隔间。你花大价钱买了全城最好看的窗，然后想办法把它盖住——这事很有九十年代科技公司的气质。

更糟的是 1997 年那则广告：John Romero Is Going To Make You His Bitch. Suck it down. 原意带着 deathmatch 玩家互喷式的垃圾话，放在杂志整页广告里，却成了开发者对消费者的公开挑衅。游戏一旦延期，每一天都在替玩家积攒反击素材。

这张照片拍于 2000 年 E3。左侧是罗梅洛，中间是沃伦·斯佩克特，右侧是迈克·威尔逊。它属于 Ion Storm 时期，不是两位约翰在 id 的早年合照。三个人站在展会通道里笑着面对镜头，背后是拥挤的人群和招牌。那时 Ion Storm 已同时背负明星工作室的期待、项目延期和内部派系压力。

必须补一句：Ion Storm 不是只有达拉斯总部，也不是只有《Daikatana》。斯佩克特领导的奥斯汀团队后来做出《Deus Ex》，成为游戏史经典。同一家公司里，一个项目被技术更换与管理冲突拖住，另一个项目却证明“设计优先”可以产生卓越结果。

Ion Storm 的故事无法归结为“罗梅洛离开卡马克就不会做游戏”。它更像一次过度补偿：在 id，技术权力太强；到了新公司，罗梅洛试图把设计、名声和自由一次拉到另一端。钟摆摆得太远，管理并没有因此出现。

《Daikatana》：作者人格变成商业负债

《Daikatana》的野心并不小。游戏计划穿越四个时代，配置两名由电脑控制的同伴，拥有三十多种武器、大量敌人和不同视觉环境。罗梅洛想借它证明，自己离开 id 后仍能领导大型作品，而不只是再做一张《Quake》地图。

规模很快失控。

团队围绕引擎路线变化，内容需要重做；成员之间形成派系，管理经验跟不上招聘与投资；发布日期不断后移。AI 同伴本应让旅程更有角色关系，实际却经常成为玩家负担。大量武器和时代提供了宣传数字，也显著增加平衡、美术、程序和测试成本。

那则挑衅广告此时开始反噬。正常游戏延期，玩家可能抱怨；一个先宣称要征服玩家的明星制作人延期，玩家会把每次跳票视为笑话。罗梅洛在 id 时建立的摇滚明星形象原本帮助《DOOM》和《Quake》传播，到了《Daikatana》，同一人格成了所有问题的集中收件地址。

2000 年游戏终于发行，评价与销售表现没有匹配漫长期待。失败是真实的，没必要替它找漂亮借口。罗梅洛在范围控制、技术决策和组织管理上犯了严重错误，Ion Storm 的资本与办公排场也放大了这些错误。

但把结论写成“卡马克才是真天才”同样偷懒。

《Daikatana》验证的是另一条规律：强烈作者人格能让小团队迅速形成方向，却不自动提供大型项目管理能力。罗梅洛在 id 的高光建立在一套互补关系里。卡马克解决底层难题，其他成员承担美术、声音和内容，罗梅洛把能力收束成玩家体验。到了 Ion Storm，他既要当创意领袖，又要当明星、管理者、技术路线决策者和投资方承诺的兑现人。

失去互补伙伴后，他原本被团队吸收的弱点全暴露出来。

这不说明过去的贡献是假的。恰恰说明过去的组合有多重要。

后来的失败，不能倒推早年的贡献

人脑喜欢用结局重写过程。

知道《Daikatana》失败后，再看罗梅洛在 id 的长发、跑车、宣传和 deathmatch，会觉得所有东西都是早已写好的伏笔。知道卡马克后来持续推动三维技术，再看两人初识，又会把他想成从第一天就独自掌握方向的核心。

这种倒叙很省力，却会制造假因果。罗梅洛在 Ion Storm 的管理失误，不能证明他对《DOOM》的关卡、节奏、工具和社区贡献不重要；卡马克后来取得的成就，也不能证明他在公司治理和人员判断上永远正确。同一个人在不同规模、伙伴和激励结构下，表现本来就会变化。

反过来也一样。卡马克后来道歉，不会让《Quake》的技术难题自动消失；罗梅洛后来的《SIGIL》得到认可，也不会把《Daikatana》的延期与范围失控洗掉。

成熟的历史叙事有点不讨喜，它拒绝给人物发永久标签。某次判断对，就写那次对；某次管理失败，就把失败的机制说清楚。英雄可以伤害团队，失败者也可以留下不可替代的作品。

两位约翰的关系之所以值得讲，正因为没有一个结局能把前面全部判完。

卡马克留下以后，也没有永远赢

罗梅洛离开后，卡马克继续留在 id。他推动《Quake II》《Quake III Arena》《DOOM 3》和《Rage》等项目，在三维图形、网络与引擎技术上继续前进。行业一次次等待他的技术演示，新显卡也常需要用 id 游戏证明能力。

从表面成绩看，这是“卡马克路线胜利”的最佳证据。罗梅洛遭遇《Daikatana》，卡马克继续成为图形程序设计的标志人物。

可卡马克自己后来的复盘没有这么轻松。

他承认 id 的作品间隔越来越长是一大遗憾。早期“做好再发”的态度在小项目里能保护质量，到了庞大三维制作，时间本身就是产品约束。引擎越先进，美术资产和工具成本越高，团队为一次技术跨越承担的等待越久。技术领先可以成为公司的护城河，也会成为开发周期的重物。

这正是组织基因的双面性。id 靠不断重写底层赢得地位，也因此很难满足于在成熟技术上快速做内容。卡马克最擅长解决下一代问题，可一家公司还需要稳定生产、团队成长与市场节奏。罗梅洛离开并没有自动补上这些能力。

2013 年，卡马克离开 id，投入 Oculus 的虚拟现实工作，后来又从 Meta 离开，转向 Keen Technologies 的人工智能研究。他仍在追逐同一种东西：一个边界刚刚松动、可以靠工程把它再推远的领域。

这张肖像拍于 2025 年，距离《DOOM》开发已经三十多年。镜头前的卡马克当然不是九十年代办公室里那个年轻程序员。可他谈旧事时仍习惯从机制开始：哪里设计错了，哪项技术本该拆开，什么激励产生了坏结果。

卡马克赢得了图形技术史上的位置。

他也越来越愿意承认，能把机器推到极限，不代表应该把人也推到极限。

1997 年，卡马克把源代码放了出去

1997 年 12 月 23 日，卡马克发布《DOOM》源代码。初始版本面向 Linux，不包括游戏数据资产。

README 里有一段很卡马克的说明。DOS 版本使用了有版权的第三方声音库，因此相关代码不能直接公开。他把依赖这种库称为错误，并说此后更倾向于自己编写声音代码。商业开发里，购买现成库本来很常见；在他看来，一项短期节省却让作品多年后无法完整释放，这笔账不划算。

“Wow, was that a mistake — I write my own sound code now.”

— John Carmack，1997 年《DOOM》源码发布 README；id Software 源码仓库

源码开放不意味着所有《DOOM》内容免费。怪物图像、音乐、原始地图等数据仍受权利保护，玩家需要合法拥有 WAD。程序与资产被清楚分开，社区可以改善引擎，又不必假装商业作品从未存在。

卡马克还在 README 中列出许多可以继续做的东西：透明效果、上下看、斜坡、更好的网络服务器、三维加速。他希望社区协调出跨平台、向后兼容的改进版本，而不是每个人造一个互不相容的孤岛。后来代码转为 GPL 授权，源端口在不同系统上生长。

结果远超一次怀旧发布。Linux、Windows、macOS、现代主机、浏览器和各种奇怪设备都能运行《DOOM》。有人把它移植到计算器、相机、电子阅读器，甚至只要一块设备有显示与可编程能力，社区就会问：“它能跑 DOOM 吗？”

这句玩笑建立在严肃的工程遗产上。代码能被阅读，旧格式保持兼容，玩家数据仍有价值，移植者才有机会把游戏带过一代代操作系统。

罗梅洛参与塑造的关卡文化，与卡马克推动的源代码开放，在两人分开后仍继续合作。一个让玩家想做内容，一个让程序员能改运行内容的机器。人事关系结束，技术接口没有结束。

从这个角度看，卡马克送给《DOOM》的最大礼物可能不是某个渲染技巧。

而是他最终同意，让作品在没有自己的地方继续活。

罗梅洛也没有被《Daikatana》定格

流行叙事常在《Daikatana》失败后匆匆结束罗梅洛的故事。这样结构很漂亮：离开黄金搭档，遭到惩罚，大幕落下。

现实没有配合。

罗梅洛后来参与 Monkeystone、Midway 等公司的项目，做过移动游戏、社交游戏与独立开发。不同阶段的作品影响力不等，职业道路也有起伏，但他没有停止制作。与 Brenda Romero 建立 Romero Games 后，两人继续把设计、教育和开发放在生活中心。

更有意思的是，他最终回到了《DOOM》关卡。

2019 年，罗梅洛发布《SIGIL》，作为原版《DOOM》非官方的后续章节；2023 年又有《SIGIL II》。它们没有试图用一套新引擎证明技术领先，而是在三十年前的约束里继续研究空间、敌人、视线和节奏。

这件事有一点动人，又不必煽情。年轻时的罗梅洛曾站在最新引擎前，把未知技术变成关卡语言；年过五十后，他回到那套人人都能研究的旧语言里，继续做地图。没有五十四层办公室，没有“让玩家臣服”的广告，文件仍能进入玩家熟悉的 WAD 生态。

《Daikatana》暴露了他的范围控制和管理问题，《SIGIL》则重新显示他在明确约束下的设计能力。两者都是真的。一个人可以在某类组织中表现糟糕，在另一种规模里重新找到力量；失败不必洗白，成功也不必抹掉失败。

这同样帮助我们重新看两位约翰。卡马克离开 id 后追逐 VR 和 AI，仍在扩大技术边界；罗梅洛回到关卡与社区，仍在经营玩家直接感受到的空间。他们年轻时走向不同层级的分工，几十年后变成两条更清楚的职业路线。

他们没有再一起做出一款新游戏。

可他们也从未真正逃离共同做出的那一款。

所谓“宿敌”，大部分时间是别人替他们演的

罗梅洛在回忆录里对两人关系给过一句很直接的概括。

“Carmack and I were friends, and we cared about each other, and we still do.”

— John Romero，回忆录 DOOM Guy: Life in First Person

这不等于两人对 1996 年没有分歧，也不等于一句温情回忆能取消被推动离开公司的事实。它只提醒我们，商业传记里的“决裂”与现实关系里的“从此仇恨”不是一回事。

他们后来在会议上碰见，会交谈。罗梅洛曾询问卡马克是否愿意在 AI 与游戏方向探索合作，卡马克因为具体路线不合没有加入。这个小插曲比任何“世纪和解”标题都更说明关系：两人足够友好，可以谈新的可能；也足够了解彼此，不会为了怀旧硬凑一个项目。

2023 年 12 月 10 日，《DOOM》发布三十周年，两人共同参加由 David L. Craddock 主持的直播。他们谈早期开发、技术、设计与旧日分歧。屏幕里的两个人已经不需要争夺下一款游戏的控制权，也不需要用工作时间证明股份合理。时间把最危险的利益冲突拿走了，剩下的记忆仍不完全相同，却终于可以放在同一段对话里。

罗梅洛认为，许多叙述夸大了两人的敌意，因为冲突更好卖。这个判断不能被用来反过来否认冲突。卡马克亲口承认推动他离开，足以说明当年不是一次毫无伤害的毕业旅行。

更准确的词不是多年仇人，也不是永远的兄弟。

他们是共同创造过重要作品、在压力与权力中分开、后来仍愿意承认彼此价值的前伙伴。这样的关系不够像电影，却更像成年人真正经历的友谊：你可以感谢一个人改变了自己，也可以知道再和他经营同一家公司会出事。

恩怨没有被抹掉。

它只是从神话里回到人的尺度。

2026 年，迟到三十年的道歉

到 2026 年，这段历史又多了一次公开复盘。

Sandy Petersen 直言，《Quake》拥有伟大的技术和艺术成就，却“毁掉”了当时的 id，至少把团队的精神状态推到难以承受的程度。若在九十年代，这种说法很可能立刻引发谁更努力、谁拖累项目的争辩。

卡马克这次没有防御。

他承认《Quake》同时承担了太多目标，团队本该先做 “Doom++”；承认自己把所有人逼得太紧，没有理解成熟公司必须保留余量；也再次谈到早期股份与买卖协议造成的坏激励，并向 Petersen 道歉。

罗梅洛同意先做 “Doom++” 的判断。他把当年的开发形容成一边修路，一边制造已经在路上行驶的汽车。回看有一百件事可以换种做法，但他们只能用当时知道的东西尽力。

这几句话没有推翻旧历史，只是改变了责任的分配。

《Quake》的痛苦不再只归因于罗梅洛不够勤奋，也不只归因于卡马克冷酷。技术目标过载、内容方向不稳、长期高压、股权激励和年轻创始人的管理经验一起作用。个人选择仍然重要，可选择发生在一套会把分歧放大的结构里。

我认为这比“谁赢了”有意思得多。二十多岁的卡马克靠极端专注完成许多人认为不可能的工作，同一种专注也让他把自己的耐受力误当成团队标准。罗梅洛靠人格、品味和广泛能力给游戏注入速度与可见度，同一种外向和自由在大型项目中又会分散责任。优点没有消失，它们只是换了环境，便露出背面的成本。

迟到道歉不能让 Hall 回到《DOOM》团队，不能让《Quake》开发者拿回被消耗的时间，也不能重做 1996 年的决定。

它能做的事情更小：让后来人不用再靠一个坏人解释所有问题。

两台电脑里，第一次看见对方

把所有商业、股权和传奇先放到一边。

回到《DOOM》开发期间的某一天。两台 DOS PC 连着，一台 NeXT 工作站参与调试。屏幕里的走廊还属于未完成的游戏。卡马克让网络状态同步起来，一个玩家转过身，第一次看见另一个真人控制的角色站在同一空间。

然后他们开枪。

那一刻已经包含了后来的一切。卡马克解决机器怎样彼此看见，罗梅洛立刻理解人会拿这个能力做什么。技术没有停在演示，玩法也不是脱离技术凭空出现。两个人的判断在几秒钟内接上了。

《DOOM》最强的地方，从来不是卡马克与罗梅洛谁压过谁。它来自两种注意力同时落在同一个问题上：机器多做一点，玩家就会多感到一点。

完美组合不等于永久组合。

有些搭档的意义，也不在于白头到老。就在那几年的什里夫波特和得州办公室里，在汽水污渍、漏水天花板、黑色 NeXT 方盒子和嗡嗡作响的 DOS PC 之间，他们把彼此最强的部分逼了出来，也把彼此最难忍受的部分一并放大。

屏幕里的枪声响过，另一个人倒下，又在地图某处重新出现。

这一次，没有谁需要把谁永远消灭。

文字资料来源

• John Romero、John Carmack 的 .plan 更新（1996-08-07、1996-08-08）
• John Romero — DOOM Guy: Life in First Person
• David Kushner — Masters of Doom
• John Carmack — Lex Fridman Podcast #309
• John Carmack — DOOM Source Code Release README
• WIRED — John Carmack on 20 Years of Doom
• Kotaku — Memories of Doom by John Romero & John Carmack
• The Guardian — Doom at 30: what it means, by the people who made it
• Fabien Sanglard — Game Engine Black Book: DOOM
• Ars Technica — DOOM 30th anniversary reunion
• Salon — Stormy Weather: A history of Ion Storm
• PC Gamer — John Carmack reflects on Quake and apologizes

一段“退步”的代码，重写了前端

2013 年 5 月，React 在 JSConf US 对外亮相。台上的代码里，JavaScript 和一种酷似 HTML 的标记挤在同一个文件。今天的前端开发者看到 <Comment author={user}> 大概不会抬一下眉毛，当时却不是这样。过去十几年，Web 开发一直在教育人们把结构、样式和行为分开：HTML 管结构，CSS 管外观，JavaScript 管交互。React 端上来的 JSX 像是把刚刚整理好的抽屉又一把推乱。

更可疑的是它的更新办法：数据一变，就再执行一次 render，把界面重新描述一遍；React 自己比较前后差异，再修改实际 DOM。对于已经习惯手工寻找节点、绑定事件、精确更新属性的开发者，这听起来差不多等于：房间里一盏灯坏了，先重画整栋楼的图纸。

React 团队没有否认早期反应糟糕。开源一周年时，官方回顾说外界最初多半持怀疑态度，JSX 尤其筛掉了大批潜在使用者。这里没有必要补写“全场哄笑”之类的传奇场面，史料并不支持。仅凭代码本身已经足够解释那种不适：React 不是给旧前端增加一个顺手工具，它在要求开发者重新划分责任。

过去，程序员负责告诉浏览器“怎样把界面从 A 改成 B”。React 希望程序员只说“状态 B 应该长什么样”，至于怎么走过去，由库负责。过去，HTML 模板与 JavaScript 逻辑按文件类型分家。React 则把同一个界面的标记和行为放在一起，把边界画在彼此独立的组件之间。

这才是 React 历史里最重要的转向。

很多回顾把它写成虚拟 DOM 的胜利史，好像 React 靠一项巧妙的性能优化击败了其他框架。这个说法太省事。虚拟 DOM 从来不是一颗可以单独出售的魔法药丸，React 也没有凭空发明“先保留中间表示、再计算更新”这种思想。对行业产生持久影响的，是组件、声明式渲染、单向数据、协调算法和渐进采用共同组成的一套工作方法。

此后的十几年，React 一直在重复同一个动作：先把某类复杂性收进内部，再为这份控制权支付新的代价。它接管 DOM 更新，于是要维护协调算法；它接管渲染时机，于是要重写调度器；它进入服务器，于是要面对序列化协议和远程代码执行漏洞；它走进编译器，于是要静态理解 JavaScript 的数据流；它成为多家公司共同依赖的基础设施，于是连所有权和治理都不能继续只放在 Meta 手里。

React 的发展史，说白了，是一套 UI 编程模型不断扩大责任边界的历史。

<img src="/images/react-history/responsibility-timeline.svg" alt="React 从 DOM 更新逐步扩展到移动端、调度、服务器、编译器和基金会治理">

React 出现以前，前端到底在忙什么

要理解 React 为什么显得离经叛道，得先回到 2010 年前后的浏览器。

那时 jQuery 已经把跨浏览器 DOM 操作磨得相当顺手。选择一个节点，改 class，塞一段 HTML，发起 Ajax，请求完成后再更新列表，这些事不再需要开发者亲自和每个浏览器的脾气搏斗。对于内容页、小型后台和局部交互，jQuery 是一把漂亮的瑞士军刀。

麻烦出在页面开始像应用。

一条动态可能同时影响列表、未读数、导航提醒、详情面板和推荐区域。用户在一个地方点了赞，若干视图都要跟着变化。请求可能先回来，也可能后回来；某个弹窗还保留着旧数据；一个事件处理器更新模型，模型又触发其他监听器，新的监听器继续修改界面。程序能运行，不代表谁还能说清一次点击究竟会经过多少条路径。

Backbone 给这种混乱提供了 Models、Collections、Views 和事件。AngularJS 用模板、指令、作用域与双向绑定减轻手工同步。Ember 更进一步，愿意用约定和完整框架换取一致的工程结构。它们都在解决真实问题，也都影响了 React 后来的生态。不能因为 React 后来流行，就把此前的工具写成一群等着被淘汰的笨办法。

分歧落在责任分配上：状态改变以后，谁负责维持界面一致？

命令式代码把责任交给开发者。你知道哪个值变了，也要知道它对应哪些节点，按怎样的顺序修改才不会露出中间态。双向绑定让框架替你传播变化，写起来轻快，可依赖关系一多，更新会沿着观察者网络扩散。单个绑定很好懂，几十个模型、模板和监听器互相牵动时，因果链又会躲起来。

React 选择了一个在当时相当奢侈的答案：别维护那张越来越难画的更新路线图。给定当前 props 和 state，组件重新描述界面。库保存上一次描述，算出差异，再把必要修改提交给宿主环境。开发者不再逐条维护“变化传播网络”，而是反复回答一个更稳定的问题——现在的界面应该是什么。

这种答案当然没有消灭复杂性。它只是把复杂性搬家了。

原先分散在业务代码中的节点查找、更新顺序和事件维护，被搬进 React 的 renderer 与 reconciler。开发者获得更直接的心智模型，React 团队则接手一台越来越复杂的机器。日后 Fiber、并发渲染、Suspense 乃至 Server Components，都从这次责任转移里长出来。

双向绑定不是反派，规模才是试纸

站在今天嘲笑 AngularJS 的脏检查或 Backbone 的事件链并不公平。Knockout、AngularJS 与 Ember 让大量团队第一次能把数据变化自动映射到界面，少写了成片浏览器兼容代码。小表单里，输入框和模型同步更新非常直觉；内容后台里，模板比手工拼 DOM 清楚太多。React 团队自己也是在使用 BoltJS 多年后，才从大型广告应用里确认问题。

差别在规模放大后出现。双向绑定常把依赖建立在运行时：模板读取变量，观察系统发现变化，再通知别处。开发者不必提前声明完整更新图，这是便利；调试时想知道“谁改了这个值”，同一份便利又变成遮挡。Backbone 的显式事件更可控，事件名和订阅者一多，也会形成看不见的总线。

React 用每次 render 重新读取数据，减少长期存活的点对点绑定。更新来源更集中，界面结果从当前状态推导。它付出的成本是更多重新计算、不可变数据习惯和向下传 props。AngularJS 让框架观察变化，React 要求应用明确状态所有权。很难说谁天然更先进，区别在于维护费最后落到谁的桌上。

后来 Vue 同时保留模板与响应式依赖追踪，Svelte 在编译期生成定点更新，Signals 又让细粒度订阅复兴，都说明业界没有在 2013 年找到唯一答案。React 赢得的是一种足够稳固、又能被普通 JavaScript 表达的折中。它在 Facebook 的规模下经受住考验，其他公司因此愿意相信自己也能从中获益。

<img src="/images/react-history/ui-update-models.svg" alt="命令式 DOM、双向绑定与 React 声明式更新对界面更新责任的不同划分">

Facebook 的问题不是“不会写 JavaScript”

React 不是实验室里凭空设计的一套纯洁理论，它出自 Facebook 广告业务。

官方在 2016 年做过一次源码考古。早期广告团队使用名为 BoltJS 的内部 MVC 框架，其中已经出现 render、createClass 和 refs 等后来能在 React 里看到的概念。Bolt 并非毫无章法，它允许视图保存对子节点的引用，再在数据变化时定点修改内容。放在一个组件里看，做法挺合理；应用长大后，代码开始变得难以追踪。

广告产品尤其容易把前端逼成小型操作系统。受众条件、预算、出价、素材、预览、审核状态、统计数字和错误提示同时出现在屏幕上。某个输入改变，不只改一行字，它会使别的选项失效、重新计算预估、刷新图表，甚至触发后台请求。每项业务规则都说得过去，规则连在一起就成了迷宫。

这类问题常被轻率归结为“工程师水平不够”。其实吧，越有经验的团队越容易撞上它，因为他们有能力把更多功能塞进同一页面。工具在小规模下隐藏的耦合，会在产品成功之后集体收债。

Jordan Walke 没把麻烦归到某个写坏的函数上，他怀疑的是整套更新模型。他开始做一个业余实验 FaxJS。名字后来消失了，里面却已经有 props、state、组件、大范围重新计算后比较界面、服务端渲染等 React 的骨架。其核心直觉带着明显的函数式倾向：界面最好能由数据推导出来，能少修改就少修改。

2012 年 3 月，Walke 把 FaxJS 带进 Facebook 代码库，改名 FBolt。这个时间点值得说准。许多二手时间线把“2011 年用于 News Feed”当成标准答案，React 官方源码考古给出的可核日期却是 2012 年 3 月入库。与其为了年表整齐复制一个流行数字，不如承认内部原型、试用和正式进入代码库很难压成一天。

FBolt 的技术想法很激进，进入组织的姿势却很保守。它可以和旧 Bolt 互操作，团队能够挑一个适合函数式表达的组件换掉，再观察结果。失败了，损失局部；有效，再往外扩。大公司内部的新技术若要求一口气改写全部产品，通常死在证明自己之前。React 从一开始就学会了“允许只用一点点”。

<img src="/images/react-history/facebook-hq.webp" alt="2014 年美国加州门洛帕克的 Facebook 总部入口">

后来 Jordan Walke 与 Tom Occhino 把 FBolt 改名 React。Walke 当时解释，很多系统所谓“响应式”仍要求开发者建立点对点监听，而这个 API 能对任意形态的 state 或 props 变化作出反应。名字没有夸耀速度，它描述的是职责：数据变了，系统负责让界面跟上。

XHP、FaxJS 与一条被误解的血缘

JSX 最容易被看成一个大胆的审美决定：Facebook 工程师忽然觉得在 JavaScript 里写 HTML 很酷。真实来路更务实。

Facebook 自约 2010 年起就在 PHP 中使用 XHP。XHP 允许工程师把 XML 字面量直接写进 PHP，并把自定义标签变成有类型、有行为的组件。它最初有安全动机，可以减少手工拼接字符串带来的 XSS 风险，后来又证明，把标记与负责生成它的逻辑放在一起，适合组织复杂界面。

在 React 进入 Facebook 代码库前，Adam Hupp 已做过一个用 Haskell 编写的 JavaScript 转换原型，让 XML 风格语法编译成普通函数调用。早期讨论一度纠缠于 innerHTML 与 document.createElement 谁更快。以当年的 IE8 和 Firefox 看，这不是无聊的微优化：选择不同生成方式，可能真会决定界面能不能接受。

Walke 的中间表示绕开了这场争论。JSX 不必直接创建 DOM 节点，它只要把标签变成嵌套函数调用，React 再决定如何渲染。于是语法层和宿主环境脱开：同一份组件描述可以变成浏览器节点，可以在服务器上生成 HTML，后来还可以变成 iOS 与 Android 的原生视图。

React 最终没有直接使用 Hupp 的实现，而是 fork 了 XHP 创建者 Marcel Laverdet 的 js-xml-literal 项目。JSX 这个名字也从那里延续下来。JSX 没有把 HTML 偷偷藏进 JavaScript；它为深层嵌套的函数调用提供了一套更容易阅读的写法。

这一区别解释了为什么“关注点分离”争论多年不散。

反对者认为，结构、样式和逻辑混在一个组件文件中，破坏了 Web 原有的清晰边界。React 的回答是：按技术类型分文件不等于按业务责任分离。一个点赞按钮的标记、交互状态和事件逻辑会一起变化，把它们拆到三个全局文件里，只是物理分开，维护者仍要同时打开。组件把共同变化的东西收在一处，再用 props 与外部世界连接。

这个观点有用，但不能被当成教条。组件文件可以膨胀，CSS、请求、权限和分析埋点也会重新纠缠。React 只改变了默认边界，没有自动替团队完成设计。JSX 活下来，靠的并非“混合永远优于分离”这种口号；它让什么东西应该一起变化成为可讨论的工程问题。

组件不是自定义标签，是责任边界

今天说“前端组件化”太容易了，按钮、弹窗、头像都能叫组件。回到 React 刚出现时，它更激进的地方是把状态、生命周期和界面描述收进同一个可组合单元。

一个组件接收 props，拥有或不拥有自己的 state，返回一棵元素树。父组件通过数据决定子组件看到什么，子组件通过回调报告发生了什么。这样的接口看起来像普通函数调用，却把界面中最难管的两个问题绑在一起：数据归谁，更新归谁。

一个成熟组件至少要把几类责任说清楚：

• 组件输入：哪些 props 是稳定合同，哪些值应由上层拥有；
• 局部状态：哪些变化只属于局部，生命周期跟谁一致；
• 行为输出：用户行为通过什么事件或回调向外报告；
• 副作用：哪些工作必须和浏览器、网络或第三方系统同步；
• 故障边界：异常、加载和空状态由哪一层接住。

这是一种组织代码的方式，也是一种组织团队的方式。

在旧式页面脚本里，任何功能都可能通过选择器摸到任何节点。约定写在文档里，浏览器不会阻止支付模块顺手改掉导航栏。组件树让边界可见：要影响另一个分支，通常得提升状态、传递 props、进入共享 store，或者明确使用 Context。路径变长了，却留下了因果痕迹。

React Native 官方后来总结，组件让工程师无需把整个系统都装进脑子，便能改动一个局部。这句话比“复用按钮”更接近组件化的商业价值。几行 DOM 花不了大公司多少钱；昂贵的是一次改动需要多少人互相确认，又可能碰坏多少隐含规则。

组件也带来新的治理难题。粒度太粗，一个组件拥有半个页面的状态；粒度太细，props 像快递一样层层中转。状态放低了，两处需要同步；放高了，每个细小变化都惊动大树。后来 Flux、Redux、Context、Hooks 和各种服务器状态库轮番流行，实质都在回答组件模型故意没有包办的问题：跨边界的数据到底放哪儿。

React 的框架克制为生态留下了空间，也把选择成本留给了使用者。

“状态放哪儿”成了新的前端基本功

组件模型普及后，前端面试和代码评审里多了一个此前不那么显眼的问题：谁拥有这份状态？

输入框文字只服务当前组件，可以留在本地。两个兄弟组件都需要同一选择结果，状态通常提升到最近共同父级，再通过 props 传下去。值由 React state 决定的输入叫受控组件，浏览器自身保存值的叫非受控组件。选择看起来只是 API 偏好，实际决定校验、重置、性能和第三方表单库怎样介入。

“状态提升”能恢复单一事实来源，也会让上层组件变成交通枢纽。十层组件只为把主题传到底部，就是 prop drilling。Context 为跨层共享提供通道，但它不是免费全局变量：Provider 的值变化会影响订阅者，边界过大时，局部更新又可能扩散。Redux、MobX、Zustand、Jotai 以及各种服务器状态库，正是在不同粒度和更新模型之间重新报价。

React 从未替开发者定义完整领域模型。它只通过数据向下、事件向上的默认方向，把所有权问题逼到明面。坏消息是架构讨论变多了；好消息是团队终于不得不说清楚，一份值为何存在、由谁修改、生命周期跟哪个界面一致。

这也是 React 组件比“可复用标签”更深的影响。它让状态归属从实现细节变成设计语言。组件难以拆分，往往因为几类生命周期不同的数据被塞进了同一责任边界，而非单纯因为 JSX 太长。

重新渲染，不等于重新造一遍页面

React 早期最成功、也最容易误导人的宣传词是 Virtual DOM。

它抓住了开发者的具体恐惧：实际 DOM 操作相对昂贵，如果每次数据变化都“重新渲染”，页面岂不是要卡死？React 的回答是，render 返回 DOM 应有形态的轻量描述，而非字符串或 DOM 节点。系统比较前后描述，生成一组最小的实际修改。这个过程叫 reconciliation。

2013 年官方文章拿 TodoMVC 举例，称一次重新渲染约一毫秒。这个数字只能被当成当时那个示例和环境下的官方基准，不能翻译成“React 所有页面更新都只需一毫秒”。真实成本取决于组件数量、计算、浏览器布局、设备和写法。历史文章喜欢把旧基准升级成永恒定律，技术营销就是这样悄悄变成神话的。

更关键的是，React 的价值并不要求虚拟树比较在任何场景都比手工更新快。一个知道确切节点的优秀程序员，当然可以写出更少的操作。问题是他还得保证未来每个功能、每条异步路径和每次团队交接都维持这种精确。React 用一部分通用计算，换取业务代码不必长期保存手工更新图。

这是一笔工程经济账，不是百米赛跑。

协调也不是“逐像素寻找绝对最小差异”。React 依赖启发式规则：元素类型变化通常意味着替换子树；列表中的 key 帮助识别项目身份。key 写错时，输入状态会跑到错误行，动画会奇怪，组件会被意外重建。抽象没有消除身份问题，只是要求开发者用更明确的方式表达身份。

后来 Svelte 等编译型框架会追问：既然很多更新关系能在构建时分析，为什么一定要在运行时比较树？Signals 路线又追问：能否追踪更细粒度的依赖，直接通知使用者？这些批评并未证明 React 一开始选错了，它们提醒我们，声明式 UI 有多种实现价格。React 选择通用 JavaScript、运行时协调与渐进采用，换来了表达自由，也长期背着运行时与调度复杂度。

事件系统把浏览器差异也收进了合同

早期 React 还承诺一件今天不太显眼的事：事件在不同浏览器里表现一致，连 IE8 也尽量提供统一接口。它在顶层做事件委托，把原生事件包装成 SyntheticEvent，再按组件树分发。组件作者写 onClick，不必同时处理几套绑定 API 与属性名。

这和 Virtual DOM 是同一种交易。React 不只接管节点更新，也接管事件进入应用的通道。它可以批处理事件里的 state 更新，统一冒泡行为，把浏览器兼容放进 renderer。开发者获得稳定合同，少数与原生事件不同的细节则会令人困惑，例如早期事件对象复用后异步读取失效。

React 17 为渐进升级把委托位置从 document 移到根容器，并取消事件池。看起来不起眼，却说明抽象层要不断适应浏览器本身的进步。2013 年必须抹平的差异，几年后可能已经不存在；曾经合理的全局委托，又会妨碍多个版本共存。

表单让这份合同更深入。受控输入把浏览器内部值重新交给 React state 管理，使验证、联动和重置可预测，也可能让每次按键触发组件更新。大型表单库后来会使用非受控节点、字段级订阅等方式减少成本。React 给出了统一模型，生态继续为不同规模寻找更便宜的实现。

这些细节很少出现在“React 改变前端”的宏大叙事里，实际迁移项目时却极其重要。开发者愿意从 jQuery 转向组件，不只因为思想新，还因为日常兼容工作真的少了。

Instagram 把内部工具推向了公共世界

一项公司内部技术要开源，填上许可证只是第一步，更难的是拆掉它对内部环境的隐性依赖。

2012 年 Facebook 收购 Instagram。Pete Hunt 原在 Facebook 照片与视频团队，随后加入 Instagram 新成立的 Web 团队。他想用 React 完整构建网站，这和 Facebook 内部逐个组件替换的保守路线很不一样。Instagram 不使用 Facebook 那套内部基础设施，React 若要在那里运行，就必须清理依赖、明确公共 API、拥有外部可用的构建方式。

压力反而帮了 React。

Hunt 推动 React 与 Facebook 私有环境解耦，发现并推广了当时还很年轻的 webpack，也实现了服务端渲染所需的 renderToString。设计师 Maykel Loomans 为网站做的视觉稿又确定了早期 React 网站的蓝色与原子轨道标志。一个内部实验开始拥有文档、构建、品牌和外部用户能理解的边界。

Instagram 对 React 的帮助不只是一份大公司背书，它还证明这套模型可以脱离发明它的组织运行。很多大公司项目开源后难以使用，代码质量未必差，问题常在于构建系统、权限服务、数据层和运维习惯被当成了空气。外部团队拿到仓库，才发现缺的是整座城市。Instagram 像一次提前进行的外部部署演习。

2013 年 5 月 29 日 React 开源后，Pete Hunt 又承担了大量解释工作。官方在 6 月 5 日发表《Why did we build React?》，开门见山：React 不是 MVC 框架；它是构建可组合用户界面的库；它不使用传统模板；JSX 只是可选语法。

“React isn’t an MVC framework.”

— Pete Hunt，2013 年《Why did we build React?》；React 官方博客

这些否定句很有意思。新项目通常急着列功能，React 却先说明自己不负责什么。它面对的是一个已经被 MVC、模板和双向绑定占满的概念市场，只有先拆开旧坐标系，用户才知道该把 React 放在哪里。

一年后，React 官方统计约 2300 次提交、1500 个 issue 与 pull request、接近 7000 个 GitHub star，Khan Academy、《纽约时报》和 Airbnb 等已在生产中使用。数字不算今天意义上的爆炸，却足以说明最初的排斥没有阻止第二批开发者进入。有人看中性能，有人看中 ClojureScript 等函数式语言与 React 的契合，也有人只是厌倦了追踪双向更新。

React 没有在发布当天征服前端。它靠一批愿意越过 JSX 第一印象的人，慢慢获得了可见的反例：原来这东西真的能用。

一套新语法，需要一整条工具链替它翻译

JSX 能普及，靠的不只是观念说服。浏览器不直接认识它，开发者需要转换器、source map、错误定位、编辑器高亮和构建工具。React 早期自带 JSXTransformer.js，可以在浏览器现场编译，适合演示，不适合生产。随后 JSX 进入 Babel，模块交给 webpack 组合，热更新让组件改动不刷新整页也能看到。

Pete Hunt 在 Instagram 解耦 React 时推广 webpack，不是一个无关花絮。组件把标记、逻辑和依赖收在模块里，打包器则负责从模块图产出浏览器可加载的资源，两种模型恰好互相加强。CSS Modules、代码分割和各类 loader 随后也开始围绕组件边界组织资源。

React DevTools 把组件树、props、state 和性能信息放进浏览器扩展。没有它，开发者只能看最终 DOM，很难知道某个节点由哪个组件生成。抽象层只要遮住底层，就必须提供新的观察窗。DevTools 不是配件，是 React 心智模型能够调试的条件。

工具繁荣也制造门槛。一个“只是 UI 库”的项目，安装后却要学 npm、Babel、webpack、ESLint 和几十项配置。React 的语言自由让生态能快速试验，官方没有统一工具又导致教程碎片化。CRA 后来会填这个坑；CRA 退场后，Vite 和框架再次接手。围绕 JSX 的工具史像一条摆动的钟：先分散创新，再集中默认值，默认值老化后重新分散。

React 如何随工程经验进入下一家公司

开源项目流行往往被画成下载量曲线，组织里的传播更像人员迁徙。工程师在一家公司学会组件、props、Redux 和测试，跳槽后能把同一套词带到下一家公司；组件库作者把日期选择器和表格发布到 npm，陌生团队不必从底层重做；招聘描述写上 React，又吸引更多人优先学习。

这形成了一种人力网络效应。React API 不必在每项指标上最好，只要它周围有足够多现成组件、问题答案、培训材料和有经验的同事，采用风险就会下降。Angular、Vue 也拥有各自网络，React 又因 Facebook、Instagram 和 React Native 的品牌获得早期信用。

设计系统把这种经验固定进组织。按钮不再是一段 CSS，而是带可访问性、交互状态、主题和测试的组件；产品团队组合已验证部件，平台团队维护版本与迁移。React 的 props 与组合模型很适合这类协作，Storybook 等工具又提供独立展示环境。组件复用因此从“少写几行”变成统一产品行为。

网络效应也会制造保守。公司积累几千个组件后，即使新框架在局部更快，迁移培训、组件库、监控与招聘的总成本仍可能更高。React 的地位逐渐不只由代码质量保护，还由沉没资产保护。新版本必须兼容，核心团队的选择又会影响大量无法迅速转向的组织。

React 当然也会衰落，只是框架竞争进入成熟阶段以后，胜负取决于整套迁移经济。技术社区喜欢比较语法能少写几行，企业计算的却是要花几年。

单向数据流：预测性是拿样板代码换来的

React 让组件从 props 和 state 推导界面，却没有替大型应用安排所有数据。多个组件需要同一份未读数怎么办？请求结果存在哪儿？一个动作要同时更新几个业务域，谁决定顺序？

Facebook 的回答是 Flux。

2014 年公开的 Flux 不是一个严密框架，更像一套交通规则。View 产生 action，dispatcher 把 action 送给 store，store 更新后通知 view。数据沿一个方向流动，不鼓励模型之间随意互相触发。官方当时直说，他们发现双向绑定会导致级联更新：一个模型改变另一个模型，单次交互究竟造成什么越来越难预测。

Dispatcher 单例只是 Flux 的外形。更长久的贡献，是把“发生了什么”和“界面怎么变”分开。Action 描述事件，store 负责业务状态，React 负责把结果画出来。调试者可以沿着同一个方向追踪，不必在观察者网络里来回游。

代价马上出现了。Action type、action creator、dispatcher、多个 store、订阅和清理，一个简单按钮也可能带上一串仪式。Facebook 又强调 Flux 是模式而非正式框架，社区只好自己决定每个细节。很快冒出大量 Flux 实现，各自宣称更简单、更纯、更适合异步。

这段历史暴露了 React 的典型生态机制：核心团队把问题边界说清，却不立即垄断答案；社区竞争填满空白；一种方案胜出后，又反过来塑造大家对 React 的理解。

从自由角度看，这很繁荣。从团队采购角度看，多少有点折磨。选 React 不再只是选一个视图库，还要选状态方案、路由、请求库、构建工具和测试组合。React 的“小”常常把体积转移到决策清单里。

Redux：一个演讲原型怎样成了默认行李

2015 年中，Dan Abramov 为会议演示制作一个 Flux 风格的状态库。他想展示时间旅行调试：用户执行一串操作后，开发者能在历史状态之间前后跳转，看每个 action 怎样改变应用。要做到这一点，状态变化必须可重复，旧状态不能被随手改坏。

Redux 把多个 store 收成一棵状态树，用 action 描述事件，用 reducer 根据旧状态和 action 计算新状态。Andrew Clark 等人在早期设计中参与推进。它吸收 Flux 的单向流，也受到 Elm、函数式 reducer 思路和 hot reloading 实验影响。结果是一套小得出奇的核心 API。

小核心不等于少代码。

早期 Redux 项目常见 actions/todos.js、constants/todos.js、reducers/todos.js 三件套。加一个待办事项，要先定义字符串常量，再写 action creator，再在 reducer 的 switch 中处理，异步请求还要装 thunk 或 saga。不可变更新一层套一层，漏一个展开运算符就可能直接修改旧状态。Redux 官方后来也承认，这些模式样板繁重，而且许多人在根本不需要 Redux 的地方使用了它。

它为什么仍然迅速流行？因为那时 React 的旧 Context API 很难可靠传递持续变化的数据。大型应用确实需要在组件树外组织共享状态，Flux 实现又多到让人疲惫。Redux 给出一个可测试、可记录、可接 DevTools 的共同语言。到 2016 年，社区甚至形成“用了 React 就得用 Redux”的误解。

这是一种很常见的技术宿命：配套工具一旦替核心平台补上关键缺口，就会从“可选”变成“标准答案”，然后被带去解决它不擅长的问题。

2017 年以后，新的 Context API、Apollo、React Query、SWR 等数据获取与缓存工具把问题重新拆开。服务器数据并不等于客户端业务状态，表单局部状态也不必塞进全局 store。2019 年 Redux Toolkit 又用 configureStore、createSlice 和 Immer 减少旧式样板。Redux 没有消失，它从万能行李箱退回一件有明确使用场景的工具。

对 React 史来说，Redux 的影响甚至超出自身。它让 action、reducer、不可变更新、时间旅行和单向数据流进入普通前端团队的词汇，也证明 React 留白的地方会长出比核心库更强势的生态规范。

Relay 与 GraphQL：组件还应该声明自己需要什么数据

Redux 解决状态如何变化，Facebook 同期还在处理另一件事：组件需要的数据怎样从服务器来。

2015 年初，Facebook 在首届 React.js Conf 介绍 Relay 与 GraphQL。Relay 让组件在旁边声明自己的数据依赖，框架把整棵组件树的查询组合、批处理和去重，再把结果以 props 交给组件。GraphQL 提供描述嵌套数据的查询语言与可验证 schema。两者都已在 Facebook 生产环境使用，随后才逐步开源。

这个设计把组件的“自包含”往后端推了一步。过去页面入口先请求一个巨大 payload，再把字段层层传下。子组件搬到别处，父级请求和服务端 endpoint 也要跟着改。Relay 希望组件声明自己精确需要的字段，父组件组合子组件时，数据需求一同组合。

官方当时强调，静态查询可提前抽取与校验，框架能合并重复请求、跟踪哪些组件使用哪些记录、处理分页和乐观更新。它还区分 Relay 管理的服务器数据与 Flux 管理的局部应用状态。后来“服务器状态不等于客户端状态”成为 React Query 等工具的重要主张，源头问题在这里已经很清楚。

Relay 没有像 Redux 那样成为每个 React 初学者的默认行李。它对 schema、编译与后端配合要求更高，GraphQL 自身反而越过 React 成为独立生态。但 Relay 留下的方向深刻影响了 Suspense 与 Server Components：让数据依赖靠近组件，再由框架统一安排请求，而不是每个组件在 Effect 里各发一枪。

从 Flux 到 Relay，Facebook 在做同一类组织工程。产品团队人数增加后，局部开发者应当能声明需求，系统负责把全局代价合并。React 组件不只是一块视图，它逐渐成为数据、代码与加载边界的汇合点。

<img src="/images/react-history/data-flow-ecosystem.svg" alt="Flux Redux 的单向状态循环与 Relay GraphQL 的声明式数据需求">

React 从一个库长成了一套工作方式

2015 年 10 月，React 0.14 把原来的单一包拆成 react 和 react-dom。表面看只是 import 路径变化，官方解释却很重：观察 React Native、React ART、react-canvas、react-three 等项目后，他们越来越确定，React 的美和本质与浏览器或 DOM 无关。

“The beauty and essence of React has nothing to do with browsers or the DOM.”

— Sophie Alpert，React 0.14 发布说明；React 官方博客

react 保留元素、组件类和组合所需的通用能力；负责把树挂进浏览器、查找 DOM 节点、在服务器生成 HTML 的 API 则进入 react-dom。这次拆分把早期 JSX 的潜台词写进包结构：组件描述和最终渲染目标是两回事。

从架构上说，React 开始出现清晰的三层。组件作者声明元素；reconciler 决定树怎样协调；renderer 把结果提交到 DOM、原生移动端或别的宿主。普通开发者未必需要知道这些名词，生态却因此获得了扩展点。React 不再只是“比 jQuery 更方便地改网页”，它试图成为一套跨渲染环境的 UI 内核。

0.14 还正式引入无状态函数组件。那时函数组件只能接收 props 并返回元素，没有实例，没有生命周期，也没有 state。官方把它定位成更简单的组件写法，并预告未来能为它做专门优化。四年后的 Hooks 会把函数组件从轻量配角推到舞台中央。

版本迁移的处理方式也值得注意。Facebook 当时已有超过 1.5 万个 React 组件。0.14 的大改动先给警告，旧名称继续工作到下一版本；官方还提供自己在 Facebook 使用的 codemod。React 团队很早就明白，大规模采用之后，API 设计只完成一半，迁移路径才决定新版本能否落地。

兼容性从此成为 React 的制度约束。一个年轻框架可以说“重写更干净”，基础设施不行。

从运行时警告到类型检查，组件接口越来越正式

早期 React 用 PropTypes 在开发环境检查 props。组件可以声明字段应是字符串、函数还是必填项，传错时控制台报警。它不像静态类型那样在构建前阻止错误，却让“组件期待什么”第一次能与实现放在一起。

随着生态成熟，接口检查逐渐从 React 核心移出。React 15.5 把 React.PropTypes 和 React.createClass 分别迁到独立包，核心继续收缩。Facebook 内部长期使用 Flow，外部 TypeScript 社区则为 React 维护类型定义。函数组件、泛型组件、事件与 ref 的类型不断变细，组件 props 越来越像一份可由编辑器理解的公共合同。

类型系统没有替代运行时验证。服务器传来的 JSON 不会因为 TypeScript 声明就自动可信，跨包版本也可能让类型与实际行为错位。它最有价值的地方，是在重构组件树时追踪接口变化：改一个 prop 名称，编译器能找出大量调用者；Context、reducer 与 Hook 返回值也能留下结构。

React Compiler 以后更进一步，静态分析不只检查字段形状，还要理解数据流、纯度和可变性。2013 年 React 把 HTML 风格标记引进 JavaScript，2025 年编译器进入稳定版，把 JavaScript 当成可优化的 React 程序。自由语言与更强工具并不是反方向，React 的路线一直是先允许普通 JavaScript 表达，再逐步用开发工具把隐含合同照亮。

<img src="/images/react-history/facebook-developers.webp" alt="2016 年 Facebook 门洛帕克总部的开发者办公现场">

React Native：同一种想法，两个完全不同的屏幕

React Native 常被介绍成 React 成功后的横向扩张，其实种子在 2013 年已经露出来。Pete Hunt 的早期文章提到，Facebook 做过通过 Objective-C bridge 驱动 iOS 原生视图的内部原型。轻量界面描述既然不等于 DOM，就没有理论要求它只能变成 div 和 span。

推动 React Native 走出原型的，是 Facebook 当时的移动困境。

Web 开发保存文件、刷新页面就能看到结果，Facebook 网站当时一天甚至可以发布两次。原生 iOS 与 Android 项目需要编译，平台 UI、手势、导航和线程模型又完全不同。业务团队被分成几套技术栈，实验从几小时反馈变成等待应用版本发布。公司口号里写着 “Move fast”，手机编译器可不认识这句话。

用 WebView 包一层能保留 Web 的迭代速度，却难以获得原生控件的手感与平台一致性。用 Objective-C 重写 React 思路的 ComponentKit 能得到原生性能，工程师仍得学习另一种语言和工具链。React Native 选择第三条路：JavaScript 在独立环境执行，用 React 描述界面，通过异步消息与批处理驱动 UIKit 或 Android 原生组件。

2015 年 3 月 F8，React Native for iOS 开源；同年 9 月 Android 版发布。Facebook Ads Manager 成为早期完整使用 React Native 的跨平台应用，Groups 则采用原生代码与 React Native 混合的渐进路线。

官方特意拒绝了最诱人的口号 “write once, run anywhere”。iOS 和 Android 有不同控件、手势、导航习惯与能力，假装它们完全相同，往往只能做出两边都别扭的界面。React Native 的说法是 learn once, write anywhere：工程师复用组件思想和 JavaScript 技能，但仍为每个平台做适配。

“We call this approach ‘learn once, write anywhere.’”

— React Native 团队，2015 年开源说明；Meta Engineering

<img src="/images/react-history/xperia-z3-plus.webp" alt="与 React Native Android 版同处 2015 年代的 Sony Xperia Z3+ 智能手机实机">

这句区别后来被大量营销文案抹平。跨端项目总被追问“代码复用率多少”，仿佛共享行数越高越成功。可跨端带来的主要节省常在状态模型、数据层、调试方式、人员训练和发布工具，不在某个按钮文件是否共用。为了追求百分之百复用而强行抽象平台差异，维护成本反会上升。

React Native 也不是把 Web 页面自动翻译成原生应用。早期 bridge 的往返成本、线程调度、列表性能和原生模块接入都可能成为瓶颈，团队仍需理解移动平台。后来新架构引入 Fabric renderer、TurboModules 和 JSI，正说明最初的抽象需要随着规模重做底层通道。

但 React Native 改变了一件更长久的事：React 组件模型被证明可以脱离浏览器。0.14 分包不再像洁癖，reconciler 与 renderer 的分层成了产品能力。此后谈 React，已经不能只把它放在“网页模板库”那一格。

Renderer 生态证明了抽象，也暴露了抽象成本

核心与 DOM 分离后，社区把 React 用在 Canvas、WebGL、PDF、命令行甚至三维场景。React Three Fiber 让开发者用组件描述 Three.js 对象，React PDF 把组件树转成文档结构，测试 renderer 可以在没有浏览器的环境检查输出。它们共享的不是像素，而是元素、组件、状态更新与协调协议。

这类 renderer 证明 React 的抽象确实越过 DOM。它们也提醒人们，跨宿主不是白送的。每种环境都有自己的属性、事件、布局和资源生命周期。浏览器移除一个节点很简单，三维场景可能要释放纹理与缓冲区；移动端文本嵌套规则也不同于 HTML。Renderer 作者必须把 React 的提交阶段翻译成宿主语义。

生态因此形成两类复用。业务逻辑、自定义 Hook 和状态模型可以跨平台共享，最靠近视觉与交互的组件常要分开实现。把 renderer 当成“自动适配器”会失望，把它当成“共同调度语言”更准确。

React 自己也受到这些非 DOM 环境反向约束。核心变更不能只在 Chrome 里正确，还要考虑 Native renderer 和第三方实现。抽象一旦对外开放，就会变成兼容承诺；成功的扩展点会限制未来重构。React 16 的 Fiber、后来的并发能力和 React Native 新架构，都得在共享内核与宿主特性之间反复校准。

Create React App：零配置的黄金年代

React 核心愿意保持小，入门体验却越来越大。

到 2016 年，写 JSX 往往意味着安装 Babel，模块化意味着 webpack，开发时需要服务器与热更新，代码质量要接 ESLint，生产构建还要压缩、替换环境变量、给文件名加 hash。每件工具都合理，组合起来却像一场资格考试。教程刚写完，插件版本已经不兼容。

社区把这种疲惫叫 JavaScript fatigue。Create React App 的发布文章引用了一句尖锐概括：选择 React 与 JSX，像是不知不觉选择了构建工具、样板、linter 和时间黑洞。对于只想写一个 Hello World 的人，先理解 loader 顺序实在有点过分。

2016 年 7 月，Dan Abramov 与 Christopher Chedeau 在一次 hackathon 中做出 Create React App 原型，Kevin 等协作者随后加入。它把 webpack、Babel、ESLint 和开发服务器收进 react-scripts，新项目只看到一项构建依赖和几个命令。没有配置文件，没有复杂目录；生产构建带压缩与缓存文件名。

谈不上技术突破，它把决策做成了产品。

CRA 替初学者和普通团队挑好一组兼容版本。升级一个依赖，就能拿到新的 Babel、webpack 和 lint 规则。配置封装不仅减少敲键盘，还减少“我是否选错了”的背景焦虑。Ember CLI 和 Elm Reactor 已展示过这种价值，React 终于补上自己的统一入口。

它还准备了 eject。如果默认配置不够，运行一次命令，所有依赖与脚本都会展开到项目里，此后由团队自己维护。名字很诚实：弹射座椅只能用一次。你获得全部控制，也离开官方升级轨道。

CRA 的诞生也打破了 React 团队此前的一条开源习惯：只发布 Facebook 内部投入生产的东西。Facebook 自己拥有强大的远程开发与构建基础设施，外部小团队的问题在公司内部并不存在。要改善公共生态，只能专门为外部用户做一个 Facebook 不用的项目。

这件事提醒人们，开源治理不能只说“我们把内部好东西送出来”。当一个项目拥有巨大外部社区，维护者还得照顾自己没有的使用环境。CRA 一度是 React 最成功的公共服务之一。

零配置为什么后来变成了零维护

封装复杂性有个前提：封装层必须持续有人维护。

CRA 的模型适合 2016 年的单页客户端应用。它能生成 bundle，却不负责路由；能让组件在浏览器里请求数据，却不知道某个路由进入前需要哪些数据；能用 React.lazy 分割代码，却难以让路由、代码和数据提前并行加载。页面规模增长后，开发者发现构建只是应用架构的一小块。

CRA 的代码质量并非症结。Web 应用的性能目标变了。

如果路由组件渲染后才发请求，会形成网络瀑布；如果组件渲染后才发现还要下载另一段代码，用户继续等。要优化这些路径，构建工具需要与路由、数据层、服务端渲染和缓存策略合作。CRA 若要全面解决，就会逐渐变成一个框架。

与此同时，Vite 用原生 ESM 和更轻快的开发服务器重塑了工具体验，Parcel、Rsbuild 等也提供了现代构建入口。Next.js、Remix 和后来框架化的 React Router 把路由、数据加载与服务端能力放到一起。CRA 夹在中间：作为构建工具不再轻快，作为框架又缺少关键层。

2025 年 2 月，React 团队正式弃用 Create React App。公告给出的理由很直接：它没有活跃维护者，现成框架已经在解决那些问题。新建项目会看到弃用警告；旧项目继续以维护模式工作，并有一版兼容 React 19 的发布。官方建议新应用选框架，特殊场景或学习用途可选择 Vite、Parcel、Rsbuild 自己搭建。

从“官方推荐的零配置入口”到“不再推荐”，CRA 走了不到九年。可这不算失败。它把可升级的预设配置变成一个工具类别，今天许多 CLI 和 starter 仍沿用这种模式。它的问题也留下教训：零配置并不代表没有配置，只是有人替你持有配置债务。维护者离场时，债不会一起消失。

更微妙的变化是 React 官方立场。2013 年，React 用“不是 MVC 框架”定义自己；2025 年，它建议多数新生产应用从框架开始。核心包仍是库，推荐路径已经不再假装 UI、路由、数据与服务器能够各自独立优化。

构建工具并没有消失，只是换了责任人

CRA 的故事常被总结成 webpack 老了、Vite 更快。这只讲到表面。2016 年的主要痛苦是工具版本难以拼合，CRA 用一个官方预设解决；2025 年的主要痛苦是路由、数据、代码与服务器时机难以各自优化，单纯换一台更快的 bundler 仍不够。

Vite 适合客户端应用和自定义架构，框架则在 Vite、Rspack、Turbopack 或其他工具之上继续持有配置。使用者看到的配置少了，框架维护者面对的矩阵更大：开发与生产一致性、服务端与客户端模块图、CSS 提取、预加载提示、边缘运行时、缓存失效。所谓“零配置”始终是一种劳动分工。

这对企业选型很现实。小团队也许更喜欢 Vite 的透明与速度，复杂产品愿意用框架约定换取路由和数据协同，组件库则可能只需要最薄的 React 加构建设置。React 2025 年的安装文档终于承认这些项目不是同一种应用，不再让一个 CLI 承担全部入门叙事。

CRA 退场还暴露开源维护的脆弱性。成千上万项目依赖一层配置，不等于有人愿意长期升级它。没有明确所有者、资金和发布节奏，下载量只会扩大风险半径。React Foundation 后来提出资助生态项目，正是因为核心库稳定并不足够；脚手架、路由、测试和编译插件同样决定用户能否安全升级。

许可证危机：代码能用，不等于组织敢用

2017 年，React 最大的一场危机来自一份 PATENTS 文件，与性能回归无关。

React 当时采用 BSD 许可证附加专利授权。企业开源项目增加明确专利条款并非天然恶意，Facebook 的解释是，希望向使用者授予相关专利保护，同时在对方发起特定专利诉讼时终止授权，以减少无意义诉讼成本。站在拥有大量专利、也经常面对诉讼的大公司位置，这套防御逻辑不难理解。

问题在下游。

Apache Software Foundation 把 Facebook BSD+Patents 列入 Category X，认为条款把风险不对称地传给下游使用者，也无法作为 Apache License 2.0 的子集再许可。Apache 项目不能分发这类组件。对普通个人开发者，专利终止条款也许遥远；对基金会、平台公司和需要向成千上万下游用户提供代码的项目，它会进入法务审查。

2017 年 9 月 14 日，WordPress 联合创始人 Matt Mullenweg 公开说，Gutenberg 团队将后退一步，考虑改用其他库重写；基于 React 的 WordPress.com Calypso 也会跟随长期选择。他没有指控 Facebook 必然滥用条款，甚至承认条款比很多公司的模糊做法更清楚。他的顾虑来自 WordPress 核心会下发到超过四分之一的网站：整个生态不该继承一场解释不清的专利争论。

这一下击中了 React 的网络效应。组件库选择不是单个团队的私事，它会传给插件作者、客户、再分发项目和法律部门。技术再好，如果每个采用者都要先说服律师，它就不再是低摩擦基础设施。

9 月 22 日，Facebook 宣布 React、Jest、Flow 与 Immutable.js 将改用 MIT。公告承认，团队没能让社区信服，已有许多团队开始选择替代方案，他们也不指望改证照就自动赢回来。React 15.6.2 在 9 月 25 日切换许可证，第二天发布的 React 16 同样使用 MIT。

把这件事写成“社区一骂，Facebook 良心发现”太简单。更准确的因果是：React 已成为广泛生态的基础，Facebook继续坚持一项对自身有利、却让下游承担审查成本的条款，会削弱这套生态对 Facebook 自己的价值。外部采用越成功，项目所有者越难只按内部风险偏好行事。

许可证不是仓库底部的装饰文字。对基础设施，它也是 API。

开源影响力会反过来约束原来的主人

Facebook 最初能快速推进 React，靠的是集中决策、内部生产验证和愿意长期投入的人。开源后，这些仍是优势：核心团队不必为每次重写先寻找赞助，Facebook 巨大代码库又提供了普通实验室没有的压力测试。

采用者增加，项目却出现另一类用户。Apache 关心可再分发，WordPress 关心数万插件和全球站点，React Native 公司关心移动发布周期，竞争框架关心公共标准。它们的风险模型不再与 Facebook 相同。所有者若只回答内部问题，外部生态会用迁移表达意见。

MIT 换证没有抹掉此前争议，却建立了一个预期：React 的治理决定必须考虑下游网络。后来公开 RFC、工作组、Canary 通道和基金会，都是同一压力的制度化结果。社区声音不会自动等于正确技术方向，封闭决策也很难继续获得基础设施级信任。

这是一种反向依赖。外部公司依赖 React，Meta 也依赖外部公司继续把 React 当成共同平台。生态越大，单方任性的代价越高。React 从公司资产变成行业设施，不只表现为提交者名单变长，更要求决策者开始对从未见过的下游负责。

Fiber：为了将来，先把心脏重写

React 15 以前的协调过程大体是同步递归。一旦开始渲染一棵组件树，JavaScript 会一路做下去，直到完成。页面较小问题不大；树很大、设备很慢，或一次更新伴随昂贵计算时，浏览器主线程会被占住。用户敲字、滚动、点击，也得等这轮工作结束。

这里的难题不只是“算法再快一点”。浏览器里不同工作有不同紧迫度。输入反馈必须尽快，屏幕外列表可以晚一点，已经过时的中间结果干脆不必完成。原来的调用栈不容易暂停和恢复，React 需要把渲染工作变成可管理的单位。

Fiber 就是这次重写。

“Fiber”既指新的协调架构，也指树中可保存工作状态的节点结构。React 可以把大任务切开，记录做到哪里，在合适时机让出主线程，再继续；不同更新可以拥有不同优先级。Andrew Clark 在 React 16 发布文章中直说：“我们重写了 React。”

2017 年 9 月发布的 React 16 已使用 Fiber，却没有把异步渲染能力默认交给所有应用。稳定版先带来 fragments、error boundaries、portals、自定义 DOM 属性与重写后的服务端渲染。新架构在 Facebook 和 Messenger.com 经过生产验证，未来调度能力仍谨慎隐藏。

这种发布节奏很有意思。重写内核通常诱惑团队顺便重做公共 API，React 反而努力让外部组件继续运行。官方通过兼容测试、警告和 codemod 把架构革命伪装成普通升级。React 16 的 react 加 react-dom 组合体积由官方统计的 161.7 KB 降至 109 KB，gzip 后从 49.8 KB 降至 34.8 KB，约下降三成；Fiber 更长远的收益则要到多年后才逐步开放。

为什么花这么久？因为可中断渲染会破坏许多隐含假设。组件若在 render 中做副作用，执行两次会出事；某些生命周期可能开始了却没有提交；库若以为一次更新必然连续完成，也会观察到陌生状态。调度器能暂停工作，生态代码未必允许自己被暂停。

Fiber 不是一个用户立刻感知的功能，它是 React 取得未来选择权的基础设施。代价是一段漫长过渡：Async Rendering、Concurrent Mode、Concurrent React，名称和 API 多次调整；一些生命周期被标记不安全；Strict Mode 在开发环境故意重复调用，以暴露非幂等代码。

React 开始管理的不只是界面长什么样，还有界面何时值得计算。

<img src="/images/react-history/fiber-work-loop.svg" alt="Fiber 将渲染拆成可暂停恢复的工作单元并在 commit 阶段集中提交">

Fiber 把一次更新拆成可以调度的循环：

1. 接收更新：把 state、props 或外部触发登记为待处理工作；
2. 安排优先级：区分输入反馈、过渡更新与后台准备；
3. 执行渲染：逐个 Fiber 计算下一棵组件树；
4. 暂停或放弃：主线程需要让路时保存进度，结果过时则丢弃；
5. 集中提交：只有完整结果准备好，才把变更提交给宿主环境。

RFC、发布通道与“还没稳定”的公开实验

Fiber 时代以后，React 的研究周期常常长于外界预期。某个概念先在大会演示，进入实验版本，API 改名，再等框架和库适配。对于追新闻的开发者，这像路线反复；对于需要保持兼容的基础设施，过早冻结错误接口会更糟。

2017 年 React 引入公开 RFC 流程，重大变更先写动机、设计和替代方案，让社区在代码合并前讨论。RFC 不是投票箱，核心维护者仍要做技术取舍，但设计过程留下可检索记录，外部库作者也能提前看见影响。

2019 年官方又系统解释发布通道。Latest 面向稳定版本；Next 更接近主干，供 React 自身测试；Experimental 用于可能永远不会稳定的研究能力。Facebook 内部会持续运行接近主干的构建，帮助团队在公开发布前发现回归。后来 Canary 让框架可以按固定版本采用已经较成熟、却尚未进入稳定主版本的功能。

这套机制有明显张力。框架需要提前集成，才能让 Server Components 之类的跨层功能成熟；普通用户看到框架依赖 Canary，又会担心生产系统踩在实验版上。锁定精确版本能控制变化，生态仍可能出现“React 稳定版没有，某框架早已在用”的认知差。

React 没法消除不确定性，只能给它贴标签、分通道、留讨论记录。基础设施创新无法等所有问题都想清楚再接触用户，也不能把研究原型伪装成稳定承诺。发布制度本身，成了技术架构的一部分。

错误边界与 Portal：组件树不等于 DOM 树

Fiber 的宏大目标容易盖住 React 16 解决的日常问题。

早期 React 中，渲染阶段发生异常可能让内部状态损坏，错误信息难懂，用户只能刷新页面。React 16 默认在未捕获错误时卸载整棵树，宁可显示空白，也不保留可能错误的界面；开发者可以用 error boundary 捕获子树异常，显示备用 UI。

这是一种产品态度：错误不能只在控制台里算“被处理”。支付金额、聊天对象或权限状态如果已经不可信，继续展示旧界面可能比白屏更危险。Error boundary 把故障隔离变成组件层面的责任，应用可以让某个侧栏失败，而不拖垮整页。

Portal 则允许子组件把 DOM 渲染到父组件 DOM 层级之外。模态框、提示层和浮动菜单常需要逃离 overflow、层叠上下文或布局限制。过去开发者要在组件归属与实际节点位置之间做别扭选择，Portal 明确区分两棵树：组件仍属于原来的 React 父级，事件和 Context 沿组件关系传播；DOM 节点可以挂到别处。

这两个功能都在强化同一件事：React 的抽象对象是组件关系，不是 DOM 文件夹。DOM 是一个 renderer 的提交结果，不能反过来完全决定应用结构。

Hooks：类组件的问题不在 class 这个词

2018 年 React Conf，Sophie Alpert 与 Dan Abramov 公布 Hooks。2019 年 2 月，React 16.8 将它稳定发布。此后几年，函数组件几乎成了 React 教程的默认语言。

如果只说“Hooks 让代码更短”，会错过它所要解决的核心问题。

类组件把相关逻辑拆在多个生命周期里。订阅在 componentDidMount 建立，在 componentWillUnmount 清理，props 改变后还要在 componentDidUpdate 重新同步。一个生命周期又可能混着标题更新、网络订阅和统计上报几件互不相干的事。复用有状态逻辑时，团队依赖 render props 或高阶组件，组件树套出层层包装，DevTools 里像一串俄罗斯套娃。

Hooks 允许函数组件调用 useState、useEffect 等能力，自定义 Hook 可以把一组状态与副作用协议抽成普通函数。它复用的是逻辑，不是渲染层级。与其说函数组件取代 class，不如说 Hook 为组件增加了另一种组合轴。

官方采取了很克制的迁移口径：不建议一夜重写旧应用，Hooks 与 class 可以并存，没有移除 class 的计划。React Native 在 0.59 支持 Hooks。这样的兼容承诺降低了采用风险，也让新旧范式长期共处。

Hooks 同时把一套新的执行模型暴露给开发者。Hook 必须按固定顺序调用，不能随意放进条件分支；闭包会捕获某次 render 的 props 和 state；Effect 依赖数组写少了会读旧值，写多了可能反复建立连接；对象与函数的引用变化又会触发子组件或 Effect。

这些问题不是语法瑕疵，它们来自 React 的函数式渲染模型。每次 render 都像一次新的函数调用，每个闭包属于那次调用。开发者如果把组件理解成“有一份变量会不断更新的对象”，就会和 stale closure 撞个满怀。

React 16.8 强烈推荐 eslint-plugin-react-hooks。也就是说，API 表面变轻，部分正确性却交给静态工具维护。只靠运行时，React 很难知道某个条件调用是不是故意，也无法判断漏掉的依赖。Hook 能够成为主流，靠的是语言约定、lint 规则、DevTools 和团队习惯共同组成的制度，函数写法本身并不足以取代类。

从 mixin 到 Hook，React 花了六年寻找逻辑复用

React 刚开源时，createClass 支持 mixin。组件可以混入订阅、窗口尺寸或权限逻辑，快速获得 state 与生命周期方法。这照顾了面向对象时代的使用习惯，也让早期采用容易一些。

规模上来后，mixin 的隐式依赖开始伤人。组件调用一个本文件没有的方法，要逐个翻 mixin 才知道来自哪里；两个 mixin 都定义 handleChange 会撞名；mixin 还能依赖另一个 mixin，共享同一 state 与方法命名空间。官方 2016 年《Mixins Considered Harmful》提到，Facebook 已出现大家不敢碰的组件，复杂性的一部分正来自这些扁平混入关系。

社区随后使用高阶组件：函数接收一个组件，返回包着它的新组件。订阅与权限逻辑有了明确 props 接口，却容易形成多层 wrapper，静态属性、ref 和命名调试也要额外处理。Render props 把复用逻辑放进带函数子节点的组件，数据流更显式，嵌套一多仍会挤占 JSX 结构。

Hooks 没有让此前模式“失效”。它改变了复用单位：自定义 Hook 只是函数调用，不增加组件层级，可以组合其他 Hook，返回值由作者明确命名。依赖仍可能复杂，至少不再把方法悄悄倒进同一实例。

这条演化路线说明 React 的“组合优于继承”也不是发布第一天就完成的答案。框架先提供迁移旧习惯的逃生门，真实项目暴露问题，再寻找更符合自身执行模型的抽象。今天看起来理所当然的 useSomething()，背后是 mixin、HOC 和 render props 轮流交过的学费。

它还解释了 React 为什么对 class 保持兼容。旧组件不是错误代码的博物馆，其中装着多年业务。新抽象若只能通过全量改写证明优雅，组织往往宁可不要这份优雅。Hooks 能逐个组件、逐段逻辑进入，才有机会成为主流。

测试文化也从“检查内部”转向“观察行为”

组件抽象出现后，测试该看什么成为新争论。React 早期提供 TestUtils 和 shallow renderer，Enzyme 又让开发者方便地找到组件实例、读取 state、调用生命周期。测试能精确确认内部结构，却容易和实现绑死：把 class 改成函数，用户看到的界面没变，大量测试先碎。

React Testing Library 推动另一种方向：尽量像用户一样通过文字、角色和可访问名称寻找元素，点击后观察页面结果，不把组件内部 state 当公共合同。这不保证测试自动优质，却与 React 的声明式承诺更一致——组件如何算出界面是实现，用户能否完成任务才是行为。

Hooks 与并发渲染又使测试时机复杂化。state 更新、Effect 与 Suspense 可能分几个阶段完成。React 16.8 加入 act()，要求测试把会触发更新的操作包起来，再在 React 刷新相关工作后断言。测试工具通常替用户调用它，泄漏时那句 “not wrapped in act” 仍会把许多开发者折腾半天（这条警告的教育方式，确实谈不上温柔）。

React 18 后，测试库还要适应可中断渲染、Strict Mode 重复调用和异步边界。核心团队改变调度器，测试生态必须重新定义“完成”是什么意思。一次点击后立刻读 DOM 的旧习惯，不一定代表用户最终看到的结果。

这段演变与 React 本身很像：从直接检查对象和节点，转向描述输入与可见结果；内部实现因此更自由，等待与查询的规则却更严格。抽象不会减少所有测试复杂性，它只是告诉团队，哪一部分复杂性值得写进长期合同。

Effect 的十年后遗症

Hooks 最有争议的部分一直是 useEffect。

它原本用于让组件与 React 之外的系统同步：网络连接、浏览器 API、订阅、第三方控件。可“副作用”这个词太宽，教程很快把请求数据、派生状态、事件响应、初始化和任何看起来不属于 JSX 的逻辑都塞进去。于是一个组件先渲染空状态，Effect 再请求，回包后再渲染；子组件此时才开始请求，网络瀑布就形成了。

依赖数组又让许多人产生一种错觉，好像它是“什么时候运行”的手动开关。实际它应当描述 Effect 使用了哪些响应式值。为了阻止重复执行而删除依赖，通常只是把同步关系藏起来。lint 报警被关掉，代码短期安静，几个月后读到旧 props。

React 新文档后来花了大量篇幅教人“你可能不需要 Effect”。能在 render 中算出的值直接算；用户点击造成的逻辑放进事件处理器；数据请求最好交给框架或专门缓存库；外部系统同步才是 Effect 的主场。文档不是突然转向保守，生态只是用几年真实项目交了学费。

React 19.2 的 useEffectEvent 又尝试拆开 Effect 中“需要响应依赖变化的同步逻辑”和“总要看到最新值、却不该让连接重建的事件逻辑”。例如聊天房间由 roomId 决定是否重连，连接成功提示需要最新主题颜色；主题变化不应让房间断开再连接。新 API 让这种事件读取最新值，又不成为 Effect 依赖。

一个 API 发展到需要专门文档、lint 和新 Hook 去解释边界，不代表它一无是处。它说明 React 把“同步外部世界”抽象成通用原语后，使用范围比设计意图扩张得更快。

老实说，Hooks 是 React 最漂亮也最别扭的一次成功。它让逻辑组合变得自然，又让闭包时间、引用身份和依赖关系成为每个初学者必须补修的课程。

React 17：一版“没有新功能”的基础设施

2020 年 10 月，React 17 发布。官方标题下最醒目的一句话是：没有新的面向开发者功能。

放在追求发布声量的软件行业，这近乎反营销。主版本通常要端出足够多的新 API，证明升级值得。React 17 却把主要精力用在让未来升级没那么危险。

此前，一个页面若同时运行两个 React 大版本，事件系统很容易互相踩踏。React 16 及更早版本通常把事件处理委托到 document，整页共享一个顶层入口。React 17 改为把事件绑定在各自根容器。这样，页面中的一块旧区域可以留在 React 17，另一块逐步升级到未来版本，非 React 应用嵌入组件也更稳。

官方把它称作 stepping stone release，一块过河用的踏脚石。大多数项目仍适合一次升级，加载两份 React 也不理想；可对于多年积累、缺少维护者的巨大代码库，“全部一起改”往往等于永远不改。渐进升级不是技术炫技，它承认组织改造有速度上限。

Facebook 用自身规模验证改动：官方称十万多个组件里，为适配 React 17 只修改了不到二十个。这个数字不是对所有公司的保证，却说明 React 团队衡量升级成本的单位早已不是示例项目。

React 17 还支持新的 JSX transform，并把支持回移到 16.14、15.7 和 0.14.10。新转换不再要求每个 JSX 文件显式 import React，但经典转换继续工作。连这种小语法便利也选择可选与回移，背后还是同一种治理习惯：React 可以变，用户不必同一天变。

没有新功能的版本，处理的是软件成功以后最不性感的问题——旧代码怎样不被未来抛下。

当组件越过浏览器，React 也开始失去边界

2022 年 3 月，React 18 把 Fiber 多年前准备的调度能力正式推到主线。自动批处理、startTransition、useDeferredValue、支持 Suspense 的流式服务端渲染一起出现，核心概念叫 Concurrent React。

“并发”很容易让人想到多线程。React 18 没有把普通 JavaScript 运算自动拆到几个 CPU 核上，也不会让一个死循环变流畅。它改变的是渲染工作的可中断性。

同步渲染一旦开始，会连续计算到可以提交。并发渲染可以启动一次更新，做一部分，暂停，让浏览器先处理更急的输入，再继续；如果期间来了更新结果，旧工作甚至可以被放弃。React 仍会等完整树准备好后再修改可见 DOM，避免用户看到半新半旧的界面。

这让更新出现优先级。用户在搜索框输入字符，输入内容必须立即显示；根据关键词过滤上万条列表，可以被标记成 transition，晚一点完成。列表计算的成本并没有消失，React 只是允许低紧迫工作让开主线程，先完成高紧迫反馈。

自动批处理处理了另一个日常细节。React 18 以前，React 事件处理器里的多次 state 更新通常合并一次渲染，但 Promise、setTimeout 或原生事件里的更新未必如此。新版本把更多场景自动批处理，减少无意义的中间 render。需要立即同步提交时仍有 flushSync，只是那是明确的逃生门。

并发渲染也要求组件更纯。一次 render 可能暂停、重复或丢弃，render 里的副作用就可能执行多次却没有对应提交。Strict Mode 在开发环境故意重复调用某些逻辑，很多开发者觉得它“制造 bug”；实际上它把生产中未来可能出现的不安全假设提前放大。

React 18 的发布策略仍然渐进。只有使用 createRoot 和并发能力的部分才启用新行为，旧应用可以先完成基础升级。官方还组建 React 18 Working Group，让框架与库维护者提前反馈。因为调度器一旦改变时间顺序，受影响的不是 React 自己，整个组件、测试和状态生态都要学会被打断。

Suspense：加载状态也要进入组件树

Suspense 的外观看起来很简单：子树还没准备好，就显示最近边界的 fallback。可它背后的野心远大于一个 loading spinner。

传统应用在每个组件中手写 isLoading、error 和数据状态。父子请求互相嵌套后，页面先出骨架，某块回来，下一块才开始，布局不断跳。加载顺序散在事件与 Effect 中，React 只看见每次请求结束后的结果，不知道整页何时算准备好。

Suspense 把“这部分暂时无法完成”变成渲染协议。组件可以暂停，边界决定用户先看到什么，流式 SSR 则允许服务器先发送页面外壳，再把准备好的片段插入。加载不再只是数据层的一枚布尔值，它进入界面结构。

这也解释了为什么 React 18 不建议普通应用随手用 Suspense 做临时数据请求。要避免瀑布，路由、缓存、请求生命周期和服务器渲染必须配合。官方列出 Relay、Next.js、Hydrogen、Remix 等有明确架构的环境。React 提供协调原语，框架负责把数据系统接进去。

从这里开始，“React 只是视图库”的说法越来越难维持。核心包当然没有自带数据库与路由，Suspense 的最佳效果却要求它知道代码、数据与渲染何时就绪。UI 边界开始反过来约束应用架构。

从 renderToString 到选择性 hydration

React 很早就能在服务器生成 HTML。Instagram 的外部化过程推动了 renderToString，2013 年官方也把 SEO、性能和代码共享列为服务端用途。可早期 SSR 更像一场视觉魔术：服务器先给用户可读 HTML，交互能力仍要等浏览器下载 JavaScript，再用同一组件树进行 hydration。

旧流程有三道“整页闸门”。服务器往往要等全页数据齐全才开始输出；浏览器要等全页组件代码下载完才开始 hydration；hydration 一旦开始，又会连续处理整棵树。评论区请求慢，导航和文章也跟着等。用户虽然早早看到按钮，点击时可能毫无反应，因为干燥的 HTML 还没接上事件。

React 16 重写服务器 renderer 并支持流式输出，主要改善发送速度。React 18 把 Suspense 接进服务器流程后，才允许不同边界分别通过这些阶段。服务器可以先发送页面外壳和 fallback，较慢内容准备好后继续流出；浏览器可以优先 hydration 用户正在交互的区域，不必让一个重量级评论组件堵住导航。

这叫选择性 hydration。它没有让下载和执行成本消失，而是拆掉“最慢部分决定整页进度”的顺序。性能从总耗时问题变成调度问题：哪块先可见，哪块先可点，哪些代码可以晚来。

SSR 也因此更依赖框架。服务器要收集数据、处理流、插入脚本、管理缓存与错误，客户端要匹配同一模块图。只调用一个 React API 能做实验，稳定生产还涉及路由与部署环境。React 在核心中提供流水线零件，框架开始负责整条装配线。

Server Components：组件越过了网络

2020 年 12 月，React 团队公开 “Zero-Bundle-Size React Server Components” 研究演示。当时官方反复强调仍在研发，不催社区立即采用。这个谨慎有理由：Server Components 不是给现有 SSR 换个名字，它重画了组件在哪儿执行的边界。

传统 SSR 在服务器把 React 树生成 HTML，浏览器下载 JavaScript 后 hydration，让同一界面恢复交互。组件代码通常仍会进客户端 bundle。Server Component 则只在服务器或构建环境执行，可以直接读取数据库、文件和服务端依赖，它的代码不发送到浏览器。需要交互的 Client Component 保留在客户端，两种组件通过协议组成一棵树。

这解决了几个长期矛盾。Markdown 解析器、日期库或数据访问代码可以留在服务器，减少客户端 JavaScript；数据读取可以靠近组件，不必把每个字段再做成一层 HTTP API；服务器返回的不是最终 HTML 字符串，而是一种能与客户端组件状态合并的表示。

听起来像免费午餐，边界规则却非常具体。Server Component 不能使用浏览器状态与 Effect，Client Component 不能直接访问数据库；从服务器传给客户端的 props 必须可序列化；"use client" 会划出模块图边界，边界下的依赖可能进入客户端 bundle。设计不好，一句指令就能把本想留在服务器的代码带回浏览器。

RSC 也不同于 SSR。一个应用可以有 Server Components 却在请求时或构建时产生表示，也可以结合 SSR 把首屏输出为 HTML。两者解决不同层级：RSC 决定组件代码与数据在哪执行，SSR 决定初始页面怎样变成可见 HTML。

React 19 把面向使用者的 Server Components 能力纳入稳定范围，却提醒框架和打包器作者：底层实现 API 在 19.x 小版本间仍可能变化，最好锁定具体版本或使用 Canary。这句注释很重要。对普通开发者，“稳定”意味着写组件的模型可用；对实现框架的人，脚下仍是施工地面。

缓存成为树里看不见的第二份状态

组件在服务器读取数据后，一个问题立即追上来：同一请求要不要复用？下一次导航呢？不同用户之间呢？结果保存多久，什么操作让它失效？

客户端 React 的 state 通常跟组件实例生命周期绑定，开发者能在树上找到它。服务器缓存可能存在进程、请求、数据中心或 CDN，生命周期不再直观。框架为了性能复用结果，用户却可能看到过期数据；每次都重新获取更容易理解，又会失去 RSC 与预渲染的许多收益。

React 提供 cache 等原语，19.2 的 cacheSignal 还能在某次缓存生命周期结束时中止或清理工作，但缓存策略仍主要由框架与部署环境决定。Next.js 某个版本的默认缓存行为，不等于 React Server Components 本身的永恒语义。把两者混写，是许多教程让人迷惑的来源。

Server Actions 又必须在变更数据后触发正确的失效与刷新。乐观界面可以先变，服务器事实稍后确认，缓存再更新。这里同时存在用户看到的 UI state、服务器持久数据、请求中的临时结果和框架缓存。所谓“全栈 React”并没有把状态合成一种，反而要求工具明确协调四种时间。

这也是 RSC 学习成本的核心。语法只有 "use client" 和 "use server" 几个词，难点在于数据跨过边界后由谁保存、何时重算、失败怎样回滚。组件靠近数据能减少胶水代码，也把缓存治理带进组件架构。

Next.js 与 Vercel：合作越成功，边界越敏感

Server Components 没法只靠 react 包落地。它需要路由决定服务器与客户端导航，需要打包器理解模块边界，需要部署平台执行服务器函数与流式响应，还要处理缓存、预取和错误恢复。Next.js 成为最早、最完整的承载者。

这段合作推动了 RSC 从研究演示进入真实项目。Next.js App Router 把 Server Components、嵌套路由、布局、Server Actions 和流式渲染组合成开发体验。React 团队获得大规模反馈，Vercel 则获得与 React 未来方向深度绑定的产品差异。

成功也带来怀疑。

React 文档越来越推荐框架，新能力先在 Next.js 中可用，社区会担心核心路线是否被一家托管公司左右。其他打包器若必须追逐未稳定的 RSC 协议，就很难提供同等体验。对使用者来说，“这是 React 的限制，还是 Next.js 的选择”也常混在一起。

简单指控 Vercel “绑架 React”不准确。React 18 已公开与 Next.js、Remix、Hydrogen 等合作，2025 年 RSC 漏洞修复又涉及 React Router、Waku、Parcel、Vite RSC 插件和 RedwoodSDK。全栈功能天然需要深度集成，最早投入最多的框架也必然走在前面。

但结构性风险真实存在：当一个库的关键价值只能由少数框架兑现，框架实现者就获得解释标准的权力；当框架商业模式又与托管平台相连，技术默认值会影响部署选择。要约束这种风险，就得承认利益关系，稳定公共协议，扩大实现数量，并把技术治理与资源董事会分开。

React Foundation 后来的治理设计，部分就在回应这种成熟生态的敏感性。

React 19：表单提交为什么成了核心能力

2024 年 12 月，React 19 稳定发布。最醒目的新概念是 Actions。

一次表单提交看似普通，真实应用却要管理 pending、错误、乐观更新、并发请求、成功跳转和表单重置。过去这些状态由开发者分别放进 useState，请求开始设为 true，结束设回 false，失败回滚，成功刷新。每个项目都会写一遍，边角条件也各漏一遍。

React 19 允许异步函数在 transition 中作为 Action，自动关联 pending 与错误处理；useActionState 管理 Action 的结果和状态，useOptimistic 先展示用户期望的结果，useFormStatus 让按钮读取父表单状态，<form action={fn}> 把函数直接接到提交过程。React 把一套反复出现的异步 UI 协议收进核心。

新的 use API 可以在 render 中读取 Promise 或 Context。读取尚未完成的 Promise 时，组件暂停并交给 Suspense 边界。它和普通 Hook 不完全一样，可以在条件分支中调用，却仍只能处于 render。官方同时提醒，不要在 render 中临时创建未缓存 Promise，应由支持 Suspense 的库或框架提供。

这些 API 让客户端表单更省事，与 Server Actions 结合时又能让客户端组件调用服务器异步函数。框架根据 "use server" 建立引用，客户端发出请求，服务器执行后返回结果。这里必须纠正一个常见混淆："use server" 标记的是可远程调用的服务器函数，不是每个 Server Component 的标志；Server Component 本身没有对应指令。

React 19 还允许函数组件把 ref 当普通 prop，改进 hydration 错误差异，提供等待数据完成的静态预渲染 API。这些改动放在一起，React 的关注点已经从“点击后改哪个 DOM”走到“异步操作跨客户端与服务器完成时，界面如何保持连贯”。

框架边界又向外挪了一格。

19.2：渲染器开始管理“暂时看不见的未来”

2025 年 10 月发布的 React 19.2 没有 React 19 那样醒目的范式口号，却把并发和服务器方向继续推深。

<Activity> 允许把应用区域设为 visible 或 hidden。隐藏时，DOM 可以保留，Effect 被卸载，更新降到较低优先级；重新显示时，输入值等状态能够恢复。它适合预渲染用户可能访问的下一页，也适合返回时保留旧页面状态。

过去条件渲染通常意味着组件不存在，状态也随卸载丢失。Activity 把“不可见”从一个布尔判断升级成调度状态：内容虽然暂时不在用户眼前，React 仍能在空闲时准备它。Fiber 当年争取的时间控制权，到这里变成普通组件 API。

19.2 还加入部分预渲染。应用的静态外壳可以提前生成并放进 CDN，动态部分在请求到来后从保存的 postponed state 继续渲染。它试图把静态生成与动态 SSR 从二选一变成同一棵树的两个阶段。

这些能力通常不会由业务组件直接裸用。框架要决定路由何时隐藏、资源如何预取、预渲染结果怎样缓存。React 核心提供更细的渲染状态，框架把它们编排成产品路径。两者的界线越来越像操作系统内核与发行版：理论上可以只用内核，普通人使用的却是整套组合。

React Compiler：把纪律从运行时搬到构建期

React 长期要求开发者理解引用身份。父组件每次 render 都创建新对象或函数，子组件的 memo 可能失效；昂贵计算用 useMemo，回调用 useCallback。写得多了，组件里到处是为了优化而存在的依赖数组，核心业务逻辑反而被包在中间。

编译器是 React 对这笔手工税的回答。

团队探索编译优化并非突然起意。2017 年的 Prepack 尝试提前执行 JavaScript，项目后来停止，却影响了 Hooks 设计。2021 年 Xuan Huang 演示新编译器原型，后续团队多次重写架构，采用基于控制流图的高级中间表示，分析数据流、可变性与 React 规则。

2025 年 10 月，React Compiler 1.0 稳定。它作为构建期工具自动 memoize 组件和 Hook，不要求重写现有代码，并兼容 React 17 及以上版本。由于能理解条件分支与具体值使用，它有时可以做到手工 useMemo、useCallback 难以表达的细粒度缓存。

编译器不只是性能插件。它的验证阶段编码了 Rules of React，通过 eslint-plugin-react-hooks 暴露违反纯度、在 render 中 setState、不安全读取 ref 等问题。原来靠文档与 lint 猜测的纪律，开始由更强的数据流分析支撑。

可别把它写成“从此不用思考性能”。官方明确保留 useMemo 和 useCallback 作为精细控制的 escape hatch，尤其当稳定引用还是 Effect 依赖协议的一部分。既有项目也不应为了代码好看一口气删除手工 memoization，因为删除可能改变编译输出，进而影响依赖某些引用稳定性的 Effect。

Meta 公布过 Quest Store 的早期结果：初始加载和跨页导航最高改善约 12%，部分交互快于原来的 2.5 倍，内存大致不变。官方也紧跟一句“实际效果因项目而异”。编译器不是把每个应用统一加速，它更像自动寻找开发者原本可能写、也可能忘记写的缓存边界。

React 最初用运行时 reconciliation 允许开发者“重新描述整个界面”；十二年后，它又用编译器降低这种写法的运行时成本。路线没有放弃运行时，而是多加一层理解 JavaScript 的机器。

2025 年安全事故：前端库第一次像服务器框架那样补洞

2025 年 11 月 29 日，Lachlan Davidson 向 Meta 漏洞赏金计划报告 React Server Components 的安全问题。12 月 3 日，React 团队公开 CVE-2025-55182：攻击者可以构造恶意请求，利用 React 解码 Server Function payload 的缺陷，在未认证情况下实现服务器远程代码执行。CVSS 评分 10.0。

公告要求受影响用户立即升级 react-server-dom-webpack、react-server-dom-parcel 或 react-server-dom-turbopack 的修复版本。Next.js、React Router 的实验性 RSC、Waku、Parcel RSC、Vite RSC 插件和 RedwoodSDK 等集成也进入升级清单。托管商部署了临时缓解，React 团队仍强调不能依赖缓解替代升级。

影响范围必须说准。纯客户端应用若不使用服务器，不受这个漏洞影响；没有采用支持 RSC 的框架、打包器或插件，也不在同一范围。把新闻标题缩成“所有 React 网站都能被接管”既不专业，也会让受影响的团队错过判断条件。

随后官方又披露拒绝服务与源代码暴露问题。源代码暴露主要涉及硬编码在 Server Function 源码里的秘密，环境变量一类运行时秘密不在同一暴露方式内。到 2026 年 1 月，补丁时间线仍在更新。

这组事故值得写进历史，关键不在漏洞数量，在责任变化。

2013 年的 React 处理浏览器中的轻量界面描述。2025 年的 React 在服务器反序列化来自网络的 payload，把引用翻译成函数调用，并协调框架、打包器与托管平台发补丁。攻击面不是偶然闯入，它跟着能力一起进入。

React 可以说底层协议由框架使用，框架也可以说协议来自 React。用户不会关心责任怎样分摊，他们只想知道该升级哪个包。这迫使生态建立更成熟的安全发布、版本锁定和跨项目通报机制。RSC 把 JavaScript 从浏览器 bundle 中拿走一部分，也把服务器安全这份新账单递了进来。

技术扩张从来不是只拿能力，不拿责任。

React Foundation：Meta 放下所有权，不等于退出影响力

2025 年 10 月，React 团队宣布建立 React Foundation 的计划。2026 年 2 月 24 日，基金会在 Linux Foundation 托管下正式成立。

React、React Native 和 JSX 等支持项目不再归 Meta 所有。八家白金创始成员是 Amazon、Callstack、Expo、Huawei、Meta、Microsoft、Software Mansion 和 Vercel。基金会董事会由成员代表组成，Seth Webster 任执行董事，负责基础设施、商标、会议、资金与生态项目。

官方特意把技术治理与基金会董事会分开。技术方向继续由日常贡献和维护 React 的人决定，临时领导委员会负责设计更具体的结构。到正式成立时，仓库、网站与基础设施迁移仍在进行，技术治理细则也没有全部定稿。

这种分离不是形式主义。董事会成员投入资金，当然希望生态健康；它们也各有云服务、移动工具、咨询或框架利益。若出资额直接换成 API 决策权，基金会只会把“Meta 控制”改成“联盟控制”。把资源治理和技术治理拆开，至少在制度上承认两种权力不该自动等价。

Meta 也不会因为移交所有权就失去影响力。它仍有长期维护者、巨型生产代码库和持续投入，工程经验会自然影响路线。Vercel、Microsoft、Expo 等同样通过框架、工具与雇员参与获得影响。基金会的职责是让这些影响通过更可见的规则发生，避免任何一家公司的产品变化直接变成项目所有权变化；它无法把影响本身清零。

基金会不是“社区接管”的完成时

把项目迁入 Linux Foundation 很容易被写成独立大结局，正式公告其实用了大量将来时：仓库、网站和基础设施还要转移，技术治理结构还要定稿，生态支持计划也待建立。法人归属改变是重要起点，不会自动解决维护者负担、路线透明和框架代表性。

“厂商中立”能否落地，要看日常权力怎样运行。谁能成为维护者，重大 RFC 如何收敛，安全事件由谁协调，不同 renderer 与框架是否有稳定发言渠道，会议和资助是否只照顾最有商业资源的成员？这些细节比董事会名单更有判断力。

八家创始成员的构成已经反映 React 的责任范围：云平台需要它稳定部署，移动公司依赖 React Native，框架与咨询团队维护生态，Meta 仍贡献核心经验。Huawei 在正式成立时加入，也让成员范围不只局限于最初七家公司。多元利益可以互相制衡，也可能让决策变慢；慢一点有时正是基础设施需要支付的保险费。

社区同样不能只要求企业交出控制，再假设志愿劳动会填满空缺。CI、发布、安全响应、文档与大会都需要长期资源。基金会的价值要在几年后衡量：它是否把公司投入转成不依赖某家公司善意的公共能力。

从 2017 年许可证危机到 2026 年基金会，React 用九年才把“谁拥有代码、专利、商标和技术方向”逐层拆开。一个内部工具开源时，Meta 的集中投入是优势；当它成为多家公司共同基础设施，同一种集中又会变成信任风险。

组织结构也必须 reconciliation。

<img src="/images/react-history/modern-react-stack.svg" alt="现代 React 从组件、协调器和 renderer 延伸到服务器、编译器与基金会治理的责任栈">

React 到底留下了什么

如果把 React 的遗产压成一张 API 清单，很多项目已经过时。createClass 退出主流，mixins 被官方劝退，类生命周期让位于 Hooks，CRA 从推荐入口变成维护模式，Concurrent Mode 这个名字也换成了 Concurrent React。今天最流行的写法，几年后仍可能被新文档重新解释。

更稳定的遗产，是几种已经进入行业日常的判断：

• 界面可以被当作状态的函数来描述；
• 组件边界可以同时服务代码结构与团队协作；
• 宿主环境不必决定组件模型，renderer 可以更换；
• 异步会影响界面何时完整、哪部分先显示、哪些工作值得继续；
• 兼容性不是保守的同义词，而是创新抵达真实代码库的运输系统。

React 也留下了一串没有彻底解决的问题。状态应该局部还是全局？运行时协调与编译期更新怎样取舍？组件该知道多少数据来源？服务器与客户端边界由谁决定？核心库、框架、托管平台和基金会之间的权力怎样透明？每一代 React 都给出新答案，又让下一代问题更大。

我不太赞成把 React 写成前端的唯一正确道路。Vue 证明模板与组件可以有另一种平衡，Svelte 把更多工作移到编译期，Signals 路线重新强调细粒度响应，服务端模板和 Web Components 也从未消失。React 的流行有技术质量，也有 Facebook 的规模、人才投入、招聘市场、社区网络和框架商业化共同作用。胜利从来不只发生在 benchmark 里。

可它确实改变了行业讨论方式。今天即使一个框架公开反对 Virtual DOM，也往往仍在谈组件、声明式界面、状态所有权、服务端与客户端边界——这些问题有很多不是 React 发明的，却被 React 推进了普通开发者的日常工作。

再回看 2013 年那段古怪的 JSX，令人惊讶的已经不是大家接受了“在 JavaScript 里写标签”，而是另一份合同成了行业常识：开发者描述现在，系统负责把过去变成现在。

十三年里，那个“系统”从几千行浏览器代码长成了调度器、移动 renderer、服务器协议、编译器和基金会。每多接一层，它就更有能力，也更难继续自称只是一件轻巧工具。

屏幕上，一个组件仍只是返回几行 JSX。

屏幕背后，已经站着整段前端工业史。

资料来源

• React 官方：Our First 50,000 Stars
• React 官方：Why did we build React?
• React 官方：One Year of Open-Source React
• React 官方：Flux: An Application Architecture for React
• Redux 官方：The History of Redux
• React 官方：React v0.14
• React 官方：React v15.5
• Meta Engineering：React Native: Bringing modern web techniques to mobile
• React Native 官方：React Native for Android
• React 官方：Create Apps with No Configuration
• React 官方：Sunsetting Create React App
• Apache Software Foundation：Third Party License Policy
• Matt Mullenweg：On React and WordPress
• Meta Engineering：Relicensing React, Jest, Flow, and Immutable.js
• React 官方：React v16.0
• React 官方：Mixins Considered Harmful
• React 官方：Introducing the React RFC Process
• React 官方：React v16.8: The One With Hooks
• React 官方：Preparing for the Future with React Prereleases
• React 官方：React v17.0
• React 官方：Introducing Zero-Bundle-Size React Server Components
• React 官方：React v18.0
• React 18 Working Group：Streaming HTML and Selective Hydration
• React 官方：React v19
• React 官方：React 19.2
• React 官方：React Compiler v1.0
• React 官方：Critical Security Vulnerability in React Server Components
• React 官方：Denial of Service and Source Code Exposure in React Server Components
• React 官方：The React Foundation

七种方块走出莫斯科

1989 年 2 月，亨克·罗杰斯飞到莫斯科，穿过一座他并不熟悉的城市，去找一家他此前几乎没打过交道的苏联国营机构。

他要买的不是石油，不是军工技术，也不是一台藏在地下室里的超级计算机。他要谈的是一款只有七种积木、画面简陋得像办公室程序员午休作品的电子游戏。

更要命的是，他没有预约。

罗杰斯后来回忆，自己在拉斯维加斯消费电子展上见过《俄罗斯方块》，随后通过自己的 Bullet-Proof Software 在日本做了电脑和 Famicom 版本。他这趟来莫斯科，最想拿到的是掌机权，因为任天堂正在准备一台叫 Game Boy 的新机器。可等他走进负责苏联软件对外贸易的 ELORG，谈判人员发现，这位潜在买家已经把 Famicom 卡带做了出来，却拿不出相应的苏联授权。

这就有点像你拿着装修好的房子去见房东，然后才发现自己签的可能只是车库租约。

罗杰斯不是当时唯一往莫斯科赶的人。英国商人罗伯特·斯坦早几年就在东欧发现了这款游戏，认定自己握有把它带到西方的经纪和电脑发行权；媒体大亨罗伯特·麦克斯韦旗下的 Mirrorsoft 也认为，自己从斯坦那里拿到的权利足以继续向街机与家用机市场延伸。美国的 Spectrum HoloByte、Atari Games 旗下的 Tengen、任天堂、罗杰斯的公司，全都已经在生产、营销或筹备不同版本。

一张旧合同，四种新机器

每个人手里都有一份合同。

每个人都能讲出一条听起来像那么回事的授权链。

可纸上的 computer 到底是什么？带键盘的个人电脑当然算。投币街机算不算？插在电视上的家用游戏机算不算？即将上市、能装进外套口袋的掌机又算不算？在个人电脑、街机、主机和掌机刚刚分化成四门生意的年代，一个旧词忽然要承担四个市场的价值，麻烦就从这里炸开了。

BBC 后来用一部纪录片重构这场争夺时，把斯坦、罗杰斯、麦克斯韦阵营和 ELORG 的谈判者全拉回镜头前。各方对见面次序、承诺内容和谁更守信用的回忆并不完全一致。这很正常。参与者都知道后来谁赢了，也都知道自己的名声和利益系在这段历史上。每句对话已难以核实，荒诞局面却很清楚：几条相互冲突的合同链，都声称拥有同一款游戏的不同平台权利。

屏幕里的玩家正忙着消除横线，屏幕外的公司却在不断制造新的横线。

说白了，《俄罗斯方块》有两套规则。第一套只有几分钟就能学会：旋转、移动、落下、消行。第二套写在合同、判决和许可协议里：地区、设备、期限、商标、版权、转授权。第一套让它成为世界上最容易理解的游戏之一，第二套让它拥有游戏史上最难讲清楚的商业故事之一。

这场战争并不是围绕一项复杂技术展开的。恰恰相反，大家争得头破血流，正因为它简单得几乎能钻进任何屏幕。

而它最初诞生时，连像素都不够用。

先别急着下落：七种方块从哪里来

把时间拨回 1984 年的莫斯科。

阿列克谢·帕基特诺夫在苏联科学院多罗德尼岑计算中心工作，研究方向与语音识别和人工智能有关。他喜欢数学拼图，尤其喜欢五格骨牌。所谓五格骨牌，就是用五个等大的正方形边对边拼出不同形状。它并不是苏联人的独门发明，数学家所罗门·戈隆布早在二十世纪中叶就系统研究并推广了 polyomino 这个概念；拼板游戏的历史还要更早。

帕基特诺夫的关键一着，是从既有的静态拼图中看见一种适合电脑的运动，而非重新发明“把小方格拼起来”。

传统五格骨牌摆在桌上，你可以慢慢试，错了拿起来重放。电脑版本如果只是照搬，也不过是把木片换成光标。帕基特诺夫做的关键动作，是让拼块从上方持续落下，把时间压力塞进空间问题。玩家不再拥有无限犹豫的权利。你必须在几秒钟里看清形状、预判空位、旋转并决定落点。

可五格骨牌如果把镜像视为同一种，也有十二种；把镜像分开算，则有十八种单面形状。对当时的机器和玩家来说，它太杂了。

于是他减掉一格。

一格减法，七种性格

五格变四格，形状一下收束为七种基本四格骨牌：长条、正方形、T 形、两种折尺和两种扭曲形。变化仍然足够丰富，识别成本却大幅降低。这个减法看起来小，实际决定了游戏此后四十年的命。

七种形状不会少到让玩家立刻看穿，也不会多到需要查说明书。它们有的平整，有的带缺口；有的适合救急，有的很容易把局面搞坏。长条能一次消掉四行，于是玩家愿意冒险留一条深井等待它；S 和 Z 在场地狭窄时像两位专门来拆台的亲戚；正方形不能旋转出新姿势，老实，却未必总能放进你需要的地方。

每一块都很简单，组合起来却永远有麻烦。

复杂来自局面的数量，不来自规则的数量。棋类用大量规则构造复杂，《俄罗斯方块》用少数规则不断生成新局面。上一块落错的位置不会立刻宣判失败，它只是给未来增加一点债。债越滚越高，屏幕越挤，玩家越想靠下一根长条翻盘。

名字也来自一次拼接。Tetris 官方的说法是希腊语中表示“四”的 tetra 加上帕基特诺夫喜爱的运动 tennis；早期 PC 移植者瓦季姆·格拉西莫夫回忆的前半段更接近 tetromino。两个版本并不冲突到需要法庭裁决，它们都说明了一件事：这款游戏从一开始就把“四格骨牌”和网球塞进同一个词里。

有意思的是，网球是有对手、有边界、有胜负终点的运动；《俄罗斯方块》的核心模式却没有终点。只要不堆到顶，你就继续。它不是让你完成一座建筑，而是让你无限期管理一场灾难。

听起来已经很像成年人的生活了。

规则看起来只有几步，却会无休止地循环：

• 读取下一块的形状，判断它会带来什么空间问题；
• 在下落压力中移动、旋转并决定落点；
• 完成横线后消除，让上方结构整体下移；
• 承担没有立刻消失的孔洞、凸起与高度债务；
• 在触顶以前重复以上动作，没有预设终点。

没有彩色积木，只有一对对方括号

帕基特诺夫最初使用的是 Elektronika 60。它属于苏联制造的 PDP-11 系计算机兼容机，没有后来个人电脑那种便利的位图图形环境。今天回看早期界面，令人惊讶的是，如此古老的字符画面已经把玩法说得足够清楚。

方块由成对的方括号表示。

不是发光的蓝色 I 块，不是黄色 O 块，也没有紫色 T 块。就是 []。一对括号算一个小格，几对括号组成一个形状，在字符终端上向下移动。场地像一只竖直的玻璃杯，底部堆着同样由字符组成的残块。

硬件限制在这里没有伤害设计，反而替设计做了一次残酷筛选。没有精美画面可遮掩时，规则必须自己站住。没有角色、对白和过场动画，玩家面对的只有形状、空隙和越来越快的节奏。

帕基特诺夫后来解释，消行机制最初是个工程解决方案。方块不断落下，场地很快就会填满；填满一行后让它消失，既腾出继续玩的空间，也给玩家一个清晰奖励。一个为延长程序运行而设计的动作，顺手创造了电子游戏史上最舒服的反馈之一：杂乱突然变整齐，压力瞬间下降，错误仿佛被擦掉。

可别小看这一下。

很多游戏的奖励来自增加：多一件武器、多一级经验、多一块领土。《俄罗斯方块》的奖励来自做减法。你辛苦操作，不是为了把屏幕塞满，而是为了让已经堆起来的东西消失。它给人的满足感，和清空邮箱、整理桌面、删掉待办事项有某种可疑的亲缘关系。

官方品牌今天把原型诞生放在 1984 年，并把 6 月 6 日作为周年纪念日。《时代》在 2014 年 6 月 6 日刊出三十周年采访，也强化了这个日期。但现有公开材料并没有一枚原始程序时间戳，可以证明“1984 年 6 月 6 日某时某分正式完成”。1985 年又反复出现在早期 PC 版本、采访导语和后来的版权标识中。

所以更稳妥的说法是：1984 年，Elektronika 60 原型成形；1985 年前后，IBM PC 移植、功能扩展和传播让它从一台机器上的实验变成了可复制的软件。游戏的诞生是一段过程，不是一场有主持人剪彩的发布会。

诞生日期的模糊值得在意：流行文化偏爱一个整齐的生日，也偏爱一个孤独天才，真实历史却没那么配合。

谁创造了《俄罗斯方块》？片尾字幕不止一个名字

核心玩法、名称和 Elektronika 60 原型属于帕基特诺夫，这一点没有太大争议。今天的官方版权说明也把游戏设计归于他。

但如果把早期历史拍成电影，只让帕基特诺夫一个人坐在电脑前，写完程序后按下发送键，游戏立刻传遍世界，那就把一支小型协作队伍剪没了。

格拉西莫夫当时还是十六岁的学生。按他留下的早期开发回忆，德米特里·帕夫洛夫斯基把他带入计算中心的游戏开发小组；帕基特诺夫做出 Elektronika 60 原型后，由他把游戏移植到 IBM PC，并继续和帕基特诺夫加入彩色、计分和其他功能。他们还尝试过双人版本，让方块从上下两端进入，两个玩家争夺同一片空间。

这类回忆需要谨慎使用。格拉西莫夫与后来以帕基特诺夫为中心的公司叙事存在利益和署名分歧，他提到的一些文件自己也没有留存。1989 年的美国版权登记只列帕基特诺夫为作者，ELORG 为权利申请人，作品说明写着“原始版本 3.12”。但版权登记目录记录的是申请人当时怎样申报，并不替历史学家逐行鉴定谁写了哪部分代码。

最合理的写法不是把帕基特诺夫从故事中心赶走，也不是突然宣布“三人已被法律认定为共同作者”。应当把两件事同时说清楚：帕基特诺夫提出并实现了决定性的原型；把它搬到 IBM PC、改善显示、测试功能和促进传播，也有格拉西莫夫与帕夫洛夫斯基等人的参与。

早期软件移植不像今天点一下“导出其他平台”。机器架构、显示能力和开发工具都不同，一段在字符终端上成立的程序，到了 IBM PC 上要重新处理输入、图形、颜色和速度。玩法看上去没变，背后已经换过一轮骨架。

这恰好预演了《俄罗斯方块》此后的生存方式。

四十年里，它一次次从旧硬件搬到新硬件。每次搬家，开发者都要回答同样的问题：什么能改，什么不能改？屏幕可以从单色变彩色，控制器可以从键盘变十字键，再变触摸屏；背景音乐可以换，特效可以加，网络对战可以塞进来。但如果旋转、落下、堆叠和消行的节奏被破坏，玩家会立刻说一句：“这不像俄罗斯方块。”

1980 年代中期，那条看不见的边界还没人写成品牌规范。开发小组是在实践里一点点摸它。

办公室里最早的病毒，不需要联网

IBM PC 版本让《俄罗斯方块》变得更容易复制。朋友给朋友，同事给同事，软盘从莫斯科流向苏联其他城市，又进入布达佩斯等东欧技术机构。

没有应用商店，没有发行日倒计时，没有媒体评分汇总，也没有“本周下载量突破百万”的庆功稿。它靠一种更原始的渠道传播：有人玩上了，觉得太好玩，于是把副本交给另一个人。

代码总是跑得比合同快。

这句话后来几乎概括了整场版权战争。软件已经穿过单位和国境，权利人是谁、能不能收费、谁可以对外签约，却没有同步得到答案。对开发者来说，复制给同事可能只是分享；对西方商人来说，这是一件已经证明需求、却还没有被正规定价的商品。

1994 年，《连线》记者杰弗里·戈德史密斯写了一篇非常私人、甚至有点失控的文章。他回忆自己在东京借住朋友家，本来只住一周，结果被 Game Boy 上的《俄罗斯方块》拖了两个月；晚上闭眼仍看见几何形状下落，出门时会忍不住把汽车、树和路人想象成可以拼合的块。他把这种现象称作 “Tetris effect”。

文章里还有一个更早的莫斯科故事。帕基特诺夫的朋友、心理学家弗拉基米尔·波希尔科回忆，自己把游戏带到莫斯科医学研究机构后，实验室里所有人都停下工作开始玩。他只好从每台电脑上删掉它。大家终于恢复上班，直到一个新版本又传了进来。

这段轶事来自当事人多年后的回忆，不能当作精确的考勤记录。但它解释了为什么一个没有市场预算的程序能一路传到西方：每个接触它的人，都可能主动成为下一个分发节点。

《俄罗斯方块》的传播还占了一个规则优势。文字冒险离开母语就需要翻译，角色扮演游戏需要理解故事，体育游戏要先认识项目。方块不说话。一个人在莫斯科、布达佩斯、伦敦、东京或纽约，看几十秒就明白要做什么。

没有语言门槛，也几乎没有文化门槛。

这种全球化是玩法结构自己带来的，并非哪家公司的营销策略。发行商后来给它穿上苏联外套，任天堂后来把它塞进日本掌机，移动公司后来把它装进手机，这些都很重要。但在所有商业包装之前，七种形状已经完成了最困难的一步：让陌生人无需解释就愿意接手。

冷战最软的一次“入侵”

英国商人罗伯特·斯坦在匈牙利接触到《俄罗斯方块》时，看到的不只是一个游戏。他经营的 Andromeda Software 专门从东欧寻找软件，再向西方市场撮合。语言无关、机器要求不高、试玩几分钟就上瘾的《俄罗斯方块》，简直像为这门生意准备的标准答案。

问题是，斯坦的商业动作走在正式合同前面。

在与苏联方面把书面授权彻底落定之前，他已经把游戏交给英国的 Mirrorsoft 和美国的 Spectrum HoloByte。两家公司随后为欧洲和北美市场准备发行。等 ELORG 进入交易链时，西方已经出现包装、广告、平台移植和下游许可，利益不再是一张白纸。

当出生地被做成卖点

Mirrorsoft 与 Spectrum HoloByte 做了一个极其成功的包装决定：把“来自苏联”变成产品的主角。

原型里没有红场，没有克里姆林宫，没有宇航员，也没有一段命令玩家保卫社会主义的剧情。它就是几何形状。但西方盒装软件的封面加入俄文字母、红色建筑、政治符号和浓厚的铁幕想象，Spectrum HoloByte 甚至把它称为 “The Soviet Mind Game”。

方块本身没有故事，发行商就把出生地变成故事。

1988 年 1 月，路透社一篇报道经《洛杉矶时报》刊出，标题大意是“苏联人用新的电脑拼图玩起资本主义游戏”。报道说，这款游戏计划在九种电脑系统上发行，售价大约十四至三十五美元，苏联方面会从版税中获得收益。几年前，它还是研究机构里免费复制的程序；现在，它被当作苏联软件出口的罕见样本，摆进西方商店。

冷战营销在这里出现了一次奇怪反转。发行商卖的是“苏联神秘感”，消费者买回家的却是一套完全不需要意识形态的规则。玩家可能被红场封面吸引，让他们留下的仍是那根迟迟不来的长条。

从商业角度看，这套包装无可挑剔。它给抽象玩法补上了辨识度，让媒体有标题可写，让货架上的纸盒一眼就与别的益智游戏区分。

从历史角度看，它也制造了一个长久误会：很多后来被视为《俄罗斯方块》传统的视觉和音乐元素，其实都不是原型自带。俄罗斯建筑、民歌《货郎》、彩色方块、宇航员动画，是不同发行商和平台逐步加上去的文化层。游戏像一块磁铁，把每个时代对“俄罗斯”的想象吸到自己身上。

这也是它第一次证明：核心规则越抽象，外层包装越容易更换。

硬件公司、发行商和品牌管理者后来反复利用这个特点。可在 1988 年，文化适配还排不上优先级，各方都急着继续转卖手里的权利。

卖着卖着，一张纸就卖成了好几张。

一款游戏，四种权利：合同迷宫是怎样长出来的

早期授权链如果画成一条直线，会非常好懂：

苏联开发者做出游戏，ELORG 代表苏联方面处理对外交易，斯坦的 Andromeda 做西方经纪，Mirrorsoft 负责欧洲，Spectrum HoloByte 负责北美。

可真实商业不会在这条线处停下。

电脑游戏能赚钱，街机公司想做投币版；家用主机市场增长，发行商又想做卡带；日本市场有自己的渠道，罗杰斯的 Bullet-Proof Software 也加入。每一家下游公司都要为移植、制造和营销投入资金，于是每一家都希望手里的合同解释得尽可能宽。

如果“computer game”是能在计算设备上运行的游戏，那么街机难道没有计算机？家用机难道没有处理器？Famicom 的名字甚至就带着 “Family Computer”。站在下游公司立场，这种解释并非毫无逻辑。

可站在 ELORG 立场，个人电脑、街机、家用机和掌机明明是四个可以分别出售的市场。为什么要让一份早期电脑合同，以一个含混词汇的价格，把未来最值钱的主机和掌机权一起打包？

合同里必须被分别定价的，至少包括：

• 个人电脑权：面向带键盘的家用或办公计算机；
• 街机权：面向投币设备与街机厅渠道；
• 家用机权：面向连接电视的主机和卡带；
• 掌机权：面向 Game Boy 这类随身设备；
• 地区与转授权：决定谁能在哪个市场继续卖给下游。

双方都不是在做语文考试。

他们是在给同一个词估价。

每转授一层，合同就离原始权利远一点；每冒出一种硬件，旧合同的含混就贵一点。斯坦认为自己已经拿到足以支持下游交易的权利，Mirrorsoft 与 Spectrum HoloByte 也据此继续行动；ELORG 后来重新检查文件时，却不接受“电脑”自动覆盖所有电子游戏平台。

这不是单纯的某个商人粗心，也不是一句“苏联人不懂市场”能解释。技术分类变化得太快，合同语言却天然回头看。签约者只能描述当时已经存在、已经有商业价值的设备；几年后冒出的新形态，会逼所有人重谈旧词。

今天再看，这个问题一点也没过时。买断一款电脑软件的发行权，是否包含云游戏？获得“移动设备”权利，是否包含智能眼镜？视频授权是否包含短视频切片、直播回放和生成式内容训练？技术每换一个盒子，合同就要重新回答“这还是原来的东西吗”。

《俄罗斯方块》的特殊之处，在于它太容易换盒子。规则不依赖复杂画面，也不依赖某种输入设备。它可以住进 PC、街机、主机和掌机，于是每个盒子的主人都想说：它本来就属于我。

<picture> <source media="(max-width: 640px)" srcset="/images/tetris-history/rights-maze-mobile.svg"> <img src="/images/tetris-history/rights-maze.svg" alt="俄罗斯方块从苏联实验室、早期西方发行链到 1989 年掌机与家用机授权的关系示意"> </picture>

这场战争的核心，从来不是谁最爱玩《俄罗斯方块》。

争的是谁握有装进盒子的权利。

莫斯科牌局：罗杰斯把一盒 Famicom 卡带摆上桌

罗杰斯进入 ELORG 时，谈判并没有因为他远道而来就自动顺利。

按他多年后的说法，他原本通过西方链条取得日本地区的相关权利，并已经发行 PC 与 Famicom 版本。他去莫斯科是为了掌机许可，却在出示产品时让苏联谈判者看到一个更严重的问题：ELORG 认为此前给斯坦的正式权利主要是个人电脑，Famicom 家用机版从哪里来的授权？

一盒卡带，把合同漏洞变成了实物证据。

对罗杰斯来说，这很危险。他可能被视为未经许可发行。对 ELORG 来说，这又是机会。既然早期合同没有清楚卖掉家用机和掌机，那么这些权利仍可重新定价。罗杰斯并不是凭一句漂亮演讲拿下交易，他也必须解释自己怎样沿着下游链条走到这里，并为新的直接授权付钱。

负责谈判的苏联人员面对的也不是简单选择。他们需要判断几位西方商人谁有能力把游戏实际卖出去，谁的合同主张最站得住，哪些平台已经被卖过，哪些还在手里。斯坦要保住自己的经纪地位，麦克斯韦阵营要保护 Mirrorsoft 及下游投入，罗杰斯要拿掌机权，任天堂则在幕后等待一款足以带动 Game Boy 的全球软件。

这是一盘信息极不对称的棋。

西方公司更懂消费电子渠道，苏联机构掌握原始对外许可；斯坦熟悉早期交易过程，罗杰斯更懂日本游戏市场；麦克斯韦家族拥有政治和媒体影响力，任天堂拥有制造、分销和诉讼能力。没有谁在所有维度都占优。

流行叙事很喜欢把这段写成资本主义商人闯入苏联官僚迷宫，靠真诚和友谊打败大公司。现实没那么整齐。罗杰斯的个人信任确实重要，他与帕基特诺夫后来也成为长期伙伴；但 1989 年的胜负同样来自合同范围、平台分类、付款能力和任天堂的商业资源。

罗杰斯回忆，自己先取得掌机权，再转授任天堂。一个月后，他与任天堂美国的荒川实、霍华德·林肯返回莫斯科，继续谈家用机权。Tetris 官方年表也采用这条叙事。由于关键细节主要来自胜利一方的口述，准确表述应当是“罗杰斯回忆”和“官方年表称”，不能把电影化对话当成会议纪要。

不过最终结果非常清楚：ELORG 把掌机与家用机视为早期电脑许可之外的独立权利，任天堂建立起直接链条。原先沿 Andromeda、Mirrorsoft 和 Atari Games 延伸的家用机主张，与这条新链正面冲突。

莫斯科的牌局还没散，美国法庭已经准备开下一桌。

任天堂对 Tengen：更好玩的版本也会输掉战争

Atari Games 通过 Tengen 品牌制作了 NES 版《俄罗斯方块》。它不是一盒随便糊弄的仿制品。许多玩家后来仍喜欢它的双人模式和玩法安排，甚至认为它比任天堂版更丰富。

可再好的产品也救不了权利断链。

Tengen 主张自己的独家权利经过 ELORG、麦克斯韦旗下公司与 Andromeda 等一系列转让而来；任天堂则主张，自己直接从 ELORG 获得 NES 家用机卡带权。诉讼里最关键的问题不是两款游戏谁得分更高，而是旧链条中的“电脑”授权是否真的覆盖家用游戏机。

禁令解决的是合同，不是游戏好坏

1989 年 6 月 21 日，美国联邦地区法官 Fern Smith 签发初步禁令，禁止 Tengen 继续分销和营销 NES 家用版《俄罗斯方块》，同时驳回 Tengen 要求反过来禁止任天堂的动议。UPI 当天的同期报道说，Tengen 家用版刚上市大约一个月；公开的两页命令当时没有附详细理由，书面理由将后发。

所以这段历史最准确的说法是：Tengen 版在初步禁令阶段被叫停。不是这一天已经走完所有终审程序，也不是当天法官在法槌落下后立刻命令焚毁某个常被转述的精确卡带数量。

电子游戏史很容易被传奇数字污染。一个故事只要多讲几遍，“大量库存被收回”就会变成“几十万盒当场销毁”，再过几年连仓库地址都有人替它补好。可同期材料支持到哪里，就写到哪里。戏剧性已经够强，不需要再加烟火。

这场官司也留下一个冷酷事实：更好玩，不等于更有权卖。

开发团队可以加入双人模式，可以把操作调得更顺，也可以赢得评测者；但如果上游许可没有覆盖目标平台，所有产品投入都建在一块可能被抽走的地基上。创意救不了断裂的授权链。

任天堂的优势也不只是律师更多。它拿到了一条更短、更直接的权利路径，并且把“家用机”和“掌机”当成两个需要明确购买的市场。旧链条层层转授，每一层都要解释上一层到底卖了什么；新链条则尽量回到 ELORG。

技术商业里经常有这种局面。早期进入者开路、教育市场、承担不确定性，后来者等价值被证明，再用资本、渠道和更干净的合同收割决定性位置。听起来不公平，却符合平台战争的规律。

斯坦与 Mirrorsoft 让《俄罗斯方块》进入西方商业市场，这份贡献不会因为他们输掉主机权争夺就消失。Tengen 做出受玩家喜爱的版本，这份产品价值也不会因为禁令而归零。可历史的最终分发入口，属于拿到相应权利并能把它装进最大硬件平台的人。

1989 年，那个人是任天堂。

下一步，它要决定把《俄罗斯方块》放在 Game Boy 的什么位置。

Game Boy：任天堂没有把马力欧塞进盒子

如果你在 1989 年负责 Game Boy 上市，最稳妥的捆绑选择大概是《超级马力欧大陆》。

马力欧已经是明星，有角色、有世界观、有任天堂血统。消费者看到包装就知道这是电子游戏。把新硬件和自家头号人物绑在一起，几乎不需要额外解释。

罗杰斯却推动任天堂换成《俄罗斯方块》。

他在采访里回忆，自己的说法抓住了产品定位的分水岭：马力欧面向既有玩家，《俄罗斯方块》则可能把掌机带给所有人。

“If you want little boys to buy your machine include Mario, but if you want everyone to buy your machine, include Tetris.”

— Henk Rogers，回忆说服任天堂捆绑《俄罗斯方块》；TIME 三十周年访谈

马力欧帮助玩家理解“这台机器能玩任天堂游戏”。《俄罗斯方块》帮助不玩游戏的人理解“这台机器我也会用”。

它不要求玩家记住角色能力，不需要阅读剧情，也不用熟悉游戏手柄上的复杂组合。方向键负责移动和加速下落，按钮负责旋转。你在旁边看一会儿，就知道完整横线会消失。孩子玩完把机器递给父母，父母不必先听十分钟教学。

Game Boy 的硬件限制也几乎伤不到它。屏幕小、颜色少、处理能力有限，对强调角色动画的游戏是妥协，对从字符终端里长出来的《俄罗斯方块》却像回到老家。它不需要艳丽色彩区分敌我，七种形状靠轮廓就能识别；它也不要求持续卷轴和大场景，十格宽的竖直场地正适合掌机屏幕。

两者的产品基因刚好合拍。

任天堂需要一款能证明“便携”价值的游戏，《俄罗斯方块》恰好由短回合、随时重开和高度重复构成。等车时玩一局，课间玩一局，躺在床上再玩一局。每局都从空场开始，不需要读档，不会因为隔了三天忘记任务做到哪里。

连接线对战又给它增加了社交理由。两台机器、两名玩家，消行可以转化成对方场地里的麻烦。原本独自整理秩序的游戏，突然多出一种很直接的攻击方式：我整理得越好，你那边越乱。

1989 年，Game Boy 在美国上市时把《俄罗斯方块》作为随机器提供的核心软件。Tetris 官方历史称，Game Boy 版后来超过三千五百万份。这个数字说的是游戏副本，不是 Game Boy 硬件最终销量。任天堂历史销售资料把 Game Boy 系列硬件累计数列为一亿一千八百六十九万台，两者不能混成“《俄罗斯方块》卖出三千五百万台 Game Boy”。

它当然帮助 Game Boy 打开大众市场，但硬件成功还来自价格、电池续航、任天堂渠道、软件阵容与长期迭代。把一切归功于一盒卡带，和完全忽略这盒卡带一样粗糙。

更值得记住的是捆绑逻辑。任天堂没有只挑一款展示性能的游戏，而是挑了一款扩张人群的游戏。平台上市时，最重要的软件未必是画面最华丽的那一个，而是能让最多陌生人迅速理解硬件用途的那一个。

人们惊叹于《俄罗斯方块》替 Game Boy 卖了多少份，却容易忽略另一件事：Game Boy 也替《俄罗斯方块》定义了此后三十年的公众形象。对数以千万计的玩家来说，那块灰绿色屏幕、十字键和循环响起的音乐，才是他们第一次遇见方块的现场。

一款苏联科学院里的免费程序，成了日本消费电子产品的全球通行证。

冷战还没正式结束，方块已经先把阵营边界消掉了。

一款没有结局的游戏，开始给自己立规矩

《俄罗斯方块》能帮掌机跨越年龄，不只因为规则简单。

简单游戏很多，能让玩家几十年后仍然反复重开的不多。

1994 年那篇创造“Tetris effect”说法的《连线》文章，除了描写记者闭眼看见方块，还采访了帕基特诺夫、波希尔科和加州大学欧文分校研究者理查德·海尔。波希尔科把吸引力拆成几个机制：玩家不断获得快速的视觉判断反馈；场上始终存在尚未完成的缺口；操作练习一段时间后会自动化，手开始先于语言行动。

这三个机制叠在一起，几乎就是一台再来一局机器。

每次落块都给一个小判断：这里行不行？落下后答案立即出现。放对了，边缘贴合；放错了，洞留在那里提醒你。玩家不必等十分钟才知道策略有没有效果，几秒钟就得到一次反馈。

可这个反馈很少结束任务。消掉一行，旁边可能还有缺口；刚把场面救回来，下一块已经出现。人脑对未完成动作格外敏感，《俄罗斯方块》则保证你永远有一件没做完的事。就算场地暂时清空，顶部仍会继续掉东西。

失败为什么总像是自己的错

它还设计了一种非常狡猾的失败。

绝大多数失败不是突然降临。你会看见自己一点点失去空间：先是底部留了个洞，后来为了绕开洞又搭出凸起，再后来 S 块没有地方，只能横着盖上去。屏幕越堆越高，你反而越专注，因为局面看起来仍有机会挽救。一根长条、一组连续消行，似乎就能翻盘。

等方块触顶，玩家很少先怪游戏太难，脑中最清楚的往往是：“刚才那块我放错了。”

失败的责任被准确地放回玩家手里。

这让重开显得合理。不是系统骗了你，不是剧情杀，也不是敌人属性突然翻倍。你清楚地记得错误发生在哪一秒，于是相信下一局能做得更好。随机序列又确保下一局不会完全重复，经验有用，却没有一套能照抄到底的答案。

海尔等人在 1992 年发表的研究观察了学习复杂视觉—空间与运动任务后的脑代谢变化。《连线》据此概括：新手练习《俄罗斯方块》时脑能量消耗上升，经过数周训练后，表现明显提高，完成任务所需的代谢活动反而下降。这里不能简化成“玩俄罗斯方块会让人更聪明”，研究谈的是特定任务学习与效率变化，不是给所有智力能力开万能证明。

它至少说明一种玩家熟悉的体验有生理基础：刚开始，你要在脑内念“转一下、向左、快落”；熟练后，手直接做了。注意力从单块操作腾出来，开始观察未来几块、堆叠形状和风险。

规则没变，玩家变了。

《俄罗斯方块》因此有两条难度曲线。一条写在程序里，方块越来越快；另一条长在玩家身上，识别和操作越来越自动。两条曲线互相追赶，直到机器速度或人的失误把比赛结束。

这也是它能成为竞技项目的根。大众玩家想着怎样把方块塞进去，顶尖玩家则在同一套规则下，把视觉识别、计划深度和手部输入推进到极限。

不过在进入竞技场前，《俄罗斯方块》还得完成另一种转变：从人人都能移植的玩法，变成有人统一看管的品牌。

创作者很晚才拿到自己的游戏

《俄罗斯方块》走红时，帕基特诺夫没有同步变成硅谷故事里的亿万富翁。

他在苏联科学院计算中心工作，程序依托单位设备与工作环境完成，对外软件交易又由国家机构掌握。帕基特诺夫在《时代》采访中回忆，自己接受过一项十年安排，由计算中心在全球利用《俄罗斯方块》；格拉西莫夫则把当时情况描述为，计算中心拥有他们制作的成果，ELORG 是能向国外销售软件的国家机构。两种口述的法律措辞不同，但指向同一现实：早期商业许可不由帕基特诺夫个人直接控制。

今天用独立开发者、股权和应用商店分成的框架回看，很容易把故事压缩成一句“国家抢走了发明人的版权”。这句话情绪很足，解释却不够。

当时的苏联没有一套让研究机构程序员以个人创业者身份，把软件卖向全球消费市场的成熟路径。开发设备、劳动关系、单位成果、国家外贸权和国际版权被分在不同制度层。帕基特诺夫当然没有从早期全球销售中得到与西方成功创作者相称的收益，但参与者最初也没有预见这个午休式项目会长成跨国品牌。

制度不是背景板，它直接决定谁能签字、谁能收款、谁能在国外起诉。

帕基特诺夫 1991 年移居美国。1995 年，罗杰斯成立 Blue Planet Software，负责品牌相关业务。1996 年，早期安排到期后，帕基特诺夫与罗杰斯共同建立 The Tetris Company，后续许可开始集中。Tetris 官方年表也把设计规范 Guidelines 的建立放在这一年。

这常被写成一个迟到的圆满结局：创作者终于拿回自己的作品，与当年冒险去莫斯科的商人成为伙伴。

圆满是真的，变化也比“物归原主”复杂。

权利统一以后，《俄罗斯方块》不再只是一个可被各家自由理解的玩法。它逐步形成商标、版权、视觉外观、音乐和许可标准构成的商业体系。今天官网标示的核心知识产权持有人、许可公司和运营主体并不是一个简单法人；2005 年向美国证监会备案的移动授权合同，甚至列出 The Tetris Company、Blue Planet Software、Tetris Holding、Elorg Company 与 Games International 等多个相关权利主体。

个人友谊、公司结构和知识产权不能混成一句“罗杰斯与帕基特诺夫拥有一切”。商业品牌成熟以后，权利通常被放进不同公司，以便持有、许可、运营和交易。

对创作者来说，这是迟来的收益与控制。对游戏来说，这是一次物种变化。

小时候，它靠软盘自由复制长大；成年后，它开始检查每个版本的身份证。

Guideline：把“像俄罗斯方块”写成最低标准

早期版本差别非常大。

方块颜色不统一，旋转中心不统一，场地细节不统一，随机方式、计分、预览数量和操作响应也各有脾气。玩家从一个版本换到另一个版本，面对的不只是画面换皮，有时连肌肉记忆都要重练。

这种混乱在市场开荒期不是坏事。不同公司愿意实验，双人模式、垃圾行、特殊计分和视觉主题都能冒出来。可当品牌要跨越几十种设备长期经营，混乱会变成成本。

玩家买了一个名字，却不能确定拿到什么；开发商每次都要重新争论基础规则；质量差的授权版本也会伤害整个品牌。The Tetris Company 建立 Guideline，实际在回答一个商业问题：怎样让消费者在新平台上仍能一眼认出并立即上手？

官方年表把 Guideline 的创建放在 1996 年。到 2000 年代初《Tetris Worlds》和跨平台、移动许可扩张前后，规范逐渐成为授权协议里可持续更新的最低标准。2005 年提交给美国证监会的移动合同明确把 Tetris Design Guidelines 定义为授权游戏原则上必须遵守、并可能随时更新的设计规范。罗杰斯 2006 年接受采访时也说，Guideline 每年提高，用来统一按键、旋转等体验。

现代玩家熟悉的一组特征，就是在这个标准化过程中逐步固定下来：七种方块使用较稳定的颜色对应；玩家能看到后续方块；可以把当前方块暂存到 Hold 区；Ghost Piece 提示硬降落点；Super Rotation System 规定旋转与“踢墙”逻辑；随机序列减少长时间拿不到某种方块的极端情况。

不能把这些功能全说成 1996 年同一天写进一份永不变化的圣经，公开材料不支持那种精确。Guideline 是一套持续更新的规范，不同机制在不同产品和时期进入最低要求。1996 年是统一工作的起点；到了 2000 年代早期，规范才随着全球许可逐步进入合同和产品。

标准化的收益与代价

标准化带来的好处非常直接。

一个熟悉现代《俄罗斯方块》的玩家，从主机换到手机，再换到网页或另一台主机，不必重新学习方块颜色和基础旋转。开发商可以把精力放在模式、美术、音乐和联网系统，而不是重造底层语言。品牌公司也能把“官方版本”与只借用落块概念的作品区分开。

代价也同样真实。

早期版本那些古怪差异会被磨平，开发者在核心规则上的自由减少。某些老玩家喜欢特定街机或主机版本的旋转手感、计分和随机性，现代 Guideline 版本并不能替代它们。经典 NES 版后来成为独立竞技传统，恰恰因为它保留了与现代规则不同的速度、输入限制和计分结构。

统一并不等于所有人从此只玩一个版本。它更像划出品牌主干，同时让旧分支成为自己的历史生态。

成熟的特许经营不再只讨论设计偏好，它还要降低跨平台迁移成本，控制消费者看到名字时的预期。Guideline 让《俄罗斯方块》从一套广为流传的规则，变成一套可被许可、验收和持续维护的产品语言。

而语言一旦有了官方语法，就会出现另一个问题：别人说得太像，算不算抄？

另一条高速支线：方块刚出生，就已经落地

Guideline 正在把官方版本拉向统一时，日本街机厅里长出了另一条影响深远的分支。

1998 年，ARIKA 推出《Tetris The Grand Master》。名字没有谦虚的意思：游戏要判断玩家有没有资格被称为“大师”，随便消磨几分钟并不能满足它。

普通《俄罗斯方块》常用分数和等级告诉玩家进度，TGM 还建立了一套段位评价。今天任天堂的复刻产品页把它概括为十九个技能等级，系统根据速度、准确性与技术表现为玩家定级。原版主流程推进到 999 级，想拿到最高的 Grand Master 评价，还要满足时间等附加条件。

这样一来，同样一次“没有堆到顶”，意义变了。

在家用版本里，活得久通常已经值得高兴；在 TGM 里，活下来只是交卷，系统还要看你完成得多快、过程是否达到标准。街机厅的投币环境也强化了这种气质：一局表现会留下成绩和时间，旁边的人能立刻看出你处在哪个层级。

20G：方块出生时已经落地

TGM 最出名的考验叫 20G。

这里的 G 不是画面特效，而是方块每帧向下移动的格数。通常版本中，玩家看着方块从顶部逐步下降，在空中完成横移和旋转；达到 20G 时，方块一生成就相当于落到场地表面。你几乎看不到它穿过中间过程。

这听起来应该没法玩。方块都落地了，还怎么挪？

答案藏在锁定延迟里。方块接触堆叠后不会立刻固定，玩家仍有一小段时间让它沿表面移动或旋转。TGM 还允许玩家在新方块出现前预先按住旋转键，让它以需要的朝向进入场地。高手不再追着空中的方块跑，而是提前读预览，决定出生姿态，再利用落地后的短暂窗口把它塞进目标位置。

视觉体验因此变得非常奇怪。普通人看见的是新方块在底部一闪一闪，几乎来不及辨认；高手看见的却是一串可以提前安排的落点。速度没有取消思考，只是把思考挪到了上一块还没结束的时候。

后续 TGM 作品继续扩展段位、速度与考核条件，逐渐形成自己的高手文化。有人追求最高称号，有人追求完成时间，还有人研究在高速下怎样保持场地可操作。这个分支在全球大众销量上没有 Game Boy 版那样的体量，却把“极限俄罗斯方块”推向了不同于 NES 的方向。

NES 高手面对第 29 级，核心问题是横向输入速度能不能追上自然下落；TGM 高手面对 20G，核心问题是能不能接受“方块已在地面”这个前提，利用旋转系统和锁定延迟完成摆放。前者后来催生 hypertapping 与 rolling，后者把预输入、落地移动和高速预判练成一套近似武术的动作。

同一副七种方块，竟然发展出两种极限运动。

这也提醒我们，标准化从来没有把《俄罗斯方块》压成一条单线。官方可以统一最低语言，具体作品仍会选择强调什么：有人强调音乐，有人强调多人攻击，TGM 强调段位和速度，经典 NES 社群则守着 1989 年那套输入限制，硬是从旧漏洞里挖出新世界。

一款长寿游戏的分支并不都靠增加内容。有时候，开发者只是把某个参数推到荒谬的位置，再认真问玩家：“现在呢，你还能不能玩？”

第二场版权战争：玩法不能独占，外观也不是随便抄

2009 年，移动游戏开发商 Xio Interactive 推出了一款叫《Mino》的落块游戏。

它的基本玩法显然来自《俄罗斯方块》。Xio 也没有把自己包装成从未见过前者的天才。争议在于，版权法通常不保护游戏的抽象规则和方法。任何公司都不能只凭版权，永久垄断“方块从上方落下、玩家旋转、填满横线后消除”这套想法。

如果规则不受版权保护，仿制者能走多近？

从玩法思想到具体表达

这道边界题在 2012 年的 Tetris Holding, LLC v. Xio Interactive, Inc. 中得到了一次重要回答。新泽西联邦地区法院区分了抽象玩法与具体表达：垂直落块、旋转、消行得分、堆到顶部失败，属于不能由版权独占的基本思想；但一个作品对场地尺寸、方块外观、预览、幽灵落点、落定后的颜色变化、结束画面等元素进行具体选择和组合，可能构成受保护的表达。

法院并未把判断限于两段源代码是否相同，还要看普通人并排比较两款游戏时，整体外观和体验是否近得需要“眯着眼找差别”。Xio 主张许多相似元素都是玩法所必需，法院却认为，《Mino》在大量并非实现落块规则所唯一必要的细节上都紧贴官方版本。最终，法院在相关版权与商业外观问题上支持 Tetris 一方并发布禁令。

这份判决不是说“十格宽二十格高从此任何人都不能碰”，也不是说做一款四格骨牌游戏就会自动侵权。判决自己强调，孤立使用某一个元素未必足够；问题在于大量具体选择的整体复制。

它给游戏行业留下一条并不十分轻松、但很有现实感的边界：

你可以借鉴一种玩法思想，但得为它做出自己的表达。

《俄罗斯方块》的第一场版权战争争的是谁拿到哪种硬件的许可；第二场战争争的是，核心玩法进入公共创作语汇后，品牌还能保护到什么程度。前一场把“电脑”拆成 PC、街机、主机和掌机，后一场把“游戏”拆成思想、规则、功能、图形表达与商业外观。

看起来都在抠字眼，背后其实是同一个商业命题：怎样把可自由流动的创意，与可以收费、许可和排他的资产分开？

《俄罗斯方块》尤其难，因为它的美学与功能贴得太近。七种四格形状是数学对象，不能因为某家公司用了就从世界上消失；可固定的配色、场地比例、边框、预览布局和一整套视觉组合，又确实会让消费者认出一个品牌。

规则越简单，边界反而越需要精细解释。

这场判决也暴露出 Guideline 的另一面。统一标准不仅服务玩家迁移，也积累了可识别的商业外观。当授权版本长期共享某些视觉与交互选择，品牌就更容易告诉法庭：公众认得的是这组具体组合，不能被概括成抽象的落块规则。

早年的《俄罗斯方块》靠模糊权利野蛮传播，成熟后的《俄罗斯方块》靠精细权利维持边界。

两种阶段没有谁更高尚。它们只是对应了产品生命周期的不同任务：年轻时先让全世界玩到，成熟后再防止名字和外观被无限稀释。

手机战争：最适合竖屏的游戏，也最怕触摸屏

Game Boy 以后，《俄罗斯方块》不再需要证明自己适合便携设备。每出现一块新屏幕，它只需要尽快搬进去。

手机看起来简直是命中注定的下一站。竖屏比例适合高而窄的场地，用户随身携带，等车、排队和通勤都能玩几分钟。游戏本身不依赖高性能，功能机也跑得动。

2001 年已经出现早期移动版。2002 年，罗杰斯成立 Blue Lava Wireless 推动相关业务。2005 年 4 月，JAMDAT 收购 Blue Lava Wireless，并在向美国证监会备案的协议中接手一项全球移动电话独家许可：基础期限十五年，另有三年续期选择；不同地区随原有安排到期逐步生效。EA 后来收购 JAMDAT，从 2006 年起成为移动发行方。

到 2010 年，EA 宣布，自 2005 年以来，多款付费移动版《俄罗斯方块》累计下载超过一亿次。这个数字不是某个 2005 年版本单独卖了一亿份，也不是所有平台总销量，更不是免费下载量。它是多款付费移动产品的累计内部数据，包含后来出现的 iPhone 和 iPod touch 版本。

数字很大，移动体验却一直有一道物理矛盾。

功能机有实体键盘，按键小但能摸到；智能手机屏幕更大、更亮，却拿掉了十字键。玩家的手指会遮挡场地，滑动距离和速度难以完全一致，误触在高速度下尤其致命。开发者不断尝试虚拟按键、点击区域、滑动、轻扫、硬降锁定延迟，玩家则不断争论哪套操作最不像在和玻璃吵架。

《俄罗斯方块》能适配任何屏幕，不等于任何输入都同样适合它。

这也是技术平台的铁律。新设备扩大分发，往往同时拿走旧设备的某项优势。触摸屏让几亿人无需按键就能操作应用，却削弱了高强度游戏需要的触觉反馈。移动版必须在可接近性、广告与付费、单手操作和高水平精度之间重新平衡。

商业模式也变了。盒装软件时代，交易在购买时完成；移动时代有免费下载、广告、内购、订阅和长期运营。游戏规则仍然是消行，产品团队却要回答留存、用户获取成本和平台抽成。屏幕里的长条没有变，屏幕外的合同又换了一套词。

这正是《俄罗斯方块》商业史反复出现的画面。

每个新盒子都声称自己只是下一台电脑。

每个新盒子又会创造一门完全不同的生意。

“俄罗斯方块效应”从一种后遗症，变成了一款游戏

移动时代把《俄罗斯方块》送进更多人的口袋，另一些开发者却在问一个方向完全相反的问题：既然核心规则已经小到不能再小，能不能把玩家感受到的东西做大？

2018 年问世的《Tetris Effect》借用了 1994 年《连线》文章里的那个说法。旧的 “Tetris effect” 指的是玩家离开游戏后仍会看见或想象落块，新的《Tetris Effect》则把这种被形状、节奏和重复动作占据注意力的感觉，直接做成了产品主题。

它没有替换七种方块，也没有把场地扩成开放世界。开发团队把力气放在方块周围：音乐随着操作增加音符，背景与消行一起变化，粒子和环境声跟着节奏回应玩家；戴上虚拟现实头显后，十格宽的场地仍在面前，世界却像从它背后向四周打开。

这条路听着很奢侈。一款在字符终端上已经成立的游戏，为什么需要鲸群、火焰、沙漠、太空和整套视听演出？

因为到了这个阶段，《俄罗斯方块》卖的不再只是规则。规则早已被玩家学会，甚至学得太熟。新版本需要重新制造“第一次看见它”的感觉。

Zone：把时间暂时存起来

《Tetris Effect》的 Zone 机制很能说明这种改法。玩家先通过正常消行积累能量，启动 Zone 后，时间暂时停止，完成的横线不会立刻从场地里消失，而是堆在底部，玩家可以在有限时间里继续叠加。传统模式里，一块四格骨牌最多同时完成四行，Zone 却允许玩家在一次结算里积攒远超四行的成果。

Zone 动了《俄罗斯方块》最基础的时间关系：过去，方块负责制造压力，消行负责释放压力；进入 Zone 后，压力被暂时封存，玩家得到一小段可以主动组织高潮的时间。结束时，多行一起清除，音乐、画面和分数同时爆发。

有些老玩家不喜欢这种包围式演出，他们宁愿只听 NES 手柄的按键声，看一台阴极射线电视上的朴素场地。也有人第一次意识到，《俄罗斯方块》可以不只是一场效率考试，还可以是一段近似音乐游戏的体验。

两边都没错。

抽象规则的好处就在这里。它可以把装饰全部脱掉，成为竞技；也可以把感官层层加上，成为表演。核心玩法足够硬，外层才经得起这么大幅度的改造。

后来扩展出的《Tetris Effect: Connected》又加入跨平台对战与合作。三名玩家甚至可以把各自场地连接起来，共同对付由电脑控制的首领。一个原本只允许玩家独自承担错误的“玻璃杯”，被临时拼成了团队战场。

从 1984 年的 [] 到虚拟现实，屏幕能力的差距大得像两个物种，玩家做的事情却仍然能用同一句话说明：看清下一块，把它放到合适的位置。

这才是《俄罗斯方块》最让同行羡慕的资产。画面升级没有逼它抛弃过去，反而让过去显得更清楚。

九十九块场地同时开战

《Tetris Effect》把单人体验向内挖。2019 年 2 月 13 日上线的《Tetris 99》，则把对战人数向外推到一个近乎胡闹的数字。

九十九名玩家同时开局，只留一个人站到最后。

基本动作没有变化。你还是旋转、移动、消行。区别在于，消掉的横线可以转化成垃圾行，塞进别人的场地。玩家可以手动指定目标，也可以选择攻击正在瞄准自己的人、徽章较多的人或濒临出局的人。击倒对手会积累徽章，提高此后的攻击力。

单人《俄罗斯方块》里，场地升高意味着你之前留下的债正在追上来。《Tetris 99》里，突然涌上来的几排垃圾可能来自屏幕边缘某个你根本看不清名字的人。失败不再全由自己制造，局势也不再只靠自己整理。

这让游戏第一次有了“大逃杀”式的群众场面。

你在主场地里只看见七种熟悉形状，四周却挤着九十八块微缩棋盘。有人开局几秒就触顶，有人安静囤积攻击力，有人因为同时被许多人锁定，反而利用反击规则把垃圾成片送回去。残局人数不断缩小，速度和攻击强度持续上升，原本安静的空间整理变成了一场互相拆家的混战。

任天堂没有按传统盒装游戏的方式单独出售它的在线主体，而是把它作为 Nintendo Switch Online 会员权益。2019 年 4 月，任天堂在财报说明会上说，Switch Online 的付费账户已经超过 980 万，《Tetris 99》则被 280 万个账户玩过。两者都不是软件销量，却说明了一种新角色：1989 年，《俄罗斯方块》被用来让所有人理解 Game Boy；三十年后，它又被用来让 Switch 用户理解在线会员有什么用。

游戏平台换了，捆绑逻辑没有消失。

这一次也能看出 Guideline 的商业价值。如果九十九名玩家还在争论每种颜色代表哪块、旋转到墙边会发生什么，战斗根本组织不起来。统一的方块语言把学习成本压到最低，开发者才有余地在目标选择、垃圾规则、徽章倍率和赛事活动上做文章。

标准化经常被误解成创新的反面。在《俄罗斯方块》身上，两者更像楼层关系：底层规则越稳定，上层模式越敢折腾。品牌公司把旋转、配色和基本操作管得很紧，开发团队便在“玩家为什么继续玩”这件事上寻找区别。

有人为沉浸感继续玩，有人为排名继续玩，有人为了每周主题活动继续玩，还有人只想在九十八个人的围攻下多活十秒。

<picture> <source media="(max-width: 640px)" srcset="/images/tetris-history/evolution-timeline-mobile.svg"> <img src="/images/tetris-history/evolution-timeline.svg" alt="俄罗斯方块从字符终端、授权战争、掌机、品牌标准到现代竞技的演进时间线"> </picture>

可就在官方版本忙着追逐联网、订阅和跨平台时，一群玩家突然掉头，抱起了 1989 年的 NES 卡带。

他们不要 Hold，不要 Ghost Piece，不要七袋随机，也不要触摸控制。

他们要和一台早就被淘汰的机器较劲。

四十年后，旧卡带迎来新一代玩家

2010 年 8 月 8 日，首届 Classic Tetris World Championship 在洛杉矶的一家影院举行。

这场比赛最初与纪录片《Ecstasy of Order: The Tetris Masters》的拍摄连在一起。导演亚当·科尼利厄斯原本关注的是谁能打出 NES 版六位数计分器的上限，也就是 999,999 分。爱好者们很快提出：只拍一个人的纪录不够，得把那些传说中的高手找来，当场比一比。

于是，网上论坛里争论多年的名字坐到了同一排电视前。

比赛用的是北美 NES 版《俄罗斯方块》。没有现代 Guideline 提供的 Hold，没有幽灵落点，也没有温和的随机保护。两名选手各玩各的场地，以得分判断胜负，不向对方发送垃圾行。它看着不像拳击，更像两个人站在并排跑步机上，谁先失足，谁输。

这种赛制把 NES 版的旧脾气全保留下来了。

游戏鼓励一次消掉四行，因为同样清除四行，分开做小消除得到的分数低得多。玩家通常在一侧留出深井，等 I 形长条落下完成 Tetris。问题是，随机序列不会保证它按时出现。长条迟到，堆叠会越长越高；为了活命提前消一两行，又会损失得分效率。高手每放下一块，都在拿生存空间和得分效率互相下注。

到了第 29 级，难度突然跨过一道墙。方块下落速度达到极端水平，传统按住方向键的操作很难把方块送到场地边缘。很长时间里，玩家把这里叫作 “kill screen”，意思不是程序真的立刻崩溃，而是人的手通常到此为止。

首届冠军是乔纳斯·纽鲍尔。

他后来成了这项赛事最稳定的脸。CTWC 官方资料记录，他进入前九届决赛，拿下七次冠军，一度在赛事中打出 37 胜 1 负的成绩。顶尖竞技游戏里，规则更新一次、角色平衡调整一次，王朝都可能结束；乔纳斯统治的却是一盒二十多年前的卡带。

旧游戏没有补丁可研究，选手照样能进步。

他们研究场地平整度，研究什么时候该放弃等长条，研究怎样用旋转减少横向移动，研究一连串不理想方块到来时如何少留一个洞。新知识不在卡带里，它长在录像、论坛和玩家之间。

2011 年的第二届比赛成本高、到场观众少，第三届能不能办下去一度成了问题。2012 年，赛事搬进波特兰复古游戏博览会，才逐渐找到稳定的生存环境。它没有一夜变成奖金惊人的职业联赛，选手也很难靠比赛养活自己。CTWC 的吸引力来自另一种稀缺东西：一群散落各地的人终于确认，原来世界上真有人和自己一样，愿意为十格宽的旧游戏练上几千小时。

YouTube 为旧卡带补上观众席

更重要的分发入口是 YouTube。

直播和录像给一款单人游戏补上了观众席。解说员能同时看到两块场地，告诉观众谁的堆叠更危险、谁还在等长条、双方在进入高速前需要拉开多少分差。普通人第一次发现，自己小时候玩过的游戏里，竟然藏着可以逐帧分析的竞技深度。

《俄罗斯方块》早年靠软盘从办公室传到办公室，CTWC 靠推荐算法从一个屏幕传到另一个屏幕。代码还是那份代码，传播病毒换了宿主。

七冠王输给了一个戴牙套的孩子

2016 年 CTWC 决赛，乔纳斯对阵杰夫·摩尔。解说员每逢杰夫完成四行消除，都会用一句后来被反复剪辑的口号把现场气氛推高。

“Boom! Tetris for Jeff!”

— 2016 年 Classic Tetris World Championship 决赛解说；赛事录像与CTWC 历史页

杰夫最后没有夺冠，比赛录像却在 YouTube 上慢慢涨起播放量。有人剪辑解说员反复喊叫的片段，有人制作恶搞视频，原本用来存档的赛事画面被算法推给一批从没搜索过经典《俄罗斯方块》的年轻人。

十五岁的约瑟夫·萨利就是其中一个。

按《纽约客》对他的采访，他看完推荐视频，又顺着看了乔纳斯、哈里·洪和日本选手 Koryan 的比赛。随后，他买来一台比自己年龄大一倍的 NES 和一盒 1989 年卡带。这个细节很有意思：年轻人进入经典游戏，不再靠父母把旧机器从储藏室翻出来，而是先在新平台看见内容，再花钱追回旧硬件。

一种新输入，结束一个王朝

约瑟夫没有照着冠军的手法慢慢练。他优先学习当时很少见的 hypertapping，也就是“超高速点按”。传统玩家按住方向键，让游戏自动重复横移；他让手臂肌肉产生快速震颤，用拇指一秒敲击十多次，绕开程序自带的等待节奏。

五个月后，他第一次打到 999,999 分。2018 年世界赛前，他又在录像中成为第一个进入 31 级的玩家。

到了比赛现场，这位十六岁新人的目标据说只是通过资格赛。可他一路赢下去，最后坐到乔纳斯旁边。对面是七届冠军，是过去八年几乎等同于项目本身的人；这边是刚练一年、还戴着牙套的高中生。

结果是三比零。

最后一局结束时，约瑟夫先低头，再抬手遮住脸。他想说话，眼泪却先出来了。乔纳斯没有把失利演成王朝末日，他拿起话筒称赞新冠军。观众起立鼓掌，解说员愣了一会儿，才开玩笑说，这大概是大家见过的第一位戴牙套的冠军。

这一场之所以不只是“新人爆冷”，是因为约瑟夫赢球的方法改变了后来者的默认选择。

乔纳斯那一代把按住方向键的 DAS 练到极致，核心是节奏、预充和场地规划。约瑟夫证明，只要身体能制造更快输入，29 级那道墙就没有过去想象得那么硬。此后，越来越多年轻选手直接从 hypertapping 起步。他们不必花十年独自摸索，因为乔纳斯、约瑟夫和其他高手的完整录像、教学与失败样本全在网上。

《纽约客》在 2021 年报道了一个很夸张的对比：从 1990 到 2019 年，统计中共有 87 名玩家完成过 maxout；仅 2020 年，就有 131 人完成。不同纪录组织的认证口径可能变化，但数量级已经足够说明问题。曾经需要传说和模糊照片支撑的成就，变成了新秀的入门礼。

录像把十年摸索压缩成入门课

纪录没有变简单。学习被压缩了。

过去，一个玩家需要自己试出哪些堆叠会在十几块以后出事。现在，他可以在直播群、教学视频和 Discord 里直接问。高手会暂停录像，讨论某个 T 块为什么不该横放，讨论长条干旱时该牺牲多少分数，讨论一个看似平整的表面为什么藏着奇偶问题。

2020 年，疫情把 CTWC 搬到线上。十三岁的迈克尔·阿蒂亚加与十五岁的哥哥安德鲁打进决赛。两个人在同一栋房子里，从相邻房间连入比赛，弟弟最后夺冠。对老一代玩家来说，找到八个同水平对手需要拍一部纪录片；对这一代孩子来说，世界赛可以从卧室开始。

更年轻的玩家已经接管旧卡带。

接下来，连默认的握法也要换。

DAS、点按与滚动：手柄上发生的三次工业革命

想看懂经典《俄罗斯方块》的纪录为什么突然暴涨，得低头看看选手的手。

NES 版的横向移动有一套固定节奏。方向键按下时，方块先移动一格；继续按住，程序会等待十六帧，然后才开始自动移动，之后大约每六帧再走一格。后半段相当于每秒十次左右，这就是 delayed auto-shift，简称 DAS。

DAS 看似只要按住方向键，高手却必须提前“充能”。一块方块还在落时按住方向，保持自动横移状态，下一块生成后便能更快冲向边缘。什么时候按、什么时候松、旋转会不会打断节奏，都会影响下一块能否到位。乔纳斯并没有按得比程序更快，他的优势在于几乎不浪费程序允许的节奏。

低速阶段，这套办法足够。第 29 级却把矛盾暴露出来：方块几乎每帧下降一格，一口气穿过空场只要约三分之一秒。场地稍微堆高，留给横移的时间还会更短。程序在第一次移动后等十六帧，玩家可能已经没地方补救。

hypertapping 的思路很直接：既然按住会触发等待，那就别按住。

玩家连续点击方向键，每次都利用“按下立即移动一格”的规则。索尔·阿克伦德很早就展示过类似能力，日本玩家 Koryan 也长期使用，但它一直是少数人的特殊技巧。约瑟夫把它带进 2018 年决赛并赢下冠军，才让大批后来者把超高速点按当作正统路线。

这动作看着有点像手臂失控。约瑟夫会绷紧肱二头肌，让肌肉震颤带动拇指，据报道能达到每秒约十五次。速度提高的代价是体力、稳定性和手部负担。不是每个人都能把震颤控制成准确输入，连续几十分钟维持更难。

2020 年末，克里斯托弗·“Cheez”·马丁内斯从另一种手柄动作得到启发，逐步发展出 rolling。

滚动手法通常把一根手指轻放在方向键上，另一只手的几根手指依次敲击手柄背面。背面的冲击把手柄向前顶，让方向键快速撞上前方那根固定手指。方向键并非由一根拇指反复按下，而是被夹在两只手的动作之间，像有人在手柄背后敲一串极快的小鼓点。

有人戴一只手套，减少指尖从手柄背面扫过时的摩擦。熟练者能把横向输入推到接近每秒三十次，明显快过 hypertapping，而且更容易长时间维持。CTWC 允许这种方法，因为控制器没有改装，输入仍由玩家双手完成。

第一次看 rolling 录像的人很容易怀疑：这还算正常玩游戏吗？

当然算。游戏从未规定手柄必须怎样握。玩家只是发现，硬件正面有一个按钮，背面也可以成为施力点。

这三种技术对应三种完全不同的人机关系。DAS 玩家理解程序的自动重复，并顺着它安排动作；hypertapper 用肌肉速度绕过重复等待；roller 干脆把控制器本身变成传递振动的工具。卡带没有更新一行代码，人的身体却连续完成三次“输入设备升级”。

竞技边界因此按四步被重新定义：

1. DAS 时代把第 29 级当作几乎不可逾越的软墙；
2. Hypertapping 让高速横移进入世界赛主流；
3. Rolling 把玩家带进一百级以后、程序未测试的区域；
4. 崩溃与 Rebirth 又把竞争从手速推进到代码边界。

技术商业故事里，人们习惯把创新归给新芯片、新软件和新平台。《俄罗斯方块》的这段历史偏偏反过来：机器冻结在 1989 年，创新发生在握机器的人身上。

rolling 普及以后，第 29 级从终点变成了起点。过去的高手要在到达这里前尽量拿分，现代纪录玩家会专门从高速等级练习。2022 年，报道里刚写下的最高等级纪录，常常在文章发布前就被别人刷新。游戏的分数显示、等级颜色和计数逻辑开始进入设计者从没打算让人看到的区域。

场地里的敌人不再只是方块。

还有三十多年前的程序员为了节省内存、限制计数而留下的每一处边界。

冠军把自己的护城河做成了教学视频

经典《俄罗斯方块》的竞技革命，不只是年轻人手快。

它更像一场集体加速实验。一个玩家发明握法，另一个玩家把动作拍清楚，第三个人改进堆叠策略，几十个孩子在放学后同时练习。成功的方法不必等到下一届赛事才被看见，直播当天就能复制。

乔纳斯在这件事上的角色尤其特别。他处在统治地位时，仍不断制作教学内容，讲解堆叠、旋转和比赛判断。商业世界里，冠军通常把诀窍当护城河；他却把护城河拆成台阶，放在后来者面前。

结果并不浪漫化：后来者真的踩着这些台阶把他淘汰了。

约瑟夫因一段推荐视频入坑，迈克尔兄弟又因约瑟夫的夺冠录像加入。rolling 被验证后，更小的玩家迅速采用。知识沿着公开录像向下传，年龄也一届届向下掉。这个项目几乎展示了互联网学习最理想、也最残酷的一面——老师越认真，学生推翻老师越快。

2021 年 1 月，乔纳斯因突发医疗状况去世，年仅三十九岁。此后，CTWC 把冠军奖杯命名为乔纳斯·纽鲍尔奖杯。官方给他的简介没有只写七次冠军，也强调他对社群的影响。

这很合适。

他的最高纪录总会被超过，冠军数量也可能有一天被追平。可一项小众竞赛能不能活下去，靠的不只是纪录有多高，还要看高手愿不愿意让新人靠近。乔纳斯最重要的遗产，恰好是让击败乔纳斯的方法更容易学会。

等 rolling 一代冲进一百多级时，玩家终于碰见一种不能靠手速解决的对手。

最后，程序撑不住了。

Blue Scuti 没有通关，他把游戏打坏了

“kill screen” 这个词在 NES《俄罗斯方块》里长期有两层意思。

旧玩家说的 kill screen 通常是第 29 级。程序还在正常运行，只是速度快到人类几乎无法继续。rolling 攻破这道软墙以后，玩家进入一百多级，才撞上更符合这个词原意的东西：代码错误会让机器冻结、黑屏或重启。

为什么会这样？

技术分析显示，NES 版在消行后计算分数时，会根据当前等级反复执行加法。等级在设计范围内，这段循环来得及完成；等级高得离谱，循环耗时会挤占每一帧的处理时间。不同等级、场上动作和消行数量组合在一起，可能触发程序失控。三十多年后，一段原本只负责计分的朴素代码，竟成了机器能够抵达的终点。

设计者没有偷懒到不可原谅。他们面对的是一台内存和处理能力都极有限的八位主机，而第 29 级已经足以挡住当年的正常玩家。要求 1989 年的程序员认真测试第 157 级，就像要求一栋六层办公楼预先设计直通月球的消防通道。

后来，专门的人工智能程序先进入这些无人区。它不会疲劳，能即时读取场地并稳定执行输入，研究者借此观察等级计数错乱、颜色异常和各种崩溃条件。机器先画出地图，人类随后沿地图往里走。

当机器先于玩家停下

2023 年 12 月 21 日，十三岁的威利斯·吉布森打开直播。他的网名是 Blue Scuti。

他从十一岁开始玩经典《俄罗斯方块》，使用 rolling。那一局持续约四十分钟。方块在高等级下以固定的极限速度下落，颜色却随着程序读入未预期的数据变得古怪，有些组合昏暗得难以辨认。威利斯一边维持高速输入，一边按社群已经分析出的条件安排消行：先进入可能崩溃的等级，再寻找一次能让程序停下的机会。

第 157 级，一次消行发生。

画面突然停住。

威利斯盯着电视，重复确认游戏是不是真的崩了，随后向后一倒，几乎喘不过气。媒体在 2024 年 1 月集中报道这次纪录，把他称作第一个“打败”NES《俄罗斯方块》的人。

这个说法需要引号。

NES A-Type 没有一段预设的通关动画等在 157 级，也没有最终首领。Blue Scuti 没有完成设计者布置的最后一关，他触发的是程序无法继续执行的崩溃。若按传统游戏定义，这更像把跑步机跑到电机烧掉，而不是跑过终点线。

可“打败”也并非全无道理。三十四年来，正常结局都是玩家先失误、方块触顶；这一次，人还在继续，机器先停了。一个十三岁的孩子把失败责任从玩家身上推回卡带：不是我堆死了，是你算不动了。

它和 1989 年的授权战争形成一种奇怪呼应。当年，公司争论 “computer” 这个词能装下多少种硬件；三十四年后，玩家争论 “beat” 这个词能不能装下让程序崩溃。词义之所以突然重要，是因为有人走到了旧规则没有准备好的地方。

Blue Scuti 触发崩溃后，经典《俄罗斯方块》还有没有更远的终点？

有。前提是先把崩溃拿掉。

255 之后是 0：四十周年那年的“重生”

八位系统喜欢 255。

一个无符号字节能表示的最大数就是 255。再加一，不会得到 256，而会绕回 0。NES《俄罗斯方块》的等级变量也存在这道边界。理论上，只要玩家避开或修补高等级崩溃，完成第 255 级后，等级计数就会重新显示为 0。

玩家把这件事叫作 Rebirth 式重生。

它比触发一次崩溃漫长得多。Blue Scuti 的目标是抵达某个可触发程序故障的高等级；Rebirth 玩家则要使用防崩溃修改版，穿过那些故障继续前进。高等级里不只有速度。颜色表早已跑出正常范围，有的方块与背景很难区分；等级计算还存在长时间不前进的区段，技术分析显示，某些位置可能要额外清除数百行才能跨过去。

2024 年 10 月 6 日，十六岁的迈克尔·阿蒂亚加开了一场直播。他使用的网名仍是 dogplayingtetris，朋友们叫他 Dog。四年前，他就是在相邻房间里击败哥哥、成为十三岁世界冠军的那个孩子。

这一次没有对手坐在隔壁。对手是一个字节。

比赛持续了 82 分钟。迈克尔用 rolling 维持输入，清完第 255 级后，看见屏幕上的等级回到 0。BBC 的报道记录了他当时的第一反应。

“Am I dreaming, bro?”

— Michael Artiaga，2024 年首次完成 Rebirth 后；BBC News

他把手放到头上，又继续盯着屏幕。方块仍在落。

这里必须说清一个很容易被标题抹掉的事实：迈克尔玩的是防止 155 级以后崩溃的修改版本，不是 Blue Scuti 当时使用的原始崩溃条件版本。Rebirth 证明的是，人类可以在保留核心操作与速度挑战、修掉程序崩溃后，把等级计数推过 255。它没有取消 Blue Scuti 的纪录，两个人完成的是不同任务。

一个让原版停机，另一个让修改版绕回开头。

这两个目标合在一起，NES《俄罗斯方块》的边界才变得清楚。玩家先找到软墙，靠新输入技术越过；再找到程序崩溃，主动触发；最后移除故障，把八位计数器跑完一圈。每一步都建立在上一步公开的录像、代码分析和训练方法之上。

帕基特诺夫在 1984 年考虑的是，怎样让不断落下的方块不要太快塞满场地。他不可能预见四十年后，一群青少年会研究 6502 处理器的计分循环、颜色表和整数溢出，只为了让同一局游戏多活几十分钟。

但这正是好规则的后半生。

开发者写下边界，玩家把边界当作邀请。

没有一家公司能决定下一块

回到 1989 年莫斯科那张拥挤的谈判桌，所有人争的都是“下一块”。

斯坦想把下一种平台纳入旧合同，麦克斯韦阵营想保住已经向下游卖出的权利，罗杰斯想拿到下一台掌机。任天堂想用下一盒卡带打开全球市场，ELORG 则要确认自己还有哪些东西没有卖掉。

他们的判断都很现实。软件一旦可以无限复制，商业就必须在人为划出的边界上收费：按地区，按平台，按期限，按设备类别。没有这些边界，开发、移植、制造和营销很难获得回报；边界画得太宽，又会把尚未出现的市场提前送给某个幸运买家。

《俄罗斯方块》的第一场战争，争的是谁能卖。

Game Boy 之后的战争，争的是谁能把它带进下一块屏幕。功能机、智能手机、虚拟现实和 Switch 都自称新入口，每个入口也都带来新的控制方式和收费方法。适配能力让《俄罗斯方块》长寿，也让每一次平台迁移都附带一轮商业重组。

Guideline 与 Xio 案代表另一种战争：当玩法已经成为公共文化记忆，品牌还能保护什么？答案不能是“所有落块游戏都归我”，也不能是“只要没复制代码，外观随便照搬”。于是律师把一眼就能认出的体验拆成规则、功能、配色、场地、预览和整体表达，逐项讨论哪些属于公共思想，哪些属于具体作品。

到了 CTWC，战争换到人的手上。DAS 玩家把程序的自动移动练到极致，hypertapper 用肌肉震颤突破等待，roller 从手柄背面制造更快输入。没有新主机发布会，没有版本更新说明，旧硬件照样被重新定义。

四条战争线，最后汇到一起

这四条线看起来各走各的，底下其实连着同一组结构。

规则少，传播自然快。权利还没理顺，市场已经出现；等市场大到需要长期经营，品牌方又开始统一体验、保护外观。标准稳定以后，竞技者才有条件把全部精力放到操作和策略上。早年的混乱帮助它扩散，后来的控制维持了辨识度，而旧版本的冻结意外留下了一套可以长期比较的竞技标尺。

没有哪一个人能独占全部功劳。

帕基特诺夫找到了那组最重要的规则，格拉西莫夫等人帮助它进入 PC；斯坦和两家西方发行商把它推向商业市场，ELORG 掌握了苏联对外许可。罗杰斯与任天堂缩短授权链并抓住掌机机会，The Tetris Company 又把分散版本收进品牌体系。此后，开发者继续改模式，玩家继续改握法，直播平台再把老卡带送到一代新观众面前。

同样，也没有哪一方能把后果完全控制住。

苏联机构没有预见一款研究单位里的程序会成为全球消费品牌；西方发行商没有预见 “computer” 会被拆成价值悬殊的四种权利；任天堂程序员没有预见第 29 级以后还有人类活动；品牌规范的制定者大概也没有预见，最火热的竞技分支之一会坚持使用规范建立前的旧版本。

这不是一个“一切早已注定”的故事。它有太多偶然：一张软盘被带去布达佩斯，一名商人没有预约就闯进莫斯科，一个掌机捆绑方案临时换掉马力欧，一段解说过于兴奋的决赛录像被算法推荐给十五岁少年。

可偶然之下确实有一条稳定规律。

最耐用的不是功能，而是核心规则

能够跨越时代的技术产品，未必拥有最复杂的功能。它往往有一个足够清楚、足够坚固的核心，让不同制度、公司、硬件和玩家都能在上面添加自己的东西。每一代人都以为自己在重新发明《俄罗斯方块》，最后又不得不回到旋转、移动、落下和消行。

1984 年的字符终端上，两只方括号拼成一个小格。

1989 年的谈判桌上，一盒 Famicom 卡带证明合同出了问题。

2023 年的阴极射线电视前，一个十三岁孩子看着画面冻结，因为机器终于先于他认输。

2024 年，另一个孩子盯着等级从 255 跳回 0。屏幕没有颁奖动画，没有制作人员名单，也没有告诉他历史已经完成。

顶部只是又出现了一块新的方块。

文字资料来源

• The Tetris Company：About Tetris
• The Tetris Company：The History of Tetris
• The Tetris Company：Corporate Bios
• TIME：Tetris at 30—对帕基特诺夫与罗杰斯的采访
• Game Developer：Alexey Pajitnov—Tetris: Past, Present, Future
• Vadim Gerasimov：Original Tetris—Story and Download
• BBC Four：Tetris—From Russia with Love
• UPI：1989 年 6 月 21 日 Tengen 禁令同期报道
• Nintendo：Game Boy 历史硬件销量
• 美国证券交易委员会：2005 年 Tetris 移动许可协议
• Electronic Arts：移动版累计一亿次付费下载口径
• WIRED：This Is Your Brain on Tetris
• Brain Research：复杂视空与运动任务学习后的脑代谢研究
• Intelligence：学习与局部脑葡萄糖代谢变化研究
• Nintendo：Arcade Archives Tetris The Grand Master 产品说明
• TetrisWiki：Tetris The Grand Master 机制资料
• Tetris Holding v. Xio Interactive，2012 年地区法院判例
• Tetris Effect: Connected 官方介绍
• Nintendo：Tetris 99 产品与玩法说明
• Nintendo：2019 财年说明会材料
• Classic Tetris World Championship：赛事历史
• Classic Tetris World Championship：历届冠军
• WIRED：2010 年首届 Classic Tetris World Championship 预告
• GDC：Building Explosive Esports on 8-bit Nintendo
• The New Yorker：The Revolution in Classic Tetris
• Engadget：How Gen Z Is Pushing NES Tetris to Its Limits
• BBC Future：Blue Scuti 如何抵达 NES Tetris 的崩溃边界
• BBC News：Michael Artiaga 完成首次 Rebirth
• Nintendo Tetris AI：NES 版本机制与高等级崩溃技术分析