“帮我写一篇文章”和“帮我看看这个报错”，都是能发出去的提问，但对方很难知道你要什么。文章写给谁？报错发生在哪一步？这些信息缺着，回答就容易停在通用建议上。

给 ChatGPT 补背景，不需要写一大段角色设定。先交代手头的事，再说明希望拿到什么结果，通常更容易继续讨论。下面用三个常见场景，说明怎么把一句模糊的话改成可执行的任务。

先补齐四件事，再考虑提示词写得漂不漂亮

OpenAI 的提示编写指南强调清楚的任务、必要背景、输出要求和准确性检查。把这些原则用到日常提问里，可以先写四行：我在做什么、现在卡在哪里、已有材料是什么、希望你交付什么。以下模板和场景是本站为新手整理的原创示例，并非官方效果承诺。

背景：我正在给一个 PHP 小网站增加文章列表。
现状：列表每页显示 12 篇，现在还没有分页链接。
已有材料：下面是列表查询和页面模板，数据库表结构也附上。
任务：先指出需要改的地方，再给最小修改方案。
要求：保留现有样式；不要重写购买模块；缺少信息先说明。

“最小修改”是一条有用的约束。否则你想补一个按钮，收到的可能是一套重新设计的页面。把不能动的范围写出来，后续评估答案也有了依据。

场景一：排查报错时，给出复现路径

只贴最后一行错误，往往不足以定位问题。更完整的材料包括运行环境、触发操作、实际结果，以及最近做过什么改动。日志保留与问题有关的几行即可，先把密码、令牌和用户资料移除。

环境：PHP 8.2、Nginx，页面由 index.php 统一处理。
复现：打开首页正常；点击文章卡片后，/articles/demo 返回 404。
预期：进入文章详情。
最近改动：昨天把站点运行目录改成 public。
材料：下面附当前路由片段、Nginx 相关配置和同一次请求的错误日志。
请按“最可能原因 → 如何验证 → 对应修改”给出建议。
先给只读检查步骤，不要一上来让我覆盖整份配置。

这个例子中的版本和路径只是示意，提问时应替换成自己的实际环境。如果你还没拿到日志，可以直接说“暂时没有日志”，让它先告诉你去哪里查看。空缺写明白，比填一个猜测值更有帮助。

场景二：让它改文章时，给一段你认可的表达

“写得专业一点”和“去掉 AI 味”都比较抽象。更具体的办法是告诉它读者是谁、哪些措辞不喜欢，再给一小段符合你口吻的文字。

读者：第一次给网站配置 HTTPS 的站长。
任务：把下面这段说明改成一篇操作教程。
表达：短句为主，遇到术语解释一次；不要夸张开场。
保留：所有命令、错误信息和原始参考链接。
删去：没有证据的效果承诺、重复结论。
限制：缺少截图或测试结果的地方，不要写“亲测可用”。
输出：先给正文，再列出需要人工核对的技术事实。

如果只是不喜欢开头，接着指出“第一段太长，直接从报错现象开始”即可。每轮改一个明确的问题，比反复要求“再自然一点”更容易收敛。涉及技术事实时，把原始文档一并提供，避免在润色过程中把前提条件改丢。

场景三：整理资料时，要求把缺失项留出来

把几份资料交给 ChatGPT 做比较，可以提前定好表头，例如“功能、适用对象、资料中的限制、来源位置”。原文没有价格，就写“资料未提及”，不要让它为了填满表格补出一个数字。

回答出现陌生的产品名、版本号或链接时，逐个打开核对。让模型自查能帮助发现问题，但不能代替阅读来源。尤其是上线配置、付费方案和安全结论，最终判断还要回到当前官方说明与实际环境。

回答不对路时，先找缺的那一块

  • 太泛：补具体对象、报错和操作步骤。
  • 太长：限定一个交付物，并说明长度或格式。
  • 改动太多：写清楚允许修改的文件和需要保留的行为。
  • 事实可疑：要求标明依据，无法证实的内容列为待核实。

你不需要把模板全部填满。简单问题直接问；复杂问题把材料和目标说明白。值得保留的，是让下一轮讨论更具体的那几条信息。

参考：OpenAI：ChatGPT 实用提示编写指南。本文不涉及特定套餐的使用额度或功能开通条件。