业务和功能介绍
一、立项背景和目标
历史纸质图书转电子书业务长期依赖邮件和共享盘，在出版社内部与多家外包转码公司之间流转，存在交接标准不一致、任务进度不透明、元数据缺失严重、异常无法追溯、历史资源检索效率低等问题。本项目立项建设一套统一的历史图书数字化资源管理平台，把出版社原稿上传、转码任务发布、外包公司处理、成果回传、内部校验、验收归档、异常隔离到检索分析的全流程收敛到同一系统内，并以约 100TB 级历史资源为目标规模，从底层保证长期稳定运行与快速查询。
二、软件功能与核心功能模块
系统为模块化单体的企业级 Web 后台，前台使用角色为出版社人员与转码公司人员，核心模块包括：
1. 图书与元数据模块：以规范化书号 canonical_book_no 作为图书唯一标识，维护图书、版本与文件资产；书号、作者等元数据由 EPUB 提取而非人工录入。
2. 任务协作模块：出版社发布转码任务，转码公司处理并回传成果，任务状态经状态机受控流转，禁止直接改状态；转码公司侧只呈现待处理、处理中、已回传、已退回、已作废五态，内部校验与验收状态不外泄。
3. 文件与上传模块：受控本地文件存储，支持大文件分片上传、断点续传与对账补传，下载走浏览器原生与 HTTP Range 分片。
4. 校验验收与异常治理模块：成果 EPUBCheck 校验、验收通过或退回、异常隔离与返工闭环，全流程留痕。
5. 归档与检索模块：对归档成果做结构化解析、切片与检索单元生成，并导出只读知识投影。
6. 权限与审计模块：组织级 RBAC、幂等键与 X-Request-Id、操作审计与状态变更事件。
7. 运行健康看板与统计报表：监控数据库、向量库、各类 worker 与后端服务状态。
三、业务流程与功能路径
典型路径为：出版社上传原稿 → 发布转码任务 → 转码公司下载原稿（首次下载触发任务进入处理中）→ 回传成果包（先上传文件资产、再创建提交批次）→ 系统自动校验 → 出版社验收（通过则归档，不通过则退回返工）→ 归档后重建切片、生成知识投影用于检索分析。异常文件进入隔离区，处理完成后回到任务流；每一次状态变更都会同步写入状态事件与审计日志，保证全流程可追溯。
历史纸质图书转电子书业务长期依赖邮件和共享盘，在出版社内部与多家外包转码公司之间流转，存在交接标准不一致、任务进度不透明、元数据缺失严重、异常无法追溯、历史资源检索效率低等问题。本项目立项建设一套统一的历史图书数字化资源管理平台，把出版社原稿上传、转码任务发布、外包公司处理、成果回传、内部校验、验收归档、异常隔离到检索分析的全流程收敛到同一系统内，并以约 100TB 级历史资源为目标规模，从底层保证长期稳定运行与快速查询。
二、软件功能与核心功能模块
系统为模块化单体的企业级 Web 后台，前台使用角色为出版社人员与转码公司人员，核心模块包括：
1. 图书与元数据模块：以规范化书号 canonical_book_no 作为图书唯一标识，维护图书、版本与文件资产；书号、作者等元数据由 EPUB 提取而非人工录入。
2. 任务协作模块：出版社发布转码任务，转码公司处理并回传成果，任务状态经状态机受控流转，禁止直接改状态；转码公司侧只呈现待处理、处理中、已回传、已退回、已作废五态，内部校验与验收状态不外泄。
3. 文件与上传模块：受控本地文件存储，支持大文件分片上传、断点续传与对账补传，下载走浏览器原生与 HTTP Range 分片。
4. 校验验收与异常治理模块：成果 EPUBCheck 校验、验收通过或退回、异常隔离与返工闭环，全流程留痕。
5. 归档与检索模块：对归档成果做结构化解析、切片与检索单元生成，并导出只读知识投影。
6. 权限与审计模块：组织级 RBAC、幂等键与 X-Request-Id、操作审计与状态变更事件。
7. 运行健康看板与统计报表：监控数据库、向量库、各类 worker 与后端服务状态。
三、业务流程与功能路径
典型路径为：出版社上传原稿 → 发布转码任务 → 转码公司下载原稿（首次下载触发任务进入处理中）→ 回传成果包（先上传文件资产、再创建提交批次）→ 系统自动校验 → 出版社验收（通过则归档，不通过则退回返工）→ 归档后重建切片、生成知识投影用于检索分析。异常文件进入隔离区，处理完成后回到任务流；每一次状态变更都会同步写入状态事件与审计日志，保证全流程可追溯。
项目实现
一、整体架构与设计思路
采用模块化单体架构，前后端分离。前端 React + TypeScript + Ant Design Pro + Vite，TanStack Query 管服务端状态、Zustand 管会话状态；后端 Python + FastAPI + Pydantic 校验 + SQLAlchemy 2.x + Alembic 迁移；数据库 PostgreSQL（预留 pgvector），异步任务与缓存用 Redis + Celery。文件本体不进数据库，进入受控本地存储，库内只存元数据、状态、索引与存储定位字段；大文件处理、校验、OCR、向量化一律走异步 worker。设计上坚持先冻结契约再写代码：实体模型、数据库 schema、API 契约、前后端设计五份文档冻结后才进入实现，状态变更一律走业务动作端点。
二、我负责的模块和结果
我负责系统从 0 到 1 的设计与实现，覆盖需求契约冻结、后端核心服务、前端后台与归档派生能力。量化结果：仓库累计 277 次提交（2026-05-06 至 09-30）；后端 190 个 Python 文件、20 个 API 模块、15 个服务包、67 个测试文件，阶段一 pytest 288 项全通过；前端 106 个 TS/TSX 文件、39 个测试文件，覆盖 81 个路由入口；EPUB 结构化解析把 14 本样书解析出 4264 个结构节点、33414 条证据记录、3584 个资产；开发库 14 个知识投影结构检查全部通过，统计 6605 个检索单元、31739 条 Canonical 证据；切片/向量化/静态契约定向测试 106 项通过；完成 FMS 与 WeKnora 生产网关打通，首次投影同步已在生产进入 running。
三、我遇到的难点、坑和解决方案
1. 状态机与幂等：外包交接场景重复提交、重复下载频繁，通过定义幂等键和"先上传资产、再建提交批次"两步契约，并在同一事务里写状态、事件与审计解决。
2. 大文件稳定性：采用分片上传 + upload session 断点续传 + 对账补传；下载改走浏览器原生下载与 HTTP Range 分片，避免整包载入内存。
3. 派生内容可追溯：切片必须能回到原文位置，因此引入确定性 embedding_text 与 evidence ID 回溯源文件，并加 tokenizer 与硬上限门禁，超限切片直接阻断而非静默截断。
4. 安全：成果包 EPUB 预览存在脚本执行风险，最终收敛为服务端加前端双层净化（DOMPurify + Shadow DOM），不开放 allow-scripts。
5. 环境坑：Windows/Docker 下 localhost 端口转发异常导致连不上数据库，改用显式端口映射并固化到配置。
采用模块化单体架构，前后端分离。前端 React + TypeScript + Ant Design Pro + Vite，TanStack Query 管服务端状态、Zustand 管会话状态；后端 Python + FastAPI + Pydantic 校验 + SQLAlchemy 2.x + Alembic 迁移；数据库 PostgreSQL（预留 pgvector），异步任务与缓存用 Redis + Celery。文件本体不进数据库，进入受控本地存储，库内只存元数据、状态、索引与存储定位字段；大文件处理、校验、OCR、向量化一律走异步 worker。设计上坚持先冻结契约再写代码：实体模型、数据库 schema、API 契约、前后端设计五份文档冻结后才进入实现，状态变更一律走业务动作端点。
二、我负责的模块和结果
我负责系统从 0 到 1 的设计与实现，覆盖需求契约冻结、后端核心服务、前端后台与归档派生能力。量化结果：仓库累计 277 次提交（2026-05-06 至 09-30）；后端 190 个 Python 文件、20 个 API 模块、15 个服务包、67 个测试文件，阶段一 pytest 288 项全通过；前端 106 个 TS/TSX 文件、39 个测试文件，覆盖 81 个路由入口；EPUB 结构化解析把 14 本样书解析出 4264 个结构节点、33414 条证据记录、3584 个资产；开发库 14 个知识投影结构检查全部通过，统计 6605 个检索单元、31739 条 Canonical 证据；切片/向量化/静态契约定向测试 106 项通过；完成 FMS 与 WeKnora 生产网关打通，首次投影同步已在生产进入 running。
三、我遇到的难点、坑和解决方案
1. 状态机与幂等：外包交接场景重复提交、重复下载频繁，通过定义幂等键和"先上传资产、再建提交批次"两步契约，并在同一事务里写状态、事件与审计解决。
2. 大文件稳定性：采用分片上传 + upload session 断点续传 + 对账补传；下载改走浏览器原生下载与 HTTP Range 分片，避免整包载入内存。
3. 派生内容可追溯：切片必须能回到原文位置，因此引入确定性 embedding_text 与 evidence ID 回溯源文件，并加 tokenizer 与硬上限门禁，超限切片直接阻断而非静默截断。
4. 安全：成果包 EPUB 预览存在脚本执行风险，最终收敛为服务端加前端双层净化（DOMPurify + Shadow DOM），不开放 allow-scripts。
5. 环境坑：Windows/Docker 下 localhost 端口转发异常导致连不上数据库，改用显式端口映射并固化到配置。
示例图片视频
相似推荐
学生综合素质测评系统-学生综合素质测评系统
面向高校、职业院校，用于落实学生综合素质评价改革，替代传统纸质填表、人工汇总打分模式。
1. 学校教务处/学工处：统一制定综合素质评价指标、发布测评任务、审核学生申报材料，汇总全院测评数据，导出报表用于评奖评优、推优入党、毕业鉴定。
2. 辅导员/班主任：查看班级学生申报记录，审核学生提交的活动证明、奖惩材料，给学生打分评语，快速统计班级测评结果。
3. 在校学生：线上填报个人综合素质材料，上传获奖证书、社会实践、志愿活动、文体活动等佐证，查看测评得分与排名。
4. 二级学院：对本学院学生测评数据进行统计分析，掌握学生德育、实践、文体发展情况，辅助学生管理工作。
推优评价系统
项目背景和目标
高校推优（推荐优秀团员作为入党积极分子）工作长期依赖 Excel 和纸质材料，存在几个痛点：
评分口径不统一：不同班级、不同团支书对同一份文件的理解不同，算出来的分数不一致。
材料收集散乱：入党申请书、学习心得、活动证明分散在微信群、邮箱、纸质档案中，难汇总。
推优依据不透明：学生不知道自己的分数怎么来的，容易产生争议。
数据无法沉淀：每学期的推优数据难以跨期对比、难以追溯。
目标： 做一个面向高校党建推优场景的量化评分系统，把"分数怎么算"标准化、"材料怎么交"线上化、"评分依据"透明化。
软件功能
系统有四种角色：
角色 主要功能
学生 上传入党申请书、学习心得；查看自己的推优总分和分项明细
班级团支书 录入本班学生的思政课成绩、群众评议分、缺勤次数
教师 查看本学院排名、导出成绩数据
管理员 用户管理、班级填报解锁、数据中台同步、孤儿文件清理、审计日志
核心功能
推优总分自动计算：把"政治理论与表现（40 分）+ 实践与创新（30 分）+ 群众评议（30 分）"三部分，按规则自动算分。
数据中台积分同步：对接学校数据中台的积分认定接口，自动拉取学生的活动、获奖、志愿服务记录，作为评分的客观依据。
材料上传与管理：学生上传入党申请书、学习心得，后端用签名 URL 保护文件访问。
班级填报闭环：团支书录入班级数据，24 小时后锁定，管理员可解锁。
排名与导出：教师查看本班/本院排名，导出 CSV。
业务流程：
学生登录——上传材料——系统自动计算得分
团支书登录——录入班级数据——提交——24h锁定
管理员登录——同步数据中台——管理用户——解锁填报——导出数据
功能路径描述：
学生：登录 ——首页（查看总分和分项）——理论研学与思考（上传材料）——材料保存后自动重算分数
团支书：登录 ——录入成绩 ——选择班级 ——填写思政课成绩/群众评议/缺勤 ——24 小时内可修改
登录 ——首页（查看排名）——选择班级 ——查看排名 ——导出 CSV
登录 —— 管理首页 ——用户管理 / 班级填报管理 / 数据中台同步 / 孤儿文件清理 / 审计日志
智衍·岗位能力图谱平台
一、立项背景与目标
从"人口红利"转向"人才红利"的关键期，数字经济增速远超人才培养周期，劳动力市场出现严重结构性矛盾：企业端新兴岗位招不到合适的人，求职者端职业路径模糊、技能需求动态性强，技术端传统关键词匹配无法回答"技术A爆发会导致岗位B产生哪些新技能需求"。
核心痛点集中在三个难题：新兴岗位发现与定义、数据质量与幻觉防控、精准匹配与差距分析。
项目目标是构建一套数据驱动的智能决策系统，以岗位和能力为核心实体、以知识图谱为知识载体、以大模型为推理引擎，实现"新岗位发现、能力图谱动态更新、全景可视化、人岗匹配诊断、改进建议与学习路径"的全链路闭环。
服务对象覆盖三类：求职者获得匹配度诊断与个性化提升路径，企业HR实现岗位能力可视化与JD结构化管理，平台运营方完成多源数据治理与图谱演化追踪。
二、软件功能与核心模块
系统采用双角色权限模型，普通用户与管理员登录后导航菜单动态渲染，共九大模块。
普通用户与管理员共同开放六个模块。首页门户是品牌落地页，展示平台价值、六大核心能力、技术架构与数据处理五步链路。工作台是数据总览入口，聚合核心指标卡、岗位-能力图谱、能力雷达、演化时间轴、技能热度趋势、新兴技能前十、热门技能排行、岗位对比。知识图谱以岗位、技能、知识三类节点与带权关系边构成领域图谱，支持多维筛选、四种布局切换、节点详情查看。演化分析回答哪些技能在兴起、哪些在衰退、岗位能力如何随时间迁移，含趋势曲线、演化历史、兴衰前十、事件时间线、迁移桑基图。对比分析支持两岗位横向量化对比，含信息卡、五维雷达、技能差异表、薪资对比、转型路径。岗位匹配完成上传简历、AI提取技能、匹配度打分、能力雷达对比、技能差距分析、学习路径推荐的完整闭环。仅管理员可见三个模块。数据管理覆盖文档管理、网站管理、岗位采集、城市管理、城市代码映射、数据质量评估、操作日志七个页签。实体消歧将原始实体名归一化为标准名称加别名，覆盖岗位、技能、公司三类。系统设置配置AI模型、图数据库、通知与系统信息。
三、业务流程
端到端主流程为：多源数据采集、信息抽取、实体消歧、图谱构建、动态演化分析、人岗智能匹配。
文档入库流程为：上传文档、服务端解析、质量评估、确认入库、进入图谱数据源。招聘采集流程为：配置网站、选择省市与岗位、发起采集生成批次、爬虫抓取JD、质量评估、沉淀为图谱输入。人岗匹配流程为：上传简历选岗位、解析提取技能、多维度打分、输出匹配度与学习路径。
四、功能路径描述
普通用户路径为：登录后浏览知识图谱，筛选布局并点击节点看详情；分析技能演化，切换粒度查看兴衰前十与桑基图；对比两岗位，选A与B查看雷达与差异表；进行人岗匹配，上传简历选岗位查看匹配度与学习建议。
管理员路径为：进入数据管理，上传入库文档并质量评估；岗位采集选网站省市查看批次详情；实体消歧维护标准名称与别名；操作日志审计。
在线选课系统
面向学生与教务管理场景的在线选课系统，解决传统线下选课效率低、课程信息不透明、人工排课易出错的问题。核心功能包括：课程浏览与检索、在线选退课、选课规则校验、个人课表可视化、课程推荐。业务流程为：学生在选课开放周期内查看课程余量，提交选课申请，系统自动校验学分上限、先修课程与时间冲突，通过后写入个人课表并实时扣减课程容量；退课后容量自动回补，支持多轮补选
“华研慧学”小程序
一、立项背景和目标
本项目属 K12 教育科技 / AI 智慧教育 / 家校共育赛道。在"教育数字化""AI 赋能教育"趋势下，教育平台由"卖课"转向"数据驱动的个性化学习服务"。"华研慧学"即在此背景下构建的 AI 学习平台，本项目是其面向学生家长的微信小程序端。
立项旨在解决家长对孩子学习「**看不见、看不懂、跟不上**」的痛点：学情不透明、报告黑盒化、错题难沉淀、缺乏规划闭环、触达门槛高。目标是让家长实时、清晰、可执行地掌握孩子学习情况，打通"学生学→平台诊断→家长监督"的家校协同闭环，提升平台用户粘性与付费转化。
服务对象：K12 学生家长，覆盖小学/初中/高中全学段（一至高三 12 个年级）及语文、数学、英语、物理、化学等全学科。
二、软件功能与核心模块
共 7 大核心模块，采用主包 + 分包架构：
1. 首页（学习情况）：以「周对比/周环比」呈现数据采集、规划练习、新增错题、学习视频四项指标，并提供四大分析入口。
2. 学生管理：学生列表、扫码添加、绑定/解绑/切换学生。
3. 诊断报告：列表 + 详情，含个人情况、能力总评、答题情况、掌握状态、提升建议五维度。
4. 学习报告：列表 + 详情，含学习总评、学情诊断、发展追踪三维度。
5. 学习规划：列表 + 新旧两版详情，结合错题/试卷生成个性化规划。
6. 错题集：按来源/题型/难度/时间多维筛选，解析页支持数学公式（TeX/MathML）渲染。
7. 个人信息：家长信息查看修改、头像上传。
三、业务流程与功能路径
主流程：学生完成学校作业/试卷、平台练习 → 平台 AI 诊断与知识图谱分析（待下载→待提交→待批改→已批改）→ 家长微信登录、扫码绑定学生 → 查看学情数据与报告 → 依提升建议规划练习 → 形成"诊断→规划→练习→批改→再诊断"闭环。
典型路径：首页 → 选择学生 → 点选模块入口 → 报告/规划/错题集列表 → 详情页（筛选、公式解析）→ 返回总览。
登录路径：微信 `uni.login` 获取 code → 请求 `/parent-login/quick/register` → 缓存 token；接口返回 9/11/12 时自动重登。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服