AI编程助手提问模板：7个高频场景急救卡

1. 为什么“会提问”成了程序员的新硬通货

写代码这件事，过去拼的是谁记得住 API、谁敲得快。现在环境变了，AI 编程助手已经能补全整段逻辑、解释报错、甚至重构模块。可我发现一个很反直觉的现象：身边同样用 Codex 类工具的同事，产出效率能差出三倍。差距不在打字速度，也不在算法功底，而在提问的质量。

我见过太多人对着对话框敲一句“这段代码有问题，帮我看看”，然后贴上一大坨没有上下文的代码，接着抱怨“AI 也就那样”。也见过有人三句话就让助手精准定位到并发死锁的根因。前者把 AI 当搜索引擎用，后者把 AI 当结对搭档用。这两种用法的分水岭，就是提问模板。

这篇内容就是把我自己这两年攒下来的提问套路整理成一张“急救卡”。所谓急救卡，意思是当你卡住、报错、思路断掉、代码跑不通的时候，能立刻翻出来照着填的模板。它不教你 AI 原理，也不吹工具多神，只解决一件事：怎么把脑子里的模糊问题，翻译成 AI 能精准接住的输入。

适合谁看？如果你已经在用 Codex 类助手写代码，但总觉得“它给的答案差点意思”，这篇就是给你写的。如果你还没用过，也可以先看看提问的骨架长什么样，等上手时直接套。全文会给出 7 个高频场景的模板，再讲怎么把模板组合起来应对复杂任务，最后分享几个我踩过的坑。

提示：模板不是咒语，填空之前先想清楚“我到底要什么”。模板的价值在于强制你把背景、目标、约束三件事说全，而不是替你思考。

2. 提问模板的底层逻辑：把 AI 当新同事而不是许愿池

2.1 信息不对称才是答非所问的根源

先想一个场景。你新来一个同事，你丢给他一句“这个接口报错了，你修一下”，他大概率一脸茫然。他不知道这个接口在哪个模块、调用链多长、报错信息是什么、你期望的返回格式是什么。AI 面对的情况一模一样，甚至更糟——它看不到你的屏幕，看不到你的运行环境，只能靠你给的文字重建现场。

所以提问模板的第一性原理，是消除信息不对称。一个合格的提问至少要让对方知道四件事：当前状态是什么、期望状态是什么、中间卡在哪、有哪些不能碰的约束。这四件事对应到代码场景，就是代码片段、报错日志、目标行为、技术栈与限制。

我早期也犯过“许愿池式提问”的毛病，比如“帮我优化一下这个函数”。AI 会给你一堆泛泛的建议，什么“减少循环嵌套”“使用缓存”，听起来都对，但用不上。后来我改成“这个函数在数据量到十万条时耗时 3 秒，目标是压到 500 毫秒以内，当前用的是嵌套遍历，不能引入新依赖”，回答立刻变得具体，甚至直接给出了用哈希表降复杂度的改法。

2.2 模板的四个固定槽位

我把所有好用的提问归纳成四个槽位，你可以理解成填空题的四个空：

这四个槽位不是每问必填，但缺得越多，返工概率越高。急救卡里的 7 个模板，本质上就是这四个槽位在不同场景下的排列组合。理解了这一点，你甚至可以不背模板，现场拼。

2.3 为什么是 7 个而不是 20 个

有人会问，场景那么多，7 个够吗？我的经验是，日常开发中真正高频的提问场景就那么几类：看不懂的代码、跑不通的报错、写不出的逻辑、改不动的性能、理不清的架构、写不全的测试、读不懂的文档。这七类覆盖了八成以上的卡点。剩下的长尾场景，用这七个模板组合一下基本都能应付。

贪多嚼不烂。我试过整理三十多个模板，结果自己都记不住，最后还是回到这七个。模板的价值在于肌肉记忆，卡住的时候不用翻笔记就能想起来，这才叫急救卡。

3. 七个高频场景的提问模板逐条拆解

3.1 模板一：代码解释——从“看不懂”到“讲明白”

场景：接手一段祖传代码，或者看到同事写的复杂逻辑，完全不知道在干嘛。

模板骨架：

请解释下面这段代码的功能。 背景：这是 [语言/框架] 写的 [模块名]，用于 [业务目的]。 代码： [粘贴代码] 请按以下结构回答： 1. 整体功能一句话概括 2. 逐行或逐块说明关键逻辑 3. 指出可能的副作用或边界情况

