300 則問卷怎麼整理？用 AI 建立可追溯的開放式回饋編碼表

10月 23, 2026

原內容日期：2026-09-16。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

300 則意見，為什麼不能直接叫 AI 摘要？

當問卷或客服紀錄累積到幾百則，最直覺的做法是全部貼給 AI，要求整理五大重點。

結果通常讀起來很合理，卻不一定可靠。最長、最激烈或最容易理解的留言可能被放大；少數但涉及財務、法規或無障礙的問題可能被埋掉；不同角色的矛盾需求，也可能被 AI 改寫成看似一致的共識。

真正可用的分析，不只要有摘要，還要能回答：這個結論來自哪些回饋？有多少人提到？分母是什麼？是否有反例？原因是證據還是推測？

先建立編碼本，再分析全部資料

編碼本是一組穩定的分類規則。每個代碼不只是一個名稱，還要有定義、納入規則、排除規則、正例與反例。

例如「操作不便」太模糊，可以拆成「送件回應狀態不明」「退件原因不足」「鍵盤焦點不清」等可驗證問題。如此一來，不同分析者或不同月份才有機會使用一致標準。

實務上可先抽取 20 至 50 則代表性資料，建立初版編碼本，再請熟悉業務的人校準。定版後才處理全部資料。中途發現新現象時，先列為候選代碼，不要悄悄改規則。

一則回饋可以有多個標籤

「附件上傳一直失敗，退件後也看不懂原因，只能打電話問財務」同時包含介面、流程與支援問題。

如果硬選單一分類，分析會遺失資訊。比較合適的做法是先切分意義單元，再允許每個單元有有限數量的多標籤，同時保留原始回饋編號。

觀察、影響、原因與方案要分開

使用者可能會說：「系統太慢，應該是伺服器不夠，請換主機。」

其中只有「等待時間長」是直接觀察；「伺服器不夠」是原因假設；「換主機」是解決方案要求。三者不能被 AI 合併成「伺服器容量不足已確認」。

先把層次分開，團隊才能選擇正確驗證方法，例如查日誌、量測反應時間或比較不同網路情境。

提及數、人數與分母不能混用

同一位使用者可能在三個地方反覆提到相同問題。這表示問題對他很重要，但不代表三位不同使用者都遇到。

報告時應盡可能同時提供提及數、獨立回覆者數、有效回覆者分母及占比。例如 8／40（20%） 比單寫「20% 使用者」更透明。

若資料沒有匿名回覆者編號，只能報告提及數，不能聲稱有多少人遇到。

高頻與高風險是兩件事

大量使用者希望按鈕更方便，可能值得改善；但只有一位使用者指出鍵盤無法辨識焦點，也可能代表特定族群無法完成核心任務。

因此頻率之外，還要檢查任務阻斷、資料錯誤、財務損失、法規、資安、安全及無障礙。嚴重度標準應由組織定義，不應交給 AI 自行宣布。

矛盾不是雜訊，而是設計條件

主管希望批次核准以節省時間，財務則擔心逐筆查核被跳過。這不是誰對誰錯，而是揭露了效率與控制之間的設計條件。

報告應並列雙方證據，說明各自適用情境，再提出可驗證的折衷方案，例如只對低風險項目開放批次操作，高風險費用仍逐筆核准。

好的分析最後會回到驗證

AI 整理出主題後，下一步不是立刻開發所有功能，而是替每個候選改善安排最低成本驗證：查 30 筆日誌、訪談 5 位特定角色、做 5 人可用性測試，或用原型比較兩種流程。

最終報告應清楚分開資料支持的發現、尚未證實的假設、候選方案與正式決策。

AI 整理回饋，人類負責邊界與判斷

AI 可以加速切分文字、套用代碼、統計提及與找出矛盾，但資料範圍、分類邊界、風險標準、隱私保護及改善優先序仍需要人類負責。

開放式回饋的價值，不在於把三百句話壓縮成三句漂亮摘要，而在於讓團隊知道每個結論從哪裡來、還不知道什麼，以及下一步如何用最小成本驗證。

