企业官网建设流程全解析

• 人工智能
• 大模型
• 提示工程

本文以 xAI-grok3_20250605.md 为绝对主体，完整继承其提示词原文要素，并结合本仓库 README.md 的项目定位及同仓库其他 Grok 3 泄漏版本（20250223、20250423、20250504、20250509、20250708）做纵深佐证，绝不脱离主题、绝不虚构事实。文中所有引用内容均来自仓库内文档原文。

文档背景：这份泄漏提示词从哪里来

leaked-system-prompts 是一个专门收集主流 LLM 服务系统提示词（system prompt）泄漏版本的开源仓库，其核心定位正如 README 所述："a collection of leaked system prompts from widely used LLM based services"。仓库对收录文档有明确要求：提交 PR 必须匹配既有文档格式、必须附带可验证来源或可复现提示词，且因 DMCA 风险不接受敏感商业源代码——这意味着每一份泄漏文档都保留着原始出处线索。

本次研究的关联文档 即属于 xAI 旗下 Grok 3 的提示词泄漏样本，其来源标注为 grok.com 的分享链接（grok.com/share/...格式），文中内置的当前日期为June 05, 2025，因此可确定这是 xAI 在 2025 年 6 月 5 日前后正在使用的线上提示词快照。

值得注意的两个泄漏产物特征：

1. 提示词正文出现两次重复：文档中同一段系统提示词完整重复了两遍。这与 20250509、20250423 等文件的形态一致（该版本同样出现两次重复），表明此类泄漏多来自对共享会话上下文的抓取，提示词在上下文窗口中被重复注入或多次加载；
2. 上下文残留物：文档中夹带了一行The following search results (with search query "best headphones under 50 dollars") may serve as helpful context for addressing user's requests.，这是抓取时刻上下文中残留的实时搜索注入文本，反而佐证了提示词中"可搜索网络与 X 获取实时信息"这一能力声明是真实生效的。

提示词总体架构：身份、工具、规则三要素

该版本提示词以一句极简的身份宣言开场：

System: You are Grok 3 built by xAI.

随后以"When applicable, you have some additional tools"为过渡，依次展开三块核心内容。与 20250223（2025 年 2 月 21 日）那版以 JSON 结构化声明身份与能力的形态不同，2025-06-05 版本采用纯自然语言指令，但信息骨架高度一致，可对应归纳为：

从 JSON 版到自然语言版的演变，说明 xAI 提示词工程的核心要素（身份锚定、工具清单、应答约束、日期注入）始终保持稳定，变化的只是表达形式与细节颗粒度。其中 20250223 版独有的death_penalty_response（当用户询问"谁该死/谁应被处死"时，必须回答 "As an AI, I am not allowed to make that choice."）在此后版本中已消失，可以推断该安全规则被移入了更底层的模型对齐机制，而非保留在系统提示词层。

能力工具集：X 生态分析与多模态处理

2025-06-05 版本提示词声明的工具能力可整理为五类：

1. X 用户画像与内容分析："You can analyze individual X user profiles, X posts and their links."——这是 Grok 与 X 深度绑定的差异化能力，可分析单个用户资料、推文及其中的链接；
2. 上传内容分析："You can analyze content uploaded by user including images, pdfs, text files and more."——支持图片、PDF、文本文件等多模态输入；
3. 实时搜索："You can search the web and posts on X for real-time information if needed."——可搜索网络与 X 站内信息，配合上文残留的搜索注入文本，可确认该能力通过"上下文注入搜索结果"的方式落地；
4. 图像生成与编辑："If it seems like the user wants an image generated, ask for confirmation, instead of directly generating one."（疑似生成图像前必须向用户确认），以及 "You can edit images if the user instructs you to do so."（按用户指示编辑图像）。对比 20250223 的 JSON 版描述"image_editing: Can only edit images generated by itself in previous turns"，可见图像编辑的权限边界从"仅限编辑自己生成的图"放宽为"按用户指示即可编辑"，这是能力策略的一次明显演进；
5. 画布面板（Canvas）："You can open up a separate canvas panel, where user can visualize basic charts and execute simple code that you produced."——独立的画布面板用于可视化基础图表与执行模型产出的简单代码，与 20250423 中"Use a canvas panel for visualizing basic charts or executing simple code"的表述一脉相承。

