HTML 成品的生命週期：計畫歷史存於何處，以及何時從一次性變得持久

問題#

面向人類的成品主題中，剩下兩個 #oq/now 項目：

HTML 作為新 Markdown — HTML 比 markdown 更難比較差異與管理版本；當成品是單檔網站時，計畫歷史與審查會如何處理？
一次性微型應用程式 — 微型應用程式能否套用範本或重複使用，而不是每次重新產生？到了什麼時候，這會推翻「一次性」的定位，並轉變成持久工具？

答案 1：成品是編譯後的檢視畫面——為內容建立版本，重新產生呈現#

對差異檢視／版本管理的疑慮，是把 HTML 檔案當成紀錄。語料庫自身的做法表明並非如此：HTML 成品把內容層（決策、規則、計畫資料）與呈現層（讓人看得懂的渲染結果）混為一談，而只有內容層需要保留歷史。 Markdown 從未迫使我們區分兩者，因為它的呈現方式很簡單；HTML 則不同，而語料庫中每項實務做法早已將兩者分開：

回存至 markdown：這個模式的表述正是如此：「微型應用程式是在持久文字之上的暫時性 編輯介面……真實來源透過 markdown 往返，而豐富的 UI 只在編輯期間存在」——明確指出這是「HTML 最嚴重弱點（差異檢視／版本管理）」的解法（一次性微型應用程式）。
擷取，不要手動撰寫：design_system.html 是從 repo 中 擷取出來的——程式碼才是有版本管理的真實來源，成品可按需重新推導；這種推導方式讓它「更難造假」（持續演進的設計系統）。它的版本歷史就是程式碼的版本歷史。
編譯儲存庫先例：這個 vault 自身的架構會從真實來源的 frontmatter 重新產生衍生檢視畫面（索引表、MOC 清單），並禁止手動編輯產生的輸出（LLM-as-Compiler Knowledge Base）。HTML 計畫只是高一層的同類物件：編譯輸出。沒有人會比較編譯輸出的差異；大家比較的是來源。

因此，「計畫歷史會如何處理」有個直接答案：它存在於內容層，或依設計蒸發。 必須保留的決策會往返存入可管理版本的形式（markdown 區塊、config、repo 檔案——透過回存循環）；呈現則以充足供應的成本按需重新產生（Compute Allocator）。而且審查會重新聚焦於決策，而不是差異：Thariq 七月提出的技巧——依 變更可能性 排列計畫，「先列出我最可能調整的決策……把機械式重構埋在最底下」——就是針對這種媒介重新設計審查方式：可審查的變更是決策清單，而非逐行差異（HTML 作為新 Markdown、未知事項作為代理式工作流程的瓶頸）。

真正失去的是呈現本身的責任追溯／歷史，以及廉價的文字差異檢視，方便審查成品的演變。這項損失之所以可以接受，正是因為這種媒介之所以有效：呈現能重新產生，因此它的歷史沒有價值；計畫促成的共識則記錄在從計畫中擷取出的決策裡。一旦某項呈現選擇成為關鍵依賴（例如利害關係人仰賴的版面配置），它就不再是一次性的呈現，而是跨入答案 2 所說的持久類別，值得真正進行版本管理。尚待釐清之處：語料庫記錄的是一位專家從業者；沒有來源展示多人共同撰寫、團隊規模的 HTML 計畫審查（該頁面剩餘的 #oq/source 正在追蹤此問題）。

答案 2：正確的重用單位是產生器，不是成品#

只要精確指出重用單位，範本問題便迎刃而解。語料庫涵蓋了兩個端點：每項任務都重新產生，價值在於 適配度（「為這個問題設計理想介面」——一次性微型應用程式）；以及持續保留成品，價值在於 一致性（「產生一次，作為上下文無限期重用」——持續演進的設計系統）。連結這兩者的機制，早已在實際情境中經過衡量：

當微型應用程式模式反覆出現時，套用範本的是 產生器提示，不是 HTML。 這正是一項 skill 的本質——可重用工作流程的「撰寫格式」（Loop Engineering）；而 skills 是系統化的基本單位，其採用率已測得每週活躍 Codex 使用者中從 5.4% 升至 26.6%，在內部幾乎普及（代理式工作系統化）。「規則編輯器 skill」會針對每組新規則，重新產生一個 全新且合用的 微型應用程式：應用程式維持一次性（保留每項任務的適配度），skill 則是持久資產（獲得一致性）。若為成品本身套用範本，就會犧牲微型應用程式之所以值得採用的適配度；為產生器套用範本則毫無損失。因此，重用並不會推翻一次性定位——而是將其分層：成品一次性，產生器持久。

只有在三項條件成立時，成品本身才應升格為持久資產；語料庫中唯一的持久範例符合全部三項條件（持續演進的設計系統）：

重複使用——相同介面會在不同任務中反覆需要，而非只用一次（「每當你開始新工作」時，這套設計系統都會交給 Claude 使用）。
同步壓力——它必須追蹤持續演變的來源（從程式碼庫擷取；它尚待解答的問題，正是重新擷取週期與維護成本）。
作者以外的受眾——非技術利害關係人會自行使用（Claire Vo 的元件頁面）。

升格並非免費。持久成品會承擔一次性成品不必負擔的義務：維護／同步成本（持續演進的設計系統本身就提出「專案規模到了什麼程度時，維護成品的成本會高於它帶來的一致性價值」）、慣例演變造成的 skill 腐朽風險（代理式工作系統化提出的債務表面問題），以及成品雜亂膨脹上限下的固定席位——這正是面向人類的 harness 雜亂膨脹轉移到的軸線（面向人類的 harness（HTML 成品）會觸及自身的雜亂膨脹上限嗎？）。這也把存續者分類法應用到面向人類的成品上：持久成品會加入必須刻意維護的 harness 類別；一次性成品之所以免費，正是因為沒有任何內容會持續存在。

失敗模式是未作選擇的中間狀態：臨時拼湊的微型應用程式未經升格便被保留下來——無人維護、與來源脫節，還不斷累積。這就是工具雜亂加上腐朽：付出持久資產的維護成本，卻既沒有一次性成品的適配度，也沒有持久成品的一致性——一次性微型應用程式所擔心的工作流程碎片化成真。這項紀律刻意採取二分法：要嘛重新產生，要嘛維護；絕不只是留著。

整合後的結論#

從不同端點來看，兩個問題其實是同一項生命週期決策。把每個 HTML 成品都當成編譯輸出：其內容在持久層（markdown、config、repo）管理版本；其呈現按需重新產生；審查則以決策為依據，而非差異。重用集中在產生器（skill），而非產生出的應用程式；成品只有透過重複使用、同步壓力與受眾，才值得持久化——而持久化也代表必須維護。其餘的都該刻意丟棄，因為在這套運作方式中，唯一糟糕的狀態，就是既無人重新產生，也無人維護的成品。