企业官网建设流程全解析

“OpenAI 给 AI 发了张工位”这个说法，最近在我的技术交流圈子里反复出现。dots，OpenAI 推出的云端驻留 AI 编码代理，被很多人形容为“AI 打工人正式入职”。它不再是你在本地终端里短暂调用的命令助手，而是一个常驻云端的执行单元：你发出任务，它异步处理，你下班回家，它还在那边改代码、跑测试、提交 PR。这篇内容我会结合我实际接触和使用 dots 的完整过程，把它的设计逻辑、运作方式、适用边界和上手路径一次讲透，尽量让已经用过 Codex CLI 的朋友和刚接触 AI 编程工具的新手都能看懂门道。

1. 先把概念说清楚：dots 不是又一个“加长版聊天窗口”

很多人第一次听到 dots 的时候，第一反应是“这不就是给 AI 接了个网页后台吗”。这个理解不对。dots 和传统的对话式编程助手在架构和使用模式上完全不是一个物种。

1.1 从本地命令行的 Codex 到云端常驻的 dots

先从背景说起。OpenAI 之前发布了 Codex CLI，也就是那个让你在终端里通过自然语言下达编程任务的命令行编码代理。它的工作方式是：你本地有一份代码仓库，AI 在本地环境里读取文件、编写代码、执行命令，整个过程发生在你面前的终端里。它的优点是干预直接、反馈实时，缺点也很明显——它绑定在你的开发机上，你的开发机一关，它就停止工作。

dots 把这一步搬到了云端。它并不是“Codex 的云端版”这么简单，而是把整个执行环境从你的电脑转移到了 OpenAI 的托管基础设施上。你的仓库可以被克隆到云端环境，AI 代理在那里持续运行，与自己执行任务。你只需把任务说明提交上去，剩下的步骤不再依赖你的电脑是否在线。

这意味着几件事情发生了根本变化。第一，时间上解耦：你不需要守在电脑前盯着它一步步跑，可以发布任务后去开会、吃饭、睡觉。第二，环境上隔离：Agent 运行在独立的云环境里，不会因为本机缺少依赖、网络波动或者后台某个进程抢资源而中断。第三，输出上固化：它完成任务之后会生成可审计的记录、改动文件和结果摘要，你可以对整个过程做复盘。

1.2 “常驻”到底意味着什么

如果说“云端执行”是 dots 的骨架，“常驻”才是它真正的灵魂。传统 AI 助手是“人问一句、AI 答一句”，dots 的模型则更像一个拥有工位的员工。

常驻意味着任务队列机制。你可以一次性提交多个任务，dots 会根据依赖关系和优先级依次处理，而不是每次都从零开始加载上下文。它可以在处理任务 A 的时候保留对仓库结构、技术栈、历史变更的记忆，然后直接过渡到任务 B，这种连续性和状态保持能力，是本地逐条互动模式很难做到的。

常驻还意味着它有自己的“工作时间”。我在实际使用中最直观的感受是：下午五点提交一个测试修复任务，第二天早上到办公室，PR 已经躺在仓库里了，CI 状态也更新了。不用等它即时响应，只要在它运行周期内完成就行。这有点像给项目组加了一个不睡觉、不吃午饭、不请假的远程协作者。

1.3 dots 解决的真实痛点

我在项目里长期维护一个中等规模的后端服务，最耗时间的事情往往不是写新功能，而是处理那些“琐碎但有确定性”的工程事务：修损坏的测试、升级依赖版本之后的兼容问题、重构冗余代码、补充缺失的注释和类型定义。这些事情规则明确、重复性高，但又不能不做。

过去这些工作占用了大量开发时间。现在我的做法是：下班前把这类任务整理成清单，提交给 dots，第二天早上来收结果。它解决的核心痛点就是“让 AI 在你不盯着的时候也能干活”，把开发者的精力从低价值重复劳动里解放出来，用在做架构决策、代码评审和复杂问题攻关上。

2. dots 的运作机制：异步代理是怎么替你干活的

理解 dots 怎么工作，是正确使用它的前提。我不打算讲源码级别的实现原理，而是从使用者的角度拆解它的任务闭环、环境模型和状态管理方式。

2.1 任务分派、执行与交付的完整闭环

dots 的一个典型任务周期大致分四步。

