用 Codex 做一个高考志愿推荐系统，AI到底能做到啥程度？

用 Codex 做一个高考志愿推荐 Demo：从前后端开发到 Docker 一键部署

前言

这次项目的目标并不是一开始就做一个成熟的商业产品，而是先快速做出一个能跑通核心链路的测试 Demo：用户登录，录入成绩与位次，填写选科和偏好，系统基于本地历史数据做规则筛选，再结合 AI 生成一份“冲、稳、保”推荐报告，最后通过 H5 页面展示出来。

这个项目的特别之处在于，很多工作并不是纯手工一点点敲出来的，而是借助 AI，尤其是通过 Codex，完成了前端、后端、部署脚本和云服务器落地的一整套工作。它非常适合拿来讨论一个现实问题：AI 到底能把一个项目推进到什么程度，又在哪些地方还远远不够。

这个项目实现了哪些功能模块

1. 用户账号与登录模块

前端已经提供了登录页、注册页和找回密码页，后端也实现了对应接口。

• 登录支持手机号、密码、图形验证码。
• 注册支持新用户提交手机号、姓名和密码。
• 找回密码支持基于手机号和姓名重置密码。
• 登录后会签发 token，前端保存本地会话状态。
• 管理员路由与普通用户路由已经做了基本区分。

这点其实很值得单独提一下。因为 AI 在最早生成页面时，确实出现过“登录页竟然没有密码”这种非常离谱但又很典型的问题。它能快速拼出一个页面，但不一定天然理解一个真实系统最基本的安全常识。后面还是要靠人去审、去改、去补，最终才变成现在这种比较正常的登录流程。

2. 考生信息录入模块

这是整个业务流程的入口，也是 H5 的核心页面。

edb51a8a6f27422156ecf982cb35828e.png

• 支持填写高考年份、成绩、全省位次。
• 支持选择选科组合。
• 支持填写风险偏好、预算倾向、是否接受民办或中外合作。
• 支持选择目标城市、偏好专业、职业目标。
• 支持上传成绩或位次截图作为辅助复核材料。
• 已经加入 OCR 识别尝试，用于从截图中自动提取部分信息并辅助回填。

从产品逻辑上看，这一块已经不只是“填一个表单”，而是在往真实业务表单靠近。它开始有约束条件、偏好项和可复核材料，这让后面的推荐结果不再只是一个随机生成的文本。

3. 志愿推荐与结果展示模块

后端目前已经实现了一条完整的推荐链路。

• 根据本地招生样例数据进行筛选。
• 按位次做核心匹配。
• 按选科要求过滤不可报专业。
• 按城市、专业、预算和风险偏好做进一步过滤。
• 形成“冲、稳、保”分层建议。
• 生成推荐报告并保存历史记录。
• 前端结果页支持查看报告摘要、推荐条目、风险提示和人工复核事项。

也就是说，这个项目不是只有一个“AI 聊天框”，而是已经具备了一个比较清晰的业务闭环。AI 的角色更像解释器和报告生成器，而不是凭空拍脑袋给建议。

4. 历史报告与基础管理模块

虽然还不是完整后台，但已经有一些可用雏形。

• 用户可以查看历史推荐报告。
• 报告与账号绑定，支持回看。
• 已有管理员页面占位。
• 后端有用户、会话、推荐报告、操作日志、系统事件日志、LLM 调用日志等数据结构。

这一部分说明项目已经开始考虑“留痕”和“管理”，而不是只做一次性页面演示。

5. AI 网关与质量控制模块

这个项目里最有意思的一点，是 AI 并不是直接裸奔输出结果，而是被放在一个受控流程里。

• 后端预留了 OpenAI Compatible 和火山方舟等模型接入配置。
• 有 LLM 网关和调用日志结构。
• 有结果后校验机制，例如候选池校验、承诺词校验。
• 推荐结果里保留人工复核提示和免责声明。

这说明项目在架构上已经意识到：AI 输出不能直接等于业务结论，必须经过规则约束、候选范围约束和人工复核提示。这是很重要的一步。

AI 和 Codex 在这个项目里具体做了什么

如果只说“AI 帮我写了代码”，其实太空了。更准确的说法是，Codex 在这个项目里承担了一个“高效率工程助手”的角色，而且覆盖面很广。

1. 帮做了前端页面和交互骨架

前端部分已经能看出明显的 AI 参与痕迹。

