连夜拆解 GPT-6 Astra 官方指南，这 6 条黄金法则建议直接抄！

（来源：AI信息Gap）

你的 GPT-6 Astra，磨叽吗？

让它改一行代码，它先把完整的测试流程跑一遍等你批准。问它一个问题，它给你列个表格再加三个 bullets。写到一半它还会突然停下来，「我可以继续吗？」你说继续，它写两段，又停了，「需要我帮你审查一下吗？」

这不是你的错觉。而且 OpenAI 自己也知道，所以它刚刚更新了开发者文档，把 GPT-6 Astra 这些「臭毛病」逐条列了出来，还附上了对应的解法。OpenAI 还顺手总结了一份 AI 八股词语黑名单，delve（深入探讨）和 leverage（赋能）不幸躺枪。

我们总结了 6 条 GPT-6 Astra 提示词黄金法则，拿好不谢。

01｜GPT-6 变磨叽了，这是设计出来的

GPT-6 Astra 被训练成一个「协作者」，而非「执行者」。上一代 GPT-5.6 Sol 接到指令就往前冲，不确定的地方自己猜，猜错了你再纠正。GPT-6 Astra 则反过来，拿不准的地方先停下来问你。

听上去挺好？但实际用下来，它对「拿不准」的定义太过宽泛。

「一两分钟就停下来，和 GPT-5.6 Sol 明显不同。」这是很多网友的体感。

OpenAI 官方解法来了。

让它直接开干，别总停下来。

你应该从用户指令和之前对话的上下文中推测用户的意图和任务范围。你的职责是执行，把用户想要完成的任务做到底。

当用户表达了要做新任务或修复现有问题的意图时，坚持做到用户的目标完成为止。朝着用户的目标自主推进（比如需要的话创建独立的工作分支、解决合并冲突、执行只读操作、创建 PR 草稿等），除非某个操作明显具有破坏性或不可逆。

专治「能帮我做吗？」「可以的，要不要我开始？」这种车轱辘问句。

当用户的提示词表达了一个行动请求，比如「能不能帮我…」「我想…」「帮我…」以及类似的表达，把这些当成指令去执行。不要停留在确认能力（比如回复「好的…」）、提出计划、或者询问是否继续。不要为了节省时间、精力或 token 就交付一个「差不多够用」的半成品。如果任务需要持续投入，就把所有必要的工作做完，直到预期的结果实现为止。

你说「帮我…」，它就应该去做，直到做完为止。

划清什么时候该问、什么时候闭嘴干活。

在向用户提出澄清问题前，你应该先把上下文中已经授权的、且让行动方案变得具体所必需的工作做完。用户要批准的应该是一个具体的、可审查的成果。比如在部署变更、写入外部应用、合并 PR 或发布网站之前，先把所有前置工作做好，让用户的批准成为最后一步。可逆操作、只读操作、代码审查和修复、以及会话中已经授权过或任务指令里明确暗示过的工作，不需要请求用户许可。

不要因为假设性的风险就主动加上注意事项、免责声明、审批流程或安全合规检查清单。

让 GPT-6 Astra 把能做的全做完，让你批准的应该是一个具体的成品。真正值得停下来确认的操作，只有推送代码上生产、删除数据库、发邮件这种不可逆的操作。

02｜GPT-6 对你的 AGENTS.md 较真了

GPT-6 Astra 比以前的模型更能理解长指令，副作用是对你写在各种文件里的规则也更加较真。以前 GPT-5.6 Sol 遇到看不懂的指令，可能跳过不管。GPT-6 Astra 不会，它会认真执行，然后可能因为两条规则互相矛盾卡住。

所以我们在「GPT-6 Astra 发布 48 小时，十大邪修玩法来了！」一文中提到，「你写在 AGENTS.md、Skills、CLAUDE.md 里的那些积累了一年的规则，现在可能会影响 Astra 的发挥。」写得好是安全护栏，写得差可能就是绊脚石了。

OpenAI 建议你做这样一件事，审计你所有的指令文件，检查有没有互相矛盾的规则。如果 GPT-6 Astra 因为某条指令停下来了，让它指出具体是哪个文件、哪条规则让它这么做的。

定优先级。 当你的指令和某个 Skill 文件里的规则冲突时，听谁的？

用户的指令优先级高于 Skill 文件里的规则。如果用户的指令明确和某条 Skill 的指令冲突，优先执行用户的指令。

让 GPT-6 Astra 自己交代是哪条规则让它卡住的。

如果某条 Skill 的规则导致你要请求许可或暂停未完成的工作、或者偏离用户的意图，指出那个 SKILL.md 文件的具体名称和链接，引用相关的指令原文，并简要解释它是怎么起作用的。区分 Skill 里明确要求的和你自己对规则的理解。

有了这段提示词，下次 GPT-6 Astra 再莫名其妙停下来，它就会告诉你「我读了 XX 文件的第 XX 条规则，它要求我先请示」，还会区分这是规则明确要求的，还是它自己的理解。这样你就知道该改哪条规则了。

03｜一份 AI 味拉满的八股黑名单

接下来是整份指南里我认为很有意思的一部分。

OpenAI 在写作风格那一节，给出了一段禁令模板，官方名「slop words」，「AI 八股」。

