ChatGPT Dots + GitHub：从缺陷报告到经过审查的 PR

团队正在开发新功能时，又收到一份缺陷报告。真正耗时的往往不是生成补丁，而是到达有效代码审查之前的整个过程：定位相关代码、复现问题、保留上下文，以及确认修改究竟产生了什么效果。

这正是值得用 ChatGPT Dots 验证的工作流：输入用户反馈，输出可审查的证据材料。目标不是无人监督的一键合并。本文设计了一个范围明确的 GitHub 缺陷分诊与调查流程，包括可复用的任务说明、测试证据要求和停止程序。

文档核查日期：2026 年 10 月 1 日。下述产品能力来自 OpenAI 官方文档。试点方案、验收条件和案例是我们提出的工程设计，并非实际运行 Dots 后得到的基准测试结果。

ChatGPT Dots 是什么？

OpenAI 于 2026 年 9 月 29 日推出 Dots：基于 GPT-6 Astra、拥有云端计算机、支持持续任务的持久化智能体。官方发布说明展示了从反馈到修复的应用场景。具备独立组织身份的专业化 dots 目前仍处于定向企业试点阶段。

对开发团队来说，关键问题不是智能体能否再生成一个补丁，而是委派任务能否减少形成可靠审查结论所需的工作。我们建议让一个 dot 协调报告接收、资料收集和范围有限的修复，但不让它自行决定结果是否通过验收。

明确区分三项责任：协调者在约定范围内决定调查什么；编码环境产出修改建议；审查者判断证据是否足以支持验收。同一个人可以负责整个试点，但不能让这三个决定都被一条“已完成”消息代替。

Dots 发布初期向哪些用户开放？

截至核查日期，官方访问指南列出了以下开放范围。套餐符合条件，并不意味着功能已经出现在具体账户中。

例如，奥地利或德国团队应检查实际工作区套餐，而不是认定所有欧洲账户的条件相同。“全球开放”也不应被理解为无需确认账户资格和服务可用性。如果功能尚未出现在自己的账户中，就不要以此承诺实施日期。

在桌面端创建 dot。设置文档将应用连接、消息渠道连接和本地计算机访问分开处理。我们建议的试点只连接一个代码仓库，暂不连接本地计算机。只有具体测试证明确实需要某项访问时，才增加权限。

分别配置 GitHub 和编码环境

计算机与应用指南说明，dot 可以通过已授权的插件调查 GitHub issue 并准备 PR。针对特定仓库的云端编码可以使用预先配置的 Codex 环境。本地任务则需要已连接且在线的计算机，并保持 ChatGPT 应用打开。

GitHub 账户已连接，不等于正确的仓库、分支、依赖和测试数据已经就绪。分配持续职责之前，先做一次小型访问验证。要求它提供选中的仓库、一个已知 issue、当前代码版本，以及仓库中定义的测试命令。明确区分实际读取的信息与推断。

接着在临时分支或测试仓库中验证允许的写入路径。连接账户能否创建约定的草稿 PR，同时没有合并或部署的途径？检查源系统权限和工作流凭据，而不只是任务说明。如果集成无法落实这一边界，就保留只读权限，让人工接收并应用补丁。

为每个编码任务附上一份简短交接说明：报告标识、预期行为、受影响的提交、允许修改的文件、复现步骤和验收测试。不要让验收依赖编码任务能否记住之前的对话。涉及已登录网站时，请参阅独立的ChatGPT 云端浏览器登录指南，不要把应用连接当成网站登录。

可复用的 Dots 缺陷调查任务说明

连接 Slack 本身不会开始监控。任务与记忆指南要求明确设置受支持的触发事件或保存定时任务，并提醒：一次执行结束不代表目标已经实现。因此，需要同时验证任务入口与输出结果。

以下内容是我们建议使用的对话任务说明，不是 Dots API，也不是配置文件。使用前应填写实际约定的对象。先由负责人指定一份报告，确认工作区支持相关能力后，再增加自动接收机制。

职责：准备可供审查的修复，不负责发布。

负责人：指定的工程审查者。
范围：约定的仓库、反馈来源和测试环境。
入口：仅调查试点中由负责人分配的报告。
修改代码前：确认原始报告和当前提交；复现问题，
或者明确说明阻止复现的具体原因。

使用约定的 Codex 云端环境，不使用本地计算机。
每份报告仅提出一个范围明确的修复。不得更改验收标准、
删除失败测试、访问生产数据或修改 CI 配置。

只有负责人授权发布且操作权限允许时，才创建草稿 PR。
否则返回补丁，由人工审查。不得合并、部署、关闭原始 issue，
也不得联系客户。

返回：报告链接、基准和修改后的提交、复现情况、变更文件、
实际执行的检查及结果、未执行的检查、剩余风险，
以及需要审查者作出的决定。
检查失败或无法执行，不等于检查通过。

扩大范围或启动另一项付费工作前先征求同意。
遇到阻塞应报告，不得擅自换用其他环境。

后续采用定时试点时，应指定准确时区、结束日期和结果发送位置，并检查保存下来的任务。采用事件触发时，提交一份合成缺陷报告，确认恰好启动一次调查。再次提交同一报告，检查重复处理策略。“监控这个频道”不足以构成验收证据。

整个流程都应保留原始报告标识。重复报告应关联现有调查，而不是生成相互竞争的修复。涉及不同代码版本的报告应重新验证，不能悄悄沿用旧版本的复现结论。

