教育系统已经进入 AI 开发时代，真正有价值的不是让模型临时写一段代码，而是把产品需求、菜单结构、后端接口、前端页面、权限规则和验收标准整理成 Codex 能持续执行的工程路径。

本文基于 _sop_workflow/project_pr 与 _sop_workflow/server 的真实文档，梳理一套教育管理系统自动化开发方法：用产品目录拆任务，用 PDD 定义边界，用 SOP 约束开发顺序，再让 Codex 分阶段生成项目代码。

项目整体架构

这个教育管理系统是一个典型的 Django + Vue3 前后端项目。后端位于 server_backend，负责数据模型、接口视图、路由注册、权限控制、菜单数据、系统配置和三方 AI 服务；前端位于 server_vue3，负责后台管理页面、菜单路由、接口封装、CRUD 配置、表单交互、按钮权限和页面回显。

从工程形态看，Django 后端不是单纯提供几个接口，而是承担教育系统的数据底座。每个业务模块通常会在 server_backend/modules/<Module>/models.py 中定义 ORM 模型，在 views_app/<ModelName>.py 中提供 ViewSet 接口，在 urls.py 中注册路由，并通过菜单、按钮权限和角色权限把接口纳入后台管理体系。三方 AI 服务则集中在 server_backend/dvadmin/third_party_service，统一管理 LLM、OCR、TTS、ASR、WORKFLOW 等能力。

Vue3 前端也不是静态页面集合，而是围绕后台菜单和业务操作组织的管理端工程。常规模块页面落在 server_vue3/src/views/modules/<Module>/<ModelName>/，通常包含 api.ts、crud.tsx、index.vue 三类文件：api.ts 对接 Django API，crud.tsx 描述列表、搜索和表单，index.vue 承载页面容器、刷新逻辑和复杂交互。

ManageBak-ExamEdu/
  server_backend/
    modules/
      <Module>/
        models.py
        urls.py
        utils.py
        views_app/
          <ModelName>.py
    dvadmin/
      third_party_service/
        views_setting.py
        config.py
        async_api.py
        points_service.py

  server_vue3/
    src/
      views/
        modules/
          <Module>/
            <ModelName>/
              api.ts
              crud.tsx
              index.vue
        system/
          ThirdPartyService/

  _sop_workflow/
    project_pr/
    server/

项目层级	主要职责	Codex 自动化开发关注点
Django 模型层	定义学生、教师、考试、题库、内容、系统配置等业务数据	读取 ORM 字段，生成序列化、筛选、校验和保存逻辑
Django 接口层	通过 ViewSet、@action 和路由提供管理端 API	生成 CRUD、业务动作、权限映射和前端调用路径
Django 系统层	管理菜单、按钮权限、角色权限、图标、系统配置和三方服务	生成菜单同步、配置同步、默认服务和验收命令
Vue3 页面层	承载列表、筛选、新增、编辑、详情、弹窗和复杂交互	生成 api.ts、crud.tsx、index.vue
Vue3 权限层	根据菜单和按钮权限控制页面操作	同步按钮 value、API 路径和后端权限点
SOP 文档层	约束开发顺序、目录结构、验收标准和交付格式	让 Codex 按阶段生成文档、代码、测试和修复项

设计与需求

这套实战路径的核心，是把教育系统里的每一个菜单页面都变成可执行的 Codex 开发任务。project_pr 当前已经按后台菜单整理出产品一级模块、菜单页面目录、说明图片和 Markdown 需求文档；server 则提供管理后台模块开发 SOP、三方服务模块开发 SOP、后端 ViewSet Action 规范，以及 LLM/OCR/TTS/ASR 等服务的 PDD 与开发 SOP。

因此，教育系统自动化开发不是“输入一句话生成代码”，而是把需求先转换成结构化上下文。产品侧给出菜单、页面截图、业务说明；后端侧给出模型、接口、权限、菜单、图标和配置同步规则；前端侧给出页面目录、接口封装、CRUD 配置和交互验收。Codex 读取这些上下文后，才能稳定生成可落地的项目代码。

