1. 为什么需要一张“提问急救卡”写代码这件事卡住的时候往往不是不会写而是不知道该问什么。我见过太多同行包括我自己早期遇到报错就把整段代码甩进对话框配一句“这为啥报错”然后等一个不知道能不能用的答案。结果要么对方回一句“信息不够”要么给出一段看似合理但跑不通的代码来回拉扯半小时问题还在原地。Codex 类工具本质上是一个“按你给的上下文推理”的系统。它不会读心也不会主动去翻你的项目结构。你给它的信息越模糊它只能靠猜猜错了你就得花更多轮对话去纠正。所以真正决定效率的不是模型多强而是你怎么问。这张“提问急救卡”就是解决这个问题的。它是一套可以随身带着用的提问模板覆盖了日常开发里最高频的 7 种场景报错排查、代码解释、重构建议、补测试、写正则、性能优化、跨语言翻译。每个模板都规定了“必须给什么信息、按什么顺序给、要它输出什么格式”。再配合组合写法把两三个模板叠在一起用就能应付绝大多数复杂需求。适合谁来参考如果你是刚接触 AI 辅助编程的新手这套模板能帮你少走很多弯路避免“问了等于没问”如果你已经用了一段时间但总觉得回答质量忽高忽低那问题多半出在提问结构上这套东西能帮你把输出稳定下来。下面我按“设计思路—模板拆解—组合写法—排查技巧”的顺序把这张卡完整拆开讲。2. 整体设计思路把提问当成一次接口调用2.1 提问的本质是构造上下文我习惯把每一次提问看成一次函数调用。你传进去的参数决定了返回值的质量。参数太少函数只能返回默认值或者抛异常参数结构清晰返回值才稳定可控。一个高质量的提问通常包含四个部分角色设定、任务描述、上下文材料、输出约束。角色设定告诉它“你现在是谁”比如“你是一个熟悉 Python 异步编程的资深工程师”任务描述说清楚“要干什么”比如“帮我找出这段代码里的竞态条件”上下文材料是代码、报错、环境信息输出约束则是“用表格列出来”“只给修改后的代码不要解释”。很多人只给了任务描述其余三块全缺。这就好比调用一个函数只传了一个参数剩下的全靠默认值结果自然不可控。2.2 为什么是这 7 个模板这 7 个模板不是拍脑袋定的是我统计了自己和身边同行过去半年里高频提问类型之后归纳出来的。排在前面的分别是看不懂报错、看不懂别人写的代码、想重构但怕改坏、不想手写测试、正则写不出来、跑得太慢、要把一段逻辑换语言实现。这七类基本覆盖了日常开发 80% 以上的求助场景。每个模板的设计都遵循一个原则把“它需要猜的东西”降到最低。比如报错模板里强制要求贴完整堆栈和最小复现代码就是为了避免它去猜你的运行环境重构模板里要求先说明“不能改变的外部行为”就是为了防止它顺手把你的接口签名改了。2.3 模板不是死规矩是骨架需要强调一点模板是骨架不是镣铐。真正用起来的时候你完全可以根据情况增减。比如一个特别简单的报错可能不需要贴完整项目结构一个复杂的性能问题可能要在模板基础上再加一段压测数据。模板的价值在于给你一个“不会漏掉关键信息”的检查清单而不是让你机械填空。我自己的习惯是先把模板背个大概用熟之后就不再逐字对照而是形成条件反射一遇到报错手就自动去复制堆栈、圈出出错行、写一句预期行为。这个反射建立起来之后提问效率会有质的提升。3. 七个常用模板逐个拆解3.1 模板一报错排查模板这是使用频率最高的一个。核心结构是“环境 报错 最小复现 预期行为”。【环境】语言/框架版本、操作系统、依赖版本 【报错】完整堆栈信息不要截断 【最小复现】能触发该报错的最短代码 【预期行为】我原本希望它做什么 【已尝试】我已经试过哪些方法结果如何为什么要求“最小复现”因为完整项目里往往有几十个文件模型很难判断哪一行才是关键。你把范围缩到最小它就能精准定位。我试过同一个报错贴整个文件时它给了五个可能原因贴最小复现后它直接指出是某个库的版本不兼容。“已尝试”这一栏也特别重要。它能避免模型重复推荐你已经试过的方法也能让它在你失败的方向上换思路。实测下来加上这一栏之后有效回答的比例明显上升。注意堆栈信息一定要贴全尤其是最底部的Caused by部分。很多人只贴第一行结果模型只能给出泛泛的猜测。3.2 模板二代码解释模板接手老项目或者读开源代码时特别有用。结构是“代码 关注点 输出格式”。【代码】需要解释的代码段 【背景】这段代码在项目里大概负责什么 【关注点】我最想搞懂的是哪部分如这个装饰器的作用、这个状态机怎么流转 【输出格式】按执行顺序逐段解释每段配一句“它在干什么”关键在于“关注点”。如果你只说“解释这段代码”它可能从第一行变量声明开始讲讲了一堆你早就懂的东西。你明确说“我只关心这个回调为什么是异步的”它就会把火力集中在那里。我个人的经验是解释模板配合“让它画一个执行顺序的文字版”效果很好。虽然不能用图表但让它用编号列表把调用顺序列出来理解起来比纯文字快得多。3.3 模板三重构建议模板重构最怕的是改出 bug。所以这个模板的核心是“约束边界”。【现状】当前代码 我觉得哪里不好如嵌套太深、重复逻辑多 【约束】不能改变的外部行为如函数签名不变、返回结构不变 【目标】希望达到的效果如降低圈复杂度、提取公共函数 【输出】给出重构后代码 改动点说明 潜在风险提示“约束”这一栏是灵魂。你不说清楚它可能为了“优雅”把你的同步函数改成异步或者把返回值从列表改成生成器调用方直接崩掉。我踩过这个坑后来每次都把“不能动的东西”写在最前面。“潜在风险提示”也很有价值。好的重构建议会告诉你“这个改动在并发场景下需要额外注意”而不是只给你一段漂亮代码就完事。3.4 模板四补测试模板写测试枯燥但必要。这个模板帮你把这件事变得省力。【被测代码】需要测试的函数或类 【测试框架】用的什么如 pytest、jest 【覆盖要求】需要覆盖哪些分支正常、边界、异常 【输出】可直接运行的测试代码 每个用例的意图说明“覆盖要求”决定了测试的完整度。你只说“写测试”它可能只给一个正常路径的用例。你明确要求“边界值和异常输入都要覆盖”它才会把空值、超长输入、类型错误这些情况考虑进去。我通常还会加一句“用参数化方式组织用例”这样生成的测试更简洁后续加 case 也方便。3.5 模板五正则表达式模板正则这东西写出来容易写对难。模板结构是“样本 规则 边界”。【样本】需要匹配的字符串示例至少给 3 个正例和 3 个反例 【规则】用自然语言描述匹配规则 【边界】哪些情况不应该匹配 【输出】正则表达式 逐段解释 测试用例给正例和反例是关键。只给正例它可能写出一个“能匹配但也会误伤”的表达式。我试过匹配日志时间戳只给正例时它给的正则会把版本号也匹配进去补了反例之后立刻就修正了。“逐段解释”能帮你验证它是不是真的理解了你的规则而不是碰巧凑出一个能跑的表达式。3.6 模板六性能优化模板性能问题最忌讳瞎猜。这个模板要求先量化。【现象】慢在哪里有多慢如这个接口 P99 是 800ms 【代码】相关代码段 【数据规模】输入数据量级如单次处理 10 万条记录 【已定位】是否已经用工具定位到热点 【约束】不能引入哪些新依赖、不能改变哪些行为 【输出】优化方案 预期收益 代价分析“数据规模”经常被忽略但它直接影响方案选择。处理一千条和处理一百万条优化手段完全不同。你不说规模它可能给你一个在小数据量下更快、在大数据量下反而更慢的方案。“代价分析”是我特别看重的一栏。任何优化都有代价可能是内存换时间可能是代码复杂度上升。让它把代价说清楚你才能做取舍。3.7 模板七跨语言翻译模板把一段逻辑从一种语言搬到另一种语言时用。【源语言】如 Python 【目标语言】如 Go 【源代码】需要翻译的代码 【保留点】哪些习惯要保留如错误处理风格、命名规范 【注意】目标语言里需要特别处理的点如并发模型差异 【输出】翻译后代码 差异说明“保留点”和“注意”是精髓。不同语言的惯用法差别很大直译往往写出“用 Python 思维写的 Go 代码”。你明确说“按目标语言的惯用写法来”它才会用地道的写法实现。我一般还会要求它“指出源语言里哪些写法在目标语言中不推荐”这能帮我顺便学到目标语言的最佳实践。4. 组合写法把模板叠起来用4.1 为什么需要组合真实场景很少只涉及单一需求。比如你遇到一个报错排查完发现是性能问题优化完又想补个测试防止回归。这时候单个模板就不够用了需要把几个模板按顺序组合起来。组合的核心逻辑是前一个模板的输出作为后一个模板的输入。这样每一轮对话都有明确的产出不会发散。4.2 三种高频组合套路第一种是“排查 重构”。先用报错模板定位问题确认是代码结构导致的再切到重构模板把“约束”设为“修复该报错的同时不改变其他行为”。这样一轮下来问题解决了代码也顺带优化了。第二种是“解释 补测试”。读不懂的代码先解释清楚理解之后立刻让它基于解释生成测试。因为解释过程中它已经理解了代码意图生成的测试会更贴合真实逻辑而不是只覆盖表面分支。第三种是“性能 翻译”。一段慢代码优化完如果打算迁移到别的语言可以直接接翻译模板把优化后的版本作为源材料。这样迁移过去的就是优化后的逻辑而不是把老问题一起搬过去。4.3 组合时的衔接话术组合的关键在于衔接。不要重新开一段对话而是在同一轮里说“基于上面的分析接下来……”。这样模型能保留前面的上下文不用你重复贴代码。我常用的衔接句式是“基于你刚才定位到的这个热点现在帮我按目标语言的惯用写法重写注意保留原有的错误处理逻辑。”一句话就把上下文和约束都带上了。提示组合模板时轮次不要太多。一般两到三个模板叠加就够了超过三个容易让上下文变得混乱模型反而抓不住重点。5. 常见问题与排查技巧实录5.1 回答质量忽高忽低怎么办最常见的原因是上下文不一致。同一段代码你第一次贴了完整文件第二次只贴了片段模型的理解就会漂移。解决办法是在同一轮对话里保持材料一致需要补充信息时用“补充”而不是“重新开始”。另一个原因是提问里混入了太多无关信息。比如你问一个报错却把整个项目的目录结构都贴上去模型可能被无关文件干扰。这时候要果断做减法只留最小必要信息。5.2 它给的代码跑不通怎么排查先看它有没有遵守你的“约束”。很多时候跑不通是因为它悄悄改了函数签名或者依赖版本。其次看它假设的环境和你的是否一致比如它默认用了某个新版本才有的语法。我的习惯是拿到代码后先不急着跑而是快速扫一遍它有没有引入新依赖、有没有改动接口。确认这两点没问题再放进项目里测试。5.3 常见问题速查表问题现象可能原因处理方式回答很泛没重点缺少关注点或输出约束补上“我最关心的是……”和输出格式代码跑不通约束没写清它改了接口把“不能改变的行为”写在最前面反复推荐已试过的方法没写“已尝试”补上已尝试列表和结果测试覆盖不全没写覆盖要求明确要求正常、边界、异常都覆盖正则误匹配只给了正例补上反例和边界说明优化方案不适用没给数据规模补上输入量级和已定位信息翻译不地道没写保留点和注意事项明确要求按目标语言惯用法5.4 几个我踩过的坑第一个坑是“一次问太多”。我曾经在一个提问里同时要求排查报错、重构、补测试、写文档结果它每样都只做了一半。后来我改成一次只聚焦一个主任务用组合写法分轮推进质量立刻上来了。第二个坑是“不给反例”。写正则和写校验逻辑时只给正例几乎必然导致误匹配。现在我养成了习惯任何匹配类需求都至少给三个反例。第三个坑是“忽略版本”。同一个库不同版本行为可能完全不同。现在我每次都会在环境里写清楚版本号省去了大量“在我这能跑”的扯皮。6. 把急救卡变成肌肉记忆这套模板用熟之后你会发现提问这件事变得像呼吸一样自然。遇到问题脑子里自动就弹出对应的结构报错先贴堆栈和最小复现重构先说约束性能先给数据规模。整个过程不需要刻意回忆模板因为结构已经内化了。我个人的体会是提问能力的提升本质上是对“自己到底卡在哪”这件事的认知提升。很多时候你以为自己不会问其实是没想清楚问题出在哪。模板强迫你把问题拆开、把信息补齐这个过程本身就在帮你理清思路。最后分享一个小技巧把你最常用的两三个模板存成代码片段或者输入法快捷短语需要的时候一键调出只改中间的具体内容。这个动作能再省下不少时间尤其是报错排查这种高频场景效果立竿见影。