第一步是任务提交。你在 dots 的界面或配套命令行工具里描述要做什么。描述可以是简单的一句话，比如“修复 auth 模块单元测试中的 token 过期问题”，也可以是一段详细的说明，包含涉及文件、约束条件、期望结果。

第二步是环境准备。dots 会准备一个干净的云工作区，克隆关联的仓库，安装基础依赖。这一步值得注意，因为本地环境常见的问题是“我这台机器上能跑，你那边跑不了”。dots 每次从仓库状态构建环境，反而把这类环境漂移问题挡在了门外。

第三步是自主执行。这是最容易让人不放心、也恰恰是最核心的阶段。dots 在这个阶段内会自主决定先读哪个文件、改哪段代码、运行哪条命令。它不是简单地生成一大段代码让用户去粘贴，而是像人一样在仓库里到处查看、修改、验证。你可以通过任务日志实时看到它在做什么，但不需要每步都确认。

第四步是交付与通知。任务完成后，它会把改动提交成分支或 PR，附带一份变更说明，说明改了哪些文件、为什么这么改、测试结果如何。如果任务失败，它也会输出失败原因和已尝试过的方案，方便你接手继续排查。

2.2 仓库环境和权限模型

仓库接入是 dots 使用中的一个关键环节。首次使用时，需要把目标仓库授权给 dots，它会在你声明的分支范围内操作。授权之后，它才能拉取代码、创建分支、推送提交、触发 CI。

从我做过的配置经验来看，权限设置要遵循最小化原则。它不需要也不应该获得你整个账号的所有仓库权限，只需要给它你打算让它处理的那几个项目。它也不应该拥有生产环境的部署凭证。换句话说，dots 像一名持有特定项目读写权限的协作者，而不是拥有整个组织的超级管理员。

云环境本身也是一个独立沙箱。仓库代码和运行环境不会直接映射到你本地文件系统，这样即便任务执行过程中发生了意外操作，受影响的也只是云上的那个临时环境，你的本地代码是安全的。任务结束后，环境会被回收或重建。

2.3 为什么说“你下班它加班”：异步与同步的差异

同步工具的逻辑是“我发出指令，等待结果，再发下一条指令”。整个过程里，你的注意力被锁定在工具上，无法并行处理别的更重要的事。

dots 的异步逻辑则是“我发指令，去干别的，回头收取结果”。它更像项目管理中的委派：你把任务交出去，约定好验收标准，然后去处理自己的优先事项。

举一个我在实际项目里的例子。那天下午我发现主分支上一个登录接口的集成测试不稳定，连续跑了几次都有零星失败。我没有当场去排查，而是把问题连同 Jenkins 日志链接一起提交给了 dots，设定了“先稳定测试，再跑完整测试套件”的目标。晚上我在家看书，dots 在云端定位到是测试数据里有一个时间戳边界问题，修正后所有测试通过。第二天上午 PR 已经等我评审。

这种异步协作模式的好处是，它把 AI 的能力从“你操作时才有”变成了“你不在时也在”。对于有碎片时间的个人开发者，或者人手有限的团队，这带来的产能增量可能比多招一个初级工程师更直接。

3. 我的实战记录：连续一周把修复任务交给 dots

空谈概念没有说服力，我拿自己在一周内实际把任务交给 dots 的经历，让各位看看它到底能干什么、不能干什么。我用的项目是一个基于 Python 的微服务应用，代码量不算特别大，但涉及 API 层、业务逻辑层、数据访问层和一堆第三方依赖。

3.1 第一天：接入与首次任务

第一天我先做最保守的实验，让 dots 处理一个我非常熟悉且结论明确的修复任务：某个接口在传入空数据时返回了 500，应该返回 400。我把相关文件路径和目标行为发给它，并在说明里明确要求它补充单元测试。

约四十分钟后我回来看日志，它做了以下事情：定位到接口入口函数，添加了参数校验逻辑，修改了相应测试文件，跑通了相关的几个用例，然后创建了 PR。我对变更做了 review，发现它把校验逻辑放的位置比我预想的更靠前，风格和我平时写的习惯略有不同，但逻辑上是正确的。我提了一处修改意见，它基于反馈做了调整。

第一步的体验让我确定了几件事：它确有识别任务范围的能力，能区分“只改动这一个函数”和“顺带重构整个模块”的边界；代码风格可以统一调整，在任务说明里写明偏好会明显改善输出；它并不死板，具体实现路径有自主选择的余地。

3.2 第三天：一次跨文件重构

