AO2 FIELD GUIDE · N026 · 內容策略與專業表達
研發專家訪談應追問適用條件、判斷依據與常見誤讀。附訪談準備、問法及核對表，讓編輯保留限制，寫成客戶能理解的技術文章。
- 讀者會遇到的具體問題與判斷順序。
- 可核對的技術主張與原始文件位置。
- 適用條件、失效情境與尚未確定的答案。
- 對外用語、核准人與需要再次確認的項目。
研發專家訪談：別從「請介紹你的產品」開始
這個開場很容易得到功能清單或多年累積的術語，卻沒有讀者使用它們的脈絡。以半導體或電子供應鏈的內容為例，編輯更適合先提出任務：「客戶拿兩種方案比較時，最容易漏掉哪個條件？」再要求專家描述一個可公開的判斷過程。
具體問題能把專家帶回工作順序：先看輸入條件，再看版本、相容範圍與驗證資料，最後才比較功能。文章因此可以教讀者如何判斷，而不只是堆出「高效能、高可靠度、適用多種場景」等無法核對的形容詞。
訪談前先準備一份主張清單與兩個錯誤示例
主張清單是目前打算寫進文章的內容，每一項標記來源、已知條件與疑問。錯誤示例則把可能的誤解具體寫出來，例如「同系列所有型號都支援這項功能」或「通過某一條件測試，就能推論任何現場都適用」。這些不是要引導專家同意，而是請他指出界線。
事前把讀者角色、文章用途與公開範圍說清楚。若專家知道內容是內訓教材，卻不知道後來會放上公開網站，原先的回答未必適合直接使用。涉及客戶、合作夥伴與未公開產品的部分，應先限制採集與公開範圍。
六層追問：從功能走到可使用的知識
| 層次 | 可以怎麼問 | 要留下什麼 |
|---|---|---|
| 問題 | 讀者通常在哪個步驟卡住？ | 角色、任務與決策情境 |
| 條件 | 這個答案需要先知道哪些資訊？ | 必要輸入與適用範圍 |
| 差異 | 什麼改變會讓答案不同？ | 版本、環境與選型分支 |
| 證據 | 哪份文件、測試或紀錄支援這個說法？ | 原始依據與位置 |
| 例外 | 哪一種情況不能照這樣判斷？ | 限制、排除與人工確認條件 |
| 表達 | 如果對採購者解釋，哪句話最容易被誤讀？ | 對外用語與禁止外推的說法 |
這套追問是本文提出的訪談工作方法。NN/g 的利害關係人訪談說明可作為訪談形式參考：用訪談指南帶出重點，保留追問空間；但內部專家的觀點不能代替真正使用者的需求研究。[1]
逐句示範：把「支援整合」問到能寫進文章
以下為 IoT 合作情境示例，並非真實逐字稿。專家說：「這個平台可以跟客戶系統整合。」編輯不宜直接改成「可無縫整合所有系統」。應追問：提供哪些接口？需要客戶提供什麼資料？是否受版本、授權與網路條件限制？哪些工作屬於客製範圍？測試完成的組合有哪些？
假設得到的答案是「可依指定接口評估，需先取得目標系統資料，部分映射要另行確認」，文章就應保留評估條件。讀者需要的下一步是資料準備表，而不是一個更有力的形容詞。訪談的深度，表現在能把承諾縮到正確範圍，同時讓讀者知道如何繼續。
生技製藥合作內容：專業分工先於文字優化
若內容涉及生技製藥夥伴，可以訪談的主題包括資料交接、術語、文件版次、受眾與核對流程。涉及產品功效、臨床、法規狀態或特定認證的主張，則要由該領域具責任的專家與適用正式文件確認。行銷訪談不能把個人解釋轉成產品已獲核准的宣稱。
這裡的重點是建立內容責任。請分別標明誰提供資料、誰判斷專業正確性、誰確認可公開範圍，以及誰核准最終版本。合作夥伴具某領域背景，不等於本文作者或 AO2 已取得相同專業資格，也不代表夥伴替所有文章背書。
訪談後，把原話、解讀與事實分成三欄
| 欄位 | 內容 | 核對方式 |
|---|---|---|
| 專家原話 | 保留必要脈絡與時間位置 | 讓受訪者確認是否記錄正確 |
| 編輯解讀 | 準備給讀者看的說明與例子 | 確認沒有擴大原意或刪掉條件 |
| 事實依據 | 文件、版本、測試條件與核准範圍 | 由責任人核對是否足以支援主張 |
「原話是真的」與「主張已被驗證」是兩回事。受訪者可能描述經驗、推測或尚在開發的功能，編輯必須標記狀態。若有錄音或逐字稿，也要依已確認的使用範圍保存與分享，不能把採訪素材自動當成公開知識。
如何把訪談整理成文章，而不是問答逐字稿？
先按讀者判斷順序重排：問題背景、必要條件、選擇分支、實作步驟、例外與下一步。把專家提到的兩個情境並排比較，讓讀者看懂哪個條件造成不同答案。再用圖表或工作單承接任務，避免只把口語修得更順。
交付專家核對時，附上「主張—來源—文章段落」對照，並標出與原話有較大改寫之處。需要他確認的是內容邊界與依據，而不是要求他替所有標點符號負責。這也呼應 Johnny Wu 公開分享中對 PM、研發、行銷與業務責任分工的關注。[2]
可帶進會議的訪談卡：一次只核對一個關鍵判斷
| 階段 | 提問與記錄 |
|---|---|
| 開場 | 這篇要幫誰做哪個判斷？本次哪些資料可以公開？ |
| 還原 | 請描述一個可使用的情境；先確認什麼，再確認什麼？ |
| 反例 | 如果缺少某個條件，原答案還成立嗎？ |
| 取證 | 請指出文件位置、有效版本與尚未確定的內容。 |
| 表達 | 這句白話改寫是否保留限制？哪個字可能造成誤解？ |
| 收尾 | 列出待補資料、核准角色與文章回看範圍。 |
訪談時可用「我先重述一次」檢查理解。例如：所以這項功能不是所有組合都具備，需要先確認配件與版本；文章應把準備條件放在功能說明旁邊，這樣理解是否正確？讓專家修正這段重述，通常比只問「還有什麼補充」更能抓到界線。
若專家提供真實案例，另外確認名稱、資料與結果可否公開。即使不公開客戶，也要確認匿名內容是否仍可能辨識專案。無法使用案例時，可以保留判斷方法，再另建標明虛構的示例，兩者不能混成一段看似真實的故事。
會後交付三份內容：供查核的原始紀錄、供文章使用的主張表，以及待辦清單。原始紀錄保存依已確認範圍處理；公開文章則只引用核准內容。這能讓下一次更新有依據，而非重新訪談一次。
常見問題
專家很忙，只有短時間可以訪談怎麼辦？
先把文件讀完，整理主張、來源位置、矛盾與待確認項，讓訪談聚焦少數會改變結論的問題。可請專家逐項確認成立條件、常見誤解與不適用情況，記錄其回答對應哪個版本。會後回傳精簡核對表，而非要求他重讀整篇草稿。缺少答案的部分列待辦，不自行補成產品事實；這能讓有限時間用在只有專家能確認的判斷上。
兩位專家說法不同，要在文章裡選哪個？
先核對談的是不是同一產品、版本、測試條件與使用情境。把兩種說法與依據並列，請對應責任人確認差異；若仍衝突，交有權核准的角色裁決，暫停爭議主張。編輯不按資歷、職稱或語氣強弱選答案。核准後保存決定與適用範圍，回寫主檔並檢查圖表、FAQ 與其他素材，避免正文修正後仍留兩套說法。
可否請 AI 根據訪談補上缺少的技術說明？
可協助列出缺口、整理用語與提出追問，不能把推測寫成專家經驗。每項新增技術主張應對應已核准來源或再次請專家確認；草稿中可標示待查，不要先放進正式版本。保存訪談紀錄、編輯摘要與補充依據，讓審查者看出哪些是受訪內容、哪些是後續研究。語句合理或另一篇網路文章提過，仍不代表適用這個產品。
相關閱讀與下一步
了解對應 AO2 服務，或帶著目前的資料與工作問題，先確認適合開始的範圍。
參考資料與查核範圍
資料查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台規則；工作表、決策流程與虛構示例為本文整理。Johnny Wu 的公開分享作為作者工作觀點來源，未以此推定客戶成果或產品資格。
