在《后端技术认知》中，我从业务角度精讲了一下后端技术认知，主要是为了让不懂技术的人搞清楚后端到底负责什么，以及有哪些主要的开发语言，怎么让AI选择语言。
这一篇就接着上一篇往下讲。
相对于前端来说，后端是很抽象，也不容易理解的。因为前端至少能看到页面。UI乱不乱、交互顺不顺，有问题很多时候一眼能看出来。
而后端的问题则会藏在接口、业务逻辑、数据库访问等等业务代码中。
对没有技术背景的人来说，你通常不是先发现代码哪里乱，而是先感受到项目越来越难改：一个小功能要改很多轮，改好一个地方又影响另一个地方，AI每次解释的结构也不一样。
所以后端会是我需要细讲的部分，我会把后端骨架搭建拆成两篇。
这一篇先讲搭建：也就是把基础规则跑通。
下一篇再讲验收：对于没有技术背景的人，怎么判断这个骨架稳不稳。
一、常见开发场景
很多人没有技术背景，用vibe coding写后端，最直接的操作就是让AI上来就写业务：我要个登录功能，我要个订单列表功能，或者再加一个支付相关功能等等。
这不是你的问题，是在很多普通人的眼里，AI被神话了，觉得什么都能做。
而且你想做项目，自然最先想到的就是功能。
当然，AI也能写，而且很快。
但如果这个后端不是一次性小脚本，而是以后还要继续加模块、继续维护的项目级后端，就不能只按功能往前堆。
这也是我在往期视频中为什么一直让你们先讨论、先立项的原因。对于后端来说，如果你已经有了一套成熟的前端项目那还好，AI只需要根据前端页面来接后端的线就可以；但如果没有这些，你就一定要和AI描述清楚你的业务逻辑和用户场景，否则AI就是在盲猜你需要什么。
就拿登录来说，你想到的可能只是用户名密码一输入，按钮一点这么一个简单的功能，但它会牵涉参数校验、身份验证、权限、错误返回、数据库读写和日志记录等等。
而常见的支付、文章列表、评论都是一样的。
如果骨架没定好，AI很容易给每个功能临时组织一套写法。
所以后端骨架阶段，不是阻止你写业务，而是在写业务之前先定规则。
只有等这些规则先定好了，后面写功能才不会乱。
在我看来，后端骨架的核心就是一句话：这个项目以后能不能按同一套规则继续写下去。
二、先把规则写进项目架构设计文档
上面这个场景其实暴露了一个问题：AI不是不会写功能，而是如果你没有提前告诉它业务边界和工程规则，它就只能边写边猜。
所以这一步不是马上让AI搭代码，而是先把两类东西写清楚。
第一类，是业务边界。
比如这个项目有哪些用户场景，你的主要业务逻辑是什么，主要功能有什么，也就是你必须要让AI清楚知道你的业务。
第二类，是工程规则。
比如后端语言和框架是什么，目录怎么放，接口怎么返回，错误怎么处理，日志怎么记录，后面新增模块应该继续按什么规则写。
把这两类东西合在一起，就是项目架构设计文档。
这份文档不是普通说明书，而是约束AI的规则文件。
对于没有技术背景的人来说，你不可能靠自己逐行看代码来判断后端结构稳不稳。你真正能做的，是先把规则写进文档，然后让AI后面所有后端开发都按这份文档执行。
写这份文档时，先确认两件事：后端语言和后端框架。
这一步不是重新做技术选型，而是复核技术路线有没有写进项目架构设计文档。
如果你已经选了Node.js、Python、Go、Java，或者其他语言，就让AI回答清楚：为什么用它，为什么不用其他方案，当前项目是否真的需要这个复杂度。
要先做这个复核，因为vibe coding最怕技术路线摇摆。
今天说Python简单，明天说Go更专业，后天说Java更稳定。对非技术用户来说，你很难判断它是在优化项目，还是只是换了一套说法。
这里顺便提一嘴语言选择。
我看很多人一上来就会选择一些比较复杂、重量级的语言，比如Java、C语言等等。
当然，这些选择没什么问题。在我个人看来，开发语言没有太大的优劣之分，只有适不适合一个项目。
Java在企业系统里很成熟，C和C++在底层系统、高性能场景里有价值。
但如果你做的是常见业务系统、后台管理、内容平台、普通API服务等等，很多时候根本不需要这么重的路线。
而且对于一个主要靠vibe coding做项目的人来说，语言越简单，理解成本越低，后期越容易维护。
但一定要注意：简单不是唯一标准，它还必须贴合你的项目。
当然，如果公司规范、历史系统、性能场景等决定必须用更复杂的语言，那是没办法的。只是这时候更要用一个成熟的框架来约束AI，优先选择AI熟悉、社区活跃、文档完整、出了问题基本上都能找到解决方案的技术栈。
还有，因为很多纯靠vibe coding的人对自己写的代码不放心，怕出什么安全问题，所以听说某个语言“更安全”，就把它当成唯一选择。
这是一定要注意的。
安全不是只靠语言决定的，决定安全的往往是业务代码。
这一步可以直接这样问：
“请根据项目架构设计文档，确认当前后端语言和框架是否适合本项目。不要重新发散选型，只判断是否存在为了高级感、性能感或者安全感而过度选型的问题。如果当前语言或框架较重，请说明项目为什么真的需要它，以及后续必须遵守哪些成熟框架规范和最佳实践。”
这段提示词的目标只有一个：把路线钉住。
路线钉住之后，就要继续让AI说明规则来源。
第一，当前语言的工程规范是什么。
比如依赖管理、配置读取、日志、异常、测试，通常怎么处理。
第二，当前框架的最佳实践是什么。
不同语言、不同框架都有自己的习惯，不能混着写。
第三，当前项目自己的架构设计文档是什么。
语言和框架只能告诉你一般怎么写，但它不知道你的用户、订单、权限、支付这些模块应该怎么分。
这也是本系列视频的实战篇为什么开头就讲立项的原因。
立项文档解决的是“项目要做什么”。
语言和框架解决的是“代码按什么规范写”。
后端骨架要做的，就是把这两部分合到项目架构设计文档里，让AI既知道你要什么，也知道该按什么规则搭一套干净、可维护、可扩展的底层架构。
所以后端骨架最后一定要落到项目架构设计文档里。
它要说明：哪些目录来自框架推荐，哪些目录是项目自定义，为什么这样自定义，如果偏离框架常见写法，原因是什么，以后新增模块应该继续按什么规则放文件。
这里还要加一条约束：框架最大化利用。
用框架，就是为了少踩坑。HTTP状态码、参数校验、错误处理、中间件、日志、路由分组，很多成熟框架本来就有推荐写法。
能用框架自带能力，就不要让AI在框架外面再手写一套。
这条建议写进agent宪法：
“后端开发必须遵守当前语言工程规范和框架最佳实践，优先复用框架能力。新增依赖、目录调整、错误码自定义、框架更换，都要先说明原因，并更新项目架构设计文档。”
写项目架构设计文档时，可以这样要求AI：
“请根据立项文档和已确定的后端语言、框架，整理项目架构设计文档。不要写业务代码。文档必须写清楚：后端语言和框架、选择原因、不选其他方案的原因、必须遵守的语言工程规范、必须遵守的框架最佳实践、框架最大化利用原则、目录约束、接口响应规则、错误处理规则、日志规则、数据库连接方式、权限校验入口，以及以后新增模块应该怎么放文件。”
这一步做完之后，你才进入真正的骨架搭建。
三、再根据文档搭建最小可运行后端骨架
当项目架构设计文档写清楚之后，再让AI根据文档开始搭建后端骨架代码。
这里一定要强调：是根据文档搭建，不是重新自由发挥。
你可以这样要求AI：
“请严格根据项目架构设计文档，基于当前后端语言和框架，按照该语言工程规范、该框架官方文档或主流最佳实践，搭建最小可运行后端骨架。先说明目录结构、目录作用、哪些是框架推荐，哪些是项目自定义。不要先写完整业务功能。骨架必须包含：项目启动入口、环境变量配置、路由分组、健康检查接口、数据库连接、统一响应格式、统一错误处理、日志、基础参数校验、权限中间件占位、README启动说明。”
这段提示词不需要写得特别复杂，但里面有几个约束不能丢。
第一，必须基于当前语言和框架。
第二，必须遵守语言规范和框架最佳实践。
第三，必须根据项目架构设计文档执行。
第四，必须先解释目录结构，再写代码。
第五，只搭最小可运行骨架，不写完整业务功能。
如果它解释不清楚目录作用、规则来源和自定义原因，先不要继续。
后端骨架不是业务开发，这一阶段不要贪功能，主要是先跑通四条线。
不要一上来就写完整登录、完整订单、完整支付。这些都应该放到后面的业务模块里。
第一，启动线。
项目必须能启动，配置必须能读取。端口、数据库地址、密钥不要写死在代码里，要有配置样板，比如.env.example。同时要有健康检查接口，比如/health。
这条线解决的是：这个后端能不能正常跑起来。
第二，接口线。
路由放在哪里，要符合当前框架习惯。接口返回要统一，但不能只说“成功失败统一”。
你要确认两类成功场景：列表和对象。
列表一般涉及数组、分页、总数；对象一般是详情、创建后的数据、更新后的数据。
失败场景也要统一。参数错误、未登录、无权限、系统异常，HTTP状态码要尽量复用框架规范和通用标准。
如果确实需要业务错误码，先写清楚规则，不能让AI想到哪写到哪。
这条线解决的是：以后前端、接口测试、继续用vibe coding加功能时，能不能按同一套接口规则对接。
第三，业务线。
接口层只处理请求和响应，业务规则放到业务层，数据库读写放到数据层。
但不要死记目录名。
不同框架叫法不一样。有的叫controller、service、repository，有的叫handler、usecase、model，有的轻框架不一定强制这些名字。
你要让AI按当前框架解释：请求入口在哪里，业务规则在哪里，数据库访问在哪里，参数校验和权限校验在哪里。
如果某个框架没有对应概念，就让它说明用什么框架机制替代，而不是自己新造一套。
这条线解决的是：以后新增功能时，不会把请求、业务判断和数据库操作全堆在一个函数里。
第四，运维线。
日志要有，统一错误处理要有，数据库连接要能验证，权限校验要有占位，README要写清楚怎么启动、怎么配置、怎么测试。
这些不是高级功能，而是后端以后能不能继续迭代的基础。
这条线解决的是：项目出问题时，能不能启动、能不能查日志、能不能知道数据库和权限这些基础入口在哪里。
四、最后
最后再把这一篇收一下。
后端骨架搭建，不是让AI上来就把登录、订单、支付都写出来。
这些功能当然重要，但它们应该建立在同一套规则上。
所以这一步真正要做的，是先把业务边界、语言框架、目录约束、接口规则、错误处理、日志规则这些东西写进项目架构设计文档。
然后再让AI根据这份文档去搭建最小可运行后端骨架。
这样做的目的，不是让你变成后端工程师，而是让AI后面写每一个功能时，都有规则可以遵守。
下一篇我们再讲后端骨架验收。
也就是没有技术背景的人，怎么判断这个骨架到底稳不稳，而不是只听AI说“已经完成了”。
