VoxFlow 卡片技能

VoxFlow 技能 — 卡片（Card）

將一段文字轉換為一組獨特且風格一致的視覺卡片圖片。 每張卡片都是一個獨立的網頁；所有卡片共用相同的尺寸與樣式系統； 它們透過 Playwright 渲染並匯出為 PNG 圖片。

這是靜態卡片圖片技能。如需其他形式，請切換至：

• 文章 → 直式卡片影片（切片） — 1080×1920 短影音，13 種主題 → voxflow:slice
• 短影片 / AI 剪輯 / 知識卡片影片 → voxflow:video
• 多人播客 → voxflow:podcast
• TTS / 語音 / 安裝 / 驗證 / 配額 → voxflow:hub

步驟 0 · 登入閘門（必要，請先執行此步驟）

此技能是 VoxFlow 的一部分，需要已登入的帳戶。 在執行任何其他動作之前 — 在提問、研究或設計之前 — 請先驗證登入狀態：

voxflow status

• 顯示帳戶資訊與剩餘配額 → 已登入，繼續進行工作流程。
• 報錯 / 顯示「未登入」 → 停止。執行 voxflow login（會開啟瀏覽器 — 支援 Google 或電子郵件 OTP），等待使用者完成登入，然後重新執行 voxflow status。在登入成功之前，不要收集參數或產生任何卡片。
• voxflow: command not found → 先執行 npm install -g voxflow，然後執行 voxflow login。

永遠不要跳過此閘門，不要為未經驗證的使用者產生卡片，也不要自行發明 token。快取的 token 存放於 ~/.config/voxflow/token.json；在 CI 環境中則支援 VOXFLOW_TOKEN 環境變數。

概述

從來源內容建立一組可分享的視覺卡片。將每張卡片視為獨立的網頁，保持所有卡片相同的尺寸與樣式系統，使用 Playwright 渲染，匯出圖片，並針對較弱的卡片進行迭代改進。

品味基準

references/taste.md 是一個約束檢查清單，它界定了每個卡片模板、主題、佈局與設計語言。請將它視為一個在設計時會強制執行的底線，而不是在工作流程開始時需要背誦的開場儀式。

• 僅在兩個時刻載入 references/taste.md，而不是在工作流程開始時：
  • 選擇主題預設與設計語言時（工作流程步驟 4），以確保選擇不違反強制約束。
  • QA 評分時（工作流程步驟 7），作為一個明確的驗證維度。
• 其他步驟（參數收集、研究、文案規劃）不需要重新載入 references/taste.md；約束已透過已選擇的預設與語言融入其中。
• 核心目標是移除明顯的 AI 生成設計痕跡。
• 強制約束包括：不允許預設的 Inter 字體、不使用純黑色、不採用預設的置中主視覺、不採用三等分卡片構圖、不使用通用的 AI 文案語氣、不使用虛假的數據。
• 品味不代表空白。請使用 references/taste.md 中的密度規則，讓真實的卡片組至少包含一張有用的資訊卡片，除非使用者明確要求僅製作海報或僅製作電影風格的一組卡片。
• 如果主題預設或設計語言與 references/taste.md 衝突，除非使用者明確要求該被禁止的樣式，否則以品味基準為準。

輸入

收集或推斷：

• content：來源文字、大綱、筆記、網址、主題或簡報。
• ratio：預設為 1:1，除非使用者要求 3:4、9:16 或其他比例。
• count：預設根據內容密度自動計算；接受明確的數量。
• style：接受明確的風格方向、品牌約束、目標對象、情緒與平台。
• content-language：zh / en / mixed。從來源推斷；只有在不明確且會影響字體選擇時才詢問。這會驅動 references/fonts.md 中的語言覆寫設定。
• output：選擇一個清晰的本地資料夾，例如 cards/<slug>/，除非使用者指定其他位置。

如果重要事實可能是即時的或有爭議的，請在規劃前先搜尋或驗證。當研究影響內容時，為使用者保留來源歸屬。請參閱「研究與事實確認」章節，了解何時需要進行完整的深度研究而非快速檢查。

研究與事實確認

在參數收集與設計工作之間插入此步驟，但僅在輸入本身不足以作為卡片內容時執行。

• 當 content 為以下任何一種情況時，觸發深度研究：主題短語、一句話簡報、尚未讀取內容的網址、推文長度的想法、一個問題、或「解釋 X / 涵蓋 X / 製作關於 X 的卡片」的請求。
• 當 content 已經是內容完整的文章、逐字稿、結構化筆記、完整的大綱草稿，或使用者明確希望從這些內容製作卡片（而非關於這些內容）的任何文字時，跳過深度研究。
• 當觸發研究時，請在任何視覺規劃之前產出事實大綱：
  • 核心主張或論點。
  • 3-7 個支援論點，附帶具體數字、名稱、日期或機制。
  • 每個重要事實的來源，附上將收錄於 sources.md 的網址或文件參考。
  • 使用者需要解決的開放性問題或爭議點。
• 將事實大綱呈現給使用者，並在進入主題/設計語言選擇之前請求確認、補充或修正。這是一個獨立於後續概念/視覺確認的確認步驟。
• 此步驟的輸出是「骨架」— 主張與證據 — 而非最終的卡片文案。卡片層級的鉤子、解說與重點將在後續的內容結構化步驟（步驟 5）中，基於已確認的骨架進行撰寫。
• 一旦事實大綱獲得確認，立即將在此收集的來源記錄到輸出資料夾內的 sources.md 檔案中。

觸發範例

在以下情況執行深度研究：

• 「做一組講 MCP 協議的卡片」— 僅有主題，沒有內容。
• 「把這篇文章做成卡片：https://example.com/post」— 在此對話中尚未讀取其內容的網址。
• 「想做一組講 RAG 優化技巧的卡片，重點放在 chunking 上」— 主題 + 角度，但沒有具體論點或數據。
• 「Cloudflare Durable Objects 適合什麼場景？做幾張卡片」— 問題或「解釋 X / 涵蓋 X」的框架。
• 一條推文、標題或一句話的簡報，僅提及主題但未提供任何證據。

跳過深度研究的情況：

• 使用者貼出了一篇完整的文章、部落格貼文、逐字稿或訪談內容（約 500 字以上、內容自足的來源）。
• 使用者提供了結構化筆記、會議記錄、課程筆記，或一個已完成的摘要大綱，其中每張卡片的標題與 2-4 個要點都已經列出。
• 使用者提供了自己完成的文案，並僅要求視覺處理（「把這段話排成卡片」、「美化一下這段文案」）。
• 使用者明確表示「不要查資料 / 直接基於這段寫 / 不要擴展」，不論輸入長度。

邊界輸入

• 簡短摘要 + 野心不匹配 — 例如，200 字的摘要加上「展開成 7 張卡」。摘要過於薄弱無法滿足目標張數，因此觸發研究，並在展開前指出該摘要缺乏證據。
• 文章 + 「再補點最新數據 / 加點案例」 — 僅針對所請求的補充部分執行範圍限定的研究；不要重新研究使用者已撰寫的部分。
• 帶有標題但無證據的項目符號列表 — 例如，「1. 性能更好 2. 更便宜 3. 更安全」。觸發研究以附加具體數字或範例；否則卡片將讀起來像 AI 填充物。
• 文章 + 使用者自身的意見或觀點 — 跳過對來源的研究，但與使用者確認該意見應原樣保留還是重新組織。
• 內容已在此對話中獲取並討論過的網址 — 視為已貼上的內容，跳過研究，但仍將網址寫入 sources.md。

當輸入不明確時，提出一個釐清問題（「這段內容是要直接做成卡片，還是希望我先查資料再展開？」）而不是猜測 — 錯誤的研究決策會浪費使用者的時間或模型的研究預算。

向使用者提問

在概念規劃之前，接近開始時，一次性詢問缺少的生成參數。將「向使用者提問」視為一個可攜帶的決策策略，而非要求呼叫特定工具的要求。不同的編碼代理人會暴露不同的互動原語，因此技能必須在結構化提問工具存在、不存在或被代理人操作模式禁止時都能運作。

• 首先提取 content、ratio、count、theme/style、platform/audience 和 output/constraints 的已知值。
• 在任何有意義的選擇仍然缺失時，在規劃之前要求使用者確認生成參數。即使使用者說「幫我做 / 生成 / 製作 / 直接出圖 / quickly export」也要這樣做；這些短語是要求執行，而不是要求默默地推斷參數。
• 當答案會對輸出產生實質影響時提問。優先順序為：content/source intent、ratio、count、theme/style、platform/audience、output/constraints。
• 預設情況下，最多提出 3 個簡潔的問題。僅當使用者明確想要配置選擇或輸出的風險很高時，才使用最多 5 個問題。
• 對於使用者原始請求中已明確的參數，不要重複提問。
• 僅在使用者明確表示不要問問題或明確批准預設參數時，才跳過提問步驟。在這種情況下，使用預設值並在執行前或執行期間簡要說明所做的假設。

