從一次生成走向可探索的資料應用，走完從技能到生產級專案的完整閉環

恭喜你！歷經 30 天的深度探索，我們從最底層的 JVM Agentic AI 核心哲學（Day 01～04），走過 Embabel GOAP 目標導向規劃與黑板狀態機（Day 05～10），完成了 工程維運、測試體系與可觀測性防線（Day 11～20），接著掌握了 現代 Generative UI 核心框架 json-render 的 Flat Spec、Catalog 與串流漸進解析（Day 21～25），最後在過去五天將這兩個強大技能合成為一個具備生產級強度的動態儀表板專案（Day 26～29）。

而這 30 天談過的所有觀念——GOAP 規劃、黑板狀態、確定性資料、Flat Spec、串流容錯、稽核與測試——最後都被濃縮成一套可以直接載入使用的技能（Skill）。換句話說，你不需要把 30 篇文章重讀一遍，也不必每開一個新專案就重新摸索一次架構：把技能載入 Claude Code 這類支援 Skill 的環境，就能用接近對話的方式，把一個 Embabel + json-render 的全端 AI 專案從零建起來。

所以最後一天，我們要完成三件收官大事：

1. 交代這 30 天的精華如何濃縮進技能，以及怎麼用它輕鬆長出一個全端 AI 專案。
2. 將靜態儀表板升級為「可互動、可下鑽探索（Interactive Drill-down）」的動態應用。
3. 交付一份企業級「生產上線 10 大檢核清單（Production Readiness Checklist）」與 30 天完整技術全景圖。

1. 30 天的精華，都濃縮在這套技能裡

技能不是拿來查 API 的線上文件，它更像一位已經讀完這 30 天、並且會逼你把防線補齊的資深隊友：先把需求整理成可執行的開發計畫，再建立 Embabel 後端 Agent 與資料流程，接著長出 json-render 前端與串流契約，最後補上測試、觀測、下鑽與上線檢核。你仍然要提供真實的業務規則與資料來源——這是技能不會、也不該替你決定的部分——但架構不必從頭想，關鍵防護也不會漏掉。

這套技能來自 ai-agent-dev-guide，包含三個互相銜接的開發角色：

實際開發時怎麼使用

1. 先用入口技能建立專案藍圖：寫清楚使用者要解決的問題、3 個 MVP 查詢、資料來源、允許的 UI 元件，以及哪些決策不能交給 LLM。
2. 再用 Embabel 技能開發後端：先產出 GOAP action table，再實作 Java domain records、正常完成 Goal、安全降級 Goal、工具與測試；數字、權限、門檻和資料列由程式負責。
3. 接著用 json-render-ui 技能開發前端：固定 DashboardSpec 的 flat tree，讓後端 catalog 與前端 registry 對帳；以 fetch + ReadableStream 接收 POST SSE，經過 lenientParse → sanitize → render 後逐步呈現畫面。
4. 最後用整合流程完成驗收：確認 3 個自然語言查詢都能產生合法 spec，進度與成本可見，未知元件不會白屏，使用者可以下鑽，且後端、前端與 E2E 測試都通過。

換句話說，30 天課程提供的是觀念與範例，技能則把這些內容固化成「建立專案 → 開發後端 → 開發前端 → 串接 → 測試 → 上線」的可重複工作流。觀念會忘，工作流不會——這正是有了技能之後，要生出一個 Embabel + json-render 全端 AI 專案會輕鬆這麼多的原因。

理解了工具，接下來我們就用它來完成最後一塊拼圖：讓儀表板從「看完就結束」變成「可以一路追問下去」。

2. 今天要解決的痛點與核心觀念

痛點背景：AI 生成應用走向生產的最後一哩路

1. 一次性死胡同（One-shot Dead End）：傳統 AI 生成的圖表看完就結束了，當主管看到「東京五日遊花費 45,000」想進一步看明細時，必須手動重新打字發問。
2. 併發重入災難（Concurrent Re-entrancy）：使用者在生成過程中狂點其他按鈕，觸發多條 SSE 串流通道併發寫入，導致前端狀態混亂。
3. 上線無檢核標準：沒有系統性的安全性、成本預算、快取防護與相容性檢查清單，上線第一天就遭遇 Prompt 注入或 Token 預算超標。

