如何使用 AI 得到可靠結果，先要給它清晰而可檢查的任務和明確的驗收方式。AI 不是最終決策者。可靠流程是先選擇任務、刪除敏感資料、說明目標和限制、檢查結果，並在風險高於收益時停止。

關鍵要點

從有明確完成標準的任務開始。

把提示詞、上載檔案、網頁和 AI 輸出視為不可信資料。

要求固定格式，讓假設和不確定性可見。

重要結論必須回到原始來源核驗。

選擇具體的 AI 工作流程。

了解一般安全流程後，按照你要完成的轉換任務選擇相應指南：

1. 如何使用 AI 選擇合適的任務

AI 很適合擔任起草、整理、轉換或腦力激盪的助手；但在醫療、法律、財務、就業、身份或安全攸關的選擇上，它不宜成為最終決策者。

任務	合適的第一個請求	人工檢查
起草	「把這些公開筆記整理成簡潔提綱。」	檢查語氣、遺漏和歸屬
編輯	「在不改動事實的前提下，令這段文字更清楚。」	逐項對照每處事實改動
整理	「把這些項目放進表格，並加一欄『欠缺證據』。」	確認分類和每一列
學習	「先解釋這個概念，再給我三條自測題。」	以課本或官方來源核對
研究	「列出各項主張，以及每項需要的原始來源。」	打開並閱讀每個來源
高風險決定	不要把決定交給 AI	諮詢合資格人士或主管機構

寫明讀者、限期和可接受的不確定程度。「幫我處理一下」沒有給模型任何可靠的完成定義。

2. 傳送前如何保護輸入資料？

最安全的提示詞，是所含敏感資料最少的提示詞。刪除密碼、API 密鑰、身份證明文件、客戶記錄、健康資料、私人地址、未公布的財務數據和專有程式碼。以佔位符取代真實姓名和識別碼，並把對照表保存在 AI 服務以外。

把公開材料和私密材料分開處理。公開新聞稿可以直接撮要；內部事故報告則可能要放在獲批准的企業工作區或本地工具中處理。請細閱供應商現行的資料控制和工作區政策，不要以為付費計劃或 VPN 會改變供應商處理提示詞的方式。VPN 保護的是網絡路徑，而不是供應商的資料處理。

上載檔案前，先問自己：

我有權分享這份材料嗎？
任務需要完整檔案，還是只需一段已脫敏的摘錄？
答案會否披露其他人的資料？
能否完全不傳送檔案而完成任務？

AI 工具私隱風險指南更詳細地講解資料分級、保留期和帳戶界線。

3. 給模型一個細小而可測試的任務

實用的提示詞通常包含五部分：

任務：你要它執行的動作。
上下文：它可以使用的事實和面向的讀者。
限制：哪些內容不得虛構或改動。
格式：答案的形式。
核驗：不確定之處應如何標示。

例如：

「你正在編輯一篇公開的說明文章。把以下段落改寫成面向初學者的 120 字說明。所有產品名稱和數字保持不變；沒有根據的說法標記為 [verify]。先交回改寫後的段落，再列出三項改動。」

這個提示詞比「把它改好一點」更好，因為你可以逐項檢查每條限制有否遵守。可重用的寫法見可重用、可檢驗的提示詞寫法。

4. 分步迭代，不要一次過要求全部完成

採用一個簡短循環：

先要求初稿或提綱。
檢查結構、欠缺的假設和沒有根據的主張。
每次只提出一項針對性修正。
要求模型說明改了甚麼。
只保留你能獨立覆核的部分。

不要因為第一個答案含糊，就加入私人細節。只補上欠缺的最少上下文，然後再測試。如果模型一直在猜測，就改變任務或尋找原始來源，而不是把提示詞越寫越長。

5. 如何核驗 AI 輸出？

文字流暢不等於有證據。把答案拆成一條條主張，並逐條分類：

穩定原則：一般性的解釋，仍值得做一次合理性檢查。
現行事實：產品功能、價格、法律、日期或供應情況等主張，需要現行的官方來源。
詮釋：屬於推論的內容，應清楚標明。
指示：指令或操作程序，使用前應先在安全環境中測試。

親自打開引用的來源，確認它支持的正是這項主張，而且日期、範圍和適用對象都一致。只是提及相關話題的引用，並不能證明結論。逐項核驗 AI 答案的方法提供了一份主張與證據清單。

