企业官网建设流程全解析

搞这个项目之前，我其实一直挺反感“打卡”这类学习方式的。因为身边太多人，打卡打了三个月，翻开笔记一片空白，问学了什么全是概念。但没想到，最后把我自己说服的，是一套把学习完全游戏化的追踪系统——就是你看到的这个标题：小白努力学习技术，从1级升级开始，目前等级：9级(3/10)。

这其实是一个给某位零基础学编程的朋友做的个人学习进度管理系统。他自称“小白”，给自己定的规则很简单：把要学的技术内容拆成经验任务，每完成一个学习动作就获得经验，经验满了就升级。从最开始的1级一路练到现在的9级，当前经验进度是3/10，也就是离10级还差最后那一段。作为开发者和使用者双重身份，我把这套系统的设计思路、数据模型、核心代码和踩坑记录全部整理出来，分享给每一个管不住进度、学不下去的自学者和技术爱好者。如果你也曾经列了一堆学习计划却没一个能坚持两周，这篇文章很值得你看完。

1. 系统整体设计与需求拆解

1.1 单纯列学习计划，到底败在哪里

先聊聊我为什么一开始对“打卡”和“计划表”那么不感冒。你自己回忆一下，是不是也经历过这样的场景：某个周末热血上头，打开笔记本写了一张“两周学会Python基础”的计划表，周一按部就班看了一小时视频，周二加班太累直接断档，周三为了补进度熬夜看到凌晨，结果大脑一片空白，周四开始自我怀疑，周五计划表就被扔进回收站了。

传统计划表最大的问题，不是没有目标，而是反馈极度滞后。你计划“本周掌握函数定义”，这个目标的达成没有明确信号。今天多学一小时和少学一小时，在计划表上没有任何直观的差别。人的大脑对延迟满足的耐心是有限的，当你看不到自己“到底变强了多少”时，放弃就成了默认选项。

1.2 为什么用等级体系，而不是星级或积分

做这套系统之前，我也考虑过几种方案：简单的积分制、日历连续打卡制、星级评价制。最后选等级制，核心源于一个很直觉的观察——游戏行业已经把“成长反馈”这件事研究得最透了。

等级制和积分表最大的区别在于，积分是线性的、枯燥的；而等级是台阶式的，每一级都是一个阶段性里程碑。升到9级(3/10)给人的感受，和“你累计积了7350分”完全不一样。前者的脑子会告诉你“我马上要跨过一个重要节点了”，后者只会告诉你“数字又变大了”。而且等级会带来隐藏的心流效应：当经验条接近满格时，人会不由自主地多做一点点任务、想把最后那点经验补齐。

这种“升级驱动”的效应，恰恰是单靠计划表完全无法产生的。

1.3 从1级到9级：系统本身的成长脉络

这套系统并不是一开始就长得像现在这么完整的。如果追溯版本，它的成长脉络大概分成三个阶段。

1级到3级阶段，系统里只有最基础的任务登记和手动加经验，说白了就是一个电子表格套了个网页壳。我从实际使用中很快发现，手动加经验这件事太依赖自律，加了几天就会忘。

4级到6级阶段，加上了任务模板和“一键完成自动结算经验”的机制，使用成本大幅下降。这个阶段开始，主人才真正养成每天打开看一眼的习惯。

7级到现在，系统已经支持主线任务、日常任务、成就任务三种任务类型，还能自动统计补级和溢出经验。当前显示“9级(3/10)”就是这一版在跑的进度。

2. 升级公式与数据模型：背后这些机制才是核心

2.1 经验值怎么算：升级曲线设计的两种思路

等级系统看起来简单，但背后最关键的，其实是“升一级到底需要多少经验”。我在设计升级公式时对比了两种方案：线性曲线和递增曲线。

线性曲线，比如每级都是固定1000经验，优点是计算简单，但缺点是前期会让玩家吃亏，后期极度枯燥。你想，如果第1级就要打1000经验才能升，对“小白”来说门槛太高；如果到了第20级还是1000经验就能升，又完全体现不出成长的重量感。

所以最终采用了递增曲线。计算公式如下：

exp_needed = level * level * 50 + 100

