AI 整理使用者訪談錄音需求主題：用 FoneClaw 建立原句與反例證據矩陣

先定義交付物：可回查的主題矩陣與研究問題

用 AI 整理使用者訪談錄音需求主題，建議交付的不是一段流暢總結，而是一份可回查的證據矩陣，加上一份尚待確認的研究問題。先縮小問題，例如「使用者如何把預約後的資訊留到之後使用」，再選取至少兩筆已獲同意、保存於 FoneClaw 的訪談錄音分析。

我們的 FoneClaw Voice Notes 語音紀要可將保存的錄音組成合集，重用既有逐字稿供提問與整理。本篇示範的是你可以採用的質性分析方法；矩陣是經人工核對的研究工作文件，不是產品內建的專業研究編碼平台，也不是我們已完成的使用者研究。

動手前，先約定三種文字的界線：

• 原句：保留受訪者實際說法，使用引號，並能回查正確來源。
• 改寫：研究者用較短文字重述意思，清楚標示為改寫，不冒充逐字引文。
• 分析者推論：從材料提出的可能解釋，例如「可能重視控制感」，仍需其他證據支持。

這個區分能避免「受訪者提到日期漏掉」在整理後變成「使用者要求自動建立提醒」。前者是材料中的陳述，後者已跨到解法假設；即使文字合理，也不能省略中間的推論。

選取獲准使用的錄音，先把來源標籤整理好

先確認同意範圍涵蓋錄音、處理方式、研究用途與預計分享對象。只選本次問題需要、且允許使用的內容；同意錄音，不應直接解讀成同意任意上傳、公開引文或轉作其他研究。需要整理告知流程時，可參考Android AI 會議錄音同意：從錄音告知、逐字稿到確認後續行動，再依實際訪談情境確認。

在相容 Agent 中，Voice Notes 支援錄音、暫停、繼續、保存與命名，並產生逐字稿、摘要及章節。建立合集前，先檢查每筆原音與逐字稿是否可用；合集須選取至少兩筆已保存錄音，會重用它們既有的逐字稿。完整來源選取操作可查FoneClaw 錄音合集專案回顧：從多次會議整理決議、變更與待辦，本篇則聚焦訪談證據與主題。

用 I01、I02、I03 這類自行指定的中性標籤，搭配訪談日期與主題命名。若研究確實需要身分對照，將對照表另外保管；錄音標籤不等於人名，說話者標記也不代表系統已驗證真實身分。同一人有多次訪談時，另行記清對應關係，避免把錄音筆數誤算成人數。

Voice Notes 是免費外掛，但需要相容 Agent、麥克風權限及適當設定；Full APK 的外掛支援受設定與權限影響，Play Lite 不安裝 APK 外掛，詳見FoneClaw Agent 功能與版本說明。外掛免費不代表所有 Agent 或模型處理皆免費，也不保證 AI 全程離線。這裡的流程以外掛內保存的錄音為起點，不應假設任意外部音檔、PDF 或其他服務的資料都能直接匯入。

三段虛構訪談：日期、確認與找回筆記

以下三段完全是為了說明分析方式而編寫的虛構材料，不是真實受訪者資料、錄音內容或 App 實際產出。虛構情境都是一般預約結束後的資訊整理，不涉及任何真實人物。

• 虛構 I01，談到轉抄資訊：「預約談完後，我會把提醒抄到另一個地方，但有時候日期就漏掉了。」
• 虛構 I02，談到保存前的判斷：「可以先幫我列出提醒，但我要看過內容和日期，才決定要不要存。」
• 虛構 I03，談到日後查找：「我不想再多一個提醒，我只要之後找得到原來那則筆記。」

先貼近材料命名，可能得到「轉抄時日期遺漏」、「保存前確認」和「原筆記找回」三個暫定主題。這些名稱是分析者整理出的標籤，不是受訪者原句。

如果再往上歸納成「對後續資訊的控制與可追溯性」，就應標示為分析假設。I02 的條件是先看過再決定；I03 更明確拒絕增加提醒。不能因為三段都談到預約後續，就把它們合併成「三人都需要自動提醒」。

真實訪談往往比這些短句複雜。保留提問方式、受訪者所指的工具，以及前後的修正，才知道一句話是在描述既有行為、提出偏好，還是回答研究者假設的情境。

把原句連到主題，並列出解讀與相反案例

下表只依上述虛構材料示範。來源情境是人工註記，不是自動生成的時間引用；正式研究時，請改填實際錄音名稱，以及自己核對後記下的段落位置或上下文。手機上可逐欄查看，重點是不要把來源與解讀混在同一格。

表中的短引文逐字取自前面的虛構原句；「可能造成資訊不完整」則是推論，不能加上引號偽裝成受訪者發言。若要把外語發言翻成中文，請另標譯文並保留原語句，不能把翻譯或改寫當成逐字原文。

