WorkBuddy 开放首日,半年前写的 Git 技能过审了
WorkBuddy 开放平台上线首日,作者提交的 git-skills 技能通过审核。该技能已持续自用半年,覆盖分支命名、Conventional Commits、PR 自检、冲突恢复等全流程,不依赖代码开发,仅以规范文档驱动。平台支持技能、专家、连接器等五类业务,当前生态含10万+资产、3000万+安装量。
昨天 open.workbuddy.cn 上线,WorkBuddy 的开放平台。第三方开发者可以把自己的经验做成产品,交给生态里的用户去装。当时我正在改代码,顺手把压了半年的一个 skill 提交了,今天早上过审。

这个 skill 叫 git-skills,管的是你和 Git 打交道的每一道工序。
它是半年前写的。这半年我几乎每天提交代码,没换过。
一个 skill 值不值钱,看它被用了多久
技能类东西最容易死在追热点上。今天出一个新框架写一篇,明天出来一个新工具再写一篇,程序员圈子尤其爱干这个。
我自己的检验办法很笨:放半年,再回头看它还能不能用。
写 git-skills 不是因为想做产品,是受不了自己。commit message 每次都是 "fix bug",分支名随手敲个 test1,碰到冲突就手忙脚乱去搜命令。每件事都不大,架不住天天发生,一年下来几百次。
这半年它一直在我日常里跑,分支命名、提交正文、PR 检查、冲突恢复都归它管。半年前定的规则,今天一条都没改过。
倒不是我有什么先见之明,是 Git 这东西本来就没怎么变。挑变化慢的东西下手,保质期自然长。
它具体管什么
分支名按 type/ticket-描述 走,feature、bugfix、hotfix、refactor、docs、test、chore 各有各的位置。切分支前先查有没有未提交的改动,有就提醒你 commit,或者 git stash -u 连 untracked 一起收起来。
提交信息走 Conventional Commits。subject 祈使句,50 字符以内,结尾不带句号。正文对非平凡改动是强制的,而且要分段:第一段讲改了什么、为什么这么改,第二段讲实现取舍、性能影响、破坏性变更,footer 挂 issue 引用。
同样是修 bug,它给出的东西是这样:
fix(database): resolve connection pool exhaustion under high load
连接未能在查询超时后正确释放,导致持续高负载下连接池耗尽,
最终引发应用不可用。
根因在于释放逻辑被放在仅在查询成功时才执行的 finally 块。
查询超时时异常处理器提前返回,连接没有被归还池中。
调整内容:
- 将 connection.release() 移至无条件执行的 finally 块
- 归还前增加连接健康检查
- 在池层面设置 30 秒超时,避免挂起
压测结果显示连接池占用率从 100% 降至约 40%。
Fixes #567跟 "fix bug" 放一起看,区别不在格式好不好看。三个月后你还得回头翻这个提交,那时候正文里的根因分析能省你半小时。
有条规则我觉得挺妙:它会主动用 sed 把提交信息里的 Co-Authored-By 和各种 AI 署名挑出来删掉,commit 完再 git log -1 验一遍。
一个由 AI 执行的技能,明确要求提交记录里不许留 AI 痕迹。矛盾归矛盾,道理也简单:提交历史是给人看的,团队要的是责任到人,不是工具声明。
PR 环节生成描述模板,合并前跑一遍自检:有没有密钥泄露,有没有超过 10MB 的大文件,有没有残留的调试输出,提交粒度是不是原子的。冲突时先定位文件、给标记上下文、分步带着你解,reset、revert、reflog 那套恢复手段也在里面。
另外支持项目级配置 .gitskills.json,可以自定义 type 列表、强制 requireBody、指定主分支名。
这个平台是什么,为什么是现在
官方的说法是「面向 WorkBuddy 生态业务的一站式工作台」。开发者入驻并通过资质审核后,能做五类业务:技能、专家、专家团、连接器、外部应用接入。
流程固定八步:注册入驻,完成开发者或企业资质认证,创建要做的业务类型,完善基础信息和能力配置,测试环境里调试验证,提交平台审核,审核通过发布上线,之后持续看运行数据做版本维护。
官方原话是,开发者可以把行业 know how、业务系统和服务能力快速转化成生态里的标准化产品,在降低开发与运营成本的同时,获得统一的发布渠道和用户触达能力。
说白了,分发和用户这两件事不用你自己跑,把东西做出来交上去就行。
首页挂着三个数字:10 万+ 生态资产,3000 万+ 累计安装,100+ 家共创伙伴。

平均下来一个资产对应 300 次安装。这个除法很粗,不过供需两端的比例大致就是这样:装的人已经很多了,做的人还不够。
五类业务里技能最轻,不用对接业务系统,也不用写一行代码,把你脑子里的流程写成规范文档就能提交。我做的正是这一类。
生态刚开,位置还空着。等同类技能堆到几十个,再想被人看见就得另想办法了。
这事每个平台都发生过一遍。微信公众号、App Store、小红书,早期进去的人和后来进去的人,拿到的从来不是同一份回报。
怎么开始
平台那套流程八步,我按自己的经验压成三步。
第一,先想清楚你被什么反复折磨过。重点不是你会什么,是你烦什么。会的东西写进简历,烦的东西才能做成工具。
第二,把它写成规范。skill 不需要写代码,就是把脑子里的流程整理成一份 AI 能照着执行的文档。
第三,提交审核。
我自己的路径是从自用开始的,半年前写给自己用,昨天想起来可以交出去。从提交到过审不到一天,比我预想的快。
最后
AI 能不能写代码,这个话题已经聊烂了。
我更在意另一件事:你攒了多年的工程习惯,现在能被打包成一个陌生人可以安装的东西。以前它最多影响同组那几个人。
半年前的 Git 习惯试了一次水,过了。
装来用:WorkBuddy 里搜索「Git 技能助手」,装上直接用。别扭的地方来找我。

自己做一个:打开 open.workbuddy.cn 注册入驻,完成开发者资质认证,创建技能类型的业务,在测试环境里调通后提交审核。技能不用对接业务系统,也不用写代码,把你脑子里的流程写成规范文档就行。
JOTO 企业落地观察
- 对企业部署意味着:当 Git 这类底层基础设施长期稳定时,基于其操作规范封装的智能体可形成低维护、高复用的工程资产;企业无需等待大模型能力升级,即可将资深工程师的隐性经验沉淀为可安装、可审计的标准化技能。
- 这类系统的取舍在于:技能形态绕开了传统 API 对接与系统集成,但要求将经验转化为机器可解析的结构化规范;企业知识工程团队需评估自身流程的稳定性与抽象程度,而非单纯追求技术先进性。
- 对 RAG 知识工程而言,git-skills 的实践表明:高质量知识源未必来自海量文档,而可能源于经年累月验证的极简规则集;RAG 系统若仅聚焦于‘喂数据’,反而可能稀释这类已被时间验证的操作确定性。
- AI 安全治理需重新审视‘责任归属’边界:该技能主动清除 AI 署名并强调人工可读的提交正文,说明在协作型智能体场景中,可追溯性与权责清晰度比自动化程度更关键;企业不应默认将 AI 行为等同于开发者行为。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们


