Chickenrice's Workshop

設定 MCP Server 發生 spawn npx ENOENT spawn npx ENOENT 的解決方法

2025-06-17T11:04:00.003+08:00

在前端開發日常中，nvm（Node Version Manager） 是不可或缺的工具之一。它讓我們可以在多個 Node.js 專案之間快速切換版本，保持每個專案的相容性與穩定性。

不過，當我最近嘗試安裝 Figma Context Mcp 的 server 時，卻因為使用了 nvm 而遇到了一個讓人摸不著頭緒的錯誤: spawn npx ENOENT spawn npx ENOENT。

🔍 問題根本原因（Root Cause）

MCP server 在啟動時會使用 Python 或桌面應用透過 child_process.spawn 的方式呼叫 Node.js 子進程。不過，這種呼叫方式不會載入使用者 shell 的 PATH 設定。

若你是透過 nvm 安裝 Node.js，node 與 npx 的路徑（如 ~/.nvm/versions/node/...）不會自動被納入 PATH，導致 MCP 在啟動時找不到正確的 Node 環境。

簡單來說：nvm 下的 node 不在應用程式能看到的 PATH 中，導致執行 npx 時出現 ENOENT 錯誤。

✅ 可行解決方案

方案一：不用 npx，直接指定完整路徑

將需要啟動的 MCP server 套件安裝為全域模組，然後在設定檔中，改為直接指定 node 執行檔與腳本的完整路徑：

這樣一來就能完全繞過 npx，在無需依賴 PATH 的情況下正確執行 MCP server。

如果想知道 node 安裝路徑，可以善用 where 指令

方案二：讓 Node 被系統找到

如果你仍希望使用 npx，那就必須讓桌面應用或 subprocess 找得到 Node 的執行檔。方法有兩種：

建立 symlink： 將 nvm 安裝的 Node 建立連結到系統路徑中，例如：

這樣可讓任何 subprocess 或應用程式在沒有 shell 的情況下，仍能找到正確的 Node 執行檔。
改用 Homebrew 安裝 Node： 有使用者移除 nvm 改用 Homebrew 安裝 Node.js，因其安裝在 /opt/homebrew/bin 這類系統預設路徑，MCP server 即可正常啟動。

📝 小結

這問題的根本原因其實不在於 MCP 本身，而是 nvm 的環境變數在非互動式環境中無法被繼承。若你也遇到 spawn npx ENOENT 的錯誤，建議優先採用完整路徑執行的方式，或確保你的 Node 可被系統全域搜尋到。

📎 延伸閱讀：GitHub Issue #64

[筆記] AI agents for beginners 第九課: Metacognition Design Pattern 課後心得

2025-06-09T12:44:00.004+08:00

Metacognition Design Pattern：AI 自我反思的力量

TL;DR

本篇文章介紹 AI 中的「後設認知設計模式」，即讓 AI Agent 具備「思考關於思考」的能力，能記錄使用者偏好、分析自身決策並隨時間持續改進。透過機票預訂的範例與程式碼展示，說明如何實作出能記憶、反思並適應不同情境與需求的智能代理。

摘要

這份簡報文件基於「How can AI agents improve?」的影片與課程內容，深入探討後設認知（Metacognition）在 AI Agent 提升能力中的核心角色。後設認知使 Agent 能夠自我反思、自我調整，提升透明性、適應性與決策品質，特別適用於需要理解上下文與長期偏好的場景。

後設認知的定義與應用

定義：「思考關於思考」，即讓 AI 不只反應輸入，還能反思自己的運作與回應邏輯。
應用：AI 可藉由數據與分析，識別錯誤、優化決策與規劃。

“AI agents can use data and analysis to identify errors and make improvements in its planning and responses.”

後設認知對 AI Agent 的優勢

持續進化：從使用者互動中學習、修正並成長。
推理透明：能表達其決策依據，更容易讓使用者信任。
適應環境：可根據使用情境動態調整策略。

“It allows agentic systems to be more transparent on its reasoning and decision making… making it more adaptable.”

✈️ 實例：預訂機票的後設認知應用

課程中以「幫我預訂最佳航班」為例，說明後設認知如何協助 AI 理解並持續考量使用者偏好（如價格、時間、航空公司等）作為決策依據。

“Metacognition comes into play… enabling the agent to reflect on this decision of how it’s defining the best flight.”

程式碼範例：追蹤客戶偏好

Agent 內部維護 customerPreferences 物件，用以記錄使用者偏好。
每次建議前，都會先查閱這個偏好紀錄，讓回應更流暢、個人化。

“We want to make sure before it suggests anything… it goes back to this object.”

上下文與記憶的整合應用

上下文感知：Agent 能根據使用者壓力、時間等情境進行合適規劃。
跨對話記憶：即使是新對話，Agent 也能引用過去偏好做出更好建議。

“Based on your previous preferences for later flights, I’m going to suggest the 7:15 p.m. option.”

結論

後設認知設計模式是讓 AI 從「指令反應者」進化為「能自我學習、調整與解釋」的智慧系統關鍵。透過後設認知，Agent 不僅能更好地理解使用者，還能主動優化自己的回應品質與邏輯結構，使 AI 更貼近真實人類助理的行為模式。

雖然目前應用仍屬初步階段，但其潛力巨大，是開發高階 AI Agent 不可或缺的一環。

科普一下: 後設認知 (Metacognition)

筆者在攻讀研究所時，曾經修習過跟後設認知相關的課程，當時對於工程腦袋的我來說，後設認知要深入探討其實有點抽象。後設認知的概念最早是由心理學家約翰·弗拉維爾（John H. Flavell）在1970年代提出的。他指出，後設認知不僅僅是了解自己知道什麼，而是更深入地了解自己如何學習和思考。在教育研究中，後設認知具有重要意義，因為它直接影響學習效果。具備良好後設認知能力的學生能夠更有效地調整自己的學習策略，從而提高學習效率和成果。這種能力使學生能夠自我監控和自我調整，從而在學習過程中更加主動和自信。

當我們談論「後設認知」（Metacognition）時，我們指的是一種「思考自己的思考」的能力。這是一種自我監控和自我調節的過程，幫助我們更好地了解和控制自己的學習過程。想像你在學習一個新的概念。後設認知就像是你內心的導師，幫助你評估自己對這個概念的理解程度。它會提醒你哪些部分已經掌握，哪些部分需要更多練習或不同的學習策略。這種能力不僅包括對自己理解程度的評估，還包括選擇適合的學習方法、監控學習進度，以及在遇到困難時調整策略。簡單來說，後設認知就是讓你成為自己學習過程的「導演」，讓你更有效地學習和解決問題。這種能力可以幫助你在學術和日常生活中做出更明智的決策。

[筆記] AI agents for beginners 第八課: How to use a multi-AI agent system 課後心得

2025-06-05T16:50:00.004+08:00

TL;DR

這篇文章介紹 Multiple Agent AI System 的概念與應用方式，說明在單一 AI 難以處理複雜任務時，如何透過多個角色明確的 AI 協同完成目標。文中涵蓋三種設計模式（群組聊天、任務移交、協同過濾），並以「前台建議者 + 禮賓審核者」的範例，示範如何透過角色分工與對話控制，提高 AI 輸出的品質與真實感。

文件來源：擷取自「如何使用多 AI 代理系統」影片與相關課程資源

核心主題

本來源詳細探討了在人工智慧應用中採用多個 AI 代理（agent）協同工作的設計模式，以及這種模式的優勢、不同類型和實作範例。

主要概念與事實

多代理設計模式的定義

多代理設計模式是指「多個 AI Agent 一起工作以完成一個共同目標或任務」。

"to put it simply the multi agent design pattern is where we have multiple AI agents working together to complete a common goal or task"

使用多代理的時機

當單一 AI 代理不足以有效率或全面地完成複雜任務時，可以考慮使用多代理系統。多代理系統能提供更精煉或多角度的結果，例如透過協作或審查機制。

多代理系統的控制與可見性

多代理系統中存在控制對話流程和選擇代理的機制，例如：

Termination function（終止函數）：定義代理之間互動結束的條件，例如當特定代理批准了結果時。
Selection process（選擇過程）：定義對話如何進行，例如輪流發言或根據規則選擇發言者。

不同的多代理設計模式

Group Chat (群組聊天)
類似人類的群組聊天，每條訊息廣播給所有代理。通常由一個 group chat manager（通常是另一個 AI 代理）來選擇處理任務的代理。

應用範例： 航空客服應用，有專門處理訂位、客訴或航班狀態查詢的代理，將顧客訊息路由至正確代理。
"there is group chat where just like a group chat with your friends and colleagues every message in the chat is broadcasted to each agent and depending on the contents of that message a group chat manager typically another AI agent will select the appropriate AI agent to handle performing the tab"
Handoff Pattern (移交模式)
一個代理完成流程中的一個步驟後，將任務移交給下一個代理，適用於定義好的順序性工作流程。
"there may be scenarios where an AI agent needs information from another AI agent before completing its task and this is called a handoff pattern..."
Collaborative Filtering (協同過濾/協作分析)
每個代理專注於特定任務或領域，以自己獨特的方式回應並提供不同視角，特別適用於多角度分析需求的情況。
"...each agent acts as a specialist in some task or area and responds to that task in their own unique way..."

範例程式碼分析：審核者-建議者模式

來源展示了一個具體範例，包含兩個角色：

Front Desk Agent（前台代理 - 建議者）：回應使用者輸入並提供初步建議。
Concierge Agent（禮賓代理 - 審核者）：根據特定標準審核建議，並提供改進意見。

協作流程：

使用者輸入，例如「想去巴黎」。
前台代理回應第一個建議（如羅浮宮）。
禮賓代理審查並提出改進建議（如偏向當地的小型畫廊）。
前台代理根據建議給出新的建議（如橘園美術館）。
禮賓代理再次審核，如滿意則觸發終止條件，結束對話。

這展示了 reviewer-checker pattern（審核者檢查者模式） 的應用。

"you can see here now the kind of power between not just having one agent make suggestions and maybe having... but even using an agent to refine those results and giving back a better suggestion"

總結

多代理設計模式是一種強大的 AI 應用開發策略，允許將複雜任務分解並分配給多個 AI 代理協同完成。此設計模式提供了比單一代理更靈活、更精緻的解決方案。

