Vibe Coding立项：验收后端架构

概览部分

内容摘要

本文详细讲解了如何对AI生成的后端架构进行有效验收，特别是针对没有技术背景的用户。文章从多个维度出发，包括规则验证、目录责任划分、最小模块演练、接口返回规范、框架复用边界、启动配置固定以及实施真源文档整理等，提供了一套完整的验收流程和方法论。通过明确的规则和证据要求，确保AI生成的后端架构具备良好的扩展性和稳定性。

核心观点

• 验收不是看功能是否可用，而是看规则是否清晰、证据是否完整
• 目录数量不重要，关键在于职责划分是否清晰
• 最小模块演练是检验架构落地性的关键步骤
• 接口返回必须有具体样例，不能只说“统一”
• 框架能力应最大化复用，避免重复封装
• 启动配置需要固定证据，防止后续开发混乱
• 实施真源文档是后续开发的唯一依据

---

目录

1. 验收的核心原则与目标
2. 验收规则的来源与证据要求
3. 目录责任划分与审计
4. 最小模块演练：结构落地性验证
5. 接口返回规范与错误处理
6. 框架复用与自定义封装边界
7. 启动配置与运行证据固定
8. 实施真源文档的整理与引用
9. 总结与行动建议

---

1. 验收的核心原则与目标

1.1 验收不是看功能，而是看规则

在使用AI搭建后端架构后，很多非技术人员会直接问：“这套架构搭好了吗？能用吗？”但这种提问方式并不科学。对于没有技术背景的人来说，验收的重点不是功能是否可用，而是看规则是否清晰、证据是否完整。

核心观点: 验收的关键在于规则是否可验证、证据是否可追溯，而不是功能是否完成。

一套好的后端架构应该能够支撑后续业务代码的开发，而不仅仅是完成当前的功能。因此，我们需要通过一系列规则和证据来判断AI生成的架构是否合格。

---

2. 验收规则的来源与证据要求

2.1 验收规则的来源

为了确保AI生成的后端架构符合预期，需要让AI根据项目实际业务文档和架构设计文档进行详细的审计和验收。每一项规则都必须说明其来源、对应的文件、验证方式和实际结果。

关键观点: 验收时要让AI交出证据，而不是依赖他的一句话“已经完成”。

2.2 验收证据的类型

• 规则来源：如项目架构设计文档、业务需求文档
• 文件位置：如/src/controller、/src/service
• 验证方式：如代码检查、日志分析、测试用例
• 实际结果：如是否通过、是否未通过

如果AI无法提供这些证据，就说明它没有真正完成架构搭建，只是表面应付。

---

3. 目录责任划分与审计

3.1 目录责任表的重要性

很多人在验收时会关注目录数量，觉得越多越专业。但实际上，目录数量并不是关键，关键是每个目录的责任划分是否清晰。

关键观点: 目录不是越多越好，而是越清晰越好。

你可以让AI输出一张目录责任表，每行包含目录主要职责、以后应该放什么、禁止放什么，以及对应框架机制或自定义内容。

3.2 验收目录责任的三个要点

1. 每个目录是否只有一个清楚的主要责任？
2. 是否说明了以后应该放什么、不应该放什么？
3. 是否说明了这些目录是框架推荐还是项目自定义？

如果目录责任不清，后期新增功能时很容易出现逻辑混杂、代码混乱的问题。

---

4. 最小模块演练：结构落地性验证

4.1 为什么需要最小模块演练

目录责任表只能说明AI会解释，但不能证明他真的会按规则组织代码。因此，这一步不要让他直接写业务，而是让他做一次最小模块演练。

关键观点: 最小模块演练是为了验证架构规则是否能够真正落地。

4.2 演练内容与要求

• 请求链路是否分层？
• 参数在哪里校验？
• 业务规则放在哪里？
• 数据访问在哪里处理？
• 统一响应和错误处理是否分开？

请让AI输出文件清单和调用路径，说明需要新增或修改哪些文件，每个文件放在哪个目录，每个文件负责什么。

---

5. 接口返回规范与错误处理

5.1 接口返回必须有具体事例

统一接口和返回格式是后端架构中非常容易被糊弄的一项。AI可能会说“我已经统一了成功和失败响应”，但你需要具体场景的事例。

关键观点: 接口返回必须有具体例子，不能只说“统一”。

你可以这样要求：

