其他版本：English workbook

Codex 入门工作坊讲义

面向业务和运营团队的 30 分钟课程。

核心信息 ChatGPT 适合帮助你思考工作。Codex 适合在你需要完成工作时使用。
主要转变 不要先写一堆步骤，要求 Codex 按你想象的方式做。先说明业务结果、背景、风险和审批边界。
练习重点 结果导向请求、权限和工具、反馈、不清楚的问题、阻塞处理，以及 goal。

概念清单

完成工作坊后，你应该理解这些概念，并能使用本讲义里的提示词模板。

1. 建议 vs 完成工作

Codex 的不同之处在于：你可以让它把工作完成，而不只是让它解释情况。

ChatGPT 式请求 Codex 式请求 
这里是 Livatro 7001 的销售数据。为什么销量下降了？

它可能会解释你给它的数据，但你还要自己判断还要查什么、更新表格、准备团队消息。

 
请完成 Livatro 7001 销量下降分析。
判断需要检查哪些数据，能查的先查完，
把结果放进表格，并准备好发给团队的消息。
只有遇到真正阻塞，或需要我批准时，再来问我。

这给了 Codex 一个要交付的结果，也说明了什么时候需要回来找你。

2. 为什么 Codex 能完成工作

差别不只是 Codex 有工具。ChatGPT 也可以读邮件、浏览网页、连接数据。真正重要的变化是：Codex 可以在真实工作的地方采取行动。

插件和内部工具 电脑操作能力
  • 飞书邮箱：准备回复、查看邮件上下文、批准后发送。
  • Excel：制作、清理和更新分析表格。
  • Snowflake/内部数据工具：检查问题背后的真实业务数据。
  • Figma：制作流程图和工作流示意图。
  • 打开 CyberFlo，实际走一遍流程。
  • 在没有直接插件时，读取飞书或微信聊天内容。
  • 使用没有插件的供应商网站、内部网页工具或其他网站。
  • 打开 PDF、截图、表格和本地下载文件。
  • 可以点击、输入、查看页面内容，并在需要批准的动作前停下。
电脑操作示例： 下面的视频展示了当工作存在于某个应用或网页中、而不是专门插件中时，Codex 如何直接使用电脑完成检查。

视频文件：computeruse-3x.mp4

插件示例： 下面的视频展示了 Codex 如何通过插件完成真实工作。如果打印讲义，可以使用下面列出的本地视频文件。

视频文件：codex-workshop-video.mp4

3. 提出业务结果

最重要的工作习惯是：先说明真实业务结果，再决定需要什么工具。

差 好一点 最好 
设计一个 dashboard：
顶部放 X 筛选器，
右边放 Y 图表，
底部放 Z 总结模块。

这在 Codex 理解问题之前，就过度规定了页面布局。

 
我需要更快回答 X、Y、Z 这类问题。
现在找正确数字、判断问题是否真实、准备回应都太慢。

请设计一个最简单但有用的工具或流程来解决这个问题。

这说明了痛点，也给 Codex 空间去选择解决方案。

 
我需要一个工具，可能是 dashboard，帮助我在电商表现复盘时，快速且准确地回答 X、Y、Z 这类问题。

主要提问的人通常是 Carson。他很喜欢盯着表现最差的指标挑战我们，即使整体表现其实不错。

这个工具应该帮我快速找到弱点，判断它到底是真问题还是数据噪音，并准备好带证据的清晰回应。

如果更简单的引导式分析、Excel 流程或固定报告能更快得到答案，就不要做很重的 dashboard。

这说明了真实工作、使用者、压力来源，以及什么才算成功。
常见误区： 有人觉得必须先写一个完美提示词，所以干脆不开始。也有人写很长很细的步骤，Codex 照做后卡住，就觉得它很死板。很多时候，它只是被迫按你的方式做事，所以才失败。

更好的习惯是给 Codex 目标、背景、风险和审批边界，然后让它自己决定路径。

4. 先做小版本，再给反馈

背包例子说明了一个简单道理：持续反馈通常比一次性规划全部更可靠。

用背包例子对比瀑布式开发和敏捷开发。
瀑布式做法会先规划并一次性构建全部内容，反馈来得太晚。敏捷做法先做小版本，再根据反馈持续改进。
一次性全部规划 Codex 工作方式
  1. 规划所有功能。
  2. 一次性全部开发。
  3. 太晚才发现问题。
  1. 先要一个有用结果。
  2. 检查结果和背后的判断。
  3. 让 Codex 修改完善。

好的反馈要同时批评结果和背后的判断。不要只把“正确答案”直接丢给 Codex，却不解释原因。人学习时需要知道为什么错，以及如何靠近正确答案。Codex 也是一样。

