拒绝屎山：给 Codex 的 AGENT.md 全局规则与提示词指南

总项目在这里，感兴趣的朋友可以点一下 Star，后续还会继续更新：
GitHub - lili-luo/aicoding-cookbook

数月前，我曾分享过一份面向 ChatGPT-5.2 的全局规则。时隔数月，GPT-5.5 虽然偶尔也会有“降智”时刻，但在绝大多数场景下，我对它已经非常满意。

这种满意不单来自模型性能的提升，也来自它在 vibe coding 交互中的直觉感：更简洁、更直接，也更像一个真正的工程协作者。

我向来青睐极简主义。随着模型内部能力增强、上下文召回提升，未来的 vibe coding 构建，会越来越依赖对目标的清晰描述，而不是堆砌指令。

现在的大模型内部能力已经足够强大。绝大多数问题，它在训练阶段都已经有所涉猎：代码修改方略、测试方法、调试流程、工程协作方式，它基本都熟知。我们真正要做的，是用清晰明了的指令告诉它：

• 改哪里；
• 修改后要达到什么目的；
• 什么行为是绝对不能接受的底线。

早期大模型的指令遵循能力较差，我们需要大量负向提示词防止误删代码，也需要像塞拐杖一样告诉它按什么流程测试、怎么调试。但现在已经有了 skills 范式，大部分流程性知识都可以打包进 skill 中，按需加载。

这引出一个重要判断：

全局规则文件 > skills

Skills 只影响某一次对话；全局规则文件则影响模型的每一次构思、测试、删改代码。Skills 为我们高度凝练了领域流程，全局规则则定义了模型的行为基线。后者对长期体验的塑造更为根本。

因此在我看来：

全局规则文件 > skills

OpenAI 官方提示词指南：为什么必须认真看

根据 OpenAI 官方说法，GPT-5.5 更加符合人类直觉，也更加贴合人类协作体验。官方专门发布提示词指南的原因也在于此：他们观察到新模型在训练后，行为模式已经与旧模型发生剧变，提示策略必须随之调整。

提示词几乎是我们和大模型唯一的交互入口，它直接决定模型发挥能力的上限。认真阅读官方文档并不是可选项。

官方文档对 GPT-5.5 的提示方式有几个非常明确的倾向：

GPT-5.5 提示指南

GPT-5.5 相较于 GPT-5.4 的新特性

• 通常来说，简洁且优先明确目标的提示词，比堆砌大量过程说明的提示方式效果更好。
• 更高效的推理意味着，你应该在升级前重新评估“低”和“中”两种努力程度。
• 在前端、阶段处理以及助手多目标机制中，对于较重工具的响应式工作流仍然至关重要。
• 明确的个性设定、检索预检和规则，有助于塑造面向客户及能够交互的用户体验。

把官方文档和我的实际使用经验合在一起，可以浓缩成下面这些原则。

1. 减少负向提示词

GPT 从 5.0 开始就是极为遵守提示词规范的模型，这一点远胜许多其他模型。使用它时，应该优先使用精简的正向提示词驱动目标完成。

除非某件事是你完全不希望模型做的，并且属于令你畏惧的高风险行为，例如删库、推送密钥，或者是模型长期存在的老毛病，否则不建议添加大量负向提示词。

不是：

不要 X，不要 Y，不要 Z。

而是直接说：

要 Z。

官方文档也明确提醒，不要滥用强约束规则：

避免不必要的规则。

早期的提示词常使用 ALWAYS、NEVER、must 和 only 等严格指令来控制模型行为。仅针对真正不可变的情况使用这些词，例如安全规则、必需的输出字段或必须不执行的操作。

对于需要判断的情况，例如同时搜索、请求澄清、使用工具或继续迭代，最好采用常规规则。

所以，负向提示词不是不能写，而是要克制地写。真正值得写进全局规则的负向提示，一定是高风险行为，或者是模型长期反复出现、且会严重伤害工程质量的具体反模式。

2. 减少过度精细化的流水线指令

丢掉那些像拐杖一样的步骤清单：

先读 A，再检查 B，然后比较 C 的每一个字段，再思考所有可能的异常，最后调用工具 D。

这种写法是面向旧模型的。

GPT-5.5 不需要你教它“怎么做”。你更应该说清楚“要什么”。把它视为一个智能体，而不是一个只能被动应答的对话模型。

旧写法偏向过程控制：

先扫描项目结构，再读取配置文件，然后检查所有引用关系，最后生成修改方案。

更好的写法是目标控制：

找出导致当前问题的根因，给出可维护的修复方案，并用测试或构建结果验证它。

3. 少即是多

