昨天 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 注册入驻，完成开发者资质认证，创建技能类型的业务，在测试环境里调通后提交审核。技能不用对接业务系统，也不用写代码，把你脑子里的流程写成规范文档就行。