需求层材料	工程层转换	Codex 代码生成方向
project_pr/README.md 中的一级模块与菜单索引	把 9 个产品一级模块拆成可执行任务池	按菜单逐个生成模块设计、接口设计和页面代码
每个菜单目录下的 _instruction.png	把页面截图转换成列表、表单、按钮、弹窗、状态和字段规则	生成前端页面结构、交互状态和验收用例
教育管理系统xxx用Codex自动生成项目代码.md	把模块业务描述转换成 PDD、API、测试用例和 SOP	生成模块级开发文档与代码任务
01.管理后台模块开发SOP.md	统一后端 ViewSet、前端 CRUD、菜单、权限和 icon 规则	生成常规管理后台模块代码
02.三方服务模块开发SOP.md	统一 LLM/OCR/TTS/ASR 等 AI 服务接入规则	生成三方服务配置、默认设置、系统配置同步和异步任务
03.后端视图 Action 规范改造SOP.md	统一 @action 命名、docstring、前后端接口路径联动	修复接口命名、权限映射和前端调用

可以直接使用下面的Prompt进行教育系统自动化开发路径设计

请基于当前教育管理系统的产品目录和 server SOP 文档，设计一套 Codex 自动化开发路径。

输入上下文：
- 产品目录：_sop_workflow/project_pr/README.md
- 菜单页面目录：_sop_workflow/project_pr 下的教学中心、考试中心、内容中心、配置中心、我的工作、系统功能、系统配置、用户中心、Tauri工具
- 管理后台模块 SOP：_sop_workflow/server/01.管理后台模块开发SOP.md
- 三方服务模块 SOP：_sop_workflow/server/02.三方服务模块开发SOP.md
- Action 规范：_sop_workflow/server/03.后端视图 Action 规范改造SOP.md
- 三方服务 PDD/SOP：_sop_workflow/server/systemWorkWorkbenches

请输出：
1. 如何把菜单目录转换成 Codex 开发任务池。
2. 如何把每个模块拆成 PDD、API、test-cases、codex-sop 四类文档。
3. 常规管理后台模块的后端、前端、菜单、权限、icon 生成顺序。
4. LLM/OCR/TTS/ASR 等三方服务模块的配置、默认设置、系统配置同步和验收方式。
5. Action 接口命名、前端调用路径、按钮权限映射的检查规则。
6. 一套可重复执行的开发、验收、修复闭环。

后端设计

后端设计的关键不是让 Codex 直接堆 CRUD，而是让它先理解教育系统的代码组织规则。常规管理后台模块以 server_backend/modules/<Module>/ 为边界，模型来自当前模块的 models.py，视图统一放在 views_app/<ModelName>.py，路由在 urls.py 注册。每个 ViewSet 默认继承项目里的 CustomModelViewSet，序列化、筛选、权限和软删除能力要按模型真实字段生成。

01.管理后台模块开发SOP.md 已经把后端落点写得很清楚：视图目录、路由注册、迁移策略、views_app 与 utils.py 的职责边界、按钮权限、菜单写库命令和校验命令都要纳入交付。尤其是 views_app 中禁止新增零散顶层 def，复杂逻辑需要下沉到 modules/<Module>/utils.py 并按工具类组织，这能避免 Codex 生成一堆无法复用的临时代码。

server_backend/
  modules/
    <Module>/
      models.py
      urls.py
      utils.py
      views_app/
        <ModelName>.py

server_vue3/
  src/
    views/
      modules/
        <Module>/
          <ModelName>/
            api.ts
            crud.tsx
            index.vue

后端设计项	设计重点	Codex 生成方向
模型识别	从 ORM 文件读取模型类、字段、软删除、默认值和外键关系	生成序列化器、筛选规则、字段校验和保存逻辑
视图文件	views_app/<ModelName>.py 只保留 import、ViewSet 与 action	生成 CustomModelViewSet、http_method_names、查询和权限
工具类	复杂逻辑放到 modules/<Module>/utils.py	生成 <Domain>QueryUtils、<Domain>ParamUtils、<Domain>TaskUtils
路由注册	在 modules/<Module>/urls.py 中注册 ViewSet	生成 router import 与 router.register
菜单权限	菜单、按钮、角色权限需要同步到数据库	生成可重复执行的 sync 命令，支持 --dry-run
Action 规范	@action 按 get_/generate_/update_/delete_/export_/render_ 命名	生成一行中文 docstring，并同步前端接口路径
校验命令	manage.py check、迁移、菜单回查	生成开发完成后的验收步骤