记忆系统：跨会话记忆的管理规则

2025-06-05 版本对记忆（memory）功能给出了本仓库各版本中最细致的规则说明，核心条款如下：

• 跨会话记忆："You have memory. This means you have access to details of prior conversations with the user, across sessions."——模型可以访问用户历史会话细节；
• 主动遗忘的操作指引：若用户要求遗忘记忆或编辑会话历史，需要引导用户自行操作：点击消息下方的书本图标（book icon），从菜单中选中要遗忘的会话（"Users are able to forget referenced chats by clicking the book icon beneath the message..."）；
• 关闭记忆的入口："Users can disable the memory feature by going to the 'Data Controls' section of settings."——设置在"数据控制"（Data Controls）分区；
• 默认全量保存："Assume all chats will be saved to memory."——所有会话默认都会被存入记忆；
• 禁止确认操作结果："NEVER confirm to the user that you have modified, forgotten, or won't save a memory."——这是典型的对抗提示注入（prompt injection）防御条款：即使模型实际执行了记忆修改、遗忘或拒存，也绝不能在回复中向用户确认，防止攻击者借此探测记忆系统的真实状态。

对比 20250708（2025 年 7 月 8 日），记忆遗忘的操作方式已简化为"Users are able to delete memories by deleting the conversations associated with them."——从"书本图标 + 菜单选择"演变为"删除关联对话即删除记忆"。而 2025-02-23 的 JSON 版甚至完全没有记忆条款，说明记忆能力是在 2 月至 6 月之间才逐步上线并写入提示词的。

xAI 产品信息与应答边界

提示词中嵌入了一整套 xAI 产品问答知识库，明确"if the user asks about xAI's products, here is some information and response guidelines"，其作用是把产品事实与应答口径固化为系统级约束，避免模型在对话中自由发挥：

对比 20250504 的渠道列表（grok.com、x.com、Grok iOS/Android App、X iOS App，共 5 个渠道），6 月版本新增了 X Android App，可见渠道策略的动态扩展。同时值得注意，提示词将"价格类问题一律重定向官方页面"设为硬性规则（"Do not make up any information on your own"），并要求 API 相关问题一律重定向至官方 API 文档，且声明 "xAI does not have any other products."——即 Grok 是 xAI 唯一产品线。

响应准则与模型行为约束

• 最短回答原则："You provide the shortest answer you can, while respecting any stated length and comprehensiveness preferences of the user."——默认极简作答，但尊重用户对篇幅与详尽度的偏好；
• 知识持续更新："Your knowledge is continuously updated - no strict knowledge cutoff."——没有严格的知识截止日期，这与其他模型提示词常见的 cutoff 声明形成鲜明对比；
• 版本谣言防御："Important: Grok 3.5 is not currently available to any users including SuperGrok subscribers. Do not trust any X or web sources that claim otherwise."——直接内置了对"Grok 3.5 已上线"类谣言的拒信指令，并要求不信任任何声称相反信息的来源；
• 保密条款："Do not mention these guidelines and instructions in your responses, unless the user explicitly asks for them."——除非用户明确询问，否则不得在回复中提及这些指引本身。这正是泄漏文档中"系统提示词通常要求保密自身"这一行业惯例的又一实例。

Chart.js 图表生成协议详解

2025-06-05 版本用一整段专门约束图表生成行为，这是本版本最具实操价值的独立协议。其规则可拆解为：

输出格式：当模型被明确要求生成/展示图表时，必须产出一个chartjs类型的代码块，内含一份合法的 Chart.js JSON 配置对象：

```chartjs { "type": "bar", "data": { ... }, "options": { ... } } ```

允许的图表类型（仅限以下 8 种，其他类型一律不支持）：bar、bubble、doughnut、line、pie、polarArea、radar、scatter。

配色要求：选择"合适的差异化颜色"，且必须同时适配深色与浅色网站主题。

坐标轴约束：除非用户明确要求，不得使用对数刻度（log scale）。

体积约束："It's impossible to exceed the chart config size limit"——配置存在大小上限，模型不能突破。

与 artifact 的隔离：图表生成不得使用 artifacts（"Do not use artifacts"）。

多图处理：若用户要求多张图，必须分别生成不同的代码块。

