企业官网建设流程全解析

1. 一场失眠夜里的"像素跳动"：项目的起心动念

18 个月前的一个凌晨两点，我躺在床上刷手机，看到一段 30 秒的游戏视频。画面里一个方块小人，在一块一块的像素平台上起跳、翻越、连跳，节奏干净利落，配上电子音效，莫名有种让人上瘾的韵律感。评论区有人问"这是哪家工作室做的"，作者回复：就我一个人。

我关掉手机，在黑暗里躺了十分钟，然后重新打开电脑。

那一晚我就是睡不着。白天我是写业务代码的后端工程师，用编辑器写了快八年程序，但从来没碰过游戏。那会儿我连"贴图"和"精灵图"的区别都说不利索。可那个叫"像素跳动"的想法像根刺一样扎在心里：我要自己做一个游戏，从零做，一个人做，不组队、不外包、不用现成的大型模板资源。游戏名字我都想好了，就叫"像素跳动"——一个方块，在像素风格的世界里不断跳跃前行。核心玩法极其简单，就是把"跳"这个动作做成有节奏感、有手感、有深度的体验。

为什么非得是像素风格？原因很务实。第一，我一个人，时间有限，像素美术是我能在"艺术表达"和"工程量"之间找到的最好平衡点。一个 16x16 的方块角色，我能自己画；一张 32x32 的瓦片草地，我也能自己磨。换成写实 3D，光建模就够我学一年。第二，像素游戏有一个独特优势：玩家对像素的容忍度极高，画面是风格而不是瑕疵，这给了独立开发者很大的试错空间。第三，平台跳跃（Platformer）这个品类对人力的要求相对集中，核心是"手感"和"关卡"，不需要做庞大复杂的 RPG 系统，特别适合单人完成。

而"一个编辑器"这个说法，在项目里其实有两层意思。第一层，我确实几乎只用一个代码编辑器写了这个项目的全部逻辑代码——没有用那种装了十几个插件的重型 IDE，就是一个轻量的、够快的、能让我专注写代码的编辑器；第二层，到了开发后期，我甚至亲手写了一个关卡编辑器——一个真正属于"像素跳动"这个游戏自己的编辑器。所以标题里的"一个编辑器"，既是起点，也是终点：从一个人的工具，到为一个梦想而造的专门工具。这个游戏真正开始成型，是从我意识到"编辑器才是核心生产力"那一刻起。

这篇分享不是要教你怎么做一款成功的游戏，而是想老老实实记录：一个没有任何游戏开发经验的人，如何只靠一个人的时间、一个顺手的编辑器、一个不切实际的梦，把一个方块从"能跳起来"打磨到"跳得舒服"，最后 18 个月做完了整个项目。如果你也想一个人做点什么，希望我的弯路和笨办法能给你一点参考。

2. 工具链极简主义：我最终依赖的五个编辑器

先说结论：我最终用的工具加在一起不超过五个，每一个都是"非它不可"才换上去的。很多个人项目死在开始不是因为没有好工具，恰恰是因为工具太多、太重、太完美——搭建工作流本身变成了逃避做正事的借口。我给自己定了一个原则：每个环节只保留一个主力工具，其他的一律砍掉。

2.1 主编辑器选型争论：Vim 还是 VS Code，我最终的取舍

开发前有个朋友强烈建议我用 Vim，理由是"效率高、省内存、程序员图腾"。我试了一周，结果大部分时间都花在背命令和配置文件上了。我的判断是：Vim 适合把编辑本身当手艺的人，而我要的是把脑子里的游戏逻辑快速落到代码里，对编辑器越无感越好。所以最终选了 VS Code。

更关键的是，我给它配置了一组自己真正用得上的快捷键和扩展，而不是和网上教程一模一样。比如我把"保存并运行游戏"绑定到 F5，把"重新加载当前关卡"绑定到 F6。开发中我的流程始终是：改代码 → F5 跑起来 → 测试 → 改代码。一个编辑器，一个按键闭环，不折腾。

很多人分不清"编辑器"和"编译器"的区别，我在这个项目里也被问过不少次。简单说，编辑器是写字的地方，编译器是把你写的字翻译成机器能听懂的命令的工具。在 LÖVE 这个框架里，Lua 代码甚至不需要显式编译——它是解释执行的，你保存完代码，重新运行游戏就看到变化。这意味着我可以把编辑器、运行调试、预览都控制在极短反馈环内，这对一个人做游戏来说太重要了。

