企业官网建设流程全解析

这几天朋友圈里最让我有成就感的东西，就是做完并上线了一款AI驱动的对战式刷题小程序。功能一句话可以说清楚：两个人进入同一场答题，AI实时出题、判定、解析，赢家获取积分，输家得到一份针对性的错题报告。上线第一周，靠自然裂变涨了700多个真实用户，没有花一分钱投放，全部来自对战结束后的分享、邀请回流和群聊里的二次转发。

我一直对“学习工具缺乏反馈”这件事耿耿于怀。题库类产品大家都有，题目越来越多，可用户打开之后，做完一页页选择题，对完答案就关掉，连“我错在哪、接下来该练什么”都没有感知，更别提再打开第二次的动力。所以做这个小程序时，我没有走“题库+解析”的老路，直接把核心玩法切成了一对一对战：参与对战的双方，本身就是彼此的进度条、倒计时和反馈信号。

这篇文章不打算只晒数据。我会把这个项目从设计思路、技术选型、功能实现、裂变机制，到上线一周的复盘和踩坑全部拆开讲。如果你正打算做小程序、做AI应用，或者关注教育类产品的增长逻辑，看到最后应该能少走几天弯路。

1. 为什么要做对战式刷题小程序

1.1 刷题场景的底层痛点

常规刷题工具的核心流程是：选题、作答、看解析。逻辑没有问题，但这里存在两个致命缺口：即时反馈的密度太低，以及学习过程中的社交缺失始终没人管。一个人默默刷题时，大脑获得的只有“对了”或者“错了”两种离散信号，而且这个信号还要在几秒后的解析翻页才出现，情绪价值被拖没了。

对战则把反馈密度直接拉满。倒计时在跑、对手进度条在跳、连击数在闪，每一个刺激都是即时出现的。我甚至不需要做任何复杂的游戏化设计，单是“你的对手已经答完5题，而你还在第3题”这一条信息，就足够让用户手心出汗。这种自然的紧张感，远比积分、勋章更有效。

另外还有一个很实际的原因：单机刷题产品没有天然的分享理由。用户觉得好，最多截个图发朋友圈，很难形成稳定的增长路径。但对战天然是双方参与的，胜负结果出来的一瞬间，无论赢家还是输家，都有极强的表达欲。我把这种表达欲做成分享卡片，就得到了一个几乎零成本的裂变入口。

1.2 AI驱动解决的是“千人千题”而不是“有题可刷”

做题库产品的都知道，自建题库的最大问题是生产速度跟不上用户消耗，而且一套静态题库往往只能覆盖有限的学习场景。我一开始也在整理题目，投入产出比实在太低，后来干脆把出题模块全部交给AI。

这里说的AI驱动，不只是用大模型去生成题目文本，而是让AI参与整个对局链路：用户进入对局前，AI根据历史作答记录和薄弱知识点生成出题策略；对局过程中，根据双方的实时正确率调整当前局难度，让双方始终保持“差一点点就赢”的胶着状态；对局结束后，AI基于错题生成解析报告，并推荐下一轮复习题。

“千人千题”的真正价值在于，每个用户的刷题行为都会产生一条独特的难度曲线，不再是一套题所有人共用。这个特性对留存的影响非常直接：第二天回访时，系统记得你上一轮的错点，这种微小的“被记住”的感受，足以把次日留存提升一截。

1.3 为什么选小程序而不是App

对战玩法非常依赖关系链。好友邀请、群内分享、榜单晒分，这些场景天然围绕社交关系展开。小程序最大的优势是分享路径极短：用户点开一张卡片，无需下载，直接进入玩法，整个转化漏斗短到几乎没有流失节点。App在这里就吃亏，真正愿意为一次对战下载一个独立应用的人非常少。

小程序也有代价：受限于包体积和渲染性能，我不能在客户端堆太多动画效果；平台的审核规则也要提前适应。但从结果看，这个选择完全正确，这700多个用户的绝大部分新增，都来自一张张分享卡片的点击回流。同样的增长曲线，放到App上很难复制出来。

2. 整体架构与技术选型

2.1 前端：原生小程序还是跨端框架

先说我踩过的坑。第一版我用了一个跨端框架来写，希望以后能同步出一套多端版本，但做到对局动画阶段就发现性能不够，列表渲染和动画会互相卡，调试起来还多一层编译问题。第二版推倒重来，改成了原生小程序开发，一个项目只维护客户端本身，所有复杂逻辑全部放服务端。

