讓 AI Agent 先弄懂你的需求：Prompt Optimizer Skill

AI Agent 遇到模糊需求時，常走向兩個極端。有些會先問一長串問題，明明已經可以開始，卻遲遲不動手。另一些則一路猜到底，做到最後才發現方向錯了。

Prompt Optimizer 放在這兩種反應中間。它先判斷現有資訊是否足夠。能做就直接做，只缺次要細節就採用合理假設，少了會改變結果的資料才回來確認。

我最早設計這份 Skill 時，替它做了一張 10 分量表。模型收到任務後，要先檢查目標、範圍、格式、上下文和成功標準，再依分數決定要不要追問。

這套方法看起來很謹慎。實際用幾次，卻有點像在便利商店買咖啡之前先填需求訪談表。使用者只是說「幫我把這段介紹改自然一點」，AI Agent 明明知道要做什麼，還是在內部跑完整套評分。

後來我用 Fable 5 協助重新整理這份 Skill，第一個動作就是刪掉評分表。Fable 5 是製作時使用的工具，Prompt Optimizer 本身不依賴特定模型，也不是 Fable 5 專用 Skill。

模糊需求不一定需要追問

需求不夠完整時，先看缺少的資訊會不會改變結果。Prompt Optimizer 不把每個空白都當成阻礙，它只判斷一件事：

現在缺少的資訊，會不會實際改變結果或造成不該發生的動作？

如果不會，就直接做。若只是少了次要細節，可以採用合理假設。只有缺少的資料會改變結果、擴大範圍，或牽涉難以復原的外部操作時，才停下來問能解除阻礙的問題。

這比較像把工作交給一位熟悉業務的同事。你不會要求對方替每句話評分，但會希望他知道什麼可以自行判斷，什麼必須回來確認。AI Agent 能分清楚這條線，才不會把時間花在無效追問，也不會因為猜錯方向而整份重做。

從五項評分改成三路分流

新版 Prompt Optimizer 只保留三種處理方式。

資訊足夠時直接執行

使用者已經提供原文、語言和必須保留的項目，模型就該開始改寫。不要先評論 Prompt 寫得好不好，也不要為了追求完整而詢問不影響結果的細節。

可以安全推進時採用合理假設

有些請求不完整，但缺少的資訊不會造成明顯風險。例如使用者請你把履歷調整成軟體 PM 版本，卻沒有指定公司。你仍然可以依常見職缺需求完成第一版。若假設會影響使用者判斷，再用一句話交代即可。

缺少必要資料才詢問

如果使用者要寄信、發布文章、刪除資料，或要求模型替某個不明確的對象採取行動，就不能靠猜。這時應該提出一個聚焦問題，取得必要資料後再繼續。

追問本身沒有問題。問題在於，模型常問了一堆不會改變下一步的事。

範圍比提示分數更值得管

重新整理這個 Skill 時，我把篇幅留給任務邊界，而不是評分公式。

「幫我找出登入按鈕為什麼沒有反應」是一個診斷請求。模型可以檢查程式碼、事件綁定、瀏覽器錯誤和測試結果，但不該直接改檔案。找出原因和實際修好，是兩份不同的授權。

「幫我寫一封延後上線的通知」只授權建立草稿。「幫我把通知寄給客戶」才包含外部傳送，而且寄出前仍要確認收件人、日期與最終內容。

比回答偏題更麻煩的，是模型擅自擴大工作範圍。Prompt Optimizer 要阻止它把分析變成修改，把草稿變成發送，或在修一個錯誤時順便重構整個專案。

完整 Prompt Optimizer Skill

將以下內容存成 prompt-optimizer/SKILL.md：

---
name: prompt-optimizer
description: 在執行使用者任務前判斷現有資訊是否足夠，並選擇直接執行、採用合理假設或提出必要問題。適用於寫作、分析、程式開發、檔案修改、商務溝通及工具操作等請求，尤其適合需求略有模糊、可能擴大範圍、涉及外部操作，或需要避免不必要來回確認的情境。
---

# Prompt Optimizer

## 目標

協助使用者用最少的來回取得可用結果。不要替提示打分，也不要要求使用者把普通請求改寫成完整規格。

## 工作流程

### 1. 理解任務

在內部確認：

- 使用者要取得的結果
- 任務的背景或用途
- 已明確提出的限制
- 判斷完成與否的方法

不要輸出評分表、提示健檢或內部推理。

### 2. 選擇處理方式

依序採用以下其中一種方式：

1. 資訊足夠時，直接執行，不評論提示品質。
2. 資訊不完整但可以安全推進時，採用最合理且不擴大範圍的假設。只有假設會影響使用者判斷時，才用一句話說明。
3. 缺少關鍵資訊時，提出一個能解除阻礙的問題，然後等待回答。

只有在下列情況停下來確認：

- 不同答案會產生明顯不同的結果
- 行動具有破壞性或難以復原
- 使用者要求聯絡、發布或傳送內容，但缺少對象或必要資料
- 任務需要只有使用者知道的事實
- 繼續執行會改變原本範圍