6. 甚麼時候應停下來請人覆核？

出現以下情況時，應停下來請人覆核：結果會影響某人的權利、金錢、健康、安全、存取權、就業或身份；來源無法核實；模型要求你提供秘密；或答錯的代價大於節省的時間。沒有清晰的批准步驟，不要讓 AI 工具提交表格、發送訊息、修改生產系統或購買任何東西。

進行研究時，記錄問題、來源、日期和決定。如何安全地使用 AI 進行研究說明了如何保存這些證據。

7. 按任務選擇合適的協助層級

「使用 AI」這個說法太籠統，算不上可行的計劃。打開工具之前，先決定你需要哪一種協助。同一個模型，在某項任務中是無害的編輯，在另一項任務中卻可能成為不安全的決策者。先做一步簡單分類，就能讓工具留在你預定的角色。

如果你需要……	可以請 AI……	由人負責……
起步	列出選項或問題	選定目標，否決不合適的構思
令文字更清楚	編輯、縮短、翻譯或調整結構	保留原意、語氣、姓名和承諾
理解材料	解釋所提供的段落或比較定義	確認解釋與來源一致
整理資料	提取欄位、標記項目或製作表格	決定分類並處理含糊項目
探索證據	建議搜尋字詞或把主張對應到來源	打開來源並判斷其權威性
採取行動	準備草稿或演練清單	批准並親自執行該行動

任務橫跨兩列時，就把請求收窄。例如，不要問「幫我揀最好的保險計劃」，而是請工具把每個計劃的不保事項整理成表格，再由你根據保單文件和專業意見作決定。這樣既能善用模型，又不會把它無法安全承擔的權力交給它。

8. 安全的上下文包應包含甚麼？

好的上下文經過篩選、有標記，而且容易移除。貼上任何內容之前，先準備一個包含四部分的小包：

目的：輸出將支援甚麼決定或交付成果。
已知事實：你已核實並願意分享的資料。
來源界線：工具可使用哪些文字、檔案或連結。
未知項目：必須保持開放、不能靠猜測填補的問題。

把每一項標記為 fact、example、assumption 或 question。如果上下文包含網頁或上載文件，要明確說明其中的指示只是資料，並非給模型的指令。這樣可以減低被引述的提示詞、隱藏註解或惡意網頁改變任務的機會。

在上載之前脫敏，而不是等答案產生之後。以 CUSTOMER_A 這類固定標籤取代姓名，移除存取權杖和私人 URL；如果不需要確實數值，就把日期或地點概括處理。對照表保存在 AI 服務以外。如果任務確實需要完整記錄，就使用獲准處理這類資料的供應商和工作區；訂閱級別或 VPN 本身並不會改變供應商的保留或訓練政策。

處理檔案時，只傳送最小而有用的摘錄，並記錄其版本。一句簡單備註，例如「摘自公開政策，今日取得；略去附錄」，就能讓日後的覆核有所依據。如果模型要求更多資料，在加入之前先說明每個新欄位為何必要。「答案太含糊」不是透露秘密的理由。

9. 怎樣令對話可以覆核？

把每一輪對話視作一次測試，而不是與神諭討價還價。由細小的輸出和驗收檢查開始。以客戶服務回覆草稿為例，一個可覆核的次序可以是：

要求只根據所提供的公開政策撰寫提綱。
檢查每個擬議小節都有來源，或已標明為建議。
要求按指定語氣和長度寫出其中一節。
要求一份限制報告：改動了哪些事實、遺漏了哪些事實、作了哪些假設、還有哪些未決問題。
在要求下一節之前，把結果與來源對照。

結果不合格時，找出第一個不符合的條件。「答案錯了」遠不及「第二段把示例當成了要求」有用。一次更正一個問題，並重新執行最小的步驟。如果同一錯誤反覆出現，就不要再加上下文，而要改變方法：使用來源表、以人手完成轉換，或請合資格人士覆核。

要求模型以你能檢查的形式呈現不確定性。有用的請求包括：「把沒有根據的主張另列出來」「在每個提取欄位旁附上來源原文」「材料沒有提及時交回 unknown」。不要要求它展示隱藏推理或給出信心百分比；簡潔的理由和可見的證據更容易核實。

10. 把有用的結果變成小流程

