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

amztianshi888 2026-07-21 13:28 1

我最近有点纠结一件事:现在 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 对一个后台脚手架来说,是加分项还是门槛?
最新回复 (16)
  • ca2oh4 07-21 13:38
    1
    手脚架代码不需要消耗 token ,而且格式固定

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


    这些仅代表我个人观点,golang 的技术栈每个人的习惯差距还是很大的
  • maichael 07-21 15:01
    8
    AI 跟已有工具的的替换原则是,能不让 AI 干的就别让 AI 干,如果没有带来能力的提高,为什么需要一个更慢、更不稳定、更贵的工具
  • lujiaosama 07-21 15:47
    9
    CURD 生成器还是必须的,天天靠 AI 自由发挥会搞出一堆微妙的差别还浪费 TOKEN 。但是很多脚手架的 CRUD 生成器是一坨,比如说需要自己建动态字典手动配字典。比如说会生成一堆没用的 CURD 方法而不是一开始就把不需要的屏蔽掉。我用 SKILL 驱动先生成 CURD 生成器需要的 SQL 资产和流程驱动文件,人工审核后导入和确认效果,手动生成到前后端。
  • TirionHo 07-21 17:00
    10
    正在用 goframe ,用的 hotgo 脚手架,我是使用 skill+AGENTS.md 进行约束,让 AI 按照规则写,感觉还行
    hotgo 的代码生成器没用,让 AI 写就行了,还能帮你建表、写后台页面呢
  • siaronwang 07-21 17:51
    11
    不冲突啊,ai 在脚手架层上不更稳定?
  • GeminiPro 07-21 17:55
    12
    这不是互补吗?
  • Rever4433 07-21 18:07
    13
    脚手架是必须有的,不然总不能每次做系统都从 0 开始写一套 RBAC 吧。
  • lesismal 07-21 18:08
    14
    后台没必要脚手架了,你说的 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 07-21 18:18
    15
    我什么时候看到把 Java 塞进别的语言(包括但不限于 JS/TS 、Go 、Rust 、Haskell……)能不笑出来(
  • Leon6868 07-22 09:32
    16
    脚手架怎么不算是 herness
* 帖子来源V2EX
返回