昨天把「使用手冊要長什麼樣」的規格問題列出來了，也從手工流程推論成三個自動化階段。今天要往前推一步：在真的開始比較工具之前，根據實際情況，先把「工具要滿足哪些條件」定清楚。

認識產品

首先，最重要的是需要認識這個產品 (i.e. 使用手冊介紹對象)。產品本身的特性會決定使用手冊內應該有哪些內容，也會影像後續工具的選擇。

我希望自動化撰寫的使用手冊的介紹對象，是一個由 Electron 所製作的桌面應用程式。它背後是一個 AI 智慧監控系統，因此會有許多設定頁面，以及即時影像串流畫面。

不過，我也不可能直接拿公司的產品做 Demo，因此，這系列示範撰寫使用手冊的對象，是我請 AI 生成的一個簡單版 Electron 桌面應用程式專案，會盡量涵蓋到各種使用情境。除了方便說明，也方便大家自己拿去玩玩看。沒意外的話，我會在後面的文章中，找一天來簡單介紹一下這個範例專案內有什麼功能。

這邊有一點值得先提一下：Electron 桌面應用程式本質上就是一個 chromium 瀏覽器再加上一個網頁。因此，它對於各種瀏覽器工具與網頁技術的相容性很高，在後面工具的選擇上會有更多選項。

後續的選擇確實與這點有關 (這應該不算暴雷吧🤔?)，所以，如果各位讀者的目標產品是原生開發的桌面應用 (不是用 Web 技術包起來的)，後面的工具選擇邏輯也需要重新推導。

工具要求

沒有最完美的工具，只有最合適的工具。大家面臨的狀況肯定都會有所差異，因此，我們需要在一開始就先決定好，我們對這個工具有哪些必要的需求 (i.e. 硬需求)，以及哪些可以被妥協的需求 (i.e. 軟需求)。

對於使用手冊，我有兩個硬需求：

1. 要有截圖

   我知道這聽起來很像廢話，但對於沒有 GUI 介面的工具，有沒有截圖的影響並不大，通常文字說明就夠了。不過，這次我需要撰寫說明的產品，是一個有 GUI 的桌面應用程式，使用手冊必須簡單到可以「讓使用者看畫面對照著操作」，所以截圖是必須的。

2. 要有 Word 檔

   在某些情況下，我們會希望可以讓工程師以外的人也可以查看與修改使用手冊 (e.g. 代理商可以修改部分內容、業務可以拿部分內容做簡報)，此時 Word 檔就會是最普遍也最方便的選擇。

   我覺得必須支援存成 Word 檔是限制最大的點，如果可以降低一點標準，變成只要可以存成 PDF 檔，那在很多地方都會更有彈性，困難度也下降許多。這部分後面會再找機會回來討論。

接下來，則是非必要但我希望能滿足的軟需求：

1. 截圖可以標註

   當畫面比較複雜時，通常需要用紅框、編號等方式，來幫助使用者理解操作步驟中對應的元件位置與功能。這個標註不需要是可以編輯的，可以直接繪製在截圖上方就好。

   當然，如果可以編輯會更好，但其實我個人不太喜歡用 word 的圖形工具或文字方塊來標註，常常一個不小心就跑版，維護起來不太方便。所以，我傾向直接把標註繪製在截圖上，省去之後還需要再三確認是否有跑版的麻煩。

2. 文字說明可以用 markdown 文件管理

   markdown 只是個人偏好，如果要改用 yaml、json、toml 或其他純文字格式也是可以的，重點是在「純文字」這件事本身。這個需求有兩個主要目的：第一個是可以用簡單的文字編輯器 (e.g. VS Code) 查看文字內容，第二個是使用 git 做版本控制時，能輕鬆看出版本差異，這對於後續追蹤「這次改版動了哪些章節」非常重要。

一點小提醒

在今天文章的最後，分享兩個小提醒。在整理需求的時候，可以去好好思考這個需求到底是不是硬需求，說不定其實是有討論空間的 (e.g. 在某些情況下可以妥協)。例如：也許在某些小型專案中，使用手冊主要是工程師在看而已，只需要用 PDF 就好，或甚至可以直接給對方 markdown 檔，讓對方可以直接給他們自己的 AI Agent 查看。

另外，「Electron 本質上就是瀏覽器」這件事，其實也很容易在認識產品的階段被忽略，畢竟表面上看起來就是一支桌面應用程式。但這個特性會直接影響到後面能選的工具範圍，算是一個「看起來是 A，但本質上其實是 B」的例子，值得在盤點產品特性時多留意類似的線索。

把軟硬需求都盤點清楚之後，明天就要正式進入「工具怎麼選」的環節了，敬請期待！