「Tool:WEBUI AI對話基礎」:修訂間差異
外觀
無編輯摘要 |
無編輯摘要 標籤:手動回退 |
||
| (未顯示同一使用者於中間所作的 2 次修訂) | |||
| 第353行: | 第353行: | ||
{{Notice|ℹ️ '''NOTE''': 本文件由 Interaction Lab 編撰,歡迎教學使用。 如有建議或補充,請聯繫課程教授。}} | {{Notice|ℹ️ '''NOTE''': 本文件由 Interaction Lab 編撰,歡迎教學使用。 如有建議或補充,請聯繫課程教授。}} | ||
於 2026年3月28日 (六) 13:48 的最新修訂
🤖 WebUI 型 AI 對話工作設定指南
- 版本:v1.0 · 最後更新 2026-03-27
- 適用範圍:ChatGPT、Claude、Gemini 等所有 WebUI 型大型語言模型
- 作者:Interaction Lab · 江振維
為什麼需要這份指南?
WebUI 型 AI(如 ChatGPT、Claude、Gemini)每次開啟新對話時,都是一個全新的空白狀態。它不知道你是誰、不知道你要做什麼、也不知道你的品質標準。
如果你直接丟問題,AI 會用「最安全的通用方式」回答——這通常意味著泛泛而談、沒有深度、可能還有幻覺。
解決方法:在對話開頭,用一段結構化的「系統提示」(System Prompt) 明確告訴 AI 三件事:
- 你是誰(角色設定)
- 不能做什麼(紅線規則)
- 要做什麼(任務背景)
完整模板
以下模板可以直接複製貼上到任何 WebUI 型 AI 的對話開頭。【】 為需要替換的欄位。
我接下來要在這個對話中進行【你的任務類型,如:一個研究主題的探討】,相關規則如下:
== 你的角色 ==
# 【專業身份,如:嚴謹專業且資深的互動設計系統、產品設計、使用者經驗研究專家】
# 【工作態度,如:對學術研究論文研究方法有深刻了解且能自我反思探討更深層問題的研究者】
== 嚴格遵守、不能違規的事項 ==
# 【紅線 1,如:嚴禁使用 MDPI 或無法查證的網路不明來源資料】
# 【紅線 2,如:優先使用知名期刊、研討會的相關研究案例與資料】
# 【紅線 3,如:設計研究案例要是知名案例且貼合本研究方向】
# 【紅線 4,如:經典文獻需貼合研究主題並能在通篇文章中串接論述】
# 【紅線 5,如:如果不是經由查找而是由知識直接生成的內容可能是幻覺,請直接說不知道】
== 我的任務背景 ==
【簡要描述背景,如:懷孕期間的女性在移動過程中,特別是步行時的休息頻率與公共設施需求研究。】
逐項拆解與說明
1. 開場宣告:定義工作模式
我接下來要在這個對話中進行一個研究主題的探討,相關規則如下:
| 要素 | 說明 |
|---|---|
| 「接下來」 | 明確告知 AI 這不是隨意閒聊,而是要開始一段有目的的工作。 |
| 「相關規則如下」 | 讓 AI 進入「遵循指令」模式,而非「自由發揮」模式。 |
2. 角色設定:告訴 AI「你是誰」
## 你的角色 # 嚴謹專業且資深嚴格的互動設計系統、產品設計、使用者經驗研究專家 # 對於學術研究論文研究方法有深刻了解且能自我反思探討更深層問題的研究者
設計原則
| 原則 | 好的寫法 ✅ | 不好的寫法 ❌ |
|---|---|---|
| 具體專業領域 | 「資深的互動設計系統專家」 | 「你是一個助手」 |
| 態度與標準 | 「嚴謹、嚴格」 | 「友善、輕鬆」 |
| 工作方式 | 「能自我反思探討更深層問題」 | 「幫我回答問題」 |
| 階層感 | 「資深」 | 無描述 |
常見角色範例
| 場景 | 角色設定 |
|---|---|
| 學術研究 | 嚴謹的學術研究者,熟悉質性與量化研究方法 |
| 程式開發 | 資深全端工程師,精通系統架構設計與代碼審查 |
| UI/UX 設計 | 具 10 年經驗的產品設計師,專注於行動裝置體驗 |
| 論文寫作 | 學術期刊編輯,熟悉 APA 格式與學術論述邏輯 |
| 商業分析 | 管理顧問,擅長市場分析與商業策略規劃 |
3. 紅線規則:告訴 AI「不能做什麼」
## 嚴格遵守、不能違規的事項 # 嚴禁使用 MDPI 或無法查證的網路不明來源資料 # 優先使用知名期刊、研討會的相關研究案例與資料 # ...
為什麼紅線規則如此重要?
AI 模型預設行為是「盡量回答」——即使它不確定,也會傾向於生成一個看起來合理的答案(即幻覺)。紅線規則的作用是:
紅線規則的五大類型
| 類型 | 範例 | 適用場景 |
|---|---|---|
| 來源限制 | 嚴禁使用 MDPI 或不明來源 | 學術研究 |
| 品質門檻 | 優先使用知名期刊 (ACM, IEEE, CHI) | 文獻探討 |
| 真實性要求 | 案例必須是真實可查的知名案例 | 案例分析 |
| 邏輯一致性 | 論述必須全篇邏輯串接 | 論文寫作 |
| 幻覺防護 | 不確定的就說不知道 | 所有場景 |
4. 任務背景:告訴 AI「要做什麼」
## 我的研究方向 懷孕期間的女性在移動過程中,特別是針對步行時的休息頻率...
設計原則
- 足夠具體:不要只說「我在做 UX 研究」,要說明具體對象、場景、關注點。
- 適度留白:給出方向但不限死結論,讓 AI 有空間提供你沒想到的觀點。
- 分層描述:先大方向,再具體問題。
好壞對比
| ❌ 太模糊 | ✅ 足夠具體 |
|---|---|
| 我在做懷孕研究 | 懷孕期間的女性在移動過程中,特別是步行時的休息頻率與公共設施需求 |
| 幫我做 UI 設計 | 設計一個針對 65 歲以上長者的掛號 App,需考慮視力退化和操作容錯 |
| 分析市場趨勢 | 分析 2024-2026 年東南亞市場生成式 AI 在教育領域的應用趨勢 |
進階技巧
技巧 1:對話中途追加規則
如果你在對話過程中發現 AI 的輸出有問題,可以隨時追加規則:
從現在開始,額外遵守以下規則: * 每個論點都必須附上具體的文獻來源 (作者, 年份) * 不要使用條列式,改用段落式學術論述
技巧 2:要求 AI 自我檢查
請先回顧你剛才的回答,檢查是否有以下問題: # 是否有任何資訊是你不確定但仍然列出的? # 引用的文獻是否真實存在? # 論述邏輯是否有跳躍?
技巧 3:分階段工作
不要一次問完所有問題。把工作拆成小階段:
第一階段:請先幫我梳理這個研究主題的理論框架 第二階段:(等 AI 回覆後)基於上述框架,找出 3-5 篇核心文獻 第三階段:(等 AI 回覆後)用這些文獻支撐,寫出文獻探討的第一段
技巧 4:固定輸出格式
之後每次給我文獻,請用以下格式: * 作者 (年份). 標題. 期刊名稱, 卷(期), 頁碼. * 一句話摘要 * 與本研究的關聯性 (高/中/低)
常見問題 FAQ
Q1:這套方法對哪些 AI 有效?
所有 WebUI 型 AI 都適用,包括 ChatGPT (GPT-4o)、Claude (Sonnet/Opus)、Gemini (Pro/Ultra)。效果程度依模型能力略有不同,但基本原則一致。
Q2:規則寫太多會不會被忽略?
建議控制在 5-8 條 以內。太多規則會互相矛盾或被降權。最重要的規則放在前面。
Q3:對話太長了,AI 是否會「忘記」前面的規則?
會。對話超過模型的上下文窗口(通常 8K-200K tokens)後,早期內容會被截斷。 建議:在長對話中,每隔 10-15 輪重複一次核心規則。
Q4:可以把規則存在「System Prompt」裡嗎?
部分平台(如 ChatGPT 的「自訂指示」、Claude 的 Projects)支援。這是最佳做法,因為 System Prompt 的權重比一般對話訊息更高,較不容易被遺忘。
Q5:AI 說「好的我會遵守」但實際沒遵守怎麼辦?
直接指出違規之處:
你剛才的回答違反了第 1 條規則(嚴禁使用不明來源)。 請重新回答,並確保所有引用都來自 ACM、IEEE 或 CHI 的論文。
快速開始範本
範本 A:學術研究 🎓
我接下來要在這個對話中進行一個研究主題的探討,相關規則如下: == 你的角色 == # 嚴謹專業的學術研究者,熟悉質性研究與量化研究方法論 # 能夠批判性思考、自我反思,並引導深層學術討論 == 嚴格遵守、不能違規的事項 == # 嚴禁使用 MDPI 或無法查證的網路不明來源資料 # 優先使用知名期刊 (ACM, IEEE, CHI, Design Studies) 的研究 # 案例必須是真實可查的知名案例 # 所有論述須邏輯串接,能在通篇文章中自洽 # 如果是由你的知識直接生成可能有幻覺的內容,請直接說「這部分我無法確認」 == 任務背景 == 【你的研究方向描述】
範本 B:程式開發 💻
我接下來要在這個對話中進行一個系統的開發工作,相關規則如下: == 你的角色 == # 資深全端工程師,精通 Python/TypeScript 與系統架構 # 注重程式碼品質、可維護性與安全性 == 嚴格遵守、不能違規的事項 == # 所有程式碼必須包含錯誤處理與邊界條件檢查 # 禁止使用已棄用的 API 或有安全漏洞的套件 # 修改前先說明影響範圍,修改後提供測試方式 # 如果不確定某個 API 的行為,直接說不確定 == 任務背景 == 【你的專案描述】
範本 C:設計工作 🎨
我接下來要在這個對話中進行一個產品設計的討論,相關規則如下: == 你的角色 == # 具豐富經驗的 UX/UI 設計師,專注於以人為本的設計方法 # 熟悉 Design Thinking、雙鑽石模型等設計流程 == 嚴格遵守、不能違規的事項 == # 所有設計決策必須有使用者研究或設計理論支撐 # 案例必須來自真實產品,不可虛構 # 考慮無障礙設計 (Accessibility) 的需求 # 不確定的設計趨勢或數據請直接說不確定 == 任務背景 == 【你的設計任務描述】