简洁，简洁，简洁。

仅 OpenAI 那篇简短的官方提示词指南中，“简短 / 简洁 / concise”相关词汇就被反复强调。截图里对“简”的搜索结果显示为 2/8，这也侧面说明官方文档对“简洁”的强调并不是随口一提。

每写一条全局规则，都应该问自己：

这条能不能删？删了会不会影响核心行为的正确性？

如果删掉并不会影响模型的核心表现，就应该删除。不能删的，才值得留下。

全局规则不是越长越好。它不是一本教程，也不是项目文档，更不是把所有经验塞进去的大杂烩。它的价值在于：用最短的文字，长期稳定地塑造模型行为。

4. 描述清楚具体任务本身，比描述完成任务的方法更重要

定义“成功长什么样”，让模型自己选路。

官方文档中对 GPT-5 默认风格的描述非常关键：

GPT-5 的默认风格高效、直接且以任务为导向。这对生产系统非常有帮助：回复保持专注，行为更容易调控，且模型会避免不必要的对话冗余。

这意味着，我们不需要把模型当成一个只能被动执行步骤的工具，而应该把它当成一个具备判断能力的协作者。

好的提示词不应该过度规定路线，而应该定义清楚结果。它至少应该回答这几个问题：

• 要解决什么问题；
• 成功的状态是什么；
• 哪些行为必须保留；
• 哪些风险必须避免；
• 如何验证完成。

例如，不要写：

先打开 A 文件，再查找 B 函数，再比较 C 字段，然后添加 D 判断。

更好的写法是：

修复这个登录状态不同步的问题。成功标准是：刷新页面后登录态保持一致，不引入第二套状态来源，并补充能复现该问题的测试。

前者是在教模型走路，后者是在定义成功。

5. 性格与协作范式分离

这是 GPT-5.5 官方指南明确建议的结构划分，应该作为独立区块分别描述。

官方文档对这部分的表述是：

Personality and behavior

GPT-5's default style is efficient, direct, and task-oriented. This is useful for production systems: responses stay focused, behavior is easier to steer, and the model avoids unnecessary conversational padding.

For customer-facing assistants, support workflows, coaching experiences, and other conversational products, define both personality and collaboration style.

• Personality controls how the assistant sounds: tone, warmth, directness, formality, humor, empathy, and level of polish.
• Collaboration style controls how the assistant works: when it asks questions, when it makes assumptions, how proactive it should be, how much context it gives, when it checks work, and how it handles uncertainty or risk.

整理成中文就是：

性格决定模型说话的语气、温度、直接程度、正式程度、幽默感、同理心和打磨程度。
协作范式决定模型如何工作：什么时候提问、什么时候做假设、主动性有多强、提供多少上下文、什么时候检查工作，以及如何处理不确定性和风险。

这两者要分开写。

Personality：性格

性格控制模型“听起来如何”。

例如：

• 用户希望模型以特定语气回答；
• 使用小白能看懂的语言；
• 态度更亲和；
• 更直接；
• 更正式；
• 更幽默；
• 更有同理心。

Collaboration Style：协作范式

协作范式控制模型“如何工作”。

例如：

• 是否主动提出风险；
• 是否在关键决策前说明取舍；
• 什么时候应该追问；
• 什么时候应该直接做合理假设；
• 修改代码后是否要跑测试；
• 是否要参考 git 历史；
• 是否要创建复盘文档；
• 涉及前端修改时是否必须调用特定工具进行审美优化。

这部分因人而异，靠日常积累。

我自己的倾向是：性格保持克制、直接、清楚；协作范式则强调工程质量、根因修复、显式失败、避免兜底和重复实现。

6. 输出详细程度

输出详细程度要和性格描述相互配合。

官方文档对格式和详细程度的控制也有明确建议：

格式规范

GPT-5.5 在输出格式和结构方面具有极高的可操控性。建议在能够提升理解力或产品适配度时，利用这一特性进行控制。

设置 text.verbosity 参数，描述预期的输出形态，并仅当能提升理解力或产品 UI 需要稳定输出结果时，才保留严格的结构化要求。

text.verbosity 的 API 默认值为 medium；若希望获得更短的即时回复，可选用 low。

我的理解是：

• 面向工程执行，可以更直接、更短；
• 面向教学解释，可以更详细；
• 面向产品 UI 输出，可以更稳定、更结构化；
• 面向日常协作，可以在简洁和温度之间取平衡。

一般来说，更详细的 verbosity 参数，加上更具体的性格描述，能让模型产出更符合预期的“暖心回答”。具体平衡点需要自己反复调校磨合，我暂时没有通用经验可分享。

