前陣子，我打算用 AI 幫忙規劃一場某公司的新產品發布活動。

我的想法很簡單，想說用 Agent 幫我來做，給了他我的產品相關的所有檔案，並下提示詞：

幫我規劃這個產品新上市的發布活動。

很快地，AI 給了一份看起來很完整的規劃：有活動流程、有宣傳方向、有主持人建議，看起來甚至比我自己剛開始想的還完整。

但仔細看了一遍後，我發現問題還真不少。

嗯… 我被唬了一道，這個不是我真正需要的東西：

• 我要的是一場給企業客戶參加的產品發布會（To B），但 AI 規劃的內容比較像面向一般消費者的活動。(To C)
• 我需要的是一份可以交給團隊執行的文件，但它給我的比較像一篇活動企劃文章。
• … 還有其他大大小小的問題

也不能說它完全錯，只是它不知道什麼叫做「對」，什麼叫做「好」。

今天這篇就來談談，當 AI Agent 真的就像我們的助手／夥伴時，我們到底應該怎麼交辦好一件事情請他做？

從「問答式 AI」到「交辦式 Agent」的提示詞技巧演變

過去使用 ChatGPT、Gemini 這類聊天型 AI 時，我們其實已經學會很多 Prompt 技巧。

例如：

你是一位資深產品經理，幫我做競品分析報告。
用高階主管看得懂的方式說明，關鍵比較資訊、內容需要整理成表格。

(貼上競品們)

這些方法都還是有效，事實上，過去幾年甚至也發展出不少成熟的提示詞框架，幫助我們更有效地和 AI 溝通。

比較知名的例如：

RTF Framework（Role、Task、Format）

RTF／RTCF 是一種常見的 Prompt 結構。

它要求使用者先說明：

• Role（角色）：希望 AI 扮演什麼角色
• Task（任務）：希望 AI 完成什麼
• Constraint（限制）：有什麼特殊限制
• Format（格式）：希望結果如何呈現

例如：

你是一位資深產品經理（Role），請分析 AI Agent 對企業工作的影響（Task）
並整理成 Markdown 格式文件（Format）。

CO-STAR Framework

CO-STAR 則加入更多背景資訊：

• Context（背景）
• Objective（目標）
• Style（風格）
• Tone（語氣）
• Audience（對象）
• Response（回覆形式）

例如：

我要準備一場給企業主管的分享（Context），目標是讓非技術背景的人理解 AI Agent（Objective）
請用簡單易懂的方式說明（Style / Tone）
最後整理成簡報架構（Response）。

這些框架都解決了一個重要問題：

如何讓 AI 更理解我的需求，產生更符合期待的回答。

但當 AI 開始從聊天工具變成 Agent，事情開始有些不同。

因為我們交給 Agent 的，通常不只是一個問題。

而是一件工作。

例如：

幫我規劃一場產品發布活動。

這背後可能包含：

• 了解產品定位
• 分析目標客群
• 研究競品活動
• 規劃活動流程
• 製作簡報
• 產生活動 Run Down 文件
• 準備主持稿
• 整理後續追蹤事項

這已經不是一個回答可以解決的事情。

它比較像把一份工作交給另一位同事。

差異在於：

聊天型 AI 比較像：

我問一個問題，它給我一個答案。

AI Agent 比較像：

我交代一個目標，它規劃並完成一件事情。

所以，使用 Agent 時，我們需要改變的不只是 Prompt 寫法，而是「交辦工作的方式」。

從提示詞框架到任務交辦框架

Prompt Framework 的核心，是讓 AI 產生更好的回答。

所以我們會補充：

• 角色
• 背景
• 語氣
• 格式
• 範例

這些資訊在 Agent 時代依然重要。

但 Agent 多了一個新的需求：

它需要知道什麼叫完成。

假設我們交代：

幫我做一份產品發布活動企劃。

AI 可能會產出一份完整文字。

但實際執行活動時，我真正需要的可能是：

