上周我把主力模型换成了 GPT-6 Astra。

第一天用下来，体验并不算愉快。

让它改一行变量名，它跑了 20 分钟测试，还顺手检查了三个不相关的模块。我盯着终端里的进度条，心里只剩一个问题：改个变量名，至于吗？

写东西也不顺手。让它写一段文案，结果满篇都是“值得注意的是”“简而言之”“从某种意义上来说”。内容可能没错，但机器味非常明显。

当时我差点换回旧模型。后来转念一想，OpenAI 不太可能花这么大力气做出一个连基础体验都不稳定的模型。更大的可能是：模型的默认行为变了，而我还在用旧模型的方式和它沟通。

于是我去翻了官方文档。

这次翻文档的收获，比看几篇二手教程大得多。Astra 的很多行为，其实都能从官方说明里找到原因，也有对应的调整方法。

一、先处理模型的写作惯性

Astra 在写作上的一个明显问题，是容易重复使用一些固定短语，同时过度依赖格式化表达。

这类问题并不影响模型理解任务，却会直接影响成稿质量。尤其是技术文章、产品文案和长篇内容，只要连续出现几次“值得注意的是”，读者很快就能判断这段文字出自模型。

官方给出的解决思路很直接：把不希望出现的表达明确列出来，同时补充一套正向写作规范。

仅仅告诉模型“不要有 AI 味”通常没什么效果。这个要求太抽象，模型不知道哪些表达属于 AI 味，也不知道应该换成什么样的句子。

可以把下面两部分作为一个组合块，放进自定义指令或项目级指令中。

负面约束

Avoid using slop words or phrases like "Bottom Line:" in conclusions, "delve," "foster," "leverage," "it's worth noting," "importantly," "Question? Answer." or "This isn't about X. It's about Y.", "genuinely" or hyphenated compound descriptions and adjectives. Do not use concluding summary statements such as "In short:..", "The simplest mental model is:...". State the intended action directly. Avoid adding what you won't do, what will remain unchanged, or how you'll separate or categorize results. Do not use contrastive framing such as "X, not Y" or "X—not Y" that introduces an unprompted alternative that the user didn't ask about. Avoid invented compound labels, vague qualifiers, and canned transitions. Use plain verbs and prepositions to state the actual relationship directly.

它约束的不只是几个词，还包括几种常见的生成习惯：

• 用固定短语充当段落过渡；
• 在结尾强行做总结；
• 自造复杂标签；
• 用没有必要的对比句引出观点；
• 用模糊限定词代替具体表达；
• 过度依赖格式化结构。

不过，只有负面清单还不够。模型知道哪些表达不能用，却未必知道理想的文章应该长什么样。

正面规范

Default to using clear, concise paragraphs, each developing one main idea. Use lists only when the information is genuinely parallel, sequential, or easier to compare. Avoid nested lists unless the hierarchy cannot be expressed clearly in prose. Use plain, simple language: familiar words, concrete examples, and precise verbs. Prefer active voice and direct statements. Make sure to state the main point clearly and early, then develop it with the explanation and detail the reader needs. Let each sentence build on what came before. Develop the points that matter and provide enough support to be useful. Use plain language over jargon, and reference technical details only to the degree that it helps illustrate an idea or your work to the user. Communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the level of background knowledge assumed from the user's prompt and context.

这部分的核心有几个：

1. 每段只展开一个主要观点；
2. 只有在信息并列、顺序明确或方便比较时才使用列表；
3. 使用具体名词和精准动词；
4. 尽早说清楚主要观点；
5. 技术细节服务于表达，不要为了显得专业而堆概念；
6. 让句子之间存在清晰的承接关系。

我实际测试后，成稿的变化比较明显。它不会立刻变成优秀作者，但固定套话少了，段落也更像人在组织观点。

这个配置的关键在于两部分要同时使用：

• 负面清单负责限制坏模式；
• 正面规范负责建立目标模式。

只放禁用词，模型容易写得生硬；只给写作风格，模型又可能继续使用那些高频套话。

二、长对话里，错误设定也会被牢牢记住

加完写作规则之后，Astra 过了几轮对话又开始偏离。

起初我以为风格配置失效了。继续看官方文档才发现，Astra 在长任务中保持上下文连贯的能力，比早期模型更强。

这带来了一个很实际的变化：

你在对话开头设定的规则，模型可能会一直执行下去。

以前写长文章，每完成一节都要重新提醒：

• 使用口语化表达；
• 不要堆砌术语；
• 避免固定套话；
• 保持统一的文章结构。

Astra 对这些要求的保持能力更强，通常在开头说清楚一次就够了。

但这也意味着，开头的错误设定会持续影响后续结果。

比如只说一句“用口语化风格”，看起来很自然，实际上信息量太低。

模型理解的口语化，可能是：

• 大量使用短句；
• 频繁加入网络用语；
• 使用聊天式表达；
• 弱化技术细节；
• 让文章变得像社交媒体帖子。