请输出当前后端架构的接口响应样例，至少包含列表成功、详情、对象成功、创建成功、更新成功、删除成功、空列表、参数错误、未登录、无权限资源、不存在系统异常等场景。

5.2 错误处理的规范

• 列表和对象要分开看
• 错误码要规范，且需写进项目架构设计文档
• HTTP状态码尽量复用框架规范和通用标准

如果AI无法给出这些细节，说明他的架构不够稳定，不适合继续开发。

---

6. 框架复用与自定义封装边界

6.1 框架复用的重要性

使用框架的目的是尽量复用成熟能力。例如，参数校验、异常处理、HTTP状态码、中间件日志、依赖注入等能力应优先复用。

关键观点: 框架能力应最大化复用，避免重复封装。

6.2 自定义封装的边界

请审查当前后端架构的框架复用和封装边界：

项目	是否复用框架	自定义封装	解决问题	影响
参数校验	✅	❌	无	无
异常处理	✅	❌	无	无
日志机制	✅	❌	无	无
自定义封装A	❌	✅	提高可维护性	可能增加复杂度

如果一个封装说不清解决什么问题，也没有被当前架构使用，只是以后可能用，那就先不要放进架构。

---

7. 启动配置与运行证据固定

7.1 固定启动配置的意义

启动配置是项目能否顺利运行的关键。如果没有固定证据，后续开发时AI可能会重新猜，导致上下文混乱。

关键观点: 启动配置必须固定，否则后续开发将变得不可控。

7.2 运行证据包的要求

请输出后端架构运行证据包，包含以下内容：

• 依赖安装命令
• 启动命令
• 服务监听端口
• 健康检查命令和结果
• 配置读取位置
• 数据库连接、验证方式和结果
• 请求日志示例
• 错误日志示例

每一项都要写明实际执行结果，没有执行的项目标记为未验证。

---

8. 实施真源文档的整理与引用

8.1 实施真源文档的作用

实施真源文档是后续开发的唯一依据。它要写清楚当前后端语言和框架规则来源、目录责任、业务代码应该放在哪里、禁止放在哪里、新增模块怎么组织、接口怎么返回、错误怎么处理、启动和配置证据在哪里、数据库和日志入口在哪里、哪些地方复用框架、哪些地方是项目自定义。

关键观点: 实施真源文档是开发的唯一依据，不能模糊。

8.2 Agent宪法的引用关系

在Agent宪法中，只需写一条引用关系即可：

后端开发必须先读取并遵守后端架构实施真源文档。

这样可以避免Agent宪法变得臃肿，同时确保所有开发行为都有据可依。

---

9. 总结与行动建议

9.1 全文总结

本文详细讲解了如何对AI生成的后端架构进行有效验收，特别是针对没有技术背景的用户。文章从多个维度出发，包括规则验证、目录责任划分、最小模块演练、接口返回规范、框架复用边界、启动配置固定以及实施真源文档整理等，提供了一套完整的验收流程和方法论。

9.2 核心收获

• 验收不是看功能是否可用，而是看规则是否清晰、证据是否完整
• 目录数量不重要，关键在于职责划分是否清晰
• 最小模块演练是检验架构落地性的关键步骤
• 接口返回必须有具体样例，不能只说“统一”
• 框架能力应最大化复用，避免重复封装
• 启动配置需要固定证据，防止后续开发混乱
• 实施真源文档是后续开发的唯一依据

9.3 行动建议

• 在验收AI生成的后端架构时，务必要求提供证据
• 要求AI输出目录责任表，并逐一核对
• 让AI做最小模块演练，验证架构是否能落地
• 确保接口返回有具体样例，不能只说“统一”
• 审查框架复用情况，避免重复封装
• 固定启动配置，防止后续开发混乱
• 整理实施真源文档，并在Agent宪法中引用

9.4 延伸思考

• 如果你发现后端架构越写越乱，AI每次解释的结构都不一样，应该如何应对？
• 如何确保实施真源文档不会随着时间推移而过时？
• 在团队协作中，如何确保所有人都遵循同一套架构规则？

---

附录

术语表

• 实施真源文档：后端开发的唯一依据，包含所有架构规则和约束。
• Agent宪法：指导AI行为的最高层规则文件，引用实施真源文档。
• 最小模块演练：验证架构规则是否能够真正落地的测试过程。
• 目录责任表：描述每个目录的职责、允许和禁止放置的内容。