<h1>AI 個人教科書生成器：從原始資料打造專屬學習路徑</h1>
<p>在資訊爆炸的時代，瓶頸不再是尋找資訊，而是如何將其<strong>篩選並整合</strong>成能被大腦吸收的形式。標準教科書是為「平均」學生設計的，通常會包含你已經知道的主題，或者缺少你工作中需要的特定情境。</p>
<p>想像一下，把你凌亂的研究筆記、PDF 收藏和 20 篇網頁文章，瞬間變成一本結構嚴謹、格式專業，且完全符合你學習程度的教科書。</p>
<p>在本指南中，我們將使用 Claude Code、Pandoc 和一點 RAG（檢索增強生成）邏輯，構建一個 <strong>AI 個人化教科書生成器</strong>工作流。</p>
<h2>TL;DR</h2>
<ul>
<li><strong>問題</strong>：通用的教科書對於自主學習者來說效率低下。</li>
<li><strong>解決方案</strong>：利用 AI 將原始資料建構成邏輯完整的課程大綱，生成教育內容，並使用 Pandoc/Calibre 匯出為 EPUB/MOBI。</li>
<li><strong>效益</strong>：在電子閱讀器（Kindle/Kobo）上進行優化的離線閱讀，內容與你的目標完全相關。</li>
</ul>
<hr>
<h2>系統架構：從原始資料到電子閱讀器</h2>
<p>一個強大的教科書生成器遵循四個階段的流程：</p>
<ol>
<li><strong>攝入與萃取</strong>：收集原始資料（PDF、URL、Markdown），並使用 <a href="https://notebooklm.google/">NotebookLM</a> 或 RAG 系統尋找相關連結。</li>
<li><strong>大綱架構</strong>：根據「用戶畫像」（例如：正在學習量子物理的軟體工程師），利用 LLM 設計邏輯嚴密的目錄（H1, H2, H3）。</li>
<li><strong>內容擴展</strong>：生成章節、摘要和測驗。</li>
<li><strong>格式轉換</strong>：將 Markdown 轉換為 EPUB 和 MOBI。</li>
</ol>
<h2>第一步：架構課程大綱</h2>
<p>不要只是要求 AI 「寫一本書」。首先要定義結構。透過定義 <strong>Syllabus Template（課程大綱模板）</strong>，你可以確保 AI 不會偏離主題。</p>
<p><strong>Claude Code 提示詞範例：</strong></p>
<blockquote>
<p>「我是一位預計移居東京擔任產品經理職務的人。我想學習針對『科技會議與社交網路』設計的『商用日語』。請建立一個包含 10 個章節的教科書大綱。每個章節必須包含：1. 核心詞彙、2. 真實情境對話、3. 針對商務敬語 (Keigo) 的語法解釋、4. 自我評量測驗。」</p>
</blockquote>
<ul>
<li><strong>小技巧</strong>：要求 AI 在每個章節末尾生成「自我評量測驗」。這能將被動的閱讀體驗轉化為主動的學習過程。</li>
</ul>
<h2>2026 工具焦點：專用平台</h2>
<p>如果使用 Pandoc 的 DIY 方法對你來說太過技術化，2026 年也出現了幾個「AI 優先」的平台來簡化這個過程：</p>
<ul>
<li><strong>Inkfluence AI</strong>：一個專為電子書打造的平台，處理從想法到格式化 EPUB 匯出的完整工作流。</li>
<li><strong>Youbooks</strong>：非常適合連貫的長篇內容，並具備即時網路搜尋功能。</li>
<li><strong>Skywork AI</strong>：具備「畫布模式 (Canvas Mode)」，可在寫作前視覺化複雜的書籍情節與結構。</li>
</ul>
<h2>案例研究：個人化日語教材 (<a href="https://github.com/chiweitw/nihongo-claude">nihongo-claude</a>)</h2>
<p>這個工作流的一個真實應用案例是 <strong><a href="https://github.com/chiweitw/nihongo-claude">nihongo-claude</a></strong> 專案。作者利用 Claude Code 從零開始構建了一套專屬的日語 N3 課程。</p>
<h3>核心亮點：</h3>
<ul>
<li><strong>專案結構</strong>：劃分為 4 個階段共 30 堂課，每堂課都以結構化的 Markdown 檔案生成。</li>
<li><strong>雙語情境</strong>：每堂課都包含日語詞彙、真實對話，以及針對學習者背景度身訂造的中文字幕與解釋。</li>
<li><strong>自動化轉換流水線</strong>：
<ul>
<li><strong>Markdown 轉 EPUB</strong>：使用 Python 腳本 (<code>convert_to_epub.py</code>) 並結合 <code>ebooklib</code> 與 <code>markdown2</code>。</li>
<li><strong>Kindle 優化</strong>：整合 Calibre 的 <code>ebook-convert</code> 以確保裝置相容性。</li>
<li><strong>PDF 匯出</strong>：使用 <code>weasyprint</code> 生成高品質的列印版本。</li>
</ul>
</li>
<li><strong>高易用性</strong>：透過 <code>quick-convert.sh</code> 腳本提供互動式選單，讓使用者只需一個指令就能生成所需的各種格式。</li>
</ul>
<p>這個專案證明了只要有正確的自動化流水線，你的 AI 助手就不僅僅是個作家，它還可以是你的<strong>專屬教科書出版社</strong>。</p>
<h2>第三步：技術橋樑（Markdown 轉 EPUB）</h2>
<p>電子書格式化的秘密武器是 <a href="https://pandoc.org/">Pandoc</a>。它能處理將結構化文本轉換為 EPUB 格式所需的複雜 XML/CSS 組合。</p>
<h3>轉換指令</h3>
<p>如果你已經將教科書儲存在 <code>textbook.md</code> 檔案中，請透過終端機運行以下指令：</p>
<pre><code class="language-bash"># 將 Markdown 轉換為包含目錄的 EPUB
pandoc textbook.md -o textbook.epub --toc --metadata title="我的 ZK 個人教科書"
</code></pre>
<h3>使用 Calibre 為 Kindle 優化 (MOBI/AZW3)</h3>
<p>雖然 Pandoc 能處理內部的結構，但 <strong><a href="https://calibre-ebook.com/">Calibre</a></strong> 才是電子書庫管理與 Kindle 專業格式化的終極工具。如果你偏好圖形介面，或需要為舊款 Kindle 轉換為 MOBI/AZW3 格式，Calibre 的 <code>ebook-convert</code> 工具是不可或缺的：</p>
<pre><code class="language-bash"># 使用 Calibre 的 CLI 將 EPUB 轉換為 MOBI
ebook-convert textbook.epub textbook.mobi
</code></pre>
<p>Calibre 還能讓你注入自定義 CSS 以獲得更好的排版效果，並確保你生成的教科書包含能在 Kindle 書櫃中顯示的「真實」封面圖片。</p>
<h2>為什麼 2026 年離線閱讀依然重要</h2>
<p>在充滿通知的世界中，將學習轉移到像 Kindle 這樣「免受干擾」的設備是一項超能力。透過生成自己的教科書，你不僅是在攝取內容，還在建構一個隨職業生涯一同成長的專屬內部圖書館。</p>
<hr>
<h3>內部連結</h3>
<ul>
<li>參考我們的 <a href="file:///Users/chi-wei/dev/shareuhack/_posts/claude-code-prd-workflow/index.md">Claude Code PRD 工作流</a> 了解更多自動化技巧。</li>
<li>了解 AI 時代下<a href="file:///Users/chi-wei/dev/shareuhack/_posts/how-to-become-a-frontend-engineer/index.zh-TW.md">如何成為前端工程師</a>。</li>
</ul>

