1. 为什么“提问”本身需要一张急救卡写了十几年代码我带过的新人没有一百也有八十发现一个特别有意思的规律同样一个报错有人三分钟拿到可用答案有人折腾一下午还在原地打转。差距不在技术底子而在“怎么把问题说清楚”这件事上。Codex 这类 AI 编程助手本质上是一个知识极广但完全没有上下文的搭档你给它的信息越精准它还给你的东西就越接近能直接粘贴进项目的程度。反过来你甩一句“我的代码报错了怎么办”它只能给你一堆正确的废话。所谓“提问急救卡”就是把这套“怎么问”的经验固化成几个可以反复套用的模板。我把它叫急救卡是因为它真正发挥价值的场景往往很急——线上冒烟、构建挂了、临交付前发现一个诡异 bug这时候你根本没心思组织语言掏出模板往里填就行。这篇文章我会把 7 个我实际用得最多的模板拆开讲透再讲怎么把它们组合起来应对复杂场景。适合谁看刚接触 AI 编程助手的新手能直接抄作业用了一段时间但总觉得“AI 答不到点子上”的中级开发者能查漏补缺带团队的人可以拿去做内部规范。先说一个底层认知这也是整张急救卡的设计依据AI 编程助手最缺的不是知识是上下文。它不知道你的运行环境、不知道你的项目结构、不知道你已经试过什么、更不知道你真正想要的是“解释原因”还是“直接给能跑的代码”。提问的本质就是在一两段话里把这些缺失的上下文补齐。7 个模板分别对应 7 类最常见的上下文缺失理解了这一点你甚至能自己造模板。2. 七个常用模板逐个拆解2.1 模板一报错定位型——把“报错”变成“可诊断的问题”最基础的场景也是最多人问得最烂的场景。新手常见问法是“这段代码为什么报错”然后贴一大坨代码。AI 只能靠猜。正确的模板结构是四段式环境 完整报错 最小复现代码 已尝试的动作。我常用的写法是这样的环境Python 3.11 / Windows 11 / 依赖版本见下 报错信息完整堆栈 Traceback (most recent call last): ... 最小复现代码 只保留能触发报错的那几行 我已经试过把 X 改成 Y报错变成 Z查了官方文档关于 A 的说明没找到对应场景。 请帮我定位根因并给出修改后的代码。为什么强调“最小复现代码”因为完整堆栈里 90% 的帧都跟问题无关你贴三百行代码AI 的注意力会被稀释反而容易抓错重点。我实测下来把代码压缩到 10 行以内AI 一次命中根因的概率明显更高。另外“已尝试的动作”这一项特别关键它能防止 AI 给你一个你早就试过的方案浪费一轮对话。注意报错信息一定要贴完整堆栈不要只贴最后一行。很多问题的根因藏在中间某个Caused by里只贴最后一行等于让 AI 盲猜。2.2 模板二代码生成型——把“帮我写个功能”拆成可验收的规格“帮我写一个登录功能”——这种提问拿到的代码基本没法直接用因为 AI 不知道你的技术栈、不知道你的数据库结构、不知道你的鉴权方案。代码生成型模板的核心是把需求写成一份迷你规格说明书包含五个要素输入、输出、约束、技术栈、验收标准。举个例子同样是登录功能我会这样写技术栈Node.js Express PostgreSQL已有 users 表字段id, email, password_hash, created_at 需求实现 POST /api/login 接口 输入JSON body { email, password } 输出成功返回 { token, user: { id, email } }失败返回 401 { error: ... } 约束密码用 bcrypt 校验token 用 jsonwebtoken 签发有效期 2 小时不要引入新的 ORM 验收标准给出接口代码 一段可直接运行的 curl 测试命令这套写法的价值在于它把“模糊的愿望”翻译成了“可验收的交付物”。AI 拿到这种规格产出的代码通常能直接跑你只需要微调。我个人的经验是约束那一栏写得越具体返工越少。比如“不要引入新的 ORM”这一句能省掉你后面删依赖的功夫。2.3 模板三代码解释型——让 AI 当你的“代码翻译官”接手别人的代码、读开源项目、看一段看不懂的算法都需要这个模板。很多人问“这段代码什么意思”得到的回答是把代码逐行翻译成中文毫无营养。真正有用的解释应该包含三层这段代码在做什么意图、为什么这么写设计动机、有什么坑边界条件。我的模板长这样请分三层解释下面这段代码 1. 整体意图它解决什么问题输入输出是什么 2. 关键实现逐段说明核心逻辑重点解释 [某个我不懂的地方] 3. 潜在问题边界条件、性能隐患、可读性问题 代码 贴代码第三层是精华。我踩过好几次坑一段看起来人畜无害的代码AI 指出它在输入为空时会抛异常或者在大数据量下是 O(n²)。这种“主动挑刺”的能力是逐行翻译给不了的。你可以把第三层的要求写得更狠一点比如“假设这段代码要上生产列出所有可能出问题的地方”。2.4 模板四重构优化型——带着“目标”去改而不是“随便看看”“帮我优化一下这段代码”是最容易得到无效回答的提问之一因为“优化”是个没有方向的目标。是优化可读性性能还是减少依赖方向不同改法完全相反。重构优化型模板的关键是先声明优化目标再给约束。优化目标可读性优先性能次要 约束不改变函数签名不引入新依赖保持现有测试全部通过 现状这个函数有 80 行嵌套 4 层我觉得难维护 请给出重构后的版本并说明每一处改动的原因。我特别想强调“说明每一处改动的原因”这句。它逼着 AI 给出可解释的重构而不是甩给你一坨看不懂的新代码。你从中学到的是方法下次自己就能改。另外约束里的“保持测试通过”是个硬指标如果 AI 的重构破坏了测试你能立刻发现。2.5 模板五方案对比型——把选择题交给 AI但你来定标准技术选型是程序员的日常用 Redis 还是本地缓存用 REST 还是 GraphQL这种问题直接问“哪个好”是得不到答案的因为“好”取决于你的场景。方案对比型模板的精髓是让 AI 按你给定的维度做对比表。场景日活 5 万的小型应用团队 3 人运维能力有限 候选方案ARedis、B进程内缓存 请按以下维度对比实现复杂度、运维成本、一致性保证、扩展性、适用边界 最后给出针对我这个场景的推荐并说明理由。这个模板的妙处在于维度是你定的AI 只负责填充。这样得到的对比表直接贴合你的决策需求而不是泛泛而谈。我一般会加一句“如果我的日活涨到 50 万结论会变吗”让 AI 顺带把扩展性也讲清楚。2.6 模板六调试排查型——把“玄学 bug”变成“可验证的假设”有些 bug 特别邪门本地好好的一上测试环境就挂跑一次没事跑十次挂一次。这种问题问 AI如果只是描述现象它会给你一堆“可能的原因”。调试排查型模板的核心是让 AI 帮你生成排查清单和验证方法。现象本地正常测试环境偶发失败频率约 1/10 已知测试环境是容器化部署本地是直接跑 请列出最可能的 5 个原因按可能性排序 对每个原因给出一个具体的验证方法命令或代码“给出验证方法”这一句是灵魂。它把 AI 从“算命先生”变成了“排查助手”。你拿着这份清单一条条验证很快就能缩小范围。我实测下来这种问法比直接问“为什么”效率高得多因为它输出的是可执行的下一步而不是一堆猜测。2.7 模板七学习路径型——让 AI 当你的私人教练想学一个新框架、新语言、新领域直接问“怎么学”得到的往往是网上抄来的大纲。学习路径型模板的关键是告诉 AI 你的起点和目标让它规划一条最短路径。我的起点熟悉 JavaScript没接触过类型系统 我的目标两周内能用 TypeScript 独立写一个小型 CLI 工具 每天可投入1.5 小时 请给出一个按天拆解的学习计划每天包含学习内容、动手练习、验收标准“验收标准”这一栏很重要它让学习变成可量化的进度而不是“感觉学得差不多了”。我按这个模板规划过好几次学习最大的收获是它帮我砍掉了大量无关内容直奔能用的部分。3. 组合写法复杂场景怎么把模板拼起来3.1 为什么单一模板不够用真实工作里的问题很少是纯粹的“报错”或纯粹的“重构”往往是复合的。比如“这段老代码报错了我想顺便重构一下但不确定重构方向对不对”这就同时涉及报错定位、代码解释、重构优化三个模板。这时候如果只用一个模板AI 的回答会顾此失彼。组合写法的思路是按优先级串联模板让 AI 分步骤输出。3.2 串联式组合一步接一步串联式适合有明确先后顺序的场景。比如排查一个性能问题我会这样组合第一步代码解释先解释下面这段代码的整体意图和关键实现 第二步调试排查基于上面的理解列出可能导致响应慢的 5 个原因 第三步重构优化针对最可能的原因给出优化方案约束是不改变对外接口 代码贴代码这种写法的好处是每一步都建立在前一步的输出上AI 的推理链条是连贯的。我实测下来串联式组合得到的答案质量明显高于把三个问题混在一起问。关键技巧是用“第一步/第二步/第三步”明确分节让 AI 知道你要的是分阶段输出而不是一锅烩。3.3 嵌套式组合模板里套模板嵌套式适合需要“先定义再执行”的场景。比如你要 AI 生成一段代码但这段代码涉及一个你不熟悉的算法你可以把“代码解释”嵌套进“代码生成”里请帮我实现 [功能]技术栈 [X] 要求在给出代码之前先用三句话解释你打算用的算法思路 代码写完后单独用一段说明这段代码的边界条件和潜在坑这里的“先解释思路”和“后说明边界”就是嵌套进去的解释型模板。它的价值在于让你在拿到代码的同时理解代码而不是盲目复制。我特别推荐新手用这种写法长期下来你对 AI 产出的信任度和判断力都会提升。3.4 组合写法的三个避坑点组合写法虽然强但有几个坑我踩过。第一别一次串太多步。超过四步AI 容易在中间某步跑偏而且回答会变得很长重点被淹没。我的经验是三步以内最稳。第二每步都要有明确的输出物。比如“列出 5 个原因”“给出修改后的代码”有输出物你才能判断这一步做没做好。第三步与步之间要留出你的判断空间。别让 AI 一口气跑完所有步骤中间停下来看看必要时调整下一步的方向比一次性问完更高效。4. 常见问题与排查技巧实录4.1 AI 答非所问怎么办这是最高频的问题。原因通常有三个上下文给少了、问题太宽泛、或者你问的其实是两个问题。排查顺序是这样的先检查是不是把两个不相关的问题塞进了一段话拆开分别问再检查是不是缺少关键上下文环境、版本、代码补上最后检查问题本身是不是太宽泛用模板把它收窄。我个人的经验是八成“答非所问”都是因为问题太宽泛比如“怎么优化性能”改成“这个函数在 10 万条数据下耗时 3 秒怎么降到 1 秒以内”答案质量立刻不一样。4.2 AI 给的代码跑不起来怎么办先别急着骂 AI按这个清单排查依赖版本对不对、环境变量配了没、代码是不是被截断了、有没有隐藏的假设比如假设某个文件存在。我遇到最多的情况是AI 假设了一个不存在的依赖或字段这时候把报错贴回去加上一句“我这边没有 X请用 Y 替代”通常一轮就能修好。另一个高频原因是代码被输出截断尤其是长函数这时候直接说“代码不完整请从第 X 行继续”。4.3 怎么判断 AI 的回答靠不靠谱这个问题很关键因为 AI 会一本正经地胡说。我的判断标准有三条第一看它有没有解释“为什么”只给结论不给理由的可信度打折第二看它有没有提到边界条件一个成熟的方案一定会谈限制第三小步验证别一次性把 AI 的代码全量替换进项目先在一个隔离环境跑通再说。我踩过的坑里最惨的一次是直接信了 AI 给的“最佳实践”结果那个方案在我的场景下根本不适用因为它默认了一个我根本没有的前提。4.4 提问急救卡速查表场景用哪个模板核心要素最容易漏的一步代码报错报错定位型环境堆栈最小复现已尝试贴完整堆栈写新功能代码生成型输入输出约束技术栈验收写清约束读不懂代码代码解释型意图实现潜在问题要求挑刺想改代码重构优化型目标约束改动说明声明优化方向技术选型方案对比型场景候选对比维度推荐自己定维度诡异 bug调试排查型现象已知原因清单验证方法要验证方法学新东西学习路径型起点目标时间验收标准写验收标准这张表我建议直接存成便签遇到对应场景就掏出来填。用熟之后你会发现提问的质量直接决定了你从 AI 那里拿到的价值而这张卡就是提升提问质量的最短路径。5. 把急救卡变成肌肉记忆模板这东西看一遍记不住用十遍才内化。我自己的做法是前两周每次提问前都对着速查表挑模板填完再发。刚开始会觉得麻烦但大概二十次之后你会发现自己在打字的时候就已经自动按模板的结构组织了根本不用刻意想。到那个阶段你甚至能根据具体场景微调模板比如把报错定位型的“已尝试动作”换成“我怀疑是 X但不确定”引导 AI 往你的假设方向验证。还有一个我个人的小习惯把每次得到高质量回答的提问原样存下来攒成一个自己的模板库。因为不同项目、不同技术栈的提问细节差别很大通用模板只是骨架真正好用的是你根据自己的项目沉淀出来的“血肉版”。我现在的模板库里大概有三十多条覆盖了我常打交道的几个技术栈每次遇到类似问题直接改几个参数就能用效率比现想高太多。最后分享一个判断标准如果你问完一个问题AI 的回答让你觉得“这不就是我自己也能想到的吗”那说明提问没到位上下文给少了或者问题太宽泛。好的提问应该让你有“原来还能这么想”的感觉。这个标准我用了很久帮我不断校准提问的质量。
1. 为什么“提问”本身需要一张急救卡写了十几年代码我带过的新人没有一百也有八十发现一个特别有意思的规律同样一个报错有人三分钟拿到可用答案有人折腾一下午还在原地打转。差距不在技术底子而在“怎么把问题说清楚”这件事上。Codex 这类 AI 编程助手本质上是一个知识极广但完全没有上下文的搭档你给它的信息越精准它还给你的东西就越接近能直接粘贴进项目的程度。反过来你甩一句“我的代码报错了怎么办”它只能给你一堆正确的废话。所谓“提问急救卡”就是把这套“怎么问”的经验固化成几个可以反复套用的模板。我把它叫急救卡是因为它真正发挥价值的场景往往很急——线上冒烟、构建挂了、临交付前发现一个诡异 bug这时候你根本没心思组织语言掏出模板往里填就行。这篇文章我会把 7 个我实际用得最多的模板拆开讲透再讲怎么把它们组合起来应对复杂场景。适合谁看刚接触 AI 编程助手的新手能直接抄作业用了一段时间但总觉得“AI 答不到点子上”的中级开发者能查漏补缺带团队的人可以拿去做内部规范。先说一个底层认知这也是整张急救卡的设计依据AI 编程助手最缺的不是知识是上下文。它不知道你的运行环境、不知道你的项目结构、不知道你已经试过什么、更不知道你真正想要的是“解释原因”还是“直接给能跑的代码”。提问的本质就是在一两段话里把这些缺失的上下文补齐。7 个模板分别对应 7 类最常见的上下文缺失理解了这一点你甚至能自己造模板。2. 七个常用模板逐个拆解2.1 模板一报错定位型——把“报错”变成“可诊断的问题”最基础的场景也是最多人问得最烂的场景。新手常见问法是“这段代码为什么报错”然后贴一大坨代码。AI 只能靠猜。正确的模板结构是四段式环境 完整报错 最小复现代码 已尝试的动作。我常用的写法是这样的环境Python 3.11 / Windows 11 / 依赖版本见下 报错信息完整堆栈 Traceback (most recent call last): ... 最小复现代码 只保留能触发报错的那几行 我已经试过把 X 改成 Y报错变成 Z查了官方文档关于 A 的说明没找到对应场景。 请帮我定位根因并给出修改后的代码。为什么强调“最小复现代码”因为完整堆栈里 90% 的帧都跟问题无关你贴三百行代码AI 的注意力会被稀释反而容易抓错重点。我实测下来把代码压缩到 10 行以内AI 一次命中根因的概率明显更高。另外“已尝试的动作”这一项特别关键它能防止 AI 给你一个你早就试过的方案浪费一轮对话。注意报错信息一定要贴完整堆栈不要只贴最后一行。很多问题的根因藏在中间某个Caused by里只贴最后一行等于让 AI 盲猜。2.2 模板二代码生成型——把“帮我写个功能”拆成可验收的规格“帮我写一个登录功能”——这种提问拿到的代码基本没法直接用因为 AI 不知道你的技术栈、不知道你的数据库结构、不知道你的鉴权方案。代码生成型模板的核心是把需求写成一份迷你规格说明书包含五个要素输入、输出、约束、技术栈、验收标准。举个例子同样是登录功能我会这样写技术栈Node.js Express PostgreSQL已有 users 表字段id, email, password_hash, created_at 需求实现 POST /api/login 接口 输入JSON body { email, password } 输出成功返回 { token, user: { id, email } }失败返回 401 { error: ... } 约束密码用 bcrypt 校验token 用 jsonwebtoken 签发有效期 2 小时不要引入新的 ORM 验收标准给出接口代码 一段可直接运行的 curl 测试命令这套写法的价值在于它把“模糊的愿望”翻译成了“可验收的交付物”。AI 拿到这种规格产出的代码通常能直接跑你只需要微调。我个人的经验是约束那一栏写得越具体返工越少。比如“不要引入新的 ORM”这一句能省掉你后面删依赖的功夫。2.3 模板三代码解释型——让 AI 当你的“代码翻译官”接手别人的代码、读开源项目、看一段看不懂的算法都需要这个模板。很多人问“这段代码什么意思”得到的回答是把代码逐行翻译成中文毫无营养。真正有用的解释应该包含三层这段代码在做什么意图、为什么这么写设计动机、有什么坑边界条件。我的模板长这样请分三层解释下面这段代码 1. 整体意图它解决什么问题输入输出是什么 2. 关键实现逐段说明核心逻辑重点解释 [某个我不懂的地方] 3. 潜在问题边界条件、性能隐患、可读性问题 代码 贴代码第三层是精华。我踩过好几次坑一段看起来人畜无害的代码AI 指出它在输入为空时会抛异常或者在大数据量下是 O(n²)。这种“主动挑刺”的能力是逐行翻译给不了的。你可以把第三层的要求写得更狠一点比如“假设这段代码要上生产列出所有可能出问题的地方”。2.4 模板四重构优化型——带着“目标”去改而不是“随便看看”“帮我优化一下这段代码”是最容易得到无效回答的提问之一因为“优化”是个没有方向的目标。是优化可读性性能还是减少依赖方向不同改法完全相反。重构优化型模板的关键是先声明优化目标再给约束。优化目标可读性优先性能次要 约束不改变函数签名不引入新依赖保持现有测试全部通过 现状这个函数有 80 行嵌套 4 层我觉得难维护 请给出重构后的版本并说明每一处改动的原因。我特别想强调“说明每一处改动的原因”这句。它逼着 AI 给出可解释的重构而不是甩给你一坨看不懂的新代码。你从中学到的是方法下次自己就能改。另外约束里的“保持测试通过”是个硬指标如果 AI 的重构破坏了测试你能立刻发现。2.5 模板五方案对比型——把选择题交给 AI但你来定标准技术选型是程序员的日常用 Redis 还是本地缓存用 REST 还是 GraphQL这种问题直接问“哪个好”是得不到答案的因为“好”取决于你的场景。方案对比型模板的精髓是让 AI 按你给定的维度做对比表。场景日活 5 万的小型应用团队 3 人运维能力有限 候选方案ARedis、B进程内缓存 请按以下维度对比实现复杂度、运维成本、一致性保证、扩展性、适用边界 最后给出针对我这个场景的推荐并说明理由。这个模板的妙处在于维度是你定的AI 只负责填充。这样得到的对比表直接贴合你的决策需求而不是泛泛而谈。我一般会加一句“如果我的日活涨到 50 万结论会变吗”让 AI 顺带把扩展性也讲清楚。2.6 模板六调试排查型——把“玄学 bug”变成“可验证的假设”有些 bug 特别邪门本地好好的一上测试环境就挂跑一次没事跑十次挂一次。这种问题问 AI如果只是描述现象它会给你一堆“可能的原因”。调试排查型模板的核心是让 AI 帮你生成排查清单和验证方法。现象本地正常测试环境偶发失败频率约 1/10 已知测试环境是容器化部署本地是直接跑 请列出最可能的 5 个原因按可能性排序 对每个原因给出一个具体的验证方法命令或代码“给出验证方法”这一句是灵魂。它把 AI 从“算命先生”变成了“排查助手”。你拿着这份清单一条条验证很快就能缩小范围。我实测下来这种问法比直接问“为什么”效率高得多因为它输出的是可执行的下一步而不是一堆猜测。2.7 模板七学习路径型——让 AI 当你的私人教练想学一个新框架、新语言、新领域直接问“怎么学”得到的往往是网上抄来的大纲。学习路径型模板的关键是告诉 AI 你的起点和目标让它规划一条最短路径。我的起点熟悉 JavaScript没接触过类型系统 我的目标两周内能用 TypeScript 独立写一个小型 CLI 工具 每天可投入1.5 小时 请给出一个按天拆解的学习计划每天包含学习内容、动手练习、验收标准“验收标准”这一栏很重要它让学习变成可量化的进度而不是“感觉学得差不多了”。我按这个模板规划过好几次学习最大的收获是它帮我砍掉了大量无关内容直奔能用的部分。3. 组合写法复杂场景怎么把模板拼起来3.1 为什么单一模板不够用真实工作里的问题很少是纯粹的“报错”或纯粹的“重构”往往是复合的。比如“这段老代码报错了我想顺便重构一下但不确定重构方向对不对”这就同时涉及报错定位、代码解释、重构优化三个模板。这时候如果只用一个模板AI 的回答会顾此失彼。组合写法的思路是按优先级串联模板让 AI 分步骤输出。3.2 串联式组合一步接一步串联式适合有明确先后顺序的场景。比如排查一个性能问题我会这样组合第一步代码解释先解释下面这段代码的整体意图和关键实现 第二步调试排查基于上面的理解列出可能导致响应慢的 5 个原因 第三步重构优化针对最可能的原因给出优化方案约束是不改变对外接口 代码贴代码这种写法的好处是每一步都建立在前一步的输出上AI 的推理链条是连贯的。我实测下来串联式组合得到的答案质量明显高于把三个问题混在一起问。关键技巧是用“第一步/第二步/第三步”明确分节让 AI 知道你要的是分阶段输出而不是一锅烩。3.3 嵌套式组合模板里套模板嵌套式适合需要“先定义再执行”的场景。比如你要 AI 生成一段代码但这段代码涉及一个你不熟悉的算法你可以把“代码解释”嵌套进“代码生成”里请帮我实现 [功能]技术栈 [X] 要求在给出代码之前先用三句话解释你打算用的算法思路 代码写完后单独用一段说明这段代码的边界条件和潜在坑这里的“先解释思路”和“后说明边界”就是嵌套进去的解释型模板。它的价值在于让你在拿到代码的同时理解代码而不是盲目复制。我特别推荐新手用这种写法长期下来你对 AI 产出的信任度和判断力都会提升。3.4 组合写法的三个避坑点组合写法虽然强但有几个坑我踩过。第一别一次串太多步。超过四步AI 容易在中间某步跑偏而且回答会变得很长重点被淹没。我的经验是三步以内最稳。第二每步都要有明确的输出物。比如“列出 5 个原因”“给出修改后的代码”有输出物你才能判断这一步做没做好。第三步与步之间要留出你的判断空间。别让 AI 一口气跑完所有步骤中间停下来看看必要时调整下一步的方向比一次性问完更高效。4. 常见问题与排查技巧实录4.1 AI 答非所问怎么办这是最高频的问题。原因通常有三个上下文给少了、问题太宽泛、或者你问的其实是两个问题。排查顺序是这样的先检查是不是把两个不相关的问题塞进了一段话拆开分别问再检查是不是缺少关键上下文环境、版本、代码补上最后检查问题本身是不是太宽泛用模板把它收窄。我个人的经验是八成“答非所问”都是因为问题太宽泛比如“怎么优化性能”改成“这个函数在 10 万条数据下耗时 3 秒怎么降到 1 秒以内”答案质量立刻不一样。4.2 AI 给的代码跑不起来怎么办先别急着骂 AI按这个清单排查依赖版本对不对、环境变量配了没、代码是不是被截断了、有没有隐藏的假设比如假设某个文件存在。我遇到最多的情况是AI 假设了一个不存在的依赖或字段这时候把报错贴回去加上一句“我这边没有 X请用 Y 替代”通常一轮就能修好。另一个高频原因是代码被输出截断尤其是长函数这时候直接说“代码不完整请从第 X 行继续”。4.3 怎么判断 AI 的回答靠不靠谱这个问题很关键因为 AI 会一本正经地胡说。我的判断标准有三条第一看它有没有解释“为什么”只给结论不给理由的可信度打折第二看它有没有提到边界条件一个成熟的方案一定会谈限制第三小步验证别一次性把 AI 的代码全量替换进项目先在一个隔离环境跑通再说。我踩过的坑里最惨的一次是直接信了 AI 给的“最佳实践”结果那个方案在我的场景下根本不适用因为它默认了一个我根本没有的前提。4.4 提问急救卡速查表场景用哪个模板核心要素最容易漏的一步代码报错报错定位型环境堆栈最小复现已尝试贴完整堆栈写新功能代码生成型输入输出约束技术栈验收写清约束读不懂代码代码解释型意图实现潜在问题要求挑刺想改代码重构优化型目标约束改动说明声明优化方向技术选型方案对比型场景候选对比维度推荐自己定维度诡异 bug调试排查型现象已知原因清单验证方法要验证方法学新东西学习路径型起点目标时间验收标准写验收标准这张表我建议直接存成便签遇到对应场景就掏出来填。用熟之后你会发现提问的质量直接决定了你从 AI 那里拿到的价值而这张卡就是提升提问质量的最短路径。5. 把急救卡变成肌肉记忆模板这东西看一遍记不住用十遍才内化。我自己的做法是前两周每次提问前都对着速查表挑模板填完再发。刚开始会觉得麻烦但大概二十次之后你会发现自己在打字的时候就已经自动按模板的结构组织了根本不用刻意想。到那个阶段你甚至能根据具体场景微调模板比如把报错定位型的“已尝试动作”换成“我怀疑是 X但不确定”引导 AI 往你的假设方向验证。还有一个我个人的小习惯把每次得到高质量回答的提问原样存下来攒成一个自己的模板库。因为不同项目、不同技术栈的提问细节差别很大通用模板只是骨架真正好用的是你根据自己的项目沉淀出来的“血肉版”。我现在的模板库里大概有三十多条覆盖了我常打交道的几个技术栈每次遇到类似问题直接改几个参数就能用效率比现想高太多。最后分享一个判断标准如果你问完一个问题AI 的回答让你觉得“这不就是我自己也能想到的吗”那说明提问没到位上下文给少了或者问题太宽泛。好的提问应该让你有“原来还能这么想”的感觉。这个标准我用了很久帮我不断校准提问的质量。
分析器构建闭环训练：从文法改写到Python实现)
![[从入门到入土!!!] Ubuntu20.04 系统开发环境配置（系统配置，显卡驱动，CUDA，ROS，VSCode，Anaconda等）](http://pic.xiahunao.cn/yaotu/[从入门到入土!!!] Ubuntu20.04 系统开发环境配置（系统配置，显卡驱动，CUDA，ROS，VSCode，Anaconda等）)
