企业官网建设流程全解析

凌晨一点，我在书桌前把一本教材翻到卷了边，身边没有一个能问的人：错题看不懂、计划不知道该怎么排、复习到一半就开始走神。那段时间我一直在想，为什么不能有一个真正“懂我”的复习伙伴——不是搜索引擎，不是题库App，不是那种你问一句它答一句的聊天机器，而是一个记得住我的薄弱点、会主动催我复习、知道怎么把一道错题讲透的“搭子”。于是我用大模型API做了这样一个东西，前后花了两个晚上加一个周末，现在把完整的实现思路和踩坑记录整理出来。这篇内容适合两类人：一类是想用AI工具辅助备考的学生，另一类是打算自己做学习工具、但不知道从哪下手的开发者。

1. 为什么需要一个“复习搭子”，它到底是什么

1.1 备考场景里那些“一个人扛不动”的时刻

先说一个我观察很久的现象：很多人复习不从“不会”开始，而从“没人管”开始垮掉。一个人备考最大的问题不是智商不够，而是反馈链路太长。你今天做错的题，要到明天才能找到人问；你对自己掌握程度的判断，完全靠感觉；你排的复习计划，没有外力约束，三天就变成一张废纸。

这些问题用传统工具很难彻底解决。题库App能给你题目和答案，但它不知道你昨天卡在哪一章；通用大模型能给出漂亮的讲解，但它的记忆是瞬时的，上次对话你告诉它“英语作文跑题了”，它今天就会忘得一干二净；真人辅导效果好，但不可能每天凌晨都有老师在旁边。

所以“复习搭子”的核心定位不是比谁的知识更渊博，而是建立一个持续、有记忆、有计划的陪伴关系。它得记住你哪些知识点总错、得知道你复习到第几轮、得在你情绪低落的时调整节奏、得在第二天主动问你“昨天那道题现在会了吗”。这才叫搭子，而不是问答工具。

1.2 搭子、题库和通用聊天助手，差别在哪

我拿同事做了个测试。同样一道“说明文阅读主旨概括”的错题，分别问题库App、通用聊天助手、复习搭子，得到三种完全不同的反馈：

通用聊天助手本质上是一个“随叫随到的智者”，但它不关心你有没有真的学会。复习搭子需要做到的，是把“讲解、出题、答疑、计划、复盘、陪伴”六个环节串成一条完整的学习链路。用户做完一道题，不是终点，而是下一次复习的起点。

1.3 用场景倒推出来的六项核心能力

我在设计这个项目时没有直接去堆功能，而是先列了一个普通学生一天的复习动线：早上看今天要学什么，白天看知识点、做题，遇到不会的问人，晚上整理错题，睡前再过一遍没记住的东西，过程中随时可能心态崩了。这个动线映射下来就是六项能力：

• 知识点讲解：把抽象概念讲成人话，能用生活类比就用生活类比；
• 智能出题：根据当前薄弱点生成有针对性的练习题；
• 答疑纠错：用户给出解题过程，它定位错在哪一步，而不是直接甩答案；
• 复习计划：把“一个月后考试”拆成每天可执行的任务；
• 错题复盘：定期把旧错题拿出来问你，形成间隔重复记忆；
• 情绪陪伴：在你连续犯错或表达疲惫时，切换成鼓励模式。

这六项能力每一项都不复杂，难点在于它们要共享同一个“记忆系统”。前期我用Prompt强行拼，后来发现必须引入结构化存储，这个后面详细说。

2. 技术选型：怎么搭才不会后悔

2.1 模型怎么选：推理型、对话型和轻量型的搭配

选大模型API的时候，我踩过最大的坑是“一个模型打天下”。以为只要选一个能力最强的模型，所有场景都能覆盖，结果一个月跑下来账单很感人，而且有些场景根本用不上那么强的能力。

我的建议是把场景拆开，按难度分配到不同模型。讲解复杂概念、分析错题、生成高质量题目，这些任务需要强推理能力，用主力模型，效果稳定最重要；日常的“背单词打卡”“今天复习什么”“知识点一句话总结”，用轻量模型就够了，速度快、价格便宜；至于那些完全不经过大模型也能做的逻辑，比如根据错题统计生成计划，直接写在本地代码里，一分钱不用花。

这里有个取舍原则：先看任务是否需要“理解复杂上下文”。不需要的，一律降级处理。我一位朋友的做法更彻底，他把所有情感陪伴类回复都固定成模板，只在检测到用户输入特殊信号时才调用轻量模型生成个性化回复，成本压到了原来的三分之一。

2.2 先别上头RAG，按这个顺序演进

