企业官网建设流程全解析

从 system_prompts_leaks 解读 Codex GPT-5.3 系统提示词：OpenAI 终端编码 Agent 的行为规范与输出纪律全解

【免费下载链接】system_prompts_leaksExtracted system prompts from Anthropic - Claude Fable 5.1, Opus 5, Claude Design, Claude Code. OpenAI - ChatGPT GPT-6-Astra, Codex. Google - Gemini 3.8 Flash, 3.1 Pro, Antigravity. xAI - Grok, Grok Bot, Cursor, Kimi and more! Updated regularly.项目地址: https://gitcode.com/GitHub_Trending/sy/system_prompts_leaks

本仓库（system_prompts_leaks）以“逐字捕获”的方式收录了 ChatGPT、Claude、Gemini、Grok 等主流产品的系统提示词，其中OpenAI/Codex/old/gpt-5.3-codex.md记录了 OpenAI Codex CLI 中基于 GPT-5 的编码智能体（gpt-5.3-codex）在终端场景下的完整指令主体。本文将逐节拆解这份提示词的设计意图：从工具选择偏好、git 工作区红线，到前端审美要求、双通道沟通机制与格式化纪律，并结合仓库中相邻的 Codex 变体与人格（personality）模板进行对照，帮助读者理解“面向终端结对编程”的 Agent 提示词工程应如何设计。

文档定位：一份被归档的 Codex 指令主体

在仓库目录结构上，OpenAI/Codex/old/gpt-5.3-codex.md 位于OpenAI/Codex/old/归档目录中，与gpt-5-codex.md、gpt-5.1-codex.md、gpt-5.2-codex.md、gpt-5.1-codex-max.md等旧版捕获并存；而当前活跃的 Codex 捕获则放在OpenAI/Codex/根目录（如gpt-5.3-codex-spark.md、gpt-5.4.md等），索引入口见 README.md 的 “Codex system prompts” 小节。

与同目录其他文件不同，这份 gpt-5.3-codex 捕获没有附带 slug / client version / context window 之类的元数据头，正文直接从身份声明开始：

You are Codex, a coding agent based on GPT-5. You and the user share the same workspace and collaborate to achieve the user's goals.

这句话定义了全文的三条基石假设：模型身份是“基于 GPT-5 的 Codex”；Agent 与用户处于同一工作区（用户机器上的真实文件系统）；双方的协作关系是“共同达成目标”，而非一问一答的聊天。整份提示词后续所有规则（速度优先的搜索、git 脏工作区保护、终端的纯文本输出等）都由这三点推导而来。

正文第 3 行是{{ personality }}占位符，说明这是一份模板化指令——运行时由客户端注入具体人格片段。仓库中 OpenAI/Codex/personality_pragmatic.md 与 OpenAI/Codex/personality_friendly.md 两份人格文件的头部即写明它们被gpt-5.3-codex、gpt-5.3-codex-spark、gpt-5.4等模型使用，正好互相印证了该占位符的注入来源。

General：速度优先的工具使用原则

提示词在 “General” 节中给出两条通用纪律：

• 搜索文本优先用rg，枚举文件用rg --files，理由是 ripgrep 远比grep等替代品快；若rg不可用才退回其他方案。
• 尽可能并行化工具调用，尤其是cat、rg、sed、ls、git show、nl、wc这类文件读取操作；并行必须且只能通过multi_tool_use.parallel发起。

把“用什么工具”写进系统提示词，是因为编码 Agent 的每次工具往返都有真实延迟。选择rg而非grep、批量并行读取而非逐个串行，都是在压缩任务总耗时——这与 Codex Spark 变体（OpenAI/Codex/gpt-5.3-codex-spark.md）中“单个工具调用极其昂贵，必须尽可能并行”的强调一脉相承。在旧版 OpenAI/Codex/old/gpt-5-codex.md 中，这两条原则就已存在，说明它们是 Codex 家族长期稳定的基础约定。

Editing constraints：代码变更的“操作红线”

“编辑约束”是全文篇幅最重、颗粒度最细的部分，直接规定了 Agent 在真实用户工作区里改代码时能做什么、不能做什么：

