线上跑的是哪版代码？我做了个 Skill 治这个病
痛点：线上跑的到底是不是最新代码？
做后端开发的朋友对这个场景应该不陌生：
应用发布后出了问题，第一反应往往是——线上跑的逻辑，是不是我以为的那份代码？
于是开始确认：登容器翻文件，文件里没有任何版本信息；去发布系统查构建记录，翻半天流水线；拿构建时间跟 git log 对，对得人眼花。团队里问一圈，谁也说不准。
也试过土办法：在工程里放一个 version.txt，发版前手动写一下版本号。结果是——总忘、总漏；更烦的是，写完还得 commit 一次，git 提交日志里隔三差五就冒出一条”更新版本文件”，历史看着不清爽；而且手动写的号也没法证明它对应哪个 commit，等于没写。
后来想明白一件事：版本信息不该由人来写，应该由 git 来写。 每次 commit 的指纹（commit id、时间、分支）就是最天然的版本凭证，问题只在于怎么把它自动落到一个线上能看到的文件里。
顺着这个思路，前前后后迭代了三个版本：
- V1：用 git 钩子自动写版本文件
- V2：解决路径适配
- V3：把整套脚本沉淀成一个 AI Skill
回头看，每一版都是被实际使用中冒出来的问题逼着改的——也正是这个演进过程，比最终方案本身更值得聊。
V1：让 git 自己写版本文件
方案很直接：给仓库加一个 post-commit 钩子，每次提交后自动把 commit_id、commit_time、分支名写进工程里的一个版本文件。
从此发版后不用再猜——登容器 cat 一下版本文件，commit id 一比对，是不是最新代码一目了然。
另外配了一个手动脚本，随时可以往文件里刷一个时间戳——标记”这个时刻我确认过/构建过”，和 git 信息互补。
V2：路径不能写死
用起来之后，第一版暴露出一个幼稚的问题：版本文件路径写死了。换个工程结构（Java 的资源目录、Python 的 src 目录、有的工程还想自定义）就不适用。
于是把路径探测抽了出来：优先读工程里的配置，没配置就按工程特征自动嗅探，探测逻辑做成公共函数，谁要用谁引入。这一步之后，脚本才算”能带出门”。
V3：从”脚本”进化成”Skill”
脚本好用了，又冒出最后一个障碍：这套东西要在每个仓库装一遍，钩子、脚本、公共库好几个文件，手动复制既繁琐又容易漏。
这就是把它做成 AI skill 的原因。现在整个流程变成两句话：
- 说 “安装 autoversion” —— 自动把钩子和脚本装进当前仓库；
- 说 “标记版本” —— 自动执行打戳，刷新时间戳和 git 信息。
日常开发什么都不用做，git commit 时钩子自动更新版本文件。
安装器也处理了脏活：仓库里已经有别人的 post-commit 钩子时不覆盖，而是备份后把自己的逻辑追加进去；检测到旧版本的自己则直接升级。脚本公共逻辑收在一个函数库里，改一处处处生效。
效果
版本文件长这样：
1 | version:1.0.3 |
登容器看一眼文件，和 git 一比，心里就有底了。
写在最后
这个事本身不大，但它是个典型的”每天都疼一下，又一直懒得治“的问题。
做下来的体会是：重复的操作值得沉淀成资产。以前把脚本存网盘、写 README 教同事怎么装；现在脚本、安装逻辑、使用说明打包成一个 skill，一句话调用、一句话分发。
AI 编程工具最好的用法，可能不是替你写多少代码，而是把你解决过的问题变成”下次一句话就能复用的服务“。
微信端的朋友也可关注我的公众号