• 生成了登录、注册、忘记密码、首页、结果页、管理页等页面骨架。
• 帮忙接好了 Vue 3、Vite、TypeScript、Pinia、Axios、Element Plus 这一套基础结构。
• 补出了表单流、历史报告查看、路由守卫、运行模式切换等典型逻辑。
• 适配了浏览器模式和小程序 WebView 模式两种展示文案。

它的优势是快。很多原本要从零开始搭的页面和状态流，几轮对话就能出一个可运行版本。

2. 帮做了后端接口和业务主链路

后端并不是只有几个空接口，而是已经形成了 Spring Boot 的完整结构。

• 生成了认证接口、资料保存接口、推荐接口、管理接口雏形。
• 搭了领域模型、Repository、Controller、配置类和异常处理。
• 做了 token 会话、图形验证码、密码加密、基础权限控制。
• 把推荐流程拆成了数据筛选、规则分层、AI 说明生成、报告保存几个环节。

对于一个测试项目来说，这种速度是非常有价值的。它让“一个想法”很快变成“一个能访问、能登录、能出结果的系统”。

3. 帮做了 Docker 化和一键部署

这部分其实是很多 Demo 最容易卡住的地方，但 Codex 在这里的帮助非常直接。

• 写出了docker-compose.yml，把 MySQL、后端、前端三个容器串起来。
• 给小内存服务器做了内存限制、CPU 限制、日志轮转等配置。
• 提供了 Windows、本地 Linux、云服务器等多套部署脚本。
• 补了deploy.ps1、deploy.sh、server-first-deploy.sh、centos76-deploy.sh等脚本思路。
• 针对腾讯云 CentOS 7.6 这种具体环境，补了从解压、装 compose、建 swap 到启动服务的说明。

这就让项目不再停留在“本机能跑”，而是进一步走到了“别人拿到包也能部署”的阶段。

4. 帮项目打通公网访问路径

当前项目已经明确面向公网访问做了部署说明和端口暴露设计。