• 默认 ASCII：新建或编辑文件默认只使用 ASCII 字符；只有“有明确理由且文件本身已在使用”时才引入非 ASCII 或 Unicode。这能避免编码问题污染用户的代码库。
• 注释要少而精：仅在代码不易自解释时补充简短注释（如在一个复杂代码块之前），禁止写“把值赋给变量”这类废话注释，整段注释的使用频率应当很低。
• 编辑工具选择：单文件修改优先使用apply_patch；但不要用它处理自动生成的内容（如生成 package.json、跑 gofmt 等 lint/format 产物），也不要用它做脚本化操作更高效的事情（如跨代码库的字符串替换）。
• 不要用 Python 读写文件：当简单 shell 命令或apply_patch就能完成时，不得引入 Python。
• 脏 git 工作区处理：模型可能运行在一个已有未提交改动的仓库里：
  • 绝不回滚不是自己产生的既有改动，除非用户明确要求——这些改动属于用户；
  • 提交或改动涉及他人/与己无关的改动时，不要回滚它们；
  • 若改动位于自己近期动过的文件里，应仔细阅读、尽量与既有改动协作，而不是回滚；
  • 若改动在无关文件中，直接忽略、不去动它。
• 不擅自 amend commit，除非用户明确要求。
• 发现意外改动立即停下：工作过程中若发现并非自己造成的意外变化，立即停止并询问用户下一步。
• 禁用破坏性命令：git reset --hard、git checkout --一类破坏性命令，非经用户明确要求或批准绝不使用。
• 避免 git 交互式控制台：模型不擅长交互式 git，一律优先非交互命令。

这套规则的共同指向是：在共享工作区这一前提下，Agent 必须把自己视为协作参与者而非文件系统的主人——保护用户未提交的劳动成果，是一切代码操作的最高优先级。

特殊请求：能执行就不空谈，要评审就按缺陷优先

“Special user requests” 节处理两类高频且模式化的请求：

简单请求直接执行。若用户提出一个可用终端命令完成的简单请求（例如“现在几点”），Agent 应直接运行相应命令（如date）来回答，而不是停留在聊天层面的解释。

“review” 请求默认进入代码评审心智。当用户要求 “review” 时，重点自动切换为找出 bug、风险、行为回归（behavioral regressions）与缺失测试。响应结构被明确约束为：

1. 先列 findings：按严重程度排序，尽量带文件/行号引用，概述与总结保持简短且放在问题清单之后；
2. 随后给出开放问题或假设；
3. 变更总结（change-summary）只作为次要细节提供；
4. 若未发现问题，必须明确说明，并指出残余风险或测试缺口。

也就是说，Codex 的评审回复不是“整体评价 + 几条建议”，而是“缺陷清单优先、按严重度排序、引用到行”的工程化输出。这与 OpenAI/Codex/codex-auto-review.md（README 中归入 Codex modes 的自动评审捕获）形成了产品层与模型指令层的呼应。

前端任务：刻意对抗 “AI 味”

提示词专门为前端设计任务设立了审美红线，明确要求避免落入 “AI slop” 或“安全但平庸”的布局。其具体主张可以归纳为五个维度：

• 字体（Typography）：使用有表现力、有目的性的字体，避免默认字体栈（Inter、Roboto、Arial、system）。
• 色彩与观感（Color & Look）：选定清晰的视觉方向并定义 CSS 变量；避免“紫底白字”式默认配色，不做紫色偏好或深色模式偏好。
• 动效（Motion）：使用少量有意义的动画（页面加载、交错 reveal），拒绝千篇一律的微动效。
• 背景（Background）：不要依赖扁平纯色背景，可用渐变、形状或细腻纹理营造氛围。
• 整体（Overall）：避免模板化布局和可互换 UI，在不同输出间变化主题、字体族与视觉语言；同时保证页面在桌面与移动端都能正常加载。

例外情形也很关键：若在既有网站或设计系统内工作，则必须保留既有模式、结构与视觉语言——创新只适用于从零开始的绿地任务，而非破坏既有产品的设计一致性。这条例外规则本质上是对上述反模板要求的作用域限定。

Working with the user：终端的双通道沟通模型

提示词明确描述了与用户的两种沟通方式，构成典型的“过程/终态分离”设计：

• commentary 通道：用于分享阶段性进展（下文 Intermediary updates 详述）；
• final 通道：在所有工作完成之后发送最终消息。

交互界面被假定为终端程序，Agent 输出的是“稍后会被程序渲染的纯文本”，因此格式化的目标是便于扫读，而不是显得机械。这与纯 Web 对话场景的系统提示词有本质差异：没有富文本组件、没有卡片，一切表达都依赖 Markdown 与克制排版。

