# 交付作業生命週期中的知識收斂

[共享知識系統](/zh-tw/hub/shared-knowledge-system)保存持久的產品知識，讓任何合資格參與者在作出重大變更前，都能掌握所需脈絡。產品意圖、架構要求、領域語義、管治指示、規格和既有程式碼共同構成交付基礎。至於這些知識刻意留待實作階段處理的問題，則由合資格工程師運用專業判斷作出決定。

因此，一項交付作業即使按照[需求、結構化討論與交付作業](/zh-tw/hub/requirements-increments-and-structured-discussion)所述的模式完成界定，並以連貫一致的知識系統為起點，工程師遇上過往無需定案的問題時，仍可能得出幾個同樣合理的答案。例如，一位工程師使用 ORM 存取資料庫，另一位選用 dataframe 程式庫，第三位察覺存取模式重複，因而建立共用 API，第四位則認為應由獨立服務承擔相關責任。這些做法都可能符合既有規格。交付過程只是揭示了一項組織以往毋須作出的技術決策。

如果交付產物是可供其他工作重用的知識，影響便會超越局部程式碼。兩位各自工作的工程師可能建立用途重疊的 Skills，令 AI 程式開發代理在處理實質相同的工作時採用不同程序。兩位經驗豐富的工程師也可能同時發現程式碼儲存庫的管治指示並不完整，各自提出互不相容的修訂，而且都認為自己的版本應該成為日後貢獻者遵循的做法。

因此，知識系統不但要為交付作業提供基礎，也要吸收交付期間產生的新知識，並釐清平行形成的專業判斷各自適用於何處、彼此有何權威關係，讓組織知識維持一致。本文把這個過程定義為**知識收斂**。

> **知識收斂，是在日後工作依賴某項重大知識之前，先明確界定它適用於哪些情況、與既有知識有何關係，以及應具備甚麼權威。這些知識可能在交付作業期間產生、受到質疑或得到釐清。**

知識收斂要判定哪些決策可以只在原有實作內生效、哪些發現會影響共享工作、哪些可重用知識需要協調，以及哪些事項必須由具明確責任歸屬的角色定案，才可成為權威知識。選擇的影響只要仍限於局部，工程師便保有相應的專業判斷空間。當新的認知開始影響共享工作，知識收斂便正式展開。組織此時要視乎問題波及哪些工作，交由具備相應專業能力和決策權限的角色處理。影響仍限於局部的選擇，則繼續由工程師在獲授予的自主範圍內決定。

## 1. 交付作業內的知識狀態

知識系統會隨交付推進而改變。實際運作時，應把交付開始前已經適用的知識，與期間產生的判斷和新知識分開處理，讓每類資訊都具有與其用途相稱的狀態和權威。

| 知識類別 | 在交付作業中的作用 | 常見例子 |
| --- | --- | --- |
| 現況知識 | 描述產品目前的實際狀態，並為交付作業提供可重用脈絡。 | 產品意圖、架構、介面、領域語義、產品常設要求、管治指示、目前程式碼 |
| 作業規格與決策 | 定義這次作業的預期變更、限制條件、執行範圍、決策權限和驗收條件。 | 功能規格、架構規格、技術規格、已接受的設計決策 |
| 局部實作判斷 | 執行者就刻意留給工程專業判斷的事項作出的決策。 | 輔助結構的選擇、局部演算法、內部命名、採用既有程式庫 |
| 實作所得知識 | 在實作、整合、驗證或審查作業期間發現的新知識。 | 過往未知的依賴、互不相容的假設、反覆出現的實作需要、效能限制條件、尚未作出的架構決策 |
| 作業完成後的現況知識 | 描述作業獲驗收後的產品，並可供後續工作直接使用的知識。 | 更新後的架構、介面文件、共享工程實務、程式碼、經修訂的產品要求 |

這些類別讓不同專業職能繼續按照各自的專業實務作出判斷，同時把足以影響其他工作的部分明確帶入共同交付流程。產品、架構、工程、安全、品質及其他職能都可保留自身的專業深度，而會影響共享工作的知識則取得清楚的狀態和權威。

