# **u6u 智慧前端與工匠 AI 開發藍圖 (v4.0)**

## **一、 核心設計理念：意圖導向的雙面畫布**

u6u 的前端不是傳統的平面繪圖板，而是一個類似 Android Studio 或 Figma 的\*\*「結構化標籤編輯器」**。 畫布上的每一個元件（Web Component），本質上都是一個**「意圖發射器 (Intent Emitter)」\*\*。前端只負責「長得好看」與「收集人類動作」，後端全權負責「業務邏輯」。

### **人機協作的「雙向同步」**

* **AI 詠唱修改：** 人類說「把按鈕改醒目一點」，CEO AI 在背景將 \<u6u-btn color="blue"\> 修改為 \<u6u-btn color="neon-red"\>，畫面瞬間更新。  
* **人類手動覆寫：** 人類覺得 AI 調的紅色太暗，直接在右側屬性面板 (Properties Panel) 點選色碼器，底層 HTML 屬性隨之改變。**AI 也能「看見」這個改變，從中學習人類的審美偏好。**

## **二、 畫布介面設計與運作機制**

### **1\. 正反面翻轉機制 (The "Flip" Interface)**

每個 UI 零件在畫布上都有「一體兩面」：

* **正面 (UI 視圖)：** 顯示 HTML 渲染的視覺結果（按鈕、溫度計、圖表）。人類可以在此調整 CSS 屬性、對齊方式與主題顏色。  
* **反面 (邏輯視圖)：** 點擊「翻面」按鈕後，會進入底層的工作流設定。這裡使用 u6u 的自定義 Cypher 視覺化語法（例如 \>\> 符號）。  
  * *範例：* \[ UI\_Button: "緊急停機" \] \>\> (Intent: emergency\_stop) \>\> \[ WASM: gsheets\_create \]

### **2\. 智慧容器與區域感知 (Smart Zone Awareness)**

為了消滅傳統 iPaaS（如 n8n）最痛苦的「手動變數綁定」，u6u 畫布具備「區域感知」能力。

* **底層邏輯（獨立元件）：** 畫布上的 TextInput 與 Button 都是各自獨立的原子元件。  
* **麻瓜體驗（智慧表單）：** 當使用者將這兩個元件拖入同一個排版容器（例如 \<u6u-card\>）時，系統會自動建立上下文關聯。當按下按鈕並觸發 Webhook 時，按鈕會**自動打包同容器內所有輸入框的值**一併送出：  
  {  
    "intent": "query\_attendance",  
    "payload": { "employee\_id": "A1234" } // 自動從旁邊的 TextInput 抓取  
  }

  使用者完全不需要理解「表單傳值」或「變數綁定」，拖拉組合即生效。

### **3\. 多重事件插槽與靜態屬性 (Multi-Event Slots)**

一個前端元件可以具備多種觸發行為，系統透過介面將「視覺」與「後端邏輯」徹底分流：

* **靜態視覺註釋：** 例如 mouseover 顯示提示。使用者只需在屬性面板輸入 Tooltip 文字，底層僅修改 HTML 屬性 \<u6u-btn tooltip="..."\>，不消耗任何伺服器資源或 Webhook。  
* **動態意圖綁定：** 在「反面」邏輯視圖中，使用者可以針對不同事件綁定不同的工作流：  
  * ⚡ When: 點擊 (onClick) ➡️ \[ 綁定至 Webhook A：送出查詢 \]  
  * ⚡ When: 獲得焦點 (onFocus) ➡️ \[ 綁定至 Webhook B：載入歷史紀錄 \]

### **4\. 智慧上下文替換 (Smart Contextual Substitution)**

當主管在畫布上對著一個已連接 Webhook 的「按鈕」點擊右鍵選擇「替換元件」時：

* 系統讀取反面的 Cypher 連線，發現需要發射一個 trigger 意圖。  
* 系統過濾 KBDB 零件宇宙，**只顯示相容的 UI 零件**（如下拉選單、開關）。不具備 trigger 能力的元件（如純文字標籤）會被自動隱藏，確保替換後系統絕對不會報錯。

## **三、 原子化組裝與極致解耦：CEO AI 與工匠 AI 的分工**

當企業主管提出需求：「我需要一個『輸入工號即可查詢員工打卡紀錄』的工具」時，這在 u6u 中**並不是一個單一零件**，而是一個由多個「原子零件」構成的**工作流 (Workflow)**。

### **1\. CEO AI 的動態組裝 (Macro Assembly)**

面對需求，大腦 AI (CEO AI) 會快速從 KBDB 挑選現成積木進行組合：

* **前端 Prototype 組合：** \<u6u-text-input\> \+ \<u6u-btn\> \+ \<u6u-text-field\>。  
* **後端 Pseudo Code 組合：** webhook\_receiver \>\> check\_kbdb(template\_name, value)。  
  AI 會自動用 Cypher 將前端的表單意圖連線到後端工作流。對不懂程式的主管來說，前端就是 Prototype，翻面的 Cypher 就是 Pseudo Code，整套系統瞬間組合完畢。

### **2\. 工匠 AI (Forge AI) 的原子生產線**

只有當現有零件庫缺乏特定原子時，機甲才會喚醒工匠 AI 進行開發。

**解耦哲學：** 後端零件開發時，根本不需要管前端零件長什麼樣子（是按鈕還是輸入框）。只要前端送來的 JSON 它能吃，就是合法的候選零件。

* **Step 1: 規格定義 (Interface Contract)**  
  工匠 AI 只在乎接收與回傳的 JSON 格式。  
* **Step 2: 打造純粹的邏輯黑箱 (後端 TinyGo WASM)**  
  工匠 AI 撰寫 Go 程式，編譯成 .wasm。絕對純粹的後端邏輯，沒有任何介面程式碼。  
* **Step 3: 獨立的前端零件生產 (若需要)**  
  獨立生成 Web Component（如 \<u6u-3d-pie-chart\>），只負責接收特定 JSON 來渲染畫面。  
* **Step 4: 註冊與編目 (Cataloging into KBDB)**  
  新積木註冊到圖資料庫，未來的 CEO AI 即可將其與任何既有的前端或後端元件進行無限的叉積組合。

## **四、 架構總結與終極產品體驗**

這套前端架構讓 u6u 成為一個\*\*「表裡如一」**的系統，成功創造了**「麻瓜的 ERP 幻覺」\*\*：

使用者不需要知道什麼是「前後端分離」、什麼是「API 串接」。他們只是覺得：

1. 拖拉了一個溫度計。  
2. 翻面把「數值更新」連線到「機台感測器」。  
3. 拖拉了一個紅按鈕放在旁邊。  
4. 翻面把「點擊」連線到「發送 Line 警報」。

在十分鐘的「繪圖」過程中，沒有寫一行程式碼，也沒有設定任何變數。但透過**前端 Web Components** 的視覺封裝、**智慧容器**的自動資料打包，以及**後端 TinyGo WASM \+ Cypher** 的無縫承接，他們在不知不覺中，就搭建出了一套具備微服務架構、高擴展性、且可部署至極限邊緣的企業級系統。