1. 先说清楚Codex 提问为什么要急救我见过太多人把 Codex 当成一个有问必答的插件结果用了两星期就放弃了。实际用下来你会发现Codex 最大的问题不是它能力不够而是它太容易误解你的意思。你问得模糊它就给你模糊的答案你问得笼统它就给你一段正确的废话。真正让它发挥价值的关键其实是你提问的方式。这也是我整理这套提问急救卡的原因。所谓急救指的是你在对话陷入僵局、Codex 开始胡言乱语、或者你完全不知道该怎么描述需求的时候直接拿模板去套先把对话拉回正轨。它不是万能药但能在绝大多数情况下救你一把。这套卡片适用的场景很广你在改一个开源项目的代码不知道怎么让 Codex 精准定位问题你在写一个复杂功能Codex 给出了一堆代码但不知道哪段能用你想要 Codex 解释一段代码但它的回答总是停留在表面你想让 Codex 帮你重构、测试、写文档但不知道该用什么语气、什么结构去提问我后面会把这 7 个模板一个个拆开讲每个都会配上原理说明、直接可以复制用的示例、还有我实测中踩过的坑。最后再分享一个我自己总结的 5 步提问检查清单和一个用组合模板实战改开源项目的完整过程。2. 7 个基础模板逐个拆解这一节是整篇文章的核心。我把常用模板分成三类理解类、生成类、修复类。每一类解决不同的问题用法和侧重点也完全不同。2.1 理解类模板让 Codex 真正读懂你的代码模板一先解释再行动这个模板的核心逻辑是让 Codex 把它的理解先说出来你再决定要不要让它动手。先解释一下这段代码的作用特别是 xxx 函数/模块/文件。解释完以后先不要修改任何代码等我确认后再继续。为什么要这么写因为 Codex 的上下文窗口有限它对你项目的理解依赖于对话历史。如果你一上来就让它帮我改 bug它可能在错误的上下文里做了错误的修改等你发现问题时已经晚了。我实测中最有效的用法是三步走贴代码或指定文件路径让 Codex 先解释整体逻辑针对你关心的部分追问细节比如这个函数的时间复杂度是多少这个状态管理为什么要用这个方案确认理解无误后再下达修改指令模板二带着约束条件去理解有时候 Codex 对代码的解释会忽略掉约束条件。比如你有一段代码依赖特定版本的库或者有性能瓶颈Codex 却只字不提。这时候你需要主动把约束条件写进问题里。在理解这段代码时请特别注意以下约束条件xxx。基于这些条件重新解释这段代码是否存在潜在问题。这个模板在评审他人代码时特别好用。我曾经用它帮某开发者审查一个异步任务处理模块Codex 原本的解释只说代码功能正常加入了必须在低内存环境下运行的约束后它立刻发现了一个未被释放的连接池问题。2.2 生成类模板让 Codex 从零写出你要的东西模板三角色任务格式这是最基础也最常用的生成模板。很多人的提问是帮我写一个登录功能这太模糊了。Codex 不知道你要用哪种框架、哪种语言、需不需要验证码、要不要记住登录状态……你什么都没说它只能给你一个通用答案。正确的打开方式是你是一个资深的前端开发工程师。请用 React TypeScript 实现一个登录表单组件要求 1. 支持邮箱和密码登录 2. 密码错误时显示提示信息 3. 登录成功后跳转到首页 4. 使用 antd 组件库 请直接给出完整代码并在代码后面附上简要的使用说明。这个模板的灵魂在于角色任务格式三段式。角色决定了 Codex 回答的专业深度任务决定了它做什么格式决定了它怎么输出。三段缺一不可。模板四给范例再生成Codex 对抽象描述的理解能力有限但对具体范例的模仿能力很强。当你不知道该怎么精确描述需求时直接给它一个参考范例。请参考下面的实现方式帮我生成类似的 xxx 功能。范例 [贴一段参考代码或伪代码] 要求 1. 保持同样的代码风格 2. 功能上增加 xxx 3. 返回给用户的错误提示要友好这个模板在生成 UI 组件、配置文件、测试用例时效果极好。我自己写测试用例时深有体会直接说帮我写单元测试Codex 给的测试往往流于形式但只要给它一个覆盖了边界情况的测试范例它就能照着写出高质量的一整套测试。2.3 修复类模板让 Codex 精准定位问题模板五报错信息期望行为实际行为这是排查 bug 时的王牌模板。很多人只会把报错信息丢给 Codex然后问这是怎么回事——Codex 确实能解释报错但它大概率不知道你期望的行为是什么自然也没办法精准定位。我遇到了一个报错信息如下 [报错信息] 我期望的行为是xxx 实际发生的行为是xxx 请帮我定位可能的出错位置并给出修复方案。注意修复方案请分步骤给出并解释每一步的意图。注意最后那句解释每一步的意图。这能逼着 Codex 把思考过程摊开而不是只丢给你一段改好的代码。修复完以后你才能真正理解问题出在哪下次再遇到类似问题也能举一反三。模板六分而治之的排查当代码复杂、报错信息含糊不清、或者 Codex 一次性改动太多时你需要把问题拆开。这个问题可能涉及多个模块。请先不要直接修改代码按照下面的步骤来排查 第一步检查数据流确认 xxx 模块的输入输出是否正常 第二步检查状态管理确认 xxx 变量的赋值顺序是否正确 第三步检查副作用确认 xxx 操作是否会影响其他模块 每一步排查后请告诉我你的判断和依据。这个模板的底层逻辑是Codex 和人类一样面对一个复杂问题时容易眉毛胡子一把抓。你帮它把问题拆成小块它反而能表现出更强的推理能力。2.4 组合写法把多个模板嵌套起来这一部分我要重点说。很多人用模板失败是因为他们把模板当成了死格式一个问题只能用一个模板。实际上真正好用的提问方式是把多个模板嵌套组合。举个例子。有一次我要让 Codex 帮我重构一个图像处理 Demo我实际使用的 prompt 长这样先解释一下当前这个图像处理管线的主要瓶颈在哪里模板一先解释再行动。 解释的时候请重点关注内存占用和耗时模板二约束条件。 然后按照下面的要求给我一个重构方案模板三任务加格式 1. 保持对外接口不变 2. 优化内存峰值 3. 给出核心代码片段 在给出方案后先不要直接修改整个文件只说明你计划改动哪些模块模板六分而治之。看到没有我把四个模板嵌套在一起每一层都在逐步收窄 Codex 的注意力和输出范围。最终它给出的重构方案非常精准全程没有一句废话。组合写法还有一个好处它能避免 Codex 在对话过程中跑偏。你要知道Codex 有一个很让人头疼的行为——它会脑补你没有说清楚的部分。你以为你只说优化内存它就会只优化内存实际上它可能会顺手改掉你的日志格式、变量命名甚至重构掉一个你根本不想动的方法。组合模板把这些边界都提前框死了它想去哪都被你拽着。3. 这套模板背后的原理为什么 Codex 需要这样的提问方式这一节讲点底层的东西。明白了原理你才能真正灵活运用模板而不是死记硬背。3.1 Codex 的上下文窗口和注意力机制Codex 这类编程助手本质上是一个超大型语言模型它一次能看到的内容是有限的这个限制在行业内被称为上下文窗口。窗口越大它能同时容纳的代码量和对话历史就越多但它对窗口内不同位置的注意力是不均匀的。这意味着什么意味着你要是把一个 2000 行的文件整个丢给它然后问帮我找到所有潜在的 bug它大概率会漏掉后半段文件的问题。它的注意力是有限的你让它一口气处理太多东西它就只能均匀地扫一遍而不是深入地看某几处。所以模板三任务格式和模板六分而治之的本质就是把模型有限的注意力集中到你真正关心的那个点上。你是在引导它往哪看而不是指望它全看到。3.2 代码理解的非唯一性Codex 需要对齐预期这是我认为 Codex 使用中最大的一个隐藏坑。一段代码的实现方式往往不是唯一的。比如排序可以用sort()、可以用冒泡、也可以用快排发请求可以用fetch、也可以用axios。Codex 在理解你的代码时它看到的不是你理解的那个意思而是它从代码中推断出来的那个意思。这两者之间天然存在偏差。模板一先解释再行动和模板二加上约束条件解决的就是这个偏差。你先让 Codex 把它的理解说出来你就能判断它理解得到不到位你把约束条件写清楚它就不敢随便用默认假设去脑补。我遇到过很多次这种情况Codex 说这段代码的功能是 A实际上这段代码做的是在 A 的基础上增加了 B 的预处理。这时候如果我直接让它改代码它所有的修改都会基于一个错误的认知。所以先对齐预期永远值得那多花的一分钟。3.3 输出格式对模型推理能力的影响这个观点可能很多人没意识到你要求的输出格式会影响 Codex 的推理质量。当你只要求给我一个修复方案时Codex 倾向于直接给出结论省去了中间的推理过程。这在复杂问题时会导致错误率升高。但当你要求分步骤给出修复方案并解释每一步的意图时模型的推理链被强制拉长了它不得不把大问题分解成小步骤并在每一步上做出解释。这个过程在行业内叫让模型逐步推理它通常能显著提升复杂任务的正确率。这就是模板五为什么要强调分步骤、解释意图。你不是在为难 Codex你是在帮它更好地思考。4. Codex 提问的真正难点不是模板是组合思维很多读者看到 7 个模板之后会陷入一个误区以为背熟了模板就能用好 Codex。我见过太多人收藏了一堆 prompt 模板真正遇到实际问题时还是不知道怎么用。原因很简单模板只是招式组合思维才是心法。那什么是组合思维简单说就是在提问之前,先想清楚三个问题这个问题Codex 需要先理解什么才能给出可靠回答这个问题的输出我希望以什么形式呈现这个问题可能涉及哪些潜在陷阱我需要提前框定哪些边界我举个真实的例子。很早之前我做一个某跨平台系统时遇到一个问题在低网速环境下某个数据同步功能总是超时而且日志里没有任何错误信息。一开始我直接用模板五提问报错超时。期望行为正常同步。实际行为超时后无日志。帮我定位。Codex 给的回答比较泛——列了五个可能原因让我的排查方向铺得很开。后来我把这个问题拆了一下换成了组合式提问先解释一下这个同步模块的数据流向模板一。 重点关注网络异常时的分支处理模板二。 然后假设你是系统架构师模板三的角色按照下面的步骤帮我排查 第一步从数据流向判断超时后哪些模块会先退出 第二步检查日志埋点哪些环节没有打日志 第三步对比正常网速和低网速下数据包大小是否有差异模板六 每一步请说明你的判断依据最后给修复建议模板五的输出格式要求。这次 Codex 给出的回答就完全不一样了。它把排查范围从所有可能原因收窄到链路中无日志埋点的环节并且明确指出低网速下数据包过大可能导致 TCP 分片进而引发超时但没有应用层日志。最后顺着这个方向检查果然是数据包过大触发了底层超时机制。这个例子想说明的是**模板之间的组合远大于单个模板相加。**模板解决的是单一层面的问题理解、生成、修复而组合解决的是真实世界中的复杂问题——它往往是跨层面的需要理解约束拆解格式化输出同时进行。那经营组合思维有没有捷径我自己总结了一个习惯叫提问前先列三行第一行我遇到的问题是什么类型理解/生成/修复 第二行Codex 要解决这个问题需要知道哪些背景信息约束/范例/上下文 第三行我要它用什么形式输出代码/解释/分步方案/对比表格把这三行在心里过一遍提问的组合结构基本都是水到渠成的事情。这也是我从死记模板到灵活提问的关键转折点。5. 3 个容易被忽视的实战要点这一部分分享一些我踩过坑之后才总结出来的东西。它们不在任何官方文档里但是用 Codex 的人几乎都会碰到。5.1 第一次提问就贴全上下文但别贴无关代码Codex 的上下文是宝贵的你要在给它足够信息和不给它无关噪音之间找平衡。我见过一些人第一次提问就把整个项目压缩包路径发给 Codex然后说帮我重构这个项目。这种行为的问题在于Codex 只会挑它觉得重要的文件看而它觉得重要的和你觉得重要的往往不完全一样。我的做法是先贴关键文件的核心片段或者明确说出只需要关注 src/utils/request.ts 这个文件。要么就只描述依赖关系让 Codex 自己去项目里找该看的文件。反正记住一个原则给 Codex 的上下文应该是你希望它深入理解的那些代码而不是所有代码。5.2 一次只让 Codex 做一件事这一点真的太重要了。人不能同时做三件事还指望每件事都做到最好Codex 也一样。你要是说帮我优化这个函数、顺便加个测试、再写个文档它一定会把三个任务互相污染。最后优化不彻底、测试覆盖不全、文档写了个寂寞。我现在的习惯是一次对话只聚焦一个任务。如果要做的任务确实很多我就把它们拆成多次对话每次对话之间清空上下文重新开始。虽然不是每次都方便但在关键任务上效果绝对值得。5.3 让 Codex 解释一下为什么比直接改更有长期价值遇到 bug 时很多人第一反应是让 Codex 直接改。改完 bug 好了皆大欢喜。但下次再遇到类似问题你依然不会排查。换个方式先让 Codex 解释为什么会产生这个问题再让它给出修复方案最后让它告诉你以后怎么避免。整个过程多花两分钟但你对代码的理解会加深一个层次。长期来看这才是用 Codex 提升能力而不是用 Codex 替代思考。6. 实战演示用组合模板改动某开源项目的完整过程理论讲了这么多最后我完整地走一遍实战。为了不涉及具体项目信息我用一个模拟项目 X 来代替。这个项目是一个命令行工具功能是把 Markdown 文件批量转换为 HTML我在使用中发现两个问题转换速度比较慢大文件要等好几秒部分包含特殊字符的 Markdown 文件转换结果会出现乱码下面是我完整的使用过程。6.1 第一步让 Codex 先建立全局认知我不会一上来就让 Codex 修 bug。我先让它解释转换流程的整体逻辑。先解释一下这个项目的主要数据流向从读取 Markdown 文件到最后输出 HTML中间经历了哪些主要步骤。重点关注有没有重复解析、有没有不必要的内存拷贝、特殊字符是在哪个环节被处理的。先不要修改任何代码。这一个 prompt 里面用了模板一先解释再行动、模板二约束条件让它重点关注性能点和字符处理点。Codex 给出了一段约 20 行的流程描述我看完之后立刻定位到一个可疑环节Markdown 解析器在每次循环中都会被重新实例化而且在解析前还做了一次全量正则预处理这个正则很可能就是特殊字符乱码的根源。6.2 第二步针对可疑环节深入追问有了初步判断我没有直接要求修改而是继续追问。你在解释中提到“解析器被重复实例化”和“全量正则预处理”这两个点。请进一步分析 1. 重复实例化的性能影响有多大 2. 这个全量正则预处理是否有必要它会不会破坏包含特殊字符的输入 3. 如果要优化哪个环节对你的改动最小、效果最明显这一步的作用是让 Codex 在一个较小的范围内展开分析。因为它已经有了全局认知这次回答明显更有针对性。它指出解析器重复实例化的性能开销大概占到总耗时的 30% 到 40%而全量正则预处理确实存在风险——它用了一个贪婪匹配规则会把某些 Markdown 内的特殊符号两侧加上多余的转义。乱码问题基本锁定了。6.3 第三步限制范围要求给出分步方案现在我可以让 Codex 动手了。但我不会说帮我改这两个问题我会把边界框得非常具体。请基于前面的分析做一个最小化改动方案。要求 1. 只修改性能优化和特殊字符处理两个模块其他模块一律不动 2. 性能优化要保留原有的文件遍历逻辑 3. 特殊字符处理不能改变最终的 HTML 渲染结果 4. 请分步骤列出改动方案每一步说明改动位置、改动内容、以及为什么这样改 5. 最后再给出改动后的关键代码片段在我这里模板三任务格式、模板五分步加解释意图、以及边界约束同时生效。Codex 给的改动方案一共 4 步把解析器实例挪出循环、去掉贪婪正则、改成按字符状态机处理特殊符号、补充两个针对特殊字符的测试用例。6.4 第四步验证与反馈闭环Codex 不是一次性就能做到完美的好的使用习惯是反馈闭环。我按照它的方案改完了代码然后跑了一遍测试发现特殊字符问题解决了但转换速度的提升没有它预估的那么明显。我把测试结果反馈给它我按照你的方案修改后乱码问题已解决感谢。但性能提升大约只有 20%没有达到你预估的 30%-40%。请再帮我分析一下当前代码中还有哪些潜在的瓶颈尤其是不涉及文件遍历逻辑的部分。然后 Codex 又定位到一处问题在 HTML 转义环节对每个字符都调用了正则替换这会引入大量不必要的回溯开销。它建议改成查表映射。这次改动之后性能提升了大概 35%。整个过程走下来我用到的模板覆盖了理解类、约束类、任务格式类、分步排查类它们不是按照某个固定顺序出现而是根据对话的进展自然组合起来的。这也是我在前文强调的组合思维的真实体现。7. 我的 5 步提问检查清单最后把我日常使用 Codex 前的检查清单分享出来。每次提问前我都会在心里过一遍这 5 步用来确保不浪费上下文、不跑偏方向、不遗漏边界。定类型这次提问是理解、生成、还是修复如果需要多个类型就准备把它拆成多个步骤。补上下文Codex 需要知道哪些背景信息才能回答好这些信息我给了吗注意区分关键信息和无关噪音。写边界哪些是绝对不能碰的哪些是要求必须满足的把边界写清楚是防止 Codex 过度发挥的关键。定格式我希望它输出代码、解释、分步方案还是对比表格格式越明确回答越可控。留验证回答给出之后我准备用什么方式验证是跑测试、看性能指标、还是人工审查这套清单看起来简单但每次提问花 30 秒过一遍长期积累下来你的 Codex 使用效率会有一个肉眼可见的跳跃。写这篇文章的时候我回想起最初用 Codex 时那种对话三句就跑偏的挫败感再看看现在组合模板跑完整流程的顺滑程度真心觉得**工具是固定的但提问的人可以把工具用出完全不同的效果。**希望这套急救卡能帮你在关键时刻少卡几次壳。