相容性策略

使用當前環境中最佳的可用的提問機制：

• 如果環境支援 ask_user_question、ask question 或類似的原生釐清能力，請使用該原生互動來釐清阻塞性問題。
• 如果環境不支援原生的提問能力，請在一般的對話中直接提問。
• 每次最多問 2-5 個問題。
• 如果缺少的資訊不會阻礙任務執行，仍應提問一次以確認會影響最終輸出的參數。如果用戶已批准預設值或要求不要提問，則做出合理假設並繼續。
• 在最終回應、sources.md 或 credits.md 中明確列出重要的假設。

停止條件

僅在以下情況之一為真時，在生成前停止並提問：

• 沒有可用的 content、主題、網址或來源素材。
• 來源意圖不明確，且選擇錯誤會浪費工作，例如「按原文使用此文字」與「研究並擴展此主題」之間的選擇。
• 所請求的比例 / 平台相互矛盾或無法以單次匯出滿足。
• 視覺方向受到缺失的品牌、法律、無障礙或精確文案限制的約束。
• 研究發現會改變核心主張的爭議事實。

否則，一次性提問以確認有意義的生成參數，然後繼續執行並記錄假設，將它們記錄在 sources.md 或最終回應中。

比例問題

使用以下預設選擇：

• 1:1 正方形卡片，用於一般社群分享。
• 3:4 直式圖文卡片，用於較豐富的文字/圖片貼文。
• 9:16 限時動態、短影音、短影音封面或行動裝置優先的卡片。

當使用者提供時，接受自由格式的比例，例如 4:5、16:9 或精確的像素尺寸。

數量問題

使用以下預設選擇：

• 根據內容自動推薦。
• 3 張卡片：用於緊湊的敘事。
• 5 張卡片：用於標準的解說。
• 7 張卡片：用於更完整的輪播圖。

自動推薦時，選擇能夠涵蓋該想法而不擁擠的最小集合。解說類偏好 3-7 張卡片，公告類偏好 1-3 張卡片。

主題問題

不要直接向使用者公開完整的預設目錄。載入 references/themes/presets.md，以及當視覺方向重要時載入 references/design-languages.md；然後根據內容、平台、目標對象和分享目標，推薦 3-5 個基於情境的風格選項。在內部將使用者選擇的情境映射到最終的主題預設與設計語言組合。

在請使用者選擇風格時，不要只呈現一個推薦選項加上模糊的「或者換一個？」問題。請提供 3-5 個具體選項，每個選項包含：

• 一個簡短、面向使用者的風格名稱；
• 它最適合的情境；
• 一行視覺描述；
• 內部的對應主題預設與設計語言。

使用兩層選擇邏輯，使輸出保持適當且不會總是收斂到少數幾種外觀：

1. 預設推薦層：

   • 根據內容類型、平台、目標對象和分享目標，提供 3-5 個高契合度的風格。
   • 使推薦的集合足夠貼近使用者的任務，以便任何選項都能成功而無需大量返工。
   • 偏好在外觀上有所不同的選項，而不僅僅是名稱上的差異。例如：保守報告、數據海報、社群筆記、雜誌解說、大膽觀點。

2. 變體擾動層：

   • 當使用者未明確指定確切風格時，在相容的風格族系內輪換，而不是始終選擇頂部的預設項。
   • 在相似任務之間，至少改變以下維度中的兩個：主題預設、主要設計語言、修飾符、佈局配方、視覺錨點、表面隱喻或標題構成。
   • 保持擾動在語義上與內容相容。不要使用與主題、平台、無障礙性或事實清晰度相衝突的隨機新奇感。
   • 在概念計畫或 sources.md / credits.md 中記錄最終選擇的組合，以便可以檢查變化。

使用面向使用者的情境標籤，例如：

• 工程資訊圖：對應到 engineering-paper、product-manual 或 porcelain-research。
• 商業簡報：對應到 quiet-report、product-manual 或 porcelain-research。
• 大膽觀點：對應到 bold-editorial、magazine-eink 或 newsroom-paper。
• 社群產品筆記：對應到 social-notebook、magazine-eink 或 bold-editorial。
• 社論 / 雜誌：對應到 magazine-eink、dune-gallery、field-notes 或 kraft-editorial。

對於設計語言的選擇，使用面向使用者的情境標籤，例如：

• 技術性但有設計感：對應到 editorial-artifact + cutaway + annotation。
• 雜誌解說：對應到 image-led-magazine + edge-crop + asymmetric-space。
• 大膽論點：對應到 swiss-po

…（因翻譯限制而截斷）