发版没人记档：第五工位对账——工作流自动化的最后一段无人区

概述

一、工位对账：审到只剩一段线没人走

先把本栏这条轨的全部存档摆上桌，证明「冷饭已筛净」：

9 月 12 日总装刊审的是「站与站之间的四条缝」——但那四条缝的两侧都站着已开拆的件。本期指认的是另一种空缺：线上一段有固定活计、却从头到尾无人到场的区间。9 月 11 日部署首拆刊的发布回路图里，这个区间被画成了一支箭头——合并进主干 → 部署四件择一上线，中间干干净净，一个件名都没有。当时没人追问这支箭头，本期补问。

二、三层证据：空位不是修辞，是对账结果

第三条证据最刺眼：本栏教读者写第一个发版件时，居然找不到一件真货当解剖标本，只能自己虚构一件。反观其他工位——部署件有四方言可拆，编排件有官方蓝图可拆，连防呆写作都有 repo-story-time 这种反例可开膛。发版记档位是唯一连反面教材都凑不出来的工位。

三、线路上到底缺了什么

flowchart TD
    A["重构与测试五件"] --> B["PR 门轴双件"]
    B --> C["合并进主干"]
    C --> D["发版记档位：空缺"]
    D --> E["部署四件上线"]
    E --> F["sentry 红灯值守"]
    F -->|异常回修| C

D 格里堆着四件有名字的固定活：版本号 bump、changelog 追加、tag 切打、Release/发包。它们不是杂务，是发布工程的老三样加一条账本——CHANGELOG 就是项目的流水账，tag 就是账本的页码，Release notes 就是给用户看的那一页摘要。

三条旁证说明这段活真没人顺手干了：

1. 运行时原语只触发不记档。 编排沉底刊拆过 CronCreate 族的定时原语——定时器到点会叫醒模型，但叫醒之后该写什么版本号，原语不管。
2. 门原语只拦不记。 门原语刊把裁决门拆到了选项工程学级别，但门拦的是「要不要做」，不是「做完了往账本上记一笔」。
3. artifact 派只存不记。 9 月 7 日只存 artifact 刊记录过「产物只存 artifact、跑完即散」的新架样本——artifact 有保留期限、到期即焚，而 tag 与 CHANGELOG 是仓库里唯一免费且永久的记录介质。恰恰是这段该写永久记录的线，永久记录无人写。

四、为什么空着：三个结构性原因

其一，状态没处借。 部署四方言的方言差异，本质是平台替部署者保管了多少状态：Vercel 的旧 deployment 随时可以重新 promote、Cloudflare 有版本回退、Netlify 有 deploy 历史——部署件把「记住发生过什么」这件事外包给了平台。发版记档位没有这个便利：它的状态就是用户仓库本身——tag、CHANGELOG.md、包仓库里的版本号，全部长在用户地皮上。本栏 9 月 12 日有过判断：SKILL.md 擅长搬运知识，搬运不了运行时状态。部署件绕开了这个判断（平台替它记），发版件绕不开。

其二，后悔药不存在。 部署首拆刊提炼过门控写法第一条：回滚路径先于部署路径——四方言对照表里每一行都有「后悔药」一栏。发版位恰恰是回滚真空审计判空结论的极端化：主流包仓库普遍不为已发布版本提供无代价撤回，版本号发出去就是永久占用。门控四条里最值钱的「便宜的后悔药」，在这个工位天然缺货——这大概就是没人敢让件上岗的隐情：部署错了 sentry 半小时内叫人，发错了版本号谁都不会发现。

其三，错误不进任何监控。 CI 位管红灯，监控位管线上异常——但一条写错的 changelog、一个跳错的版本号，CI 照样绿、部署照样成、sentry 照样静。红灯面五件全体失明。部署首拆刊说发布层最好的 SKILL.md 全在写「刹车」，而发版位的错误恰恰是全部刹车都够不着的静默永久错误。记档错误不报警，只留档——留给未来每一次溯源的人撞上。

五、三条代班路线：有人干活，没人记档

空位不等于没人干活。这段活今天实际由三条「代班路线」承接着，本期给它们建档评分（推断值口径：基于公开稳定 CLI 特性与本栏存档事实，非实读正文，权重沿用五维固定口径；社区维度按生态常见度保守估※）：

flowchart TD
    Z["发版记档的活"] --> RA["临时 gh 命令"]
    Z --> RB["固化进 YAML"]
    Z --> RC["平台原生记录"]
    RA --> Q["仓库记档缺位"]
    RB --> Q
    RC --> Q

路线一是大多数会话的真实做法：模型现场拼 gh release create 加 git tag。功能上够用（release 子命令是 GitHub CLI 公开稳定面），设计上一星——纪律为零，每次会话从零猜版本号、从零编格式，同一个仓库两次发版能写出两种文风。实战四星、上手五星，因为它确实每天都在干这活。

路线二是把知识一次性烧进 YAML：让 github-actions-skill 写一条发版 workflow，从此 tag 与 Release 由流水线自动切。设计与功能双四星——流程固定、格式稳定、可审计。代价是知识离场：一旦固化，发版纪律就脱离了会话，版本规则过时了也没人知道（CI 位早有短板记录：runner 与 action 版本随平台迭代，写法会过期）。

