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

7 月 21 日
 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

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

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

1. 有了 Agent 以后,CRUD 生成器还有价值吗,还是应该只保留项目结构和权限约束?
2. 后台框架最该固化的是 RBAC 、目录结构、测试验收,还是别的东西?
3. GoFrame 对一个后台脚手架来说,是加分项还是门槛?
3325 次点击
所在节点    Go 编程语言
17 条回复
ca2oh4
7 月 21 日
手脚架代码不需要消耗 token ,而且格式固定

ai 的话就不好说了
linauror
7 月 21 日
感觉脚手架还是必要的,相当于一个规范,AI 生成的难保一致性风格
jackOff
7 月 21 日
不完全建议,ai 出来以后基本上重点砍掉阅读性困难的注解,过度设计模式或者抽象类脚手架设计,可以极大地增强项目代码可维护性,ai 阅读理解起来也很快,哪怕月月换新人也能很快上手项目
amztianshi888
7 月 21 日
@ca2oh4 是的有同感,有了一定的设计思想规范 ai 可以按参考继续
amztianshi888
7 月 21 日
@linauror 是的。
amztianshi888
7 月 21 日
@jackOff 但是很多 vibe coding 不这么想
Ayanokouji
7 月 21 日
我也维护自己的脚手架,不过我更喜欢叫他 template ,来说说我的见解
1. 脚手架有必要,比如日志处理,error 处理,我觉得这两个对 golang 脚手架来说很重要,看起来这俩很简单,但是上线后的问题溯源,很考验这两样的设计功底
2. curd 生成,我不喜欢。我不反对生成器,我用的是 ent ,也有大量生成代码。但是生成的代码应该是不能修改的,所以我不喜 curd 生成器,写好 agents.md ,AI 还是遵循风格


这些仅代表我个人观点,golang 的技术栈每个人的习惯差距还是很大的
maichael
7 月 21 日
AI 跟已有工具的的替换原则是,能不让 AI 干的就别让 AI 干,如果没有带来能力的提高,为什么需要一个更慢、更不稳定、更贵的工具
lujiaosama
7 月 21 日
CURD 生成器还是必须的,天天靠 AI 自由发挥会搞出一堆微妙的差别还浪费 TOKEN 。但是很多脚手架的 CRUD 生成器是一坨,比如说需要自己建动态字典手动配字典。比如说会生成一堆没用的 CURD 方法而不是一开始就把不需要的屏蔽掉。我用 SKILL 驱动先生成 CURD 生成器需要的 SQL 资产和流程驱动文件,人工审核后导入和确认效果,手动生成到前后端。
TirionHo
7 月 21 日
正在用 goframe ,用的 hotgo 脚手架,我是使用 skill+AGENTS.md 进行约束,让 AI 按照规则写,感觉还行
hotgo 的代码生成器没用,让 AI 写就行了,还能帮你建表、写后台页面呢
siaronwang
7 月 21 日
不冲突啊,ai 在脚手架层上不更稳定?
GeminiPro
7 月 21 日
这不是互补吗?
Rever4433
7 月 21 日
脚手架是必须有的,不然总不能每次做系统都从 0 开始写一套 RBAC 吧。
lesismal
7 月 21 日
后台没必要脚手架了,你说的 AI 都能做很好。

BTW ,用 go 实现的类似 java spring 的框架,或者 go 实现的其他重度框架,goframe 也好、beego 也好,还有 go-zero 那些更重的 wrapper ,都没必要存在。

我不是现在才说它们不好,我是一直都说它们不好,个人一直反对这些其他语言框架的拥趸来用 go 搞这些违背 go 哲学的框架。

下面有其他人写的文章,挺好的,建议读读。

别再往 Go 里塞 Java 了:拆解 spf13 的 Idiomatic Go 信仰:
https://zhuanlan.zhihu.com/p/2059895250592731300
netabare
7 月 21 日
我什么时候看到把 Java 塞进别的语言(包括但不限于 JS/TS 、Go 、Rust 、Haskell……)能不笑出来(
Leon6868
7 月 22 日
脚手架怎么不算是 herness
realism
7 月 22 日
说到约束层,我觉得什么契约都约束不了 AI 。全看实际的项目运行情况。当有一个具体的需求具备重大商业价值、时间紧迫时,以现在 AI 的能力,可以快速突破约束给你搞一套实现出来。现在的老板和领导们可太馋这个了。比不听话的程序员好用太多。

有一次突破就有二次突破,就有第三次,再到后面架构就腐化了,但 AI 总是能搞定,所以一切都还只是处于一个危险的边缘而已。老板们是能接受的。

所以我感觉,脚手架挺有用的,但会随时间腐化,会被替换实现。它可能有利于项目快速启动和早期维护,但长期会被 AI 破坏掉。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1228795

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX