一对一辅导案例

本文整理自一次真实的约 50 分钟一对一辅导，已做脱敏处理：隐去学员身份与背景细节、公司业务、一切商业信息，演示数据只保留了「新增了一条员工记录」这一事实。留下来的，是问题和解决问题的思路——因为这位学员的处境，和本站大多数读者几乎一样。

学员的起点：会做产品，但链路是黑的

十年以上 B 端产品经验，做过带多个子系统的大型行业系统，写需求、理逻辑是老本行。用 AI 编程做了一个真实的管理系统：页面能跑，表单能提交。但学员自己说，心里始终悬着几个问题：

1. 我做的到底是一个「能上生产的项目」，还是一个 demo？
2. 同事推荐的后台管理框架（若依 RuoYi 这类）到底该怎么用？让 AI 先读框架，还是先写需求？
3. 数据库在哪、容器是什么、怎么上线——这些名词都听过，但没有一个有画面。

这三个问题问得很准。尤其第一个：「是生产级还是 demo」，就是假数据当真数据那个反模式背后的分界线。

问题一：要不要用成熟框架？

管理后台这类需求，答案是可以直接在成熟开源框架上改，而不是从零搭：

• 框架自带一套完整的管理端代码、标准的目录结构和规范，登录鉴权（JWT）、参数校验这些后台必备件都是现成的
• AI 在有规范、有既有代码的项目上开发，比在空白项目上更稳
• 关键转念：用框架不改变产品经理的工作。需求分析、PRD 该怎么做还怎么做，变的只是实现起点——从空白，变成站在一套完整代码上改

问题二：引入 AI 之后，流程是什么顺序？

学员把自己摸索的流程摊开，一起校准成了一个固定顺序：

1. 照常梳理需求、写 PRD（需要的话连高保真原型一起做）
2. 让 AI 以「架构师」身份做技术选型：前端用什么、后端用什么、数据库选 MySQL 还是别的
3. 把选型和架构设计落成文档
4. 换一个模型对架构做一轮评审，交叉校验后再改定稿
5. 回到编码工具（如 Claude Code），按文档实现

模型搭配的经验：选型、架构设计这类初期环节用高级模型；文档写清楚之后，编码阶段换便宜模型（DeepSeek、GLM 这一档）偏差也不大。

问题三：最重要的习惯——文档留在项目文件夹里

自查环节发现了一个险情：学员手里只有需求文档，技术选型的结论只存在于某次对话里——对话一翻过去，几乎就找不回来了。

所以这节课立下的规矩是：

• 需求文档、技术选型、架构设计，全部以 markdown 文件留在项目目录下
• 需求有变更，就补一份新的文档，而不是靠对话记忆
• 跨工具、跨 agent 协作时，文件是唯一稳定的上下文。文档在，便宜的模型也能稳定干活

问题四：我的数据库到底在哪？（三连问模板）

学员盯着自己的项目问出了那句话：「我的数据到底存到哪了？」

答案不靠背概念，靠把三个问题直接抛给 AI：

1. 我当前的数据库是什么？
2. 数据库是怎么启动的？
3. 数据库连接串是什么？

当场得到的答案：用的是本地 MySQL，本机启动——只有这台电脑自己能用，别人访问不到。要让别人访问，才轮到「上云」这件事。

顺带补上一个认知：数据库本质上也是一个「服务」，和你的后端一样，是跑在那里、等着被连接的东西。

现场演练：一条数据到底流到了哪

整节课最值钱的十分钟：学员在管理页面新增了一条员工记录，然后打开数据库管理软件刷新——那条记录就躺在表里。

顺着这条记录，把链路画了出来：

• 表单提交 → 前端把请求发给后端 API → 后端去写数据库
• 数据库管理软件和后端 API 是同一层级，都拿着连接串直连数据库；前端永远不直接碰数据库
• 所以点「详情」或「修改」时，页面要先去数据库查出这条记录当下的真实状态，回显的不是前端记住的旧值

最后学员自己总结出来一句话：「所有交互都是前端跟后端交互，后端再给数据库下指令。」——这句话，就是前端与后端那页讲的链路，从名词变成画面的一刻。

问题五：容器是什么？一杯外卖咖啡讲明白

一杯外卖咖啡，如果不打包，拎着走容易洒，也容易和别的单混在一起；装进标准化的杯托和打包袋，才好递出去、好配送。

• 容器就是给服务套上的标准化包装：一个隔离的环境，稳定、安全，方便部署和迁移
• 学员本机直接启动的数据库，属于「非标准启动」：能用，但不方便搬走
• 有了容器和镜像，服务才能顺利地搬上云端

问题六：怎么上线？万能提示词 + 三条路线

到这一步，直接给 AI 这段话就够了：

我的产品已经开发完成，我现在要上线到正式的生产环境。我有一台云服务器，想知道完整的上线步骤，以及上线前有什么必须处理的问题。

AI 会给出三条常见路线：

1. 裸机部署：最简单，个人项目够用
2. Docker Compose：行业标准做法，随时可以整包迁走
3. 云厂商的托管容器服务：省心，但绑定那家云的生态，以后想换云就要重做

选型原则一句话：**永远选最标准的、随时可以迁走的。**这位学员选了第二条。完整流程见上线课。

上线前的检查清单

• 环境变量：.env 文件就是一个密码本——明文文本，只放在自己的电脑和服务器上，绝不提交到公开的地方
• 生产的数据库账号密码要换一套新的，不和本地相同；密码本一旦泄露，别人就能直连你的数据库
• 限制 API 只允许自己的前端来调用
• HTTPS 证书：有免费档，证明你的域名安全可靠；付费的效果更好
• 域名：在国内上线需要备案；申请域名这类操作，让 AI 教步骤，但去网页上自己操作
• 部署命令是在服务器上执行的，不是在自己的电脑上点

这节课带走了什么

课后学员的原话（转述）：很多东西做了十年产品都听过，但从来没有概念；现在「整张拼图基本补齐了，冰山下面看不见的东西，脑袋里有画面了」。还主动列出了下一步：先自己消化，再补最后一块尾巴——打包、发布、迭代之后的回滚。

让学员收获最大的不是某段代码，而是链路本身：前端 → API → 后端 → 数据库 → 部署上线。每一段都亲手摸过一遍，demo 和生产级项目的分界线，从此是看得见的。

为什么这个案例放在这个站

它印证了这条学习路径的设计顺序。这位学员卡住的每一个点，站里都有对应的一页：

• 数据存在哪 → 数据存在哪：传单、便签和账本
• 前后端关系 → 前端与后端
• 上线在做什么 → 什么是部署、上线课

文中的「数据库三连问」和「万能上线提示词」，可以直接拿去用。

如果你也是产品、运营背景，正在用 AI 做自己的系统：**卡住你的几乎从来不是「不会写代码」，而是链路上的黑盒概念。**把黑盒一个个打开，AI 才真正从玩具变成生产力。