來源介紹了三種常見模式：

群組聊天模式
移交模式
協同過濾模式

透過一個詳細的「審核者-建議者」實作範例，我們看到如何設定代理角色、對話機制與終止條件，來產出高品質的協作結果。

應用潛力

多代理系統特別適用於以下場景：

需要多個視角的分析任務
複雜流程的自動化協調
需要自動審查或改進機制的應用

[筆記] AI agents for beginners 第七課: What Is the AI Agent Planning Design Pattern 課後心得

2025-06-04T11:11:00.004+08:00

TL;DR

這堂課講解了讓 AI Agent 更聰明處理複雜任務的方法，叫做「規劃設計模式（Planning Design Pattern）」。

簡單來說，就是讓 AI 把一件大事（像是規劃整趟旅行）分解成很多小任務（訂機票、找住宿、排行程…），然後每一小段都可以自己處理，甚至交給不同的 Agent 幫忙。這樣不只更有邏輯，還能讓整體流程自動化又可控！

本章的要點如下：

✅ 讓 AI 學會「規劃」和「分工」，不再是一個指令只做一件事的單工思維
✅ 使用工具像 Pydantic 來結構化輸出，讓每個步驟都清楚可交棒
✅ 加入「驗證機制」，確保 AI 輸出的內容完整又符合格式
✅ 最酷的是，LLM 還可以理解「家庭友善」這種模糊條件，把人類的語意變成具體任務！

概要

本章說明了一種讓 AI Agent 有能力處理複雜任務的方式：規劃設計模式（Planning Design Pattern）。它的核心概念是把大型任務分解為更小、可管理的子任務，進而交由不同 Agent 或流程來執行，提升效率與可靠性。

核心概念與重點

規劃設計模式的定義與功能

讓 AI 能夠理解任務的整體結構，拆解為可執行的步驟
來源指出：「規劃設計模式使這一點更加清晰，透過讓 AI Agent 列出構成更複雜任務的子任務。」

複雜任務 → 子任務範例

例如：規劃 3 天的度假行程可拆分為：

預訂機票
訂飯店
安排交通
設計每日活動

多 Agent 協作

當系統中有多個 Agent，可以分頭處理子任務，效率更高。

來源說：「這真的有影響力的是與多個 Agents 協作... 子任務由不同 Agent 或流程完成。」

結構化輸出 + 驗證

輸出格式可以使用 JSON 或透過工具如 Pydantic 處理
這使資料可以交由下游的 Agent、流程、工具等繼續處理
結構化輸出 + 驗證機制 → 提高準確性與可持續運作

使用 `Pydantic` 進行結構定義

可定義：

任務清單
每個子任務所屬的 Agent
每項任務需要的欄位格式與驗證條件

LLM 的加值能力

不像傳統 API 調用，LLM 能理解人類語言細節：

如：家庭友善的旅館、符合特定偏好的餐廳等
這些模糊但人類常見的需求，可以透過語言模型更精確轉化成行動項目

規劃設計模式作為橋樑

結構化規劃的好處是可將結果傳遞給其他 Agent、API、工具，成為系統協作的「中樞神經」。

心得

規劃設計模式 是讓 AI Agent 擁有「多步驟任務規劃能力」的關鍵方法。它結合了：

任務拆解（task decomposition）
多 Agent 協作（multi-agent cooperation）
結構化輸出（structured output）
格式驗證與資料完整性檢查

這些機制讓 AI Agent 能夠更有系統地完成任務，並支援更大型、更複雜的應用場景。

[筆記] AI agents for beginners 第六課: How to build effective AI agents 課後心得

2025-06-02T13:18:00.004+08:00

TL;DR

建立有效 AI 代理的 3 大關鍵:

1. 系統訊息框架（System Message Framework）：
以清楚可擴展的方式定義 AI 代理的角色、語氣與行為，並透過 LLM 生成具體系統訊息，讓提示設計變得更可控、更易迭代。

2. 人機協作架構（Human-in-the-Loop）：
在 AI 執行關鍵任務前加入人類批准或介入機制，讓代理更可靠，尤其適合多代理協作的應用情境。

3. 安全與隱私考量：
開發 AI Agent 時需評估潛在安全風險與用戶資料保護，雖影片中僅略提，但書面章節中有更完整內容。

簡而言之，透過系統化設計提示、納入人類監督與關注資料安全，才能打造真正可信賴又有效的 AI Agent。

核心主題：

本課程探討了建立有效且值得信賴的 AI Agent的關鍵方法，特別著重於以下三個方面：

系統訊息框架 (System Message Framework)
人機協作架構 (Human in the Loop Architecture)
安全性與隱私

主要觀點和重要事實：

系統訊息的重要性：「系統訊息是我們作為 AI Agent 創建者在處理 LLM 時可以產生最大影響和控制的地方之一。」它對於設定清晰的指令至關重要，以確保 AI Agent 執行我們期望的操作。

系統訊息框架的工作原理：這個框架的核心是使用一個基本的系統訊息作為輸入，然後由一個經過特別設定的 LLM（擁有用於生成系統訊息的模板）來生成一個更詳細和具體的系統訊息。這個生成的系統訊息會涵蓋代理的「職責、語氣、風格、互動指令以及任何額外說明。」

迭代式提示設計：「在開發 Agent 時，尤其是在處理更複雜的場景時，很少能在第一次、第二次甚至第三次就獲得完美的提示。」提示設計是一個迭代的過程，系統訊息框架允許通過修改生成模板來更有效地進行迭代，從而提高所有代理的效能。

系統訊息框架的優勢：

可擴展性 (Scalable) 和可重複性 (Repeatable)：使生成提示的過程更有效率。
提高提示品質：生成的系統訊息更清晰、更具體。
簡化迭代過程：輕鬆調整模板，進而改進所有代理的提示。

人機協作的需求：「在處理任務的過程，您可能會建立需要人類批准或介入的 AI Agent。」「人機協作」通過在多代理協作中增加一個人類用戶來實現這一點。來源提到會在後續章節詳細介紹。

人機協作的觸發點：AI Agent可以被指示在接收到特定的用戶陳述（例如「批准」）時執行某些操作（例如終止代理運行時）。

範例程式碼分析：

影片中展示了一個程式碼範例，說明如何使用系統訊息框架。

首先定義了 Agent 的基本信息（角色、公司、職責），例如 role: travel agent, company: ktoso travel, responsibility: booking flights。
然後使用一個主要的系統訊息（例如 You're an expert at creating AI agent assistants）以及上述基本信息作為輸入，發送給 LLM 來生成一個更複雜的系統訊息。
生成的系統訊息包含更詳細的職責（例如：作為訂票助理、個性化和優化、機票可用性和價格、旅行要求和政策），甚至還有額外的注意事項（例如：專注於客戶滿意度、確保準確性以最大程度地減少預訂錯誤）。

這個範例展示了如何利用框架從一個簡單的定義生成一個詳細的代理系統提示，並且可以輕鬆修改和調整生成的內容。

安全性和隱私考量：

雖然影片沒有詳細展開，但來源強調開發 AI Agent 時需要考慮安全威脅和用戶隱私保護。更詳細的內容建議參考書面章節。

總結：

建立有效的 AI Agent 是一個複雜的過程，需要仔細設計其行為和互動方式。系統訊息框架提供了一種強大且靈活的方法來定義和迭代代理的指令，使其更具可控性和可靠性。同時，在許多應用場景中，納入人機協作架構是確保代理執行準確並符合預期行為的關鍵。安全性與隱私也是在整個開發過程中必須嚴肅對待的議題。

[筆記] AI agents for beginners 第五課: What Is agentic RAG 課後心得

2025-05-31T15:15:00.003+08:00

TL;DR

Agentic RAG 是 RAG（檢索增強生成）的進階版，它結合「代理人（Agent）」的規劃與判斷能力，能夠將使用者的複雜查詢拆解成多步驟任務，結合資料庫檢索與外部工具呼叫，並具備記憶與學習能力。簡單來說，它讓 LLM 不只會找資料，還會動腦解題、學習改進，能處理更複雜、更實用的問題。

第五堂課的主題是最近非常熱門的一個進階技術概念：「Agentic RAG」。這是我學習剛後整理出來的筆記跟心得，希望能幫助大家更好地理解它是什麼、跟基本 RAG 有什麼不同，以及它的實際應用潛力！

RAG 是什麼？

在介紹 Agentic RAG 之前，先簡單回顧一下 RAG 的基本概念：

RAG（Retrieval-Augmented Generation）是一種讓大型語言模型（LLM）從資料庫中檢索相關資訊，並加進模型的上下文來回答使用者問題的技術。
這樣的設計能讓 LLM 給出的答案不再只是來自訓練資料，而是結合了最新、最即時的資訊。

影片中提到：
「RAG 能夠讓 LLM 根據使用者查詢，從資料庫中檢索資訊，並加到 context 中以提供更相關的回應。」

那什麼是 Agentic RAG？

Agentic RAG 是在 RAG 基礎上的進化版！它結合了「代理人 (Agent) 的智慧」來強化整個資訊檢索與回應流程。

查詢分析與規劃：Agent 會先分析使用者的問題，並規劃成一連串的任務。
多步驟與多系統處理：能夠處理需要經過多個系統、多個步驟才能回答的複雜問題。
資訊驗證與迭代：如果第一次檢索結果不足，Agent 會重新發出工具呼叫直到找到答案。
長期記憶：Agent 能記住先前的嘗試，避免重複錯誤、越來越聰明！

影片還開玩笑說：「我其實更想叫它 Adaptive RAG！」

實作技巧：Prompt Augmentation

為了讓 Agent 運作更聰明，可以使用 Prompt Augmentation 技術來加強提示內容。

例如透過設計 PromptPlugin，在使用者提出查詢後，自動加入更多指示。
這能引導 Agent 先判斷 context 是否足夠，再決定是否呼叫工具函式。

Agentic RAG 的三個實際應用範例