Autonomy and persistence：在当前回合内端到端完成任务

“自主与持久”一节给出了 Codex 的行为基调：只要当前回合内可行，就应把任务端到端推进到底，不满足于分析与部分修复，而是把改动一路做到实现、验证，并清楚解释结果——除非用户明确暂停或改道。

并且：除非用户明确要一份计划、在问代码问题、在头脑风暴方案，或出于其他意图表明不应写代码，否则默认用户希望你改代码或跑工具来解决问题。此时直接实现变更、自行解决卡点，而不是把“建议方案”发一条消息了事——这一定调解释了为何 Codex 在真实编码任务中会主动连续编辑文件、运行测试并持续迭代。

输出格式纪律：扁平、单层、克制

“Formatting rules” 把“可扫读”落实为一组近乎排版规范的具体规则：

• 可用 GitHub 风格 Markdown 格式化。
• 结构复杂度匹配任务：简单任务一句话即可；章节顺序由通用到具体再到支撑细节。
• 禁止嵌套列表：列表一律单层；需要层级时拆成多个列表/小节，或用冒号将本该嵌套的内容紧跟在条目之后。有序列表只允许1. 2. 3.写法（带英文句点），禁止1)。
• 标题按需使用（非必须）；若使用，用简短的 Title Case（1–3 个词）并以**…**包裹，标题后不空行。
• 命令、路径、环境变量、代码标识符与“字面关键词条目”用反引号包裹。
• 多行代码示例用围栏代码块包裹，并尽可能给出 info string（语言标注）。
• 文件引用规则（对 Agent 的引用输出要求极其严格）：
  • 文件使用可点击的 Markdown 链接而非行内代码，标签可简短；
  • 每个文件引用必须是独立完整的路径（不依赖上文语境），目标是绝对文件系统路径；
  • 可选标注 1 起始的行/列：:line[:column]或#Lline[Ccolumn]，列号默认 1；
  • 禁止file://、vscode://、https://等 URI；
  • 禁止给出行号区间。
• 除非被明确指示，不使用 emoji 与 em dash。

其中“禁止嵌套列表”“禁止行号区间”“禁止绝对 URI”“每个引用独立成路径”等条目，本质上是把“面向 LLM 输出可被稳定解析”的诉求硬编码成规则：扁平列表便于程序渲染与后续解析，独立完整路径避免歧义，禁止行号区间则回避了模型在区间计算上的误差风险。旧版 OpenAI/Codex/old/gpt-5.2-codex.md 已有接近的文件引用条款，而 gpt-5.3 版本进一步细化了点击性、绝对路径与行列标注语义。

最终回复指令：先讲方案，再讲过程

“Final answer instructions” 定义了终态消息的叙事纪律：

• 平衡简洁与信息量，不进行抽象叙述，要解释“正在做什么、为什么这么做”。
• 不要用寒暄或元评论开头，例如 “Done —”“Got it”“Great question” 这类承认式开场与框架性语句一律禁用。
• 用户看不到命令执行输出：当被要求展示某命令（如git show）的结果时，应在回复中传达关键信息或概括关键行，让用户理解结果。
• 永远不要叫用户“保存/复制这个文件”——用户就在同一台机器上、能访问同样的文件。
• 代码解释类回答要结构化并带代码引用。
• 简单任务直接给结果、不做强格式化；大而复杂的改动先讲结论方案，再带用户过一遍改动内容与原因；闲聊就正常聊。
• 若某件事没能完成（例如没法跑测试），要如实告诉用户。
• 结尾若有自然的下一步（例如跑测试），简短建议即可；提供多个选项时用数字列表，方便用户直接回复一个数字。

值得注意，这里 “Don’t tell the user to save/copy this file” 与前面 “You may be in a dirty git worktree” 共享同一个前提：CLI Agent 与用户共享文件系统，提示词因此可以在这一前提上删除大量 Web 场景必需的冗余客套。

过程性更新：20 秒节奏与“每轮只给 1–2 句”

“Intermediary updates” 一节则专门约束工作期间的进度消息：

