0. AI 沒有降低門檻｜它只是把「判斷力」變得更值錢
這場 AI x Web3 School 的題目是「AI 時代，Web3 開發者需要具備的基礎知識和架構能力」。如果只看標題，它很像一場給入門者的基礎課；但實際上，這場分享真正值得留下來的，是一個比入門更重要的問題：當 AI 已經可以快速產生程式碼，開發者還需要學什麼？
講者一開始就把答案講得很直：如果基礎知識和架構能力不足，人就沒有辦法判斷 AI 端上桌的是食物還是幻覺。
這句話在 Web3 場景尤其重。一般 Web2 產品裡，AI 寫錯一段程式，最糟可能是頁面壞掉、訂單狀態錯誤、服務需要 rollback；但 Web3 裡，錯誤常常直接碰到資產、私鑰、簽名、授權與鏈上不可逆交易。當 AI 產生一段「看起來能跑」的合約互動、支付監聽或錢包授權流程時，真正危險的不是它完全不會寫，而是它寫出一個你看不懂、也無法驗證的東西。
講者把人與 AI 的協作邊界拆成兩邊。人要做的是設計方案、評估方案合理性、驗收程式執行結果、分析問題；AI 則適合協助細化方案、補足資料流與請求流、根據 plan 編碼，並透過自我驗證反覆修正。換句話說，AI 很適合放大工程能力，但它不能替代工程判斷。
這也是近年 AI coding 最容易被誤解的地方。很多 demo 展示的是「從 prompt 到程式碼」的速度，卻很少展示「從程式碼到可信系統」的過程。速度只是第一層。真正進入產品、金流與安全場景時，問題會變成：規格是否完整？邊界條件是否被列出？測試是否覆蓋資產風險？錯誤是否會擴散？AI 自我驗證到底驗證了什麼？
在這個框架下，AI 不是讓基礎知識變得不重要，而是讓「能不能審稿」變得更重要。以前一個初階工程師可能慢慢寫、慢慢查、慢慢踩坑；現在 AI 可以一次產出大量程式碼，錯誤也可能被大量放大。當產出速度提高，審核能力就成為瓶頸。
所以這場分享的第一個結論不是「大家都要成為底層專家」，而是：你至少要知道自己在讓 AI 做什麼。你要能看懂它拆出來的資料流，知道請求從哪裡來、狀態在哪裡變、資產在哪裡動、簽名授權代表什麼；你也要能判斷方案裡哪些步驟可以自動化，哪些步驟不能交給模型自行決定。
如果用一句話收束，就是：AI coding 讓「寫程式」變便宜，但讓「知道該寫什麼、怎麼驗證、哪裡不能錯」變貴。
1. Web3 不是另一個宇宙｜它更嚴格，但沒有離開 Web2 工程
第二個常見問題是：Web3 和 Web2 是不是完全不同的體系？
講者的回答很務實。Web3 的確更嚴格，尤其在安全與資金互動上；但它不是一個和 Web2 完全斷裂的宇宙。很多 Web3 專案裡，Web2 能力占比其實很高，甚至高到如果沒有成熟的 Web2 工程，整個產品根本跑不起來。
以中心化交易所為例，使用者表面上是在買賣加密資產，但背後需要大量 Web2 系統支撐：帳戶系統、KYC、風控、撮合、客服、通知、資料倉儲、後台管理、監控告警、前端體驗。這些不是鏈上合約能單獨解決的問題。預測市場、DeFi 介面或鏈上交易產品也是如此：即使核心資產或結算在鏈上，前端、索引、狀態管理、資料查詢與使用者流程仍然高度依賴 Web2 能力。
這個觀點很重要，因為它修正了「學 Web3 等於只學合約」的想像。合約是 Web3 系統的一部分，但不是全部。使用者不會直接生活在合約裡；他們生活在錢包、前端、交易流程、通知、訂單狀態、客服與風控構成的完整產品裡。任何一個環節沒設計好，都可能讓鏈上邏輯再正確也無法形成好產品。
講者也從安全角度補了一刀：在很多 Web2 專案裡，安全常常被放在「先跑起來再補」的位置；但 Web3 因為牽涉資金交互，安全必須源於設計。這句話不是口號。Web3 的攻擊面常常是公開的，合約上線後就暴露在所有人面前，資產也可能在漏洞被利用後立刻轉走。審計可以降低風險，但不是安全的全部；如果系統設計本身就沒有處理好權限、資金流與信任邊界，審計只是在已經偏掉的路線上幫你找坑。
這裡可以把開場的三個結論整理成一組基準線：
第一，AI 沒有降低對人的要求，反而提高了對判斷力的要求。
第二，Web3 不是孤島，Web2 工程能力仍然是產品能不能被使用的基礎。
第三，Web3 安全不能只靠上線前審計，而要從架構設計開始。
這三句話合在一起，就是後面支付系統案例的背景。講者不是在教大家背 Web3 名詞，而是用一個大家熟悉的金流場景，示範信任邊界如何在 Web2 和 Web3 之間移動。
2. 支付系統裡的信任邊界｜把銀行換成鏈，不代表問題消失
整場分享最好的切入點，是講者用支付系統來說明 Web2 和 Web3 的差異。支付是一個非常適合拿來比較的場景，因為它逼你回答三個工程問題：錢怎麼流？狀態怎麼更新？信任在哪裡？
傳統 Web2 支付可以簡化成幾個角色：使用者在電商平台下單，電商平台建立訂單並呼叫支付服務；支付服務再接銀行或支付機構，展示付款資訊給使用者；使用者完成法幣支付後，銀行或支付機構 callback 給支付服務，支付服務再通知電商平台更新訂單狀態。最後，平台根據付款完成狀態出貨或提供服務。
這套流程裡有兩條流。第一條是資料流：訂單建立、支付請求、付款結果、callback、狀態更新。第二條是資金流：錢從使用者的銀行帳戶出去，進入支付服務或銀行體系控制的帳戶，最後再清結算給商戶。
看起來很平常，但信任其實藏在每一步。電商平台要信任支付服務回傳的付款結果；支付服務要信任銀行或支付機構的 callback；使用者要信任銀行帳本裡的餘額；各服務之間要用 API key、secret、簽章或其他方式確認請求不是偽造的。這些信任很多時候不是靠技術單獨完成，而是靠機構、合約、牌照、清結算制度與營運流程共同支撐。
當這套系統改成支援穩定幣支付，變化並不是「整個系統全部重寫」，而是信任邊界移動了。原本接銀行或支付機構的位置，換成了區塊鏈；原本等待銀行 callback 的位置，換成了鏈上監聽服務；原本使用者輸入法幣支付資訊，換成了錢包對地址轉帳或簽名授權。
在穩定幣支付裡，電商平台可以產生一個付款地址，使用者把 USDC 或其他代幣轉到該地址，交易被寫入鏈上。鏈上監聽服務看到這筆交易後，解析地址、金額、代幣與確認數，再通知支付服務更新訂單。最後，平台仍然要把訂單改成已付款，仍然要處理發貨或服務開通。
這說明 Web3 不是把支付系統變簡單，而是把原本由機構承擔的一部分信任，轉移到鏈上資料、簽名、共識與監聽邏輯上。你不再信任某個銀行 callback 說「這筆錢到了」，而是信任鏈上交易狀態、節點資料、合約邏輯與自己的監聽系統。
但這也帶來新的工程責任。鏈不會主動打電話告訴你的後端「訂單付款完成」。你要自己監聽、解析、確認、重試、去重、處理 reorg，並保證訂單狀態不會被錯誤更新。Web3 解決的是一部分信任問題，不是替你免除系統設計。
3. 區塊鏈取代的是信任方式｜不是讓信任消失
講者在支付案例裡特別提醒一件事：Web3 不是「沒有信任」，而是改變信任的來源。
在 Web2 支付裡，我們信任銀行、支付機構、平台與它們之間的合約關係。在 Web3 支付裡，我們信任資料不可竄改、合約邏輯公開透明、相同輸入在相同狀態下會得到相同結果，以及共識機制能讓多數節點對狀態達成一致。這些信任比較技術化，但它仍然是信任。
這個差異值得講清楚，因為 Web3 很容易被說成「trustless」。比較精確的說法是，它降低了對單一中心化機構的信任，並把信任拆散到密碼學、共識、開源程式、節點網路與使用者自我保管上。它不是把風險消滅，而是把風險換了位置。
舉例來說，傳統支付的風險可能在支付機構 callback 被偽造、帳務資料被竄改、內部權限濫用，或清結算出錯。Web3 支付的風險則可能在私鑰外洩、錢包簽名被釣魚、RPC 節點回傳資料不可靠、監聽服務漏單、合約授權過大、reorg 後訂單狀態沒有修正。問題沒有消失，只是從「信任機構」變成「信任協議與你的工程實作」。
這也是為什麼講者反覆回到基礎知識。你不需要一開始就能推導所有共識協議或簽名演算法，但你要知道它們在系統裡扮演什麼角色。區塊鏈提供不可輕易竄改的狀態與公開可驗證的執行環境；私鑰與簽名提供控制權證明；合約提供可重複執行的邏輯；節點與 RPC 則提供讀寫鏈上狀態的入口。
如果開發者看不懂這些角色，就很容易把 Web3 當成另一種 API：呼叫一下錢包、送出一筆交易、查一下鏈上結果。這樣可以做 demo，但很難做可靠產品。真正的設計問題是：哪個狀態可以相信？需要幾個確認數？RPC 回傳結果要不要交叉驗證？監聽服務掛掉後怎麼補掃？使用者簽名時看到的內容是否足夠清楚？
AI 在這裡可以幫忙寫很多程式，但不能替你定義信任模型。如果你沒有先說清楚系統信任什麼、不信任什麼，AI 只會根據常見樣板補一套看起來合理的實作。那套實作可能適合 demo，不一定適合碰錢。
4. 錢包是身份與資產入口｜私鑰、簽名與控制權
支付案例往下走，錢包就成為核心。講者用一個很簡單的模型拆錢包：錢包的輸入是 private key，輸出是 signature。私鑰可以先理解成一串秘密數字，簽名則是在不洩漏秘密的前提下，證明「我持有這個控制權」的方法。
錢包在 Web3 裡同時扮演兩個角色：身份證明與資產授權。
身份證明的場景通常是消息簽名。網站要確認你是不是某個地址的持有人，可以產生一段訊息，請你的錢包簽名。你把簽名交回網站後，網站可以驗證這個簽名是否對應到該地址。整個過程中，網站不需要知道你的私鑰，卻能確認你掌握該地址。
資產授權的場景則是交易簽名。當你要轉帳、授權合約、鑄造 NFT、呼叫某個鏈上功能，錢包會組出交易內容，請你用私鑰簽名。簽名有效時，鏈就承認這是你授權的操作。鏈不會問你是不是本人，不會寄簡訊驗證碼，也不會找客服確認；它只看簽名是否有效。
這帶來很高的自主性，也帶來很高的風險。Web2 帳號密碼忘了通常可以重設；銀行卡遺失可以掛失；支付平台帳號被盜還可能有客服流程。但 Web3 私鑰丟了，通常就真的失去控制權；私鑰外洩時，攻擊者也能簽名，而且鏈會承認他的簽名。
講者提到一個很直觀的情境：如果使用者和攻擊者都拿到同一把私鑰，資產找回有時候會變成「搶交易」。誰先把資產轉走、誰的 gas 設得更好、誰的交易先被打包，結果就可能完全不同。這不是傳統客服能輕易處理的問題，而是控制權已經被密碼學地交給了私鑰持有人。
簽名釣魚也是另一個核心風險。使用者看到的畫面可能像是登入、領取獎勵或確認某個安全操作，但實際簽下去可能是授權合約移動資產，或直接簽了一筆危險交易。EIP-712 這類可視化簽名規格，就是希望讓使用者更清楚看到自己簽了什麼；但講者也提醒，對一般使用者來說，這仍然偏技術，不能假設「有顯示內容」就代表安全。
所以錢包不是 Web3 的 UI 小工具，而是整個安全模型的入口。理解錢包如何產生地址、如何簽名、如何授權、如何被釣魚，是 Web3 開發者不能跳過的基礎。
5. 交易生命週期與鏈上監聽｜從按下確認到訂單完成
使用者在錢包裡按下「確認」只是表面。對系統來說，一筆交易有完整生命週期。
第一步是構造交易。應用程式或前端要決定轉給誰、轉多少、呼叫哪個合約、data 欄位是什麼、gas 相關參數如何設定。第二步是錢包簽名。使用者確認後，錢包用私鑰對交易簽名。第三步是廣播交易。簽名後的交易會被送到節點網路。第四步是節點驗證。節點檢查簽名、nonce、餘額、gas 與狀態是否有效。第五步是交易進入區塊，鏈上狀態更新。第六步是外部系統監聽到交易結果，更新自己的資料庫或訂單狀態。
這裡最容易被低估的是最後一步：鏈上監聽。對使用者來說，錢轉出去了；對電商或支付系統來說，必須可靠地知道哪一筆鏈上交易對應哪一筆訂單。監聽服務要處理地址、金額、代幣、鏈別、確認數、重試、去重與異常狀態。這些都不是「查一下鏈」就結束。
講者提到兩種常見方式：一種是輪詢 RPC，例如定期查 block、交易或事件；另一種是 WebSocket 訂閱新區塊或事件。WebSocket 看起來像推送，但很多客戶端實作底層仍然可能是定期查詢再包成推送介面。工程上真正要思考的，不是名字叫 polling 還是 subscription，而是可靠性。
例如，服務暫時斷線時要怎麼補掃？RPC 回傳資料不一致時要不要用其他節點交叉驗證？交易在低確認數時被 reorg 怎麼辦？同一筆交易被重複掃到會不會重複入帳？如果使用者轉錯金額、轉錯 token、轉到過期地址，系統怎麼處理？這些才是支付監聽真正困難的地方。
問答裡有人提到想做多鏈監聽，講者建議可以參考 epusdt 類型的開源多鏈收款實作。這個建議背後的思路很對：學 Web3 不能只看概念，要看能跑的系統如何處理地址生成、鏈上掃描、交易確認、資料落庫與 API 查詢。真實系統裡，細節比名詞重要。
這段也再次呼應 AI。AI 可以很快幫你寫出一個監聽服務，但如果你沒有把補掃、確認數、重試、去重、reorg、RPC 失真、資料落庫與對外查詢壓力寫進規格，它大概率只會給你一個能 demo 的版本。能 demo 不等於能碰錢。
6. 託管、多簽與帳戶抽象｜不要只問技術，要問控制權在哪裡
分享後半段轉向錢包分類。講者先從 EVM 生態談帳戶型態：EOA 是外部帳戶，由私鑰直接控制；合約錢包是鏈上程式控制的帳戶；AA，也就是 Account Abstraction，則試圖讓帳戶具備更彈性的可程式化能力，改善使用者體驗與安全策略。
這些名詞可以先不用一次背完。更重要的問題是：誰能移動資產？需要幾個條件？失去某個條件時能不能恢復？被攻擊時能不能止血？
從控制權來看，錢包可以粗略分成自託管、全託管與混合託管。
自託管代表私鑰在使用者自己手裡，自由度最高，也最符合 Web3 的自主精神；但風險也完全由使用者承擔。私鑰丟了、助記詞外洩、簽名被騙，後果通常很難逆轉。
全託管比較像交易所帳戶。使用者不直接碰私鑰，體驗簡單，恢復流程也比較接近 Web2；但使用者必須信任服務商保管資產、管理風控、遵守規則，並承擔服務商本身的營運與安全風險。
混合託管則介於兩者之間，常見做法是 MPC 或合約錢包，把控制權切成多份，讓使用者與服務商都不能單獨完成高風險操作。這類設計的重點不是名詞，而是權限拆分：不要讓單一私鑰、單一服務或單一人員能夠獨立移動所有資產。
多簽是這裡最容易理解的風控工具。常見的 2-of-3 或 3-of-5，代表不是任何一把鑰匙都能獨立移動資產。公司資產、DAO 財庫、團隊共管資金，通常都不應該依賴單一私鑰。EOA 世界可以透過 MPC 把私鑰切片；合約錢包世界則可以在合約邏輯裡直接定義門檻與規則。
AA 的方向則是把帳戶變得更像可程式化的安全邊界。它可以支援更彈性的驗證方式、恢復流程、批次操作、gas 代付、權限限制與使用者體驗。但講者也提醒，具體方案仍在演化，像 4337、3074、7702 等都曾出現在以太坊路線討論裡。對開發者來說，與其追逐每個 EIP 的短期熱度，不如先理解帳戶抽象想解決什麼問題：讓「誰能做什麼」不再被單一私鑰模型綁死。
這些討論最後都回到同一個核心：控制權。Web3 安全不是只看合約有沒有 bug，也不是只看錢包支援哪個標準，而是看資產控制權如何被建立、拆分、限制、恢復與審計。
7. Agent payment 的核心是權限｜不是把免密支付接上 AI 就好
問答裡有人提到 agentic payment 或小額免密支付。這是 AI 與 Web3 交會時很自然會出現的問題：如果 AI agent 可以幫人執行任務，它能不能也幫人付款？能不能在某些條件下自動花 token？能不能不用每次都叫人確認？
講者的回答很值得記：這不只是支付層問題，而是帳戶權限與信任邊界問題。
如果只從支付角度看，很容易把問題簡化成「怎麼做免密」、「怎麼讓小額自動過」、「怎麼讓 agent 發交易」。但真正的問題是：agent 被授權做什麼？每天最多花多少？單筆上限是多少？可以付給誰？可以呼叫哪些合約？異常行為如何拒絕？授權如何撤銷？事後如何稽核？
比較合理的設計，是把 agent 當成帳戶權限的一部分，而不是讓它直接拿到完整私鑰。你可以想像一個 2-of-2 或多方權限模型：人持有一份權限，agent 或服務持有一份權限，風控規則作為第三道條件。低於規則的交易可以自動通過；超出金額、頻率、對象或風險條件的交易，則拒絕或升級成人工確認。
這和傳統金融風控其實有相似處。信用卡也不會對每筆小額交易都要求你打電話確認，但它會設定額度、偵測異常、保留拒絕或凍結能力。差別在於 Web3 的授權更接近密碼學控制權，錯誤授權可能更難追回，所以權限設計要更精細。
這裡也能看出 AI 時代 Web3 開發者需要的能力組合。你不只要知道怎麼發交易，還要知道怎麼設計規則；不只要知道怎麼簽名，還要知道怎麼限制簽名能做的事；不只要知道怎麼自動化，還要知道哪些行為需要升級、拒絕或留痕。
Agent payment 不是一個單純的新支付 API，而是一套帳戶權限、風控、資產控制與可追蹤性的設計問題。AI 讓自動化需求變強，Web3 讓控制權更直接，兩者加在一起，安全邊界只會更重要。
8. 能力模型要從場景倒推｜基礎、架構、安全，再加 AI 協作
最後，講者在問答裡給了一個很務實的學習建議：不要先問「Web3 要學哪些全部知識」，而是先問「我想做哪個場景」，再從場景倒推能力。
如果你想做鏈上安全，就要理解主流鏈架構、合約執行模型、交易生命週期、常見攻擊面、審計方法與逆向能力。如果你想做支付，就要理解地址生成、交易監聽、確認數、資金歸集、對帳、風控與商戶結算。如果你想做錢包，就要理解私鑰、簽名、託管、多簽、MPC、合約帳戶與使用者體驗。如果你想做 agent payment，就要理解權限拆分、限額、授權撤銷、異常檢測與稽核。
這種倒推法比死背知識清單有效，因為 Web3 的範圍太大。鏈、合約、錢包、交易所、DeFi、跨鏈、ZK、MPC、安全、支付、資料索引，每一塊都可以深到變成獨立職涯。對初學者來說，最容易迷路的不是資訊太少，而是資訊太多。先選場景，再補能力，才有方向。
如果把整場分享濃縮成能力模型，大概可以分成四層。
第一層是基礎能力。你要知道鏈、帳戶、交易、合約、錢包、簽名、RPC、事件與狀態是什麼。這一層不一定要求你一開始就能實作所有底層演算法，但要能理解系統裡每個元件的責任。
第二層是架構能力。你要能把一個產品拆成資料流、資金流、信任邊界與失敗模式。支付案例裡，Web2 和 Web3 的差異不是名詞，而是整個信任模型、監聽流程與風控責任的移動。
第三層是安全能力。你要在設計階段就問：資產如何被盜？授權如何被濫用？監聽如何漏單？callback 如何被偽造？私鑰如何外洩？RPC 如何失真？重複入帳如何避免？安全不是最後買一次審計，而是貫穿設計、開發、上線與營運。
第四層是 AI 協作能力。你要能把需求寫成規格，把場景拆成任務，把驗證條件交代清楚，讓 AI 幫你加速實作，而不是讓 AI 替你決定架構。AI 可以協助你查資料、產出方案、寫程式、補測試、做初步驗證；但人仍然要負責定義問題、審核方案、承擔結果。
這也是這場分享最適合放進魚塘的原因：它不是把 Web3 講成一堆新名詞，而是用支付這個老問題，把 AI、架構、安全與信任重新接起來。Web3 開發者真正要學的不是「鏈上版本的 CRUD」，而是當信任邊界改變時，整個系統應該如何重新設計。
AI 時代的門檻不是消失，而是換了形狀。會寫程式的人變多了，能判斷系統是否可信的人反而更稀缺。對 Web3 開發者來說，這可能是最重要的提醒：程式碼可以由 AI 加速產生，但資產風險、信任邊界與架構責任，仍然必須由人看懂並承擔。