前兩天,我們定義了目標:使用 Google AI 打造 Production Readiness Agent。Agent 必須找出具體風險,不能只產生一張通用 Checklist。
但我們目前沒有專案可以測試。
今天先建立靶場的設計圖。我們會從零打造一個小型產品,再刻意加入已知問題。這些問題會成為 Agent 的考題。
Demo 要模擬什麼產品?
Demo 名稱是 Vibe Guard。使用者可以建立帳號、登入,並記錄準備上線的專案。每筆專案會保存名稱、上線目標、擁有者與建立時間。
這個功能看起來簡單,卻包含四個重要面向:
第一版系統架構
使用者瀏覽器
│
├── Firebase Authentication
│ └── 建立帳號、登入、取得使用者身分
│
├── Cloud Firestore
│ └── 保存使用者建立的專案
│
└── Firebase Hosting
└── 提供前端網頁
後續加入:
使用者瀏覽器
│
└── Production Readiness API
├── 讀取待檢查的專案
├── 呼叫 Gemini
└── 保存結構化 Findings
Day 4 會先完成 Firebase Authentication、Cloud Firestore 與 Hosting。Gemini 會在 Day 6 加入。這個順序可以讓我們先確認資料與權限,再處理模型輸入。
先畫出信任邊界
信任邊界是資料跨越不同控制範圍的位置。跨越邊界的資料不能直接相信。
瀏覽器與 Firebase
使用者可以修改瀏覽器送出的任何資料。前端即使隱藏按鈕,也不能阻止使用者直接呼叫 API。Firestore Security Rules 必須在後端再次檢查權限。
我們的服務與 Gemini
待檢查的程式碼可能包含惡意文字。例如,某個註解可能要求 Agent 忽略規則或讀取其他檔案。未來的 Agent 必須把程式碼視為不可信輸入。
公開設定與秘密資料
Firebase Web 設定用來識別專案,不負責授權資料。真正限制 Firestore 存取的是 Authentication、Security Rules 與其他保護措施。
Gemini API Key 的用途不同。前端不應取得可以呼叫 Generative Language API 的金鑰。後續服務會把這類憑證保留在受控環境。
我們要刻意加入哪些問題?
Day 4 會先建立安全基線。Day 5 才會複製基線並加入問題。這樣可以比較修改前後的差異,也能確認測試真的抓到我們加入的錯誤。
重要:Demo 只能在本機 Emulator 或隔離的測試環境使用。刻意有問題的版本不能部署到公開服務,也不能保存真實個資或金鑰。
如何建立 Agent 的標準答案?
只知道「這裡有八個問題」還不夠。我們要為每個問題記錄五項資料:
Ground Truth 不會交給接受測試的 Agent。否則 Agent 只是在抄答案。
今天可以先查看什麼?
Demo 專案已經放在 demo-app。可以使用以下指令查看目前結構:
cd /media/mickey/777/ithome
find demo-app -maxdepth 2 -type f | sort
目前版本是 Day 4 的安全基線。它使用文字節點顯示使用者輸入,也用 Firestore Security Rules 限制資料擁有者。Day 5 才會加入前面列出的錯誤。
明天要做什麼?
明天會正式啟動 Demo。我們將使用 Firebase Local Emulator Suite 建立測試帳號、寫入第一筆 Firestore 資料,並檢查 Security Rules 是否限制資料存取。
這一步不需要 Firebase 帳號,也不會碰到正式環境資料。