第三天我给了它一个更复杂一些的任务：把项目中所有读取环境变量的方式，从散落的 os.getenv 调用统一收敛到一个 config 模块里，并确保测试覆盖不会因此减少。

这个任务的特点是涉及面广、机械性强、不容易出创造性问题，但特别消耗人工时间。我估算如果自己做需要大约一个下午，并且极其无聊。

dots 用了接近两个小时完成。它枚举了所有引用环境变量的文件，统一改成从 config 模块导入，更新了对应的测试 mock 方式，最后跑了一遍全套单测。我检查的时候发现它遗漏了一处 docstring 里提到旧写法的说明文字，按说无关紧要，但既然发现了就顺手让它改了。

到了这一步，我可以确认它的“上下文记忆”是真实存在的。它能够在多个文件之间来回切换时保持对整体目标的理解，不会修改了 A 文件就忘了 B 文件和它的关联。这种一致性正是我在本地使用早期对话式工具时经常抱怨的短板。

3.3 第五天：处理测试失败和回归

第五天我给它的任务，描述起来非常简单：一条集成测试挂了，需要定位根因并修复。但我知道这个测试牵涉交易状态机和并发回调，属于视角容易卡住的类型。

我在任务里只附了失败信息和一句“彻底解决问题，不要通过跳过测试来掩盖”。我预期它可能会卡住，因此设定了允许它尝试最多三小时。

结果它做了这么几步：先复现失败，确认不是偶发性问题；追踪回调时序，发现一个竞态条件；修改了并发控制逻辑，并增加了对边界场景的断言；完整运行该测试文件三次确认稳定；同步运行了相关的其他两个测试模块确认没有回归。

那天晚上我查看日志时确实有点意外。它不是靠“猜一个原因、改一行代码、跑一下看运气”的撞大运式调试，而是有步骤、有验证地完成了排查闭环。当然也存在局限——如果这是一个需要深度理解业务背景才能定位的问题，比如涉及历史债务或特定业务规则的隐含约束，它仍然可能给出机械化的错误根因判断。所以我依然会对它的结论做 review。

4. 任务边界：哪些活适合交给 dots，哪些会坑到你

用了小半个月之后，我对 dots 的能力边界有了相对清晰的认识。它不是一个通用的“AI 程序员”，而是特定类型工程任务的高效执行器。把任务分型判断好了，用它效率翻倍；把不合适的任务丢给它，反而要花更多时间收尾。

4.1 适合异步托管的任务画像

根据我的经验，以下几类任务交给 dots 的收益最明显：

• 机械性重构：重命名变量、提取公共函数、统一代码风格、迁移配置文件。这些任务规则明确但数量巨大，人工做容易疲劳出错，AI 做正合适。
• 测试补全与修复：现有测试断言失败、缺少边界测试、mock 不匹配。这类任务有明确的成功标准，即测试通过并符合预期的行为规范。
• 依赖升级的兼容性修复：升级某个库之后，API 调用方式变了，编译或测试报错。dots 可以按报错信息逐项修复，让升级过程大幅提速。
• 文档与注释同步：代码行为变了但注释没更新，接口参数没写全等文档债务问题。虽然价值不算高，但它处理这些琐事能省下不少时间。
• 跨文件的小型功能实现：比如给现有模块新增一个端点、新增一个字段校验逻辑、补充一个工具函数。这类任务上下文清晰，不涉及全局架构变动。

4.2 不适合交给 dots 的场景

有正面清单就有反面清单，下面这些情况请谨慎：

• 架构决策类任务：比如“订单模块未来该不该拆分成独立服务”“数据模型怎么设计才能支撑未来三年的业务增长”。这类任务需要大量业务背景和对未来的预判，dots 在信息不充分时的表现，跟所有 AI 工具一样，是自信而大胆的猜测，参考价值有限。
• 涉及敏感权限的操作：生产环境的数据修改、真实用户信息处理、生产密钥轮换。不要因为图省事把这些交给任何自动化代理，风险完全不受控。
• 需要与业务方反复确认的需求实现：如果需求的验收标准本身就模糊，或者隐含了大量只可意会的沟通细节，AI 实现出来的结果大概率离题万里，你在评审纠偏上花的时间可能比自己写还多。
• 高度依赖领域经验的调试：比如一个性能问题是由特定中间件配置和业务数据分布共同导致的，纯代码层面很难看到全貌，dots 容易在表面症状上打转。

