1. 为什么“提问”本身需要一张急救卡写代码这件事卡住的时候往往不是不会写而是不知道该问什么、怎么问。我见过太多同行包括我自己早期遇到报错第一反应是截图丢群里配一句“这个怎么解决”然后等半天没人理。不是别人冷漠是这种问法根本没法答——没有上下文、没有复现路径、没有已经尝试过的方向回答者要花十分钟反问你才能开始思考。Codex 这类代码辅助工具现在几乎成了日常标配但很多人用它的方式还停留在“许愿”阶段输入一句模糊需求期待它吐出能直接跑的代码。结果要么得到一段泛泛而谈的示例要么生成的代码跟自己的项目结构完全对不上。问题不在工具在于提问的颗粒度太粗。所谓“提问急救卡”本质是把提问这件事模板化。就像医生急救有标准流程程序员向 Codex 提问也该有一套固定动作先交代环境再描述现象然后给出约束最后明确期望输出。这套动作练熟了你会发现同一个工具给出的答案质量能差出三倍以上。这篇文章面向的是所有日常用 Codex 辅助编码的人——不管你是刚入行的新手还是写了七八年代码但没系统研究过提示词的老手。我会拆解 7 个高频场景下的提问模板再讲清楚怎么把它们组合起来用。每个模板都附带我实际踩过的坑和调整过程你可以直接抄也可以按自己的项目改。核心关键词就三个提问模板、Codex 组合写法、代码辅助效率。这三个词贯穿全文后面每个章节都会围绕它们展开。2. 提问模板的底层逻辑Codex 到底在“听”什么2.1 从“许愿式提问”到“结构化提问”的转变先搞清楚一件事Codex 不是人它没有“猜你意思”的能力。你给它一段模糊描述它只能根据训练数据里最常见的模式去补全。你问“怎么写一个登录功能”它大概率给你一个最通用的用户名密码表单用最流行的框架但跟你项目里用的技术栈可能八竿子打不着。结构化提问的核心是把“我想要的”翻译成“它能理解的”。这中间有三个关键信息层环境层语言、框架、版本、运行平台、依赖库。这些决定了代码能不能跑起来。现象层当前发生了什么、报错信息是什么、期望发生什么。这是定位问题的锚点。约束层性能要求、代码风格、不能用的库、必须兼容的旧代码。这是让输出可用的关键。我试过同一个 bug用“许愿式”问法得到的回答是“检查你的配置”用结构化问法得到的回答直接指出了是某个依赖版本冲突并给出了降级方案。差距就在这三层信息上。2.2 模板不是死格式而是信息完整度的检查清单很多人一听“模板”就觉得死板其实模板的作用是防止你漏掉关键信息。就像写事故报告有固定字段不是为了限制你是为了确保该说的都说了。我常用的检查清单是这样的提问前先问自己四个问题——什么环境、什么现象、什么约束、要什么输出。这四个问题答完了提问内容自然就完整了。模板只是把这四个问题的答案组织成 Codex 容易解析的格式。举个例子同样是问“数组去重”许愿式数组怎么去重结构化JavaScript ES6 环境有一个对象数组需要根据 id 字段去重保留第一个出现的元素不能用 lodash输出一个可直接调用的函数。后者得到的代码基本可以直接粘贴使用前者得到的可能是一段需要大改的示例。2.3 组合写法的价值让 Codex 处理复合任务单个模板解决单个问题但实际开发中很少只有一个问题。比如你既要重构一段旧代码又要给它加单元测试还要保证不破坏现有接口。这时候就需要组合写法把多个模板的要素按顺序排列让 Codex 一次性理解完整意图。组合写法的关键在于分层递进先给背景再给任务然后给约束最后给输出格式。这跟人沟通的逻辑是一样的——你先跟同事说清楚项目背景再说要做什么然后说有什么限制最后说交付物长什么样。Codex 虽然不理解“背景”这个概念但它能根据你提供的信息量调整输出的具体程度。我实测下来组合写法比单模板提问的首次可用率高出不少。单模板大概三四成需要二次修改组合写法能到七成以上直接可用。这个差距在赶项目的时候非常明显。3. 七个高频场景的提问模板拆解3.1 模板一报错定位与修复这是使用频率最高的场景。报错信息往往很长很多人习惯只截最后一行但最后一行通常只是表象。模板结构环境语言/框架/版本 操作我执行了什么命令或写了什么代码 报错完整的报错信息不要截断 已尝试我试过哪些方法结果如何 期望希望得到什么结果实操示例假设你在用 Python 的某个数据处理库运行时报了一个 KeyError。不要只发“KeyError 怎么解决”而是环境Python 3.10pandas 1.5.3 操作读取一个 CSV 文件后用 df[user_id] 取列 报错KeyError: user_id完整报错栈如下…… 已尝试检查了 CSV 文件确实有 user_id 这一列但列名前后可能有空格 期望定位为什么取不到这一列并给出修复代码这个模板的关键在于完整报错栈和已尝试。完整报错栈能让 Codex 看到调用链路已尝试能避免它给出你已经试过的无效方案。注意报错信息里的文件路径如果包含敏感信息记得替换成占位符。这不是为了安全是为了让 Codex 聚焦在错误本身而不是路径上。3.2 模板二代码生成与补全代码生成不是让 Codex 替你写整个项目而是让它帮你完成一个边界清晰的小任务。模板结构语言/框架 功能描述一句话说清楚这个函数/类要做什么 输入参数类型和含义 输出返回值类型和含义 约束性能、风格、不能用什么 示例给一个输入输出示例实操示例语言TypeScript 功能实现一个函数把扁平数组转成树形结构 输入Array{id: number, parentId: number | null, name: string} 输出嵌套的树形节点数组每个节点包含 children 字段 约束时间复杂度 O(n)不能用递归因为数据量可能很大 示例输入 [{id:1,parentId:null},{id:2,parentId:1}]输出 [{id:1,children:[{id:2}]}]这个模板里示例是最容易被忽略但最有价值的部分。一个具体的输入输出示例能消除大量歧义。我试过不加示例Codex 对“树形结构”的理解可能跟我的预期有偏差加了示例之后基本一次到位。3.3 模板三代码重构与优化重构类提问最容易犯的错是只说“优化一下”不说优化目标。是跑得更快、读起来更清晰、还是更容易扩展目标不同重构方向完全不同。模板结构当前代码粘贴需要重构的代码 问题当前代码存在什么问题可读性差/性能瓶颈/重复逻辑 目标希望达到什么效果 约束不能改变的外部接口、必须保留的行为实操示例当前代码一段嵌套了五层 if-else 的函数 问题嵌套太深新增条件时容易改错而且每个分支里有重复的日志代码 目标降低嵌套层级消除重复日志保持函数签名不变 约束不能引入新的依赖不能改变函数的输入输出类型重构模板的核心是约束。没有约束的重构Codex 可能给你一个完全不同的实现虽然更优雅但跟你项目里其他代码不兼容。加上约束之后它会在你划定的范围内做优化。3.4 模板四单元测试生成让 Codex 写测试最怕它写出一堆“测试了但没完全测试”的用例。关键是要告诉它边界条件在哪里。模板结构被测函数粘贴函数代码 测试框架Jest/Pytest/JUnit 等 需要覆盖的场景正常情况、边界情况、异常情况 特殊要求mock 方式、断言风格实操示例被测函数一个计算折扣价格的函数 测试框架Jest 需要覆盖正常折扣、折扣为 0、折扣为 100%、价格为 0、价格为负数、折扣超过 100% 特殊要求用 describe/it 结构每个用例要有清晰的描述这个模板里需要覆盖的场景是灵魂。你不列出来Codex 可能只测正常情况。你列出来了它就会针对每个场景设计断言。我一般会把自己能想到的边界条件都写上然后让 Codex 补充它认为还缺的。3.5 模板五技术方案对比与选型选型类提问需要的是对比维度不是直接要答案。模板结构场景项目背景和需求 候选方案我了解到的几个选项 对比维度性能、学习成本、社区活跃度、与现有技术栈的兼容性 倾向我目前倾向于哪个为什么实操示例场景一个中小型后台系统需要做实时消息推送团队只有三个人前端用 React 候选方案WebSocket、Server-Sent Events、轮询 对比维度实现复杂度、服务器资源消耗、浏览器兼容性、断线重连的处理难度 倾向目前倾向 SSE因为实现简单但不确定消息量大了之后性能如何选型模板的关键是倾向。告诉 Codex 你目前的倾向和顾虑它就能针对性地分析而不是给你一份泛泛的对比表格。我试过不加倾向得到的回答像百科词条加了倾向之后回答更像一个同事在帮你分析利弊。3.6 模板六代码解释与文档生成接手旧代码或者看开源项目时需要快速理解一段代码在做什么。模板结构代码粘贴代码 背景这段代码在项目中的位置和作用 需要解释的粒度逐行/逐函数/整体逻辑 输出格式注释/文档/口头解释实操示例代码一段正则表达式和字符串处理逻辑 背景这是一个表单验证函数但正则写得很难读 需要解释的粒度逐段解释正则的每个部分匹配什么 输出格式在代码上方加注释每行注释对应一段正则解释类模板的粒度很重要。你说“解释一下”Codex 可能给你一段概括你说“逐行解释”它才会深入到每个符号的含义。我一般会要求它在代码里加注释这样解释和代码在一起以后回头看也方便。3.7 模板七跨语言/跨框架迁移把一段代码从一种语言翻译到另一种或者从一个框架迁移到另一个。模板结构源语言/框架 目标语言/框架 源代码 迁移要求保持逻辑一致/利用目标语言特性优化/保持相同的 API 设计 注意事项目标语言中与源语言差异较大的地方实操示例源语言Python 目标语言Go 源代码一段用列表推导和装饰器实现的缓存逻辑 迁移要求保持缓存逻辑一致但利用 Go 的并发特性优化读写性能 注意事项Python 的装饰器在 Go 里没有直接对应需要用函数包装实现迁移模板的注意事项是防止 Codex 生硬直译的关键。两种语言之间总有无法一一对应的特性提前说明能让它选择更地道的实现方式。我试过不加注意事项得到的 Go 代码里全是 Python 的影子能跑但很别扭。4. 组合写法实战把多个模板串起来用4.1 组合写法的排列原则单个模板解决单点问题组合写法解决的是“一串问题”。排列顺序遵循一个原则先背景后任务先整体后局部先约束后输出。我常用的组合顺序是环境与背景模板一的环境部分当前代码或现象模板三的代码部分 模板一的现象部分要做的任务模板二的功能描述 模板三的目标约束与注意事项各模板的约束部分汇总期望输出格式模板六的输出格式 模板二的示例这个顺序跟人沟通的逻辑一致先说“我在什么情况下遇到了什么”再说“我想做什么”然后说“有什么限制”最后说“给我什么”。4.2 一个完整的组合提问示例假设你接手了一个旧项目需要把一个用回调实现的异步逻辑改成 Promise同时加测试还要保持接口不变。这是一个典型的复合任务。组合提问环境Node.js 16项目用 CommonJS测试框架是 Jest当前代码粘贴一个嵌套了三层回调的函数用于依次读取配置、请求数据、写入文件任务把回调改成 Promise 链或 async/await为改造后的函数写单元测试保持函数签名和返回值不变约束不能引入 bluebird 等额外 Promise 库错误处理要保持原有的错误信息测试要 mock 文件读写和网络请求输出改造后的函数代码对应的测试文件代码简要说明改造前后的行为差异这个提问里环境来自模板一当前代码来自模板三任务 1 来自模板三任务 2 来自模板四约束是各模板约束的汇总输出格式来自模板六。Codex 拿到这个提问能一次性理解完整意图输出的代码和测试基本可以直接用。4.3 组合写法的常见误区第一个误区是信息过载。把所有能想到的都塞进去结果 Codex 抓不住重点。组合写法不是信息越多越好而是每个信息都要有明确目的。我一般控制在五个信息块以内超过就拆成两次提问。第二个误区是顺序混乱。先说要什么输出再说背景Codex 可能还没理解背景就开始生成输出导致输出跟背景脱节。顺序一定要遵循“背景→任务→约束→输出”的递进。第三个误区是约束冲突。比如同时要求“性能最优”和“代码最简洁”这两个目标有时候是矛盾的。Codex 遇到冲突约束会随机选一个结果可能不是你想要的。约束之间要有一致性如果确实有取舍明确说明优先级。5. 常见问题与排查技巧实录5.1 Codex 回答太泛怎么办这是最常见的问题。原因通常是提问太短、缺少具体信息。排查思路检查是否给了具体的语言和版本检查是否给了输入输出示例检查是否说明了“不要什么”比如“不要用递归”“不要引入新依赖”我试过同一个问题加了一句“不要给我通用示例要根据我上面给的数据结构来写”回答的具体程度立刻提升。5.2 Codex 生成的代码跑不起来先别急着怪工具按这个顺序排查排查项检查内容常见原因版本兼容代码用的语法/API 是否匹配你的版本用了更高版本才有的特性依赖缺失是否引用了未安装的库忘记在提问中说明可用依赖上下文缺失是否假设了不存在的变量/函数提问时没给完整的代码上下文环境差异操作系统/运行时的差异路径分隔符、换行符等我踩过最多次的坑是版本兼容。后来养成了习惯提问时第一句就写清楚版本号这个问题基本消失了。5.3 如何让 Codex 记住之前的对话上下文Codex 这类工具通常有上下文窗口限制对话太长会丢失早期信息。我的做法是每个独立任务开一个新对话如果必须连续对话在关键节点重新粘贴核心代码和约束用“基于上面的代码”这样的指代但不要依赖它记住太早的内容提示如果你发现 Codex 的回答开始偏离最初的约束大概率是上下文被冲淡了。重新发一遍约束比反复纠正更高效。5.4 提问时哪些信息绝对不能给虽然 Codex 是辅助工具但有些信息给了反而添乱无关的业务背景除非影响代码逻辑否则不用讲业务故事情绪化描述“这个破代码烦死了”对解决问题没有帮助多个不相关的问题混在一起一次问一个主题混在一起会互相干扰我早期喜欢在一段提问里塞三四个问题结果 Codex 只回答了第一个后面的被忽略了。后来改成一次一个主题效率反而更高。5.5 独家避坑技巧反向提问法有时候正向描述问题很费劲可以试试反向提问先让 Codex 生成一个可能的错误实现然后你指出哪里不对让它修正。这个方法在需求很模糊、你自己也没想清楚的时候特别管用。比如你不确定某个功能该怎么设计可以先问“如果要用最简单的方式实现 X可能会有什么问题”Codex 列出的问题往往能帮你理清需求。然后你再基于这些问题提出更精确的提问。6. 把模板变成肌肉记忆日常训练方法模板这东西看一遍记不住用多了才能变成条件反射。我的训练方法是每次遇到问题先不急着问花三十秒在脑子里过一遍四个问题——环境、现象、约束、输出。过完了再打开 Codex按模板结构写出来。前两周会觉得麻烦因为要多打很多字。但第三周开始你会发现提问一次就得到可用答案的概率明显上升省下的反复修改时间远超多打的那几行字。另一个方法是收集自己的失败提问。我有个笔记专门记录那些 Codex 回答得很差的提问然后分析缺了哪个要素。分析多了就发现九成以上的失败提问都是因为缺少约束或示例。组合写法也需要练。一开始可以只组合两个模板比如“报错定位代码修复”熟练了再增加到三四个。不要一上来就搞复杂组合容易信息过载。最后分享一个小技巧把你最常用的模板存成代码片段用编辑器的 snippet 功能一键插入。我存了五个最常用的每次提问先插入模板再填空效率提升非常明显。这个习惯坚持一个月你会发现提问本身变成了一种设计行为而不是碰运气。
1. 为什么“提问”本身需要一张急救卡写代码这件事卡住的时候往往不是不会写而是不知道该问什么、怎么问。我见过太多同行包括我自己早期遇到报错第一反应是截图丢群里配一句“这个怎么解决”然后等半天没人理。不是别人冷漠是这种问法根本没法答——没有上下文、没有复现路径、没有已经尝试过的方向回答者要花十分钟反问你才能开始思考。Codex 这类代码辅助工具现在几乎成了日常标配但很多人用它的方式还停留在“许愿”阶段输入一句模糊需求期待它吐出能直接跑的代码。结果要么得到一段泛泛而谈的示例要么生成的代码跟自己的项目结构完全对不上。问题不在工具在于提问的颗粒度太粗。所谓“提问急救卡”本质是把提问这件事模板化。就像医生急救有标准流程程序员向 Codex 提问也该有一套固定动作先交代环境再描述现象然后给出约束最后明确期望输出。这套动作练熟了你会发现同一个工具给出的答案质量能差出三倍以上。这篇文章面向的是所有日常用 Codex 辅助编码的人——不管你是刚入行的新手还是写了七八年代码但没系统研究过提示词的老手。我会拆解 7 个高频场景下的提问模板再讲清楚怎么把它们组合起来用。每个模板都附带我实际踩过的坑和调整过程你可以直接抄也可以按自己的项目改。核心关键词就三个提问模板、Codex 组合写法、代码辅助效率。这三个词贯穿全文后面每个章节都会围绕它们展开。2. 提问模板的底层逻辑Codex 到底在“听”什么2.1 从“许愿式提问”到“结构化提问”的转变先搞清楚一件事Codex 不是人它没有“猜你意思”的能力。你给它一段模糊描述它只能根据训练数据里最常见的模式去补全。你问“怎么写一个登录功能”它大概率给你一个最通用的用户名密码表单用最流行的框架但跟你项目里用的技术栈可能八竿子打不着。结构化提问的核心是把“我想要的”翻译成“它能理解的”。这中间有三个关键信息层环境层语言、框架、版本、运行平台、依赖库。这些决定了代码能不能跑起来。现象层当前发生了什么、报错信息是什么、期望发生什么。这是定位问题的锚点。约束层性能要求、代码风格、不能用的库、必须兼容的旧代码。这是让输出可用的关键。我试过同一个 bug用“许愿式”问法得到的回答是“检查你的配置”用结构化问法得到的回答直接指出了是某个依赖版本冲突并给出了降级方案。差距就在这三层信息上。2.2 模板不是死格式而是信息完整度的检查清单很多人一听“模板”就觉得死板其实模板的作用是防止你漏掉关键信息。就像写事故报告有固定字段不是为了限制你是为了确保该说的都说了。我常用的检查清单是这样的提问前先问自己四个问题——什么环境、什么现象、什么约束、要什么输出。这四个问题答完了提问内容自然就完整了。模板只是把这四个问题的答案组织成 Codex 容易解析的格式。举个例子同样是问“数组去重”许愿式数组怎么去重结构化JavaScript ES6 环境有一个对象数组需要根据 id 字段去重保留第一个出现的元素不能用 lodash输出一个可直接调用的函数。后者得到的代码基本可以直接粘贴使用前者得到的可能是一段需要大改的示例。2.3 组合写法的价值让 Codex 处理复合任务单个模板解决单个问题但实际开发中很少只有一个问题。比如你既要重构一段旧代码又要给它加单元测试还要保证不破坏现有接口。这时候就需要组合写法把多个模板的要素按顺序排列让 Codex 一次性理解完整意图。组合写法的关键在于分层递进先给背景再给任务然后给约束最后给输出格式。这跟人沟通的逻辑是一样的——你先跟同事说清楚项目背景再说要做什么然后说有什么限制最后说交付物长什么样。Codex 虽然不理解“背景”这个概念但它能根据你提供的信息量调整输出的具体程度。我实测下来组合写法比单模板提问的首次可用率高出不少。单模板大概三四成需要二次修改组合写法能到七成以上直接可用。这个差距在赶项目的时候非常明显。3. 七个高频场景的提问模板拆解3.1 模板一报错定位与修复这是使用频率最高的场景。报错信息往往很长很多人习惯只截最后一行但最后一行通常只是表象。模板结构环境语言/框架/版本 操作我执行了什么命令或写了什么代码 报错完整的报错信息不要截断 已尝试我试过哪些方法结果如何 期望希望得到什么结果实操示例假设你在用 Python 的某个数据处理库运行时报了一个 KeyError。不要只发“KeyError 怎么解决”而是环境Python 3.10pandas 1.5.3 操作读取一个 CSV 文件后用 df[user_id] 取列 报错KeyError: user_id完整报错栈如下…… 已尝试检查了 CSV 文件确实有 user_id 这一列但列名前后可能有空格 期望定位为什么取不到这一列并给出修复代码这个模板的关键在于完整报错栈和已尝试。完整报错栈能让 Codex 看到调用链路已尝试能避免它给出你已经试过的无效方案。注意报错信息里的文件路径如果包含敏感信息记得替换成占位符。这不是为了安全是为了让 Codex 聚焦在错误本身而不是路径上。3.2 模板二代码生成与补全代码生成不是让 Codex 替你写整个项目而是让它帮你完成一个边界清晰的小任务。模板结构语言/框架 功能描述一句话说清楚这个函数/类要做什么 输入参数类型和含义 输出返回值类型和含义 约束性能、风格、不能用什么 示例给一个输入输出示例实操示例语言TypeScript 功能实现一个函数把扁平数组转成树形结构 输入Array{id: number, parentId: number | null, name: string} 输出嵌套的树形节点数组每个节点包含 children 字段 约束时间复杂度 O(n)不能用递归因为数据量可能很大 示例输入 [{id:1,parentId:null},{id:2,parentId:1}]输出 [{id:1,children:[{id:2}]}]这个模板里示例是最容易被忽略但最有价值的部分。一个具体的输入输出示例能消除大量歧义。我试过不加示例Codex 对“树形结构”的理解可能跟我的预期有偏差加了示例之后基本一次到位。3.3 模板三代码重构与优化重构类提问最容易犯的错是只说“优化一下”不说优化目标。是跑得更快、读起来更清晰、还是更容易扩展目标不同重构方向完全不同。模板结构当前代码粘贴需要重构的代码 问题当前代码存在什么问题可读性差/性能瓶颈/重复逻辑 目标希望达到什么效果 约束不能改变的外部接口、必须保留的行为实操示例当前代码一段嵌套了五层 if-else 的函数 问题嵌套太深新增条件时容易改错而且每个分支里有重复的日志代码 目标降低嵌套层级消除重复日志保持函数签名不变 约束不能引入新的依赖不能改变函数的输入输出类型重构模板的核心是约束。没有约束的重构Codex 可能给你一个完全不同的实现虽然更优雅但跟你项目里其他代码不兼容。加上约束之后它会在你划定的范围内做优化。3.4 模板四单元测试生成让 Codex 写测试最怕它写出一堆“测试了但没完全测试”的用例。关键是要告诉它边界条件在哪里。模板结构被测函数粘贴函数代码 测试框架Jest/Pytest/JUnit 等 需要覆盖的场景正常情况、边界情况、异常情况 特殊要求mock 方式、断言风格实操示例被测函数一个计算折扣价格的函数 测试框架Jest 需要覆盖正常折扣、折扣为 0、折扣为 100%、价格为 0、价格为负数、折扣超过 100% 特殊要求用 describe/it 结构每个用例要有清晰的描述这个模板里需要覆盖的场景是灵魂。你不列出来Codex 可能只测正常情况。你列出来了它就会针对每个场景设计断言。我一般会把自己能想到的边界条件都写上然后让 Codex 补充它认为还缺的。3.5 模板五技术方案对比与选型选型类提问需要的是对比维度不是直接要答案。模板结构场景项目背景和需求 候选方案我了解到的几个选项 对比维度性能、学习成本、社区活跃度、与现有技术栈的兼容性 倾向我目前倾向于哪个为什么实操示例场景一个中小型后台系统需要做实时消息推送团队只有三个人前端用 React 候选方案WebSocket、Server-Sent Events、轮询 对比维度实现复杂度、服务器资源消耗、浏览器兼容性、断线重连的处理难度 倾向目前倾向 SSE因为实现简单但不确定消息量大了之后性能如何选型模板的关键是倾向。告诉 Codex 你目前的倾向和顾虑它就能针对性地分析而不是给你一份泛泛的对比表格。我试过不加倾向得到的回答像百科词条加了倾向之后回答更像一个同事在帮你分析利弊。3.6 模板六代码解释与文档生成接手旧代码或者看开源项目时需要快速理解一段代码在做什么。模板结构代码粘贴代码 背景这段代码在项目中的位置和作用 需要解释的粒度逐行/逐函数/整体逻辑 输出格式注释/文档/口头解释实操示例代码一段正则表达式和字符串处理逻辑 背景这是一个表单验证函数但正则写得很难读 需要解释的粒度逐段解释正则的每个部分匹配什么 输出格式在代码上方加注释每行注释对应一段正则解释类模板的粒度很重要。你说“解释一下”Codex 可能给你一段概括你说“逐行解释”它才会深入到每个符号的含义。我一般会要求它在代码里加注释这样解释和代码在一起以后回头看也方便。3.7 模板七跨语言/跨框架迁移把一段代码从一种语言翻译到另一种或者从一个框架迁移到另一个。模板结构源语言/框架 目标语言/框架 源代码 迁移要求保持逻辑一致/利用目标语言特性优化/保持相同的 API 设计 注意事项目标语言中与源语言差异较大的地方实操示例源语言Python 目标语言Go 源代码一段用列表推导和装饰器实现的缓存逻辑 迁移要求保持缓存逻辑一致但利用 Go 的并发特性优化读写性能 注意事项Python 的装饰器在 Go 里没有直接对应需要用函数包装实现迁移模板的注意事项是防止 Codex 生硬直译的关键。两种语言之间总有无法一一对应的特性提前说明能让它选择更地道的实现方式。我试过不加注意事项得到的 Go 代码里全是 Python 的影子能跑但很别扭。4. 组合写法实战把多个模板串起来用4.1 组合写法的排列原则单个模板解决单点问题组合写法解决的是“一串问题”。排列顺序遵循一个原则先背景后任务先整体后局部先约束后输出。我常用的组合顺序是环境与背景模板一的环境部分当前代码或现象模板三的代码部分 模板一的现象部分要做的任务模板二的功能描述 模板三的目标约束与注意事项各模板的约束部分汇总期望输出格式模板六的输出格式 模板二的示例这个顺序跟人沟通的逻辑一致先说“我在什么情况下遇到了什么”再说“我想做什么”然后说“有什么限制”最后说“给我什么”。4.2 一个完整的组合提问示例假设你接手了一个旧项目需要把一个用回调实现的异步逻辑改成 Promise同时加测试还要保持接口不变。这是一个典型的复合任务。组合提问环境Node.js 16项目用 CommonJS测试框架是 Jest当前代码粘贴一个嵌套了三层回调的函数用于依次读取配置、请求数据、写入文件任务把回调改成 Promise 链或 async/await为改造后的函数写单元测试保持函数签名和返回值不变约束不能引入 bluebird 等额外 Promise 库错误处理要保持原有的错误信息测试要 mock 文件读写和网络请求输出改造后的函数代码对应的测试文件代码简要说明改造前后的行为差异这个提问里环境来自模板一当前代码来自模板三任务 1 来自模板三任务 2 来自模板四约束是各模板约束的汇总输出格式来自模板六。Codex 拿到这个提问能一次性理解完整意图输出的代码和测试基本可以直接用。4.3 组合写法的常见误区第一个误区是信息过载。把所有能想到的都塞进去结果 Codex 抓不住重点。组合写法不是信息越多越好而是每个信息都要有明确目的。我一般控制在五个信息块以内超过就拆成两次提问。第二个误区是顺序混乱。先说要什么输出再说背景Codex 可能还没理解背景就开始生成输出导致输出跟背景脱节。顺序一定要遵循“背景→任务→约束→输出”的递进。第三个误区是约束冲突。比如同时要求“性能最优”和“代码最简洁”这两个目标有时候是矛盾的。Codex 遇到冲突约束会随机选一个结果可能不是你想要的。约束之间要有一致性如果确实有取舍明确说明优先级。5. 常见问题与排查技巧实录5.1 Codex 回答太泛怎么办这是最常见的问题。原因通常是提问太短、缺少具体信息。排查思路检查是否给了具体的语言和版本检查是否给了输入输出示例检查是否说明了“不要什么”比如“不要用递归”“不要引入新依赖”我试过同一个问题加了一句“不要给我通用示例要根据我上面给的数据结构来写”回答的具体程度立刻提升。5.2 Codex 生成的代码跑不起来先别急着怪工具按这个顺序排查排查项检查内容常见原因版本兼容代码用的语法/API 是否匹配你的版本用了更高版本才有的特性依赖缺失是否引用了未安装的库忘记在提问中说明可用依赖上下文缺失是否假设了不存在的变量/函数提问时没给完整的代码上下文环境差异操作系统/运行时的差异路径分隔符、换行符等我踩过最多次的坑是版本兼容。后来养成了习惯提问时第一句就写清楚版本号这个问题基本消失了。5.3 如何让 Codex 记住之前的对话上下文Codex 这类工具通常有上下文窗口限制对话太长会丢失早期信息。我的做法是每个独立任务开一个新对话如果必须连续对话在关键节点重新粘贴核心代码和约束用“基于上面的代码”这样的指代但不要依赖它记住太早的内容提示如果你发现 Codex 的回答开始偏离最初的约束大概率是上下文被冲淡了。重新发一遍约束比反复纠正更高效。5.4 提问时哪些信息绝对不能给虽然 Codex 是辅助工具但有些信息给了反而添乱无关的业务背景除非影响代码逻辑否则不用讲业务故事情绪化描述“这个破代码烦死了”对解决问题没有帮助多个不相关的问题混在一起一次问一个主题混在一起会互相干扰我早期喜欢在一段提问里塞三四个问题结果 Codex 只回答了第一个后面的被忽略了。后来改成一次一个主题效率反而更高。5.5 独家避坑技巧反向提问法有时候正向描述问题很费劲可以试试反向提问先让 Codex 生成一个可能的错误实现然后你指出哪里不对让它修正。这个方法在需求很模糊、你自己也没想清楚的时候特别管用。比如你不确定某个功能该怎么设计可以先问“如果要用最简单的方式实现 X可能会有什么问题”Codex 列出的问题往往能帮你理清需求。然后你再基于这些问题提出更精确的提问。6. 把模板变成肌肉记忆日常训练方法模板这东西看一遍记不住用多了才能变成条件反射。我的训练方法是每次遇到问题先不急着问花三十秒在脑子里过一遍四个问题——环境、现象、约束、输出。过完了再打开 Codex按模板结构写出来。前两周会觉得麻烦因为要多打很多字。但第三周开始你会发现提问一次就得到可用答案的概率明显上升省下的反复修改时间远超多打的那几行字。另一个方法是收集自己的失败提问。我有个笔记专门记录那些 Codex 回答得很差的提问然后分析缺了哪个要素。分析多了就发现九成以上的失败提问都是因为缺少约束或示例。组合写法也需要练。一开始可以只组合两个模板比如“报错定位代码修复”熟练了再增加到三四个。不要一上来就搞复杂组合容易信息过载。最后分享一个小技巧把你最常用的模板存成代码片段用编辑器的 snippet 功能一键插入。我存了五个最常用的每次提问先插入模板再填空效率提升非常明显。这个习惯坚持一个月你会发现提问本身变成了一种设计行为而不是碰运气。