可以直接使用下面的Prompt进行后端代码的设计

请按教育管理系统“01.管理后台模块开发SOP”实现或补齐一个后台模块。

输入信息：
1. ORM 文件位置：server_backend/modules/<Module>/models.py
2. 目标模型：<ModelName>
3. 模块归属：modules/<Module>
4. 菜单挂载：<一级目录> > <二级分组> > <菜单中文名>
5. 特殊要求：如软删除、批量操作、导入导出、审核、统计或文件上传，没有则写“无”。

后端生成要求：
1. 读取模型字段，生成或补齐 views_app/<ModelName>.py。
2. ViewSet 继承项目当前 CustomModelViewSet，支持列表、详情、新增、编辑、删除。
3. 根据真实字段生成序列化规则、模糊查询、日期范围查询、枚举筛选和基础校验。
4. 复杂逻辑必须放到 modules/<Module>/utils.py，views_app 中不要新增顶层 def。
5. 在 modules/<Module>/urls.py 注册路由。
6. 如有 @action，函数名必须使用 get_/generate_/update_/delete_/export_/render_ 前缀，并写一行中文 docstring。
7. 输出菜单按钮权限映射：Search、Retrieve、Create、Update、Delete，以及新增 action 对应权限。
8. 输出需要执行的 check、migrate、菜单同步和回查命令。

请先输出后端文件结构和接口清单，再给出代码修改方案。

前端设计

前端设计要服务教育系统里的真实操作路径，而不是把模型字段简单铺成表格。01.管理后台模块开发SOP.md 规定每个常规模块默认包含 api.ts、crud.tsx、index.vue：api.ts 负责统一接口前缀和增删改查方法；crud.tsx 负责列表、搜索、表单、字段转换和按钮配置；index.vue 负责页面容器、useFs 初始化和刷新动作。

project_pr 里的页面说明和截图，正好可以作为前端生成的输入。比如考试中心、用户中心、内容中心、系统功能等模块，菜单目录已经表达了业务归属，_instruction.png 提供页面视觉参考，Markdown 说明文档提供业务边界。Codex 在生成前端时，需要把这些材料转换成列表字段、筛选条件、表单分区、弹窗状态、接口调用、权限按钮和保存回显。

前端设计项	设计重点	Codex 生成方向
页面目录	server_vue3/src/views/modules/<Module>/<ModelName>/	生成 api.ts、crud.tsx、index.vue
接口封装	apiPrefix = '/api/<Module>/<ModelName>/'	生成 GetList、GetObj、AddObj、UpdateObj、DelObj
列表配置	核心字段、创建时间、状态、业务筛选条件	生成 FastCrud columns、search、formatter 和权限按钮
表单结构	新增编辑字段、默认值、枚举、下拉、日期、文件	生成表单组件、字段转换和校验规则
保存回显	数组、枚举、JSON 字段、外键展示要前后端一致	生成 addRequest、editRequest、afterOpen、valueResolve
页面刷新	页面进入后触发 doRefresh()	生成 useFs({ createCrudOptions }) 与 onMounted
权限按钮	新增、编辑、删除、详情、导出、生成等动作受控	生成按钮权限 value 与后端 API 映射

可以直接使用下面的Prompt进行前端代码的设计

请按教育管理系统“01.管理后台模块开发SOP”生成 Vue3 前端模块。

输入信息：
- 模块名：<Module>
- 模型名：<ModelName>
- 菜单中文名：<菜单中文名>
- 页面截图或说明：读取 _sop_workflow/project_pr/<一级模块>/<菜单目录>/_instruction.png 与对应 Markdown 文档
- 后端接口前缀：/api/<Module>/<ModelName>/

前端生成要求：
1. 在 server_vue3/src/views/modules/<Module>/<ModelName>/ 下生成 api.ts、crud.tsx、index.vue。
2. api.ts 统一导出 apiPrefix、GetList、GetObj、AddObj、UpdateObj、DelObj，并补齐真实 action 接口。
3. crud.tsx 生成列表列、搜索字段、表单字段、字段格式化、保存前转换和回显转换。
4. index.vue 使用 <fs-page><fs-crud /></fs-page>、useFs 与 onMounted doRefresh。
5. 页面按钮需要预留权限控制，权限点与后端按钮权限保持一致。
6. 如果存在文件上传、数据统计、审批、导入导出、AI 生成等真实能力，需要按说明文档生成对应交互；没有真实能力不要编造。
7. 输出页面结构、接口调用清单、字段转换规则和验收用例。