這些類別彼此相關，而持久共享知識應有多詳盡，則要與決策後果相稱。局部選擇可以留在作出該選擇的實作之內。若要求每項實作選擇都預先寫進規格，知識系統便會累積大量對後續工作價值有限的細節，造成[共享知識系統](/zh-tw/hub/shared-knowledge-system)所述的脈絡膨脹。反過來說，任何已合併的選擇若都直接成為先例，組織便容易累積偶然形成的慣例和彼此衝突的解讀。

例如：

- 一項局部決策可以在程式碼合併後繼續只適用於原有實作。例如，某項實作使用特定格式化工具處理小數值，只要不會影響產品其他部分，便可由該實作自行維持。
- 一位工程師發現的模式，只有在適用範圍和權威延伸至原有實作以外時，才會成為共享模式。某個設計模式可能適合一種情境，而同一產品內的其他情境仍可採用不同做法。
- 實作期間的發現可以啟動架構規格的變更。是否把該項發現確立為架構決策，應由適當的決策負責人決定，例如架構師、工程主管或具明確責任歸屬的團體。

相稱原則同時維持工程自主與組織一致性。[規格優先交付](/zh-tw/hub/specification-first-delivery)讓實作決策只在原有實作內生效，直至其影響開始波及其他工作。

## 2. 局部工程判斷何時影響其他工作

交付作業往往會揭示，幾項最初看似互不相關的決策，其實彼此相連。

假設有四項實作工作，各自交由不同工程師負責，而且全部都需要存取同一個資料庫。規格已定義所需行為、資料庫契約、安全要求和驗收條件，但沒有指定存取程式庫，因為界定交付作業時毋須深入至這個程度。工程師可以按實際實作需要自行選擇。

四位工程師作出不同選擇：

| 工程師 | 實作選擇 | 可能波及其他工作的影響 |
| --- | --- | --- |
| A | 使用 SQLAlchemy | 建立其他模組可能仿效的 ORM 模式 |
| B | 使用 pandas 存取資料庫 | 採用另一種抽象方式，配合以資料處理為主的工作流程 |
| C | 建立共用內部 API | 建議以可重用的應用程式抽象層集中處理資料庫存取 |
| D | 建立獨立服務 | 建議新增一項架構責任和部署單位 |

四項工作可能確實各有不同需要，因此多種實作可以同時成立。真正要判斷的是，這些選擇是否仍然彼此獨立。只要各項實作容易理解，而且沒有為其他工作帶來共用介面、依賴或責任，便可以繼續視為局部工程決策。只有當產品需要更廣泛的一致性時，才應把其中的技術選擇提升為產品整體規則。

當實作開始產生共享影響，團隊便需要重新評估，例如：

- 幾項工作各自解決實質相同的問題；
- 一種做法建立其他工作必須使用的介面或依賴；
- 多項實作同時試圖承擔同一項責任；
- 局部抽象層很可能成為日後工作的先例；
- 新程式庫或服務改變整個產品的營運或架構預期；
- 一項工作建立供其他人或 AI 系統使用的可重用指示；
- 兩項實作選擇在整合時變得互不相容；或
- 實作所得知識顯示，過往只影響局部範圍的問題，現在需要在整個產品內一致處理。

原本只關乎局部實作的選擇，一旦需要多位參與者採用共同解讀，甚至改變既有做法，協調難度便會提高。Carlile 的框架把跨越知識邊界的協調分為傳遞、轉譯和轉化三種逐步加深的要求：團隊先建立共享語法，再處理不同解讀，最後處理因參與者需要改變既有認知或做法而出現的利益差異。[^citation-01]

知識收斂把這個知識邊界問題帶入交付作業生命週期。當實作所得知識開始成為共享技術知識，團隊必須在日後工作把某個答案視為先例之前，先界定它適用於哪些情況、由誰定案、與既有知識有何關係，以及如何同步至受影響的工作。到了這個階段，團隊便發現了一項作業開始時尚未察覺、如今需要共同處理的*技術問題*。換言之，交付已產生足以影響其他工作的重大知識，團隊必須判定它應具備甚麼權威，以及由誰定案。

