原則

# 具明確責任歸屬的交付制度基礎。

規格優先交付（Spec-First Delivery）的這十項原則，為人與 AI 提供共同依據，據以採取行動、升級處理及驗收變更。

## 讓專業判斷在變更中持續可用。

這些原則協助組織保留交付所需的判斷、權限與證據，讓人員、團隊和工具改變後仍能繼續交付。

探索原則

## 選擇與眼前決策最相關的原則。

這些原則共同構成框架的制度基礎。當詳細指引未能涵蓋眼前情況時，它們提供判斷依據，但不規定必須採用某一套工具或流程。

### 參與與責任歸屬

哪些職能直接參與交付、誰有權作出決定，以及如何讓權限保持清楚。

#### 軟體交付是一條跨職能價值鏈

> 每個對交付成果負責的職能，都直接參與產出、質疑、執行、驗證或驗收軟體變更。

產品、領域、架構、工程、品質、營運、安全及其他負責職能，為同一套交付系統提供不同的專業判斷。直接參與可以減少交接造成的資訊流失，但不會混淆各自的專業責任。

#### 重大決策仍須由人負責

> AI 可以提出建議、進行分析、拆分工作、完成實作和協助驗證；重大規格、偏差、驗收與發佈決策，仍須由具名人員保留決策權並承擔責任。

AI 可以承擔大量交付工作，但不會因此成為組織決策的責任人。只要後果重大或需要專業判斷，相關權限和責任便必須清楚落在人身上。

#### 責任歸屬、權限與優先順序必須明確

> 每一項重大規格都必須有清楚的負責人、權威來源、既定優先順序，以及明確的變更途徑。

工作單、測試、架構文件、聊天紀錄與程式碼可能互相矛盾。參與者必須知道哪個來源作準、誰有權決定，以及發生衝突時如何處理。

### 規格與執行

共享的專業判斷如何引導委派工作，並在出現新發現時有紀律地調整。

#### 規格是共享且具權威的交付層

> 規格是連結意圖、知識、專業判斷、限制、執行與證據的共享權威層。

規格不是完工後補寫的文件，也不是實作開始後便可以丟棄的前置材料。它在變更開始前、進行中和完成後都持續發揮作用。

#### 委派工作必須有明確範圍

> 每個被委派的工作單位，都必須說明工作範圍、權限、限制、不可改動範圍與驗收條件。

執行者可以在已同意的權限內放心行動；遇到模糊、風險或需要偏離規格時，應交由適當的決策者處理，而不是在實作中悄悄決定。

#### 可以變更，但不可默默偏離

> 規格可以修訂，但所有變更與偏差都必須明確記錄、能追溯至負責人，並依既定變更控制程序審查和處理。

新的發現可以令規格變得更好。關鍵在於調整是否經過清楚決策並留下紀錄，而不是直到實作完成後才發現結果已經偏離。

#### 規格深度必須與交付風險相稱

> 規格深度應與模糊程度、新穎性、相依關係、風險及可能後果相稱。

低風險修正所需的規格，理應少於涉及客戶資金、安全、法規責任、不可逆資料變更或複雜跨系統契約的工作。目標既不是規格不足，也不是把規格變成繁瑣程序。

### 證據與延續

已驗收的變更如何累積成為可以延續的組織能力。

#### 重要判斷必須成為可延續的組織知識

> 即使原作者已經離開，重大決策、理由、語意、限制、責任歸屬與證據仍必須能夠被找到和使用。

安全地延續軟體交付所需的知識，本身就是交付成果的一部分。這些知識應有明確權威、容易找到，亦不應被綁定於單一人員或工具，並足以讓另一位合資格的參與者只需少量重新查證便能繼續工作。

#### 驗收必須有可觀察的證據

> 軟體變更必須憑可觀察的證據驗收，而不能只以程式碼完成、AI 代理的信心或個人保證作準。

證據既要顯示變更確實運作，也要顯示結果符合已核准的意圖與限制。證據深度應隨工作的後果而調整。

#### 工具使用規格系統，但不能擁有它

> 規格的意義與權威，必須獨立於任何檔案格式、程式碼儲存庫結構、供應商、模型或 AI 代理平台。

工具可以擷取、轉換、分析規格，也可以建議修改，但方便存取不等於擁有決策權。即使交付技術不斷演進，組織仍必須保有規格系統的所有權。

## 先選一條可以建立信任的交付路徑。

以這些原則塑造一項真實變更，再根據工作揭示的問題，逐步強化整個組織的交付系統。

[查看實際採用指引](https://specfirstdelivery.org/zh-tw/framework/adoption)