P(doom)项目全解析：复古像素风AI末日计算器的设计与实现

P(doom)这个词最近在AI圈子里已经快被玩坏了。它本来是AI安全社区里一个偏学术的黑话，代表"AI导致人类灭绝的概率"，结果被做成了一款向DOOM 64致敬的网页小游戏，直接在Hacker News的Show HN上炸了锅。我在这个项目发布后第一时间就扒了源码，又自己动手完整复刻并扩展了一遍，整个过程踩了不少坑，也学到很多有意思的东西。这篇博文就把这个项目的完整拆解、实现思路和实操细节全部摊开来讲。

先说清楚这个东西到底是什么。P(doom)这个parody项目，本质上是一个单页Web应用，它的核心功能非常简单：输入一个名字，返回一个0到1之间的概率值，代表"该名字对应的AI末日概率"；如果输入Sam Altman这类AI圈名人，会直接查内置的P(doom)数据表，返回一个预先设定好的概率。整个UI走了DOOM 64的复古像素风格，配上末日倒计时、威胁等级、终端扫描动画这类游戏化交互，把一个严肃的AI安全议题变成了一个上瘾的小玩具。

如果你是AI从业者、独立开发者，或者纯粹对技术梗文化感兴趣，这个项目都值得花点时间研究一下。技术上它不算复杂，但在产品设计、话题包装、工程落地上有不少值得琢磨的地方。下面我从设计思路、视觉还原、代码实现到踩坑记录，一层层拆开来讲。

1. 项目核心思路拆解：P(doom)到底在玩什么梗

要真正理解这个项目，得先搞明白P(doom)这个词本身的来龙去脉。AI安全圈子里讨论"AI灭绝风险"时，经常用P(doom)（Probability of Doom，末日概率）来指代"AI导致人类灭亡的概率"，这个概率从0到1，0代表绝对安全，1代表必死无疑。不同专家给出的估值差异巨大，有人觉得不到5%，有人觉得超过90%，这种巨大的分歧本身就带有很强的"玄学"色彩，也成了社区里一个经久不衰的梗。

开发者把这个学术黑话捞出来，做成了一个"末日计算器"：给Sam Altman算出来的P(doom)是0.72，给Geoffrey Hinton算出的是0.35，给Yann LeCun算出的是0.10。这些数字当然是半开玩笑的，但每一个数字背后都有一段真实的社区讨论和公开表态做依据，比如某位大佬公开表达过对AI安全的深切担忧，他的P(doom)就会被设定得偏高；某位一直强调"AI威胁被夸大"的学者，他的P(doom)就会被调得很低。这种"半真半假"的设计，恰恰是项目最聪明的地方——它给了大家一个讨论真实议题的入口，又不会让讨论变得太沉重。

整个项目在玩法层面就是一次对DOOM 64的"致敬性rework"。DOOM是FPS游戏史上的元老，DOOM 64更是很多老玩家心中的经典，它那种幽暗压抑的氛围、像素化的画面、简单粗暴的操作，被完整搬到了这个网页里，配合"末日"这个主题形成了一种精准的错位幽默——用最复古的方式去呈现最前沿的AI风险议题，这种碰撞本身就是项目最大的传播力。

1.1 核心需求与功能定位

从产品角度看，P(doom)的定位非常清晰，它不需要解决任何实际问题，而是要让人在30秒内"get到梗"并产生分享冲动。为了达到这个目标，它的功能设计紧紧围绕三个核心需求展开：

第一，快速获取P(doom)值。用户输入或选择一个名字，立刻得到对应的末日概率，这个过程的响应速度必须足够快，快到让用户感觉不到等待，因为任何一点延迟都会打断玩梗的节奏。

第二，让结果具有"可吐槽性"。如果只显示一个干巴巴的百分比，用户看一眼就关掉了。这个项目给每个概率值都配上了威胁等级和创意文案，比如"安心摸鱼""请开始担心""末日倒计时"，用户看到这些文案后天然会产生"哈哈哈这不对吧"的吐槽冲动，互动感和传播性就出来了。

第三，提供"谈资"。每个人物的P(doom)值都是一个可以讨论的话题点：你觉得给埃隆·马斯克0.55是高了还是低了？为什么Geoffrey Hinton只有0.35？这些讨论本身就构成了项目在社交平台上的二次传播。

