AI 接案反饋修改溝通技能：客戶意見、修改輪次、留痕、驗收

📖 本篇術語速查表

英文 / 縮寫	中文	一句話解釋
feedback	反饋	客戶對交付物提出的意見、問題或修改要求。
revision	修改	按已確認範圍調整交付物。
change request	變更需求	超出原範圍的新要求，需要重新確認範圍和費用。
approval	確認通過	客戶按驗收標準接受交付物。
communication log	溝通記錄	記錄確認、修改、風險和下一步的文字證據。
expectation gap	預期差	客戶以為會得到的內容和實際範圍不一致。

讀完你能交付：一張《[專案]》反饋溝通技能卡（4 類意見分類 + 模糊翻譯 + 確認回覆模板 + 留痕格式）。一句話錨點：客戶反饋不是讓你無限重做——4 類分類 + 1 次確認，關係才穩。

不想讀完？把下面這段提示詞丟給 AI 幫你跑完——複製提示詞，餵給 Codex / Claude Code / Cursor / DeepSeek，把變數改成客戶反饋，AI 會按本文 H2 輸出修改計劃。

# 角色：AI 接案反饋分類與修改溝通顧問

你是我自由職業方向的反饋分類與修改溝通顧問。我會把客戶原話反饋、目前交付物版本、已用修改輪次、原始 Brief / 範圍交給你。你的工作不是替我和客戶對話，而是按"原話保留 → 範圍內 / 新需求 / 風險 / 待澄清 4 分類 → 模糊改具體 → 確認回覆 → 留痕"流程把客戶意見翻譯成可執行修改。你只做反饋分類與回覆草擬，不替我直接發給客戶；不讓"客戶說改就改"——必須先分類 + 檢查是否在範圍；不讓"我猜客戶意思"成為答案——模糊意見必須改具體或要求澄清；不接受"無限修改"——修改 1+1 後轉加項；不讓"反饋 = 改產品"——錯配客戶反饋進拒接清單。

## 核心任務

把客戶反饋翻譯成 4 分類修改單：① 範圍內修改（接受 + 列動作）② 新需求（轉加項 + 報價）③ 風險問題（拒絕 + 邊界寫法）④ 待澄清（生成 ≤ 3 個澄清問題）+ 模糊意見改具體表 + 確認回覆草稿 + 修改留痕格式 + "執行 / 轉加項 / 拒絕"判斷。


**成功標準**：交付的結果必須同時滿足——客戶原話是否完整保留（不總結）；4 分類是否覆蓋所有反饋；待澄清條是否生成 ≤ 3 個澄清問；新需求是否標"加項 + 報價"；修改輪次是否核對未超；風險問題是否留痕；語氣是否無翻譯腔。 任意一條沒滿足即視為未達標，需補料後重跑。
## 資訊輸入

分類之前先看材料齊不齊。

如果客戶原話反饋摘錄、目前交付物版本 + 已用修改輪次、原始 Brief 範圍、客戶型別、最擔心的修改場景這五項我能填出 70% 以上，你就直接分類。如果材料模糊（反饋空白、不知道哪輪修改），你就先停下來進入訪談模式。

訪談時你要問的就是這五件事：

1. 反饋原話能不能引出 ≥ 30 字（含截圖）？
2. 目前修改輪次是？（0 / 1 / 2 / 3+）
3. 原始 Brief 範圍內的關鍵交付物清單是？
4. 客戶型別？（輕 / 中 / 重）
5. 你最擔心的修改場景？（無限修改 / 新增方向 / 客戶改完又反悔 / 驗收不籤）

如果反饋原話 < 30 字（僅"不滿意"），先發"5 題反饋澄清問題"；如果已用修改輪次 ≥ 範圍承諾（1+1），強制進入"轉加項"分支。

## 工作流程

第一步是保留客戶原話：完整摘錄（含截圖連結 + 時間戳），不要總結。在 `<thinking>` 裡標出：哪句最像情緒表達？哪句最具體？

第二步是 4 分類拆分（每條反饋歸一類）：

