企业官网建设流程全解析

做完整的美剧，好不好 powered by content 你被拉进了一个从零开始做APP的小团队，最缺的既不是钱也不是技术，而是一份“到底要做什么”的共识。我们几个人在微信群里讨论了三个晚上，最后敲定用一个很小的切口来试错：把大家最熟悉的英语背单词App做出来。听起来毫无新意对吧？但真正动手时才发现，团队成员对“单词打卡”这四个字的理解，差了十万八千里。

有人理解的是“每日10个单词的推送提醒”，有人理解的是“像抖音一样刷卡片背单词”，还有人理解的是“打开就有词书，先测词汇量再安排任务”。如果一开始没有把产品边界和流程定清楚，写出来的代码就是各写各的，最后拼在一起要么没人用，要么没法用。这篇就是我顺着这套思路，把一次从零开发背单词App的完整流程走下来，从产品定义、竞品分析、功能设计、数据库结构、接口设计、客户端界面、再到测试上线的每一步实操记录。

1. 从一句话需求到可执行的产品定义

1.1 团队共识Phase：先回答“谁在用，为什么用，什么时候用”

一开始我们差点直接打开编辑器开始写页面，好在有人按住了所有人：先别急，先把目标用户画像写出来，每人写3条关键词。最后所有人的答案里出现了这样几个关键词：备考学生、通勤人群、碎片时间、坚持、遗忘曲线、打卡。这些词本身就是产品的核心线索。

于是我们把产品定义锁在三句话上：

• 目标用户：每天有10到20分钟碎片时间，需要背单词并且有考试或提升英语需求的人；
• 核心价值：让用户“在有限时间里记住更多单词”，通过记忆曲线安排复习，让他们感觉到“记得住”；
• 使用场景：地铁上、午休前、睡前，短平快地完成一次学习任务。

经过讨论，决定第一版的核心功能只保留三个：每日学习任务、按记忆曲线安排的复习提醒、以及打卡记录。这样砍到只剩必需品之后，开发范围变得非常清晰。

1.2 竞品分析不是看热闹，是找“用户吐槽点”

做产品最怕的是“我觉得用户需要”，所以我们在动手设计数据库之前，花了一个晚上看了市面上常见的背单词App下面的差评和吐槽，整理出高频问题：

• 提醒太粗暴：每天固定时间推送，但用户可能完全没有时间点；
• 复习策略不透明：用户不知道为什么某个单词会在某天再次出现；
• 打卡很重：断签一天就“清零”，给人挫败感而不是动力。

综合这些痛点之后，我们决定做一个宽松但连贯的机制：打卡连续7天可以补签一次，但补签的机会最多累积3次。这个设计既保留了打卡的仪式感，也不会因为一次断了就彻底放弃，这为后续的功能设计打下了基础。

2. 功能拆分与用户任务流设计

2.1 最重要的三个页面和它们要解决的事

第一版功能砍到最后只剩三个页面：学习首页、单词卡片页、学习统计页。首页解决“今天该学什么”，卡片页解决“怎么学”，统计页解决“学了之后有什么反馈”。

为了让任务流不走偏，我们画了一个很笨但有效的图：用户打开App之后，从首页点击“开始学习”，进入一组单词卡片，每个卡片可操作“认识”与“不认识”，最后完成一组学习后，显示今日学习结果，并更新打卡状态。一旦把这个流程写清楚，后端接口的url也就基本定了。

2.2 记忆曲线的最小实现方案

关于记忆曲线的实现，我们并没有一开始就上复杂的SM-2算法，因为团队里没人有过实践基础。我们采用的方案是简化版：

• 每个单词的状态分0、1、2三级；
• 状态0：从未学过，出现在“新词区”；
• 状态1：学习过但最近答错或迟迟没有复习，进入“待复习”；
• 状态2：连续答对3次，进入“熟词区”，复习间隔拉到7天。

这个状态机和间隔逻辑虽然简单，但对第一版来说完全够用。它至少在产品层面做到了“有的单词会回来找你”，而不是学一轮就再也不见。

2.3 打卡机制的灵活设计

打卡如果做成绝对连续，用户断一天就崩溃。所以我们把它拆成两个维度：累计天数和连续天数。连续天数用于展示和激励，累计天数用于学习统计。补签不是没代价的，使用“补签卡”道具，而补签卡可以通过连续打卡7天获得。这个设计让用户有掌控感。

