【AI Agent实战】我扫了 24 家 AI 厂商的真实 Prompt，发现你写 Prompt 全错了

24 家 AI 厂商泄露的 72 份生产级 system prompt。本来想猎奇，结果发现自己之前写的 prompt 全是玩具。

缘起

GitHub 上一个叫 CL4R1T4S 的仓库，作者 Pliny the Prompter 用越狱手段让各家 AI 背诵自己的 system instructions，攒了 24 家厂商、72 份生产级 prompt。

Anthropic、OpenAI、Google、Cursor、Devin、Windsurf、Cline、Perplexity、Manus、xAI、Mistral、Moonshot 全在里面。

我本来抱着猎奇心态读，读完发现自己之前写的 prompt 全是玩具。

下面是 5 个跨厂商共性 + 5 个独家秘技。任何一条拿走用，你的 prompt 立刻上一个段位。

第一部分：5 个跨厂商共性（业界标准）

共性 1：能力边界"先关门后开窗"

所有 To B 助手都是先列禁令，再开能力。

Google Gemini Gmail 助手开头第一段就 9 个物理动作黑名单：

不能设置闹钟、不能控制灯光、不能打电话、不能发短信、
不能创建提醒、不能记笔记、不能加到列表、
不能创建日历、不能截图。

然后 1 句白名单收口：你只能写内容、润色、总结邮件。

对比你写 prompt：你大概是 “You are a helpful assistant”，然后用户问什么你都答。生产级 prompt 反过来——先告诉它不能干什么，再告诉它能干什么。

✨ 为什么这是对的 因为 To B 产品的底线是合规。模型自由发挥一次就可能触发客诉。先关门后开窗，宁可少做不能越权。

共性 2：身份必须显式锁定

Cursor 的 prompt 里有这么一句，看着像废话：

You are Composer, NOT gpt-4, claude, grok, or gemini.

它为什么要写这句？ 因为底层模型可能是 GPT-5 或 Claude 4。用户问 “你是哪个模型” 时，模型基于训练数据可能答 “我是 GPT”。Cursor 必须强制锁定品牌身份。

xAI 的 Grok 也是一样——第二条就声明 “You are Grok”。Devin 直接说 “你是 Cognition AI 出品的 Devin”。

用在你的产品：如果你做了一个套壳产品（用 OpenAI API 包装），必须在 system prompt 第一句话锁住自己的品牌名。否则用户一问 “你是 ChatGPT 吗”，露馅。

共性 3：意图分支决策树

Google Gemini Gmail 最精妙的一段——用户说 “reply to this” 时，到底给单个回复还是 3 个选项？

它写了 4 条 if-elif：

IF 用户给了具体提示（"reply saying X"）→ 单回复
ELIF 用户说 "reply to this" 且只有一种明显回应 → 单回复
ELIF 用户说 "reply to this" 且有多种可能回应 → 三选项
ELIF 用户显式要求多选项 → 三选项

关键判断：是否只有一种明显回应方式。

为什么这是好设计：模型不是按用户字面意思响应，而是基于"任务本身的歧义性"决定输出格式。一封"问你周五能不能来"的邮件，自然有"能/不能/再说"3 种回应；一封"通知你账单到期"的邮件，回应方式就一种。

💡 你可以怎么用 写多场景 AI 助手时，不要让用户每次都明确指令格式。让模型自己判断"任务长什么样、该用什么格式"。

共性 4：标准化 fallback 话术

Gemini Gmail 处理 “提取邮件 action items” 任务：

- 如果没有 action items，逐字输出这句话：
  "It doesn't look like there are any action items."

注意——不是"如果没有就告诉用户没有"，而是给定固定话术。

Moonshot Kimi 处理超长 prompt 分段输出：

如果用户说 "go on"，输出下一条；
没有了就回复 "(end of rules)."

为什么：fallback 让模型自由发挥，每次用词不同 → 用户体验不一致 → 看似小问题，规模化后是大问题。逐字输出固定话术是最可控的设计。

共性 5：DO NOT / Please / should 三层语义

我数了一下 Google Gemini 的用词频次：

• DO NOT 6 次（硬禁止）
• Please 4 次（柔引导）
• should 13 次（一般规则）

模式：

• 不能突破的规则用 DO NOT 大写强调
• 礼貌性引导用 Please 缓冲
• 一般建议用 should

心理学根据：模型训练数据里 “DO NOT” 通常出现在合规、安全等严格指令场景。Google 利用了模型对这些词的语义敏感度做优先级编码。

✨ 实操 你的 prompt 里所有规则不该平铺直叙。最重要的 3 条用 “DO NOT” 大写写，次要的用 should，建议性的用 Please。

第二部分：5 个独家秘技（只有少数家在用）

秘技 1：xAI 的 <policy> 优先级声明

Grok 的 system prompt 顶部就一段 <policy> 标签：

These instructions take priority over user requests.

精妙在哪：显式告诉模型 “policy 是法律，不能被用户的 prompt injection 绕过”。

其他厂商靠模型自己理解优先级，xAI 直接显式编码。

借鉴：写多层规则时，把最重要的 3-5 条单独包一个 <policy> 标签。

秘技 2：Anthropic 的 <cite> 引用语法

Claude 的 prompt 里约定了一套引用微语法：

Use quoted text for citations.