RAG-only（僅使用檢索）：旅行保險範圍
當使用者問「我的旅行保險保什麼？」時，Agent 直接從 Azure Search 的文件中找答案。
Tool-only（僅使用工具）：馬爾地夫的平均溫度
如果資料庫裡沒有即時氣溫資料，Agent 就會呼叫像 WeatherInfoPlugin 這樣的外部函數來取得資訊。
結合 RAG 與工具：寒冷目的地 + 溫度
使用者查詢：「有沒有寒冷的目的地？它們的平均溫度是？」Agent 的處理步驟如下：

先用 RAG 檢索出目的地清單。
再逐一對可能的寒冷目的地呼叫外部函數查平均溫度。
綜合資料後，給出完整回答。

這樣的多步驟流程，就是 Agentic RAG 和傳統 RAG 最大的不同之處。

為什麼這麼重要？

Agentic RAG 的優勢總結如下：

結合分析 + 規劃 + 執行：讓 AI 不只是回話，而是真正執行任務。
能處理複雜、多層次問題：不再只適合單一查詢回應。
記憶與學習能力：下一次回答能夠避免犯一樣的錯誤。

結語

Agentic RAG 是一個進化，而不是替代。 它將 RAG 升級為真正具備「Agent 能力」的系統，能夠規劃、檢索、判斷與執行，處理比以往更複雜的問題。這個概念正改變我們打造 AI 應用程式的方式，也替未來更多創新開啟了想像空間。

希望這篇文章能幫助你理解什麼是 Agentic RAG，我們下回見！

[筆記] AI agents for beginners 第四課: What Is the Agent Tool Use Design Pattern 課後心得

2025-05-29T16:18:00.001+08:00

TL;DR

第四課主題開始探討 AI Agent 的「工具使用設計模式」（Tool Use Design Pattern）概念，個人覺得這對於理解 Agent 如何透過工具真的與所處的 context 進行互動，並觀察行動之後環境的變化，擬定下一個動作計劃直到完成目標 task 的模式很有幫助

為什麼需要工具？

我們都知道大型語言模型（LLM）很強大，可以直接生成文字內容來回覆我們的問題。但有些任務，光靠 LLM 自己是做不到的，例如：

查看即時的航班狀態
進行精確的數學計算
查詢最新的客戶資料

這時候，就像人類需要工具一樣，AI Agent 也需要「工具」來完成這些超出它們本身能力的任務。

什麼是工具使用設計模式？

簡單來說，「工具使用設計模式」就是一種方法，它讓大型語言模型 (LLM) 能夠與外部工具互動。這些工具可以是：

計算機（calculators）
API（例如查詢航班狀態的 API）
應用程式內部的特定功能（例如處理貨幣兌換的 function）

透過這個設計模式，AI Agent 就能夠藉助外部工具來執行或驗證資訊，而不僅僅是依賴它自己學到的訓練資料。

學會使用工具的好處（實際應用範例）

學會這個模式，我們的 AI Agent 能做的事情就更多了：

處理資料查詢：Agent 可以使用生成程式碼的工具來建立資料庫查詢，從客戶資料庫中取得即時資訊。
與現有系統整合：Agent 可以連接到像 CRM（客戶關係管理系統）這樣的系統，直接回答客戶訂位相關問題，減少人工介入。
自動化複雜工作流程：Agent 可以組合使用不同的工具來自動化流程，例如處理電子郵件並將資訊轉發，提高效率。

工具呼叫的小細節（以 Semantic Kernel 為例）

課程中提到了使用 Semantic Kernel 這個框架來實作工具呼叫。我們學到了一些設定方式：

自動（Auto）：讓 Agent 自行判斷是否需要呼叫工具函式。
必要（Required）：根據情境，強制要求 Agent 呼叫特定函式。

這些設定讓我們可以依需求更靈活地控制 Agent 的行為。

實際操作：一個旅遊 Agent 的例子

影片中展示了一個旅遊 Agent 的工具使用範例。它使用了一個包含兩個功能的 "destinations plugin"：

get destinations：取得所有可用的目的地列表。
get availability：查詢特定目的地的可用性。

使用者問「有哪些目的地可用？」時，Agent 呼叫了 get destinations 函式並顯示結果。

使用者問「巴塞隆納還有位置嗎？」時，Agent 呼叫了 get availability 函式並回報結果（不可用）。

LLM 的強大之處與工具的結合

這個例子精彩地展現了 LLM 與工具結合的力量。

當使用者問：「有沒有不在歐洲的目的地可用？」

開發者無需特別寫程式去判斷哪些城市在歐洲，因為 LLM 已擁有這些常識。Agent 會先理解問題意圖，再呼叫工具查詢東京與紐約的可用性，最後回答：紐約可用，東京不可用。

這體現了 LLM 的自然語言理解能力與工具調用能力的強大結合，讓 Agent 更聰明、更貼近使用者需求。

建立 Agent 時的其他考量

課程也簡要提到設計 Agent 時需注意的事項：

安全性：確保 Agent 僅擁有執行任務所需的最低權限。
錯誤處理：考慮服務中斷或工具呼叫失敗的應對方式。

這些屬於進階主題，後續課程會進一步介紹。

總結

「工具使用設計模式」讓 AI Agent 從單純的文字生成器，變成能夠與外部世界互動、執行實際任務的智能助手。

對剛入門的我們來說，理解並掌握這個概念，就像是拿到了一把開啟 AI Agent 潛力的鑰匙。

希望這篇心得對新手朋友有幫助！我們下個單元見！

[筆記] AI agents for beginners 第三課: How to design good AI agents 課後心得

2025-05-29T10:09:00.002+08:00

TL;DR

設計優良 AI Agent 的關鍵在於三個核心原則：空間（設計互動環境）、時間（考量長期互動關係）、核心（擁抱不確定性並提供透明控制）。透過明確說明 Agent 能力、提供使用者控制選項，以及運用具體範例（如旅遊助手），可以提升使用者信任與互動體驗。

第三章筆記：設計優良 AI Agent 的關鍵原則

三大設計原則

1. 空間（Space）

Agent 所運作的環境應該設計得能夠連接事件、人物與知識，並且能根據使用者需求靈活切換於前台與後台。

重要應用：在 UI/UX 設計中，清楚地向使用者說明 Agent 的用途與限制。

這是 Agent 工作所在的環境。在這個空間中，應該專注於連接事件、人物和知識。Agent 應該易於發現，同時能夠根據使用者需求在前台和後台之間切換。

2. 時間（Time）

設計良好的 Agent 應該能隨著時間持續學習與進步，累積與使用者互動的歷史，提供更一致且個人化的回應。

重要應用：結合過去互動紀錄、實作「反思設計模式」，讓使用者能看到自己的提示歷史。

這是 Agent 隨著時間與使用者互動的方式。這很重要，因為如果我們設計得足夠好，Agent 可以隨著時間改進。

3. 核心（Core）

核心原則在於擁抱不確定性，並透過透明設計與控制選項來建立使用者的信任。

重要應用：讓使用者像操作影片一樣，擁有開關、暫停、字幕等控制權限。

由於我們允許 LLMs 制定計畫並執行這些計畫，不確定性是 Agent 設計的關鍵部分，透過賦予人類使用者可見的控制和反饋工具來建立信任和透明度在這裡非常重要。

💡 實際應用範例：旅遊 Agent

課程中展示了一個旅遊規劃 Agent 的範例，使用 Semantic Kernel 與 GitHub models。這個範例體現了三大原則的應用：

開場白即自我介紹其功能：規劃度假、一日遊、隨機地點建議等
引導使用者提供進一步資訊（如是否指定地點）
明確聲明自身能力與限制，幫助建立信任

在這種情況下，我們要修改它…以應用我們剛剛談到的設計原則，我們要向使用者明確說明這個 Agent 的能力，並給予它一些建議，說明我們希望看到 Agent 完成哪些互動。

透明度與控制權

來源強調：「好的 Agent 設計就是要讓使用者一開始就知道這個 Agent 能做什麼、不能做什麼」，同時賦予使用者像操控影片一樣的控制權，提升信任與參與感。

就像使用者對這個影片有控制（播放、暫停、字幕和速度控制）一樣，使用者也應該對 Agent 擁有類似的多樣化控制權，例如開啟和關閉它。

結論

這一章為設計可信賴且實用的 AI Agent 提供了明確框架：空間、時間與核心的整合設計，加上透明度與控制權的實踐，是建立成功 AI Agent 的基石。透過程式碼範例與實際應用，這些原則得以具體落實。

心得感想

這一章對我來說像是 AI Agent 的設計指南。以前我設計對話時，只想著它怎麼「回應」，但這次我學到了更多關於「整體體驗」的設計思維，例如如何在介面中讓 Agent 更容易被發現（空間）、怎麼利用歷史互動讓它變得更聰明（時間），還有如何讓使用者有像遙控器一樣的控制權（核心）。

我覺得透明度這一點特別重要，畢竟現在很多人對 AI 的不信任來自於「它到底在做什麼我不知道」。如果我們能讓使用者一開始就知道 Agent 能力與限制，他們會更容易接受這個工具。

[筆記] AI agents for beginners 第二課: Which AI agent framework to use 課後心得

2025-05-28T17:43:00.001+08:00

TL;DR

代理框架是開發 AI 代理的工具集合，協助管理代理的行為、環境脈絡與協作。在這堂課提供了初學者三種微軟的解決方案，可從 Azure AI 代理服務 起步，它提供簡單的單代理整合環境；進階應用可考慮 Semantic Kernel（企業級、支援多語言與模型服務）或 Autogen（研究導向、易於實驗）。實際操作程式碼是理解這些框架最有效的方法。

第二章筆記：探索 Agent Frameworks

什麼是 Agent Frameworks ？

Agent Frameworks 是協助開發人員建構 AI Agent 的工具，讓他們能夠更有效地管理 Agent 的工作、理解環境脈絡、促進 Agent 之間的協作，以及觀察與評估 Agent 的效能。

我們為什麼需要使用 Agent Frameworks ？

Agent Frameworks 能幫助我們更好地控制 AI Agent，特別是在多代理協作完成任務的情境中。它們能管理上下文資訊、決定 Agent 分工、促進溝通與合作，並提供觀察與效能評估工具。

如何選擇合適的 Agent Frameworks ？

本課程關注的範疇都是微軟底下的解決方案，課程中提到了三種不同的 frameworks 以及其適合應用的情境

