The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
amztianshi888

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

  •  
  •   amztianshi888 · 11h 27m ago · 1487 views
    我最近有点纠结一件事:现在 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 对一个后台脚手架来说,是加分项还是门槛?
    15 replies    2026-07-21 18:18:34 +08:00
    ca2oh4
        1
    ca2oh4  
       11h 18m ago
    手脚架代码不需要消耗 token ,而且格式固定

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


    这些仅代表我个人观点,golang 的技术栈每个人的习惯差距还是很大的
    maichael
        8
    maichael  
       9h 55m ago
    AI 跟已有工具的的替换原则是,能不让 AI 干的就别让 AI 干,如果没有带来能力的提高,为什么需要一个更慢、更不稳定、更贵的工具
    lujiaosama
        9
    lujiaosama  
       9h 8m ago
    CURD 生成器还是必须的,天天靠 AI 自由发挥会搞出一堆微妙的差别还浪费 TOKEN 。但是很多脚手架的 CRUD 生成器是一坨,比如说需要自己建动态字典手动配字典。比如说会生成一堆没用的 CURD 方法而不是一开始就把不需要的屏蔽掉。我用 SKILL 驱动先生成 CURD 生成器需要的 SQL 资产和流程驱动文件,人工审核后导入和确认效果,手动生成到前后端。
    TirionHo
        10
    TirionHo  
       7h 55m ago
    正在用 goframe ,用的 hotgo 脚手架,我是使用 skill+AGENTS.md 进行约束,让 AI 按照规则写,感觉还行
    hotgo 的代码生成器没用,让 AI 写就行了,还能帮你建表、写后台页面呢
    siaronwang
        11
    siaronwang  
       7h 4m ago
    不冲突啊,ai 在脚手架层上不更稳定?
    GeminiPro
        12
    GeminiPro  
       7h 1m ago
    这不是互补吗?
    Rever4433
        13
    Rever4433  
       6h 49m ago
    脚手架是必须有的,不然总不能每次做系统都从 0 开始写一套 RBAC 吧。
    lesismal
        14
    lesismal  
       6h 47m ago
    后台没必要脚手架了,你说的 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
        15
    netabare  
       6h 37m ago
    我什么时候看到把 Java 塞进别的语言(包括但不限于 JS/TS 、Go 、Rust 、Haskell……)能不笑出来(
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1471 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 62ms · UTC 16:56 · PVG 00:56 · LAX 09:56 · JFK 12:56
    ♥ Do have faith in what you're doing.