扩展功能

教育系统进入 AI 开发时代后，后台模块不再只有普通 CRUD。当前 server 目录已经把三方 AI 服务、异步任务、系统配置同步、Action 命名和菜单图标规范沉淀下来，这些都是 Codex 自动化开发需要稳定遵守的扩展能力。

扩展功能	主要用途	落地重点
三方 AI 服务	管理 LLM/OCR/TTS/ASR/AUDIOCLONE/WORKFLOW 等服务	统一平台、模型、默认配置、应用配置和系统配置同步
菜单权限与图标	让生成的模块真正进入管理后台	菜单写库、按钮权限、角色权限、icon 与 image 同步
Action 接口规范	让自定义接口可读、可维护、可被前端准确调用	统一前缀、docstring、权限映射和前端 URL

三方 AI 服务

三方 AI 服务是教育系统 AI 化的基础设施。02.三方服务模块开发SOP.md 把 LLM、OCR、TTS、ASR、AUDIOCLONE、WORKFLOW、TencentAgent 放到统一规范下，后端以 exam_ai_service_setting、exam_ai_service_setting_data、exam_system_config 作为配置底座，前端统一采用左侧平台菜单加右侧详情 Tabs 的页面结构。

systemWorkWorkbenches 目录进一步把 LLM/OCR/TTS/ASR 拆成子模块 PDD 和开发 SOP。LLM 服务强调 text/reasoning/function_calling 三组默认模型；OCR 服务强调 api_key 与 secret_id/secret_key 的差异化鉴权；长任务模块通过 ai_async_task_submit/status 统一提交和查询。Codex 生成这类模块时，要优先遵守总纲，再处理子模块差异。

可以直接使用下面的Prompt进行三方AI服务设计

请按教育管理系统“02.三方服务模块开发SOP”实现或补齐一个三方 AI 服务模块。

输入信息：
1. 模块分类：LLM / OCR / TTS / ASR / AUDIOCLONE / WORKFLOW
2. 平台清单：厂商名、是否启用、鉴权字段、API 地址字段、模型字段
3. 默认配置规则：哪些能力需要默认模型，哪些字段允许为空
4. 应用配置规则：是否需要 app_setting
5. 特殊差异：如腾讯云 OCR 使用 secret_id/secret_key，LLM 使用 text/reasoning/function_calling 分组

生成要求：
1. 后端遵守 server_backend/dvadmin/third_party_service 的当前结构。
2. 子模块至少包含 api.py、setting.py、provider_xxx.py、__init__.py。
3. API 层只做参数解析、调用服务、组装响应，不堆积业务逻辑。
4. 默认配置通过 AIServiceConfigService 同步到 api_service 系统配置分组。
5. 空值提交必须触发清理，不保留垃圾空字符串字段。
6. 长任务统一通过 /api/system/ai_async_task_submit/ 与 /api/system/ai_async_task_status/。
7. 前端页面使用左侧平台菜单、右侧横向 Tabs、系统默认配置弹窗。
8. 激活开关独立保存，失败时回滚 UI。
9. 输出 PDD 验收清单、接口清单、前端页面结构和自测步骤。

菜单权限与图标

教育系统的模块生成完成后，真正的交付不是文件存在，而是菜单可见、按钮可用、角色有权限、图标风格一致。01.管理后台模块开发SOP.md 明确要求叶子菜单写入 web_path、component、component_name、visible、status、icon、image 等字段，并通过可重复执行的管理命令同步菜单和权限。

图标规范也属于开发交付的一部分。业务模块图标放在 server_backend/media/icon/modules/<Module>/，三方服务图标放在 server_backend/media/icon/system/ThirdPartyService/，统一使用 SVG，并采用 320x200 的卡片风格。Codex 生成模块时，如果只生成页面和接口，却没有菜单、按钮权限和图标绑定，这个模块就没有真正进入教育系统后台。

