1. 为什么“提问”本身需要一张急救卡写代码这件事卡住的时候往往不是不会写而是不知道该问什么。我见过太多同行包括我自己早期遇到报错第一反应是复制整段错误信息丢给 Codex然后得到一段看似正确、跑起来全是坑的代码。问题出在哪出在提问的方式上。Codex 这类代码生成工具本质上是一个“基于上下文补全”的系统。你给它的信息越结构化、越贴近它训练时见过的模式它返回的结果就越靠谱。反过来如果你只丢一句“这段代码报错了帮我看看”它只能靠猜猜错的概率极高。这张“急救卡”要解决的问题很具体当你被一个 bug 卡住、被一段逻辑绕晕、或者需要快速生成某个功能的骨架时手边有一套现成的提问模板直接套用就能拿到可用的结果。它适合所有用 Codex 辅助写代码的人不管你是刚入行的新手还是写了七八年代码但没系统研究过提示词的老手。我把它叫做“急救卡”是因为这些模板的使用场景都是“急”的——线上出问题了、deadline 快到了、某个 API 怎么调死活想不起来。这时候你没时间慢慢琢磨怎么提问需要的是拿来就用的东西。2. 七个模板的底层逻辑与适用边界在展开每个模板之前先说清楚它们共同的设计原则。这七个模板不是随便凑的它们覆盖了日常编码中最常见的七类求助场景报错排查、功能生成、代码重构、逻辑解释、性能优化、测试编写、文档生成。每一类场景对上下文的要求不同所以模板的结构也不一样。2.1 模板设计的三个核心变量所有模板都围绕三个变量做文章上下文量、约束条件、输出格式。上下文量决定了 Codex 能“看到”多少信息。给太少它只能泛泛而谈给太多关键信息被淹没。我的经验是报错类问题给 20 到 50 行相关代码足够功能生成类问题给接口定义和数据结构即可。约束条件是你对输出的硬性要求。比如“不要用第三方库”“必须兼容某个版本”“时间复杂度不能超过某个量级”。没有约束Codex 会按它认为最“标准”的方式写但那个标准未必符合你的项目规范。输出格式是你希望它怎么组织答案。是要完整代码、只要关键片段、还是先给思路再给代码。明确格式能减少来回修改的次数。2.2 什么情况下不该用模板模板不是万能的。有两种情况我建议你直接自己写一是问题涉及你项目的私有业务逻辑Codex 没有相关上下文套模板也问不出什么二是你需要的是架构层面的决策比如“该不该引入消息队列”这种问题更适合和人讨论而不是问代码生成工具。还有一种情况是问题本身还没想清楚。如果你连自己卡在哪都说不明白先别急着问 Codex拿张纸把问题写下来写到能一句话说清楚为止。这个过程本身往往就能帮你找到答案。3. 七个常用模板逐一拆解下面逐个说这七个模板。每个模板我会给出适用场景、模板正文、一个实际使用的例子以及我踩过的坑。3.1 模板一报错定位与修复适用场景代码运行报错错误信息明确但你不知道根因在哪。模板正文我遇到了一个报错请帮我定位原因并给出修复方案。 运行环境[语言版本/框架版本/操作系统] 报错信息[完整的错误堆栈] 相关代码 [粘贴 20-50 行相关代码] 我已经尝试过[描述你已经试过的排查步骤] 期望结果[描述正常情况下应该发生什么]这个模板的关键在于“我已经尝试过”这一行。很多人会忽略它但这一行能帮 Codex 排除掉那些你已经验证过无效的方向避免它给出你早就试过的建议。实际例子某次我用一个数据处理脚本跑的时候报KeyError但报错行看起来完全正常。我套了这个模板把报错堆栈和前后 30 行代码贴进去并注明“我已经检查过字典的键确实存在”。Codex 返回的分析指出问题出在数据加载阶段某个字段被重命名了导致后续访问时键不匹配。这个方向我自己没想到因为它不在报错行附近。踩坑记录不要只贴报错行那几行代码。很多 bug 的根因在报错位置的上游贴代码时要包含数据流入的那部分逻辑。我一般会贴从函数入口到报错行的完整片段。3.2 模板二功能代码生成适用场景需要快速生成某个函数或类的实现骨架。模板正文请帮我实现一个功能。 功能描述[一句话说清楚这个功能做什么] 输入[输入的数据类型和结构] 输出[输出的数据类型和结构] 约束条件[性能要求/依赖限制/代码风格] 请先给出实现思路确认后再给完整代码。最后那句“先给思路再给代码”很重要。直接要代码的话Codex 可能会选一个你不熟悉的实现方式等你发现不对再改就浪费时间了。先看思路确认方向对了再让它展开。实际例子我需要一个函数把嵌套的 JSON 结构拍平成单层键值对。套模板提问后Codex 先给了两种思路递归和用栈迭代。我选了递归因为数据层级不深递归更易读。然后它给出了完整实现包括处理数组和 null 值的边界情况。踩坑记录约束条件里一定要写清楚你用的语言版本。我有次没写Codex 用了一个新版本才有的语法而我的运行环境是旧版本跑不起来。后来我养成了习惯模板里固定加一行“语言版本XXX”。3.3 模板三代码重构与优化适用场景代码能跑但写得烂想改但不知道从哪下手。模板正文请帮我重构下面这段代码。 当前代码 [粘贴代码] 当前问题[可读性差/重复代码多/性能瓶颈/难以测试] 重构目标[希望达到什么效果] 不能改变的行为[哪些外部行为必须保持不变]“不能改变的行为”这一行是安全绳。重构最怕的就是改着改着把功能改坏了。明确哪些行为不能变Codex 会在保持这些行为的前提下做优化。实际例子我有一段处理订单状态的代码十几个 if-else 嵌套每次加新状态都要改好几处。套模板提问后Codex 建议用状态模式重构把每个状态的处理逻辑抽成独立的类。重构后新增状态只需要加一个类不用动原有代码。踩坑记录重构类问题不要一次贴太多代码。我有次贴了 300 多行Codex 的返回被截断了只处理了前半部分。后来我改成每次只重构一个函数或一个类效果稳定很多。3.4 模板四逻辑解释与学习适用场景看到一段别人写的代码或者 Codex 自己生成的代码看不懂逻辑。模板正文请解释下面这段代码的逻辑。 代码 [粘贴代码] 我的理解[描述你目前理解到什么程度] 不理解的地方[具体哪一行或哪个概念不清楚] 请用通俗的语言解释必要时举例说明。“我的理解”这一行能帮 Codex 判断你的知识水平从而调整解释的深度。如果你什么都不写它可能从最基础的概念讲起浪费你时间。实际例子我看到一段用位运算做权限控制的代码知道大概和权限有关但看不懂具体怎么算的。套模板提问后Codex 用“每个二进制位代表一种权限”这个类比解释了一遍还给了几个具体的数字例子一下就清楚了。踩坑记录解释类问题不要问太宽泛的“这段代码什么意思”。要具体到“这个循环的作用是什么”“这个变量为什么要这样赋值”。问题越具体回答越有用。3.5 模板五性能问题排查适用场景代码逻辑正确但跑得慢需要找到瓶颈。模板正文我的代码有性能问题请帮我分析可能的原因。 代码 [粘贴关键代码] 数据规模[处理的数据量级] 当前耗时[实际耗时] 期望耗时[目标耗时] 运行环境[硬件配置/语言版本]数据规模和运行环境是性能问题的关键上下文。同样一段代码处理 100 条数据和处理 100 万条数据瓶颈可能完全不同。实际例子一个数据聚合脚本处理 10 万条记录要跑 3 分钟。套模板提问后Codex 指出问题在于循环内反复查询数据库建议改成批量查询后在内存中做关联。改完后耗时降到 8 秒。踩坑记录性能问题不要只贴代码一定要给数据规模。我有次没给Codex 建议用缓存优化但我的数据量其实很小缓存反而增加了复杂度。给了规模之后它才会判断是该优化算法还是该减少 IO。3.6 模板六测试用例编写适用场景写完一个函数需要补测试但不知道从哪下手。模板正文请帮我为下面的函数编写测试用例。 函数代码 [粘贴函数] 函数职责[一句话描述这个函数做什么] 边界条件[你知道的边界情况] 测试框架[使用的测试框架] 请覆盖正常情况、边界情况和异常情况。“边界条件”这一行如果你不知道怎么写可以留空让 Codex 帮你列。但如果你已经知道一些写上去能让测试更完整。实际例子我写了一个解析日期字符串的函数套模板让 Codex 生成测试。它不仅覆盖了正常日期格式还覆盖了闰年、月末、时区偏移这些我没想到的情况。后来跑测试果然发现了一个闰年处理的 bug。踩坑记录测试类问题要明确测试框架。不同框架的断言写法、mock 方式都不一样。不写的话 Codex 可能用错框架的语法你还得手动改。3.7 模板七文档与注释生成适用场景代码写完了需要补文档或注释但不想手动写。模板正文请为下面的代码生成文档注释。 代码 [粘贴代码] 文档格式[JSDoc/Google Style/其他] 需要包含[参数说明/返回值/异常/示例] 目标读者[其他开发者/API 使用者]目标读者决定了文档的详细程度。给其他开发者看的内部文档可以简略些给 API 使用者看的就要详细最好带示例。实际例子我写了一个工具函数库套模板让 Codex 生成 JSDoc 注释。它自动识别了每个参数的类型和用途还根据函数逻辑推断出了可能抛出的异常。我只需要微调几处措辞就完成了。踩坑记录文档类问题不要一次生成整个文件的注释。分函数生成每个函数的注释单独确认质量更可控。一次生成太多容易出现模板化的废话注释。4. 组合写法把模板串起来用单个模板能解决单一问题但实际工作中问题往往是复合的。比如你先要定位一个报错修复后发现性能不行优化完还得补测试。这时候就需要把模板组合起来用。4.1 串联式组合按问题解决流程走最常见的组合方式是串联模板一报错定位→ 模板三重构优化→ 模板六测试编写。具体操作时不要在一个对话里把所有模板都发出去。正确的做法是分步进行先用模板一拿到修复方案确认修复有效后再用模板三对修复后的代码做优化最后用模板六补测试。每一步的输入都基于上一步的输出。我试过一次性把三个模板拼在一起发出去结果 Codex 的注意力被分散了每个部分都处理得不够深入。分步走虽然多几轮对话但每轮的质量都更高。4.2 嵌套式组合一个模板里嵌入另一个有时候你需要在生成功能代码的同时就考虑测试。这时候可以把模板六的要素嵌入模板二请帮我实现一个功能并同时给出对应的测试用例。 功能描述[描述] 输入输出[描述] 约束条件[描述] 测试框架[框架名] 请先给实现思路确认后同时给出实现代码和测试代码。这种嵌套写法适合你明确知道这个功能需要测试覆盖的情况。好处是一次性拿到实现和测试不用来回切换上下文。4.3 组合写法的注意事项组合使用时上下文会越来越长。Codex 对上下文长度是有限制的超过之后前面的内容会被截断。我的经验是一个对话里最多组合三个模板超过就开新对话。另外组合使用时每一步的输出都要确认。不要连续发多个模板然后等所有结果。每一步的结果都可能影响下一步的提问方向确认后再继续。5. 常见问题与排查技巧实录这一节整理我在使用这些模板过程中遇到的高频问题以及对应的排查思路。5.1 返回代码跑不通怎么办这是最常见的问题。Codex 返回的代码看起来没问题但一跑就报错。排查顺序是这样的先检查依赖。Codex 可能用了某个库但没在代码里体现导入语句或者用了你环境里没有的版本。我一般会先看它用了哪些 import逐个确认是否已安装且版本匹配。再检查边界条件。Codex 生成的代码往往对正常路径处理得很好但对空值、越界、类型不匹配这些情况考虑不足。手动构造几个边界输入测一下通常能发现问题。最后检查语言版本差异。不同版本的语言在语法和标准库行为上可能有差异。如果报错信息里有“未定义”“不支持”这类词大概率是版本问题。5.2 返回结果太泛怎么办有时候 Codex 的返回很“水”说了一堆正确的废话但没有可落地的内容。这通常是因为提问时约束条件给得太少。解决办法是加约束。比如把“帮我优化这段代码”改成“帮我把这段代码的时间复杂度从 O(n²) 降到 O(n log n)不能引入新的第三方库”。约束越具体返回越有针对性。另一个办法是给例子。如果你希望返回某种特定风格的代码先贴一段你项目里已有的、风格类似的代码作为参考。Codex 会模仿这个风格。5.3 对话变长后质量下降这是上下文窗口的限制导致的。对话轮次多了之后早期的信息会被逐渐“挤出去”Codex 对整体上下文的理解会变模糊。我的做法是当一个问题的解决过程超过五轮对话还没结束就开一个新对话把当前的状态和关键信息重新整理一遍发进去。虽然多花几分钟整理但后续的返回质量会明显回升。5.4 常见问题速查表问题现象可能原因排查动作返回代码报导入错误缺少依赖或版本不匹配检查 import 语句确认依赖已安装返回代码逻辑正确但结果不对边界条件未处理构造空值、极值、类型异常输入测试返回内容泛泛而谈约束条件不足补充性能、依赖、风格等硬性约束对话后期返回质量下降上下文被截断开新对话重新整理关键信息返回代码风格与项目不符未提供风格参考贴一段项目现有代码作为示例生成的测试跑不过测试框架不匹配明确指定测试框架和版本5.5 几个我踩过的坑第一个坑是过度信任。早期我会直接复制 Codex 返回的代码到项目里不做任何检查。有次它返回了一个排序算法逻辑看起来没问题但实际上是不稳定排序而我的场景需要保持相同元素的原始顺序。后来我养成了习惯任何返回的代码都要过一遍逻辑特别是涉及顺序、边界、并发的地方。第二个坑是提问太急。有时候 debug 到半夜脑子不清醒随手丢一句“这段代码为什么不对”就发出去。这种提问基本得不到有用的回答。后来我给自己定了个规矩提问之前先深呼吸把问题在脑子里过一遍确保能说清楚“我期望什么”“实际发生了什么”“我已经排除了什么”。第三个坑是忽略环境信息。有次我让 Codex 写一个文件读取的函数它用了某个新版本的 API而我的运行环境是旧版本。报错之后我才想起来没写环境信息。现在我的模板里固定包含运行环境这一行不管问题看起来多简单。6. 把急救卡变成肌肉记忆这七个模板和组合写法刚开始用的时候需要对着卡片一条条填。用多了之后你会发现自己在提问之前会自然地想上下文给够了吗约束条件写了吗输出格式明确了吗这个过程就变成了肌肉记忆。我的建议是先挑一个你最常遇到的场景比如报错排查把对应的模板用熟。用熟一个再练下一个。不要一次性七个全上那样反而记不住。另外模板不是死的。你可以根据自己的项目特点调整。比如你的项目有严格的代码规范就在所有模板里都加上“遵循项目 ESLint 配置”这一条。你的项目用特定的测试框架就在测试模板里固定写上框架名。模板是起点不是终点。最后分享一个我最近在用的技巧把最常用的三个模板存成代码编辑器的 snippet触发词设成ask1、ask2、ask3。需要提问的时候直接敲触发词模板就出来了填几个空就能发。这个技巧帮我省了不少打字时间也避免了临时想不起来模板结构的情况。