• 一份主管簡報
• 一份活動流程表
• 一份工作分配表
• 一份主持流程
• 一份風險清單

甚至在開始產出前，它還需要先完成：

• 蒐集產品資訊
• 分析市場定位
• 比較競品活動
• 判斷活動方向

所以 Agent 任務交辦時，需要補充的不只是：

「我要什麼結果。」

還包括：

「你需要在什麼條件下完成。」

這也是傳統 Prompt 和 Agent Task 最大的差異。

交辦 AI Agent 做事的簡單框架－GUIDE

GUIDE 的中文意思是「指引」，我覺得這個詞很適合用在「指引 Agent 完成任務」的情境。

但需要先說明：GUIDE 並不是一個既有的業界標準框架。

它是我把 AI Agent 任務交辦時常見的重要元素整理成一個方便記憶的方法。它的目的不是取代原本的 Prompt Framework。

而是幫助我們從：「我要問 AI 什麼？」

轉換成：「我要如何把一件工作交辦給 AI？」

GUIDE 共分成五個部分，一個一個來說明。

G — Goal（目標）

我要 Agent 完成什麼？這是所有任務的起點。

例如：

幫我整理 AI 新聞。

這句話看似清楚，但其實仍然有很多未知。

哪些新聞？給誰閱讀？

想解決什麼問題？

如果改成：

幫我整理每週值得知識工作者關注的 AI 產業新聞。

Agent 才知道自己的任務方向。

目標越清楚，Agent 越容易判斷哪些資訊值得保留。

U — User Context（使用者背景）

Agent 需要知道哪些關於我的資訊？同樣一個任務，不同人的需求可能完全不同。

例如整理 AI 新聞。

如果使用者是一位技術部落客，他可能需要：

• 技術細節
• 新工具介紹
• 開發者影響

如果使用者是一位企業主管，他可能需要：

• 商業影響
• 導入成本
• 競爭分析

任務名稱相同，最後產出的內容卻可能完全不同。

User Context 就是在告訴 Agent：你現在是在什麼情境下，幫我完成這件事情。

I — Instruction（執行方式）

Instruction 是告訴 Agent 怎麼做。

包含：

• 執行步驟
• 工作流程
• 判斷原則
• 注意事項

但不是所有任務都需要指定方法。

有些工作，我們希望 Agent 自己探索最佳方式。

有些工作，我們希望它複製我們累積多年的方法。

這兩種情況，需要不同程度的 Instruction。

D — Definition of Done（完成定義）

什麼狀態才算完成？這是很多人在交辦工作時容易忽略的地方。（就連交辦給同事、下屬也是）

例如：

幫我做一份分析報告。

對人類同事來說，他可能會主動追問。

但 Agent 不知道。

所以需要拆成兩部分：

Deliverable（交付物）

我要收到什麼？

例如：

• PowerPoint 簡報
• Word 文件
• Excel 分析表

Acceptance Criteria（驗收標準）

我要如何判斷品質？

例如：

一份主管簡報：

• 15 分鐘內可以講完
• 每頁只有一個核心訊息
• 包含實際案例

一份分析報告：

• 有資料來源
• 有分析過程
• 有明確結論
• 有改善建議

Definition of Done 的價值，是讓 Agent 知道：

什麼情況下，這份工作可以被認定為完成。

E — Example（範例）

有些工作標準很難只靠文字描述。

例如：

請使用我的寫作風格。

這句話對 Agent 來說仍然非常模糊。

但如果提供：

• 過去文章
• 喜歡的段落
• 不喜歡的寫法

Agent 就能更接近你的期待。

很多時候，範例參考比規則描述更容易傳達這類「隱性」的評估標準。

不一定需要每次都完整使用 GUIDE

看到這裡，可能有人會想：

「所以以後每次叫 Agent 做事情，GUIDE 五元素都要寫完整？」，這也太麻煩了吧？

其實不用－GUIDE 是方便你在交辦時的思考框架，不是固定的規則。

