给大家分享六个我在 Codex 中会高频用到的提示词，感觉也是一个使用 AI 的习惯。 最近硅谷又开始流行一个概念，叫 Loop Engineering。 简单来说，就是让 Agent 在一个任务中持续执行、检查、修正，直到达到目标。 我觉得它和 Prompt Engineering 依然有很多弯弯绕绕的关系。到今天为止，无论是用 ChatGPT 还是 Codex 这样的 Agent，提示词依然很重要。 模型能力再强，我们怎么和它沟通，会直接影响最终的产出。 不过，今天的提示词已经不需要写成八股文了。不需要每次都套一套复杂的格式，提示词说到底就是我们和 AI 交互的思路。 跟和同事沟通是一个道理，沟通方法不同，达成的结果往往也不一样。 下面是我最近使用 Codex 时，最常用的六个提示词思路。注意，重点是思路。具体怎么问，可以根据自己的任务随时调整。 一、从何而来，何以至此 遇到一个复杂概念，比如一篇论文、一个新的技术框架，想快速搞懂它，效率最低的方法往往是从第一行开始，一行一行往下看。 看了半天，记住了很多术语，却不知道作者为什么要研究这个问题，它和以前的方法有什么关系，也不知道这篇论文真正重要的地方在哪里。 这时候，我通常会先问 Codex： 详细总结这个论文解决了什么问题，思路是什么？有什么非共识的判断。 因为我觉得理解一个概念，第一步是搞清楚它从何而来，何以至此。 没必要急着深入到细节，而是应该往回倒，想一想为什么会是这样，到底要解决什么问题，又是怎么一步一步走到现在的。 很多知识单独拿出来看，会显得非常抽象。一旦知道它是为了解决什么问题、之前别人是怎么做的，就会立马明白其中的逻辑。 比如一篇论文提出了一套新的架构，先不用急着看每一个公式。 搞清楚旧架构遇到了什么问题，为什么继续增加参数、增加数据或者调整训练方法已经解决不了。脉络理出来之后，后面的细节就容易理解了。 二、让 AI 指出我的思维盲区 我在和 Codex 协作时，如果自己对方向比较确定，通常会不断地告诉它需求和想法。 Codex 一般都会顺着这个方向执行，完成得也还不错。 这种场景下，Codex 扮演的还是执行者。我告诉它要做什么，它就会尽可能做好。 只要当前方案能成立，它通常不会跳出来挑战我们的判断。 但其实协作过程中，Codex 会阅读相关材料，看过完整代码，知道我们为什么这样改，也知道前面做过哪些取舍。 很多时候，它掌握的上下文甚至比其他参与者还完整。 所以做完一个相对完整的任务之后，我会让 Codex 暂时跳出执行者的角色，重新审视整个过程，然后问它： 从刚才这个任务来看，我的思维盲区是什么？ 这时候 Codex 会基于上下文以及它对于这件事情的理解，列出来可能存在的思维盲区。 多数情况下，Codex 反馈的这些新的视角对我来说都有很多启发。大家可以试试。 三、让 AI 反思它最没把握的地方 还有的时候，我们会给 Codex 一个相对复杂的需求，让它自己搞定。Codex 可能会花很长时间执行。 这个过程中，很多决定是 Codex 自己做的，诸如用什么方案，怎么实现。 最后做完之后， Codex 基本上也会用比较确定的语气说它搞定了，然后列出来自己做了什么。 但其实，AI 也有自己的盲点。所以，在进入细节看具体的实现之前，我会先问： 重新反思一下，刚才执行过程中最没把握的地方有哪些？ 再或者，还可以继续要求说得更具体：哪些结论经过了实际验证？有哪些问题暂时无法确认？ 这样一问，Codex 通常会主动把风险暴露出来。 比如某个接口没有真实环境所以没跑完整测试，某段代码看起来已经废弃但无法百分之百确认，某个功能只测了正常流程没有覆盖异常输入，或者为了兼容旧逻辑选了一个保守方案但不确定是不是我们真正想要的。 这些信息非常重要。 四、让 AI 用大白话讲清楚它的逻辑 AI 做长程任务的时候，速度肯定是人的几十倍。我们不可能每次都逐行检查代码。即使看了，也未必能快速理解它为什么这么改。 这时候，我通常会直接问： 言简意赅地讲一下，刚才这个任务的解决逻辑是什么。不要逐个文件介绍，用通俗易懂的话讲清楚就行。 也可以问得更具体： 这个问题原来为什么会出现？做了哪几项关键修改？修改之后这套逻辑是怎么运行的？后面最容易出问题的地方在哪里？ 这个提示词看起来简单，但我觉得特别重要。当 AI 可以独立完成越来越多工作之后，人很容易只关注最后的结果。只要功能正确，就皆大欢喜。 但时间长了以后，我们会逐渐失去对项目的理解。这种理解层面的让渡非常可怕，因为后面一旦 AI 出问题，搞不定了，需要我们接手，那我们面对的可能完全是一个黑盒。 所以我会要求 Codex 把关键逻辑讲到我能听懂。 比如它可以这样解释：以前每次切换页面，系统都会重新请求一次数据，所以页面会闪烁。 我现在把数据放进了共享缓存里，第一次打开时请求，之后优先读取缓存，缓存过期之后再重新更新。 这样的解释没有太多代码细节，但我们很容易理解。理解之后才能继续判断这个方案是否符合预期，缓存多久合适，会不会出现数据更新不及时的问题，下一步应该怎么继续。 代码可以交给 AI 写，很多细节也可以让 AI 处理。但关键逻辑，最好还是让它讲到我们真正理解。 五、让 AI 做结构化的信息呈现 有些事情，AI 用文字讲了很多，我们还是很难理解。特别是系统架构、数据流、业务流程、模块依赖这些内容。它写了三四段，看的人云里雾里。 这时候我一般不会继续让它再换一种文字表达，而是直接说： 能不能给我做一张图，把这套逻辑表达清楚？具体用什么图，根据场景来定。 流程图适合表达任务的执行顺序，架构图适合说明前后端和数据库之间的关系，脑图适合整理功能结构，时序图适合展示一次完整请求的过程，对比图适合说明修改前后的区别。 Codex 现在已经可以调用图像生成能力，也可以生成 Mermaid、Excalidraw、HTML 图表等不同形式的图。 六、表达完需求后，先让 AI 确认理解 给 Codex 说完需求，它会马上开始执行。但注意，我们表达需求的时候，本来就很容易遗漏信息。 特别是现在用语音输入法，表达可能东一句西一句。Codex 只能根据有限的信息去猜。一旦最开始理解错了，后面执行得越认真，浪费的时间越多。 所以我表达完需求之后，经常会紧接着说： 先看看是否理解了我的需求，不要开始执行。有不理解的地方直接追问我，追问清楚之后再继续。 或者有时候也会让它把理解复述一遍： 先用自己的话复述一下我的目标、限制条件和最终要交付的结果。 这一小步，真的可以提前消除很多误会。