這是一份關於使用 AI、Pandoc 和 Claude Code 構建個人化教科書生成器的工作流指南。將原始數據轉換為結構化的 EPUB/MOBI 格式。

AI 在教育中的應用：個人化學習路徑

AI 個人教科書生成器：從原始資料打造專屬學習路徑

<h1>Claude Code UX 研究員：利用 AI Agent 自動化競品與介面評測</h1>
<p><strong>TL;DR</strong>: 別再每週浪費 10 小時做重複性的「競品審核 (Competitive Audit)」了。透過結合 <strong>Claude Code</strong> (終端機 Agent) 與 <strong>Playwright</strong>，你可以建立一個不眠不休的 UX 研究員，自動抓取競品資料、利用 AI 視覺分析 UI，並產出結構化的評測矩陣——本次我們以 <strong>Perp DEX</strong> 的交易量領先者作為實戰範例。</p>
<h2>適合本方案的讀者</h2>
<ul>
<li><strong>UX 研究員</strong>：厭倦了手動截圖與填表，想轉向策略性分析。</li>
<li><strong>PM 產品負責人</strong>：需要快速掌握競品功能疊代，作為 PRD 決策基礎。</li>
<li><strong>dApp 競品分析師</strong>：專注於 Web3 領域的交互模式（Interaction Patterns）研究。</li>
</ul>
<h3>使用情境 (User Journey)</h3>
<blockquote>
<p><strong>場景</strong>：DeFi 協議的資深設計師 Max 需要每週產出競品報告。</p>
<ol>
<li><strong>啟動</strong>：週一早上執行 <code>claude-code-research</code> 指令。</li>
<li><strong>自動導航</strong>：Agent 自動獲取熱門協議清單並截圖。</li>
<li><strong>AI 視覺</strong>：Claude Vision 比對「一鍵交易」流暢度。</li>
<li><strong>省下時間</strong>：Max 只需花 10 分鐘審閱自動生成的 Markdown 報告，重點放在產品差異化設計。</li>
</ol>
</blockquote>
<hr>
<h2>問題點：無意義的「審核疲勞」</h2>
<p>在快速變動的 DeFi 領域，競爭對手每週都會推出新功能。對於產品設計師與 PM 來說，跟進意味著：</p>
<ol>
<li>手動訪問 10 個以上的 dApp。</li>
<li>截取數十張截圖。</li>
<li>在 Excel 填寫「有無功能」的差異表。</li>
<li>記錄文案變化。</li>
</ol>
<p>等你做完，這份報告通常已經過時了。這是典型的「高重複性、高價值」任務——正是 <strong>AI Agent 工作流</strong> 的最佳發力點。</p>
<hr>
<h2>第一階段：AI 驅動的自動化接棒</h2>
<p>與其親自動手，我們將「體力活」交給 Claude。</p>
<h3>步驟 1：自動化發現 (DeFiLlama 交易量)</h3>
<p>我們不需要手動維護競品清單。直接利用 DeFiLlama API 抓取 <strong>24 小時交易量前 10 名的 Perp DEX</strong>。高交易量通常代表其交易介面經過高度優化。</p>
<p><strong>給 Claude Code 的指令</strong>：</p>
<blockquote>
<p>「寫一個腳本，利用 DeFiLlama API 抓取 24 小時交易量前 10 名的 Perp DEX 協議，並將其『交易頁面』的 URL 儲存為 JSON 檔案。」</p>
</blockquote>
<h3>步驟 2：Agent 的「眼睛」(Playwright)</h3>
<p>Claude Code 可以生成並執行 Playwright 腳本，以 Headless 模式訪問這些網址。</p>
<p><strong>核心行動</strong>：捕捉「Hero Section (首屏)」與「主儀表板」的截圖。</p>
<pre><code class="language-javascript">// Claude 生成的 Playwright 範例片段
const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://hyperliquid.xyz');
  await page.screenshot({ path: 'assets/hyperliquid-trade.png' });
  await browser.close();
})();
</code></pre>
<hr>
<h2>第二階段：AI 視覺深度分析</h2>
<p>截圖只是完成了一半，接著我們利用 <strong>Anthropic Vision</strong> 能力來「閱讀」UX。</p>
<p>我們將截圖餵回給 Claude 並給予結構化指令：</p>
<blockquote>
<p>「分析這張 Hyperliquid 交易介面的截圖。請提取：</p>
<ol>
<li>交易面板 (Order Entry) 的位置 (左側/右側)。</li>
<li>主要呼籲行動 (CTA) 的顏色。</li>
<li>列出所有可見資產。</li>
<li>根據視覺清晰度給予 1-5 分的『層級感 (Hierarchy)』評分。」</li>
</ol>
</blockquote>
<hr>
<h2>成果產出：評測矩陣 (Benchmarking Matrix)</h2>
<p>最終產出的不是一堆圖片，而是可以直接貼入 PRD 或 Notion 的<strong>精美 Markdown 矩陣</strong>。</p>





