选择原生还有两个理由：一是原生小程序对分享卡片、订阅消息、页面栈这些能力的支持最直接，接口稳定，不用等框架去适配新能力；二是包体积控制更好，原生项目空包就能压到很小的体积，对局所需页面加动画，最终包体控制在1.5MB以内，审核和首屏加载都很顺利。

如果你也做此类项目，我的建议很直接：首发用原生，等验证了核心玩法再考虑跨端。多端覆盖不是第一版该考虑的问题，先把单端体验打磨到极致更重要。

2.2 后端：Serverless云函数为主

后端我直接用Serverless云函数，而不是自建服务器，理由很现实：前期用户量未知，自建服务器的最低成本也要一台云主机，还要处理运维、部署、日志，一个人做不过来。云函数按量计费，没用户的时候几乎不花钱，有用户的时候也能扛住峰值。

我把服务端按功能切成了几个独立云函数，互相之间通过云数据库流转数据：

• user：注册、登录、用户资料、积分流水；
• battle：匹配队列、对局创建、结算；
• question：AI出题、缓存、错题记录；
• share：分享参数校验、邀请关系绑定。

云函数之间的调用次数不多，但每一处都做了幂等处理。原因是对战场景很特殊，重试请求是常态，比如用户在弱网环境点击“开局”两次，如果没有幂等，系统就会创建出两场一模一样的对局，数据就脏了。

2.3 实时通信：WebSocket与轮询混用

对局过程数据链路要尽量短。我的方案是“匹配用轮询、开局后走长连接”，没有把整个系统全部压到WebSocket上。

匹配阶段不适合长连接，因为用户可能匹配30秒没对手就退出了，轮询每3秒查一次状态，实现简单，也不会产生多余的常驻连接。开局之后，双方进入同一场对局，再用长连接推送题目、计时、答案、连击和对手进度，保证延迟在几百毫秒以内。

长连接的心跳我设成30秒一次，中间如果超过40秒没收到心跳，服务端就认为对局中断，把当前用户标记为掉线，进入AI托管流程。这个机制在后面实测中帮了大忙，等排障章节我会具体讲。

2.4 AI服务接入与成本控制

AI出题模块接的是通用大模型API，这是整个项目里最不确定的成本项。我做了一整套降本策略，核心原则是“能缓存就缓存，能不用生成就不用生成”。比如同样考点、同样难度的题目，第一次生成后会缓存起来，后面对局命中缓存就直接复用，只有缓存没命中时才去请求模型。

成本上还有一个明显优化点：模型温度和最大输出长度直接拉低。出题只要求返回精简JSON，最短长度控制在200个token以内，实测成本完全可控。解析文本也不要求长篇大论，一个问题配一到三句话的解析，对用户来说信息密度刚好，对成本来说也不会爆炸。

3. 核心玩法实现拆解

3.1 三种对战模式

第一版我做了三种模式，对应不同的用户场景：

• 随机匹配：用户点击“立即开战”，系统从当前队列里给他找一个水平相近的对手；
• 好友约战：用户通过分享卡片邀请好友，双方约定同一时间开局；
• 镜像挑战：单人也能玩，系统根据你上一场的数据生成一个虚拟镜像对手，按你当时的速度和正确率答题。

镜像挑战最初只是为了补足没有好友在线时的体验，结果上线后成了使用率最高的模式，也变成了裂变的一个重要前置：很多用户先独自练两把，觉得有意思才去分享好友。

好友约定的时间不同步是最难处理的，后来我改成了“异步好友赛”：邀请方先打完，生成一张对局快照，好友收到卡片后随时应战，系统用对方的历史平均速度模拟对方作答，双方都完成后再统一结算。这个改动把好友模式的参与门槛降了一大截。

3.2 匹配与对局状态机

匹配队列我用一个带优先级的数组实现，核心思路很简单：用户进入队列时，带着自己的隐藏分和期望对战的知识点，系统优先从同知识点队列里找分差在正负30分以内的空闲用户，找不到就逐步放宽分差。直到60秒都没匹配上，就给他匹配一个虚拟镜像对手，保证任何人点了“立即开战”都不会空等。

对局状态机有五个状态：准备中、出题中、作答中、结算中、已结束。每个状态都有超时时间，比如准备中超过10秒没有双方都就绪，系统自动把未就绪方判负；结算中超过5秒没有拉取结果，客户端主动拉一次结算接口。