2.2 自研关卡编辑器的诱因：引擎内置编辑器不够用的地方

"像素跳动"开发到第 6 个月，我开始犯愁了。游戏不是只有一块空地乱跳，我需要设计很多平台、陷阱、移动地板、重力反转区、可碎砖块……如果所有关卡都靠手写坐标数组来拼，几百个物体的位置、大小、属性堆在代码里，根本没法维护。我试过 Tiled，一个很流行的 2D 地图编辑器，用它编辑地图图层完全是够的。但我的游戏有一个特殊需求——每一个平台都可以挂一个自定义行为脚本，比如"站在上面会下坠""踩到后 3 秒碎裂""双向平台只允许从上方穿越"。

Tiled 能放自定义属性，但属性一多，每次写属性名都像是在做表格数据录入，眼睛都要花掉。更重要的是，我的场景运行在 LÖVE 里，最自然的关卡表现方式是一张 Lua 表结构，而不是 Tiled 导出的 JSON。JSON 和 Lua 表来回转换多了，我总觉得有一层隔阂。

于是我决定自己做关卡编辑器。当时身边有人劝我——"你游戏都没做完，还要费劲做编辑器？" 我心里也嘀咕过，但最后还是干了。这个编辑器只有两个核心窗口：左边一个可以拖拽、缩放、对齐像素网格的 2D 视图，右边一个属性面板，选中哪个物体就显示哪个物体的参数。一切操作最终保存为一个.level文件，其实就是一个封装好的 Lua 表文本。

做这个编辑器花了我大概一个半月的时间，但后面九个月的关卡设计效率至少翻了三倍。对于一个强空间感的游戏，可视化编辑带来的不仅是效率提升，更是设计思维的整体升级。你能肉眼看到一块平台是不是跳得过去，距离是不是符合手感，而不需要凭空在脑中做 3D 模拟。

2.3 像素素材管线：从 Aseprite 到脚本批处理

像素美术部分，我从头到尾只用 Aseprite。它的图层帧动画功能非常直观，还能直接导出精灵表（Sprite Sheet），省掉了我手动切图的痛苦。做到第 8 个月，我给角色画了大概 40 帧的动画：待机、跑动、跳起、下落、冲刺、受伤、死亡、重生、二段跳特效……这些帧拼在一张精灵表里，由代码里的动画状态机来切换。

素材多了以后，一个麻烦出现了：每次角色调整尺寸，我都得手动重新切图、更新坐标数组。后来我写了一个 Python 脚本，读取 Aseprite 导出的 JSON 数据，自动生成 Lua 的动画定义表，直接放进项目里。虽然这只是一个小脚本，但它教会我一个道理：编辑器不只是代码编辑器，所有能自动化生成内容的工作都值得花时间搭一条管线。这条管线让我后来做不同风格的 BOSS 动画时，省下了大量体力劳动。

3. 十八个月拆成四个阶段：每个阶段只做一件事

"18 个月"听起来很长，但拉出来看，真正能用的整块时间并没有想象中多。我是晚上下班后开发，偶尔周末整天投入，平均下来每周大约 15 到 20 个小时。如果换算成全职工作，这 18 个月大概只相当于四到五个月的工时。正因为时间稀缺，我更不敢乱来，每个阶段只给自己定一个主要目标。

3.1 前三个月：用周末搭建可玩原型

第 1 个月，我干了件很多人觉得"浪费时间"的事：没有先去学什么大型引擎、没去看游戏开发入门课，而是直接拿 LÖVE 写了一个 200 行的方块移动脚本。屏幕上出现一个能用方向键移动、空格起跳的白色方块时，那种兴奋感是支撑我后面 17 个月的最大动力。

第 2 个月我在原型里加了重力、加速度和简单碰撞。那会儿经常出现一个 bug：方块掉到平台边缘"卡住"，或者跳到半空被看不见的墙弹回去。我那时还不知道这叫"碰撞体边界"问题，纯粹靠调试日志一点点找原因。第 3 个月结束，我的原型除了一个方块和一堆平台，还有一个很重要的东西——一套可配置的跳跃参数文件。我把重力、初速度、跳跃缓冲这些值都拎出来放在配置里，每调一个数字跑一次游戏看感觉。这个习惯后来帮了大忙。