这个公式的好处在于，每一级所需经验的增量是缓慢上升的，等级越高升级越难，但在前期不会卡得太狠。我实际验证过前10级的数据：

可以明显看出来，前三级几乎是给新人“送温暖”的，让小白能快速感受到升级的快乐；而从7级开始，每一级需要的经验就开始变得有点分量了。这个设计不是随便拍脑袋定的。我参考了大部分RPG游戏的数值节奏：前期升级快让人入坑，中期逐渐拉高难度让人保持专注，后期靠成就感和级别本身撑住动力。

2.2 当前进度“9级(3/10)”是怎么算出来的

标题里的“9级(3/10)”不是随便写的，它对应一套精确的进度表示法。括号里的分母10，是把当前等级升到下一级所需的经验等分成10份；分子3，代表已经积攒的份数。

结合上面的公式，9级升10级需要4150经验。3/10表示目前已经积累了其中30%的经验，也就是约1245点。在界面上，它会被渲染成一个从左到右填充的经验条，并在旁边标注精确数值：

<p>当前：{{ user.level }} 级</p> <p>经验：{{ user.current_exp }} / {{ exp_needed_for_next_level }}</p> <div class="exp-bar"> <div class="exp-fill" style="width: {{ progress_percent }}%;"></div> </div>

这里有一个很容易被忽略的细节：如果用进度条展示，“3/10”这样一个只有一维的表达，会被自然转化成“目前还差70%才升级”的心理预期，让人把注意力放在“还差多少”，而不是“已经得了多少”——这正是游戏化设计中应用很广的“流失规避”技巧。

2.3 数据表结构：用户、任务、经验记录怎么拆

系统后端我用的是Python Flask加SQLite，数据量不大，但表结构划分很重要。一共三张核心表：玩家表、任务表、经验记录表。

CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT NOT NULL UNIQUE, level INTEGER DEFAULT 1, current_exp INTEGER DEFAULT 0, total_exp INTEGER DEFAULT 0, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE tasks ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, description TEXT, task_type TEXT NOT NULL, -- 'main' 主线, 'daily' 日常, 'achievement' 成就 exp_reward INTEGER NOT NULL, is_completed BOOLEAN DEFAULT 0, completed_at TIMESTAMP, user_id INTEGER ); CREATE TABLE exp_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER, task_id INTEGER, exp_amount INTEGER, earned_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

tasks表和exp_records表看起来有重复，但实际分工完全不同。tasks表描述的是“有哪些任务可以做”，它的is_completed字段标记完成状态；exp_records表记录的是“经验值什么时候因为哪个任务到账的”，它是一份流水账。

之所以要把流水单独拆出来，是为了排查问题。比如某一天经验突然不对，我只需要查exp_records就能还原出当时的加减记录，而不需要去改任务主表的数据。这也是我在实际运行中经验值对不上账之后才补上的设计，刚开始偷懒没拆分，后来踩了坑。

3. 实操过程与代码实现：从空白到可运行

3.1 环境准备与项目初始化

这部分直接给结论，跑通这套项目需要的东西并不多。我用的环境是Python 3.10、Flask 2.3、SQLite3，前端直接用Jinja2模板加一点原生的CSS。如果读者想在自己的机器上复现，可以按下面步骤来。

mkdir xiaobai-level-system cd xiaobai-level-system python -m venv venv source venv/bin/activate # Windows系统执行 venv\Scripts\activate pip install flask

数据库不需要单独安装，Python自带的sqlite3模块就够用。项目结构按功能拆成四个文件，对小白非常友好：

xiaobai-level-system/ ├── app.py # 主入口，路由和业务逻辑 ├── models.py # 数据表和数据库操作封装 ├── templates/ │ └── index.html # 前端页面 ├── static/ │ └── style.css # 页面样式 └── task_seed.py # 初始化任务模板数据

我说实话，一开始没必要把项目拆太细，拆成模块是为了后续加功能时好维护，整套系统就这么大的数据量，单文件也完全能跑。用Flask的原因就一个：生态成熟、资料多，哪怕你之前只接触过一点Python，遇到报错也能很快搜索到答案。

3.2 核心代码：等级计算与任务提交

