https://yennj12.js.org/yennj12_blog_V4/tags/claude/Recent content in Claude on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/Thu, 30 Apr 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/情境設定 公司背景： PixelFlow Agency，台灣台中，8 人數位行銷公司 主要服務： 社群媒體管理、廣告投放（Meta / Google Ads）、SEO、內容行銷 服務客戶數： 同時服務 15-20 個品牌 核心痛點： 每個客戶每月需要 30-50 篇社群貼文，文案師產能跟不上 廣告成效報告每月要花 2 天手動彙整，格式各異 新客戶的「內容策略規劃」每次都要從頭寫，耗時 3-5 天 客戶問「我們這個月的廣告怎麼樣」時，帳號管理師要翻資料才能回答 目標： AI Agent 承擔 60% 的文案產出、100% 的報告彙整、80% 的策略草稿。 整體架構設計 定期觸發（每日/每週/每月）+ 客戶即時請求 ↓ ① Brand Agent（品牌守門員） → 載入品牌 DNA，確保所有輸出符合品牌調性 ↓ ┌────────────────────────────────┐ │ 並行執行（Parallel Execution） │ ├──────────────┬─────────────────┤ ② Content Agent ③ Ad Copy Agent （內容策略師） （廣告文案師） └──────────────┴─────────────────┘ ↓ ④ Analyst Agent（數據分析師） → 讀取廣告成效數據，產出洞察 ↓ ⑤ Report Agent（報告撰寫師） → 整合所有產出，製作月報/週報 ↓ ⑥ Presenter Agent（簡報師） → 把報告轉成客戶易讀的簡報格式 技術選型： 本案例使用 LangGraph + Claude API（路線 C）https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part3-example-zh/Sat, 04 Jul 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part3-example-zh/講概念很容易流於空泛,所以這篇只做一件事:挑一個 Agent,走一次真實流程。 GL Reconciler 是 fund-admin 這條線裡最具代表性的 Agent——輸入是總帳(GL)和對帳來源, 輸出是「哪裡斷了、為什麼斷、該找誰簽核」,而不是一個自動幫你改帳的黑盒子。 一、核心問題:對帳為什麼還需要人做 GL 對帳的痛點不是「不會算」,是斷點的根因五花八門——可能是時間差(trade date vs settlement date)、可能是手續費分類錯誤、也可能真的是資料輸入錯誤。傳統做法是資淺 Analyst 一筆一筆比對兩份表,慢且容易漏看模式。 傳統對帳流程 ───────────────────────────── GL 匯出 ──┐ ├─ 人工逐筆比對 ──▶ 找到斷點 ──▶ 憑經驗猜根因 ──▶ 簽核 對帳來源 ──┘ │ 耗時、容易漏看跨期模式 GL Reconciler 要解決的,不是取代這個判斷,而是把「找斷點」和「聚類根因」這兩步自動化,把人力集中在真正需要判斷力的「這筆該怎麼調整」上。 二、三個演進階段 Phase 1(POC / 單一基金,< 10K 筆交易月對帳量) ┌─────────────────────────────────────┐ │ Claude Code + gl-reconciler plugin │ │ 手動貼上 GL 匯出 + 對帳來源 CSV │ └──────────────┬────────────────────────┘ ▼ Claude 讀兩份表,找斷點,輸出 markdown 報告 新增元件:僅 financial-analysis 核心 + gl-reconciler plugin,無連接器 成本/複雜度:幾乎零,一個 Analyst 手動貼資料跑 解決的問題:比人工逐筆比對快,能聚類出「同一根因造成的一批斷點」 未解決的問題:資料要手動匯出貼進去,無法排程,無歷史對照 Phase 2(MVP / 多基金,10K–200K 筆/月) ┌───────────────┐ ┌───────────────┐ │ Fund Admin │────▶│ Egnyte/Box │ │ 系統匯出 │ │ (GP 報告來源) │ └───────────────┘ └───────┬────────┘ ▼ ┌─────────────────────┐ │ gl-reconciler Agent │ │ (Cowork,人在迴圈) │ └───────┬─────────────┘ ▼ 斷點清單 + 根因分類 + 待簽核佇列 新增元件:接上 Egnyte/Box 連接器自動抓 GP 報告,Cowork dispatch 讓多個基金的對帳可以並行跑 成本/複雜度:需要文件儲存連接器的訂閱/權限設定,人力成本從「逐筆比對」降到「審核聚類結果」 解決的問題:多基金並行處理,斷點根因有分類而非逐筆羅列 未解決的問題:仍然是互動觸發,沒有排程,月底集中跑時人力仍是瓶頸 Phase 3(Scale / 機構級,200K–1M+ 筆/月,多基金多幣別) ┌──────────────┐ │ 排程觸發 │ (每日/每週跑增量對帳,而非月底一次性) └──────┬────────┘ ▼ ┌─────────────────────────────┐ ┌──────────────────┐ │ Managed Agent │─────▶│ callable_agents │ │ (agent.https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part2-concepts-zh/Sat, 04 Jul 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part2-concepts-zh/大部分「AI Agent 框架」的第一個問題是:互動模式(chat)和自動化模式(headless)得寫兩套邏輯。 financial-services 的做法是:同一份 system prompt、同一組 skill,兩邊共用,只是包裝層不同。 這篇講清楚它是怎麼切出 Agent / Skill / Command / Connector 四層,讓這件事成立的。 一、核心問題:一份系統提示,兩種跑法 Claude Cowork 是互動式的,人全程在迴圈裡,隨時可以插話。Claude Managed Agents API 是 headless 的,接到你自己的批次工作流引擎裡跑,沒有人盯著。 如果這兩種模式各寫一套 prompt 和邏輯,維護成本會隨 Agent 數量線性爆炸——改一個 skill,要同步改兩個地方,遲早會漂移。 錯誤做法(兩套維護) ───────────────────────────── Cowork prompt.md ──╮ ├─ 各自維護,容易漂移 Managed prompt.md ──╯ financial-services 做法(一份來源) ───────────────────────────── agents/<slug>.md + skills/ │ ├──▶ Cowork 直接讀這個目錄 └──▶ managed-agent-cookbooks/<slug>/ 引用同一份檔案 scripts/sync-agent-skills.py 和 scripts/check.py 的存在就是為了守住這個「單一事實來源」——後者會在 CI 檢查任何 Agent 綁定的 skill 有沒有跟 vertical 裡的原始版本「漂移」。 二、五層架構總覽 ┌───────────────────────────────────────────────────────────┐ │ Agents(命名的端到端工作流,如 Pitch Agent、GL Reconciler)│ │ plugins/agent-plugins/<slug>/ │ │ ── 自包含:把它用到的 skill 都打包進來 │ └───────────────────┬───────────────────────────────────────┘ │ 綁定/呼叫 ▼ ┌───────────────────────────────────────────────────────────┐ │ Skills(領域知識與步驟方法,Claude 自動判斷何時使用) │ │ plugins/vertical-plugins/<vertical>/skills/ ← 原始來源 │ │ plugins/agent-plugins/<slug>/skills/ ← 同步副本 │ └───────────────────┬───────────────────────────────────────┘ │ 部分 skill 對應 ▼ ┌───────────────────────────────────────────────────────────┐ │ Commands(手動觸發的 slash action,如 /comps、/dcf) │ │ plugins/vertical-plugins/<vertical>/commands/ │ └───────────────────┬───────────────────────────────────────┘ │ 讀寫外部資料 ▼ ┌───────────────────────────────────────────────────────────┐ │ Connectors(MCP Server,接資料商:FactSet、Moody's.https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part1-usage-zh/Sat, 04 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part1-usage-zh/大部分團隊想用 LLM 做財務分析,第一步是自己從零寫 prompt、兜資料源、堆流程。 正確的起手式是:先看有沒有人已經把這套流程做成可重複使用的 Agent。 anthropics/financial-services 就是 Anthropic 官方把「投銀、研究、私募、財管」最常見工作流程包好的參考實作。 裝上去、調參數,比從空白 prompt 開始快得多。 一、這個套件解決什麼問題 金融業的分析工作有一個共通結構:輸入一堆非結構化資料(財報、CIM、GP 報告、KYC 文件),經過固定的分析步驟,產出一份要給人審核的工作成果(模型、備忘錄、對帳表)。 典型金融分析工作流程 ───────────────────────────────────────── 財報 / 文件 / 資料源 │ ▼ 固定分析步驟(comps、DCF、對帳、KYC 規則) │ ▼ 工作成果草稿(memo / model / deck) │ ▼ 人工審核與簽核 ← 必要,不可跳過 這個流程本身重複性很高,但每個環節都需要領域知識(怎麼抓可比公司、怎麼算 WACC、怎麼追帳目斷點)。financial-services 這個 repo 就是把這些領域知識寫成 Claude 的 Skill 和 Slash Command,再包成 Agent。 [!IMPORTANT] 這些 Agent 產出的是分析師工作草稿——模型、備忘錄、對帳結果——供合格專業人員審核。它們不做投資建議、不執行交易、不核准開戶,每一份輸出都停在「待人工簽核」這一步。 二、兩種部署方式,同一套系統 這是這個 repo 最重要的設計決定:同一份 system prompt、同一組 skill,可以用兩種方式跑。 ┌─────────────────────────┐ ┌─────────────────────────┐ │ Claude Cowork │ │ Claude Managed Agents │ │ (互動式,人在迴圈中) │ │ API(headless,接你自己 │ │ │ │ 的工作流引擎) │ └────────────┬─────────────┘ └────────────┬─────────────┘ │ │ └──────────────┬───────────────────────┘ ▼ plugins/agent-plugins/<slug>/ 同一份 agents/<slug>.https://yennj12.js.org/yennj12_blog_V4/posts/finance-data-ai-pipeline-how-it-works-zh/Tue, 30 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/finance-data-ai-pipeline-how-it-works-zh/多數人做股票分析:打開券商 App,看 K 線、查財報、Google 新聞,然後自己下判斷。 finance_data 的做法:讓 42 個機器人每天定時自己抓數據、自己讀財報、自己寫成繁中研究報告、自己發佈上線——全程沒有人手介入。 這篇就拆解這條「零人工」pipeline 的每一個齒輪是怎麼咬合的。 一、它到底是什麼 finance_data 是一個全自動的 AI 投資研究平台。它覆蓋 30+ 家公司(AAPL、MSFT、NVDA、TSLA、PLTR、台股 0050、2330.tw……),每天自動產生: 個股基本面分析(fundamental analysis) 個股技術面分析(technical analysis) 每日市場新聞摘要(market news) 配合 SEC 申報文件(10-K / 10-Q / 13-F / 6-K)、investor day 簡報、研究 notebook 關鍵字是「全自動」:從定時觸發、抓數據、餵 LLM、生成報告、到建置部署上線,整條鏈沒有任何一步需要人手操作。 整體 pipeline 長這樣: ┌──────────────┐ 每天定時觸發 │ GitHub Actions│ ◀────── cron schedule │ Cron │ └──────┬───────┘ │ 1. 排程把「某支股票 + 某種分析」丟給腳本 ▼ ┌──────────────────────┐ │ 資料蒐集層 │ yfinance + Finviz + StockAnalysis + Roic.https://yennj12.js.org/yennj12_blog_V4/posts/spotifymcp2-claude-spotify-mcp-server/Tue, 24 Feb 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/spotifymcp2-claude-spotify-mcp-server/SpotifyMCP2 is a TypeScript MCP server that gives Claude direct control over Spotify — search tracks, manage playback, browse playlists, and queue songs through natural language. Built with full OAuth2, automatic token refresh, and 95%+ test coverage.https://yennj12.js.org/yennj12_blog_V4/posts/llm-fine-tuning-aws-bedrock-complete-guide/Sun, 21 Dec 2025 11:00:00 +0000https://yennj12.js.org/yennj12_blog_V4/posts/llm-fine-tuning-aws-bedrock-complete-guide/Comprehensive guide to fine-tuning and customizing Large Language Models (LLMs) with AWS Bedrock - covering supervised fine-tuning, continued pre-training, and reinforcement fine-tuning with practical examples and AWS CDK infrastructure setup.