觀念圖解：動態下鑽閉環（The Drill-down Loop）

3. 官方核心技術依據與架構深度

1. 宣告式下鑽模板（Declarative DrillTemplate）

在 json-render 規範中，我們不讓前端寫死業務路由，而是由後端 Action 在組裝 DataTable 或 MetricCard 時，於 Props 中宣告 drillTemplate：

{
  "type": "DataTable",
  "props": {
    "columns": [...],
    "rows": [...],
    "onRowClickAction": {
      "type": "DRILL_DOWN",
      "template": "深入分析客戶 {customerId} 在 {date} 的 {destination} 行程明細"
    }
  }
}

前端只需要一個通用的 onDrill(interpolatedQuery) 回呼函式，就能自動實現無縫的深層數據鑽取！

2. 生產上線 10 大黃金檢核清單（Production Checklist）

4. 完整程式碼實戰（Production-Ready Code）

以下提供：

1. 前端動態下鑽處理器與防重入鎖（React）
2. 端到端自動化驗收測試（JUnit 5 Integration Test）

1. 前端動態下鑽實作

// src/components/interactive/DrillDownHandler.tsx
import React, { useState } from 'react';

interface DrillDownProps {
  onExecuteQuery: (query: string) => void;
  isBusy: boolean;
}

/**
 * 通用動態下鑽處理器
 */
export const useDrillDown = ({ onExecuteQuery, isBusy }: DrillDownProps) => {
  
  /**
   * 處理表格點擊下鑽
   * @param template 下鑽模板字串 (如: "深入分析客戶 {customerId} 的消費")
   * @param rowData 當前點擊的資料列物件
   */
  const handleRowDrill = (template: string, rowData: Record<string, any>) => {
    if (isBusy) {
      console.warn("當前正在生成中，略過重複點擊");
      return;
    }

    // 將模板中的 {key} 替換為真實資料
    let interpolated = template;
    for (const [key, value] of Object.entries(rowData)) {
      interpolated = interpolated.replace(new RegExp(`\\{${key}\\}`, 'g'), String(value));
    }

    console.log("[Drill-down] 觸發下鑽查詢:", interpolated);
    onExecuteQuery(interpolated);
  };

  return { handleRowDrill };
};

2. 端到端自動化驗收測試（E2E Integration Test）

package com.antechinus.travel.integration;

import com.antechinus.travel.domain.UserQuery;
import com.antechinus.travel.spec.DashboardSpec;
import com.embabel.agent.api.EmbabelClient;
import com.embabel.agent.api.ProcessResult;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.ActiveProfiles;

import static org.assertj.core.api.Assertions.assertThat;

/**
 * 全系統端到端驗收測試
 * 驗證 3 大核心業務場景是否均能穩定產出合規之 DashboardSpec
 */
@SpringBootTest
@ActiveProfiles("test")
class FullstackE2EVerificationTest {

    @Autowired
    private EmbabelClient embabelClient;

    @Test
    @DisplayName("驗收場景 A：查詢客戶 1001，應成功產出包含 Stack, MetricCard, DataTable 的合法 Spec")
    void testScenarioA_CustomerOverview() {
        UserQuery query = new UserQuery("查詢客戶 1001 的年度消費與旅遊偏好");

        ProcessResult<DashboardSpec> result = embabelClient.goal(DashboardSpec.class)
                .withInput(query)
                .run();

        // 1. 流程必須成功
        assertThat(result.isSuccess()).isTrue();
        DashboardSpec spec = result.getOutput();

        // 2. 驗證 Flat Spec 結構完整性
        assertThat(spec.root()).isEqualTo("root_stack");
        assertThat(spec.elements()).containsKey("root_stack");
        assertThat(spec.elements()).containsKey("elem_table");

        // 3. 驗證資料確定性 (DataTable rows 不可為空)
        var tableElement = spec.elements().get("elem_table");
        assertThat(tableElement.type()).isEqualTo("DataTable");
        assertThat(tableElement.props()).containsKey("rows");
        
        var rows = (java.util.List<?>) tableElement.props().get("rows");
        assertThat(rows).isNotEmpty();
    }

