用两次真实求职经历理解 ChatGPT Codex dot 和云电脑

10 月 5 日，我和 dot 完成了 11 份有效求职申请。第二天早上，一篇把这次经历讲清楚的 LinkedIn 帖子也发了出去。

看到这个结果，很容易把它理解成一句话：我说要找工作，AI 就替我全部做完了。实际过程里，有简历底稿，有我对经历的纠正，有反复确认的申请问题，也有登录、文件上传和退信。正是这些细节，让我开始认真区分：AI 会回答问题、会调用软件、会操作电脑，究竟是怎么连起来的？

我想用这两次经历，把自己一直好奇的几个问题串起来。ChatGPT、Codex 和 dot 有什么区别？为什么能直接跟它说话？MCP 是不是让 AI 获得了所有软件的控制权？云电脑又是不是意味着，我以后可以把自己的电脑关掉？

先说我目前的理解：能做成多少事，除了模型本身，还取决于它拿到了哪些工具、在哪台机器上运行、能访问什么资料，以及有没有把结果检查到底。本文的产品说明以 2026 年 10 月 6 日可核验的公开资料为准；具体按钮、套餐和开放范围会继续变化。

1.先把三个名字分开

会按任务来选入口。

ChatGPT 适合从一个问题开始：讨论思路、解释概念、写作、分析材料，也可以在具备相应功能和连接的情况下查资料、调用工具。它已经超出了单纯的文字聊天。若要判断某个任务能不能做，仍然要看当前账号和界面实际提供了什么。

Codex 的重心是软件工作。它会围绕代码库读文件、修改代码、运行命令和测试，帮我把一个需求推进成可以检查的改动。现在的 Codex 也有浏览器和计算机操作能力，但能力跟运行模式有关，不能只看到 Codex 这个名字，就假定它能控制任何电脑。

dot 在我的使用场景里更像持续合作的个人助手。求职过程中，今天改过的材料、还没完成的申请、明天要发的内容，需要放在同一段工作里继续处理。我感受到的区别，主要在于工作怎样组织、怎样接续，以及执行到哪一步会回来找我决定。这些体验不足以证明它用了某个更聪明的模型，也不能反推出它的内部架构。公开文档确认，dot 有自己的云端电脑和浏览器；它的开放范围仍在逐步扩展。

三者的能力有交集。我不会把它们画成互不相通的三个盒子。比较实用的分工是：需要想清楚问题时先讨论；要在项目里改代码时进入 Codex；事情横跨材料、网页、邮件和后续沟通时，由 dot 协助推进。最终仍要检查当前环境，而不是靠名字猜功能。

2.AI 怎样从一句话走到一个点击

这里有两条很容易混淆的路线。

第一条是调用软件提供的工具。比如邮件服务把搜索邮件、读取正文等能力开放出来，AI 可以带着结构化参数调用，并拿到结果。MCP，全称 Model Context Protocol，是连接 AI 应用和外部工具、数据源的一种协议。可以把它理解成统一描述工具和交换信息的方式。

MCP 本身不会凭空生成一个 LinkedIn 接口，也不会替用户授予账号权限。服务端要实现相应能力，应用要连接它，账号访问还要通过认证和授权。只读邮件与发送邮件也是两种不同动作，不能因为前者可用，就默认后者已获得同意。

图 1MCP 和浏览器操作处在不同层次，可以配合使用。概念图，依据公开协议与工具文档整理；不代表 dot 的内部实现。

第二条是操作页面或桌面。当没有适用的接口，或任务必须经过网页时，AI 可以在获准的环境中观察页面、找输入框、填写内容、点击按钮，再观察页面是否变了。底层可能利用网页元素信息，也可能根据屏幕图像执行鼠标键盘动作。具体方式取决于工具，不能把所有操作都描述成“识别截图后点坐标”。浏览器控制工具本身也可以通过 MCP 接入；一个说的是连接方式，一个说的是实际操作方法，两者可以同时存在。