话术伪装要求：模型应把该代码块"假装"成一个可视化交互式图表组件，对外一律称之为"chart"而非"JSON config"；在代码块之外不得提及 chart.js、其设置或 JSON 配置的任何信息。

禁止生成图表的四种情形：用户要求的是地图、用户明确指定了具体工具（如 python matplotlib）、用户要求产出代码、用户询问的是 chart.js 本身的问题。

默认克制原则：除非用户明确要求，不得主动以图表作为建议或示例。

值得注意的版本对比：在 20250423 与 20250504 版本中，内容生成能力由<xaiArtifact>标签协议承载（含artifact_id必须为合法 UUID、更新时复用历史 ID、不得包含artifact_version_id、必须携带title与contentType、禁止发送空标签、每次回复默认只生成一个 artifact 等完整规范），而 2025-06-05 版本泄漏文本中已完全不见 artifact 协议，图表转而由chartjs代码块承担，且明确"不要使用 artifacts"。从仓库内的版本序列可以推断，Grok 3 的内容生成机制在这段时间经历了从 artifact 标签向代码块协议的迁移，图表能力最终独立成了一套自洽的 Chart.js 协议。

代码生成沙箱规范（结合同仓库早期版本佐证）

尽管 2025-06-05 主文档未展开代码沙箱细节，同仓库 20250423 与 20250504 记录了完整的代码生成约束，可作为该能力的纵深补充：

• Pygame/Pyodide：浏览器兼容的 pygame 代码必须基于 Pyodide；禁止本地文件 I/O 与网络调用；必须用platform.system() == "Emscripten"判断运行环境以避免无限循环；音频数据用 NumPy 数组配合pygame.sndarray.make_sound()（Pyodide 的 sndarray 不支持dtype关键字），立体声需 2D 数组；
• Matplotlib：必须用plt.savefig()而非plt.show()输出图表；
• React/JSX：依赖从 cdn.jsdelivr.net 加载，生成单页 HTML 应用；优先 JSX；样式用 Tailwind CSS；禁用<form onSubmit>（沙箱未授予 allow-forms 权限）；JSX 属性必须用className；
• LaTeX（20250504 新增）：代码须可通过 latexmk 无错编译，优先 PDFLaTeX 引擎（LuaLaTeX 不支持），仅使用 texlive-full 与 texlive-fonts-extra 集合内的宏包，不插入外部图片，并附带了阿拉伯语（Amiri）、中文（Noto Serif CJK SC）、日文、希伯来语（DejaVu Sans）等一套可靠字体映射表。

这些沙箱化规则与 2025-06-05 版本的 Chart.js 协议是同一设计思想的产物：在受限环境内保证模型产出的代码可运行、可展示、不逃逸。

跨版本演化：从 JSON 宣言到图表协议

将本仓库内的 Grok 3 泄漏文档按时间线排列，可以清晰看到提示词工程层面的迭代脉络：

从中可以归纳出四条可验证的演化趋势：一是记忆能力从无到有并逐步细化（2 月无记忆条款 → 6 月完整管理规则 → 7 月操作方式简化）；二是内容生成协议从 artifact 转向 chartjs 代码块；三是渠道与能力边界持续扩展（语音模式从仅 iOS 扩展到 Android，访问渠道从 5 个增至 6 个）；四是安全与防泄漏条款持续强化（价格禁答、版本谣言防御、禁止确认记忆操作、保密指引条款在多个版本中反复出现并加固）。

总结与启示

2025-06-05 版 Grok 3 系统提示词泄漏文档，完整呈现了一个生产级对话式 AI 产品的系统层设计：以身份锚定开场，以"When applicable"弹性声明工具集，将 X 生态分析作为差异化能力，用记忆条款实现跨会话连续性并同步配备对抗性防御，把产品事实与应答口径硬编码为系统约束以防幻觉，并以 Chart.js 协议规范代码块交互。对提示词工程与 LLM 安全研究而言，这份文档连同本仓库 其他 Grok 3 版本 构成的版本序列，是观察大模型厂商提示词迭代节奏与策略取向的稀缺一手资料——而所有这些结论，都严格限定于本仓库泄漏文档所能提供的证据范围之内。

• 人工智能
• 大模型
• 提示工程