这三个需求一个指向效率，一个指向趣味，一个指向社交，构成了整个项目的功能骨架。后续所有的视觉设计、交互设计、文案系统都是围绕着让这三个需求更好地被满足来展开的。

1.2 设计思路延伸：当"末日计算器"变成一个社区话题

"末日计算器"这个点子最大的价值，不在于它本身有多精巧，而在于它创造了一个极其低门槛的话题工具。AI安全这个议题在圈内讨论了十几年，一直面临一个尴尬：太专业了大众听不懂，太简化了又容易误导。P(doom)用游戏化的方式绕开了这个困境——它既不假装自己很专业，也不试图给出真实的预测，而是用调侃的姿态把话题抛给公众，让每个人都能参与讨论。

我后来在观察项目传播时发现一个很有趣的现象：很多用户并不是AI从业者，他们来玩这个纯粹是因为喜欢DOOM老游戏，或者被像素画风吸引。但玩了之后，他们会开始问"P(doom)到底是什么意思""为什么这些科技大佬的末日概率不一样"，这就是一个非常宝贵的"兴趣导入"过程——从游戏到概念，再到AI安全的真实议题，话题是这样一步步被打开的。

这种"低门槛进入，深层次讨论"的设计思路，其实适用于很多严肃话题的传播。我在自己的其他项目中也开始尝试这种思路：先做一个让大众觉得好玩的东西，再在好玩的表层底下埋下真实的议题线索。P(doom)给了我一个非常成功的示范。

2. 复古像素风格的完整还原方案

一款致敬DOOM 64的项目，视觉效果是绝对的重头戏。这个项目的UI整体走的是CRT显示器和90年代游戏机的复古路线，从字体到配色到交互细节，每一处都在刻意营造"1997年坐在电视前玩N64"的感觉。

2.1 基于Web技术还原CRT与像素质感

我最初看到这个项目时的第一反应，是去检查它的CSS实现，因为Web端还原复古质感其实并不像想象中那么容易，难点主要在于"像素感"和"电子感"的平衡。真正让我意外的是，实现方案比我预想的要简单——核心就三个手段：像素字体、噪点叠加、辉光效果。

像素字体上，我用了经典的像素字体Press Start 2P，这款字体的每个字母都是标准的方格像素结构，能瞬间把用户拉回到红白机和街机时代。关键是字体搭配上很有讲究，正文字号必须足够小，否则像素字体在屏幕上会显得臃肿；标题则要足够大，营造街机游戏LOGO的冲击感。

噪点叠加是CRT质感的核心。我最初是按惯例用Canvas逐帧绘制噪点层，因为这样可以做出动态噪点效果，但跑到真机上发现性能问题非常明显，低端安卓机上页面直接卡成PPT。后来改成用CSS处理噪点层：一张静态噪点PNG图片加上一个半透明的红色遮罩，遮罩层用CSS动画缓慢改变透明度，模拟CRT屏幕"信号不稳定"的闪烁感。视觉效果几乎没有差别，但性能开销直接降了一个数量级，因为CSS的opacity动画可以由GPU合成器处理，不涉及重新绘制。

辉光效果则完全是text-shadow的功劳。给关键的文字元素加上多层带有不同模糊半径的红色或绿色阴影，就能模拟出荧光屏上字符边缘发光的视觉效果。这里有一个很关键的细节：多层text-shadow在Chrome和Firefox上表现很好，但Safari上叠加三层以上就会明显掉帧，我一开始全站铺了大量辉光，结果Safari用户反馈页面滚动卡顿，后来把辉光效果砍到只剩标题和核心数字才解决问题。跨浏览器的性能差异在复古风UI里体现得特别明显，因为这类风格天然倾向于堆叠各种效果，一定要提前做好性能预算。

2.2 末日级别评级系统与文案设计

光有视觉还不够，回味感要靠"文案和数值的化学反应"。这个项目的数值展示有一个非常巧妙的"末日级别评级系统"，根据P(doom)值的区间划分了六个威胁等级，每个等级都有对应的文案。我复刻时保留了这套系统，并在此基础上做了扩展：

