問題
It's 6:00 a.m., Patrick's yard just flooded, and he has no idea who to call.譯文清晨 6 點,Patrick 家的院子剛淹水,他完全不知道該打給誰。
他不要電話語音選單,不要常見問題集,也不要一句道歉。他要的是一個能立刻受理通報、並告訴他事情正在處理的東西——而 W.E.S,正是為那一刻而打造的。
一支來自聖文森及格瑞那丁的團隊,為格瑞那達的一個水務機關打造了一個水務助理。他們從未巡過它的管線,從未站在它的辦公室裡,也從未見過將來會使用它的客戶。他們手上有的,是一份需求書——a bot that can read a water meter with its eyes(「一個能用眼睛讀水表的機器人」)——以及四週的時間。
他們把這份需求書照字面理解。不是把它當成對便利的比喻,而是當成這個東西真正非做到不可的那一項能力。
他們打造了什麼
W.E.S 運行於一個即時模擬的 National Water and Sewerage Authority(NAWASA)網站之中,背後是一個收錄 628 筆事實、涵蓋格瑞那達、Carriacou 與 Petite Martinique 的知識庫。六種使用者角色各有一個自適應的虛擬形象——承包商是一頂工地安全帽,年長與弱勢客戶則是一根手杖。緊急分流會完全跳過常見問題,在詢問你的姓名之前,就先給出熱線電話、WhatsApp 派工連結與一組專屬的參考編號。用手機拍下的水表照片會以光學字元辨識(OCR)判讀;照片模糊時會要求重拍,而不是用猜的。一段十五道問題的對話式受理流程,會產出一份可直接列印的 PDF 接水申請表。帳單金額異常飆升時,系統會主動發出漏水警示;社區停水動態則會發布全島都能據以因應的公告。
- 628
- 經查證的事實
- 6
- 使用者角色
- 3
- 服務島嶼
- 73
- 分,第一名
涵蓋格瑞那達、Carriacou 與 Petite Martinique
家庭、商業、現場人員、年長與弱勢族群
格瑞那達 · Carriacou · Petite Martinique
聊天機器人組最高分

評審追問的重點
Caribbean Institute for Meteorology & Hydrology(CIMH)的 Horace Lashley 提出了兩個問題。
"When will live integration occur with NAWASA's public servers?"(「NAWASA 公共伺服器的即時整合何時進行?」)團隊回答,webhook 與 REST 端點的程式碼已經完成,只待 NAWASA 的新入口網站與帳務應用程式介面(API)就緒。
"How confident are you in authentication and preventing data leaks?"(「你們對身分驗證與防止資料外洩有多少把握?」)他們說,檢索機制把一般知識與私人紀錄隔離開來,而且在任何轉交發生之前,都會先驗證 token。
兩個回答都不是對未來的承諾。兩者陳述的,都是已經存在的程式碼,而團隊也願意把它拿出來給人看。
轉捩點
被要求拿出證明時,團隊沒有搬出投影片。他們把自己的 Python 後端程式碼投上成果展的螢幕,一行一行地念出來。
We'd rather show you the truth than a polished lie … No token raises an error and refuses to run. It cannot invent a balance. That is what agentic means in practice!譯文我們寧可讓你們看見真相,也不要給你們一個包裝精美的謊言……沒有權杖就會拋出錯誤、拒絕執行。它不可能憑空編出一筆餘額。這就是「代理式」在實務上的意義!

使用技術
- Python
- FastAPI
- LangGraph
- RAG
- OCR
- Gemini
團隊
- Alysson Ambrose
- Azaray Defreitas
- Akasha Dember
- Mikayla Durant
- J'Nae Edwards
- Cornel London
- Aren Ollivierre
- Arriana Peters
- Kyron Quashi
- Shannon Ralph — 隊長
- Keleisha Simmons
- Kevin Thomas
- Nijonte Thomas
信任,成了一行一行讀得出來的東西。
編輯評析
我們對這件作品的解讀
由本出版品編輯群所做的獨立評估——既非評審的評分,也非團隊的自述。
- 技藝
- 以四週的時間來說,這個作品完整得不尋常。這個層級的專案,大多停在一段能運作的對話;W.E.S 交出的卻是一個知識庫、一條能產出真實文件的受理流程、一條影像處理管線,以及一則公開動態。最洩漏玄機的細節,是 OCR 的行為——模糊的水表照片會被要求重拍,而不是用猜的。那是一個關於失敗的決定;會為失敗而設計的團隊,打造的是產品,而不是展示品。
- 他們學到了什麼,又展現在哪裡
- 二十天的課程脈絡,幾乎可以在這個產品裡逐行讀出來。防護機制那一週,化為一道寧可拒絕執行、也不捏造餘額的 token 驗證。黃金紀錄(Golden Record)化為 628 筆各自附上來源的事實。檢索化為一道牆,隔開一般知識與私人紀錄。代理之間的轉交,化為先派工、後問姓名的緊急分流。他們不是把課程大綱當成檢查清單逐項打勾,而是用它為一個特定的客戶,做出一個個具體的決定。
- 易用性
- 最有力的決定,是一個關於順序的決定。遇到緊急狀況時,W.E.S 會在問你是誰之前,就先給出熱線電話、派工連結與參考編號。幾乎所有的服務軟體都先要你表明身分。把這個順序倒過來,是對一個清晨六點驚慌失措的人真正需要什麼所做的判斷,也是整個作品中最清楚的證據,說明團隊想的是一位使用者,而不是一張功能清單。使用者角色的虛擬形象——一頂安全帽、一根手杖——有淪為裝飾的風險,但搭配會隨對象調整的用語,它們確實幫助了那些對上網沒有把握的人。單向的社區動態對自身的侷限很誠實;它不假裝自己是客服。
- 可擴充性
- W.E.S 與正式上線之間隔著兩件事,而團隊把兩件事都說了出來,沒有藏起來。整合的程式碼已經完成,但尚未經過驗證:webhook 與 REST 端點都已存在,NAWASA 的入口網站與帳務 API 卻還沒有;在兩端接通之前,帳務功能仍只是展示。其次,628 筆事實與其說是資產,不如說是一整片需要維護的範圍——NAWASA 必須有人負責管理它們,而「最後查核日期」欄位的可靠程度,永遠只取決於更新它的那個人。架構本身則很容易移植:換掉地區資料,整體結構依然成立。營運成本也會一併跟著移植過去。
Just text WES, he ready to chat — check your bill, just like that!譯文傳個訊息給 WES,他隨時陪你聊——帳單一查,就這麼簡單!
影像攝於 2026 年 ECCU 聊天機器人暨多媒體成果展(2026 年 8 月 28 日)。 螢幕截圖已經裁切,移除了瀏覽器與直播介面;聊天機器人介面與簡報者皆未經修改。
