從手繪介面到資料庫地基：AI遇弱則弱，如何規劃具備資安邊界的雛形

在各級學校與非資訊科系的課堂上，我們常能看見學習工具帶來的顯著落差。

國中小階段推廣程式教育，Scratch或Blockly這類圖形化積木介面非常容易被孩子理解。色彩鮮明、卡榫直觀，拖拉幾下就能看到角色在畫布上跳動；但隨著年齡增長，走進高中甚至大學，非資訊背景的學生面對終端機冷冰冰的文字指令、複雜的巢狀迴圈與抽象邏輯時，依然能保持熱情的人屈指可數。

生成式AI的出現，看似替這道鴻溝鋪上了一層平坦的柏油路。

現在你只要拿出一張白紙，隨手畫出一個網頁的導覽列、搜尋框與內容清單，拍照丟給具備多模態視覺能力的模型（如Gemini或Claude），短短幾秒鐘，前端的HTML、CSS與排版程式碼就整整齊齊吐了出來。

看著螢幕上那個會動的頁面，很多人忍不住驚呼：「太神了，人人都能當全端工程師了！」

但介面的生成只是浮在海面上的10%，真正決定一個系統能不能穩定存活的90%，深埋在看不見的地基底下。

一、 介面好畫，地基難築：入門者最難從AI身上抄到的「資料庫功夫

」

為什麼很多初學者拿著AI生成的華麗介面，專案依然在一週後徹底崩塌？

因為介面只是外皮（UI），而資料庫設計（Database Design）才是系統的骨架。

在關聯式資料庫的世界裡，有太多的關鍵決策不是單純丟一句提示詞就能解決的：

• 這個欄位該開成字串（String）還是數值（Integer）？
• 歷史訂單紀錄是該直接覆寫，還是該逐筆追加（Append）以保留時間序列特徵？
• 學生選課的清單，該拆成幾張表格才能避免資料冗餘與異常更新？
• 哪一些快取數據可以放手捨棄，哪一些日誌必須永久固化其中？

這些資料儲存的取捨與欄位規範，大語言模型在缺乏完整業務脈絡的情境下，根本無從幫你做主。如果你自己的腦袋是一團混亂，AI只會順著你的模糊提問，給出看似能跑、實質上缺乏正規化約束的脆弱程式碼。

只要資料一多、只要出現跨表查詢，整個系統立刻陷入效能卡死與資料錯亂的災難。

這正是為什麼在程式入門教學中，我始終主張：專業教育者或資深前輩最大的價值，不是教學生怎麼刻按鈕，而是擔任那個「引路磚」，陪著他們把資料欄位的一格一格排正。

把資料的流向理清了、表格之間的關聯鍵（Primary Key / Foreign Key）畫明白了，前後端的資料串接與功能實作，速度往往快得驚人。

二、 資安的敬畏心：會員、訂單與金流，交給專業或第三方平台

當系統的骨架能跑通之後，下一個等在轉角處的巨坑，就是「資訊安全（Cybersecurity）」。

很多初學者興致勃勃地對AI說：「請幫我寫一個會員登入系統，要有註冊、密碼驗證、購物車結帳，還要串接信用卡付款。」AI當然也很聽話地吐出了看似完整的程式碼。

但在專業工程師眼裡，這份未經資安防護審核的程式碼，簡直像是一座不設防的毛胚屋：

看清這些代價，總是不斷告誡：「涉及會員個資、訂單排程與金流交易，千萬不要單憑AI幾行代碼就硬上，老老實實交給專業團隊，或者善用成熟的第三方平台。」

在實務專案與教學中，最常採取的避險策略是：

• 金流與結帳直接跳轉至經過嚴格金融合規的專業通道
• 資料暫存與日誌調度，依託在既有權限防護下

利用成熟的第三方平台作為安全護城河，你的系統不需要背負沉重的資安維運代價。

而手繪出來的前端雛形與初版腳本價值在於充當跨領域溝通的翻譯橋樑。當你帶著一個會動的Prototype走向專業工程師或外包團隊時，你不需再用抽象的形容詞比手畫腳。工程師一眼就能看懂你的業務流程，你也因此能聽懂專業人士指出的資安漏洞在哪裡。跨域的對話，從那一刻起才真正接軌。

三、 AI遇弱則弱、遇強則強：解構「垃圾進，垃圾出」的規律

回過頭審視我們與AI的互動模式。人機協作研究中歸納出一條鐵律：「生成式AI是一面極度誠實的鏡子，遇弱則弱，遇強則強。」

低結構互動：輸入含糊願望 ➔ 模型機率瞎猜 ➔ 產出空洞罐頭

