Skip to content

Home

Jump to bottom
MDG_JMS edited this page Sep 20, 2026 · 4 revisions

PxDCA：專案背景與設計理念

1. 專案起點

AI 已能快速產生架構、程式碼、設定檔與測試案例。

然而，軟體工程的核心瓶頸已從「產出速度」轉向「方向校準與邊界控制」。當開發者僅輸入一段抽象需求，AI Agent 便能自主分析並連續實作。執行速度越快，若方向錯誤或邊界模糊，所造成的架構返工代價就越高。

常見的失控情境包括：

  • 職務視角混淆：需求邊界尚未釐清，實作程式碼已開始鋪排；或負責實作的角色擅自擴增業務範圍。
  • 任務顆粒度失控：嘗試在單一指令中同時完成全域架構與底層細節，導致 AI 遺漏邊界條件、自行編造合理假設。
  • 假性驗證與跳步：缺乏可證偽的客觀檢驗，AI 產出程式碼後即直接宣告完成，缺乏品質防線。
  • 脈絡中斷與局部偏離：大專案被拆解為子任務分派後，執行者僅持有片段指令，遺失了父層的系統邊界與驗收指標。

PxDCA 的核心目的不是限制開發速度，而是在每次關鍵執行之前，強制 AI 與開發者遵守具備確定性邊界的工程閉環。

2. PxDCA 是什麼：變數 $x$ 的核心意涵

PxDCA 將經典的戴明環（PDCA）升級為**多型態（Polymorphic）與階層分形（Fractal）**的工程控制框架。

名稱中的 $x$ 並非離散的次數計數器，而是一個多型態向量（State Vector）。它將**「職務角色（Role）」與「任務階層（Task Hierarchy）」**完全合併，使每一次規劃（$P_x$）都具備明確的專業視角與任務顆粒度：

$$\vec{x} = \langle \text{職務態 (Role)}, \text{任務層級 (Level)} \rangle$$

在 PxDCA 體系中：

  • 任何專案都不可能一次性完成：全域大規劃（大 P）必須透過階層降解，精確衍生為模組規劃與單元任務（小 P）。
  • 任何規劃都必須具備專屬邊界：不同職務視角（$P_{\text{PM}}, P_{\text{PG}}, P_{\text{PQ}}$）各自對應獨立的驗收標準與交付物。
  • 所有多型態皆強制遵守 DCA 閉環：無論是何種職務、何種層級的 $P_x$，都必須完成專屬的執行（Do）、查核（Check / Quality Gate）與處置（Act），杜絕跨階段跳步。

3. 多型態雙軸模型：職務態與任務階層

3.1 職務維度（Role Polymorphism）

傳統 PDCA 常將所有角色混雜在同一個 Plan 中。PxDCA 要求嚴格切換職務視角，不同角色的 $P_x$ 互不越權：

  • $P_{\text{PM}}$ (Product / Project 態)：
    • 責任：釐清商業價值、定義系統邊界、鎖定不可打破的系統約束（Invariants）與使用者驗收條件（AC）。
    • 限制：專注於「做什麼（What）與邊界何在」，嚴禁直接決定底層技術細節與程式碼語法。
  • $P_{\text{PG}}$ (Programmer / Generator 態)：
    • 責任：承接 PM 劃定的邊界，負責技術選型、模組解耦、資料結構、通訊協議與具體工程落盤。
    • 限制：專注於「如何實現（How）」，嚴禁擅自擴增或變更 PM 已凍結的業務邏輯。
  • $P_{\text{PQ}}$ (Product Quality 態)：
    • 責任：擔任客觀的審查防線，負責可證偽驗證、極端邊界測試、架構稽核與合規性檢驗。
    • 權限：具備絕對否決權，未通過即阻斷交付，杜絕「看似完成」的表面修復。

3.2 任務階層維度（大 P 轉小 P）

軟體系統由宏觀延伸至微觀，PxDCA 將專案分解為不可逾越的階層：

  • Level 0 (大 P：系統架構級)： 例如「建立分散式訂單系統之資料庫持久層架構與高可用性（HA）策略」。
  • Level 1 (中 P：模組與實體級)： 例如「建立訂單（Orders）與使用者（Users）之關聯資料表與交易邊界」。
  • Level 2 (小 P：單元與邏輯級)： 例如「建立訂單明細資料表之欄位精度約束、索引策略與資料庫遷移程序」。

4. DCA 閉環與品質門禁（C 轉 Q 的實質本義）

在工程實務中，將 Check 延伸或替換為 Quality（Q）是語意細緻度的深化，但絕非影響驗證與交付的關鍵。