而你真正想要的，可能是“表达自然，但保留技术准确性；句子简洁，但不要写成聊天记录”。

两者差别很大。

所以，使用 Astra 的第一步不是马上开始任务，而是先把任务边界、角色、语气和输出格式说清楚。

我的习惯是把这些内容整理成一个可复用的技能或指令文件，包括：

• 写作风格；
• 目标读者；
• 输出结构；
• 技术深度；
• 禁用表达；
• 是否允许使用列表、代码和表格；
• 需要避免的行为。

新建会话时，先让模型读取这份规则，再开始正式工作。

它为什么会主动提问

Astra 还有一个容易被误解的行为：当关键信息缺失时，它会停下来提问。

例如：

• “这个参数的默认值是多少？”
• “异常发生时应该重试还是直接返回？”
• “这个配置是否需要兼容旧版本？”
• “限流阈值应该按用户还是按 IP 计算？”

早期模型遇到这类问题，通常会根据自己的假设继续往下做。假设正确时，体验很快；假设错误时，后面几十步工作都可能建立在错误基础上。

Astra 更倾向于在结果会受到明显影响的地方先确认。

这在复杂任务里通常是好事。真正麻烦的是，有些人希望模型完全自主推进，于是把所有提问都视为模型“不够聪明”。

官方文档给出的主动执行指令如下：

You should infer the user's intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the user's intended task to completion. When the user expresses intent to perform new work or fix an existing issue, persist until the user's intended goal is complete. Progress autonomously towards the user's goal (e.g. creating isolated worktrees / checkouts if needed, resolving merge conflicts, read-only actions, creating draft PRs etc.) unless they are clearly destructive or irreversible.

这段指令的重点不是让模型“少提问”，而是让它区分两类信息：

• 缺少后会显著改变结果的关键条件；
• 不影响主流程的普通偏好。

比如：

“在这个文件描述的 API 端点上实现限流，用滑动窗口方案。”

这句话已经足够让模型开始分析代码结构，但它可能需要确认：

• 每秒允许多少请求；
• 超限后是否返回 429；
• 限流维度是用户、IP 还是 API Key；
• 是否需要分布式一致性；
• 是否要增加监控指标。

另一方面，“代码使用 TypeScript 还是 JavaScript”更像是用户偏好。如果你在意，就应该直接说出来。模型不会替你猜测每一种个人习惯。

判断标准很简单：这个信息缺失后，模型还能不能做出符合预期的实现？

如果不能，停下来问一句通常比默默猜测更省时间。

三、编码任务要明确测试范围

开头那个“改一个变量名却跑 20 分钟测试”的问题，也能从官方文档里找到解释。

Astra 在编码任务中倾向于把验证做得比较完整。它会判断：任务没有经过充分测试之前，还不能算真正完成。

大范围重构、核心逻辑调整、涉及多个模块的改动，这种策略比较稳妥。

但对于低风险的小修改，就容易产生明显浪费：

• 改变量名却运行完整测试集；
• 调整注释却重新构建整个项目；
• 修改一个前端样式却检查全部端到端流程；
• 改一个配置项却扫描不相关模块。

模型并不知道你的修改影响范围，除非你明确告诉它。

官方给出的提示词如下：

Do not write tests for reversible, low-impact changes that mirror the implementation. If you do choose to verify your work with tests, make sure that the tests are meaningful and necessary to verify implementation. Run tests appropriate to the change and complete required checks. Once those pass, broaden or repeat testing only when new changes, failures, or unresolved concerns justify it. Otherwise, continue toward completing the task.

这段话实际建立了一套测试分级逻辑：

测试越多，安全感不一定越高。测试本身也会消耗时间、计算资源和开发注意力。

更合理的做法，是让验证强度和变更风险匹配。

这也是使用编码代理时最容易被忽略的一点：模型需要知道“这次改动有多大”。

可以在任务中直接补充：

这是一个低风险的小修改，只改变量名。 请不要运行完整测试集，只执行必要的静态检查或相关测试。

或者：

这是一次跨模块重构，涉及公共接口和数据结构。 请在实现后运行相关单元测试、集成测试和完整构建检查。

前一句能避免模型过度验证，后一句能避免它只做表面检查。

四、并行能力需要主动打开

Astra 还支持把复杂任务拆分给多个并行运行的子代理。

这项能力适合处理彼此独立的工作，例如：

• 同时研究多个互不相关的资料来源；
• 并行检查多个模块；
• 分别实现几个不共享状态的功能；
• 同时分析前端、后端和数据库层面的影响；
• 对多个候选方案进行独立评估。

但它默认不会在所有场景下积极委派任务。

官方文档提到，模型的委派频率可能低于用户对工作流的预期。换句话说，即使一个任务明显可以拆成几块，模型也可能选择按顺序处理。

可以加入这样的规则：

If at any point you can parallelize work by delegating tasks to another agent, no matter if you are the root or subagent, you should do so using collaboration tools if it could save time or improve quality.

