1.5 Vibe Coding 的心法

写完上一篇的 Markdown 需求文档以后，很多老师会松一口气。

需求终于不是一句“帮我做个系统”了。标题有了，功能有了，验收标准也有了。按理说，AI 应该能稳稳接住。

但真实情况往往没这么顺。

你让 AI 做一个机房排座系统，它可能做出一个挺漂亮的座位网格。按钮有，颜色也不错。可你一试就发现：电脑编号没体现，不同班级混在一起，刷新页面后座位没了，学生还能被安排到两个位置上。

这里继续使用机房排座，是因为它是作者亲自跑通、问题边界完整的技术样板。各学科老师真正要迁移的不是“排座”两个字，而是把自己的课堂和校园现场翻译成可执行结构的方法。

页面看起来像那么回事，现场用起来却不对味。

问题不一定是 AI 不聪明。

更多时候，是老师脑子里的校园现场，还没有被翻译成 AI 能执行的结构。

AI 听不懂痛点，但听得懂结构

老师说“排座很麻烦”，这句话 AI 其实很难处理。

它不知道麻烦在哪里。是学生名单难整理，还是机房电脑位置固定？是不同班级要轮换，还是任课老师想临时查看？是保存不方便，还是打印座位表太费劲？

这些东西对老师来说是日常经验，对 AI 来说却是隐藏信息。

所以 Vibe Coding 的心法，不是背一堆神奇提示词。

它更像把校园现场翻译成五件事：

• 角色：谁在用这个系统。
• 流程：他们按什么顺序完成事情。
• 数据：系统要记住哪些东西。
• 异常：哪里最容易出错。
• 验收：做到什么程度才算完成。

这五件事说清楚，AI 才不容易把你的痛点理解成一个空泛功能。

换成英语单词练习、古诗自测、实验观察记录或课堂分组时，这五件事仍然成立：谁使用、按什么顺序操作、哪些数据要处理、出错时怎样反馈、做到什么程度才算能用。学科内容会变，需求结构不会变。

第一件事，先把角色说清楚

很多需求一开始就写功能。

比如：

做一个排座系统，可以拖动学生到座位上。

这句话不算错，但它少了一个很关键的东西：谁在用。

在校园现场里，角色不是装饰。不同角色决定了系统应该长什么样。

对机房排座系统来说，至少要说清楚这几类人：

• 信息科技老师负责创建班级、录入学生、安排和调整座位。
• 学生不一定需要登录，但他们会被分配到具体电脑位置。
• 班级不是一个静态名单，不同班级要有不同座位表。
• 任课教师可能只需要查看或打印座位表，不需要修改数据。

这样一说，AI 就会明白：这不是一个给学生自由选座的网站，也不是一个简单的座位展示页面。

它是信息科技老师用来管理机房座位的工具。

角色清楚了，功能才不会跑偏。

第二件事，把流程排出来

角色说清以后，还要把事情发生的顺序讲出来。

AI 很容易把一个功能做成“页面上都有”，但不知道老师真正操作时先后要做什么。

排座系统的最小流程可以这样描述：

老师先选择一个班级。
系统显示这个班级对应的座位表。
如果还没有座位表，就显示空的机房布局。
老师把学生安排到具体电脑位置。
系统检查学生和电脑是否重复占用。
老师点击保存。
下次再选择这个班级时，系统能恢复上次保存的座位。

这段话没有任何高深技术。

但它比“支持拖拽排座”强很多。因为它告诉 AI：先做什么，后做什么，什么时候检查，什么时候保存，什么时候恢复。

老师平时写教学流程，其实就是这种能力。

先导入，再活动，再展示，再评价。换到 AI 开发里，就是先选择班级，再显示布局，再分配座位，再保存结果，再验证是否能重新打开。

第三件事，把数据关系说出来

到了这里，不需要马上讲数据库。

但你要让 AI 知道，校园里的这些东西不是一回事。

班级是一类数据。

学生是一类数据。

机房座位是一类数据。

电脑编号又是一类数据。

座位表则是“某个班级的某个学生，被安排到某个座位或电脑上”的关系。

如果你不说清楚，AI 可能会把学生姓名直接写死在座位格子里。看起来能用，但只要换一个班级，就乱了。

你可以用很朴素的人话描述：

机房座位布局是固定的，电脑编号也是固定的。
班级可以有多个，每个班有自己的学生名单。
同一个班级保存一张座位表。
座位表记录的是学生和机房座位之间的对应关系。
不同班级的座位表互不影响。

这就是数据意识。

它不要求你现在会建表，也不要求你会写 SQL。你只是先告诉 AI：哪些东西要长期存在，哪些东西之间有关联，哪些东西不能混在一起。

后面真正进入 Web 项目时，前端、后端、数据库会分别接住这些信息。

这一篇先不展开。

第四件事，提前告诉 AI 哪里会出错

很多老师用 AI 做项目时，只告诉它正常情况。

但学校现场最麻烦的，往往不是正常情况。

比如排座系统里，这些问题非常容易出现：

• 同一个学生被安排到两个座位。
• 同一台电脑被两个学生占用。
• 老师切换班级后，看到的还是上一个班的数据。
• 页面刷新后，刚保存的座位丢了。
• 老师误点清空，整张座位表没了。
• 有学生转入转出，名单和座位表对不上。

这些不是边角料。

它们才是系统能不能在办公室、机房和课堂里真正用起来的关键。

所以你要学会把异常提前说出来。不是等 AI 写完以后再抱怨“怎么这里没考虑”，而是在需求阶段就告诉它：