<table><thead><tr><th align="left">協議</th><th align="left">核心資產</th><th align="left">主要 CTA</th><th align="left">視覺風格</th><th align="left">UX 複雜度</th><th align="left">24H 交易量</th></tr></thead><tbody><tr><td align="left"><strong>Hyperliquid</strong></td><td align="left">USDC</td><td align="left">Deposit</td><td align="left">專業交易終端</td><td align="left">高</td><td align="left">$1.2B+</td></tr><tr><td align="left"><strong>dYdX</strong></td><td align="left">USDC</td><td align="left">Trade Now</td><td align="left">機構型介面</td><td align="left">高</td><td align="left">$800M+</td></tr><tr><td align="left"><strong>GMX</strong></td><td align="left">GLP/GM</td><td align="left">Long/Short</td><td align="left">加密原生風格</td><td align="left">中</td><td align="left">$300M+</td></tr></tbody></table>
<hr>
<h3>量化成果：AI vs 手動審核</h3>






























<table><thead><tr><th align="left">項目</th><th align="left">手動分析 (10 個競品)</th><th align="left">AI Agent 自動化</th></tr></thead><tbody><tr><td align="left"><strong>資料收集時間</strong></td><td align="left">~4 小時</td><td align="left">&#x3C; 5 分鐘</td></tr><tr><td align="left"><strong>視覺分析深度</strong></td><td align="left">依賴個人主觀</td><td align="left">結構化標註 (顏色/佈局)</td></tr><tr><td align="left"><strong>維護成本</strong></td><td align="left">高 (需手動更新截圖)</td><td align="left">低 (一行指令重新執行)</td></tr><tr><td align="left"><strong>資料完整性</strong></td><td align="left">常遺漏細節</td><td align="left">100% 覆蓋預設規則</td></tr></tbody></table>
<hr>
<h2>FAQ</h2>
<p><strong>Q: AI 分析結果如何校正與驗證？</strong>
A: 建議採用「採樣檢查制」。對於分析報告中的重點數據（如主要 CTA），隨機選取 10-20% 的截圖進行人工比對，確保 Vision 模型對特定介面（如深色模式或複雜 Web3 動效）的識別度。</p>
<p><strong>Q: 對於需要連結錢包才能看到的介面能分析嗎？</strong>
A: 透過 Playwright 注入私鑰或模擬 Session 是可行的，但開發複雜度較高。初期建議專注於「非登錄狀態」下的產品展示頁與核心交易面板。</p>
<hr>
<h2>風險與限制 (Risk Disclosure)</h2>
<p>雖然 AI Agent 大幅提升了效率，但讀者需注意：</p>
<ol>
<li><strong>視覺依賴性</strong>：目前方案主要依賴靜態截圖，對複雜的「交互流程」（如滑動觸發的動畫或多步彈窗）無法深度理解。</li>
<li><strong>Token 消耗</strong>：頻繁捕捉高解析度截圖並交由 Vision 模型處理會產生一定的 API 費用。</li>
<li><strong>反爬蟲機制</strong>：部分 dApp 可能會封鎖 Headless Browser，需搭配 Proxy 或更擬人的 Playwright 配置。</li>
</ol>
<hr>
<h2>🚀 為什麼這在 2026 年至關重要</h2>
<p>單純的效率已不再足夠。要平衡「人類 + AI」時代，你必須從<strong>研究員</strong>轉型為<strong>架構師</strong>。</p>
<p>與其花 8 小時收集數據，你應該只花 15 分鐘審閱 <strong>AI 自動化審核報告</strong>，剩餘的 7 小時 45 分鐘則用來做真正的設計決策，打造產品的差異化。</p>
<hr>
<h2>結語：建立你的自動對手觀察塔</h2>
<p>別只是跟隨競爭對手，要自主觀察。透過建立「Claude 觀察塔」，你將原本枯燥的雜事轉化為策略優勢。<strong>從「找資料的人」進化為「解讀資料的人」</strong>，這才是 UX 研究員在 AI 時代的核心價值。</p>
<p><em>準備好自動化你的下一次審核了嗎？讓我們開始動手吧。</em></p>

這是一份關於如何利用 Claude Code 與 Playwright AI Vision 建立自動化 UX 研究與競品評測 AI Agent 的技術指南。

Anthropic: Claude Code 說明文件

Playwright: 自動化測試與截圖

Anthropic: Vision API 視覺分析

DeFiLlama API

Claude Code UX 研究員：利用 AI Agent 自動化競品與介面評測

<h1>多重 AI 協作編排：結合不同工具強項打造高品質內容</h1>
<p><strong>TL;DR</strong>: 不要指望單一個 AI 能搞定所有事。透過將「大腦」（邏輯/文字）與「眼睛」（視覺）分工，讓各個專業 AI 在其最強的領域協同作業，才能製作出超越通用型模型上限的頂尖內容。</p>
<hr>
<h2>一、 全能 AI 的迷思：為什麼你需要協作？</h2>
<p>真的有完美的 AI 能一次完成結構化的簡報、撰寫內文，並生成富有情境的背景圖嗎？市面上許多工具宣稱能做到，但結果往往是缺乏靈魂且精確度不足的「罐頭感」內容。</p>
<h3>1.1 理論背景：分佈式智能 (Distributed Intelligence)</h3>
<p>在 AI 研究領域，<strong>多代理系統 (Multi-Agent Systems, MAS)</strong> 是一個核心概念。它主張複雜問題不應由單一模型處理，而應由多個專業、可互相溝通的代理 (Agents) 協作完成。這種「分佈式智能」能顯著提升輸出品質、適應性與穩定性。</p>
<h3>1.2 為什麼這對內容生產者很重要？</h3>
<p>問題不在於 AI 的能力上限，而在於<strong>預期與限制</strong>。專業工具在其特定領域（如 Midjourney 之於藝術感、Claude 之於邏輯架構）累積的權重與優化，是通用型模型在短期內難以完全覆蓋的。</p>
<hr>
<h2>二、 🏗️ 核心邏輯：連結「大腦」與「視覺」</h2>
<p>這套「協作編排 (AI Orchestration)」工作流建立在一個簡單的原則上：<strong>專業分工與接棒 (Handoff Points)</strong>。</p>
<h3>2.1 決策指南：何時該切換工具？</h3>





