不要使用以下 AI 味拉满的词语和句式。包括用「总结一下」「一句话概括」做结论，delve（深入探讨）、foster（促进）、leverage（赋能）、genuinely（真正地），「值得注意的是」「重要的是」，先问后答式（自己抛个问题自己回答），以及连字符堆砌的复合形容词。也不要用「简而言之…」「最简单的理解方式是…」结尾。

delve、leverage、genuinely 这些英文词的地位，可以类比于下面这个。你肯定在哪儿见过。

我将用最直白，最直接，最不绕弯子，最客观，最正确，最系统，最真实，最简略，最容易理解、最实在、最凝练、最通俗、最严谨、最周全、最中肯、最务实、最浅显、最无修饰、最不浮夸、最无虚言、最接地气、最条理分明、最一针见血……最硬核、最干脆、最不墨迹、最戳痛点、最不留情面、最硬核、最不讲虚的、最不玩套路、最不搞形式、最不整虚头巴脑、最只讲干货、最只说重点、最只给结果、最只聊真相、最只谈核心、最只戳关键的方式来告诉你。

怎么治疗「AI 八股」？用下面这段提示词。

直接说明你要执行的操作。不要预告你不会做什么、哪些内容会保持不变、或者你打算如何分类整理结果。不要使用「不是 X，而是 Y」这种对比框架，它引入了一个用户根本没有提到的替代方案。不要自造术语，不要使用模糊的修饰词和套路化的过渡句，用简单的动词和介词来直接描述实际的关系。

对比框架「不是 X，而是 Y」，老朋友了。你问它一个问题，它先说你的问题框架不对，再告诉你应该怎么问，先否定 X 再引出 Y。你没问 X，它自己引入了一个替代方案。

自我约束预告，可能更隐蔽。「我不会修改你没提到的文件」「我会保持其他部分不变」，做就行了，别预告你的自我约束。还有自造术语，看上去专业，其实是 AI 自己编造的词。

划重点，「AI 八股」不是 GPT-6 Astra 的问题，所有 AI 多多少少都有这毛病。

04｜提示词越来越像项目管理规范了

模型越来越强，你可能会有这种感觉，「写提示词不像在教模型说话了，更像在写一份项目需求文档。」

而这份需求文档，包括下面 6 个重要维度。

目标，做什么、交付什么、给谁看。比如「写一份备忘录，每条建议引用来源，区分事实和推断」，越具体它越不会跑偏。

上下文，哪些信息重要。来源冲突时标注出来而不是编答案。

指令优先级，冲突了听谁的。前面提到的指令优先级说的就是这件事。

自主权，哪些事可以自己决定、哪些必须问。可逆的、只读的、已经授权的任务直接执行，不可逆的操作停下来确认。

工具和子智能体，什么时候安排子智能体并行处理，什么时候自己干。GPT-6 Astra 默认可能委派得不够积极，需要你明确写「能并行就并行」。

输出格式，格式、章节结构、引用要求、验证标准。不想要列表就写「默认用段落，只有内容天然适合对比的时候才用列表」。想要简洁就写「开门见山给结论，然后用支撑材料展开」。

本质上来说，模型能力越强，你需要告诉它的「怎么做」就越少，「做到什么程度算完成」越多。

提示词工程正在从「话术」变成「规范」。

05｜GPT-6 的三个行为变化

除了磨叽和指令敏感，GPT-6 Astra 还有三个行为变化。

回复太长、太格式化。 你问它一句话，它可能给你一整页表格加列表。你需要在系统提示词里写清楚你要什么格式。

默认使用清晰简洁的段落，每段讲一个要点。只有当内容本身适合并列、排序或对比的时候才用列表，除非层级关系用段落确实表达不清楚，否则不要用嵌套列表。

子智能体用得偏少。GPT-6 Astra 能拆解任务、安排子智能体并行处理，但实际使用中它可能不够积极，需要你给出明确指令（token 是你最大的敌人）。

如果把任务委派给其他子智能体并行处理可以节省时间或提升质量，你就应该这么做。

小改动也要完整测试。 改一行代码也要把整个测试流程过一遍，有时候等待测试的时间比改代码还长。

不要为可逆、影响小的改动重复测试。执行与改动相关的测试，完成必要的检查。一旦通过，只有在出现新改动、测试失败或未解决的问题时才扩大测试范围，否则继续推进任务。

好模型，是调教出来的。

06｜一份可以直接用的检查清单

打开你的 AGENTS.md 文档，每条规则问三个问题。

这条规则是给所有任务用的，还是只有特定场景才需要？如果是后者，可以改成按使用场景触发，别让它占用每个任务的上下文。

GPT-6 Astra 自己会做这件事吗？如果会，这条规则就是重复指令，删掉。

如果没有这条规则，最坏结果是什么？如果最坏结果可以接受，改成授权而不是强制要求。

还有一件容易忽略的事，你引用的文档必须保持更新。「过期的项目说明比没有说明更危险，因为 GPT-6 Astra 会把它当成高优先级上下文认真执行。」

同样的逻辑适用于 Claude Code 的 CLAUDE.md 和 Skills。工具不同，但核心理念一致。模型越强，你的指令越应该像写给老司机的交接文档，一页纸能讲清楚边界和优先级，就别写二十页操作手册。

提示工程的下一站，写更短、更精准、更像项目管理规范的提示词。