这个阶段最容易犯的错是：想太多。我刚开始甚至设计了一个背包系统和商人 NPC，后来意识到这和"像素跳动"的核心乐趣毫无关系。砍掉的时候有点心疼，但回头看，原型阶段唯一的 KPI 是"这个跳跃好不好玩"，不是"系统多不多"。如果你也在做 prototype，我建议你写一个极简的"爽点清单"——先搞清楚这个游戏最核心的几个瞬间是什么感觉，然后再往里加东西。

3.2 第 4 到第 9 个月：手感打磨是最磨人的沼泽

做了一个能跳的方块后，我才发现"能跳"和"跳起来舒服"之间的距离大概隔了一个马里奥。

所谓手感，在代码里其实是一堆数字的组合：重力有多大，跳跃初速度有多快，空中能不能转向，掉下平台边缘的瞬间还能不能跳（这个机制业界叫"土狼时间"），按跳跃键的瞬间如果已经在空中能不能缓冲（跳跃缓冲）……这些数字单独拿出来都不难调，难的是它们互相之间有极强的耦合。重力变大了，跳跃高度就变矮；跳跃初速度变大了，滞空时间就变长；缓冲时间开的太长，玩家会觉得按了没反应；太短，按早一点点就跳不出来，判定很"硬"。

我把这些参数做成了一张巨大的测试记录表。拿最核心的三组参数来说：

• 重力加速度：从 800 px/s² 一路加到 2000 px/s²
• 跳跃初速度：从 500 px/s 一路加到 900 px/s
• 跳跃缓冲：从 0 ms 到 200 ms 每次 +20 ms

每调一组，就跑一遍同一个测试关卡，记录"起跳瞬间的反馈感""最高点悬停时间""下落时的节奏"三个主观指标。那段时间我最像的不是程序员，而是一个帮游戏"试味道"的品酒师。我试了 71 组参数组合后，锁定了一组手感最干脆的参数，再用这组参数去调二段跳和冲刺。

为什么要这么较真？因为平台跳跃游戏的乐趣就来自"精确控制"的快感。一个玩家操纵一个小方块，如果每一次起跳、每一次落点都在他的预期之内，他就会觉得自己"变强了"，这就是心流的来源。反过来，如果起跳总是慢半拍，玩家会非常愤怒，而且他说不清为什么，只会觉得"这游戏不舒服"。这半年的手感打磨，让我明白了什么叫"细节即游戏"。

3.3 第 10 到第 15 个月：内容量才是独立游戏的天花板

手感稳住之后，游戏的框架基本定了。但从"手感好"到"值得玩"，中间还隔着一道巨大的坎：内容。

这五个月我在做三件事。第一，关卡设计。我利用自研的关卡编辑器搭建了 3 个主题世界：第一个世界是绿色草地的"起跳平原"，教玩家基础跳跃；第二个世界是阴冷洞穴的"重力迷窟"，引入重力反转和移动平台；第三个世界是霓虹电子城"像素都市"，挑战二段跳连跳和精确落点。每个世界 6 到 8 个常规关卡，加上一个 BOSS 关，总共 20 个关卡。

第二，敌人和机关。我给游戏加了三类基础敌人：巡逻小兵、尖刺球、飞行眼。它们的 AI 都很简单，但每类敌人都能和主角的跳跃能力形成良性互动——你永远可以"跳过去"，而不是被迫攻击。这就是平台跳跃的默契：敌人的作用不是杀死你，而是让你的跳跃更有挑战性。第三，音频和反馈。我找了开源的音效素材库，给跳跃、双段跳、踩敌人、吃金币、死亡、重生都配了不同的音效。配合轻微的屏幕震动和像素粒子特效，这个小方块立刻"活"了。

这个阶段最常见的心理挑战是：你会在某个星期三突然觉得整个游戏是个垃圾。我自己就经历过，某天测试到自己第 10 关时，突然觉得所有关卡都长得差不多，特别想全部推翻重做。后来我学会了一个办法：不当天做决定，先把想法写进"改进清单"，过一周再看哪些意见是真的需要改，哪些只是一时的情绪。事实证明，清单里大约只有三分之一值得动手。

3.4 最后三个月：性能、发布与那一刻的忐忑

第 16 个月开始，游戏内容基本冻结，不再加新玩法了。我的任务变成：让游戏流畅跑起来，并且在三个平台上都能发布。LÖVE 框架本身很轻，但我在粒子特效上过度放飞，导致一个 BOSS 倒地时满屏像素碎片，中端电脑能掉到 30 帧。我用 Profiler 查了热点，把粒子数量上限从 2000 砍到 600，加了对象池复用，瞬间稳定到 60 帧。这个教训很典型：独立游戏最先被砍的通常不是功能，而是粒子特效。