文章 CTA： 收藏文中的完整提示詞，下次收到問卷或試用回饋時，先用 30 則建立編碼本，再處理全部資料。

逐步操作

步驟 1：先定義這次分析要回答的問題

不要只寫「請分析回饋」。改成可回答的問題，例如：

哪些問題阻止使用者完成報帳？
哪些問題只是偏好，哪些會造成錯誤或合規風險？
哪些主題值得下一輪訪談？
哪些改善可以先小規模驗證？

一次保留一個主要問題，最多三個次要問題。問題太多，分類會彼此混雜。

步驟 2：固定資料範圍與分母

記錄：

蒐集期間
對象與管道
邀請人數
實際回覆人數
有效文字回覆數
同一人是否可能提交多次
本次包含與排除的資料

如果不知道分母，必須標示「無法計算代表性」，不要自行估算。

步驟 3：替每筆資料加上穩定編號

建議欄位：

回饋編號｜回覆者匿名編號｜日期｜角色群組｜使用情境｜原始內容｜來源

範例：F-017｜U-009｜2026-09-08｜一般同仁｜手機送件｜發票上傳後一直轉圈｜試用問卷

後續所有判讀都必須能回到回饋編號。

步驟 4：先去識別化，不要直接貼原始名單

移除或替換：

姓名、Email、電話與員工編號
客戶、供應商與專案代號
地址、帳號、訂單號與付款資訊
健康、績效、申訴或人事敏感資訊
內部網址、權限資訊與系統畫面中的機密資料

需要區分族群時，用必要的角色群組即可，例如「主管」「一般同仁」「財務覆核」，不要保留可重新識別個人的組合。

步驟 5：抽取一小批資料建立初版編碼本

先抽 20 至 50 則，或總量的 10% 至 20%，確保包含：

常見意見
很長與很短的回答
正面、負面與中性回答
不同角色與情境
看似矛盾或難分類的回答

不要一開始就讓 AI 對全部資料自由發揮，否則分類容易重疊、漂移或過度細碎。

步驟 6：讓每個代碼都有邊界

每個代碼至少包含：

欄位	說明
代碼	簡短穩定名稱，例如 `流程_退件原因不清`
定義	這個代碼代表什麼
納入規則	什麼情況要標記
排除規則	容易混淆但不屬於此代碼的情況
正例	應納入的原句
反例	不應納入的原句
上位主題	流程、介面、權限、資料、支援等
風險屬性	便利、效率、錯誤、阻斷、合規、資安、無障礙等

如果兩個代碼沒有清楚差異，先合併；如果一個代碼包含多個完全不同問題，再拆分。

步驟 7：允許多標籤，但限制標籤數

一則回饋可能同時包含多個問題：

手機上傳發票常失敗，退件後也看不到原因，只能打電話問財務。

可同時標記：

介面_附件上傳失敗
流程_退件原因不清
支援_需人工查詢

建議每則最多 3 至 5 個主要代碼，避免什麼都標而失去判讀力。若一段包含多件事，先切成「意義單元」，並保留原回饋編號。

步驟 8：分開四種內容

同一句話常混合不同層次，請分別記錄：

觀察／經驗： 使用者實際遇到什麼。
影響： 因此多花時間、犯錯或無法完成什麼。
原因假設： 使用者或分析者推測為什麼發生。
解決方案要求： 使用者希望怎麼改。

例如「系統太慢，應該是伺服器不夠，請換主機」：

觀察：操作等待時間長。
影響：送件耗時。
原因假設：伺服器容量不足，尚未驗證。
方案要求：更換主機，尚未評估。

步驟 9：用人工校準一小批結果

請兩位熟悉業務的人各自標記同一批 20 至 30 則，再比較：

哪些代碼一致？
哪些代碼常被混淆？
是否需要補充納入與排除規則？
哪些回饋確實無法判讀？

