经常有人来找我，问：“Codex 能做这个吗？”
然后他们会花上两三分钟，详细解释“这个”到底是什么：他们想解决的问题、应用程序应该做什么、一个好的结果是什么样的。有时他们还会分享自己已经尝试过的方法，哪些有效，哪些无效。
而我在想：你其实应该直接把这些话对 Codex 说。
你刚才那整段解释，本身就是提示词了。
提示工程已死。但又没死。
如果说提示工程意味着在寻求帮助之前先要学习一门秘密语言，那我认为它基本上已经死了。尤其是对于推理模型来说，通常没有什么神奇的咒语能解锁正确答案。我不认为你应该对着空白屏幕苦思冥想一小时，试图写出完美的提示词。
但说它没死，是因为清晰表达仍然很重要。模糊不清会让 Codex 的工作变得更困难，就像对任何人一样。如果我打乱这篇文章的段落顺序，或者换成一种你不懂的语言，读起来就会更费劲。甚至连时态都很重要：“我试过这个”和“我希望你试试这个”完全是两码事。
你到底想要什么？哪些背景信息是重要的？Codex 需要知道哪些限制条件？一个好的结果看起来是什么样的？
像跟同事说话一样跟 Codex 交流。
我喜欢从结果开始：我的目标是什么？这也是使用 Agent 时更广泛的转变。与其编写每一步的脚本并请求每个中间输出，我可以解释我想要实现的目标，设定边界，然后让 Codex 帮忙找出路径。
说出那个混乱的版本
大多数想法都不是以清晰的规格说明形式出现的。它们听起来更像是：
“好吧，我有所有这些文件。格式有点不一样。我周五前需要一份报告。我觉得大部分数据都在，但这次导出的数据有点奇怪……”
没关系。直接说出来就行。
当你漫无边际地讲述时，你往往会给 Codex 提供更多信号。你会提到那些本会在精心打磨的提示词中删掉的细节。你会在中途改变主意。你会说：“等等，不，我不要那个。”
改变主意会揭示你不想要什么。一次跑题可能会揭示一个隐藏的限制条件。边想边说有助于你和 Codex 理解任务。
使用语音听写功能，你按下麦克风，口述需求，检查转录文本，然后发送。
如果你的设置支持，语音模式更进一步。你可以追问、打断、改变方向，或者开启一个新的思路。你也可以用它来协调工作：开始另一个任务、检查现有任务、询问什么被卡住了，或者引导已经在运行的工作。
说实话，对着电脑说话还是有点奇怪。在办公室里，我手里拿着一个 DJI 麦克风。带麦克风的耳机也行。
但这总比让一个好主意卡在脑子里，因为你还没找到完美的写下来方式要好。
问那个荒谬的问题
有一个大家熟悉的 meme 版本是这样的：
“Codex，给我做一个十亿美元的 B2B SaaS。别搞错了。一次性搞定。”
你不可能一次性搞定一家十亿美元的公司。但这样的对话可能会发现一些真实的东西：一个你理解的问题、一个遇到这个问题的人，以及一个值得迈出的第一步。这是经典的问题解决方法：把一个复杂问题分解成更小、可实现的步骤。
价值在于对话本身。它可以把你从一个荒谬的问题，带到你今天就能实际交付的东西。
一些实用的开始方式
如果想法还很模糊，让 Codex 来采访你：
“我还在琢磨这件事。一次问我一个问题。追问任何模糊的地方，然后帮我把它们变成具体的东西。”
或者非常直接：
- 我的盲点是什么？
- 什么会导致这个失败？
- 我在什么事情上想得太多了？
- 最小可用版本是什么？
- 在你开始之前，你需要知道什么？
当你需要更多结构时，Codex 的计划模式很有用。它可以提出澄清性问题、提供选项，并在实施之前探讨一个方法。
但我认为并非每个想法都需要从那里开始。有时，开放式的对话会更流畅。我们不会把和同事的每一次对话都分成计划和执行。先聊起来。让问题的轮廓浮现出来。当工作需要时，再转向计划。
向 Codex 询问 Codex 本身
“和 Codex 对话”还有第二层含义：向它询问关于它自身的问题。
问它能看到什么。问它哪种模式更合适。问它有哪些工具可用。问它打算如何验证自己的工作。
如果 OpenAI Docs 技能可用，让 Codex 查阅文档。你也可以查看公开的 Codex 仓库，或者克隆它，然后让 Codex 解释它是如何工作的。
如果 Codex 没达到预期，问为什么
“你做了这个，但我其实想要那个。我们哪里出错了？”
也许你的请求有歧义。也许某个 AGENTS.md 文件或技能把工作带向了不同的方向。也许某个插件、权限或工具不可用。也许 Codex 做出了错误的假设。
问它理解了哪些内容，遵循了哪些指令，什么失败了，以及你本可以怎样表达得更清楚。Codex 通常可以利用仍然可用的上下文来帮助审查协作本身。
在可用的情况下，你可以在 Codex 运行时打开一个侧边聊天 /side，而不会中断主聊天。询问哪些已完成、哪些未完成、哪些被卡住，以及你能如何提供帮助。你基本上就是它在站会上的经理。
如果你希望用通俗易懂的语言解释某些内容，可以在对话记录中选择文本，然后选择“在侧边聊天中提问”。
把想法从脑子里拿出来
在一次公路旅行中，我开始跟 Codex 聊一个演示文稿。这后来成了这次演讲和这篇文章的框架。我口述了粗略的想法，改变了几次主意，然后继续下去。
通常，最大的障碍不是模型本身。是我们自己。我们认为想法还不成熟。我们不知道正确的提示词。我们担心自己没有解释清楚。
界面会变得更好。如果你对跟 Codex 对话应该是什么感觉有想法，我真的很想听听。
直接问 Codex 吧。