很多人一听到“给AI加教材知识库”就直接上RAG（检索增强生成），我一开始也是这么做的，后来发现对一个第一版项目来说，这是过度设计。因为大模型的通用知识已经能覆盖大多数学习场景，你要解决的其实是两个更具体的问题：答案准确性和内容贴合考试范围。

所以我的技术演进路线是：第一版完全靠提示词，把老师过往的考试重点整理成Instruction塞进system prompt，先跑通交互逻辑；第二版才做知识库，因为这时候我才真正知道哪些问题模型答得不准、哪些知识不在模型知识范围内。把用户的常见追问收集两周，再决定知识库里需要放什么内容，这种“需求倒逼”的方式比一开始就盲目建库高效得多。

具体做RAG的时候，流程是教材PDF转文本，按章节拆块，每块控制在500字左右，做向量化后存进本地向量库。用户提问时先做相似度检索，召回相关段落，把原文片段拼到Prompt里让模型基于内容回答。这样做的最大好处是模型不敢瞎编，因为Prompt里强调了“只能基于以下参考资料回答”。

2.3 整体架构和代码骨架

整个项目的技术栈我选得比较轻：后端用FastAPI，前端就是一个简单的Web单页，数据库用SQLite存用户档案和错题记录，向量库用的本地方案，没有上重型服务。整套东西跑在普通笔记本上毫无压力。

后端核心代码其实很短，难的是把各模块串起来。下面这个片段是收到一条用户消息后的完整处理流程：先判断消息类型，再决定走哪个模块，最后限制返回长度。

from fastapi import FastAPI, HTTPRequest import requests, json, sqlite3 app = FastAPI() SYSTEM_PROMPT = "你是一个复习搭子……" # 详细内容见下一章 def call_llm(messages, model="main", temperature=0.7): resp = requests.post( "https://api.xxx.com/v1/chat/completions", headers={"Authorization": "Bearer 你的Key"}, json={ "model": model, "messages": messages, "temperature": temperature, "max_tokens": 800, }, timeout=30, ) return resp.json()["choices"][0]["message"]["content"] @app.post("/chat") async def chat(req: HTTPRequest): body = await req.json() user_msg = body["message"] user_id = body.get("user_id", "default") # 1. 从数据库读取用户档案 conn = sqlite3.connect("review_buddy.db") profile = load_profile(conn, user_id) # 2. 组装消息上下文 messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"用户当前薄弱点：{profile['weak_points']}"}, {"role": "user", "content": user_msg}, ] # 3. 调用模型 reply = call_llm(messages) # 4. 异步保存对话记录 save_message(conn, user_id, user_msg, reply) return {"reply": reply, "profile": profile}

这个骨架我建议直接抄，后面每一个功能模块都是往这个主流程里加组件。真正的复杂度不在API调用，而在“如何让模型在正确的时间给出正确形式的回应”，这就轮到提示词工程上场了。

3. 最见功力的部分：提示词与功能实现

3.1 设定一个“会带人复习”的人设

我见过太多AI学习工具的Prompt写得像在写岗位说明书：“你是一个有用的助手，可以帮助用户解答问题……”这种设定出来的回复，普通话标准，但完全没有陪伴感。我的做法是给搭子一个明确的“人设”：一个比你大三届、当年考过这门试、现在回过来带你复习的学长学姐。

这个设定不是玄学，它直接影响模型的语气和策略。学长学姐不会直接给你整段答案，而是会说“你先告诉我你卡在哪一步”；不会列十个要点把自己绕晕，而是用一个类比让你听明白；你连续几次答错的时候，它不会冷冰冰继续讲题，而是说“这道题确实绕，咱们换条路试试”。这些差异来自人设中的行为准则，我在System Prompt里写了四条硬性规则，并且用分隔符把规则包住，防止用户对话把规则覆盖掉：

你是X同学的复习搭子，一个懂考试策略、有耐心、会引导的学长学姐。 你的核心准则： 1. 永远不直接给完整答案。用户问问题，先判断他卡在哪里，再给提示；除非用户明确说“我真的不会，请直接讲”，并且已经尝试过三次，才可以完整讲解。 2. 讲概念优先用生活类比。如果用户表示没听懂，换一个类比再讲，不要重复原话。 3. 每回答完一个知识点，主动问一个检测问题，确认用户是否真的掌握。 4. 当用户连续答错超过两次，或表达疲惫、焦虑，停止继续讲新内容，切换到情绪安抚模式，并建议休息。 <用户输入> {user_input} </用户输入>

