知識漫畫改稿 QA 紀錄｜四格分鏡、文字密度、手機預覽與輸出版本

知識漫畫很適合把一篇技術筆記、維護流程或工具教學變成可分享的內容。但實作時最常出現的問題，不是畫風不夠漂亮，而是「每一格到底要讓讀者理解什麼」沒有被驗證：文字太密、主角視線不清楚、手機縮圖看不出重點、社群版本與 Blog 版本檔名混在一起。

因此我會把知識漫畫改稿當成一個小型 QA 流程，而不是單純的美術修圖。每一次改稿都要留下 observe / change / verify 紀錄，讓下次把文章改成漫畫、短片或社群輪播時，可以回頭知道哪些判斷已經確認過。

先確認四格各自的任務

四格漫畫不需要每格都塞滿資訊。比較穩的節奏，是把每格拆成一個可檢查任務：情境、問題、方法、結論。

Four-panel purpose map
- panel 1: reader situation / pain point
- panel 2: wrong assumption or visible symptom
- panel 3: practical method or command evidence
- panel 4: result, lesson, next reusable asset

如果某一格同時想講背景、工具、指令與結論，代表它其實應該拆成兩格，或改成 Blog 內文而不是漫畫台詞。漫畫負責讓讀者快速抓到脈絡，詳細指令與表格則留在文章中承接。

文字密度要用手機預覽判斷

桌機上看得清楚，不代表手機上可讀。知識漫畫常被丟到 LINE、Threads、Instagram 或簡報截圖裡，最小可讀尺寸才是真正的驗收標準。

我會用這種方式記錄文字密度：

Text density check
- title: readable at mobile card size
- speech bubble: max 2 short lines per bubble
- annotation label: keep to 4-8 Chinese characters
- no paragraph-like copy inside panels
- important keyword appears once, not repeated in every panel

如果一個對話框需要三行以上才說清楚，通常可以改成「短句 + 文章補充」。例如把「我們需要先比對文章 canonical、sitemap 與 OG image 是否一致」改成「先比對 canonical / sitemap / OG」，細節放在旁邊的驗收清單。

改稿紀錄要分成 observe / change / verify

改稿最怕只留下「已修正」三個字。等到下一次換尺寸或重做縮圖，沒有人知道當時改了什麼，也不知道是否真的驗證過。

Comic revision log
Observe
- panel 2 text is readable on desktop,
  but too dense at 390px mobile preview
- export file name mixes draft and final versions

Change
- shorten panel 2 bubble to two short lines
- move detailed command to Blog article body
- rename export files with date and channel

Verify
- mobile preview: title and bubble remain readable
- Blog card: cover image matches article topic
- social crop: no key character or label is cut off

這份紀錄不需要很長，但要能回答三件事：改稿前看到什麼、改了哪個檔案或文字、改完後如何確認。對內容團隊來說，它比單純保存一堆 final-final-v3.png 更有用。

檔名與版本要讓素材能回收

知識漫畫通常不只輸出一張圖。可能會有 Blog cover、文章內圖、社群輪播、短片開場、簡報截圖。若檔名沒有規則，半年後要回收成短片素材時會非常痛苦。

一個可讀的命名方式可以像這樣：

2026-08-21-knowledge-comic-qa-cover.png
2026-08-21-knowledge-comic-qa-carousel-01.png
2026-08-21-knowledge-comic-qa-carousel-02.png
2026-08-21-knowledge-comic-qa-mobile-preview.png

重點不是格式一定要完全相同，而是檔名要包含日期、主題、用途與序號。若有多個語言版本，也應該在檔名裡標示 zh-tw、en 或目標平台，避免上線時拿錯版本。

Blog 文章要承接漫畫沒說完的細節

知識漫畫的目標不是取代文章，而是讓讀者願意進一步閱讀。Blog 文章可以補上漫畫無法承載的內容：完整流程、指令輸出、表格、判斷理由、錯誤案例與下一步行動。

我會在文章裡放三種承接內容：

原始問題：這篇漫畫從哪一篇技術筆記或維護案例拆出來。
驗收證據：手機預覽、輸出尺寸、裁切範圍與檔名規則。
回收方式：未來可以如何改成短片腳本、社群輪播或簡報素材。

這樣做的好處是：漫畫提供入口，文章提供可信度，素材庫提供長期可重用性。

上線前的最小驗收清單

每次發布知識漫畫前，我會至少檢查這幾項：

四格順序是否從情境走到結論。
每一格是否只有一個主要訊息。
手機寬度下標題、對話框與註解是否可讀。
Blog cover 是否與文章主題一致，不是泛用圖片。
Open Graph 圖片是否能代表文章，而不是只顯示抽象背景。
輸出檔名是否包含日期、主題、用途與版本。
社群裁切後，人物、標題與重點標籤是否沒有被切掉。
文章內是否有足夠的文字說明承接漫畫。

知識漫畫做得好，會變成技術內容的入口；做得不好，則只是把原本清楚的文章壓縮成難讀圖片。把改稿 QA 留成紀錄，可以讓創意內容和網站經營連在一起：每一次輸出不只是完成一張圖，而是增加一份未來能搜尋、能回收、能再次改編的內容資產。