等级计算是整个系统里最核心的模块。我先把升级判断逻辑封装成一个函数，放在models.py里：

def exp_needed_for_level(level): return level * level * 50 + 100 def add_exp(user_id, task_id, exp_amount): # 给指定用户加经验，并处理连升多级的情况 conn = get_db() cur = conn.cursor() # 1. 更新当前经验 cur.execute( "UPDATE users SET current_exp = current_exp + ? WHERE id = ?", (exp_amount, user_id) ) # 2. 检查是否可以升级，注意这里用循环，处理一次加经验跨多级的情况 while True: row = cur.execute( "SELECT level, current_exp FROM users WHERE id = ?", (user_id,) ).fetchone() level, current_exp = row need = exp_needed_for_level(level) if current_exp < need: break remaining_exp = current_exp - need cur.execute( "UPDATE users SET level = level + 1, current_exp = ? WHERE id = ?", (remaining_exp, user_id) ) # 记录升级日志 cur.execute( "INSERT INTO exp_records (user_id, task_id, exp_amount) VALUES (?, ?, ?)", (user_id, task_id, -need) # 这里用负数代表扣除升级所需经验 ) # 3. 记录经验流水 cur.execute( "INSERT INTO exp_records (user_id, task_id, exp_amount) VALUES (?, ?, ?)", (user_id, task_id, exp_amount) ) conn.commit() conn.close()

这段代码里最值得留意的是while循环。很多人第一次写的时候会下意识用if，但实际使用中完全可能出现一个任务大量经验、一口气从9级冲到11级的情况。if只判断一次，会漏掉连升多级后的二次升级判断。我第一次写就是因为用了if，导致用户从8级升到10级时，系统只给升了一级，经验还凭空消失了一大截。用while之后才彻底解决。

任务提交的逻辑比较简单，在app.py里加一个路由：

@app.route("/tasks/<int:task_id>/complete", methods=["POST"]) def complete_task(task_id): # 防止任务被重复提交 conn = get_db() cur = conn.cursor() row = cur.execute( "SELECT is_completed FROM tasks WHERE id = ?", (task_id,) ).fetchone() if row is None: return "任务不存在", 404 if row[0] == 1: return "该任务已经完成", 400 # 获取任务奖励经验 task = cur.execute( "SELECT exp_reward, title FROM tasks WHERE id = ?", (task_id,) ).fetchone() # 更新任务状态 cur.execute( "UPDATE tasks SET is_completed = 1, completed_at = datetime('now') WHERE id = ?", (task_id,) ) # 给玩家加经验 add_exp(current_user_id, task_id, task[0]) conn.commit() conn.close() return "任务完成，经验 +{}".format(task[0])

3.3 任务模板的初始化数据

task_seed.py里有整套系统最初的任务清单。这部分数据不是锁死的，是我经过两轮调整后沉淀下来的。主要分三类：

主线任务对应完整的课程学习模块，是升级的主干道。日常任务每天刷新，适合碎片时间完成，奖励经验虽然不多，但能帮玩家保持手感。成就任务是隐藏的惊喜，比如“连续一周完成日常任务”，这类任务的奖励经验最高，但难度也大。

这里要重点说明经验数值的配比逻辑。主线任务是“升级的主要经验来源”，所以单次奖励定在200-300；日常任务是为了保持在线活跃度，奖励太低没动力，太高又会让主线失去意义，所以压在100-150。成就任务则是用来制造“惊喜感”，800经验瞬间到账，能大幅度拉高玩家的情绪峰值。

3.4 前端页面：等级卡片的渲染

整个前端只有一个页面，核心就是那张等级卡片。我刻意没有做复杂的仪表盘，因为对使用者来说，最需要的信息就三个：当前等级、经验条进度、还差多少升级。

<div class="player-card"> <div class="player-avatar"> <span>{{ user.level }}</span> </div> <h2>{{ user.username }}</h2> <p class="level-text">当前等级</p> <h3>Lv.{{ user.level }}</h3> <div class="exp-label"> <span>{{ user.current_exp }}</span> <span>/</span> <span>{{ exp_needed }}</span> </div> <div class="bar"> <div class="bar-fill" style="width: {{ percent }}%;"></div> </div> <p class="tip">距离升到下一级还差 {{ remain_exp }} 经验</p> </div>