## 3. 交付期間的知識收斂

當實作所得知識或不同的專業判斷開始對原有決策範圍以外的工作產生重大影響，知識收斂便隨之展開。團隊此時應先釐清各種做法之間的關係，再決定是否讓其中一種成為日後工作的先例。

**在交付期間收斂新知識**



在日後工作開始依賴新知識之前，團隊先提出並評估其影響，交由具備適當權限的角色處理，再把結果同步至受影響的工作。



1. **讓新知識清楚可見**

   記錄實作期間的發現、不同做法、重複知識，以及新近浮現而需要共同處理的技術問題。

2. **判定適用範圍**

   判斷事項是否可以保留在局部範圍，還是會影響其他工作、模組、規格、可重用程序或日後的交付作業。

3. **確認決策負責人**

   把重大問題交由具備相應決策權限和專業責任的角色定案。

4. **釐清彼此關係**

   決定哪些做法只適用於原有實作、是否採用共同做法、如何劃分適用情況、是否取代其中一方，或把問題明確保留為未解決事項。

5. **更新受影響工作**

   如果決策改變其他參與者應採取的做法，便修訂規格、實作工作、可重用知識或現況文件。

6. **驗證收斂結果**

   在驗收前確認，足以影響後續工作的不同解讀，並未演變成彼此衝突的權威來源或偶然形成的先例。

### 3.1. 保留部分局部決策

回到資料庫的例子，團隊可能發現 SQLAlchemy 適合處理交易的應用程式碼，而透過 pandas 存取資料則適合受控的分析流程。合適的結果可以是同時保留兩種做法，並清楚說明各自適用於哪些情況。

關鍵在於團隊理解兩種做法為何並存，並判斷日後工作是否需要知道這項差異。局部選擇通常應在以下情況保留於局部範圍：

- 只影響作出該選擇的實作；
- 另一個合理選擇不會改變產品行為或系統責任；
- 沒有建立共用介面或責任；
- 日後貢獻者無需為保持相容而重複採用該選擇；以及
- 把它記錄為持久共享知識，所增加的維護成本會高於交付價值。

這正是受託自主權應有的運作方式。

### 3.2. 建立共同決策

如果產品多個部分需要採用同一個答案，或某項實作選擇會限制其他參與者，團隊便應建立共同決策。

在資料庫例子中，團隊可能認為應用程式模組應採用同一個共用存取抽象層，否則交易處理、連線管理、可觀測性或可測試性都要重複實作。

決策一經作出，團隊便應在與其影響相稱的層級清楚記錄。視乎實際後果，可能需要新增或更新架構規格、技術規格、產品架構文件、共用實作元件，或其他權威來源。記錄共同決策，是為了讓日後參與者直接找到決策及其適用情況，毋須再從幾項不同實作自行推斷。

### 3.3. 保留未解決問題

部分重大問題在目前交付作業完成後仍可維持未解決狀態，前提是其狀態和後果已經清楚記錄。

團隊可能確認兩種做法目前都有效，也可能認為現有證據不足以把其中一種定為標準，或較大的架構問題應該另行處理。只要日後工作可能誤把某項既有實作當成獲批准的產品整體慣例，團隊便應清楚記錄尚未解決的問題。

例如：

> 兩種資料庫存取模式仍然適用於各自目前的實作。這項交付作業沒有建立產品整體的資料庫存取抽象層。如果日後出現第三個共用使用者，便應重新審視這個問題。

把未解決問題清楚記錄下來，同樣可以形成連貫一致的知識。若幾項實作沒有明言，卻為同一使用案例暗示不同標準，日後參與者便無法判斷哪一種做法具有權威。

## 4. 可重用知識與語義衝突

當交付作業建立可供日後重用的知識，收斂便更為重要。

局部輔助程式只會影響呼叫它的程式碼。可重用 Skill 卻可能影響日後多個 AI 工作階段和工程師，而這些使用者並未參與建立該項知識時的決策。