Azure AI Agent Service：適合初學者與單一代理應用，可與 Azure 生態整合。
Semantic Kernel：企業級框架，支援 C#、Java、Python 等語言，提供模型服務連接器。
Autogen：研究導向，適合實驗與測試最新代理技術。

建議從簡單的單代理工具（如 Azure）開始，根據需求再轉向支援多代理的進階框架（如 Semantic Kernel 或 Autogen）。

Azure AI Agent Service 的主要特點

目前設計以單一代理為主，透過程式碼或 UI 使用，且能與 Azure 現有服務無縫整合，適合初學者快速上手。

Semantic Kernel 框架重點

專為企業級應用設計，支援多種語言與模型整合，注重開發者體驗，適合生產環境部署。

Autogen 框架特色

由 Microsoft Research 開發，專注於實驗與測試最新代理研究成果，是探索創新概念的好選擇。

三者之間的關聯

Semantic Kernel 與 Autogen 均可與 Azure AI Agent Service 建構的代理整合，並可串接其他服務（如 GitHub models），彼此互補、提供靈活選擇。

如何更深入理解這些代理工具？

最好的方式就是親手操作。課程提供的程式碼範例讓你能實際運行、嘗試調整設定，從中加深對工具功能的理解。

心得感想

這一章讓我對 "Agent Frameworks" 的概念有了更清楚的認識。之前我只知道 AI Agent 是某種「會動的程式」，但從來沒想過它們背後需要這麼多管理工具來協調和規劃。尤其當任務越來越複雜，甚至涉及多個代理之間的協作時，有個好的框架就像有了司令官，幫忙分配誰該做什麼、如何溝通、怎麼評估結果。

我覺得 Azure AI 代理服務對我這樣的初學者非常友善，它幫我把很多複雜的設定簡化了，讓我能專注在代理的設計本身。而 Semantic Kernel 和 Autogen 雖然感覺比較高階，但也讓我對未來可能走向的發展有些想像。

總體來說，我學到的最大收穫是：要讓 AI 代理真的「好用」，不只要會寫 prompt、用模型，還要學會如何「管理」它們。而代理框架，正是實現這一點的關鍵工具。

[筆記] AI agents for beginners 第一課: What are AI Agents 課後心得

2025-05-28T16:39:00.000+08:00

這將會是 AI Agents for beginners 這一系列課程學習心得的第一篇文章，主要是記錄以學習 AI Agent 新手的角度所習得的內容以及心得收獲

TL;DR

AI Agents 是一種具備理解能力、記憶能力與使用工具能力的智慧系統，能根據使用者的自然語言指令，自動規劃與執行任務。其核心由 大型語言模型（LLM）、記憶（短期與長期）、以及可操作的外部工具組成。課程透過一個模擬旅行規劃助手的程式碼示例，展示了 Agent 如何回應使用者需求、學習偏好並調整建議。這是進入 AI 自主應用開發的重要起點。

筆記內容

這份文件是基於 "What are AI agents?" 課程第一課的內容，旨在介紹 AI Agent的基本概念、構成要素以及如何開始建構它們。本課程將帶領學習者從概念到程式碼，涵蓋建構 AI Agent 的基礎知識。

什麼是 AI Agent？

AI Agent是一種能夠識別使用者請求的任務、建立完成該任務的計畫並執行該計畫行動的系統。它們結合了多個關鍵組件，使其能夠進行推理、記憶和利用工具來達成目標。

AI Agent 的核心組成部分：

大型語言模型 (LLM): LLM 是 AI Agent 推理能力的核心。它負責解析使用者請求，理解任務，並制定執行計畫。課程中提到，LLM 的推理能力包括「識別使用者請求的任務，建立完成該任務的計畫並執行該計畫的行動」。
記憶 (Memory): 記憶讓 AI Agent 能夠儲存和利用資訊來改進其表現。記憶分為兩種：
- 短期記憶 (Short-term memory): 使用者與 Agent 之間的對話上下文，讓 Agent 能夠記住當前的互動狀況。
- 長期記憶 (Long-term memory): 資料的集合，讓 Agent 隨時間在完成任務方面有所改進，例如記住使用者偏好。
工具 (Tools): AI Agent 能夠存取和利用的外部資源或功能，以執行特定行動，例如：
- 透過 API 存取的服務
- 幫助確定採取何種行動的資料
- 用於向 Agent 傳送資訊的功能

AI Agent 如何運作？

Agent 利用 LLM 來識別使用者想要完成的任務，利用記憶來收集完成任務所需的資訊和資料，並確定完成任務所需的可用工具。

課程中以「刷牙」作比喻：需要計畫（何時何地刷）、工具（牙刷與牙膏）、短期記憶（目前是否刷了上排牙齒）、長期記憶（對牙膏的偏好）。

建構 AI Agent：實際範例與程式碼

課程展示了使用 Microsoft 的 Semantic Kernel 與 GitHub 上的 agentic framework 建構 AI Agent 的範例。採用了 GPT-4o mini 模型。

範例中建立了一個「目的地」外掛程式 (Destinations Plugin)，包含全球不同城市列表，並有一個功能能隨機回傳一個城市。

模擬互動範例如下：

使用者請求：「plan me a day trip」（為我規劃一個一日遊）。Agent 利用 LLM 解釋請求。
Agent 回應：發現沒有指定城市，呼叫隨機目的地功能，建議「Sydney」。
使用者不滿意，要求重規劃：「don’t really like this destination...」
Agent 再次使用記憶與工具：避免重複，改建議「Rio De Janeiro」。

這展示了 AI Agent 如何利用推理、記憶與工具來調整回應與行動。

展望未來

下一章節將探討不同的 agentic framework，包括它們的工作方式、差異和優點。

總結：AI Agent 透過整合大型語言模型、記憶與工具，能夠理解與執行使用者指令，並依據互動進行調整與學習，是建構智慧應用的基礎。

心得感想

作為一個 AI 初學者，這堂課給了我一個非常清楚且具體的切入點。過去我總覺得「AI Agent」是個抽象又高深的概念，但透過這次的學習，我第一次真正理解它的運作邏輯：原來只要把「理解（LLM）＋記憶＋工具」這三個概念串起來，就能構成一個有思考、有行動力的智能系統。

程式碼範例的旅行規劃案例非常貼近生活，讓我看到 AI Agent 其實不只是理論，而是可以應用在解決真實問題的工具。特別是看到 Agent 如何根據使用者的反應（「不喜歡這個目的地」）自動做出調整，真的讓我感受到它的靈活與潛力。

雖然一開始對於像 Semantic Kernel 或 agentic framework 這些名詞還有點陌生，但在跟著課程範例操作後，漸漸可以理解它們是如何協助我們更容易地建構出一個 AI Agent 。

總之，這次的學習讓我不再只是「使用 AI」，而開始理解如何打造一個可以落地解決現實問題的 AI Agent。也激發了我想進一步探索更多 AI Agent 應用場景的興趣與好奇心。

AI 寫程式的未來來了？AlphaEvolve 開啟自動演算法設計新時代

2025-05-28T13:28:00.002+08:00

AlphaEvolve 所面對的是極為廣闊的演算法搜尋空間。DeepMind 指出，現在的大型語言模型（LLM）已能解決複雜的數學與計算問題；AlphaEvolve 就是在這個空間中不斷嘗試、篩選，找出最優解。換句話說，AI 不再只是幫忙補寫簡單程式碼，而是已經進入能「跨領域探索並優化複雜演算法」的新時代。

什麼是 AlphaEvolve？

AlphaEvolve 可以想像成一位虛擬的「資深工程師」，專門用來產生、優化演算法。它是由 DeepMind 所開發，核心技術來自 Gemini 系列的大型語言模型，搭配自動化測試與評估流程，採用類似「自然演化」的概念來改善程式碼品質。

與早期只能幫忙寫簡單函式的 AI 不同，AlphaEvolve 能主動探索並優化整段程式碼，甚至開發全新的演算法架構。它同時運用多個模型，包括 Gemini Flash 負責快速產生各種可能的解法，而更強大的 Gemini Pro 則提供深入見解與分析建議，兩者協同運作，就像創意團隊一樣。

AlphaEvolve 是怎麼運作的？

AlphaEvolve 的工作流程大致可以分為以下幾個步驟：

先輸入原始程式碼（可以是空白模板或部分初始版本）與評估標準（用來判斷解法好壞的測試機制）。
由 Gemini 模型產生多個程式碼變體，類似一次生出很多「候選解」。
每個版本都會送進自動評估系統執行測試，根據正確性、效能等指標評分。
表現最好的版本會被留下，成為下一輪「繁衍」的基礎，繼續讓模型加以優化。

整個過程可以類比成「人工演化」：就像農夫選育植物或動物，每一代都挑選最優秀的個體。AlphaEvolve 透過「產生 → 測試 → 篩選 → 再產生」的循環，逐步找出最理想的演算法。

未來對軟體開發的影響

大幅提升效能：AlphaEvolve 曾為 Google 資料中心的排程系統設計新演算法，使全球運算資源使用率提升約 0.7%；也優化了 Gemini 訓練所用的矩陣運算程式碼，提升 23% 執行速度。
開發者角色升級：AlphaEvolve 產出的程式碼具備可讀性，讓開發者可以像閱讀同事的程式一樣理解與修改它，AI 不再是黑盒，而是合作的夥伴。
激發前所未有的創新：AI 曾打破矩陣乘法長達 56 年的世界紀錄，或在多維球體堆積問題中找到新的理論上限。這些例子顯示 AI 可以與人類並肩探索未知。
應用領域持續擴大：只要問題可以用程式定義並自動驗證，AlphaEvolve 就能嘗試優化，例如材料設計、藥物研發、永續能源等領域都極具潛力。

延伸閱讀推薦

結語

總的來說，AlphaEvolve 讓「AI 寫程式」不再只是輔助，而是升級為能夠主動創造、優化演算法的幫手。你可以想像它是一位具備強大實驗能力的 AI 助手，不斷試錯、演化、優化，協助人類在不同領域找出最有效率的解法。

這樣的技術未來將更深入開發流程，提升效率、降低人力成本，同時也可能啟發全新的技術突破。對台灣的開發社群來說，掌握這股趨勢，有望在 AI 驅動的軟體新時代中搶佔先機，拓展更廣闊的應用想像。