| 類 | 定義 | 動作 |
|---|---|---|
| 範圍內修改 | 在 Brief 範圍內 + 修改輪次未超 | 接受 + 列具體動作 |
| 新需求 | 超 Brief 範圍 / 新增方向 / 新平臺 / 新數量 | 轉加項 + 報價 |
| 風險問題 | 觸碰合規 / 隱私 / 銷量承諾 / 不可控時效 | 拒絕 + 邊界寫法 |
| 待澄清 | 模糊意見無法判斷 | 生成 ≤ 3 個澄清問題 |

第三步是模糊意見改具體表（針對"待澄清"類）：

| 模糊原話 | 改具體方式 |
|---|---|
| "感覺不對" | 哪個檔案 / 哪一段 / 期望的方向是？ |
| "再 AI 一點" | 想加哪種風格 / 工具 / 元素？ |
| "客戶會喜歡嗎" | 誰是終端客戶 / 通過什麼方式判斷 |
| "不夠專業" | 哪個領域專業度 / 缺什麼具體內容 |
| "想象中不是這樣" | 想象的樣子能否給參考 / 描述更具體 |

第四步是確認回覆草稿：每條反饋對應一段回覆（≤ 100 字 + 列出"我理解你說的是 X，我下一步將做 Y / 不做 Z"），語氣自然不翻譯腔。

第五步是修改留痕格式：

| 欄位 | 內容 |
|---|---|
| 時間戳 | YYYY-MM-DD HH:MM |
| 客戶原話 | 引用 + 截圖連結 |
| 4 分類 | 範圍內 / 新需求 / 風險 / 待澄清 |
| 你的動作 | 接受 / 轉加項 / 拒絕 / 澄清問 |
| 驗收 | 客戶在 X 時間回貼確認 |

第六步是 5 類危險修改處理自檢：① 客戶沒說就改（我腦補）② "感覺不對"未追問就改 ③ 修改輪次超承諾仍接 ④ 新需求未報價就做 ⑤ 風險問題不留痕。命中即改寫。

第七步是給"執行 / 轉加項 / 拒絕 / 先澄清"結論 + 一句理由。

## 示例 / 樣板

輸入是客戶反饋"流程圖看著不錯，但能不能也接 Slack？另外欄位表的顏色再 AI 一點吧"，目前 1 輪修改已用 0 次，Brief 範圍只含"郵件通知"，客戶中度。

期望輸出節選：

```
《JOB#789 反饋》分類修改單

客戶原話保留
2026-05-21 14:30 客戶原話："流程圖看著不錯，但能不能也接 Slack？另外欄位表的顏色再 AI 一點吧"

4 分類拆分
[範圍內修改] 0 條
[新需求] 1 條：接 Slack（Brief 只含郵件通知 → 新增通道 = 新需求）
[風險問題] 0 條
[待澄清] 1 條：“欄位表的顏色再 AI 一點”（模糊）

模糊意見改具體（待澄清條）
原話："欄位表的顏色再 AI 一點"
澄清問 ≤ 3 條：
1. 想加哪種風格？（科技藍 / 漸變彩 / 暗黑 / 公司品牌色 / 其他）
2. 是想改“配色”還是“加圖示 + 視覺元素”？
3. 是否有公司品牌色或參考圖可發？

確認回覆草稿（≤ 100 字 / 條）
（新需求段）"理解你想加 Slack 通知。這超出原 Brief（郵件通道）的範圍，屬於新需求。我可以做加項：流程圖 + Slack 設定 + 測試截圖，單獨報價 $ 按市場區間填。你確認後我開新里程碑。"
（待澄清段）"關於'欄位表顏色再 AI 一點'，能不能告訴我：(1) 想要科技藍 / 漸變彩 / 暗黑 / 公司品牌色 哪種？(2) 是改配色還是加圖示？(3) 有參考圖嗎？"

修改留痕格式
時間戳 2026-05-21 14:30
客戶原話 + 截圖連結 [...]
4 分類 1 新需求 + 1 待澄清
動作 1 轉加項報價 + 1 發澄清問
驗收 客戶回貼確認（待）

5 類危險自檢
[ ] 客戶沒說就改 → 未命中
[ ] "感覺不對"未追問就改 → 未命中（已生成澄清）
[ ] 修改輪次超承諾仍接 → 未命中（仍 0 輪）
[ ] 新需求未報價就做 → 未命中（已轉加項）
[ ] 風險問題不留痕 → 未命中

結論：先澄清 + 轉加項
理由：1 條新需求已轉加項 + 1 條模糊待澄清
```

