AI Postman 的服务拆分，为什么前后端和 Worker 要分开跑

AI Postman 这类工具型项目，如果一开始把所有逻辑都塞进一个进程里，开发会很快，后面排障会很慢。

当前线上形态其实已经说明了问题：

• 前端是独立静态构建产物。
• API 是单独的 Java 服务。
• 机器上还保留了 Python 能力，用来承担更适合脚本化处理的部分。

拆分的意义不是“高级”，而是降低排障成本

当站点已经在生产环境上运行时，最大的成本不再是写出第一版，而是定位问题、回滚问题、独立升级问题。

前端静态化

把前端构建成纯静态产物之后，Nginx 只需要负责托管和转发。这样首页改版时，不必牵动 API 服务。

API 保持独立

业务接口仍然交给 Java 服务处理，能够继续维持原有项目能力，不必因为主站改造而整体重构。

Python 只留给擅长的事情

脚本、实验性处理、模型调用封装，如果已经有 Python 基础设施，就不必强行再塞回 Java。

真正需要补的是部署纪律

目前最大的风险不是语言混用，而是历史上直接在生产环境里改代码、缺少仓库和回滚流程。这个问题不补，后面再加服务也只是把风险分散到更多地方。

后续最优先的动作不是再加一层抽象，而是把：

1. 代码源整理出来。
2. Nginx 入口分离清楚。
3. 产物部署和内容更新流程固定下来。

结构一旦清楚，后面的功能迭代才会轻松。