真正決定交付成敗的核心，在於該階段是否具備**「具否決權的確定性品質門禁（Deterministic Quality Gate）」**。

     P_x (Plan)      ──► 鎖定邊界、約束條件與可證偽驗收標準 (AC)
          │
          ▼
     D_x (Do)        ──► 在 P_x 約束下落盤具體工程製品 (架構/規格/實作)
          │
          ▼
     C_x / Quality   ──► 執行確定性檢驗 (型別安全/邊界覆蓋/契約對齊)
          │
          ├─► [合格通過] ──► A_x: 固化基準線 (Baseline)，交付或向上回報
          │
          └─► [檢驗失敗] ──► A_x: 產出具體差額修復 (Patch)，重回 C 驗證
  • P（Problem / Plan）：確認當前向量 $\vec{x}$ 下真正要處理的問題。明確定義成功條件與不可違背的約束，若複雜度過高則在此階段啟動任務分解。
  • D（Design / Do）：將確認後的約束轉換為當前層級的具體工程製品。大 P 產出模組劃分與子任務規格，小 P 產出具體實作。
  • C（Check / Quality Gate）：
    • 可證偽性：必須存在明確量化的失敗條件，禁止主觀陳述。
    • 約束全覆蓋：$P_x$ 中宣告的每一項驗收指標，$C_x$ 必須逐項對齊檢驗。
    • 無情阻斷：只要任一檢查項目未通過，強制阻斷交付管道。
  • A（Action / Act）：
    • 處置失敗：僅針對 Check 所列出的差額清單進行局部修復，禁止非授權的全域重構。
    • 標準化交付：若 Check 全數通過，凍結該階段成果基準線，允許狀態機推進。

5. 階層遞迴機制：大 P 轉小 P 的運作實例

以「資料庫系統開發」為例，展示職務態與任務階層如何協同閉環：

[ Level 0 : 大 P ] 系統級規劃 (P_PG:L0)
目標：建立電商持久層架構、決定資料庫引擎、連線池與交易隔離原則。
  │
  ├─► D_L0 產出子任務規格清單，觸發階層拆解 (Decomposition)
  │     │
  │     ├─► [ Level 1 : 小 P-1 ] 訂單主表 (p_PG:L1_Orders)
  │     │      ├── p: 定義 Orders 欄位、主外鍵、NULL 約束與狀態機列舉
  │     │      ├── d: 撰寫 DDL 腳本、資料庫遷移檔案與 ORM 實體對齊
  │     │      ├── c (Q-Gate): 靜態驗證外鍵有效性、型別長度、索引覆蓋度
  │     │      └── a: 修復語法缺失，通過後標記為 PASSED
  │     │
  │     └─► [ Level 1 : 小 P-2 ] 庫存扣減表 (p_PG:L1_Inventory)
  │            ├── p: 定義樂觀鎖欄位、庫存不得為負之 Check 約束
  │            ├── d: 撰寫 DDL 腳本與扣減交易隔離程序
  │            ├── c (Q-Gate): 驗證高並發鎖定風險與死結可能
  │            └── a: 調整約束條件，通過後標記為 PASSED
  │
  ▼
所有子層級小 P 全數標記為 PASSED
  │
  ▼
[ 接續 Level 0 閉環 ]
C_L0 (Q-Gate)：跨表整合驗證、外鍵相依性檢查、全域備份與復原演練
A_L0：凍結資料庫基準線 v1.0，交付應用程式開發流程

系統核心不變量（Invariants）

  1. 防越權原則（Anti-Bypass）： 大 P 的責任是劃分邊界與衍生子規格，嚴禁跳過子層直接輸出底層實作細節。
  2. 邊界隔離原則（Strict Scoping）： 衍生出的小 P 僅能在被授權的局部作用域內修改，嚴禁修改父層未授權之全域設定，亦不得跨界污染其他並行小 P。
  3. 自下而上阻斷原則（Bottom-Up Blocking）： 父層任務在所有子任務取得品質合格證明之前，處於強制凍結狀態。任一小 P 失敗，大 P 絕不標記交付。

6. 職務與階層的二維對照矩陣

在系統運作中，AI 必須根據當前的二維座標嚴格定位其輸出內容：

階層 ($L$) 職務態: PM ($P_{\text{PM}}$) 職務態: PG ($P_{\text{PG}}$) 職務態: PQ ($P_{\text{PQ}}$)
Level 0
(大 P：全域系統級)		 • 業務邊界劃分
• 全域業務目標與限制
• 驗收標準 (AC) 總綱		 • 系統拓撲與技術棧選型
• 跨模組資料流向與通訊協議
• 系統層級交易隔離規範		 • 全域架構資安合規基準
• 系統高可用性 (HA) 稽核指標
• 架構合規檢核表
Level 1
(中 P：模組實體級)		 • 模組實體生命週期
• 業務狀態轉移矩陣
• 模組暴露介面功能清單		 • 資料表綱要 (Schema) 設計
• 模組間 API 介面協議契約
• 索引策略與 ORM 模型定義		 • 介面相容性檢查 (Contract Test)
• 死結風險與 SQL 執行計畫分析
• 模組整合驗證矩陣
Level 2
(小 P：單元邏輯級)		 • 單一欄位之業務驗證規則
• 業務錯誤代碼與語意定義
• 極端異常使用者情境		 • 具體 Migration 腳本撰寫
• 商業邏輯函式與演算法實作
• 例外捕捉與交易回滾實作		 • 單元測試覆蓋率檢驗
• 邊界模糊測試 (Fuzz Testing)
• 靜態代碼與安全性弱點掃描