第 17 个月，我搭构建脚本，自动打包 Windows、macOS、Linux 三个平台的版本。中间踩了一个很无语的坑：Windows 下 Lua 读取中文路径的存档文件会乱码，排查了一个通宵才发现是文件编码问题。最后还是老老实实用 UTF-8 无 BOM 格式统一所有文件，并在代码里做了容错。

第 18 个月上旬，我提交了 Steam 的审核申请，上架了 itch.io 的免费试玩版。发布前我在本地反复模拟了十几次"从零开始下载安装并进入游戏"，确认任何一个陌生玩家都能顺滑打开。当你真的按下发布按钮的那一刻，你会发现自己竟然有点不敢看后台数据——那种忐忑，和做游戏时破解难题的快感完全不一样，但同样真实。

4. 像素跳动的核心难关：物理手感与关卡设计的数据化

如果说"一个人 18 个月"是这个项目的外壳，那么真正撑起"像素跳动"的内核，是两件事：物理手感的数据化调优，以及关卡结构的编辑器化设计。这两部分如果只说"慢慢调"或者"凭感觉"，读者很难复现。我尽量把背后的逻辑摊开讲。

4.1 跳跃物理：为什么我试了 71 组重力参数

平台跳跃的物理公式其实特别简单，因为我不做空气阻力、不做斜坡摩擦，纯粹就是：

-- 每帧更新垂直速度 velocityY = velocityY + gravity * dt -- 应用位移 positionY = positionY + velocityY * dt -- 地面判定 if positionY >= groundY then velocityY = 0 isGrounded = true end

一句"gravity"，一个"jumpSpeed"，就是整个跳跃的核心。不同的取值组合会让手感千差万别：

• 重力小 + 初速度大 = 高而绵软，有点像在月球走路
• 重力大 + 初速度小 = 低而脆快，落地非常果断
• 重力大 + 初速度大 = 高耸且节奏快，刺激但有压迫感

我最终锁定的参数是：重力 1500 px/s²，跳跃初速度 620 px/s，二段跳初速度 550 px/s。这组参数下，单跳最高约 128 像素，滞空全程大约 0.83 秒。为什么是 128？因为我的基础平台高度是 64 像素，正好两倍——跳两格高、不太费力，这个比例让玩家视觉上觉得"我能轻松跳过一块砖，但连续跳三块是有难度的"。

至于土狼时间和跳跃缓冲，简单说就是给玩家发福利：

• 土狼时间：玩家离开平台后的 80ms 内，仍然可以起跳
• 跳跃缓冲：玩家落地前的 120ms 内按下跳跃键，落地后会立刻起跳

这两个机制在职业术语里叫"手感宽容度"。真正的硬核玩家可能不会感知到它们的存在，但没有了它们，游戏会莫名"僵硬"。我在 71 组测试里，把缓冲时间按 20ms 一档从 0 加到 200，最终落到 120ms 是因为它恰好是"玩家感觉不到延迟"和"能拯救误触"的平衡点。

4.2 像素级判定：从碰撞体到"感觉对"的微调

游戏是像素风格，但碰撞检测并没有真正精确到像素级别，那样成本太高了。我用的是网格碰撞：把整个关卡划分成 16x16 的格子，角色占据一个或多个格子区域，移动时先检测水平方向，再检测垂直方向，避免对角线穿透。这套方案在纯平台跳跃游戏里已经是标准的可靠做法。

但真正"手感对"的秘诀，不在碰撞检测的精度，而在碰撞盒的形状。一个角色看似只有 16x16 像素大，但他的碰撞盒不应该占满整个身体。我把玩家的碰撞盒设成了 12x14 像素，缩水了一圈。为什么？因为玩家在跳跃时"觉得能过去"的一瞬间，往往是因为视觉边缘已经擦到了目标；如果碰撞盒完全等于视觉效果，那些极限跳跃会被严苛地拦截。给碰撞盒缩小一点，就好像给玩家发了一张"视觉误差豁免卡"，游戏瞬间变得宽容而友好。

