系統架構摘要 (Executive Summary)
本報告深入剖析「Gem 提示詞產生器」的微型無伺服器架構。設計核心在於不依賴高成本雲端主機的前提下，利用純前端靜態沙盒、Google Apps Script (GAS) 輕量代理，以及客製化大模型對齊技術，達成 100% 的用戶隱私保護與極低運行成本。本文將從系統設計、流量工程、安全沙盒與模型優化等四個維度，配合實際工具介面，詳實拆解其生產環境實踐。
在生成式 AI (Generative AI) 奇點爆發的時代下，軟體開發的底層邏輯依然如舊：工程的本質，始終是在有限的資源限制下，追求系統的極簡、安全性、與使用者體驗的完美平衡。
當我們規劃設計 Gemify 旗下最受歡迎的工具——「Gem 提示詞產生器 (prompt-generator)」時，我們將這套原則完全實裝。這款提示詞產生器在前端沙盒、無伺服器 (Serverless) 防爆限流、社群 Prompt 注入防禦、以及低溫 0.3 AI 專家調教上，皆有著嚴謹的核心架構考量。這份文檔將作為一份現代微型系統架構師的實踐指南。
一、 系統概述與用戶端安全沙盒 (Client-Side Sandboxing)
本章核心：隱私防線與前端規則引擎
解析如何透過純前端規則引擎，在無後端伺服器的狀態下，以 0 毫秒延遲拼接生成符合 RTF 框架的提示詞，保障敏感數據絕不流出本機瀏覽器沙盒。
在評估高流量微型工具的架構時，首要原則在於確立「隱私與成本的防禦邊界」。任何頻繁將用戶敏感輸入發送至雲端伺服器的設計，都會在無形中增加網路延遲、提高運維成本，並暴露出資料外洩的資安隱患。
架構師心法：「最好的伺服器就是不要伺服器，最安全的資料庫就是不要儲存資料。」
因此，「Gem 提示詞產生器」的第一層防禦，是基於原生 Astro 靜態網站生成架構 與 Tailwind CSS v4 引擎 建構的用戶端沙盒規則引擎 (Client-Side Rules Engine)。
本機端拼接引擎採用標準的 RTF (Role-Task-Format) 指令範本庫，直接在用戶瀏覽器的本機執行緒中進行字串正規化與動態拼接。在基本生成模式下均 100% 在瀏覽器沙盒內完成，保證了符合 本機端資料隱私保護 ，並將雲端主機持有費用降低至零。
圖 1.1：本機端參數設定與 AI 平台選擇面板
二、 流量工程與雙重防護限流策略
本章核心：軟性時間鎖與無伺服器限流體系
詳解如何藉由前端黃金 60 秒倒數計時鎖，提高使用者網頁停留時間，並結合 GAS 的虛擬 UUID 與全站總調用限制，建立多層防禦體系。
當系統需要提供雲端高階 AI 潤色服務時，後端直連 API 往往會面臨高頻刷量 (DDoS) 以及免費額度耗盡的問題。這是一場需要結合用戶心理學與系統流量工程的防禦博弈。
2.1 黃金 60 秒 Retention Lock (時間留存鎖)
為防範用戶「開屏即點、無效生成、隨即離去」的高流失行為，本架構在前端部署了 60 秒軟性解鎖機制。用戶首次訪問工具時，雲端高階模式處於凍結狀態，強制其優先使用本機極速拼接。這 60 秒的等待期，成功引導用戶熟悉基礎功能並閱讀技術科普。
這項設計將網站的 平均停留時間 (Session Duration) 從 5 秒大幅拉長至 75 秒以上，使 Google 爬蟲與 AdSense 權重評分顯著提升，並過濾了高達 80% 的空白無效請求。
2.2 GAS 雙重防爆限流控制器
後端透過 Google Apps Script (GAS) 與 Google Sheets 組裝了高效的 API 限流控制機制 。 前端生成虛擬 UUID 並檢查日調用次數，強制設定單人每日最高調用 5 次高階 AI 生成，全站每日總上限 1000 次，達到臨界點即自動無感降級回純本機端規則引擎拼接，確保網頁可用性始終為 100%。
圖 1.2：解鎖倒數進度條與雲端高階模式配額狀態
<!-- 倒數中畫面 -->
<div id="countdownBox" class="w-full space-y-2">
<div class="flex justify-between text-xs font-semibold">
<span id="countdownUpgrade" class="text-indigo-300 flex items-center">免費升級倒數中...</span>
<span id="countdownText" class="text-white">60秒</span>
</div>
<div class="w-full bg-slate-700 h-2.5 rounded-full overflow-hidden">
<div id="progressBar" class="bg-gradient-to-r from-blue-500 to-indigo-500 h-full rounded-full transition-all duration-1000 ease-linear" style="width: 100%;"></div>
</div>
<p id="countdownDesc" class="text-[10px] text-center text-slate-400">停留期間可先使用基本模式，倒數完自動解鎖高階模式</p>
</div>
三、 安全防護與 Prompt 注入漏洞防禦
本章核心：非信任資料的安全隔離與審核機制
分析 AI 時代新型態注入威脅的防範手段，解密社群範本數據如何透過待審核（Pending）隔離沙盒，防止惡意代碼與安全漏洞外流。
在傳統 Web 安全中，我們致力於防範 SQL 注入攻擊 與 跨站腳本攻擊 (XSS) 。而在人工智能大潮下，新型安全威脅——提示詞注入攻擊 (Prompt Injection) 成為了防禦重點。
架構心法：「永遠不要信任任何來自用戶端的輸入，不論是參數、程式碼，還是提示詞文字。」
我們的「社群範本共享」機制允許用戶提交客製化提示詞。為了阻斷惡意提示詞在他人套用時篡改 AI 運作邏輯，我們在後端構建了 Pending 隔離安全沙盒：
寫入 Sheets 資料庫暫存佇列
任何由前端訪客自由提交的共享範本，在 GAS API 寫入 `PromptTemplates` 資料庫時，其 status 狀態欄位皆被強制、硬編碼初始化寫入為 Pending。
Astro 離線安全拉取核心
只有經由後台管理員人工安全語意與程式碼審核、確認無惡意代碼後，手動覆寫為 Approved 的範本，才會被 API 傳送並編譯輸出。
四、 大語言模型對齊與低溫專家調教 (LLM Alignment)
本章核心：降低隨機性與消除提示詞噪音
探討如何限制 LLM 溫度參數以提高輸出確定性，配合嚴格的角色框架，杜絕大模型的幻覺與冗餘問候語，提供工業級精密 Prompt。
在調用雲端大模型進行優化時，大模型預設的發散性經常會產生「囉唆、寒暄或格式混亂」的現象，這在提示工程中被稱為提示詞噪音 (Prompt Noise)。若用戶將含有噪音的提示詞直接部署於 Gems 或 GPTs 中，會嚴重稀釋其底層神經元權重。
我們在 GAS 發送至 Gemini 1.5/2.5 Flash API 的 Payload 中實裝了高度精準的 模型對齊 (LLM Alignment) 技術 ：
- 低溫控制 (Temperature 0.3)：將 溫度參數 (Temperature) 強制限制為 0.3。低隨機性會強迫模型收斂創造力，輸出高度 stable、精準的工程藍圖。
- 專家角色指令對齊：在後端 System Instruction 中下達高度約束：「不要進行任何無意義的問候或多餘 Markdown 說明，直接以結構化格式輸出提示詞主體。」
生成的提示詞
你現在是一位專業的文案總監...
</role>
<core_task>
協助審查使用者的社群文案...
</core_task>
你現在是一位專業的文案總監...
## 🎯 核心任務 (Core Task)
你的主要工作與職責如下...
圖 1.3：大模型在不同溫度參數 (Temperature) 下的結構化輸出差異
五、 結語：架構師的減法藝術
本段綱要：回歸系統工程的實踐本質
總結三十年系統設計哲學：優秀的架構不取決於堆疊複雜度，而在於如何用極簡、低成本、高防禦性的思維解決現實痛點。
從早期的實體主機，到如今的無伺服器微型混合架構，系統工程的載體在變，但「在資源邊界下尋找最優解」的本質從未動搖。
「Gem 提示詞產生器」的架構演進，正是這條原則的具體實踐。我們不追求昂貴的伺服器集群或鋪張的 API 預算，而是透過前端沙盒的安全設計、巧妙的時間留存博弈、嚴謹的防爆限流、以及低溫模型對齊，達成了一個高效、永不卡死的穩定生態。
優秀的架構師，始終在追求「減法」的藝術：先定義防禦邊界，再約束核心邏輯，最後將安全徹底鎖在最底層。