大概两年前我第一次在朋友群里看到91行代码创意赛的征集帖第一反应是这不就是变相的代码减肥大赛吗后来真正动手投稿才发现限制行数这件事和“能不能写出来”完全是两码事。你哪怕不加空行、硬凑91行也不难真正难的是让这91行里同时有创意、有完成度、有技术含量还经得起评委一行一行去读。这篇文章我打算把这类比赛从构思、编码到写技术文章的整套思路拆开来讲既是给自己留一份复盘也是给后来参赛的人一份可以直接照着走的借鉴。1. 为什么偏偏是91行先读懂规则背后的意图再动手1.1 行数限制不是门槛是方向91行这个数字乍看有点奇怪。市面上大多数极客挑战要么是“100行写一个编译器”、要么是“50行实现一个3D引擎”91行不在这些主流数字里。如果你去看比赛公告的措辞基本都会提到“创意优先、以小见大”这类说法有些还会把“91”解读成谐音“就要”意思是“你离一个完整作品只差就要动手”。理解了这层意图再看规则就完全不一样了。它不是在要求你写一个极其精密的“微型系统”而是在引导你做一个恰好能讲完一个故事的作品。91行既不像10行那样只够写玩具也不像300行那样有足够空间铺陈完整业务逻辑。它卡在一个很有意思的区间刚好能塞下一个核心玩法和一层简单交互但塞不下多余的系统设计。这种“带一点点挤”的体感才是这个比赛真正的趣味所在。1.2 评委端到端看作品的三层视角我参加过几次类似的评审交流也和不少评委聊过他们真实打分时的心理过程。一个91行的作品摆在那里评委通常不会先看代码而是先跑一遍效果然后才会回头看代码。他们的关注点基本落在三个层面创意层这个东西有没有让人眼前一亮是不是以前没见过技术层代码结构是否合理有没有人在刻意压缩后还能保持条理叙事层技术文章是否讲清楚了“为什么这么做”和“卡在哪了”如果三个层面都不出错作品分数就不会低。但很多参赛者最容易犯的错是把90%的精力都花在技术压缩上创意和文章草草带过。评委看完效果觉得普通看完代码觉得厉害看完文章觉得什么都没说最后总分就被拉下来了。1.3 行数松紧的潜规则这里要说一个规则外的经验91行的统计口径不同比赛差异很大。有的比赛只算代码行不含空行和注释有的比赛会把注释也算进去有的甚至要求提交的文件直接以执行入口为起点连package声明都算。这直接决定了你后续的编码策略。我的建议是动手之前先把“一行”的定义看清楚尤其是换行符算不算一行这类细节。遇到最严格的情况一个很长的条件表达式如果被自动格式化工具折成了三行那三行就是三行。这会极大影响你写代码时的换行习惯。2. 从创意倒推91行真正该先做的事情是画思维导图2.1 一句话说清楚你的内核不管你脑子里冒出来的是炫酷的粒子动画、复古小游戏还是一个藏在浏览器地址栏里的彩蛋先别急着打开编辑器。我习惯的流程是拿一张便利贴把作品的内核用一句话写在上面比如“让文字变成不断分裂又重组的气泡”“一个人在沙漠里走每走一步身后就长出一棵树”“输入公式自动生成一幅函数画”这句话必须足够具体具体到别人听完就能脑补出画面。如果这个阶段你要想很久说明创意还没成型。91行代码的承载能力有限凡是连你自己都无法一句话讲清的东西代码里多半也讲不清。2.2 拆出一个“必须功能”清单一句话定稿之后把它拆成三个清单必须有、可以有、纯属加戏。以“输入公式生成函数画”为例必须有公式解析、坐标映射、画布渲染。可以有预设几个常用公式、颜色渐变、渐变背景。纯属加戏多语言切换、导出图片、公式历史记录。拆完之后你会发现真正的主角只有三个功能模块。91行的空间足够把这三个模块写得明明白白前提是你愿意砍掉“可以有”里那些凑热闹的项。很多参赛作品死掉不是因为想法不够好而是想塞的东西太多最后每个模块都在凑合整体就像一盘糊掉的菜。2.3 从技术栈角度反推复杂度同一个创意用不同语言和运行时实现行数可以是天壤之别。比如你要做粒子动画用CSS配合少量JavaScript和用全量实现一个Canvas粒子引擎体感完全不同。我个人的倾向是能靠解释器或浏览器内置能力解决的事就不要自己重复造轮子。参与这类创意赛其实也是一次技术选型博弈。选了处理图片方便的库你的代码重点可以放在创意逻辑上选了必须手动管理内存的语言你的精力就会被底层细节吃掉一大半。在91行这个体量里没有什么比“把生态用起来”更划算的事了。这个原则适用于绝大多数参赛者除非你参加的就是“不允许依赖任何库”的硬核赛道。2.4 先画代码骨架再填血肉拆完功能后我建议你用伪代码或者简单的括号图把代码骨架画出来。通常9行以内的代码就能勾勒出一个程序的骨架数据初始化。主循环/主流程。渲染/输出。事件响应如果有交互。骨架一旦清晰后面填代码就是一个“对号入座”的过程。很多人在写91行代码时感到混乱就是跳过了这个骨架步骤想到什么写什么最后代码顺序跟大脑一样乱。3. 把创意压进91行的工程化技巧先写正常代码再做减法3.1 先定行数统计口径再谈压缩我在前面提过不同比赛对“行”的定义不一样。在你动手写第一行代码之前先把口径固定下来空行算吗注释算吗库导入算吗打包配置算吗口径直接决定你后续的压缩空间。比如注释也算行的话你就要考虑用更简短的命名来代替注释或者在文末统一放注释说明。如果只有纯代码算行的话偶尔用一两个注释反而能提高评审阅读效率是性价比很高的“隐藏加分项”。3.2 先写一个“未压缩版”别跟自己较劲这是我最想强调的一点不要一开始就写“91行版本”。先无视行数把一个能跑、功能完整、逻辑清楚、稍微臃肿的版本写出来。这个版本可能是150行也可能是190行都不重要。因为压缩这件事本质上是在删“冗余”而不是在一张写满字的纸上抠缝。先写完整版你才能看到哪些逻辑其实是重复的、哪些分支其实可以合并、哪些变量其实可以抽象成数组索引。你在原始版本里做重构比在纠结的91行里边写边改要容易十倍。而且这个“完整版”还有一个隐藏用途它是你调试时候的救生圈。等压缩版出了问题翻回去看一眼完整版问题往往一眼就能看出来。3.3 压缩三板斧函数折叠、数据驱动、状态联动做完未压缩版就可以开始真正的手艺活了。我总结出三个最常用、也最不容易破坏代码可读性的压缩手段。第一板斧函数折叠把只在某个流程里出现一次的逻辑拆成一个独立函数。听起来像在反压缩但实际操作里把一段10行的循环体挪进函数再用一行调用它只要函数在代码里出现了两次以上总行数反而会下降。这个操作尤其适用于处理重复的绘制、重复的数据转换。函数折叠的另一大好处是评审能在脑子里建立“入口函数若干功能性函数”的模块感代码不会看起来像一坨意义不明的线性流水账。第二板斧数据驱动用数据表替代条件分支。比如你要根据不同的状态码生成不同颜色的点不需要写五个if只需要准备一个数组const colors [#ff004c, #00a1ff, #8d00ff, #ffb300, #00c853]; // 后续直接用 colors[state] 取色类似地如果不同按键要触发不同动作也可以用一个对象把按键名映射到方法名。把逻辑分支变成数据索引之后代码行数会肉眼可见地下降而且逻辑反而更清晰。唯一的代价是你需要一点抽象思维把“一堆if”翻译成“一张表”。第三板斧状态联动很多程序里存在“一个变量变其他好几个变量跟着变”的连锁反应。如果你不留神就会为每个连锁反应写一行更新逻辑白白浪费好几行代码。更好的做法是把这些状态收敛到一个对象里通过一个函数统一重新计算。比如一个粒子系统里的速度、位置、透明度其实可以一次性从更新函数里推出不必各自单独维护。3.4 压缩的边界不要为了行数牺牲可读性这里必须泼一盆冷水。压缩有一个很明确的边界越过去就是灾难。比如把变量名全部改成a、b、c把逻辑全部写成一行嵌套三元表达式确实能压掉不少行数但你自己过一个星期都未必看得懂。而评审是要一行一行读你代码的他们看到的不是聪明而是一堆自找麻烦。我在实际操作中的习惯是压缩幅度限制在略低于未压缩版60%左右。也就是190行的完整版目标压到110到120行再从里面优雅地扣掉20行。这个幅度既能体现出“我很懂行数控制”又不至于让代码变成不可读的密码本。4. 极限行数下的调试与自测如何避免交出一个“看起来很美”的残次品4.1 压缩代码后的第一件事跑一遍完整流程回放代码压缩到91行以后第一件要做的事不是再减几行而是把核心流程从头到尾跑一遍。很多压缩手法会带来变量作用域和初始化的顺序问题。比如你为了省代码把声明和初始化合并到表达式里了结果变量在渲染时才被定义执行时直接报错。我见过太多参赛作品演示动图拍得挺好看但真正运行起来只在某个特定窗口大小下不出错换个环境就白屏。这种问题在普通项目里不算致命但在比赛里是致命的印象分减分项。4.2 几个最适合极限代码项目的“自检套路”变量清零测试刷新页面后不进行任何额外操作程序能否自动进入正常状态数据边界测试如果输入是空数组、0、负数、极大数程序会不会崩溃窗口缩放测试画布类作品请重点测试窗口尺寸变化特别是从非常小拉到非常大。连续交互测试按钮连点十次以上、鼠标快速移动会不会出现状态卡死这四个测试不需要写测试框架肉眼手动跑几遍就够了。它们能拦下90%的“演示时没问题、交卷就翻车”的惨案。4.3 给代码留“呼吸位”顺便给自己留后路再强调一遍91行限制不代表你要写满91行。很多参赛者以为越接近91行越好其实并不是。只要你的核心功能完整、代码干净写87行、88行完全没问题。那些“留白”的行数在你发现一个bug但想不出优雅修法时就是你的补丁空间。我自己甚至会刻意在压缩完之后至少保留3到5行的余量专门用来应急修复。这比费尽心机压到刚好91行要健康得多。5. 代码之外的半壁江山技术文章到底该怎么组织5.1 把技术文章当成作品的一部分而不是事后总结比赛既然叫“创意赛”那技术文章就不该只是“代码说明书”。你身后的文字某种程度上是评委理解你创意意图的第二个窗口。代码再漂亮文章写得乱七八糟分数也很难高。我建议把技术文章当作作品的活动说明书来写读者没有打开代码之前光看你的文章就已经能在脑海里运行一遍你的作品。要达到这个效果文章里至少要有三层内容灵感入口为什么想到做这个最初的触发点是什么结构拆解91行代码是如何分布的每段代码负责什么职责过程叙述从想法到成品你经历了哪些取舍和失败5.2 用“一个主流程三个关键片段”的方式讲解代码把全部91行代码贴出来然后从头到尾逐行注释这是效率最低的写法。评委并不需要你把每一行都讲一遍他们需要的是你帮他们抓住重点。我推荐的结构是贴一个完整的程序运行效果图或动图。用一个“入口到出口”的整体流程图讲清楚数据从哪来、经过哪几步、最后输出到什么。挑三个最“见功力”的代码片段分别讲清楚它们为什么这么写、有没有更常规的做法、你为什么要选择这种更精简的写法。这样讲文章既不会太啰嗦又能把技术深度展示到位。很多人担心自己写不出深度其实深度不在于代码有多绕而在于你能不能让读者感受到你不是只会写代码你在认真思考怎么写代码。5.3 把失败尝试写进文章反而更容易拿“技术分”我参与过的评审里对技术文章的评分往往有个神奇的口味有失败尝试的文章分数通常更高。因为失败尝试能让评委看到你的思考过程知道你遇到过真实的问题并且通过调整方案解决了它。这比一帆风顺的完美叙事可信得多。比如你可以写“一开始我试图用循环生成背景网格但这样会让代码多出8行后来我改用Canvas的填充样式配合透明度直接省掉了这8行。”这种叙述非常短却能立刻展现你的工程判断力。5.4 文章标题、开头和结尾的小技巧标题不要直接叫“基于××的××系统”太像毕业论文了。创意赛的文章标题更适合走“悬念功能”的路线比如“我用91行代码让字母在屏幕上学跳舞”。开头直接用场景切入别铺背景知识你要让读者在30秒内知道这个作品是什么、好玩在哪。结尾也别写“综上”把你在调试中最意外的一次发现写出来反而会留下更深刻的印象。6. 我实际参赛和评审后的几个经验细节6.1 展示效果图和动图一定要用真实运行的截图很多参赛者的文章里效果图是从设计稿里截的或者修过色。“实物与图片不符”在评委这里是硬伤。代码类比赛的评审不需要多专业只需要把代码跑一下立刻就知道你的图真不真。与其花时间美化截图不如把运行效果录成一段几秒钟的GIF或短视频这反而最能体现作品的真实程度。6.2 注意“本地能跑”和“别人能跑”之间的差距这可能是最容易被忽视的一点。你本地装的依赖、环境变量、浏览器版本和评委的评审环境大概率不完全一致。能缩小这个差距的手段就是保证你在提交说明里写清楚运行方式是直接双击HTML还是需要先执行哪条命令。写得越清楚评委跑通你的作品的概率越大第一印象自然越好。如果你还能顺手把依赖文件一起提交那就更稳妥了。6.3 文件名、入口文件和提交格式别让细节拖后腿我见过有作品因为入口文件叫main2.js、代码里却引用app.js而直接跑不起来的。也见过有些作品压缩包解压后有一堆临时文件评委根本不知道该打开哪个。正确的做法是压缩包里只保留必要文件入口文件命名为index.html或main.py再写一个几行的README说明运行环境和操作步骤。这些细节不花多少时间却能让评委对你的好感度直接拉满。6.4 最后再分享一个小技巧我个人在提交前一定会做一个“30秒陌生人测试”找一位朋友把压缩包发过去只发一句话“你打开跑一下”然后看他的操作。如果他看完这句话就能顺利跑起来说明你的提交没问题如果他卡住了卡住的地方就是你需要改进的交接点。这个测试虽然土但能测出你在自己脑子里想当然忽略的所有问题比你自己反复自测十遍都有效。如果你正准备参加类似的创意赛我的建议是别把91行当成一座必须爬过去的山把它当成一张刚好够画完一张小画的纸。创意决定这张画值不值得看代码决定它能不能真正呈现出来技术文章决定观众离开后记不记得住它。三样东西都照顾到成绩自然不差。