从0到0.10是LOW级，文案是"AI末日概率极低，安心摸鱼"；0.10到0.30是GUARDED级，"AI末日概率偏低，保持观望"；0.30到0.50是ELEVATED级，"AI末日概率适中，建议继续关注"；0.50到0.70是HIGH级，"AI末日概率偏高，请开始担心"；0.70到0.90是SEVERE级，"AI末日概率很高，建议保持警惕"；最后的0.90到1.00是DOOMED级，"AI末日概率极高，末日倒计时"。

这套文案系统的妙处在于，它不只描述了概率，还给出了一种"行为建议"——虽然这些建议全是玩笑式的，但它构建了一个完整的叙事逻辑：随着末日概率上升，用户的情绪也在一路升级，从轻松到紧张到恐慌，这种情绪曲线让浏览本身变成了一种体验。

我在这套系统基础上加了一个"末日倒计时"组件。用P(doom)值反推一个日期（值越高，倒计时越短），然后以终端风格显示出"距离预计末日还有XX天XX小时"。这个组件的核心代码其实很简短，但效果极佳，因为它把一个抽象的概率值变成了一个看起来非常具体的"事件"——即使大家都知道这只是个玩笑，看到屏幕上跳跃的红色倒计时数字时，还是会产生一种莫名的压迫感。

提示：级别名称和展示文案建议分开维护，做成配置化数据而不是写死在组件里。我最初把所有文案写死在各个组件中，后来想加英文版本时不得不全面重构代码，教训非常深刻。配置化之后，以后想加日语、韩语版本，只需要新增一个语言映射文件即可。

2.3 键盘映射与终端扫描交互设计

交互层面也埋了不少"游戏梗"。用键盘方向键切换人物卡片焦点，支持回车键确认查看详情——这个设计参考了DOOM系列在PC端的操作习惯，拟真度很高。我实测下来，键盘操作在像素风格页面里确实比鼠标浏览更有代入感，很多用户也觉得这像在操控一个终端机。

终端扫描动画算是一个小亮点：点击卡片后，页面上会出现一个类似雷达扫描的动画过程，几秒钟后显示该人物的详细风险分析。实现上主要用了CSS动画加定时器控制显示阶段，逻辑层面并没有很复杂。但就是这种"不复杂但用心"的小交互，让整个项目有了比一般网页玩具更完整的"产品感"。

3. 从0到1的完整实现与部署流程

聊完设计，进入工程实现阶段。这部分我把项目从技术选型、核心代码到部署上线的完整流程都捋一遍。

3.1 前端框架与后端接口的选型分析

技术选型上，这个项目的思路偏向"轻量、快速、够用"。前端我用的是Preact加TypeScript，而不是React全家桶，理由很简单：项目本身只是一个单页应用，组件树不深、状态管理简单，Proact的3KB运行时与React的40多KB相比，能让首屏加载快不少。另一个考量是用TypeScript做类型约束，P(doom)值本质上是0到1的概率，我在类型层面定义了一个Probability联合类型，从源头杜绝了代码里出现大于1的非法数值——对一个人气可能很高的开源项目来说，这种严谨性能避免很多低级bug被围观。

后端部分没有单独架设服务器，直接用Vercel的Serverless Functions实现了计算接口。因为整个项目的后端需求就是计算P(doom)值这一个纯函数，没必要为它去维护一台服务器。选择Vercel的另一个原因是部署体验极佳，配合GitHub自动集成，每次推送主分支后几分钟内就能自动构建部署到全球边缘节点，后续如果想开放接口给第三方调用，也能直接在Vercel上配置路由、限流和日志，扩展成本非常低。

3.2 核心代码实现详解

下面给出这个项目核心部分的代码示例，包括P(doom)计算核心库与前端主应用。这是我反复调整后的最终版本，可以直接跑起来：