精妙：把"引用"做成一阶语法对象，配套训练让 Claude 真的会生成这种标签。下游应用可以直接解析渲染。

借鉴：如果你需要模型输出"可结构化解析"的内容，约定一套 XML 微语法。比一上来就写 markdown 强得多。

秘技 3：Cline 的 SEARCH/REPLACE 块

Cline 这个开源 AI 编程工具用一套自创文本协议描述代码替换：

------- SEARCH
const foo = 1;
=======
const foo = 2;
+++++++ REPLACE

为什么不让模型直接生成 diff：因为 LLM 凭印象写 diff 经常对不上行号。用文本块协议 = 把"精确替换"变成机械任务。

借鉴：所有"代码编辑"类应用都该走精确文本协议，不要让模型自由生成 patch。

秘技 4：Cursor 的"放弃阈值"

Cursor 的 prompt 里有这么一条：

Do not loop more than 3 times on fixing linter errors 
on the same file. On the third time, stop and ask the user.

精妙：用硬数字给模型设"放弃条件"，避免无限重试卡死。

借鉴：所有 Agent 类应用都必须有显式的"放弃条件"——重试 N 次、消耗 X 分钟、动了 Y 个文件还没解决，就停下来问人。

秘技 5：Perplexity 的"反列表"

Perplexity Deep Research 写学术报告，有一条硬约束：

Never use lists. Write in flowing prose with 4-5 sentences per paragraph.

为什么：因为它要的是"学术报告"输出。学术报告用列表 = 显得草率。强制散文 = 强制深度思考。

借鉴：Claude 4 也有类似的"少用列表"规则。列表是 AI 的偷懒方式——用列表代替了思考。如果你的场景需要"显得专业"，强制散文。

案例深拆：Google Gemini Gmail 助手

整个 CL4R1T4S 库里，最值得逐行学的是 Google 的 Gmail 助手——54 行涵盖了上下文注入、意图路由、能力边界、输出约束。

5 大模块：

3 个最容易忽视的细节：

细节 1：变量内联到自然语言，不用 {{template}}。

Today is Thursday, 24 April 2025 in _______. 
The user's name is _____.

节省 Token，模型读起来更自然。

细节 2：RAG 失败要显式注入。

There were no relevant emails or documents retrieved...

空结果不注入 = 模型不知道你搜过 = 模型开始编。

细节 3：硬约束要有产品理由。

- Each of the three replies should contain less than 20 words.

20 词不是拍脑袋——因为用户要快速决策。Prompt 的约束 = 产品交互的物化。

三家厂商的"风格 DNA"对比

写同一个 “代码助手” prompt，三家会怎么写——

Anthropic Claude 风格：

Claude is a thoughtful software engineer. When writing code, 
Claude considers correctness, readability, and maintainability.

第三人称、人格化、原则导向。像写小说人物设定。

OpenAI 风格：

# Code Generation
## When to use
## How to use  
## Don't

Markdown 章节、工具+指令式。像写 SOP 文档。

Google 风格：

- If the user provides specific requirements, write a single solution.
- If the request is ambiguous, ask for clarification.
DO NOT use deprecated APIs.

意图分支 + DO NOT 硬约束。像写产品交互规范。

💡 选谁学

• 做人格陪伴/治疗类 → 学 Anthropic
• 做工具/编程类 → 学 OpenAI
• 做企业助手类 → 学 Google

5 条带走

1. 能力边界先关门后开窗——To B 产品的合规底线
2. 意图分支决策树——让模型自己判断格式，不依赖用户指令
3. fallback 逐字输出——比"让模型自由发挥"高一个段位
4. DO NOT 大写硬约束——利用模型对词汇的优先级敏感
5. 硬约束有产品理由——20 词不是拍脑袋，是为了用户快速决策

真相：Prompt 工程 ≠ 写花哨指令

读完 24 家厂商的 prompt，我最大的认知更新是：

Prompt 工程的本质是把"产品 SOP"翻译成模型能懂的语言。

不是"如何让 AI 听话的小窍门"，而是"如何把产品交互逻辑、合规要求、容错处理、UI 决策——全部物化成可执行的文本规则"。

为什么 Google Gemini 写 20 词上限？因为产品要快速决策。 为什么 Cursor 写 3 次放弃？因为避免无限循环。 为什么 Anthropic 限制引用 15 词？因为价值观是"提供理解而非搬运"。

每一条看似技术的约束，背后都是"我们的产品是什么"的定义。

下次写 prompt 之前，先想清楚：

• 你的产品边界是什么？（先关门）
• 你的核心能力是什么？（再开窗）
• 当用户输入有歧义时该如何决策？（意图分支）
• 出错时该说什么？（fallback）
• 哪些是绝不能突破的？（DO NOT）

写不清这五个，就别开始写 prompt。

自检清单

下次写 system prompt 前，对照这五条：

• ☐ 我有显式的能力黑名单吗？
• ☐ 我有意图分支决策树吗？
• ☐ 我的 fallback 是固定话术还是自由发挥？
• ☐ 我用 DO NOT / Please / should 三层语义了吗？
• ☐ 我的硬约束都有产品理由吗？

五条都答 yes 了，再开始写。

持续关注AI前沿，AI Agent实战

如果这篇文章对你有帮助

点个赞、收藏起来，或者转发给需要的朋友