開始閱讀
文案讀起來很自然，不代表可以直接發布。最容易被忽略的問題，往往是活動日期、多加的一項服務，或一句聽起來合理的效果承諾。與其只問「這篇文案好不好」，不如把檢查拆成明確任務。
這是一份編輯工作方法，可用於課程介紹、社群貼文與活動頁；不取代特定產業必要的專業審查。
第一輪：只找可查核的主張
把文案中的日期、金額、人數、功能、資格、比較與效果承諾圈起來。情緒形容與事實主張應分開處理。例如「輕鬆開始」偏向語氣；「三小時學會全部廣告操作」則包含範圍與成果承諾，需要特別檢查。
建立三欄表：原句、依據、處理決定。不要讓 AI 只回覆「查核完成」，要看它指出了什麼主張，以及來源是否真的支持那一句話。
| 原句示例 | 需要的依據 | 沒有依據時 |
|---|---|---|
| 完成即可獲得證照 | 正式發證條件 | 刪除，或改成可核對的結業條件 |
| 適合所有產業 | 適用範圍與例外 | 寫出主要適合對象 |
| 今天最後一天 | 已確認截止日期與時區 | 不使用倒數式說法 |
以上是虛構句子，僅供辨認不同類型的主張。
第二輪：核對來源的版本與範圍
來源可能只適用某個方案、地區或時間。檢查時記下「資料日期」與「適用條件」，不要把局部支援寫成全面開放。若來源無法讀取，標成待確認；不要因為網址看起來正式，就當成已經核實。
同一份文案若使用兩個互相衝突的數字，先回到原始資料確認口徑，例如計算期間、是否去重與是否含稅。無法釐清時，不應自行挑一個看起來合理的數值。
第三輪：檢查讀者會不會誤解
一句話可能字面沒錯，卻容易讓讀者形成超出證據的期待。檢查比較基準是否清楚、限制是否藏得太深，以及標題是否比內文更誇張。必要的條件應靠近對應主張，不要全部塞在文章最後。
可交給 AI 的檢查任務：
請把這篇文案拆成「事實主張、效果承諾、語氣表達、行動指示」四類。只列出疑點與原因，不自行補證據。對可能造成誤解的句子，提供保留原意且範圍更清楚的改寫。
AI 的輸出是檢查線索，最後仍要回到資料與實際頁面確認。
第四輪：實際點一次讀者的路徑
用手機閱讀標題、第一段與按鈕，確認主要訊息沒有被裁切。點開連結，核對目的頁的活動名稱、表單與時間。若是報名或購買流程，測試與真實送出要分開，不要為了檢查而產生不必要訂單或名單。
把「已寫完」「已審核」「已排程」「已公開」分成不同狀態。工具顯示提交成功，仍應到目的地查看結果；若不確定是否公開，先核對再重送，以免重複貼文。
發布後發現錯誤怎麼處理
先保存原始版本與錯誤範圍，再修正網站內容，記錄更正日期與重點。社群平台能否編輯因功能而異；已寄出的電子郵件無法靠修改網站版直接改回收件匣，必要時另發更正通知。
今天的練習：選一篇舊文，列出三個最值得查核的主張。目的不是找出最多錯字，而是先處理最可能影響讀者決策的資訊。
延伸閱讀：工具呼叫與結果驗證。
查核之前，先區分內容的風險
不是每一句文字都需要同樣深度的檢查。產品價格、報名資格、日期、退款條件與效果承諾，會直接影響讀者決策，應優先對照有效來源。一般比喻與語氣表達，可以用可理解性與適切性判斷。把查核時間平均分配給每一句，反而可能在裝飾文字上花太久，漏掉真正重要的條件。
可以在內部標記三種狀態：已有來源支持、需要負責人確認，以及無法支持應移除。標記不用出現在對外正文，但每個高風險主張都應有人能說明依據。例如「適合零基礎」應對照課程先備要求；「立即提升業績」若沒有足夠證據，就不能因為語氣有力而保留。查核不是最後找一個人按同意，而是讓每一種資訊有明確的責任來源。
圖片與連結也可能改變意思
很多團隊只檢查文字檔，卻忽略設計圖上的舊日期、截斷的價格與不清楚的單位。若正文寫「每堂」，圖片卻只顯示總價，讀者可能理解成整套課程。把圖像與文字放在一起閱讀，確認兩者傳達的是同一組條件。手機上看不清的小字，也不能被當成已充分說明的限制。
連結的檢查應一路走到目的地。按鈕能點，不代表表單能送；表單能送，不代表使用者會收到回覆。可以用專用測試資料走一次流程，檢查頁面名稱、重要欄位、成功訊息與後續說明是否一致。測試資料應能辨識，避免混進真正的詢問或訂單統計。
用兩輪審查降低來回修改
第一輪只處理事實與必要資訊：誰、什麼、何時、何地、條件與下一步。這輪未完成以前，不必急著修飾每個句子。第二輪再看段落節奏、讀者用語與可讀性，刪除重複資訊與不必要的形容詞。若在事實尚未確定時就投入大量設計與潤飾，後續更正會同時影響多個版本。
每次回饋盡量寫成可以執行的修改。例如「第二段的課程對象太廣，請改成首次接觸工具的行政同仁」，比「再精準一點」容易落實。若要求 AI 修改，也應保留不可以改動的資訊清單，避免在改善語氣時順手重寫日期、數字或資格。編輯者仍須核對修訂後的完整版本，不能只看被圈出的句子。
發布前的最後一張檢查卡
可以用一張卡記下版本日期、核對人、發布通路、原始來源與需要追蹤的項目。若同一篇內容改成電子報與社群貼文，就讓兩個版本連到同一份事實資料。如此當日期更改時，團隊能找到所有受影響的地方，不必靠記憶搜尋。
最後問一個實際問題：讀者照著這篇內容行動，會遇到什麼？如果得到的是失效連結、與文案不同的價格或無人處理的表單，文字再漂亮也沒有完成任務。把查核延伸到整個行動流程，才能讓 AI 文案真正成為可交付的內容，而不是只在編輯器裡看起來完整。
把方法帶回下一次任務
下一次開始前，先找出上一份版本最常被修改的地方，判斷是資訊不足、責任不清，還是驗收沒有說明。把問題改寫成一條具體規格，再用新任務檢查是否改善。不要把所有回饋都變成更長的規則，優先保留會影響正確性與讀者行動的條件。
完成後請另一位沒有參與討論的人閱讀，讓他說出內容的對象、目的與下一步。若理解不同，就回到需求與結構修正。這個小步驟能提早發現團隊因為太熟悉而忽略的資訊，也能讓交付不再只依賴同一個人的記憶。