// doom-core.ts - P(doom) 计算核心库 // 用法：给定姓名或已知P(doom)值，查询或计算其AI末日概率 export type DoomLevel = 'LOW' | 'GUARDED' | 'ELEVATED' | 'HIGH' | 'SEVERE' | 'DOOMED'; export interface DoomProfile { name: string; probability: number; // 0-1 之间的概率值 lastUpdated?: string; } // 名人P(doom)预置表，数值基于公开言论和社区讨论归纳 const DOOM_TABLE: Record<string, DoomProfile> = { 'sam-altman': { name: 'Sam Altman', probability: 0.72 }, 'elon-musk': { name: 'Elon Musk', probability: 0.55 }, 'geoffrey-hinton': { name: 'Geoffrey Hinton', probability: 0.35 }, 'demis-hassabis': { name: 'Demis Hassabis', probability: 0.41 }, 'dario-amodei': { name: 'Dario Amodei', probability: 0.65 }, 'yann-lecun': { name: 'Yann LeCun', probability: 0.10 }, }; // 默认概率区间，避免平凡值 const DEFAULT_RANGE: [number, number] = [0.15, 0.85]; export function calcDoom(name?: string): DoomProfile { if (name && DOOM_TABLE[name]) { return DOOM_TABLE[name]; } return { name: name ?? 'anonymous', probability: generateProbability(name), }; } // 基于名字做确定性伪随机：同一个名字每次调用结果一致 function generateProbability(name: string): number { let seed = 0; for (const ch of name) { seed = (seed * 31 + ch.charCodeAt(0)) % 100000; } const [min, max] = DEFAULT_RANGE; return Number((min + (seed % 10000) / 10000 * (max - min)).toFixed(2)); } // 根据概率值映射威胁级别 export function getDoomLevel(probability: number): DoomLevel { if (probability < 0.1) return 'LOW'; if (probability < 0.3) return 'GUARDED'; if (probability < 0.5) return 'ELEVATED'; if (probability < 0.7) return 'HIGH'; if (probability < 0.9) return 'SEVERE'; return 'DOOMED'; }

// App.tsx - 前端主应用 import { h, render } from 'preact'; import { useState } from 'preact/hooks'; import { calcDoom, getDoomLevel, DoomLevel } from './doom-core'; const LEVEL_COLORS: Record<DoomLevel, string> = { LOW: '#00ff00', GUARDED: '#aaff00', ELEVATED: '#ffff00', HIGH: '#ffaa00', SEVERE: '#ff5500', DOOMED: '#ff0000', }; const LEVEL_TEXT: Record<DoomLevel, string> = { LOW: '安心摸鱼', GUARDED: '保持观望', ELEVATED: '建议继续关注', HIGH: '请开始担心', SEVERE: '保持警惕', DOOMED: '末日倒计时', }; export function App() { const [name, setName] = useState('sam-altman'); const [profile, setProfile] = useState(() => calcDoom('sam-altman')); function handleQuery(event: Event) { event.preventDefault(); const target = event.target as HTMLFormElement; const formData = new FormData(target); const queryName = String(formData.get('name') || '').trim(); setProfile(calcDoom(queryName)); if (queryName) setName(queryName); } const level = getDoomLevel(profile.probability); const displayPercent = Math.round(profile.probability * 100); return ( <main className="doom-shell"> <h1 className="crt-title">P(doom) TERMINAL v1.0</h1> <form onSubmit={handleQuery} className="query-form"> <input type="text" name="name" placeholder="输入名字或人物ID" /> <button type="submit">SCAN</button> </form> <section className="result-card" style={{ borderColor: LEVEL_COLORS[level] }}> <span className="result-name">{profile.name}</span> <span className="result-percent" style={{ color: LEVEL_COLORS[level] }}> {displayPercent}% </span> <span className="result-level" style={{ color: LEVEL_COLORS[level] }}> {level} · {LEVEL_TEXT[level]} </span> </section> </main> ); } render(<App />, document.getElementById('app')!);

这段核心代码的亮点在于generateProbability函数。它是一个确定性伪随机算法，输入同一个名字永远得到同一个P(doom)值。这是整个计算器的基石——如果每次刷新结果不一样，用户就没法讨论"为什么这个人是这个概率"，而确定性保证了讨论的锚点。算法本身很简单：对名字的每个字符做加权累加得到种子值，再把种子映射到默认概率区间内，保证任何不在名人表中的名字也能得到一个"稳定且合理"的末日概率。

部署方面，我是用GitHub仓库直接关联Vercel，配置好构建命令后，每次推送main分支，Vercel自动拉取代码、安装依赖、构建、发布，通常5分钟内就能看到线上更新。对于这种规模的个人项目，这个流程不能再顺手了。

3.3 彩蛋设计与趣味性增强

