前面讲了前端，也讲了数据库。到这一步，就要进入后端了，按节奏来说应该是准备进入后端骨架搭建的，因为在之前的视频中讲过后端技术认知。但我发现那个讲的不太全面，只是讲了一下后端技术的大概，没有从业务角度出发。
因此本小节主要从业务角度出发，精讲一下后端的技术认知。
后端讲起来是比较抽象的，它不像前端，能直接看到页面。也不像数据库，你可以看到一堆表，即便你看不懂表语句，你也可以从excel的角度去理解数据表，它们其实是差不多的。
然而，后端则是偏逻辑性的，它是藏在产品后面的那套处理逻辑，逻辑这个东西是讲不清楚的。
这里需要插一句题外话，之前群里有人问我，看逻辑学的书对后端有没有帮助，这里需要说清楚的是，后端逻辑指的是程序运行逻辑，程序运行逻辑往往取决于你对项目业务的认知以及你的思维能力，这个和专业的逻辑学没太大关系。
在本小节中，我先用一个简单说法：凡是用户看不见，但负责业务逻辑、数据处理、权限校验、接口调用、任务执行的部分，我们都先归到后端。
前端负责让用户操作。
数据库负责存数据。
后端负责判断这件事能不能做、该怎么做、做完之后数据要不要存进数据库、数据库已有的数据要不要变化？
比如用户登录。
页面上输入手机号和密码，这是前端。
用户信息存在表里，这是数据库。
但用户是否注册、密码是否正确、账号有没有被封、登录状态怎么生成，这些是后端处理的。
再比如用户下单。
页面上选择商品和地址，这是前端。
商品、用户、订单这些数据存在数据库里。
但库存够不够、价格对不对、优惠券能不能用、订单状态怎么流转，这些是后端处理的。
所以后端不是一个玄乎的名词。
它本质上就是产品背后的业务处理层。
一、先分清两种后端场景
新人接触vibe coding，一般会遇到两种后端场景。
第一种，是小脚本。
比如批量整理文件、处理表格、生成报表、压缩图片、调用某个API、定时跑一个任务。
这种不一定要做成完整项目，一个脚本就够了。
我一直说，vibe coding很重要的意义在于技术平权。
它不是让每个人都变成程序员，而是让不懂技术的人，也能用技术解决自己的实际问题。
以前你不会写代码，很多重复劳动只能自己做。
现在你可以让AI帮你写一个小脚本，自动整理资料、处理数据、生成结果。
这件事本身就很有价值。
所以，你不需要因为自己没掌握AI就焦虑。
技术是工具，不是人生标准。
能掌握就用它省时间；暂时掌握不了，也没什么大不了。好好生活才是正道。
小脚本这类需求，逻辑通常没那么复杂，现在的AI也比较容易写出来，所以这篇不展开讲。
第二种，是项目级后端。
比如用户系统、订单系统、内容发布、权限管理、支付回调、后台审核、数据统计。
这种后端就不是一个小任务了。
它是在支撑一个产品的业务逻辑。
这篇主要讲的，就是项目级后端。
二、项目级后端到底管什么
在我看来，项目级后端，主要管三件事。
第一，业务规则。
比如：谁能登录，谁能下单，什么状态可以退款，什么内容需要审核，什么操作必须管理员才能做。
这些规则不能只写在前端。
因为前端是用户能接触到的地方，页面上的很多东西都可以被绕过或篡改。
真正关键的判断，必须放在后端。
第二，数据流转。
前端提交数据之后，不是直接塞进数据库。
后端要先校验，再处理，最后再决定怎么写入数据库。
比如保存文章，要判断标题是否为空、内容是否合法、用户有没有发布权限、是否需要审核。
比如创建订单，要判断库存、价格、优惠券、收货地址、支付状态。
第三，接口协作。
在大多数业务项目里，前端和后端是通过API协作的。
API你可以先理解成：前端和后端之间约定好的沟通入口。
前端说我要登录，后端返回是否成功登录或者登录失败，为什么登录失败等等。
前端说我要订单列表，后端返回当前用户能看到的订单数据。
前端说我要提交评论，后端判断这条评论是否合法、合规，然后讲评论写入数据库。
所以在现代的多数业务场景中：后端经常表现为API接口。
但API只是入口，背后的业务判断才是重点。
三、认识一下常见的后端语言
后端语言有很多，目前市面上常见的包括Java、Go、Python、Node.js、PHP。
这些名字不需要一次学会，但至少要先知道它们大概适合什么场景。
因为你有了基本认知，后面AI推荐方案时，才不会完全听不懂它在说什么。
简单说一下。
Python很常见，业内有对此流传着一句话：人生苦短，我用PY。
我还听说Python现在已经进入初中学生课堂了，
所以组件python简单、强大，在我看来它适合做一些小脚本、自动化、数据处理、AI应用，也可以做轻量后端。
Node.js适合前后端语言统一的项目。如果前端本来就用JavaScript或TypeScript，后端继续用Node.js，理解成本会低一些。
Java很成熟，适合企业后台、复杂业务系统、大型项目，但整体结构会相对重。
Go部署简单，性能好，适合现代API服务、并发任务、云服务，也适合很多中小型后端项目。
PHP是成熟的Web开发语言，在技术人员和技术还不普遍的时候，PHP可以说是互联网的王牌语言，成就了无数互联网奇迹和财富。
在我看来PHP也是容易上手的。
但是，因为你不是专业的程序员，你的重点是和AI写作去实现一个项目，所以你不需要把这些语言都学一遍。
你真正要做的是让AI根据项目情况，给你一个当前最适合的语言。
可以这样问AI：
“请根据我的项目类型、核心功能、用户规模、数据库方案、部署方式、后期维护难度等等，推荐一个最适合当前项目的后端语言。只给一个主推荐方案，不要列多个选择题，并说明为什么选它，为什么不选其他方案。”
这里重点是唯一推荐。
前面我也说过了，非技术用户最忌讳的就是技术路线摇摆。
今天觉得Python简单，明天觉得Go专业，后天又觉得Java稳，项目很快就乱了。
四、框架比语言更影响项目质量
语言选完之后，还要选框架。
你可以这样理解：语言决定用什么写。
框架决定按什么规矩写。
框架会影响目录怎么分、接口怎么组织、数据库怎么连接、错误怎么返回、权限怎么接入、日志怎么记录。
这里也不用上来背一堆框架名。
你只要先理解框架大概分两类。
一类偏轻，主要处理路由和API。
它灵活，但很多项目规范、模块都需要你自己补。
另一类更完整，除了API，还会提供项目结构、数据库支持、配置管理、权限能力、命令行工具、任务处理等。
对非技术用户来说，如果是后台系统、SaaS、订单系统、权限复杂的项目，我更建议优先考虑后者。
因为规则越清楚，AI越不容易乱发挥。而框架模块更完善，也就是减少AI自己胡乱组织。
注意：无论是前端还是后端，假设你不具备专业知识，不具备驾驭AI的能力，就一定要用框架去约束AI，让AI在框架下跳舞。
如果只是轻量接口、小工具、内部服务，轻框架也可以，但你要让AI把目录规范、数据库访问、参数校验、权限、错误返回这些补清楚。
你可以这样问AI：“请基于已选后端语言，推荐一个适合当前项目的后端框架。说明它适合什么场景，官方目录规范是什么，哪些能力框架自带，哪些能力需要额外SDK或库。优先选择成熟、文档完整、社区活跃、AI熟悉度高的方案。”
不要为了看起来高级，选一个资料少、AI也不熟的方案。
你不是在比技术名词。
你是在做一个能跑、能维护、能继续迭代的项目。
五、和AI交流时，先问业务，不要先问代码
新人让AI写后端，最常见的错误是直接说：
帮我写登录接口。
帮我写订单接口。
帮我写后台接口。
这样问，AI很容易直接开始写代码。
但你真正需要的，不是先让它写接口，而是先让它把项目的后端技术边界讲清楚。
你可以先问：
这个项目的后端主要负责哪些业务逻辑？
前端需要通过哪些API和后端交互？
每个API背后有哪些业务校验？
每个API会读写哪些数据库表？
哪些接口需要登录后才能访问？
哪些接口需要管理员权限？
用户身份认证准备怎么做？
权限校验放在哪一层？
错误返回格式怎么统一？
后端适合用什么语言和框架？
这个框架自带哪些能力，哪些能力需要额外SDK或库？
你也可以直接给AI这段提示词：
“先不要写代码。请基于当前项目的前端流程、数据库设计和业务需求，分析这个项目的后端技术方案：后端要负责哪些业务逻辑，前端需要哪些API，每个API涉及哪些数据库表、权限校验、参数校验和异常情况；同时推荐一个适合当前项目的后端语言和框架，并说明框架自带哪些能力，哪些能力需要额外SDK或库。”
这段话的核心是：先把后端技术边界讲清楚，再写代码。
你不是让AI立刻开工。
你是在让AI先说明：后端负责什么、API怎么分、权限怎么校验、数据库怎么交互、语言和框架为什么这么选。
六、讨论结果要写进真源文档
后端语言、框架、API边界、业务规则确认之后，一定要写进项目真源文档。
因为后面AI搭后端骨架、写接口、接数据库、做权限，都要按这份文档来。
文档里至少写清楚：
后端语言和框架选什么。
为什么选它。
哪些方案不选。
后端负责哪些业务逻辑。
前端需要哪些API。
哪些规则必须在后端校验。
你可以直接告诉AI：
“请把本次后端语言、框架、API边界和业务规则写进项目真源文档。后续后端开发必须以这份文档为准；如果要更换语言、框架或核心SDK，必须先说明原因，并更新文档。”
这一步的核心，是防止AI中途换路线。
七、最后
后端不是简单写几个接口。
对大多数业务项目来说，后端负责的是业务逻辑、数据流转、权限校验和API协作。
如果你只是做小脚本，就用最简单的方式解决具体问题，不要硬上完整后端。
如果你做的是项目级产品，就要先搞清楚后端负责什么，再让AI帮你选语言、选框架、梳理API和业务规则。
讨论完成之后，一定要把这些选择写进项目真源文档。
这一篇讲的是后端技术认知。
下一篇再讲怎么搭建后端项目骨架。