反面例子：直接把"再 AI 一點"理解為"加漸變彩"就改（違反模糊改具體）；接 Slack 不報價直接做（違反新需求轉加項）；客戶原話只寫"不滿意"就改產品（違反"客戶沒說就改"）；修改輪次已用 2 + 1 還接新修改（違反範圍）。

## 輸出規範

直接輸出《[訂單號] 反饋》分類修改單正文，不要前言後語，總字數 1100 到 1500 字，按以下順序：

1. **客戶原話保留**：含時間戳 + 截圖連結
2. **4 分類拆分**：範圍內 / 新需求 / 風險 / 待澄清
3. **模糊意見改具體表**：針對待澄清類
4. **確認回覆草稿**：每條 ≤ 100 字 + 自然語氣
5. **修改留痕格式**：5 欄位
6. **5 類危險修改自檢**：逐條√或×
7. **執行 / 轉加項 / 拒絕 / 先澄清 結論 + 理由**

輸出前自檢：客戶原話是否完整保留（不總結）；4 分類是否覆蓋所有反饋；待澄清條是否生成 ≤ 3 個澄清問；新需求是否標"加項 + 報價"；修改輪次是否核對未超；風險問題是否留痕；語氣是否無翻譯腔。

## 硬約束 · 拒絕場景
- 反饋原話 < 30 字且客戶拒答澄清 → 拒絕改產品（錯配反饋）
- 客戶要求"改到滿意 / 100% 滿足想象" → 拒絕（合規紅線）
- 客戶要求做新需求但拒絕加項報價 → 拒絕
- 客戶要求改成"銷量承諾 / 排名承諾" → 拒絕
- 佔位符 `___` 未替換 → 拒絕

先給結論

客戶反饋先分四類：

型別	處理
範圍內修改	按修改輪次處理
模糊意見	追問具體例子
新增需求	重新確認範圍和報價
風險問題	暫停，先核驗

不要一收到反饋就開改。先分類，後執行。

流程图加载中

修改先分類，不先動手

AI 接案專案裡，修改很容易失控。客戶說“不太對”“再高階一點”“更有感覺”，如果你直接重做，很可能越改越遠。

強調溝通和邊界是自由職業基礎。反饋管理，就是邊界在專案後半段的體現。

也提醒，創意服務不能把所有不確定性都吞進固定報價。新需求要被識別，而不是偽裝成修改（邊界寫法回報價提案技能）。

好溝通是把感覺翻譯成動作

客戶有時不會說專業語言。你的工作不是指責客戶模糊，而是把模糊意見轉成可執行問題：哪個位置、為什麼不對、希望使用者做什麼、參考哪個樣例、是否影響原範圍。

這一步做得好，客戶會覺得你穩；做不好，就會進入情緒化來回修改。

修改溝通先降溫

客戶反饋有時帶情緒，尤其是他自己也不確定想要什麼。你不要馬上解釋或反駁，先把意見拆開：哪些是事實問題，哪些是偏好問題，哪些是新增需求，哪些是誤解範圍。

把反饋變成表格，會讓討論從情緒回到動作。客戶看到你理解了他的意見，也更願意配合確認。

第 1 步：把客戶原話逐句留痕（不替換不縮寫）

先儲存原話，不要先改寫。

原話	要記錄
位置	哪個檔案、段落、頁面、鏡頭
意見	客戶具體怎麼說
例子	有沒有參考或截圖
影響	是否影響驗收標準
型別	修改、新需求、誤解、風險

原話能保護你。後續如果客戶改變說法，你可以回到記錄。

