1. 从一条比赛通知说起：这个活动到底在比什么

第一次看到“WorkBuddy和麦当劳，欢迎你来程序员创意开发大赛，赢50次巨无霸免费兑换券和10240积分”这个标题，我第一反应是：这不像传统那种“命题作文式”的编程比赛，更像是一次把工具能力、创意表达和真实消费场景揉在一起的轻量级开发活动。它面向的不是只写算法题的选手，而是那些愿意把代码变成“能玩、能用、能分享”的小东西的人。

先把核心信息拆开看。标题里出现了三个关键元素：WorkBuddy、麦当劳、程序员创意开发大赛。WorkBuddy大概率是一个面向开发者的协作或效率工具平台，麦当劳是消费品牌，而“创意开发大赛”说明比赛的重点不在性能压榨，而在创意落地。奖励也很有意思：50次巨无霸免费兑换券加10240积分。10240这个数字对程序员来说太熟悉了，正好是10×1024，也就是10KB的字节数，这种“程序员梗”式的奖励设计，本身就说明活动方懂开发者文化。

那这个比赛适合谁？我认为有三类人值得关注。第一类是独立开发者和小团队，手里有零散的点子，缺一个 deadline 和展示舞台；第二类是学生和转行者，需要拿得出手的项目经历，同时奖励又是实打实能吃到的；第三类是喜欢做趣味项目的资深工程师，平时工作写业务代码写腻了，想借比赛做点“不正经但有意思”的东西。这个比赛解决的核心问题，就是给创意一个低门槛、有反馈、有奖励的出口。

我参加过也围观过不少类似活动，最大的感受是：很多人不是没能力，而是不知道从哪下手，或者一上来就想做“大而全”的东西，结果两周过去连原型都没跑起来。所以下面我会按一个真实参赛者的视角，把整个思路、技术选型、实操步骤和踩坑经验完整拆一遍。你不需要是算法大神，只要会写基本的增删改查和调接口，就能跟上。

2. 比赛整体设计与思路拆解

2.1 为什么这类比赛偏爱“轻创意”而不是“重技术”

传统编程竞赛往往是算法导向，比如限定时间解几道难题，考的是数据结构和思维速度。但“创意开发大赛”这类活动的评分逻辑完全不同，它更看重想法的新颖度、完成度和可演示性。原因很现实：赞助方是消费品牌，他们要的是能传播、能引发讨论的作品，而不是一段跑分很高的代码。

我观察过几个类似活动的获奖作品，发现一个规律：拿奖的往往不是技术最复杂的，而是把某个日常场景做得特别顺滑的。比如有人做过“根据心情推荐套餐”的小程序，技术含量不高，但演示时全场都笑了，评委印象分直接拉满。所以你在定方向时，不要先想“我要用什么高深框架”，而要先想“我要让谁在什么场景下会心一笑”。

WorkBuddy 出现在标题里，说明它很可能是官方指定的开发载体或协作工具。这类平台通常会提供 API、SDK 或者低代码能力，让你不用从零搭后端。我的建议是：优先用官方给的能力，把省下来的时间花在创意和交互上。自己造轮子不是不行，但在有限赛期里，能跑通比“架构优雅”重要得多。

2.2 奖励机制背后的心理设计：为什么是50次和10240

50次巨无霸兑换券，按一次一顿来算，够你吃将近两个月（如果天天吃的话）。这个数量不是随便定的，它制造了一种“持续获得感”——不是一次性发个红包就结束了，而是让你在很长一段时间里反复想起这个活动。10240积分则更像程序员之间的暗号，10KB的梗一出来，目标人群立刻会心一笑，传播成本极低。

从参赛策略上讲，这种奖励结构意味着参与本身就有价值。很多比赛只有前三名有奖，大部分人陪跑。但这个活动如果设置了参与奖、人气奖、创意奖等多个维度，那你即使拿不到大奖，也有机会靠“完成度”或“投票”拿到一部分兑换券。所以我的建议是：先保证提交一个完整可演示的作品，再去打磨细节。半成品再惊艳，也不如一个能跑通的简单作品。

2.3 选题方向：从“麦当劳场景”里找切口

既然赞助方是麦当劳，选题最好和它的消费场景有关联，但不必硬蹭。我梳理了几个容易出彩的方向，你可以根据自己的技术栈挑一个：

