AI Workflow Conduction

繁體中文

Home
English

繁體中文

Home
English

Appearance

AI-First 脈絡基礎設施 ​

本提案建立一個統一的 AI 可存取層，確保所有產品開發相關資訊（程式碼、規格、設計、專案管理）都在 AI 能夠存取的範圍內。這是實現真正 AI 輔助開發的基礎設施層。

核心洞察： AI 的效能取決於可存取的脈絡品質與完整度。當 AI 只能看到程式碼而無法存取需求、設計和決策記錄時，其輸出必然受限。建立統一的脈絡基礎設施，讓 AI 成為真正的開發夥伴。

問題陳述 ​

當前狀態：脈絡孤島 ​

團隊回饋的證據 ​

痛點對 AI 工作流程的影響
需求分散AI 無法理解功能的完整背景，只能根據程式碼猜測
設計資產隔離AI 生成的 UI 與設計稿不一致，需要大量人工修正
決策記錄遺失AI 不知道為何做某些設計選擇，可能重蹈覆轍
專案狀態不明AI 無法判斷哪些功能正在開發、哪些已完成
跨團隊資訊斷層AI 無法發現其他團隊已解決過類似問題

根本挑戰：可及不等於可用 ​

即使解決了存取問題，還有更深層的挑戰：

關鍵洞察： 各個平台（Confluence、Figma、Jira 等）在設計之初的目的，並不是作為 Single Source of Truth（單一真理來源），且人類目前也沒有維護這類資訊的意識。因此，即使我們可以透過 Agent 去存取資訊，也面臨三個問題：

  1. 該資訊可能是過時的
  2. 該資訊可能是缺漏的
  3. 很大概率不知道要去哪裡找——不清楚該去這個平台的什麼地方，才能查找到需要的資訊

這意味著本提案有兩個層次的目標：

層次目標挑戰
第一層：可及性讓 AI 能夠存取產品開發相關資訊技術整合與資料治理
第二層：有效性確保 AI 存取到的是真正有意義的資訊文化與流程改變（維護意識建立）

第一層的解決路徑：

第一層並非只有「讓 AI 直接存取現有平台」一種做法，而是有兩種互補的路徑：

路徑做法適用情境
路徑 A：即時連接透過 MCP Server 連接現有平台（Figma、Jira 等）資訊頻繁變動、需要即時查詢
路徑 B：集中遷移建立全新的 Git-based 平台，將資料從各平台遷移過來核心知識、需要長期維護的資訊

路徑 B 的具體實踐可參考 AI 代理友善知識庫 提案，該提案詳述如何從 Confluence 等人類導向的 Wiki 遷移至 Git-based Markdown 知識系統。

第二層的解決策略：

  1. 核心知識庫集中化：將關鍵資訊從各平台遷移到 Git-based 系統，建立明確的維護責任
  2. Frontmatter 標準化：透過結構化中繼資料（如 lastUpdated、status）讓 AI 能判斷資訊的時效性
  3. 持續脈絡清理：建立定期審查機制，確保知識庫內容保持更新（參見持續脈絡清理）
  4. AI 輔助驗證：讓 AI 在使用資訊前，主動檢查相關文件的更新狀態和一致性

提議解決方案：混合式 AI 脈絡架構 ​

目標架構 ​

核心原則 ​

  1. 脈絡完整性：所有影響開發決策的資訊都應對 AI 可及
  2. 混合式架構：核心知識集中化（Git-based），外部系統透過 MCP 即時連接
  3. 單一入口：透過 MCP Gateway 統一存取，降低 AI 的認知負擔
  4. 漸進式遷移：從最痛的資訊孤島開始，逐步擴展覆蓋範圍
  5. 權限對齊：AI 的存取權限與使用者權限一致，不額外開放

架構分層 ​

第一層：核心知識庫（集中化） ​

這些資訊需要長期維護，適合集中管理：

系統內容來源 Proposal
知識庫領域知識、指引、最佳實踐AI 代理友善知識庫
需求儲存庫產品需求、使用者故事、驗收標準全域需求儲存庫
規格平台功能規格、API 合約、UX 規格內部規格平台
通用語言詞彙表術語定義、領域概念通用語言
架構決策記錄ADR、技術選型理由待建立

第二層：即時連接（MCP Servers） ​

這些資訊頻繁變動，適合即時查詢：

MCP Server提供的脈絡優先級
Git MCP程式碼、PR、Issue、Commit 歷史P0（已有）
Figma MCP設計稿、Design Tokens、元件庫P1
Jira MCP任務狀態、Sprint、Roadmap、EpicP1
Confluence MCP現有文件（過渡期使用）P2
Teams MCP討論記錄（搜尋用）P3

第三層：MCP Gateway ​

統一的存取入口，提供：