真實矩陣每一列都要回查逐字稿與原音，尤其是「不」、「只要」、「有時候」及「才」等會改變意思的詞。找不到支持某個主題的原句，就寫「引文待查」或「目前無直接證據」，不要為了填滿表格而補出合理台詞。

限定所選來源提問，再逐列核對分析

確認合集中的錄音與標籤後，可以用一個範圍明確的要求開始整理。以下是可修改的提問範本，不是受訪者引文；請把標籤與研究問題換成自己的實際資料：

「請只根據本次選取、標記為 I01、I02、I03 的訪談，整理『預約後如何保留並使用資訊』的可能主題。每個主題列出來源錄音標籤、可找到的原句、情境、改寫、分析推論、相反案例與待確認問題。只有來源確實存在的文字才能放進引號；沒有直接引文或來源不確定時，明確標記待查。不要合併不同人的發言，也不要補寫姓名、負責人、期限或功能承諾。結論只限這批材料，不推估所有使用者的偏好。」

得到回答後，不要只看主題名稱是否順眼。逐列打開相應來源，確認引文是否屬於同一位受訪者、前後是否有轉折，以及提問本身是否引導了答案。若某列同時引用兩筆錄音，就分別檢查，不能用其中一筆替另一筆背書。

逐字稿若先前有誤，應先回聽處理，再於研究工作筆記記下修正與理由；確認來源內容後，重新提出限定範圍的問題。不要假設先前生成的矩陣會自動更新，也不把另外保存的修正紀錄稱為產品內建版本歷史。

如果單筆錄音的文字或說話者區分還沒整理好，先回到Android AI 錄音轉寫摘要：快速錄音、逐字稿校正與筆記整理完成基礎核對，再做跨訪談比較。來源尚未可靠時，增加分析文字不會補足證據。

保留反例，不把需求假設寫成普遍結論

回到虛構案例，「所有人都想自動保存提醒」沒有材料支持。較合適的寫法是：在這三段虛構材料中，I01 提到轉抄時可能漏掉日期，I02 希望先檢查再決定是否保存，I03 則不想新增提醒，只希望找回原筆記。三種說法指向不同問題，尚不能收斂成同一項功能需求。

下一層可以提出假設：「資訊完整性、保存前控制，以及日後回查，可能是不同使用情境下的考量。」再列研究問題：「哪些情境需要新增提醒，哪些只需要保留可找回的紀錄？」這樣保留了值得追查的方向，也沒有把假設寫成已確認事實。

相反案例不是應該刪掉的雜訊。虛構 I03 直接限制了「提醒越多越好」的解讀；若把這一列移走，剩下的矩陣會顯得一致，卻改變了材料原貌。同樣地，受訪者沒談某件事，不等於他反對它；沒有問到的內容應留為未知。

計數也要有界線。同一人在一次訪談中重複五次，不是五位獨立使用者；選了幾筆錄音，也不能換算成市場偏好比例。這裡的三個案例只是示範數量，不構成普遍性、因果關係或市場規模的證據。即使真實訪談已完成核對，需求假設與後續提問仍不等於核准功能、優先順序或產品承諾。

處理來源錯誤，最後只選一項後續行動

交付前，先針對錯誤類型處理，不要只是要求 AI「寫得更有把握」：

• 錄音選錯或標籤重複：重新確認合集選取與標籤對照，修正後再分析。
• 原音缺漏或轉寫未完成：先處理來源可用性，暫停以該段支持結論；不能用生成文字補回沒錄到的話。
• 逐字稿與原音不符：回聽相關片段，記下修正；聽不清楚就標記未知。
• 引文找不到或被改寫：撤下引號，改列為推論或待查，不讓它留在原句欄。
• 兩人發言被合併：拆回各自來源，重新檢查每人的條件與否定。
• 相反案例消失：回到所選材料補查，並縮小原來過度概括的結論。

最後保留三份清楚的成果：已核對的證據矩陣、仍缺資料的問題清單，以及一項你選定的研究後續行動。例如，先準備一題追問，釐清什麼情境需要提醒、什麼情境只要找回筆記，而不是立即把所有主題變成功能待辦。

若你明確要求建立受支援的個人待辦，請另外提出要求，確認帳戶與儲存位置；有確定日期才填日期，沒有就保留未排程，並查看實際保存的紀錄。可參考Android AI 待辦沒有日期：安全保存與改期，避免為研究問題擅自加上期限。

整理訪談不會自動替團隊指派工作、寫入 CRM、聯絡受訪者或分享材料，也不代表已建立研究儀表板。原始錄音、逐字稿、人工核對的矩陣與後來取得的確認，應維持可分辨的來源關係。這份矩陣的價值，是讓每個主題知道憑什麼成立、受到哪個案例限制，以及下一步還需要問什麼。