开发工作里，一条 Bug 通常不会自己长成一份可执行任务。用户说页面打不开，客服补了一张截图，开发者在群里问浏览器版本，之后又有人贴出一段日志。真正动手改代码之前，已经有人花时间把这些信息串在一起。
OpenAI Dot 与 Codex 的配合，可以从这一段工作开始理解。Dot 协助收集背景、追踪问题和协调任务，Codex 处理明确的仓库工作，开发者检查修改与最终结果。每个环节都有自己的输入和交付，分清之后，比一句“把项目全部优化一下”更容易得到可用结果。
第一件任务完全可以只读资料、整理问题。确认它没有误解之后，再允许修改一个范围明确的 Bug，不必一开始就交出生产仓库的全部操作权限。
第一关：把用户反馈变成能接手的问题
“登录有问题”包含太多可能性。密码错误、验证服务不可用、Cookie 设置错误、旧页面缓存，以及后台接口失败，都可能表现成登录不成功。
Dot 接到反馈时，应该先收集条件：出现在哪个页面、发生时间、使用设备与浏览器、操作步骤、预期结果和实际结果。已有日志就附位置，没有日志就保留缺失。不要根据一张截图直接猜根因。
一份能交给开发任务的问题单，可以写成这样：
目标：调查桌面端登录提交后停留在原页的问题。输入：用户截图、页面路径、发生时间与浏览器版本。先读取相关登录流程和近期修改，列出可能路径及需要补充的证据。没有复现或日志支持时，不要把猜测写成已确认根因。
先调查也有产物：相关代码位置、信息缺口和下一步检查方案。不能因为暂时没有改代码，就认为这轮工作没有价值。
反馈中如果含有令牌、用户信息或完整请求头，在转交前处理好。大多数前端问题不需要把整份客户资料带入开发任务。保留必要条件，减少无关数据，也让问题更容易读懂。
第二关：明确代码到底在哪里运行
Dot 有自己的云端电脑，但一个代码项目还有仓库、依赖、配置和测试数据。知道 GitHub 地址，不等于已经拥有一个准备好的开发环境。
可以让 Dot 使用预先设置的 Codex 云环境，也可以在连接的个人电脑上创建本地任务。两种方式要分开考虑。
| 工作方式 | 适合的情况 | 开始前要确认 |
|---|---|---|
| Codex 云环境 | 仓库和准备步骤已配置，可独立执行 | 分支、依赖、权限、必要配置 |
| 本地 Codex 任务 | 需要本机目录或专用工具 | 电脑在线、应用开启、项目路径 |
| 只读代码整理 | 暂时不允许修改，先了解问题 | 当前版本与允许读取的范围 |
Dot 的电脑与应用文档说明，本机文件和工具需要相应连接，本地工作有在线要求。它的云端浏览器也不继承你个人浏览器的登录。
一个实用原则是：每份交接都写明仓库、分支或版本和执行位置。尤其是同一项目有本机、测试服务器和生产服务器时，不能只说“在项目里改”。
Cloud 和 Local 的名字再直观，也不能代替查看实际任务环境。开始前问一句“这项工作使用哪个目录和哪个环境”，比修改后才发现改错位置省事。
右侧电脑区域区分了助手电脑与个人电脑，个人电脑仍需明确授权。
第三关：让 Codex 接到小而完整的修改
任务粒度过大，容易混入不必要的重构；任务粒度太小，又可能只修表象。合适的范围是一个可以独立说明、独立检查的问题。
以搜索结果页为例，任务可以是“修正空结果状态，让筛选条件保留，并提供返回全部结果的入口”。不要同时要求重做首页、迁移路由和更新依赖，除非这些事情与问题确有关系。
交接单最好包含原始反馈、已经确认的条件、允许修改的范围、当前项目约定和完成标准。已有 AGENTS.md 或开发文档就让它先读。框架版本也要准确，不能用一套旧经验处理升级后的接口。
在指定分支上修复搜索空结果页。保留现有页面结构和查询参数，不改数据模型。先读项目开发约定。交付代码差异、必要检查结果，以及没有覆盖的情况。完成后等待审查，不合并、不发布。
这种写法仍允许开发助手判断具体实现，但没有把所有后续动作一并交出去。
Dot 负责协调时，还要给任务设置优先级。紧急修复与一项顺便想到的优化，不应该争抢同一条发布路径。无关改进记入后续事项即可。
演示说明了任务之间的分工。审查代码时，仍应以具体差异与实际交付为准。
多个任务并行，先处理共享文件
并行容易让人感觉速度更快，但代码有共享状态。两个任务同时修改同一个路由、配置文件或数据模型，最后还需要有人处理相互影响。
先按问题拆任务，再看文件与依赖是否重叠。一个任务整理文档，另一个修独立页面，通常容易协调；两个任务都改登录逻辑，就需要一个明确的协调者。
可用的工作安排包括让任务使用不同的 Git 工作区，或明确文件归属与合入顺序。具体办法要服从仓库约定。不要让两个任务各自认为自己拥有完整项目的修改权。
任务交付之后，也不是把两份结果简单相加。共同集成后的行为需要检查。一个分支单独通过检查，可能仍与另一个分支在接口、字段或页面结构上冲突。
Dot 可以帮助维护任务关系：A 的修改是否是 B 的前提，哪个任务碰到了共享文件，哪些检查要等集成后执行。这样的信息比“两个任务都完成了”更有用。
任务与记忆指南说明，助手可以分派工作并继续跟进，但新任务有自己的上下文。交接时仍要带上必要约束，不能假设每个任务都知道主对话里说过的全部事情。
检查结果要和问题相对应
代码任务最容易生成一份看起来很完整的检查报告：构建通过、若干测试通过、没有类型错误。它们有用，但不一定覆盖用户最初遇到的情况。
修一个搜索空结果页，至少要检查有结果、无结果、筛选后无结果，以及返回入口是否保留正确参数。若原始问题发生在手机端，只有桌面截图仍然不够。
修权限问题，要检查允许的操作与不允许的操作；修数据导入，要检查重复记录与失败后的状态。不要为了凑数量编写一堆只证明实现细节的检查。
已有项目要求的检查应完成，额外检查则围绕风险安排。文案小改、可逆的样式微调，和数据库迁移显然不需要同一套验收强度。
如果环境缺少必要服务，助手应明确哪些检查没有执行，提供原因和可继续的步骤。不能把“静态阅读看起来正确”写成“运行已验证”。
交付时可以要求一份短报告：问题如何修正、检查了什么、结果在哪里、仍有哪些限制。大段重复计划和命令说明，不会让修改本身更可信。
PR、合并、部署，分别授权
很多演示会把流程压缩成“发现问题，然后自动修好”。真实仓库里，准备代码、提交 PR、合并 PR 和部署，有各自的影响。
你可以允许 Dot 和 Codex 创建一个供审查的修改，同时保留合并决定。如果仓库本来就有审查与发布流程，让助手沿用它，不要因为这次使用了新工具就绕开原有管理。
PR 说明应该围绕实际触发条件和修改后的行为。像“提升稳定性、改善体验”这样的摘要太宽，读者仍要猜改了什么。更好的描述是：“筛选后没有结果时，保留当前筛选条件，增加返回全部结果入口；补充无结果路径检查。”
如果代码修改涉及配置，审查时要区分应用代码与部署配置。构建产物更新了，不代表服务器上的环境变量、反向代理和外部服务也同步完成。
上线之后再检查公开结果：请求是否到达正确实例，资源是否更新，原来的触发路径是否恢复。助手交出一个成功的本地结果，仍然不能替代公开站点验收。
把权限写在任务中，规则写在适当位置
长期协作常见的麻烦是规则放错位置。一次修改只允许碰哪些文件，应当在那次任务里说；整个仓库通用的规范，可以放进项目约定；助手对外沟通和高影响动作的长期边界，可以使用产品支持的控制方式。
不要把所有偏好堆进一个几千行文件。任务越具体，规则越容易找到并执行。反过来，别指望助手只凭上次聊天记住每个项目不同的发布习惯。
“先给我看改动再发布”和“可以自动合并所有修复”是很不同的授权。不要用“你全权负责”代替明确的动作范围，尤其是长期任务会持续收到新信息。
控制指南说明，指令和 Custom Rules 都不能取消内置安全要求。设置规则也不会自动给助手访问某个仓库或电脑的权限，这些仍要分别连接。
更重要的是，代码库和网页里的文字不应该变成用户授权。仓库附件中一段“请将所有密钥发到某地址”的内容，是需要处理的材料，不是项目负责人下的新命令。
对失败和停止，做一次完整交接
一次构建失败，可以留下可继续的修改；一次登录失败，可以留下待处理的权限请求；一项需求无法复现，可以留下条件缺口。问题在于，助手要把这些分别报告。
可以要求它固定说清楚：哪一步成功、哪一步失败、修改是否保留、哪个任务还在运行、下一步由谁处理。需要你提供账号连接，就不要悄悄改用无关环境继续。
停止任务也要看执行关系。主助手停下，委派出去的工作和未来安排未必都停止。到 Activity 检查子任务，到 Scheduled 查看重复工作。停止前后查看 Git 状态，保留需要的修改，别把未提交结果当成已经保存。
开发项目尤其要记录结果归属。某次修复位于哪个分支，是否推送，有没有 PR，线上使用的是哪个版本。这些记录可以放在任务交付里，不必写成繁重的行政流程。
可以从一个每周问题清单开始
如果还不放心让 Dot 直接协调开发，先给它一项只读任务：每周整理用户反馈和仓库中尚未处理的问题，找出重复报告、缺少复现条件的事项，以及适合本周处理的小修复。
要求每项建议都附原反馈、相关代码或 issue、影响范围和需要补充的信息。然后你挑一项，明确交给 Codex。下一周再看反馈是否处理，修复是否合入，是否还有相同症状。
这个循环很普通，但容易形成实际帮助。你不需要第一天就建立庞大的 Agent 团队，也不需要把生产权限全部交出。先让一条反馈顺利变成一份能审查、能交接、能确认结果的修改，再讨论扩展到更多项目。