/gs 你好,世界！
在 Go-Spring 的日常里,gs 是一个命令行工具。它像是围绕项目干活的一组小家伙:gs init 起一个新项目,gs-http-gen 从 IDL 里吐出 HTTP 服务端和客户端代码,gs-mock 帮忙搭点测试壳子。要跑起来一个符合 Go-Spring 约定的服务,这些命令基本够用了。
从工具的角度看,gs 解决的是"项目冷启动"这一段的效率问题:目录怎么摆放、代码怎么生成、样板代码怎么少写点。用完之后它就退到后台去了,后面的日子还是团队自己过。
但现在 AI 时代来了,gs 也需要一次升级,才跟得上新的用法。升级之后,它就成了 /gs。
多出来的斜杠是 AI 会话里的调用符号。/gs 不是新的 CLI,而是一个面向 Go-Spring 项目的 AI Skill:它会调用底层的 gs 工具,也会读项目上下文、理解 Go-Spring 的约定、跑编译和测试、写文档、整理变更。可以先粗略地这样区分:gs 是手里的锤子,/gs 是那个知道什么时候该抡锤子、抡完还要收尾的人。
顺着这条线,我们来看看它到底能把研发过程带到哪里。
从"起项目"到"陪项目"
传统脚手架站在项目的第 0 天。目录摆好、依赖装上、示例跑通,它的活儿就干完了,之后项目怎么走,和它基本没什么关系了。
但问题是,真实的工程从来不是一次性的。一个 Go-Spring 项目在跑起来之后,还要经历需求变更、接口新增、配置调整、组件接入、测试补齐、编译踩坑、线上排障、文档同步——团队的时间大部分都花在这些"之后"里。项目最后走成什么样,取决于每一次改动能不能守住同一套工程标准,而不是最开始那一下把架子搭得多漂亮。
/gs 想接管的,就是这段"之后":
- 需求阶段:把自然语言里的模糊描述,拆成能落地的工程任务
- 设计阶段:判断模块边界、依赖关系,以及 Go-Spring 组件应该怎么摆
- 编码阶段:顺着项目已有的风格改,而不是丢一段孤立片段进来
- 测试阶段:顺手把单测、集成测试或者示例补齐
- 编译阶段:知道该进哪个 module,
go test、go build都能跑对地方 - 交付阶段:整理变更说明、风险点和验证结论
- 沉淀阶段:把踩过的坑和约定回写到文档、Skill 里
同一个入口把这些串起来之后,/gs 就不再只是"帮我写代码"的角色,更像是"帮我按 Go-Spring 的方式把这件事做完"。
一个装在研发流程里的中间件
熟悉 Go-Spring 的人对"中间件"这个词不会陌生:框架允许你把日志、鉴权、追踪这些横切逻辑挂到请求或者应用生命周期上。/gs 在研发流程里做的事,跟这个思路挺像。
它不替人拿主意,但会在几个关键节点插一脚,把该走的动作走一遍:
- 需求进来时,把模糊的说法追问清楚,补上目标、边界和验收标准
- 方案成型时,把偏离项目结构的实现拉回到 Go-Spring 的组件模型里
- 改代码时,守住已有的目录、命名、错误处理和配置约定
- 跑测试时,把"改完就交"的习惯换成"改完先验"
- 编译报错时,不把红字原样丢回来,而是给出定位和一条能走的修法
- 提交时,变更摘要、验证情况、遗留风险一并补齐
绕这一圈的意思是:/gs 不是一个更聪明的代码生成器,更像是给流程加了几个卡点,让规范从"文档里写着"变成"每次都会走一遍"。
AI 时代的工程化,到底指什么
聊到 AI 时代,很多人第一反应是让模型放开手脚生成。但对做工程的团队来说,更值钱的方向反倒是相反的:给模型划出一条清楚的边界,让它在里面干活。
Go-Spring 项目的边界,大致就是这么些常识:
- 仓库根目录不一定是 Go module,构建要下到具体子项目里
- 配置、日志、IoC、生命周期由框架统一托管
- 接组件优先复用现成的 Starter
- 错误往上抛的时候要带够上下文
- 依赖注入在启动期完成,不引入运行期动态注入
- 同名同类型的 Bean 不靠隐式覆盖,而是通过条件互斥显式选一个
- 测试、示例、文档跟着代码一起走,不留到事后再补
这些约定如果只装在人脑里,项目一大就会走形。/gs 要做的,就是把它们翻译成 AI 能读到、能执行的上下文。
拿几个日常场景对照一下会更直白:
- 用户说"加一个接口",不该只吐一个 handler——得看这个接口属于哪个模块、要不要动 IDL、要不要加配置、依赖怎么注入、错误怎么包、测试怎么覆盖、文档要不要跟着改
- 用户说"编译一下",不该默认根目录就有
go.mod,Go-Spring 的仓库通常是多个子模块拼起来的,得挑对目录再跑 - 用户说"接一下 Redis",也不该从头写一套初始化——先看有没有现成的 Starter,能复用就复用,顺手把配置绑定、Bean 注册、生命周期都接进去
所谓 AI 时代的工程化,大概就是这个样子:上下文驱动、按规范执行、每次改动都能收敛到一个可验证的结果上。
/gs 怎么落地
大致分三层。
一、项目上下文要显式
AI 想稳定参与研发,前提是能读懂这个项目。
Go-Spring 项目可以通过 AGENTS.md、编码规范、目录约定、示例项目和文档,把关键信息摊在明面上:
- 项目怎么组织
- 哪些目录是独立的 Go module
- 常用的构建、测试、运行命令是什么
- 错误和日志有什么要求
- 加新功能应该照着哪些示例抄
- 哪些改动必须同步文档
写得越清楚,/gs 表现得越稳。团队不用每次都重讲一遍项目规则,AI 也不必靠猜。
二、常见动作要有流程
第二步是把高频的研发动作固化成流程。
"新增 HTTP 接口"听起来只是写几行代码,拆开看其实是一串有先后的步骤:
- 把接口语义、入参出参先说清楚
- 看要不要动 IDL、跑一次代码生成
- 找到对应的 module 和已有分层
- 改 handler、service、配置、注册
- 补测试或者示例
- 跑 gofmt、测试、编译
- 汇总一份变更和验证结论
/gs 可以把这套顺序默认跑通。用户负责说清楚目标,AI 把中间的步骤走完,遇到需要抉择的地方再说明选了什么、为什么。
三、能力尽量交给工具
第三步是让 /gs 多调工具,少往提示词里塞逻辑。
Go-Spring 项目手边就有一批可用的工具:
gs init:按约定拉一个项目骨架gs-http-gen:从 IDL 生成 HTTP 代码gs-mock:生成测试辅助代码go test:验证模块行为go build:验证能不能构建出产物gofmt:统一 Go 代码格式- 文档构建工具:确认站点能正常生成
AI Skill 的价值,在于什么时候调哪个工具,以及能读懂工具输出背后的工程含义。它不是给 CLI 套一层自然语言外壳,而是把 CLI 拼进完整的研发流程里。
一条 /gs 请求会经历什么
理想情况下,用户的输入可以简单到这种程度:
/gs 给用户服务加一个查询用户详情的 HTTP 接口,按 user_id 查,顺便把测试和文档补上。/gs 要做的,就不止是"写个接口"那点事:
- 看清项目结构,定位到用户服务所在的 module
- 判断已有的 IDL、路由、handler、service、repository 都是怎么分的
- 生成或修改代码,命名和分层跟着现有风格走
- 用 Go-Spring 的 IoC、配置、生命周期来组织依赖
- 按项目习惯包错误,保留定位信息
- 补测试,覆盖正常路径和几条关键失败路径
- 跑 gofmt、go test,必要时 go build
- 更新文档或示例,把接口行为说清楚
- 最后给一份变更摘要、验证命令和遗留风险
背后是一种不太一样的干活姿势:开发不用再挨个工具去切,而是把目标交给 /gs,让它拆成一串标准动作往下推。
对 Go-Spring 意味着什么
Go-Spring 一直在做的事,是应用侧的工程化——配置、依赖注入、日志、生命周期、组件集成,凑在一起是为了让 Go 服务在保持简洁的同时,底盘更稳一点。
/gs 则把这种工程化往前挪了一步,搬到了研发过程本身。
框架管的是应用运行时怎么组织,/gs 管的是开发过程怎么组织。一个让服务的启动、装配、退出更可控,一个让需求、代码、测试、交付更可控。两件事凑在一起,Go-Spring 的工程化就不只体现在代码里,也会体现在日常的干活方式里:
- 运行时有统一的生命周期
- 开发时有统一的入口
- 组件有标准的接入路径
- 需求有可复用的落地流程
- 代码有默认的验证动作
- 经验有稳定的沉淀去处
你好,世界之后
"你好,世界"通常是一门技术露面时的第一句话。
/gs 你好,世界! 想传达的不是一个最小示例,而是一个新的入口:从这句话开始,Go-Spring 项目的需求可以被理解,代码可以被改,测试可以被跑,编译可以被验证,文档可以被更新,踩过的坑可以被留下来。
gs 让项目更好起,/gs 让项目更好养。
AI 时代真正值得追求的,不是偶尔写出一段能跑的代码,而是让 AI 稳定地参与到一套可复用、可验证、可沉淀的研发流程里。对 Go-Spring 来说,/gs 就是这套流程的入口。