繳交方式：將你的 GitHub repo 網址貼到作業繳交區 作業性質：個人作業
使用 Antigravity Skill 引導 AI，完成一個具備前後端的 AI 聊天機器人。 重點不只是「讓程式跑起來」，而是透過設計 Skill，學會用結構化的方式與 AI 協作開發。
你的 GitHub repo 需要包含以下內容：
為以下五個開發階段＋提交方式各設計一個 SKILL.md：
| 資料夾名稱 | 對應指令 | 說明 |
|---|---|---|
prd/ |
/prd |
產出 docs/PRD.md |
architecture/ |
/architecture |
產出 docs/ARCHITECTURE.md |
models/ |
/models |
產出 docs/MODELS.md |
implement/ |
/implement |
產出程式碼（需指定：HTML 前端 + FastAPI + SQLite 後端） |
test/ |
/test |
產出手動測試清單 |
commit/ |
/commit |
自動 commit + push（需指定：使用者與 email 使用 Antigravity 預設值） |
用你設計的 Skill 產出的文件，需包含：
docs/PRD.mddocs/ARCHITECTURE.mddocs/MODELS.md
一個可執行的 AI 聊天機器人，需支援以下功能：
| 功能 | 說明 | 是否完成 |
|---|---|---|
| 對話狀態管理 | 支援多聊天室（session），維持上下文 | [O] |
| 訊息系統 | 訊息結構包含 role、content、timestamp | [O] |
| 對話歷史管理 | 可顯示並切換過去的對話紀錄 | [O] |
| 上傳圖片或文件 | 支援使用者上傳檔案作為對話內容 | [O] |
| 回答控制 | 提供重新生成（regenerate）或中止回應的功能 | [O] |
| 記憶機制 | 儲存使用者偏好，實現跨對話持續性 | [O] |
| 工具整合 | 串接外部 API，使聊天機器人具備實際操作能力 | [O] |
在 screenshots/ 資料夾放入以下截圖：
chat.png：聊天機器人主畫面，需包含至少一輪完整的對話history.png：對話歷史或多 session 切換的畫面
在本 README 的心得報告區填寫。
your-repo/
├── .agents/
│ └── skills/
│ ├── prd/SKILL.md
│ ├── architecture/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
│ └── skill.png
├── main.py
├── database.py
├── services/
├── requirements.txt
├── .env.example
└── README.md ← 本檔案（含心得報告）
# 1. 建立虛擬環境
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
# 2. 安裝套件
pip install -r requirements.txt
# 3. 設定環境變數
cp .env.example .env
# 編輯 .env，填入 GOOGLE_API_KEY
# 4. 啟動伺服器
uvicorn main:app --reload
# 開啟瀏覽器：http://localhost:8000姓名：蔡秉倫 學號：d1245587
Q1. 你設計的哪一個 Skill 效果最好？為什麼？哪一個效果最差？你認為原因是什麼？
效果最好的 Skill：
/architecture與/api-design。 因為將後端 FastAPI 與前端的原生 JavaScript/HTML 介面切割得非常清楚，提供了明確的實作邊界。AI 在有了明確架構藍圖後，撰寫出來的程式碼穩定度大幅提升，不會隨意去安裝不需要的套件或引入過度複雜的框架。效果最差的 Skill：
/test或/commit。 測試階段因為依賴具體的執行環境，AI 有時候會給出純理論的測試腳本，但在實際網頁 DOM 渲染或 API 串接上（例如跨域或檔案上傳），手動測試的邊界條件依然需要人類實際去點擊才能真正抓出問題。而自動 Commit 部分有時會因為環境的 Git 設定問題導致無法順利推播。
Q2. 在用 AI 產生程式碼的過程中，你遇到什麼問題是 AI 沒辦法自己解決、需要你介入處理的？
- Gemini API 的配額與版本相容性 (Rate Limit & 404 Errors)： AI 原本直接寫死使用最新版的
gemini-2.0-flash，但我在測試時遇到了 Google API 免費額度耗盡 (RESOURCE_EXHAUSTED) 以及部分版本不支援 (NOT_FOUND 404) 的致命錯誤，導致伺服器回傳 HTTP 500。這部分 AI 無法預知我本地端 API Key 的權限狀態，最後是我主動提供 Terminal 的錯誤 Log，並要求 AI 實作「多模型自動降級與輪替機制 (Fallback)」，才徹底解決 500 錯誤。- 前端錯誤捕捉與顯示問題： 原本 AI 實作的
main.js在遭遇後端失敗時，只會在前端籠統地顯示「System Error: Unable to process request」，使得除錯非常困難。我必須介入指示 AI 去修改try-catch與 JSON 解析邏輯，把後端的詳細 Traceback 暴露到前端與終端機上，才有辦法釐清是模型問題，並成功將專案轉型為「旅遊與美食專用的主題機器人」。