一天一个 vibe coding 小技巧，今天讲：怎么验收AI搭建的后端架构。
在《后端架构搭建》中，我们讲了后端架构搭建篇，也就是怎么让 AI 搭建出一个最小可运行的后端底层架构。
对于后端底层架构，你需要知道的是：这一步不是可有可无的。后面业务代码好不好写、功能好不好增加、代码会不会越写越乱，很大程度上取决于一开始的底层架构有没有打好。
在以前，一个架构完备的开发团队，往往还有系统架构师这样的角色。他会先把底层规则定好，再把业务系统里的不同功能拆成模块和开发任务，分派给不同程序员去完成。
所以对于后端来说，一个好的底层架构非常重要。
可是对于完全没有技术背景的人来说，纯靠 AI 搭完后端底层架构以后，到底要怎么验收、怎么判断好坏呢？
即便 AI 告诉你它完成了，你也很难直接判断它是不是真的完成了，更难判断这套架构后面能不能继续支撑业务开发。
因此，这一篇就接着上一小节讲：后端架构搭完之后，怎么验收。
开始学习之前，你只需要先记住一点：对于一个完全没有技术背景的人，要想验收 AI 写的后端代码，靠的不是读懂每一行代码，而是规则、示例和证据。
一、先验收的不是功能，而是规则
也许你验收的时候会直接问：这套架构搭建好了吗，能用吗？
你大概率会得到这样的回答：好了，可以开始写业务代码了。
这肯定不是合格的验收。
对于一个没有技术背景的你来说，后端架构验收阶段要看的，是以后继续加功能时，这套规则能不能立住，后续代码是不是能在这套架构体系下继续生长。
所以你要让 AI 直接交证据。
可以这样要求：
“请根据项目实际业务文档以及项目架构设计文档，对后端架构层代码做详细的审计和验收。每一项必须说明：规则来源、对应文件、验证方式、实际结果、是否通过。没有证据的项目标记为未验收，不允许写通过。”
这样要求，AI 就不能只回一句“已经完成”，而是要拿证据证明。
你不需要看懂每一行代码，但你一定要看验收结果里有没有告诉你证据在哪里，有没有把没验证的地方老老实实标出来，有没有和你后续要写的业务逻辑冲突。
如果它只说“已完成、已优化、已符合最佳实践”，但没有文件、命令、返回示例和日志结果，这就不算验收。
如果你看不懂它的解释，可以直接说：用最直观的语言告诉我，不要说一堆技术名词。
二、验收目录责任
在验收的时候，有些人因为没有技术背景，就会去看目录数量，觉得越多越专业，你可千万别被目录数量带偏了。
对于项目架构目录，不是越多越好，关键是看每个目录的责任划分是否清晰。
你可以让 AI 输出一张目录责任表：
“请根据当前后端架构，输出目录责任表。每一行包含：目录、主要职责、以后应该放什么、禁止放什么、对应的框架机制、示例文件。请标注哪些目录来自框架推荐或者框架本身，哪些是项目业务自定义的。同时请按当前框架说明：请求入口在哪里，业务规则在哪里，数据库访问在哪里，参数校验在哪里，错误处理在哪里，权限校验入口在哪里。”
你看这张表时，只看三件事。
第一，每个目录是不是只有一个清楚的主要责任。
第二，它有没有说清楚以后应该放什么、不应该放什么。
第三，它有没有说明这些目录是框架推荐，还是项目自己定义的。
如果每个目录都写“处理业务逻辑”，那就是没说清。
如果它能说明接口入口为什么不能堆复杂业务判断，数据库访问为什么不能散落在各个请求函数里，配置为什么不能写死在业务代码里，就说明规则更稳。
如果它说不清目录边界，后面新增功能时就很容易把接口、业务和数据库访问混在一起。
三、用最小模块演练，验收规则能不能落地
目录责任表只能说明 AI 会解释，不能证明它真的会按规则组织代码。
所以这一步不要让它直接写业务，而是让它做一次最小模块演练。
这个演练不看业务复杂度，只看请求链路有没有分层：请求从哪里进来，参数在哪里校验，业务规则放在哪里，数据访问放在哪里，最后怎么走统一响应和统一错误处理。
你可以直接这样要求：
“请做一次最小模块演练，不写完整业务代码，只输出文件清单和调用路径。请说明：需要新增或修改哪些文件；每个文件放在哪个目录；每个文件负责什么；请求从哪里进入；参数在哪里校验；业务规则在哪里处理；数据访问在哪里处理；统一响应和统一错误在哪里处理；这些安排是否符合项目架构设计文档。”
你看它的回答时，只看两点。
第一，文件放置有没有延续第二节的目录责任表。
第二，请求入口、参数校验、业务规则、数据访问、响应和错误处理有没有被分开。
如果 AI 每次回答的文件都不一样，或者说“都可以写在一个接口里”，这套架构就不适合继续往下堆业务。
到这里，你验的是结构能不能落地。
四、接口返回必须看示例，不能只听“统一”
接口统一返回，是后端架构里非常容易被糊弄的一项。
AI 很容易说“我已经统一了成功和失败响应”。
但你要问具体场景。
在多数 vibe coding 项目中，前端和后端交互全靠接口完成。接口格式固定下来，后面前端对接、接口调试、继续让 AI 加功能时，才不会每次重新猜返回格式。
比如：接口成功返回是有不同场景的，列表、详情对象、创建、更新、删除、空列表，这些都必须规范统一，要让它给出具体示例。
你可以直接这样要求：
“请输出当前后端架构的接口响应样例，至少包含：列表成功、详情对象成功、创建成功、更新成功、删除成功、空列表、参数错误、未登录、无权限、资源不存在、系统异常。每个场景都要给出 HTTP 状态码、响应 JSON 示例、由哪个文件或框架机制统一处理。”
这里有两个地方不要漏。
第一，列表和对象要分开看。
列表通常会涉及数组、分页、总数。对象通常是详情、创建后的数据、更新后的数据。不能一句“data 里放数据”就结束。
第二，错误不能只看业务错误码。
HTTP 状态码要尽量复用框架规范和通用标准。参数错误、未登录、无权限、资源不存在、系统异常，本来就有常见状态码。
如果项目确实需要业务错误码，也必须写进项目架构设计文档，说明错误码格式、命名规则、谁负责维护。
五、验收框架复用和封装边界
用框架的目的，就是尽量复用成熟能力。
能用框架自带的参数校验、异常处理、HTTP 状态码、中间件、日志机制，就不要让 AI 在框架外面再手写一套。
这一步专门验收框架能力有没有被正确复用。
你可以直接这样要求：
“请审查当前后端架构的框架复用和封装边界。哪些能力直接复用了框架？哪些是项目自定义封装？每个自定义封装解决什么问题？如果去掉会有什么影响？是否存在为了显得专业而提前封装的内容？”
你就看它有没有把边界说清楚：能用框架的地方有没有用框架，自定义封装有没有明确理由，这些封装规则有没有写进项目架构设计文档。
如果一个封装说不清解决什么问题，也没有被当前架构使用，只是“以后可能用”，那就先不要放进架构。
后端架构要稳，不是要复杂。
这条原则也要被后端架构实施真源文档收录，并在 agent 宪法中引用：
“后端开发必须遵守《后端架构实施真源文档》中的框架最大化利用原则。HTTP 状态码、参数校验、错误处理、路由分组、中间件、日志、依赖注入等能力，优先复用当前框架推荐机制。确需自定义时，必须说明原因，并更新后端架构实施真源文档。”
六、验收启动、配置、数据库和日志，要固定启动证据
前面验的是代码该放哪里、接口该怎么回。
这一节验的是项目以后怎么跑起来。
注意，这一步不是让你看懂所有命令，也不是让你学会部署。
它的作用是把启动方式、配置来源、数据库连接和日志入口固定下来。
否则后面继续开发时，AI 很可能又要重新猜：依赖怎么装，服务怎么启动，端口是多少，数据库配置在哪里，健康检查怎么访问。
它一边猜一边试，就会消耗很多上下文，也容易改乱原来的启动方式。
可以直接让它交一个运行证据包：
“请输出后端架构运行证据包。必须包含：依赖安装命令、启动命令、服务监听端口、健康检查命令和结果、配置读取位置、.env.example 内容检查、数据库连接验证方式和结果、请求日志示例、错误日志示例。每一项都要写明实际执行结果。没有执行的项目标记为未验证。”
你不需要逐行理解命令。
你只看它有没有把“怎么启动、用什么配置、数据库是否连上、日志在哪里看”说固定。
如果 AI 只说“理论上可以启动”，不算通过。
如果这次说一个启动命令，下次又换另一套，说明运行规则还没有收住。
最好的结果是：以后继续写业务时，AI 可以直接引用这份证据包，不需要重新猜项目怎么跑。
七、把验收结果收口成实施真源文档
前面每一步都是单项验收。
到了最后，不要让 AI 散着回答，也不要让它重新把前面的内容讲一遍。
这一步只做收口：哪些已经通过，证据在哪里，哪些还没有验证，当前后端架构能不能进入业务开发。
你可以直接这样要求：
“请汇总本次后端架构验收结果，不要重新发散，也不要重复解释前面的内容。请按以下结构输出：验收项、是否通过、证据位置、未通过原因、下一步处理、是否影响进入业务开发。最后给出明确结论：当前后端架构是否可以开始写业务功能。没有证据的项目必须标记为未验证，不能写基本完成。”
这个报告的重点，不是再列一堆技术名词。
它要帮你判断一件事：这套后端架构现在能不能作为稳定起点继续往下写。
如果关键项没有通过，比如目录责任没说清、接口返回没有示例、错误处理没有统一、启动证据没有固定，那就不要急着写业务。
如果关键项都通过了，下一步不是把所有架构约束都塞进 agent 宪法。
agent 宪法只放最高层约束，不承载所有后端细则。
正确做法是：让 AI 根据验收通过的结果，整理出一份详细的后端架构实施真源文档。
这份文档才是后面开发时真正要引用的规则文件。
它要写清楚：当前后端语言和框架、规则来源、目录责任、业务代码应该放在哪里、禁止放在哪里、新增模块怎么组织文件、接口怎么返回、错误怎么处理、启动和配置证据在哪里、数据库和日志入口在哪里、哪些地方复用框架、哪些地方是项目自定义。
然后再在 agent 宪法里写一条引用关系。
比如：
“后端开发必须先读取并遵守《后端架构实施真源文档》。新增或修改后端功能前，必须确认目录责任、接口规则、错误处理规则、启动证据和框架复用边界。任何目录调整、规则变更、框架更换或新增关键依赖，都必须先说明原因，并同步更新后端架构实施真源文档。”
详细规则放在实施真源文档里，agent 宪法只负责引用它、约束 AI 不能绕开它。
以后业务代码越写越多，也不会把 agent 宪法越写越臃肿。
八、最后
验收通过后，记得让 AI 先提交一次 Git，把这套后端架构作为第一个稳定版本。后面继续写业务功能时，就基于这个版本往下加；如果还有没验证的项，就不要让 AI 用“基本完成”糊过去，没验证就是没验证。
你不需要完全看懂证据，但每一步都要让 AI 留下可检查的结果。
其实 vibe coding 只是团队角色发生了改变。以前你要做项目，可能会找程序员说需求、理清楚需求，再让程序员开工写代码；现在你面对的是 AI，本质上还是要把需求和规则说清楚。
沟通清楚、规则写清楚、证据留下来，项目后面才不会靠猜继续写。
到这一步你也已经发现了，AI很强，但是AI也很懒，它更像是一种指令型、规则型生物，有些事情你不说，它就不会管。
