為什麼產品發布資料總是找不到？
── 從 Mary 的 5 分鐘變 30 分鐘，談開發團隊隱性知識的流失
Release-as-Knowledge（R2K · 軟體發布即知識傳遞）系列・篇 1 / 6
下午 2 點 25 分，Mary 接到一個 Slack 訊息。
「客戶 A 公司明天要從 2.3.4 升到 2.4.1，他們問升級要做什麼準備、要停機多久、有沒有需要改的設定。我半小時後跟他們開會，你能準備一下嗎？」
Mary 是支援工程師，做這份工作三年了。她很熟悉接下來要做的事：
application.yml 跟 migration/ 兩個資料夾的 commit30 分鐘過去，她拼湊出一個答案。她有八成把握答案是對的。剩下兩成，只能在客戶會議上小心應對。
Mary 知道所有資訊都在某個地方 — 開發團隊一定知道這次改了什麼、改了多少、有什麼風險。問題是這些資訊沒有一個系統化的出口。
每次發布，開發團隊腦袋裡的知識就跟著新版本被釋出。但這份知識並不會跟著 Docker image 一起被發布出去。它留在工程師的腦袋裡、留在 PR description 裡、留在 Slack 對話裡、有時候是 commit message 裡。
這篇文章想討論的是：這個情況可以改變嗎？如果產品發布時，「開發團隊知道的事」可以自動跟著一起發布，世界會變什麼樣？
這是一個 6 篇系列的開頭。從 Mary 的痛點出發，一步步走到一個我認為未來 3-5 年會變成 ISV 標準做法的方向。今天先談問題的本質。
讓我們先盤點一次。每一次 CI/CD pipeline 跑完，實際上產出多少資訊：
spring-configuration-metadata.json、所有設定鍵的型別與預設值這個清單可以列得很長。
但這些資料的命運是什麼？
沒有一個自動化管道，把這些資料跟產品 image 綁在一起、發布給需要它的人。
CI/CD 的設計者沒有犯錯。他們的目標是「讓建置可以重現」，不是「讓組織內外的非開發者能查詢」。資料留在 CI 系統內部，從 CI 設計者的視角是對的 — 從 Mary 的視角是災難。
這是設計上的盲區，不是技術上的瓶頸。
但更糟糕的是另一類資訊 — 真正存在於開發團隊「腦袋裡」的知識：
這類問題的答案，通常只在 PR description 跟一兩個工程師的對話裡。發布之後三個月，連他們自己都記不清。
這類知識的命運更差：
更可惜的是 — 這些知識的「原始資料」其實都在 code 跟 config 裡。
只是沒人把這些原始資料變成「給人看的 manifest」。
每一次發布，開發團隊都產出大量結構化資料、寫了大量 PR 文字、留了大量 commit message。然後這些東西在 CI 跑完的瞬間，跟新版本說再見。
過去十幾年，我們花了很多心力把「程式碼」管道化：
但「程式碼以外的開發團隊知識」呢？
這些知識停在前工業時代。
這就讓我想：軟體發布這個動作，為什麼只發布 binary？
binary 是給機器跑的，但文件、變更說明、測試結果、設定變動清單 — 這些是給「人」用的。
過去的設計假設是「程式碼是核心，其他都是周邊」。
但對 Mary 來說，周邊才是她的工作。
對客戶 DevOps 來說，周邊才是他們需要的。
對業務來說，周邊才是報價依據。
如果我們重新想：軟體發布應該同時是「binary 發布」與「知識發布」，事情會變什麼樣？
如果 image 是發布的最終載體，那為什麼不把資料放進 image？
OCI 規格本來就準備了好幾種機制 — Docker LABEL、image annotations、metadata layer、OCI Referrers。每一種都可以放 metadata。
但這只是工具。真正的問題是：有哪個 ISV 有意識地用這些工具，把開發團隊的隱性知識變成可發布的資料？
我看到的答案是：業界個別工具非常成熟（oasdiff 處理 API diff、Atlas 處理 DB schema migration、Confluent Schema Registry 處理 event schema），但「整合給非開發團隊看」這個 niche 是空白的。
每個工具產出自己的 diff 報告。
Release notes 還是工程師人工從這些 diff 摘錄出來的。
沒有「客戶升級前自動產出影響評估報告」的統一機制。
這個空白 — 是這個系列接下來 5 篇要填的東西。
如果要把「軟體發布同時是知識傳遞」這個觀念變成可實踐、可採用、可宣告的東西，它需要一個名字。
跟 Infrastructure-as-Code（IaC）讓基礎建設變成可被管理的程式碼一樣，我把這個方向稱為：
Release-as-Knowledge，簡稱 R2K，中文「軟體發布即知識傳遞」。
R2K 不是一個工具、不是一個產品。它是一個 thesis：
軟體發布同時應該是知識傳遞。
開發團隊產出的 implicit knowledge，應該變成 explicit data，
跟著 image 一起發布。
從下篇開始，我們進入具體機制。我會用 R2K Levels（像 SLSA Level 那樣的漸進階梯）展開：
/r2k/ snapshots + index.yaml 入口清單，2-3 週每一級都有獨立價值，不需要一次做完。
這個系列共 6 篇：
/r2k/index.yaml（R2K Level 2 · Trust）回到 Mary。
下週她又會接到類似的 Slack 訊息。客戶又會問「我升級要做什麼」。她又會開五個瀏覽器視窗、@ 三個工程師、拼湊一個八成正確的答案。
這不是 Mary 的問題。
這不是工程師的問題。
這是設計的問題 — 我們設計 CI/CD 時，沒有想到非開發者也會需要這些資料。
我們設計 release notes 時，把它當成工程師的副產品，不是支援團隊的主產品。
我們設計 image 時，只想到 binary 的傳遞，沒想到知識的傳遞。
這個系列想說的是：這個設計可以改。
工具其實已經就位 — OCI 規格、diff 工具、registry — 都是現成的。
缺的不是技術，是整合的設計 — 一個我們稱為 R2K 的設計。
開發團隊腦袋裡的知識，跟著新版本被釋出 — 但這份知識並不會跟著 image 一起發布出去。
這句話是這個系列的起點。
篇 2 開始，我們進到具體機制 — 從最簡單也最被低估的 Docker LABEL 講起，看 R2K Level 1 怎麼落地。
若你的團隊也有 Mary 的場景，我很想聽聽你的故事。
R2K 系列導覽
Release-as-Knowledge · R2K · 軟體發布即知識傳遞 · v1 · CC BY 4.0
完整介紹 : https://enjtorian.github.io/release-as-knowledge/zh-tw/
官方網站 : https://www.releaseasknowledge.com
在 AI vibe coding 的潮流下, 有沒有考慮 SDD (Story driven development) 的開發模式 ?
應該能一舉解決 Mary 遇到的問題。
如果程式設計師 vibe coding 的開發行為模式還停留在一問一答的片段式程式開發, Mary 的遭遇我一點也不感到意外 !
相較於一問一答的 prompt 開發, 去年幾乎所有的 AI agent 都能進行上下文 context 開發了 !
一份完整的 SDD 更接近一份程式開發的計畫書, 詳細記載開發的技術棧、測試項目、infrastruture、風險評估、...。
物件導向大師 Martin Fowler 都在力推 SDD 了, 現在上車還來的及 !
我其實蠻認同 SDD（Story Driven Development）方向的。
因為現在很多所謂的 vibe coding 問題，本質上就是：
開發行為還停留在「片段式 prompt → 片段式 code」，
缺少完整 context、技術約束、infra、測試與風險描述。
而 SDD 的價值，就是把「開發意圖」結構化。
不過我覺得 R2K 跟 SDD 其實是在不同層次解決問題。
SDD 比較偏：
「怎麼把開發過程描述清楚」
但 R2K 更偏：
「當系統被 build、deploy、release 之後，
這些 knowledge 能不能跟著 images 一起存在」
也就是說：
很多團隊即使有完整 spec、story、ADR、設計文件，
最後進到 production 時，
container/image 仍然是 knowledge-less artifact。
你只能看到：
但你看不到：
而這正是 R2K 想處理的問題：
把 implicit operational knowledge，
變成跟 release images 一起存在的 explicit knowledge。
所以某種程度上，
我反而會把 SDD 視為 R2K 的上游。
SDD 負責產生高品質 knowledge source，
R2K 則負責把 knowledge 跟著 release 一起傳遞出去。
這也是為什麼 R2K 的 客群 不只是工程師，
而是更偏向：
因為它處理的是：
「知識如何成為 deployment supply chain 的一部分」
而不只是「如何寫程式」。
iThome鐵人賽
看影片追技術