验收项	检查重点	通过标准
菜单层级	一级目录、二级分组、三级菜单是否正确	页面在目标菜单分组下可见
菜单字段	web_path、component、component_name 是否匹配前端目录	刷新后路由能正常加载页面
按钮权限	Search、Retrieve、Create、Update、Delete 是否绑定 API	无权限时按钮不可用或接口不可访问
角色权限	同级已有角色是否补齐新菜单和按钮	对应角色登录后能看到模块
图标绑定	menu.icon 与 menu.image 是否都有值	侧栏和工作台卡片都能显示
图标文件	SVG 路径是否真实存在且风格统一	页面无缺图或风格突兀

可以直接使用下面的Prompt进行菜单权限与图标验收

请对当前教育管理系统模块进行菜单、权限和图标验收。

输入信息：
- 模块名：<Module>
- 模型名：<ModelName>
- 菜单中文名：<菜单中文名>
- 前端页面目录：server_vue3/src/views/modules/<Module>/<ModelName>/
- 后端接口前缀：/api/<Module>/<ModelName>/
- 图标路径：server_backend/media/icon/modules/<Module>/<ModelName>.svg

验收要求：
1. 检查菜单 web_path 是否为 /modules/<Module>/<ModelName>。
2. 检查 component 是否为 modules/<Module>/<ModelName>/index。
3. 检查 component_name 是否为 <ModelName>。
4. 检查 icon 是否非空，且同层菜单图标类型一致。
5. 检查 image 是否指向真实 SVG 文件。
6. 检查按钮权限是否包含 Search、Retrieve、Create、Update、Delete。
7. 检查新增 @action 是否有对应按钮权限和 API 映射。
8. 输出 dry-run 菜单同步命令、正式同步命令和 Menu(component_name) 回查命令。
9. 输出未通过项、影响范围和修复建议。

Action 接口规范

教育系统里很多模块都会出现普通 CRUD 之外的动作，例如查询统计、生成内容、更新状态、导出文件、渲染资源。03.后端视图 Action 规范改造SOP.md 的价值，是让这些动作不再随意命名。@action 函数必须按业务语义命名，允许前缀包括 get_、generate_、update_、delete_、export_、render_，并要求 docstring 与前缀匹配。

这个规范对 Codex 很重要。模型生成代码时常会写出 handle_xxx、process_xxx、do_xxx 这类临时函数名，看起来能跑，后续权限配置、前端接口封装和角色授权都会变得混乱。把 Action 规范写进 Prompt，可以让 Codex 同步处理后端函数名、前端 api.ts URL、页面调用方法和按钮权限 value。

Action 前缀	语义要求	docstring 起始词	适用场景
get_	查询数据	查询	查询统计、查询配置、获取模板
generate_	生成内容	生成	AI 生成、报告生成、题目生成
update_	更新状态或业务数据	更新	审核状态、配置保存、批量更新
delete_	删除业务对象	删除	批量删除、清理临时数据
export_	导出文件	导出	Excel、CSV、报告导出
render_	渲染资源	渲染	预览、模板渲染、可视化输出

可以直接使用下面的Prompt进行Action接口规范检查

请按教育管理系统“后端视图 Action 规范改造SOP”检查并修复当前模块的 @action 接口。

检查范围：
- server_backend/modules/<Module>/views_app/<ModelName>.py
- server_vue3/src/views/modules/<Module>/<ModelName>/api.ts
- server_vue3/src/views/modules/<Module>/<ModelName>/index.vue 或 crud.tsx
- 菜单按钮权限配置

检查要求：
1. @action 函数名必须使用 get_/generate_/update_/delete_/export_/render_ 前缀。
2. 禁止 handle_xxx、process_xxx、do_xxx、save_xxx、build_xxx 等无业务语义命名。
3. 每个 @action 必须有一行中文 docstring，并以中文句号结尾。
4. docstring 起始词必须与函数前缀匹配，例如 get_ 以“查询”开头。
5. Action 改名后同步修改前端 api.ts URL、页面调用方法和按钮权限 value/api。
6. 复杂逻辑优先下沉到 utils.py 的工具类，不在 views_app 中新增零散 helper。

请输出问题清单、修复后的命名表、涉及文件和回归测试点。

Codex开发标准