这个Prompt里有几个容易被忽略的细节。第一是“尝试过三次才允许给完整答案”，这道门槛极大抑制了学生直接抄答案的行为；第二是“换一个类比”，这迫使模型从不同角度解释，而不是复读机式地换措辞；第三是“回答问题后主动提问”，这是把单轮问答变成学习闭环的关键。

3.2 六项核心能力的提示词模板与参数配置

人设只是基础，每一项具体的功能还需要一套补充指令。我把六项能力的核心指令都写成模板了，这里挑三个最有代表性的详细说说。

知识点讲解：我用的是苏格拉底式提问 + 三重解释法。模型先问用户“关于这个概念，你目前理解到哪一步了”，然后给出第一层解释（一句话直觉版），如果用户追问，再上第二层（生活类比版），还不够再来第三层（公式/机制版）。这样逐层递进，用户不容易被长文劝退。

智能出题：我最看重的不是让模型出多刁钻的题，而是让题目严格匹配用户的薄弱知识点。所以在指令里明确要求“基于以下薄弱知识点生成题目，难度分为基础、进阶、易错三档，每档一题，题目附详解，但详解默认折叠”。这一段折叠详解的设计，是为了让用户先做题再对答案，而不是边看题边瞄答案。出题时temperature我调到0.8，保留一定随机性，避免每次出的题都类似。

错题复盘：这是复习搭子里最有价值的功能。用户发来一道错题，我会让模型先不要分析答案，而是先让用户描述“你当时是怎么想的”，然后定位错误类型。指令中把常见错误类型显式列出来：概念混淆、计算失误、审题不清、方法缺失、记忆遗忘。模型必须先归因，再给针对性的改进建议。

下面是这三项功能的参数参考表格，是我反复测试后觉得比较稳的配置：

注意一个规律：涉及事实准确性和步骤规范的功能，temperature要调低，我用0.3；涉及创造性和需要随机性的功能，温度调高到0.8甚至0.9。情绪陪伴我特意调高温度并限制输出长度，发现短回复比长篇大论的安慰效果好很多。

3.3 上下文管理与会话记忆

第一个版本我天真地以为把所有历史对话都塞给模型就行，结果对话到第15轮就开始出问题：模型忘了早期的约定，越来越“笨”，token消耗也成倍上涨。后来我用了三层记忆方案，效果立竿见影。

第一层是“关键档案”，用结构化数据把最重要的信息提取出来存进数据库：薄弱知识点列表、错题数量、最近一次复习日期、学习时间偏好、目标考试倒计时。这部分不是靠模型记忆，而是每次对话结束后用一套简单规则或一次轻量模型调用，从对话中抽取增量信息，写回数据库。第二层是“滑动窗口”，确保发送给模型的messages列表不超过最近20条。第三层是“早期对话摘要”，当对话超过窗口后，把最早的10轮对话用轻量模型压缩成一段摘要，替代原始内容拼进Prompt。

这套三层记忆方案的收益非常明显：模型永远在一个干净、聚焦的上下文中工作，不会带着三小时前的闲聊杂讯回答问题。而且用户下次打开网页时，哪怕隔了一整天，搭子也能准确说出“你上次在概率论这一章卡住了，要不要先把错题过一遍？”这是最让用户觉得“哇它记得我”的时刻，但实现上不过是读了一下数据库里的档案字段。

4. 实操过程：从0到1跑通最小可用版本

4.1 五分钟先跑通一个命令行版

我知道很多人看教程最烦的就是“环境配置两小时，代码一分钟”。所以这里给一个最省事的最小路径：先不搞前端、不搞数据库，直接用Python脚本在终端里跑对话。先把核心逻辑跑通，再逐步加功能。

找一个支持OpenAI兼容接口的模型平台，拿到API Key，写一个不到四十行的脚本。核心就是封装一个chat(messages)函数，循环接收用户输入，控制台打印回复。这一步的作用不是做出产品，而是验证三件事：网络连通性、Prompt效果、回复速度。很多人会在这一步发现模型平台选得不对，及时换还来得及。

我当时测试的是让搭子讲解一个数学概念，结果它讲完概念后真的追问了我一道检测题，那一刻我就知道人设Prompt写对了。这个版本虽然没有界面、没有记忆，但已经能回答“什么条件下x的平方大于4”这种问题，并且不直接给答案而是反问“你觉得x的取值范围分几种情况？”——那种“被搭子带着思考”的感觉，从命令行里也能体验得很明显。

4.2 升级成网页版与本地知识库

命令行版验证完之后，我很快加了两个升级：网页交互界面和本地知识库。网页界面我直接用的是FastAPI的静态文件服务，加一个单页HTML，聊天框加一个“标记为易错”的按钮，还有侧边栏显示薄弱点数量，整个界面做得非常朴素，但已经够日常使用了。

