打造AI时代“人工智能+”应用技术底座，基于 Python 自研核心框架，整合应用底座、AI 接入、内容管理、知识库问答与多端扩展，为开发者、企业与机构提供更稳的系统建设与交付能力。
为什么叫PyCodev
从名字上可以这样理解：
Py：代表Python开发语言
Code：代表代码、工程化能力和开发框架本身
Dev：代表 Development，也就是开发、交付和业务扩展
把这三个部分组合起来，PyCodev 的含义可以理解为：“一套基于 Python 的、面向业务开发和后台交付的工程化开发平台。”它不是一个只提供路由和请求处理的轻量库，而是一套围绕企业后台常见能力组织起来的完整框架，重点包括：
· 系统管理 · 系统监控 · 表单管理 · 流程管理 · 权限控制 · 定时任务 · 日志审计
PyCodev MVC 架构定位
当前版本采用前后端分离架构：
· 后端：Python + ASGI + Uvicorn
· 前端：Vue 3 + Element Plus
· 数据库：MySQL、PostgreSQL、Oracle、SQLite
· 缓存与辅助能力：Redis
PyCodev 的架构优点
PyCodev 的优势不在于“更小”，而在于“更适合企业后台项目直接落地”。
1. 不只是 Web 框架，而是带业务底座的后台平台
很多框架只解决“接口怎么写”，而 PyCodev 同时把下面这些后台项目高频能力也组织进来了：
· 登录和权限
· 用户、角色、菜单、部门、岗位
· 登录日志、操作日志
· 定时任务
· 表单设计和表单数据
· 流程设计和流程流转
这意味着项目启动后，不需要从零再拼一整套后台底座。
2. 模块分层更明确
PyCodev 约定了比较清晰的职责边界：
· controller 负责入口和返回
· entity 负责 ORM 和基础读写
· service 负责复杂业务编排
· libs 负责跨模块复用能力
这种结构对中大型后台项目更友好，后期维护成本更可控。
3. 更适合做“业务单据 + 审批流”类系统
很多企业系统不是单纯的 CRUD，而是：
· 先有表单
· 再有数据提交
· 再进入流程审批
· 最后还要审计和监控
PyCodev 的表单管理和流程管理就是围绕这种场景设计的。
4. 对实施和交付更友好
因为系统管理、监控、任务、日志这些能力已经具备，实施人员和交付人员可以更快把系统搭起来，而不是把大量时间耗在底层基建补齐上。
PyCodev 和 Flask、Django、FastAPI 的区别
这里不讨论“谁绝对更好”，而是看它们各自更适合什么场景。
与 Flask 的区别
Flask 的特点是轻量、自由、易于快速起步，但很多能力需要自行组合。
相比之下，PyCodev 的特点是：
· 不只是一个微框架
· 自带后台管理常用底座
· 更强调模块化业务扩展
· 更适合直接落地企业后台
如果你的项目只是一个很轻的 API 服务，Flask 足够简单直接；如果你的目标是做一套带权限、菜单、日志、任务和审批的后台系统，PyCodev 更省基建时间。
与 Django 的区别
Django 的特点是生态成熟、组件齐全、Admin 强、约定完整。
相比之下，PyCodev 的特点是：
· 更聚焦企业后台业务开发场景
· 结构更偏工程化业务模块拆分
· 前后端分离思路更明确
· 更方便把权限、表单、流程和调度组合进一个系统
如果你更看重 Django 自身完整生态和官方 Admin，Django 很强；如果你更关心一套中国式后台业务系统如何快速组装出系统管理、流程和表单能力，PyCodev 的贴合度更高。
与 FastAPI 的区别
FastAPI 的特点是：
· 接口声明清晰
· 类型提示友好
· OpenAPI 文档能力强
· 很适合做现代 API 服务
相比之下，PyCodev 的重点不只是“把 API 写得漂亮”，而是“把一个后台系统真正搭起来”。
PyCodev 在企业后台场景中的优势主要体现在：
· 已经内置系统管理基础能力
· 更适合承载菜单权限体系
· 带定时任务、日志、表单和流程能力
· 更像“业务平台框架”，不只是“接口框架”
如果你只做标准 API 平台，FastAPI 非常合适；如果你要交付一整套后台业务系统，PyCodev 更接近开箱可扩展的业务底座。
四大核心模块怎么配合
系统管理
系统管理是所有业务功能的基础。没有用户、角色和权限，其他模块即使存在，也无法被正确使用。
界面示例：
表单管理
表单管理负责定义业务数据结构。很多流程都不是直接流转“一个按钮”，而是流转“一个带字段内容的业务单据”。
界面示例：
流程管理
流程管理负责把业务表单接入审批规则，形成可以发起、审批、驳回和归档的流程。
界面示例：
系统监控
系统监控负责维护系统运行状态，确保日志、任务和异常情况可见。
界面示例：
为何能成为 AI “人工智能+”应用的技术底座
PyCodev v2.0 之所以能够成为“人工智能+”应用的技术底座，不是因为它只接了某一个大模型接口，而是因为它本身已经具备了承载AI 应用落地所需的完整业务骨架。一个真正可交付的 AI 应用，通常不只是“调用一次模型”，而是要同时具备用户权限、业务表单、流程审批、任务调度、日志审计、内容管理、接口治理和运行监控等能力。PyCodev 恰好已经把这些企业级后台基础能力沉淀成了统一框架，因此 AI 能力接入后，不需要从零搭业务底盘，而是可以直接挂接在现有系统管理、表单、流程、调度和监控体系之上。
更重要的是，PyCodev 的定位不是单点 AI Demo 框架，而是“AI 能力和业务系统融合”的平台型底座。它既能承载知识库问答、AI 发布、智能识别、智媒体处理这类 AI 场景，也能把这些能力真正接入到组织、角色、菜单、流程、日志和任务中，形成可管理、可运营、可审计、可持续扩展的应用系统。这正是“人工智能+”应用底座和普通 AI 工具项目之间的本质区别。
在 AI 应用构建上 PyCodev 有哪些优势
PyCodev 在 AI 应用构建上的第一大优势，是“业务底座完整”。很多 AI 项目做到后面都会补系统管理、权限体系、上传能力、任务队列、日志追踪、后台页面和运维监控，而这些在 PyCodev 中本身就是现成能力。也就是说，开发者可以把更多精力放在 AI 场景本身，而不是反复搭后台基建。
第二大优势，是“模块化和可扩展性强”。PyCodev 采用 modules + libs + controller/entity/service 的组织方式，适合把 AI 能力拆成独立模块逐步演进。无论是模型管理、知识库管理、文档解析、AI 发布、视频分析，还是后续的智能代理、媒体理解、多模态处理，都可以在统一框架内持续扩展，而不会把系统做成一堆彼此耦合的脚本。
第三大优势，是“天然适合 AI 与业务流程融合”。AI 应用真正有价值的地方，往往不是模型本身，而是模型结果如何进入业务。
PyCodev 本身具备动态表单、流程审批、定时任务、内容管理和运行监控能力，因此 AI 可以很容易从“一个能力接口”升级成“一个业务闭环”。例如知识库问答可以接入后台管理和知识库运营，AI 发布可以接入 CMS 内容生产流程，视频识别可以接入监控、审核和事件追踪，智媒体能力可以接入内容处理和分发链路。
第四大优势，是“可交付、可运营、可持续演进”。PyCodev 不是只适合实验室验证，而是更适合落地。它的系统管理、权限控制、日志审计、调度能力、配置体系和前后端分离结构，使 AI 应用从一开始就具备企业级交付条件，这对于“人工智能+政务”“人工智能+内容”“人工智能+媒体”“人工智能+视联网”这类场景尤其重要。
PyCodev 已经具备的 AI 能力
从现有生态来看，PyCodev 已经不是“准备接 AI”，而是已经在多个方向上具备了明确的 AI 落地能力。
首先，在 pycodev-rag 方向，PyCodev 已经完成了面向知识库问答场景的第一阶段 RAG 基础设施建设，包含模型配置管理、知识库管理、文档上传、文档解析、文档分段入库、分段查询、RAG 相关数据模型以及 Qdrant 向量库配置与客户端封装。这说明 PyCodev 已经具备承载知识增强、企业知识库、智能问答后台的基础能力。
其次，在 pycodev-cms 方向，PyCodev 已经把 AI 能力延伸到了内容生产与发布场景。当前 pycodev-cms 已接入 AI 发布 MCP Server，能够把 CMS 的内容管理能力与 AI 生成、AI 发布链路结合起来，说明 PyCodev 不只是能做“AI 聊天”，还能把 AI 接入实际业务发布流程，形成内容平台中的智能生产能力。
再次，在 pycodev-pcmediakit 方向，虽然当前 README 更侧重视联网与媒体接入，但从项目结构和你给出的定位看，它正在向摄像头接入、视频流处理、边缘设备联动和 AI 识别场景演进。这意味着 PyCodev 的 AI 能力正在从文本和内容侧，扩展到视频、设备、摄像头和实时识别侧，具备走向“AI+视联网”“AI+边缘感知”的基础条件。