還記得 Day 1 的時候，我替這個系列取了名字：
Java × AI：30 天打造智慧健康助理
當時的想法其實很簡單。
我希望透過這次鐵人賽，從 Java 和 Spring Boot 的基礎開始學習，一步一步做出一個可以記錄健康資料，甚至能夠結合 AI 的小專案。
一開始只是想完成 BMI 計算功能。
後來慢慢加入飲水紀錄、睡眠紀錄、資料庫、AI 健康摘要、多輪對話，最後甚至做出了可以在瀏覽器操作的聊天網頁。
雖然這個專案距離真正可以公開使用的健康管理系統還有一段距離，但對我來說，已經是一次很完整的學習經驗。
今天是整個系列的最後一篇文章。
所以不打算再加入太多新功能，而是想好好整理這 30 天完成的內容，回顧整個專案的架構，並且進行一次完整的功能測試。
最後也想分享這段時間遇到的問題，以及我從這次挑戰中學到的事情。
在開始這個系列之前，我對 Java 的理解主要還停留在程式語言本身。
例如：
public class Main {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
我知道 Java 可以寫程式，也知道它經常被用在後端開發。
但如果要我回答：
「Java 到底要怎麼做成一個可以使用的應用程式？」
其實我沒有那麼清楚。
像是：
這些問題在一開始都讓我有點困惑。
所以我希望透過一個具體的專案，把這些概念串在一起。
而健康管理是一個相對容易理解的主題。
像是：
今天喝了多少水？
昨天睡了幾個小時？
我的 BMI 是多少？
這些都是生活中常見的問題。
如果能夠將這些資料記錄下來，再透過 AI 整理成自然語言摘要，感覺就能做出一個有實際應用情境的小系統。
於是，這次的智慧健康助理專案就開始了。
回頭看這 30 天，我覺得最有趣的地方是：
每一天學習的內容其實都不算特別複雜。
但當這些功能慢慢累積起來，就變成了一個完整的專案。
以下是這次鐵人賽的開發歷程。
| 天數 | 主題 | 主要學習內容 |
|---|---|---|
| Day 1 | 專案動機 | 為什麼想使用 Java 與 AI 打造健康助理 |
| Day 2 | 需求規劃 | 確認健康助理需要哪些功能 |
| Day 3 | 系統架構 | 認識前端、後端、資料庫與 AI |
| Day 4 | 建立專案 | 使用 Spring Initializr 建立 Spring Boot |
| Day 5 | 第一支 API | 建立 Hello World REST API |
| Day 6 | 接收參數 | 使用 @RequestParam |
| Day 7 | BMI 計算 | 使用 Java 實作 BMI 公式 |
| Day 8 | JSON 回傳 | 讓 API 回傳結構化資料 |
| Day 9 | POST API | 使用 @RequestBody 接收 JSON |
| Day 10 | 分層設計 | 認識 Controller 與 Service |
| Day 11 | 資料驗證 | 使用 Jakarta Validation |
| Day 12 | BMI 分類 | 加入成人 BMI 分類規則 |
| Day 13 | 飲水紀錄 | 建立飲水紀錄 API |
| Day 14 | H2 資料庫 | 認識資料庫與 JDBC |
| Day 15 | 保存飲水資料 | 將飲水紀錄寫入 H2 |
| Day 16 | 飲水歷史 | 查詢指定日期與歷史紀錄 |
| Day 17 | 飲水統計 | 計算七天飲水統計 |
| Day 18 | 睡眠紀錄 | 建立睡眠紀錄 API |
| Day 19 | 睡眠統計 | 計算七天睡眠統計 |
| Day 20 | 每日健康摘要 | 整合飲水與睡眠資料 |
| Day 21 | 認識生成式 AI | 學習 AI API 與 Prompt |
| Day 22 | Java 呼叫 AI | 使用 HttpClient 串接 AI API |
| Day 23 | AI 健康摘要 | 讓 AI 整理每日健康紀錄 |
| Day 24 | AI 健康問答 | 建立健康知識問答 API |
| Day 25 | AI 多輪對話 | 使用 conversationId 管理上下文 |
| Day 26 | 保存 AI 對話 | 將聊天紀錄寫入資料庫 |
| Day 27 | 聊天紀錄管理 | 查詢與刪除歷史對話 |
| Day 28 | 聊天網頁 | 使用 HTML、CSS、JavaScript |
| Day 29 | 網頁功能整合 | 整合健康摘要與歷史對話 |
| Day 30 | 成果整理 | 系統測試、架構回顧與學習心得 |
這樣整理之後才發現，原來我們已經完成這麼多內容！
如果要把這 30 天分成幾個階段，我會分成五個部分。
第一階段
Java 與 Spring Boot 基礎
Day 1～Day 6
↓
第二階段
健康計算與 API 設計
Day 7～Day 12
↓
第三階段
資料庫與健康紀錄
Day 13～Day 20
↓
第四階段
生成式 AI 整合
Day 21～Day 27
↓
第五階段
前端網頁與成果整合
Day 28～Day 30
從最初的 Hello World，到最後可以在瀏覽器操作的健康助理，每個階段都建立在前面學過的內容上。
先來整理這次專案最後完成的主要功能。
使用者可以輸入：
{
"height": 1.65,
"weight": 55
}
由 Java 計算 BMI：
BMI = 體重（公斤）÷ 身高（公尺）的平方
例如：
55 ÷ (1.65 × 1.65)
得到約：
20.20
接著依照台灣成人 BMI 分類，提供初步體位分類結果。
這裡要注意：
BMI 只是初步篩檢指標，不能單獨判斷一個人的整體健康狀況。
使用者可以透過 API 新增飲水量。
例如：
POST /health/water
Request Body：
{
"amount": 300
}
系統會將紀錄保存到 H2 Database。
也可以查詢：
GET /health/water
以及指定日期的飲水總量：
GET /health/water/date?date=2026-10-17
除了單日紀錄，也可以查詢最近七天的飲水統計。
例如：
GET /health/water/statistics
由 Java 計算：
七天總飲水量
七天平均飲水量
最高紀錄
最低紀錄
這些數值都是由後端程式計算，而不是交給 AI 猜測。
使用者可以新增睡眠紀錄。
例如：
POST /health/sleep
Request Body：
{
"sleepDate": "2026-10-17",
"hours": 7.5
}
這裡的 sleepDate 代表醒來的日期。
系統會將資料保存到資料庫。
也可以查詢指定日期：
GET /health/sleep?date=2026-10-17
使用：
GET /health/sleep/statistics
可以取得最近七天的睡眠統計。
包含：
總睡眠時數
平均睡眠時數
最高睡眠紀錄
最低睡眠紀錄
有紀錄的天數
統計期間天數
這樣就不需要每次都手動計算。
使用：
GET /health/summary?date=2026-10-17
可以將飲水與睡眠資料整合在一起。
例如：
{
"date": "2026-10-17",
"water": {
"totalWater": 1500,
"unit": "ml",
"hasRecord": true
},
"sleep": {
"totalHours": 7.5,
"unit": "hours",
"hasRecord": true
}
}
這是我覺得整個專案很重要的一個轉折點。
因為在這之前，我們都是分別處理不同的健康紀錄。
到了這個階段，才開始把不同資料整合成同一個服務。
使用：
GET /health/ai/summary?date=2026-10-17
系統會先查詢健康資料，再交給 AI 整理成自然語言。
例如：
{
"date": "2026-10-17",
"summary": "今天已記錄飲水量 1500 ml，睡眠時間 7.5 小時，可以持續記錄生活習慣，方便日後觀察變化。"
}
實際文字會依照 AI 模型產生的結果而不同。
這裡我們特別設計 Prompt，要求 AI：
雖然 Prompt 無法百分之百保證 AI 回覆正確，但至少可以明確限制我們希望它完成的任務。
使用者可以詢問一般健康知識。
例如：
什麼是 BMI？
接著再問：
那它怎麼計算？
系統會透過：
conversationId
辨識同一段對話。
再將適當的歷史訊息提供給 AI，讓它可以理解前後文。
聊天內容可以保存到 H2 Database。
也可以透過 API：
GET /health/ai/conversations
查詢歷史對話。
或是：
GET /health/ai/conversations/{id}
查看指定對話的完整內容。
另外也加入刪除對話的功能。
最後在 Day 28 和 Day 29，我們使用：
HTML
CSS
JavaScript
建立網頁介面。
使用者可以直接在瀏覽器：
http://localhost:8080/
操作主要功能。
包含：
每日健康摘要查詢
AI 健康摘要
AI 聊天
歷史對話列表
恢復之前的對話
這也是整個專案最有成就感的部分。
因為它終於不再只是一堆 API，而是有了實際可以操作的畫面。
經過 30 天的開發，目前智慧健康助理的架構如下：
使用者
│
▼
Web Browser
│
┌──────────┴──────────┐
│ │
HTML CSS
│
▼
JavaScript
│
▼
Fetch API
│
▼
┌────────────────────────────┐
│ Spring Boot │
│ │
│ Controller │
│ │ │
│ ▼ │
│ Service │
│ │ │
│ ┌─────┴─────┐ │
│ │ │ │
│ ▼ ▼ │
│ Repository AIService │
│ │ │ │
└──────┼───────────┼─────────┘
│ │
▼ ▼
H2 Database OpenAI API
這張架構圖其實就是我們這 30 天學習的核心。
其中最重要的概念是：
不同層級負責不同的工作。
例如：
@RestController
@RequestMapping("/health")
public class HealthController {
// API endpoints
}
Controller 主要負責：
接收 Request
取得參數
驗證輸入
呼叫 Service
回傳 Response
它不應該負責所有的業務邏輯。
這也是我們在 Day 10 開始學習分層設計的原因。
例如：
@Service
public class HealthSummaryService {
// Business logic
}
Service 負責：
BMI 計算
飲水統計
睡眠統計
健康摘要整合
AI Prompt 建立
對話流程管理
當功能越來越多時，這種分層方式就變得非常重要。
如果把所有程式都放在 Controller 裡面，後面真的會越來越難維護。
例如：
@Repository
public class WaterRepository {
// Database operations
}
Repository 主要負責：
INSERT
SELECT
UPDATE
DELETE
這次我們使用 Spring JDBC 操作 H2 Database。
雖然沒有使用比較進階的 ORM 框架，但透過 JDBC，我反而更清楚 SQL 是怎麼和 Java 程式連接的。
我們在 Day 22 建立了：
AIService
使用 Java 17 的：
HttpClient
發送 HTTP Request。
整個流程是：
Java 建立 Request
↓
JSON 序列化
↓
HTTP POST
↓
OpenAI API
↓
取得 JSON Response
↓
解析 AI 文字
↓
回傳給 Service
這裡讓我印象最深刻的是：
AI API 其實也是一種 HTTP API。
原本覺得 AI 好像是一個很特別、很複雜的東西。
但真正開始串接後，發現它仍然需要理解：
HTTP
JSON
Request
Response
Status Code
這些之前學過的基礎觀念。
前面每一天，我們都有使用 Postman 測試當天建立的 API。
但單獨測試成功，不代表所有功能整合後一定沒有問題。
例如：
飲水 API 可以正常使用
不代表：
每日健康摘要一定能正確取得飲水資料
同樣地：
AI 聊天 API 可以正常使用
也不代表：
前端一定能正確顯示 AI 回答
所以最後一天，我希望從使用者的角度，重新檢查整個系統。
以下是一份可以實際執行的測試清單。
先確認：
OPENAI_API_KEY 已設定。啟動指令：
./mvnw spring-boot:run
Windows：
.\mvnw.cmd spring-boot:run
接著打開：
http://localhost:8080/
確認網頁可以正常顯示。
| 測試項目 | API | 預期結果 |
|---|---|---|
| BMI 計算 | POST /health/bmi |
正確計算 BMI |
| BMI 輸入驗證 | POST /health/bmi |
拒絕不合理數值 |
| 新增飲水紀錄 | POST /health/water |
成功保存資料 |
| 查詢飲水紀錄 | GET /health/water |
回傳已保存資料 |
| 查詢指定日期飲水量 | GET /health/water/date |
正確計算總量 |
| 飲水歷史 | GET /health/water/history |
回傳歷史統計 |
| 飲水統計 | GET /health/water/statistics |
回傳七天統計 |
| 新增睡眠紀錄 | POST /health/sleep |
成功保存資料 |
| 查詢睡眠紀錄 | GET /health/sleep |
回傳指定日期資料 |
| 睡眠統計 | GET /health/sleep/statistics |
回傳七天統計 |
| 每日健康摘要 | GET /health/summary |
整合飲水與睡眠 |
| AI API 測試 | GET /health/ai/test |
回傳 AI 文字 |
| AI 每日摘要 | GET /health/ai/summary |
回傳自然語言摘要 |
| AI 健康問答 | POST /health/ai/ask |
回答一般健康問題 |
| AI 多輪對話 | POST /health/ai/conversation |
保留對話上下文 |
| 歷史對話列表 | GET /health/ai/conversations |
回傳對話清單 |
| 指定對話查詢 | GET /health/ai/conversations/{id} |
回傳完整訊息 |
| 刪除對話 | DELETE /health/ai/conversations/{id} |
刪除指定對話 |
這張表也可以作為最後的驗收清單。
首先使用 Postman 新增飲水紀錄。
POST http://localhost:8080/health/water
Request Body：
{
"amount": 500
}
再新增另一筆：
{
"amount": 300
}
如果兩筆紀錄屬於同一天，當天總飲水量應該增加：
500 + 300 = 800 ml
接著查詢當天的飲水資料。
確認：
總量是否正確
資料是否保存
重新啟動後是否仍然存在
最後一點特別重要。
因為我們在 Day 13 最初使用記憶體保存飲水紀錄。
當時只要重新啟動程式，資料就會消失。
後來改成 H2 File Database，才讓紀錄可以持續保存。
接著準備指定日期的飲水與睡眠紀錄。
例如：
日期：2026-10-17
飲水量：1500 ml
睡眠時間：7.5 小時
呼叫：
GET http://localhost:8080/health/summary?date=2026-10-17
預期回傳：
{
"date": "2026-10-17",
"water": {
"totalWater": 1500,
"unit": "ml",
"hasRecord": true
},
"sleep": {
"totalHours": 7.5,
"unit": "hours",
"hasRecord": true
}
}
這裡要檢查的不只是數字。
還要確認：
日期正確
單位正確
hasRecord 正確
尤其是沒有紀錄的情況。
如果當天沒有睡眠資料，應該顯示：
{
"totalHours": 0.0,
"unit": "hours",
"hasRecord": false
}
這代表系統沒有紀錄，不代表使用者真的睡了零小時。
接著測試：
GET http://localhost:8080/health/ai/summary?date=2026-10-17
如果資料庫裡面有：
飲水量：1500 ml
睡眠時間：7.5 小時
AI 產生的摘要就應該以這些數值為基礎。
例如：
今天已記錄飲水量 1500 ml，
睡眠時間 7.5 小時。
但如果 AI 回答：
今天喝了 2500 ml 的水。
就代表 AI 產生了與資料不一致的內容。
這種情況就是我們之前提到的：
AI Hallucination（幻覺）
因此在測試時，不能只確認 AI 有回傳文字。
還需要檢查：
數值是否正確
有沒有編造資料
沒有紀錄時是否正確說明
有沒有提供不適當的醫療判斷
另外也要注意：
Prompt 雖然可以限制模型行為，但不能保證完全不會出錯。
如果未來真的要公開使用，還需要加入輸出驗證與更完整的安全機制。
首先發送：
POST http://localhost:8080/health/ai/conversation
Request Body：
{
"question": "什麼是 BMI？"
}
假設回傳：
{
"conversationId": "550e8400-e29b-41d4-a716-446655440000",
"answer": "BMI 是身體質量指數。"
}
接著發送第二個問題：
{
"conversationId": "550e8400-e29b-41d4-a716-446655440000",
"question": "那它怎麼計算？"
}
如果 AI 能理解：
它
指的是：
BMI
就代表多輪對話功能有發揮作用。
不過這裡也需要注意，AI 對話不是每次都會產生完全相同的回答。
因此測試重點應該放在：
回答是否理解前後文，而不是文字是否一模一樣。
最後打開：
http://localhost:8080/
依序測試：
| 操作 | 預期結果 |
|---|---|
| 開啟網頁 | 正常顯示智慧健康助理 |
| 選擇日期 | 日期欄位正常更新 |
| 查詢健康紀錄 | 顯示飲水與睡眠資料 |
| 點擊 AI 摘要 | 顯示 AI 產生的摘要 |
| 輸入聊天問題 | 顯示使用者訊息 |
| 等待 AI 回答 | 顯示等待提示 |
| 收到 AI 回答 | 顯示 AI 訊息 |
| 連續提問 | 保留同一段對話 |
| 點擊新對話 | 開始新的對話 |
| 查看歷史對話 | 顯示已保存的對話 |
| 點擊舊對話 | 恢復歷史訊息 |
| 接續舊對話 | 使用原本的 conversationId |
| 重新整理網頁 | 仍可查詢歷史對話 |
如果以上測試都能通過，就代表主要功能已經可以完成整合操作。
當然，這只是基本的手動測試。
並不代表整個系統已經通過正式環境所需要的安全性、效能與可靠性測試。
在最初建立 API 時，我其實很想把所有程式都放在 Controller 裡面。
因為感覺這樣比較直接。
例如：
接收參數
↓
計算 BMI
↓
回傳結果
全部放在同一個 Method 裡，好像也能正常執行。
但當後面開始加入：
飲水紀錄
睡眠紀錄
資料庫
AI
就發現這樣很容易讓程式變得混亂。
所以後來開始學習：
Controller
Service
Repository
DTO
的分工。
這讓我慢慢理解：
程式可以執行，和程式容易維護，是兩件不同的事情。
一開始我以為保存資料很簡單。
只要使用：
List
或：
Map
就可以把資料存起來。
但後來發現，只要重新啟動程式，這些資料就會消失。
所以才開始學習 H2 Database。
接著又遇到：
資料表怎麼建立？
SQL 要怎麼寫？
Java 怎麼執行 SQL？
日期欄位要怎麼處理？
查不到資料時要回傳什麼？
這些問題。
尤其是：
沒有紀錄
和：
數值為零
之間的差異，是我以前比較沒有注意到的地方。
但對健康紀錄系統來說，這個差異其實很重要。
在 Day 21 開始研究生成式 AI API 時，我原本以為只要：
Java → AI API
就可以完成智慧健康助理。
但後來發現，真正需要思考的事情很多。
例如：
Prompt 要怎麼設計？
API Key 要怎麼保存？
AI 回覆的 JSON 要怎麼解析？
如果 API 發生錯誤怎麼辦？
AI 如果編造健康資料怎麼辦？
怎麼讓 AI 記得之前的對話？
其中最重要的收穫是：
AI 不應該取代原本可以由程式確定完成的工作。
例如：
BMI 計算
飲水總量
睡眠平均時數
這些都應該由 Java 負責。
而 AI 比較適合處理：
自然語言摘要
一般健康知識問答
對話式互動
這樣可以讓整個系統的責任分工更清楚。
到了 Day 28 開始寫網頁時，又遇到另一個新的挑戰。
之前使用 Postman 時，可以直接看到 JSON。
但到了 JavaScript，就需要自己處理：
fetch()
JSON.stringify()
response.json()
以及：
async
await
尤其是當 API 回傳格式和 JavaScript 預期不同時，畫面可能就無法正常顯示。
例如後端回傳：
{
"answer": "你好！"
}
但前端卻寫：
data.message
就會取得：
undefined
所以這次也讓我更理解：
前後端必須先約定好資料格式，才能順利合作。
雖然這 30 天完成了不少功能，但我覺得還是要清楚說明目前系統的限制。
因為：
可以在本機執行，不代表已經適合公開提供服務。
目前最主要的限制有以下幾個。
目前專案主要以單人使用情境設計。
還沒有：
使用者註冊
登入驗證
使用者資料隔離
所以不能直接拿來當成多人使用的健康紀錄平台。
尤其是聊天紀錄可能包含個人健康資訊，更需要做好權限管理。
健康紀錄可能涉及敏感資訊。
如果未來要公開使用，需要考慮：
個人資料保護
資料保存期限
資料刪除
傳輸加密
第三方 AI 服務的資料處理方式
不能只因為系統可以正常執行，就忽略這些問題。
即使已經設計 Prompt，AI 仍然可能產生：
不精確的說明
不完整的回答
不存在的資訊
因此這個系統目前只能提供一般健康知識與紀錄整理。
不能作為疾病診斷或治療決策工具。
目前主要使用：
Postman
以及：
瀏覽器
進行手動測試。
未來可以學習：
JUnit
Mockito
Spring Boot Test
建立自動化測試。
這樣未來修改程式時，才能更容易確認舊功能沒有受到影響。
目前專案主要在：
localhost:8080
執行。
還沒有處理正式部署需要的：
HTTPS
正式資料庫
環境變數管理
日誌監控
API 使用量限制
備份與還原
所以這次的成果比較適合定位為：
智慧健康助理的本機展示原型。
雖然 30 天挑戰要結束了，但我覺得這個專案還有很多可以繼續延伸的方向。
如果未來有時間，我最想加入以下幾個功能。
目前網頁可以查詢健康摘要，但還沒有完整的資料輸入表單。
未來希望使用者可以直接輸入：
今天喝了 300 ml 的水
或：
昨晚睡了 7.5 小時
不需要再使用 Postman。
目前的統計結果主要以 JSON 和文字呈現。
未來可以使用：
Chart.js
將飲水與睡眠資料畫成圖表。
例如：
最近七天飲水量折線圖
最近七天睡眠時數長條圖
這樣使用者可以更直覺地觀察自己的紀錄變化。
未來希望加入：
Spring Security
讓不同使用者擁有自己的帳號。
每個人只能查看自己的健康資料和聊天紀錄。
這會是讓專案從單人練習走向多人使用的重要一步。
目前 AI 可以整理指定日期的健康摘要，也能回答一般健康問題。
未來希望可以詢問：
我最近一週的飲水紀錄有什麼變化？
或：
幫我整理這個月的睡眠紀錄。
這時候就需要讓 Java 先查詢指定期間的資料，再把整理後的結果提供給 AI。
而不是讓 AI 自己猜測。
最後希望有機會把專案部署到雲端。
讓它不只能在自己的電腦上使用，也能透過網址開啟。
不過在公開部署之前，必須先完成身分驗證、資料保護和 API 使用限制等安全措施。
以前學習程式語言時，常常是完成一個個小練習。
例如：
計算 BMI
使用迴圈
建立 Class
雖然這些都是重要的基礎，但我比較難想像它們最後可以怎麼組合成一個完整的應用程式。
這次透過 Spring Boot 專案，我開始理解：
使用者輸入
↓
前端
↓
API
↓
後端邏輯
↓
資料庫
↓
回傳結果
這整個流程。
也開始知道當某個功能發生問題時，應該從哪個部分檢查。
如果 Day 1 就直接要求自己：
「做出一個有資料庫、有 AI、有網頁的智慧健康助理。」
我大概會完全不知道從哪裡開始。
但這次把目標拆成：
先建立 Spring Boot
接著：
先完成一支 API
再來：
加入資料庫
最後：
串接 AI 與前端
整個過程就變得比較容易理解。
每一天只要完成一個小目標，就能慢慢累積成最後的成果。
這也是我覺得 30 天挑戰很有價值的地方。
在這次專案之前，我對 AI 的想像比較接近：
使用者問問題
↓
AI 回答
但現在我開始理解，AI 其實可以只是整個系統中的其中一個服務。
例如：
Java 查詢資料
↓
Java 計算統計
↓
Java 建立 Prompt
↓
AI 產生自然語言
↓
Java 回傳結果
這樣的設計，讓 AI 不需要負責所有事情。
而是讓 Java 處理確定性的資料運算，再讓 AI 負責比較擅長的文字整理。
我覺得這是整個系列最重要的觀念之一。
一開始寫 API 時，只要看到：
200 OK
就會覺得很開心。
但後來發現，真正需要注意的事情不只是成功的情況。
還包括：
使用者輸入負數怎麼辦？
沒有輸入日期怎麼辦？
資料庫沒有紀錄怎麼辦？
AI API 失敗怎麼辦？
使用者重複點擊按鈕怎麼辦？
這些問題都會影響系統的使用體驗。
所以我也開始理解，寫程式不只是完成正常流程，更需要思考異常情況。
這 30 天裡面，有些內容真的花了不少時間理解。
尤其是：
Spring Boot 分層
JDBC
AI API
多輪對話
JavaScript Fetch
這幾個部分。
有時候只是少了一個參數，或是前後端欄位名稱不一致，就可能讓整個功能無法正常運作。
但當問題解決，重新測試成功時，又會覺得非常有成就感。
尤其是 Day 28 第一次在瀏覽器看到 AI 回答的時候。
那個感覺和單純在 Postman 看到 JSON，真的不太一樣。
因為終於有一種：
「原來我真的可以把學過的東西做成一個應用程式！」
的感覺。
這次的鐵人賽雖然完成了，但我知道自己還有很多地方需要繼續學習。
例如：
Spring Security
JUnit
Docker
正式資料庫
雲端部署
以及更完整的 AI 應用設計。
不過和 Day 1 相比，現在至少已經知道這些技術大概會出現在系統的哪個位置，以及為什麼需要它們。
我覺得這就是這 30 天最大的進步。
以前看到一個完整的網站或應用程式，常常只會覺得：
「哇，這到底是怎麼做出來的？」
現在雖然還沒有辦法做出非常複雜的系統，但至少開始能夠想像：
它可能有哪些 API？
資料會存在哪裡？
前端怎麼和後端溝通？
AI 又是怎麼被整合進去的？
這種思考方式的改變，我覺得比單純記住某個語法還重要。
最後再用一張表格，整理這次專案的主要技術。
| 項目 | 使用技術 |
|---|---|
| 程式語言 | Java 17 |
| 後端框架 | Spring Boot |
| 專案管理 | Maven |
| API 設計 | REST API |
| 資料格式 | JSON |
| 資料驗證 | Jakarta Validation |
| 資料庫 | H2 Database |
| 資料庫操作 | Spring JDBC |
| 外部 API 呼叫 | Java HttpClient |
| AI 服務 | OpenAI API |
| 前端結構 | HTML |
| 前端樣式 | CSS |
| 前端互動 | JavaScript |
| 前後端溝通 | Fetch API |
| API 測試 | Postman |
| 開發環境 | IDE、瀏覽器 |
整個系統目前包含：
Java × AI 智慧健康助理
│
├── 1. 健康計算
│ └── BMI 計算與分類
│
├── 2. 健康紀錄
│ ├── 飲水紀錄
│ ├── 飲水統計
│ ├── 睡眠紀錄
│ └── 睡眠統計
│
├── 3. 健康摘要
│ ├── 每日健康資料整合
│ └── AI 每日健康文字摘要
│
├── 4. AI 聊天
│ ├── 一般健康知識問答
│ ├── 多輪對話
│ ├── 對話紀錄保存
│ └── 歷史對話管理
│
├── 5. 資料庫
│ ├── 飲水資料
│ ├── 睡眠資料
│ └── 聊天資料
│
└── 6. 網頁介面
├── 每日健康摘要
├── AI 摘要產生
├── AI 聊天視窗
└── 歷史對話查詢
雖然這還不是一個可以正式上線的完整產品，但它已經包含一個基本 Web 應用程式需要的主要元素：
前端、後端、資料庫、API，以及 AI 服務整合。
這也是這次 30 天挑戰最終想完成的目標。
終於完成 30 天了！
從最初的：
System.out.println("Hello World!");
到最後：
使用者
↓
網頁
↓
Spring Boot
↓
資料庫與 AI
↓
健康摘要與聊天回覆
這一路學習了很多以前不熟悉的技術。
也慢慢理解，一個應用程式並不是只靠某一種程式語言就能完成。
而是需要將不同技術整合在一起，讓每個部分各自完成適合的工作。
這 30 天最大的收穫，不只是學會了 Spring Boot、JDBC 或 AI API。
而是開始建立一種開發專案的思考方式。
遇到問題時，先確認需求。
接著拆解功能。
再思考需要哪些資料、API 和程式邏輯。
最後透過測試，一步一步確認功能是否正確。
如果要用一句話總結這次的挑戰，我會選擇：
從一個小小的 API 開始，每天完成一點點，最後真的能把想法變成一個看得見、也能操作的作品。
這個智慧健康助理還有很多可以改善的地方。
但至少對現在的我來說，它已經不只是課本上的範例，而是一個從規劃、開發到整合，自己一步一步學習完成的專案。
也希望未來回頭看這 30 篇文章時，能夠記得自己是怎麼從不熟悉 Java 後端開發，慢慢學會建立 API、操作資料庫，以及串接 AI。
最後，謝謝這 30 天願意一起閱讀的大家！
如果你也是剛開始學習 Java、Spring Boot 或 AI API，希望這個系列能夠提供一些入門方向。
不一定要一開始就做出很厲害的系統。
先從一支簡單的 API 開始，也許就是很好的第一步。
iThome鐵人賽
看影片追技術