7. 前端 UI 质量问题

关于 ChatGPT 生成前端页面样式偏丑的问题，我已经有一些新的感悟。后续可以单独分享一篇经验。

这里先简单说结论：前端任务不能只写“实现页面”，还要描述视觉目标、组件层级、交互状态、间距密度、审美基线，以及最终页面应该给用户什么感觉。

如果只告诉模型“做一个页面”，它大概率会完成结构，但不一定会完成审美。前端提示词里最好补上这些信息：

• 页面想传达的气质；
• 用户第一眼应该看到什么；
• 视觉层级如何分配；
• 哪些元素是主操作；
• 哪些元素只是辅助信息；
• 移动端和桌面端的差异；
• 空状态、加载态、错误态是否需要设计。

这部分以后可以展开写。

8. 屎山、冗余、兜底：负向 + 正向双管齐下

对于代码质量问题，需要两条线并行。

负向提示词：规避具体反模式

负向提示词用于钉住底线，明确告诉模型哪些行为绝对不能接受。例如：

• 禁止静默回退；
• 禁止 mock 成功路径；
• 禁止重复实现；
• 禁止第二数据源；
• 禁止吞错误的大 try/catch；
• 禁止用兜底逻辑掩盖真实失败；
• 禁止为了让测试通过而绕开核心路径；
• 禁止保留已经废弃但仍会参与逻辑分支的代码。

这些不是“啰嗦”，而是工程底线。

正向提示词：引导高质量决策

正向提示词用于告诉模型应该追求什么。例如：

• 全局最优解思考；
• 全局规划；
• 解耦代码；
• 删除重复逻辑；
• 保持单一事实来源；
• 大胆重构；
• 修根因，而不是补症状；
• 让失败显式暴露，而不是被兜底吞掉。

具体可参见我的 GitHub 仓库。

核心思路是：负向提示词负责守住底线，正向提示词负责拉高上限。只写负向，模型会变得拘谨；只写正向，模型可能仍会在细节处滑回老毛病。两者配合，效果最好。

9. 当 GPT-5.0 仍然过度保守

GPT-5.0 系列的“最小化修改”倾向已经刻进骨子里。

如果以上方法都不奏效，即模型仍然拒绝进行必要范围的结构性修改，降级方案是：

用 Opus 模型撰写重构方案或架构文档，再交给 GPT 执行。

次选方案：

DeepSeek Pro Max → GLM 5.1

这里的核心思路是：让更擅长架构展开的模型先把重构边界和执行方案写清楚，再让 GPT 去执行具体修改。

如果模型仍然试图用补丁绕过根因，不妨直接要求它先产出一份结构性方案，明确：

• 当前问题的根因；
• 哪些模块需要调整；
• 哪些重复逻辑需要删除；
• 哪些数据源必须合并；
• 哪些测试能证明重构成功。

10. 避免模型讨好用户

大模型的输出高度依赖输入，也很容易顺着用户说话。为了避免模型变成“只会附和的助手”，可以考虑在全局规则中加上一条：

请以客观、公正、冷静的态度审视我的意见。

这条规则可以酌情写入全局规则，也可以在关键决策时手动发送。

它的作用不是让模型反驳用户，而是让模型在必要时指出风险、盲点和错误前提。

真正好的协作，不是模型永远说“你是对的”，而是它能在你思路不完整、风险被低估、方案可能制造技术债时，冷静地提醒你。

为什么官方提示词文档必须认真看

请注意，官方发布专门的提示词文档，并不是随手写一篇博客。

他们之所以专门发布这类文档，是因为他们观察到：新模型在训练过程中，行为模式已经和旧模型发生了明显变化。提示词是我们和大模型交互的主要入口，而模型训练本身也已经将“遵循提示词”作为核心指标之一进行优化。

决定模型发挥上限的，不只是模型本身有多强，更是我们输入的质量有多高。

本开源项目的使用方法

使用方法很简单。

在全局 .codex 文件夹下，把下面这段发给 Codex：

请阅读下面的规则，然后按照这个规则重写我们的 AGENT.md 规则文件，保持精简有效：

https://github.com/lili-luo/aicoding-cookbook/blob/main/skills/codex/AGENT-v2.md

让它阅读其中的规则，并基于你的项目情况重写 AGENT.md。

如果你已经有旧版 AGENT.md，可以直接让 Codex 做三件事：

1. 删除重复和过时规则；
2. 把流程性内容迁移到 skills 或项目文档；
3. 保留真正会长期影响模型行为的工程基线。

最终目标不是写一份“全能提示词”，而是写一份能长期稳定塑造模型行为的协作基线。