GPT-6 Astra 的高杠杆用法

上周我把主力模型换成了 GPT-6 Astra。第一天用下来体验并不算愉快。让它改一行变量名它跑了 20 分钟测试还顺手检查了三个不相关的模块。我盯着终端里的进度条心里只剩一个问题改个变量名至于吗写东西也不顺手。让它写一段文案结果满篇都是“值得注意的是”“简而言之”“从某种意义上来说”。内容可能没错但机器味非常明显。当时我差点换回旧模型。后来转念一想OpenAI 不太可能花这么大力气做出一个连基础体验都不稳定的模型。更大的可能是模型的默认行为变了而我还在用旧模型的方式和它沟通。于是我去翻了官方文档。这次翻文档的收获比看几篇二手教程大得多。Astra 的很多行为其实都能从官方说明里找到原因也有对应的调整方法。一、先处理模型的写作惯性Astra 在写作上的一个明显问题是容易重复使用一些固定短语同时过度依赖格式化表达。这类问题并不影响模型理解任务却会直接影响成稿质量。尤其是技术文章、产品文案和长篇内容只要连续出现几次“值得注意的是”读者很快就能判断这段文字出自模型。官方给出的解决思路很直接把不希望出现的表达明确列出来同时补充一套正向写作规范。仅仅告诉模型“不要有 AI 味”通常没什么效果。这个要求太抽象模型不知道哪些表达属于 AI 味也不知道应该换成什么样的句子。可以把下面两部分作为一个组合块放进自定义指令或项目级指令中。负面约束Avoid using slop words or phrases like Bottom Line: in conclusions, delve, foster, leverage, its worth noting, importantly, Question? Answer. or This isnt about X. Its 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 wont do, what will remain unchanged, or how youll 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 didnt 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 users prompt and context.这部分的核心有几个每段只展开一个主要观点只有在信息并列、顺序明确或方便比较时才使用列表使用具体名词和精准动词尽早说清楚主要观点技术细节服务于表达不要为了显得专业而堆概念让句子之间存在清晰的承接关系。我实际测试后成稿的变化比较明显。它不会立刻变成优秀作者但固定套话少了段落也更像人在组织观点。这个配置的关键在于两部分要同时使用负面清单负责限制坏模式正面规范负责建立目标模式。只放禁用词模型容易写得生硬只给写作风格模型又可能继续使用那些高频套话。二、长对话里错误设定也会被牢牢记住加完写作规则之后Astra 过了几轮对话又开始偏离。起初我以为风格配置失效了。继续看官方文档才发现Astra 在长任务中保持上下文连贯的能力比早期模型更强。这带来了一个很实际的变化你在对话开头设定的规则模型可能会一直执行下去。以前写长文章每完成一节都要重新提醒使用口语化表达不要堆砌术语避免固定套话保持统一的文章结构。Astra 对这些要求的保持能力更强通常在开头说清楚一次就够了。但这也意味着开头的错误设定会持续影响后续结果。比如只说一句“用口语化风格”看起来很自然实际上信息量太低。模型理解的口语化可能是大量使用短句频繁加入网络用语使用聊天式表达弱化技术细节让文章变得像社交媒体帖子。而你真正想要的可能是“表达自然但保留技术准确性句子简洁但不要写成聊天记录”。两者差别很大。所以使用 Astra 的第一步不是马上开始任务而是先把任务边界、角色、语气和输出格式说清楚。我的习惯是把这些内容整理成一个可复用的技能或指令文件包括写作风格目标读者输出结构技术深度禁用表达是否允许使用列表、代码和表格需要避免的行为。新建会话时先让模型读取这份规则再开始正式工作。它为什么会主动提问Astra 还有一个容易被误解的行为当关键信息缺失时它会停下来提问。例如“这个参数的默认值是多少”“异常发生时应该重试还是直接返回”“这个配置是否需要兼容旧版本”“限流阈值应该按用户还是按 IP 计算”早期模型遇到这类问题通常会根据自己的假设继续往下做。假设正确时体验很快假设错误时后面几十步工作都可能建立在错误基础上。Astra 更倾向于在结果会受到明显影响的地方先确认。这在复杂任务里通常是好事。真正麻烦的是有些人希望模型完全自主推进于是把所有提问都视为模型“不够聪明”。官方文档给出的主动执行指令如下You should infer the users intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the users intended task to completion. When the user expresses intent to perform new work or fix an existing issue, persist until the users intended goal is complete. Progress autonomously towards the users 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.这条规则的边界很重要。适合并行的任务通常具备三个特点子任务之间依赖较少一个子任务不需要持续读取另一个子任务的中间结果并行能够节省时间或提高检查质量。例如一个项目需要同时检查鉴权、日志和缓存模块这三个方向可以分别交给不同代理分析。但如果任务必须按照顺序执行就不要为了使用子代理而强行拆分。比如先修改数据库结构再生成迁移脚本再更新服务代码最后调整接口测试。后一步依赖前一步的结果硬拆只会增加上下文同步成本。并行不是越多越好协调本身也有成本。生产环境里很多所谓的“自动化提效”最后都卡在这里任务拆得很漂亮合并、冲突处理和结果复核却没人负责。五、推理强度可以在会话中途调整Astra 还有两个不太容易被注意到的能力。第一个是可以在对话过程中调整推理强度同时避免让整个上下文缓存失效。在早期模型中推理强度通常属于请求级配置。你在上一轮使用较高推理强度下一轮切换到较低强度可能会改变请求前缀导致已有的 prompt cache 无法继续复用。Astra 引入了configuration_update允许从对话中的某个节点开始调整推理配置。这对长任务很有价值。例如需求澄清阶段使用较高推理强度代码生成阶段维持中等强度文案润色或格式转换阶段降低强度遇到复杂异常时再临时提高强度。可以把它理解成按任务阶段分配计算资源。高推理强度适合复杂架构设计多文件代码重构根因分析涉及多个约束条件的决策。低推理强度适合格式转换简单重命名文案改写已经明确方案后的重复性操作。当然这项能力目前更适合开发者和 API 场景。普通用户界面是否完整暴露这类配置还要看具体产品实现。六、执行过程中发现遗漏可以直接补充第二个功能是在任务执行过程中动态修正要求。很多人把它当成“紧急停止”使用。其实更常见的场景是模型已经开始工作你突然想起一个遗漏条件。比如它正在实现一个接口你补充实际上还需要处理输入为空的情况。 已经开始的其他部分按原计划继续。或者补充一个约束这个接口必须兼容旧客户端。 请把这个要求合并到当前实现中再继续完成剩余工作。如果模型支持在执行中接收新指令它可以把这项要求并入当前任务而不必等整个过程完成后再开启一轮修复。这对长时间运行的编码任务尤其有用。过去的工作方式通常是等模型完成通读结果发现遗漏再发起一轮修改重新测试。现在可以在任务执行期间及时补充约束减少返工。但这也要求指令足够清晰。不要只说“这里好像有问题”最好直接说明新增了什么条件影响哪些部分已经完成的内容是否保留是否需要重新测试哪些结果可以继续沿用。七、模型升级后旧提示词习惯也要调整翻完这份官方文档后一个比较明显的感受是很多过去常用的提示词技巧在 Astra 上需要重新评估。早期模型需要不断提醒继续完成任务不要停在分析阶段不要忘记上下文每一步都要汇报任务完成后再结束。Astra 对上下文和任务状态的保持能力更强重复提醒的必要性下降了。与此同时它也表现出更强的自主判断会主动确认关键歧义会根据任务风险决定验证范围会持续执行长任务会在复杂工作中拆分子任务会保留早期指令对后续行为的影响。这意味着提示词的重点正在从“告诉模型每一步怎么做”转向“定义目标、边界和决策规则”。真正值得写进自定义指令的内容通常包括什么情况下可以自主推进什么情况下必须停下来确认哪些操作需要用户授权小改动和大改动分别执行什么测试哪些任务可以并行采用什么写作风格输出需要满足什么格式。模型能力越强前置约束的重要性越高。因为一个能力较弱的模型可能会忘记错误指令一个能长期保持上下文的模型则可能把错误指令贯彻到底。所以GPT-6 Astra 的高杠杆用法并不在于堆更多提示词而在于把任务边界写清楚让模型知道什么时候该自主推进什么时候该停下来询问什么时候需要扩大验证范围。这些内容只是其中一部分。真正开始使用 Astra 后建议直接阅读官方文档尤其关注模型行为、编码任务、上下文管理和代理协作相关章节。很多看似奇怪的默认行为都能在那里找到原因。