當後端變成樂高：一個前端工程師在 AWS × MongoDB 研討會的現場筆記
當後端變成樂高：一個前端工程師在 AWS × MongoDB 研討會的現場筆記
我不是遊戲開發者。
但那天坐在 AWS 台北辦公室，聽完三位講者輪番上台，我有點震撼地發現——這場活動跟遊戲的關係，遠不如它跟「開發這件事本身」的關係來得深。
裡面談的每一個痛點，我都在接案和職場裡反覆撞牆過：需求模糊得不像話、AI 輸出品質忽高忽低、凌晨三點伺服器突然爆炸、改個資料庫 Schema 就得停機一整晚。
活動資訊： https://events.mongodb.com/taiwangamingseminarwithaws ，2025 年 3 月 6 日，AWS 台北辦公室。
第一場：Amazon Kiro — AI 終於成為開發「夥伴」，而不只是打字機
Irving Hsu（AWS Partner Solutions Architect）一開口就問了個讓全場苦笑的問題：「同樣的需求，今天問 AI 和昨天問 AI，結果一樣嗎？」
沒人舉手。
這正是他想講的核心。現在的 AI 開發工具，說白了就是個聰明的補全引擎——幫你寫段小程式、解釋一行報錯、建議一個修法。但整條開發流程呢？從計畫、設計、測試到上線，AI 真正參與的，其實只有中間那一小段。前後都是空白。
Kiro 要填補的，就是那兩端的空白。
先把腦袋裡的話，變成一份可以執行的文件
Kiro 的核心叫 Spec-Driven Development（規格驅動開發）。
邏輯很直白：別急著寫程式，先把你要做什麼說清楚。你用自然語言描述需求，Kiro 把這句話轉化成 ERS 格式的需求文件——不是散亂的條列清單，而是用「當什麼條件成立，系統就執行什麼動作」的語法逐條寫下去。需求確認後，它繼續往下生成系統架構圖、API 定義、資料庫欄位設計。最後把整個功能拆成一個個極細的 Task，像拆樂高一樣，一塊一塊依序執行。
Irving 特別強調「拆細」這道工序。讓 AI 一口氣消化一個複雜功能，出來的結果往往面目全非；但把任務切得夠小、夠明確，每一步都可以驗收，整體品質就穩了。
現場 Demo 裡，他隨口說了一句話描述某個管理系統，不到兩分鐘，Kiro 就端出完整的需求文件、系統設計、MongoDB 資料模型，連每個 Collection 該建哪些 Index 都想好了。那個密度，要是手寫的話，你得對著螢幕坐到天亮。
每次按下儲存，背後都有人在把關
另一個讓我記下來的功能叫 Agent Hooks，觸發條件非常日常：存檔、建立新檔、刪除檔案。就在這些再平凡不過的動作瞬間，Hooks 可以自動啟動你設定好的任務——跑測試、更新文件、掃描安全漏洞。
Demo 裡，Irving 把一組密碼直接寫進程式碼，然後按儲存。幾秒後，Kiro 跳出紅字警告：第幾行，發現了高風險機密資訊，建議改用環境變數。
他說了一句話我很有感：「我在 AWS 待了七年，還是偶爾會接到警報，說有人把 Key 推上公開 repo。不是不知道不能這樣做，是人就是會分神。Hooks 要解決的，就是這種人性弱點。」
把規範寫進工具裡，永遠比寫進文件裡有效。
讓 AI 現學現賣你公司的規矩
第三個功能叫 Stereotypes，說白了就是給 AI 設定行為規範。你告訴 Kiro 公司的編碼標準——用什麼框架、命名規則怎麼定、哪些 Library 禁止使用——它之後所有的回答都會在這個框架裡走，今天如此，明天也如此。
一個十人開發團隊，十個人各自用 AI，最後程式碼風格亂成一鍋粥——這個場景太多人經歷過了。Stereotypes 要解決的就是這件事：讓 AI 從一個隨機回答的外包工具，變成真正懂公司規矩的開發成員。
設計稿丟進去，程式碼走出來
Kiro 還支援 MCP（Model Context Protocol）Server 整合，讓 AI 能直接跟外部系統對話——讀取 Figma 設計稿、查詢 AWS 文件、串接資料庫，都可以接進來。
Demo 裡，Irving 把一個 Figma 頁面連結丟給 Kiro，請它根據設計稿生成需求文件，再一路產出可執行的程式碼。設計稿到代碼，中間幾乎沒有人工翻譯的環節。我就坐在台下，親眼看著這件事發生。
投影片上也出現了 Amazon ECS and EKS managed MCP Servers 的架構圖，說明 Kiro 跟 AWS 容器服務之間的整合已經到位——開發工具和雲端基礎設施之間那條一直需要人工跨越的溝，正在被填平。
第二場：AWS EKS — 把「凌晨三點被電話吵醒」這件事，從你的人生刪掉
Danny Ho（AWS）上台，第一句話就讓現場氣氛鬆了：「你們有沒有試過，凌晨睡得正熟，電話響了，說伺服器掛了？」
台下幾個人舉了手，然後是一片心有戚戚的笑聲。
他接著說：「這就是遊戲後端工程師的日常。」
遊戲流量的特性，跟大多數 Web 服務截然不同——它不是緩慢爬升的曲線，而是懸崖邊的垂直跳躍。賽季更新的那一刻、限時活動開搶的那一秒，流量可以在幾分鐘內飆到平時的 10 倍。玩家能接受的延遲極限大概是 100ms，超過這個數字，不是體驗變差，是投訴信件開始湧入。而公司對你的 SLA 承諾是全年 99.99% 可用性，換算下來，一整年最多只能停機不到一個小時。
這三個數字壓在一起，就是遊戲後端工程師每晚輾轉反側的重量。
從「一台大機器扛所有」到「各自獨立的小盒子」
傳統架構有個根本矛盾：一台大機器上跑多個 Game Server Process。白天流量低的時候，大半資源閒著燒錢；晚上活動一來，機器又不夠用。更要命的是，一台機器掛掉，上面所有的 Process 一起陣亡——不是一個房間出問題，是這台機器上所有玩家同時被踢出去。
容器化改變的是資源調度的邏輯。把每個服務打包成獨立的 Container，由 Kubernetes 統一排程，需要就開、不需要就停，某個 Container 壞了也不會拖垮整個系統。EKS 把這套機制搬上 AWS，同時把維運的複雜度大幅壓低。
幾秒鐘，從零到能用的節點
自動擴展工具有一堆，但 Danny 特別點名了 Karpenter。傳統的 Cluster Autoscaler 走的是間接路徑：偵測到 Pod 排隊 → 通知 Auto Scaling Group → 等 EC2 節點慢慢起來，整個過程動輒一分鐘以上。Karpenter 直接跳過中間層，對 EC2 的 Fleet API 下指令，實測幾秒內節點就緒。
對遊戲來說這個差距不是技術數字，而是開賽瞬間玩家是否能順利進場——一分鐘的等待，足以讓一批玩家關掉遊戲然後去 PTT 發文。
流量走的路，比你想的更重要
Danny 投影片上有張對比圖很清楚：傳統 Instance Mode（紫色路徑）要在好幾個節點之間跳來跳去才能找到目標；IP Mode（綠色路徑）直接打到 Pod IP，一條線到底。他建議遊戲場景用 NLB 搭配 IP Mode，跳過所有不必要的轉發層。
對 FPS 或格鬥遊戲這種「每毫秒都有意義」的場景，這段路程省掉幾個跳轉，玩家的手感真的感受得出來。
大活動前，提前把門打開
EKS Control Plane 預備制聽起來是個很小的功能，但解決的是一個非常現實的問題。Control Plane 本身接受請求有容量上限，如果大型活動在晚上九點開始，工程師可以下午三點先把容量升上去，活動結束再降回來。
與其在流量炸進來的瞬間才手忙腳亂，不如提前三個小時把基礎設施備好。這個邏輯就像演唱會開場前先把所有通道打開，而不是等觀眾擠在門口才開始拆圍欄。
第三場：MongoDB Atlas — 資料庫第一次讓我覺得「這不是後端禁地」
Aloysius Chang（MongoDB Senior Partner Solutions Architect）一開口就問：「有沒有人做過凌晨兩點四點八點輪班，等資料庫遷移完成的？」
台下幾個人舉手，不是全部，但足夠讓全場會意地笑出來。
他說：「這就是我們要消滅的事。」
投影片上有一句話讓我眼睛亮了一下：「MongoDB，最像 RDBMS 的資料庫。」這不是說它要取代你熟悉的一切，而是說——你已經懂的那套思維，在這裡還能用，只是現在多了更大的彈性空間。
JSON 格式，前端的母語就是資料庫的語言
MongoDB 的核心是 JSON-like 的文件模型。對前端來說，這幾乎是零學習成本——API 回來的資料長什麼樣，存進資料庫就長什麼樣。不需要把物件打散成一堆關聯表，查詢時也不需要費力把它們 JOIN 回來。
就像你一直用中文思考，突然有人說：「來，我們就用中文開會，不用翻譯了。」
彈性更是關鍵。遊戲版本更新、新增角色屬性、調整道具結構——這些在傳統資料庫裡都是「先停機、改 Schema、再上線」的儀式，輕則半小時，重則整晚。MongoDB 的動態 Schema 讓修改可以在線上悄悄進行，玩家毫無感知。
水平擴展，對應用程式來說完全透明
資料量超出單台機器的上限怎麼辦？MongoDB 的 Sharding（分片） 會自動把資料分散到多台機器，但對外永遠呈現成一個完整的資料庫。
你的 API 不用改，查詢語法不用改，承載量卻能跟著分片數量線性成長。
Aloysius 提到對岸某個大型電商「分表分庫」的案例，那張截圖在技術社群裡流傳已久。見過的人都知道那段代碼的重量——應用層要自己算資料在哪個表，每次修改牽一髮而動全身。「當你的應用程式不需要改，省下的不只是時間，」他說，「是工程師的精神健康。」
三個讓人坐直的數字
高併發的壓力，Aloysius 用三個數字說清楚了：10 倍瞬間流量、100ms 玩家忍耐極限、99.99% SLA 全年停機不超過一小時。MongoDB Atlas 針對這三個指標，都有對應的架構設計來承接。
導入之後，數字說話
「導入 MongoDB Atlas 的成果」那張投影片，每個數字都很具體：63% 年度成本下降、82% 效能提升、維運人力壓縮到 1–2 人、開發工作量減少 70%、部署時間縮短 78%。這不是 Demo 環境跑出來的數字，是客戶真實回報的結果。
Square Enix：一個人，全球規模
整場讓我最震驚的，是 Square Enix 那張投影片。節省約 $1M 硬體與維運成本、查詢時間從數月壓縮到 2 分鐘、每天處理 0.5TB 遊戲資料。
但最後那行才是讓全場靜了一秒的數字：整個資料層，只需要 1 個人維運。
一個人，全球規模的遊戲資料工作。Aloysius 說：「這就是為什麼 MongoDB Atlas 不只是資料庫，而是讓小團隊能打大仗的基礎建設。」
第四場：向量搜尋 × Voyage AI — 當搜尋引擎開始理解你「想說什麼」
最後這段還是 Aloysius，但整個氛圍轉了——從架構討論，變成更接近產品思維的對話。
他問了一個問題，簡單到讓人愣了一下才反應過來：「玩家搜尋『怎麼取得高品質武器』，你的系統能找到『傳說級裝備』嗎？」
傳統關鍵字搜尋：不能。這兩組字沒有任何重疊。
向量搜尋：可以。因為它比的不是字，是意思。
語意，才是搜尋的真正維度
把所有文字放進一個巨大的空間，語意相近的詞自然靠攏在一起，語意相遠的詞距離遙遠。「傳說級裝備」和「高品質武器」在這個空間裡是鄰居，「傳說級裝備」和「釣魚竿」則住在城市的兩端。
搜尋時，不再問「有沒有這個字」，而是問「這個概念的鄰居是誰」。一個問法的轉換，讓搜尋從「字面匹配」升維到「理解意圖」。
為什麼是 Voyage AI？
業界基準測試排名第一、原生支援中英日多語言混搜（不需要對照表、不需要翻譯層）、低幻覺特性讓 NPC 對話更可靠。
但對我來說最實際的一點是：Voyage AI 已經整合進 MongoDB Atlas 平台，不需要另外申請 API 金鑰，不需要管理第三方服務。少一個外部依賴，就少一個可能在凌晨三點炸掉的環節。
先撒一張大網，再用細篩把雜質濾掉
向量搜尋有個盲點：它只判斷「語意接近」，不判斷「是不是真的在回答這個問題」。有時候兩份文件在語意空間裡靠得很近，但一份真正切題，另一份只是恰好用了相似的詞。
Reranker（重排序模型） 解決的就是這件事。它在向量搜尋撈出候選名單之後，把「問題」和每一份候選文件放在一起重新評分——不是分開計算，而是同框比對。這種「放在一起看」的能力，讓 AI 不只知道文件跟問題語意接近，還能判斷它是否真的回答了這個問題。兩段式架構，精準度大幅提升，答非所問的機率也跟著降下來。
四個場景，四種不同的產品突破
玩家個人化推薦：把遊玩時間、角色選擇、消費紀錄轉成自然語言，向量化成一個「代表這位玩家喜好」的數字向量，找最接近的內容推薦。捕捉的不只是明顯的偏好，還有那些玩家自己可能說不清楚的隱性喜好。留存率提升 20–35%。
智慧 NPC 對話（RAG 架構）：NPC 只能從遊戲世界觀文件裡取材回答，不准自由發揮——這條限制是防止 AI 信口開河的防線。搭配快取機制，大量重複性問題直接從快取拿答案，查詢延遲從 500ms 壓縮到 50ms，99% 玩家認可對話品質。
遊戲內容語意搜尋：「釣魚竿」找得到「高品質漁具」，「高品質武器」找得到「傳說級裝備」。搜尋引擎第一次開始理解玩家想找什麼，而不只是找玩家輸入了什麼。
玩家配對：不只看等級和勝率，把戰鬥風格、活躍時段、溝通習慣都納入配對邏輯，組出真正有默契的隊伍，而不只是數值相近的陌生人。
一個資料庫，什麼都放得下
向量搜尋的資料和應用程式的資料，存在同一個 MongoDB 資料庫裡。不需要另外架向量資料庫，不需要維護兩套同步機制。一次寫入，兩種能力都有。架構越簡單，出問題的地方就越少。
來源：https://www.notion.so/AWS-MongoDB-31c48a1740bf80098849fd6204e7bf50
AWS：從「程式片段」到「流程自動化」
- Kiro 的 Spec‑Driven Development：自然語言 → ERS 需求 → 架構/DB/Index → 任務極細拆解
- Agent Hooks：在「存檔、建檔、刪檔」瞬間自動跑測試、掃敏感資訊、更新文件
- Stereotypes：把公司編碼規範變成 AI 的行為邊界，團隊輸出一致
- MCP Servers 與 Figma→Code 串接，縮短設計到代碼的翻譯鏈
EKS for Games：用 Karpenter 把「等一分鐘」變成「等幾秒」
- 遊戲流量不是曲線，是懸崖；Karpenter 直接對 EC2 Fleet 起節點，幾秒 ready
- NLB + IP Mode 減少轉發；EKS Control Plane 預備制，在活動前先把門打開
MongoDB Atlas：最像 RDBMS 的文件資料庫
- 動態 Schema 線上調整、Sharding 線性擴展；應用端不必改
- 成果數字：成本降 63%、效能升 82%、DBA 工時大幅降低
- Square Enix：查詢從數月縮到 2 分鐘、節省約 100 萬美金；一人維運全球資料層
向量搜尋與 RAG：從「字」到「意圖」
- Voyage AI Embeddings + Reranker：語意找鄰居，再同框評分，降低答非所問
- 應用：玩家個人化推薦、智慧 NPC 對話、內容語意搜尋、玩家配對
- 一次寫入，同庫服務：應用資料與向量資料同在 MongoDB，架構更單純
我的三個下一步
- 試行 ERS 規格文件 → 自動拆任務
- Atlas Vector Search 試升級既有關鍵字搜尋
- 在團隊裡以「架構建議者」角度推動自動化與可觀測
來源：https://www.notion.so/AWS-MongoDB-31c48a1740bf80098849fd6204e7bf50?source=copy_link