繳交方式：將你的 GitHub repo 網址貼到作業繳交區 作業性質：個人作業
使用 Antigravity Skill 引導 AI，完成一個具備前後端的 AI 聊天機器人。 重點不只是「讓程式跑起來」，而是透過設計 Skill，學會用結構化的方式與 AI 協作開發。
你的 GitHub repo 需要包含以下內容：
為以下五個開發階段＋提交方式各設計一個 SKILL.md：
| 資料夾名稱 | 對應指令 | 說明 |
|---|---|---|
prd/ |
/prd |
產出 docs/PRD.md |
architrcture/ |
/architecture |
產出 docs/ARCHITECTURE.md |
models/ |
/models |
產出 docs/MODELS.md |
implement/ |
/implement |
產出程式碼（HTML 前端 + Flask 後端） |
test/ |
/test |
產出手動測試清單 |
commit/ |
/commit |
自動 commit + push（使用者與 email 使用 Antigravity 預設值） |
用我設計的 Skill 產出的文件，包含：
docs/PRD.md— 產品需求文件，定義產品願景、目標使用者、功能優先級與成功指標docs/ARCHITECTURE.md— 系統架構文件，定義前後端架構、模組通訊與設計系統docs/MODELS.md— 資料模型文件，定義 TarotCard、Spread、DrawingSession 等資料結構
一個可執行的塔羅抽籤互動網站「神奇塔羅」，具備以下功能：
| 功能 | 說明 | 是否完成 |
|---|---|---|
| 對話狀態管理 | 支援多次抽牌 session，每次抽牌維持獨立狀態 | ✅ |
| 訊息系統 | 牌義結構包含 position、name、keywords、meaning、timestamp | ✅ |
| 對話歷史管理 | 可顯示並瀏覽過去的抽牌紀錄（LocalStorage） | ✅ |
| 上傳圖片或文件 | 使用 emoji 藝術替代牌面圖像，78 張牌各有獨立視覺呈現 | ✅ |
| 回答控制 | 支援「再抽一次」重新生成結果，可返回首頁中止流程 | ✅ |
| 記憶機制 | 使用 LocalStorage 儲存抽牌歷史，實現跨 session 持續性 | ✅ |
| 工具整合 | 串接 Flask 後端 API（/api/draw, /api/cards, /api/spreads） |
✅ |
在 screenshots/ 資料夾放入以下截圖：
chat.png：塔羅抽牌主畫面，包含完整的抽牌 → 翻牌 → 解讀流程history.png：抽牌歷史紀錄頁面，顯示多次 session 的切換
在本 README 的心得報告區填寫。
讓每個人都能輕鬆獲得塔羅牌的指引與啟發
「神奇塔羅」是一個沉浸式線上塔羅抽牌平台，支援完整 78 張塔羅牌組（22 張大阿爾克那 + 56 張小阿爾克那），提供 3 種經典牌陣，搭配精美的 3D 翻牌動畫與星空背景，為使用者帶來神秘、優雅的占卜體驗。
- 78 張完整牌組 — 包含 22 張大阿爾克那（含詳細牌義）與 56 張小阿爾克那（四花色各 14 張）
- 3 種牌陣 — 每日一牌（1 張）、三牌陣（3 張：過去/現在/未來）、凱爾特十字（10 張）
- 3D 翻牌動畫 — CSS 3D Transform 實現流暢的翻牌效果，支援正位/逆位
- 多面向解讀 — 每張牌提供總體、感情、事業面向解讀與行動建議
- 歷史紀錄 — 自動儲存至 LocalStorage，可回顧過去的抽牌結果
- 星空背景 — 動態星空粒子動畫，營造神秘氛圍
- 響應式設計 — 支援桌面、平板、手機各種裝置
w7-pr/
├── .agent/
│ └── skills/
│ ├── prd/SKILL.md # PRD 產出技能
│ ├── architrcture/SKILL.md # 架構文件產出技能
│ ├── models/SKILL.md # 資料模型產出技能
│ ├── implement/SKILL.md # 程式碼產出技能
│ ├── test/SKILL.md # 測試清單產出技能
│ └── commit/SKILL.md # 自動提交技能
├── docs/
│ ├── PRD.md # 產品需求文件
│ ├── ARCHITECTURE.md # 系統架構文件
│ └── MODELS.md # 資料模型文件
├── templates/
│ └── index.html # 前端頁面（純前端，可直接開啟）
├── screenshots/
│ ├── chat.png # 抽牌主畫面截圖
│ └── history.png # 歷史紀錄截圖
├── app.py # Flask 後端應用程式
├── requirements.txt # Python 依賴套件
├── .gitignore
└── README.md # 本檔案（含心得報告）
# 直接用瀏覽器開啟 HTML 檔案即可使用
open templates/index.html💡 此版本已將所有 78 張牌組資料與抽牌邏輯內嵌於前端 JavaScript，無需後端伺服器即可完整運作。
# 1. 安裝套件
pip install -r requirements.txt
# 2. 啟動伺服器
python3 app.py
# 3. 開啟瀏覽器
# http://localhost:5000| 層級 | 技術 | 用途 |
|---|---|---|
| 前端 | HTML5 + CSS3 + Vanilla JS | UI 介面與互動 |
| 後端 | Flask 3.1.1 | API 伺服器與模板渲染 |
| 字型 | Google Fonts (Noto Serif/Sans TC) | 中文字型優化 |
| 儲存 | LocalStorage | 抽牌歷史紀錄 |
| 動畫 | CSS 3D Transform + Keyframes | 翻牌動畫與星空背景 |
| 設計 | Glassmorphism + Dark Theme | 神秘優雅的視覺風格 |
| 方法 | 路徑 | 說明 |
|---|---|---|
| GET | / |
首頁（渲染模板） |
| POST | /api/draw |
抽牌 API（傳入 spreadId、question） |
| GET | /api/cards |
取得 78 張牌的基本資訊 |
| GET | /api/spreads |
取得所有牌陣資訊 |
curl -X POST http://localhost:5000/api/draw \
-H "Content-Type: application/json" \
-d '{"spreadId": "daily", "question": "今天的運勢如何？"}'
姓名：林伽紜 學號：D1149890
Q1. 你設計的哪一個 Skill 效果最好？為什麼？哪一個效果最差？你認為原因是什麼？
效果最好：
prd/PRD Skill 的效果最好，因為它的工作流程設計最完整。先用 Step 1 收集產品名稱、願景、目標使用者等基本資訊，再用 Step 2 引導功能分類（P0/P1/P2），最後用 Step 3 輸出一份結構化的文件。這種逐步引導、先問再寫的設計讓 AI 不會一次丟出一份空洞的模板，而是能根據我實際給的資訊客製化產出內容。最終產出的 PRD 涵蓋了 10 個功能、3 種使用者角色和完整的風險評估，品質遠超預期。
效果最差：
implement/Implement Skill 效果相對較差，原因是程式碼實作牽涉太多執行環境的細節，單靠文件規範很難預先涵蓋。例如 AI 最初產出的
index.html使用了 Jinja2 模板語法（{{ spreads | tojson }}），導致兩個問題：（1）IDE 報出 JavaScript 語法錯誤；（2）從檔案直接開啟時完全無法運作，因為 Jinja2 需要 Flask 伺服器渲染。這些能不能跑的問題需要實際測試才會發現，純文件規範無法預防。Skill 設計可以改進的地方是：加入獨立執行驗證的步驟，要求 AI 確保前端可以脫離後端獨立運作。
Q2. 在用 AI 產生程式碼的過程中，你遇到什麼問題是 AI 沒辦法自己解決、需要你介入處理的？
1. Jinja2 模板無法從檔案直接開啟
AI 產出的
templates/index.html使用了 Flask 的 Jinja2 語法（{{ }}和{% %}），這在透過python3 app.py啟動伺服器時運作正常，但我嘗試直接雙擊開啟 HTML 檔案時，整個牌陣選擇區域是空白的，抽牌功能完全失效。AI 無法自己發現這個問題，因為它只在伺服器端驗證過，是我實際操作後回報我從檔案開啟 index.html 是不能按抽牌的，AI 才理解問題所在，並將整個架構重寫為純前端版本。
反思：AI 在產出程式碼方面非常強大，但在驗證程式碼是否真的能用這件事上仍有盲點。它傾向於假設程式碼會在理想的環境中執行，而忽略了使用者實際的操作方式。作為開發者，我需要扮演最終測試者的角色，從使用者的角度去實際操作，才能發現 AI 遺漏的問題。