不必追求假裝精準的分數；重點是把分歧變成更清楚的規則。若只有一位審查者，也至少保留一輪「隔天重看」與抽樣複核。

步驟 10：鎖定編碼版本，再處理全部資料

將初版修正為 編碼本 v1.0，記錄：

生效日期
變更內容
合併或拆分的代碼
受影響的既有資料

大量資料可分批處理，但每批都要使用同一版本。發現新主題時先標記 候選新代碼，不要在中途悄悄改規則。

步驟 11：計算時同時看「提及數」與「人數」

至少分開：

意義單元提及數
涉及的獨立回覆者數
占有效回覆者比例
各角色或情境的分布

同一人重複提及三次，不應自動當成三位使用者。若無匿名回覆者編號，只能報告提及數，不能聲稱有多少人遇到。

步驟 12：頻率與嚴重度分開判斷

高頻不一定最嚴重，低頻也不一定不重要。建議檢查：

發生頻率
是否阻止核心任務
是否造成資料錯誤或金錢損失
是否涉及法規、資安、無障礙或安全
是否有替代方式
影響是否集中在特定角色
證據是否足夠

嚴重度必須依組織定義，不要讓 AI 自行宣布「重大」。

步驟 13：主動找反例、矛盾與沉默族群

例如多數人希望自動帶入資料，但部分財務人員擔心沿用錯誤內容。報告不能只寫「大家希望自動帶入」，應同時呈現：

支持意見
反對或附帶條件
哪些角色沒有回覆
哪些情境沒有被資料涵蓋

沒有留言不代表沒有問題，也不代表滿意。

步驟 14：把洞察連到最低成本的下一步

每個優先主題至少對應一個動作：

再訪談 5 位特定角色
查系統日誌或客服紀錄
做 5 人可用性測試
用原型比較兩種流程
補量等待時間或錯誤率
先修正文案，再觀察退件率

先驗證問題與原因，再決定完整解法。

步驟 15：發布前做人工審查

確認：

數量與分母正確
引句未改變原意
低頻高風險項目未被省略
推測未寫成根因
少數群體未被不必要地識別
改善方案尚未被誤寫成正式承諾
對外版本沒有暴露內部或個人資訊

可直接複製的完整提示詞

將中括號內容替換成你的資料。第一次建議只貼代表性樣本，確認編碼本後，再分批處理完整資料。

【角色】
你是一位謹慎的質性研究與營運改善分析助理。你的任務是協助建立可重複、可追溯的開放式回饋編碼流程。你不能替使用者發明事實、推測個人動機、診斷根因或宣布正式改善決策。

【主要任務】
分析下方去識別化回饋，建立或套用主題編碼本，保留每項判讀的回饋編號與最短必要證據原句，並將觀察、影響、原因假設及解決方案要求分開。最後提出需要驗證的問題與低成本下一步，不得把建議寫成已核准承諾。

【本次分析目的】
- 主要問題：[例如：找出阻止員工完成行動報帳的主要問題]
- 次要問題：[例如：辨識低頻但涉及錯帳、個資或無障礙的風險]
- 使用者／決策對象：[例如：產品負責人、財務主管、專案經理]
- 分析期間：[YYYY-MM-DD 至 YYYY-MM-DD]
- 資料來源：[試用問卷／訪談／客服／其他]

【母體與分母】
- 受邀人數：[數字／未知]
- 實際回覆人數：[數字／未知]
- 有效文字回覆數：[數字]
- 是否可能重複提交：[是／否／未知]
- 回覆者匿名編號是否可用：[是／否]
- 已知未涵蓋族群：[角色或填未知]

【業務背景】
- 流程或服務：[簡述]
- 核心任務：[使用者必須完成的工作]
- 已知限制：[政策、技術、權限、時程；未知請填未知]
- 嚴重度定義：[組織既有定義；沒有則填無，請勿自行創造]
- 既有編碼本版本：[無／vX.X，若有請貼上]