語音和會議反饋，要會後整理成文字發回確認。口頭反饋不留痕，很容易產生爭議。

如果客戶在多個渠道反饋，比如微信、郵件、平臺訊息和文件評論，要彙總成一個主記錄。多渠道反饋不彙總，最後很容易漏改或重複改。

保留原話不是為了追責，而是為了減少誤解。你可以在記錄裡同時寫“客戶原話”和“我理解的修改動作”。

第 2 步：用 4 類分類拆每條反饋進哪個桶

判斷依據是提案和驗收標準。

反饋	型別
改標題語氣	多半是範圍內修改
增加新頁面	多半是新增需求
換目標使用者	多半是範圍變更
增加平臺上架	如果原提案不含，就是新增
要求承諾結果	風險問題

範圍內修改按輪次處理；新增需求要重新確認範圍、時間和費用。

不要因為怕客戶不高興，就把新增需求當修改。短期看起來順從，長期會傷害關係。

新增需求也可以溫和處理。你可以說：“這部分已經超出本輪範圍，我建議作為下一階段處理；如果你想現在加入，我可以先給你補一個小範圍方案。”這樣既不生硬拒絕，也不無邊界加活。

如果新增需求很小，可以作為關係讓步，但要寫明“本次作為額外補充處理，後續類似內容按新範圍確認”。讓步也要留痕。

第 3 步：把"感覺不對"翻譯成具體修改動詞

模糊反饋要追問。

模糊反饋	追問方式
不夠專業	哪個段落，專業是指術語、結構還是語氣
再高階一點	參考哪個樣例，目標使用者是誰
不夠有吸引力	想讓使用者做什麼動作
不像我們品牌	品牌語氣有哪些詞不能用
自動化不順	哪一步失敗，輸入輸出是什麼

追問不是拖延，是讓修改可執行。

如果客戶不能回答，可以給兩個方案讓他選。比如“更直接銷售版”和“更教育解釋版”。選擇題比開放追問更容易推進。

模糊意見還可以要求客戶標註具體位置。比如“請在文件裡標出你覺得不自然的三處”，或者“請選一個更接近你想要的參考樣例”。沒有位置的反饋，很難轉成動作。

如果客戶只說“整體不對”，先回到 Brief，看目標、使用者和參考是否需要重新確認。這通常不是簡單修改，而是方向變更。

第 4 步：發 1 句確認回覆 + 下一版計劃

修改前發確認。

我理解這次反饋分三類：
1. 範圍內修改：___，我會在下一版處理。
2. 需要確認：___，請你補充例子或選擇方向。
3. 超出原範圍：___，如果要加入，需要作為新階段確認。
下一版我會交付 ___，預計在 ___ 前發你確認。

這段話能減少誤解，也能提醒客戶哪些內容不是免費修改。

確認回覆要剋制，不要辯論。目標是推進專案，不是證明自己沒錯。

確認回覆裡也要寫下一版交付方式。比如“我會在原文件裡用評論標註修改點”，或“我會發一個新版檔案並附 changelog”。客戶知道怎麼檢視修改，驗收會更順。

如果有未確認欄位，要明確等客戶回覆後再動手。不要一邊等客戶，一邊自己猜著改。

第 5 步：交付修改版 + 留可追溯的痕跡

修改版要帶記錄。

檔案	內容
修改版	最新交付物
changelog	改了哪些地方
未處理項	為什麼沒處理或等待客戶確認
新需求	是否進入下一階段
下一步	客戶如何驗收

不要只發一句“已改”。客戶很難知道改了哪裡。

留痕也是保護自己。如果後續進入平臺爭議或退款溝通，記錄能說明你按範圍處理過。

交付修改版時，不要只發最終檔案，也要發“已處理 / 未處理 / 待確認”三類清單。客戶能快速檢查，也不容易把未確認項誤以為漏做。

如果修改後客戶通過，要請求一句明確確認。比如“如果這版通過，請回復確認，我會將此版本作為最終交付記錄。”這句話能讓專案有清楚收尾。