系统必须避免一个学生占多个座位。
系统必须避免一台电脑同时分给多个学生。
切换班级时，只能显示当前班级的座位表。
刷新页面后，已经保存的数据不能丢失。
清空座位表前要二次确认。

这几句话，能帮 AI 少走很多弯路。

更重要的是，它让你自己也更清楚：这个系统真正危险的地方在哪里。

第五件事，用验收标准把 AI 拉回现实

AI 很擅长做出“看起来完成了”的东西。

按钮能点，页面能打开，颜色也挺顺眼。但校园工具不能只看第一眼。你要用真实场景验收它。

排座系统至少可以这样验：

• 新建一个七年级 1 班，录入 5 个学生。
• 把 5 个学生分别安排到 5 台不同电脑。
• 尝试把同一个学生再安排到另一个座位，系统要阻止。
• 保存座位表后刷新页面，数据还在。
• 新建七年级 2 班，确认不会看到七年级 1 班的座位。
• 切回七年级 1 班，原来的座位表还能恢复。

这些验收动作不复杂，但很真实。

它们比“页面美观、功能完整”更有用。因为 AI 可能不知道你学校怎么用这个系统，但你知道。

老师仍然是最后的验收人。

你不用看懂每一行代码，但你要能判断：这个东西放到机房里，到底能不能减少你的重复劳动。

先聊透，再让 AI 出 PRD

角色、流程、数据、异常和验收这五件事，听起来清楚，真写的时候却不一定一下子想得全。

这时候，不要急着让 Coding Agent 动手改项目。需求还很模糊的时候，先找一个适合讨论的 AI 应用聊一轮。

比如 DeepSeek，或者其他带有专家模式、深度思考模式的 AI 应用。你可以先把它当成一个懂一点产品、懂一点学校现场的教研组同事，让它围绕刚才这五件事追问你，而不是立刻写代码。

你可以告诉它：自己是一名信息科技老师，想做一个机房排座系统；先不要写代码，先从产品经理和一线中小学教师的视角追问；重点帮你发现角色、流程、数据、异常和验收上的遗漏；等讨论清楚后，再整理成一份适合交给 Coding Agent 的 PRD。

这个过程很像磨课。

第一次说出来的想法，往往只是一个粗稿。AI 追问几轮以后，你会发现自己原来没想清楚：任课老师到底能不能改座位，导出打印是不是第一版必须做，学生转班以后旧座位表怎么处理，清空座位表要不要二次确认。

这些问题在写代码前暴露出来，是好事。

因为它们如果等到代码写完才冒出来，就会变成返工。

所以更稳的顺序是：先和讨论型 AI 头脑风暴，把五件事聊透；再让 AI 整理 PRD；再把 PRD 放进项目文档；最后交给 Coding Agent 按文档开发。

前面的 DeepSeek 或类似 AI 应用，负责帮你把想法聊清楚。

后面的 Coding Agent，负责在项目目录里读文件、改代码、跑命令。

这两个环节别混在一起。先聊透，再开工，项目会稳很多。

可以这样把现场说给 AI

把前面五件事合起来，你就能得到一段更稳的人话描述：

我想做一个机房排座系统，主要给信息科技老师使用。

机房电脑位置固定，每台电脑有固定编号。
学校有多个班级，每个班级有自己的学生名单。
老师选择班级后，系统显示该班级的座位表。
如果这个班还没有安排座位，就显示空的机房布局。

老师可以把学生安排到某个电脑座位上。
同一个学生不能被安排到多个座位。
同一台电脑在同一个班级的座位表里不能分给多个学生。
老师保存后，下次打开同一个班级，座位表要能恢复。

暂时不做学生登录、复杂权限和自动排课。
验收时，我会用两个班级测试，确认它们的座位表互不影响。

这不是万能模板。

它只是示范一种表达方式：别只说你想要什么功能，还要说清楚谁使用、怎么操作、数据怎么对应、哪里不能出错、最后怎么验收。

这才是好 Prompt 背后的底层东西。

今天就能做的一件事

现在可以回到你上一篇写的 Markdown 需求文档里，给它补五个小标题：

## 角色

## 流程

## 数据

## 异常

## 验收

每个标题下面先写三五句话就够。

不要追求一次写完美。先把脑子里的现场经验倒出来，再找 DeepSeek 或类似 AI 应用讨论一轮，让它帮你检查哪里有歧义、哪里缺边界、哪里还没法验收。

讨论清楚以后，再让它整理成一份 PRD。最后把这份 PRD 放进项目文档，交给 Coding Agent 去执行。

Vibe Coding 最厉害的地方，不是让老师变成职业程序员。

而是让老师把自己最懂的校园现场，变成 AI 能执行的项目语言。

这也是各学科教师共同的优势：你最清楚学生会在哪一步卡住、课堂时间怎样流动、哪些数据不能随便处理。AI 可以负责实现，但这些判断必须由老师做。

到这里，破局篇的准备工作就基本齐了：你知道 Vibe Coding 不是一句话魔法，知道要搭指挥链，知道环境要跑通，也知道需求要写成文档，更知道文档背后要有角色、流程、数据、异常和验收。

接下来，我们要开始拆开 Web 项目这个黑盒。

因为当你开始说“页面要显示座位”“数据要保存”“刷新后不能丢”时，背后其实已经牵出了前端、后端和数据库的配合。下一部分，我们就用老师听得懂的方式，把这个黑盒一点点打开。

封面