GPT-6 Astra 轮次中引导：无需重新开始即可调整任务

轮次中引导会改变什么

官方引导文档说明，GPT-6 Astra 支持通过连接 Responses API 的 WebSocket 使用该功能。文档明确区分了引导与撤销早先操作：已经交付的输出不会被改写，已经启动的工具也不会自动取消。

这一区别应体现在界面设计中。“修改要求”和“停止操作”需要表达不同含义。如果外部写入正在执行时用户更改了目标位置，应用不能贸然认定此前的写入从未发生。

清楚的状态信息应说明什么仍在等待、什么已经完成。“新要求会应用于接下来的工作”比静默替换原始请求更明确，也不会让用户猜测上一项操作遵循的是哪组指令。

按照引导事件顺序处理更新

流式输出会随着内容生成而展示结果；引导则修改后续工作应遵循的指令。一个产品可能支持其中一种，却未提供另一种。

按照文档中的 WebSocket 流程，先发送 response.create 并等待 response.created。然后在同一连接上发送 response.steer，将响应 ID 作为 previous_response_id，将修订后的指令作为 input。response.steer.accepted 表示更新已进入队列，不代表所有修订工作已经完成。如果缺少必需的工具结果或批准，response.steer.pending 会指出它们。应将由此产生的后续执行与原始响应分开追踪。

同样，任务结束后的普通追加消息，与响应运行期间的更新也不是同一种交互。应在应用日志中区分这两条路径，让审阅者能够准确还原任务。

GPT-6 Astra 指南将轮次中引导列为模型较新的工作流能力之一。这不代表每个聊天输入框或第三方应用都实现了所需的事件处理。应核实实际使用的界面，而不只是看旁边标注的模型名称。

在应用界面中，应把“已收到更新”与“新工作已完成”分开显示。将当前要求与仍在执行的操作并列展示。这是界面设计建议，不代表 API 自带完整的任务仪表板。

编写能保留有效成果的更新指令

有效的任务中途更新应说明哪些内容改变、哪些保持不变，以及下一步不能做什么。

例如：“保留现有桌面布局。下一轮改为重点检查触控操作。不要发布或替换当前构建。”这样的指令能保留有用的上下文，同时缩小下一步操作范围。

相反，“换一种做法”会迫使助手猜测用户要的是新目标、视觉调整还是停止。界面可以通过展示当前目标，并让用户编辑具体要求来减少歧义。

当更新与已完成工作冲突时，应明确说明冲突。用户可能希望纠正结果，但纠正仍是一项新操作，有自己的范围和影响。

假设助手正在审查原型的键盘操作，设计师此时补充了移动端要求。有效的更新不是“全部重做”，而是“保留玩法目标，接下来检查触控输入，不要修改已有键盘行为”。

助手先前的观察可能依然有价值。新增测试应覆盖触控目标大小、意外重复输入、屏幕方向变化，以及同一操作是否提供一致反馈。这些是建议检查项，不是 Astra 性能的实测结论。

为了让触控简报更具体，可以试玩街机游戏，观察游戏如何表达轻触、长按和快速连续操作。用这些观察来定义下一轮审查；不要据此推断游戏由哪个模型制作，或是否使用了模型。

为变化中的要求建立任务状态模型

在应用记录中，应区分计划中的工作、执行中的工作和已完成工作。

下表是应用设计辅助材料，不能替代 API 事件参考文档。它有助于避免一个常见错误：把每项任务都当作可以随时改写的文本段落。

将工具结果关联到发起它的操作。迟到的结果不能被误认为是在新要求下产生的证据。如果结果已经过时，即便它不再适合支持下一步判断，也可能仍需要记录。

考虑一个假设流程：某次读取依据要求 A 启动；用户提交要求 B；旧读取随后返回。应先把结果记录在 A 下，再判断它是否也能回答 B。不要把它重新标为一次新的检查。例如，键盘处理的结果不能证明触控操作可用。

通过应用控制管理外部影响

在含糊的更新与后果重大的操作之间，模型不应是唯一的防护措施。应用可以维护拟议写入队列，为影响较大的步骤要求批准，并检查批准是否仍符合最新任务。

例如，用户批准上传某份草稿后，又更改了目标项目，旧批准不应悄然转移到新目标。应重新核对目标位置和拟上传的内容。

同样的原则也适用于外部消息、购买、删除和部署。引导能够帮助助手理解修订后的目标，但不提供事务系统或回滚保证。

对于只读操作，迟到结果的影响通常是浪费工作或造成困惑；对于写入操作，则可能产生真实的状态变化。应分别设计和测试这些情况。

在容易出问题的时刻测试更新

以下案例组成一份建议的集成测试计划。本文尚未实际执行这些测试。

对每个案例，明确用户可见状态、是否允许启动新操作，以及应用如何记录完成情况。应根据行为是否一致来判断成功，而不只是检查模型是否回应了新消息。

• 更新在任何工具启动之前到达。
• 更新在只读工具运行期间到达。
• 更新在写入已经执行期间到达。
• 两次更新携带互相冲突的要求。
• 用户看到确认之前，连接已经断开。
• 迟到的工具结果属于较早的任务版本。

让下一步操作清晰可见

可靠的引导体验应明确展示三件事：当前目标、已经完成的工作，以及下一项等待授权的操作。用户不应需要从长篇对话记录中自行推断。

实际收益是减少不必要的重新开始，而不是赋予无限自主权。应让变更保持可审阅，并如实记录发生过的事情。

如果需要新的交互简报，可以浏览游戏库，选择一种操作行为进行检查。练习范围应足够小，使中途变更能够明确表述：哪些保留、哪些修改，以及哪些必须等待批准。