系統化互動：鎖定邊界條件 ➔ 調用具體規格 ➔ 產出高精確解方

電腦科學界幾十年來常講一句話：「垃圾進，垃圾出（Garbage in, garbage out）。」

很多人抱怨AI給出的回答空洞、程式碼跑不動、企劃案像通俗廢話，原因在於提問者把未經消化的大腦雜訊，一股腦倒進了輸入框。

要想讓AI穩定產出符合專業預期的成果，我們必須建立一套不可跳步的「三階互動流程」：

階段一：目標設定（The Goal）

不要漫無目的地閒聊。先清楚界定「這一次對話的終點線在哪裡」：

• 是一張能夠在手機瀏覽器點擊的單頁式預約表單？
• 是一段能自動抓取未繳費名單並推播LINE通知的Google Apps Script函式？
• 還是一篇針對傳產企業主管、闡述資安號誌模型的兩千字專欄文章？

明確的成果形態，決定了AI底層神經網路的調度路徑。

階段二：資源準備（Preparation）

巧婦難為無米之炊。在要求AI動工前，先幫它備齊實體積木：

• 資料環境： 資料存放在哪張試算表？工作表名稱是什麼？
• 欄位規格： 包含哪些欄位（如Timestamp、UserID、Status）？
• 流程標準： 哪一步先執行、哪一步是觸發條件？
• 工具邊界： 使用的是免費配額，還是需要調用外部 API？

階段三：細節刻劃（Refinement）

最後一步，用精確的限制條件（Constraints）壓制模型的發散本能：

• 語氣與風格： 專業嚴謹還是冷酷的格式化解析？
• 專有名詞： 精準帶出領域術語（如Debounce、Webhook、JSON Schema），杜絕模糊泛稱。
• 呈現格式： 強制要求Markdown表格、Mermaid架構圖或是特定JSON格式，確保後續程式碼能百分之百安全解析。

四、 實戰法：條列指出，拒絕一次性許願

學會了三階規劃，具體坐在螢幕前時該如何打字？

請記住一個樸素的心法：不要試圖在第一句話裡塞進整個宇宙。沒辦法一次完整敘述沒關係，一步一步來，條列式指出。

很多人把AI當成神燈精靈，打下一行：「幫我做一個可以讓學生預約諮詢並自動寄信確認的系統。」這種單行句許願，往往換來一個前後端混雜、資料庫結構不明的半成品。

成熟的人類建築師，會像工程交接一樣，將需求、規格與目標拆解為清晰的條列清單：

示範

你現在是一位熟稔 Google Workspace 與 LINE Messaging API 的全端架構師。
我目前正在規劃一個「學生課後諮詢預約小工具」，請依據以下三維規格協助我梳理系統骨架：

1. 目標設定：
- 終端成品：一個跑在 Google Apps Script 上的 Web App（SPA單頁介面），結合 LINE Bot 即時發送確認訊息。
- 驗收標準：學生填表後，資料必須安全寫入 Google Sheets，且不需架設任何付費虛擬主機。

2. 資源與環境準備：
- 資料庫：Google Sheets（工作表名稱：Appointment_Logs）。
- 既有欄位：Timestamp、StudentID、StudentName、BookingDate、TimeSlot、Status。
- 外部通道：已備妥 LINE Channel Access Token 與 Google AI Studio API Key。

3. 細節與邊界要求：
- 前端介面：手繪版型包含「學生姓名輸入框」、「日期挑選器」與「送出按鈕」，請生成乾淨的 HTML/CSS。
- 資料庫取捨：預約狀態預設為 [Pending]，禁止在前端處理商業邏輯。
- 資安防線：API Key 嚴禁寫死在前端 JavaScript 中，必須透過 GAS 後端 PropertiesService 讀取。
- 請先不要一次產出全部程式碼，請先列出「資料庫欄位對齊表」與「系統資料流三步驟」，待我確認後再進行下一步。

把「背景、資源、規格、安全底線與輸出節奏」條列攤開時，AI就被定格為一位訓練有素的高階工程助理。

結語：

技術工具的演進只會越來越快。未來，手繪草圖轉程式碼的工具無疑會越來越擬真，一鍵生成全套系統的宣傳也只會越來越喧鬧。但無論演算法如何翻新，軟體工程的定律始終未變： 介面只是皮囊，資料結構才是筋骨，而資安與責任承擔則是不可踰越的底線。

不要因為AI能快速生出畫面，就誤以為自己跨過了思考的苦工； 更不要在複雜的商業邏輯面前逞強，把高風險的金流與個資押在一串未經查驗的機率文字上。

扎扎實實把資料庫的欄位摸透，依循「目標、資源、細節」的三階節奏，一步一腳印向AI精準下達規格。