这个模板的关键在最后一句。如果你只说“解释一下”，AI 可能给你一段泛泛的概述。指定结构之后，它会老老实实分层拆解。我特别看重第三点“副作用和边界情况”，因为祖传代码的坑往往就藏在这里。有一次我让助手解释一段日期处理逻辑，它在边界情况里指出“当输入为月末最后一天时，月份加一会跳到下下个月”，这个坑我肉眼扫了三遍都没发现。

注意：粘贴代码时把敏感信息（密钥、真实用户数据、内部地址）替换掉。这不是不信任工具，是基本的职业习惯。

3.2 模板二：报错诊断——别只贴一行错误信息

场景：程序崩了，控制台一片红，你不知道从哪下手。

模板骨架：

我遇到一个报错，请帮我定位原因并给出修复方案。 环境：[语言版本、框架版本、操作系统] 报错信息： [完整堆栈] 相关代码： [触发报错的代码片段] 我已经尝试过：[列出你试过的方案]

这个模板里最容易被忽略的是“我已经尝试过”。很多人觉得这行可有可无，其实它极其重要。它告诉 AI 哪些方向已经排除了，避免它重复给你“你重启一下试试”这种废话。同时它也能暴露你的排查思路，如果思路本身错了，AI 会顺带纠正。

还有一个细节：报错信息要贴完整堆栈，不要只贴最后一行。最后一行往往只是表象，真正的根因在堆栈中段。我见过有人只贴“NullPointerException”，然后问怎么修，这种提问神仙也救不了。

3.3 模板三：逻辑生成——把需求翻译成可运行代码

场景：知道要做什么，但不知道怎么写，或者懒得从零敲。

模板骨架：

请帮我实现一个 [功能描述]。 输入：[输入的数据结构或参数] 输出：[期望的返回格式] 约束：[性能要求、依赖限制、代码风格] 请给出完整可运行的代码，并附上关键步骤注释。

这个模板的难点在“输入输出”要写清楚。很多人描述需求时用的是自然语言，比如“帮我写个函数处理用户列表”，这太模糊了。用户列表是什么结构？处理是排序、过滤还是聚合？返回什么？把这些写清楚，AI 一次就能给对。

我个人的习惯是，如果输入输出比较复杂，直接给一个示例。比如“输入是[{id:1,name:'a'},{id:2,name:'b'}]，输出是{1:'a',2:'b'}”，比任何文字描述都直观。示例就是最好的规格说明。

3.4 模板四：性能优化——先量化再动手

场景：代码能跑，但慢得让人想砸键盘。

模板骨架：

下面这段代码在 [数据规模/并发量] 下耗时 [具体数值]，目标是降到 [目标数值]。 当前实现： [粘贴代码] 运行环境：[硬件、语言版本] 约束：[不能引入新依赖 / 不能改变对外接口 / 内存上限] 请分析瓶颈并给出优化方案，说明每项改动的预期收益。

性能优化最忌讳“凭感觉”。你说“太慢了”，AI 只能猜。你说“十万条数据耗时 3 秒”，它就能算出复杂度，判断瓶颈在算法还是 IO。加上“说明预期收益”这一句，能逼着 AI 给出可验证的方案，而不是一堆“可以试试”的模糊建议。

我踩过的一个坑是：没写约束就让它优化，结果它建议我引入一个第三方缓存库。方案本身没错，但我们的项目规定不能随便加依赖，白高兴一场。后来我养成习惯，约束条件永远写在前面。

3.5 模板五：架构梳理——让 AI 帮你画脑图

场景：面对一个陌生模块，想快速搞清它的结构和依赖关系。

模板骨架：

请帮我梳理下面这个模块的架构。 模块职责：[一句话描述] 涉及文件/类： [列出关键文件或类名，可附简要代码] 请输出： 1. 模块的核心职责与边界 2. 主要组件及其关系 3. 数据流向 4. 潜在的耦合点或设计问题

这个模板适合在接手新项目或者做重构前使用。把关键文件列出来，AI 能帮你还原出一张逻辑上的结构图。虽然它画不出真正的图，但用文字描述组件关系，效果一样清楚。

第四点“潜在耦合点”是我最看重的。AI 在找循环依赖、职责不清这类问题上，比人眼快得多。有一次它指出两个类互相引用，建议抽出一个中间层，我照着改完，单元测试都好写了不少。

