难以置信！这10个Codex技巧让你的工作效率瞬间翻倍！

嘿，朋友们，跟我聊聊 Codex 的新变化吧！

大家好，我是阿星！

最近我在加班学习 Codex 的新功能，发现这次更新可真有意思。表面上看，Appshots、Goal mode、浏览器标注、插件共享和分析功能都上线了，但其实更大的变化不是功能多了，而是 Codex 的角色发生了转变。

现在，Codex 不再仅仅是一个简单的代码助手，而是逐渐变成了一个懂得上下文、能进行长时间任务、可以操作浏览器、接入团队工具，并且能持续追踪目标的开发代理。接下来，我给大家分享10个实用的小技巧。

1. 提示词要用四段式，不要只说“帮我改”

其实，Codex 的最佳实践已经很明确地告诉我们怎么提示了：

目标、上下文、约束和完成标准。

换句话说，就是 Goal、Context、Constraints、Done when。（信息

比如，普通的请求可能是：

帮我优化登录页

而更专业的写法应该是：

Goal：优化登录页的移动端布局。
Context：关注 src/pages/login.tsx 和 src/components/AuthForm.tsx。
Constraints：保持接口逻辑不变，不引入新的 UI 库，风格一致。
Done when：在 375px 宽度下，按钮不溢出，表单间距一致，现有测试通过。

这样写的好处在于，Codex 不用猜测，你给了它明确的标准。

2. 长任务用 /goal，一次性搞定，不要催

之前用 AI 写代码时，最令人头疼的就是它可能写到一半就停了，你还得不停地说“继续”“再来点”。

现在，Goal mode 正式上线了。

官方说它可以在 Codex App、IDE 插件和 CLI 中使用，

你可以让 Codex 围绕一个明确的目标持续工作，甚至可以持续几个小时或几天。（信息

适合用 /goal 的任务不是“写一个按钮”，而是像这样的：

/goal
把这个项目的登录、注册和忘记密码的页面统一成新的设计规范。
要求：

1. 1.不改变后端接口；

2. 2.保留现有表单校验；

3. 3.统一移动端样式；

4. 4.每完成一个页面后运行相关检查；

5. 5.最终给我总结改了哪些文件，哪些地方需要人工复核。

关键在于，目标文本本身就是完成标准。

所以，/goal 的提示越清晰越好，重点是要明确什么算“完成”。

3. 对于复杂任务，先开 /plan，别急着让它动手

如果任务比较复杂，建议先让 Codex 规划，而不是直接让它动手写代码。

官方也建议，对于那些复杂、模糊或难以描述的任务，先让 Codex 进行计划，再开始实现。（信息

你可以这样写：

先别改代码。
请先阅读项目结构，找出实现这个功能可能涉及的文件。
然后给我一个修改计划，包括：

1. 1.需要改哪些文件；

2. 2.每个文件改什么；

3. 3.可能的风险；

4. 4.需要我确认的问题。
   等我确认后再开始实现。

虽然这一步看起来慢，但其实是省时间的。

因为 Codex 出错的地方往往不是不会写代码，而是最初的方向就理解错了。

4. 用 Appshots 传递上下文，少说废话

这次更新中最实用的功能之一就是 Appshots。

在 macOS 的 Codex App 中，只需按两个 Command 键，

就能把当前应用窗口发给 Codex。

不仅是截屏，还能带上可读取的文字。（信息

这意味着你不再需要这样描述：

页面右上角那个按钮旁边的间距有点怪，就是头像左边那个地方……

你可以直接使用 Appshot，然后说：

看这个界面。
把顶部导航右侧的按钮组间距调得更自然一点，视觉上和左侧的 Logo 对齐。
不要改页面结构，只改样式。

对于 UI、报错弹窗、配置界面、控制台输出、设计稿预览这类场景，

Appshots 会大幅减少沟通成本。

5. 前端改样式，用浏览器标注，不要光说文字描述

Codex 的 in-app browser annotations 这次也增强了。

官方说明里提到，

高级标注能够直接针对字体大小、颜色、间距等样式问题给出更精确的反馈。（信息

这对前端开发者特别有帮助。

以前你可能会说：

第二个卡片的标题太大，

按钮离底部太近，

图片比例不太对。

现在，简单有效的方式是：

打开页面预览，直接在浏览器里标注对应的元素：

这里字体缩小 2px。
这里上下间距加 8px。
这个按钮和左边的文案居中对齐。
这张图保持 16:9，不要拉伸。

这样比起写长长的提示词要准确多了。

本质上，这让 Codex 从“听你描述页面”变成了“看着页面来改”。

6. 让 Codex 自己来写测试、跑测试、分析结果

很多朋友在使用 Codex 时常常犯一个错误：只让它写代码，却不让它去验证。

官方的使用建议里也提到，不能仅仅依赖 Codex 进行修改，

还要让它负责创建测试、执行检查、确认结果以及审查变动。(信息来自OpenAI Developers)

你可以直接加一句：

改完之后，请执行相关的测试、lint 和类型检查。
如果测试未通过，先自行查找原因并修复。
最后告诉我：

