如题。 我目前有两个方案构想： 方案 1：是从 0 起步，全部用 ai 生成一个包含前后端的 CRUD 脚手架 方案 2：找出以前的低代码 CRUD 平台，在其基础之上，让 ai 遵循其开发风格的前提下，进行业务代码开发
方案 1 的好处是，没有框架限制，自由度大，ai 可以不用操心上下文，自由发挥。但是缺点是前期还得把脚手架的基础功能补上，非常耗 token 。还得验证 ai 开发的基础功能，如登录、权限控制、菜单管理等等是否正确。
方案 2 的好处是，前期非常省力，基础功能都具备。缺点是，框架限制太死，开发业务代码时，得时刻让 ai 知道框架的开发规则，别写出屎山代码。特别是针对脚手架自带的前端页面，如果想换套 UI 界面，改动面也非常大。
一时不知道如何权衡，想请教 V 友们，有哪些比较好的推荐实践方式
 |
1 xiaomushen 13 小时 10 分钟前先让 AI 扫一遍基座代码（推荐用 Opus4.6 扫），来回 review 提炼完美规则。 就这样，后续不管是国际模还是国内模，不管是 CC 还是 Trae ，都挺规矩的 |
 |
2 fennu2333 13 小时 5 分钟前用方法 2 让 ai 根据项目自己改一个方便复用的版本+全套文档出来 |
 |
3 Edward4074 13 小时 2 分钟前1 我正在干，rust runtime + ts business layer |
 |
5 lujiaosama 12 小时 52 分钟前看你的项目规模。如果就是搞个 RABC 的单体前后端脚手架其实还好。你要类似 BLADEX 这种大而全的商业代码框架，那要费老鼻子劲了，主要的成本在于实战测试，没经过生产验证的代码都是不可靠的。 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。