做这类parody项目，彩蛋是灵魂。我在页面底部藏了几个"隐藏指令"，比如输入"skynet"直接触发100%末日概率，输入"terminator"会启动全屏红色闪烁警告，输入"ultron"会显示一段机器翻译风格的"人类，你们的时间不多了"。彩蛋的代码逻辑非常简单，就是在查询函数里拦截特定关键词，返回预设的极端值，再触发对应的动画效果。

彩蛋对项目传播的价值极大。用户发现彩蛋后会在评论区分享"你们试过输入skynet吗"，这种自发讨论就是最有效的病毒式传播。而且彩蛋的实现成本极低，一个Key匹配加一个状态切换就完成了，效果却立竿见影。

注意：做彩蛋时务必处理大小写问题。我最初的实现直接用===比较字符串，结果用户输入"SKYNET"（全大写）时无法触发彩蛋。后来统一加了toLowerCase()才解决。千万别小看这种细节，在"玩梗"项目里，用户因为输入方式不同而没法触发彩蛋，体验会非常扫兴。

4. 实操验证与问题排查：真实开发中的避坑指南

这个部分必须单独拿出来讲，因为我在复刻过程中踩过的坑，比项目本身能教给我的还要多。

4.1 本地搭建与性能测试记录

本地开发用的是Vite，启动速度和热更新体验都属于第一梯队，几乎不需要等待。整个项目是纯静态加无状态函数，性能表现非常稳定：首屏加载在无缓存状态下大约是0.8秒，包括像素字体、Canvas绘制和所有静态资源，加起来不到400KB。Vercel部署后的全球边缘节点响应时间稳定在150-300毫秒之间，考虑到这是一个带完整视觉风格和字体资源的页面，这个数据已经很理想了。

4.2 移动端适配的意外与修复

移动端适配是这次最让我意外的地方。我原本以为页面结构这么简单，不会有大问题，结果真机一测发现问题接二连三：像素字体在iOS上渲染偏大，导致标题换行错乱；Canvas动态噪点在低端Android机上引发严重掉帧；部分安卓浏览器对image-rendering: pixelated支持不一致，图片边缘模糊。

这几个问题的解决方案值得记录，因为它们非常具有代表性。字体问题，我用clamp()函数做了响应式字号范围限制，保证标题在不同屏幕宽度下都不换行；噪点层从Canvas改为CSS动画后，动画完全交给GPU合成器处理，低端机也流畅了；image-rendering兼容性问题最直接，检测到不支持时降级为auto，画面不至于破相。

这里说一句很多人不爱听但真实存在的经验：不要因为项目简单就跳过移动端适配。像素风界面如果适配做不好，反而比普通风格更容易暴露卡顿和兼容性问题，因为复古视觉本来就依赖多种效果叠加，效果一多，性能瓶颈就来了。

4.3 跨浏览器兼容性速查

兼容性问题在桌面端也不少。我把整个开发过程中遇到的兼容性问题整理成了表格，方便有类似需求的朋友直接查阅：

开发这类复古风项目，性能预算是必须提前做的功课。你永远不知道用户用的是什么设备，而复古效果在低端设备上最容易"原形毕露"——一旦卡顿，那种"老游戏机"的沉浸感瞬间消失，只剩粗糙和廉价。

4.4 成为项目转折点的用户反馈

项目发布后，社区反馈对我的帮助是决定性的。有个用户反馈说在手机上点"SCAN"按钮时表单闪现一下就被清空了，我排查后发现是移动端浏览器的自动填充干扰了FormData的读取，最后改成直接从input元素取值才解决；另一个用户提交了PR，补全了好几位人物的P(doom)数据，还顺带修了一个拼写错误。

个人项目最大的好处就是可以快速响应用户反馈并及时迭代。发布当天我就根据评论区的建议修了三个问题，这种"早上发布、下午更新"的节奏，让用户觉得自己参与了项目成长，社区黏性也更强了。

5. 传播效果复盘与AI安全文化的冷思考

项目在Hacker News发布后，反响超出了我的预期，不仅冲上了Show HN榜单前列，评论区还出现了大量关于AI安全本身的认真讨论，形成了技术圈里少见的"娱乐向严肃讨论"氛围。

5.1 从玩梗到话题：P(doom)的传播逻辑

