企业官网建设流程全解析

这个项目的最初动机，来自一次很普通的抱怨。某教研机构的一位朋友跟我吐槽，家长下班回家打开学习类App，孩子对着屏幕看了十分钟就走神了，因为这些产品要么就是一道接一道地刷题，要么就是用AI给出一段冷冰冰的“标准讲解”，压根没说到孩子卡住的点子上。他想知道，能不能快速做出一个真正懂学生的学习助手——孩子哪里卡住了就讲哪里，讲完马上出几道同类练习。他自己不会写代码，而我那阵子恰好在用Vibe Coding的方式做几个小系统，于是我们决定把这件事真正落地，也就有了这套面向K12场景的AI智能教育系统。

动手之前先把Vibe Coding这个概念说清楚。它在圈子里常被翻译成“氛围编程”或“随性编程”，但更准确的理解是：开发者用自然语言描述意图，AI承担生成主体代码的工作，人在关键节点负责审查、纠偏和接手。它并不是让AI替你胡思乱想，而是把“写代码”这个动作从键盘敲击变成了“需求沟通”。拿盖房子类比，传统开发是你拿着施工图去找施工队，Vibe Coding则是你带着需求描述去和一支很聪明的施工队合作，图纸可以现场改，前提是你知道自己要住什么样的房子。

如果你对K12教育场景多少有些了解，还会发现这类系统的需求有个特点：特别碎。不同年级讲分数除法的方式完全不同，三年级可以用分披萨的直观例子，六年级就得讲倒数概念，八年级则需要把它映射到比例关系。传统方式想把这些分支逻辑都做出来，产品经理写文档、后端写接口、前端调样式，排期动辄几周。Vibe Coding的工作方式把这条链路压缩成了“描述需求、看效果、不满意就改描述”，这恰恰切中了教育产品最需要快速试错的那一块。

1. Vibe Coding真正改变的，是需求传递的方式

1.1 从“命令机器”到“和机器商量”

在Vibe Coding出现之前，我们和计算机沟通的唯一方式是编程语言，本质上是一条单向的指令链：你告诉机器每一步做什么，它机械地执行。Vibe Coding带来的最大变化是，出现了“意图层”的沟通——你可以直接说“这里需要根据用户输入判断异常并给出提示”，AI会自己拆解成具体的函数、判断逻辑和交互反馈。这个过程不再要求你把每一个变量和函数都提前想好，而是把目标描述清楚，剩下的实现细节由模型推演。

但这不意味着你可以撒手不管。很多刚接触的人有一个误区：只要把需求描述得足够“像人话”，AI就会给你一个完美系统。实际用过两三周就会明白，AI生成的代码里藏着大量需要人类把关的东西：模块边界是不是清晰、错误处理是不是完善、提示词和业务逻辑有没有耦合死。我的经验是，Vibe Coding的效率提升不来自“完全放手”，而来自“把审查和修改的粒度从函数级提升到模块级”。传统开发改一个需求要动几十行代码，Vibe Coding模式下你可能只是追加一句话，剩下的由AI完成重写。你省下的时间没有消失，而是转移到了设计、测试和真实用户体验上。

1.2 为什么教育产品是Vibe Coding最合适的试验田

我见过很多人把Vibe Coding用在一些高风险场景，比如交易系统、医疗数据处理，这类场景对正确性和审计要求极高，AI生成的代码反而会带来额外风险。但教育产品不一样，尤其是面向K12的学习辅助工具，核心交互链路是问答、出题、反馈，链路不复杂，但业务流程中的分支条件非常多，这是Vibe Coding最能发挥优势的地方。

更重要的是，教育产品必须依赖真实反馈来迭代。同一个知识点，你给三个不同的学生讲，效果可能完全不一样，因为卡点不同。用传统方式做一个“换一种讲法”的按钮，需要前端的交互设计、后端的逻辑分支、测试用例补充，每个环节至少一天。在Vibe Coding的流程里，我只要在对话中告诉AI“如果学生说没听懂，换一个生活化类比再讲一次”，它就能自己完成逻辑插入。一个是按天计，一个是按小时计，这种迭代节奏的差异，决定了K12这类高度依赖反馈的产品非常适合先用Vibe Coding跑通。

