Codex 入门工作坊讲义

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

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

概念清单

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

Codex 最适合用来交付结果，而不只是回答问题。
插件、内部工具和电脑操作能力，让 Codex 能在真实工作的工具里采取行动。
好的请求会说明业务结果、使用背景、风险和审批边界。
不需要完美提示词。先要一个有用结果，再通过反馈改进。
好的反馈会说明哪里错了、为什么重要，以及希望 Codex 朝什么结果修改。
当解决方案不清楚时，可以让 Codex 先问少量关键问题。
当 Codex 做得不够好时，不要太早手动接手。先找出缺什么，再推动它继续。
需要长期跟进的任务，可以使用 /goal。

1. 建议 vs 完成工作

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

ChatGPT 式请求	Codex 式请求
这里是 Livatro 7001 的销售数据。为什么销量下降了？它可能会解释你给它的数据，但你还要自己判断还要查什么、更新表格、准备团队消息。	请完成 Livatro 7001 销量下降分析。判断需要检查哪些数据，能查的先查完，把结果放进表格，并准备好发给团队的消息。只有遇到真正阻塞，或需要我批准时，再来问我。这给了 Codex 一个要交付的结果，也说明了什么时候需要回来找你。

ChatGPT 式请求

Codex 式请求

这里是 Livatro 7001 的销售数据。为什么销量下降了？

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

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

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

2. 为什么 Codex 能完成工作

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

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

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

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

电脑操作示例： 下面的视频展示了当工作存在于某个应用或网页中、而不是专门插件中时，Codex 如何直接使用电脑完成检查。

视频文件：computeruse-2x.mp4

3. 提出业务结果

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

差	好一点	最好
做一个 dashboard，可以回答 X、Y、Z 问题，并且长得像另一个 dashboard。这会过度规定解决方案。	做一个 dashboard，可以回答 X、Y、Z 问题。这说明了可能的工具，但还是先假设 dashboard 就是正确答案。	我需要一个工具，可能是 dashboard，帮助我快速且准确地回答 X、Y、Z 这类问题。主要提问的人通常是 Carson。他很喜欢盯着表现最差的指标挑战我们，即使整体表现其实不错。这个工具应该帮我快速找到弱点，判断它到底是不是真问题，并准备好清晰回应他的挑战。这说明了真实工作、使用者、压力来源，以及什么才算成功。

差

好一点

最好

做一个 dashboard，可以回答 X、Y、Z 问题，
并且长得像另一个 dashboard。

这会过度规定解决方案。

做一个 dashboard，可以回答 X、Y、Z 问题。

这说明了可能的工具，但还是先假设 dashboard 就是正确答案。

我需要一个工具，可能是 dashboard，帮助我快速且准确地回答 X、Y、Z 这类问题。

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

这个工具应该帮我快速找到弱点，判断它到底是不是真问题，并准备好清晰回应他的挑战。

这说明了真实工作、使用者、压力来源，以及什么才算成功。

常见误区： 有人觉得必须先写一个完美提示词，所以干脆不开始。也有人写很长很细的步骤，Codex 照做后卡住，就觉得它很死板。很多时候，它只是被迫按你的方式做事，所以才失败。

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

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

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

用背包例子对比瀑布式开发和敏捷开发。 — 瀑布式做法会先规划并一次性构建全部内容，反馈来得太晚。敏捷做法先做小版本，再根据反馈持续改进。

一次性全部规划	Codex 工作方式
规划所有功能。一次性全部开发。太晚才发现问题。	先要一个有用结果。检查结果和背后的判断。让 Codex 修改完善。

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

弱反馈	更好的反馈
你应该做 X。	这个结果不够好，因为你选择了 Y。如果我们这样做，会造成这个问题。请朝着 [期望结果] 修改。如果你认为你的选择仍然正确，请解释原因。

弱反馈

更好的反馈

你应该做 X。

这个结果不够好，因为你选择了 Y。
如果我们这样做，会造成这个问题。
请朝着 [期望结果] 修改。
如果你认为你的选择仍然正确，请解释原因。

好管理者的特质： 不要自己替 Codex 收拾残局。指出问题，并让 Codex 自己修好。

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

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

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

6. 不要担心设置

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

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

7. 当 Codex 做得不够好

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

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

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

8. Bonus：/goal

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

基础任务

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

电商示例

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

常用提示词

要求结果

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

给更好的反馈

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

让 Codex 修好

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

让 Codex 反问

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