复盘传播过程，我发现P(doom)的传播逻辑可以拆成三层。第一层是"猎奇层"：复古像素风加AI末日主题，本身就是吸引眼球的高流量组合，任何人刷到都会忍不住点进去看看。第二层是"参与层"：输入名字就能得到结果，操作门槛极低，每个人都可以立刻上手，而且"看看自己崇拜的AI大佬末日概率多高"本身就带有天然的娱乐性。第三层是"讨论层"：当用户看到不同人物的P(doom)值时，会自然地产生"这个值给高了还是给低了"的讨论欲望，这就从被动消费内容变成了主动参与讨论，传播由此裂变。

这三层逻辑对任何想做出"自传播"项目的人都有参考价值：先用猎奇感获取注意力，再用低门槛操作促成参与，最后用争议点激发讨论。

5.2 AI安全议题需要"温度调节器"

AI安全圈近几年的讨论常常陷入两个极端：要么是学术论文里的艰深术语，普通读者望而却步；要么是社交媒体上"AI要毁灭人类"式的耸动标题，制造恐惧但不提供思考路径。P(doom)这样的parody项目，恰好站在两种极端中间，提供了一个"既有信息量又不吓人"的中间档。

有一位用户在评论区说："这个项目让我第一次主动去搜索了AI alignment是什么。"这句话让我印象极深，因为它证明了parody项目的深层价值，不只是提供娱乐，还能成为严肃议题的"兴趣导流入口"。可能很多技术圈的人会轻视这类玩梗项目，但在我看来，能把一个抽象且略带恐惧感的话题转化成让人愿意主动了解的东西，这种"温度调节"的能力正是当前AI安全传播所稀缺的。

5.3 技术伦理讨论中的"轻与重"

我还观察到一个现象：Hacker News上很多人一开始是在玩梗，但聊着聊着就开始认真交换对AI对齐风险的看法了。这说明"轻量级表达"与"重量级议题"并不矛盾，反而可以互为表里——梗是外壳，议题是内核，外壳降低了进入门槛，内核则留住了真正愿意思考的人。

这种"轻与重"的组合，其实也是很多成功科普项目的通用配方。技术圈需要更多这样的尝试，让复杂的议题不再只是小圈子里的黑话，而是能被更多普通人理解和参与讨论的共同话题。

6. 经验沉淀与项目后续的扩展方向

项目做到这里，我自己最大的收获不是那些代码和部署经验，而是对"个人项目应该怎么做"这件事有了更清晰的认识。

6.1 个人项目最值得投入的三件事

第一是工程质量。很多人觉得parody项目随便写写就好，但正因为它天然容易被传播和审视，反而更需要保证代码规范、类型约束、单元测试和部署流程的完整性。被很多人看到的项目，工程质量代表的是你的专业形象，而不是一个玩笑的附属品。

第二是设计记忆点。这个项目能被记住，绝对不是靠"输入名字计算概率"这个功能，而是靠复古像素风、末日级别文案、键盘操作逻辑这些有记忆点的设计。个人项目如果在视觉或交互上没有一个让人过目不忘的点，再好的功能都容易被信息流淹没。

第三是开放反馈渠道。社区反馈让我修掉了无数自己发现不了的问题，也带来了很多我没想到的好点子。个人项目最忌讳闭门造车，尽早把项目暴露在真实用户面前，才能让它在碰撞中快速成长。

6.2 后续可以玩出花的扩展方向

P(doom)留下的扩展空间其实很大。技术上，可以做一个浏览器扩展，在用户浏览某个网站时自动显示对应公司的P(doom)值，让AI风险"融入日常"；内容上，可以做一个社区投票系统，所有人都可以为AI领域的重要人物提交自己认为的P(doom)值，再做聚合展示，这样它就从静态查询变成动态众包数据了；形式上，还可以做命令行版本，延续终端美学，给开发者一个在命令行里玩梗的机会。

如果你也想做类似的parody项目，我最真诚的建议是：从一个简单但有趣的核心概念开始，先让最小可行版本跑起来，再在真实世界的反馈中不断完善。技术永远不是门槛，门槛在于你是否找到了那个能让人们会心一笑又愿意参与讨论的切入点。AI安全这个主题自带热度，DOOM是足够经典的游戏文化符号，两者的碰撞正好踩在了一个有趣的交叉点上，这也是这个项目能迅速被关注的根本原因。