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

這周我發(fā)布了維護(hù)的VS Code擴(kuò)展v0.9.7版本。修復(fù)的形狀才是我想寫的——因?yàn)槟莻€(gè)顯而易見的版本會是錯的。

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

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

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

看看一個(gè)項(xiàng)目一年實(shí)際積累的附件：

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

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

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

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

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

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