搭建一个基于 Vue3 的后台管理系统主要包含商户库存、周期询价、实时查价、供应商 Top10 等业务模块。项目本身并不复杂到需要特别强调业务但它非常适合作为 Codex 的实践案例因为它具备典型后台项目的特点页面多、字段多、接口多、需求变化频繁、交互细节不断调整。开发过程中Codex 参与了代码 Review、架构统一、接口接入、页面重构、状态轮询、跨模块跳转、供应商详情复用和构建校验等工作。通过这个项目可以比较清楚地看到Codex 的价值并不只是生成一段代码而是能够围绕一个真实工程持续推进任务。1. Codex 更适合“工程任务”而不只是代码片段生成很多人第一次使用 AI 编程工具时习惯把它当成一个代码问答助手。比如问它“这个函数怎么写”“这个组件怎么封装”“这个报错是什么意思”。这些当然可以但不是 Codex 最有价值的地方。在真实项目里一个需求通常不是写一个函数就结束。例如“接入实时查价模块”这个需求背后包含很多步骤阅读接口文档理解接口路径、参数和响应字段查看项目中已有 API 封装风格新增 TypeScript 类型新增接口请求函数修改 Vue 页面删除 mock 数据增加 loading 和 error 状态增加筛选条件增加分页增加批次展开增加任务列表增加供应商详情跳转运行类型检查和构建根据报错继续修正如果只是普通代码生成工具可能只能完成其中一小段。但 Codex 更像是在执行一个完整工程任务。它会先查项目结构再看已有代码再决定在哪里新增文件、在哪里修改组件、在哪里改路由。这个过程更接近一个开发者接手需求后的工作方式。所以使用 Codex 时建议不要只把问题拆成很碎的代码片段而是可以直接给它一个工程目标。例如按照接口文档接入实时查价模块保持和现有 Vue3 架构一致。这样的指令比“帮我写一个请求函数”更能发挥 Codex 的能力。2. 让 Codex 顺着项目架构工作在这个 Vue3 项目中代码结构相对清晰页面组件放在src/componentsAPI 请求封装放在src/api路由集中在src/router/index.ts通用 HTTP 请求在src/api/http.ts样式主要使用 Tailwind CSS当接入新模块时比较好的方式不是让 Codex 直接在页面里写fetch而是让它先观察现有结构。比如项目中已经有src/api/inventory.ts src/api/periodic.ts那么接入实时查价时Codex 就会新增src/api/realtime.ts并在其中封装实时查价相关接口例如getRealtimeBatches()addRealtimeBatch()getRealtimeBatchTasks()getRealtimeSuppliers()页面组件只负责调用这些 API而不是把请求逻辑散落在模板组件中。这一点很重要。AI 写代码最大的风险之一是生成的代码“能跑但不融入项目”。如果每次需求都生成一套自己的结构项目很快会变得难维护。Codex 的优势是可以阅读现有代码并按已有风格继续扩展。所以在实际使用中给 Codex 的指令可以强调按现有 API 封装风格实现。保持和现有页面组件结构一致。不要新增重复页面优先复用已有组件。这些约束会让 Codex 更像团队成员而不是外部代码生成器。3. 接口文档驱动开发非常适合 Codex这个项目中有一份接口文档frog-bid-api.md里面定义了商户库存、周期询价、实时查价等接口。Codex 非常适合处理这种“接口文档到前端代码”的转换。以实时查价模块为例接口包括获取实时查价门店列表获取实时查价车型名称列表获取实时查价车型配置明细列表获取实时查价起租日期列表新增实时查价批次获取实时查价批次列表获取批次下任务列表获取实时查价供应商 Top10这些接口如果人工逐个接入需要不断复制字段、写类型、写请求函数、写页面逻辑。Codex 可以根据文档中的路径、参数和响应字段快速补齐 TypeScript 类型和请求方法。例如它会为批次、任务、供应商等定义类型exportinterfaceRealtimeBatch{...}exportinterfaceRealtimeTask{...}exportinterfaceRealtimeSupplier{...}然后在组件中使用这些类型减少字段拼写错误和结构不清晰的问题。不过接口文档驱动开发有一个前提文档要准确。如果后端更新了字段就需要明确告诉 Codex实时查价接口已更新至frog-bid-api.md按最新文档调整。Codex 可以高效执行“文档到代码”的工作但它不能自动知道后端刚刚改了什么。因此接口文档的及时同步仍然是人的责任。4. TypeScript 校验让 Codex 更可靠Codex 写代码很快但真正让它适合工程实践的关键是修改后的校验闭环。这个项目中每次主要修改后都会运行npm.cmd run check这个命令包含vue-tsc--noEmitvite build也就是说不只是看代码表面是否合理还要让 TypeScript 和构建工具实际检查一遍。这个过程发现过不少问题例如类型字段缺失字段加到了错误的接口类型上模板引用了不存在的变量import 未使用函数定义后没有被调用路由名称或参数不匹配比如实时查价任务列表增加“结束日期”时逻辑需要支持endDate。一开始类型补充到了批次类型中而不是任务类型中vue-tsc就直接报错。Codex 根据错误再修正把endDate?: string补到了RealtimeTask上。这说明 Codex 的正确使用方式不是“相信它一次生成的代码”而是让它完成修改代码 → 运行检查 → 读取错误 → 修复错误 → 再次检查这个闭环非常关键。没有校验的 AI 代码只是草稿有校验闭环后才更接近可交付代码。5. Vue3 单文件组件的改造能力这个项目的大部分开发都发生在.vue单文件组件中。Vue3 的script setup写法让逻辑相对集中但实际修改时仍然要同时处理TypeScript 类型响应式状态computedwatch生命周期模板结构表格字段按钮事件弹窗状态路由跳转Codex 在这类组件改造中比较实用因为它能同时处理脚本区和模板区。例如需求周期询价详情里数据采集状态放在采集时间后面。看起来只是换两列顺序但正确修改需要调整表头顺序调整对应数据单元格顺序确认空状态和 loading 状态的colspan确认表格最小宽度是否需要调整再比如实时查价任务表格车型、车牌不需要前面补充开始日期和结束日期。这个需求需要删除任务表中的车型列删除车牌列增加开始日期列增加结束日期列如果接口没有endDate根据startDate duration计算补充RealtimeTask.endDate?: string确认构建通过这些都是典型的前端后台表格需求。人工做并不难但容易遗漏同步修改。Codex 的优势是可以快速定位相关模板和逻辑并在修改后运行校验。6. 后台表格类需求非常适合 Codex后台系统开发中表格字段调整是高频工作。比如这个项目中出现过很多类似需求表格后面加一列某一列移动位置某个字段不显示某个字段改名某些操作按钮互斥某些按钮根据状态禁用任务统计卡片默认收起筛选项增加清除按钮批次号隐藏操作列增加复制按钮这些需求单个看都很小但数量多了非常耗时间。更麻烦的是它们往往需要保持一致性表头、表体、空状态、宽度、按钮样式都要同步。Codex 对这种“细碎但有规律”的工作非常擅长。它能快速找到表格区域修改模板补充逻辑并运行构建。人更多负责判断业务规则而不是花时间在模板中来回查找。7. 状态流转和轮询逻辑采集类业务通常有状态变化例如待采集采集中采集成功采集失败如果页面不自动刷新用户就需要手动刷新或重新查询。这个项目中实时查价和周期询价都加入了轮询机制。实时查价的轮询规则是新建任务成功后立即刷新批次列表批次列表每 5 秒刷新一次持续 2 分钟后停止当前展开的任务列表每 5 秒刷新一次当任务全部不再是待采集或采集中时停止收起批次或离开页面时停止周期询价的轮询规则是任务统计中runningCount 0或pendingCount 0每 5 秒刷新任务统计和任务列表当两个值都为 0 时停止查询、重置、翻页、切换批次、离开页面时停止旧轮询这里 Codex 的实现不只是简单写一个setInterval。真正重要的是边界处理静默刷新避免页面每 5 秒闪 loading避免重复开启多个 interval状态结束后自动停止组件卸载时清理定时器查询条件变化时停止旧轮询翻页后按新页面数据重新判断这些细节对长期运行的后台页面很重要。否则很容易出现重复请求、内存泄漏或页面状态错乱。8. 路由跳转和页面预填项目中有一个比较典型的跨模块流程在周期询价详情中点击“实时查价”跳转到实时查价模块并自动打开新建实时查价弹窗。这个功能涉及多个技术点周期询价详情新增按钮只有采集成功时按钮可点击点击后跳转/realtime使用 query 携带城市、门店、渠道、车型、开始日期、取还车时间、租期等字段实时查价页面读取 query自动打开新建弹窗根据渠道和城市门店加载车型配置尽量自动匹配车型配置匹配不到时保留弹窗让用户手动选择这个需求如果手写需要跨多个文件处理状态。Codex 可以同时修改周期询价详情组件和实时查价组件把跳转、参数解析、弹窗状态和异步加载逻辑串起来。这种能力在真实后台系统中很有价值。很多业务不是单页面完成而是从一个模块跳到另一个模块并带入上下文。Codex 能处理这种跨页面协作逻辑。9. 组件复用供应商 Top10 详情供应商 Top10 详情页最开始用于周期询价后来实时查价也需要同样的页面展示。如果人工开发可能会很自然地复制一个新页面。但复制页面会带来维护成本样式改两遍字段改两遍bug 也可能改两遍。Codex 的处理方式是复用已有SupplierDetail.vue。新增实时查价供应商路由/realtime/supplier/:supplierId然后在供应商详情页中判断来源如果路径来自/periodic调用周期询价供应商接口如果路径来自/realtime调用实时查价供应商接口这样页面结构、返回逻辑、表格展示都可以复用。这个例子说明Codex 不只是会“生成新代码”也可以帮助做更合理的工程复用。前提是指令要明确例如点击效果和周期询价详情里的“查看供应商价格”保持一致不要弹窗跳转新页面。Codex 就会倾向于复用现有详情页而不是继续保留弹窗。10. 新建、复制和预填表单实时查价模块中有一个很实用的功能复制已有批次新建一条类似任务。实现上需要在批次表“备注”后增加“操作”列操作列放一个 Copy 风格按钮点击后打开新建实时查价弹窗将当前批次的渠道、城市、车型配置、开始日期、取还车时间、租期、备注带入保存时仍然调用新增接口这个需求体现了 Codex 对表单状态管理的处理能力。它不仅要打开弹窗还要处理异步加载车型配置的问题。因为车型配置列表依赖渠道和城市门店不能简单把vehicleCfgId塞进表单就结束。需要先设置渠道和门店再加载车型配置最后回填车型配置 ID。Codex 在这里加入了临时抑制 watch 的逻辑避免自动加载过程把已回填字段清掉。这类细节如果人工实现也需要认真考虑。11. 使用 Codex 时如何写需求通过这个项目可以明显感受到Codex 的输出质量和需求描述的清晰度高度相关。不太好的指令是优化一下页面。这种说法太宽泛Codex 也能做但很可能和实际预期有偏差。更好的指令是实时查价任务表格去掉车型和车牌在前面补充开始日期和结束日期。结束日期优先用接口返回的 endDate没有则用 startDate duration 计算。或者周期询价详情中当任务统计里的采集中或待采集数量任意一个不为 0 时每 5 秒刷新任务统计和任务列表当两个值都为 0 时停止轮询。这种需求具备几个特点改哪个模块改什么字段保留什么行为触发条件是什么停止条件是什么Codex 对这种明确需求执行得非常好。12. Codex 的边界和注意事项Codex 很适合工程实现但它不是业务负责人。使用时需要注意几个边界。第一业务规则必须由人明确。例如状态为2才能点击操作状态为0可以停用状态为-1可以启用这些规则不能依赖 Codex 猜。第二接口字段必须以最新文档为准。如果后端更新了接口最好明确告诉 Codex 使用最新接口文档。否则它可能沿用之前的字段。第三生成结果必须经过 Review。类型检查只能证明代码可以构建不代表业务一定正确。比如结束日期如何计算、轮询时长是否合理、复制任务是否复制备注都需要业务确认。第四项目历史质量会影响效率。这个项目中部分中文在终端输出时出现乱码导致 Codex 做文本补丁时偶尔匹配失败。虽然最后可以通过更小范围的结构性修改解决但如果项目编码统一、文案干净效率会更高。第五不要让 Codex 无限扩大范围。如果需求是改一个字段就让它改一个字段。除非明确要求重构否则不要让它顺手改太多。工程协作中控制修改范围很重要。13. 更推荐的协作模式结合这次实践我认为比较理想的 Codex 协作模式是人提出明确目标比如“把实时查价 TOP10 从弹窗改成跳转详情页”。Codex 阅读代码和定位文件它会查路由、组件、API 封装。Codex 修改代码包括脚本逻辑、模板、类型、路由等。Codex 运行校验通过npm.cmd run check检查类型和构建。人验收业务效果判断是否符合真实使用习惯。根据反馈继续迭代比如字段顺序、按钮样式、轮询规则继续调整。这种协作方式下人和 Codex 的分工比较清楚人负责业务判断、接口确认、交互取舍Codex 负责代码定位、实现、类型补齐、构建校验14. 总结这次 Vue3 后台项目实践说明Codex 最适合的不是一次性代码生成而是持续工程协作。它擅长理解项目结构按现有风格扩展代码根据接口文档生成 API 和类型修改 Vue3 单文件组件调整后台表格字段实现弹窗、筛选、分页和按钮状态处理路由跳转和跨页面预填实现状态轮询复用已有详情页运行类型检查和构建而人的重点应该放在明确业务规则确认接口语义控制需求范围Review 结果做最终验收如果只是把 Codex 当成“帮我写一段代码”的工具它的价值会被低估。更好的方式是把它当成一个可以持续协作的工程助手。特别是在后台管理系统这类页面多、字段多、接口多、需求变化快的项目中Codex 可以明显降低重复劳动提高开发节奏。简单来说Codex 适合承担“实现和验证”人负责“判断和决策”。这两者结合起来才是目前 AI 编程工具在真实工程里最有效的使用方式。