iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
Vibe Coding

轉生到全端工程師沒多久就要負責公司的大平台?? 系列

謝謝AI,真的很謝謝他才能讓我在短時間內學到很多預料之外的內容。
這是一個「完全」由ai開發的portal,甚至連接下來30天的內容也是ai產的。
主要業務是一個ai客服平台。從前端經由portal(大平台)再到後方的engine檢索km,來得到最精確回答的一系列過程。
雖然我覺得RAG檢索KM,很有趣,但portal更有趣!!
接下來的30天就讓我們從頭開始認識這個portal(我真的很想把頭貼換成王大陸)需要知道哪些技術細節吧。

參賽天數 21 天 | 共 21 篇文章 | 3 人訂閱 訂閱系列文 RSS系列文
DAY 1

Portal大平台-從零點一開始的世界

Day 1|系列總導覽 接下來 30 天,我想帶你把一個東西從頭拆到尾:Agent Portal,一套銀行的企業 AI 助理平台的對外入口。不是貼程式碼那種拆法...

2026-08-02 ‧ 由 木木貝爾 分享
DAY 2

Day 2|Portal 在整個系統裡的位置

昨天 Day 1 給了地圖,也給了一個定位:Portal 是對外入口,自己不產生答案,只做身分、安全、路由、整合這四件橫切的事。今天把鏡頭拉遠一格,看它站在整個...

2026-08-03 ‧ 由 木木貝爾 分享
DAY 3

第參天、大平台與LiteLLM的異同

昨天 Day 2 我們把 Portal、Engine、KM 三者的分工攤開來看,結論是 Portal 在最外層當了一層 BFF/Gateway——身分、安全、路...

2026-08-04 ‧ 由 木木貝爾 分享
DAY 4

第IV天|技術選型全景

昨天我們把 Portal 跟 LiteLLM 那類純 AI Gateway 擺在一起比,結論是:Portal 不只是轉發流量的閘道,它是一個內建身分、守門、路由...

2026-08-05 ‧ 由 木木貝爾 分享
DAY 5

Day 5|非阻塞與事件迴圈

昨天把三大技術選型攤在桌上時,我留了一個沒拆開的選擇:Portal 的 web 層走的是 reactive,不是大家最熟悉的那套「一個請求配一條執行緒」。當時只...

2026-08-06 ‧ 由 木木貝爾 分享
DAY 6

第陸天|事件迴圈的鐵律

昨天結尾我說了這麼一段話:reactive 用少數幾條執行緒撐起高並行,本錢是「事件迴圈絕不空等」這個能力,但同一個本錢也是弱點——只要有一段程式在事件迴圈上一...

2026-08-07 ‧ 由 木木貝爾 分享
DAY 7

Day 7|reactive 下的上下文傳遞

昨天 Day 6 結尾埋了一個問題:既然 reactive 下一個請求會在不同執行緒間流轉,那「這位使用者是誰」「這次請求的追蹤碼是什麼」這些隨身資訊,要怎麼跟...

2026-08-08 ‧ 由 木木貝爾 分享
DAY 8

Day 8|身分始於 SSO

Day 7 我們把身分和追蹤碼這兩件「隨身行李」從執行緒身上挪下來,改掛在請求本身(request context)上,讓它們跟著資料流走、跨幾條執行緒都不掉。...

2026-08-09 ‧ 由 木木貝爾 分享
DAY 9

Day 9|是誰在那裡??

昨天 Day 8 把身分的源頭講清楚了:使用者是誰,在他登入 SSO(單一登入)那一刻就由帶 HMAC 簽章的 cookie 確立,往後每個請求靠驗章重新確認,...

2026-08-10 ‧ 由 木木貝爾 分享
DAY 10

第十天|容錯不對稱:fail-open vs fail-closed

昨天我們看著一個請求進門:先貼上 correlation id a1b2c3d4,再驗 cookie、還原出「他是誰」,把身分放進請求上下文一路帶下去。今天要追...

2026-08-11 ‧ 由 木木貝爾 分享