# 規格優先交付 規格優先交付是一套跨職能工程框架。組織把已有知識和各專業職能的判斷寫成規格，讓人與 AI 都能據此可靠地交付軟件。這套框架所處理的，是軟件交付中一個常見問題：重要假設留在會議裏，架構取捨只有少數資深工程師記得，例外情況只由領域專家掌握，驗收要求更可能到實作開始後才逐漸浮現。軟件雖然交付了，日後要理解、維護和繼續改動它所需的知識，卻沒有全部隨成果留下。 一項涵蓋 17 個大型軟件專案的實地研究發現，大型系統設計反覆遇到幾類難題：只有少數人掌握應用領域知識、需求經常變動或互相衝突，以及溝通出現樽頸。[^citation-01] 問題不在於完全沒有知識，而在於作出正確決定所需的內容散落在不同人手上，未必會跟着工作傳到下一位參與者。生成式 AI 令這個弱點更難忽視，因為它能很快按照其中一種理解完成實作，卻不會自動知道組織認可哪一種理解；產品意圖、領域知識、架構取捨、安全要求或營運限制若仍然含糊，AI 便會像新加入團隊的工程師一樣，要麼找出欠缺的脈絡並提出問題，要麼自行猜一個答案，而實作越快，片面的理解也越快變成程式碼。 規格優先交付關注的，正是這個問題背後的組織安排：產品、領域、架構、工程、品質、安全、可靠性與營運職能，以及負責執行的 AI，如何參與同一套交付流程，讓任何一個人或模型都不用代替其他所有人重組其專業判斷。 規格優先交付包含規格驅動開發，也結合了多種既有實務： - 規格驅動開發（SDD） - 跨職能產品交付的管治安排 - 技術專案或產品管理 - 架構決策紀錄（ADR） - 根據證據驗收 - 由人參與重大決策的 AI 軟件工程 因此，這套框架同時涉及軟件工程與組織管理。其他交付基礎文章會分別說明這套模式的主要部分：[共享知識系統](/zh-tw/hub/shared-knowledge-system)界定交付工作會運用並持續更新的知識脈絡；[需求、結構化討論與交付作業](/zh-tw/hub/requirements-increments-and-structured-discussion)說明團隊如何理解交付需要，並把它整理成一項連貫的變更；[交付作業生命週期中的知識收斂](/zh-tw/hub/knowledge-convergence-across-the-increment-lifecycle)探討交付期間形成的專業判斷和實作所得知識；[可信賴交付作業與驗收證據](/zh-tw/hub/trusted-increments-and-acceptance-evidence)則說明團隊如何審查成果是否符合規格，再由具明確責任歸屬的角色根據證據決定是否驗收，從而確立交付後的產品狀態。 ## 1. 既有規格實務為何未能連成完整交付系統 早在生成式 AI 出現之前，需求工程已經以找出持份者需要，並把需要寫成可供分析、溝通和實作的內容為主要工作。[^citation-03] 業務需求、功能規格、架構文件、介面契約、技術設計、測試計劃、操作手冊和驗收條件，本來就是軟件工程常見的工作產物，成熟組織很少只把一個毫無脈絡的構想交給開發人員，要求他們自行補上其餘一切。軟件設計也會不斷產生新知識，團隊在設計途中有所發現，需求隨之改變，各項限制亦逐步說清楚；最後作出的決定及其理據必須連貫地記錄下來，日後的審查、實作和維護才有可靠依據。 然而，這些工作產物往往彼此鬆散，沒有連成一套完整的交付系統，而且仍假定參與者早已了解組織與產品的大量背景。一項需求可能由產品負責人提出，經業務分析師解讀和架構師梳理，再由工程師實作，最後由另一位參與者按照自己對預期成果的理解進行測試。 ```mermaid flowchart LR accTitle: 傳統軟件交付中的逐層解讀 accDescr: 一項需求依次經過產品、分析、架構、工程和驗收，每位參與者都會解讀上一階段傳來的資料。 P[產品意圖] BA[分析] A[架構] E[工程] Q[品質與驗收] P --> BA --> A --> E --> Q ``` 正式文件只記下其中一部分，經驗豐富的團隊會用對話和記憶補上其餘內容。工程師知道遇到不尋常的業務規則要找誰；架構師記得一個看似較簡單的設計為何曾被否決；長期參與團隊的人也看得出，某個奇怪的既有行為其實是必須保留的相容要求。這些非正式做法確實有用，卻依賴懂得相關歷史的人一直在場，還要由他們及時察覺哪段往事會影響目前的變更。軟件組織一直都有規格，真正的限制是規格與相關紀錄未能彼此銜接，仍要靠資深參與者記在腦中的知識，其他人才看得懂；AI 只是加快了片面理解變成實作的速度。這個交付難題早在 AI 出現前已經存在，根源在組織如何傳遞知識與作出決定，而不在工具本身。 ## 2. 先確立交付方式，再選擇工具 現時談論 AI 輔助軟件工程，話題往往由實作層開始，例如程式開發代理、IDE 整合、規劃模式、規格範本、程式碼儲存庫指示、上下文協定、編排框架和多代理工作流程。這些技術固然重要，卻沒有回答更根本的問題：組織希望以甚麼方式交付軟件？ > **實務必須先於工具。** 組織首先要決定，產品意圖如何成為工程承諾、誰有權決定架構、安全和可靠性要求如何進入交付流程、哪些決定可以交給執行者，以及驗收一項變更前需要甚麼證據。這些安排確立後，才適合考慮特定工具如何記錄和取用相關決定。 ```mermaid flowchart TD accTitle: 實務先於工具 accDescr: 組織原則塑造交付實務和工作流程。規格與控制措施表達這些實務，工具則實作和取用它們。 O[組織原則] P[交付實務] W[工作流程] S[規格與控制措施] T[工具] O --> P --> W --> S --> T ``` 不少團隊從工具入手，先提出「我想建立一個代理」，再按照工具預設的運作方式設計流程，結果讓工具反過來決定組織怎樣交付軟件。工具一變，做法便要跟着變；又或者，組織只能另找一套工具，勉強維持一個從未獨立說清楚的流程。規格優先交付則先確立交付方式，把工具視為落實這套方式的最後一環。工具正在迅速演進，AI 大幅降低了執行成本，卻沒有減少對產品、領域、架構、安全與工程判斷的需要；執行越快，關鍵決定含糊不清的代價反而越高。 規格可以放在 Markdown、文件平台、議題管理系統或專門的規格服務，AI 程式開發工具則可以透過程式碼儲存庫脈絡、檢索、API、自動產生的提示，或日後出現的其他機制取用規格。這些都是實作選擇，不會界定框架本身；成熟組織即使更換工具，也無須重新摸索軟件決策應由誰作出、如何作出，只需隨工具演進調整平台之間的連接方式。執行越快，組織越要及早分清楚哪些事情必須先定案，哪些可以放心交給執行者判斷。AI 令執行成本下降，專業判斷卻沒有因此變得廉價。 ## 3. 軟件交付需要哪些知識 人們通常用程式碼、系統、服務、介面、資料和基礎設施來描述軟件，但任何重要的軟件系統都依賴一些無法單憑原始碼可靠重建的知識，包括產品意圖、領域概念、業務規則、架構、安全要求、系統要如何應付故障、資料含義、營運經驗、介面責任、被否決的方案和過往作出的妥協。有些可以從實作看出來，很多卻不行。 交付知識往往先存在於個人經驗之中，組織把它記錄在持久而且可供各方查閱的來源，後續工作才用得上。AI 帶來的改變，是當產品意圖、架構理據、限制或營運知識已經寫清楚，並且知道哪個來源可以作準，工程師和 AI 都能直接重用，毋須一再請人解釋、重新發掘，或臨時改寫成只用一次的指示；這些知識亦可直接規範執行。[共享知識系統](/zh-tw/hub/shared-knowledge-system)會進一步說明組織應如何整理和維護這些知識。 規格優先交付把上述組織安排帶進工程流程。知識是規格的原料，參與者透過討論、分析和專業判斷作出決定，寫明哪些要求必須成立、哪些內容可以改變、工作要遵守甚麼限制、誰有權決定，以及最後如何判斷成果；規格經過審查後，本身也成為組織知識，而實作又會產生程式碼、獲接受的偏離、測試證據、營運觀察和其他經驗，其中重要的內容應留給日後工作使用。 ```mermaid flowchart TD accTitle: 規格優先交付的知識循環 accDescr: 既有知識與目前需求經過專業討論，成為經審查的規格。執行產生程式碼、決策、證據和新知識，再納入組織知識。 K[既有組織知識] R[目前需求] D[討論與專業判斷] S[經審查的規格] X[執行] E[程式碼、決策、證據與新知識] K --> D R --> D D --> S K --> S S --> X X --> E E --> K ``` 這個循環是規格優先交付的核心。文件本來就是工程工作的一部分，與其他工程活動一同進行：知識塑造規格，規格引導實作，實作又改變組織對產品的了解，新的知識再於同一次交付中記錄下來。 保存資訊只是第一步，更難的是決定哪個來源可以作準。待辦項目可能與架構決策衝突，既有程式碼可能保留已過時的行為，測試可能把產品負責人現在想改變的舊假設固定下來，最近一次會議作出的決定也可能尚未寫入後續規格；提供更多上下文，可能只會讓 AI 看到更多互相矛盾的資訊，卻仍不知道哪一項才算數。因此，規格優先交付要求規格同時交代責任和權限：每項重大決策都要有明確的決策負責人、可作準的來源、清楚的適用範圍，以及日後修改時要依循的審查程序。遇到衝突時，處理方法有兩種： - 適用來源和優先次序已經明確，AI 程式開發代理便依照既定規則處理；或 - 交由適當的決策負責人確認，再把結果寫入後續工作可使用的知識來源。 這樣，人與 AI 都能直接根據交付所需的知識行動，不必每次重新拼湊組織意圖。 ## 4. 規格應在執行前回答哪些問題 一份有用的規格，會回答那些足以影響成果、又不應留給下一位參與者猜測的問題。若一份規格沒有釐清任何重要事項，便沒有另寫一份的必要；後文會再以相稱原則說明應寫到多詳細。以加入一項新的產品行為為例，在需求進入實作之前，可能需要回答幾類本質上不同的問題： 1. **產品負責人** 確定真正需要的成果，以及哪些看似相關的需求其實不屬於範圍。 2. **業務分析師或領域專家** 釐清業務規則、術語、例外情況和無效狀態。 3. **架構師** 決定系統責任應放在哪裡、哪些介面可以改變，以及實作必須遵守哪些架構限制。 4. **安全職能** 定義誰可以執行某項操作，以及需要哪些控制措施。 5. **可靠性專家** 說明系統失敗時應有甚麼行為、如何復原，以及需要哪些可觀測性訊號。 6. **品質專業人員** 確定哪些證據足以證明預期行為在相關流程中正常運作。 這些問題各自需要不同的知識、經驗和決策權。技術規格交到工程師或 AI 程式開發代理手上時，重大事項應已釐清，執行者要知道變更應達成甚麼、工作受哪些限制、哪些內容必須保留、如何驗收，以及哪些實作決定可以由自己作出。 > **規格優先交付讓各領域專家和工程師在實作中繼續運用專業判斷。** 工程師仍會選擇演算法、抽象方式、局部結構、命名、實作技術，以及其他已交由工程職能判斷的細節；AI 程式開發代理也可以有相近的實作空間。與同一項交付作業有關的各份規格，合起來便是**規格體系**。 規格體系是一張依賴圖。不同規格需要不同輸入，一份規格又可以成為另一份的依據，直到各項決定匯聚成可以執行的技術規格。功能、架構、安全、可靠性、資料和整合規格若沒有先後依賴，可以同時準備；每一類規格回答不同問題，也會限制其他規格的選擇，或令原本未察覺的問題浮現。例如，架構和安全規格尚未完成時，功能規格仍可先描述系統應有的行為；其後，一項安全限制可能令部分原定功能無法成立，一項架構選擇可能帶來新的可靠性要求，測試亦可能揭示從未寫入規格的例外處理。 ```mermaid flowchart TB accTitle: 規格構成相互連結的決策圖 accDescr: 產品、架構、安全、可靠性、工程與驗證規格會按彼此的依賴和回饋共同發展，毋須依循固定的階段順序。 D[討論與待決事項] F[功能規格] A[架構規格] S[安全規格] R[可靠性規格] T[技術規格] I[實作] Q[整合與驗收規格] D --> F D --> A D --> S D --> R F --> T A --> T S --> T R --> T F --> Q S --> Q R --> Q T --> I Q --> I I -. 實作發現 .-> D Q -. 缺漏或衝突的需求 .-> D D -. 修訂後的決策 .-> F D -. 修訂後的決策 .-> A D -. 修訂後的決策 .-> S D -. 修訂後的決策 .-> R ``` 每項變更所需的規格並不相同。小型變更可以由討論直接進入技術規格，大型變更則可能需要多類專項規格；關鍵是先回答那些不應留給後續參與者猜測的重要問題。交付期間若發現尚未釐清的問題，誰有權解決取決於問題涉及哪一類決定，而不取決於它在哪個階段被發現：若屬於已交給執行者的實作決定，工程團隊可以直接處理；若會改變正式確認的產品行為、架構、安全、可靠性、資料含義或驗收條件，便要重新審議相關規格，交由負責該事項的角色決定。 AI 參與交付時，這一點尤其重要。AI 很擅長為不完整的問題產生看似合理的答案；若欠缺的只是已交由它處理的實作細節，這項能力十分有用，但若模型既沒有足夠脈絡，也未獲授權，卻在不知不覺間替組織作出重大決定，風險便會出現。上游已經釐清的事情，無須再由之後每位工程師、供應商、維護人員或每次 AI 工作階段重新摸索；經審查的規格讓組織作出一次重大判斷，便能在後續交付重用，讓之後的參與者專注於新的決定，而不是反覆拼湊舊有決定。 ## 5. 讓各職能直接提供其專業判斷 軟件工程師愈來愈常被要求涉獵廣泛：理解產品脈絡和業務領域、設計系統架構、處理安全問題、編寫和測試程式碼、營運生產系統、與使用者溝通，現在還要協調 AI 代理。前線交付工程師等角色，正反映了這種趨勢。工程師需要了解軟件開發所處的整體脈絡，各專業職能也不能只看自己的部分，不過廣闊視野不能取代專門經驗和相應的決策權： - 工程師即使懂得從產品角度思考，也不會因此具備產品負責人的領域知識、客戶脈絡、經驗和決策權。 - 工程師熟悉一般安全原則，仍不等同安全專家。 - 架構師需要了解可靠性和品質，營運或測試決定仍各有其負責人。 「全能開發者」或英雄式工程師看似把更多能力集中在同一角色，簡化了組織，實際上往往只是把組織尚未處理的難題推給工程師。不完整的需求、未記錄的決定、各專業職能的考量和互相衝突的假設，最後都要由工程師自行整合；組織沒有定案的事情，也由工程師補上答案。AI 令這種安排更具吸引力，有能力的工程師現在可以利用 AI 研究陌生領域、草擬安全考量、產生測試、比較架構方案和探索產品問題，單一工程師看似可以涵蓋更多工作，但他獲授予的決策權和本身的專門經驗不會隨之增加。工程師可以利用 AI 更快了解安全問題，重大安全決定仍應由適當的負責人作出；AI 也可以協助產品經理探索架構方案，架構決策仍然屬於架構職能。 規格優先交付把不同角色的專業深度連接起來。Faraj 與 Sproull 將「協調專業知識」解釋為知道專業知識掌握在誰手上、何時需要，以及如何讓所需專業真正參與工作；他們的研究亦發現，團隊越能做到這幾點，表現通常越好。[^citation-02] 規格優先交付在此基礎上提出一項明確責任：經驗、知識和能力必須連到它們所支援的決定，而且每項重大決定都要知道由誰負責。 AI 程式開發工具可以協助各職能把專業判斷直接帶入交付：產品決定寫成規格，繼而塑造產品行為；架構判斷說明系統由哪些部分負責，以及實作受甚麼限制；安全與可靠性要求從一開始便影響技術規格；品質要求則在工作完成前已寫入驗收條件。工程師仍然不可或缺，他們會質疑規格、判斷技術影響、實作已確認的決定，並依據經審查的要求建立技術上可靠的成果；其他職能直接提供自己負責的專業判斷，工程師便毋須在沒有授權的情況下代為重建。 參與程度要與工作相稱。低風險的局部變更毋須召集組織內所有職能，原則很簡單： > **一項變更若需要重大的專業判斷，便應由適當而且對該事項負責的角色提供，讓執行者毋須自行猜測。** ## 6. 人與 AI 如何分工和行使權限 AI 程式開發代理已經不只是程式碼補全工具。它可以接收上下文、解讀需求、提出方案、實作變更、編寫測試、更新文件，也可以參與審查，因此已是交付流程中的實際參與者。與此同時，重大決策和成果仍要由具名人員負責，人與 AI 的角色必須分清楚。 人與 AI 有一項關鍵差別：每次開始新的 AI 工作階段，都像迎來一位能力很強、卻幾乎沒有組織記憶的新同事。它可以迅速分析整個程式碼儲存庫，卻不會自動明白組織過往為何作出某些選擇。 > **AI 每天都是你的新同事。** 模型可能不知道，某個看似笨拙的實作之所以存在，是因為更簡單的架構曾經在生產環境失敗；也可能不知道，持份者六個月前已明確否決某個替代方案、某項不尋常的業務規則只適用於特定客戶群，或某個既有測試所保留的行為已被組織視為過時。大型上下文視窗讓模型看到更多資訊，卻不會賦予它決策權，也不會自動解決矛盾或分清哪些行為源於刻意設計，哪些只是歷史偶然，而且無論對大型語言模型還是人而言，能夠集中處理的資訊始終有限。規格優先交付因而為人與 AI 提供同一套交付系統，在執行前把重大決定寫進規格並保存下來。 **共享交付系統: 從組織意圖到可信賴交付** 1. **探索需求** 在實作前找出模糊之處、假設、選項、風險和待決事項。 2. **記錄決策與責任歸屬** 記下已作出甚麼決定、由誰負責、哪些問題仍未定案，以及哪些來源可以作準。 3. **建立經審查的需求規格** 對有實質影響的事項，明確說明產品行為、領域含義、架構、安全、可靠性、介面和驗收期望。 4. **產生可實作的技術規格** 把經審查的要求寫成範圍清楚的工作，列明依賴、限制、可由執行者決定的事項和必須保留的行為。 5. **在獲授權的範圍內執行** 人與 AI 按照已同意的範圍執行；遇上重大模糊之處時升級處理，而不是自行改寫工作內容。 6. **以證據驗收** 根據規格驗證實作，並把重要決策、偏離、程式碼和證據保存為持久的組織知識。 規格系統保存討論和決定，讓後來加入的同事，包括 AI 程式開發代理，都可以查閱。產品探索、設計討論、架構辯論、實作回饋和審查仍然有必要，會長期影響交付的決定則要在對話結束後繼續留存；規格亦不會代替專業判斷，而是記下哪些事情已定案、哪些仍未決定，以及下一位參與者可以在哪些地方運用自己的判斷。 這樣，AI 可以自主處理甚麼便不再是抽象爭論，組織可以直接列明代理的工作範圍和決策權。執行者可以自由選擇實作方式，卻無權改變產品行為；可以重構元件，卻無權擅自增加系統之間的依賴；也可以產生測試，卻無權重寫由相關負責人訂立的驗收條件。這就是**受託自主權**：執行者在明確範圍內自行決定和行動，遇到範圍以外的重大事項時，則交回適當的負責人處理。 ## 7. 組織如何運作規格優先交付 對單一變更而言，規格優先交付與常見的工程流程相似：定義需求、準備所需規格、執行工作，再驗證結果。到了整個組織的層面，它還要說明權限如何行使、資訊和專業知識如何傳遞、哪些事情可以交給執行者，以及最終由誰負責，其中三方面尤其重要：權限、授權，以及組織能否在參與者轉變後繼續交付。 第一是**權限**。軟件交付涉及多類決定，產品行為、架構、安全控制、營運風險和實作細節各有負責角色，不會因為某位參與者先提出意見便由他說了算。有效的交付系統要說清楚誰可以決定甚麼，以及決定經過甚麼程序後可以作準。 第二是**授權**。傳統管理容易走向兩個極端：一端緊盯實作細節，資深工程師或管理人員因每項決定都要檢查或批准而成為樽頸；另一端只向團隊或 AI 代理交代預期成果，重要限制則留給執行者在工作途中自行發現。規格優先交付先由相關職能運用專業判斷，把工作範圍、限制、各項決定由誰負責和如何驗收說清楚，再讓執行者在這個範圍內自行選擇實作方法。隨着 AI 程式開發代理承擔更多實作工作，交付團隊可以**細緻管理規格，而非程式碼**：團隊先透過規格回答重大問題，界定代理可以處理的範圍，再細緻審查那些會塑造實作方向的決定，具備足夠能力的代理便能在已授權的範圍內完成實作。 第三是**持續交付的能力**。如果組織意圖和技術理據主要存在個人記憶之中，每次人員變動都會令團隊失去一部分原本已有的脈絡，新參與者不只要了解程式碼，還要重新發掘背後的理據。共享規格系統能減少組織對個人記憶的依賴。 ```mermaid flowchart LR accTitle: 跨職能規格優先交付價值鏈 accDescr: 具明確責任歸屬的專業職能把判斷帶入共享規格系統，由它引導人與 AI 執行、驗收，以及形成日後可重用的組織知識。 P[產品] D[領域與分析] A[架構] S[安全] R[可靠性] E[工程] Q[品質] O[營運] SPEC[共享規格系統] X[人與 AI 執行] V[證據與驗收] K[組織知識] P --> SPEC D --> SPEC A --> SPEC S --> SPEC R --> SPEC E --> SPEC Q --> SPEC O --> SPEC SPEC --> X X --> V V --> K K --> SPEC ``` 規格系統是共享知識系統的重要部分，把可以作準的意圖、限制、決定和驗收要求連到實際執行。即使更多工作由系統自動完成，責任仍然清楚；AI 可以承擔更多實作，卻不會因此取得組織從未授予它的決策權。 ## 8. 規格詳略要與工作相稱 一套框架必須能幫助實務工作者面對具體工作時作出決定。規格優先交付涵蓋從最初要求到變更獲得驗收之間的各項做法，包括如何探索需求、選擇適用的規格、讓相關專業職能參與、記錄權限、界定實作範圍、處理偏離，以及準備驗收所需的證據。 1. **原則** 關於責任歸屬、權限、規格、執行、證據、持續交付能力，以及不受特定工具限制的基本規則。 2. **規格類型** 功能行為、架構、安全、可靠性、資料語義、技術工作、整合行為和驗收證據可採用的規格形式。 3. **工作流程** 把模糊要求逐步整理成經審查的規格、可執行的工作、經驗證的成果和可供日後使用的組織知識。 4. **角色責任** 說明產品、分析、架構、工程、品質、安全、可靠性、營運和其他具明確責任歸屬職能應提供哪些專業判斷。 5. **管治** 有關責任歸屬、權限、優先次序、修訂、重大偏離和驗收的規則。 6. **專業能力** 專業人員要在規格優先交付價值鏈中有效貢獻所需具備的能力。 這些做法不受特定工具限制。共享知識系統可以採用文件儲存庫、知識圖譜或其他合適技術，重點是人和 AI 程式開發代理都能穩定地找到並正確理解當前工作適用的知識和程式碼。程式碼儲存庫中的 `docs/` 目錄若能做到這一點，也是一種合適的實作方式。 規格要寫到多詳細，應視乎工作還有多少重大疑問、是否涉及新的做法、有哪些依賴、風險有多高，以及出錯會帶來甚麼後果。把兩行文字的變更寫成二十頁流程，就是**規格過細**。以下做法都可以符合規格優先交付： - 小型文字修正，可能只需要一項清楚指示、小幅實作變更，以及確認相關文件仍然一致；它未必需要為知識系統加入任何新內容。 - 一般功能可能值得先建立功能規格，再建立一份或多份技術規格。 - 如果變更涉及敏感資料、複雜整合、重大安全風險、重要的可用程度要求或不可逆轉的遷移，則可能同時需要架構、安全、可靠性、資料和整合規格。 **規格不足**會默默把尚未解決的問題推給後續參與者；**規格過細**則花時間預先決定本來可以放心交給執行者的細節，還可能令提供給人或 AI 的上下文過多，反而妨礙理解。兩者都會拖慢交付。合適的規格會在執行前回答足以影響成果的問題，並把合理的實作判斷留給執行者。因此，衡量一個成熟的規格優先組織，要看其規格能否令交付更可靠、責任更清楚、工作更容易理解，並可按相同準則再次進行，而不是把規格數量當成關鍵績效指標（KPI）。 ## 9. 規格架構師如何連接不同專業 規格優先交付改變了專業判斷進入交付流程的方式，也因而要求實務工作者具備相應能力。這套框架把能夠說清楚本身專業判斷，讓其他參與者直接用於交付的人稱為**規格架構師**。這是一種不限職能的能力，並不要求具備軟件工程背景。 產品負責人若能說清楚產品意圖、取捨、範圍和各項決定由誰負責，便是在運用規格架構師的能力；業務分析師可以把領域知識和業務行為寫成精確的功能規格；架構師則把系統結構方面的決定、介面、依賴和限制整理成實作團隊可以直接採用的內容。工程師指出模糊之處和欠缺的上游決定，把經審查的要求寫成可執行的技術規格，並判斷哪些技術選擇應留給實作者，也是在運用同一套能力；安全、可靠性、品質、營運和其他專家亦會在各自範疇做相同的事。他們的共同點，是懂得整理和表達專業判斷，讓其他人可以據此工作，因此可以統稱為**規格架構師**。 規格架構師要看得出，一個表面上的實作問題何時其實是尚未解決的產品或架構決定；也要分清楚哪些要求可以作準、哪些只是有用的背景資料，找出可能令後續參與者一再猜測的假設，並在不過分指定實作細節的前提下說清楚各項限制。他們也要懂得利用 AI 探索其他方案、檢查規格是否完整、找出含糊之處和加快執行，同時明白模型回答得多有信心，也不代表組織已授權它作出決定。 > **補充觀察** > > 規格優先交付的核心，是把意圖、權限、限制和驗收要求說清楚，只要人們要合作交付複雜軟件，這些做法便有價值。AI 參與交付時，善用 AI 也成為專業能力的一部分，實務工作者必須知道 AI 可以執行甚麼，以及哪些事情仍要由組織自行決定。 規格架構師要把交付鏈不同位置的決定連接起來，讓產品意圖仍可從功能行為中辨認，架構決定確實影響技術工作，安全和可靠性要求落到實作與測試，而驗收證據也能追溯至最初界定工作的要求。實作若發現規格不完整或有錯，團隊要按適當的決策程序提出質疑和修訂，因此，**規格架構是一種分布在不同專業角色之間的能力**。 規格優先組織需要不同專業範疇的人都具備這種能力，直接參與交付，並把自己的知識說得足夠清楚，讓其他人和 AI 可以據此行動。若由一個人編寫或掌管所有規格，所有解讀又會集中在同一人身上，重現框架要解決的問題。 ## 10. 人員與工具更替後，組織仍要能繼續交付 規格優先交付最終要做到的是**組織交付能力延續**：即使人員、團隊、供應商、模型和工具有所更替，組織仍保留足夠知識、清楚的權限安排和決策歷程，可以繼續交付並改進軟件。軟件系統往往比設計它的團隊存在得更久，產品負責人、架構師、工程師和領域專家會轉往其他專案或離開組織，供應商、AI 模型、開發工具和組織架構也會改變；時間一久，一項服務可能由從未接觸原始設計團隊的人維護。 若沒有持久的交付知識系統，人員更替會帶來兩種損失：組織會失去離職者日後本可作出的貢獻，也可能失去本應早已留在組織內的知識。前一種無可避免，後一種則可以避免。新參與者當然要花時間了解陌生系統，但這個過程不應變成「組織考古」；若沒有人能說明哪些決定是刻意作出的、現在哪個來源可以作準，新參與者便只能翻查舊待辦項目、聊天紀錄、原始碼和未有記錄的既有行為。AI 令這個問題更常出現，因為每次開始新的代理工作階段，都像再有一位新參與者加入。 具備相應專業能力的新參與者，應能判斷哪些行為是刻意保留的、哪些限制仍然適用、未決事項由誰負責、重大選擇當初為何作出、驗收依據了甚麼證據，以及現在哪些地方需要新的專業判斷，而不用先重建組織的整段決策歷程，才能了解系統本來應該做甚麼。經驗豐富的工程師、架構師、產品負責人或領域專家離開，組織仍會失去任何規格系統都無法完整保存的專門知識、人際關係、直覺和未來判斷；規格優先交付要保住的，是那些本應早已屬於組織的知識，避免它們跟着個人離開。 這就是規格優先交付所說的**組織交付能力延續**。知識系統必須與軟件一起交付。以往的實務標準可能只問必要文件是否存在；有了 AI 程式開發代理後，我們可以提出一個更嚴格的測試： > **AI 程式開發代理能否在毋須猜測任何重大事項的情況下，開始處理新的交付作業？** 如果每次啟動新的 AI 程式開發代理工作階段，都要由資深工程師再講一次同樣的架構歷史、限制和例外情況，知識系統便仍未真正融入交付，組織依然靠個人記憶串連一切。因此，組織能否延續交付能力，也是檢驗框架是否有效的實際標準：規格系統即使產生大量文件，若合資格參與者仍然不知道哪個來源可以作準、系統為何以現有方式運作，或自己獲准改變甚麼，這套系統仍未發揮作用。 有效的規格優先系統，會把所需查證控制在與當前問題相稱的程度：參與者要看足夠資料，才能理解問題並作出新的專業判斷，卻毋須重新考古，完整重建過往所有決定。 ## 11. 結論 規格優先交付所描述的軟件交付，是先匯集分散在組織各處的知識和專業判斷，寫成可以可靠指導工作並接受審查的規格，最後交付可信賴的軟件。規格一直是軟件交付的一部分，只是過往往往彼此割裂，整套交付方式仍高度依賴非正式溝通和個人記憶；AI 令這個問題更明顯，因為實作可以快到組織尚未察覺某項假設從未釐清，程式碼已經寫好。 規格優先交付讓每個職能直接提供自己負責的判斷，再以與工作相稱的詳略寫進規格。工程師和 AI 在清楚的權限範圍內選擇實作方法，驗收證據則把成果連回組織原本的意圖；交付期間作出的決定和取得的新知識，最後再納入組織的知識系統。即使未來的 AI 模型能力大幅提升，這項需要也不太可能消失，因為 AI 不會自動知道一個組織如何運作、承擔了哪些合約責任，或一個開發專案經歷過甚麼。 知識、規格與程式碼因而形成一個循環：組織以已有知識為基礎寫成規格，讓與當前工作有關的內容可以直接指導行動；實作產生軟件和證據，過程中作出的決定再成為下一次交付可以使用的知識。這個循環也解釋了，為何規格優先交付既是一套工程框架，在組織層面也是一種軟件交付的運作模式；它不只說明工作應如何描述，也說明權限如何行使、各職能的專業判斷如何連接、哪些工作可以交給執行者、成果如何驗收，以及人員和工具更替後如何繼續交付。 AI 令這些問題變得更迫切，問題本身卻早已存在。如今，許多組織正承受過往沒有記錄決定和歷史所累積的技術債。任何負責建立軟件的組織，都需要一套可靠方法，把已有知識、已作決定和各專業人員的重要判斷，帶進最終由組織擁有的軟件。 [^citation-01]: Curtis, B., Krasner, H., and Iscoe, N. (1988). *A Field Study of the Software Design Process for Large Systems*. *Communications of the ACM*, 31(11), 1268–1287. [doi.org](https://doi.org/10.1145/50087.50089). [^citation-02]: Faraj, S., and Sproull, L. (2000). *Coordinating Expertise in Software Development Teams*. *Management Science*, 46(12), 1554–1568. [doi.org](https://doi.org/10.1287/mnsc.46.12.1554.12072). [^citation-03]: Nuseibeh, B., and Easterbrook, S. (2000). *Requirements Engineering: A Roadmap*. *Proceedings of the Conference on the Future of Software Engineering*, 35–46. ACM. [doi.org](https://doi.org/10.1145/336512.336523).