# 2025 webconf 心得分享
:::info
[官方共筆入口](https://hackmd.io/@webconf/HJiwwqnxZe/%2F9SP9NyHoSiSZEOYHsaeYeg)
:::
# 總覽
統整內容重點項
> 議程大致有安排 前端/後端/PM 三個面向在同一時段，我聽後端居多
底下會重點拎幾個主題出來講，其他詳細的內容建議參考官方共筆
* 需求
* AI 協助產出 MVP / Prototype（PO & PM）
* 提早看到價值
* 釐清需求細節
* 需求規格化要全團隊參與
* 讓 AI 和人類都看得懂
* 關鍵：該需求解決了什麼問題？
* GA [數據追蹤](https://hackmd.io/@webconf/HJiwwqnxZe/%2FWS10vh3_RhGEZP_oxRhZTg)
* 驗證問題是否被解決，以及未來決策的走向
* 開發
* AI APP (Agent)
* AX
* Agent 的開發與可視化
* Agent 要能穩定的解決問題，"可以動"很容易，實際可用比較難
* SDD 提高 vibe coding 穩定產出
* 結合 TDD 更強大
* prompt 版控
* 資安
* 與 AI 協作
* AI 已經取代碼農
* 問對問題才能解決問題
* 測試
* AI Agent
* Playwright Agent 幫你寫界面測試 & 自動修復程式
* 無障礙設計很重要 [參考](https://www.facebook.com/share/p/1BWbKhYPyQ/)
* AI 協助寫測試案例效果有限
* 維運
* AI Agent
* 與人或其他 Agent 協作解決問題
* AI 服務的數據觀測指標
* 持續重構迭代
* [營救 Legacy Code 沒有捷徑](https://hackmd.io/@webconf/HJiwwqnxZe/%2F_KlVlnVMSiSJiFx49_xaEg)
* [DevOps](https://hackmd.io/@webconf/HJiwwqnxZe/%2FwVkrSNJBSr-yBIycrXyAxw)
* 適應變化

# 需求
### 先做 Prototype 再做 Product
MVP & Prototype 是這時代最重要的能力，盡可能地看見全貌然後逐步實現

#### 用 Prototype ~~取代~~ 簡化 Document
當 PM 可以自己做出產品的 Prototype，PM 就可以直接針對這個 Prototype，自己跟 AI 對話，然後自己跟自己對話，回頭自己調整，而不用等到產品真的做出來才去頓悟，「啊！原來這裡要這樣改」，去花費整個團隊投入的資源

而最關鍵的資源，是「時間」
團隊做出來時才說「不是你要的」，花費了可能 2 個月，而透過 Prototyping，是 2 分鐘


### 開發流程變革：PRD -> PRP
:::info
[B2B 服務的 AI Agent 產品設計原則 - 李昆謀
](https://hackmd.io/@webconf/HJiwwqnxZe/%2Ff1Eeu9_HTWKIey9mRPBr0A)
:::
從「取代」到「賦能」的 AI 開發思維
演講者強調，AI 開發不應只是想著用 AI 取代現有功能（Replacement），而應該思考如何透過 AI 增強現有能力（Enhancement）或解決過去無法解決的**商業問題**
#### 傳統 vs. 新流程
* 過去
* PM 寫規格書 (PRD) -> 工程師寫 Code
* 現在
* 提倡 PM 使用 AI 工具（如 Claude, NotebookLM）生成 PRP (Product Requirement Prototype)
* Project Manager --> Prototyping Master
能更精準地與工程師溝通需求，減少開發後的修改成本

> 結論：PM 要會 Vibe Coding 嗎？ Yes

# 開發
## SDD
因為我們不會導入，這邊只有簡單整理
:::info
[軟體開發邪教的救贖：AI 時代更應掌握的 TDD 技能 - Kuma Syu](https://hackmd.io/@webconf/HJiwwqnxZe/%2FTle_Ecv6TjOKnL7UPhcpZg)
:::
### SDD 的概念
用「文件即程式碼」連接開發與團隊
將文件當作程式碼管理，達到「唯一事實來源」的效果
讓需求文件不再只是開發的附屬品，而是真正融入開發生命週期的核心
### SDD、TDD 雙劍合璧
#### 精髓
在動手寫程式之前，先寫出可描述需求的測項，又能藉以保護功能，一舉兩得
而測試覆蓋，則方便重構迭代

#### 怎麼執行
可不可以這樣？

...或這樣？啊，這就不就 TDD

### Vue Vibe Coding
:::info
[AI 只懂 React？Vue.js 也能 Vibe Coding！- Kuro Hsu](https://hackmd.io/@webconf/HJiwwqnxZe/%2FSsKHqlcXSaqzzoyt-peN7Q)
:::
簡單說明規格化的好處，並提出一種方便閱讀和版控的 SDD 方案，且後續方便自動化測試

* spec 明確定義行為，AI 修改有邊界
* spec 就是文件，變更歷史可追溯
* `<spec>` 區塊常駐檔案， 開發時 AI 自動讀取，發佈時自動去掉
* spec 作為驗收標準，不依賴 AI 的一致性
* 可維護可追溯的 workflow
## Agent 開發
:::info
⭐️ **[構思觀念！](https://docs.google.com/presentation/d/e/2PACX-1vRRYD6cGGqnkrsJETMLgq1yQb_aJrfkNigqAeTwO8Dfw_rVoO_zjC6-QwKFTe6wSK4UYiRUxD2v_KJZ/pub?start=false&loop=false&delayms=3000&slide=id.g3adc4c6dbf3_0_178)**
[SaaS 的下一步：從 Service 到 Agent - 安得魯
](https://hackmd.io/@webconf/HJiwwqnxZe/%2FMwd6YO29QPWRcI1WL15hkA)
:::
:::info
⭐️ **[實作方法！](https://ihower.tw/presentation/ihower-agents-202512.pdf)**
[實戰 AI Agents 應用開發：從 Web 後端到前端的整合 - 張文鈿 ihower](
https://hackmd.io/@webconf/HJiwwqnxZe/%2FjioJQzn_SlyxNCTzy9nCvQ)
:::
### 什麼是 Agent
#### LLM Model-based vs. Agent-based
* 模型 (Model-based)： 像是**靜態諮詢師**
* 只能根據訓練過的資料，進行單次問答預測
* 重點在於解釋資訊或生成內容
* 代理程式 (Agent-based)： 像是**數位員工**
* 能連接外部系統、使用工具，並具備記憶與推理邏輯
* 重點在於執行任務（Action Oriented），幫你把事情做完

#### Agent 是會使用工具的 LLM

> 中間皆是 MCP 參與的部分

講者說目前主流開發語言是 python 和 js，其他的工具支援度沒那麼高
### UX 使用者體驗
腦中沒有畫面的話，可以想像一下正在使用 Cursor 或 AI 客服 之類的
#### streaming
1. 實時提示推理過程或階段性結論，避免長時間和使用者沒有互動
* Server-Sent Events
* 思考進度、推理摘要等
3. LLM 不中斷，即使前端斷線也可以從上次斷掉的地方連回去
> 透過 redis stream 將回應先存起來再一筆筆取用，實現非同步解耦
4. 要做一開始就得做，後面再加很麻煩
#### streaming chunk 訊息標準化
AG-UI 是一種協定，Server 端把各家 LLM 的回傳結果標準序列化後再丟給 Client 端，Client 端用套件如 CopilotKit 來解析內容
* [AG-UI](https://docs.ag-ui.com/introduction) (後端) 
* [CopilotKit](https://www.copilotkit.ai/) (前端)

#### UI 組件標準化
MCP-UI 是一個 SDK，讓 MCP Server 端可以回傳「介面描述（UI Resource）」，而 Client 端（如 AI 聊天視窗）能把它渲染成真的網頁元件

> AG-UI 和 MCP-UI 兩者可同時使用，不衝突

#### TTFT (Time-to-First Token)
Time to First Token，用戶首個看到 Token (輸出) 的時間
監控工具可以幫忙簡單的記錄，但若自定義有效輸出要自己記

##### 改進方式 = 模型效率
* 模型選擇
* Prompt 工程
* Prompt Caching
* 合併減少 API 呼叫次數
* 已知的問題型態，用非推理模型
* 平行化 + 部分改用小模型
* 開 Priority processing

### 提高模型效率 & 省錢
#### Prompt 工程

[結構化輸入輸出](https://www.inside.com.tw/feature/2025-generative-ai/38543-91app-how-to-build-high-accuracy-ai-functions)，AI 理解得更精確，產出的結果也好拿來用
只用自然語言的話模糊空間太大，容易產生無效的內容
#### Prompt Cache 快取命中 => 省 token
* 讓 prefix 固定
* JSON 序列化保持固定順序
* **保持上下文僅有追加**
* 在流程之間，盡量 append items，而不是拿前一個 output 重組新的 prompt
* 不要動態更改工具呼叫定義
* 原因：為了讓 Agent 在處理用戶問題前就知道有哪些工具可用，工具定義通常會放在 Prompt 的最前面
* 熟悉各家 Prompt Cache 設定

#### 其他比較複雜一點，請看簡報有很多範例[從 55 頁開始](https://ihower.tw/presentation/ihower-agents-202512.pdf)
>有點類似我們在開發某個功能，要根據業務情境去設計服務的規格、併發機制和數量、語法要不要批次下等等，有很多做法，選擇哪些和經驗有關
### Context Engineering
<img src="https://hackmd.io/_uploads/BJD06QgmWl.png" style="padding: 10px; background-color: white;">

### 怎麼知道有沒有做對？
#### 量化指標並制定改善策略
:::spoiler *我對上面四項的理解*
1. 在著手建構系統之前，就應該明確了這個系統核心要解決的問題
唯有釐清問題，我們才能針對性地訂定出使用者最在意的關鍵指標（偏商業價值）

2. 接著，我們可以根據這些指標來收集相關的參考資料
以領域知識對資料進行梳理與歸納，我們便能找出指標不如預期的背後原因，進而對症下藥

3. 同時，我們必須確保 AI 的應用符合指標，我們最需要的且他最擅長的地方
若讓 AI 執行不擅長或錯誤的任務，不僅無法解決問題，更會降低服務效率並增加不必要的成本

4. 總結來說，方向做對了，我們就能夠進一步考慮如何做得更好
:::
#### 如何量化？
* 驗證產出是否符合規範
* 由 AI 自己標記評估結果，降低人工負擔
* 使用者情緒感知
#### Agent 的核心價值
* 專家不是只給答案，而是有一套可重複的思考流程
* AI 若沒有被拆解成穩定流程，只會停留在 Prototype
* Agent 的價值，在於把「不穩定的生成能力」變成「可控的產出能力」
## Agent 維運
控制良率、效率和成本所需的服務監控數據支持 --> 觀測性
做對了之後，要持續做得更好
:::info
[初探 LLM 可觀測性：打造可持續擴展的 AI 系統 - Mike Hsu](https://hackmd.io/@webconf/HJiwwqnxZe/%2FO_bBsYiqTHysuP27CMdbwQ)
[（我請 NoteBookLM 根據簡報整理出的筆記）](https://notebooklm.google.com/notebook/9160be23-301e-4cf5-ab3d-94f7114af96a)
:::
> Try it： 讓 NoteBookLM 告訴我們為何講者認為觀測性重要
### LLM vs. 傳統服務的可觀測性
| 比較維度 | 傳統服務可觀測性 (Traditional Observability) | LLM 可觀測性 (LLM Observability) |
| -------- | -------- | -------- |
| 遙測數據<br>(Telemetry) | CPU 使用率、記憶體使用量、應用程式 Log | 完整的 Prompt (提示詞)、完整的 Response (回應)、使用者詳細資訊、模型參數 (如 Temperature, Top_p) |
| 關鍵指標 (Key Metrics) | 成功/失敗狀態碼 (Status Codes)、錯誤率 (Error Rates)、延遲 (Latency) | 除了延遲與狀態碼外，還包含 Token 使用量 (Input/Output Tokens)、例外狀況 (Exceptions) |
| 輸出特性<br>(Output) | 確定性 (輸入相同，輸出必相同) | 非確定性 (輸入相同，輸出可能不同) |
| 品質評估<br>(Quality) | 系統是否正常運作 (Uptime, Availability) | 語意正確性 (Semantic Correctness)、上下文相關性 (Relevance)、內容毒性 (Toxicity)、幻覺 (Hallucination)、流暢度 (Fluency) |
| 成本因子<br>(Cost) | API 呼叫次數、基礎設施資源 (CPU/Memory) | Token 使用量、不同模型的定價 (Per-model pricing) |
| 關注焦點<br>(Focus) | 系統層面的健康度與效能 | 模型輸出的內容品質、安全性與邏輯一致性 |

### Model-based AND Agent-based 的治理策略
| 策略維度 | 模型 (Model) 的策略 | 代理程式 (Agent) 的策略 |
| -------- | -------- | -------- |
| 可觀測性<br>(看什麼？) | **看「結果」與「成本」**<br>監控有無幻覺、毒性內容、以及 Token 使用量 | **看「過程」與「行為」**<br>必須追蹤推理路徑 (Tracing)、工具使用狀況與多輪對話的記憶一致性 |
| 治理重點<br>(管什麼？) | **內容審查 (Content Filter)**<br>利用護欄 (Guardrails) 雙向過濾輸入與輸出，防止不當回答 | **權限控制 (Permission & Control)**<br>因為會執行動作，需加入「人機介入 (Human-in-the-loop)」機制來審核關鍵決策 |

> 講者有提出一些比較具體的實行方法，但我們也還沒做到那邊，就先不深入研究

## AX

| 比較項目 | **UX (User Experience)** | **DX (Developer Experience)** | **AX (Agent Experience)** |
| :--- | :--- | :--- | :--- |
| **全名** | 使用者體驗 | 開發者體驗 | **代理體驗** |
| **主要使用者** | 人類 (Human) | 軟體工程師 (Developer) | **AI Agent (機器/模型)** |
| **互動介面** | GUI (圖形介面)、視覺、按鈕 | SDK、CLI、文件、程式碼 | **API、結構化資料、Prompt** |
| **核心需求** | 直覺、美觀、情感連結 | 文件清楚、工具好用、除錯方便 | **確定性 (Determinism)、容錯率、上下文完整** |
| **溝通語言** | 自然語言、視覺符號 | 程式語言 (Python, JS 等) | **JSON、XML、Schema、Function Calling** |
| **設計重點** | 減少點擊次數、視覺引導、防呆 | 減少重複性代碼 (Boilerplate)、易於整合 | **減少幻覺 (Hallucination)、明確的工具定義、自我修復能力** |
| **成功指標** | 轉換率、停留時間、NPS | 開發速度、API 採用率 | **任務完成率 (Success Rate)、Token 消耗量** |

> **確定性**
> 時區時間格式、標準化輸出、參數意義明確

> **容錯率 & 自我修復**
> 過程中發生錯誤時，能理解錯誤訊息、自行修正後再嘗試，而非直接把錯誤拋出

> **明確的工具定義**
> 定義工具的用途和觸發的邊界條件，避免 AI 因幻覺亂呼叫工具導致工具濫用和 token 浪費

# 維運
## 處理問題
:::info
[工程師和 AI 小隊，是合作、競爭、混亂？ - 蕭晊莛](https://hackmd.io/@webconf/HJiwwqnxZe/%2Fbri1B6QHQ023CtEaYiapSA)
:::
建立用來查看服務的 log、metrics、資料庫，
甚至可以在有授權的情況下執行系統指令的 AI Agent (bot)

透過適當的 Context Engineering，並提供足夠的產品 Domain 知識，讓它有能力協助排查線上問題，與工程師做即時互動；甚至每個部門都有自己的 bot，靠 bot 之間自己互動，形成「AI 小隊」

# 測試
:::info
[GenAI 時代下的測試三板斧 - 柯仁傑
](https://hackmd.io/@webconf/HJiwwqnxZe/%2F_JH43d8-R2KbcfRn-e8Z-g)
:::
* AI 仍不太懂軟體測試
* 技術參考文獻偏少，很多廠商文章
* 網路上的參考資料多是 新手練習/不完整的答案/過時的作法
* Prompt 還是要靠軟體測試知識+領域知識，才能下的好

# 資安
:::info
[從冷知識到漏洞：你不懂的 Web，駭客懂 - Huli](https://hackmd.io/@webconf/HJiwwqnxZe/%2FkqRzuYEES9-RuzuW0FLsBg)
:::
* 不同context的相等就是不相等
* `mysql SELECT 'gmail.com' = "GMAIL.com" COLLATE utf8mb4_unicode_ci`
搜尋結果是一樣的，mysql官方寫到 a, A, å, Å 即使是不同的 unicode，但都會被當作同一個 a
* AI 取代人之前，先小心你的字串被取代
* 寫好測試 確保你的 output 是對的
* 絕對不要把使用者的輸入照單全收
* 謹慎使用 /regex/
# 未來
> 能寫出程式碼已經不夠了，擴大專業領域更能幫助團隊交付價值


:::info
[軟體工程不只是寫程式 - 李智樺
](https://hackmd.io/@webconf/HJiwwqnxZe/%2FIKqR_MCoT4WUx-y0AY_06w)
:::
> AI 時代下，除了要具備軟硬技能外，應該要深化最難被取代的濕技能


:::info
[活在科技工作者最好的年代，用商業思維優化你的人生選擇 - 游舒帆](https://hackmd.io/@webconf/HJiwwqnxZe/%2FYYImx_ddQwSqvh496J6e0A)
:::
> 思維創造價值


## 延伸思考
* [這個簡報](https://docs.google.com/presentation/d/e/2PACX-1vRRYD6cGGqnkrsJETMLgq1yQb_aJrfkNigqAeTwO8Dfw_rVoO_zjC6-QwKFTe6wSK4UYiRUxD2v_KJZ/pub?start=false&loop=false&delayms=3000&slide=id.g3adc4c6dbf3_0_178)裡面的思考過程，推薦一定要閱讀，這講者講太快了，內容又偏實例經驗，比較難整理跟轉述
* 寫一個什麼樣的 Agent 可以幫助我們的產品發展？