2. 动工之前先画边界：这套K12系统到底管哪些事

2.1 定位成“数字助教”，比“全能老师”更务实

项目启动后的第一件事不是写代码，而是定义系统边界。当时我们反复讨论过一个让人纠结的问题：要不要让AI承担“批改作文”和“情感陪伴”这类功能。最后我们主动把它们砍掉了，因为AI做得到不代表适合做。K12场景里，家长的信任是最脆弱的资产，作文批改一旦出现评价偏差，会直接引发投诉和抵触情绪；情感陪伴的尺度也极难把控，一个语气不当可能产生反效果。

最终系统定位为“数字助教”而非“全能老师”，只负责三件事：回答知识疑问、生成同类练习、记录学习轨迹。边界收窄之后，AI的发挥空间反而更稳定，每个模块都能把一件事做透。这是Vibe Coding项目里最重要的取舍原则：工具的边界，决定了产品的下限。你可以在后续版本里慢慢加功能，但一开始就把范围铺开，会让AI生成的代码互相纠缠，后面每一次需求变更都可能引发连锁修改。

2.2 三个核心模块：答疑、出题、追踪

系统里最核心的三个模块，对应学生在真实学习中的三条行为链路。

答疑模块解决“孩子卡住了”的问题。学生输入一道不会做的题，或者一个没理解的概念，系统先通过一两个追问判断卡点，再有针对性地讲解。这个模块对讲法的要求极高，本质上是从“给答案”变成“带着推导”，对提示词设计的要求也最重，后面的章节会单独展开讲。

出题模块解决“懂了但练得不够”的问题。学生在某个知识点通关之后，系统生成3到5道同类题，覆盖不同题型和难度，并保证不简单重复。出题模块对确定性有要求——题目答案必须正确，解析必须对应题干，这里后来引入了程序化校验，不能只靠模型自觉。

追踪模块解决“家长什么都不知道”的问题。系统记录学生做对了几次、做错了几次、反复卡在哪个知识点，生成一张简单的学情图。这个模块不需要复杂的大数据模型，只需要在每次交互时把关键事件写入结构化记录。

2.3 内容准备：把教材和题库先“喂”给结构

在Vibe Coding项目里，很多人忽略了一个前置工作：语料和题库的整理。模型本身再好，没有有效的知识结构做锚点，出题和答疑就会飘。我们当时把教材的目录按章节拆成了一个树状的JSON，每个知识点标注了年级、学科、所属章节、前后置关系，然后给题库里的每道题打了标签，包括知识点、题型、难度等级和标准答案。

这些工作没法交给模型“自动完成”，因为结构化信息的准确性需要人来把关。我一开始也想偷懒，让AI从教材文本里自动抽取知识图谱，结果生成了大量语义重复的节点，诸如“分数除法”和“分数的除法”被拆成两个知识点。最后老老实实花了两天人工整理，但这一步的价值在后来的每一个模块里都体现了出来——所有提示词都需要引用这个结构，没有它，AI根本不知道该往哪个方向约束自己。

3. 让模型“懂”教育：提示词里的三层约束怎么写

3.1 第一层约束：给AI装一个“教研组长”的身份

很多人写提示词只会写“你是一个AI助手”，这在教育场景里完全不够。我们实践下来，身份设定至少要包含三个信息：角色、服务对象、禁忌。一个可复用的模板是：

你是某实验学校的教研组长，有十年一线教学经验，负责为小学到高中阶段的学生讲解学习问题。 你的服务对象是K12学生，请用他们能理解的语言回答问题。 禁忌：不要直接抛出超过学生当前年级的概念；不要在确认卡点之前给出完整答案。

这一层看起来很基础，但它决定了AI回答的“人格底色”。没有身份设定，模型容易切换成百科全书的语气，输出完整、抽象、充满术语的定义，学生根本读不下去。加了“教研组长”的身份之后，输出会更像一个老师在面对学生，而不是一个搜索引擎在返回条目。身份设定是后续所有逻辑约束的地基，本质上是用角色把模型的“调用域”卡在一个可控的范围内。

3.2 第二层约束：讲法控制，苏格拉底式引导的模板