• 点餐辅助类：比如根据人数、预算、口味偏好自动生成套餐组合，核心是规则引擎加一点推荐逻辑。
• 趣味互动类：比如“今天吃什么”转盘、汉堡叠叠乐小游戏，重点在动画和反馈。
• 数据可视化类：比如把积分、优惠券使用情况做成图表，适合喜欢做前端的同学。
• 工具效率类：比如帮店员或用户快速计算最优优惠组合，偏实用向。
• 社交传播类：比如生成专属“汉堡人格”海报，方便分享，容易拉投票。

我个人最推荐点餐辅助类和趣味互动类，因为这两类最容易在演示时出效果，而且技术栈要求不高。下面我会以“套餐推荐小工具”为例，把完整实现过程拆开讲。

3. 核心细节解析与实操要点

3.1 技术选型：为什么我选 Web 而不是原生 App

赛期通常不长，可能就两到四周。在这种时间压力下，Web 技术栈的迭代速度是最快的。你改一行代码，刷新浏览器就能看到效果，不需要重新编译、签名、安装。而且演示时只要一个链接就能打开，评委和观众都能当场体验，传播成本最低。

具体来说，我建议用HTML + CSS + 原生 JavaScript起步，不要一上来就上 React 或 Vue。原因很简单：这个规模的项目，框架带来的收益有限，但配置成本和学习成本是实打实的。等你发现状态管理变复杂了，再引入轻量库也不迟。如果你本来就会框架，那用顺手的就行，不必为了“轻量”而轻量。

后端方面，如果 WorkBuddy 提供了云函数或 API 网关，直接用。如果没有，可以用最简单的 Node.js + Express 起一个服务，甚至用静态 JSON 模拟数据也能撑过演示。关键是把数据流跑通，而不是把数据库设计得多完美。

3.2 数据建模：菜单和偏好怎么存

假设我们要做一个套餐推荐工具，核心数据就两块：菜单项和用户偏好。菜单项可以先用一个 JSON 数组存，每个对象包含名称、价格、热量、类别（主食/小食/饮料）、辣度等字段。用户偏好则用几个滑块或选项来收集，比如预算范围、是否吃辣、要不要饮料。

这里有个细节很多人会忽略：单位要统一。价格用元，热量用千卡，辣度用1到5的整数。统一单位后，后面的计算逻辑才不会乱。我见过有人价格用“分”存，展示时忘了除以100，结果推荐出一个“0.15元”的套餐，演示时非常尴尬。

const menu = [ { id: 1, name: "经典汉堡", price: 18, calories: 550, category: "main", spicy: 1 }, { id: 2, name: "辣味鸡腿堡", price: 20, calories: 600, category: "main", spicy: 4 }, { id: 3, name: "中份薯条", price: 10, calories: 320, category: "side", spicy: 0 }, { id: 4, name: "可乐", price: 8, calories: 150, category: "drink", spicy: 0 } ];

偏好对象可以长这样：

const preference = { budget: 35, maxSpicy: 3, needDrink: true, maxCalories: 800 };

有了这两块数据，推荐逻辑就是一次过滤加排序。过滤掉超预算、超辣度、超热量的项，然后按“主食+小食+饮料”的组合去凑。如果凑不出完全满足的，就给出“最接近”的方案，并提示哪一项超标了。这种渐进式推荐比直接说“无结果”体验好得多。

3.3 交互设计：让推荐结果“看得见”

推荐结果不能只给一串文字，那样太干。我的做法是：用卡片展示每一项，配上简单的图标或色块，然后在底部显示总价和总热量。如果总价接近预算上限，用橙色提示；如果超了，用红色并给出替换建议。

这里有个实操心得：动画不要多，但要准。比如用户拖动预算滑块时，结果卡片用 200 毫秒的淡入淡出过渡，而不是瞬间跳变。这个细节成本很低，但演示时观感提升明显。我试过加太多花哨动画，结果在低配电脑上卡顿，反而扣分。所以动画只加在“结果更新”这一个环节就够了。

另外，一定要做移动端适配。评委很可能用手机打开你的链接，如果布局在手机上错位，第一印象就毁了。用 CSS 的 flex 布局加媒体查询，半小时就能搞定基础适配。

4. 实操过程与核心环节实现

4.1 第一步：搭出最小可运行页面