假設兩位工程師各自發現一個反覆出現的資料庫結構變更問題，並建立兩項 Skills：

```text
skills/
  database-migration/
  schema-change/
```

兩項 Skills 單獨來看都可能有用，當中的指示在技術上也可能完全正確。問題是兩者用途大幅重疊，日後參與者無法判斷應該採用哪一項。這就是**語義不一致**，團隊需要釐清兩項可重用知識之間的關係。

可能的處理結果包括：

- **合併。** 兩者處理同一類工作，應合併成一套持續維護的程序。
- **劃分適用範圍。** 一項處理資料庫結構遷移，另一項處理資料遷移，並清楚區分各自的適用情況。
- **訂明優先次序。** 當指定條件成立時，以較專門的 Skill 取代較通用的程序。
- **有意保留兩者。** 即使部分步驟重疊，兩者處理的問題仍然不同，而且用途足夠清楚，日後參與者可以正確選用。
- **取代其中一項。** 某種做法不應再指導日後交付。

規格優先交付要求共享知識系統足夠清晰，讓合資格的人或 AI 參與者能夠判斷哪些知識適用，以及為何適用。在上述情況中，程式碼儲存庫內的 Skills 和管治指示會影響整個團隊，因此應由團隊共同討論。

> **可以合併不等於知識一致**
>
> 兩項變更即使能順利合併，仍可能留下互相矛盾的指示、用途重疊的可重用程序，或互不相容的架構先例。版本控制處理的是文字層面的整合；知識收斂要求處理的，則是具有重大影響的語義關係。

隨著 AI 程式開發工具日益普及，程式碼儲存庫包含愈來愈多可供機器取用的知識。人類看到兩份文件似乎重複，可能會停下來要求釐清；AI 程式開發代理卻可能直接選用其中一份，按照當刻檢索到的解讀繼續工作。因此，可重用知識需要比局部實作細節更嚴謹的收斂紀律。

## 5. 知識的權威與影響範圍

新知識需要接受多少審查，應取決於它對日後交付的影響範圍。不同組織分配權限的方式各有不同，但核心問題相同：一項知識變更會影響多少日後決策？

| 例子 | 一般影響範圍 | 收斂重點 |
| --- | --- | --- |
| 局部實作選擇 | 單一實作範圍 | 決策是否可以保留在局部範圍 |
| 模組文件或共用元件 | 幾項相關實作工作 | 模組使用者是否獲得一套連貫一致的說明 |
| 可重用 Skill 或程序 | 日後選用或檢索它的工作 | 適用情況、重疊、責任歸屬和維護 |
| 產品整體架構或常設要求 | 多項日後交付作業 | 決策權限、受影響規格和現況知識同步 |
| 管治指示 | 按這些指示運作的貢獻者和 AI 系統 | 誰可以修改界定執行行為和權限的規則 |

知識的影響愈廣泛，就愈需要由相應層級的角色審查和確立，而不應由個別實作工作順帶形成產品整體規則。

> **文件結構應配合產品需要**
>
> 規格優先交付不會訂明單一的文件資料夾結構。產品最初可以只在 `docs/` 下建立幾個檔案，例如 `product-intent.md` 和 `use-cases.md`。當同一個程式碼儲存庫逐漸涵蓋多個元件和大量使用案例，團隊可以按情境整理使用案例，或為計算方法等產品特有資料建立合適結構。文件結構應隨產品知識的增長和查找需要而演進。

### 5.1. 互相衝突的管治指示變更

管治指示特別能清楚反映這項原則。

假設兩位工程師都發現程式碼儲存庫缺少同一項規則。一位認為所有應用程式都應透過共用抽象層存取資料庫；另一位則認為，負責自身資料持久化的模組仍可直接使用 ORM。

兩位工程師都在運用合理的專業判斷，也可能各有充分證據，於是分別提出修改 `AGENTS.md`。如果每項實作工作都可以自行把偏好的答案變成具管治作用的知識，問題便會出現。