typescript
// MCP Gateway 概念
const mcpGateway = {
  // 統一查詢介面
  query: async ({ intent, scope, filters }) => {
    // 根據 intent 決定查詢哪些資源
    // 例如：「找出這個功能的所有相關資訊」
    const results = await Promise.all([
      knowledgeBase.search(intent),
      requirementStore.search(intent),
      specPlatform.search(intent),
      figmaMcp.search(intent),
      jiraMcp.search(intent)
    ]);
    return aggregateResults(results);
  },

  // 脈絡載入
  loadContext: async ({ feature, product }) => {
    return {
      requirements: await requirementStore.get(product, feature),
      specs: await specPlatform.get(product, feature),
      designs: await figmaMcp.get(product, feature),
      tasks: await jiraMcp.get(product, feature),
      relatedCode: await git.search(feature)
    };
  }
};

資訊流整合 ​

功能開發的完整脈絡 ​

跨系統追溯 ​

需求                    規格                    設計                    實作
────────────────────────────────────────────────────────────────────────────
REQ-001          →     func/device-mgmt   →   Figma/DeviceList   →   DeviceList.tsx
(使用者故事)            (功能規格)              (UI 設計)              (程式碼)

                 →     api/device-mgmt    →                      →   deviceApi.ts
                        (API 合約)                                    (API 客戶端)

                 →     ux/device-mgmt     →   Figma/DeviceCard   →   DeviceCard.tsx
                        (UX 規格)              (元件設計)              (元件)

實施路線圖 ​

階段 0：需求盤點（Q2 2026/4-6） ​

目標： 了解現狀，確定優先級

  • [ ] 盤點所有產品開發相關資訊來源
  • [ ] 評估各資訊源的 AI 可及性現狀
  • [ ] 識別最痛的脈絡斷點
  • [ ] 設計混合式架構細節
  • [ ] 確定 MCP Server 開發優先級

交付物：

  • 資訊源清單與 AI 可及性評估報告
  • 混合式架構設計文件
  • 實施優先級排序

階段 1：核心知識庫建立（Q3 2026/7-9） ​

目標： 建立集中化的核心知識層

週次工作項目
1-2建立 Git-based 知識庫 repository
3-4遷移關鍵領域知識和指引
5-6建立需求儲存庫基礎結構
7-8試點一個產品的需求遷移
9-10規格平台 MVP 上線
11-12整合測試與調整

交付物：

  • 知識庫 repository 可運作
  • 一個產品的需求遷移完成
  • 規格平台 MVP

階段 2：擴展與整合（Q3-Q4 2026/7-12） ​

目標： 擴展知識庫覆蓋範圍，評估是否需要即時連接層

主要路徑：集中化至 Git

優先將各平台資訊遷移至 Git-based 知識庫，透過 AI 原生支援的 Git MCP 存取：

資訊類型來源平台遷移至
設計規範Figmaknowledge-base/designs/ (Design Tokens, 元件規格)
專案狀態Jiraknowledge-base/projects/ (Sprint 摘要, Roadmap)
技術文件Confluenceknowledge-base/docs/ (遷移活躍內容)

備案：MCP Server 開發

若集中化無法滿足即時性需求，再考慮開發 MCP Server 直接連接各平台：

MCP Server適用情境優先級
Figma MCP需要即時讀取最新設計稿低（優先遷移 Design Tokens）
Jira MCP需要即時任務狀態低（優先定期同步摘要）

交付物：

  • 知識庫覆蓋率達 80% 以上
  • 評估報告：是否需要開發 MCP Server

階段 3：全面整合與推廣（Q4 2026/10-12） ​

目標： 全面啟用 AI-First 脈絡存取

  • [ ] 所有產品完成知識庫/需求遷移
  • [ ] MCP Gateway 穩定運作
  • [ ] 開發者培訓與推廣
  • [ ] 建立維護機制與治理流程
  • [ ] 效能優化與快取策略

交付物：

  • 全面可運作的 AI-First 脈絡基礎設施
  • 開發者使用指南
  • 維護與治理文件

與現有 Proposals 的關係 ​

本 proposal 作為統籌層，整合以下現有 proposals：

Proposal在本架構中的角色
AI 代理友善知識庫核心知識層 - 領域知識和指引
全域需求儲存庫核心知識層 - 需求管理
內部規格平台核心知識層 - 規格託管
通用語言跨層共用 - 術語一致性

成功指標 ​

指標目標如何測量
脈絡完整度>80% 功能有完整脈絡審計功能的可及資訊
AI 脈絡載入時間<5sMCP Gateway 延遲監控
開發者滿意度>4/5季度調查
脈絡使用率>70% 的 AI 會話使用會話分析
跨系統追溯100% 需求可追溯到程式碼連結驗證

風險與緩解 ​

風險緩解措施
即時性需求未滿足MCP Server 開發作為備案，優先評估定期同步是否足夠
遷移成本過高採漸進式遷移，先遷移活躍內容
權限管理複雜MCP Gateway 統一處理，與現有權限系統整合
效能瓶頸實作快取層，非即時資訊定期同步
團隊採用阻力從痛點切入，展示具體價值

相關： AI 代理友善知識庫 | 全域需求儲存庫 | 內部規格平台 | 返回： 提案概覽