我理解的执行过程大致是这样：读清任务和当前页面，选下一步，执行，重新检查。搜索结果变了，按钮没出现，登录过期了，都意味着下一步要重新判断。如果输入框里残留着旧答案，还必须发现并改掉。网页自动化的难点，往往就在这些日常的小意外里。

我的 LinkedIn 案例走的是已登录的云端浏览器界面；查投递邮件则用到了已连接的邮件工具。它们可以配合，但不能据此说“LinkedIn 通过 MCP 开放了全站控制”。发布以后能看到正文和固定链接，才有了这一项动作完成的证据。

至于 Codex 能不能控制我的电脑或云端电脑，答案需要拆开。Local 和 Worktree 模式中的代码工作在本机上；Cloud 模式会在另一个工作环境里执行。浏览器、桌面控制、远程连接是否可用，还要看具体产品入口、操作系统、连接状态和权限。云端代码环境也不必然带着一套可随意点击的完整桌面。

一个很具体的例子是，当前桌面内置浏览器文档明确写着不支持自动文件上传。这不能被扩大成“所有 Codex、所有浏览器都无法上传”，也不能因为其他环境能上传，就忽略眼前工具的限制。我的电脑上的文件、登录状态和公司网络，同样不会因为开了云任务就自动出现在远端。

3.跟 AI 说话时背后发生了什么

内置语音支持实时交谈、打断、补充和纠正。它跟“语音听写”有区别：听写主要把口述转成待发送的文字，实时语音则要持续处理双方的说话和轮次。文字适合精确修改，语音适合把一个还没整理好的问题先讲出来。

公开的语音系统至少有几种实现方式。最容易理解的是一条链：把声音转成文字，让语言模型处理，再把回答转回声音。它的中间文字比较容易检查。另一种是实时语音模型直接处理音频，在同一个会话里结合理解、工具调用和语音输出。还有一种把实时对话与后台任务模型分开，让前者保持对话，后者处理推理和工具工作。

截至本文日期，OpenAI 当前的 ChatGPT Voice 公开说明提到了 GPT-Live。但这条信息不能用来断言我使用的 dot 具体采用了哪种模型或完整语音链路。上述结构是帮助理解的公开参考架构，不是对 dot 内部实现的拆解。

“流式”也没有那么神秘：声音可以分成连续的小段发送和生成，不必等一整段长录音结束才开始处理。系统还需要判断人什么时候开口、什么时候暂时停顿；有些方式进一步估计一句话是否已经说完。能打断和接话，依赖的是这类实时处理和轮次管理。

语音改变了下指令的方式，却不会凭空增加软件权限。我口头说“发出去”，系统仍需要知道发什么、发给谁、用哪个账号。重要内容尤其要说清楚，避免让一段含糊的口头讨论直接变成对外承诺。

4.第一次实战十一份有效申请怎样完成

这次求职并不是从一份空白简历开始。我先确认可以使用的材料和申请方向，再让 dot 逐个看职位描述，也就是 JD，判断要求与我的经历是否相符。软件、供应链和教学岗位需要突出不同证据，不能把同一段介绍原样塞给所有公司。

有一份业务系统实施岗位愿意提供培训，适合把真实的数据核验、软件测试和教学解释经验对应过去，但不能编成已有的商业系统实施经验。另一份物流行政岗虽然带着 Warehouse，完整职责却侧重订单、记录和协调，不能只凭标题判断。进入申请前，还要对照公司、岗位编号和历史邮件去重。

底稿的分工很具体：11 份有效申请里，4 份使用软件方向主简历，6 份使用供应链方向主简历，另 1 份使用修正后的教学简历。逐岗写过申请文字、求职信或问题答案，但这不等于把 11 份简历正文都完整重写过一遍。

接下来是填表和提交。dot 需要打开正确的岗位，选择对应文件，处理申请问题，检查系统预填内容，完成获准的提交动作。需要我确认的关键事实和选项，仍然要回来问我。登录状态失效、上传限制、旧答案残留，都可能打断这条流程。

