时间紧、不会写代码，我让AI帮我选技术栈——一次真实的框架选型挣扎

更新于 2026年10月10日 · 荣哥
技术选型 AI代理开发 RuoYi-Vue-Plus 智采云 框架对比

背景：某高校采购管理系统原型急需落地。我一个人扛项目，代码功底一般，打算指挥AI代理开发。面对两套成熟框架，我经历了从”选业务积累”到”选技术匹配”的思维转变。

一、我面临的局面

我是一个非典型开发者——懂业务、懂需求、能看代码，但让我从零手撸一套采购管理系统，我心里是没底的。

学校要上一个采购管理系统，覆盖从采购申请、任务分配、供应商报价、合同签订到结算报账的全流程。我之前用 Vue 3 + Element Plus 搭了一个前端原型 gkd-web，12个页面、完整的交互逻辑、mock数据驱动，跑起来像模像样。但原型终究是原型，没有后端、没有真实数据流转，就是一张漂亮的皮。

Deadline 不等人，我必须尽快把这个原型变成一套真正能跑的系统。

我的开发策略很明确：我不亲自写代码，我指挥 AI 写。Kimi Agent、WorkBuddy、DeepSeek Harness——这些AI代理是我的”开发团队”。

但问题来了：AI 再强，也需要一个好的”脚手架”。我该让 AI 在哪套框架上搭建这个系统？

二、两套框架，两种截然不同的基因

我的备选有两个，恰好都在手边：

候选A：gkd-Vue-Plus

这是 RuoYi-Vue-Plus 6.0 官方发行版，一个极其现代化的企业级后台管理框架。

  • 后端：Spring Boot 4.1 + JDK 21，Sa-Token 权限、MyBatis-Plus、WarmFlow 工作流、SnailJob 调度、Redisson 缓存——基础设施堪称豪华
  • 前端：双前端架构，官方管理端 plus-ui（Vue 3.5 + Element Plus 2.14 + Pinia + Vite 8）+ 业务前端 ark-web（Vue 3.5 + Naive UI）
  • 业务模块：ruoyi-biz 只有基础数据（供应商库、专家库、品目库、代理机构库），完全没有采购流程

候选B：zcy-blank-framework（智采云）

这是一个已经存在几年的采购云平台框架，看起来就是为采购场景生的。

  • 后端：Spring Boot 2.5 + JDK 1.8，MyBatis-Plus 3.4，技术栈相对传统
  • 前端：Vue 3.1 + Element Plus 1.0.2-beta.55 + Vuex + Vite 2.4——注意这个版本号，beta 版，2021年的老酒
  • 业务痕迹：采购类型（Cglx）、采购结果状态（CgjgStatus）、采购进度（PurchaseProgress）、耗材管理、流程审批、支付对接、供应商/专家/品目选择器——满满都是采购业务的积累

一开始，我倾向于 zcy。理由很朴素：人家就是干采购的，业务模型成熟，复用现成的不好吗？

三、第一轮分析：业务积累的诱惑

我第一次分析（也是之前某个AI助手的建议）核心论据就一个：zcy-blank-framework 有采购业务的积累，可以复用。

这个论据是成立的。打开 zcy-web 的 main.ts，满眼都是采购专用组件：

  • ZcyCgsqrSelect —— 采购申请人选择器
  • ZcyGysSelect —— 供应商选择器
  • ZcyZjSelect —— 专家选择器
  • ZcyPmSelect / ZcyPmTree —— 品目选择器/树
  • ZcyDljgSelect —— 代理机构选择器
  • ZcyStepPbProgress —— 采购步骤进度条

后端常量文件更是直接定义了采购的状态机：Cglx（采购类型）、CgjgStatus（采购结果状态）、PurchaseProgress（采购进度）。

这就像一个装修队走进一间房子，发现墙上有现成的水电走线、地板已经铺好，虽然装修风格老了点，但骨架都在。相比之下，gkd-Vue-Plus 的后端 ruoyi-biz 只有几张基础数据表，采购流程的业务逻辑完全空白。

如果我是一个全栈老手，有大把时间慢慢打磨，zcy 可能真的是更省心的选择。

但我不是。

四、第二轮分析：当我把”AI代理开发”放进等式

