Codex 补充讲义：给 Codex 一个完成标准
入门工作坊之后，用这个简单方法来描述任务。
| 适合对象 | 刚开始使用 Codex 的业务、运营、客服、数据和产品同事 |
|---|---|
| 核心想法 | 好的 Codex 请求会说清楚：需要什么结果、什么样才算好、应该去哪里查、什么时候必须找人批准。 |
1. 一个简单公式
普通 Codex 任务可以这样写。更大的长期任务也可以用同样写法。
我需要 [完成后的结果]。 请使用/检查 [相关来源或工具]。 结果合格的标准是 [成功标准]。 请注意 [风险或常见错误]。 在 [需要审批的动作] 之前先问我。
完成标准很重要，因为 Codex 需要知道什么叫“做完”。如果没有完成标准，它可能只给一个部分解释，而不是交付完整结果。
2. 问问题 vs 分配工作
| 问问题 | 分配工作 |
|---|---|
你能看一下为什么销量下降了吗？ 这可能会得到有用解释，但后续工作仍然要你自己负责。 |
找出 Livatro 7001 本周销量下降最可能的原因。 检查现有销售数据、库存线索、listing 问题和客户投诉。 把发现整理到 Excel，并准备一段发给团队的飞书消息。 清楚区分哪些是已经验证的，哪些只是推测。 这给了 Codex 一个要完成的工作，也给了最终结果的标准。 |
3. 告诉 Codex 什么叫“做完”
“做完”要具体到 Codex 能在交付前自己检查。
| 场景 | 好的完成标准 |
|---|---|
| 销量或表现分析 | Excel 已更新，主要原因已解释，发给团队的消息已准备好等待 review。 |
| 客服回复 | 回复已写在飞书邮箱草稿里，但在我批准前不要发送。 |
| CyberFlo 流程检查 | 已经实际走过流程，列出卡点，并给出产品团队能直接理解和处理的改进建议。 |
| 工具或 dashboard 请求 | 工具能快速回答真实业务问题，包括领导最可能挑战的薄弱指标。 |
4. 给背景，不要微管理
有用的背景会解释业务情况和任务原因。微管理则是在 Codex 可能知道更好路径时，强行规定每一步。
| 不太有用 | 更有用 |
|---|---|
先打开这个文件，再做这个图，然后写总结。 |
最大的风险是我们给 Carson 一个很模糊的回答。 他通常会挑战表现最差的指标，即使整体表现不错。 请帮我判断这些弱点到底是真问题还是数据噪音，然后准备回应。 |
5. 依赖结果前，先要求证据
Codex 有时语气很确定，但其实漏了某个来源或做了假设。使用结果前，先让它说明自己实际检查了什么。
在我依赖这个结果之前，请告诉我： 你验证了什么？ 你假设了什么？ 你没有检查什么？ 我应该小心什么？
如果缺了重要内容，不要先自己修。告诉 Codex 缺什么，然后让它继续。
6. 练习
把下面这个弱请求，改写成 Codex 式任务。
帮我做一个 sales dashboard。
更好的版本应该包括：
- 你真正需要的业务结果。
- 谁会使用这个结果。
- 这项工作应该回答哪些问题。
- 什么会让结果可信。
- Codex 什么时候需要找你批准。
可复用提示词
分配结果
我需要 [完成后的结果]。 请使用/检查 [来源]。 结果合格的标准是 [成功标准]。 在 [需要审批的动作] 之前先问我。
确认完成标准
开始前，请先复述什么叫“做完”。 告诉我你会验证什么、可能需要假设什么，以及什么时候会找我帮忙。
检查证据
在我依赖这个结果之前，请告诉我： 你验证了什么？ 你假设了什么？ 你没有检查什么？ 我应该小心什么？
推动继续
这个还没有完成。 不要让我手动做完。 告诉我缺什么，然后在安全范围内继续推进。