有利益的东西就会挤满了各种参差不齐的资源，2020年以后各种机构直播间开始线上发布一些真的假的消息，主打一个信息不对称，尤其是每年到了7月份中考志愿填报的时候，各大机构更是打破了头抢流量。小机构有时候即便说的是真话也没什么人信。有一段时间我特别热衷于让老板做数字化转型，毕竟真实数据驱动做出来的东西更有说服力，对于工作而言前期虽然比较繁琐但是后续会节省不少时间，但是当初设想过“试题库”，“小初高的学校信息数据库”，最后都不了了之了......原因嘛懂得都懂......
这个项目我很早就写过一个很简单的版本，当时用的是Java spring框架，今年更新了新的学校数据，增加了AI，更新了后台......如果你是家长，那么直接用我的线上版本查一查可以抹平一些信息差。如果你是教培机构的工作人员直接部署到你的服务器上，在后台补全你掌握的学校，就说是你写的，没毛病这叫数据赋能......当然你嫌麻烦数据直接拿走编辑也可以......
👉 在线体验：http://39.107.81.139:8888 (复制项目地址到浏览器体验项目）
Github地址：https://github.com/lsy7800/HighSchoolMatch
这个系统在解决什么问题
中考填志愿填报的核心就是"这个分能上哪所学校"。
分数线每年都在变——题难易、招生计划、报考人数都会影响。所以直接拿今年分数去比去年的录取线，是不准的。但位次（你在全市排第几名）相对稳定，学校每年录取到的最低位次，波动比分数线小得多。
这套系统的核心就是位次法：把你的分数换算成位次，再跟各校历年录取位次比，最后按"冲 / 稳 / 保"三档给你列出来。
⚠️ 结果仅供参考，正式填报请以官方招生政策与发布数据为准。
用户端介绍
用户端一共有四个页面。
1. 志愿推荐
输入分数，系统换算成位次，给你三档学校：冲一冲能上的、稳一点能上的、保底用的。每所学校还会带一个历年位次的小趋势图，能直观看到这学校录取位次是涨是跌。
2. 学校一览
所有学校一张表，可以按名称或代码搜，可以按招生口径、所在区、公办/民办筛，也能按编号或录取分数排序。点学校名字会弹出详情。
点击学校名称可查看详情
3. 智能问答
这个是重点。有什么不明白的直接问AI，AI会调取学校的数据然后回答比如：
"720 分能上哪些学校" "管得严的公办校有哪些" "管得严的公办校 720 分能上哪些"
回答是流式的，字一个个蹦出来。背后不是普通的聊天机器人，而是一个会调工具的 LLM Agent——它有 5 个工具可用：
recommend | |
score_to_rank | |
get_school_detail | |
search_schools_by_text | |
get_thresholds |
第三种复合问题最能体现这套设计的好处：模型先做语义检索拿到候选学校代码，再把这些代码丢给 recommend 跟位次推荐取交集，服务端算完才返回。这样"管得严"和"720 分能上"两个条件是同时满足的，不是 LLM 自己脑补的。
4. 一分一段表
全市和市内六区的累计位次表，可以输入分数定位高亮，对照用。
**2026年新版一分一段表出来后可以直接替换掉2025年的表**
关于数据
天津中考有个细节：市内六区考生只能报"面向市内六区招生"和"面向全市招生"的学校，"面向郊区招生"的学校报不了。
系统把这条规则做进去了：
目前只支持市内六区考生，后续可扩展； "面向郊区"的学校，已经从推荐结果和学校一览里自动排除（数据还在库里，没删）； 一分档里"全市累计"和"市内六区累计"两列都有，按学校招生口径自动配对——市内六区招生的学校用市内六区位次比，面向全市的用全市位次比。
这样推荐出来的学校，都是考生真能报的，不会出现"看着能上、其实填不了"的情况。
学校信息里有一个‘学校介绍’的字段我没有填，这个字段是用来填写一些公开采集不到的信息，比如学校管理严不严？入校收不收手机？饭好不好吃，等等关于这一字段大家各凭本事填就好。
部分2026年新增的学校目前还没有招生代码，等到今年的《报考指南》出了把新增的学校添加上就好
2026年的中考一分档下来之后直接上传替换2025年的文件就可以用位次来推算学校了，原理很简单
技术选择
更新过后整个项目没有用到什么特别高深的技术，但有几处设计想聊一下。
语义检索没用向量数据库。 一共就 137~278 所学校，这点数据量，直接把 embedding 存进 SQLite，内存里暴力算余弦相似度，亚毫秒级就回来了。Pinecone、Milvus 这类组件在这个量级完全是杀鸡用牛刀。模型用 bge-m3（硅基流动远程 embedding），按 doc_hash + model 增量重建，只重算 intro 改过的学校。
智能问答走 tool calling，不是 RAG。 常见的 RAG 是"检索 → 拼 prompt → 生成"，让 LLM 凭拼接的上下文回答。这里没这么干，而是让 大模型 通过 tool calling 主动去调位次引擎、语义检索、学校详情这些工具。复合条件的交集在服务端算，比让 LLM 自己猜精确得多。这个解决方案我觉得后续还需要优化一下，让回答更合理。极有可能放弃当前的这套方案。
前后端同源 + SSE 流式。 前端 nginx 反代 /api，浏览器没有跨域问题。流式回答靠 proxy_buffering off 加后端 X-Accel-Buffering: no，能实时下发，不是等全部生成完才返回。
技术栈：
后端：FastAPI + SQLAlchemy 2.0 + SQLite + pydantic v2 前端：Vue 3 + Vite + Element Plus LLM / 检索：DeepSeek API（tool calling）+ 硅基流动 bge-m3 部署：Docker Compose
部署
整个项目 Docker Compose 一键起，第一次启动会自动导入一分档和高中数据，之后重启不会重复导入。
cp .env.example .env # 填 4 个必填项docker compose up -d --build必填的环境变量就 4 个：管理后台密码、JWT 密钥、硅基流动 API Key、DeepSeek API Key。SQLite 数据放在命名卷里，要清数据得 docker compose down -v。后端容器不对外暴露端口，只走前端 nginx 反代。
管理后台
给运营者用的（/admin，登录后可用）：
数据导入：上传 xlsx 导一分档 / 高中数据，可以先预览再入库 学校管理：增删改学校信息和历年录取数据 数据导出：学校列表导出 xlsx / csv 阈值配置：调冲 / 稳 / 保的分类阈值 向量索引：补完学校简介后一键重建（增量）
最后
填志愿本质是个信息差的事。家长缺的不是关心，是把官方数据算明白的工具。这个项目做的，就是把"位次法"从懂行的人手里，搬到任何一个会打字的家长面前。
再次强调：结果仅供参考，正式填报以官方数据为准。
项目已开源，欢迎交流。
