TL;DR:大多數人之所以在人工智慧上掙扎，是因為他們將人工智慧視為對話。這不是對話，而是一個 系統。Google 最近強調了 PASEC 提示框架，該框架可將模糊的請求轉換為精確的指令。如果您分析這個架構，就會發現它與 Systemic Design 完全相同。提示不再是一門藝術，它現在已成為需求工程的一門學科。
Mercury Technology Solutions 首席執行官 James here。 日本千葉縣成田市 - 2025 年 12 月 18 日。
我經常看到聰明的工程師為了在 LLM 中取得好成績而煞費苦心。他們把提示框當成搜尋列或聊天視窗。他們輸入「幫我寫一份關於雲端趨勢的報告」。
然後當輸出是一般的垃圾時，他們就會抱怨。
問題不在於模型。問題在於缺乏 系統定義。
Google 最近正式制定了一個稱為 PASEC 的高品質提示框架。表面上看來，它只是另一個縮寫。但是如果您深入瞭解，它就是 Systemic Design 的藍圖。
PASEC 協定
要控制像 LLM 這樣的隨機（隨機）系統，您必須定義邊界條件。PASEC 正是這樣做的：
- P | 角色 (Who)： 定義代理的角色。
- A | Aim (What)： 定義特定的任務或功能需求。
- S | 結構 (如何)： 定義輸出介面和格式。
- E | 有效/約束 (界限)： 定義不要做的事。
- C | 上下文 (輸入)： 定義環境變數。
為什麼這實際上是系統工程
如果您有系統工程或產品架構的背景，這個結構看起來應該很熟悉。
LLM 是一個 黑盒系統。它接受輸入並將其處理為輸出。 在傳統工程中，您絕不會要求工廠「製造一輛汽車」。您會提供一份規格表。
PASEC 簡直就是智慧時代的規格表。
讓我們映射一下邏輯：
- 人物 = 系統架構：
- 工程： 「這是一台高扭矩電動馬達」。
- PASEC： 「您是一位擁有 20 年經驗的資深系統架構師」。
- 原因：它設定 作業參數和知識庫檢索權重。
- 目標 = 功能需求：
- 工程： 「馬達必須提升 500 公斤」。
- PASEC： 「您的目標是批判此程式碼的安全漏洞」。
- 原因：它定義了成功標準。
- 情境 = 環境輸入：
- 工程： 「馬達可在 -20°C 天氣下運作」。
- PASEC： 「聽眾是非技術性的董事會成員；公司面臨預算削減」。
- 原因：它提供了系統正確處理邏輯所需的 狀態變數。
- 有效（限制）=邊界條件：
- 工程： 「不要超過 240V；不要過熱」。
- PASEC：「請勿使用行話。回應字數限制在 500 字內。不要說大道理"。
- 原因：在系統理論中，約束比目標更重要。它們將解決方案的空間從 「無限 」縮小到 「有用」。
- 結構 = 介面設計：
- 工程： 「透過 3 針插頭輸出」。
- PASEC： 「輸出為 Markdown 表格，其中包含風險、影響和緩解措施等欄位」。
- 為什麼： 它可以確保輸出與工作流程的下一步（下游系統）整合。
案例研究：Vibe 與 Spec
讓我們來看看「聊天」提示和「系統」提示的差異。
「聊天」提示（失敗模式）：
「幫我寫一封電子郵件給客戶，介紹我們的新 AI 功能」。
PASEC「系統」提示（成功模式）：
- (P)個人：您是專精於 B2B SaaS 的資深產品行銷經理。
- (C)ontext：我們正在推出「Mercury AI」，可自動進行程式碼驗證。我們的客戶是對 AI 幻覺持懷疑態度的 CTO。
- (A)im： 寫一封啟動電子郵件，說服他們預約試用。注重信任和安全性，而不僅僅是速度。
- (E)ffective (Constraints): 最多 200 字。語氣應該專業但緊急。請勿使用 "Game-changer "等流行字眼。
- （S）結構：
- 主題列 (3 個選項)
- 身體 (問題 -> 煩躁 -> 解決方案)
- CTA
結論：您就是建築師
PASEC 奏效的原因並不是因為它是一種魔術。它之所以有效，是因為它迫使您將 AI 視為 計算元件，而不是魔法精靈。
我們正在邁出「提示耳語」的階段，進入 提示工程的階段。
- 說悄悄話是希望模特能聽懂您的意思。
- Engineering (工程) 是將系統定義得非常好，以至於模型除了正確之外別無選擇。
下次打開 Claude 或 ChatGPT 時，不要只是說說而已。設計系統。
Mercury Technology Solution：加速數位化。
