Codex提问急救卡：7个常用模板与组合写法，提升代码助手回答质量

1. 为什么“提问”本身需要一张急救卡写代码这件事卡住的时候往往不是不会写而是不知道该问什么、怎么问。我见过太多同行包括我自己早期遇到报错第一反应是复制整段堆栈丢进对话框然后得到一段看似正确、跑起来继续报错的回答。来回几轮之后时间没了问题还在。后来我慢慢意识到跟 Codex 这类代码助手打交道本质上是一次“需求描述 上下文投喂 约束条件”的工程化沟通而不是聊天。你给的信息越结构化它返回的代码越接近可直接落地的状态。所谓“提问急救卡”就是把这套沟通方式固化成几个可复用的模板。标题里说的 7 个常用模板覆盖的是日常开发中最高频的七类场景报错定位、函数补全、代码重构、单元测试生成、性能优化、跨语言翻译、以及代码解释。而“组合写法”指的是当单一模板不够用时把两三个模板拼接起来形成一条信息密度更高的提问。这套东西我用了大半年最大的感受是提问质量决定了返工次数。一条好的提问能让你少改三遍代码。这篇文章适合谁看如果你是刚接触代码助手的新手这 7 个模板可以直接抄去用如果你已经用了一段时间但总觉得“它答得不够准”那问题多半出在提问结构上组合写法那部分会对你有帮助。我不打算讲什么玄学提示词只讲我实际验证过、能稳定复现效果的写法。下面从整体设计思路开始拆。2. 提问模板的整体设计思路2.1 一条好提问的三个必备要素我总结下来任何一条能让 Codex 给出高质量回答的提问都包含三个要素角色与目标、上下文、约束条件。缺一个回答就会偏。角色与目标解决的是“你要它干什么”。比如“帮我写一个函数”太模糊“帮我写一个接收字符串数组、返回去重后按长度排序的数组的 Python 函数”就明确得多。上下文解决的是“它需要知道什么才能干对”包括语言版本、框架、已有代码片段、报错信息。约束条件解决的是“边界在哪”比如不能用某个库、必须兼容某个版本、时间复杂度要求。很多人提问只给了第一项然后抱怨回答不能用。其实不是模型不行是信息没给够。你可以把 Codex 想象成一个刚入职的同事他技术不错但完全不了解你的项目。你交代任务时如果只说“把这个功能做了”他大概率做偏如果你说清楚背景、目标、限制他一次就能做对。提问模板的价值就是帮你把这三要素固定成填空格式避免每次临场组织语言时漏掉关键信息。2.2 为什么是这 7 个模板而不是别的日常开发中我们向代码助手求助的场景其实高度集中。我统计过自己一个月的提问记录排在前面的依次是看不懂的报错、写一半卡住的函数、想优化但不敢动的老代码、没有测试覆盖的新模块、跑得太慢的查询、需要从别的语言搬过来的逻辑、以及接手别人代码时看不懂的段落。这七类几乎覆盖了 80% 以上的求助场景所以我把它们各自固化成一个模板。选择这七个而不是更细分的模板还有一个考虑模板太多反而记不住。急救卡的意义在于“卡住时能立刻想起来用哪个”七个刚好是能记住的上限。每个模板我都尽量做到结构一致——都是“场景 输入 期望输出 约束”四段式这样你记住一个就等于记住了七个的骨架用的时候只需要换内容。2.3 模板与组合写法的关系单一模板解决单一问题但真实开发中问题往往是复合的。比如你拿到一段报错定位到是某个函数的问题然后需要重构这个函数并补上测试——这就同时涉及报错定位、重构、测试生成三个模板。组合写法不是简单拼接而是有主次的通常以最终目标为主模板把其他模板作为上下文或约束嵌入进去。我常用的组合方式是“主模板 前置上下文模板”。比如以“重构”为主前面嵌入“代码解释”让模型先理解这段代码在干什么再让它重构。这样比直接丢一段代码说“重构一下”效果好很多因为模型先建立了对代码意图的理解重构时就不会改变原有语义。这个思路在后面组合写法章节会展开讲这里先建立概念。3. 七个常用模板逐个拆解3.1 模板一报错定位模板这是使用频率最高的一个。核心结构是环境信息 完整报错 相关代码 已尝试的操作。很多人只给报错不给代码模型只能猜。正确的写法是这样环境Python 3.11使用 requests 2.31运行在 Linux 报错信息粘贴完整堆栈不要截断 相关代码粘贴报错涉及的函数前后各留几行上下文 我已经试过比如换过版本、加过超时说明结果 请帮我定位根因并给出最小修改方案。这里有个关键细节报错信息一定要完整。我见过太多人只复制最后一行KeyError: xxx把前面的调用栈全删了。调用栈才是定位问题的关键它告诉你错误从哪一层传上来的。另外“已尝试的操作”这一项很多人会省略但它能避免模型给出你已经试过的无效建议节省来回轮次。注意如果报错里包含敏感路径或内部标识粘贴前先做替换用占位符代替这不影响模型理解问题。3.2 模板二函数补全模板当你写了一半卡住或者知道要什么但懒得从头写用这个模板。结构是函数签名 输入输出示例 边界条件 语言与风格要求。请帮我实现下面这个函数 函数签名def merge_intervals(intervals: list[list[int]]) - list[list[int]] 输入示例[[1,3],[2,6],[8,10],[15,18]] 期望输出[[1,6],[8,10],[15,18]] 边界条件输入可能为空列表区间可能完全包含输入未排序 语言Python 3.10不要用第三方库 风格加类型注解关键步骤写注释给输入输出示例这一步特别重要。文字描述“合并重叠区间”有歧义但给一组具体的输入输出模型立刻就能对齐你的预期。边界条件则是防止它写出“happy path 能跑、边界就崩”的代码。我实测下来带边界条件的提问返回代码的健壮性明显更高。3.3 模板三代码重构模板重构的难点在于“不改变行为”。所以这个模板的核心是先声明行为不变再给出重构目标。下面这段代码功能正常但我想重构它。 重构目标降低圈复杂度 / 提取重复逻辑 / 改善命名 约束不改变对外行为不改变函数签名不引入新依赖 代码粘贴完整函数 请给出重构后的代码并说明每处改动的原因。“说明每处改动的原因”这一句是我后来加的非常有用。它逼着模型解释自己的决策你能借此判断改动是否合理而不是盲目接受。有几次模型的重构其实改变了边界行为正是通过它的解释我才发现的。3.4 模板四单元测试生成模板写测试是很多人的痛点交给模型很合适。结构是被测代码 测试框架 覆盖要求 命名规范。请为下面的函数生成单元测试 被测代码粘贴函数 测试框架pytest 覆盖要求正常路径、边界值、异常输入各至少一个用例 命名规范test_ 开头用例名描述被测行为 请使用参数化测试覆盖多组输入。这里的关键是“覆盖要求”要具体。只说“生成测试”模型可能只给两个 happy path 用例。明确要求边界值和异常输入它才会认真覆盖。另外指定参数化测试能避免生成一堆重复结构的用例函数可读性好很多。3.5 模板五性能优化模板性能问题不能瞎优化得先有数据。所以这个模板要求现状数据 瓶颈位置 优化目标 不可动的约束。下面这段代码在处理 10 万条数据时耗时约 8 秒目标是降到 2 秒以内。 瓶颈我初步定位在嵌套循环部分已标注 约束不能改变输入输出格式不能引入重型依赖 代码粘贴代码 请分析瓶颈并给出优化方案说明预期提升幅度。“说明预期提升幅度”这句能帮你判断方案值不值得做。如果模型说某个改动只能提升 10%那可能不值得引入复杂度。另外一定要给现状数据没有基线就没法衡量优化效果这是性能工作的基本纪律。3.6 模板六跨语言翻译模板把逻辑从一种语言搬到另一种坑很多因为两种语言的惯用法不同。模板结构源语言与目标语言 源代码 目标语言版本 特殊要求。请把下面的 JavaScript 代码翻译成 Python 源代码粘贴 目标版本Python 3.10 要求使用 Python 惯用法不要逐行直译保持原有逻辑和边界行为 如果某些 JS 特性在 Python 中没有直接对应请说明你的处理方式。“不要逐行直译”这句很关键。逐行直译出来的代码往往带着源语言的思维在目标语言里很别扭。要求用惯用法模型会做更地道的转换。最后那句“说明处理方式”则是为了处理那些没有直接对应的特性比如 JS 的undefined和 Python 的None语义差异。3.7 模板七代码解释模板接手别人代码、或者看开源项目时用。结构代码 解释粒度 关注点。请解释下面这段代码 代码粘贴 解释粒度逐段解释每段说明它在做什么、为什么这么做 关注点重点说明数据流向和异常处理逻辑 如果代码有潜在问题或坏味道请一并指出。“关注点”这一项让解释更有针对性。不加的话模型可能平均用力讲了一堆你不需要的细节。加上之后它会围绕你关心的部分深入。最后那句“指出潜在问题”经常能挖出一些原作者留下的坑很有价值。4. 组合写法把模板拼起来用4.1 主模板加前置上下文最常见的组合。比如你要重构一段看不懂的代码直接丢给重构模板模型可能改错语义。正确做法是先让它解释再让它重构第一步请先解释下面这段代码的功能和数据流 粘贴代码 第二步在理解上述功能的基础上帮我重构它目标是提取重复逻辑 约束是不改变对外行为。这种“先理解后操作”的组合我实测下来重构准确率提升明显。因为模型在第二步时已经建立了对代码意图的认知不会把“看起来冗余但实际必要”的逻辑删掉。4.2 报错定位加函数补全有时候报错是因为某个函数根本没实现完。这时候组合写法是先定位再补全。下面这个报错出现在调用 process_data 时 粘贴报错和调用代码 请先定位根因。如果根因是 process_data 未实现或实现不完整 请按以下签名补全它 签名def process_data(records: list[dict]) - dict 输入示例给一组 期望输出给一组这样一条提问同时解决了“为什么错”和“怎么修”省了一轮交互。4.3 测试生成加性能优化给一段待优化的代码生成测试先锁定行为再优化这样优化后能立刻验证行为没变。这是很工程化的组合第一步为下面这段代码生成 pytest 测试覆盖正常和边界情况 粘贴代码 第二步在测试保护下优化它的性能目标是从 8 秒降到 2 秒 约束是不改变输入输出。这个组合的价值在于测试成了优化的安全网。我强烈建议做任何性能优化前都先有测试否则你根本不知道优化有没有改变行为。4.4 组合写法的注意事项组合不是越长越好。我试过把四五个模板全塞进一条提问结果模型顾此失彼每个部分都做得不深。经验是一条提问最多组合两个模板超过两个就拆成多轮。另外组合时要有明确的主次用“第一步/第二步”或“在……基础上”这样的连接词把逻辑串起来别让模型猜你的意图。提示组合提问如果发现模型只完成了后半部分说明前半部分被当成了背景信息。这时候把前半部分单独发一轮拿到结果后再发后半部分效果更稳。5. 实操过程与核心环节实现5.1 从一条真实报错开始走完整流程假设你遇到一个典型报错处理数据时抛出TypeError: unsupported operand type(s) for : NoneType and int。按急救卡流程第一步用报错定位模板环境Python 3.11 报错TypeError: unsupported operand type(s) for : NoneType and int 相关代码 def total_score(records): result 0 for r in records: result result r.get(score) return result 已尝试确认 records 非空 请定位根因并给最小修改方案。模型会指出r.get(score)在键不存在时返回None与0相加报错。最小修改是r.get(score, 0)。这一步很快。5.2 定位之后紧接着补全与加固拿到根因后问题其实还没完——如果业务上score缺失应该报错而不是当 0 处理呢这时候用组合写法把函数补全和测试生成接上基于上面的函数请做两件事 1. 修改为score 缺失时抛出 ValueError 并带上记录索引 2. 为修改后的函数生成 pytest 测试覆盖 score 存在、缺失、为 0 三种情况这样一轮下来你不仅修了 bug还明确了边界行为并且有了测试保护。这就是急救卡组合写法的实际价值——把一次救火变成一次加固。5.3 参数与约束的写法示范约束条件怎么写才有效我总结了几种高频约束和它们的写法约束类型无效写法有效写法依赖限制别用太多库仅使用标准库不引入第三方依赖版本兼容兼容老版本需兼容 Python 3.8不能用 3.10 的语法性能要求快一点处理 10 万条数据需在 2 秒内完成风格要求写好看点加类型注解函数不超过 30 行关键逻辑写注释行为约束别改逻辑不改变函数签名和对外行为仅内部重构这张表是我踩坑总结出来的。约束越具体模型越不会自由发挥。模糊的约束等于没约束。5.4 一次完整的重构实操记录我拿一段真实的老代码走过完整流程。原始函数有 60 多行嵌套三层命名混乱。第一步用代码解释模板让它先讲清楚这段代码在干什么确认理解无误。第二步用重构模板明确目标是“提取重复的校验逻辑、降低嵌套层级、改善命名”约束是“不改变行为”。模型返回后我用第三步测试生成模板补了测试跑通确认行为一致。整个过程三轮提问比我自己硬啃快了大概一倍。关键心得是别指望一轮提问解决所有问题。把大任务拆成“理解—改造—验证”三步每步用对应模板比一次性提一个大而全的要求靠谱得多。6. 常见问题与排查技巧实录6.1 模型答非所问怎么办最常见的原因是上下文给少了或者问题里混了多个不相关的诉求。排查顺序先看是不是一条提问里塞了太多目标是的话拆开再看上下文是否足够比如报错没给全、代码没给上下文。我遇到过一次模型一直答偏最后发现是我粘贴代码时漏了函数定义它只能靠猜。补上之后一次就对了。6.2 返回代码跑不通怎么排查先别急着说模型不行。按这个顺序查第一检查它用的库版本和你环境是否一致第二检查它假设的输入格式和你实际的是否一致第三看它有没有用你没提到的依赖。多数“跑不通”其实是环境或假设不匹配。把报错再喂回去用报错定位模板追问通常一两轮就能收敛。6.3 提问太长被截断的处理组合写法容易让提问变长。如果发现回答只覆盖了后半部分说明前半部分可能被当背景略过了。处理办法是拆轮次先发前半部分拿结果再把结果作为上下文发后半部分。另外粘贴大段代码时只保留相关部分无关的删掉既省长度又减少干扰。6.4 常见问题速查表现象可能原因处理办法答非所问目标不明确或诉求过多拆成单目标提问代码跑不通环境/版本/输入假设不符补充环境信息后追问只答一半提问过长前半被忽略拆轮次分步提问改动超范围约束没写清楚补上明确的边界约束解释太浅没指定关注点加上“重点关注……”测试覆盖不足没要求边界和异常明确列出覆盖要求6.5 几条压箱底的避坑经验第一永远给一组具体的输入输出示例这比任何文字描述都管用。第二约束要写成“不能做什么”而不是“尽量怎样”前者是硬边界后者模型会打折执行。第三重构和优化前先要测试没有测试保护的改动都是赌博。第四别在一条提问里既让它解释又让它改先解释确认理解再动手改这个顺序不能省。第五保留你的提问记录好的提问是可以复用的资产下次遇到同类问题直接改改就能用。这套急救卡我自己用下来最大的改变不是省了多少时间而是提问前会先想清楚“我到底要什么”。这个思考过程本身就解决了一部分问题。后面如果你用顺手了可以按自己的场景再扩展模板比如加一个“接口设计”模板或者“日志排查”模板骨架还是那四段式换内容就行。