不要一上来就写完整逻辑。先写一个 HTML 骨架，放上标题、几个输入控件和一个“生成推荐”按钮。按钮点击后，先用alert弹出一句“功能开发中”。这一步的目的是确认页面能打开、按钮能点，把环境问题提前暴露。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>套餐推荐小工具</title> </head> <body> <h1>今天吃什么</h1> <label>预算：<input type="range" id="budget" min="20" max="60" value="35"></label> <span id="budgetValue">35元</span> <label>辣度上限：<input type="range" id="spicy" min="0" max="5" value="3"></label> <button id="generate">生成推荐</button> <div id="result"></div> <script src="app.js"></script> </body> </html>

这个骨架不到 20 行，但已经包含了核心交互元素。我见过有人花两天配环境，结果比赛过半还没写出第一行业务代码，非常可惜。先跑起来，再优化，这是铁律。

4.2 第二步：实现推荐算法

推荐算法的核心是组合搜索。菜单项不多的情况下，直接三重循环枚举“主食+小食+饮料”的所有组合，然后打分排序。打分维度包括：总价是否接近预算、辣度是否在范围内、热量是否超标。每个维度给一个权重，最后取总分最高的组合。

function recommend(menu, pref) { const mains = menu.filter(i => i.category === "main"); const sides = menu.filter(i => i.category === "side"); const drinks = menu.filter(i => i.category === "drink"); let best = null; let bestScore = -Infinity; for (const m of mains) { for (const s of sides) { for (const d of drinks) { const total = m.price + s.price + d.price; const spicy = Math.max(m.spicy, s.spicy, d.spicy); const calories = m.calories + s.calories + d.calories; if (spicy > pref.maxSpicy) continue; let score = 0; score -= Math.abs(total - pref.budget) * 2; score -= Math.max(0, calories - pref.maxCalories) * 0.1; if (score > bestScore) { bestScore = score; best = { items: [m, s, d], total, calories }; } } } } return best; }

这段代码的逻辑很直白：遍历所有组合，跳过辣度超标的，然后给接近预算且热量不超的组合打高分。权重是我拍脑袋定的，你可以根据演示效果调整。比如你希望价格更敏感，就把价格差的系数从2调到3。

4.3 第三步：渲染结果并处理边界情况

拿到最佳组合后，把它渲染成卡片。同时要处理“找不到任何组合”的情况，比如预算设成5元，那肯定无解。这时候不要显示空白，而是给出提示：“预算太低啦，试试提高到20元以上？”这种友好的兜底文案能显著提升体验。

function render(result) { const box = document.getElementById("result"); if (!result) { box.innerHTML = "<p>没有找到合适的组合，试试放宽条件？</p>"; return; } box.innerHTML = result.items.map(item => `<div class="card"> <strong>${item.name}</strong> <span>${item.price}元 / ${item.calories}千卡</span> </div>` ).join("") + `<p class="total">总计：${result.total}元，${result.calories}千卡</p>`; }

这里用模板字符串拼 HTML 是最快的方式，不需要引入任何模板引擎。注意对用户输入做转义，虽然这个场景下输入都是数字，但养成习惯没坏处。

4.4 第四步：接入 WorkBuddy 能力（如果可用）

如果 WorkBuddy 提供了 API，比如用户身份、积分查询或分享能力，那就在这一步接入。通常官方文档会给一个 SDK 和几个示例请求。我的建议是：先跑通官方示例，再改成自己的逻辑。不要跳过示例直接写，否则报错了你都不知道是环境问题还是代码问题。

接入时注意错误处理。网络请求可能失败，接口可能限流。给每个请求加try/catch，失败时降级到本地模拟数据，保证演示不中断。我吃过这个亏：演示当天网络不稳，接口超时，页面直接白屏。后来我加了本地缓存兜底，即使接口挂了也能展示上次的结果。

5. 常见问题与排查技巧实录

5.1 页面打开空白怎么办

这是最高频的问题，通常有三个原因。第一，JavaScript 报错导致后续代码不执行。打开浏览器控制台，看有没有红色报错，按报错信息定位行号。第二，脚本加载顺序不对，比如app.js在 DOM 元素之前执行，导致getElementById返回 null。解决办法是把<script>放到</body>之前，或者用DOMContentLoaded事件包裹。第三，文件路径写错，比如src="app.js"但文件实际在js/app.js。这个用浏览器的 Network 面板一看就知道。