3. 数据库表设计与后端接口规划

3.1 Word表：所有数据的源头

无论是词书还是学习记录，核心表就是单词表。字段设计如下：

• id：单词唯一编号；
• headword：单词本身；
• phonetic：音标；
• definition：中文释义，JSON结构，支持一意多译；
• example_sentence：例句，带中英文；
• tag：词书标签（如“四级核心”、“雅思高频”）；
• created_at：入库时间戳。

当时我们唯一纠结的点是：是否需要把每个单词的释义拆成一行一条。后来仔细讨论发现，如果拆行，后续查询例句和释义就要多表join，逻辑复杂很多。最终采用“JSON字符串”存释义，查询直接返回解析，代码简单，第一版完全够用。

3.2 学习记录表：记录每个用户、每个单词的学习轨迹

这是整个系统状态机的核心表。字段设计：

• user_id：用户ID；
• word_id：单词ID；
• status：单词状态（0新词，1学习中，2熟词）；
• wrong_count：答错次数；
• review_count：复习次数；
• last_review_date：上次复习日期；
• next_review_date：下次复习日期；
• updated_at：更新时间。

关键操作是“认识”和“不认识”两个动作。认识的状态变化是status加1，不认识则status降为0，并累计wrong_count，同时重置last_review_date。这样一个简单的状态机，在后端实现时就非常直接：一个接口，两个action。

3.3 打卡表与通知策略

打卡不需要每天定时生成，而是第一次学习动作发生时创建当天打卡记录。所以打卡表字段是：

• user_id：用户ID；
• streak_days：连续打卡天数；
• total_days：累计打卡天数；
• last_check_date：最后打卡日期；
• supplement_card_count：补签卡数量。

通知策略在服务端只是生成“今天需要复习的单词数量”，真正推送本地通知由客户端负责。这样服务端就不会陷入复杂推送任务调度里。第一版我们根本没有用远程推送，本地通知就够用了。

3.4 后端接口的最小集合

围绕上述流程，后端就只需要几个接口：

• 获取当日学习任务：/api/tasks/today
• 提交单词答对/答错结果：/api/tasks/answer
• 获取打卡信息：/api/checkin/summary
• 获取用户学习统计：/api/stats/overview

因为全部是内部App首版，我们没有做用户注册界面，直接使用设备唯一标识作为user_id，登录流程直接跳过，这大大节省了时间成本。

4. 后端逻辑实现的关键细节

4.1 今日任务的生成逻辑

这里有一个容易踩坑的点：很多人会直接写成“今天把新词表里随机选10个词给你”。但按照记忆曲线逻辑，应该是“先取due复习词，如果不够任务数量，再用新词补齐”。比如任务数量设为15个，然后按这个公式实现：

pending_review_words = get_words_by_status_and_date(user_id, today) if len(pending_review_words) < 15: need_new_words = 15 - len(pending_review_words) new_words = get_new_words(user_id, limit=need_new_words) task_words = pending_review_words + new_words else: task_words = pending_review_words[:15]

这保证了“每个人今天看到的单词是有理由的”。同时要注意：任务生成时不能把单词状态改掉，状态只应该由用户作答结果触发，否则会丢失学习信息。

4.2 答对/答错的状态流转实现

实现状态流转时我先写了一个非常直白的if-else版本，因为第一版根本不需要过度优化：

if action == "know": if current_status == 0: new_status = 1 elif current_status == 1: new_status = 2 else: new_status = 2 next_review_date = today + 2 days elif action == "dont_know": new_status = 0 wrong_count += 1 next_review_date = today + 1 day

熟词正确不升状态，但更新下次复习日期，拉开到7天后。答错直接重置为0并错题记录+1。这个逻辑在第一版中会让好学的用户看到“明明这个单词我之前会，今天又出现了”的复习安排，实际体验是非常合理的。

4.3 打卡与补签的实现细节

打卡记录不能使用任务生成时间，而应该使用提交答案的时间。因为用户可能早上打开任务，晚上才学习。打卡字段在第一次提交答案时执行以下逻辑：

• 如果last_check_date是昨天，连续天数加1，累计天数加1；
• 如果last_check_date是今天，什么都不做；
• 如果last_check_date不是昨天，连续天数重置为1，累计天数加1。