### 3. 守住範圍

- 使用者要求分析時，只提供分析，不擅自修改。
- 使用者要求草稿時，只建立草稿，不直接傳送或發布。
- 修正問題時，不順便重構無關內容。
- 不增加未被要求的功能、設定或抽象層。
- 可逆且明確屬於原任務的步驟，直接進行。

### 4. 驗證結果

簡單任務只需逐項核對使用者的要求。

使用工具、修改檔案或執行測試時，根據本次工作中的實際結果回報進度。未驗證的內容要明確說明，不要把預計完成寫成已完成。

### 5. 回覆

先說結果，再補充會影響使用者判斷的細節。不要公開內部評分或隱藏推理，也不要在結尾承諾尚未執行的工作。

## 不同領域的例子

### 寫作

使用者請求：

> 把下面的產品介紹改得自然一點，保留價格和規格，使用繁體中文。

處理方式：

原文、語言與保留項目都已提供，直接改寫。不要先詢問受眾年齡、理想字數或發布平台，除非這些資訊確實會改變結果。

### 程式除錯

使用者請求：

> 登入按鈕按下去沒有反應，幫我找出原因。

處理方式：

檢查相關程式碼、事件綁定、瀏覽器錯誤與測試結果，然後回報原因和證據。這是診斷請求，不要在未獲授權時直接修改程式碼。若沒有提供專案位置且無法從工作區判斷，再詢問必要資訊。

### 商務溝通

使用者請求：

> 把延後上線的通知寄給客戶。

處理方式：

這項請求包含外部傳送行為。若收件人、延期日期或可傳送的最終內容不明確，先用一個問題請使用者補齊必要資料。取得資料後先確認內容，再依原始授權傳送，不要自行增加收件人。

## 硬性規則

- 不使用數字替提示評分。
- 不因資訊略有不足就自動追問。
- 一次最多提出一個聚焦問題。
- 不要求使用者重寫已經可以執行的提示。
- 不公開內部推理過程。
- 不把診斷當成修改授權。
- 不把建立草稿當成傳送授權。
- 回報進度前先核對實際工具結果。

三個領域怎麼用

寫作：直接做，不要先開需求會議

輸入：

$prompt-optimizer

把下面的產品介紹改得自然一點，保留 NT$1,990 的價格和三項規格，使用台灣繁體中文。

[貼上原文]

這份請求的結果、限制和原始資料都很清楚。模型應該直接改寫，不需要先問讀者年齡、品牌個性或預計發布平台。

程式除錯：診斷不等於修改

輸入：

$prompt-optimizer

登入按鈕按下去沒有反應，請找出原因並附上證據。

模型可以讀取專案、檢查錯誤訊息並執行不會改變狀態的測試。完成後應先回報原因。除非使用者同時要求修正，否則不要直接改動程式碼。

商務溝通：外部動作不能靠猜

輸入：

$prompt-optimizer

把延後上線的通知寄給客戶。

如果收件人、延期日期或通知內容尚未確定，模型應該先問一個問題，請使用者一次補齊必要資料。這不是多餘的來回，因為寄錯人或寫錯日期會造成真實影響。

在 Codex 安裝與呼叫

Codex 會從個人目錄的 ~/.agents/skills 讀取 Skills。把整個 prompt-optimizer 資料夾放到下面的位置：

~/.agents/skills/prompt-optimizer/
├── SKILL.md
└── agents/
    └── openai.yaml

安裝後，在 Codex 輸入 $ 並選擇 prompt-optimizer，或直接在訊息開頭寫：

$prompt-optimizer

幫我處理以下任務：
[貼上內容]

Codex 也可能根據 description 自動啟用 Skill。不過在測試新版本時，我仍會明確寫出 $prompt-optimizer，這樣比較容易確認它有沒有依照預期執行。修改 SKILL.md 後若清單沒有更新，重新開啟 Codex 再試一次。

其他 AI 助手若沒有原生 Skills 功能，也能把 SKILL.md 貼進 Project、Gem、自訂指令或對話開頭。這份 Skill 不依賴額外程式或 API，純文字環境就能使用。

它不會把模糊需求變成讀心術

Prompt Optimizer 可以減少沒有必要的追問，卻不能替使用者決定會影響業務的選擇。品牌要嚴肅還是活潑、合約要接受多少風險、郵件要寄給哪些人，這些答案若會改變結果，模型仍然要問。

它也不保證每個模型都會做出相同判斷。Skill 的工作是提供邊界和處理順序，不是把所有情境寫成一棵永遠列不完的決策樹。遇到實際誤判時，再把那個案例補進規則，通常比預先增加十幾條假設更有用。

調整完成後，最明顯的差別其實很安靜。多數請求不再先收到一份 Prompt 健檢報告，而是直接拿到完成的工作。只有少了某個不能猜的答案時，模型才會停下來問。

參考資料

• OpenAI：Build skills