某項任務行得通之後，要保存的是令它安全的部分，而不是某一個出色的答案。保留提示詞、輸入說明、輸出格式、覆核清單和一個已脫敏示例。只有當所用模型或工作區會影響可重複性時才記錄下來，並預期介面和功能會有變化。

重用範本之前，先以一個乾淨的例子和一個刻意設計的困難例子測試。確認範本不會誘使用戶貼上敏感資料、假定某項功能存在，或隱藏不確定性。為範本設定停止條件，例如「如果欠缺來源，交回 not verified，不要繼續」。可重用的流程應令安全路徑更容易走，而不是令未經覆核的自動化跑得更快。

以任務的驗收條件衡量輸出。提取任務，就點算缺漏和標錯的欄位；編輯任務，就把改動過的事實和名稱與來源對照；研究任務，就點算仍欠原始來源的主張。這些小檢查能看出工具是真的節省時間，還是只在製造一段要別人重寫的文字。

11. 小心處理檔案、瀏覽和代理

AI 工具可能可以讀取檔案、瀏覽網頁、呼叫 API 或操作軟件。即使問題本身很簡單，這些能力也會改變風險。只授予所需的最少權限，優先採用唯讀存取，並把有後果的操作放在獨立的批准步驟之後。

處理網頁時，記錄 URL 和你實際使用的原文段落；模型讀取之後，頁面可能會改變。處理檔案時，把原件和脫敏副本分開保存。使用代理時，界定哪些資料夾、帳戶和指令屬於範圍之內，並在容許真正寫入之前先在沙箱測試。絕不能讓草擬中的流程靜悄悄地發送訊息、提交表格、修改生產記錄或購買服務。

如果任務需要登入，先確認工作區正確，而且帳戶持有人已批准這條資料流。不要把密碼或復原碼貼進提示詞。如果工具要求的權限超出任務所需，就拒絕，另找範圍較窄的途徑。

完整示例：由含糊請求到已核實草稿

假設你要為一份公開的產品政策寫一段簡短的內部說明。先自行寫下完成標準：「新讀者應明白這項政策涵蓋甚麼、不包括甚麼，以及到哪裏確認最新措辭。」這句話比請工具「總結這項政策」有用得多。

接着準備上下文包：放入公開政策原文、來源 URL、目標讀者和篇幅要求。政策以外的內容一律標為問題。說明工具不得加入來源沒有的功能、日期或法律結論。這時你就可以要求它提供一份六行提綱，每行旁附上來源備註。

在要求撰寫正文之前，先覆核提綱。假設其中一行寫着「供應商保證服務可用」，但來源只說服務的設計目標是保持可用。繼續之前先刪除或更正這一行。問題不在於模型用錯了一個形容詞；如果你沒有核對就把錯誤潤飾一番，失敗的是整個流程。

撰寫草稿時，一次只要一節，並保留政策中的定義用語。每節完成後，要求一份簡短的修改記錄：加入了哪些事實、刪去了哪些事實、哪些措辭屬於詮釋、還剩哪些問題。把該節與來源對照，然後批准，或發回一項更正。不要為了令文字「更真實」而提供一個不相干的私人例子；虛構例子已足以測試語氣和結構。

最後，以已批准的草稿和來源界線另外執行一個審核提示：「列出每一項事實陳述，引述支持它的原文，並把沒有根據的陳述標記為 not verified。」這只是整理工具，不是獨立證據。你仍要親自打開來源，核對日期和範圍，並刪除審核無法支持的內容。

同一模式也適用於試算表、程式碼修改或研究備忘錄：界定完成標準，提供最少的安全上下文，要求一次細小的轉換，檢查第一個結果，並為最終決定保存證據。如果任務變成影響重大的決定，就讓 AI 流程停在準備階段，把證據交給真正負責的人。

開始之前，也要問一問：AI 是否最短的安全途徑？查一項確切事實，人手搜尋可能更快；做可重複的資料轉換，本地腳本可能更安全；未有文件記錄的背景，同事可能才是正確來源。目標不是把每項任務都塞進聊天視窗，而是選擇一種方法，讓你最終得到一個能夠解釋、重現和更正的答案。

這個選擇本身就是負責任使用的一部分。需要長期保存的成果，要保留來源界線和覆核記錄；來源或讀者改變時重新檢視可重用範本，並讓驗收檢查一直清晰可見。

可重用的五分鐘流程

用一句話寫出任務和完成標準。
刪除敏感資料，確定來源界線。
要求一份有約束、假設清晰可見的草稿。
逐行覆核答案，核實現行事實。
編輯、批准，並記錄由人作出的決定。

