
如题。 我目前有两个方案构想: 方案 1:是从 0 起步,全部用 ai 生成一个包含前后端的 CRUD 脚手架 方案 2:找出以前的低代码 CRUD 平台,在其基础之上,让 ai 遵循其开发风格的前提下,进行业务代码开发
方案 1 的好处是,没有框架限制,自由度大,ai 可以不用操心上下文,自由发挥。但是缺点是前期还得把脚手架的基础功能补上,非常耗 token 。还得验证 ai 开发的基础功能,如登录、权限控制、菜单管理等等是否正确。
方案 2 的好处是,前期非常省力,基础功能都具备。缺点是,框架限制太死,开发业务代码时,得时刻让 ai 知道框架的开发规则,别写出屎山代码。特别是针对脚手架自带的前端页面,如果想换套 UI 界面,改动面也非常大。
一时不知道如何权衡,想请教 V 友们,有哪些比较好的推荐实践方式
1 xiaomushen 2 天前 先让 AI 扫一遍基座代码(推荐用 Opus4.6 扫),来回 review 提炼完美规则。 把规则做成项目 Skill 就这样,后续不管是国际模还是国内模,不管是 CC 还是 Trae ,都挺规矩的 |
2 fennu2333 2 天前 用方法 2 让 ai 根据项目自己改一个方便复用的版本+全套文档出来 |
3 Edward4074 2 天前 1 我正在干,rust runtime + ts business layer |
4 EastLord 2 天前 jhipster |
5 lujiaosama 2 天前 看你的项目规模。如果就是搞个 RABC 的单体前后端脚手架其实还好。你要类似 BLADEX 这种大而全的商业代码框架,那要费老鼻子劲了,主要的成本在于实战测试,没经过生产验证的代码都是不可靠的。 现在已经有人实践了,抛弃 MVC ,改为 DDD 驱动开发,一切为了更好的 VIBE CODING 。老的模式适合多人分工协作,但不一定适合 AI 。 |
6 yjxjn 2 天前 说说我来重构的经验。 首先,你得落地详细设计文档,别小看这个,这是我目前我认为省 token 还不偏离最有效的过程,按照模块写清楚。我曾经生成了 1 个挺复杂的模块,4000 多行代码,详细设计文档大概 1200 多行。用的 Github Copilot Pro 的 Codex ,但是最终消耗了 7%额度,从那以后我只要 vibe coding ,我都会认真 review 和修改文档。省 token 有效捷径。 然后,你规定开发规约,开发规约发现 VC 中有问题就加限制修改。 最后,开始让跑就行了。 |
7 swaylq 2 天前 我会选 2 ,但只借登录、RBAC 、菜单、审计这些脏活,业务层自己重新切薄。别让 AI 从 0 造后台基建,token 烧得快,后面填坑更贵。 @yjxjn 说的先把设计文档和规约写死,收益最大。 |
8 prosgtsr 1 天前 2:为啥要在低代码平台之上继续开发?有什么意义吗? 我选择 3:直接在若依之类的项目上继续开发 |