有个做企业培训的朋友去年花了两万块找外包做了一个答题小程序，题库导了500道题，上线第一周同事用了两天就没人打开了。他自己试了一下才发现问题在哪：50道题做一半切出去回微信，再进来从头开始；多选题选了三个选项，提交的时候系统说"请选择正确答案"；成绩页面只显示一个分数，错了哪些题、哪个知识点薄弱完全看不出来。他问我"答题功能不就选择题判断题吗，怎么做出这么多问题"，我说答题这件事，表面看是用户选ABCD，背后至少涉及题库结构、答题状态管理、判分逻辑、防作弊、数据统计五个模块，任何一个模块考虑不周全，用户体感就是"难用"。
我自己做过两个答题类小程序，踩过的坑比做过的功能多。这篇文章把从题库设计到答题交互到防作弊的全链路拆开来讲，不管你是自己开发还是找外包，看完至少知道该盯住哪些关键点。
设计答题小程序前先搞清楚五件事
| 1 | 你的题目数据是什么结构？单选、多选、判断、填空、简答的存储方式完全不同 |
| 2 | 答题状态怎么保存？用户切后台、断网、中途退出后能不能恢复到刚才那题？ |
| 3 | 防作弊做到什么程度？切屏检测、随机出题、限制作答时间，三个维度怎么组合？ |
| 4 | 成绩怎么展示才有价值？一个分数远远不够，错题解析、知识点薄弱分析、排名对比一个不能少 |
| 5 | 你是做一次性活动还是长期运营？这个决定直接影响题库更新机制和用户激励体系的设计 |
一、题库表结构怎么设计，一开始就想清楚五种题型
很多答题小程序的问题根源不在前端，在数据库设计第一天就埋下了雷。最典型的错误是把所有题型塞进一张表里，用一个大JSON字段存选项和答案。前期确实快，但题型一多——比如从单选扩展到多选再扩展到填空题——改起代码来就是地狱。
实际项目中至少需要三张核心表：题库分类表、题目主表、答题记录表。如果有积分系统，还需要用户积分表和积分流水表。
| 表名 | 核心字段 | 设计要点 |
|---|---|---|
| category（题库分类） | id, name, parent_id, sort, status | 支持无限级分类，章节/知识点灵活组织 |
| question（题目主表） | id, category_id, type, title, options, answer, analysis, difficulty, status | type字段区分题型（1单选2多选3判断4填空5简答），options用JSON存储 |
| answer_record（答题记录） | id, user_id, exam_id, question_id, user_answer, is_correct, duration, created_at | 每题一条记录，方便做错题分析和知识点薄弱统计 |
一条经验：options字段不要存成字符串拼接（比如"A.xxx|B.xxx"），用标准JSON数组[{"key":"A","value":"选项内容"}]。前端渲染和答案比对都方便，将来如果要支持选项乱序（防作弊需求），只需要在查询时对数组shuffle即可。
二、答题交互的四种状态管理，少一种用户就想卸载
答题功能最容易被低估的部分不是出题逻辑，是答题过程中的状态保持。用户答题不是一口气做完的——接个电话、回个微信、地铁到站了关掉手机，这些场景下如果答题进度丢了，他大概率不会重新做一遍，而是直接关掉小程序。
进度持久化
用户每做完一题，立即将当前进度（做到第几题、已选答案列表、剩余时间）写入本地缓存和服务器。小程序用wx.setStorageSync做本地兜底，用后端接口做云端同步。用户重新打开时先读本地缓存，再跟服务端对比，取最新的那份。
切后台计时处理
小程序切后台时通过onHide记录时间戳，回到前台时通过onShow计算离开时长。如果是考试模式，离开超过设定阈值（比如30秒）自动提交；如果是练习模式，只做提示不做强制提交。
答题卡实时标记
在答题页面底部或侧边栏放一个答题卡入口，用色块标记每道题的状态：绿色=已答、白色=未答、橙色=标记（用户觉得不确定想回头检查的）。用户可以点击答题卡上的任意题号跳转，这个交互细节直接影响做大题量考试时的体验。
断网续答
用户在地铁/电梯等弱网环境答题，每次提交答案时如果网络失败，答案先存到本地队列，监听网络恢复后批量上传。小程序提供了wx.onNetworkStatusChange接口，结合本地队列可以做到用户无感知的断网恢复。
这四个状态管理场景看起来都是细节，但每个都对应着用户流失的关键节点。进度丢了→用户不做了；切后台被强制交卷→用户觉得不合理；不知道哪些题没答→大题库里找不到北；断网丢答案→白做了。一个都不能少。
三、防作弊不是做得越多越好，不同场景选不同力度
防作弊是最容易"用力过猛"的模块。一个企业内部的培训答题，搞人脸识别加双机位监控，同事会觉得你在侵犯隐私；一个知识竞赛活动，只做了题目乱序没有限制切屏，前三名全是切出去百度搜答案的。关键在于根据场景选择防作弊力度。
| 场景 | 推荐防作弊方案 | 用户体感 |
|---|---|---|
| 企业内部培训考核 | 题目乱序 + 选项乱序 + 限时作答 + 切屏3次自动交卷 | 适中，员工能接受 |
| 知识竞赛/有奖活动 | 题目乱序 + 选项乱序 + 切屏禁止 + 每题限时 + 随机题库 | 严格，竞赛公平优先 |
| 学生学习/刷题练习 | 题目乱序即可，不做切屏限制 | 宽松，学习场景允许查资料 |
| 正式认证考试 | 人脸识别 + 切屏禁止 + 全程录屏 + 题目选项全乱序 + IP限制 | 严格，等同于正式考试 |
容易忽略的细节：选项乱序和题目乱序要在服务端做，不能在前端做。如果前端shuffle后传给后端校验，作弊者可以通过抓包看到原始题目顺序。正确做法是服务端生成随机种子，前端按种子渲染，提交时带种子值，服务端用同一种子还原正确答案进行比对。
四、判分逻辑比你想象的复杂，多选和填空是重灾区
单选和判断的判分很简单，用户答案和正确答案字符串比对就行。但多选和填空两个题型，判分逻辑的实现方式直接影响用户会不会来投诉。
多选题有三种判分策略，选哪一种要在产品设计阶段就定下来，写到答题规则里让用户看到：
全对得分
漏选、多选、错选均不得分。适用场景：认证考试、知识竞赛。用户投诉最多的是"我选对了三个，漏了一个就零分"。
部分得分
选对几个给几分，选错一个扣一分（不低于0）。适用场景：学习练习。用户接受度最高，但实现复杂，需要逐选项比对。
漏选得分
只要没有选错选项，漏选按比例得分。适用场景：教学测验。对考生最友好，但判分逻辑最复杂，需要比对"用户答案集合"和"正确答案集合"的差集。
填空题的坑更大。用户填"北京"和"北京市"算不算对？填"GDP"和"国内生产总值"算不算对？答案里多了一个空格算不算错？这些在判分逻辑里都需要明确处理。常见做法是：
填空题判分三步处理：
· 第一步：去除首尾空格和多余空白字符
· 第二步：将用户答案和标准答案统一转为小写（如果大小写不敏感）
· 第三步：在标准答案表中设置"等价答案"字段，比如"北京"="北京市"="北京城"，任意匹配即得分
· 第四步：如果以上都不匹配，标记为"待人工复核"（适用于主观性较强的简答题）
五、成绩展示页面做对了，用户才会回来第二次
只显示一个分数"80分"的成绩页面是浪费了最好的用户触达机会。用户在成绩页面的停留时间往往比答题页面还长——他在消化结果、想知道自己哪里不行、想知道别人考了多少。成绩页面至少承载三个功能：自我认知（我哪里薄弱）、社交比较（我在什么水平）、行动引导（接下来做什么）。
知识点正确率
雷达图
按分类展示各知识点得分率，一眼看出薄弱环节
错题本入口
一键重做
错误题目自动归集，支持分类筛选和针对性重练
排行榜
实时排名
按得分+用时综合排名，激发竞争动力
答题用时分析
每题耗时
展示每道题耗时，超时题目标记，辅助分析答题节奏
排行榜不能只按得分排。同样90分，3分钟做完和15分钟做完含金量完全不同。合理的排名算法应该综合考虑得分和用时，比如：排名分 = 得分 x 0.7 + (1 - 用时/总限时) x 0.3。得分相同的情况下，用时短的人排在前面，这样更公平。
六、用户体系和激励设计，让刷题这件事不那么枯燥
答题本身是一个有门槛的行为——用户要动脑子。如果没有任何激励机制，除了考试前的学生和被迫参加培训的员工，很少有人会主动打开一个答题小程序。想让用户持续用，需要设计一套轻量但有效的激励体系。
常见的激励手段分为四类，不同场景选不同组合：
| 激励类型 | 具体方式 | 适合场景 | 开发难度 |
|---|---|---|---|
| 积分体系 | 答题得分→积分→兑换奖励（优惠券、课程、实体奖品） | 企业培训、知识付费 | 中等 |
| 排行榜 | 日榜、周榜、总榜，按得分+用时排名 | 知识竞赛、学习社区 | 低 |
| 成就徽章 | 连续答题7天、正确率超90%、答完1000题等成就解锁 | 学习刷题、个人成长 | 中等 |
| 社交裂变 | 答完题生成成绩海报→分享朋友圈→好友扫码挑战 | 活动营销、品牌推广 | 低 |
成绩海报的分享是答题小程序获客成本最低的方式之一。用户做完一套题看到自己的分数和排名，生成一张包含成绩、排名、二维码的海报分享到朋友圈——"我得了92分，超过了85%的人，你也来试试？"——这种社交传播的转化率远高于普通广告。
一个小提醒：海报上的排名数据要做模糊化处理。如果用户只超过了12%的人，海报上可以写"你已完成挑战！"而不是"你击败了12%的人"。没有人愿意分享一张让自己丢脸的成绩单。
七、出题策略：随机不等于随便，组卷有门道
出题方式决定了用户的答题体验是否公平、是否有挑战性。最简单的做法是完全随机——从题库里随机抽N道题——但这样做有两个问题：一是可能抽到难度极不均匀的题目组合（10道题全是最简单的），二是不同用户抽到的题目难度差异太大，排行榜失去比较意义。
更好的做法是按难度分层出题。比如一场考试出20道题，设定规则：简单题40%（8道）、中等题40%（8道）、困难题20%（4道），每个难度层级内部再随机抽取。这样不同用户做的题目不同，但整体难度一致，排行榜才公平。
三种组卷策略对比
| 完全随机 | 从全题库随机抽取 | 开发最简单，体验最差 | 仅适合题库很小（<50题）的轻量场景 |
| 难度分层 | 按简单/中等/困难比例抽题 | 公平性好，开发量适中 | 适合大多数考试和竞赛场景 |
| 自适应出题 | 根据前面答题表现动态调整后续题目难度 | 体验最好，开发最复杂 | 适合学习刷题，需要算法支持 |
自适应出题是体验天花板，但实现成本也最高。基本思路是：初始给一道中等难度的题→答对了下一题难度+1→答错了下一题难度-1→连续答对3道同难度题则提升基础难度等级。这种算法能让用户始终处在"有点挑战但不至于放弃"的区间，是刷题类产品留存率最高的出题方式。
八、自研还是用现成平台，先看清三种路径的代价
设计到这一步，其实已经能判断自己应该走哪条路了。目前市面上的答题小程序实现方式分三种：
| 实现方式 | 适合谁 | 成本 | 灵活性 | 周期 |
|---|---|---|---|---|
| SaaS平台（问卷家、考试云等） | 一次性活动、内部培训、不需要定制 | 低，按次或按年付费 | 低，功能固定 | 1天内上线 |
| 开源源码二次开发 | 有开发能力、需要定制功能 | 中，开发人力成本 | 高，可任意修改 | 1-3周 |
| 从零自研 | 复杂业务逻辑、高并发、需和现有系统打通 | 高，前后端+运维 | 最高 | 1-3个月 |
如果只是做一个简单的知识竞赛活动，SaaS平台足够。但如果答题是你的核心业务——比如一个在线教育产品里的题库系统、企业内部的认证考核平台——开源源码二次开发是性价比最高的选择。目前GitHub上有不少成熟的答题小程序开源项目，基础框架（登录、答题流程、成绩展示）都是现成的，你需要做的是根据自己的题型需求改造题库结构和判分逻辑。
选开源项目时的检查清单：题目表结构是否支持你的所有题型？判分逻辑是否在后端而非前端？答题进度是否有本地+云端双重持久化？是否有防作弊基础能力（切屏检测、随机出题）？代码是否还在维护（看最近一次commit日期）？这五条有一条不满足，二次开发的成本可能就超过从零写了。
回到最开始那个朋友的问题。他那个外包做的小程序，核心问题不是功能不够多，是每个模块都只做了表面——答题能选ABCD就算完了，切后台丢失进度不管，成绩就一个数字，题库导进去就再也不更新。答题小程序不是一个"选择题展示器"，它是一个从数据到交互到激励的完整系统。题库结构决定你能支持多少种题型，状态管理决定用户会不会中途流失，判分逻辑决定用户信不信你的分数，防作弊决定排行榜有没有公信力，成绩展示和激励体系决定用户会不会再来。
这五个模块，任何一个只做到60分，整体体验就是不及格。但好消息是，这些坑前人已经踩过一遍了，你要做的不是从零摸索，是把这五个模块的设计思路先想清楚，再动手写第一行代码。