这条规则的边界很重要。

适合并行的任务通常具备三个特点：

1. 子任务之间依赖较少；
2. 一个子任务不需要持续读取另一个子任务的中间结果；
3. 并行能够节省时间或提高检查质量。

例如，一个项目需要同时检查鉴权、日志和缓存模块，这三个方向可以分别交给不同代理分析。

但如果任务必须按照顺序执行，就不要为了使用子代理而强行拆分。

比如：

1. 先修改数据库结构；
2. 再生成迁移脚本；
3. 再更新服务代码；
4. 最后调整接口测试。

后一步依赖前一步的结果，硬拆只会增加上下文同步成本。并行不是越多越好，协调本身也有成本。

生产环境里，很多所谓的“自动化提效”最后都卡在这里：任务拆得很漂亮，合并、冲突处理和结果复核却没人负责。

五、推理强度可以在会话中途调整

Astra 还有两个不太容易被注意到的能力。

第一个是可以在对话过程中调整推理强度，同时避免让整个上下文缓存失效。

在早期模型中，推理强度通常属于请求级配置。你在上一轮使用较高推理强度，下一轮切换到较低强度，可能会改变请求前缀，导致已有的 prompt cache 无法继续复用。

Astra 引入了configuration_update，允许从对话中的某个节点开始调整推理配置。

这对长任务很有价值。

例如：

• 需求澄清阶段使用较高推理强度；
• 代码生成阶段维持中等强度；
• 文案润色或格式转换阶段降低强度；
• 遇到复杂异常时，再临时提高强度。

可以把它理解成按任务阶段分配计算资源。

高推理强度适合：

• 复杂架构设计；
• 多文件代码重构；
• 根因分析；
• 涉及多个约束条件的决策。

低推理强度适合：

• 格式转换；
• 简单重命名；
• 文案改写；
• 已经明确方案后的重复性操作。

当然，这项能力目前更适合开发者和 API 场景。普通用户界面是否完整暴露这类配置，还要看具体产品实现。

六、执行过程中发现遗漏，可以直接补充

第二个功能，是在任务执行过程中动态修正要求。

很多人把它当成“紧急停止”使用。其实更常见的场景是：模型已经开始工作，你突然想起一个遗漏条件。

比如它正在实现一个接口，你补充：

实际上还需要处理输入为空的情况。 已经开始的其他部分按原计划继续。

或者：

补充一个约束：这个接口必须兼容旧客户端。 请把这个要求合并到当前实现中，再继续完成剩余工作。

如果模型支持在执行中接收新指令，它可以把这项要求并入当前任务，而不必等整个过程完成后，再开启一轮修复。

这对长时间运行的编码任务尤其有用。

过去的工作方式通常是：

1. 等模型完成；
2. 通读结果；
3. 发现遗漏；
4. 再发起一轮修改；
5. 重新测试。

现在可以在任务执行期间及时补充约束，减少返工。

但这也要求指令足够清晰。不要只说“这里好像有问题”，最好直接说明：

• 新增了什么条件；
• 影响哪些部分；
• 已经完成的内容是否保留；
• 是否需要重新测试；
• 哪些结果可以继续沿用。

七、模型升级后，旧提示词习惯也要调整

翻完这份官方文档后，一个比较明显的感受是：很多过去常用的提示词技巧，在 Astra 上需要重新评估。

早期模型需要不断提醒：

• 继续完成任务；
• 不要停在分析阶段；
• 不要忘记上下文；
• 每一步都要汇报；
• 任务完成后再结束。

Astra 对上下文和任务状态的保持能力更强，重复提醒的必要性下降了。

与此同时，它也表现出更强的自主判断：

• 会主动确认关键歧义；
• 会根据任务风险决定验证范围；
• 会持续执行长任务；
• 会在复杂工作中拆分子任务；
• 会保留早期指令对后续行为的影响。

这意味着提示词的重点正在从“告诉模型每一步怎么做”，转向“定义目标、边界和决策规则”。

真正值得写进自定义指令的内容，通常包括：

• 什么情况下可以自主推进；
• 什么情况下必须停下来确认；
• 哪些操作需要用户授权；
• 小改动和大改动分别执行什么测试；
• 哪些任务可以并行；
• 采用什么写作风格；
• 输出需要满足什么格式。

模型能力越强，前置约束的重要性越高。

因为一个能力较弱的模型，可能会忘记错误指令；一个能长期保持上下文的模型，则可能把错误指令贯彻到底。

所以，GPT-6 Astra 的高杠杆用法并不在于堆更多提示词，而在于把任务边界写清楚，让模型知道什么时候该自主推进，什么时候该停下来询问，什么时候需要扩大验证范围。

这些内容只是其中一部分。真正开始使用 Astra 后，建议直接阅读官方文档，尤其关注模型行为、编码任务、上下文管理和代理协作相关章节。很多看似奇怪的默认行为，都能在那里找到原因。