3.6 模板六：测试用例——把边界条件交给 AI 想

场景：功能写完了，要补测试，但想不全边界情况。

模板骨架：

请为下面的函数生成单元测试。 函数代码： [粘贴代码] 测试框架：[JUnit / pytest / Jest 等] 请覆盖： 1. 正常输入 2. 边界值 3. 异常输入 4. 你认为容易被忽略的特殊情况

第四点是精髓。人写测试容易陷入“ happy path ”思维，只测正常流程。AI 在列举异常和边界方面往往更全面，因为它没有“这段代码肯定没问题”的预设。我经常让它先列测试点，我再筛选，比我自己从零想快得多。

提示：AI 生成的测试不要直接合并，先跑一遍。它有时会假设一些不存在的函数或错误的返回值，需要你手动修正。

3.7 模板七：文档解读——把官方文档嚼碎

场景：读英文文档或者晦涩的 API 说明，抓不住重点。

模板骨架：

请帮我解读下面这段文档。 文档内容： [粘贴文档片段] 我的使用场景：[描述你要做什么] 请回答： 1. 这段文档的核心结论 2. 与我的场景相关的部分 3. 容易误解的地方 4. 一个最小可运行示例

这个模板解决的是“文档读了但没懂”的问题。官方文档往往写得很全但很散，AI 能帮你提炼出跟你场景相关的那一小块。第四点“最小示例”尤其有用，看完示例再回头看文档，很多概念一下就通了。

4. 组合写法：复杂任务怎么把模板串起来

4.1 单模板的边界在哪里

七个模板各自解决一类问题，但真实开发中的卡点往往是复合的。比如你接手一个慢接口，既要看懂它、又要优化它、还要补测试。这时候单模板就不够用了，需要组合。

组合的核心思路是分阶段提问，而不是把所有需求塞进一段话。我见过有人一口气写五百字，把解释、优化、测试全塞进去，结果 AI 顾此失彼，每样都答得浅。正确的做法是拆成几轮，每轮聚焦一个目标，上一轮的输出作为下一轮的输入。

4.2 串联式组合：解释 → 优化 → 测试

这是最常用的组合链路。以优化一个慢函数为例：

第一轮用模板一，让它解释代码功能，确认你理解的和它理解的一致。第二轮用模板四，把第一轮确认的功能描述作为背景，提出优化目标。第三轮用模板六，把优化后的代码丢进去生成测试。

这样串下来的好处是，每一轮都有明确的输入和输出，AI 不会跑偏。而且中间你可以随时纠偏，比如第一轮发现它理解错了，立刻补充说明再继续，避免错误累积。

4.3 并联式组合：同时要多个方案再对比

有时候你不需要 AI 给一个答案，而是想要几个不同思路供你选。这时候可以用并联式提问：

请针对 [问题] 给出三种不同思路的方案。 方案一偏向 [方向A]，方案二偏向 [方向B]，方案三偏向 [方向C]。 请分别说明每种方案的适用场景、优缺点和实现复杂度。

这种问法适合做技术选型。比如“实现一个本地缓存”，你可以让它分别给出基于字典、基于 LRU、基于文件三种方案，然后自己权衡。AI 不会替你决策，但能把选项摆清楚，这已经省了很多查资料的时间。

4.4 组合时的上下文管理技巧

组合提问最大的坑是上下文丢失。多轮对话之后，AI 可能忘了前面的约束。我的做法是，每轮开头用一句话复述关键背景，比如“接着上面那个不能引入新依赖的优化任务”。这一句话成本很低，但能显著降低跑偏概率。

另外，如果对话太长，我会主动开新会话，把必要的背景重新贴一遍。别指望 AI 记住几十轮之前的所有细节，它记不住，你也不该指望。

5. 实测中那些让回答质量翻倍的细节

5.1 给代码加“路标”比贴全量代码更有效

很多人喜欢把整个文件贴进去，觉得信息越全越好。实测下来，这反而稀释了重点。AI 的注意力是有限的，无关代码越多，它越容易抓错重点。

我的做法是给代码加“路标”：在关键行上面加注释，标明“这里是瓶颈”“这里可能为空”“这里的类型不确定”。这些注释就像给 AI 画了重点线，它会优先关注你标记的地方。有一次我贴了两百行代码，只在可疑的那一行加了句“这里并发访问可能有问题”，AI 直接锁定那一行给出了加锁方案，其他代码它扫一眼就过了。

