title: 后端工程这一章要解决什么：环境、骨架、数据与调试
lecture: 2-1-1
chapter: 2
section: 1
series: AI Agent 全栈开发工程师学习笔记
tags: 开发环境, 项目架构, 依赖管理, Postman
后端工程这一章要解决什么：环境、骨架、数据与调试
起点：模型会调了，但工程还没地方放
第 1 章收的是认知------LLM 是什么、能做什么、边界在哪。从这里开始换成动手：在本机立起一个能长期演进的后端工程，后面几章的记忆模块、RAG 知识库、Agent 工具调用，全部往这个工程里加代码。
这一步的产出看起来最不像"功能"，但决定后面舒不舒服。目录结构是随手糊的、依赖版本没锁，到第 5 章就要开始还债------而且是那种"在我机器上好好的"式还债。
整章分三块。
第一块：环境与编辑器
- Python 版本选择。要区分"稳定版"和"发行版"这两件事。公司生产环境优先选仍在安全支持期内的稳定版本，图的是长期运行不出意外；个人学习可以挑较新的发行版先体验特性。最常见的误解是把"最新"当成"最好"，实际是"最新"等于"第三方库支持还没跟上"。
- 虚拟环境。核心作用只有一个：隔离不同项目的依赖包，避免版本冲突，从而保证开发、测试、部署三个阶段拿到的是同一套环境。它是环境隔离手段，不是容器，这两个概念别混。
- 国内镜像加速 。全局配一次镜像源，之后所有
pip install都走国内站。这是后面每一次装包的前置条件，值得单独配。 - PyCharm 配置。代码格式化与导入优化、字体与文件模板、高频快捷键、插件。目的是统一风格和提效，不是编辑器崇拜------VS Code 同样能干，只是要自己凑的插件更多。
第二块：架构与依赖
- 七层架构。LLMOps 后端按表示层、接入层、控制层、服务层、核心层、存储层、资源层自上而下划分，规则是每层只和直接相邻的上下层交互，禁止跨层调用。这条规则是整个工程能长大的前提。
- 目录与文件命名约定 。Flask 是微框架，结构完全交给开发者；团队开发里"个人风格"就是混乱的直接来源。所以先把
internal/下每个目录的职责钉死，再约定文件名、类名、函数名、常量名怎么写。 - 依赖注入。一句话是"我需要什么，你传给我什么，而不是让我自己去创建"。控制器不自己 new 服务，模块之间才解得开，代码可阅读性和可维护性都跟着上来。
requirements.txt锁版本 。生产环境必须做的一步：不锁版本，项目拷到服务器或者发布时，装出来的依赖组合可能和开发时完全不同，直接跑不起来。这里有个高频混淆------requirements.txt不等于pip freeze的原样输出。
第三块：数据与调试
- PostgreSQL。选型时对比了不同数据库的差异，说明为什么这个项目选它；安装与配置覆盖多个操作系统。
- Postman。配置环境变量、基础 URL、路径参数、身份认证，用来逐个验证开发中的接口，确认正确性与可用性。接口写完不实际打一遍，等于没测。
生产环境和个人练习，配置项差在哪
| 维度 | 生产环境 | 个人练习 |
|---|---|---|
| Python 版本 | 稳定版，保守选择 | 可以尝试最新发行版 |
| 依赖管理 | 必须锁定 requirements.txt |
可灵活升级依赖 |
| 数据库 | PostgreSQL 这类生产级 | 轻量级数据库即可 |
| 工具配置 | 完整配置 + 插件 | 基础配置够用 |
优先级上，"虚拟环境 + 依赖管理"和"项目架构与目录约定"是地基------前者决定项目能不能跑，后者决定能不能协作，建议先啃。Python 版本选择花不了多少时间但影响后续迁移；编辑器配置、数据库安装、Postman 属于效率和验证工具，用到再补。
小结
- 这一章交付的不是业务功能，是一个能承接后续所有章节的工程骨架。
- 版本按场景选：生产用安全支持期内的稳定版，学习可以激进；"新版"和"稳定版"不是一回事。
- 虚拟环境解决依赖冲突，镜像源解决下载速度，两者是所有装包操作的前置。
- 七层架构 + 目录约定 + 依赖注入，是让 Flask 这种"什么都不管"的微框架长成商业项目的三道约束。
requirements.txt必须锁版本，而且它是需要维护的清单，不是pip freeze倒出来的垃圾堆。- 数据库和 Postman 排在最后，因为它们服务于已经立起来的骨架，而不是反过来。