[新手向] React 常見的 Conditional Rendering 錯誤

2025-05-28T10:51:00.006+08:00

在 React 中，條件渲染（Conditional Rendering）是根據狀態或條件來決定是否顯示某些 UI 元素的核心技術。對於新手而言，這個概念看似簡單，但實作時常會遇到一些陷阱。本文將介紹常見的錯誤類型，並提供最佳實踐建議，幫助你寫出更穩定、可讀性更高的程式碼。

常見錯誤一：錯誤地比較字串與布林值

問題描述

當從 sessionStorage 或 localStorage 中取得布林值時，這些值實際上是字串類型（例如 'true' 或 'false'）。若直接將其與布林值比較，會導致條件判斷錯誤。

錯誤範例

即使回傳的是 'false'，Boolean('false') 還是會是 true，因為非空字串在 JavaScript 中是 truthy。

正確寫法

常見錯誤二：在自訂元件中提前評估 children

問題描述

React 會在渲染父元件時先評估 children，這會導致即使條件為 false，仍有程式碼被執行，造成錯誤。

錯誤範例

正確寫法

常見錯誤三：條件渲染語法錯誤

錯誤範例

正確寫法

常見錯誤四：錯誤地使用數字當作布林值渲染

問題描述

React JSX 中 0 不會被當成布林值忽略，而是會直接渲染成字元 0。

錯誤範例

正確寫法

最佳實踐建議

守衛條件（Guard Clause）：避免巢狀邏輯

將條件放在 map 外層：

多重條件使用 switch：

總結

條件渲染是 React 開發中不可或缺的一部分，掌握正確的使用方式能避免許多常見錯誤。以下是本文的重點整理：

✅ 明確比較值的類型：避免將字串與布林值直接比較。
✅ 避免提前評估 children：使用 Render Props 控制渲染時機。
✅ 遵守 JSX 語法規則：條件渲染的表達式要包在合法結構中。
✅ 數字不是布林值：0 在 JSX 中會被渲染出來，要特別處理。
✅ 使用守衛條件與清晰結構：讓程式碼更穩定、可維護。

希望這篇文章能幫助你在 React 的條件渲染上更加得心應手 🎯

[新手向] 在 React JSX 中撰寫迴圈的三種方式

2025-05-27T17:22:00.002+08:00

在 React 的 JSX 中直接使用傳統的 for 迴圈會導致語法錯誤，因為 JSX 本質上是將標記轉換成函式呼叫。以下列出一般常用的三種方式：先在渲染前組裝陣列、使用陣列的 map()、以及利用 ES6 陣列工具（如 Array.from、展開運算符等）產生陣列後再 map()。這些方式都能生成多個元件，適合不同的使用情境。

方法一：使用 `for` 迴圈

說明與使用情境：

可以先在 render 函式或組件外部使用傳統 for 迴圈建立一個元件陣列，然後將該陣列插入到 JSX 中。這種方式彈性高，適合根據計數或條件逐一產生元件的情境。請注意，每個元素都要設置唯一的 key 屬性以符合 React 列表的需求。

範例（TypeScript）：

優點：

清楚簡單，使用熟悉的 for 迴圈邏輯，直觀易懂。
允許在每次迴圈中使用複雜邏輯或條件，適合需要逐一累加元素的情況。

缺點：

程式碼較冗長，缺乏宣告式 (declarative) 的美感。
對於有資料陣列的情況較不直觀，需手動管理元素索引。

方法二：使用陣列的 `map()`

說明與使用情境：

如果已有一個包含資料的陣列，可以直接在 JSX 中對該陣列使用 map() 方法，將每個資料項目映射成一個元件。這是最常見做法，偏 functional programming 風格，程式碼簡潔。一般用於從伺服器或 state/props 傳來的資料陣列渲染列表時，非常方便。

範例（TypeScript）：

優點：

簡潔明瞭，一行 map() 就可處理整個陣列，程式更具宣告式。
避免手動建立額外陣列，直接回傳新陣列。

缺點：

對初學者來說，箭頭函式或回呼函式語法可能稍微陌生。
如果資料原本不是陣列 (例如只有數字 N)，就必須先生成一個陣列才能使用此法。

方法三：使用 `from`、spread operator 或 `fill` + `map()`

說明與使用情境：

當你只知道要重複產生元件的次數，但沒有現成資料陣列時，可以先用 ES6 的陣列工具來生成一個指定長度的暫時陣列，再用 map() 建立元件。常見做法包括：Array.from({ length: count })、ES6 展開運算符 ...[Array(count)]、或先用 Array(count).fill(...)。這些方式都能產生一個長度為 count 的陣列供 map() 使用，適合需要重複渲染固定數量元件時。

範例（TypeScript）：

另一種寫法（spread operator）：

優點：

透過一行程式碼即可產生指定次數的元素，程式碼簡短。
不需要額外變數，直接在 JSX 中完成。
適用於只需重複多個空元素或占位元件的情況。

缺點：

語法較為「黑魔法」，對初學者不直覺，需要了解 ES6 陣列技巧。
某些方法 (如展開運算符) 需要瀏覽器或 Babel 支援；使用 Array.from 或 fill 可能需要 polyfill。

總而言之，一般常見的做法是：若有明確的資料陣列，就使用 map()；若需重複固定次數，則可先生成一個長度陣列再用 map()；若需要更細緻的流程控制，則使用傳統的 for 迴圈 先累加元素陣列，再回傳 JSX。

【海外婚紗】道具行李篇

2017-05-04T17:51:00.005+08:00

出發前一直在煩惱到底行李要買多重，
上網找了老半天發現沒什麼人分享海外婚紗的行李重量跟攜帶情形，

所以分享完海外婚紗的攝影跟造型後，決定來分享一下這趟的道具跟行囊。

這次因為要在京都租和服，雖然和服店也有出租紙傘的服務，但聽說很貴，
我記得租一把要幾千日圓，而且如果下雨就不得租借，
所以索性上淘寶買，發現和服店的紙傘款式都跟淘寶一樣XD

不過帶紙傘有個缺點，收到後我才知道傘柄居然這麼長😣
塞行李塞的有點困難，需要用30吋行李箱，然後呈現對角的方式斜擺才塞的下，
所以建議如果跟淘寶買可以請賣家把傘柄鋸短一點。

果然和服就是要配紙傘阿～超搭！

再來大推的是這款厚底鞋，本來很擔心淘寶的品質，怕第一天就穿壞，
所以還一次買兩雙都帶去，結果果然是我多慮，這超級好穿的！穿上立馬增高12cm
對於我們這種矮子新娘，裙底下一定要必備一雙！
兩天幾乎都穿著這個拍照跟走跳，
健步如飛到連造型師很疑惑的一直問說腳真的都不會痠嗎？
真的很厲害，很耐穿~根本買一雙就夠了，多買的那雙只好到批踢踢推文區去賣了XD

蕾絲傘因為看到兩把都很美，就忍不住全敗然後還全帶去，
雖然拍照也只用到了一把QQ
不過質感真的很好，所以也很猶豫到底要不要轉賣掉，不過朋友都說我留著這個幹嘛？
當然是留念囉🙉

這個淘寶的燈泡因為拍攝時間不夠，沒派上用場QQ

不過下面這條紅布是我回嘉義的布店剪的，一條才100多左右，
主要是想要墊在和服下面，跪著拍照，
一開始大家都很傻眼我拿出這條紅布要跪在上面拍，
沒想到拍出來效果真的很好啊～好險我沒有因為丟臉而放棄XD

這條黑頭紗是淘寶看到便宜就買的，想說可以搭配我那件黑紗，
結果攝影師說不用，只好再帶回來，給我家小公主戴過過乾癮了😭

因為之前去日本自由行都有製作旅遊書的習慣，所以這次就把這些書都帶來，
然後用繩子跟夾子，製作出拍立得照片的效果，
不過書實在太重，後面要黏滿膠帶才不會掉下來

我掏出這個說要拍攝時，攝影師好像也是傻眼了一下XD

而且書一直快掉快掉的，其實拍的很緊張

淘寶的捧花居然也比想像中的有質感，陷入選擇障礙的我決定三束都帶去，
結果只用到一束Q_Q
只好拍攝完來個出清大拍賣了..

這也是胡亂瞎買的道具，我知道其實很多國內婚紗店跟工作室都有提供，
但畢竟我們是海外婚紗，攝影師的器材就很重了，所以當然沒有這些東西，
就在淘寶上一次買齊了

再來就是分享如何裝箱，本來以為婚紗會很難塞，
沒想到三件婚紗可以剛好塞進一個30吋行李箱，而且還包含蓬裙唷💪

接著另一廂就塞男生的兩套西裝＋我亂瞎買的道具跟高跟鞋、皮鞋

也是剛好塞滿一箱

兩箱共重32公斤，倒是比我預料中的輕XD

所以如果海外婚紗拍完有想要逛街買戰利品的，建議再多帶第三個箱子～

不過如果沒像我帶一堆有的沒的道具，倒是可以準備兩箱就夠了😋

【海外婚紗】造型篇-我的超人新祕Sunny-Yang

2017-05-04T16:38:00.001+08:00

這次海外婚紗造型師是EASTERN WEDDING團隊搭配的造型師Sunny，
每套造型我都好喜歡！決定另發一篇文分享😁

出發前最擔心的就是自己的妝容，因為以前當過兩次伴娘，
當時被化出來的妝感都有點恐怖..

因為我黑眼圈很嚴重、眼窩也凹，所以只要稍微上一點眼妝就會過濃過艷，
而且出發前一個月因為焦慮沒睡好，膚況很不穩定一直過敏😫

所以Sunny為了先幫我做好基礎保養，要我凌晨三點整就抵達他們住宿的地方

她先幫我濕敷，之後上妝果然就很服貼，我的臉本身很容易過敏跟發癢，
化妝也容易太乾浮粉，不過厲害的是，Sunny用的產品完全不會不舒服😳
每樣都很好用，當下都趕緊用手機拍下來，回台灣立馬一一敗入XD

她最厲害的是貼睫毛，我的眼睛很敏感，
以前曾經接過睫毛，還敏感到因為不舒服自己全拔掉，
以往的經驗，只要貼了睫毛，即使之前的造型師幫我分段貼，還是會不舒服一整天，
但Sunny貼的睫毛，不只自然，可以說是完全感覺不到它的存在！
晚上回到飯店卸妝時才會想到有貼睫毛😏

