老項目想用 OpenSpec，第一步根本不是寫規範
整理版優先睇
老項目用 OpenSpec 第一步係由下一個具體變更開始，唔好諗住一次過反曬成個倉庫做規範
呢篇文章係整理自 OpenSpec 維護者 TabishB 喺 GitHub issue 嘅回覆。文章主要幫大家釐清一個常見誤區：好多開發者一裝好 OpenSpec，就諗住先將成個老項目嘅代碼反推成規範，但呢個做法其實反效果。維護者強調 OpenSpec 本身係為老項目（brownfield）設計嘅，但接入嘅姿勢同新項目完全唔同。整體結論係：規範係接入嘅結果，唔係前提；你應該由第一個真正嘅變更加手，邊做邊累積規範，而唔係花兩星期去反推成個倉庫。
第一段：文章背景係好多開發者喺 OpenSpec 嘅 issue 區問「大型老項目第一步做咩？」。維護者 TabishB 指出，最直覺嘅做法——叫 AI 讀曬成個代碼庫再反推規範——其實行唔通，因為上下文窗口有限、AI 容易混淆意圖同實現細節，而且反推出嚟嘅規範一定要經人工審核先可以當作事實基線。所以第一步應該係直接用 OpenSpec 創建第一個 change proposal，由 agent 引導你點樣做。
第二段：正確做法有五個動作。首先，啟用 expanded profile 代替默認嘅 core profile，用 /opsx:new 加 /opsx:continue 逐步生成，每步都要 review。其次，一定要先用 /opsx:explore 瞭解相關模塊，唔好一嚟就 propose。第三，按業務域（domain）切分規範，例如 auth、payments，而唔…
- 老項目用 OpenSpec 第一步唔係寫規範，而係由第一個實際變更加手，規範係邊做邊累積出嚟
- 啟用 expanded profile，先用 /opsx:explore 瞭解背景，再用 /opsx:new 加 /opsx:continue 逐步生成
- 按業務域（domain）切分規範，唔好跟文件目錄；一個域一句話講得清就係好開始
- 反推規範成本高：AI 分唔清意圖同實現，而且一定要經人工審核先可以當事實基線
- 將老項目嘅隱性約束（例如唔改得嘅接口）寫入 config.yaml 嘅 context 字段，每次 propose 自動讀取
問題：老項目點樣開始用 OpenSpec？
好多開發者裝咗 OpenSpec，打開跑咗幾年嘅老項目就傻眼：廿幾個模塊，冇文檔冇註釋。第一個諗法係叫 AI 讀曬成個倉庫反推成規範，但 OpenSpec 維護者 TabishB 喺 GitHub issue 回覆話呢個做法正好相反。
OpenSpec 本身係為老項目設計嘅，唔只係畀新項目用
OpenSpec README 嘅設計原則第4條寫明「built for brownfield not just greenfield」，即係佢哋一開始就考慮咗老項目場景。老代碼隱性約束多，對齊更重要，但接入姿勢同新項目完全唔同。
點解唔應該先反推規範？兩個代價
TabishB 喺 issue #724 話：規範存嘅係意圖同用戶體驗嘅契約。就算反推出嚟嘅規範，都一定要經過人工審核，先可以成為 agent 當作事實基線嘅上下文。
- 上下文窗口扛唔住幾萬行代碼，塞入去會截斷或者亂估
- AI 容易將實現細節當成意圖，將臨時繞坑當成需求
所以維護者堅持：唔好一嚟就想將整個倉庫反推成規範，從下一個具體變更加手就得。
正確做法：5個動作，按順序做
- 1 啟用 expanded profile，用 /opsx:new 建腳手架，再用 /opsx:continue 按依賴逐個生成，每步要 review
- 2 先 /opsx:explore 瞭解相關模塊，而唔係直接 propose；explore 唔生成 artifact，只係同 agent 一齊調研
- 3 按域（domain）切分規範，例如 auth、payments，而唔係跟 src/controllers/ 呢啲目錄；用一句話講得明嘅模塊做起點
- 4 如果真係要反推 baseline 規範，一次只做一個域，草稿一定要揾熟手逐條確認意圖，確認先合入
- 5 處理跨模塊改動時，delta 規範放喺受影響嘅「對外行為」所屬嘅域；將唔改得嘅老接口寫入 config.yaml 嘅 context 字段
規範係接入嘅結果，唔係前提；先做第一個變更，規範自然就會慢慢累積
跑起來之後：配置同歸檔要注意嘅嘢
config.yaml 嘅 context 字段對老項目好重要。唔使一次寫曬，可以喺前幾次跑 change 嘅過程中邊發現邊補。每次 agent 提嘅方案唔對路，就將對應嘅約束追加落去。
模型選擇方面，OpenSpec README 建議老項目用高推理能力嘅模型
Archive 嗰陣，三種 delta（ADDED、MODIFIED、REMOVED）嘅行為會令主 spec 慢慢長大。ADDED 最常用，係畀老模塊加新行為；MODIFIED 會替換主 spec 嘅 requirement；REMOVED 就刪除。想主 spec 覆蓋曬核心域，通常要花幾周到幾個月。
喺老代碼上用 OpenSpec，應該由邊一步開始？OpenSpec 維護者俾嘅答案，可能同你諗嘅啱啱相反。
寫在前頭
裝好 OpenSpec，興致勃勃打開手上跑咗三年嘅老項目，第一秒就呆咗。
廿幾個模塊，冇文檔冇註釋。規範應該由邊度開始寫？要唔要先花兩個禮拜俾 AI 將全部代碼讀一次反推出來，定係索性乜都唔寫，等嚇一個需求慢慢補？官方文檔大部分篇幅都係講新項目點樣跑 propose → apply → archive，但大多數人手上係祖傳代碼，唔係由零開始嘅新項目。
去 GitHub 上 OpenSpec 倉庫嘅 issue 區睇過，發現問呢件事嘅人唔少——#510「大型老項目第一步係乜嘢」、#214「為現有倉庫初始化 specs」、#724「反向工程 specs」等好幾個 issue 都喺度圍繞同一個問題，到依家官方都冇俾標準答案。
但係維護者 TabishB 喺幾條回覆裏面將思路講清楚過，同大多數人嘅直覺啱啱相反。
一、OpenSpec 本身就係為老項目設計嘅
OpenSpec 嘅 README 開頭列咗五條設計原則，類似團隊嘅口號：
第 4 條好關鍵：OpenSpec 係為老項目設計嘅，唔單止係俾由零開始嘅新項目用。brownfield 就係「老項目」，greenfield 係「新項目」，下文都用中文。
OpenSpec 想做嘅事好簡單：喺 AI 動手寫代碼之前，先將「呢次到底要做啲乜」對齊清楚。老代碼上隱性約束多——歷史決策、繞坑實現、鬱唔到嘅接口都散喺文件裏面——呢種對齊喺老項目上反而更重要。問題從來唔係 OpenSpec 適唔適合老項目，而係接入嘅方式同新項目完全唔同。
順便交代嚇背景：截至 2026 年 6 月初，OpenSpec 最新版本係 v1.4.0（2026-06-01 發佈），GitHub 上有大約 5.2 萬 star，Claude Code、Cursor、Codex、Windsurf、Kimi CLI、Mistral Vibe 呢啲主流 AI 編程工具都接得上。
二、最反直覺嘅一步：唔好先將成個倉庫反推成規範
呢件事同大多數人嘅第一反應啱啱相反。
大多數人第一個想法係：既然 OpenSpec 係「規範驅動開發」，咁老項目第一步當然係俾 AI 將現有代碼全部讀一次，反推出一套規範，再根據規範做後續變更。聽落都幾合理。
但 TabishB 喺 issue #510 係咁樣回覆嘅（節選翻譯）：
呢個聽落反直覺，但好多開發者確實會過度分析呢件事。建議第一步就係用 OpenSpec 建立你嘅第一個 change proposal。佢自帶引導，如果卡住可以直接問你嘅 coding agent 接下來應該點做。
issue #214 裏面佢講得更直接：
你可以俾 agent 讀
openspec/AGENTS.md然後為現有代碼庫生成 specs。但我冇將呢個做成內置功能，因為好難做得啱，而且對好多 agent 嚟講喺一個上下文窗口裏面搞掂成個代碼庫都好睏難。
兩段連埋一齊讀，就係同一個意思：唔好一嚟就想將成個倉庫反推成規範，由下一個具體變更加開始用就得。規範係一邊做一邊儲返嚟嘅，唔需要事先畫好。
三、點解唔應該先反推：兩個避唔開嘅代價
點解維護者咁堅持？issue #724 裏面嗰段關於反向工程嘅回覆，說話講得幾重：
規範存嘅係關於意圖同用戶體驗嘅契約。就算係反推出嚟嘅規範，都一定要經過人工審核，先至可以成為 agent 用作事實基線（ground truth）嘅上下文。
原文：Specs store contracts of intent and user experience. Even reverse-engineered specs should be reviewed by humans before becoming the context that agents treat as ground truth.
簡單解釋嚇：事實基線係 agent 默認相信嘅事實——一旦寫入規範，agent 後續每次判斷都會根據佢。所以呢樣嘢一定要可靠，靠 AI 反推出嚟嘅版本如果冇人審核，等於俾 agent 抱住錯誤嘅"事實"繼續推理。
拆開嚟睇，其實係兩個具體代價：
OpenSpec 倉庫嘅 issue #690 有人嘗試緊一套叫 opsx-discovery 嘅草案——自己整一套模板同工作流程幫老代碼出基線規範——目前仲好早期，未合入官方。呢個思路可以參考，但唔好當成熟方案用。
四、咁應該點做：5 個動作，跟順序
前 4 個動作講「點樣將佢跑起」，第 5 個講「老項目獨有嘅兩個難關」。
1. 啓用 expanded profile，唔好用默認嘅 core
新裝 OpenSpec 默認係 core profile，包含 5 個命令：/opsx:propose、/opsx:explore、/opsx:apply、/opsx:sync、/opsx:archive。/opsx:propose 一步生成曬全部 planning artifact（artifact 指 proposal、specs、design、tasks 呢幾份 OpenSpec 自動生成嘅產物）。
新項目行呢個節奏冇問題，但老代碼上下文複雜，agent 一次估中嘅概率唔高。
社區開發者 sgryphon 喺 issue #510 俾嘅實戰建議：啓用 expanded profile，用 /opsx:new（先建腳手架）+ /opsx:continue（按依賴順序逐個生成）嘅組合，每步生成後手動 review。如果 proposal 寫歪咗，當場改或者刪咗再生成，比起 4 個 artifact 全部生成曬先發現方向錯咗再返工要省事好多。
啓用方式：
啓用後會多出 /opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive、/opsx:onboard 6 個命令。老項目場景下 new + continue 呢一對最常用。
2. 先 explore 再 propose
/opsx:explore 命令喺 core 同 expanded 兩種 profile 都有，但好多人冇意識到佢對老項目有幾重要。
explore 唔生成任何 artifact，只係同 agent 一齊調研：讀相關模塊、對比可能嘅方案、畫思維導圖、問問題。等思路清楚咗再 /opsx:propose 或 /opsx:new。
老代碼場景下，explore 呢一步千祈唔好慳。先俾 agent 將相關嘅幾個文件讀明，再俾佢寫 proposal。唔係佢只可以基於唔完整嘅上下文估，生成嘅方案大概率會繞過老代碼裏面嘅隱性約束。
3. 按域（domain）切分，唔好按文件目錄切
openspec/specs/ 係按域組織嘅：specs/auth/、specs/payments/、specs/checkout/。老倉庫往往按文件目錄組織：src/controllers/、src/services/、src/utils/。
第一次接入唔好諗住將成個目錄結構都搬成 spec 域結構。揀一個邊界清晰、改動頻繁嘅域先動手——認證、支付、訂單呢啲業務上可以獨立講清楚嘅模塊——淨係由呢一個域開始建立規範，其他域等真係改到先再補。
判斷「邊界清唔清晰」嘅簡單標準：可唔可以用一句話向新嚟嘅同事講清楚呢個模塊係做咩嘅、對外暴露啲咩行為。講唔清楚嘅模塊，說明佢喺代碼裏面就同其他模塊纏埋一齊，唔好攞呢種模塊做起點。
4. 真係要反推，按模塊嚟、一定要人工過一次
如果團隊就係想俾某個老模塊出基線規範（要交俾新人、要做外部審計、要拆服務），將佢當成一個特殊嘅 change 嚟做，千祈唔好繞過人工 review。
操作上：
openspec/specs/，由呢一刻開始，呢套規範先可以作為 agent 嘅事實基線反推一定要分模塊逐步做，唔好一次過俾成個倉庫批發。
5. 處理老項目獨有嘅兩個邊界問題
新項目幾乎碰唔到、老項目避唔開嘅兩件事。
跨模塊改動時，delta 規範應該放喺邊個域
delta 喺 OpenSpec 裏面指增量規範，描述呢次 change 相對當前主 spec 嘅增刪改。老代碼成日係 A 模塊直接 import B 模塊嘅內部函數，做一個 change 時，delta 應該寫喺 A 域定係 B 域？
實操判斷：改動影響嘅「對外行為」屬於邊個域，delta 就放邊個域。如果一次改動改咗 A 嘅實現，同時令 B 嘅對外行為都變咗，一係拆成兩個 change，一係喺同一個 change 裏面同時寫 A、B 兩個域嘅 delta。
唔好為咗慳事將跨域嘅改動塞入一個域嘅 delta，archive 後主 spec 就會亂。
將鬱唔到嘅老接口寫入 context 字段
老項目成日有「祖傳鬱唔到」嘅接口——被外部系統依賴、寫喺合約裏面、上游團隊維護、改咗就會炸十幾個調用方。
將呢啲約束寫入 config.yaml 的 context: 字段，每次 propose 時 agent 都會讀到，提出嘅方案就唔會建議你去改鬱唔到嘅嘢。
sgryphon 喺 issue #510 提到呢一點：「如果上下文整體錯咗，可以試嚇向 config.yaml 的 context: 段裏面補充信息。」老項目接入嘅難點，好多時就係在於將呢啲「唔喺代碼裏面、只喺人腦裏面」嘅約束寫出嚟。
五、跑起之後仲要顧兩件事：配置同歸檔
上面 5 個動作將「點樣起步」講完咗，跑起之後仲有兩件事要照顧嚇。
1. config.yaml 俾老項目用嘅關鍵字段
老項目第一次接入，建議至少配上兩樣嘢：
context 字段唔需要一次寫曬，可以喺前幾次行 change 嘅過程中邊發現邊補。每次 agent 提出嘅方案唔對路，就將對應嘅約束加返入去。
2. archive 時三種 delta 喺老項目上嘅差異
老項目第一次行完 archive 後，主 spec 先會真正建立起來。三種 delta 類型喺老項目裏面嘅典型用法：
archive 後變更歸檔到 openspec/changes/archive/，主 spec 會隨每次 archive 慢慢生起嚟。想令主 spec 將核心域都覆蓋到，通常要花幾個禮拜到幾個月。
最後
OpenSpec 自己喺 README 裏面就將「為老項目設計」寫成一條明文原則，但接老代碼嘅方式同新項目完全唔係一回事。好多人卡住嘅點都一樣：以為規範係接入嘅前提，要有規範先可以開始。維護者反覆講嘅剛好相反——規範係接入嘅結果，由第一個真實變更加開始逐啲逐啲儲。
老項目接 OpenSpec 嘅核心唔係將代碼反推成文檔，而係將「下一個改動」做成第一個 change。先做動作，規範自然就有。
在老代碼上用 OpenSpec，該從哪一步開始？OpenSpec 維護者給的答案，可能跟你想的正好相反。
寫在前面
裝上 OpenSpec，興致勃勃打開手裏跑了三年的老項目，第一秒就懵了。
二十幾個模塊，沒文檔沒註釋。規範該從哪開始寫？要先花兩週讓 AI 把代碼全部讀一遍反推出來，還是乾脆什麼都別寫，等下一個需求慢慢補？官方文檔大部分篇幅都在講新項目怎麼跑 propose → apply → archive，但大多數人手上是祖傳代碼，不是從零開始的新項目。
去 GitHub 上 OpenSpec 倉庫的 issue 區翻了翻，發現問這事的人不少——#510「大型老項目第一步是什麼」、#214「為已有倉庫初始化 specs」、#724「反向工程 specs」等好幾個 issue 都在繞同一個問題，到現在官方都沒給標準答案。
但維護者 TabishB 在幾條回覆裏把思路說清楚過，跟大多數人的直覺剛好相反。
一、OpenSpec 本來就是衝老項目設計的
OpenSpec 的 README 開頭列了五條設計原則，類似團隊的口號：
第 4 條很關鍵：OpenSpec 是為老項目設計的，不只是給從零開始的新項目用。brownfield 就是「老項目」，greenfield 是「新項目」，下文都用中文。
OpenSpec 想做的事很簡單：在 AI 動手寫代碼之前，先把「這次到底要做啥」對齊清楚。老代碼上隱性約束多——歷史決策、繞坑實現、不能動的接口都散在文件裏——這種對齊在老項目上反而更重要。問題從來不是 OpenSpec 適不適合老項目，而是接進去的姿勢和新項目完全不一樣。
順便交代下背景：截至 2026 年 6 月初，OpenSpec 最新版本是 v1.4.0（2026-06-01 發佈），GitHub 上 5.2 萬 star 左右，Claude Code、Cursor、Codex、Windsurf、Kimi CLI、Mistral Vibe 這些主流 AI 編程工具都接得上。
二、最反直覺的一步：別先把整個倉庫反推成規範
這事和大多數人的第一反應正好相反。
大多數人第一想法是：既然 OpenSpec 是「規範驅動開發」，那老項目第一步當然是讓 AI 把現有代碼全讀一遍，反推出一套規範，再基於規範做後續變更。聽着挺合理。
但 TabishB 在 issue #510 是這麼回的（節選翻譯）：
這聽起來反直覺，但很多開發者確實會過度分析這件事。建議第一步就是用 OpenSpec 創建你的第一個 change proposal。它自帶引導，如果卡住可以直接問你的 coding agent 接下來該怎麼做。
issue #214 裏他說得更直接：
你可以讓 agent 讀
openspec/AGENTS.md然後為現有代碼庫生成 specs。但我沒把這做成內置功能，因為很難做對，而且對很多 agent 來說在一個上下文窗口裏搞定整個代碼庫都很困難。
兩段連起來讀，就是一個意思：別一上來就想把整個倉庫反推成規範，從下一個具體變更開始用就行。規範是邊做邊攢出來的，不需要事先畫好。
三、為什麼不該先反推：兩個繞不開的代價
為啥維護者這麼堅持？issue #724 裏那段關於反向工程的回覆，話說得挺重：
規範存的是關於意圖和用戶體驗的契約。即便是反推出來的規範，也必須經過人工審核，才能成為 agent 用作事實基線（ground truth）的上下文。
原文：Specs store contracts of intent and user experience. Even reverse-engineered specs should be reviewed by humans before becoming the context that agents treat as ground truth.
簡單解釋下：事實基線是 agent 默認相信的事實——一旦寫進規範，agent 後續每次判斷都會基於它。所以這玩意必須靠譜，靠 AI 反推出來的版本如果沒人審核，等於讓 agent 抱着錯誤的"事實"繼續推理。
拆開看，其實是兩個具體代價：
OpenSpec 倉庫的 issue #690 有人在嘗試一套叫 opsx-discovery 的草案——自己造一套模板和工作流幫老代碼出基線規範——目前還很早期，沒合進官方。這思路可以參考，但別當成熟方案用。
四、那應該怎麼做：5 個動作，按順序
前 4 個動作講「怎麼把它跑起來」，第 5 個講「老項目獨有的兩個坎」。
1. 啓用 expanded profile，別用默認的 core
新裝 OpenSpec 默認是 core profile，包含 5 個命令：/opsx:propose、/opsx:explore、/opsx:apply、/opsx:sync、/opsx:archive。/opsx:propose 一步生成全部 planning artifact（artifact 指 proposal、specs、design、tasks 這幾份 OpenSpec 自動生成的產物）。
新項目跑這個節奏沒問題，但老代碼上下文複雜，agent 一次猜對的概率不高。
社區開發者 sgryphon 在 issue #510 給的實戰建議：啓用 expanded profile，用 /opsx:new（先建腳手架）+ /opsx:continue（按依賴順序逐個生成）的組合，每步生成後手動 review。如果 proposal 寫歪了，當場改或者刪了重生成，比 4 個 artifact 全生成完才發現方向錯了再返工要省事得多。
啓用方式：
啓用後會多出 /opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive、/opsx:onboard 6 個命令。老項目場景下 new + continue 這一對最常用。
2. 先 explore 再 propose
/opsx:explore 命令在 core 和 expanded 兩種 profile 裏都有，但很多人沒意識到它對老項目有多重要。
explore 不生成任何 artifact，只是和 agent 一起調研：讀相關模塊、對比可能的方案、畫思維導圖、問問題。等思路清楚了再 /opsx:propose 或 /opsx:new。
老代碼場景下，explore 這一步千萬別省。先讓 agent 把相關的幾個文件讀懂，再讓它寫 proposal。不然它只能基於不完整的上下文猜，生成的方案大概率會繞過老代碼裏的隱性約束。
3. 按域（domain）切分，別按文件目錄切
openspec/specs/ 是按域組織的：specs/auth/、specs/payments/、specs/checkout/。老倉庫往往按文件目錄組織：src/controllers/、src/services/、src/utils/。
第一次接入別想着把整個目錄結構都搬成 spec 域結構。挑一個邊界清晰、改動頻繁的域先動手——認證、支付、訂單這種業務上能獨立講清楚的模塊——只從這一個域開始建立規範，其他域等真改到了再補。
判斷「邊界清不清晰」的簡單標準：能不能用一句話向新來的同事講明白這個模塊是幹嘛的、對外暴露什麼行為。講不清楚的模塊，說明它在代碼裏就跟別的模塊纏在一起，別拿這種模塊當起點。
4. 真要反推，按模塊來、一定要人工過一遍
如果團隊就是想給某個老模塊出基線規範（要交給新人、要做外部審計、要拆服務），把它當成一個特殊的 change 來做，千萬別繞過人工 review。
操作上：
openspec/specs/，從這一刻開始，這套規範才能作為 agent 的事實基線反推一定要分模塊小步做，不要一次性給整個倉庫批發。
5. 處理老項目獨有的兩個邊界問題
新項目幾乎碰不到、老項目躲不開的兩件事。
跨模塊改動時，delta 規範應該放在哪個域
delta 在 OpenSpec 裏指增量規範，描述這次 change 相對當前主 spec 的增刪改。老代碼經常是 A 模塊直接 import B 模塊的內部函數，做一個 change 時，delta 應該寫在 A 域還是 B 域？
實操判斷：改動影響的「對外行為」屬於哪個域，delta 就放哪個域。如果一次改動改了 A 的實現，同時讓 B 的對外行為也變了，要麼拆成兩個 change，要麼在同一個 change 裏同時寫 A、B 兩個域的 delta。
不要圖省事把跨域的改動塞進一個域的 delta，archive 後主 spec 就亂了。
把不能動的老接口寫進 context 字段
老項目經常有「祖傳不能動」的接口——被外部系統依賴、寫在合同裏、上游團隊維護、改了就炸十幾個調用方。
把這些約束寫進 config.yaml 的 context: 字段，每次 propose 時 agent 都會讀到，提出的方案就不會建議你去改不能改的東西。
sgryphon 在 issue #510 提到這一點：「如果上下文整體錯了，可以試着往 config.yaml 的 context: 段裏補充信息。」老項目接入的難點，很多時候就在於把這些「不在代碼裏、只在人腦子裏」的約束寫出來。
五、跑起來之後還要顧兩件事：配置和歸檔
上面 5 個動作把「怎麼起步」講完了，跑起來之後還有兩件事得照顧下。
1. config.yaml 給老項目用的關鍵字段
老項目第一次接入，建議至少配上兩件事：
context 字段不需要一次寫完，可以在前幾次跑 change 的過程中邊發現邊補。每次 agent 提的方案不對路，就把對應的約束追加進去。
2. archive 時三種 delta 在老項目上的差異
老項目第一次跑完 archive 後，主 spec 才會真正建立起來。三種 delta 類型在老項目裏的典型用法：
archive 後變更歸檔到 openspec/changes/archive/，主 spec 會隨每次 archive 慢慢長起來。想讓主 spec 把核心域都覆蓋到，通常得花幾周到幾個月。
寫在最後
OpenSpec 自己在 README 裏就把「為老項目設計」寫成了一條明文原則，但接老代碼的姿勢和新項目完全不是一回事。很多人卡住的點都一樣：以為規範是接入的前提，得先有規範才能開始。維護者反覆說的恰好相反——規範是接入的結果，從第一個真實變更開始一點點攢。
老項目接 OpenSpec 的核心不是把代碼反推成文檔，而是把「下一個改動」做成第一個 change。先做動作，規範自然就有了。