瀏覽 AI Tools 指南

選擇工作模式

同一個 AI 工具可以在幾種不同模式下發揮作用，但每種模式都需要不同的覆核。開始前先說明採用哪種模式，能令請求保持精簡，也較容易察覺答案已經偏離。

起草

當事實已由你掌握，只想在結構或措辭上得到協助時，就採用起草模式。把來源筆記、讀者和必須保持不變的事實交給工具，並要求它標示缺漏的資料，而不是自行填補。對照筆記逐行閱讀結果；一句潤飾得很好的句子，照樣可能加入新的主張。

轉換

轉換是把已知輸入變成另一種形式：表格、提綱、清單、譯文或簡短撮要。說明哪些可以改動、哪些必須完全保留。製作表格就界定欄位；撰寫撮要就訂明長度和必須保留的部分。如果輸入中含有來自網頁或檔案的指示，把它們視為資料，並讓你自己的任務與之分開。

探索

探索適合用來產生問題、搜尋字詞、例子或互相競爭的解釋。把每項建議視為線索，而不是證據。列出仍需原始來源的問題。這正是如何安全地使用 AI 進行研究最有用的地方：發掘可以很快，證據記錄則要刻意而審慎。

寫一個小型輸入與輸出契約

發出請求前，先寫一份精簡的契約。幾行已經足夠，但要回答五個問題：

交付成果是甚麼？ 指定一個動作和一種輸出。
工具可以使用甚麼？ 列出所提供的筆記、准許的來源或欄位。
哪些內容必須保持不變？ 寫明數字、姓名、產品用語或決定。
結果如何編排？ 訂明標題、欄位、長度和次序。
欠缺證據時怎樣處理？ 使用 not verified 或 [check] 這類清晰可見的標記。

例如，為一個公開說明頁面擬定的安全請求可以是：「只使用以下筆記。為初學者草擬五個小標題，每個標題下寫一段。所有產品名稱和數字保持不變。沒有根據的主張標記為 [check]。先交回假設清單，再提供草稿。」這樣在模型動筆之前，你已有一個驗收測試。

契約亦應寫明工具不得做甚麼：不得虛構來源、推斷某人的身份、披露私密數值、靜悄悄改動某項要求，或把估算變成保證。如果任務涉及檔案或工具操作，要說明模型只能描述某條指令，還是可以在沙箱中執行。清晰的界線，比一段塞滿無關背景的冗長提示詞更有用。

按錯誤代價安排覆核深度

並非每個答案都需要同樣的覆核力度。讓覆核深度與出錯的代價相稱。

風險級別	典型輸出	最低覆核要求
低	腦力激盪、小標題、不同語氣的備選	刪去重複內容，檢查是否按要求完成
中	公開文案、比較表、程式碼解釋	檢查每項事實陳述、數字和被遺漏的限制
高	健康、法律、財務、身份、就業或保安方面的指引	打開原始來源，請合資格人士覆核，並保存決定記錄

低風險的腦力激盪，否決不符要求的構思便已足夠。中風險的表格，要逐列檢查，並確認各類別可以互相比較。高風險工作，不要把一份語氣自信的撮要當作來源或覆核人的替代品。成果的後果越重大，你就越不應依賴工具自稱「已經檢查過」。

分四輪覆核答案：

指示檢查：是否按要求的形式、讀者、長度和次序交回？
證據檢查：哪些主張有根據，哪些是假設，哪些在所提供的材料中根本沒有？
安全檢查：答案有否重複秘密、個人資料、不安全的指示，或它本不應擁有的權限？
決定檢查：還有哪些地方需要人作選擇、核對來源或進行受控測試？

三個實用流程

改寫公開訊息

從原有訊息入手，標出不能改動的事實。提供目標讀者、語氣、最大長度和一個期望的下一步。要求交回草稿和修改清單。把草稿與原文對照，特別是姓名、日期、承諾，以及任何聽起來比原文更肯定的句子。只批准保留了負責人真正承諾的措辭。

比較兩個選項

先界定決定和準則。請工具為每項準則建立一列，引述所提供的證據；兩個來源都沒有回答的儲存格就留空。然後檢查兩個選項是否採用相同的定義和時段。靜悄悄採用不同標準的比較，即使文字清晰，也不算公平。

準備研究簡報