如果兩位工程師修改同一行，版本控制的合併衝突可能會揭示這項分歧。這個提示雖然有用，卻只是碰巧出現。他們也可能修改不同部分，令兩項變更順利合併，卻留下互不相容的政策。因此，成功合併並不能證明管治知識已經收斂。

參與者可能發現管治指示並不完整、不切實際，甚至根本錯誤，他們理應可以提出修改。不過，有權執行一項交付作業，不代表同時有權重新定義其他交付作業所依循的指示。

規格優先交付要求按知識變更會影響哪些工作，把建議交由具備相應權限的角色處理。管治指示訂明貢獻者應如何在整個產品、程式碼儲存庫或程式碼庫的指定範圍內工作。因此，這些指示應由具明確責任歸屬的參與者審查並同意，再確立為權威知識。

管治指示的詳細結構、位置、責任歸屬和生命週期，會在後續有關準備和管治程式碼庫的文章中處理。就交付作業生命週期而言，以下這項規則已經足夠：

> **一項實作工作可能會發現管治知識需要修改，卻不會因此自動取得把該項變更確立為權威知識的權限。**

## 6. 把已收斂的知識同步至受影響工作

重大問題解決後，相關決策還要同步至仍受舊有解讀影響的工作，才算真正生效。因此，知識收斂也包括把決策帶到每一項受影響的工作。如果幾項技術實作工作都依賴同一項決策，團隊除了更新其中一位工程師的程式碼，可能還要更新：

- 一份架構規格；
- 一份或多份技術規格；
- 受影響的實作工作；
- 共用介面或元件；
- 驗收條件或測試規格；
- 模組或產品文件；
- 可重用 Skill；
- 已記錄的決策；
- 現況架構或領域知識；或
- 另一個與日後工作相關的權威來源。

具體要同步哪些內容，取決於實際變更。

新發現的局部最佳化可能毋須更新文件。相反，訂明所有模組應如何存取共用資料庫的決策，很可能需要持久的技術或架構紀錄。如果兩項既有 Skills 互相重疊，便要直接協調 Skills 本身。產品常設要求如有改變，也可能牽動幾份規格和驗收條件。

知識系統的價值不只來自文件本身，也來自各項知識來源之間的關係，以及團隊能否更新後續工作真正依賴的來源。在平行交付中，同步的作用，是把經審查的決策及其適用情況帶到每一項受影響的工作。變更一旦足以影響正在進行的工作，團隊便應先按新決策調整相關工作，再繼續實作，以免形成更多互不相容的先例。

## 7. 交付作業完成時的知識收斂

確認實作完成、完成驗證、作出驗收和批准發佈，是四項不同的決策。知識收斂主要關注的是：在交付作業獲驗收並成為產品的新現況之前，哪些知識必須先達致一致。

到了這個階段，所有足以影響後續工作的實作所得知識，都應已有明確處理結果。這些結果可以是：

- 保留為局部實作判斷；
- 納入既有規格或現況知識來源；
- 確立為新的共享知識；
- 與重疊或互相衝突的知識完成協調；
- 記錄為明確的未解決問題；
- 拒絕採用，避免相關做法成為先例；或
- 保留在交付紀錄中，因為其歷史理據日後可能仍然重要。

重點是讓重大分歧有明確的決策權威和處理狀態。

在驗收交付作業之前，具明確責任歸屬的參與者應能判定：

1. 足以影響後續工作的實作所得知識，是否已經提出並在需要時記錄；
2. 影響多項工作的決策，是否已經解決或明確延後；
3. 交付作業期間建立的可重用知識，是否與既有知識重疊或衝突；
4. 架構、要求、介面或其他現況知識的變更，是否已反映在其權威來源；
5. 共同決策改變後，受影響的實作工作是否已經更新；
6. 已被取代的知識是否仍可能誤導日後參與者；以及
7. 合資格的人或 AI 參與者，現在是否能判斷哪些知識是交付後產品狀態的權威依據。

[可信賴交付作業與驗收證據](/zh-tw/hub/trusted-increments-and-acceptance-evidence)說明驗證證據如何支援符合性審查，讓具明確責任歸屬的角色有依據作出驗收決定。知識收斂處理的則是另一項相關問題：組織對即將驗收的系統，是否已有連貫一致的理解。