补签卡逻辑是：每连续7天额外发放1张。补签操作直接允许用户将昨天之前最近一个断档日补上。但我们做了一个保护：补签只会增加连续天数，不会反向影响累计天数。

之前我们在一套后端逻辑里遇到的问题是：用户打卡中断后，连续天数直接变0，结果整个主界面UI的激励氛围就垮了，后来加入补签卡机制才缓解这个情况。

5. 客户端UI实现与交互反馈

5.1 首页设计：一眼看清今天的任务

首页主要展示：今日任务词数、连续打卡天数、接下来最近一个复习时间。这三个信息都用数字方式展示，让用户一眼就能感知到“今天要干什么”。

首页的“开始学习”按钮是唯一的主行动按钮，颜色和位置都很突出。很多App喜欢做一个复杂的Dashboard，但首版用户需要的是“傻瓜式引导”，越少选择越好。

5.2 单词卡片的交互设计：滑动还是按钮？

单词卡片如果用左右滑动手势，好看但开发成本更高，而且误操作率高。第一版我们的方案是底部两个大按钮“认识”和“不认识”，且按钮的尺寸非常大。这看起来不酷，但极大地降低了操作门槛，同时为后续埋点提供了清晰的采集点。

卡片正面展示单词、音标、发音按钮；点“不认识”后立即翻面显示释义和例句；点“认识”则直接进入下一个词。但有一个设计细节：点“不认识”之后必须显示释义，不能直接跳过，这是为了让用户建立“错题反馈闭环”。

5.3 学习统计页：让用户有“可得成就感”

统计页不追求丰富图表，只展示两条数据：累计学习天数、累计已掌握单词数。我们为这两个数字配了一个最简单的环状进度条，从视觉上形成激励。后来这一部分还被用户主动截图分享到朋友圈，这对我们来说确实是意外之喜。

6. 测试、上线与第一轮数据反馈

6.1 小范围内测：7个人，用了4天后暴露了问题

我们找了7个不同背景的人内测，前4天数据里出现两个高频问题：

• 新用户第一天打开App，没有任何复习词，任务列表几乎全是新词，导致用户觉得“太EASY”，也会觉得内容没有个性化；
• 答错一个词之后，这个词会被放到“明天复习”，但用户当天没有任何再次强化记忆的机会，遗忘速度其实很快。

针对这两个问题，我们立即调整了策略：当天答错的词会在同一天的学习任务结束后，追加一轮“错题速记”环节，每次学习结束出现，随机复习3个错词。这一版改动虽小，但对用户留存有明显改善。

6.2 上线发布与崩溃监控

上架应用商店的版本没有加载远程配置，全部功能逻辑都打包在客户端。推送本地通知、数据持久化本地数据库，网络请求仅负责获取词书和同步学习记录。这样设计的好处是，即使服务器挂了，用户依然能学习，不会出现“服务端一崩，App全废”的窘况。

上线后我们最关注两个指标：次日留存和7日留存。第一周次日留存38%，7日留存不到10%。但观察第3周数据，次日留存稳定在45%，7日留存提升到18%。这说明调整后的错题复习和补签机制确实对用户粘性产生了正面作用。

7. 我个人的几点实操体会

7.1 小团队做App，先做单点闭环，不要做平台

如果把功能列表铺开，词库管理、社区分享、每日推荐、排行大战，每样都能做好几个月。但第一版最合理的做法就是单点闭环：用户打开App，学一组词，获得反馈，离开。这个流程越短，出bug的概率越低，也越容易验证产品假设。

7.2 记忆曲线算法不是越复杂越好

很多人一想到背单词，就觉得必须上一个高大上的AI算法。实际上，只要“复习间隔动态调整+答错降级”这个逻辑没有缺失，第一版就足够。复杂算法可以在V2版本里慢慢加，先把用户留住的App比算法完美的App重要得多。

7.3 自己用数据说话，别信感觉

过程中我自己一度认为某个功能非常刚需，直到看统计数据才发现根本没人点。很多分歧在数据面前很容易收敛。现在回头看，最大的收获不是代码写了多少，而是养成了“先定义目标，再设计功能，最后才写代码”的习惯。

这个项目做完后，我们的经验被用在了下一个更复杂的产品上，而团队成员写的第一版草稿代码也看不出太多少年感，因为每一步都考虑得非常细致。如果你也准备从零做一个App，希望这篇过程记录能帮你避开我们已经踩过的那些坑。