簡而言之：大多數人與 AI 互動時會遇到困難，因為他們將其視為對話。這不是對話；這是一個 系統。 Google 最近強調了 PASEC 提示框架，該框架將模糊的請求轉化為精確的指令。如果你分析這個框架，你會發現它與 系統設計 是相同的。提示不再是一門藝術；它現在是一門需求工程的學科。
我是 James，Mercury Technology Solutions的 CEO。 日本千葉成田 - 2025 年 12 月 18 日
我經常看到聰明的工程師在從 LLM 獲得良好結果時掙扎。他們將提示框視為搜尋欄或聊天窗口。他們輸入："寫一份關於雲端趨勢的報告。"
然後當輸出是普通的垃圾時，他們會抱怨。
問題不在於模型。問題在於缺乏 系統定義。
Google 最近正式化了一個高品質的提示框架，稱為 PASEC。表面上看，它似乎只是一個縮寫。但如果你深入了解，它是一個 系統設計 的藍圖。
PASEC 協議
要控制像 LLM 這樣的隨機系統，你必須定義邊界條件。PASEC 正是這樣做的：
- P | 人物 (誰)： 定義代理的角色。
- A | 目標 (什麼)： 定義具體的任務或功能需求。
- S | 結構 (如何)： 定義輸出介面和格式。
- E | 有效性/約束 (邊界)： 定義什麼是 不 要做的。
- C | 上下文 (輸入)： 定義環境變數。
為什麼這實際上是系統工程
如果你有系統工程或產品架構的背景，這個結構應該看起來非常熟悉。
LLM 是一個 黑箱系統。它接受輸入並將其處理為輸出。在傳統工程中，你不會要求工廠 "製造一輛汽車"。你會提供一份規格表。
PASEC 只是智慧時代的規格表。
讓我們映射邏輯：
- 人物 = 系統架構：
- 工程： "這是一個高扭矩電動馬達。"
- PASEC: "您是一位擁有20年經驗的資深系統架構師。"
- 為什麼: 它設定了操作參數和知識庫檢索權重。
- 目標 = 功能需求：
- 工程： "這個馬達必須能夠提升500公斤。"
- PASEC: "您的目標是對這段程式碼進行安全漏洞的評論。"
- 為什麼: 它定義了成功標準。上下文 = 環境輸入：
- 工程：
- "這個馬達在-20°C的環境下運行。"PASEC:
- "觀眾是非技術性董事會成員；公司面臨預算削減。"為什麼:
- 它提供了狀態變數，以便系統能夠正確處理邏輯。有效（約束）= 邊界條件：
- 工程：
- "請勿超過240V；請勿過熱。"PASEC:
- "請勿使用行話。將回應限制在500字以內。不做道德說教。"為什麼:
- 在系統理論中，約束比目標更為重要。它們將解決方案空間從「無限」縮小到「有用」。結構 = 介面設計：
- 工程：
- "通過3針插頭輸出。"PASEC:
- "以Markdown表格形式輸出，包含風險、影響和緩解的欄位。"為什麼:
- 它確保輸出能夠與您工作流程中的下一步（下游系統）整合。案例研究："Vibe" 與 "Spec"
讓我們看看 "Chat" 提示與 "Systemic" 提示之間的區別。
「Chat」提示（失敗模式）：
"幫我寫一封關於我們新AI功能的客戶電子郵件。"
PASEC "Systemic" 提示（成功模式）：
(P)ersona:
- 您是一位專注於B2B SaaS的資深產品行銷經理。(C)ontext:
- 我們正在推出 "Mercury AI"，這是一個自動化代碼驗證的工具。我們的客戶是對AI幻覺持懷疑態度的CTO。(A)im:
- 撰寫一封推廣電子郵件，說服他們預約演示。重點放在信任和安全上，而不僅僅是速度。(E)ffective (Constraints):
- (E)ffective (Constraints):最多 200 字。語氣應該專業但緊迫。請勿使用像「改變遊戲規則」這樣的流行詞。
- (S)結構：
- 主旨行（3 個選項）
- 內容（問題 -> 激發 -> 解決方案）
- 行動呼籲（CTA）
結論：您是架構師
PASEC 有效的原因不是因為它是一個魔術把戲。它之所以有效，是因為它迫使您將 AI 視為一個計算元件而不是一個魔法精靈。
我們正在從「提示低語」的階段轉向「提示工程」的階段。低語是希望模型能理解您。
- 工程是如此明確地定義系統，以至於模型別無選擇，只能正確。
- 下次您打開 Claude 或 ChatGPT 時，請不要只是交談。設計系統。
Mercury Technology Solutions：加速數位化。Design the system.
Mercury Technology Solutions: Accelerate Digitality.
