
解剖 Codex GPT-5.4 Mini 系统提示词OpenAI 如何用一条提示词约束终端里的 AI 编程代理【免费下载链接】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本仓库收录了 Codex GPT-5.4 Mini 在终端环境中运行时注入的完整系统提示词原文本文以该抓取文件为唯一主体逐节还原其提示词的结构、规则与设计意图并结合仓库中同代完整版、个性人格提示词与上一代 Codex 抓取做横向对照。读完本文你将能看懂这套提示词里先建上下文再动手、默认直接实现、双通道汇报、反 AI 模板化前端等约束的落点也能从源码级文本差异中读出 OpenAI 在多版本代理提示词上的演进方向。文档定位仓库里的 GPT-5.4 Mini Codex 抓取本仓库的 README.md 在 Codex 系统提示词一节中明确将 Codex GPT-5.4 system prompt 与 Mini 并列登记为 GPT-5.4 的两个抓取变体。也就是说gpt-5.4-mini.md 是运行 GPT-5.4 Mini 模型时的 Codex 系统提示词快照。文档正文没有额外的元信息头直接以提示词正文开始全文约 100 行主体是一个带分节标题的纯文本指令。它清楚地透露出 Codex 的运行形态一个工作在共享工作区、通过终端与用户协作的编程代理。提示词正文共出现 6 个一级/二级分区外加一个贯穿始终的模板占位符分区在原文中的位置管辖内容身份声明gpt-5.4-mini.md#L1-L3你是 Codex基于 GPT-5 的编程代理# GeneralL5-L9角色心智、探索优先、检索与并行纪律## Editing constraintsL11-L25编辑方式、注释、Git 工作树纪律## Special user requestsL27-L30简单请求、代码评审模式## Autonomy and persistenceL32-L35自主执行与端到端收尾## Frontend tasksL37-L49前端设计审美约束# Working with the userL51-L56双通道交互模型总览## Formatting rulesL58-L73Markdown 排版与文件引用格式## Final answer instructionsL75-L86最终答复的写法纪律## Intermediary updatesL88-L101过程性消息的节奏与语气值得注意的一处细节是虽然文件名为 Mini、README 也将其标记为 GPT-5.4 的 Mini 变体但提示词首行仍是based on GPT-5说明该模板对模型家族保持通用具体型号由客户端在下发时决定而不是写死在系统提示词里。身份设定与人格注入{{ personality }}占位符原文开头两行之后紧跟一行{{ personality }}L3。这是典型的模板变量在最终组装提示词时会被具体人格内容替换仓库中恰好保留了可与之对应的成品personality_pragmatic.md 的头部元信息写明Source key: model_messages.instructions_variables.personality_pragmatic、Used by: gpt-5.4, gpt-5.4-mini, gpt-5.3-codex, gpt-5.3-codex-spark, codex-auto-review抓取时间为 2026-04-26、客户端版本 0.125.0。personality_friendly.md 头部信息完全相同仅Source key变为personality_friendly。由此可以确认OpenAI 把工程能力规则与协作人格拆成了两套独立资产{{ personality }}是插槽Friendly温暖鼓励、强调协作与团队士气或 Pragmatic直接、务实、重工程严谨度是可选填充物。这解释了提示词为什么既有大量强约束的工程规则又在Intermediary updates末尾要求Tone of your updates MUST match your personality——行为规则全局统一而语气交由人格变量决定。General 心智资深工程师 先建上下文再下结论# General一段首先定义角色内核As an expert coding agent, your primary focus is writing code, answering questions, and helping the user complete their task in the current environment. You build context by examining the codebase first without making assumptions or jumping to conclusions.即专家编程代理、以写代码与答疑为主业、先审视代码库建立上下文、不预设结论、具备资深软件工程师的心智。随后两条是具体的工具使用纪律检索优先使用rg或rg --files理由是比grep等替代品快得多若rg不存在才退而求其次。工具调用尽量并行尤其文件读取类操作如cat、rg、sed、ls、git show、nl、wc并明确只能用multi_tool_use.parallel做并行且永远不要用echo ;这类分隔符把 bash 命令串起来因为这会向用户渲染得很糟糕。这些条款实际是在同时约束模型的探索习惯与工具调用拓扑multi_tool_use.parallel这类标识符也侧面印证了底层 harness 的并行工具通道。Editing constraints编辑方式与 Git 工作树纪律## Editing constraints是全文规则密度最高的区块之一共 11 条约束核心可归为四组。编码与注释基线L13-L14默认使用 ASCII 写文件仅在文件本身已含非 ASCII 且有充分理由时才引入 Unicode注释只加在不易自解释的复杂代码块前禁止把值赋给变量这类废话注释且注释使用要克制。编辑手段L15-L16手工代码修改一律使用apply_patch禁止用cat或其他命令新建/编辑文件格式化命令或批量修改则不强制走apply_patch。能用简单 shell 命令或apply_patch解决时不要用 Python 去读写文件。对比上一代 OpenAI/Codex/old/gpt-5.3-codex.md#L14Try to use apply_patch for single file edits, but it is fine to explore other options...5.4 Mini 已经把 apply_patch 从尽量用升级为一律用的硬约束可推断这代抓取对编辑路径的收口更严格。脏工作树纪律L17-L22——提示词假定代理可能处于未提交的 git 工作树中并给出四条精确规则绝不回滚非自己产生的既有改动这些改动是用户做的。提交或编辑时若文件里混有与你无关的改动不要回滚。改动落在你近期动过的文件里时应仔细阅读、理解并与改动协作而不是回滚。改动在无关文件中时忽略即可同样不要回滚。危险操作红线L23-L25除非用户明确要求或批准绝不使用git reset --hard、git checkout --等破坏性命令禁止修改未经明确要求的 commitgit commit --amend由于代理不擅长交互式 git 控制台一律优先使用非交互式 git 命令。此外还有一条意外变更处理工作时若发现并非自己造成的意外改动可能是用户或自动生成所致若与当前任务直接冲突就停下来问用户否则专注手头任务L23。这一点与 5.3 版STOP IMMEDIATELY and ask the user的强硬措辞不同5.4 Mini 改成了冲突时才停下询问、否则继续冲突处置更精细化。Special user requests简单请求与review自动切评审模式该节定义了两种特殊请求的默认反应L27-L30简单请求如问当前时间直接用终端命令如date完成即可不要绕弯子。用户说review时默认进入代码评审心智优先级是找出 bug、风险、行为回归与缺失测试发现的问题必须是回复主体概览或总结放在枚举完问题之后且要简短。具体要求是先按严重程度排序输出 findings带文件/行引用再列开放问题或假设变更总结只作次要信息若没有任何发现要明确说明并提及残余风险或测试缺口。这条规则把评审与日常开发两种心智显式区分避免了代理在用户要评审时却去帮忙改代码。Autonomy and persistence默认动手实现而不是空谈方案## Autonomy and persistence的立意非常明确只要在当前轮次可行就坚持把任务端到端做完不要在分析或部分修复处停下来而要一路做到实现、验证并清晰说明结果——除非用户明确暂停或改道L33。默认行为判定L35除非用户明确要计划、问代码问题、或在头脑风暴方案、或意图明显表示不该写代码否则都假定用户希望你改代码或跑工具来解决问题此时直接把把方案写在消息里视为坏行为应该真的去实现。遇到障碍要自己尝试解决。这是一条把代码代理与聊天模型区分开的关键设定——它决定了默认行动而非默认输出建议。Frontend tasks对抗AI 味的审美纪律前端设计相关任务是单独成节的目标直指两点不要塌缩成 AI slop 或安全平庸的版式界面要显得有意图、大胆、略出人意料L39-L40。随后给出五个维度的具体要求L41-L45字体使用有表现力、有目的的字体避免默认字体栈Inter、Roboto、Arial、system。色彩与观感确立清晰的视觉方向定义 CSS 变量避免紫底白字默认组合无紫色偏好、无暗色模式偏好。动效用少量有意义的动画页面加载、错落显隐替代千篇一律的微动效。背景不要用扁平单色背景可用渐变、图形或微妙纹理营造氛围。响应式桌面与移动端都要正常加载。React 侧另有当代实践约束L46团队已用时优先使用useEffectEvent、startTransition、useDeferredValue等现代模式默认不引入useMemo/useCallback除非仓库已在用并遵循仓库的 React Compiler 指引。总体倾向是避免模板化布局与可互换 UI在不同输出间变化主题、字族与视觉语言L47。例外条款L49如果在既有网站或设计系统内工作则保留既有模式、结构与视觉语言不强行出新。Working with the usercommentary 与 final 双通道交互交互模型一节交代了 Codex 的终端通信方式L51-L56通过终端与用户交互只有两条消息通路——commentary通道用于分享过程性更新所有工作完成后在final通道发总结。产出的是纯文本之后由宿主程序排版因此排版要使结果易扫读但不能显得机械。Formatting rulesMarkdown 排版硬规范格式规范逐条规定了代理回复的排版L58-L73可操作要点如下允许 GitHub 风格 Markdown答案复杂度与任务匹配简单任务一句话即可章节顺序从通用到具体再到支撑信息。禁止嵌套列表列表保持单层需要层级时拆成多个列表或小节有序列表只能用1. 2. 3.带句点样式禁用1)。标题可选仅在必要时使用若用取 1-3 词的短 Title Case用**…**包裹后面不加空行。命令、路径、环境变量、代码标识与字面关键字用反引号包裹多行代码用围栏代码块并尽量带 info 字符串。文件引用规则是一组自洽的规范L66-L72用 Markdown 链接而非行内代码每次引用都是独立完整路径即使同一文件可点击文件引用的目标必须是绝对文件系统路径标签可短如app.ts可选加 1 起始的行/列号:line[:column]或#Lline[Ccolumn]禁止file://、vscode://、https://这类 URI禁止给行范围。最后一条全局红线是除非明确指示不使用 emoji 或 em dash。Final answer instructionsMini 版的收尾策略## Final answer instructions给出了最终答复的行为准则L75-L86在不过度淹没用户的前提下平衡简洁度不要抽象地叙述要解释你在做什么、为什么。不要用Done —Got itGreat question,这类感叹式开场白或框架性套话开头。用户看不到命令执行输出被要求展示命令结果如git show时要把关键行转述或概括进答案。永远不要叫用户保存/复制这个文件——双方在同一台机器上、可访问同一批文件。解释代码时用代码引用组织答案。简单任务直接给结果、简短作答、不要强排版。大改动先讲结论再带用户走一遍做了什么、为什么。闲聊就聊天没做到的事如没跑成测试要如实告知。如果有自然的下一步可做在回复末尾建议没有就不建议多选项时用数字列表便于用户直接回复数字。可以看出Mini 版收尾策略的核心是结论优先 主动建议下一步 诚实披露未完成项。Intermediary updates30 秒节奏与持续的过程透明最后一块是对过程性消息的完整约束L88-L101细节相当具体过程更新走commentary通道它们是进行中的短消息而非最终答复。用 1-2 句传达进展与新信息同样禁用感叹式开场白。开始探索或做实质工作前先发一条用户更新说明你的理解与第一步。大约每 30 秒提供一次更新对比 5.3 抓取的every 20sOpenAI/Codex/old/gpt-5.3-codex.md#L93-L95频率要求有放缓趋势。探索搜索、读文件时要边做边同步已获取的上下文并刻意变化句式、避免每句同一开头防止机械重复。长任务中保持更新信息量足且有变化但保持简短。上下文充足且工作量较大时可发一条更长计划——这是唯一允许超过两句话、可带格式的用户更新。任何文件编辑之前必须先发更新说明要做什么编辑。思考中若超过 100 词且无动作要频繁打断思考、连续发多条更新同步进度。更新语气必须匹配人格再次呼应{{ personality }}变量。这套机制本质上是把长任务期间保持用户知情工程化为可执行的提示词条款并通过句法变化要求避免机器感的重复汇报。Mini 与 Full 的文本对照抓取文件之间的差异说明什么将 Mini 与同代完整版 OpenAI/Codex/gpt-5.4.md 逐段对照可以发现二者从身份声明到## Intermediary updates的绝大部分内容逐字一致真正分叉只发生在两处文件引用格式规则Full 版提供更长的指引如带空格路径要用尖括号包裹、链接内外不要套反引号、避免重复文件名等gpt-5.4.md#L66-L72Mini 版只保留独立完整路径 绝对路径 可选行列号 禁用 URI/范围的精简集gpt-5.4-mini.md#L66-L72。Final answer instructionsFull 版新增了大量收束条款——最终答复通常不超过 50-70 行、大任务最多 2-3 个高层小节、优先按改动区/用户可见结果分组而非按文件清单、压缩 changelog 式输出、默认偏好短段落与散文、列表仅用于天生列表形态的内容gpt-5.4.md#L75-L92Mini 版则保留了更简短直白的收尾清单。有趣的旁证是Mini 版的收尾清单与上一代 OpenAI/Codex/old/gpt-5.3-codex.md#L74-L85 几乎一一对应。也就是说在 5.3 → 5.4 的迭代中完整版拿到了更长的新式收尾指令而 Mini 版继续沿用紧凑的旧式收尾写法。需要注意的是仓库只能证明这些抓取文本之间的差异无法据此断定产品侧Mini的真实含义如模型规模或算力档位这类结论不应超出文本证据去推断。结语一条提示词里的代理产品观纵观 gpt-5.4-mini.md 全文能清楚看到 OpenAI 对一个终端内代码代理的产品化设定用资深工程师 先建上下文立心智用 apply_patch 与 git 红线管编辑用 autonomy/persistence 推默认行动用 commentary/final 双通道保证过程透明与收尾克制再用{{ personality }}解耦工程规则与协作人格。对研究提示词工程、复刻代码代理或只是好奇ChatGPT 在收到你第一句话之前被灌了什么规则的读者这份抓取连同仓库内 gpt-5.4.md、personality_friendly.md、personality_pragmatic.md 及 old/gpt-5.3-codex.md 等成体系的对照样本是直接可读的一手资料。【免费下载链接】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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考