教育场景里最大的坑就是“直接给答案”。孩子问一道题，AI噼里啪啦输出完整解法，孩子抄一遍，什么都没学到。我们在答疑模块里强制要求先引导、再讲、最后总结，具体做法是在系统提示词里固定一个讲解流程：

当学生提问时，按照以下顺序进行： 1. 先问一个问题，了解学生卡在哪一步； 2. 根据学生回答，拆解为2-3个递进小步骤； 3. 每个小步骤先用提问引导，学生答不上来再给出提示； 4. 最后给出完整推导，并总结关键思路。

这套流程看着简单，但效果非常明显。原来直接给答案的模式下，学生会话平均只持续两轮；改成引导式之后，平均会话轮数拉到六轮以上，而且很多学生在最后一轮会主动说出“哦，我明白了”。对学生来说，自己推导出来的结论比被告知的结论牢固得多，这是教学法上的常识，不在代码里体现的话，所谓“智能教育”就只是套了一个壳。

3.3 第三层约束：用课标元数据锁住内容深浅

第三层是对“K12”这个标签的祛魅。K12的跨度实在太大，一个笼统的“面向K12学生”会让AI默认输出中间水平的内容，既不适合二年级，也不适合高二。我们的做法是，在每次发起对话时强制带上年级、学科、教材版本和知识点ID，元数据会拼进提示词的开头：

当前用户背景：小学四年级，数学，指定版本教材，知识点ID=math_4_frac_division 请严格基于上述背景作答，不要使用该年级之前未接触过的概念。

这样做的好处是，同一个答疑接口可以复用于所有年级，模型会根据元数据自动切换语言复杂度和例子类型。有一段时间我们忘记传年级字段，默认值设成了高中，结果一个六年级的孩子问“分数除法怎么算”，AI给出了一堆涉及极限思想的类比——这在教育场景完全不可接受。不同年级对同一个概念的理解路径差异极大，不用元数据锁死内容深浅，再好的讲解框架都会翻车。

4. 从一句需求到能跑的Demo：核心模块的搭建实录

4.1 先要数据模型，再要业务接口

Vibe Coding不代表不要设计，只是设计的表达方式变了。我们启动时没有写架构文档，却让AI先生成了整个系统的数据模型雏形，这一步相当于把地基先画出来。当时我给出的提示词是：

请设计一个Python数据模型，包含三个实体：知识点、题目、答题记录。 知识点需要包含：id、名称、所属年级、所属章节、前置知识点列表。 题目需要包含：id、知识点ID、题干、选项、正确答案、难度、题型。 答题记录需要包含：学生ID、题目ID、是否答对、用时、答题时间。 要求使用dataclass实现，字段类型必须明确。

AI在几秒内生成了一套完整的数据模型。我们在此基础上做了两处修改：给题目加了“解析”字段，给答题记录加了“卡点标签”。从成品质量来看，这个起点的结构比很多手工写的还要规范，因为它参考了大量开源项目的命名习惯。这一步给我的启发是：在Vibe Coding流程里，AI生成的代码已经不是“能不能用”的问题，而是“你愿不愿意在它上面继续迭代”的问题，所以一开始就要让它生成结构化、可扩展的代码，而不是一坨能跑就行的一次性脚本。

4.2 用自然语言改需求，迭代真的可以按小时算

数据模型确定之后，后续的功能开发基本都是自然语言驱动的。我印象最深的一个修改是出题模块的选项配置。第一次生成的题目选项只有A、B、C三个，正确答案永远是选项A，这显然不行。我的修改请求是：“把选项改成四个，正确答案随机分布，不要让AI自己指定答案位置，而是把选项顺序交给程序洗牌”。

AI理解了需求后，把出题流程拆成两步：先生成题干和几个干扰项，再由程序随机排列并标记正确答案位置。改动涉及的代码量不大，但背后是“内容生成”和“顺序编排”的逻辑分离，这个设计如果是人手工做，可能需要半小时梳理需求，AI生成只用了十分钟，测试覆盖也一并附上了。

这段经历让我总结出一条经验：Vibe Coding的每次修改，尽量只提一个核心变化，一次塞五个需求进去，模型很容易顾此失彼。就像你和一个开发同事沟通，把需求拆细了，对方才能把每个点想透。