知识库这步我建议等聊了两三个星期、积累了真实问答记录后再加。因为这个时候你会看到模型哪些回答招架不住，比如某门专业课的教材是自编版本，模型完全没有学过，这类内容才是知识库要解决的。我用的是PDF转文本、按章节切块、向量化入库、检索召回这条标准路线。检索到的文本片段会以“参考资料”的形式拼在Prompt后面，并且模型被严格限定只能基于资料作答。

加了知识库之后我专门做了个对比测试，同一个关于某自编教材概念的问题，不加知识库时模型答得模棱两可，加了之后能准确引用教材里的术语和案例。这一步的体验提升非常明显，可以说是从“泛泛而谈的AI”变成“懂我这门课的搭子”的分水岭。

4.3 错题本与复习计划的实现思路

错题本和复习计划是让搭子“主动起来”的关键。我的实现思路是：每次对话结束，把用户标记为“易错”的知识点记录到数据库，按出现频次生成薄弱知识点榜。然后搭子每天在用户设定好的学习时间自动发送一条消息，内容是“今天预计花40分钟，前20分钟复习昨天错过的两个知识点（各出一道变式题），后20分钟学习一个新章节”。这一条推送看似简单，背后是那个反向倒排的计划生成器：从考试日往回推算，把总任务按天拆分，再结合每天的薄弱点动态调整优先级。

这里有个细节，我没有让模型直接生成每日计划，而是先用本地代码读取错题统计和剩余天数，算出一个任务清单，再让模型把清单转成语气自然、有陪伴感的文案。这个“本地规则算逻辑 + 模型负责表达”的混合架构，既可靠又省钱，是我这个项目里最值得复用的一条经验。

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

5.1 模型胡编怎么办

这是大模型学习工具最致命的问题。我的排查顺序是：先检查Prompt是否明确要求“不确定就说不知道”，再检查是否有知识库兜底，最后看问题本身是否超出了模型能力边界。我实际测下来，Prompt里那句“如果参考资料中没有相关内容，请直接说‘这个我不太确定’，不要编造”，能把明显的幻觉降低一半以上。剩下的漏网之鱼，就需要知识库里的原文作为事实锚点了。

5.2 对话越长越笨怎么破

症状是聊了半小时后，模型开始重复说过的话、漏掉早前约定的规则。这不是模型坏了，是上下文被无关信息塞满了。解决办法就是我前面提到的三层记忆方案，这里再补充一个排查技巧：每次对话结束，打印一份当前发送给模型的messages长度，如果超过6000个token，就检查一下滑动窗口和摘要逻辑是不是没生效。我习惯在代码里加一个日志，记录每次请求的token数和压缩行为，这样才能及时发现性能退化。

5.3 钱烧太快怎么控

有段时间我发现自己每个月光API调用费高得离谱，检查后发现两个原因：一是所有请求都用了主力模型，二是某些后台定时任务（比如每天生成计划）也在重复调用模型。我的对策是做一个模型路由表，按请求类型映射到不同模型；同时把定时任务里的生成文案改成只在首次创建时调用，之后每天复用模板。另外，缓存高频问题的答案也能省不少钱。这一套组合拳下来，成本降到了原来的四成。

5.4 学生想“抄答案”怎么办

这是学习工具特有的使用风险。一开始就有使用者会直接问“这道题答案是什么，直接给我”。如果搭子真给了，那这个工具就退化成搜索引擎了。我的处理方式是在Prompt里加了一道“提问门槛”：要求用户先描述自己的解题思路，否则搭子会拒绝回答并用引导式追问。比如用户说“直接给我答案”，搭子会回“你先说说你觉得第一步该做什么，咱们一起顺一下思路”。实际测试下来，多数用户被这个过程带进了学习状态，抄答案的现象明显变少。

下面把高频问题整理成一个速查表，方便大家直接对照：

速查表列出来之后我自己对照了一遍，发现大部分问题都不是模型能力不够，而是工程架构上偷了懒。把记忆、路由、成本控制这些基础做扎实，模型的体验自然就稳了。

最后说点个人体会。这个项目做完之后，我最意外的收获不是“AI讲题讲得有多好”，而是那些被记住的感觉带来的学习动力。看到一个搭子告诉我“这是你第5次错同类题，今天咱们彻底把它搞定”，比任何学习技巧都让人想坚持。后面我想给它加一个多人模式，拉上朋友组一个线上自习室，各学各的但能互相看进度，或者把规划功能和日历联动。总之这个方向还远没到头，希望这篇记录能帮少走一点弯路。