產(chǎn)品規(guī)格文檔從來不是孤立的文本。它帶著線框圖、需要回應(yīng)的監(jiān)管PDF、必須遵守的API契約、還有人談判過的利益相關(guān)者幻燈片。很長一段時間里，我的規(guī)格樹里只有Markdown文件被Git追蹤；而那些支撐它們的證據(jù)，卻在Confluence里腐爛，在共享驅(qū)動器里迷失，在聊天窗口的粘貼截圖里丟失。

這周我發(fā)布了維護(hù)的VS Code擴(kuò)展v0.9.7版本。修復(fù)的形狀才是我想寫的——因為那個顯而易見的版本會是錯的。

先交代背景：我是SPECLAN的創(chuàng)建者，這是一個管理產(chǎn)品規(guī)格的VS Code擴(kuò)展，用帶YAML前置元數(shù)據(jù)的Markdown文件實現(xiàn)——Git原生，每個需求一個文件，按層級樹組織。這個模式（Markdown + YAML + Git）沒有工具也能工作；SPECLAN只是我觀察并工程化解決下面這個設(shè)計問題的地方。

規(guī)格有生命周期：草稿→評審→已批準(zhǔn)→開發(fā)中→測試中→已發(fā)布→已棄用。一旦規(guī)格獲批，團(tuán)隊就對其內(nèi)容達(dá)成一致；實現(xiàn)據(jù)此構(gòu)建、測試和發(fā)布。自然的下一步想法是：附件也應(yīng)該遵循同樣的紀(jì)律。如果你不能悄悄重寫已發(fā)布需求的正文，你也不能悄悄換掉附在上面的API契約。所以：一個通用的附件機(jī)制，處處實行變更請求治理。

我畫了這個方案。沒發(fā)布。測試兩天后，我意識到這個顯而易見的版本把儀式感強(qiáng)加給了根本不該走評審流程的材料。

看看一個項目一年實際積累的附件：

前兩類是釘在特定實體上的證據(jù)，有特定生命周期，治理本身就是目的。后四類是參考資料——跨多個規(guī)格共享，不屬于任何一方，不綁定任何規(guī)格的發(fā)布周期。

如果我強(qiáng)迫第二類走變更請求流程，每次架構(gòu)圖更新都需要一個4階段評審，針對……哪個規(guī)格？它不屬于任何一個。評審者會批準(zhǔn)一個變更，卻沒有父實體可以對比。儀式感沒有錨點。

所以我發(fā)布了兩套故意不同治理機(jī)制的附件系統(tǒng)：

這個分裂來自一個觀察：鎖定適用于有狀態(tài)的實體；項目文件夾沒有狀態(tài)。規(guī)格有狀態(tài)。項目文件夾沒有。不存在"已發(fā)布的項目"來把關(guān)變更，所以統(tǒng)一的治理機(jī)制對兩種情況之一會沒有錨點。

每個功能、需求或變更請求都在其.md文件旁邊獲得自己的artifacts/文件夾：

在所見即所得編輯器中，Artif