4.3 前端的两种“友好”：给孩子看和给家长看

前端部分我们一开始没花太多精力，因为教学效果主要看后端逻辑，但实际体验中也踩了一些交互的坑。面向小学生的界面，字号、文案、反馈语气都是功能的一部分。字体过小、反馈语气生硬，孩子会直接失去耐心。具体改了三处：把“再试一次”改成了“没关系，我们一起看看另一个思路”；把错误提示框的红色改成了橙色；题目区域的字号调大了一档。

家长端则完全不同，家长需要的是信息密度而不是花哨，我们用最简单的一张卡片展示本周的学习数据：练习多少题、正确率、薄弱知识点。前后端界面最后都是用对话式迭代完成的，每次只改一个视觉细节，实时修改，效率远超传统切图联调。这里想强调一个容易被忽略的点：Vibe Coding虽然擅长生成代码，但前端的“好感度”往往藏在文案和细节里，需要你以一个真实使用者的身份反复体验，再通过对话去调整。

5. 让输出“稳下来”的进阶手段：幻觉、记忆与成本控制

5.1 标准答案注入：把瞎编的概率压到最低

教育系统最不能接受的就是AI一本正经胡说八道。数学题答案算错、语文阅读理解给出错误主旨总结，都会直接摧毁家长信任。我们当时最紧急的优化，就是把“模型自由发挥”的空间压缩到极致。具体做法是简化版的检索增强生成：每次出题或讲解前，先从题库里按知识点匹配最合适的一条标准记录，把题干、标准答案和解析直接拼进提示词，并明确指示模型只基于以下材料讲解，不得自行扩展新结论。

以下是从题库中检索到的题目和标准答案，请基于它们组织讲解。 题目：... 标准答案：... 解析：... 请严格遵守，不要新增任何材料之外的计算步骤。

这样一来，AI的角色从“知识创造者”收敛成了“讲解员”，幻觉空间一下就小了很多。执行之后，答疑模块的错误率从频繁翻车降到了每百次一两例，剩下的个例再由边界规则拦截。这个思路对所有内容生成类产品都适用：凡是答案有确定性要求的部分，就不要让模型自己算。

5.2 对话状态外置：别让模型自己记着所有事

第二个大问题是多轮对话的“记忆漂移”。孩子上一轮说“我不理解分数乘法的意义”，下一轮AI就忘了，重新讲一遍一样的内容；或者学生中途切换了年级，模型还停留在之前年级的语境里。这种问题的根因在于，模型依赖上下文去推断当前状态，而上下文一长，注意力分布就会失衡。

我的解决办法是把关键状态放到会话变量里，每次请求时由程序重新组装成固定的摘要，塞进提示词。比如会话对象里维护一个字段：“当前知识点、上次讲解方式、学生反馈标记、已练习次数”。每次模型回答之前，程序先把这些状态转译成一句标准话术，拼到用户问题前面。相当于给模型发了一份“学生档案”，它只管基于档案回答，不需要从漫长的历史对话里猜。这个改动彻底解决了重复讲解的问题，也让系统的行为变得可预测。

5.3 贵模型和便宜模型混用，账单才能好看

几个模块全挂在同一个大模型上，确实省事，但成本会很难看。我实际跑了一段时间后发现，答疑和出题这种需要高质量输出的模块必须用好模型，而另一些模块完全可以降级用便宜模型甚至规则逻辑。实际划分如下：

三个档位跑下来，整体成本比全用强模型下降了大概六成，质量几乎没有感知差异。成本控制这件事，在Vibe Coding项目里尤其容易被忽略，因为写代码不花钱，但每次接口调用都是真金白银，等到用户量上来再优化就晚了。

6. 踩坑实录与内容安全：这两个环节决定能不能上线

6.1 三个真实翻车现场，以及修复过程

翻车现场一：年级字段漏传，AI讲成了大学课。当时我们接口里的年级默认值写错了，前端没有把年级传上来，后端兜底逻辑取了一个高年级默认值。发现过程是一个内测用户反馈“这个AI讲得太深了”。排查链路是这样：先在会话日志里定位所有异常回答，发现都集中在近两天，再检查前端请求体，发现年级字段一直是空的，后端取到了默认值。修复办法是前端必传年级，缺失时直接弹层要求学生先做选择。这个坑提醒我们，Vibe Coding生成的代码逻辑往往是对的，但不同模块之间的默认值衔接，仍然需要人来检查。