首次修复前，先定义 PR 证据要求

我们建议的验收规则是：只有当另一位工程师能够将声称的结果关联到实际测试的准确提交时，补丁才具备审查条件。视频有助于解释界面变化，但不能单独证明运行的是哪个提交、断言是否通过，或者相邻功能是否出现回归。

假设有一份虚构报告：“手机上看不到导出按钮。”不充分的修复会让所有用户都看到按钮。有效调查应先明确受影响的屏幕尺寸、用户角色和账户状态，再分别验证有权限的移动用户、没有权限的用户，以及现有桌面行为。如果导出是异步的，还应覆盖等待中和失败状态。

要求使用相同的相关输入，展示基线失败和修复后的结果。预期结果应独立于补丁，否则智能体可能通过弱化断言让自己生成的测试通过，而没有真正修复应用。

采用明确的审查状态，例如 not-reproduced、blocked、patch-unverified 和 ready-for-review。这些是建议的团队标签，并非 Dots 内置状态。最终验收应由人根据规定检查作出。无法访问浏览器时，应报告“浏览器检查未执行”，而不是“已通过代码阅读验证”。

增加任何提交后，都应重新应用同一标准。旧版本的证据不能自动批准新补丁。更广泛的测试架构可参阅智能体测试与确定性测试自动化的区别。

将操作授权与软件正确性分开

Enterprise 管理指南说明，只有所有者可以通过受支持的 Slack 消息指挥自己的个人 dot。指南还指出，Enterprise 的默认模型设置不适用于 Dots。因此应单独检查 Dots 访问权限，不能假设已有模型策略已经覆盖试点。

这一区别会直接影响任务接收设计。同事的缺陷报告是待处理资料，不是扩权指令。issue 中要求导出秘密、跳过测试或发布版本的内容，不应仅因出现在获准访问的仓库里就成为有效任务指令。

OpenAI 的 Dots 安全说明介绍了针对恶意指令的防护和只读的主动研究。主动研究与用户授权的工作任务不同。我们的工程判断也必须区分：允许执行某项操作，不代表操作结果就是正确的。

在这个试点中，允许读取约定报告并准备隔离修改；发布 PR 前要求审查；把合并、部署、凭据变更和客户沟通排除在任务之外。在应用、仓库和执行环境各层落实可用的限制。不要提供权限更大的浏览器会话，作为绕过受限插件的替代路径。

扩展访问前，主动测试三个失败场景：范围外的仓库、包含恶意指令的报告，以及缺失的依赖。期望结果分别是拒绝访问、忽略恶意指令和准确报告阻塞，而不是三次寻找更宽权限路径的机会。

如何停止 Dots，避免遗漏后台任务？

控制指南区分三种操作：Pause 影响当前主任务；委派任务需要在 Activity 中停止；周期任务需要在 Scheduled 中停用或删除。自定义规则是可能出错的指令，不是应用访问授权。停止操作也不会撤销已经完成的动作。

把停止流程纳入试点验收。启动一个无害的委派任务和一个未来的周期检查。暂停协调者后，分别检查二者，再停止委派任务并删除计划。记录真正停止了什么。在认定试点已完成退出前，还要单独检查应用权限和已登录的网站会话。

帮助中心的 Dots 指南也区分了断开应用与删除已经取得的信息。移除 dot 前，阅读当前重置或删除确认说明，并保存已批准的证据。撤销权限、处理已保留上下文，以及管理已经发布的产物，需要分别作出决定。

对于本文的 GitHub 流程，这意味着检查未关闭的草稿 PR、分支、排队任务和定时接收任务。移除访问权限，并不会替团队决定如何处理已经生成的补丁。

衡量通过验收的修复，而非智能体活动量

选择非关键问题开展小规模、边界明确的试点。将所有分配的报告计入总数，包括重复报告、受阻的尝试，以及最终认定并非缺陷的报告。否则，统计面板会奖励简单案例，却隐藏协调成本。

我们建议记录：通过验收的修复数、每份已分配报告所需的人工审查分钟数、误报、未经验证的输出，以及验收后发现的回归。将类似任务与团队现有流程对比。修订任务说明、修复测试环境、排除看似合理但缺乏证据的结论所花的时间，也应计入。

成本应包括设置、人工审查和所有任务用量，含被丢弃的尝试。OpenAI 的 ChatGPT 更新日志描述的是临时发布额度，而非永久无限执行承诺。设置周期预算前，应确认产品内当前额度以及适用的 Work 或 Codex 用量规则。

有价值的结果不一定是更多 PR。也可能是更早发现无法复现的报告、减少上下文交接，或者为相同数量的修复提供更好的证据。继续或停止的条件应在查看结果前确定，而不是看完精彩演示后再设定。

什么时候用 Dots，什么时候开发专用流程？

我们建议的适用范围是围绕一位明确负责人的变化优先级进行协调：调查这份报告，维护那个有限队列，把证据交回审查。如果验收要求共享服务身份、确定性触发器、明确的重试语义，或者试点尚未证明的生产服务等级承诺，就应选择其他实现路径。

这不是主张所有东西都自行开发，而是要求区分助手的实际帮助与生产系统必须履行的约定。我们的 OpenAI Agents API 工程评估讨论定制产品路线，不把 Dots 当作公开的应用 API。

下一步可以带上一条持续产生缺陷的队列和一个有代表性的代码仓库，进行工作流与 QA 范围讨论。先定义验收证据和权限边界，明确之后再自动化交接过程。