Codex 能做什么？哪些活不该交给它

装好 Codex 之后，大多数人是从改一个函数开始的。其实它能接的活不止这一类，反过来，也有一批活不该交到它手上。这条线在哪，最好在动手之前就弄清楚。

它真正的本事是把一整件事做完

Codex 真正的本事，是在真实的项目里把一件事推进到能 review 的状态。读文件、写代码、跑测试、整理 diff，这些动作它自己串得起来。你要做的是把活交代清楚，而不是替它排好每一步。

接手一个陌生项目的时候，最省事的开头是让它先读一遍。项目用什么技术栈，入口文件在哪，核心模块在哪，测试和构建命令是什么，这些它能替你摸清楚。哪些文件不能随便动，它读一圈也能给你标出来。

很多人上来就让 Codex 改代码，任务容易失败，就是因为它还没看明白项目长什么样。

这几行逻辑是干什么的，这个组件为什么这么写，接口的调用链路是什么样，一个 bug 可能牵扯到哪些文件。这些问题丢给它都行。

它不只看单个函数，还会顺着上下文把模块关系和数据流捋一遍。接手别人的旧项目时，这一条特别省时间。

修一个能复现的 bug，加一个设置页，给表单补上校验，或者把某个前端页面顺一遍。这类活范围明确，结果能验证，交出去最放心。

一个大项目整包丢给它就不合适了。更靠谱的做法是把任务拆小，先让它读项目，再让它出方案，一次只改一个模块，跑完测试看 diff，确认没问题再往下走。它适合连着做完一串小任务，不适合一口吞下一个大项目。

补单元测试和边界条件，把重复的逻辑提出来，拆一拆过长的函数，顺手把组件结构理顺，这些它都能做。

但这类活必须提前划边界。不改业务逻辑，不改公共 API，不引入无关依赖，不做大范围重构，改完必须跑测试。它可以重构，前提是范围由你定。

README 和安装说明，接口文档和环境变量说明，PR 描述，这些都能让它起草。commit message 和更新日志也一样。

在 Codex 的工作流里，文档不是附属品，是上下文的基础设施。文档写得越清楚，后面接手的人和 AI 都越省事。有一点要提前交代：不许编造不存在的命令，不确定的信息必须标出来。

跑测试和 lint，跑 typecheck 和 build，看一眼 git status 和 git diff，也能搜代码、检查改动结果。这是它和普通聊天工具最不一样的地方，它不只是猜答案，它能自己验证。

命令执行有风险，所以要有分工。能验证的让它跑，涉及生产环境、数据库和真实用户数据的操作，不要让它自动执行。

有几类活，最好不要直接交出去。生产数据库和真实用户数据算一类，支付和权限这类核心模块算一类，大规模架构迁移也算一类。

还有两种容易漏掉。一种是没备份的重要项目，一种是没测试的核心业务。

判断标准其实很实在。目标明确，范围可控，上下文清楚。结果能验证，失败能回滚，风险也能接受。这几条都满足，交给它没问题。缺一条，先自己动手，或者先把条件补上。

还有一条更难把握的，连你自己都没法验收的任务。如果结果对不对你都判断不了，那就不该让它独立完成。它能提高效率，但替不了你做判断。

第一次用，可以先挑一件范围清楚的小活试手，比如修一个能复现的 bug，或者补一段测试。跑顺了，再往外扩。