翻车现场二：AI出题答案错。某个知识点下，AI生成的题目题干和解析自洽，但答案本身算错了。根因是让模型同时承担出题和计算答案两种任务，它的推理能力并不稳定。修复办法是把“出题干”和“算答案”拆开：AI只负责生成题干和干扰项，答案交给程序化函数求解，或者直接从题库预置的标准答案里取。遇到数学题，出题之后系统还会内部跑一遍求解校验，算不出来就自动换一题。这一步做完之后，答案错误类反馈基本清零。

翻车现场三：孩子说“没听懂”，AI重复同一套讲解。根因是会话里没有记录已经用过的讲解方式。修复办法是在状态里增加“历史讲解方法”字段，例如“用了分披萨类比”，当学生第二次表示不懂时，提示词里要求模型换一种生活化类比，而不是原样复述。这个细节对教学体验影响很大，同样是讲解，换个说法常常就能打通卡点。

6.2 面向未成年人的内容审核闸门

教育产品面向未成年人，内容安全不是加分项，是生死线。我们搭了三道闸门，缺一不可。

第一道是输入侧和输出侧的规则过滤。输入侧要挡掉隐私信息、诱导性问题、不当用词；输出侧要挡掉暴力、低俗、成人向内容以及可能引发心理不适的表达方式。规则过滤的维护成本不高，但必须持续更新，因为孩子们总能问出成年人想不到的问题。

第二道是模型自带的安全对齐，加上系统提示词里的显式约束。我们在所有模块的提示词末尾都固定加了一句：只讨论与当前学科问题直接相关的内容，不回答任何与学习无关的请求。这能拦住大部分越界问题，但要清楚，它不是万能的，所以必须有第三道闸门。

第三道是人工抽检和举报通道。系统上线前两周，我们每天抽样50条对话记录，专门看边界表现；同时在界面里放了一个不显眼的“反馈”入口，让家长和老师可以一键上报异常内容。三道闸门加起来，才勉强算对得起“面向孩子”这几个字。另外，隐私保护也要单独说：学生统一使用匿名ID，不收集真实姓名、位置等个人信息；学习记录只保留知识点和结果数据。K12产品的数据合规红线比普通C端产品高很多，宁可功能少一点，也不要留任何隐患。

6.3 小步上线、灰度验证，别一次扔出个大爆炸版本

教育产品最怕一上来就把所有功能铺满，一个语气词都可能引爆家长情绪。我们当时的做法是把规划里的六个功能砍到三个，先在一个年级的一个班级试用两周，收集孩子们的真实反馈。有学生说“AI讲得太绕了，能不能直接一点”，于是我们把引导步骤从每轮必问改成“卡住了再问”；也有学生反馈“做对之后的小红花让他们愿意多做两道题”，于是我们强化了正向反馈的展示。

两周之后扩大到整个学校，再隔一周才全量开放。这种灰度节奏看起来保守，但教育产品一旦出现内容安全或教学质量问题，口碑伤害是不可逆的。在Vibe Coding模式下，改功能很快，但验证“这个功能是否适合真实孩子”的耐心，不能因为开发速度快而省略。

这个项目做到最后，我最深的体会是：Vibe Coding确实把开发门槛拉低了，但它没有把“思考门槛”拉低。你依然要非常清楚产品在解决什么问题、边界在哪里、哪些内容绝对不能含糊。教育的特殊性就在于它面对的是孩子，任何一点“差不多就行”都会在真实课堂上被放大。如果你也想用AI快速做点什么，我的建议是先从一个小到不能再小的功能闭环开始，把它跑到稳定，再去想第二个功能。

最后分享一个我一直在用的习惯：每次和AI协作时，把完整的对话记录存档，特别是那些让它改需求的关键节点。这个系统跑了一个月之后回看，那些存档就是最好的项目文档，比任何wiki都管用。再小的项目，记录都会成为你下一步迭代的底气。