• 簡單任務，只需要 Goal 就夠了。例如：幫我翻譯這段文字。
• 中等任務，可能需要 Goal + User Context + Definition of Done。例如：整理今天會議紀錄成給高階主管的概要，完成後寄出，確認有收到回條。
• 複雜任務：例如建立每週 AI 產業情報報告，才需要完整描述 GUIDE 的所有元素。

你想控制到什麼程度？GUIDE 背後的兩種 Agent 委派方式

同一套 GUIDE 框架，背後還有一個重要選擇：你希望 Agent 使用你的方法完成工作？還是希望它自己探索完成目標的方法？

這會形成兩種不同的 Agent 委派方式。

方法委派：要求 Agent 使用我的方法

方法委派適合：「我知道怎麼做，而且這套方法本身具有價值。」

例如：

• 投資研究
• 文章撰寫
• 簡報設計
• 面試評估

假設請 Agent 分析一家公司的投資價值。

如果只說：

請幫我分析這家公司值不值得投資。

Agent 可以產出一份看似完整的分析。

但問題是，它不知道你的判斷框架。

不同投資方式，關注的事情可能完全不同。

價值投資者可能關注：

• 商業模式
• 競爭優勢
• 管理團隊
• 財務品質

交易型投資者可能關注：

• 市場情緒
• 股價趨勢
• 技術指標
• 短期事件

這些方法沒有誰一定比較正確，而是使用目的不同。

如果希望 Agent 模仿自己的分析方式，就需要把方法交代清楚。

例如：

請幫我分析這家公司值不值得投資。
按照我的分析流程：先分析商業模式，再評估競爭優勢與財務品質，最後整理長期成長因素。

這時交給 Agent 的，已經不只是任他發揮的任務。

而是自己習慣的方法步驟。

目標委派：讓 Agent 探索完成目標的方法

目標委派適合：「我知道想解決什麼問題，但不知道最佳方法。」，或是想要進行「探索」類型的工作任務。

例如：

一款 App 最近使用率下降了，我們目前只知道結果，但不知道原因。

其中的原因具體可能是：

• 新版本造成體驗問題
• 使用流程變複雜
• 競品推出新功能
• 特定市場流失

如果一開始就指定分析方法，可能會限制 Agent 的探索方向。

目標委派會提供：

Goal：
找出近期 App 使用率下降的可能原因，並提出改善方向。

User Context：
這是一款面向一般消費者的 App，目前主要市場在台灣。

Resource：附件中提供的檔案
- 使用數據
- 使用者評論
- 客服紀錄
- 更新紀錄

Definition of Done：
產出問題分析報告，包含可能原因、支持證據，以及下一步驗證建議。

接著 Agent 可以自行決定：先分析哪份資料、哪些假設值得驗證、哪些問題需要深入研究。

兩者最大的差異：

• 方法委派：我知道方法，希望 Agent 複製我的專業能力。
• 目標委派：我知道目標，希望 Agent 幫我探索達成的方法。

真正成熟的 AI 工作分身，通常會混合兩種方式

實際工作中，很少只有單純的方法委派或目標委派。

例如請 Agent 建立一份產品提案報告：

1. 我們可以讓它先自行探索資料，找出舊有產品問題，與改善設計 ← （目標委派）。
2. 接著要求最後使用自己的說服表達力框架，與公司的常規報告格式呈現 ← （方法委派）

好的使用 AI Agent 工作的方式，不是完全放手，也不是每一步都控制。真正重要的是知道：哪些事情可以讓 Agent 自己判斷，哪些地方則是需要保留自己的專業方法。

當 AI Agent 開始參與真正工作後，我們需要學習的能力，其實和主管很像。

好的主管，不會只丟一句：「幫我做 OOXX 任務，你是全村的希望，就靠你了，加油！」

然後手比愛心，轉身離開。

好的主管會讓交辦對象知道：目標、背景、好的標準是什麼，以及什麼情況算完成（DoD）。

面對 AI Agent，也是同樣的道理。不要因為對方不是真的人類，就不小心變成了慣老闆嘿 :D