跳到主要內容

/rewrite//brief 到底是不是 ChatGPT 的內建功能?一篇說清楚

先說結論

ChatGPT 官方不支援 /rewrite//brief 這種語法

ChatGPT (GPT-3.5 / GPT-4 / GPT-4o) 本身的 prompt 處理是自然語言為主,目前官方 API、ChatGPT 網站、OpenAI 文檔 沒有定義 /rewrite//brief 這種 Parser Prompting 語法

也就是說,丟這樣的指令,ChatGPT 會「試圖當作自然語言理解」

這類語法通常是「外掛的 parser」、「客製化的 prompt 模板」、「LangChain、Flowise、Notion AI、自建系統」做出來的 conventions,不是 ChatGPT 本體的功能。

ChatGPT 目前的行為現象,因為 2024–2025 年 GPT-4o / GPT-4-turbo 確實「開始對部分格式 prompt 有潛在 parsing 能力」,但這要拆成兩層來看,才能理解為什麼你「看起來它可以用」:

第一層:ChatGPT 現在會「嘗試理解」這種格式

GPT-4o(或 GPT-4-turbo)確實現在會:

  • 把 /rewrite 當作「你希望重寫」
  • 把 //brief 當作「風格(brief)」
  • 把 : 用一句話重寫這段內容 當作目標說明
/rewrite//brief: 用一句話重寫這段內容