7. 為什麼需要將 PxDCA 協定化

需求與架構整理通常散落在個人經驗、零碎的 Prompt、Markdown 文件或口頭溝通中，難以跨模型、跨工具、跨專案穩定複現。

PxDCA 透過標準協定將此工作流程具體化：

  • 角色與契約 (Prompts)：明確定義 PM、PG、PQ 等不同職務態在各階層的輸入、輸出與責任邊界。
  • 政策與規範 (Resources)：提供固定的架構策略、命名常規、檢核準則與工作流政策。
  • 確定性驗證 (Tools)：由工具自動執行輸入格式檢驗、階層派生標記、狀態機轉移驗證與差額對齊審查。

由模型負責語意理解與邏輯推理，PxDCA 則負責強制鎖定工作流程、階層深度與品質邊界。

8. AI Agent 與邊界收斂

AI Agent 具備持續修改、自主重試的執行能力。然而，在缺乏邊界約束的狀況下，持續執行極易演化為持續偏離：

  • 將實作中的臨時妥協當作正式規格。
  • 為了解決局部測試失敗，擅自變更原本定義的業務需求。
  • 在未經授權的情況下，大幅重構與當前任務無關的程式碼。

PxDCA 限制 Agent 僅能在指定的向量 $\vec{x}$ 內活動。未定義 Plan 之前不得 Do；未通過 Check 之前不得交付；若要擴大範圍，必須向上觸發父層變更流程，杜絕無效且失控的自主重試。

9. 稽核原則與可追溯性 (Audit & Traceability)

PxDCA 遵循系統工程與品質稽核的基本準則：

  • 需求必有來源：所有技術實作均能向上追溯至特定層級的業務約束。
  • 規劃必可證偽：任何 Plan 提出的驗收條件，皆須具備明確的檢驗方式。
  • 變更必留痕跡：當需求或技術方案調整時，必須明確標記受影響的上下游層級。
  • 事實與假設分離：已確認的事實、待確認的假設、技術建議必須明確區分，未確認事項嚴禁作為下游實作的基線。

10. 與版本控制系統（Git）的互補定位

Git 與程式碼代管平台主要保存工程的最終製品與變更歷史：

  • 原始碼、Commit 紀錄、Pull Request 與 Release 版本。

然而，許多關鍵的決策脈絡通常不會完整記錄在 Commit 訊息中：

  • 為什麼選擇此架構而放棄另一方案？
  • 哪些邊界條件曾被討論但最終排除？
  • 大專案是如何被分解為數個子系統？
  • 各階段的品質驗證依據為何？

PxDCA 不取代版本控制系統。它在產物進入版本控制之前，建立嚴謹的決策脈絡與驗證基線；同時也能為每一次的 Issue、Feature 或 Pull Request，啟動局部的 PxDCA 閉環。

11. 核心系統原則

  1. 先確認問題，再選擇技術：需求與邊界定義永遠優先於實作。
  2. 單一向量責任制：每個職務態僅處理當前範疇的事務，PM 不寫語法，PG 不擅改需求，PQ 專注於可證偽防線。
  3. 大任務強制降解：跨模組、跨資料表或跨系統的龐大任務，必須拆解為「大 P 轉小 P」的階層模型，禁止一次性跳步實作。
  4. 階層繼承與隔離：小 P 必須完全繼承大 P 確立的邊界與約束，且其修改權限嚴格受限於被指派的作用域。
  5. 以品質門禁為唯一交付條件：不以產出篇幅或執行速度為衡量標準，僅以 100% 通過 Check 為閉環條件。

12. 核心主張

PxDCA 不只用於專案啟動之初，它存在於整個軟體生命週期的每一次狀態推進。

從全域架構、模組切分、資料庫設計到單一函式的修復，每一個維度都可以建立屬於自己的工程閉環。

每一項工程任務，都必須在明確的職務與階層邊界下，完成一次獨立的規劃、執行、查核與處置。

AI 負責高速推進，PxDCA 負責鎖定邊界與工程方向。

PxDCA is a Polymorphic and Hierarchical Closed-Loop Architecture for Deterministic Software Engineering.

Clone this wiki locally