状态流转全部由服务端驱动，客户端只做渲染，这样即使两端时钟不一致，也不会出现“A显示你赢了、B显示他赢了”的尴尬。

3.3 AI出题引擎的Prompt设计与防重复

出题Prompt是整套AI模块的核心。第一版我也是直接甩一句请求让模型生成，结果出来一堆超纲题目，还有重复的，后来才把Prompt结构化。我的模板大概是这样的：

请生成一道适合知识点“分式方程”的选择题，难度3级（满级5）， 要求： 1. 题目文本不超过60字，贴近初高中应用题风格； 2. 四个选项，只有一个正确答案； 3. 错误选项设置要有迷惑性，不能太离谱； 4. 返回JSON格式：{"question":"...","options":["A.x=1","B.x=2","C.x=3","D.x=4"],"answer":"B","analysis":"...","difficulty":3}； 5. 不要解释，只输出JSON，不要输出多余字符。

关键在于结构化输出和难度收敛。没有“只输出JSON”这个约束时，模型经常在答案后面补一段废话，解析JSON会报错，出题失败率一度到15%。加了约束后，失败率直接降到2%以下。

防重复用的是组合键缓存，键由“知识点+难度+题型”组成，每个键下面存最近生成的几题，优先从缓存里取，缓存命中率大约三成。加上缓存后，用户体验好了一大截，不会出现一局里连续遇到同一道“鸡兔同笼”。

3.4 胜负判定与分值计算

对局采用10题制，谁先完成并获得更高总分谁赢。总分不只看正确率，我的公式是：

最终得分 = 正确题数 x 10 + 平均单题用时得分（满分30） + 最强连击加成（满分10）

平均单题用时得分用的是分段函数：单题用时在0到5秒内拿满分，5到10秒拿一半，10秒以上只拿一点基础分。连击加成是连续答对时累计的，连续5题加2分，连续10题加10分。这样设计的目的很明确：避免一味求快乱点，保证一定正确率的同时，让做题过程时刻保持紧张感。

结算时服务端会校验两端上报的答案，以服务端收到的第一个有效答案为准，防止弱网下的重复提交把数据打乱。每一道题从展示到提交，服务端都记录完整的时间戳，复盘的时候能精确看到用户在哪道题上卡了多久。

3.5 错题复习与AI弱项分析

对局结束后的报告页是第二屏，也是我认为AI驱动体现最完整的地方。系统会把本局错题按知识点聚合成一个“弱项图谱”，并用一句话告诉用户：“你在这局里暴露的问题是熟练度不足，建议优先练习分式方程。”这句话不是固定文案，是AI根据错题分布实时生成的。

我还做了一个简单的间隔复习逻辑：被标记为错题的题目，会在24小时后、3天后、7天后各出现一次到错题本里。配合订阅消息提醒，用户回访时直接进入复习局。这块功能开发量不大，但对留存的影响非常明显，也是我在复盘数据时才意识到的。

4. 自然裂变是怎么设计出来的

4.1 裂变载体：对战结束页

对战结束那一帧的流量价值最高，胜负落定，情绪到达顶点，这时候放任何分享引导，都比常规页面的转化率高。我做了两套分享入口：

• 赢家看到的是“邀人再战”，海报文案自带一种“我赢了，来挑战我”的微妙骄傲；
• 输家看到的是“找好友复仇”，落败不甘的情绪直接被转化成一个分享动作。

实际数据里，输家分享率反而比赢家高了一些，因为“复仇”的叙述比“炫耀”更让人有行动冲动。这个结论和很多增长文章说“越炫耀越有分享率”是反的。所以我在做增长的时候始终坚持一个原则：用自己产品里的真实用户行为定策略，不盲目照搬外部方法。

4.2 分享卡片与标题策略

分享卡片的关键是参数如何设计。我用了两层参数：第一层是分享者的用户ID和来源标识，第二层是场景参数，记录“这个用户是从复仇、邀战、还是好友赛卡片点进来的”。回流页根据参数渲染不同的引导文案，比如从“复仇”卡片进来的人，落地页文案就渲染成“帮你的好友出这口气”，然后直接进入对局匹配。

标题我也做过两组对照。第一版中规中矩写“来和我来一局AI刷题对战”，第二版改成“有人刚刚击败了我，不服来战”，同一周内第二版的点击率高了近一倍。标题的秘诀就是破坏性名词和场景悬念，不要讲产品功能，要讲用户之间的情绪。