这次最值得保留的细节，发生在“提交以后”。有一封邮件进入了已发送，但大约 3 秒后就收到了退信。如果统计只停留在发送动作，它会被算成一份成果；检查退信后，这一份被从有效数量中扣掉。

图 2Gmail 中的一份 SEEK 申请确认邮件节选。邮件日期为 10 月 5 日，截图采于 10 月 6 日，姓名已遮盖。它证明平台确认收到这一份申请，不代表招聘方已阅读或给出面试。

因此，我可以准确地说，当天完成了 11 份有相应提交证据的有效投递。不能把它改写成 11 份从头定制的简历，更不能写成全程零人工参与。

投完后，我又审阅了实际使用的简历。供应链方向需要补上 Power BI 和 Excel，减少项目数量，把经历按 STAR 讲得更清楚，也就是交代情境、任务、行动和结果。我随后要求每次重新比较 JD，必要时调整简历顺序和重点。这是复盘后的改进；前面 6 份供应链申请使用的旧主版本，没有被自动替换或重新发送。

这一轮里，我的工作从重复打开页面、搬运文字，更多转向确认底稿、纠正经历、决定岗位是否值得投，以及处理异常。AI 接手了一部分执行，我依然要对申请里的事实负责。至于到底省了多少时间、提高了多少面试率，我没有做对照测量，不会用一个漂亮百分比来替代证据。

5.第二次实战从想法到 LinkedIn 发布和沟通

第二个案例来自一个很自然的想法：既然已经做过这轮求职，能不能把过程写成别人看得懂、也经得起追问的 LinkedIn 内容？

10 月 5 日，我提出选题后，看了英文草稿和中文预览，再要求修改 STAR 叙事。我特别纠正了一个容易被写错的地方：我已有 React、TypeScript 和 Express 项目经验，不能把自己包装成一个完全零基础、只靠 AI 就突然会开发的人。文章要说清楚原来的基础、我做了什么，以及 AI 具体参与了哪些步骤。

草稿随后补充了实际行动、提示词思路和结果。我检查事实和表达，确认要保留哪些内容，也批准了最终版本与 3 个标签。发布被安排在次日进行。写出草稿和对外发布是两个阶段，中间这一轮审阅确实改变了文章内容。

发布前又做了一次核对：投递数是否仍然准确？有没有已经发过相同内容，或存在会导致重复的排期？此前的另一篇 RAG 帖子保持原样，没有被当成这次的新稿覆盖。

10 月 6 日 08:02，澳大利亚东部夏令时间，这篇 2,946 字符的帖子发布成功。检查包括页面上可见的正文和对应的固定链接。读者可以在文末找到原帖。这一段流程里，AI 既处理了文字，也操作了网页；我的审阅决定了它最终代表我说什么。

招聘联系人沟通是另一条相关工作。10 月 5 日的记录包括 2 条私信和 1 个连接邀请；10 月 6 日又实际联系了 3 人。后来每日上限改为 10 人，但上限和完成数要分开，不能因此宣称当天已经联系了 10 人。

实际操作中，先核对对方的角色和公司，再检查之前有没有聊过、邀请是否已经待处理，避免重复打扰。有一次直接私信需要付费额度，流程退出后改用可用的普通邀请。对我来说，有价值的消息需要知道对方是谁、与目标岗位有什么关系、我的哪段经历能接上。批量把同一段自我介绍丢给陌生人，很难形成有效交流。收到一条回复也不能直接算成面试机会；这篇文章只把已核实的发送动作当作结果。

图 3LinkedIn 会话中的职业介绍节选，截图采于 10 月 6 日

用户同意、工具能执行、平台允许，是三件需要分别确认的事。LinkedIn 对未经授权的自动访问、发消息和发布等行为有明确限制；这里记录的是一次操作结果，不代表平台许可这种方式。更稳妥的使用方式，是让 AI 整理相关经历、准备待审核的文字，再用平台允许的方式完成发布和沟通。