重新思考这个问题，是因为我意识到一个被我忽略的决定性变量：我不是人写代码，是AI写代码。

这个前提改变了一切。

4.1 前端技术栈的鸿沟

我的原型 gkd-web 是用 Vue 3.5 + Element Plus 2.13 + Pinia 3 + Vite 7 + TypeScript 5.9 写的。看看两个候选框架的前端技术栈：

技术项gkd-webgkd-Vue-Pluszcy-web
Vue3.5.313.5.403.1.4
Element Plus2.13.62.14.31.0.2-beta.55
状态管理Pinia 3Pinia 4Vuex 4
Vite7.3.18.1.52.4.1
TypeScript5.9.36.0.34.3.5

gkd-Vue-Plus 与 gkd-web 的前端技术栈几乎完全一致，差异小到可以忽略不计。我的 12 个页面、119KB 的 Pinia store、路由配置、布局组件——几乎可以原封不动地搬进去。

而 zcy-web？Element Plus 1.0 beta 到 2.13 之间隔着的是整整两年的 API 演进。表单验证写法变了，表格插槽语法变了，弹窗属性变了，菜单组件重构了。把 gkd-web 的页面放进 zcy-web，不是”适配”，是”翻译”，而且是跨语系的翻译。

4.2 AI代理的”认知偏差”

更深层的问题是：AI代理在哪种技术栈上更不容易犯错？

我测试过，让 Kimi Agent 写一段 Element Plus 的表单代码，它默认输出的是 2.x 的语法。因为训练数据里，Element Plus 2.x 的项目占绝对主流。如果我强行让它在 zcy 的 beta 版上开发，它会不断生成 el-form 的 :rules 新语法，然后我在 beta 版上跑报错，再让 AI 改回去——这种循环是致命的。

AI 代理在现代化的、主流的技术栈上，理解力和生成准确率都更高。 zcy 的前端技术栈不仅老，而且是”非主流的老”，AI 很容易”踩空”。

4.3 时间成本的真实对比

我的项目周期很紧。两种方案的时间账：

方案前端工作量后端工作量总估算
gkd-Vue-Plus页面直接迁入（1-2天）在 ruoyi-biz 中开发采购流程（中等）较短
zcy-blank-framework前端几乎重写（2-3周）已有采购业务可复用（较少）较长

zcy 确实后端业务积累多，但前端的重写成本完全抵消了这个优势，甚至超额透支。

4.4 后勤维护的长期视角

我还要考虑系统上线后的维护。gkd-Vue-Plus 是一个活跃的开源项目，Gitee 上 1700+ Star，有完整的文档、视频教程、演示系统、社区支持。而 zcy-blank-framework 是一个内部/商业框架，技术栈停留在 2021 年，Element Plus beta 已经是一个官方不再维护的技术死胡同。

选 zcy，意味着我未来每一次想升级依赖、修安全漏洞、加新功能，都要在一条没有出口的老路上挣扎。

五、为什么两次分析的结论会打架？

我第一次问的时候，得到的建议是”选 zcy，因为采购业务积累可复用”。第二次深入分析后，我的结论是”选 gkd-Vue-Plus，因为技术栈匹配+AI友好+长期可维护”。

这两种结论的差异，本质上是对”更容易”的定义不同：

  • “选 zcy”的分析：站在”后端业务逻辑开发成本”的角度。采购流程复杂，状态机、审批流、支付对接——这些从零写的成本极高。zcy 有现成的，复用就是省钱。
  • “选 gkd-Vue-Plus”的分析：站在”AI代理开发+前端资产保留+项目周期”的角度。前端重写的时间成本、AI 在老旧技术栈上的犯错率、维护期的技术债务——这些隐性成本更高。

没有绝对的对错，只有适合不适合我的约束条件。

而我的约束条件是：时间紧、不会写代码、靠 AI 代理开发、要长期维护。这些条件同时指向 gkd-Vue-Plus。

六、我的最终决策：混合策略

最终方案不是二选一，而是**“取两家之长”**：

底座：gkd-Vue-Plus

  • 前端直接迁入 gkd-web 的 12 个页面，技术栈零摩擦
  • 复用 RuoYi-Vue-Plus 豪华的基础设施（权限、工作流、代码生成、文件存储、定时任务）
  • 享受活跃社区的文档和升级支持