因為目前 GPT-4o 裡面強化了 parsing ability

  • 有更多 “markdown parser” / “command style parser” 訓練
  • 有被大量 Slash Command prompt 訓練(Discord / Midjourney / Slack 等 prompt corpus 裡有大量 /xxx//yyy)
  • 有 exposure 到 LangChain / Prompt template 社群的 parsing 風格

所以 GPT-4o 其實「能靠類比學習」理解你這樣的 prompt,並進行正確回答。官方文檔(OpenAI API docs、Prompt Engineering Guide)目前並沒有正式定義 /rewrite//brief 這種格式是官方語法。

它是靠 LLM 本身的泛化能力 + 過去大量 prompt 模型學習資料影響,導致 GPT-4o 現在能理解這類 prompt。

  • 在自建 bot 或自建 API Wrapper 裡可以用(ex: Slack bot, Discord bot, 自建 LangChain agent)
  • 在 ChatGPT.com 直接用 → 不一定 work,要靠資料、外掛、plugin 或自建 parser。

第二層:「是不是 官方有支援規範格式?」

答案是:沒有明文規範。

官方文檔(OpenAI API docsPrompt Engineering Guide)目前並沒有正式定義 /rewrite//brief 這種格式是官方語法。

👉 它是 靠 LLM 本身的泛化能力 + 過去大量 prompt 模型學習資料影響,導致 GPT-4o 現在能理解這類 prompt。

後記及統整

為什麼你覺得「看起來可以用」?GPT-4o 已經 implicit 隱晦的學會解析這種 prompt pattern,所以你丟進 ChatGPT 裡,它「通常」能理解並正確執行

但是這種不是「保證行為」→ 未來模型更新後可能會更穩定,也可能格式規範會改變

✅ /rewrite//brief 是屬於進階 prompt parser 技巧
✅ ChatGPT 本身沒內建,但很多進階框架(LangChain、Flowise)會用這種 Parser Prompting Skill
✅ 你要用,可以自己加 parser,或改用 ChatGPT 支援的自然語言/Function Calling
✅ 學習資料已整理,依照需求選擇對應場景。

現況分類

用法 在 ChatGPT 內建 解析穩定性 備註
/rewrite//brief: xxx ✅ GPT-4o 會理解 90% 準確(目前 GPT-4o 行為) 靠語言模型學出來,不是官方明訂規範
/rewrite brief: xxx ❌ 容易被當自然語言誤解 低(常失敗) 沒有分隔符,parser 不好拆解
Function calling + schema ✅ 官方支援 100% 穩定 需要 API + schema 設定
自建 parser(LangChain 等) ✅ 自己定義 100% 控制 自己定義指令解析規則

GPT-4o 現階段支持清單

雙斜線風格 (/command//mode:)

GPT-4o 行為:幾乎 100% 理解 command + mode 結構,會照模式執行。

/rewrite//brief: 將下面這段話用一句話改寫
/translate//zh-hant: Please translate the following text.
/summarize//bullet: 幫我摘要成條列式

斜線+dash風格 (/command -mode:)

GPT-4o 行為:目前大致能理解,但比 // 稍弱(大概 80~90% 成功)。

/rewrite -brief: 用一句話改寫
/translate -zh-hant: 翻譯成繁體中文

YAML block / tag prompt

GPT-4o 行為:穩定解析,因為 YAML prompt 是官方 prompt engineering 裡常用格式。

task: rewrite
mode: brief
content: 將這段內容改寫成一句話

JSON-style inline prompting

GPT-4o 行為:穩定解析,非常推薦用於 API / GPT Builder。

{ "command": "rewrite", "mode": "brief", "content": "請改寫以下內容" }

Function-like syntax

GPT-4o 行為:解析能力佳(目前 85% 以上穩定性),容易受到 Function Calling 的學習影響。

rewrite(mode="brief"): 請改寫以下內容
translate(to="zh-hant"): Please translate this text.

冒號風格 prompt (Command: Mode: Content)

GPT-4o 行為:意外穩定(受到 Notion AI / Jasper 等工具 corpus 影響)。

Rewrite: Brief: 用一句話改寫
Summarize: Bullet: 以下文章請摘要

【目前 GPT-4o 還不穩定 / 不建議用】❌

Prompt 風格 GPT-4o 理解率 問題
/rewrite brief: xxx < 60% 沒有分隔符,容易被誤解
/command/ mode: xxx 單斜線容易被當成 URL
沒有 command,直接 //brief 開頭 缺主動詞
/command --mode xxx(雙減號) 受 CLI 語法影響,混淆概率高

目前能學的詳細文件

類別 學習資料
ChatGPT 官方 Prompt Engineering https://platform.openai.com/docs/guides/prompt-engineering
OpenAI Cookbook - Prompt 使用 https://github.com/openai/openai-cookbook
LangChain Prompt Templates https://python.langchain.com/docs/tutorials/llm_chain/#langsmith
LlamaIndex Prompt Engineering https://docs.llamaindex.ai/en/stable/optimizing/basic_strategies/basic_strategies/#prompt-engineering
Flowise Docs(圖形化 Prompt 編排) https://docs.flowiseai.com/
Midjourney Prompt Parsing https://docs.midjourney.com/hc/en-us/articles/32023408776205-Prompt-Basics
Notion AI(非公開) https://www.notion.com/help/guides/using-notion-ai
Prompt Engineering Guide(AI 社群版) https://www.promptingguide.ai/
Awesome Prompt Engineering(超級大全) https://github.com/dair-ai/Prompt-Engineering-Guide

參考來源

留言

這個網誌中的熱門文章

Vibe Coding:到底?氛圍驅動程式開發必殺技?

Vibe Coding(氛圍編程) 是由 OpenAI 共同創辦人 Andrej Karpathy 在 2025 年提出的革命性程式開發方式,它讓開發者透過自然語言與 AI 對話來生成程式碼,徹底改變了傳統的編程模式。 這種開發方式的核心理念是 「順著感覺走」 ,讓 AI 處理技術細節,開發者專注於創意和需求描述。 Vibe Coding 需要基本上的規劃和執行,但並沒有強制規範,從日常經驗來說可分為三個階段, 前期準備、開發過程、和後期維護 三個關鍵階段。每個階段都有其特定的任務和注意事項,正確執行這些步驟將大幅提升開發效率和程式品質。 將靈感與需求透過 AI 快速轉化成產品功能或原型。以下幫你分成 「前、中、後」 三階段要做的事情,適合你自己做、或帶團隊做 前期:設定 vibe & 準備素材 這個階段的重點是 「建立開發語境」 ,因為 AI 的生成表現高度依賴前期提供的上下文與資料。 明確目標 :釐清要解決的問題、預期要做的功能與核心價值。例如在筆記軟體的情境中,可能是:「我要做一款讓使用者能用 Markdown 記錄筆記,並提供標籤與全文搜尋功能的簡單 App。」 收集靈感 :觀察同類產品(如 Obsidian、Notion)、蒐集市場痛點(例如太多筆記軟體無法脫機使用,或同步效能差)。 建立語境 :準備初步 prompt、背景知識、產品定位、品牌調性、目標使用者輪廓等。 確認資源 :決定用哪些工具(Gemini、ChatGPT、設計軟體、流程管理工具等)。 確認完上述內容之後,就可以先開始進行準備規格,進行第一次的 Vibe Coding 方向驗證 提示詞模板準備 很多人會跳過這步驟,但一份 「好的 AI 提示詞模板」 將決定接下來每一次 AI 對話的品質。有效的提示詞模板需具備: 描述具體且無歧義 包含技術要求和約束條件 提供範例資料和測試案例 指定程式碼風格和慣例 例如針對筆記軟體的案例:   「建立一個支援 AI 功能純文字筆記,輸入內容可即時渲染;需支援儲存到本地檔案,提供標籤欄位做分類;以 React 架構,程式風格採用 Tailwind style components 並使用 hooks。」 開發工具選擇 開發工具的選擇 同樣重要,目前市場上主要的 ...

Claude Code Hooks:自動化與安全的最佳實踐

寫在最前頭,這份文章主要寫起來是給自己看, 同時內容是比較適合開發者,工程師們可以做些自動化處理的簡單筆記。 Claude Code hooks Claude Code hooks 是一種強大的自動化機制,允許用戶在 Claude Code 的不同生命週期階段,自定義執行 shell 指令。這種設計讓開發者能夠將規則和自動化行為嵌入到應用層級,確保每次都能可靠執行,而不必依賴 LLM(大型語言模型)是否會選擇執行某項操作。 Hooks 的核心用途 通知 :自訂收到 Claude Code 等待用戶輸入或執行權限時的提醒方式。 自動格式化 :如在每次檔案編輯後自動執行 prettier (針對 .ts 檔)、 gofmt (針對 .go 檔)等。 日誌記錄 :追蹤所有執行過的命令,便於合規或除錯。 自動反饋 :當 Claude Code 產生不符合團隊規範的程式碼時,自動給出反饋。 自訂權限 :阻擋對生產環境檔案或敏感目錄的修改[^1]。 配置與結構 Hooks 透過設定檔進行配置,分為全域( ~/.claude/settings.json )、專案( .claude/settings.json )、本地專案( .claude/settings.local.json )以及企業級策略設定。每個 hook 由「事件名稱」和「匹配器」組成: "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "jq -r '...'" } ] } ] } matcher :用於匹配工具名稱(支援正則表達式),如 Write 、 Edit|Write 、 Notebook.* 。 hooks :當匹配時要執行的命令陣列。 type :目前僅支援 "command" 。 ...

[CSS] z-index 在不同瀏覽器繼承問題

今天會討論到這個課題,是因為要實做一個Popup dialog,所以我們希望的結果如下圖。 可是在IE7 卻發生了這樣的情況。 Popup不論怎麼設定z-index都無法浮在最上層,我們看一下html架構發生什麼事情。