我个人的判断标准就三条：可验收、可回退、低风险。只要任务满足这三条，交给 dots 就很安全。可验收意味着有明确的客观完成条件；可回退意味着即使它改坏了，也能通过分支管理轻松撤销；低风险意味着涉及数据的敏感度不高，不需要人工复核安全策略。

4.3 人工评审仍然是不可省略的一环

dots 交付的 PR 我一定会在代码评审阶段逐行看关键改动。不是不信任，而是职责划分问题：它负责高效地产出提案，我负责保证提案的质量和适配性。这套机制有点像技术负责人和初级工程师的关系，一个人给出方向、另一个高效执行，最后还是要由前者把关。

具体到我自己的流程：收到提交通知之后，先看变更摘要，判断范围是否匹配任务描述；再检查关键业务逻辑，确认语义没有出错；最后看测试覆盖，缺失的地方我会补提要求让它继续完善。这套流程跑下来，每个任务平均耗时从过去的半天压缩到半小时以内。

5. 从零接入 dots：注册到交付的完整操作路径

这部分写给还没上手的读者，我从实际部署角度把接入流程顺一遍，同时把容易踩坑的节点标出来。我尽量说得细致，因为任何一个环节卡住都可能导致任务流程走不通。

5.1 账号与仓库准备

前提是准备一个 ChatGPT 账号用于身份认证。dots 的接入直接复用了 ChatGPT 的登录体系，使用体验上比较省事。如果你所在组织使用企业版，还需要确认管理员已经开通了对应的代理功能权限，这一步在团队落地时尤其重要，否则个人账号根本没有入口。

然后是仓库授权。我最初尝试的时候，在授权粒度上吃了点亏。当时图省事选择了对组织账号下所有仓库授权，虽然流程是走通了，但后续每次操作都提示我可以接触项目列表里所有仓库的信息，让我觉得不太安心。后来我重新配置，把权限收敛到了实际需要处理的仓库，才放心开始批量派活。

建议各位在准备阶段就建立好仓库标签或者说分组。比如按“核心业务”“工具链”“测试项目”做区分。dots 的任务面板在针对分组派发任务的时候会更清晰，也避免跨项目混淆。

5.2 创建第一个任务

完成授权之后就可以提交任务了。dots 的任务入口支持一句话描述，但我的经验是描述越结构化，结果越可控。一个良好的任务描述应当包含：

• 明确的目标：期望达成什么样的最终状态。
• 相关文件或模块：帮助它缩小检索范围，减少意外改动。
• 约束条件：比如不允许修改公共接口签名、需要兼容 Python 3.9、必须更新对应测试等。
• 验收标准：例如运行 pytest 全部通过、改动文件数不超过 10 个、需要补充文档等。

举个实际描述的例子：请修复 user_service.py 中 create_user 接口对重复邮箱的处理逻辑，要求返回 409 状态码而不是 500，补充对应的重复邮箱用例，运行 tests/test_user_service.py 确保新增测试通过，不要修改其他文件的非必要内容。

任务提交后，会在队列里进入执行流程。如果你一次提交了多个任务，建议拆分成独立任务而不是揉成一团，这样它能并发或按序处理，处理结果也各自独立，某一个是失败的不必牵连其他任务全部推翻重来。

5.3 结果验证与迭代模式

任务跑完后，不要只关注“PR 合了没有”。我建议按以下顺序检查交付质量：

1. 先看执行摘要，了解 AI 自己认为做了什么。
2. 再看变更文件列表，确认与任务范围一致，没有多改无关文件。
3. 打开关键文件的核心改动，检查实现逻辑是否合理。
4. 看 CI 结果，确认测试在独立环境中真是通过了，而不是本地缓存碰巧绿了。
5. 有疑问直接在评审里写评论让 dots 继续迭代，它可以基于现有 PR 进行新一轮修改。

这套验证流程熟练之后，一个任务从通知到完成 review 基本在十五分钟以内。需要迭代时，我一般会给出非常明确的指令，例如“把刚才的错误处理改成先校验再查询的顺序”或者“给新增的解析函数补充两个空值输入的用例”。反馈越具体，下一轮改动就越精准，不用我重复追问。

6. 几个容易被忽略的实际细节：权限、定价、日志与多代理协作