1. 1. 运行了哪些命令；

2. 2. 是否通过；

3. 3. 还有什么风险需要人工检查。

这句话的重要性不言而喻。

因为你想要的不是一段“看起来能运行”的代码，

而是一个“经过验证的交付成果”。

7. 为项目写 AGENTS.md，记录下你的偏好

如果你每次都在提醒 Codex：

不要乱改目录结构。不要引入新库。接口文件别动。CSS 用 Tailwind。组件命名按项目规范来。

那么你就该考虑写一个 AGENTS.md 了。

官方表示 AGENTS.md 是为 agent 设计的开放格式 README，

会自动加载到上下文中。

它非常适合记录项目结构、运行方式、测试命令、工程规范、禁止事项以及完成标准等。(信息来自OpenAI Developers)

你可以这样简单地写：

# AGENTS.md## Project rules- Do not introduce new dependencies unless explicitly approved.- Keep existing file structure.- Use TypeScript strict mode.- Follow existing component naming conventions.## Commands- Install: pnpm install- Dev: pnpm dev- Test: pnpm test- Lint: pnpm lint## Done means- Code compiles.- Relevant tests pass.- No unrelated files changed.- Summary includes changed files and risk notes.

这份文档的价值在于：

你不需要每次都重新教 Codex。

8. 用多层 AGENTS.md 管理不同目录

还有一个不少人忽略的细节：AGENTS.md 其实可以放在不同的层级。

官方说明提到，可以有一个全局的 ~/.codex/AGENTS.md，

还可以有针对 repo 级别和子目录级别的 AGENTS.md。

越靠近当前目录的说明优先级越高。(信息来自OpenAI Developers)

这对于复杂项目来说非常合适。

例如：

~/.codex/AGENTS.md个人通用偏好：回答中文、改动前先解释、不要擅自装依赖project/AGENTS.md项目级规则：技术栈、启动命令、测试命令、PR 标准project/apps/admin/AGENTS.md后台系统规则：Ant Design、权限逻辑不能动project/apps/mobile/AGENTS.md移动端规则：React Native、注意 iOS/Android 差异

这样，Codex 在不同目录时，会自动获取不同的工作规范。

相比每次手动解释，这种方式高效多了。

9. 配置好 config.toml

很多时候 Codex 出问题，并不是模型的错，而是环境配置不当。

官方建议把个人的默认配置放在 ~/.codex/config.toml，项目级的配置放在 .codex/config.toml。

在配置中，你可以管理模型、推理强度、沙盒、审批策略、MCP 等。(信息来自OpenAI Developers)

新手小建议：权限不要一开始就设得太大。

可以先保持默认的审批和沙盒策略，只给它处理当前项目的权限。等你确认这个项目的可靠性后，再逐步放宽权限。

更实用的方法是为不同场景设置不同的配置文件：

# ==========================================# Profile：安全模式（用于新项目/陌生仓库）# ==========================================[profiles.safe]approval_policy = "on-request"# approval_policy = 执行命令前要不要经过你批准# "on-request" = 每次执行命令前都弹窗问你"能跑吗？"（最严格，适合不确定安全性的场景）# ==========================================# Profile：信任模式（用于熟悉、已验证的项目）# ==========================================[profiles.trusted]approval_policy = "on-request"# 官方推荐即使是信任项目也保持 "on-request"（手动批准）# 如果你确定要全自动（比如跑 CI 脚本、定时任务），可以改成：# "never" = 从不请求批准，Codex 直接执行（效率最高，风险最大，仅限非交互式自动化）

核心原则是：
让 Codex 高效，但不要让它失去控制。

10. 团队使用 Codex，不要只关注“生成了多少代码”，更要看“节省了多少流程”

在这次与业务和企业相关的更新中，插件共享和分析功能都十分引人注意。

插件共享让团队可以通过市场资源分发可复用的插件包，其中可以包含技能、应用集成和 MCP 服务器。(信息来自OpenAI Developers)

分析功能的升级让你可以看到活跃用户、积分、token、运行次数、用户排行榜、代码生成行数、插件使用情况等指标。(9to5Mac)

但企业真正应该关注的，不是“Codex 写了多少行代码”。

更重要的应该是：

哪些重复任务被自动化了？哪些测试、排查、修复流程变短了？哪些内部工具可以通过插件共享给全团队？哪些人已经把 Codex 融入真实工作流？哪些仓库最适合先做 agent 化改造？

换句话说，Codex 对团队的价值，并不仅仅是多了一个写代码的人。

而是让团队里那些本来需要人力进行复制、搜索、排查和跑命令的流程，

开始被系统化的方式压缩。

总结

这次 Codex 更新，最值得关注的并不是某一个特定功能。

Appshots 解决了上下文的问题。

Goal mode 解决了长任务的问题。

浏览器标注则是解决了前端反馈的问题。

插件共享和分析功能则解决了团队规模化的问题。

所以，Codex 的正确用法已经不再是：帮我写一段代码。

而是要给出一个与成熟开发代理相匹配的任务布置。

能够这样使用的人，才算真正进入了 Codex 的新阶段。