<table><thead><tr><th align="left">任務類型</th><th align="left">推薦領域</th><th align="left">切換時機 (Handoff)</th><th align="left">為什麼不選全能 AI？</th></tr></thead><tbody><tr><td align="left"><strong>結構與大綱</strong></td><td align="left">邏輯性模型 (Claude 3.5)</td><td align="left">當邏輯框架完整後。</td><td align="left">通用型模型常會產生重複或廢話。</td></tr><tr><td align="left"><strong>高品質視覺</strong></td><td align="left">專業繪圖 (Midjourney)</td><td align="left">將文字提示轉為視覺 Prompts。</td><td align="left">統合型 AI 產圖控制力弱，Midjourney 則能提供電影級細節。</td></tr><tr><td align="left"><strong>最終排版</strong></td><td align="left">專業載體 (Gamma / Canva)</td><td align="left">當文字與圖片皆備齊。</td><td align="left">專業載體支援更精緻的排版層次與 4K 輸出。</td></tr></tbody></table>
<h3>2.2 階段一：智囊 (邏輯、策略、架構)</h3>
<p>從優化邏輯與結構的工具開始。</p>
<ul>
<li><strong>任務</strong>：生成大綱、層級結構、核心訊息與對應的視覺提示語。</li>
<li><strong>關鍵決策點</strong>：此階段只輸出「文字」，絕不勉強在邏輯模型中生成低品質插圖。</li>
</ul>
<h3>2.3 階段二：畫筆 (視覺呈現、美學)</h3>
<p>將視覺需求餵給專業的圖像引擎。</p>
<ul>
<li><strong>任務</strong>：根據概念描述，生成風格一致的高產值資產。</li>
<li><strong>核心工具</strong>：追求極致視覺選 <strong>Midjourney</strong>；追求準確與通用選 <strong>DALL-E 3</strong>。</li>
</ul>
<hr>
<h2>三、 🛠️ 實戰案例：生成專業級簡報 (PPT)</h2>
<p>想像你需要製作一份關於「DeFi 的未來」的專題簡報：</p>
<ol>
<li><strong>Step A (Claude)</strong>：要求生成 10 頁簡報大綱，並針對每一頁提供「賽博龐克風格、抽象金融感」的視覺提示詞。</li>
<li><strong>Step B (Midjourney)</strong>：批次運行提示詞，確保色調一致。</li>
<li><strong>Step C (Gamma)</strong>：匯入文字結構，手動替換 AI 預設的隨機圖庫，放入剛剛生成的 Midjourney 資產。</li>
</ol>
<p><strong>結果</strong>：一份看起來像是量身訂製（而不是自動生成）的專業簡報。</p>
<hr>
<h2>四、 ⚠️ 風險與限制 (Risk &#x26; Trade-off)</h2>
<p>邁向多重 AI 協作前，你必須意識到的現實障礙：</p>
<ol>
<li><strong>隱形成本：額外的協調時間</strong>
<ul>
<li>跨工具移動資料需要手動「接手」。對於簡單任務，這套流程的性價比極低（Overkill）。</li>
</ul>
</li>
<li><strong>工具成本與生成時間</strong>
<ul>
<li>你需要訂閱多個平台的 Pro 版本（Midjourney + Claude + Gamma），且生成時間通常是單一工具的 3-5 倍。</li>
</ul>
</li>
<li><strong>風格一致性 (Style Consistency)</strong>
<ul>
<li>雖然使用了 <code>--sref</code> 等參數，但跨工具的風格對接仍需要頻繁的手動微調 (Fine-tune)，AI 目前還無法完全理解「美感統一」的抽象概念。</li>
</ul>
</li>
</ol>
<hr>
<h2>五、 ⚖️ 判斷準則：何時「不該」用這套流程？</h2>
<ul>
<li><strong>適合使用的場景</strong>：對外簡報、品牌官網圖、具備深度思考的週刊、高流量社群內容。</li>
<li><strong>建議跳過（直接用通用模型）的場景</strong>：內部簡單週報、純文字隨筆、對品質要求極低的臨時草稿。</li>
</ul>
<hr>
<h2>六、 FAQ</h2>
<p><strong>Q：如何維持視覺風格的一致性？</strong>
A：在 Midjourney 中使用固定參數（如 <code>--sref</code> 或 <code>--cref</code>）處理所有圖片，並在提示詞中鎖定核心美學關鍵字。</p>
<p><strong>Q：這難道不比直接用工具生成器更費工嗎？</strong>
A：是的，這會多花約 20% 的時間，但內容的「專業感」提升通常超過 5 倍。</p>
<hr>
<h2>七、 🚀 進階：邁向自動化代理流水線 (Multi-Agent Workflow)</h2>
<p>當你掌握了手動「接手」的邏輯，下一個維度是透過工具將其自動化。</p>
<h3>7.1 使用 AI Agent 平台 (Dify, Coze)</h3>
<p>這些平台允許你配置多個模型節點，完成自動對接。</p>
<ul>
<li><strong>節點 1 (推理層)</strong>：標題 -> 生成結構與 Prompts。</li>
<li><strong>節點 2 (視覺層)</strong>：Prompts -> 調用圖像 API。</li>
<li><strong>節點 3 (輸出層)</strong>：合併結果 -> 推送至你的工作空間。</li>
</ul>
<h3>7.2 什麼時機切換到自動化？</h3>
<ul>
<li><strong>任務重複性高</strong>：每天都要生成固定格式的圖文。</li>
<li><strong>追求規模化 (Scale)</strong>：需要短時間產出大量高品質內容時。</li>
</ul>
<hr>
<h2>八、 結語：從操作員轉型為編排者</h2>
<p>生產力的未來不在於找到更聰明的 AI，而在於成為更好的<strong>編排者 (Orchestrator)</strong>。透過協調專業工具，你可以達到通用型工具無法企及的高品質境界。<strong>不再是讓模型替你思考，而是讓不同模型各司其職，實現 1+1 > 2 的協作力量。</strong></p>

這是一份關於多重 AI 協作 (AI Orchestration) 的深度指南。了解如何透過分工編排，結合不同專業 AI 工具（如文字、圖像生成）的強項，建立高品質的自動化內容生產線。

IBM: What is a Multi-Agent System?

NVIDIA: Multi-Agent AI Collaboration Concepts

Anthropic: Claude 3.5 Sonnet Capabilities

Midjourney Documentation

多重 AI 協作編排：結合不同工具強項打造高品質內容

<h1>零成本回饋機制：打造 Telegram + AI Vision 的自動化 Bug 分類機器人</h1>
<h2>TL;DR</h2>
<ul>
<li><strong>無摩擦收集</strong>：將 Telegram 群組當作你的「收件箱」。只需將任何回饋或截圖轉傳到群組，剩下的交給機器人。</li>
<li><strong>AI 驅動分類</strong>：利用具備視覺能力的 LLM（如 GPT-5.2 或 GPT-4.5 Turbo）分析圖片、提取錯誤訊息，並判斷意圖（Bug、新功能需求等）。</li>
<li><strong>Jira 自動化</strong>：自動建立夾帶圖片附件的工單，或連結至現有的追蹤項目，保持需求管理流程的清爽。</li>
</ul>
<hr>
<p>身為一名產品經理（Product Manager），你經常被來自 Slack、Email 和各種私訊的回饋轟炸。最具價值的回饋往往是一張原始截圖——一個錯誤訊息、一個 UI 破圖，或是一個競爭對手的亮點功能。</p>
<p>問題在於：<strong>分類（Triage）是一件苦差事。</strong> 將圖片從手機移到 Jira、撰寫描述、貼上適當的標籤，這整套流程耗費的精力，往往讓 50% 的回饋最後直接死在你的「收藏訊息」裡。</p>
<p>身為一名 <strong>AI 增強型 PM (AI-augmented PM)</strong>，你的目標是自動化這些枯燥的雜事，將精力集中在產品策略上。以下是如何打造一個<strong>零維護成本的回饋循環</strong>。</p>
<h2>工作流：從螢幕截圖到結構化工單</h2>
<p>我們不需要複雜的 App 或笨重的 SDK，直接停留在使用者（和你的隊友）已經在使用的地方：<strong>Telegram</strong>。</p>
<h3>1. 收件箱：Telegram「分類」群組</h3>
<p>建立一個私人的 Telegram 群組，並將你的機器人加入為<strong>管理員（Administrator）</strong>。</p>
<blockquote>
<p><strong>重要：隱私權陷阱</strong>
預設情況下，Telegram 機器人無法讀取群組訊息，除非是指令或被提及。若要解決此問題，你必須透過 <a href="https://t.me/botfather">@BotFather</a> <strong>關閉隱私模式 (Disable Privacy Mode)</strong>，或確保機器人擁有「管理訊息」的管理員權限。</p>
</blockquote>
<ul>
<li><strong>步驟</strong>：每當你看到一個 Bug，或者有使用者傳送回饋給你，只需將其轉傳到這個群組。</li>
<li><strong>原因</strong>：它能將混亂集中化。你不需要打開電腦，只需一鍵轉傳，即可完成收集。</li>
</ul>
<h3>2. 觸發機制：手動 Agent vs. 自動化任務 (Trigger)</h3>
<p>根據你的工作偏好，你可以透過兩種方式處理訊息擷取：</p>
<ol>
<li>
<p><strong>選項 A：手動 / Agent 驅動 (Claude Skill)</strong>：</p>
<ul>
<li><strong>方式</strong>：在你的 AI 環境（如 Antigravity 或 CLI 工具）中手動觸發任務。</li>
<li><strong>觸發字</strong>：「Claude，幫我抓取分類群組中的最後 10 則訊息並進行處理。」</li>
<li><strong>優點</strong>：高度可控、節省自動化 API 成本，且能即時加入背景資訊（例如：「這與目前的 Sprint 有關」）。</li>
</ul>
</li>
<li>
<p><strong>選項 B：自動化 / 定時任務 (n8n &#x26; Cron)</strong>：</p>
<ul>
<li><strong>方式</strong>：使用 <strong>n8n</strong> 或本地的 <strong>Cronjob</strong> 設定定時任務。</li>
<li><strong>觸發</strong>：每小時定期檢查，或透過 Webhook 在每則訊息抵達時自動掃描群組。</li>
<li><strong>優點</strong>：真正的「零維護」。即使你在睡覺，回饋也會自動流入 Jira，並搭配專用的 LLM API Key 執行背景分析。</li>
</ul>
</li>
</ol>
<h3>3. 大腦：AI Vision 分析 (GPT-5.2 / GPT-4.5 Turbo)</h3>
<p>這是奇蹟發生的時刻。機器人會將照片發送給具備視覺能力的 LLM。在 2026 年，你有兩個首選：</p>
<ul>
<li><strong>GPT-5.2</strong>：複雜推理的金標準。如果你需要 AI 交叉引用特定的技術規範或 PRD，這是最佳選擇。</li>
<li><strong>GPT-4.5 Turbo</strong>：便宜 70% 且經過高度優化。非常適合簡單的「這是不是 Bug？」分類。</li>
</ul>
<p><strong>提示詞（Prompt）</strong>：</p>
<blockquote>
<p>「分析這張截圖。提取任何可見的錯誤訊息，識別涉及的 UI 元件，並判斷這是 Bug、功能需求 (Feature Request) 還是 UX 改進。請以結構化的 JSON 格式輸出結果。」</p>
</blockquote>
<p><strong>結構化輸出範例</strong>：</p>
<pre><code class="language-json">{
  "triage_type": "bug",
  "priority": "P2",
  "summary": "Mobile 登入頁面失效",
  "description": "使用者回報 SSO 登入流程出現 404 錯誤。錯誤文字：'Service Unavailable'。",
  "components": ["Auth", "Mobile Web"],
  "suggested_action": "check_existing_ticket: AUTH-123"
}
</code></pre>
<h3>4. 執行：Jira 整合</h3>
<p>最後，系統呼叫 Jira API：</p>
<ul>
<li><strong>新問題</strong>：針對獨特的 Bug，建立一張標籤工單，上傳原始截圖作為附件，並設定優先權。</li>
<li><strong>現有工單</strong>：如果 AI 偵測到這是已知問題，則僅將新截圖作為評論（Comment）加入現有的追蹤項目中。</li>
</ul>
<h2>結語</h2>
<p>最好的工具就是你真正會去用的工具。透過橋接一段隨意的訊息與正式的需求追蹤系統，你能確保任何有價值的回饋都不會「被遺漏在隙縫中」。</p>

針對 AI 增強型 PM (AI-augmented PM) 與獨立開發者的專業指南，教你如何利用 GPT-5.2 Vision 與 Telegram 機器人自動化收集與分類使用者回饋。

Telegram Bot API

Jira REST API

零成本回饋機制：打造 Telegram + AI Vision 的自動化 Bug 分類機器人

<h1>PRD 寫作革命：類 Git Flow 的高效「離線優化」工作流</h1>
<h2>TL;DR</h2>
<ul>
<li><strong>離線協作 (Offline-First)</strong>：不再受限於網頁編輯器的緩慢與分心。這套工作流程讓你在慣用的 IDE（如 Cursor, VS Code）或 AI 代理（如 Claude Code, Antigravity）中，以 Markdown 專注產出。</li>
<li><strong>混合效率 (Hybrid Efficiency)</strong>：利用精準的 API 腳本負責「大量數據傳輸」（精準且節省 Token），而將 Claude Code/MCP 用於「邏輯分析、關聯參考與內容產出」。</li>
<li><strong>擺脫瀏覽器限制</strong>：像寫代碼一樣對待 PRD。在本地環境「拉取 (Pull)」上下文，使用 Markdown 進行高效編輯，並在審閱差異 (Diff) 後「推回 (Push)」雲端。</li>
<li><strong>安全至上 (Safety First)</strong>：務必在沙盒環境進行測試，並建立「審閱差異」的思維，嚴防自動化工具導致的 Jira 或 Confluence 內容大規模覆蓋。</li>
</ul>
<hr>
<p>作為一名 Technical Product Manager (TPM)，你的工作處於高層戰略與深層技術實現的交匯點。日常使用的工具——通常是 Jira、Confluence 和 Slack 的大雜燴——有時會讓人感到與實際的工程開發脫節。現在，是時候借鑒開發者的工具箱了：<strong>像管理代碼一樣管理你的需求。</strong></p>
<p>這就是所謂的 <strong>Claude Code PRD 工作流</strong>。</p>
<h2>現狀：瀏覽器與上下文的瓶頸</h2>
<p>撰寫一份 PRD 通常意味著：</p>
<ol>
<li>打開 Confluence，在編輯器不穩定的格式中苦苦掙扎。</li>
<li>在 15 個以上的瀏覽器分頁中切換，查找技術文檔與相關 Jira Tickets。
這個過程不僅緩慢，且難以讓 LLM 發揮最大價值。若只是單純將混亂的資料丟給 AI，往往會因為上下文過多而導致 Token 浪費，甚至產生幻覺。</li>
</ol>
<h2>解決方案：「混合型」Pull/Push 工作流</h2>
<p>最有效率的工作流並不完全依賴 AI Agent 來搬運數據，而是採用 <strong>「混合模式 (Hybrid Approach)」</strong>：</p>
<ol>
<li><strong>API 腳本</strong>：負責精準、高效的原始數據傳輸（省 Token、保證格式）。</li>
<li><strong>Claude Code + MCP</strong>：負責智能推理、跨文檔參考與草案生成。</li>
</ol>
<h3>第一步：精準拉取 (Pull) 上下文</h3>
<p>比起要求 AI Agent 在茫茫文檔中「搜尋」，直接利用針對 <a href="https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/">Jira REST API</a> 編寫的腳本會更有效率。</p>
<p><strong>混合策略</strong>：使用 API 腳本來處理 <strong>複雜的過濾條件</strong> 並精準控制 Fetch Data 的範圍。這正是 API 腳本的價值所在——當你面臨複雜的 JQL 條件、需要遞歸抓取子頁面，或是根據特定自定義字段進行篩選時，API 腳本能提供比 AI Agent 更穩定的精準度。</p>
<pre><code class="language-bash"># 示例：針對複雜過濾條件的精準抓取
python scripts/fetch_jira.py --jql "project = 'AUTH' AND status = 'In Progress' AND labels in ('v2-refactor')" --depth 2 --output target_scope.md
</code></pre>
<p>透過 API 處理「數據搬運」，你能為 Claude 提供一個乾淨且高度精煉的上下文。這在過濾條件複雜、數據範圍需要嚴格掌控時尤為重要，同時也避免了 Agent 在「尋找與過濾」過程中浪費的大量 Token。</p>
<h3>第二步：智能關聯參考 (Cross-Referencing) 與撰寫</h3>
<p>這是最具魔力的部分。你不再只是編輯文字，而是與一個擁有「全域視野」的智能夥伴共同開發需求。</p>
<p><strong>多源導引</strong>：利用 <strong>Claude Code + MCP</strong> 來關聯參考從 Jira 和 Confluence 抓取的數據。</p>
<ul>
<li><strong>指令示例</strong>：「Claude，分析我剛剛從 Jira 拉取的 <code>user-stories</code>，並與 Confluence 上的 <code>architecture-spec</code> 進行關聯參考。找出我們提議的 API 身份驗證流程中可能存在的技術缺口。」</li>
</ul>
<p><strong>進階技巧：引入 RAG 與 NotebookLM</strong>
當你的技術文檔累積到數百頁時，即使是再大的上下文窗口 (Context Window) 也難免力不從心。</p>
<ul>
<li><strong>策略</strong>：將 <a href="https://notebooklm.google.com/">NotebookLM</a> 作為你的外部大腦。索引大量的 PDF 規格書、舊版 Confluence 導出文檔以及 Slack 對話紀錄。</li>
<li><strong>橋樑</strong>：利用如 <a href="https://github.com/PleasePrompto/notebooklm-skill">NotebookLM Claude Skill</a> 這樣的工具，直接從 CLI 查詢你索引的知識庫。這讓你能「與文檔對話」並將精準的片段提取到 PRD 草案中，完全無需手動搜索。</li>
</ul>
<h3>第三步：安全推回 (Push) 更新</h3>
<blockquote>
<p><strong>⚠️ 安全至上</strong>：使用自動化工具更新生產環境的 Confluence 或 Jira 具有極高的風險。如果解析出現故障，可能會意外抹除數月來的協作歷史。</p>
</blockquote>
<p><strong>安全標準操作程序 (SOP)</strong>：</p>
<ol>
<li><strong>沙盒優先</strong>：在應用到正式環境前，務必先在測試用的 Jira 專案或獨立的 Confluence 空間進行流程測試。</li>
<li><strong>審閱差異 (Review Diffs)</strong>：像 Code Review 一樣審視文檔更新。在同步回雲端前，務必對比本地 Markdown 與雲端版本的差異，確保沒有非預期的變更。</li>
<li><strong>草稿模式</strong>：如果可能，請先將更新推送到「草稿」或「評論」區，而非直接覆蓋主頁面內容。</li>
</ol>
<h2>常見陷阱與避免方案</h2>
<ul>
<li><strong>ADF 格式轉換</strong>：Confluence 使用的是 ADF 格式。Markdown -> ADF 的轉換可能不完美，建議使用功能完整的庫（如 <code>atlassian-python-api</code>）來處理。</li>
<li><strong>上下文窗口限制</strong>：面對超大型 PRD，不要一次丟入所有內容。利用 <a href="https://modelcontextprotocol.io/">Anthropic 的 MCP</a> 進行局部索引。</li>
<li><strong>權限管理</strong>：確保你的 API Token 遵循「最小權限原則」，僅授權寫入特定的專案或空間。</li>
</ul>
<h2>權威資源參考</h2>
<ul>
<li><strong><a href="https://academy.anthropic.com/">Anthropic Academy</a></strong>：學習與 Claude 進行 Agentic Coding 的最佳實踐。</li>
<li><strong><a href="https://support.atlassian.com/rovo/docs/set-up-the-rovo-mcp-server/">Atlassian Rovo MCP Server</a></strong>：連接 Claude 與 Atlassian 數據的官方橋樑。</li>
<li><strong><a href="https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/">Jira Cloud API 参考</a></strong>：開發自定義精準腳本的必備文檔。</li>
<li><strong><a href="https://modelcontextprotocol.io">Model Context Protocol (MCP)</a></strong>：AI 數據集成的開放標準。</li>
</ul>
<p>透過消除需求定義與開發工具之間的隔閡，你不僅能寫出更高質量的 PRD，還能與工程團隊建立更深層的技術共識。</p>

這是一份為 Technical PM 打造的專業指南，深入探討如何利用 Claude Code、自定義 API 腳本以及 MCP 協議來優化 PRD 撰寫流程。涵蓋高效同步與安全開發的最佳實踐。

Anthropic Academy - Claude Engineering

Model Context Protocol (MCP) Official Site

Jira Cloud Platform API Reference

PRD 寫作革命：類 Git Flow 的高效「離線優化」工作流

<p>最近我在產品管理 (PM) 的工作中導入了 <strong>Claude Code</strong>，這是我近期工作方式最大的變革。原本需要幾天才能完成的規格文件與原型製作，現在幾個小時就能搞定，而且 AI 考慮的邊角案例 (Edge Cases) 甚至比我還周全一百倍。</p>
<p>這不僅僅是用 ChatGPT 問問題，而是將 AI 之於<strong>工作流 (Workflow)</strong> 的深度整合。正如 Anthropic 在其 <a href="https://www.anthropic.com/research/building-effective-agents">Building Effective Agents</a> 指南中所述，真正的生產力爆發來自於將 AI 從單純的「問答機器」轉變為能夠執行複雜任務的「代理人 (Agents)」。</p>
<h2>核心流程：一人產品團隊</h2>
<p>我的新工作流大致如下，這是一個從模糊到精確的收斂過程：</p>
<blockquote>
<p><strong>需求進來</strong> → <strong>Claude Skills</strong> (SOP) 初步分析 → <strong>Sub-agents</strong> (多角度) 檢視與辯論 → 產出高品質 <strong>PRD + Prototype</strong> → 跨部門溝通 → 規格確立</p>
</blockquote>
<p>這就像是你擁有了一個隨傳隨到的虛擬團隊，隨時準備好為你工作。與其說我是 PM，我現在更像是一個 <strong>AI 團隊的指揮官</strong>。</p>
<hr>
<h2>1. Claude Skills：把你的 SOP 寫進大腦</h2>
<p><strong>Skills</strong> 的概念很簡單：把你腦袋裡的標準作業程序 (SOP) 寫下來，讓 AI 嚴格遵守。這對應到 Anthropic 提到的 "Workflows" 概念——透過預定義的路徑來引導 LLM，確保產出的一致性。</p>
<p>以前寫 PRD，我們要注意命名一致性、格式規範、團隊慣用語，還要記得參考以前的舊文件。人腦很容易漏掉細節，改了 A 卻忘了壞了 B。</p>
<p>現在，我將這些規則封裝成 Skills。以下是一個真實的 <code>requirement-analyzer</code> Skill 範例：</p>
<pre><code class="language-markdown"># Skill: Requirement Analyzer

## Role
你是一位資深的技術產品經理 (TPM)，擅長將模糊的商業需求轉化為結構化的 User Stories。

## Input
- 原始需求 (Raw Input)
- 目標客群 (Target Audience)

## Output Format (Markdown)
1. **Executive Summary**: 一句話解釋這個功能是做什麼的。
2. **User Stories**: 格式為 "As a &#x3C;role>, I want to &#x3C;action>, so that &#x3C;benefit>"。
3. **Acceptance Criteria (Gherkin Syntax)**:
   - Given [情境]
   - When [動作]
   - Then [預期結果]
4. **Edge Cases**: 至少列出 3 個極端狀況 (例如：斷網、資料為空、權限不足)。

## Rules
- 必須使用這種格式: `FE-[Feature Name]-001` 作為 ID。
- 優先考慮 Mobile First 的體驗。
</code></pre>
<p>當這些規則被寫成 Code (或 Prompt)，AI 就會按照預設的標準產出，既穩定又一致。那些花時間又容易出錯的 Cross-reference 工作，就全交給 AI 處理。</p>
<h2>2. Sub-agents：換位思考的虛擬分身</h2>
<p>如果說 Skills 是「手」，那麼 <strong>Sub-agents</strong> 就是「腦」。</p>
<p>自己寫規格時，很容易陷入盲點 (Blind spots)。根據 Basecamp 的 <a href="https://basecamp.com/shapeup">Shape Up Methodology</a>，產品開發最忌諱的是在還沒想清楚 (Shaping) 之前就冒然投入開發。</p>
<p>為了避免這個問題，我創造了不同的 Agent 來進行「自我辯證」：</p>
<ul>
<li><strong>User Researcher Agent</strong>: 質疑這個流程是否符合直覺？有沒有更好的體驗？</li>
<li><strong>Dev Agent</strong>: 評估技術可行性，釐清資料庫 schema 要怎麼開，API 要怎麼接。</li>
<li><strong>QA Agent</strong>: 專門找漏洞，列出所有可能的極端狀況。</li>
<li><strong>Stakeholder Agent</strong>: 從商業價值的角度挑戰這個需求的必要性。</li>
</ul>
<h3>實際運作對話 (Simulation)</h3>
<blockquote>
<p><strong>Me (PM)</strong>: "我想做一個『一鍵產出週報』的功能。"</p>
<p><strong>Dev Agent</strong>: "技術上可行，但要考慮 Context Window 的限制。如果使用者的每週 Ticket 數量超過 500 張，API 可能會 Timeout。建議加上 Pagination 或與非同步處理 (Async Job)。"</p>
<p><strong>QA Agent</strong>: "同意。另外，如果這一週完全沒有 Ticket 怎麼辦？報表會顯示空白還是有預設文案？還有，如果 API call 失敗，要有 Retry 機制嗎？"</p>
<p><strong>User Researcher Agent</strong>: "等等，使用者真的需要『一鍵』嗎？他們通常會想要編輯 AI 產出的內容。我建議流程改成：生成草稿 -> 讓使用者預覽/編輯 -> 存檔發送。"</p>
</blockquote>
<p>運作起來，就像是在電腦裡開了一場高效的會議。以前這些來回確認要開好幾次會，現在幾個小時內就能完成。這正是 <strong>"Shift Left"</strong> (測試左移) 的極致表現——在寫下第一行程式碼之前，問題就已經被發現並解決了。</p>
<h2>3. 秒產 Prototype：溝通不再靠想像</h2>
<p>這是最強大的部分。文字再精準，都不如一個能動的畫面。</p>
<p>以前常常規格寫好了，但設計圖還沒出來，跟工程師或老闆討論時大家只能「各自想像」，導致上線後才發現誤會大了。</p>
<p>現在利用 Claude Code 結合 <code>v0.dev</code> 或 Tailwind CSS，我可以直接產出前端代碼，給我一個<strong>能動的 Interaction Prototype</strong>。</p>
<ul>
<li><strong>Before</strong>: "點擊這個按鈕後，會彈出一個 Modal，裡面有三個選項..." (工程師：聽起來好複雜)</li>
<li><strong>After</strong>: "直接看這個 HTML 檔，點點看就知道了。" (工程師：秒懂)</li>
</ul>
<p>溝通效率快非常多，甚至可以在開發前先驗證技術細節。沒圖沒真相，現在我幾乎是帶著 Prototype 去開會。</p>
<h2>4. Git Flow：文件即代碼 (Docs as Code)</h2>
<p>最後一個關鍵改變是 <strong>Git Flow</strong>。這與 Atlassian 提倡的 <a href="https://www.atlassian.com/agile/knowledge-management/docs-as-code">Docs as Code</a> 理念不謀而合。</p>
<p>以前文件散落在 Google Docs、Confluence 或 Slack 對話裡，久了就變成沒人維護的垃圾 (Stale documentation)。現在我嘗試讓所有的產出都進入 Git 版本控制。</p>
<h3>推薦的文件結構</h3>
<pre><code class="language-bash">project-root/
├── src/                # 原始碼
├── docs/
│   ├── adr/            # 架構決策紀錄 (Architecture Decision Records)
│   ├── prd/            # 產品需求文件
│   │   ├── 2026-02-feature-A.md
│   │   └── 2026-03-feature-B.md
│   └── specifications/ # 技術規格書
├── .claude/            # AI 相關設定
│   ├── skills/         # 定義好的 Skills
│   └── prompts/        # 常用的 Prompt Templates
└── README.md
</code></pre>
<p>這樣做的好處是：</p>
<ol>
<li><strong>Single Source of Truth</strong>: 代碼變了，文件就在旁邊，提醒你要由改。</li>
<li><strong>Code Review</strong>: 文件的修改也走 Pull Request 流程，確保有人看過。</li>
<li><strong>Traceability</strong>: 誰在什麼時候改了什麼規格，Git Log 寫得清清楚楚。</li>
</ol>
<h2>總結</h2>
<p>目前這都還是很粗淺的應用，但已經顯著減少了「產出低品質文件」的機會，也省下大量重複造輪子的時間。</p>
<p>很多 PM 擔心 AI 會取代他們，但我認為，AI 取代的是「執行者 (Doer)」，而不是「思考者 (Thinker)」。把繁瑣的工作 (寫文件、畫圖、查資料) 交給自動化，PM 才能將時間花在真正有價值的地方：<strong>決策與溝通</strong>。</p>
<p>未來的 PM，或許更像是一個 AI 團隊的指揮官，你的價值取決於你能調度多少 AI Agents 來為你解決複雜問題。</p>

深入解析如何將 Claude Code 導入 PM 工作流，從需求分析、PRD 撰寫到 Prototype 產出的完整自動化實踐。附完整 Prompt 範例與 Git Flow 架構。

AI 工具庫

AI 個人教科書生成器：從原始資料打造專屬學習路徑

Claude Code UX 研究員：利用 AI Agent 自動化競品與介面評測

多重 AI 協作編排：結合不同工具強項打造高品質內容

零成本回饋機制：打造 Telegram + AI Vision 的自動化 Bug 分類機器人

PRD 寫作革命：類 Git Flow 的高效「離線優化」工作流

PM 工作流革命：如何用 Claude Code、Skills 與 Sub-Agents 打造一人產品團隊

探索更多

學習方法

職涯發展

專案管理

生產力工具

AI Agents

金融理財

加密貨幣卡

旅行駭客

思維與心態

訂房攻略