    @Test
    @DisplayName("驗收場景 B：輸入無效客戶編號，系統應順利降級而非崩潰")
    void testScenarioB_InvalidCustomerFallback() {
        UserQuery query = new UserQuery("查詢客戶 -999 的資料");

        // 嘗試以通用目標執行
        var result = embabelClient.run(query);

        // 系統必須優雅終止，不可拋出未捕獲例外
        assertThat(result.isCompleted()).isTrue();
    }
}

5. 實機畫面：從一次生成走向可探索

最終成果：先查「營收前三的客戶」得到排行表格（第 1 層），點選任一列即下鑽出該客戶的 360 綜合分析（第 2 層）——LTV、訂單歷史、工單分類、AI 風險提醒與行動建議一次展開，上一層儀表板凍結保留在上方形成可回溯的探索軌跡。這就是 30 天旅程的終點：不只是生成一張畫面，而是一個可以一路追問下去的資料應用。

6. 今日動手實作任務與完賽總結

🛠️ 今日實作任務

1. 執行端到端測試：運行 FullstackE2EVerificationTest，確保測試全部綠燈通過。
2. 進行生產清單檢核：對照「生產上線 10 大檢核清單」，逐一確認專案的代碼與配置是否全部達標。
3. 體驗動態下鑽：在前端頁面中點擊 DataTable 的任意一列，體驗自然語言二次下鑽生成的流暢閉環！

🎓 完賽總結：核心心法

「演算法管邏輯，Java 管數據，LLM 管溝通，Catalog 管邊界。」

當我們把不可預測的語言模型，妥善安置在 Embabel 確定性的 GOAP 導航軌道 與 json-render 受控的 UI 白名單 之中時，AI 就不再是一個隨機說胡話的玩具，而是真正能夠被企業信任、維運、測試與規模化落地的強大生產力工具。

🔍 最後一件事：能跑不等於能交付，可追蹤審查才是

如果這 30 天只讓你帶走一句話，我希望是這句：AI 應用真正的門檻，不在於它能不能生出畫面，而在於出事那天你能不能說清楚它為什麼這樣做。

Demo 只需要跑得起來，生產系統卻要面對「這個數字哪來的？」「誰核准的？」「這次為什麼比上次貴三倍？」這些會被追問到底的問題。而這正是前面那些看似麻煩的設計真正的用意：

• 每一步都留下證據：Day 17 的 ActionAudit 讓每次 Action 執行都帶著 traceId、耗時、Token 與成本落地，事後可以整條回放，而不是翻著一片狼藉的日誌猜測。
• 關鍵決策留給人：Day 19 的人工審查關卡確保高風險行為不會在無人知情的情況下發生，同意與駁回本身也是稽核紀錄的一部分。
• 數字不經 LLM 轉手：金額與資料列由 Java 填入，因此每個數字都能往回追到來源系統，而不是「模型說的」。
• 邊界寫在契約裡：Catalog 與 Flat Spec 讓「允許出現什麼」是白紙黑字的白名單，而非靠事後人工目視檢查。
• 下鑽軌跡即審查軌跡：今天完成的下鑽堆疊，讓每一層追問都保留在畫面上，使用者的探索路徑本身就是一份可回溯的說明。

不可追蹤的 AI 系統，會在第一次出錯時失去所有人的信任；可追蹤的 AI 系統，就算出錯也還能被修好、被交代、被繼續用下去。能不能上線，從來不是看它跑得多順，而是看它能不能被審查。

感謝你完成這趟 30 天的旅程，這套架構與這份可稽核的紀律，將成為你未來打造任何企業級 AI 應用的最堅實地基！🚀