从聊天到交付：我是如何使用 Codex 完成真实工作的
过去使用人工智能，我习惯先问一个问题，再把答案复制出来，自己继续完成后面的工作。写代码时如此，查资料、整理文档和分析数据时也是如此。人工智能提供建议，人仍然负责寻找文件、执行命令、修改内容和检查结果。
使用 Codex 以后，这种分工开始发生变化。
它不再只是坐在对面回答问题，而是能够进入真实的工作现场：读取项目文件，理解目录结构，搜索资料，运行命令，修改代码或文档，检查网页，执行测试，再把完成的结果交给我审核。对我来说，Codex 最值得关注的地方并不是“它会不会写代码”，而是它正在把人工智能从问答工具变成能够承担完整任务的工作代理。
当然，这并不意味着人可以从此退出。恰恰相反，当人工智能能够执行更多动作以后，人的目标设定、边界管理和结果审核变得更加重要。怎样把事情说明白，怎样让过程可检查，怎样判断结果真的完成，是使用 Codex 时最需要学习的能力。
一、Codex 不是更大的聊天框
如果只是输入“帮我写一段代码”或者“帮我写一篇文章”，Codex 当然可以给出结果，但这只是最基础的用法。它与普通聊天工具真正的区别，在于它能够围绕一个目标连续工作，并使用文件、终端、浏览器、搜索、插件等工具完成任务。
OpenAI 将 Codex 定位为面向真实工作的智能代理。官方列出的使用场景已经包括理解大型代码库、开发功能、修复错误、迁移项目、审查代码、更新文档、测试网页、分析数据、生成报告和处理重复工作。换句话说，它首先擅长软件开发，但能力边界已经延伸到许多知识工作。
例如，一个网站突然出现 500 错误。过去我可能会把错误信息贴给聊天机器人，得到一份常见原因清单，然后自己逐项排查。使用 Codex 时，我可以直接打开网站项目，让它先阅读项目说明、检查配置和日志、尝试复现问题，再根据实际证据判断根因。如果我只需要诊断，还可以明确要求“暂时不要修改”；确认方案以后，再让它实施最小修复并运行检查。
这时，我提出的不再是一个知识问题，而是一项有现场、有边界、有交付标准的工作。
二、把问题变成一项可以完成的任务
很多人认为使用人工智能的关键是研究复杂的“提示词技巧”。实际使用下来，我更愿意把它理解为正常的工作沟通。你不需要写一篇华丽的指令，只需要把目标、背景、边界和验收条件说清楚。
以修改博客移动端样式为例，一句“优化一下文章页”几乎没有判断标准。什么叫优化，是字号变大，还是图片不溢出？是否允许更换主题？能否修改数据库？桌面端原有布局要不要保留？这些问题不说明，Codex 只能自行猜测。
更有效的表达方式是：
检查当前 Z-BlogPHP 站点的文章页。手机上正文图片和代码块会横向溢出，请只修改主题前端模板和样式，不要升级程序、不要修改数据库，也不要影响桌面版。完成后实际检查常见手机宽度，并说明修改了什么、怎样验证。
这段话并不复杂，却包含了一项完整任务所需的核心信息：问题是什么，工作范围在哪里，哪些东西不能碰，怎样才算完成。
如果自己不熟悉技术细节，也不必先猜一个解决方案再要求 Codex 照做。可以直接描述现象，让它先调查根因，并选择改动最小的方案。许多问题之所以越改越复杂，并不是工具能力不足，而是一开始就把未经验证的猜测当成了结论。
三、我更信任“先调查，再执行”的工作方式
对于简单、可逆的小改动，可以直接让 Codex 完成。但只要任务涉及旧项目、数据库、框架升级、批量文件或生产环境，我都会把工作分成调查、计划、执行、验证和复核几个阶段。
第一步是调查。要求它阅读项目、复现问题并寻找证据，而不是看到一条报错就马上修改。第二步是计划，列出准备改哪些文件、可能影响什么、如何回滚以及怎样验证。第三步才是执行，并且尽量限制在与目标直接相关的范围内。执行以后必须验证：能运行测试就运行测试，能打开网页就实际打开，能比较数据就比较修改前后的数据。最后再从审查者角度检查一次，确认没有引入新的风险。
这个过程看起来比“一句话生成”多了几步，却往往更节省时间。因为真正昂贵的不是多问一句，而是错误方向执行很久以后再推倒重来。
X 上关于 Codex 的近期讨论中，也能看到类似变化。有用户把关键转折概括为：不要只给零碎指令，而要提供足够上下文和更高层目标。另一些工作流会把需求审查、方案制定、代码实施和独立复核分开，由不同任务承担不同角色。社交平台上的个人案例不能当作严格统计，但它们反映出一个共同趋势：熟练用户正在从“让 AI 写几行内容”转向“设计一套可以检查的交付过程”。
四、它能做的远不止写代码
Codex 最成熟的能力仍然是软件工程。面对一个陌生项目，它可以整理技术栈、入口文件、主要模块和数据流；面对程序错误，它可以结合日志与代码定位根因；面对新功能，它可以完成实现、测试和文档；面对旧系统，它也可以协助进行依赖升级、数据迁移和批量修改。
但在实际工作中，我发现它同样适合处理大量“以文件为中心”的任务。
写文章时，它可以先阅读网站已有内容，了解基本语气，再搜索近期资料，把官方事实和社区观点分开，最后生成带标题、摘要、标签和来源链接的 Z-Blog HTML。与普通聊天生成相比，最大的不同不是文字更漂亮，而是它能够直接检查项目里的文章格式，保存成真实文件，再验证标签、链接和编码。
处理表格时，它可以先审计字段、重复记录、缺失值和异常值，然后计算指标、生成图表与报告。一个可靠的数据任务不应该只有“帮我分析”，还要说明指标口径、原始文件是否允许修改，以及最终需要 Excel、图表还是文字结论。这样得到的不是一段泛泛而谈的分析，而是一组能够继续使用和核对的工作成果。
整理旧网站时，它还可以扫描附件、统计失效链接、生成旧路径到新路径的映射表，并在确认以后批量修复。此类操作尤其适合采用“先扫描、后预览、确认后执行”的方式，因为批量处理的效率很高，出错时影响也会被同样放大。
随着插件和连接器接入，Codex 还可以在经过授权的前提下使用外部工具与资料，例如从项目讨论中整理需求，从代码变更生成发布说明，或把会议记录转换为后续任务。公开信息可以通过网页搜索获取，私有信息则应该通过明确授权的连接器读取，而不是依靠模型记忆或人工复制大量敏感内容。
五、从一次性任务走向可以复用的工作流
当同一类任务反复出现时，每次重新解释全部规则会显得低效。Codex 提供了几种不同层次的复用方式。
项目长期约定可以写入 AGENTS.md。例如一个旧站点必须兼容 PHP 7.1，数据库修改前必须备份，不能覆盖用户已有改动，完成后需要运行哪些检查。这些规则属于项目本身，不应该依赖每一次临时提醒。
跨项目重复出现的流程，可以做成 Skill。Skill 并不是一个神秘的能力开关，而是一组可复用的说明、参考资料、模板和脚本。写 Z-Blog 文章、进行代码审查、制作周报、执行发布前检查，都可以在流程跑通以后固化成 Skill，让同类任务保持稳定。
插件覆盖的范围更大，它可以把 Skills、外部应用、工具和配置组合起来，使 Codex 适应某个角色或一类工作。需要访问邮件、云盘、项目管理工具或内部服务时，则由连接器或 MCP 提供经过授权的实时数据和操作能力。
如果一个流程已经足够稳定，并且需要每天、每周或按固定周期运行，就可以进一步设置 Automation。OpenAI 展示的自动化场景包括问题分类、持续集成失败汇总、发布简报和定期缺陷检查。社区中也有人用它整理竞品动态、会议记录和用户反馈。
我的原则是：第一次做的工作不要急着自动化。先手动运行，观察输入是否稳定、结果怎样验收、失败如何处理、哪些动作必须人工确认。只有一项工作已经可重复、可检查、可回退，自动化才真正有价值。
六、并行任务改变了人与 AI 的协作方式
Codex App 的另一个重要特点，是可以同时推进不同任务。在 Git 项目中，还可以借助隔离的 worktree，让多个任务在不同副本中工作，减少相互覆盖。
例如，一个任务排查后端错误，另一个任务检查前端表现；一个任务实现功能，另一个任务补充测试或更新文档；也可以同时探索两种方案，最后比较结果。复杂项目中，我还可以让一个任务负责实施，另一个任务只负责审查，把“作者”和“审稿人”分开。
并行并不意味着开的任务越多越好。多个任务如果频繁修改同一批文件，冲突和沟通成本反而会上升。真正适合并行的是边界清楚、互相依赖较少、结果可以独立检查的工作。
这也带来了一种新的角色变化：人不再需要一直盯着每一行代码，而是更像项目负责人，决定哪些工作可以同时推进，什么时候需要调整方向，什么结果可以接受，什么风险必须停止。
七、能力越强，越需要明确安全边界
当 AI 只能回答问题时，错误答案的影响通常停留在屏幕上；当它能够修改文件、运行命令和连接外部应用时，权限与安全就成为使用方法的一部分。
生产环境、数据库、批量删除、部署上线、发送邮件、发布文章和对外回复，都不应该被视为普通的文本生成。对于这些动作，我通常要求先给出方案或草稿，保留明确的人工确认点。数据库和批量文件操作必须先备份、统计影响范围，并在执行后重新核对数量和内容。
密码、API 密钥、客户资料和生产数据也不应随意写进提示词或提交到代码仓库。连接外部系统时，应只授予完成任务所需的最低权限。涉及法律、医疗、财务、安全和合规的结果，则必须由具备相应资格的人复核。
Codex 可以帮助我们发现问题、整理证据和执行大量机械工作，但它不能替代目标责任。最终决定做什么、是否上线、是否发送以及是否承担风险的人，仍然是使用者。
八、从一个真实的小任务开始
学习 Codex 最有效的方式，不是先背下所有功能，也不是一开始就搭建复杂的多代理系统，而是选择一个今天原本就要完成的小任务。
可以让它阅读一个陌生项目并写出结构说明；可以让它复现一个积压已久的小错误；可以交给它一份表格，要求先检查数据质量；也可以像本文一样，让它研究资料、阅读网站现有内容，写成适合 Z-Blog 的正式文章并保存为草稿。
第一次使用时，只需要记住一条原则：
给它真实的工作现场，说明目标与边界；让它先调查，再实际完成；最后用测试、数据或页面证明结果。
当某个流程反复成功以后，再把项目约定写入 AGENTS.md，把通用方法做成 Skill，把真正独立的工作并行处理，把稳定、低风险的重复任务交给 Automation。这样，Codex 才会逐渐从一个偶尔问几句话的 AI 工具，变成真正参与日常工作的数字协作者。
人工智能正在改变的不只是写代码的速度，更是工作的组织方式。过去我们习惯亲自执行每一个步骤；现在，我们开始学习如何定义问题、组织上下文、设置边界、验证成果，并与能够使用工具的智能代理共同完成工作。这种能力，可能比任何一条所谓的“万能提示词”都更重要。