搜尋之前，先寫下問題、讀者、日期界線、地域範圍和可接受的來源類型。用 AI 提出搜尋字詞和可能相關的文件清單，然後親自打開原文。記錄確切的 URL、標題、日期、相關段落和適用範圍。只有在這個表格完成之後，才讓工具把證據整理成提綱。AI 答案核驗指南說明了發布前如何把一段潤飾過的文字拆成一項項主張。

建立受控的工作產物

當 AI 輔助產物會指導團隊協作時，先準備有版本的範本、明確負責人和批准路徑。你可以用 AI 草擬數據字典、建立風險登記冊、準備會議議程，或把職位描述轉為面試評分卡，但不要讓工具補造缺失事實或批准結果。保留所有未知項，由真正負責的人作最終決定。

審查質量、證據與管治

面對較高風險的營運審查，應先明確證據、負責人、決策規則和升級路徑，再讓 AI 整理資料。這個方法適用於軟件發布檢查清單、實驗計劃、網站無障礙審查和私隱影響評估草案。AI 可以暴露缺口和組織記錄，但發布批准、統計選擇、無障礙結論以及法律或私隱判斷仍須由合資格人員負責。

對於強調來源和專業責任的財務、服務、合規與保證工作，應採用保留證據的流程：提取發票行項目、建立服務藍圖、維護合規義務登記冊，以及規劃不捏造證據的審計抽樣。模型只整理有邊界的輸入，計算、適用性、程序和結論仍由相應專業人員負責。

受控營運也遵循同一原則：制定資料保留計劃、核查營運容量計劃、分析缺貨模式而不猜測原因，或把設備手冊轉為維護計劃。始終明確保留來源、公式、假設、安全約束和審批，避免 AI 悄然成為決策者。

開着 VPN，傳給 AI 的提示詞就安全了嗎？

只在傳輸途中有效。按第 2 步傳送已脫敏的提示詞時，VPN 會加密裝置至 VPN 伺服器之間的連線，減少公共 Wi-Fi 上的窺探；提示詞到達 AI 服務方後，保留、訓練和工作區權限仍由服務方自己的設定決定，脫敏和資料控制不可省略。如果你經常在酒店、咖啡店等不可信的 Wi-Fi 上寫提示詞，可以用 AethoVPN 加密這一段連線，下次外出前先免費試用 3 天。

延伸閱讀：全部 AI 工具指南

下面列出 AI 工具專題的其餘指南，可以直接跳到你需要的工作流程。

總結

任務越窄、輸入越安全、輸出越可測試，AI 就越有用。選擇能從起草或整理中得益的工作，把高風險決定留在人手掌控之下，並在證據足以支持之前，把每個答案都視為草稿。

上述流程以下列 AI 風險、私隱和提示詞設計指引為依據。［1］［2］［3］

常見問題

需要特別的 AI 提示詞公式嗎？

不需要。清晰的任務、相關的上下文、限制、格式和核驗要求，比任何萬能公式都更有用。

應該把自己的情況全部告訴 AI 工具嗎？

不應該。只分享任務需要的上下文，傳送任何內容之前先刪除秘密和個人資料。如果第一個答案含糊，就補上欠缺的那一項最少事實，而不是交出你的全部情況。

AI 能替我作最終決定嗎？

它不應在健康、法律、金錢、身份、就業或安全方面替你作高風險決定。可以用它準備問題或整理證據，再請合資格人士覆核。

為甚麼語氣肯定的答案仍要核實？

AI 可以在沒有可靠證據的情況下寫出看似合理的文字。語氣自信、行文流暢都不是證明。

如果 AI 工具在我的網絡上無法使用，應怎樣處理？

先查看供應商支援的地區、帳戶要求和狀態頁。VPN 只能用來測試准許範圍內的網絡層問題，無法改變資格或平台規則。參見 AI 工具 VPN 指南。

免責聲明：本文只供一般資訊參考，不構成法律、醫療、財務或專業建議。請遵守供應商的最新條款和所屬機構的資料政策。

來源：

NIST — Generative AI Profile — https://www.nist.gov/itl/ai-risk-management-framework
OpenAI Help Center — Data usage and privacy — https://help.openai.com/en/articles/7730893
Google — Prompt design strategies — https://ai.google.dev/gemini-api/docs/prompting-strategies

Sources checked 2026 年 8 月 22 日。

延伸閱讀：