先说明一句，标题的关键词里有“无审查”“无限制”“无审核”这类词，我看了下跟项目本身并没什么关系，也不在我的内容范围内，直接忽略掉。我不做任何灰产向、规避审核向的所谓技巧，LiveCourse 这个方向本身足够有价值，就围绕它好好讲。
1. 为什么做 LiveCourse：自主学习场景下的真实痛点
1.1 自学者最常见的三重困境
我做 LiveCourse 之前，先花了不少时间去观察身边的“非典型学习者”：在职转行的人、准备考证的实习生、自学术科内容的高中生，甚至还有几个退休后想学编程的大哥。观察得越久，越觉得传统在线学习产品和“自学”这件事之间存在一条很深的缝。
第一重困境是内容结构太死。大部分在线课程是按“老师排好章节”来做的，一章节接着一章节，像放录像带。但真实的自学者不是这样学习的——他们今天可能只想知道“怎么用 SQL 做分组统计”，后天又要回头补“索引为什么能加快查询”。需求是碎片化、非线性、围绕问题发起的。用固定章节去应对这种需求，体验就是“我想学A，结果要先把B和C看完”。
第二重困境是反馈缺失。自学者在自己房间里对着屏幕学习，没有同桌、没有答疑老师、没有任何人在旁边说“你这条路走偏了”。很多人在一个错误的理解上卡了三四天，最后放弃了，不是因为他笨，而是因为没人能告诉他“你只是把某个概念理解反了”。
第三重困境是路径无法自适应。每个学习者的基础不一样，但课程内容对所有人一样。基础好的人被拖慢，基础差的人被拖垮。这个问题的根源在于：传统课程设计是“以内容为中心”而不是“以学习者为中心”。
1.2 LiveCourse 的核心设计目标
LiveCourse 这个项目的立意其实就一句话：做一个由 AI 驱动的、围绕学习者当前真实状态来组织内容的自主学习课堂。“Live”不是指视频直播，而是指整个学习过程是动态、实时、活的——知识会随着你的提问生成，学习路径会随着你的表现调整，答疑在对话里直接解决。
我做这个项目的时候给自己定了三个硬性目标，整个开发过程都围绕它们取舍：
- 课程内容不能是预先录好的静态视频，而应该由 AI 按学习目标动态生成，学习者可以自由选择切入点和深度。
- 学习过程中必须有一个随时可问、能结合当前课件内容回答的“AI 助教”，而不是让学习者跳出课程去另一个搜索引擎。
- 系统的推荐逻辑要做到“千人千面”：根据答题准确率、停留时长、重复学习次数等信号，动态调整接下来学什么、复习什么。
这个定位决定了整个项目的技术选型和架构方向。我不打算做一个“挂着 AI 名头的视频网站”，而是要把生成式 AI 嵌入到学习内容生产、学习过程陪伴、学习路径决策三个环节里。这条路线做完之后回头看，确实踩了不少坑，也沉淀了一些可以复用的经验，下面逐个环节拆开讲。
2. 系统架构与核心选型
2.1 整体架构：前端应用层 + AI 工作流层 + 数据层
LiveCourse 的第一版架构不算特别复杂，但分层必须清楚。我参考了 AI 应用工程的常见套路：把“和模型对话”的部分封装成工作流/服务层，不让业务代码直接满天飞地调用模型接口，否则后面想换模型、调参数、加缓存都会非常痛苦。
整个系统拆成三层：
- 应用层：负责学习者交互，包含课程学习页、AI 助教对话窗口、答题与测验模块、学习路径展示面板。这一层我用的是 React + TypeScript，主要考虑生态成熟、组件库丰富，对话流式渲染有现成方案。服务端用 Python FastAPI，因为 AI 相关的 SDK 和生态几乎都在 Python 侧，FastAPI 的异步能力也能支撑长连接。
- AI 工作流层：这一层是核心，专门处理所有涉及大模型的逻辑，包括课程大纲生成、章节课件生成、知识点问答、学习总结、推荐解释。每个能力封装成独立的 Service，Service 之间通过内部 API 或消息队列通信。这里我没有直接调用“裸模型”，而是给模型套了多轮 Prompt 模板和结构化输出解析器。
- 数据层：业务数据（用户、课程、学习记录、答题记录）放在 PostgreSQL；向量数据（课件切片、知识点、FAQ）放在向量数据库中，第一版用的 Milvus，后面也试过单机可用的 Chroma；热数据与流式中间状态用 Redis 做缓存和队列。
这里我多说一句选型原因。很多人做这类项目喜欢一上来就上微服务、K8s，但学习类产品的核心瓶颈从来不是并发量，而是内容质量和个性化效果。所以我的原则是：能在一个进程里解决的，就不拆出去；能让队列异步处理的，就不阻塞接口；能用缓存的，就别重复调模型。
2.2 模型方案：混合部署与成本权衡
模型选型是 LiveCourse 里最纠结的部分，也是我后来反复建议别人不要“一步到位”的事情。市面上有很多开源模型可以本地跑，闭源 API 的质量也足够好，但两者在 Latency、成本、上下文长度、知识时效性四个方面差异非常大。
我第一版直接把所有任务都走了一个通用大模型 API，结果成本高得吓人——尤其是课程内容生成，一次生成一章课件可能消耗几万 token，而且是高频调用。后来我把任务拆成了两类：
- 长文本生成任务：课程大纲、章节课件、学习总结、复习题生成。这类任务对单次生成质量要求高，但频率相对低，可以接受秒级延迟。我优先用质量更强的模型，但全部放到异步任务队列里执行，不阻塞用户请求。
- 高频短交互任务：AI 助教回答、知识点拆解、简单答疑。这类任务对延迟敏感，几乎每个学习动作都会触发，所以我把它们路由到延迟更低的本地部署模型，同时配合检索增强（RAG）来保证回答质量。
具体来说，文本生成主链路用的是 Claude 系列模型和本地量化后的开源模型做双路方案。同一个任务，我可以根据当天的成本预算和排队情况动态切换。很多团队喜欢只抱一家，但 AI 应用工程的现实就是：模型能力和成本之间存在动态平衡，把路由逻辑抽象出来，你才有调整空间。
部署本地模型的时候，我在一台 24GB 显存的机器上跑了量化后的 7B/14B 级开源模型，用 vLLM 做推理框架。吞吐量在并发 50 左右仍然能稳定输出，单次回复首字延迟在 800ms 到 2 秒之间。这个表现在助教场景里完全够用。
提示：如果你的场景以短文本为主，建议把 embedding 模型和对话模型分开部署。embedding 用小模型就够，对话用大模型，这样显存利用率会高出不少。
2.3 为什么把“内容生成”做成异步工作流
这是个容易忽略但很关键的架构决策。课程内容生成不是单次 Prompt 调用就能完成的——我需要先生成课程大纲，再逐章生成课件，再为每章生成测验题和扩展阅读材料。这是一条完整的生产流水线，完全同步执行的话，用户得等好几分钟。
我的处理方式是把这条流水线封装成一个异步任务：用户提交“我想学 XX”之后，系统先返回一个“课程生成中”的状态，让用户可以去浏览其他内容或者直接进入 AI 助教对话；后台任务在队列里依次跑大纲生成、章节生成、题目生成，每完成一部分就实时推送给前端，前端展示生成进度。
这样做还有一个额外的好处：万一中间某一步生成失败，我可以只重跑那一步，而不是整体重新来。这点在长内容生成场景下非常重要，后面章节里我会专门讲失败重试和内容校验。
3. 课程内容生成：从大纲到课件的完整链路
3.1 第一阶段：用“两步法”生成课程大纲，不要一步到位
这是整个 LiveCourse 里我最想分享的经验。很多人刚开始做 AI 生成课程时，习惯写一个很长的 Prompt，让模型“直接生成一门完整的课程”，结果出来的内容表面上结构齐全，实际上逻辑混乱、知识点重叠、章节之间没有递进关系。
我试了很多次之后，发现最稳的方案是两步法：先让模型生成课程的知识结构图谱，再基于图谱细化每一章的大纲和教学目标。
第一步的 Prompt 里我会要求模型只输出一个树状结构，不展开具体内容：
你是资深的课程设计师。请为以下学习目标设计课程的知识结构。 学习目标：{user_goal} 学习者基础：{learner_level} 要求： 1. 输出知识主题的层级关系，最多四级 2. 每个节点标注该知识点对应的学习目标 3. 明确哪些知识点是前置基础，哪些是核心重点，哪些是扩展内容 4. 只输出 JSON 结构，不要多余文字为什么要这样做？因为知识结构本身就包含大量信息——哪些该先讲、哪些是另一个知识点的前提、哪些可以并行学。如果让模型一上来就写章节内容，它很容易把“前提性知识”和“进阶知识”混在同一章里，学习路径就乱了。
拿到知识结构 JSON 之后，我再逐节点让它生成章节大纲，每个章节包含本节目标、前置要求、核心内容要点、自测题、推荐实践任务。这一步我还会强制要求模型为每章打上“难度标签”和“预计学习时间”，这两个字段是后面个性化推荐的重要依据。
3.2 第二阶段：逐章生成内容，并加入事实性校验
大纲完成之后，接着就是逐章生成课件内容。这里我有一个反直觉的建议：不要一次性让模型生成整章内容，而是按小节生成。
一整章内容通常超过 3000 字，一次生成很容易在中间部分开始“车轱辘话来回说”，或者前后矛盾。按小节生成的话，每段内容控制在 500-800 字，质量稳定得多，而且我可以对每个小节单独做校验和风格统一。
校验环节我做了两层。第一层是结构校验，解析模型返回的 Markdown 或 HTML，检查标题层级是否完整、代码块是否闭合、是否有空章节。第二层是内容校验，把生成的课件核心观点发送给另一个模型实例做“事实一致性检查”，让它找出“与前文矛盾”或“明显超出常识”的句子。
这两层校验会显著增加 token 开销，但对教育产品来说非常值得。AI 生成内容最大的风险不是不够精彩，而是自信地讲错。教育场景里一旦出错，学习者可能记住错误知识很久都发现不了。
3.3 课件生成的关键参数与模板
我在课件生成时用的 Prompt 结构化程度很高，核心模板大概是这个思路：
你是主讲老师，正在讲解课程《{course_name}》第{n}章「{section_title}」。 你的学生已经有以下基础：{prerequisites}。 本章学习目标：{learning_objectives} 请按照以下结构输出本节内容： 1. 本节导读（150字以内，用一个生活化例子引入） 2. 核心知识点讲解（每个知识点配一个类比、一个实际案例） 3. 常见误区提醒（列出3个初学者最容易犯的错） 4. 动手练习建议（给出一个可操作的小任务） 5. 本节小结（3-5句话总结） 要求： - 语气自然，像真人讲师授课，不要用教科书腔 - 遇到公式或代码时，必须给出可运行的完整示例 - 难度要与学习者基础匹配 - 使用 Markdown 格式输出这里值得强调的一点是：Prompt 里的角色设定和输出结构必须稳定，但每次生成的“具体内容”要有随机性。学习者如果每刷新一次页面都看到一模一样的解释，感觉很机械；但如果内容差异太大，又可能把关键概念讲偏。所以我把 temperature 设置在 0.4 左右，既能保证稳定性，又有一定的多样性。
另外，我在生成内容时加了一个很有效的技巧：让模型先“列出教学意图”，再生成正式内容。也就是先让模型回答“本节要让学生掌握什么、用什么类比、用什么例子”，然后基于这个教学意图再展开正文。实测下来，这种“先规划再写作”的方式能显著减少内容空洞的问题。
4. AI 助教与实时问答：RAG 落地实践
4.1 为什么助教要用 RAG，而不是纯靠大模型自由发挥
LiveCourse 的 AI 助教定位是“结合当前课程内容来答疑”。如果直接让大模型自由回答，它很可能给出一段通用解释——正确但没用。比如学生在学“递归”时问“这个函数为什么死循环了”，他真正需要的是结合教材里那个具体例子来排查，而不是一段递归概念科普。
所以我给助教接入了检索增强生成（RAG）架构。核心思路是：把每门课的课件、讲义、扩展阅读材料全部切片，向量化后存入知识库；学生提问时，先把问题向量化，在知识库里检索出最相关的若干片段，再把这些片段连同问题一起交给模型生成回答。
这样有几个实际好处：
- 回答有“上下文锚点”，能和当前课程内容对齐
- 模型可以明确回答“根据本课程第 3 章的介绍……”，降低模糊感
- 如果问题不在课程知识范围内，可以引导到扩展学习，而不是瞎编
4.2 知识库构建：切块策略与向量化细节
知识库构建里最容易被忽略的是切块策略。我一开始用固定长度切块，每 500 个字符切一段，结果发现很多语义完整的段落被拦腰截断，检索召回时经常只拿到半截上下文，模型回答自然就飘了。
后来我改成“滑动窗口 + 语义边界”的切法：先按段落切分，段落过长时再按句子边界二次切分，同时保留前后各 50 字符的 overlap。这样每个 chunk 都尽量保持语义完整，而 overlap 能避免关键信息恰好落在边界上被漏掉。
向量化模型我本地部署了一个 bge-m3，支持中英文混合场景，效果比第一版用的 OpenAI embedding 接口更稳定，而且没有额外 API 费用。向量检索的 top_k 我设置为 6，重排之后再取前 3 个片段喂给模型。一开始 top_k 用 3，经常出现检索不到准确片段的情况，调到 6 之后覆盖率明显提升。
检索完之后，我会在 Prompt 里明确告诉模型：“你只能基于以下课程片段回答，如果片段内容不足以回答，请直接说明。”这一步是为了压制模型的“补充性幻觉”——它总喜欢在检索结果之外再往外延伸几句，而那些延伸内容往往是最容易出错的。
4.3 会话管理与上下文裁剪
助教对话是持续交互的，意味着会积累越来越长的历史记录。大模型的上下文窗口有限，而且历史越长，单次调用的 token 成本越高、延迟越久。我试过一股脑把全部历史塞进去，结果到了第四五轮之后响应速度明显下降，第六七轮就开始报上下文超限。
我的解决方案是分级记忆：
- 最近 4 轮对话完整保留，作为精确上下文
- 更早的对话用模型生成一段 100 字内的摘要，作为压缩记忆
- 与当前课件切片相关的历史问答单独缓存，优先引用
这个方案相当于给助教加了一个“短期工作记忆 + 长期笔记”的机制，既保证多轮对话的连贯性，又控制 token 开销。实测下来，一个连续学习 30 分钟的会话，平均每轮调用 token 数量能控制在新会话的 1.5 倍以内，而不会无限膨胀。
4.4 流式输出与前端渲染
助教回答如果等模型完全生成完再返回，用户要盯着一个转圈图标等十几秒，体验非常差。我用的是 SSE（Server-Sent Events）做流式输出，模型每生成一小段文本，服务端就通过 SSE 推给前端，前端边收边渲染。这样首字返回时间能压到 1 秒左右，用户感觉就像真人在打字。
前端在渲染流式内容时要注意一个细节：模型输出的 Markdown 是“半截”状态，比如代码块可能刚输出到一半。直接扔给 Markdown 渲染器，会看到闪烁的乱码。我在前端做了延迟渲染：对代码块等特殊格式，等待收齐完整片段后再渲染；普通段落则逐句上屏。这个细节打磨到位之后，整个对话体验的流畅感会上一个台阶。
5. 个性化学习路径与推荐逻辑
5.1 学习行为数据模型：先定义“学好”这件事
个性化推荐的前提是量化学习行为。我花了很长时间设计学习行为数据模型，因为如果数据字段定义不清，后面任何推荐算法都是空中楼阁。
LiveCourse 的核心学习记录表包含这几个主要维度：
- learn_event：行为类型，包括 view（观看课件）、quiz_answer（答题）、ask_question（提问）、review（复习）、regen_request（请求重新讲解）
- content_id：关联到具体的知识点或章节
- duration_ms：在某个知识点停留的时长
- correct：答题是否正确
- self_rating：学习者自评“这个知识点我感觉理解了吗”，1-5 分
- parent_id：行为关联的父级知识点，便于做知识树级别的聚合
有了这些原始数据，我就可以定义“知识点掌握度”这个指标。它不是一个简单的正确率，而是结合了答题表现、自评分数、暴露次数、时间衰减四个因子的综合值。简单公式如下：
mastery = 基础正确率 * 0.5 + 自评分归一值 * 0.3 + 复习稳定性 * 0.2其中复习稳定性根据“该知识点在多轮复习中的正确率是否趋于 1”来计算。如果一个知识点连续三轮复习都答对了，稳定性就是满分；如果第一次对、第二次错、第三次又对，稳定性就会很低，说明掌握得还不牢固。
5.2 掌握度驱动的动态计划调整
每次学习行为发生后，后台会异步重算相关知识点的掌握度。然后推荐系统根据一套可解释的规则来调整学习路径：
- 如果当前章节掌握度低于 0.5，不推荐进入下一章，而是推荐复习当前章节，并生成针对性变式题
- 如果当前章节掌握度在 0.5-0.8 之间，推荐进入下一章，同时把当前章节加入“待复习队列”
- 如果掌握度高于 0.8，标记为“已通过”，后续复习间隔拉长，采用类似间隔重复的安排
- 如果学习者在同一个知识点上反复停留且答题表现差，系统会触发“换一种讲法”机制，用类比、图解、实物演示等不同教学策略重新讲解
这套逻辑不复杂，但非常实用。它本质上是一个“规则优先 + 模型辅助”的混合推荐系统：规则确保路径不会走偏，模型负责生成个性化的讲解内容。我的经验是，在教育场景做个性化，别一上来就上强化学习或者图神经网络，先把行为数据分析清楚，用可解释的规则跑起来，效果就已经超过绝大多数“一刀切”的在线课程了。
5.3 冷启动：新用户和新课程怎么办
冷启动是个绕不开的问题。新用户没有行为记录，怎么判断他的水平和偏好？新课程没有足够多学习数据，怎么和已有知识点关联？
LiveCourse 的做法是“轻量入学测评 + 内容相似度推荐”。新用户注册后，系统先给一份包含基础概念的快速测评，大概 8-10 道题，覆盖不同难度梯度。根据答题情况，估算出用户的知识起步水平和薄弱方向，再把这些标签写入用户画像。
对于新课程，我维护了一个知识点级的知识图谱。当一门新课进入系统时，先解析它的知识结构，把它映射到已有的图谱节点上。这样哪怕没有历史学习数据，我也能通过“这个课程包含哪些知识点，而用户在哪几个知识点上薄弱”来做出初版推荐。等到用户产生行为记录后，协同过滤和规则推荐再慢慢接管。
这里提醒一个坑：知识图谱的维护是持续活，不是建完就一劳永逸的。我每个季度会跑一次分析，把新增知识点和旧知识点之间的前后置关系做一次标注更新，否则图谱会越来越陈旧，推荐效果会逐渐衰减。
6. 工程实施中的问题排查与优化实录
6.1 生成内容质量不稳定：重复、跑题、术语不一致
做 AI 课程生成时，模型偶尔会“唐突跑题”，比如在讲 Python 装饰器时突然花了很大篇幅介绍历史背景；或者在同一门课里，前面章节把某个概念叫“函数对象”，后面突然又改成“callable”。这种术语不一致对学习者非常不友好。
我的解决方案是在课程创建流程中加入一个术语表约束。每个课程都维护一份由模型在生成大纲阶段同步产出的术语表，包含“标准术语-可选别名-定义”三列。所有后续章节的生成 Prompt 都会附上这份术语表，并要求模型强制使用标准术语。这个方法几乎零成本，但极大提升了课程内容的统一性。
对于跑题问题，我是靠“输出结构校验 + 主题相关性检查”两层机制解决的。每章内容生成完成后，后台用模型对每个小节做一次主题一致性打分，低于阈值的片段会被标记为“待重写”，自动触发重生成。
6.2 上下文体量膨胀与成本失控：从记账开始的优化
我开发过程中最大的教训之一就是：不监控 token 消耗的 AI 应用，等于在给云厂商写支票。有一段时间我没做 token 计量，月底一算，课程生成和助教对话的费用高得离谱。
后来我在 AI 工作流层加了一个统一的“token 记账中间件”，每个请求进出模型都记录 prompt_tokens、completion_tokens、模型类型、任务类型和成本估算。通过分析，我发现最大的费用来源不是助教对话，而是课程内容生成中的“重试失败任务”——一次生成失败，重新生成的成本是前一次的两倍，因为 Prompt 里包含了已生成的前文。
优化措施有几个：
- 对容易失败的长文本生成，加入自动降级逻辑：第一次用高质量大模型，失败后改为“分段生成 + 中量模型补全”
- 对重复性很高的助教问题，建立问答缓存，命中的直接返回缓存结果
- 对课程内容的相同知识点讲解，做全局内容复用，避免反复生成雷同文本
这些措施落地后，每门课程的平均生成成本下降了约 40%，助教对话成本下降了约 25%。
6.3 冷启动推荐失效：行为数据稀疏时的出路
冷启动阶段的行为数据非常稀疏，个性化推荐基本是“盲推”。我第一版直接上了协同过滤，结果推荐出来的内容非常离谱——因为用户少，相似用户几乎找不到，推荐列表退化成热门内容榜，完全没有个性化。
后来的调整思路是用“内容属性”替代“用户行为”：给每个知识点打上多维属性标签（领域、难度、抽象程度、是否偏重实操、是否偏重理论），然后根据用户测评结果和当前学习目标，用内容属性相似度做初筛。这个方案不依赖大量用户行为，单用户也能有不错的推荐效果。
等用户积累了一定行为数据（大约 15 次有效学习行为以上）后，再逐步过渡到“协同过滤 + 规则调整”的混合策略。现在系统里有了一条清晰的策略梯度，我管它叫“标签推荐 → 行为增强 → 混合优化”，每到一个阶段就解锁下一层能力，避免冷启动期强行用高级算法反而劣化体验。
6.4 流式输出的连接稳定性问题
SSE 流式输出在弱网环境下容易断连。用户在图书馆或地铁里用手机学习时，网络抖动很常见，客户端和服务器的连接一旦断开，模型还在后端生成内容，这部分内容就永久丢失了，用户会看到回答“卡住不动”。
我给流式接口加了断点续传机制：服务端在返回每个 SSE 事件时带上一个自增序列号，客户端记录已接收的最大序列号。重连时客户端把断点序列号带给服务端，服务端从缓存里找到未发送的事件，继续推送。这个机制实现不算复杂，但对移动端学习场景的体验提升非常明显。
6.5 异步任务中的模型“假死”与超时处理
异步工作流里，模型偶发“假死”——既不返回结果，也不报错，连接一直挂着。这个问题在最开始几乎每周都能碰到一次，而且特别隐蔽，因为任务队列里看不到失败，只看到任务“一直在执行中”。
解决方法是给所有模型调用加三层防护：
- 连接超时：建立连接的等待时间限制，超过即重试
- 空闲超时：模型长时间不产出任何文本，判定为异常
- 总时长超时：单次任务超过预设上限，强制标记失败并进入重试队列
重试队列还附带指数退避策略：第一次失败后 10 秒重试，第二次 30 秒，第三次 90 秒。超过三次失败的，转为人工处理标识，课程生成界面会提示用户“该课程生成遇到问题，请稍后重新尝试”。
7. 几个自己沉淀下来的实战体会
项目做到现在，体验过不同角色的切换，有一点感受比较深：AI 在教育类产品里的正确用法，不是替代老师的“讲”，而是放大学习者的“问”和“练”。LiveCourse 里效果最好的功能不是自动生成的课件，而是那个可以随时追问、并且永远耐心重讲的 AI 助教。很多学习者告诉我，他们不敢在学校里反复问同一个问题，但在 AI 助教面前可以问到彻底明白为止。
最后再分享一个我踩坑后的经验。做这类项目很容易陷入“模型越强越好”的惯性思维，但真实的学习场景里，用户要的不是“最强 AI”，而是“刚刚好的 AI + 及时的反馈 + 可靠的组织”。课程内容再漂亮，如果学习路径是乱的，用户照样会迷路；模型回答再精准，如果 UI 要等十秒才吐出一个字，用户照样会流失。
所以看我的做法，核心精力其实有一半花在了内容组织、对话管理、数据记录这些“不性感”的工程环节上。把知识图谱建好、把行为日志记录准、把生成质量校验住，AI 的价值才能真正落进自主学习这件事里。
有朋友问过我后面打算怎么扩展。方向其实挺多的：答题模块可以接入代码自动评测，让学习者在浏览器里直接写代码跑测试，AI 基于运行结果给反馈；助教可以结合语音输入，让口语化提问更方便，尤其适合通勤场景；还可以考虑引入“学习伙伴”机制，几个学习者共享一份 AI 生成的学习计划，互相打卡监督。
这些想法能不能落地，最终还是要回到学习者的真实反馈上来。做教育产品最怕自嗨，我现在每周都会拉几个真实用户聊一聊，看他们实际怎么用、卡在哪、哪里又放弃了。技术和算法永远在变，但“帮一个人真正学会一个东西”这件事的内核，始终是值得花很长时间去磨的。
