1. 为什么“提问”本身需要一张急救卡写了十几年代码我越来越确信一件事问问题的方式直接决定了你拿到答案的速度和质量。尤其是现在用 Codex 这类代码助手很多人抱怨“它答得不对”“它老是跑偏”但真正的问题往往不在工具而在提问的人。你给它的信息越模糊它返回的东西就越像正确的废话你把上下文、约束、期望输出讲清楚它给出的代码往往能直接粘进项目里跑。所谓“提问急救卡”说白了就是一套在卡壳时能立刻套用的提问模板。它解决的不是“我不会写代码”而是“我知道要什么但不知道怎么把它准确描述给 Codex”。适合谁用三类人最受益一是刚上手代码助手、还在摸索怎么问的新手二是天天用但效率卡在瓶颈、回答质量忽高忽低的中级开发者三是需要把提问能力沉淀成团队规范、让协作更顺的工程负责人。我自己的经历很典型。早期我用 Codex 就是一句话丢过去“帮我写个函数处理数据”。结果它给我一个玩具级别的实现边界情况全没考虑。后来我逼着自己把提问拆成“背景、输入、输出、约束、示例”五块同一个需求回答质量直接上了一个台阶。这篇文章就把我压箱底的7 个常用模板和它们的组合写法完整拆开讲每个模板都配了适用场景、填写要点和我踩过的坑你可以直接抄作业。2. 提问质量的决定性因素拆解2.1 为什么模糊提问必然得到模糊答案先讲清楚底层逻辑不然模板你只会照抄不会活用。Codex 这类工具本质上是基于上下文做概率补全。你给的上下文越少它就越倾向于输出“最常见、最通用”的答案而通用答案往往等于没有针对性的答案。这就像你找同事帮忙只说“帮我看看这段代码”对方只能泛泛扫一眼但你说“这段循环在数据量到十万时会超时帮我看看能不能改成批量处理”对方立刻能聚焦。我做过一个对比实验同一个需求“解析日志文件”两种问法提问方式实际输入返回结果质量模糊式帮我写个解析日志的代码通用模板无字段定义无异常处理结构化日志格式为时间 级别 模块 消息用空格分隔需要按级别统计条数输出字典处理文件不存在的情况可直接运行含异常分支字段解析准确差距一目了然。结构化提问的核心是把“隐含在你脑子里的约束”显式写出来。你脑子里的约束越多、越明确答案就越贴近你的真实需求。2.2 一个高质量提问包含的五个要素我把这五个要素记成一句话背景、输入、输出、约束、示例。这五个要素不是每个提问都要全上但缺得越多答案越飘。背景这段代码在什么项目里、什么语言、什么框架、什么版本。语言和版本尤其关键Python 3.8 和 3.12 的写法可能完全不同。输入函数或模块接收什么数据格式、类型、取值范围。输出期望返回什么格式、类型、精度要求。约束性能要求、不能用的库、代码风格、必须处理的边界情况。示例给一组输入输出样例这是最容易被忽略但最有效的一招。提示示例的力量被严重低估。给一组“输入 A 应该得到输出 B”的样例比写一百字描述都管用因为它把抽象需求变成了可验证的具体目标。理解了这五个要素下面的 7 个模板你就能灵活组合而不是死记硬背。3. 七个常用提问模板逐个拆解3.1 模板一功能实现型——从零写一个模块这是最常用的模板适合“我要一个能干活的东西”。核心是把功能边界画清楚。请用 [语言/版本] 实现一个 [功能名称]。 功能描述[一句话说清它做什么] 输入[类型、格式、示例] 输出[类型、格式、示例] 必须处理的情况[边界1、边界2...] 不要使用[禁止的库或写法] 代码风格[如需要注释、类型标注]我拿它写过一个“按时间窗口聚合请求量”的函数。如果只说“写个聚合函数”Codex 大概率给你一个简单的groupby。但我把输入写成“时间戳列表单位秒可能乱序”输出写成“按 60 秒窗口聚合的计数字典”约束写成“窗口从第一个时间戳对齐不用第三方库”它给出的实现直接可用连乱序处理都考虑到了。填写要点输入输出一定要给示例哪怕只有一行。边界情况至少列三个比如空输入、超大输入、非法输入。这一步花你三十秒能省你半小时调试。3.2 模板二调试排错型——让 Codex 帮你找 bug代码报错时很多人只丢一句“这段报错了帮我看看”这是效率最低的问法。正确的调试模板要把现象、期望、已尝试讲清楚。以下代码在 [运行环境] 下出现问题。 现象[报错信息原文 / 错误行为] 期望[正确行为应该是什么] 已尝试[你改过什么结果如何] 相关代码 [粘贴代码] 请分析最可能的原因并给出修改方案。这里有个关键技巧报错信息要贴原文不要转述。你说“它说类型不对”和贴出TypeError: unsupported operand type(s) for : int and str后者能让 Codex 直接定位到具体运算。我踩过的坑就是转述报错结果它猜了三个方向都不对贴原文后一次命中。注意事项粘贴代码时只贴相关片段别把整个文件几千行丢进去。上下文太长反而会稀释重点让它抓不住关键。如果 bug 涉及多个文件的交互用注释标出调用关系。3.3 模板三代码重构型——让烂代码变干净接手老代码或者自己写崩了想优化时用这个模板。重构的难点在于“保持行为不变”所以约束要写死。请重构以下代码保持功能完全不变。 重构目标[可读性 / 性能 / 减少重复 / 拆分函数] 约束[不能改变对外接口 / 不能引入新依赖 / 保持原有异常行为] 代码 [粘贴代码] 请说明每处改动的原因。我特别看重最后那句“说明每处改动的原因”。不加这句Codex 会默默改一堆东西你根本不知道它动了什么、为什么动。加了之后它会逐条解释你既能学到重构思路也能快速判断改动是否合理。实操心得重构前先让 Codex 帮你写测试用例重构后再跑一遍。顺序是“先补测试再重构”这样万一改出问题测试能立刻发现。这个习惯救过我好几次。3.4 模板四解释学习型——把看不懂的代码讲明白读别人代码或者读开源项目时这个模板能当私人讲师用。请逐行解释以下代码的作用。 我的背景[如熟悉 Python 但不熟悉异步] 重点解释[某几行 / 某个设计模式 / 某个算法] 代码 [粘贴代码]关键在于“我的背景”这一句。同样一段异步代码对熟悉协程的人和对只写过同步代码的人解释方式完全不同。你告诉它你的水平它就会调整讲解的深度和类比方式。我让 Codex 解释过一段装饰器嵌套的代码说明“我懂函数但没写过装饰器”之后它用“给函数穿衣服”的类比讲得特别清楚。避坑提醒解释型提问容易得到“正确的废话”比如“这行代码定义了一个变量”。要避免这个就指定重点行或者追问“为什么这里要用这种方式而不是另一种”。追问是提升解释质量的关键动作。3.5 模板五测试生成型——把测试用例一次写全写测试是很多人的痛点交给 Codex 很合适但要用对模板。请为以下函数生成单元测试。 测试框架[pytest / unittest / jest 等] 需要覆盖[正常情况 / 边界值 / 异常输入 / 空值] 函数代码 [粘贴代码] 每个测试用例请加注释说明测试意图。我强调“每个测试用例加注释”因为测试的可维护性比测试本身更重要。半年后你回来看一个叫test_case_3的测试你根本不知道在测什么但test_empty_input_returns_zero加一行注释一眼就懂。参数选择边界值要具体。别说“测试边界”要说“测试输入为 0、负数、最大值、空列表这四种情况”。越具体生成的测试越有针对性。我一般会先让 Codex 列出它认为该测哪些情况我补充遗漏的再让它生成代码这样覆盖更全。3.6 模板六性能优化型——让慢代码跑起来性能问题最怕瞎优化所以这个模板的重点是先定位再优化。以下代码在 [数据规模] 下性能不达标。 当前表现[耗时 / 内存占用] 目标[期望耗时 / 内存] 运行环境[语言版本、硬件大致情况] 代码 [粘贴代码] 请先分析瓶颈可能在哪再给出优化方案并说明预期收益。“先分析瓶颈再优化”这个顺序不能反。我见过太多人一上来就让 Codex 优化结果它把没问题的部分改得花里胡哨真正的瓶颈纹丝不动。让它先分析你还能顺便验证自己的判断对不对。经验之谈优化方案要问“预期收益”这样你能判断值不值得改。有些优化能把耗时降一半但代码复杂度翻倍那就得权衡。Codex 通常会给出几个方案你按收益和成本挑。3.7 模板七方案对比型——在多个选择间做决策技术选型时用这个模板让 Codex 帮你把利弊摆清楚。我需要在 [场景] 下选择 [方案A] 或 [方案B]。 场景约束[数据量 / 团队规模 / 维护成本 / 学习曲线] 请从 [维度1、维度2、维度3] 对比两者给出推荐并说明理由。这个模板的价值在于逼你把决策维度想清楚。你列出的对比维度其实就是你真正在意的点。我选过“用队列还是直接调用”的方案把“峰值吞吐、故障隔离、运维复杂度”三个维度列出来后Codex 的对比表直接帮我做了决定。注意事项方案对比没有绝对答案只有适不适合。所以一定要把“场景约束”写足否则它会给你一个教科书式的“看情况”回答等于没说。4. 组合写法把模板串起来解决复杂问题4.1 为什么单一模板不够用真实开发中问题很少是单一的。你可能需要“先解释这段老代码再重构它最后补上测试”。这时候单一模板就捉襟见肘了。组合写法的核心思路是把大问题拆成有先后顺序的小问题每个小问题用一个模板前一步的输出作为后一步的输入。这就像做菜你不能把所有食材一起丢锅里得按顺序来。组合提问的好处是每一步都有明确的中间产物你能随时检查、纠偏而不是等最后发现方向全错了。4.2 三种高频组合套路套路一解释 → 重构 → 测试。这是接手遗留代码的标准流程。先用解释模板搞懂它在干嘛再用重构模板优化最后用测试模板锁住行为。三步走完一段烂代码就变成了可维护的资产。套路二实现 → 调试 → 优化。新功能开发的常见路径。先实现基础版本跑起来发现问题就调试功能对了再优化性能。注意顺序别在功能没跑通时就优化那是本末倒置。套路三对比 → 实现 → 测试。技术选型后的落地流程。先对比选定方案再实现最后补测试。这个套路适合引入新库或新架构时用。4.3 组合提问的衔接技巧组合提问最容易断在“衔接”上。我的做法是在每一步的提问里带上上一步的结论。比如重构时我会写“基于上一步的分析这段代码的核心逻辑是 X现在请重构”。这样 Codex 不会丢失上下文回答更连贯。还有一个技巧给每一步设定验收标准。解释步骤的验收是“我能复述它的逻辑”重构步骤的验收是“测试全绿”优化步骤的验收是“达到目标耗时”。有验收标准你就不会在模糊的状态下进入下一步。提示组合提问时如果某一步的回答你不满意不要急着往下走。回到那一步重新问把不满意的点说清楚。带着问题往下走只会越走越偏。5. 常见问题与排查技巧实录5.1 回答跑偏了怎么办这是最高频的问题。回答跑偏通常有三个原因上下文不足、约束没写、需求本身有歧义。排查顺序也是这样。先检查上下文语言版本、框架、运行环境写了吗再检查约束有没有说“不要用什么”“必须满足什么”最后检查需求你自己是不是也没想清楚要什么如果是第三种先别问 Codex先拿张纸把需求写清楚。我遇到过一次让 Codex 写个排序它给了个冒泡。我以为是它水平不行后来发现是我没说数据规模。补上“数据量十万级要求 O(n log n)”之后它立刻换成了快排。跑偏往往是提问的镜子。5.2 回答太笼统怎么破笼统的回答对应笼统的提问。破解方法是加具体数字和具体例子。把“处理大量数据”改成“处理一百万条记录”把“要快”改成“单次调用 100 毫秒内”把“格式要对”改成“输出 JSON字段为 id、name、time”。还有一个技巧是要求它给多个方案。当它只给一个笼统答案时你说“给我三个不同思路的方案并说明各自适用场景”它就被迫具体化。这个方法我屡试不爽。5.3 代码能跑但不符合项目规范这是团队协作里的常见痛点。解决办法是把规范写进提问。命名风格、注释要求、目录结构、错误处理方式这些都要显式说明。更好的做法是维护一份“项目规范提示词”每次提问时附上让 Codex 始终按你的规范来。我见过有团队把规范做成一个模板文件提问时直接引用效果很好。规范这种东西你不说Codex 就按它自己的默认来而默认往往和你的项目不一致。5.4 常见问题速查表问题现象最可能原因排查动作回答跑偏上下文或约束缺失补语言版本、约束、示例回答笼统需求太抽象加具体数字、具体例子代码不符合规范没写项目规范附上命名、注释、结构要求边界没处理没列边界情况显式列出空值、极值、非法值解释太浅没说明自身背景补充你的技术水平和关注点优化没效果没先定位瓶颈要求先分析再优化5.5 我踩过的三个坑第一个坑是一次问太多。我试过把实现、测试、优化全塞进一个提问结果它每样都做得马马虎虎。后来拆成三步每步质量都上去了。提问和写代码一样要单一职责。第二个坑是不给示例。我一度觉得描述清楚就够了直到有次给了组输入输出样例回答质量肉眼可见地提升。示例是最省事的“需求说明书”。第三个坑是不追问。第一版回答不满意就重问其实更好的做法是基于第一版追问“这里为什么这样写”“能不能改成 X”。追问能让它在你已有的上下文上迭代比从头再来效率高得多。6. 把提问能力沉淀成个人资产用久了你会发现这 7 个模板不只是提问工具更是一套把模糊想法结构化的思维框架。每次套模板的过程其实都是在逼自己把需求想清楚。很多时候模板填到一半我自己就发现问题在哪了根本不用等 Codex 回答。我的建议是先挑最常用的两三个模板练熟比如功能实现型和调试排错型这两个覆盖了日常八成场景。用顺了再扩展到组合写法。另外把你每次觉得“这个回答真好”的提问存下来慢慢就攒出了自己的提问库。这东西和代码片段一样是能复用的资产。最后分享一个我最近在用的扩展思路把模板和项目的实际代码结构结合做成带项目上下文的“专属提问卡”。比如把常用的数据模型、工具函数、错误码都写进提示词这样每次提问它都自带项目背景回答的贴合度又上一个台阶。这个方向我还在摸索等有更成熟的经验再单独写一篇。