I Gave My Own .NET App an MCP - Now My AI Runs It 🤯
三句話摘要
MCP（Model Context Protocol）讓 AI 從被動解釋轉變為主動操作工具的標準協議。 未來不是會說你工具的 AI，而是在你掌控下實際使用工具的 AI。 MCP 的本質：就像 USB 之於裝置，MCP 是 AI 與工具間的通用連接標準，讓 AI 能讀取、寫入並在工具中執行動作，而非僅通過文字描述。
重點整理
重點- 1
MCP 的本質：就像 USB 之於裝置，MCP 是 AI 與工具間的通用連接標準，讓 AI 能讀取、寫入並在工具中執行動作，而非僅通過文字描述。
- 2
使用方式轉變：傳統需開啟應用手動輸入資訊，現在只需用自然語言敘述目標（「建立 dev ticket 關於上傳影片」），AI 透過 MCP 自動完成，跨越了應用切換與複製貼上的繁瑣工作。
- 3
應用範例與侷限：在 Stackbody 中，AI 可建立工單、排程新文章；但因 Substack 無公開 API，仍需透過 Chrome 擴充才能推送，說明 MCP 仍受工具本身支援程度限制。
- 4
風險與責任：AI 能快速精確執行，但也能快速犯錯，使用者必須保持警覺驗證結果，使用者才是真正的操縱者，AI 僅是執行層工具。
實用技巧與重點
乾貨- 工具/平台：Stackbody（bug tracker）、Substack、Chrome 擴充、Claude Code
- 具體操作：
- 建立 dev ticket：無需開啟應用，直接透過 MCP 建立工單（票號 16，標題「支援上傳影片到節點」，狀態開啟，優先級正常）
- 排程內容：AI 自動將新節點排入下一個開放時段，並依使用者原有風格生成內容
- 檢查重複：建立前自動檢查現有工單避免重複
- Token 成本：36K tokens（建立工單）、41K tokens（排程內容）
- 內容風格特性：短句、無標題、無粗體、無 emoji、無破折號
- 限制：Substack 無公開 API，需透過 Chrome 擴充推送
結論
結論“未來不是會說你工具的 AI，而是在你掌控下實際使用工具的 AI。”
完整解析
詳細Patrick 是擁有近 30 年編程經驗的開發者，過去以應用介面作為工具的唯一入口。這次他透過 MCP（Model Context Protocol）演示了 AI 如何跳過應用介面，直接在後端系統執行真實動作。
MCP 的核心概念就像 USB 標準化了裝置連接——它提供統一協議讓任何 AI 都能操作任何支援的工具。傳統 AI 只能回答「怎麼做」，MCP 讓它能實際「去做」。這個轉變的關鍵在於工具必須透過 MCP 向外公開其能力。
在 Stackbody 示例中，Patrick 在終端機簡單敘述「建立 dev ticket 關於上傳影片到節點」，無需開啟應用介面。AI 自動載入工單建立工具，檢查現有工單避免重複，隨後建立票號 16，包含完整標題、描述、優先級。整個過程消耗 36K tokens，用戶可在狀態列看到實時成本。重新載入 Stackbody 時，新工單已出現在系統中。
進一步演示中，Patrick 要求 AI 排程一篇關於 MCP 價值的新文章。AI 自動判斷時間、撰寫內容，並根據 Stackbody 已學習的使用者聲音風格（短句、無標題、無裝飾符號）生成文本。新節點被排入下一開放時段，總共使用 41K tokens。這展示了 MCP 不僅服務開發者，也能增強一般使用者的生產力。
然而，Patrick 強調一個關鍵點：AI 能快速精確執行，也能快速大規模犯錯。使用者的責任不在於巧妙的提示詞設計，而在於驗證 AI 執行結果的正確性。他將自己定位為真正的操縱者，AI 則是忠實執行指令的副駕駛。基於這個理念，他在 Blazor AI Accelerator 課程中教授如何在可理解的基礎上為自有應用構建 MCP，讓開發者能安心賦能 AI。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