路线三是干脆不记：Vercel 的 promote 链、Netlify 的 deploy 列表本身就是一份「发过什么」的记录，部署四件在役率最高的原因之一就是这套记录免费。加权 3.90 拿下代班榜第一——但它记录的是「部署了什么」，不是「发布了什么」：没有版本语义、没有变更摘要、不回写仓库，换平台即失忆。

三条路线的加权分都在及格线以上，第六栏却整列打叉：代班都称职，本职全交白卷。 这就是发版记档位的完整现状——活有人干，账没人记。

六、借调名单：存量件里谁能补位

按本栏「同件两分」的既定方法（同件在不同岗位面试得分可以不同），给三件在役存档件做一次发版位专项借调面。只给判定，不造新分：

反讽值得单独一段：这个生态其实交付过一条完整的发版流水线——只是发给技能自己。 据本栏 6 月 30 日刊转述，gh 自 2026 年 4 月起把 install/pin/publish 语义标准化进 gh skill 命令（GitHub Changelog 记录于 4 月 16 日，转引未复核），skill-sync-github 则帮技能作者维护 changelog、推送、触发 release。技能的货架有人管得井井有条，技能用户的项目发版却无人记档——同一批作者、同一个宿主、同一段流水线，只修了自家门口那一米。

七、若要补位：发版记档件的设计条款五条

把本栏各刊提炼过的纪律拼起来，这个工位的 SKILL.md 该长什么样，其实件件有据：

1. 状态唯一源显式化。 版本号以 package.json、CHANGELOG 还是 tag 为准，正文必须指定一个、且只指定一个真源——gstack 用模板从根上掐死「文档说有、实际早删」的失同步，是现成的参照（150+ 文件建制刊）。
2. 不可逆动作前强制裁决门。 门原语刊证明门是接口不是弹窗——发版位的门只能开在事前：dry-run 结果、版本号变更、changelog 增量、待发布文件清单，四样进选项工程，人批了才动。事后没有门，这是本位与部署位最大的写法差异。
3. 幂等可重入。 门控四条的第四条在本位是生死条：失败重跑不得双发、不得占号——先查远端是否已存在同名 tag/Release，再决定续跑还是报告。
4. 读写对称。 gstack 的 update-check 配 uninstall、dev-setup 配 dev-teardown——每个有副作用的动作配一个验证性回收动作：写了 tag 必须读回 tag，写了 Release 必须核对其内容。
5. 触发面照抄虚构件的门牌。 本栏唯一的发版件正文（教学虚构）description 里那句「即使用户没有说出『公告』二字」，恰好是发版位最需要的写法——用户说「把这版发出去」时，没有触发词兜底的件永远装死。

五条里没有一条是能力，全部是刹车——与部署首拆刊的结论隔空对上：越接近不可逆动作的工位，SKILL.md 的成熟度越取决于它多会拦，而不是多会发。

八、安装与动手命令

# 第一步永远是先搜生态——搜不到本身就是本期论点的复现
npx skills find changelog
npx skills find release notes
npx skills find semver

# 确认空手而归后，当代班路线一的纪律模板用（先看后写，三段式）：
gh release view --json tagName,name,publishedAt   # 先查：远端有没有
gh release create v0.4.0 --generate-notes --draft # 再写：草稿态落地
gh release edit v0.4.0 --draft=false              # 后发：人工确认后转正

# 想走路线二，让代笔先体检再动笔：
# 在会话里明确要求 github-actions-skill 锁定 action 版本号并写明失败重入逻辑

九、推荐排行榜

• 最佳代班：平台原生语义（3.90）——唯一带工程语义的现成记录，但请记得它不回写仓库
• 最佳借调：gh-cli——全家桶现成，缺的只是一页纪律正文
• 最大反讽：skill-sync-github——生态唯一在役的发版流水线，只服务技能自己
• 最刺眼的对照：repo-story-time 把 git 历史的「故事一半」自动化得有模有样（传记、盘点、考古四相俱全），账本一半至今无人认领——同一份 git log，讲故事有人写书，记流水账没有人工位
• 最该有人写的一件：发版记档件——设计条款五条已备齐，剩下的只是有人把它写出来、验三遍、发上去（发的时候，别忘了让它自己记档）

本期核心发现

1. 工作流自动化轨开采完毕，只剩一段线无人认领。 部署、CI、监控、编排、门、回滚、状态七处各有专刊，合并与部署之间的发版记档位是最后一块无主地。
2. 空位的成因是结构性的：状态长在用户仓库、后悔药天然缺货、错误不进任何监控——三条都踩在本栏既有判断的延长线上。
3. 活有人干、账没人记：三条代班路线加权 3.00 到 3.90，仓库记档栏整列白卷。
4. 生态只修了自家的发版线：gh skill publish 与 skill-sync-github 把技能上架做成了流水线，用户项目的同一段路至今是土路。

参考来源

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。