写给普通人的 Vibe Coding 前必懂简洁技术词典！！
这篇文章我希望用更加易懂的方法讲解，推荐先看配图，不懂的地方再结合文本食用
我昨天和一个同学交流，他说他vibecoding太慢了，后来发现是底层技术名词都不太了解就想上手做软件
还有很多同学想找我学习vibecoding，于是想写一篇先导文章，用易懂的语言讲讲一些技术名词。
很多第一次做 vibe coding 的人，摔倒的位置其实比想象中更早
AI 把开工门槛拉低了，也顺手放大了一种错觉：词越多，完成感越强，页面一亮，像是产品已经做出来了，域名一买，像是已经上线了，数据库一接，像是自己在搭平台。
可只要地图没分清，后面走得越快，返工也会越快。
所以这篇文章只干一件事：先把这些词用人话讲明白。你不用先学成工程师，也不用背一堆定义。你只要先分清，每一层到底在管什么，第一次做产品时顺序就不会那么容易走反。
这些词为什么总能把人绕晕
原因很简单：它们总是同时出现。
AI 给你一整套方案时，聊天框里经常同一分钟冒出前端、后端、API、数据库、部署、域名、环境变量。
对老手来说，那是在拆技术架构。对新手来说，更像一次性端上来一桌陌生菜名。你还没吃出味道，已经先被名字震住了，最后只能“叽里咕噜说啥呢，接受计划”
再加上很多教程爱从“完整方案”讲起。
架构图、服务图、模块图、流程图，一张比一张像在做大项目。
普通人最容易在这里被骗到：看起来越完整，越像自己已经进入了正式开发，最后进度被这些有的没的拖死。
第一次做产品，最好的方向，从来都落在先认清哪一层在干什么、哪一步该先动上。
还有一个隐蔽的坑：AI 太配合了。
你说想做一个产品，它会立刻给你技术栈、数据库设计、权限系统、部署建议、未来扩展方案。你会有一种很强的推进感，像是团队已经开起来了。
可很多时候，真实进度还停在“我甚至不知道用户点下第一个按钮以后，事情该往哪儿走”。
词一多，人就容易拿“理解了一堆名词”误当成“已经能把东西做出来”。这篇文章真正要拆掉的，就是这种完成感幻觉。
前端：用户手能摸到的那一层
先从前端开始。
因为用户第一眼碰到的，就是它。
页面长什么样，按钮放哪，输入框怎么填，点完以后有没有反应，加载时转不转圈，结果页长什么样，这些都算前端。
如果把产品想成一家店，前端更像门头、菜单和收银台。
客人愿不愿进门，进门后会不会迷路，先看这里。
很多人会把前端理解成“外观层”或者“美工层”，这会把它看轻。
页面好不好看当然重要，但前端更大的作用，是把交互讲清楚。
你让 AI 先把前端做出来，页面会不会更漂亮反倒是次要的。更值钱的是，那些原本容易被你糊弄过去的问题，会突然一个个冒出来。用户
第一步点哪？点完要等多久？失败了看见什么？结果要不要保留？能不能返回上一步？
很多想法只要一落到页面上，真假就开始分了。
比如你说自己想做一个“AI 帮你改简历”的小工具。
光听这个名字，脑子里很容易觉得已经挺完整了。
可一旦开始做前端，问题马上会变得很具体
用户是上传 PDF，还是直接粘贴文本？点“开始优化”以后，按钮要不要先变灰？等 10 秒没结果，用户会不会以为卡死了？改完以后，是整份重写，还是一句句对照？这一层不理顺，后面模型再强，用户体验也会像在跟空气对话。
很多新手第一次做产品，往往会把注意力全压在“自己会不会写前端”上，却没意识到前端还负责建立信任。
按钮点下去没反应，用户不会心疼你的架构。他只会觉得这东西不行。页面看起来乱，流程断在半路，用户也不会因为你用了更高级的模型就多给一次机会。
所以前端很像产品的第一轮面试。用户先看到它，再决定要不要继续给你时间。
后端：按钮按下去以后，背后到底谁在干活
用户点完按钮，事情并没有结束。很多时候，真正的处理才刚开始。
后端更像后厨和店员调度。有人下单以后，谁去做，先查什么，再算什么，做完以后把什么结果送回来，这一段多数都在后端。
比如你做一个“把一段文字变成摘要”的小产品。
用户在页面里输入文字，这是前端在接人。
点下提交以后，系统要去调用模型、检查输入有没有问题、决定把什么结果回给页面，这条路多数发生在后端。
这时顺手理解一个经常把人吓住的词：API。你可以把它当成零件之间说话的规矩。
前端找后端拿结果，后端找模型服务办事，它们都不是靠心灵感应，全靠一来一回的规则。
你给我这个，我回你那个，这就够了。听起来很技术，落到人话层面，其实就是“不同零件怎么接上话”。
很多新手会把后端和数据库连成一个东西。
这样一混，后面很容易乱。后端负责办事，数据库负责记住办过的事。一个偏动作，一个偏记忆。它们经常一起出现，但不是一回事。
你可以把后端想得再接地气一点。
**前端像服务员，把客人的需求接过来；后端像店里真正会做事的人，知道这单该送去哪里、该查什么、该让谁先动。**用户只看到了按钮和结果，中间那一大段脏活累活，很多时候都藏在后端。
为什么很多人会过早被后端吓到？因为一说后端，脑子里就开始自动联想到“服务器”“数据库”“接口”“权限”“支付”“消息队列”这些更大的词。听起来像一整栋楼。可第一次做小产品，后端常常没那么夸张。很多时候它只是在负责几件朴素的事：接住请求、做判断、去拿结果、把结果送回来。
前端如果只是一个漂亮页面，后端没接上，那按钮就很像商场里的假电梯。你按下去会亮一下，心里也会短暂觉得“它应该在工作”，可门根本不会开。
用登录这件小事，看一遍前端和后端怎么接上
如果你还是觉得前端、后端、数据库有点飘，拿登录来想会很快。
用户先在页面里看到两个输入框，一个填账号，一个填密码，还有一个登录按钮。
这一层就是前端。
它负责把东西摆到用户面前，让用户能输入、能点击、能看到“登录中”“密码错误”或者“登录成功”这些反馈。
用户点下登录按钮以后，前端不会自己判断密码对不对。
它更像是把一张单子递出去：这是用户刚刚填的账号和密码，请你处理一下。
这个“递出去”的动作，通常就是前端通过一条 API 去找后端。
后端接到这张单子以后，才开始真正干活。它会先看这份输入合不合理，再去数据库里翻账本，看看这个账号存不存在，对应的密码信息对不对。
如果查到了，后端还要决定接下来给这个用户什么登录状态，告诉系统“这个人已经通过了”。如果没查到，或者密码不对，它就把失败原因回给前端。
数据库在这里并不负责判案。它更像档案室。
后端问它：“这个账号在不在？它之前存的资料是什么？”数据库把记录翻出来，后端再继续做判断。
最后，后端把结果回给前端。前端拿到“登录成功”，就让页面跳到首页，或者把用户头像显示出来；拿到“密码错误”，就把错误提示贴回输入框下面。
这条链路一旦想顺，前后端的分工就清楚很多了。
前端负责接人和反馈，后端负责处理和判断，数据库负责把该记住的东西存着。很多人第一次做产品，脑子里这些词总缠在一起，是因为没把它们放回同一个具体动作里看过。
这个例子还有一个很重要的好处：它能让你看懂，为什么“前端做好了”不等于“功能就通了”。登录页再漂亮，如果后端没接上，用户填完账号密码也进不去。后端接上了，如果数据库里根本没有账号记录，登录照样会失败。三层只要少一层，用户感受到的结果都一样：进不去。
所以以后你再听到“登录功能还没通”，脑子里最好能自动拆成三句：页面能不能收输入，后端有没有接住请求，数据库里有没有正确记录。很多技术名词一旦能拆回这种人话问题，恐惧感会小很多。
数据库：产品为什么能记住你
数据库更像仓库加账本。
谁来过，做过什么，上次停在哪，下次还能不能接上，这些通常都和数据库有关。你做聊天产品，要不要记住聊天记录；你做工具产品，要不要记住用户上次的输入；你做内容产品，要不要记住草稿和版本，这些都属于“要不要把东西存下来”的问题。
第一次做产品时，数据库经常上得太早。
页面还没顺，交互还没稳，仓库先搭得像商场。
等你后面一改流程，前面的字段、结构、关系也跟着一起返工。
更稳稳健的做法往往简单得多：先用假数据（Mock把路走通，等你真的知道哪些东西值得长期记住，再决定数据库怎么上。
你会发现，很多第一次做的小产品，刚开始并不急着需要一个很重的数据库。
它更需要的是一个能跑通的页面，一个能得到结果的按钮，和一条能被真实使用的最短路径。
数据库这个词吓人的地方，在于它很容易让人脑补成一间特别正式的机房。其实你先记住一句更有用的话就够了：数据库解决的是“产品会不会失忆”。
用户今天传了一份资料，明天再回来，你还认不认得他？他上次做到一半的内容，下次能不能接上？他刚改过的设置，刷新以后会不会全没了？这些问题都跟数据库有关。
如果没有数据库，很多产品会像短期记忆很差的人。
你刚跟它说完话，转头它就忘了。你刚填完一堆东西，一刷新全没了。用户会很崩，因为他心里冒出来的多半只有一句话：这玩意儿一点都不可靠。
但另一头也很危险。有些人刚开始做产品，最先搭得最完整的就是数据库，像还没开店先把仓库修成物流园。
这样做看起来很踏实，实操里却经常让自己先背上一堆维护负担。第一次做产品，记忆这件事当然重要，可它排在“先让产品活起来”后面会更稳。
别人为什么打不开：服务器、部署、域名放在一起讲
到了这里，最容易把人绕晕的三个词就都来了：服务器、部署、域名。
你在自己电脑上把产品跑起来，只能说明它在你这台机器上活着。别人能不能访问，还差好几步。很多人第一次做产品最强的误会，就出在这里。本地能开，只代表你家的厨房能开火。路人能不能进门，还没发生。
服务器可以理解成那台对外运行的电脑，或者那块对外运行的空间。你得把东西放到那里，外面的人才有机会访问它。它像你租下来的铺位，店总得先有个落脚点。
部署更像“把店搬出去并且把门打开”。你在本地写好的代码，要被搬到那台对外运行的机器上，还要确认它真的启动、真的没死、真的可以让别人访问。很多产品卡住，常见情况是代码还只活在作者自己的电脑里。代码写没写完，反倒经常不是最先该追的问题。
域名最后再讲，因为它最容易被误会成“上线”本身。域名更像门牌号，或者一个更好记的网址。你买了域名，只是拿到了一个入口名字。它不会替你部署，也不会替你把服务跑起来。店还没开，门牌先挂上去，路人照样进不来。
这三个词一旦分清，很多焦虑会立刻变具体。页面打不开时，你至少知道该先问哪一句：东西到底还在我电脑里，还是已经部署到外面了？部署出去以后，服务到底有没有启动？域名到底有没有正确指过去？
这三者之所以总被说乱，是因为它们经常在同一天出现。你写完一点代码，就开始想“要不顺手买个域名”；买完域名，又会开始查服务器；查完服务器，就觉得好像已经离上线不远了。可真实情况经常更像一串连环待办，只是被压缩成了一个“上线”。
你甚至可以这么记：
- 服务器回答的是：东西放哪儿跑。
- 部署回答的是：东西有没有真的搬过去并启动。
- 域名回答的是：别人怎么更方便地找到它。
只要这三句分开了，很多新手期的慌乱会立刻降下来。
还有个特别现实的小坑。你自己的电脑一合盖，程序可能就跟着睡了；你把本地窗口一关，页面也可能直接没了。很多人第一次把链接发出去后，隔半小时一看发现打不开，心态会瞬间崩。其实问题往往很普通：它从头到尾就没被放到一个真正对外稳定运行的地方。
所以“别人能打开”这件事，本身就是一次筛选。只活在自己电脑里的产品，严格说还停在半成品阶段。
为什么本地能跑，上线就炸：密钥和环境变量
很多人第一次遇到这种情况，会以为出了玄学问题。
其实常见原因很朴素。你电脑里偷偷帮你存了不少东西：模型服务的 key、数据库密码、第三方账号、回调地址。你在本地调试时，这些配置已经躺在本机里，所以一切看起来都很顺。等东西搬到外面，那些钥匙没带过去，门自然打不开。
工程里有人会把这些配置放进一个叫“环境变量”的地方。你不用先背住这个词。把它想成后台钥匙柜就行：哪些钥匙该放进去，少了哪把门会打不开，放错了又会出安全问题。第一次做产品，管好这些钥匙，比背定义实用得多。
这也是为什么很多人会觉得“它在我电脑里明明好好的，怎么一上线就像变了个人”。常见情况更像是你自己的电脑替你偷偷兜了很多底。文件路径在本地有，密钥在本地有，测试数据也在本地有。等你把产品搬出去，那些隐形扶手一下全没了，问题就开始一层层露出来。
密钥这件事还带一点危险。很多新手图省事，会把它直接写进前端代码里，或者截个图发给别人看。这样做很像把收银台密码贴在店门上。短期看省事，长期看非常容易出事故。第一次做产品，先别把所有安全细节都学成专家级，但至少要有个基本感觉：钥匙该放在后台，不该挂在门口给路人看。
日志：出事以后，先别猜，先看现场
日志更像监控录像、病历和小票。用户什么时候点了按钮，系统有没有收到，卡在哪一步，哪一行开始报错，很多线索都在里面。
没有日志的时候，你和 AI 的排障对话很容易变成隔着电话修车：“它坏了。”“哪里坏了？”“反正就是打不开。”这时候模型再强，也得靠猜。你给它的现场不够，它就只能陪你一起盲猜。
有了日志以后，事情会一下子具体很多。你会知道出错是在前端、后端、数据库，还是部署以后；你会知道是接口没回、密钥没配，还是服务根本没启动。
所以产品一出问题，先别急着换模型、换工具、换 prompt。先看日志。看不到日志，就先把日志接上。你给 AI 的现场越完整，它越像修理工；现场越少，它越像陪你一起猜谜的人。
拿前面的登录例子来说，没有日志时，你只知道一件事：用户说自己登不上。到底是密码输错了，前端没把请求发出去，后端报错了，数据库里没记录，还是部署后环境变量丢了，你根本分不清。
有日志以后，排查会像开灯。你可能会看到：前端请求已经发出，后端确实收到；后端去查数据库时，提示账号不存在。那问题就很清楚了。或者你会看到：后端刚一启动就因为缺少密钥直接报错，那这时再去折腾前端页面，基本就是绕路。
这就是为什么我会说，日志这个词很值得先记住。它不华丽，也不性感，甚至很多教程不会把它当标题党材料。可它常常决定了你是在排障，还是在许愿。
第一次做产品，顺序最好土一点
第一次做产品，顺序越朴素，越不容易死在第一周。
- 先把页面和交互做出来。先让人能看到它、点动它，很多假需求会在这一步自己露馅。
- 先用假数据跑通。别一上来就急着接一切真实服务，先确认这条路值不值得走。
- 再补真正处理事情的那一层。到这时你才更清楚，后端到底是在接什么、算什么、回什么。
- 再决定哪些东西值得长期记住。数据库在这一步之后长出来，通常会更贴近真实需要。
- 把产品部署出去。让别人真的能打开、真的能用，产品才算第一次离开你自己。
- 最后再接域名、补日志、管好密钥，把“能用”慢慢补成“稳得住”，把“只能自己玩”补成“别人也敢点开”。
这条顺序看起来不高级。可很多看上去很高级的返工，都是因为前面少走了这几步。第一次做产品，先别急着追求一个完整系统。
先让一条最短路径活起来，后面那些词东西才会开始各归各位。
AI 让做产品这件事更快了，也让很多人更容易在第一周就产生一种“我已经在搭系统”的幻觉。
先把地图认清，速度才有意义。
前端管你给别人看到什么，后端管事情怎么在背后流动，数据库管产品记住什么，服务器和部署管别人能不能进门，域名管别人怎么找到你，日志管出了事以后你有没有现场。
这些词一旦分清，后面很多东西都会顺下来。
最后关于coding或者计算机/AI相关知识有任何问题都可以随时私我~
