写完一篇文章发给 AI帮我看看。代码运行不符合预期贴过去这段代码有什么问题程序突然报错截取最后一行怎么解决这些问法并非完全不能用但很容易遇到一种情况AI 回答了很多却没有解决你最关心的问题。你想知道文章里的技术解释有没有错误它却帮你调整了措辞你想定位接口为什么返回空数据它却把整段代码重构了一遍你想解决启动失败它列出十几种可能原因却没有告诉你先检查哪一个。问题常常出在我们把材料发过去了却没有把要做的事情说清楚。这篇文章整理了文章、代码、报错三类场景下的 6 种提问模板。每个模板都可以直接复制再根据实际情况填写。一、先把“帮我看看”拆成具体任务“看看”可能包含很多不同的意思解释这段内容是什么意思检查有没有错误、遗漏或风险修改怎样改得更符合要求排查为什么出现这个现象验证怎么确认问题已经解决这些任务需要的回答不同。例如同样是一段代码帮我解释这段代码的执行流程。和检查这段代码是否存在重复扣款风险。虽然材料相同但关注点完全不同。所以提问前可以先补齐下面这句话我希望 AI 根据哪些材料完成什么任务并按什么方式给我结果在此基础上再补充必要的背景和限制就能形成一个实用的结构背景我正在做什么。 任务这次需要你解决什么。 材料文章、代码、日志或配置。 约束哪些内容不能改哪些结论不能猜。 输出希望按什么结构回答。不必每次都写成长篇说明。简单任务可以简单问涉及修改、排错和技术判断时再把信息补充完整。二、模板 1检查文章先明确检查标准适用场景文章已经写完准备发布希望检查内容是否偏题逻辑是否连贯示例能否支撑结论技术表述有没有疑点。这时直接要求“润色一下”容易把本来需要核对的问题变成措辞调整。可以直接复制的模板我准备发布一篇技术文章请先做内容审阅。 【文章信息】 标题…… 目标读者…… 读者看完后应该能够…… 【本次任务】 重点检查 1. 正文是否回应了标题提出的问题。 2. 论述是否存在跳步、重复或前后矛盾。 3. 示例是否足以支持结论。 4. 是否有表述过满、需要核实的技术判断。 5. 是否缺少影响读者理解的前提条件。 【约束】 先列出问题不要直接重写全文。 区分确定的问题、需要核实的疑点和表达建议。 涉及外部技术事实时如未核实请明确标注。 【输出格式】 按“原文位置—问题—影响—修改建议”输出。 优先列出影响准确性和理解的问题。 【正文开始】 …… 【正文结束】这个模板解决什么问题它明确了文章准备给谁看以及读者看完应该获得什么。例如一篇面向新手的 Docker 教程即使命令本身正确如果没有说明运行环境、配置文件位置和访问方式读者依然可能无法完成操作。文章审阅需要检查的不只是句子通不通顺还有内容能不能完成写作目标。三、模板 2修改文章保留自己的意思和表达适用场景你已经知道文章的问题希望 AI 帮忙调整表达例如删除重复内容缩短过长的句子补上必要的过渡让段落更容易阅读。这时最需要说明的是修改范围以及哪些内容必须保留。可以直接复制的模板请根据以下要求修改文章。 【发布场景】 准备发布到 CSDN。 目标读者…… 【修改目标】 1. 删除重复表达。 2. 拆分过长的句子和段落。 3. 补充必要的衔接让论述更连贯。 4. 保留原文的主要观点和技术细节。 【必须保留】 个人经历…… 关键案例…… 代码、命令或数据…… 希望保留的表达…… 【约束】 不要编造测试过程、项目经历、数据或引用。 不要擅自改变技术结论。 不要把有条件的判断改成绝对结论。 需要新增事实才能讲清楚的位置请单独标注。 【输出格式】 先输出修改后的正文。 再简要说明主要修改以及仍需作者确认的内容。 【正文开始】 …… 【正文结束】使用时注意什么如果文章里写的是在我的本地测试环境中这种方式减少了配置步骤。修改后仍然需要保留“本地测试环境”这个范围不能直接变成这种方式适用于所有项目能够显著提升开发效率。修改可以改善表达但不能顺手扩大结论。如果你只想调整某个段落就只提供相关段落及必要上下文避免让一次局部修改变成整篇重写。四、模板 3理解代码要求说明调用关系和信息边界适用场景接手已有项目或者阅读一段不熟悉的代码想了解入口在哪里参数怎样传递核心分支如何执行数据在哪里发生变化哪些行为还需要查看其他文件才能确认。可以直接复制的模板请帮助我理解下面的代码。 【背景】 语言和框架…… 这段代码所在的位置…… 我已经了解的内容…… 我不熟悉的部分…… 【本次任务】 请说明 1. 这段代码的主要职责。 2. 从入口到返回结果的执行顺序。 3. 关键变量和条件分支的作用。 4. 数据库、缓存、网络请求等外部交互。 5. 哪些行为无法仅根据当前代码确认。 【约束】 区分代码中能直接确认的行为和推测。 不要根据方法名称猜测未提供的内部实现。 如需补充代码请指出具体文件或方法及原因。 【输出格式】 先用一段话概括。 再按执行顺序解释。 最后列出需要进一步查看的位置。 【代码开始】 …… 【代码结束】为什么需要限制“推测”假设代码中只有这一行orderService.submit(order);仅凭方法名无法确认内部是否进行了库存扣减、支付处理或消息发送。更可靠的解释应该是这里调用订单提交方法具体是否包含库存扣减需要继续查看submit的实现。读代码时要分清“当前代码展示了什么”和“按照常见设计可能做什么”。五、模板 4修改代码把预期行为和验收条件写出来适用场景需要给现有代码增加功能或修复问题例如增加参数校验修复分页逻辑调整异常处理补充某个边界情况。“帮我优化一下”容易让修改范围不断扩大。更有效的做法是直接描述目标行为。可以直接复制的模板请修改以下代码完成指定需求。 【项目背景】 语言和版本…… 框架和版本…… 相关文件及调用关系…… 【当前行为】 目前输入……时实际返回或发生…… 【预期行为】 希望输入……时返回或发生…… 【修改范围】 允许修改…… 需要保持兼容…… 依赖限制…… 【验收条件】 1. 正常输入……应得到…… 2. 边界输入……应得到…… 3. 非法输入……应得到…… 4. 原有行为……应继续保持。 【约束】 优先采用满足需求的最小修改。 不要顺带重构无关模块。 缺少必要上下文时先指出缺失信息。 没有实际执行测试时不要声称测试通过。 【输出格式】 说明问题原因。 给出需要修改的代码及位置。 列出验证步骤和预期结果。 区分已执行的验证与建议执行的验证。 【代码开始】 …… 【代码结束】一个更具体的需求示例比较下面两种问法。模糊问法这个分页接口帮我优化一下。明确问法当前分页接口允许 pageSize 传入负数。 请在现有参数校验方式中增加检查 pageSize 小于 1 时返回参数错误 合法值继续按原逻辑处理。 保持接口地址、响应结构和合法请求的行为不变。 请给出修改代码及验证步骤。第二种问法更容易判断修改是否完成因为预期行为已经可以检查。代码生成出来之后还需要通过编译、测试或实际运行确认结果。六、模板 5定位报错给出完整异常链和触发过程适用场景程序已经出现明确报错例如应用启动失败接口调用异常数据库连接失败某个操作触发异常。这类问题最需要的是报错上下文而不只是最后一句错误信息。可以直接复制的模板请帮助我定位下面的报错。 【我要完成的操作】 …… 【触发步骤】 1. …… 2. …… 3. …… 【预期结果】 …… 【实际结果】 …… 【运行环境】 操作系统或容器环境…… 语言、运行时版本…… 框架及相关依赖版本…… 启动方式…… 【最近变更】 报错前修改过…… 如果不清楚请写“暂不确定”。 【完整报错及相关日志】 保留异常链、文件名和行号 …… 【相关代码或配置】 …… 【本次任务】 1. 找出日志中最值得关注的信息。 2. 区分已经确定的事实和待验证的原因。 3. 按排查优先级给出下一步检查。 4. 说明每一步如何判断结果以及结果对应的下一步。 【约束】 不要仅凭异常名称直接确定根因。 涉及删除数据、清空缓存或修改权限的操作 先说明影响范围再给出建议。怎样提供日志更有用以 Java 异常为例最上层可能只是“应用启动失败”具体原因还需要结合异常链中的Caused by、相关堆栈以及前后日志判断。发送前可以做必要脱敏密码、Token 和密钥直接隐藏用户信息替换为示例值内网地址使用一致的代称保留异常名称、代码行号和参数结构。例如把同一个服务地址统一替换为SERVICE_A比全部替换成***更容易保留调用关系。脱敏时隐藏敏感值同时尽量保留排查所需的结构。七、模板 6排查环境差异把“本地正常”变成对照信息适用场景程序没有明显改动却出现本地正常服务器异常Postman 能调通代码请求失败测试环境正常生产环境失败一台机器成功另一台机器失败。这类问题的关键是找到条件差异。可以直接复制的模板请帮助我排查同一操作在两个环境中表现不同的问题。 【操作目标】 …… 【正常的一侧】 环境…… 执行方式或请求内容…… 实际结果…… 【异常的一侧】 环境…… 执行方式或请求内容…… 实际结果及日志…… 【已知对照信息】 代码版本 A…… B…… 运行时及依赖版本 A…… B…… 配置来源和关键配置 A…… B…… 请求地址、方法、请求头和请求体 A…… B…… 网络访问方式及代理 A…… B…… 相关文件路径、权限或工作目录 A…… B…… 未知项请保留为“未知”。 【本次任务】 1. 整理已知差异和未知信息。 2. 按与当前现象的相关性安排检查顺序。 3. 每一步说明检查对象、方法和结果判断。 4. 优先提供能够验证猜测的检查避免一次修改多个变量。 【输出格式】 按“检查项—为什么检查—如何检查—结果如何解释”输出。 最后指出当前证据最不足的环节。为什么要列对照信息“本地和服务器一样”可能只表示代码一样。实际执行时还可能存在配置、依赖、时区、权限、工作目录、代理或网络路径等差异。哪些差异相关需要结合现象判断。例如Postman 请求成功、代码请求失败时可以先比较实际发送的请求地址和方法是否相同请求头是否一致参数放在查询串、表单还是 JSON 请求体中两边是否使用了不同的代理或认证信息。先把能观察到的差异列出来才方便逐步缩小范围。八、拿到回答后还要检查是否真的完成任务提示词更具体并不意味着回答一定正确。收到结果后可以用三个问题检查1. 回答是否对应我的任务要求检查文章逻辑结果却只有润色要求定位根因结果却只有常见原因列表都说明任务还没有完成。可以继续收窄请结合我提供的材料 指出目前最有依据的判断以及下一步最值得执行的检查。2. 结论是否有材料支持留意这些表达“肯定是……”“这样修改就能解决……”“该方法没有任何风险……”检查它们是否有对应的代码、日志或验证结果。如果没有应当作为待验证判断处理。3. 是否有可执行的下一步“检查配置”“优化代码”“排查网络”还不够具体。有用的建议应尽量说明检查哪个配置、执行什么操作、看到什么结果以及接下来如何处理。如果 AI 给出了代码修改也要确认它有没有实际运行条件。“提供了测试方法”和“已经执行并通过测试”是两种不同的状态。九、写在最后这 6 个模板可以按任务快速选择你要做的事需要优先补充的信息检查文章目标读者、写作目标、检查标准修改文章修改范围、保留内容、事实边界理解代码所在位置、调用关系、已有知识修改代码当前行为、预期行为、验收条件定位报错触发步骤、异常链、环境和最近变更排查环境差异正常与异常两侧的对照信息模板只是起点实际提问时不必机械填满每一项。下一次准备输入“帮我看看”时可以多补一句请重点检查什么依据哪些材料以及希望得到什么结果。这句话说清楚之后后续沟通通常会更容易围绕具体问题展开。