Codex 自动化开发要依赖稳定的输入约束。PDD 定义业务边界，SOP 定义开发顺序，API 文档定义接口契约，test-cases 定义验收路径。没有这些文档，Codex 容易生成能运行但不符合教育系统真实流程的代码；有了这些文档，Codex 才能按模块、按阶段、按验收标准持续迭代。

SOP 标准

SOP 用于约束目录、文件职责和开发顺序。在这套教育系统中，常规模块优先使用 01.管理后台模块开发SOP.md，AI 服务模块使用 02.三方服务模块开发SOP.md 和 systemWorkWorkbenches 下的子模块 SOP，接口动作统一接受 03.后端视图 Action 规范改造SOP.md 检查。

_sop_workflow/
  project_pr/
    README.md
    教学中心/
    考试中心/
    内容中心/
    配置中心/
    我的工作/
    系统功能/
    系统配置/
    用户中心/
    Tauri工具/
    Demo/

  server/
    README.md
    01.管理后台模块开发SOP.md
    02.三方服务模块开发SOP.md
    03.后端视图 Action 规范改造SOP.md
    systemWorkWorkbenches/
      LLM服务-PDD.md
      LLM服务-开发SOP.md
      OCR服务-PDD.md
      OCR服务-开发SOP.md
      TTS服务-PDD.md
      TTS服务-开发SOP.md
      ASR服务-PDD.md
      ASR服务-开发SOP.md
      新增厂商基础需求单模板.md

开发阶段	Codex 执行目标	输出结果
产品识别	读取 project_pr/README.md 与目标菜单文档	明确模块归属、页面截图、业务边界
PDD 生成	把业务需求转换成目标、范围、字段、接口、验收	输出 pdd.md
API 设计	明确 CRUD、Action、三方服务接口和权限映射	输出 api.md
SOP 规划	固定后端、前端、菜单、权限、图标开发顺序	输出 codex-sop.md
测试设计	覆盖新增、编辑、删除、筛选、扩展能力和异常路径	输出 test-cases.md
后端实现	生成模型相关视图、序列化、筛选、路由、权限	后端接口可运行
前端实现	生成页面、接口封装、CRUD 配置、保存回显	页面功能可用
菜单同步	写入菜单、按钮权限、角色权限和图标	后台可见可操作
验收修复	按 PDD 和 SOP 检查问题并修复	输出交付记录

可以直接使用下面的Prompt进行SOP撰写

请为当前教育管理系统模块撰写 Codex 开发 SOP，并按 SOP 规划实现路径。

输入上下文：
- 产品目录：_sop_workflow/project_pr/README.md
- 当前模块说明：_sop_workflow/project_pr/<一级模块>/<菜单目录>/<模块说明>.md
- 页面截图：_sop_workflow/project_pr/<一级模块>/<菜单目录>/_instruction.png
- 管理后台 SOP：_sop_workflow/server/01.管理后台模块开发SOP.md
- 三方服务 SOP：_sop_workflow/server/02.三方服务模块开发SOP.md
- Action 规范：_sop_workflow/server/03.后端视图 Action 规范改造SOP.md

要求：
1. 先输出目录结构，不要直接写代码。
2. 先生成 docs/modules/<Module>/<ModelName>/pdd.md、api.md、test-cases.md、codex-sop.md。
3. pdd.md 覆盖业务目标、页面结构、数据模型、接口规则、权限控制、扩展能力和验收标准。
4. api.md 列出 CRUD、Action、三方服务调用、菜单按钮权限和请求响应示例。
5. test-cases.md 覆盖成功路径、异常路径、权限路径和保存回显。
6. codex-sop.md 定义后端实现、前端实现、菜单同步、图标绑定、校验命令和交付格式。
7. 文档确认后再生成或修改项目代码。

请输出阶段计划、文件清单、开发步骤和验收检查项。

PDD 标准

PDD 是 Codex 自动化开发的业务约束文件。教育系统模块通常会牵涉学生、教师、考试、题库、内容、三方服务、系统配置等多个业务域，如果只给 Codex 一个页面名称，它会默认生成通用表单。PDD 需要把“这个模块为什么存在、服务哪个业务流程、字段如何保存、接口如何验收、哪些操作受权限控制”写清楚。