完成驗收後，仍要區分兩類重要知識。

**現況知識**說明產品目前的實際狀態，並包含日後工作直接需要的架構、要求、介面、領域語義、指示和其他持久知識。

**交付紀錄**保存交付作業如何達到這個狀態，包括重要的替代方案、決策、偏離、證據和未解決問題，讓有用的歷史脈絡得以保留。

現況知識直接說明目前適用的產品狀態；交付紀錄則保留重要決策形成的過程和理據。這樣，日後工作既可直接取得目前適用的做法，也可在需要時追溯重要決策如何形成。

[共享知識系統](/zh-tw/hub/shared-knowledge-system)會更詳細地定義這些知識類別。交付作業生命週期則加入收斂要求：日後參與者應能從權威來源直接判斷哪些知識適用，毋須從最先遇到的實作、Skill、文件或指示自行推斷。

## 8. 與交付作業生命週期的關係

知識收斂貫穿整項交付作業，應在交付期間持續進行，而不是留到最後才當作文件工作補做。

```mermaid
flowchart TD
  accTitle: 交付作業生命週期中的知識收斂
  accDescr: 現況知識和作業規格指導執行。實作產生局部判斷和實作所得知識。團隊在驗收確立下一個現況之前，先處理影響超出局部範圍的問題，並把結果同步至受影響的工作與知識。

  K0[現況知識]
  I[作業規格與決策]
  X[實作]
  L[局部判斷與實作所得知識]
  M{影響是否超出局部範圍？}
  LOCAL[保留為局部判斷]
  R[釐清範圍、權限與關係]
  P[同步至受影響的工作與知識]
  V[驗證]
  A[驗收]
  K1[作業完成後的現況知識]

  K0 --> X
  I --> X
  X --> L
  L --> M
  M -->|否| LOCAL
  M -->|是| R
  R --> P
  P --> X
  LOCAL --> V
  X --> V
  V --> A
  P --> A
  A --> K1
```

因此，這個生命週期包含兩種彼此關聯的控制方式。

第一種是**規格符合性**。實作應符合交付作業中已經審查的意圖、要求、範圍、限制條件和驗收條件。

第二種是**知識收斂**。實作期間產生並足以影響後續工作的知識，需要得到明確處理，讓組織對產品保持一致理解，並讓日後的交付作業可靠沿用。

兩種控制處理不同問題。符合性檢視執行結果是否符合既定決策；收斂則處理組織過往未有一致答案，直至交付揭示其影響才需要共同決定的問題。

設計良好的知識系統會在兩者之間取得平衡。它保存已確立的知識和重大決策，同時保留專業判斷空間，處理尚未需要預先定案的實作問題。知識系統只需完整至足以支援後續責任和決策。專業判斷正是在交付作業的生命週期中面對實際情況、產生新知識，並辨別哪些知識值得持久保存。

## 9. 運作成果

健全的知識系統為合資格參與者提供足夠的共享脈絡、規格、權限和歷史，讓他們既能作出局部決策，也能察覺決策何時開始影響其他人。

知識收斂則為此提供相應的生命週期紀律。

一項判斷只要影響局部，便保留為局部判斷。重複或互相衝突的做法一旦波及其他工作，便要清楚呈現。可重用知識會在形成含糊指示之前完成協調，重大決策由具備適當權限的角色作出，變更則同步至日後工作使用的規格和知識來源。未解決問題也會清楚記錄，不會隱藏在偶然形成的先例背後。

因此，每項交付作業除了改變程式碼，也應加深組織對產品應如何建構和持續發展的理解。可信賴的交付作業完成後，程式碼和知識系統都應準確反映現況，並可供後續工作直接使用。

[^citation-01]: Carlile, P. R. “Transferring, Translating, and Transforming: An Integrative Framework for Managing Knowledge Across Boundaries.” *Organization Science* 15, no. 5 (2004): 555–568. [INFORMS](https://doi.org/10.1287/orsc.1040.0094).