6.云电脑云服务器和 AWS 到底是什么

做到这里，我自然会问：既然 AI 能在另一台电脑上完成任务，我是不是可以把所有工作都搬到云端？

先把“云”还原成实体。云服务背后仍然是数据中心里的服务器、磁盘和网络。我们通过网络按需使用这些资源，不必自己买齐、摆好、维护每一台机器。AWS 是亚马逊的云服务平台，Azure 和 Google Cloud 也是提供者。“上云”不等于“用 AWS”，更不能据此猜测 dot 的电脑由哪家厂商提供。

而且，云里租到的东西不一定长得像桌面电脑。

虚拟机 VM 像一台分配给你的计算机，可以选择系统、安装软件、运行程序，也通常需要自己管理系统和补丁。虚拟桌面或云电脑在此基础上提供适合远程交互的桌面体验，本地设备主要发送操作、接收画面。

容器主要打包应用及依赖，让它在合适的环境里运行；它不天然提供一套给人点鼠标的完整桌面。托管数据库直接提供数据库服务，把一部分运维交给供应商。Serverless 通常进一步减少自己管理服务器的工作，但服务器仍然存在，费用和资源限制也仍然存在。

图 4　聊天入口、运行机器与账号会话需要分别看。下方展示界面操作的通用循环，是概念说明，不是某次任务的内部记录。

所以，“把工作搬到云端”要问得更细。如果是一段数据处理脚本、一个网站或一项可重复运行的任务，可能不需要桌面，容器、虚拟机或托管服务就够了。如果工作依赖某个图形软件、现有登录状态、摄像头或本地文件，迁移就需要另外设计。换个运行地点，不会自动复制所有依赖。

dot 自带的云端电脑、Codex 的云端工作环境、可以自行租用的服务器，以及家里的电脑，是不同资源。能使用其中一个，不代表自动拥有其他几个的访问权。让 AI 操作某台机器，需要该机器有受支持的连接方式、合适的软件环境和明确的授权。从手机发一条指令，也不代表任务跑在手机里。

这也回答了关机的问题：任务如果在 dot 自己的云端电脑上运行，我的电脑关机不一定会影响它；任务如果在我的电脑上执行，那台电脑仍然需要保持可用。先确认执行地点，再决定能不能合上笔记本。

^{7.我的电脑还需要承担什么}

如果使用云电脑，本地仍然需要一个能联网的终端，通常还要用到屏幕、键盘、麦克风或其他外设。远端算得再快，也消除不了网络延迟、断网和外设兼容问题。真正可以减轻的，是部分本地计算和维护负担；是否划算，要看任务多久运行一次、需要多大配置，以及存储和网络费用。

另一种选择是把自己的旧电脑配置成可远程使用的机器。这能保留熟悉的软件和文件，也让硬件控制权更直接。但“自托管”意味着电力、稳定联网、系统更新、备份和访问安全也要自己负责。设备已经买过，不代表持续运行没有成本，更不代表默认安全。而且，即使程序跑在家里，如果仍然调用云端模型，相关输入仍可能被发到云端。数据会去哪里，要沿着实际流程看。

一个容易验证的迁移起点，是用一份不敏感的样本跑数据处理。先确认输入在哪里、结果存到哪里、失败后如何重试，再决定是否扩大。求职材料和账号则要额外检查保存位置与访问范围，不能为了省几次上传就随意开放整台机器。

回头看这两次经历，最实用的变化是，我开始要求 AI 交付可以检查的结果。申请要有提交记录，邮件要看退信，帖子要有正文和链接。与此同时，职业经历是否真实、哪些机会值得投入、公开说出去的话是否准确，仍然由我判断。

这也是我会继续使用这类工具的方式：让它多承担整理和执行，让我把注意力放在真正需要自己决定的地方。下一次有人问“它到底能不能做”，我会先追问一句：在哪个环境，用什么工具，做到哪一步才算完成？