这个思路也可以用在敌人身上：敌人的碰撞盒略大于视觉尺寸，这样玩家被判定碰到敌人的情况更多一点，但踩到敌人头顶的判定略微缩小——两头都适当收紧，让"跳过敌人"变得更安全。

4.3 关卡结构如何被编辑器驯服

"像素跳动"的关卡文件结构是这样的：

return { width = 40, height = 20, tilemap = { ... }, -- 每一格是地板/墙面/空白 entities = { { type = "player_spawn", x = 2, y = 14 }, { type = "spike", x = 10, y = 15 }, { type = "moving_platform", x = 15, y = 8, range_x = 3, range_y = 0, speed = 2 }, { type = "coin", x = 8, y = 8 }, { type = "goal", x = 38, y = 5 }, }, }

我自研编辑器的工作模式极其朴素：左边是网格画布，右上是属性面板，右下是层级列表。在网格上点一下就能放一个平台，拖拽调整位置，右侧改属性，搞定。最关键的一点是"热重载"——在游戏运行中，我按 F6，当前关卡立刻重新加载，玩家位置保留在原来的地方。这样我可以反复测试同一小段关卡，不需要从关卡开头一步步跳过去，测试效率提升了非常多。

举个小例子：第 7 关有一处非常极限的连续移动平台跳跃。我为了微调第二块平台的移动速度，在编辑器里把它从 2.5 改到 3.2，按 F6 重新加载，立刻就能站在起点尝试手感。这个动作一分钟能循环十几次。如果不用编辑器、直接改代码里的坐标数字，一次循环可能要两分钟，而且容易改错坐标。编辑器带来的不仅是视觉直观，更是试错成本的指数级下降。

5. 从零到一的过程中，我踩过的那些坑

一个人做项目，坑几乎是等比例增长的——系统越多，坑越深。这里选四个我在开发里印象最深、也最典型的教训。如果你正准备一个人启动自己的项目，这几个坑大概率你也会遇到。

5.1 过早优化和过晚备份是捆在一起的

第 4 个月的时候，游戏还只有一个能在空地跳的方块，我却已经开始折腾"通用敌人 AI 框架"，想着以后敌人的状态机肯定很复杂。结果那个框架写了一千多行，占满了我每天晚上 3 个小时的精力，而游戏本身一个敌人都没有。后来我决定全删重写，删完的那一刻人清爽了，但时间已经浪费了两个星期。

更痛的是另一个晚上。我的 Aseprite 工程文件不小心被误删——准确地说，是编辑器崩溃连带写坏了文件头。那里面是我花了两周画的主角动画帧，部分帧连参考图都没有第二份。那天我对着空荡荡的回收站发了好一会儿呆。从那时起我立下两条死规矩：

• 每天结束开发前，必须 Git 提交一次，提交信息哪怕只写"add spikes"也行
• 美术原始文件每天做一次自动快照，放到另一个硬盘目录

这些备份在最后三个月帮了我大忙——至少有三次，我在调 BOSS 战的时候改出了奇怪的 bug，全靠回滚到前一天版本才恢复。备份不是让你避免犯错，而是让你敢犯错。对独立开发者来说，敢犯错的心态比什么都重要。

5.2 一个人也需要"代码评审"：给自己当陌生人的经验

没有同事，没有 code review，这是单人开发最危险的陷阱之一。我写过太多"当时觉得天才能看懂、一个月后自己看像天书"的代码。尤其是 Lua 这种动态类型语言，函数参数传错了类型不会立刻报错，往往是运行到某个边界条件才炸。

中期我给自己做了一个强制流程：每两周一次"重构日"，把最近两周写的代码从头读一遍，凡是出现以下特征的代码全部处理：

• 函数超过 40 行，拆
• 命名含义含糊的变量，改名
• 注释和代码不一致，以代码为准改注释
• 同一个算法出现两次，抽成公共函数

这个流程救了我非常多。有一次在重构日的阅读中，我发现跳跃缓冲的实现漏掉了"玩家在落地瞬间才按跳跃键"的情况，而这个 bug 在正式测试时几乎不可能被发现，但会导致玩家在特定节奏下跳跃失灵——这正是"感觉这游戏有问题但说不清哪里有问题"的元凶。一个人不能总依赖别人帮你发现问题，做自己的陌生人，反而更能看清短板。

5.3 当我发现"编辑器比游戏还大"时

