給弱模型寫「程式」，給強模型寫「規格」。
讓第一個模型把模糊的需求轉成結構化的指令，再交給第二個模型執行。
流程：作業要求 → meta-prompt → code，中間用回饋當 oracle 做迭代。
好處： 把「需求規格化」這個工程動作外包給模型。 陷阱：
自我檢測： 把 meta-prompt 砍到只剩骨幹，看輸出品質差多少。常常差很少。
要分清楚兩種完全不同的東西：
✅ 有資訊量的 persona
「你是 Python code reviewer，重點看 production deployment 時的 race condition」
對任何模型都有用，因為它真的縮窄了任務定義。
❌ 純儀式性的 persona
「你是世界頂尖的天才超級 AI，請用你的全部智慧⋯」
對強模型是雜訊——佔了 context window 卻沒給新資訊。對弱模型有時還有用（會把輸出分佈往該領域訓練資料偏移），但對 Claude Opus 4.7 / GPT-5 Pro / Gemini 3.1 Pro 這種等級多半是冗餘。
判斷準則： 把這個 persona 拿掉，模型還能知道任務範圍嗎？
當你把每一步都寫死，模型就沒空間探索更好的解法。 對能 reasoning 的模型，這個成本特別明顯——你等於用人類的局部最優解，去取代它可能找到的全局最優解。
症狀： 提示寫得越仔細，結果越平庸、越沒新意。 對策： 給 what，不要給 how。除非 how 真的有約束（例如必須用某個 library、必須遵守某個 API）。
| 模型等級 | 例子 | 建議提示風格 |
|---|---|---|
| 頂級 reasoning 模型 | Claude Opus 4.7, GPT-5 Pro, Gemini 3.1 Pro | 短、明確、給目標跟例子，留思考空間。像跟一個資深同事討論。 |
| 一般強模型 | Claude Sonnet, GPT-5, Gemini 2.5 Pro | 中等長度，目標 + 約束 + 1–2 個例子。可加有資訊量的 persona。 |
| 小模型 / 開源模型 | Llama, Mistral, Qwen 7B–70B | 詳細 step-by-step，明確角色，多範例 (few-shot)，限定輸出格式。 |
醫師不會因為躺在手術台上的是教授就更認真，但他需要病例、X 光片、手術部位——這些是「任務資訊」，不是「身份戲份」。
學生提示詞常見的問題不是「角色不夠華麗」，而是「沒告訴模型病灶在哪」。
寫完提示後，問自己這五題：
強模型怕 over-prompt（被綁手綁腳），弱模型怕 under-prompt（自己亂走偏還很自信）。
你的提示複雜度，要 match 模型的能力等級。