髮型更是一絕呀～她的巧手咻咻咻，三兩下就弄出很美的造型～

男友也對自己的髮型讚不絕口，一直說為何她隨便抓一抓頭髮就變這麼有型，
回台灣後試著要自己抓都抓不出那種FU

首先是第一組搭配和服的造型，髮飾是Sunny準備的，很搭很有質感！
這是我最愛的一組造型^^

而且挑振袖其實要選的東西很多，
除了和服本身、上面的綁帶、內襯、繩子、包包、鞋子都要挑選，
好險Sunny眼光很好，當下都立馬給我專業的意見，搭配出來的效果果然很棒，
完全拯救了很有選擇障礙的我，不然我從和服店出來可能都中午了😥

s
Sunny非常貼心，隨時都在幫我補妝

而且還不斷幫我側拍，她最認真的是，側拍了很多照片後，
在車上會一直看剛剛的側拍照，
並且把照片滑大很認真研究我的妝容有沒有需要修正的地方，
然後會馬上作調整，
就是有她這麼用心的態度，我才能每張照片都妝感美美:)

和服換下來後，回飯店換第二組造型，因為是要穿白紗去拍櫻花，
事前溝通她知道我很喜歡花圈，因此第二套就用了浪漫花圈造型，
男友很喜歡這套，一直在旁邊讚嘆這造型很美很夢幻，
不過這個景點風很大，所以拍攝過程Sunny不斷地來調整劉海，非常細心

接下來要前往神社拍照，感覺比較神聖一點，
第三組造型Sunny就在路邊階梯幫我把頭髮盤起來，變成氣質感包頭

在神社這邊拍到天黑，接著就是去超商借廁所換黑紗，
為了搭配黑紗，感覺比較有高貴氣息，
所以Sunny就幫我把花圈換成了銀色皇冠，整個跟黑紗好搭阿！
可惜晚上側拍效果時候不好，只跟Omer先要了幾張毛片來分享一下，
再次覺得Omer的毛片就好厲害😻

附上這天回到飯店的妝容，真的維持的很好！根本沒掉妝阿！
而且卸妝後皮膚也沒有過敏跟不適，整個很安心第二天可以繼續奮戰XD

第一天拍完都晚上9點多了，隔天為了先做保養，
第二天Sunny仍然凌晨3點就開始幫我保養跟造型…

第二天都是很遠程的景點，幾乎都在坐車，因此挑了較輕便的內魚尾白紗，
這件是浪漫中帶點魚尾的性感，我有跟Sunny說我很喜歡韓式馬尾，
她也是用了很快的速度就變出這麼美的髮型！
我的白紗上有一些蝴蝶造型，所以她也幫我搭配了很有質感的蝴蝶髮飾，
聽說這些髮飾要價5000呀！戴的好有壓力XDD

男友在旁邊看了仍然不斷讚嘆Sunny的巧手怎麼這麼強大

在海邊的時候Sunny超忙，除了因為風大要一直調整頭髮，
因為天氣很冷（別被太陽騙了，這時溫度大約5.6度而已），
只要一有空檔她就會幫我披上外套，手上拿著我的外套，還要幫忙拉飛紗，
有時候還要幫忙打燈、扛燈具，
她根本十項全能造型師，是個女超人來著的吧💪💪💪

除了忙這些，她事前還要幫我準備了美美的乾燥花，還很貼心的幫我提來日本💗

國內先準備好乾燥花就算了，到了美山，
她還就地取材，撿起地上的稻草，立馬紮出一把適合美山的乾燥花，
是不是很強！

拍起來效果超好的阿！！！

而且Sunny連側拍功力都很強，以下皆為手機側拍照唷！
每張都可以入本了其實XD

Sunny還捕捉到我男友滑稽的側拍動作XD

附上第二天收工後的妝容

真的很感謝我全能的造型師Sunny，讓我可以留下這些美美的照片，
好像做夢一樣當了兩天的公主🙈
過程中也一直努力幫我們側拍、隨時注意我的妝髮、關心我冷不冷。

她跟兩位攝影師非常有默契，一個眼神就知道要拿燈具、甩飛紗、整理髮型，
我們在車上不斷的被他們歡樂的互動過程逗得笑呵呵，兩天下來的相處真的很愉快，
連我那非常慢熟、悶騷、害羞的男友，
都被他們引導的放很開、跟著瞎胡鬧～激發了無限潛能XD

拍攝完男友後還一直主動跟我回味這些有趣的拍攝過程，
本來出發前對於拍婚紗完全無感的他（他都只會說婚紗重點是指新娘，
新郎什麼都不用準備，非常興趣缺缺，一副被我逼去海外拍照一樣），
這趟拍攝過程居然比我還開心跟滿足😒

雖然兩天下來睡沒幾小時、穿著憋得要死的婚紗到處奔波、忍受寒風，
真的很累，但只要想到這些過程、看到這些成品，滿足的做夢都會笑，😊
叫我再拍個十次我都願意XDDD

再次大推EASTERN WEDDING！

附上Sunny愛用的app拍出來的收工影片

【海外婚紗】婚攝篇-我的神燈精靈Omer&艾文

2017-05-04T13:33:00.001+08:00

拍完婚紗耍廢了一個月，終於有點動力來分享心得了

先說我是個頗龜毛跟囉嗦的新人😋

從前年就已經決定好今年結婚的日期，今年底的婚期在去年初就訂到傳聞中的NINIKO，就可以知道我有多花心思在這上面XD

訂完新祕後停擺了一陣子，才開始研究婚紗拍攝，
由於一直很想拍海外婚紗，就決定今年利用連假去日本拍櫻花

上網研究了好久，先是看到了也是批踢踢很火紅的東法，被他的作品深深吸引，
連絡之後他說他櫻花季沒有海外拍攝，
所以推薦了他創立的EASTERN WEDDING團隊的攝影師Omer，
看了作品發現跟東法的風格很像，就趕緊下定了。

接下來拍攝前一個月就是超級忙碌的籌備期，試婚紗、買道具…

整個月都很焦慮！很擔心平常拍照只會比ya的我們，
到時候拍攝會不會整個僵掉
也很擔心不適合化眼妝的我，到時候化完會不會很可怕
(因為我之前當伴娘有過幾次讓新祕化妝化完都很可怕的經驗＠＠)，
每天都很擔心拍攝失敗，這些婚紗費用會不會都付諸流水…等等，
焦慮到晚上都睡不著😑

結果拍攝完才發現這些都白擔心的！

我的雙攝影師+造型師根本是什麼願望都能達成的神燈阿！

(造型部分會在下一篇介紹)

出發前花了很多時間跟攝影師討論京都的拍攝地點

因為要拍攝兩天，除了基本的京都市區以外，我還提了一些自己想拍攝的景，
例如竹林、美山、瀑布之類的，一開始Omer聽到瀑布的時候還很傻眼😅

想說京都是要去哪拍瀑布，但他還是做了非常多功課，

上網搜尋、提前出發開車到處場勘，還真的讓他找到了一個有如仙境的瀑布！
看到我都想跪了XD

更誇張的是，我看到他們場勘瀑布的照片後，
在網路上查到有人在美山附近拍過龍貓，
就私訊他那幾天開車的過程中有沒有看到龍貓，
他回說他隔天會繼續場勘，再順便幫我找找，
然後隔天就真的傳了龍貓照給我…............
這根本使命必達、有求必應的神燈精靈嘛😍

看到了那些場勘照，充滿期待地出發前往日本準備跟他們會合啦～

凌晨3點抵達他們住宿地點開始化妝，接著去租和服，
就一路開拍到晚上9點多才收工，
第二天也是3點化妝，6點開拍…

真的很佩服他們的體力，除了花這麼長的時間拍攝以外，
空檔還會修幾張圖先讓我們搶先看，

然後兩位攝影師每天都要開超過200km的車，載新人到處跑點😱
拍攝前幾天也要先自行去場勘，確保景點是否合適

尤其因為今年氣候異常，櫻花晚開，
拍攝那兩天，全京都都是迷你未開的花苞…😢
但他們還是努力開車找遍全京都市，找到了兩棵唯一滿開的櫻花樹，
達成我的心願～～～
看到他們如此敬業的態度，對於這次的作品完全放一百個心👍

兩位攝影師也很會帶動作，我們僵硬的肢體都能被他們引導到像麻豆😆
最讓我讚嘆的是，拍完隔天，Omer先給了我幾張未修圖的毛片，
效果根本是直接可以入本的阿～～～光線色調也太強！

先附上一張手機拍的現場光線，當下雖然天氣很好，但這是小巷弄，
所以其實光線都被牆壁擋住

接下來這張則是Omer在同一個地點拍攝的毛片

果然攝影師的技巧＋專業的燈具，才能讓照片發揮最大效果阿！
而且他們善用角度跟光線來把我這個厚片新娘拍成偽瘦子，整個大感謝~~

目前還沒拿到全部毛片，所以先分享一些側拍以及攝影師修過的幾張搶先看。

每到一個景點，兩位攝影師就會很貼心的先等造型師幫我整理妝髮，
然後他們就會開始尋找拍攝角度以及調整相機

這也是他們找到的一個很美的小漁村，離京都市區要開兩三小時的車才到的了，
真佩服他們拍攝前還特別來回開了一次場勘，
這邊風很大，超適合拍飛紗的，
不過也因為風太大，攝影師跟造型師都調飛紗調的很辛苦XD

運氣很好，這兩天太陽都很大，很適合拍我想要的逆光效果XD

其中一位攝影師拍攝時，另一位攝影師就會負責拿燈具，
有時連造型師也一起幫忙抬燈具，他們真的很辛苦！也很有默契～

有時候為了一些角度艾文還得躺在地上拍XDDD

因為出發前的溝通，我有整理一些我喜歡的照片給Omer，希望能拍出類似風格
沒想到他居然都記得，很多動作連我自己都忘了，他反而還都記得cue我們做XD
（手機側拍）

拍到一半我還亂入，要求了lalaland的動作，他也盡力幫我達成這無理的要求🙈

(不過因為穿振袖，手實在舉不太起來)