业务模型来源：zcy-blank-framework

  • 不放弃 zcy 的采购业务积累
  • 让 AI 代理阅读 zcy-admin 的采购常量（Cglx.java、CgjgStatus.java、PurchaseProgress.java）
  • 让 AI 代理分析 zcy-web 的采购组件和流程页面，提取业务规则
  • 在 gkd-Vue-Plus 的 ruoyi-biz 模块中，按照提取的模型重新实现采购后端

这就像：我用现代化的建筑材料和施工队（gkd-Vue-Plus + AI代理），但拿着老房子的设计图纸（zcy 的业务模型）来盖新房。

七、执行路线图

Step 1: 保留前端资产
├── 将 gkd-web/src/views/、stores/、router/、layouts/ 迁入 gkd-Vue-Plus
└── 复用 Element Plus 2.x 组件，零 API 迁移成本

Step 2: AI 提取业务模型
├── 读取 zcy-admin: Cglx.java、CgjgStatus.java、PurchaseProgress.java
├── 解析 zcy-web: 采购组件逻辑、审批流程页面、状态转换规则
└── 输出: 采购领域模型文档（状态机、实体关系、流程节点）

Step 3: 后端落地
├── 复用 RuoYi-Vue-Plus: 用户/角色/部门/字典/菜单/日志/文件管理
├── 使用 WarmFlow: 实现采购审批流
├── 代码生成器: 快速生成基础 CRUD
└── 手动补充: 采购流程特有的业务逻辑（报价汇总、结算规则等）

Step 4: 接口对接
├── 替换 gkd-web 中的 mock 数据为真实 API 调用
├── 复用 plus-ui 的请求拦截、错误处理、权限控制
└── 联调测试

八、反思：AI 时代，技术选型的逻辑变了

这次选型让我意识到一个更深层的趋势：当开发者从”亲手写代码”变成”指挥 AI 写代码”，技术选型的权重会发生迁移。

在传统开发模式下，“团队熟悉度”和”业务积累”的权重极高——因为人学习新技术有成本，复用旧代码能省脑力。

但在 AI 代理模式下：

  • “团队熟悉度”被削弱：AI 不需要”熟悉”，它需要的是清晰、标准化、文档完善的输入。一个活跃的开源项目（gkd-Vue-Plus）比一套内部老框架（zcy）更容易被 AI 理解和生成。
  • “业务积累”的形式变了：业务积累不再是”必须沿用旧代码”，而是”可以被 AI 读取、理解、转译为新代码的知识”。zcy 的采购模型是知识，不是枷锁。
  • “技术栈现代性”权重上升：AI 在主流技术栈上的准确率显著高于小众/老旧技术栈。选一个 AI “练得多”的框架，等于选一个更靠谱的”开发队友”。

这或许是 AI 时代技术选型的一条新原则：优先选择 AI 训练数据中”密度高”的技术栈，其次考虑业务复用，最后才考虑人的熟悉度。

九、写在最后

这个项目还在推进中。我已经把 gkd-web 的页面成功迁入了 gkd-Vue-Plus，AI 代理正在阅读 zcy-blank-framework 的采购常量文件。

回头想想，如果我没有把”AI代理开发”这个前提放进分析，我很可能真的会选 zcy——因为”采购业务积累可复用”听起来太诱人了。但诱惑不等于正确，尤其在时间紧、资源少、要靠AI扛大头的情况下。

框架选型没有银弹，只有适合你当前约束条件的局部最优解。

希望这篇记录能给同样站在十字路口的你一点参考。

2026年8月 · 某高校采购管理系统项目笔记

同一主题的其他复盘

觉得有用？分享给需要的朋友

本文首发于 荣哥AI实战手记，原创内容，转载请注明出处：https://blog.cyuan.work/blog/2026-08-27-framework-selection-struggle/

聊得来的话，交个朋友

这篇文章源自我在一线的真实实践。同行朋友想交流方案细节、聊技术落地，欢迎加我微信 yangxr114（备注「博客」，好认）

也欢迎关注我的视频号「荣哥的AI项目实战」、公众号「胡子杨的AI炼丹炉」，日常分享 AI 项目落地的实战思考。

微信二维码 扫码加好友
← 返回首页