AWS Summit Taipei 2026: 拆解 Ontology(領域語意本體、本體論)與 Agentic AI(自主式 AI):使用 Amazon Bedrock 讓製造業 ERP 變出活水

Post Title Image (圖說:在 AWS Summit Taipei 2026 屬於社群一起探索與一起前進的角落。圖片來源:謝謝主持人 Amy 和 Eric 攝影留念。)

每次回到社群都好喜歡一群人一起圍成一圈席地而坐、一起討論彼此都感興趣的議題、一起捲起袖子解決問題的氛圍,很不好意思讓後面的大家站了許久,希望這天簡短的分享能夠帶給大家一些些啟發、或一些些有用。每個年代都有當下的 buzzword 與 buzzvibe,每個年代都有當代的焦慮與徬徨,我希望能夠帶給大家的是一種輕鬆中帶點舒服謙卑的各種拆解整合以及融會貫通,也許不到醍醐灌頂,但若能稍微帶著志同道合的人往前踏出一步,都心滿意足。

也很感謝 AWS Summit Taipei 2026 的邀請,身為從 2008 一路跟著拆解走過來的鐵粉,感謝一起心無旁騖地堅持做對的事情。最後最後感謝社群好朋友 Amy 與 Eric 細心的顧前顧後與主持(以及土播幫忙採集與傳送香蕉 :p

如果對於 Ontology 有興趣一起探索、一起整合與落實到個人或企業組織的工作流程當中,歡迎先留言,我們正在與幾個友好單位洽談接下來一起探索的點子們。可能的話,請記得留下 email 方便後續聯繫各位。另外若是關於產品經理、產品人的成長嚮導,歡迎右轉看看 StableProgress 的嚮導與諮詢服務。

✳️ 簡報下載


演講後通知信

Hi everyone,

很開心能與大家一起窩在 AWS Summit Taipei 2026 Developer Community Zone 小角落,一起初步拆解 Ontology(領域語意本體、本體論)與 Agentic AI(自主式 AI):使用 Amazon Bedrock 讓製造業 ERP 變出活水。

比較抱歉的是原定當天晚上就想要寄出簡報檔案和練習檔案包給大家,但最近頻繁出差有點不敵睡魔。終於在整補之後,也檢查了一輪簡報與檔案內容無誤,終於可以發信給大家了。

以下是與大家約定好的投影片與練習檔案包:(推薦使用 Claude Code 和 Kiro 然後選用 Opus / Fable 以上的模型)👉

  • 投影片 (中文) 👉 Google search = ernest ontology
  • 練習檔案包(expired in 14 days, since 2026-07-17) 👉 請掃描頭投影片最後一頁 QR Code 留言說想要練習檔案包 (只有兩週請把握時間)(時間總是難搞,對不?)(心意也是(?

大家練習之後如果有任何想法都歡迎一起討論,我會就我所能地盡量回覆,我在以下地方出沒,歡迎大家隨時問我問題(是說… 雖然大部分時候應該 AI 都可以回答啦)👉(見留言)

很感謝大家給了我 平均 4.69/5 的分數,我會再接再厲,期待下次的見面與討論 :)


Q&A

最後針對大家有留言問到幾個常見問題,我先一起回覆給大家參考看看,我的觀點不一定正確或不一定符合您的場景,但多一個思考維度或觀點,也許有助於您的迭代思考:

Q1:

關於 API / 消耗 token 的成本應該如何評估與控制。 e.g. 公司專業 KM 消耗太多 token e.g. 如果 erp 裡面要有 ai 詢問功能 不就會一直燒 api 費用嗎?要如何拿捏成本與功效?

My two cents:

現在我會先挑選高價值問題當作目標來嘗試運用 AI,從過程中拆解細節步驟,並找出可控或不可控的參數細節。沒有嘗試永遠不知道官方文件背後實作的時候到底藏了哪些雷,時間永遠不會夠用,只能先抓大放小,抓住先行者優勢與資訊不對稱優勢。問題還沒定義出來,就先被成本卡住,基本上換成任何工具或想法或方法論都屬於無解,而無需浪費時間。如果吃了誠實豆沙,我都一率建議換題目、或是換___(不好說)。

另一個我相信的是 token 費跟電信費、水電費類似,應該會隨著時間過去逐步降價。想當年大哥大(手機)剛出來的時候是以分計費,後來才挑戰以六秒計費、以秒計費,然後一路玩到零元手機。想當年信用卡扣掉黑卡之後頂規就只到白金卡,幾萬元的年費,一路玩到現在要疊加鈦金卡、無限卡、世界卡,才能收到年費,其餘都玩到沒有利潤的免年費,發卡行只能從手續費和點數遊戲規則裡頭撈一些餘裕回來。AI token 單位費用隨著時間過去,可獲利的應用與服務會被逐漸挖掘,市場充分競爭的情況下,降價屬於可以預期的方向。

如果讓我來選,我現在就應該盡可能大量練習、大量實作、大量討論(在能力許可的合理範圍內),在市場還沒充分反映 token 價值到價格之前,盡可能成為先行者,盡快摸透各種底層知識、拆解步驟、參數教調。就像當年大家都在花時間教調 web server 或 database server,也是一堆的參數(parameters),所有參數都可以在開發者手冊找到定義,甚至在開源程式碼裡面找到原始碼,但是你的、我的、他的應用場景不同,光是最常見的 cache timeout 該設定多久、或是每個執行緒最大可以用多少記憶體、小到每個檔案節點的 inode 該設定多少(當年的 bbs 系統站長的痛?),都是對應到各自應用場景找出最適合的設定值。

所以都是「局部最佳解」,但是身為人類的我們有時候總貪心想要找「系統無腦解」或「一飛沖天解」。

回到題目,先盤點問題、分類問題,鎖定高價值問題,然後嘗試運用 AI。如果沒有高價值問題,也許,暫時還不需要 AI 進到你的場景裡頭,你可以等待 token 降價,但也可能錯過資訊不對稱帶來的紅利。解題仍須繫鈴人,但是選題可以自己來。

喔對,套皮的 AI 與原廠的 AI 要記得一件事情,system prompt 是不同的。就如可口可樂、百事可樂、伊良可樂的配方是不同的,味道(結果)也是不同的,但從外觀看起來就是一杯冒泡泡的飲料。


Q2:

You suggested people to use MORE WORDS when chatting with whatever AI chat/agents, doesn’t that gonna consume more tokens? or, maybe it’s gonna SAVE more tokens, since it has better understanding of what we requestes/asked. Much appreciated!

My two cents:

我嘗試將我的論述,用另一個方式描述看看,有可能在現場我講太快了,我想要建議的不是「更多的字」而是「更完整的前情提要、更明確的目標方向、以及保有彈性地請 LLM AI 綜合各種維度後提供多種解決方案選項或想法思路」。

在現場最後收尾時我有提到,如果可能,可以偶爾運用「multiple shots」這個魔法。

「multiple shots」之一:同一個 prompt 可以在不同時間點、或對著不同模型都打過一次。沒有做過實驗,就無法取得經驗,就無法形成 feedback loop 教調參數往目標逼近。

「multiple shots」之二:同一個問題,在同一個時間點(大部分場景屬於同一個時間點,而沒空運用上述「之一」),用不同長度的 prompt 對著同一個模型(或不同的模型)各打過至少一次。字少,可以發散,可以有想像力,可以亂猜,可以通靈。字多,可以聚焦,可以專注,但也可能形成狹隘與侷促而放不開手腳。但是疊加態可能可以解,將字少的 prompt 與字多的 prompt 不厭其煩的合體疊加之後,也許能夠有個平衡的味道浮現,可以期待看看。至少我們團隊目前嘗試的結果,多半屬於正面。

就如進場交易,不需要求 100% 穩贏的勝率,而可以追求每次進場都贏過平均值。有形成資訊不對稱,比斤斤計較單位成本來的重要,至少在 2026 年的現在我會這麼選擇。也許回想當年的衛星電話費率、手機費率、有線電視費率、網際網路上網費率,再過十年之後我們一起回頭想當年,至少不會後悔又錯過了一次,而可以是,喔耶好險我有邁出一小步。


Q3:

如果是以中年轉職非工程背景來說,會建議從哪一個平台先入手?謝謝。

My two cents:

先不管我的政治正確,同時從工程與商業角度來看,我會建議從順路的、離你近的、你運用目前自身已知知識與觀念學起來最輕鬆舒服的平台入手。例如你身邊可以觸及的資源(人、機、材)都靠近 AWS,那就從 AWS 開始。

這時候你的需求不是系統有多穩定、平台服務有多棒(價格不用在這個階段做比較,沒有量就沒有價格),你的需求是將自己賣掉,讓市場看見你的價值。另一條可能的路徑是盤點與梳理自己已經經歷過的產業,從中提煉(抽象化)可以跨產業運用的魔法,然後盡可能想辦法與高階模型進行盡可能深度的對話(在自己舒服的範圍內),多多嘗試開放式的問題,如果可能,先讓各種維度的資訊進來,如果太多,就先抓自己覺得重要的重點寫在紙上或筆記本上。先廣再深、循序漸進、先能步行再來小跑步。小跑步的時候,因為基本功已經練習透徹,一個平台和兩個平台或是更多平台,對你來說都是同一個概念,只是呼叫的 API 不同、疊層架屋的架構不同而已,但那都可能是 agentic coding 可以幫忙守備的範圍。

希望這樣有回答到您的問題。


Q4:

我最近在思考一个问题,ai agents现在已经足够成熟到生成生产级别的代码,人类程序员存在的价值得到很大的挑战。你怎么看待程序员未来行业的形势变化,如果我仍需要学习编程,我应该注重哪些技能,哪些现在被强调的技能应该被减少关注

My two cents:

  • 每天都聽到的那些隨著時間推進被抽換名詞的 👉 減少關注。
  • 檯面上一直沒提或看不到的的基本功與基礎設施 👉 增加關注。

Q5:

如果回答這個問題的是Ernest的AI agent, 告訴我製造業ERP實例的deployment 跟security concern,除了data isolation以外的practice。

My two cents:

嘿嘿,抱歉,我是本人,不是 AI agent。 (所以就不告訴你製造業… 囉)


Q6:

  • 聽到您在AWS的講座,真的讓人如浴春風,從日常生活中開始一步一步讓聽眾理解LLM的樣態,超級舒服的學到東西。謝謝您。
  • it’s good to see your sharing, but the time is extremely limited and I’m eager to learn more from you though….lol
  • 我得說,我很喜歡 Ernest 的手寫筆記 XD
  • 總是從您的文章或公開演講中獲得許多啟發,十分感謝!

My two cents:

也謝謝您們週三下午一路陪我站了一個多小時,未來也請繼續舒服地學習各種東西,也許可以從 Ernest PKM 開始起個頭 :)

ernest,