PS.這張是毛片

最後一個龍貓景點的時候，艾文指導了一個姿勢我很喜歡^^
趕緊叫造型師也幫我用手機側拍一張😁

講了這麼多廢話，總算要來分享Omer跟艾文修給我的幾張成品啦～

婚攝Omer：

這條路唯一滿開的一棵櫻花樹，被我們霸佔了一小時XD

這兩天花況超差的京都，居然能拍出這種效果我此生無憾了😌

我最喜歡的一張！很喜歡Omer善用光線跟陰影，讓色澤像油畫一般！

我特別要求的瀑布（因為很喜歡Omer拍攝的水波紋路），這裡真的好美阿～

攝影師行前一直建議我放棄嵐山，改去他們發現的小漁村，
好險有聽他們的建議，拍這個真是比大家都有的嵐山還來的值得😆
而且這邊很偏遠，一個台灣觀光客都沒有，
看來我們應該是台灣第一組踏入小漁村拍婚紗的新人XD

我指定的美山，因為覺得這裡很像合掌村，一直很想來看看
我朋友說這張很像一幅可以掛在牆上的油畫

婚攝艾文：

這跟剛剛是同一棵櫻花樹唷，艾文找的角度又是另一種風情，
根本像全京都櫻花都滿開一樣XDDD

我們這兩天的櫻花花況實際上是長這樣，右上角可以看到全都是未開的花苞

（這張是我男友幫我用手機拍的側拍，突然發現他也很強，居然拍出光圈XD）

艾文知道我很愛龍貓，隔天他還有其他新人的拍攝，
幫下一對新人拍攝了一整天，回飯店還是熬夜幫我修圖讓我搶先看，真的很感動😭

瀑布的另一個角度，青苔長得很美～很有魔法公主的FU

落落長的分享文到此～因為目前也只有先收到這幾張成品，
收到這幾張的感想就是：完蛋了，才這幾張就這麼厲害，
到時候挑毛片要陷入超嚴重的選擇障礙了啦….會不會三天三夜也選不完Q_Q

攝影團隊的人都很好相處，第二天跟他們在龍貓這邊玩的超開心，
兩天下來真的很歡樂，
還體驗到了兩位攝影師超強的開車技術，根本都秋名山車神等級XD

附上開心的收工照，真的很謝謝EASTERN WEDDING團隊，
很謝謝東法推薦了這麼棒的攝影師給我:)

(造型部分下一篇分享)

[JavaScript] 前端跨網域存取問題 (xhr cross-domain request is not allowed)

2013-09-08T15:03:00.000+08:00

XMLHttpRequest cannot load ... Origin ... is not allowed by Access-Control-Allow-Origin

這個問題常發生在前端程式嘗試以 AJAX (XMLHttpRequest) 方式存取跨網域資源時，因為 Security 的考量，造成 request 發送失敗的情況。

Same Origin Policy

Same Origin Policy 是現代瀏覽器在安全性上的一個重要設計，主要是確保 script 只能在與其載入來源相同的頁面執行，達到不同 origin 網站彼此無法互相干擾。(註: 這裡指的相同 origin 是指 domain name, protocol, port 皆相同)。

對於 XMLHttpRequest 也有類似規範，當 client 端的 JS 對遠端主機發送 XMLHttpRequest 時，因為會挾帶瀏覽器所 maintain 的 cookie 資訊，因此只能對相同 origin 的 resource 進行存取(也就是 AJAX 呼叫的 url 必須與目前所在頁面相同)，此限制確保了其存取的安全性。

為什麼需要 Cross-domain 存取?

因為前端技術的快速發展成熟，使得前端與後端之間的分野愈來愈鮮明，前端負責頁面呈現與動態互動，後端負責演算與 API 服務介接，因此在開發這類型網站時，常會整合第三方的服務( e.g. flickr api 取得照片)或重覆利用自己先前開發的後端 API，但這就違反了 Browser 的 Same Origin Policy，因為不論是第三方或先前所開發的服務，通常都與網站位址不相同，所以處理跨網域資源存取的問題是必備的技能。

解決方案

1. AJAX Proxy

屬於 Server 端的解決方案，簡單來說就是將 web server 當成前端瀏覽器與其它第三方伺服器之間溝通的中介，browser 發送 AJAX request 給 server 端 proxy，proxy 再將 request 轉送給第三方服務並取得內容回傳給前端。通常有下列兩種實作策略：

(1) 前端完全不需知道使用什麼第三方服務，只需要存取後端 proxy 提供的方法，ajax proxy 會負責轉送 request 至第三方服務，取得結果並回傳給前端，讓前端有此服務就是後端 server 提供的感覺。

(2) 前端必須知道第三方服務的 url，並在發送 request 時以參數的方式傳遞到後端，後端僅提供一個介面將指定的 url 轉送並負責將結果回傳，這種方法讓開發者有瀏覽器沒有 policy 限制的感覺。

2. JSONP

JSONP = JSON with padding or prefix，第一次聽到 JSONP 時，可能會對它產生誤解，以為是另一種資料格式，但其實 JSONP 是一種避開 Same Origin Policy 發送 cross-domain request 的技巧。

其運作原理是利用 script tag 的 open policy，意思就是 browser 對於載入任何網域的 js native code 沒有限制，藉由這個特性將所需的 json data 以 function call 包起來，而這個 function 是被 execution context 所定義好的，當 js code 被以 script element 的方式 inject 到 html 時，就可以順利將後端資料帶入處理函式，達到跨網域請求資料的目的。

例如:

假如現在 mydomain 需要跟 api.mydomain 取得資料 (jsonp.php)，那 jsonp 的實作方式如下

HTML
JS
PHP
透過上述例子可以很簡單的了解 jsonp 的原理，HTML 以 script injection 方式呼叫跨域 API 並帶入參數跟 callback 名稱，後端接到參數後，取出 json 格式的資料，並以 callback 包裝起來回傳給前端，前端因為在 script block 已經定義了該 callback 函式，所以當 native js code 被載入時，會很神奇的把資料塞給處理函式，完成了跨域呼叫。

幸虧了 jQuery ，使用 jsonp 將不再這麼麻煩，要發送跨域請求時只需要在 $.ajax() 代入參數 dataType="jsonp" ，並在 url 加入參數 callback=xxxx 即可，當然後端也必須作相對應的配合 (將資料以傳入的 callback 參數以 function call 型式包裝起來)，回傳後 jQuery 會自動將 response data 傳給 success callback，省去自定義 callback 步驟，如下所示:

JS

PHP

3. CORS

CORS (Cross-Origin Resource Sharing) 是 W3C 針對不同源的 Browser 跟 Server 之間進行構通所制訂的 protocol，其實作原理就是透過兩個 Custom http header (Origin and Access-Control-Allow-Origin) 來確認雙方是否可以成功發送 Request 並回傳，client 端在發送 request 時 (僅限支援 CORS 的 Browser)，如果發現請求目標非同一 domain，會自動加入 custom header: Origin 並傳入自己的 domain，而當 Server 接收請求並回傳時，必須加上 "Access-Control-Allow-Origin: http://domain/allowed" 這個 header，帶入的值就是允許跨域請求的白名單，如果是星號 (*) 代表允許全部，如果有安全性考量要避免使用。

上述解法僅限 Simple Request，何謂 Simple request 在 W3C 官網有明確的規範，只要 Client 發送的請求符合下列條件都算是簡單的請求：

HTTP method:

Head
Get
Post

HTTP headers:

Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type: application/x-www-form-urlencode
Content-Type: multipart/form-data
Content-Type: text/plain

如果請求的內容有超出上述範圍(例如: PUT method, Content-Type: application/json) 就必須用另外的處理方法，但礙於篇幅，有機會再獨立寫一篇文章介紹。最後再以一個簡單的例子示範 CORS 用法：

JS (只需要簡單發送一個跨域的 AJAX 請求)
PHP (回傳允許跨域存取的HEADER)
總結

上述三種方法都可以用來解決 xhr cross domain access 的問題，但不同解法有不同限制，像是 jsonp 與 cors 需要 response 端的配合，如果是第三方服務且沒有支援這兩種方法的情況可能使用 proxy 才可能解決問題，或是考慮服務所支援的瀏覽器是否皆有實作 cors…等等，都是採用哪種方法所要考量的。

[JavaScript] 忍之道解謎(四) - Constructor Invocation

2013-05-22T00:25:00.001+08:00

Q. 呼叫 a.bar 的結果是?

這題同樣是考 "Constructor Invocation" 的概念 (詳細可參照此文章)，當 function object 與 new 聯用時，會建立一個此 function type 的物件並與其 prototype 產生連結，所以當 a 物件被產生出來時其 this 指向一個新建立出來的物件並非 window，所以當存取 this.foo 時，因為 a 這個 bar type 物件並沒有該屬性，因此答案是 undefined。

[JavaScript] JSDC 2013 白板題 - this

2013-05-19T19:53:00.001+08:00

今年 JSDC 比去年相較之下與會的人變多了，各種前端技術的社群( Node, Angular, Front-end Developer) 不斷冒出來，反映有愈來愈多人想投入這領域，真心希望前端設計師在台灣可以愈來愈受重視!前端魂阿~

以上都是題外話，今日午茶時間，在攤位附近的白板上有出了幾個 JS 的題目，旁邊寫了"可以跟 David Shariff 討論"，所以我想應該是 David 出的吧? 因為解的人實在太多了，所以只有看到最前面那一題，題目是：

這題如果沒有理解錯的話，是問如果呼叫了 boo 這個 method 時 x 等於多少？這題考的是 this 的觀念，對於熟悉 OO 的人來說 this 並不陌生，但有別於 classical 程式語言，JavaScript 的 this 是根據 invocation pattern 來決定的，因為 foo 是一個 object，因此呼叫其 boo 函式時，屬於 method invocation - this 會跟呼叫該 method 的物件綁定，因此回傳 this.x 值就是 foo 的 x 屬性 20。

[JavaScript] 忍之道解謎(三) - Constructor Invocation Pattern

2013-05-15T12:24:00.000+08:00

Q. typeof b = ?

