-
Notifications
You must be signed in to change notification settings - Fork 0
Home
AI 已能快速產生程式碼、文件、架構與測試內容。
問題也隨之改變。
過去，開發成本主要來自執行速度；現在，開發者可能只提供一段需求，Agent 就能持續分析、修改與實作。
執行越快，方向錯誤的代價也越高。
常見情況包括：
- 需求尚未確認，實作已經開始。
- 開發者與需求提出者理解不同。
- AI 自行補充缺少的條件。
- 規劃持續延伸，逐漸偏離原始目標。
- 局部功能正確，整體業務邏輯錯誤。
- 工作被分派後，執行者只看到任務，缺少完整背景。
- 開發過程出現新條件，卻沒有重新檢查原始設計。
LogicMCP 的目的不是限制開發速度，而是在每次重要執行之前，提供一個可以重新整理與檢查方向的邏輯流程。
LogicMCP Server 是以 MCP 提供的開發邏輯校準服務。
它將需求、規劃、檢視與執行整理為可重複呼叫的工作流程，讓開發者或 AI Agent 在開始工作前，先建立清楚的執行基線。
LogicMCP 可以應用於：
- 新專案
- 既有系統改造
- 單一功能
- 系統模組
- 資料庫業務邏輯
- API 設計
- UI 流程
- 效能改善
- 錯誤修正
- 資料清理
- 部署與基礎架構工作
- 開發過程中的需求變更
它不是只能執行一次的專案前置流程。
任何工作進入新的範圍、責任或技術層級時，都可以再次啟動 LogicMCP。
LogicMCP 參考 PDCA 的循環概念，但不直接套用傳統管理流程。
它將 PDCA 重新定義為適合軟體開發與 AI Agent 的四個階段。
確認目前真正要處理的問題與目標。
主要內容包括：
- 業務需求
- 問題背景
- 預期成果
- 執行範圍
- 已知條件
- 未確認事項
- 限制與例外
- 成功條件
P 階段不急著決定技術。
重點是確認執行者正在解決正確的問題。
將已確認的需求轉換成可執行規劃。
主要內容包括：
- 系統邊界
- 功能設計
- 技術方案
- 資料流程
- 模組責任
- 輸入與輸出
- 執行步驟
- 驗證方式
- 風險與替代方案
D 階段不是直接產生大量功能，而是建立需求與技術之間的對應關係。
在實作前檢查規劃是否可靠。
主要檢查：
- 是否偏離原始需求
- 是否存在需求缺漏
- 是否產生未授權延伸
- 設計是否互相矛盾
- 資料來源是否正確
- 邊界條件是否完整
- 技術方案是否可執行
- 是否具有驗證方式
- 是否能追溯重要決策
- 是否需要回到 P 或 D 重新整理
C 階段不是形式上的審核。
它是開發者、顧問、架構師或 Agent 在實作前進行的反向檢查。
將確認後的規劃交給執行者。
執行者可能是：
- 軟體開發者
- 資料庫工程師
- 系統工程師
- AI Coding Agent
- 測試人員
- 外部服務
- 自動化工作流
A 階段包含實作、測試、交付與結果紀錄。
執行中若出現新問題，不需要勉強完成原始規劃，而是重新啟動下一輪 PDCA。
軟體開發不是單一路徑。
LogicMCP 採用可重複、可分層、可遞迴的工作方式。
專案 PDCA
├─ 系統架構 PDCA
├─ 模組 PDCA
│ ├─ 資料庫 PDCA
│ ├─ API PDCA
│ ├─ UI PDCA
│ └─ 測試 PDCA
├─ 功能 PDCA
└─ 問題修正 PDCA
專案層級完成一次 PDCA，不代表後續工作不再需要整理。
當工作被分派到不同人員、不同 Agent 或不同技術領域時，可以針對該工作建立新的局部 PDCA。
局部流程必須繼承上層已確認的目標與限制，但可以補充更細的技術內容。
假設一個系統已進入開發階段，資料庫開發者收到一項任務：
建立訂單成本計算與更新程序。
若直接進入 SQL 實作，開發者可能只看到資料表與計算公式，卻不知道完整業務條件。
此時可以重新啟動 LogicMCP。
- 成本來源是什麼？
- 使用標準成本、實際成本還是核價成本？
- 幣別如何換算？
- 精度與四捨五入規則是什麼？
- 哪些單據狀態可以更新？
- 是否需要保留還原紀錄？
- 跨月、跨年與歷史資料如何處理？
- 確認來源資料表與關聯鍵。
- 規劃查詢、驗證與更新順序。
- 定義交易處理。
- 定義資料精度。
- 建立更新前後紀錄。
- 規劃失敗回復方式。
- 查詢條件與更新條件是否一致？
- 是否可能重複更新？
- 幣別換算是否使用正確匯率？
- 小數精度是否符合 ERP 規則？
- 是否影響未簽核或歷史資料？
- 是否能完整還原？
- 先產生驗證查詢。
- 確認結果。
- 執行更新。
- 驗證異動。
- 保存紀錄。
- 將結果回傳至上層工作流程。
這就是開發者自己的局部 PDCA。
需求整理方法通常存在於：
- 個人經驗
- Prompt
- Markdown 文件
- 專案管理制度
- 顧問訪談流程
- 開發者腦中的判斷方式
這些方法難以穩定地跨模型、跨工具與跨專案重複使用。
LogicMCP 將流程拆分成 MCP 能力：
定義不同階段的工作角色、輸入、輸出與限制。
例如：
- 需求探索
- 需求訪談
- 技術對齊
- 規劃檢視
- 規格產生
- 稽核整理
提供固定的流程與規則。
例如：
- Workflow Policy
- Capability Profile
- JSON Schema
- 文件模板
- 欄位定義
- 稽核條件
負責執行結構化工作。
例如：
- 驗證需求資料
- 驗證規劃內容
- 產生規格文件
- 建立交付基線
- 執行跨階段檢查
- 產生稽核結果
模型負責理解與推理。
LogicMCP 負責提供流程、結構與檢查邊界。
LogicMCP 不取代：
- 需求提出者
- 專案經理
- 顧問
- 系統分析師
- 架構師
- 開發者
- 測試人員
- AI Agent
它也不保證所有規劃都正確。
LogicMCP 提供的是一個共同工作方式，讓不同角色能以相同結構確認：
- 現在要解決什麼
- 為什麼要這樣設計
- 哪些內容已經確認
- 哪些內容仍是假設
- 執行者可以做什麼
- 執行結果應如何驗證
最終決策仍由實際負責者承擔。
AI Agent 可以持續修改、測試與重試。
這種能力適合目標明確、評估標準固定的工作。
例如：
修改程式
→ 執行測試
→ 比較指標
→ 改善則保留
→ 失敗則回退
→ 繼續執行
軟體需求通常沒有單一評分指標。
「建立一個最好用的管理系統」無法直接轉換成明確的成功條件。
若目標、範圍與限制沒有先整理，Agent 的持續執行可能變成持續偏離。
LogicMCP 不負責讓 Agent 無限執行。
它負責在執行前與執行中，確認：
- 目標是否明確
- 範圍是否可控
- 成功條件是否存在
- 評估方式是否可靠
- 是否需要停止或重新規劃
AI 可以持續執行。
LogicMCP 用來確認它是否仍在執行正確的工作。
LogicMCP 採用 ISO-aligned audit 的概念，但不代表專案取得任何 ISO 認證。
這裡使用的是稽核與品質管理中的基本原則：
- 重要需求應有來源。
- 規劃應對應需求。
- 執行結果應能被驗證。
- 未確認事項不應被當成事實。
- 變更應留下紀錄。
- 關鍵決策應能追溯。
- 不同階段的產物應保持一致。
LogicMCP 的稽核重點不是文件格式，而是內容之間的關係。
需求
→ 規劃
→ 技術決策
→ 執行項目
→ 測試
→ 交付結果
當任何一個階段發生變更，應能確認它影響了哪些後續內容。
GitHub 主要保存：
- 程式碼
- Commit
- Branch
- Pull Request
- Issue
- Release
- 最終技術文件
實際開發過程中的許多內容通常不會完整保存在 README：
- 為何選擇這個方案
- 哪些需求曾經被排除
- 哪些假設尚未確認
- 為何某項設計被修改
- 開發者如何判斷風險
- 任務分派後如何重新理解業務邏輯
LogicMCP 不取代 GitHub。
它可以在程式碼進入 GitHub 之前，建立需求與規劃基線；也可以在 GitHub 開發過程中，為 Issue、Feature、Module 或 Pull Request 建立新的局部 PDCA。
GitHub 保存開發成果與版本歷史。
LogicMCP 保存成果背後的需求、規劃與檢查邏輯。
目前的 LogicMCP Server 是一個前哨站。
它先驗證一個核心想法：
開發者與 AI 是否能在不同開發階段，共同使用一套可重複的邏輯校準流程。
現階段重點不是建立完整的軟體生命週期管理平台，而是逐步確認：
- 哪些需求欄位真正有用
- 哪些規劃內容能降低返工
- 哪些檢查規則能發現方向錯誤
- MCP Client 是否會正確呼叫流程
- 不同模型能否維持一致輸出
- 局部 PDCA 是否能承接上層需求
- 文件與結構化資料如何互相轉換
- 稽核結果是否能協助實際開發
LogicMCP 會從可執行的小型流程開始，再逐步擴張。
技術不能取代需求定義。
需求階段不應直接決定所有實作細節。
檢查階段不應擅自增加新需求。
執行階段不應將未確認假設視為正式規格。
所有重要內容應標示其狀態：
- 已確認
- 待確認
- 合理推論
- 技術建議
- 已排除
- 已變更
模組、功能與技術工作的 PDCA，不應違反專案層級已確認的目標。
當條件改變、設計失效或執行結果不符預期時，應回到適當階段重新整理。
LogicMCP 不追求產生更多文件。
它重視內容是否：
- 清楚
- 可執行
- 可驗證
- 可追溯
- 能被下一階段使用
模型產生的合理內容仍需確認。
完整不等於正確。
輸入需求或工作項目
↓
P：確認問題、目標、範圍與限制
↓
D：建立設計、技術與執行規劃
↓
C：檢查缺漏、矛盾、風險與偏離
↓
A：交付開發者或 Agent 執行
↓
結果驗證
↓
完成，或啟動下一輪 PDCA
這個流程可以套用於整個專案，也可以套用於一項 SQL 修改、一支 API、一個畫面或一次錯誤修正。
LogicMCP 希望建立一種適合 AI 開發時代的工作方式：
- 將模糊想法整理成可執行問題。
- 將需求與技術規劃建立對應。
- 在實作前發現缺漏與方向錯誤。
- 在開發中允許局部工作重新校準。
- 讓不同開發者與 Agent 使用相同基線。
- 保存重要需求、決策與變更關係。
- 降低快速執行造成的返工與偏離。
- 讓最終成果能回到原始目標接受驗證。
LogicMCP 不只用於開發之前。
它存在於整個開發過程中。
從專案、模組、功能到單一技術工作，每一層執行都可以建立自己的 PDCA。
每一層開發工作，都可以重新確認一次問題、設計、檢查與行動。
AI 可以持續執行，LogicMCP 負責持續校準方向。
LogicMCP is a recursive PDCA workflow for human and AI software development.