【輸入資料格式】
每列一筆原始回饋：
回饋編號｜回覆者匿名編號｜日期｜角色群組｜使用情境｜原始內容｜來源

規則：
1. 回饋編號必須唯一。
2. 無資料請填「未知」，不要留白讓你猜測。
3. 如果一則包含多個議題，可拆成意義單元，但必須保留原回饋編號並新增 .1、.2。

【回饋資料】
[貼上去識別化資料]

【分析規則】
1. 僅根據提供的資料判讀，不補寫未提供的背景、比例、原因或人物意圖。
2. 保留原始回饋編號；證據原句只能節錄支持該判讀的最短必要片段，不得改寫成更強烈的說法。
3. 分開「觀察／經驗」「影響」「原因假設」「解決方案要求」。受訪者提出的原因仍標示為假設。
4. 每個意義單元可有多個代碼，但主要代碼最多 [3] 個；無法判讀時標示「待釐清」。
5. 若建立新編碼本，每個代碼必須包含：代碼、定義、納入規則、排除規則、正例、反例、上位主題及風險屬性。
6. 代碼名稱應互斥到足以操作，但允許同一意義單元多標籤；避免只用「其他」吸收大量內容。
7. 如果提供既有編碼本，先套用既有代碼。新現象列為「候選新代碼」，不得直接改寫正式版本。
8. 不得以情緒字眼自動推定嚴重度，也不得用正負面情緒代替問題分析。
9. 分開「提及數」與「獨立回覆者數」。沒有匿名回覆者編號時，只能計算提及數。
10. 所有比例都要顯示分子與分母，例如 8／40（20%）。分母未知時不得計算百分比。
11. 不得把樣本結果外推為全公司、全部客戶或所有使用者的意見。
12. 主動找出矛盾意見、反例、附帶條件、缺席族群與資料涵蓋缺口。
13. 低頻但涉及安全、法規、資安、個資、財務、無障礙或核心任務阻斷的內容，另列人工審查；不得僅因低頻而忽略。
14. 不得依姓名、職稱或寫作風格推測身分、個性、績效、健康、情緒狀態或惡意。
15. 不得產生針對個人的評分、排名或人事建議。
16. 改善構想必須標示為候選方案，並說明需要驗證的假設、成功訊號與可能副作用。
17. 若資料互相矛盾，並列呈現，不自行選一個當真相。
18. 若資料量過大，先回報可處理範圍與建議分批方式，不得假裝已讀取全部內容。
19. 使用繁體中文，語氣中性、具體、尊重，不責怪回覆者或執行團隊。
20. 所有對外引用與行動決定都需人工確認。

【輸出格式】

一、資料完整性檢查
- 實際讀取筆數
- 唯一回饋者數（可計算時）
- 重複或缺號
- 缺少欄位
- 可否計算比例
- 可能偏誤與未涵蓋族群

二、主管摘要
限 180 字，說明最常見問題、低頻高風險訊號、最重要的資料限制，以及建議先驗證的事項。避免使用「大家都」「普遍認為」等無法由資料支持的詞。

三、編碼本
| 代碼 | 定義 | 納入規則 | 排除規則 | 正例編號及短句 | 反例編號及短句 | 上位主題 | 風險屬性 |

四、逐筆編碼表
| 意義單元編號 | 回饋編號 | 回覆者匿名編號 | 原始內容短句 | 觀察／經驗 | 影響 | 原因假設 | 方案要求 | 主要代碼 | 次要代碼 | 信心 | 待釐清 |

五、主題統計
| 主題 | 提及數 | 獨立回覆者數 | 分子／分母 | 占比 | 涉及角色／情境 | 代表性證據編號 | 資料限制 |

六、頻率與風險分開排序
分成：
- 高頻且影響核心任務
- 高頻但偏好／便利性
- 低頻但需人工風險審查
- 證據不足但值得驗證
不得自行創造嚴重度標準。

七、矛盾、反例與附帶條件
| 議題 | 支持證據 | 反對／不同情境證據 | 可能解釋（標示假設） | 需要補充的資料 |