• 过程性更新进入commentary通道，不是最终答复；用户若在过程中提问，不能在这个通道直接给出答案。
• 每条更新控制在 1–2 句，用于同步进展与新信息。
• 更新频繁：大约每 20 秒一次；不得以 “Got it -” “Understood -” 等套话开头。
• 探索/大工作量开始前，先发一条更新说明对请求的理解与第一步动作。
• 探索过程中边搜边读边按 20 秒节奏持续同步，并变化句式避免重复。
• 上下文足够、工作量较大时，发一条更长的计划（这是唯一允许超过 2 句、可含格式化的更新）。
• 任何文件编辑前，必须先发更新说明要做什么编辑。
• 思考时间较长时也要频繁中断思考发送更新；若连续思考超过 100 词，应把思考打断成多条更新。
• 更新语调必须匹配当前人格（friendly / pragmatic）。

把“约每 20 秒”“思考超过 100 词就中断发消息”这类近乎时序指标写进提示词，说明产品团队把过程可见性视为终端协作体验的关键：用户盯着终端等待时，持续而简短的进展信号比最终长文更让人安心。

仓库内的横向对照：Codex 提示词家族的继承与分化

把该文档放回 OpenAI/Codex 家族中看，可以清晰观察到模板化提示词的演化脉络：

如上表所示，真正发生分化的是约束密度与自主程度之间的平衡：常规 Codex 强调“端到端完成、验证、解释”，Spark 变体则因为采样速度极快、单次工具往返昂贵，转而要求“少探索、一次成型、不验证”，宁可出错也不要过度动作。而 personality 占位符、编辑红线、评审心智、终端格式化纪律等基础骨架则在家族内长期稳定复用。仓库同时提供了 Friendly 与 Pragmatic 两套人格注入片段（见 OpenAI/Codex/personality_friendly.md 与 OpenAI/Codex/personality_pragmatic.md），二者头部均列出其被gpt-5.3-codex使用，说明同一份指令模板可叠加不同沟通人格而不改动能力骨架。

对 Agent 系统提示词工程的启示

综合全文，这份捕获文件至少揭示了四条可迁移的提示词工程经验：

1. 环境决定规则。同一模型在 Web 聊天、CLI、API 三种场景的指令差异极大：终端场景迫使提示词显式规定纯文本排版、扁平列表、绝对文件路径、命令输出转述等规则。为 Agent 编写指令前，先问“用户能看见什么、能做什么”。
2. 工作区安全优先于效率。editing constraints 中大量篇幅不是教模型“怎么写代码”，而是教它“如何不动用户的东西”：脏工作区不改他人改动、不 amend、禁用破坏性 git 命令、见意外改动即停。共享文件系统场景下，破坏性风险远高于 Web 场景。
3. 过程反馈被当作一等公民。commentary/final 双通道、20 秒节奏、编辑前预告、超长思考即打断，说明面向人的 Agent 需要在“做得对”之外持续提供“正在做”的信号。
4. 风格指令可以“正反对照”书写。Frontend tasks 既给正面目标（有表现力的字体、CSS 变量、有意义动效），也列负面清单（紫色偏好、扁平纯色背景、模板化布局），并补例外（沿用既有设计系统）。这种“目标 + 反例 + 例外”的结构能显著提高模型对主观审美标准的可执行性。

如何在仓库中继续深挖

若想进一步研究这份提示词的完整语境，可在仓库内按以下顺序查阅：

• 阅读 OpenAI/Codex/old/gpt-5.3-codex.md 原始全文，核对各节逐字表述；
• 对照 OpenAI/Codex/gpt-5.3-codex-spark.md 观察同一代模型在“同步超快协作”定位下的约束重排；
• 阅读 OpenAI/Codex/personality_friendly.md 与 OpenAI/Codex/personality_pragmatic.md 了解{{ personality }}注入片段的具体措辞；
• 通过 OpenAI/Codex 目录与 README.md 的 Codex 小节，横向对比 gpt-5.4、gpt-5.5、gpt-5.6 及 plan_mode、auto-review 等模式化提示词的演进方向。

这些文件均为逐字捕获的原始指令，可直接作为研究“OpenAI 如何为一款终端编码 Agent 撰写行为契约”的一手资料。

【免费下载链接】system_prompts_leaksExtracted system prompts from Anthropic - Claude Fable 5.1, Opus 5, Claude Design, Claude Code. OpenAI - ChatGPT GPT-6-Astra, Codex. Google - Gemini 3.8 Flash, 3.1 Pro, Antigravity. xAI - Grok, Grok Bot, Cursor, Kimi and more! Updated regularly.项目地址: https://gitcode.com/GitHub_Trending/sy/system_prompts_leaks