• 前端容器默认暴露 `8080 端口。
• 文档里明确要求在云服务器安全组放行22和8080。
• 如果后续接域名和 HTTPS，还可以继续放行80和443。
• 用户可以直接通过浏览器访问公网 IP 查看和登录系统。

这一步虽然不是复杂算法，但对一个项目能不能“展示出去”非常关键。很多 AI 生成项目死在本地，原因不是功能没有，而是根本没有把部署和公网访问做通。

5. 帮适配了小程序查看场景

这里要实事求是地说：当前不是完整原生小程序，而是 H5 对小程序 WebView 场景做了适配。

• 前端有browser和miniapp两种运行模式。
• 能根据参数、缓存和 User-Agent 切换展示状态。
• 页面文案会根据是否处于小程序环境调整。
• 这意味着同一套 H5，可以面向浏览器使用，也可以嵌入小程序中进行查看、登录和结果展示。

这已经足以支撑“浏览器 + 小程序承载页”的 Demo 级验证，但距离真正的小程序原生产品，显然还有不少工作要做。

Codex 对这个项目的影响

如果总结 Codex 带来的最大变化，我认为不是“省了多少敲代码时间”，而是它显著改变了项目从想法到落地的速度。

正面影响

第一，原型成型速度极快。
很多以前要花几天才能拼起来的前端页面、接口骨架、部署脚本，现在可能几个小时内就能看到一个能跑的版本。

第二，降低了全栈门槛。
一个人不一定同时精通前端、后端、运维，但借助 Codex，可以先把各部分的基础结构搭起来，再逐步修正。

第三，特别适合做“从 0 到 1”的验证。
当一个产品想法还没有证明价值时，先用 AI 快速做个 Demo，是非常划算的做法。它能快速验证用户流程、功能链路和部署可行性。

第四，部署能力提升明显。
很多人做 Demo 最大的问题不是代码本身，而是部署不会、Docker 不熟、云服务器环境复杂。Codex 在这些工程细节上提供了很强的补齐能力。

Codex 的缺点和这次踩过的坑

如果只谈优点，那结论一定是不真实的。这个项目恰恰说明，Codex 很强，但远远没有强到“你一句话，它就替你做出生产级产品”。

1. 会做出看似完整、实则不合理的页面

最典型的例子就是登录页。

AI 很容易生成一个“长得像登录页”的东西，但它不一定天然具备真实产品的完整意识。早期甚至会出现没有密码输入这种明显不合理的问题。后来虽然补上了密码、验证码、注册和找回密码，但这个过程说明：AI 生成的是初稿，不是终稿。

2. 页面经常不好看，需要不断调整

这一点几乎是所有人用 AI 做前端都会遇到的问题。

• 页面能生成，但视觉审美往往不稳定。
• 它能做出“像那么回事”的布局，但离真正耐看的产品页面还有距离。
• 字体、层次、间距、色彩和组件一致性，经常需要人工反复改。

简单说，AI 能把页面“搭出来”，但很难一步到位把页面“设计好”。这个项目现在能看、能用，但如果以正式产品的 UI 标准去看，仍然需要持续打磨。

3. 不会主动替你做架构级选择

AI 通常更擅长顺着现有上下文补代码，而不是主动承担关键架构决策。

比如：

• 它不会天然判断你现在该不该引入新的第三方框架。
• 它不会自动帮你平衡“快速上线”和“长期维护”的成本。
• 它不会替你承担安全、合规、权限、审计等最终责任。

如果你没有明确要求，它通常会优先在现有结构里继续拼，而不是主动重构到一个更成熟的体系。

4. 很容易把 Demo 做成“能跑就行”

AI 最擅长的是先把东西做出来，但这也意味着它天然偏向“先可运行”，不天然偏向“先高质量”。

所以你会发现：

• Mock 数据很多。
• 占位页面很多。
• 规则能跑，但边界不一定完善。
• 异常处理虽然有，但未必覆盖真实线上场景。
• 安全能力、监控能力、性能能力还比较初级。

这不是它做错了，而是它的默认优化目标通常是“完成任务”，而不是“达到工业级交付标准”。

为什么说它目前只能算测试 Demo

从这个项目的当前状态看，我认为把它定义为“测试 Demo”是准确的，也是负责任的。

已经具备的能力

• 核心流程跑通了。
• 前后端都有了。
• 登录、录入、推荐、结果展示、历史报告这些主链路具备了。
• Docker 一键部署和公网访问已经打通。
• 还能兼顾浏览器和小程序 WebView 的展示场景。

这些已经足够拿来做演示、验证流程、给团队讨论方向，甚至给潜在用户看一个初步版本。

距离生产产品还差什么

但如果要真正走向生产，仍然有大量工作要补。

• 真实高考数据源需要持续校验与更新，不能只靠样例数据。
• 推荐规则需要更细，不能只停留在 Demo 级筛选。
• 账号体系、安全策略、权限审批和风控需要加强。
• 真正的小程序端能力、域名、HTTPS、WebView 合法域名配置都要完善。
• AI 模型接入、提示词治理、输出评估、成本控制都要进入正式工程化阶段。
• 监控、日志检索、告警、容灾、备份、审计等能力都还需要补。
• UI 和交互需要持续打磨，不然用户第一眼就会觉得“像个测试页”。

换句话说，AI 很适合帮你把“毛坯房”快速盖起来，但真正能交付用户长期使用的产品，后面还有非常重的装修、水电、结构加固和长期维护工作。

我对 Codex 的真实看法

经过这个项目，我对 Codex 的看法很明确。

它不是一个“替代开发者”的工具，更像一个能显著提高产出速度的全栈协作器。它特别适合做这些事：

• 快速搭原型。
• 补前后端骨架。
• 写重复性很强的业务代码。
• 生成部署脚本和基础运维配置。
• 帮人跨过原本不熟悉的技术门槛。

但它不适合被神化。

因为真正决定一个项目能不能从 Demo 走向产品的，仍然是人对业务、架构、安全、体验和质量的持续判断。AI 可以把起点往前推很多，但没法替你走完整条路。

结语

如果只看结果，这个项目已经说明了一件事：借助 Codex，AI 确实可以帮助个人或小团队，在很短时间内做出一个包含前端、后端、AI 能力、Docker 部署和公网访问能力的完整演示系统。

但如果再往深一层看，它也同时说明了另一件事：AI 做出来的第一版，通常只能算可运行的测试 Demo。要把它打磨成真正能上线、能稳定服务真实用户的产品，仍然需要持续补数据、补安全、补体验、补工程质量。

所以最现实的结论不是“AI 已经能完全代替开发”，而是：

AI，尤其是 Codex，已经非常适合拿来做项目的第一阶段加速器；但从 Demo 到生产，依然是一场需要长期打磨的工程。