八、未知與資料缺口
| 缺口 | 目前不能回答的問題 | 影響 | 建議補充方式 |

九、候選改善與驗證計畫
| 候選改善 | 對應證據 | 尚未證實的假設 | 最低成本驗證 | 成功訊號 | 可能副作用 | 建議負責角色 |
負責角色若未提供，只能寫「待確認」。

十、五個高價值追問
優先提出能區分原因、影響或方案的問題，避免再次詢問原資料已有答案的內容。

十一、一頁簡報大綱
包含：分析範圍、三項主要發現、一項低頻高風險訊號、資料限制、下一步。每項發現附回饋編號。

十二、人工確認清單
列出發布、引用、決定改善優先序及聯絡回覆者前必須確認的事項。

建議分兩輪使用

第一輪只要求輸出「資料完整性檢查、初版編碼本與 20 至 50 則樣本編碼」。人工修正後，將編碼本定版。

第二輪提供 編碼本 v1.0 與完整資料，要求 AI 套用，不在中途自行改分類。每批完成後抽查 10% 至 20%，最後再合併統計。

實際教學範例

情境

公司試行新的行動報帳系統，共 40 位員工完成任務並填寫問卷，其中 32 位留下文字回饋。以下是節錄並去識別化的 8 則：

編號	角色	情境	原始回饋
F-001	一般同仁	手機送件	拍完發票後轉了快一分鐘，我以為沒成功又按一次，結果出現兩張。
F-002	一般同仁	退件重送	財務退回但只寫資料不完整，我不知道缺哪一欄。
F-003	主管	手機核准	如果能一次全部核准會更快。
F-004	財務覆核	查核	不建議全部核准，有些費用需要逐筆看憑證。
F-005	一般同仁	國外出差	外幣金額輸入後，不知道系統採哪一天的匯率。
F-006	一般同仁	無障礙操作	鍵盤移到附件按鈕時沒有明顯焦點，我無法確認目前選到哪裡。
F-007	一般同仁	日常送件	整體比紙本快，常用的成本中心可以記住會更方便。
F-008	財務覆核	重複資料	同一張發票似乎可以送兩次，請確認是否有重複檢查。

不好的摘要

大家普遍認為系統速度慢、操作不直覺，希望增加批次核准、記憶成本中心與匯率顯示功能。

問題包括：

只有一則明確提到等待時間，不能說「普遍」。
把風險、偏好與功能要求混在一起。
忽略批次核准的反對意見。
把「似乎可重複送件」當成已證實缺陷。
完全漏掉鍵盤焦點的無障礙問題。
沒有回饋編號，無法追溯。

建議編碼本節錄

代碼	定義	納入	排除	風險屬性
`效能_送件回應不明`	送件後等待過久或缺少處理狀態，造成重複操作	明確提到等待、轉圈或不知道是否成功	單純偏好操作更快	效率、錯誤
`流程_退件指示不足`	退件內容不足以讓送件者完成修正	缺欄位、缺原因、下一步不明	不同意退件決定	阻斷
`核准_批次操作需求`	希望一次處理多筆核准	批次、全選、一次核准	只要求清單排序	效率、控制
`資料_匯率依據不明`	不知道匯率日期或來源	明確詢問匯率計算依據	單純要求支援外幣	財務、透明度
`無障礙_鍵盤焦點不清`	鍵盤操作時無法辨識焦點位置	明確提到鍵盤、焦點、目前選取	一般視覺美觀偏好	無障礙、阻斷
`控制_疑似重複送件`	回饋指出可能重複建立同一憑證	同發票、重複送件或重複紀錄	使用者自己重按但系統已攔截	財務、資料品質

逐筆判讀節錄