5.2 推荐结果总是不对怎么排查

先检查数据，再检查逻辑。把菜单数组和偏好对象打印到控制台，确认字段名和值都符合预期。我遇到过有人把category写成categroy，结果过滤出来全是空数组，推荐自然就错了。然后检查循环边界，比如mains为空时三重循环直接不执行，best保持 null，页面就显示“无结果”。这时候要区分是“真的无解”还是“数据为空导致的假无解”。

5.3 演示时卡顿或动画掉帧

多半是一次性渲染了太多 DOM 节点，或者动画属性用了width、height这类触发重排的属性。解决办法：结果卡片数量有限，一般不会太多；动画改用opacity和transform，这两个属性走 GPU 合成，性能好很多。另外，避免在滚动事件里做复杂计算，如果要做，加个防抖。

5.4 常见问题速查表

5.5 几个只有踩过才知道的坑

第一个坑：不要用innerHTML拼接用户输入。虽然这个场景输入是数字，但万一以后扩展成文本输入，就有注入风险。养成用textContent或转义的习惯。

第二个坑：预算滑块的最小值不要设成0。设成0的话，推荐算法会试图找免费组合，结果全是空，体验很差。设一个合理下限，比如15元。

第三个坑：演示前一定要清缓存。我有次改了代码但浏览器缓存了旧版 JS，演示时还是老逻辑，当场尴尬。用无痕模式或者加版本号查询参数都能避免。

第四个坑：准备一个“演示脚本”。不要现场随机输入，提前想好三组参数：一组正常、一组极端（预算很低）、一组边界（辣度刚好卡线）。这样演示节奏可控，也能展示你的边界处理能力。

6. 从提交到拿奖：作品包装与传播策略

6.1 提交材料怎么写才加分

很多选手代码写得好，但提交说明写得像流水账。评委一天要看几十份作品，第一眼看到的是你的描述，不是代码。所以描述要突出三点：解决什么问题、怎么用、亮点在哪。用短句，配一张截图或 GIF。如果平台支持视频，录一个30秒的演示，比一千字文字都管用。

我通常会把说明写成这个结构：一句话简介、适用场景、核心功能列表、技术栈、演示链接。技术栈不用写太细，除非你用了特别有意思的方案。重点放在“这个工具能帮用户省多少时间”或者“能带来什么乐趣”上。

6.2 拉投票的正确姿势

如果比赛有人气投票环节，那传播就很重要。但不要群发“帮我投票”这种消息，转化率极低。有效的做法是：把作品变成一个可分享的小测试或小游戏，别人玩完自然愿意转发。比如“测测你的汉堡人格”这种，分享动机是“展示自己”，而不是“帮别人”。这个思路转换一下，投票数会差好几倍。

另外，在开发者社区发帖时，标题要具体。不要写“我做了个套餐推荐工具”，而要写“我用200行代码做了个套餐推荐器，预算辣度一键匹配”。具体的数字和功能点能显著提高点击率。

6.3 关于奖励兑换的实操提醒

50次巨无霸兑换券和10240积分，通常会有使用规则，比如有效期、是否可转赠、是否限门店。拿到奖励后先读一遍规则，别等到过期了才想起来。积分如果能在平台内兑换其他东西，也可以看看有没有更划算的选项。我一般会把兑换券集中用在几个特定场景，而不是分散使用，这样心理满足感更强。

7. 如果再来一次，我会怎么优化

这个项目如果继续迭代，我会从三个方向扩展。第一，加入历史记录，用 localStorage 存最近几次推荐结果，用户不用每次重新输入。第二，加入分享功能，把推荐结果生成一张带二维码的图片，方便传播。第三，接入真实菜单数据，如果官方提供接口的话，让推荐更准确。

技术层面，我会把推荐算法从“暴力枚举”改成“带剪枝的搜索”，虽然当前数据量下没必要，但作为学习练习很有价值。另外，我会把 UI 组件抽成独立的函数，方便复用和测试。这些优化不一定能提高比赛名次，但能让代码更耐看，也方便以后放到作品集里。

最后分享一个小心得：比赛期间每天提交一次进度。很多平台会记录提交活跃度，而且每天提交能强迫你保持节奏，避免最后一天通宵赶工。我试过连续一周每天提交一个小版本，最后完成度比之前任何一次都高。这个习惯比任何技巧都管用。