有了 Agent,后台脚手架是该退场,还是变成约束层?

发布于

amztianshi888: 我最近有点纠结一件事:现在 Claude Code、Codex、Cursor 这类工具已经能很快把 CRUD 页面和接口搓出来了,那 Go 后台脚手架还有没有必要继续做?

先说明身份,XYGo Admin 是我自己在维护的一个 GoFrame + Vue3 后台项目,不是第三方推荐。上一次我在分享创造发过一次项目介绍,这次不想再重复功能清单,想单独聊聊“生成器和 Agent 的边界”。

我的感觉是,第一版页面和接口确实越来越不值钱。让 Agent 按表结构生成列表、表单、接口、路由,速度很快。但后台系统真正麻烦的地方通常不在这里,而在后面的约束:

比如菜单隐藏了,接口权限还要不要拦?按钮权限和 API 权限怎么同步?字段改名后,前端 store、后端 DTO、权限点、菜单配置是不是一起变?生成器第二次跑的时候,是覆盖、合并,还是提示人工处理?这些地方如果全靠 Agent 临场发挥,短期看很爽,后面容易变成一堆“看起来能跑”的代码。

我现在更倾向于把脚手架做成约束层,而不是替代 AI 写代码。XYGo 里目前有几块是围绕这个方向做的:GoFrame v2 后端、Vue3 前端、RBAC 权限、CRUD 代码生成器,还有一些给 Agent 用的 AI Skills。最近也在处理几个具体边界:v1.4.7 把前端 Pinia 双树合并掉,避免状态目录重复; GitHub Issue #8 里有人问多租户,开源版目前还没开放,这块确实是一个很现实的取舍。

相关代码放在这里,主要方便对照上面说的生成器和权限边界:[https://github.com/z312193608/xygo-admin](https://github.com/z312193608/xygo-admin)

不足也先说清楚:如果你只想做一个很轻的 Go API,这种后台框架会显得重;如果团队不接受 GoFrame,也会有采用成本;多租户现在开源版还没有放出来;文档和交互也还有不少地方需要磨。

想听听 V 友怎么看几个问题:

1. 有了 Agent 以后,CRUD 生成器还有价值吗,还是应该只保留项目结构和权限约束?
2. 后台框架最该固化的是 RBAC、目录结构、测试验收,还是别的东西?
3. GoFrame 对一个后台脚手架来说,是加分项还是门槛?

---

原文链接:[点击查看](https://www.v2ex.com/t/1228795)

评论(12)

我自己也维护了一套 template,说点个人看法。1. 脚手架绝对有必要,像日志和错误处理的设计直接决定了线上排查问题的难易程度,这很考验功底。2. 个人不喜欢 CRUD 生成器,因为生成的代码往往不该被二次修改。我还是倾向于写好 agents.md 让 AI 遵守规范。当然,Go 圈子每个人习惯不同,仅代表个人意见。

· 0 个赞

原则就是:能不用 AI 干的活就尽量别让 AI 插手。如果用 AI 不能明显提高效率,那我为啥要抛弃现有工具,去用一个又慢、不稳定还死贵的玩意儿呢?

· 0 个赞

CRUD 生成器还是少不了的,天天指望 AI 临场发挥肯定会出现一堆莫名其妙的 Bug,而且贼费 Token。不过现在很多脚手架自带的生成器挺鸡肋的。我现在是自己搞个 Skill 驱动,先让它生成 SQL 和流程文件,人工 review 完再导入生成前后端代码。

· 0 个赞

目前在用 goframe+hotgo。我是直接写好 AGENTS.md 去约束 AI,让它按规矩写代码,体验还行。hotgo 自带的代码生成器我直接弃用了,反正让 AI 搞定建表和写前端页面也很快。

· 0 个赞

脚手架和 AI 肯定不冲突啊,有了脚手架打底做规范,AI 在这上面写代码不是更稳吗?

· 0 个赞

其实这俩完全不冲突吧?脚手架和 AI 分明是互补的关系。

· 0 个赞

脚手架肯定是刚需啊,不然总不能每次新开个系统,都从零开始手搓一套 RBAC 权限吧?那太折磨了。

· 0 个赞

讲道理,后台这块没必要专门弄脚手架了,AI 直接写就行了。另外顺便吐槽一句,现在很多用 Go 写的仿 Java Spring 框架(像 goframe、go-zero 这些)真没必要存在,严重违背了 Go 语言本身的哲学。强推一下别人写的这篇《别再往 Go 里塞 Java 了》,建议大家都去读读。

· 0 个赞

回复

看到有人想把 Java 那一套硬塞进 Go 或者 Rust、JS 里,我就忍不住想笑。

· 0 个赞

脚手架直接生成多省事,还不花 token,而且格式写死了肯定没问题。换用 AI 生成的话,那稳定性就不好说了,指不定给你整出什么幺蛾子。

· 0 个赞

感觉脚手架还是得保留的,毕竟它可以作为一个统一的标准和规范。你纯靠 AI 临场发挥写代码,时间长了很难保证全局的一致性和代码风格不飘。

· 0 个赞

个人觉得有了 AI 以后,倒是给脚手架“减负”的好机会。建议狠心砍掉那些晦涩难懂的注解、过度抽象的设计模式。代码越扁平越好,既能提升项目的可维护性,AI 理解起来也快。这样一来,哪怕是公司里月月换新人,接手项目也会快得多。

· 0 个赞