弱反馈 更好的反馈 
你应该做 X。
 
这个结果不够好，因为你选择了 Y。
如果我们这样做，会造成这个问题。
请朝着 [期望结果] 修改。
如果你认为你的选择仍然正确，请解释原因。
好管理者的特质： 不要自己替 Codex 收拾残局。指出问题，并让 Codex 自己修好。

5. 如果你不确定，就让 Codex 反问

有时候你知道痛点，但不知道解决方案。不要假装自己已经很清楚。

我有一个问题/痛点，但我不确定需要什么解决方案。
[描述问题或痛点]
最多问我 5 个最重要的问题。
只问会改变最终结果的问题。
然后建议我们应该怎么做。

6. 不要担心设置

设置指 Codex 需要的提示词、插件、内部工具、技能和权限。业务用户不需要直接管理这些。

你只需要关注结果。如果 Codex 缺什么，它通常会告诉你。如果别人的 Codex 能做某件事，而你的不能，问 CyberFlo 团队即可。通常只是加一个插件、接入一个内部工具、打开电脑操作能力，或补一段 instruction。

7. 当 Codex 做得不够好

不要太早把工作拿回来自己做。先找出阻塞点，然后推动它继续。

这个结果还不完整。
不要让我手动完成。
告诉我缺的是什么：目标、信息、权限、批准，还是检查。
然后在安全范围内继续推进。

会用 Codex 很像会管理人：给清楚反馈，移除阻塞，再把工作推回给 Codex。

8. 常见摩擦和应对方式

这些是早期使用中很正常的问题。目标不是完全避免摩擦，而是知道如何回应，让 Codex 能继续朝结果推进。

问题 常见表现 应对方式
太慢 Codex 花的时间比预期长，尤其是在使用电脑操作或检查多个来源时。 避免把任务切得太小，导致你每一步都要插手。这种方式最需要“看着它做”。更好的做法是交给它一个比较完整的交付物，让它先做完，再统一 review。多个独立任务可以开多个 Codex 线程同时跑。
取数失败 查询失败、数据源缺失、权限不清楚，或者来回修正的时间很长。 问它具体哪里失败、尝试了哪个来源、继续推进还缺什么最小条件。同时把这些错误反馈给数据团队。现在处于早期阶段，错误反馈会帮助 agent、数据权限和数据定义一起改进。
结果不一致 同类请求每次产出的格式、检查步骤或判断质量不稳定。 一旦你发现一个好的流程，就让 Codex 把它做成 skill。如果这个流程需要反复执行，再进一步把它自动化，按固定频率运行。
工具使用不稳定 插件失败、页面变化、登录过期，或者 Codex 选择了不适合的操作路径。 告诉 Codex 以后应该记住什么路径。比如：“以后读取飞书消息时，请始终使用电脑操作直接访问飞书 app。”
看起来很自信，但漏查了东西 结果很完整、语气很确定，但漏掉了某个来源、假设、边界情况或必要检查。 在依赖结果前先要求证据：“你验证了什么、假设了什么、还有什么没有检查？” 然后让 Codex 补齐缺口，或者明确标出剩余不确定性。

9. Bonus：/goal

普通 Codex 已经能完成很多基础工作。需要长期跟进的任务，可以使用 /goal。

基础任务

阅读这封飞书邮件，写好回复，发送前先让我批准，批准后再发送。
完成这个基于 Snowflake 数据的分析，放进 Excel，并准备发给 Y 的飞书消息。
打开这个 CyberFlo 页面，实际走一遍流程，并准备改进建议。

电商示例

/goal 解决这个客户的换货问题。
需要时使用飞书邮箱和 CyberFlo。
在飞书邮箱里写好回复草稿。
发送前先问我。
我批准后再发送。
如果客户回复，继续跟进，直到问题解决或需要我做决定。

常用提示词

要求结果

我需要完成 [结果]。
现在的问题是 [痛点]。
请判断最好的帮助方式。
只有缺少重要信息时再问我。

给更好的反馈

这个结果不够好，因为 [判断或假设]。
如果这样做，会有 [问题]。
请朝着 [期望结果] 修改。
如果你认为你的选择是对的，请解释原因。

让 Codex 修好

这个结果是错的，或者很乱。
不要让我手动清理。
如果需要，请解释哪里出了问题，然后修好。

让 Codex 反问

我有一个问题/痛点，但我不确定需要什么解决方案。
[描述问题或痛点]
最多问我 5 个最重要的问题。
只问会改变最终结果的问题。
然后建议我们应该怎么做。

课后补充讲义

更轻量的课后复习，请阅读 如何给 Codex 一个完成标准。它总结了如何把普通 Codex 任务描述成可交付结果。