前面的内容已经把主流程捋完了，这一节我想专门挑几个实际操作中容易忽略、但影响体验的细节展开说说，都是我自己踩过或者对比过的经验。

6.1 权限回收与安全审计细节

很多用户接入的时候只想着怎么把权限交出去，很少考虑回收的问题。我的建议是：定期检查和回收临时任务的仓库权限。如果你只是想让 dots 帮忙修一个历史 bug，任务完成之后，就可以把对应仓库的访问权移除，需要的时候再加回来。

安全审计也要做。好在 dots 的执行过程是有日志记录的，它访问了哪些文件、运行了哪些命令、提交了哪些改动，都能追溯到。对于合规要求严格的团队，我建议把执行日志纳入日常审计范围，异常行为能及时发现。

有一次我发现一个任务日志里出现了访问本不应该需要读取的配置文件的记录。虽然没有造成任何实际影响，但它提醒了我：即使是看起来很窄的授权，Agent 在执行过程中也可能会因为解决某个问题去访问仓库内其余文件。如果你是严格监管的行业，这一点需要提前评估。

6.2 从我的经验看定价与成本控制

关于成本，我只能说从公开信息和实际体感来谈，因为定价策略随时可能调整。dots 的计费核心是运行时长和任务资源消耗，不是你提交了多少条指令。这意味着一个任务让它跑三个小时和跑三十分钟，成本差异是数量级的。

控制成本的有效手段是给任务加上超时限制。我通常把普通修复类任务的时长限制设在一个小时左右，把涉及全量测试的重任务放到两小时。它会在接近上限前输出阶段性结论，不会无限耗下去。还有一个小技巧，如果任务说明里已经提供了明确的定位信息，比如具体函数名或错误日志，它通常能大幅缩短探索时间，间接降低任务消耗。

6.3 日志阅读：理解 AI 在做的每一件事

dots 的执行日志我强烈建议打开看，尤其是前几次使用。不看日志直接收结果，相当于把一个实习生招进来，不看过程，只收产出，你永远不知道它是怎么工作的，也就谈不上优化任务描述的方式。

它的日志包含访问过的文件、执行的命令、每一步的关键发现。从日志里你能学到很多关于任务拆解的技巧：它是因为缺少某个信息而反复尝试，还是因为一开始就拿到足够上下文而一路顺畅？这些观察可以直接转化为你下一次写任务描述的语料。

这个方法也是判断它“聪明”还是“笨”的依据之一。如果日志显示出结构化、有目标的推理过程，说明模型在认真做事；如果只是盲目地改文件、跑测试、再改回来碰运气，你就要留意这是不是它的典型行为模式了。

6.4 多代理协作的潜力：dots 与其他 AI 工具的组合玩法

dots 已经可以作为常驻执行单元参与日常工作流了，更妙的是它还能和你本地的其他 AI 工具组合使用，形成“多代理协作”的工作链。

我现在的工作方式是这样的：白天在 IDE 里用传统的 AI 插件辅助编写代码，比如本地生成新函数、补注释、解释复杂逻辑；到了傍晚，把需要独立验证和批量处理的任务汇总，交给 dots 去云端执行。一边是人在回路里的实时互动，一边是完全自主的云端执行，两者形成互补。

多代理协作的另一个方向是，让 dots 跑完一个任务之后，自动触发下一个依赖任务。比如修复主功能代码之后，紧接着运行回归测试，若发现问题再自动生成修复请求。这需要通过任务面板的编排能力来实现，把“修复 bug”和“跑回归”串联成一条流水线。

在我个人的实践中，这种编排方式最节省时间的场景是处理技术债清零类的工作。我规定每周五下午统一给 dots 派发一组低风险清理任务，周一早上汇总结果，新的一周在干净整洁的代码库上开始。那段时间我们的遗留问题数量肉眼可见地下降。这个习惯的形成，本质上就是接受了 dots 这种“云端打工人”的角色设定，把它看成团队里一名不领工资但从不摸鱼的远程工程师。

最后再分享一个体会：对 AI 工具的态度，我不推荐两个极端，一个是不管不顾地把生产环境直接交给它，另一个是永远停留在“让 AI 给我解释代码”的低阶用法。dots 这类云端常驻代理真正改变的不是写代码的速度，而是你对时间和任务的分配方式。试着把第一个值得托付的小任务写清楚、发出去、收回来，你会发现“你下班它加班”这句话，从一句口号变成工作日常并不需要多少时间。