4.3 邀请奖励设计与风控

奖励我做得比较克制：双方各获得一次“复活卡”，可以在对局里做错题后多一次重答机会。为什么不直接送积分？因为积分会稀释排行榜的含金量，而复活卡是和玩法直接绑定的稀缺道具，对这场对战有效，用户能立刻感知到它的价值。

不过奖励一上来，刷量问题马上就会出现。我做了三道防线：同一个用户每天最多只能获得3张复活卡，多出的分享不计数；分享回流必须携带有效签名，服务端会校验分享者和接收者不能是同一设备或同一IP；邀请关系绑定后，接收者必须完成至少一场真实对局，邀请才生效。这三道防线基本堵住了绝大多数脚本刷量，运营数据也没有出现异常跳增。

4.4 留存补位：群排行与周目标

裂变只能解决新增，不能解决回访。我在第三周加了个轻量的群排行机制，用户可以把对局结果的最高分发到群里，群内成员点击卡片就能看到一个小型排行榜，排行数据只保存在本地缓存，不需要注册登录。这个设计没有任何复杂的社交关系链，却让群活跃用户每天至少被吸引回来一次。

周目标则是另一种心理抓手：系统每周生成一张“本周学习情报”，统计你完成了多少局、正确率变化、强项弱项分布，用户想看完整版就必须回到小程序里。这种定时回访的钩子对7日留存帮助明显，从第7天的后台数据看，当天回访用户里超过四分之一是因为想看周报告进来的。

4.5 粗算700用户的裂变模型

700多个用户听起来不多，但这是零投放的自然增长，拆开看就有参考价值。上线一周后台数字大约是：累计注册用户713人，其中直接分享带来的新用户约420人，自然搜索和其他渠道来的约190人，其余是测试和杂项来源。

我把对战分享漏斗拉出来算过一次：每天活跃对局数大约50到60局，每局结束后分享率约30%，也就是每天产生约18个分享卡片；卡片点击率约15%，每天约有2.7个人点开；点开后注册转化率约30%，也就是每天不到1个新用户。

单看这个链路很低，真正撑起新增的是群聊里卡片被多次转发的乘数效应——一个卡片被转发三次，就等于多两次曝光，而群场景里的转发率远高于单聊。如果只按单聊链路算，7天到不了400个新用户，所以群内二次转发才是自然裂变里真正的放大器。

5. 上线一周的真实数据与复盘

5.1 发布前要做的事

上线前我踩了不少审核和配置的坑。首先是小程序的类目选择：做学习对战类内容，平台更希望走教育类目，但教育类目往往需要对应的资质证件。第一版没有资质，我先选了学习效率工具类目，功能描述里尽量不提“课程”“培训”，只描述为“趣味学习对战工具”，这让我顺利过了审核。

上线前还要准备好的是隐私政策、用户协议，以及域名配置。AI出题需要网络请求，所有请求域名都要在后台配置白名单并校验HTTPS证书。我在这一步耗费了几乎一整天，因为漏配了AI解析接口的域名，导致真机预览时所有解析内容都拉不到。

5.2 一周增长数据全景

我把每天的核心数据列了一张表，方便对照：

第1天到第2天的增幅并不快，真正涨起来是从第3天在群聊里开始出现转发开始的。周末两天是明显的增长高峰，说明碎片时间和对战的组合对目标用户尤其有效。

次日留存是35%，7日留存18%，对一款没有资产沉淀的新工具来说，这个数据能看但还谈不上好，所以我后续的迭代重心一直在往“错题资产沉淀”方向走，只有用户在小程序里积累了错题本，才会有持续回来的理由。

5.3 用户反馈驱动的三处改动

上线第一周我在对局结束页放了一个轻量反馈入口，收到的最多意见集中在三处：

第一是难度不适应。新用户进来前几局经常被老用户碾压，挫败感很强。我加了新手保护期，前5局只匹配同样新注册的用户，或者匹配镜像，这个改动让前三局的弃局率下降了近一半。

第二是题目类型不够。初期只有数学题，反馈要求增加语文、英语的占比很高。于是题库模块加上了多学科出题策略，AI按照用户选择的知识点池生成对应题目。