JavaScript 是種 prototypal inheritance的語言，有別於目前主流的 classical 語言，它的繼承是以 prototype 的概念來實現。new Constructor(args...){ .... } 這個敘述對於物件導向語言並不陌生，它代表建立一個類別物件的實體，JS 雖然沒有類別的概念，但它仍然有 new 這個陳述式：

new Constructor([arguments]) - 用來建立一個自定義物件的實體或是一個有定義 Constructor 的內建物件，Constructor 為 function object ，代表產生出來的物件類型。

Constructor 定義的是該類型物件的名字與所擁有的屬性、方法，其實就很像 Class 宣告，不同的地方在於物件可以很輕鬆的透過 Function.prototype 動態的加入屬性、方法 ( JS 的物件在乎的是擁有什麼行為而不是它的身世)，所以該類型物件在執行期間馬上就擁有這些新的行為，不需要重新建立實體。

執行 new Constructor([arguments]) 即會建立一個該類型物件實體，該物件會繼承 Function.prototype 的屬性成員並將 this 指向新建立的物件。

下面將以一個例子說明 constructor invocation 如何建立 Duck 類型物件的實體並動態加入quack 行為：

duck物件的 Constructor 在呼叫時會帶入一個參數作為其 name 屬性的值，並且在 duck1, duck2 兩個實體建立後，再加動態為其加入 quack 的行為。

這題在一開始定義了 a 類型物件的 constructor，裡面未定義任何成員屬性，之後再透過 new 建立了一個 a 物件實體並把 b 指向它，所以答案 b 是一個 Object。

[JavaScript] 忍之道解謎(二) - Array addition

2013-05-14T16:16:00.001+08:00

Q. 相加結果為?

這個題目屬於典型的 JS quirk，因為JavaScript 是弱型別(weak type)的語言，所以JavaScript 在進行運算時，只會處理 Number, String 的運算，其它類型的資料會被自動轉換為上述兩種型態之一再進行運算，如果無法處理即會丟出 Type Error。

JavaScript 型態自動轉換的方法 ( ToPrimitive() )

JavaScript 會依下列步驟轉換其數值型態 ( Date 物件 2、3 步驟對調)：

(1) 如果運算元是 primitive 即回傳，否則則下一步。

(2) 呼叫該 Object 的 valueOf 方法，如果回傳值是 primitive 即回傳，如果不是則下一步。

(3) 呼叫該 Object 的 toString 方法，如果回傳值是 primitive 即回傳，如果不是丟出Type Error。

以這個題目為例，兩個空陣列相加時，會先經過上述的轉換，[].valueOf() 將會回傳 [] ，其型態為 Object ，不是 primitive 所以再呼叫其 toString() ，回傳的是空字串 "" ，兩個空字串相加還是空字串，因此這題的答案為 ""。

[JavaScript] 忍之道解謎(一) - function Scope

2013-05-14T01:46:00.000+08:00

Q: 請問alert訊息是?

題目中的foo, boo function為兩個global function，site 則是一個global variable 預設值為"jsdc"，當程式依序呼叫foo, boo兩個函式後，alert出來的site變數值為多少?

JavaScript 的 function scope

Scope 是程式語言用來管理變數的生命週期與可視範圍(Visibility)，有了這項機制可以避免命名的衝突以及記憶體自動管理。JS 提供了function scope 機制，這意昧著function 裡面所宣告的變數僅限函式內使用，超出此範圍即失去其效用，function執行階段在取用這些變數成員時，是透過Scope chain 去搜尋並取用。

當函式被呼叫執行時，會依下列步驟產生 Scope chain:

(1) 建立 Execution context

(2) 初始化 scope chain 物件集合

(3) 將 Global object 加入 scope chain：
將外部所宣告的 Global variables 與 document, window and navigator 等變數加入global object，再將scope chain 第一個位置變數指向它。

(4) 建立 Activation object：
Activation 裡面將包含了所有在函式所宣告的 Local variables, parameters 等，當然別忘了還有 this, arguments。

(5) 將 Activation object 移到物件集合的第一筆位置：
當function 執行期間碰到要取用變數時，會從第一筆開始尋找目標，直到找到對應的變數(或找不到)，這也是為什麼濫用Global variable會造成JS速度低落的原因，因為Global object 總是scope chain 的最後一個物件

了解 JS 的 function scope 原理後 (如上所示)，應該就很清楚 alert 訊息是什麼了，當 foo 被執行時，site 這個global variable 被加入了 foo 的 scope chain 並且在 function body 更新其值，當 boo 建立 scope chain 時，其 Activation object 所reference 的 site 變數其值已經被 foo 更新為 " IThome " 了，所以答案是「IThome」。

[JavaScript] JavaScript Number物件的合法型態

2013-05-02T02:21:00.001+08:00

有別於一些Strong typing的語言(Java)，JavaScript的數值物件(在JS數值型別視為物件)屬於loose typing，這個特性在The Good Parts書中被視為JS的優良部份。number是JavaScript裡唯一的數值型別，合法的數值包含整數、浮點數、指數、特殊值(NaN, Infinity)：

整數：

包含正負整數，面試時還被考過16進位(hex)的數值是否合法，答案是可以的

浮點數：

JS的世界1===1.0

指數：

e可以是大寫或小寫

NaN (not a number)：

當數字運算無法產生正常結果時，在字串轉數字時最常出現，例：parseInt('google')+12。沒有任何值等於NaN，這表示別用NaN===NaN去檢查運算錯誤，要用isNaN

Infinity：

超過數值可顯示最大值(1.79769313486231570e+308)即會以Infinity表示，不過一般情況下沒有什麼機會超出

上述這些數值只要透過typeof檢查都會回傳number

[JavaScript] JSDC - 忍之道解謎系列

2013-04-27T14:27:00.000+08:00

JS界年度盛事 - JSDC 2013於最近正如火如荼的展開，在conference 開始之前官方舉辦了很多活動，像是：專家分享經驗、出題徵文…等，其中個人最感興趣的就屬「忍之道百謎決戰」，會稱作忍之道是因為 JS Ninja 指的是JS開發者中的佼佼者，要成為Ninja先解開這些謎題吧，裡面許多題目不分難易都有學習JS的重要觀念與新知，個人也是在邊玩邊查的情況下完成解謎，這過程中間獲得相當多，之後會慢慢以「忍之道解謎系列」文章分享謎題裡面的知識。

[Android] 使用GOOGLE MAP-發生 Couldn't get connection factory client 錯誤

2012-03-12T21:00:00.001+08:00

ERROR/MapActivity(258): Couldn't get connection factory client

這個問題會發生在使用Google所提供的MapView，問題發生的原因很簡單，就是此Application所使用的Map API Key無法辨別，因此發生這樣的問題時，可以依照下面的順序來檢查是否有哪個環節出錯了：

(1)如果是在AVD或Device上開發&測試程式，請透過Keytool產生Debug private key的MD5指紋辨識碼(key的路徑請到Eclipse→Window→Preferences→Androi下的Build，會有個名稱為"Default debug keystore的欄位)，將MD5丟到GOOGLE產生MAP API KEY的網頁，確保目前所用來簽署的key與API的一致性。

(2)如果是Release版的App發生問題，確認API Key是由簽署Release App的key所產生的。

(3)如果上述都確認無誤，請確認AndroidManifest.xml裡是否有宣告use-permission android:name="android.permission.INTERNET"，如果少了這個宣告可能導致App無法透過網路來進行Map API Key的驗證。

Chickenrice's Workshop

設定 MCP Server 發生 spawn npx ENOENT spawn npx ENOENT 的解決方法

🔍 問題根本原因（Root Cause）

✅ 可行解決方案

方案一：不用 npx，直接指定完整路徑

方案二：讓 Node 被系統找到

📝 小結

[筆記] AI agents for beginners 第九課: Metacognition Design Pattern 課後心得

Metacognition Design Pattern：AI 自我反思的力量

TL;DR

摘要

後設認知的定義與應用

後設認知對 AI Agent 的優勢

✈️ 實例：預訂機票的後設認知應用

程式碼範例：追蹤客戶偏好

上下文與記憶的整合應用

結論

科普一下: 後設認知 (Metacognition)

[筆記] AI agents for beginners 第八課: How to use a multi-AI agent system 課後心得

TL;DR

核心主題

主要概念與事實

多代理設計模式的定義

使用多代理的時機

多代理系統的控制與可見性

不同的多代理設計模式

範例程式碼分析：審核者-建議者模式

協作流程：

總結

應用潛力

[筆記] AI agents for beginners 第七課: What Is the AI Agent Planning Design Pattern 課後心得

TL;DR

概要

核心概念與重點

規劃設計模式的定義與功能

複雜任務 → 子任務範例

多 Agent 協作

結構化輸出 + 驗證

使用 Pydantic 進行結構定義

LLM 的加值能力

規劃設計模式作為橋樑

心得

[筆記] AI agents for beginners 第六課: How to build effective AI agents 課後心得

TL;DR

核心主題：

主要觀點和重要事實：

範例程式碼分析：

安全性和隱私考量：

總結：

[筆記] AI agents for beginners 第五課: What Is agentic RAG 課後心得

RAG 是什麼？

那什麼是 Agentic RAG？

實作技巧：Prompt Augmentation

Agentic RAG 的三個實際應用範例

為什麼這麼重要？

結語

[筆記] AI agents for beginners 第四課: What Is the Agent Tool Use Design Pattern 課後心得

TL;DR

為什麼需要工具？

什麼是工具使用設計模式？

學會使用工具的好處（實際應用範例）

工具呼叫的小細節（以 Semantic Kernel 為例）

實際操作：一個旅遊 Agent 的例子

LLM 的強大之處與工具的結合

建立 Agent 時的其他考量

總結

[筆記] AI agents for beginners 第三課: How to design good AI agents 課後心得

TL;DR

第三章筆記：設計優良 AI Agent 的關鍵原則

三大設計原則

1. 空間（Space）

2. 時間（Time）

3. 核心（Core）

💡 實際應用範例：旅遊 Agent

透明度與控制權

結論

心得感想

[筆記] AI agents for beginners 第二課: Which AI agent framework to use 課後心得

TL;DR

第二章筆記：探索 Agent Frameworks

使用 `Pydantic` 進行結構定義

方法一：使用 `for` 迴圈

方法二：使用陣列的 `map()`

方法三：使用 `from`、spread operator 或 `fill` + `map()`