5.2 用“反例”代替“正例”描述需求

描述需求时，给正例是常规操作，但给反例往往更有效。比如你要一个格式化函数，与其说“把日期格式化成 YYYY-MM-DD”，不如补一句“不要输出类似 2024-1-1 这种缺零的格式”。反例能精准排除你不想要的结果，比反复强调你要什么更省事。

这个技巧在处理模糊需求时特别好用。因为“我想要什么”有时候你自己都说不清，但“我不要什么”通常很明确。把不要的列出来，剩下的空间就小了，AI 猜中的概率就高了。

5.3 指定角色和视角能改变回答风格

同一个问题，你让 AI 以“资深架构师”的身份回答，和以“刚入行的开发者”身份回答，内容深度完全不同。我常用的角色设定有这么几个：

角色设定不用太花哨，一句话就够。但加上之后，回答的“人设”会明显不同，你可以按需切换。

5.4 让 AI 先提问再回答

这是个反直觉但极其好用的技巧。当你自己都说不清需求时，可以这样问：

我想实现 [模糊目标]，但不确定细节。 请先向我提三个最关键的问题，帮我理清需求，然后再给方案。

AI 提的问题往往能戳中你没想清楚的地方。回答完它的问题，需求自然就清晰了。这个技巧我称之为“反向提问”，特别适合项目启动阶段。

6. 我踩过的坑和对应的修正方案

6.1 坑一：把 AI 当搜索引擎，问“XX 怎么用”

早期我经常问“某个库怎么用”，然后得到一段官方文档的复述。后来我意识到，这类问题应该问搜索引擎或查文档，AI 的价值不在复述已知信息，而在处理你的具体问题。

修正方案：把“XX 怎么用”改成“我要用 XX 实现 YY，当前遇到 ZZ 问题”。带上你的场景，回答才有针对性。

6.2 坑二：一次问太多，回答全是浅尝辄止

我试过一段话里塞五个问题，结果每个都只答了两句。AI 的单次回答长度有限，问题越多，每个分到的篇幅越少。

修正方案：一轮一个核心问题。如果确实有多个问题，拆成多轮，或者明确说“请重点回答第一个问题，其余简要带过”。

6.3 坑三：不验证就复制粘贴

这个坑最危险。AI 给的代码看起来头头是道，跑起来直接报错，甚至逻辑是错的。我有次偷懒直接复制了一段排序逻辑，结果边界条件处理反了，测试才发现。

修正方案：把 AI 的输出当“草稿”而不是“成品”。关键逻辑自己过一遍，跑一遍测试。尤其是涉及金额、权限、并发的地方，必须人工复核。

6.4 坑四：上下文太长导致“失忆”

对话超过一定轮数后，AI 开始忘记前面的约束，甚至自相矛盾。这不是它故意的，是上下文窗口的物理限制。

修正方案：长任务定期开新会话，把关键背景浓缩成几句话重新贴。或者把重要约束写在每轮提问的开头，反复强化。

6.5 坑五：提问里带情绪，浪费字数

“这代码谁写的太烂了”“烦死了又报错”，这类情绪化表达对解决问题毫无帮助，还占用了宝贵的提问篇幅。

修正方案：提问只保留事实和需求。情绪留给同事吐槽，别留给 AI。

7. 把急救卡变成肌肉记忆的练习方法

模板看一遍记不住，得练。我的方法是刻意练习加复盘。每次用 AI 解决完一个问题，回头看一眼自己的提问，问自己三个问题：背景说清了吗？目标明确吗？约束漏了吗？坚持两周，提问质量会有肉眼可见的提升。

另一个方法是收集好问题。看到别人问得漂亮的，截图存下来，分析它好在哪里。我有个笔记专门存这类“提问范本”，现在攒了三十多条，卡住的时候翻一翻，经常能找到灵感。

最后说个心态问题。别指望一个模板解决所有问题，也别因为一次回答不好就否定工具。提问是双向的，你给的信息越精准，它回馈的价值越高。这套急救卡不是终点，是起点，用着用着你会长出适合自己的变体。

我在实际使用中最大的体会是：提问能力本质上就是拆解问题的能力。你能把问题拆清楚，AI 就能接得住；你拆不清楚，换什么工具都白搭。所以练提问，练的其实是自己的思维。