用 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 可以把起点往前推很多但没法替你走完整条路。结语如果只看结果这个项目已经说明了一件事借助 CodexAI 确实可以帮助个人或小团队在很短时间内做出一个包含前端、后端、AI 能力、Docker 部署和公网访问能力的完整演示系统。但如果再往深一层看它也同时说明了另一件事AI 做出来的第一版通常只能算可运行的测试 Demo。要把它打磨成真正能上线、能稳定服务真实用户的产品仍然需要持续补数据、补安全、补体验、补工程质量。所以最现实的结论不是“AI 已经能完全代替开发”而是AI尤其是 Codex已经非常适合拿来做项目的第一阶段加速器但从 Demo 到生产依然是一场需要长期打磨的工程。
用 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 可以把起点往前推很多但没法替你走完整条路。结语如果只看结果这个项目已经说明了一件事借助 CodexAI 确实可以帮助个人或小团队在很短时间内做出一个包含前端、后端、AI 能力、Docker 部署和公网访问能力的完整演示系统。但如果再往深一层看它也同时说明了另一件事AI 做出来的第一版通常只能算可运行的测试 Demo。要把它打磨成真正能上线、能稳定服务真实用户的产品仍然需要持续补数据、补安全、补体验、补工程质量。所以最现实的结论不是“AI 已经能完全代替开发”而是AI尤其是 Codex已经非常适合拿来做项目的第一阶段加速器但从 Demo 到生产依然是一场需要长期打磨的工程。