自研编辑器前期帮我提效，但做到第 12 个月，我犯了一个典型的"工具沉迷"错误。编辑器本来只需要支持"放平台、放敌人、调属性"，我却开始给它加"图层混合模式""撤销历史的可视化时间轴""自动生成某类关卡的参数模板"等功能。每次打开编辑器，都有一种"我真厉害"的错觉——但仔细一想，游戏本身的关卡才做了 7 关，而编辑器快 5000 行了。

那个月我终于清醒了：我是在用做编辑器逃避做关卡内容。做一个新功能很容易带来成就感，但把 20 关一个个设计完，需要的是持续而枯燥的专注。我给自己定下铁律：新功能必须满足"当前做关卡时立刻会用到"这一条，才能加入编辑器。那一堆花哨的"未来可能会用到"的功能，全部砍掉。砍完之后编辑器瘦了一圈，关卡产量反而上来了——因为我没有借口再折腾工具了。

5.4 一人团队的进度崩溃：当连续三周没有写出一个漂亮的关卡时

还有一种坑，不是技术问题，是情绪问题。做到第 14 个月，我连续三周没写出一个自己满意的关卡，每天晚上在编辑器里拖来拖去，存了删，删了又存，最后的产出是负的。那段时间我变得特别不想打开项目，甚至想过原地放弃。

后来我怎么出来的？我做了一个特别"蠢"的决定：不再造新关卡，而是把已经做好的第 1 关到第 8 关重新玩一遍，每玩一关只改一个我觉得最不爽的小问题——比如某块平台的间距过大，某颗金币的位置太偏。连续一周，我不追求大突破，只追求"每天让游戏好一点点"。一周后，信心回来了，第 14 关的灵感也冒出来了。

对单人开发来说，进度低谷是必然的，但你不必用"硬扛"去熬过它。把目标缩小到"今天只改进一个像素的间距"也行，只要还在接触编辑器、还在和项目保持连接，低谷总有一天会过去。

6. 上线前两天我为"像素跳动"收尾时的一些心里话

发布前两天，我没有在做功能，而是在做减法。我把所有标题界面的文案重新念了一遍，删掉所有我自认为幽默但玩家根本看不懂的梗；把操作说明从三页压缩成一页，用一张图加六个字讲清楚"方向键移动，空格跳跃，Shift 二段跳"；还重新设计了存档界面的默认命名——直接给玩家一个推荐名字，而不是让他们面对一个空输入框发呆。

当时旁边有人问我："你怎么不搞个新手教程关卡？"我说，平台跳跃游戏的新手教程应该藏在第一关里，让玩家不知不觉学会跳跃，而不是逼他先读一段说明书。所以我砍掉了专门的教学关卡，改成把基础操作融进第 1 关的地形里。这个决定需要一点勇气，因为教学缺失确实是很多独立游戏的败笔，但好的关卡本身就是最好的说明书。

上线后我收到的第一条玩家评论，不是评价画面，也不是说什么手感，而是："我把你游戏里的编辑器玩明白了，自己做了一关全是移动平台的，结果发现我跳不过去。" 那一刻我特别高兴——因为这说明有人比我更早意识到，"像素跳动"这个项目最大的隐藏玩法，其实是让玩家自己编辑关卡。有人用内置编辑器做出了整屏的像素跳板迷宫，传到了社区；有人开始研究"不同平台的移动速度该怎么搭配才好玩"，这让我的游戏意外地多了一层"无穷内容"的可能性。

最后想跟所有打算"一个人出来做点什么"的读者说几句实在话：第一，别一上来就追求大作，一个好点子加上扎实的核心机制，远比一张宏大但空洞的路线图靠谱；第二，做一个"能结束"的东西——哪怕它很小，有头有尾才能让你获得完整的正反馈，而不是永远在开发第一个系统；第三，工具够用就行，但值得你亲手为项目的核心需求做一个专属工具，真正的效率提升往往不是来自更快地打字，而是来自更少的重复劳动。

我在 18 个月里没有一天是不焦虑的，但我坚持每天打开编辑器，哪怕只写一行代码、摆一个平台、调一个参数，也算今天没有白过。量变到质变，靠的就是这种笨拙而持续的重复。一个人，一个编辑器，一个梦——正是这份"微小但确定"的日拱一卒，最终让"像素跳动"从一个失眠夜的念头，变成了一款真真切切可以下载、可以玩、可以让人开心的游戏。你要是也有那个一直放不下的念头，别等辞职，别再想太多，今晚就试着在编辑器里敲下第一行代码吧。