第三是加载慢。匹配等待超过5秒时没有提示。我在匹配页面加了一个动态文案“正在为你寻找对手”，并允许直接点“先打镜像”，这个小的交互修复把匹配页的退出率拉回正常水平。

这些改动全部在两周内完成，每次修改的版本号都控制在小版本内，不触及核心对局逻辑，避免引入新的回归问题。

6. 常见问题与排查实录

6.1 卡在审核的两种情形

审核卡壳最常见的就是类目和资质问题。第二次提审时，我在分享卡片文案里用了类似“史上最强”这种字眼，直接被驳回。修正后我把分享文案里所有绝对化用语全部替换成中性或情境化的表达，比如“你的好友刚刚完成了一场轻松胜利，你确定不来看看？”这类文案，就再也没有因为广告用语问题被卡过。

另一个坑是审核人员可能会认为AI生成内容不可控，存在误导风险。我在隐私政策里明确写了“AI生成内容仅作为学习参考，以最终展示解析为准”，并且后台把AI出题结果做了关键词过滤，把风险直接降到最低。

6.2 云函数冷启动导致开局超时

周末流量上来后，最典型的问题是云函数冷启动。新用户的AI出题请求打到尚未预热的云函数上，函数要完成初始化再执行，首屏等待时间一度超过4秒，在对局场景里几乎等于直接劝退用户。

我做了两件事：第一，给核心云函数配置了定时预热的定时触发器，每隔5分钟发一次空请求，让常驻实例的数量保持在一个稳定值；第二，把出题请求改成先取缓存、缓存为空再回源生成，回源失败时返回一道本地静态题兜底，保证任何情况下都能开局。这套“兜底题”逻辑上线后，出题接口的请求失败率直接降到接近零。

6.3 对局中途掉线，状态不同步

对局里最麻烦的是用户切后台超过30秒，长连接断连后产生状态不同步。比如A已经答完第6题，B还停留在第3题，如果直接给双方结算，B会觉得莫名其妙输了。我引入了两个机制来解决：

断线重连：用户回到前台，立即尝试重新建立连接，服务端根据对局ID把当前状态完整推给客户端，包括题号、双方答题情况、剩余时间。

托管逻辑：断线超过40秒仍未回来，服务端启动AI托管，用他历史答题速度的估计值自动作答，并且在结算页标注“本局部分内容由托管完成”，这样输了也不会造成“网络坑了我”的负面情绪。

这两个机制上线之后，因为掉线产生的负面反馈几乎消失，用户对对局公平性的信任也明显提升。

6.4 并发竞态导致同一题重复推送

数据量大了之后还出现过一种偶发问题：两个用户同场对局，服务端在极短间隔内把同一道题推送了两次，客户端渲染出上下两道一样的题目，用户不知道点哪道，导致答题记录混乱。排查发现是出题缓存写入的并发竞态：两个请求同时发现缓存未命中，就同时往缓存里写，写完后同时弹出。

修复方法是给缓存写入加了一个分布式锁，同一个知识点同一难度的请求只让一个进程去执行生成逻辑，其余请求直接等待并读取写入结果。这个修复很小，但对局引擎的稳定性提升却非常明显，对局中途报错率从3%降到了0.4%以下。

6.5 成本与算力控制实测

最后说一下很多人关心的成本。一周跑下来，AI出题接口的总调用次数不到3000次，平均每次的token成本按公开价格粗算约0.01元左右，一周的开销大概在30元上下，加上Serverless资源费用，整体成本在50元以内。这个数字远低于我之前担心的水平，原因是缓存命中率做到了三成，而且我严格控制了出题Prompt的输出长度和温度参数，没有让模型生成多余的内容。

当然成本的控制是动态的，如果后续日活跃到几千人，缓存策略和配额都要重新设计。我个人目前的做法是把出题模块单独拆出来，加了一个熔断开关，当某个时间段的调用量超过预算阈值时自动切换到静态题库，优先保证体验，再谈成本收敛。

最后聊一点个人体会。700这个数字单独看并不惊艳，但它让我确认了一件事：教育工具的增长不一定靠投流，也可以通过玩法机制让用户自己成为传播节点。AI在里面的角色是降低内容生产成本、提升体验反馈密度，而裂变的核心永远是产品本身的情绪钩子，和AI没有直接关系。如果你正在做类似产品，我建议先把分享链路的数据埋点做全，再去追求AI出题的准确率——前者教你的增长方法论，比后者更能决定产品能不能活过第一周。