編號	觀察／經驗	影響	原因假設	方案要求	代碼	判讀
F-001	送件等待近一分鐘，重按後出現兩張	可能產生重複紀錄	回應狀態不清或防重機制不足，待驗證	無明確方案	效能_送件回應不明；控制_疑似重複送件	需查操作日誌與唯一性規則
F-003	主管希望一次核准多筆	現行逐筆操作較慢	無	增加批次核准	核准_批次操作需求	偏好／效率需求，不等於已核准規格
F-004	某些費用需逐筆看憑證	批次核准可能降低查核控制	無	不建議全面開放	核准_批次操作需求	F-003 的重要反例與附帶條件
F-006	鍵盤操作看不出焦點	特定使用者可能無法完成操作	無	無明確方案	無障礙_鍵盤焦點不清	低頻但需優先人工審查
F-008	疑似同一發票可送兩次	可能造成重複請款	無法確認系統是否缺少檢核	請確認重複檢查	控制_疑似重複送件	是待驗證風險，不是已證實缺陷

正確的摘要方式

在 32 份有效文字回饋中，樣本顯示送件狀態、退件指示及部分財務規則的透明度需要進一步檢查。批次核准同時存在效率需求與查核控制顧慮，不宜只依單一意見直接實作。另有 1 則鍵盤焦點問題，雖然低頻，但可能阻止特定使用者完成核心任務，應進行人工無障礙檢查。重複送件目前是疑似風險，需以日誌及資料規則驗證。

建議下一步

優先項目	最低成本驗證	成功訊號
送件狀態與重複操作	查 30 筆送件日誌並做弱網路測試	狀態清楚；重按不產生重複資料
退件指示	用 5 個真實退件案例測試原因欄位	使用者無需另問財務即可修正
批次核准	原型測試「低風險可批次、高風險逐筆」	主管節省時間且財務控制未降低
鍵盤焦點	以鍵盤完成整段流程的人工檢查	全程可辨識焦點並完成送件
匯率依據	核對現行規則及畫面說明	使用者能說明匯率來源與日期

常見錯誤、隱私與使用注意事項

常見錯誤

直接要求「幫我總結」： 容易得到不可追溯的順口故事。
先決定答案再找引句： 會造成確認偏誤。
只有單一標籤： 一句含多個問題時會遺失資訊。
代碼太抽象：「體驗不好」無法指向驗證或改善。
代碼太細： 每則回饋都變成獨立分類，無法聚合。
每批改分類： 不同批次的統計不能直接合併。
把情緒當嚴重度： 語氣平淡的回饋也可能涉及重大風險。
只看高頻： 法規、資安、財務或無障礙問題可能低頻但重要。
只報百分比： 小樣本的 50% 可能只是 1／2，必須同時列分子分母。
提及數當人數： 同一人重複留言會放大主題。
沉默當滿意： 沒有留言可能是不願回覆、沒使用過或無法完成。
把方案當需求：「加一個按鈕」可能只是使用者對問題的其中一種解法。
把使用者推測當根因：「一定是伺服器」仍需技術證據。
抽一句話脫離上下文： 引句應保留足以理解原意的最短內容。
以 AI 信心取代人工查核： 信心高不等於事實正確。

資料隱私

使用組織核准的 AI 環境與資料處理規範。
優先貼入去識別化資料，不上傳完整名單或可識別附件。
敏感申訴、人事、醫療、薪資與紀律資料應採更嚴格權限，必要時不要使用外部 AI。
小族群交叉欄位可能重新識別個人；報告時合併或隱藏過小群組。
對外引用前取得必要同意，並確認引句不包含可識別線索。
不使用回饋內容替員工做績效、人格或忠誠度判定。
設定原始資料、編碼表與報告的存取權限及保存期限。

使用注意事項

AI 適合協助整理、套用規則、發現矛盾與產生查核表，不適合替團隊宣告根因。
若要比較月份，需維持相同問題、樣本定義與編碼版本，或清楚記錄變更。
自動情緒分析容易受反諷、文化與語境影響，不應單獨作為優先序。
小樣本適合探索問題，不適合代表整體母體。
所有改善優先序仍需綜合業務影響、成本、風險與決策權。
報告應保留「未知」，不要為了完整而填入推測。