PDD 不是写给人看的摆设，而是 Codex 后续验收代码的标准。比如题库中心不能只检查新增记录是否成功，还要检查题目内容、知识点、选项结构、LLM 回填、图片识别草稿和文件 URL；LLM 服务不能只检查厂商列表，还要检查默认模型分组、系统配置同步、清空配置后的清理逻辑。

PDD 验收维度	验收重点	通过标准
业务目标	模块是否服务教育系统真实流程	能说明该模块和教学、考试、内容、用户或系统配置的关系
页面结构	列表、筛选、表单、弹窗、按钮是否完整	页面操作路径和截图说明一致
数据模型	字段、默认值、枚举、JSON、外键是否正确	保存、编辑、回显和筛选稳定
接口规则	CRUD、Action、三方服务接口是否清晰	前后端路径、方法、参数一致
权限控制	菜单、按钮、角色权限是否绑定	无权限用户无法执行受控操作
菜单图标	icon、image、组件路径是否正确	侧栏、工作台、页面路由都正常
扩展能力	AI 服务、导入导出、文件、统计、审批等真实能力	只验收文档和代码中确实存在的功能
测试用例	成功、异常、权限、回显、清理路径是否覆盖	能按用例复现并定位问题

可以直接使用下面的Prompt进行PDD 验收

请根据当前模块的 pdd.md 对教育管理系统模块进行 PDD 验收。

验收范围：
- 文档：docs/modules/<Module>/<ModelName>/pdd.md、api.md、test-cases.md、codex-sop.md
- 后端：server_backend/modules/<Module>/models.py、views_app/<ModelName>.py、urls.py、utils.py
- 前端：server_vue3/src/views/modules/<Module>/<ModelName>/api.ts、crud.tsx、index.vue
- 菜单权限：Menu、按钮权限、角色权限、icon、image
- 如为三方服务：server_backend/dvadmin/third_party_service 与 server_vue3/src/views/system/ThirdPartyService/<Module>/

请检查：
1. 业务目标是否与产品目录和菜单说明一致。
2. 页面结构是否覆盖截图或说明文档中的核心操作。
3. 数据模型字段、枚举、JSON、外键、软删除和默认值是否按 PDD 实现。
4. CRUD、Action、三方服务接口是否在前后端正确调用。
5. 菜单、按钮权限、角色权限和图标是否完成同步。
6. Action 命名和 docstring 是否符合规范。
7. 扩展能力是否只包含真实存在的功能，没有编造交互。
8. 测试用例是否覆盖成功路径、异常路径、权限路径和保存回显。

请输出验收结果表，标记通过、未通过、风险项和需要修复的文件位置，并给出具体修复建议。

实战执行清单

这套路径可以直接用于日常模块开发。每次新增或改造教育系统模块时，把需求按下面的清单交给 Codex，能明显减少来回补信息的成本。

步骤	输入材料	Codex 输出
选择菜单	project_pr 中的一级模块和菜单目录	模块归属、页面名称、业务边界
补齐说明	_instruction.png 与模块 Markdown	页面结构、字段、按钮和交互说明
选择 SOP	常规模块用 01，AI 服务用 02，Action 用 03	开发顺序和工程约束
生成文档	PDD、API、test-cases、codex-sop	可验收的开发任务
生成代码	后端、前端、菜单、权限、图标	可运行模块
执行校验	check、migrate、build、菜单回查	自测结果
PDD 验收	对照业务边界和验收表	问题清单与修复建议
交付记录	变更摘要、文件列表、校验结果	可追踪交付说明

总结

教育系统用 Codex 完成自动化开发，关键不在“AI 会不会写代码”，而在项目是否有足够清晰的需求入口和工程约束。project_pr 把菜单、页面和业务说明整理成任务地图，server 把后端、前端、菜单、权限、图标、Action 和三方 AI 服务规范沉淀成可执行 SOP，这就是实战路径的底座。

这套方法让 Codex 从临时编码工具变成模块开发协作者。PDD 定义业务边界和验收标准，SOP 约束目录结构和开发顺序，Prompt 把页面、模型、接口、权限和扩展能力分阶段交给 Codex 实现。教育系统的 AI 开发时代，真正可复用的是这条从产品目录到代码交付的闭环。