进度条的高宽比、颜色过渡、底部提示文字，这些细节都被我和“小白用户”反复调整过。最初进度条是纯蓝色的，后来发现视觉疲劳太快；改成绿色渐变加尾端发光效果后，每次看到进度条推进都稍微有点小兴奋。别看这些是小事，游戏化产品的反馈强度往往就决定于这类视觉机场。

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

4.1 经验值溢出与连续升级：最容易写错的地方

有人可能觉得加经验有什么可写的，做加法谁都会。但真正跑起来之后你会发现，一次性加800经验直接导致跨两级的情况特别常见。如果你在代码里用if判断一次升级，那么剩余经验会丢失，累计经验也可能和真实数字对不上。

我遇到的一次典型问题是：等级8才攒了2000经验，突然完成了一个800经验的成就任务，理论上应该连升两级到达9级并剩余不少经验，但代码只升到8级就把经验清零了。从那以后我在add_exp函数里强制用while循环，并且专门加了一条升级日志，经验扣除也写在流水里，方便事后核查。

4.2 任务重复提交与防刷机制

因为这套系统给的是正向激励，没有惩罚机制，“刷经验”就成了设计上必须考虑的问题。日常任务是每天一次，如果我在前端加一个“完成”按钮就不管了，用户疯狂点刷新就会重复领取奖励。

防刷方案用了两层：第一层是前端控制，任务完成后立即禁用按钮，并提示“今日已完成”；第二层是后端兜底，检查tasks表的is_completed字段，如果已经是1就不再添加经验。后端校验才是真正的防线，前端控制只是为了提升用户体验。想绕过前端直接向接口发请求，后端的拦截逻辑会确保数据不会出错。

4.3 数据备份：SQLite文件的定时拷贝

SQLite的优点是很轻量，一个文件搞定所有数据，但缺点也很明显：如果用户把项目部署在一台普通电脑上，硬盘坏了数据就全没了。我对这套系统的备份策略是写了一个极其简单的shell脚本，每天用cron定时把数据库文件拷贝到另一块磁盘上。

#!/bin/bash cp /path/to/xiaobai-level-system/data.db /backup/data_$(date +%Y%m%d).db find /backup -name "*.db" -mtime +7 -exec rm {} \;

备份策略并不复杂，但足以应对大部分意外。数据库文件本身没多大，保存最近七日的备份也占不了多少存储。一次意外断电导致数据库损坏后，我就把这个脚本的优先级提到了最高。

4.4 使用的节奏：等级越高越需要重新设计任务

还有一个偏心态层面的问题想聊聊。目前到了“9级(3/10)”这个进度，我发现原有任务模板开始不够用了。因为随着技术内容深入，单个任务的学习时长变长了，但经验奖励还是固定的。如果继续按旧模板执行，会出现一种“卡等级”的体验：投入的时间明显变多，经验条却走得无比缓慢，挫败感直线上升。

这时候需要重新调整任务经验配比和任务类型。我目前的做法是把主线任务拆得更细：以前“学完变量视频”一个任务给300经验，现在拆成“看视频+做笔记+自己写案例”三个任务，总经验变成500。这相当于变相调高了中高等级的成长速度，让使用者不会因为卡级而放弃。

注意：等级系统的核心是“保持玩家正反馈”，当玩家觉得升级吃力时，不要怀疑是他的问题，先检查自己的数值设计是否没跟上玩家的成长速度。

我个人的体会是，做这套系统的过程，跟学习技术本身一样，都在不断“升级”。一开始以为只是写个网页，后来才发现懂一点交互设计、懂一点任务机制、懂一点数据库防坑，样样都对体验有实打实的影响。如果你也在做类似的学习追踪工具，建议从最简版本跑起来，然后按照实际使用中的反馈一点一点加功能——这比一开始就把所有功能都想全再动手靠谱得多。这里最后一个经验：别把等级和真实的能力挂等号，等级只是学习过程的副产品，真正的收获是那个为了凑经验连续七天看笔记的自己。