角色指南 # 每個角色都直接參與工程成果的交付。 在規格優先交付中，你不是直接交付產品，就是協助交付支撐產品的知識系統。兩者必須一同演進：知識、決策、限制與證據持續與產品保持一致，並在整個交付過程中供人與 AI 程式開發代理使用。 ## 產品知識系統 知識可以存放在不同位置，但其權威和可存取性不能含糊。它為每位參與者和 AI 程式開發代理提供可長期使用的共享變更脈絡。 - 意圖 - 知識 - 成果 ## 技術長／工程主管 設計組織與交付架構，把可信賴的軟體交付變成可重複的組織能力。 熟悉的交付日常 ### 身為技術長或工程主管， 你需要把日益加快的 AI 輔助工作，轉化為可靠的組織能力，而不是讓所有重大問題最後都要由你親自處理。 常見情況: 一天通常由交付指標、AI 採用情況和優先事項開始，儀表板看起來一切清晰。實際上，資深工程師仍在對話中補上系統歷史、責任和限制，而你需要決定哪些專業判斷必須成為組織長期保留的交付條件。 #### 設定能力與風險方向 你在不斷變化的環境中，為架構、團隊、投資、AI 採用、可靠性與管治排定優先次序。 #### 依靠分散訊號管理 路線圖、交付指標、事故、審查和團隊報告顯示大量活動，卻很少說明具責任歸屬的決策是否真正進入執行和驗收。 #### 透過升級處理介入 當交付放慢、工作互相衝突或正式環境風險已經上升時，你才發現責任不清、脈絡流失、工作範圍不當或限制不明確。 現行流程的結構性問題 ### 為甚麼局部速度不能自動變成可靠的組織交付能力。 決策權、脈絡與證據散落各處，令組織無法把個別團隊的活動轉化為整體可以信任的交付能力。 #### 交付依賴少數人的脈絡 有經驗的人長期填補組織記憶的缺口；當團隊或優先事項改變時，他們便成為瓶頸和組織交付能力延續的風險。 #### 管治與執行彼此分離 領導決策、工程標準和審查要求，沒有在團隊與 AI 代理實際作出變更的位置一致出現。 #### AI 會放大不均衡的運作模式 實作速度提升，既會放大有價值的工作，也會放大決策權不清、工作範圍定義不足和證據不完整的後果。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 定義責任清晰的交付系統 讓產品、工程、品質和營運之間的責任歸屬、決策權限、必要脈絡、審查路徑、驗收責任與驗收條件清楚可見。 #### 把運作模式帶進實際工作 確保規格系統、程式碼儲存庫指引、工作範圍和證據要求，能按任務需要為團隊和 AI 代理提供脈絡，並清楚訂明責任歸屬與審查控制。 #### 以證據和經驗改善管治 利用可追溯的交付證據、偏差、事故和重複問題改善組織能力，而不是依賴逐級升級處理或個人英雄主義。 ## 產品負責人 負責產品價值、優先順序與範圍，並判斷交付行為是否值得驗收。 熟悉的交付日常 ### 身為產品負責人， 即使 AI 能迅速把簡短需求變成實作動力，你仍須為這項變更是否創造正確價值負責。 常見情況: 持份者提出改進要求，你釐清預期成果、取捨與急迫程度。其後，需求變成待辦項目、提示和一連串交付活動，而原本令這項變更值得投入的理由，逐漸變得難以追溯。 #### 界定需求 你與持份者釐清預期成果，但相關對話往往只留下片段紀錄。 #### 決定優先順序 你作出範圍與取捨決定，再把它們寫成待辦項目，交由後續工作解讀。 #### 檢視結果 你通常要到較後階段才看到實際行為，此時再修正假設或遺漏，成本已經很高。 現行流程的結構性問題 ### 為甚麼具責任歸屬的產品決策愈到後期愈難找回。 當產品決策、實作工作和驗收證據彼此分離，要重新找回一項變更原本要創造的價值，便會變得昂貴而緩慢。 #### 產品價值被壓縮成一張工作單 需求背後的成果、非目標和取捨，容易在簡短的實作摘要中消失。 #### 驗收來得太晚 團隊已經按某種理解投入開發後，你才需要判斷結果是否真正創造價值。 #### AI 加速了未經驗證的假設 實作愈快，模糊的產品決定便可能傳得愈遠，直至有人提出質疑。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 清楚表達預期成果 記錄要解決的問題、預期價值、優先順序、非目標，以及影響變更的重要決定。 #### 共同訂立可觀察的驗收條件 與分析、工程和品質角色合作，在執行前訂明正常與例外結果應如何被驗證。 #### 憑可追溯證據驗收 檢視預期價值是否實現、已同意的工作範圍是否獲遵守，以及預期行為是否獲保留。 ## 產品經理／計劃經理 連結產品或計劃成果、相依關係、先後次序與交付決策。 熟悉的交付日常 ### 身為產品經理或計劃經理， 你需要維持一條由預期成果和相依關係通往實際交付的可信路徑，但 AI 產生的更新可能令活動看起來比背後的決策更清晰。 常見情況: 計劃畫面看起來令人安心：工作持續推進、摘要保持更新、各團隊亦有目標日期。然而，在這些訊號之間，未決問題和相依假設仍在會議中浮現，你需要再次把原定成果連回已經進行中的工作。 #### 協調優先順序與相依關係 你透過交付計劃協調工作、團隊、日期與風險，但計劃通常未能承載完整的產品與工程理由。 #### 升級處理不確定性 當未決事項在例會或進度更新中浮現時，往往已經影響工作次序。 #### 追蹤交付訊號 活動和進度清楚可見，卻不容易判斷已完成的工作是否仍然服務原定成果。 現行流程的結構性問題 ### 為甚麼進度訊號不能證明團隊正在交付正確的作業。 如果成果、相依關係、決策權和證據沒有連結，活動量再清楚，也不能證明正在交付正確的作業。 #### 計劃狀態掩蓋決策質素 里程碑看似健康，但關鍵的產品、架構或相依決定可能仍未解決。 #### 相依關係失去實際含義 相依關係只被記錄成日期或負責人，卻沒有說明它所保護的介面、假設或能力。 #### 進度不等於驗收證據 已回報的進度，不能證明產品與其知識系統仍然保持一致。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 把成果連結至交付決策 由倡議意圖一路連結至相依關係、範圍選擇與具責任歸屬的負責人，讓決策路徑保持清晰可見。 #### 安排範圍清晰的工作 根據明確限制和未決問題安排先後次序，而不是要求團隊猜測交付計劃背後的隱藏假設。 #### 以符合性證據引導交付 以證據說明預期行為是否實現、限制是否獲遵守，以及哪些風險仍未解決，而不是只根據活動量引導交付。 ## 業務分析師 讓業務規則、領域語意、決策、例外與可追溯性直接用於交付。 熟悉的交付日常 ### 身為業務分析師， 你負責把軟體所依賴的領域語意說清楚，但 AI 可以迅速把不完整的理解變成表面合理的系統行為。 常見情況: 一次對話揭示了看似簡單規則背後的重要例外，你需要從持份者和既有材料追查真正含義。實作開始後，工程師與 AI 代理同樣需要這項區分，但它可能仍只存在於工作坊筆記、聊天紀錄或你的記憶中。 #### 整理領域知識 你從對話和既有材料辨識規則、術語、例外，以及持份者作出的決定。 #### 描述功能行為 你把知識整理成需求或流程工作產物，但工程團隊仍要把它重新放回實際的系統脈絡中理解。 #### 在實作期間反覆澄清 問題透過會議和訊息不斷回流，令同一項業務決定逐漸出現多個版本。 現行流程的結構性問題 ### 為什麼業務規則與例外總要被重新找回。 領域知識散落在不同地方，每次澄清都要重新拼湊，也令互相矛盾的理解長期存在。 #### 規則與實作脫節 對業務重要的精確語意，未必會出現在工程師或 AI 代理實際修改軟體的位置。 #### 例外在後期才曝光 重要例外情況留在專家記憶中，直至測試、事故或持份者審查時才被發現。 #### 可追溯性依賴人手維護，容易斷裂 決策歷程沒有與其所規範的規格和程式碼放在一起，團隊只能事後拼湊某項行為存在的原因。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 建立具明確權威的領域知識 讓規則、術語、來源、例外與未決問題可以被檢視，並清楚標明責任歸屬。 #### 訂明行為與決策邏輯 以人與 AI 都能直接使用的形式，描述正常流程、例外、資料語意和驗收條件。 #### 維持可追溯的變更 把已交付行為更新至知識系統，令決策理由與領域語意長期保持一致。 ## 開發主管 把已同意的意圖與限制，轉化為團隊可以安全執行、範圍清晰並有明確次序的工作。 熟悉的交付日常 ### 身為開發主管， 你要讓工程師與 AI 安全地推進變更，卻經常需要自行補上工作沒有說明的先後次序、工作範圍和整合脈絡。 常見情況: 工程師帶著合理問題來找你，AI 提示亦已準備好，團隊希望立即開始。你依靠個人經驗、架構討論和幾位可靠專家，決定哪些工作可以並行，以及哪些內容必須保持不變。 #### 解讀需求 你從工作單、討論和既有程式碼推斷技術影響、相依關係與尚未作出的決定。 #### 拆分和委派工作 你分配實作工作，並透過非正式協調，避免團隊直接承受尚未解決的不確定性。 #### 整合並修正偏差 各項工作開始合併時，你才處理衝突和重新釐清理解；此時原先假設可能已經改變。 現行流程的結構性問題 ### 為什麼委派工作最後變成整合和修復工作。 如果工程師與 AI 接到的工作缺乏共享脈絡、明確範圍與限制，或沒有訂明證據要求，委派只會把不確定性延後至整合階段。 #### 你成為隱形的脈絡中心 關鍵次序和範圍決策留在你的腦中或短暫對話內，形成瓶頸和能力延續風險。 #### 委派工作沒有足夠規格 工程師與 AI 代理接到工作時，缺乏清晰的工作範圍、責任歸屬、不可改動範圍和可觀察的完成標準。 #### 延後的決定在整合時才曝光 各自按不同理解完成的工作，往往要到合併時才顯現產品與技術衝突。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 先質疑並完善規格 在把工作交給團隊或 AI 代理之前，找出模糊之處、相依關係、風險與技術後果。 #### 建立範圍清晰的實作工作 訂明責任歸屬、介面、不可改動範圍、先後次序與證據要求，讓每項工作都可以安全推進。 #### 依同一套共享系統整合 使用委派工作時採用的同一套意圖、限制與驗收證據，審查偏差和已完成成果。 ## 架構師 負責系統責任、介面、限制與重大變更的技術決策權，並讓相關脈絡可供交付工作使用。 熟悉的交付日常 ### 身為架構師， 你要維持整體系統結構和技術決策的一致性，但 AI 輔助實作可能在相關限制尚未完整進入工作前，已經迅速推進。 常見情況: 一項變更由一個服務延伸至另一個服務，或觸及一個歷史悠久的整合。你知道某項限制為何存在，資深工程師亦可能記得背後的事故，但團隊與 AI 代理在選擇方案的當下便需要這些判斷。 #### 從整體系統評估變更 你在持續演進的系統中，分析責任、介面、相依關係、資料、風險與技術標準。 #### 建議或核准方案 你透過設計審查、架構模式和直接指引說明限制，但這些資訊未必會隨實作工作一同傳遞。 #### 在後期才發現偏差 對系統的不同理解，往往要到審查、整合、事故，或架構逐漸偏離原意後才被發現。 現行流程的結構性問題 ### 為什麼架構管治總是在重要決定之後才介入。 當架構脈絡與實作工作分離，管治便會淪為後期檢查，而不能由一開始便成為交付可以直接使用的指引。 #### 架構決策未能直接引導執行 如果正確的架構決定沒有連結至實作工作、工具與驗證證據，它便很難真正影響結果。 #### 系統責任與介面被反覆重新解讀 團隊與 AI 代理只能從分散的工作產物和既有程式碼推斷介面、責任歸屬和限制。 #### 管治在決定之後才發生 審查太遲才發現偏差，因為技術決策權沒有在執行當下轉化為可直接使用的限制。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 讓技術決策權可以直接使用 在交付參與者實際工作的地方，清楚表達相關責任、介面、限制、決策及其權威來源。 #### 以系統脈絡塑造變更 與產品、分析、開發主管和工程師合作，把系統層面的考量轉化為明確而深度相稱的交付範圍與限制。 #### 驗證架構符合性並更新脈絡 利用證據審查變更是否保留架構要求，並隨系統演進持續更新知識系統。 ## 軟體工程師（例如後端或 UI 工程師） 在已授權的產品與技術範圍及限制內實作、提出質疑、測試並說明變更。 熟悉的交付日常 ### 身為軟體工程師， 你需要迅速交付安全的變更。AI 可以協助撰寫程式碼，卻不會自動取得散落在產品、架構與營運工作中的專業判斷。 常見情況: 一項工作只有簡短說明，AI 助手亦已準備好加快實作。你在能夠安全開始前，仍須從程式碼、工作單、聊天紀錄，以及記得某項特殊限制為何存在的資深工程師身上，重新拼湊真正意圖。 #### 重建意圖 你從不完整或互相矛盾的來源，推斷什麼需要改變、什麼必須保留，以及哪些條件最重要。 #### 實作並處理模糊之處 在工作已經開始後，你才作出局部技術決定，或向相關負責人尋求澄清。 #### 事後證明變更是否正確 測試和審查可以建立部分信心，但技術選擇與偏差背後的理由仍可能沒有留下清楚紀錄。 現行流程的結構性問題 ### 為什麼實作中的不確定性最終變成工程返工。 意圖、限制和證據散落在不同來源，令不確定性在實作期間反覆出現，而不是在執行前被清楚處理。 #### 尋找脈絡消耗大量工程時間 安全實作所需的知識分散在工具和人員之間，沒有隨工作一同提供。 #### 工作缺乏明確範圍與保護措施 如果沒有明確的非目標、介面與限制，即使看似很小的變更也可能產生非預期影響。 #### AI 產出仍依賴隱藏脈絡 AI 程式開發代理可以加快實作，卻無法可靠地找回組織尚未明確表達的意圖和決策權。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 執行前先審查並提出質疑 使用規格系統找出模糊之處、遺漏的限制或風險，並交由具相應責任歸屬的角色處理。 #### 在明確範圍內實作 以產品、領域、架構和工作規格引導人與 AI 的實作，不在過程中悄悄擴大範圍。 #### 記錄證據與必要偏差 證明變更如何符合已同意的行為和限制，並讓任何必要偏差都清楚可見，以供審查。 ## 生產環境工程師／系統可靠性工程師 把營運限制、可靠性要求、發佈準備與正式環境證據，帶進整個交付過程。 熟悉的交付日常 ### 身為生產環境工程師或系統可靠性工程師， 你要在發佈前揭示正式環境風險，但 AI 可能迅速推進一項仍缺乏營運脈絡、可觀測性、復原限制或回退條件的變更。 常見情況: 一項變更接近發佈時，負載、監控、回退和支援問題突然出現。你知道上次事故留下了哪些教訓，但相關經驗往往仍分散在操作手冊、儀表板，或當時處理事故的人員記憶中。 #### 找回營運脈絡 你從事故、遙測資料、操作手冊、服務責任和支援經驗，判斷這項變更必須保留哪些條件。 #### 在後期審查發佈風險 產品和實作方案大致已定後，你才有機會評估可觀測性、韌性、容量、回退與部署安排。 #### 發佈後回應並吸收經驗 你處理非預期行為的後果，但這些營運經驗未必會成為下一次變更可以直接使用的長期指引。 現行流程的結構性問題 ### 為甚麼營運風險總是在部署後才被發現。 交付與營運工作彼此分離，令團隊要到部署風險已經升高後，才發現準備、復原和支援方面的缺口。 #### 正式環境的現實介入得太晚 故障模式、支援需要、相依關係和營運限制被視為發佈前檢查，而不是一開始便塑造變更的條件。 #### 可靠性要求沒有進入執行工作 服務目標、可觀測性、復原和回退需求，可能與需要滿足這些要求的工作、程式碼和證據分開記錄。 #### 事故經驗未能穩定改善交付 經驗只留在事故檢討或個別操作手冊中，沒有更新未來參與者和 AI 代理可以取得的權威脈絡。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 在實作前訂明營運要求 提供服務目標、故障行為、相依關係、支援需要、可觀測性、復原和發佈限制。 #### 設計通往正式環境的受控路徑 與產品、架構、工程和品質角色合作，把營運風險、分階段推出條件、回退路徑與具責任歸屬的核准安排寫進交付計劃。 #### 驗收營運證據並更新脈絡 利用部署與正式環境證據評估發佈準備、揭示偏差，並把重要營運所得知識轉化為規格系統中的可重用脈絡。 ## QA 工程師 設計驗證方法與證據，顯示正常流程、例外、迴歸和營運要求均已獲滿足。 熟悉的交付日常 ### 身為 QA 工程師， 你需要為變更建立有意義的信心。AI 可以很快產生測試，卻不能自行判斷哪些行為、風險和證據最重要。 常見情況: 一項完成的變更帶著程式碼、簡短的驗收清單，以及可能由 AI 產生的測試進入驗證階段。你需要重新釐清承諾的行為、重要例外，以及哪些營運條件能令現有證據足以支持驗收。 #### 釐清預期行為 你從工作單、示範、對話、程式碼和過往缺陷，整理真正需要驗收的細節。 #### 設計並執行驗證 你按持續變化的理解，測試正常流程、例外情況、整合和迴歸風險。 #### 說明信心與缺陷 你回報結果和缺陷，但證據、原定意圖與風險之間的連結仍可能十分零散。 現行流程的結構性問題 ### 為甚麼驗證工作總要彌補上游的模糊。 規格與驗證證據彼此分離，品質專業人員便要重新釐清需要證明甚麼，以及哪些證據才足以支持驗收。 #### 品質在範圍決定之後才加入 可測試性、負面流程和營運要求在後期才被發現，而不是從一開始便參與塑造規格。 #### 驗收條件留下重要缺口 一份只涵蓋正常流程的簡短清單，無法代表複雜變更所需的完整驗收證據。 #### 證據難以重用 測試結果可能證明某次建置成功，卻沒有保留為甚麼這些證據足以支持驗收。 規格優先工作方式 ### 讓你的專業判斷持續進入後續工作。 這套流程令你的貢獻清楚可見、可以被質疑，也能被後續工作直接使用。工程師與 AI 程式開發代理因而可以在明確的工作範圍與執行權限內沿著一致路徑工作，而不會默默取代人的判斷。 #### 及早設計驗收方式 在變更仍處於規格階段時，共同訂立可觀察成果、風險條件、負面流程和證據要求。 #### 把驗證追溯至意圖與限制 依照具明確權威的行為、限制和品質屬性設計測試，而不是依靠事後推測的摘要。 #### 支援以證據為本的驗收 清楚呈現規格符合性、剩餘風險和任何限制，讓具驗收責任的角色能有充分依據作出決定。 所有角色共享的專業紀律 ## 每個人都可以成為規格架構師。 這不是一個新的通用職稱，也不代表正式架構師要負責每一份規格。規格架構師是任何能在自己責任範圍內，把意圖、知識、限制、決策、執行範圍與證據表達得足夠清楚，讓其他人和 AI 系統可以直接使用的交付專業人員。 > 每個人都在自己的責任範圍內，設計並維護相應的規格層。