8.0
热点
AI SCORE
编程提效2026-08-07 17:58
48个prompt改写实例：信息位置影响模型准确率
dev.to · AI#Prompt工程#模型研究#AI技巧
Editor brief · 编辑速览
通过Stanford/Google研究揭示大模型存在「中间丢失」效应，关键指令应放首尾；提供48个before/after改写对比。
"Prompt Engineering 示例"
Prompt 库 · 第 1 篇，共 2 篇 · 2026 年 8 月更新
我第一次"精心设计" Prompt，是为一句产品描述。我输入了"写一段能转化的产品描述"，Claude 返回了四句毫无特色的套话，放到蜡烛、CRM 系统或皮划艇上都成立。词语本身没问题，问题出在结构上——它根本没有捕捉到具体的预期结果。这篇文章要填补的正是这个缺口。不是靠形容词（"写点厉害的"），而是靠真正的 mechanics：Prompt 结构里哪些地方变了，为什么一变模型就给出了不同的响应。下面是 48 组配对示例——通用版和改进版并列——横跨五个类别，并附上研究支撑的通用模式。快速答案 问题几乎从来不在词汇。关键在于：点名受众、限制范围、锁定输出格式——这五个结构性动作涵盖了"提示词工程"在实践中真正意味着什么。示例教的是格式，不是内容。一个格式良好的示例通常比三个粗糙的示例更有用。信息放哪里，决定了模型会不会用它——关键指令放在开头或结尾，不要埋在第四段。整个学科本身正在转变。到 2026 年中，大多数从业者已经把"提示词工程"合并到了更广泛的"上下文工程"工作中——即管理模型看到了什么，而不只是怎么措辞这个提问。下面的模式依然有效；在那个更大的尺度上，有些模式反而更重要，而非更不重要。一个诚实的警告 2026 年是写这类文章比较尴尬的年份，我宁可说出来而不是假装没事。Andrej Karpathy 把模型比作 CPU、把上下文窗口比作 RAM 的框架，在 2025 年到今年之间获得了真正的关注，越来越多的从业者现在把 Prompt 措辞视为更大的上下文管理工作流中的一个输入，而不是主要杠杆。2026 年 2 月，HxAI Australia 的一项研究在 11 个模型和四种上下文格式上运行了 9,649 次实验，发现了一个应该让所有格式建议——包括下面某些内容——都冷静一下的结果：格式选择对整体准确率没有统计上显著的影响，而前沿模型与开源模型能力之间的差距是 21 个百分点——这是该研究测量到的最大因素。直白地解读，这意味着：使用哪个模型通常比你怎么巧妙地格式化它周围的上下文更重要。这篇文章里的模式仍然值得了解。只是别指望 Prompt 打磨能跑赢能力差距。目录 写作与内容（10） 代码与工程（11） 数据与电子表格（9） 支持与销售（9） 营销与 SEO（9） FAQ 注意：这是第一部分：横跨上述五个类别的 48 个示例。第二部分——研究与决策、图像/视频/设计、AI 智能体工作流、教育、法律/HR/行政，以及"哪些 Prompt 失败了以及为什么"一节——正在制作中。我们分开发布而不是把全部 11 个类别合成一篇超长文，因为一篇包含 111 个示例的单一文章就不再是参考资料，而是一面墙。到处出现的四个 mechanics 下面的 48 个重写中反复出现四样东西，且全部有已发表研究的支撑，而不是凭感觉：
角色 + 赌注 "你在它发到 40,000 名订阅者之前做审核。"
上下文优先 背景、数据、约束条件——放在任务之前。
一次任务，一句话 不要把三个目标塞进一个请求里。
一个带操作的示例 展示格式和判断标准，不只是指令。
输出锁定 格式、长度，以及信息缺失时怎么办。顺序很重要：第 1 和第 2 项锚定开头，第 5 项锚定结尾——见下面的"中间丢失"。研究实际说了什么 信息放哪里，决定了模型会不会用它。Stanford 和 Google 的研究人员测试了语言模型如何处理长输入，发现了一条一致的 U 形曲线：当相关事实位于上下文的最开头或最末尾时，准确率最高；当它埋在中间时，准确率明显下降——即使在专为长上下文构建的模型中也是如此。Anthropic 自己的当前文档指出，较新的 Claude 模型在这方面有了显著改善，但安全的习惯——关键指令放前面，关键指令放末尾，不要埋在第四段——仍然不花任何成本，而且仍然有效。
示例在格式上的教导不亚于内容。University of Washington 和 Meta AI 在 2022 年发表的一项被广泛引用的研究发现了一个真正反直觉的结果：在少样本示例中把正确的标签替换成随机标签，几乎没有损害性能，因为模型依赖的是示例的结构和标签空间，而不是每个标签的字面正确性。实际上，这意味着一个格式良好的示例通常比三个粗糙的示例做更多的工作——这就是为什么下面的很多重写都只包含一个示例。
结构胜于词汇，角色扮演式的前言比过去更弱了。这是大多数"100 条 Prompt"列表跳过的地方。Hugging Face 的 Phil Schmid 说得很直接：大多数生产环境中 AI 智能体的失败不是糟糕的 Prompt，而是上下文失败——检索到了错误的文档、往窗口里塞了太多历史记录、工具定义缺失。好几位构建生产系统的从业者报告说，"你是一位专家……"这种身份 priming 在前沿模型上几乎不动准确率，主要浪费的是你宁愿用在别处的 tokens——这就是为什么本文中"角色 + 赌注"模式侧重于具体的赌注（真实的受众、真实的截止时间），而不是一个职位头衔。
验证是 Prompt 的一部分，不是事后补救。重写时要求模型在完成前根据声明的约束条件检查自己的输出，比只要求输出的版本始终产生更少的隐性错误。这不是来自某篇论文——这是我做这行三年来发现的最可靠的单杠杆，而且这是最便宜的一个加法。例如，微软研究院做了一个对照试验，让开发者分别在使用和不使用 GitHub Copilot 的情况下写一个 JavaScript HTTP 服务器。使用 Copilot 的那组快了 55.8%，置信区间为 21% 到 89%——一个真实的、可复现的效应，但范围足够宽，以至于"AI 让你更快"和"AI 让你快一倍"都是对同一项研究的合理解读，取决于你落在区间的哪一端。这正是大多数"AI 生产力"标题剥离掉的细微差别，也是本网站规则的原因：不带条件说明的统计数字不出来。如何阅读示例 表格格式 每张卡片展示通用 Prompt、改进后的重写，以及发生改变的那一个 mechanics。可移植性 大多数示例在 Claude、GPT-5 和 Gemini 上无需修改即可使用。少数针对特定模型的说明会做标记。使用方法 复制，把括号里的细节换成你自己的，保持结构完整。症状 → 修复对照表 如果你的 Prompt 正在产生这些问题，这里是对应的修复方法： 表格 症状 修复 输出很泛，可以描述任何东西 具体性锁定 + 角色 & 赌注 模型忽略了你一半的指令 分解（一次只做一个请求） 每次重新运行格式都不一样 一个带操作的示例 + 输出 schema 听起来自信，但事实错误 验证通过 + 来源接地 运行一次，下一个输入就坏了 边缘情况强制 + 少样本锚点 把这张表放在手边。下面的 48 个"改进后" Prompt，几乎都是把上述五种修复方法之一应用到具体情境中。写作与内容 10 个示例。大多数"让它更好"的请求失败，根源就两个：模型不知道谁在读，或者模型不知道该忽略什么。这里的每个示例都修复了这两件事之一。示例 1：具体性锁定 + 负面约束 通用版： plain 写一段关于远程工作效率的博文引人入胜的开头。
改进版： plain 你正在为一篇博文的开头写前 80 个词，受众是刚接手一支完全远程团队、还不信任这支团队的中层管理者。
背景：文章认为远程团队表现不佳，不是因为距离，而是因为管理者用监控替代了信任——而这适得其反。
用一个具体的、具体的场景开头，描述一个正在这样做的管理者。不要用统计数据。不要用问句。段落结尾落在张力上，而不是解决方案上。不要说"在当今远程优先的世界"。
为什么有效：直接点名模型默认的三种开头（统计数据、问句、以及那句完全一样的陈词滥调），在它写出一个字之前就把它们排除掉了，而不是等写完你再去发现和拒绝。示例 2：受众锁定 通用版： plain 为陶瓷手冲咖啡滴滤器写一段能转化的产品描述。
改进版： plain 为一款陶瓷手冲滴滤器写一段 60 词的产品描述，$38，面向已经拥有 $200+ 意式咖啡机、买这个是为了一个更慢、更刻意替代品的人。
直接说明这一技巧解决的具体痛点——而不是"绝佳风味"这种套话，用户家里已经有咖啡机了。一句话说明它不适合的场景。最后给出实际冲泡时间。工作原理：说出"已经拥有意式咖啡机"这个用户画像，淘汰了那些适用于任何咖啡产品的千篇一律的"醇厚饱满风味"文案；而主动列出一个诚实的取舍而非免责条款，读起来反而像自信而非示弱。
示例 3：约束预算 + 自我批评循环
通用版：
给我写 10 个关于我们黑色星期五促销邮件的主题行。
工程化版：
为一封面向曾经购买过一次但未再回购的老客户的黑色星期五邮件生成 8 条主题行。
不超过 45 个字符。不使用 emoji，不用"最后机会"，不使用感叹号。至少 2 条要提及他们没有回来过，但要用好奇心而非愧疚感来包装。
选出你最喜欢的 2 条并各用一句话说明原因。
工作原理：禁止使用四个早已塞满用户收件箱的短语，去掉了模型最安全、最偷懒的默认输出；而让它对自己的输出排序，给你的是一个决策而非 8 条近似重复、仍需你逐一判断的选项。
示例 4：角色 + 利害关系 · 范围栅栏
通用版：
让这段文字更专业：[粘贴文字]
工程化版：
将以下内容重写给 CFO 阅读：句子更短，不使用模糊措辞（"我认为"、"也许"、"看起来"），优先呈现关键数字，删除任何不影响决策或风险的内容。
如果某句话不能改变 CFO 本周要做的决策，就直接删除而非改写。
工作原理："更专业"是一个没有明确靶点的语气要求；而指定读者本周实际要做什么，给了模型一个具体的过滤器，而不是它默认的——更长的词、更正式、更模糊。
示例 5：分解
通用版：
写一篇 1500 字的文章，探讨 2026 年人们为什么辞职。
工程化版：
在写任何内容之前，为这篇 1500 字的文章提供一个 6 点大纲，主题是为什么人们在 2026 年辞职。每一点用一句话陈述论点，一句话命名支撑它的证据（一项研究、劳动力统计数据、一个具体案例）。
写完大纲就停。我来告诉你保留哪些点。
工作原理：把"写文章"拆成"规划 → 核对 → 写作"，在还只是六个要点的时候就抓住一个薄弱或缺乏支撑的论点，而不是等 1500 字已经搭好之后才发现。
示例 6：负面约束 + 验证通过
通用版：
把这些会议记录整理成一段话。
工程化版：
将以下要点整理成 3 段简短的文字，给非技术背景的利益相关者看。精确保留每个数字——不四舍五入、不估算、不把数字软化成"显著"或"一般"。如果某个要点表意不清，用方括号标出而非猜测其含义。
[会议记录]
工作原理：禁止在文字中软化数字，是修复 AI 重写时最常见的事实漂移问题的唯一办法——这种漂移发生在没人再去核对原始来源的状态更新里。
示例 7：范围栅栏 + 验证通过
通用版：
让这段更短。
工程化版：
通过删除冗余句子和弱限定词将这段压缩到 200 字——不是把它们概括成更模糊的版本。如果两句话说的是同一件事，直接删掉其中一句，而不是把两者合并。
在被改写的文字下方，单独列出你删掉的内容。
工作原理：单独的"更短"通常产生更薄、更模糊的草稿；而指定压缩意味着删除而非合并，并要求一份可见的删减清单，让编辑决策变得可检查而非消失于无形。
示例 8：角色迁移 + 受众锁定
通用版：
为我的个人介绍页写一段简短的简历。
工程化版：
写一段 90 字的个人介绍。受众：正在决定是否给我发邮件的潜在自由职业客户，而非我行业内的同行。
要用的facts：10 年 UX 研究经验，在两家被收购的初创公司工作过，现在是独立顾问，居住在里斯本。
优先呈现客户真正关心的——我能否信任这个人处理一个真实项目——而不是按时间排列的工作经历。最后一句话可以有点个性，但不是爱好列表。
工作原理：指定读者是谁（买家而非同行）改变了哪些事实被放到前景；没有这一点，简历默认按时间顺序排列，悄悄回答了错误的问题。
示例 9：受众锁定 + 失败模式命名
通用版：
为普通读者简化这段。
工程化版：
为没有任何背景知识的读者重写，长度相当或更短。替换掉非专业人士无法辨认的每个术语——但要用它指代的具体事物，而不是更模糊的词。如果某句话没有准确的白话等价物，保留该术语并在括号内用不超过 6 个词为其下定义。
[段落]
工作原理：命名具体的失败模式——"不要用更模糊的词替换"——防止了 AI"简化"文本时最常见的翻车方式：让内容变得不精确而非不技术化。
示例 10：自我批评循环 + 受众锁定
通用版：
给我 5 个这篇文章标题的选项。
工程化版：
为下面的文章生成 6 个标题选项。为每个标题命名它所针对的具体读者场景（不是人口统计学标签——比如"刚被晋升卡住的人"）。
然后选出如果你自己的通讯刊物会用的一条，并说明你会用它做什么 A/B 测试。
[文章摘要]
工作原理：要求读者场景而非人口统计学标签，过滤掉了"10 个技巧"这种通用直觉；而强制一个承诺的选择，给出的是一个决策而非你仍需自己做的菜单。
代码与工程 11 个示例。在微软研究院的随机对照试验中，使用 GitHub Copilot 的开发者在标准化任务上比对照组快 55.8%（95% CI 21–89%）。以下提示是建立在这个基础之上的那一层：AI 编程助手从更快的高级自动补全，变成真正的协作者，其中的差异就在这里。
示例 11：边缘情况强制 + 范围栅栏
通用版：
写一个验证邮箱地址的函数。
工程化版：
写一个 Python 函数，用于注册表单的邮箱地址验证。写之前，列出你将处理的 5 个边缘情况（加号寻址、子域名、缺少 TLD 等）以及 2 个你明确不处理的情况及其原因。然后写这个函数，用 docstring 记录这些决策。只用标准库，不引入新依赖。
工作原理：在写代码之前列出边缘情况，暴露了通常在三周后以 bug 报告形式出现的验证漏洞；而限制依赖则阻止了一个 6 行函数变成没人要求过的 regex 库导入。
示例 12：推理轨迹 + 范围栅栏
通用版：
修这个 bug：[代码 + 错误]
工程化版：
这个函数在给定输入时抛出 [错误]：[代码]。在改任何东西之前，用一句话陈述你对根本原因的假设，并命名一个你排除的替代方案及其原因。然后做最小的修复——不要重构与 bug 无关的周围代码。
工作原理：要求陈述一个被排除的替代方案，抓住了常见的失败模式：模型在调用处修补症状，而不是去修复上游两个函数的真正原因。
示例 13：范围栅栏 + 负面约束
通用版：
审查我的代码。
工程化版：
只审查这一件事：这两个函数之间共享状态中的数据竞态。不要评论命名、风格或任何与并发无关的内容。如果没有发现任何问题，直接说明——不要用次要的样式笔记来填充内容以显得全面。
工作原理：只做一件事的栅栏防止了"全面审查"变成被无关问题淹没的审查——而要求直接说"没发现问题"，防止了为了显得 thorough 而混入噪音。
通用提示：plain Refactor this to be cleaner.
工程化提示：plain Refactor this function for readability only. Don't change its behavior, its public interface, or add error handling for cases that can't currently occur. Don't introduce a new abstraction unless it's already reused at least twice in this file.
生效原因：不设定边界的"更清洁"往往会生成比任务所需更灵活、更抽象的代码——提前声明限制可以预防它，而不是等到审查阶段才发现。
通用提示：plain Write tests for this function.
工程化提示：plain Write unit tests covering: the happy path, an empty input, a boundary value at the function's stated limit, and one case that should raise an exception. Use pytest. One assertion focus per test — no test checking five unrelated things at once.
生效原因：提前命名四种情况可以防止模型默认生成三个几乎相同的通过路径测试——它们都通过了，但无法告诉你那个在实际生产中真正出问题的边界在哪里。
通用提示：plain Explain this code.
工程化提示：plain Explain this code to a developer who knows Python but has never seen this codebase. Assume they understand the language, not our domain. Walk through what it does in execution order, not file order, and flag the one part that isn't obvious from reading it line by line.
生效原因：未指定受众时，你得到的要么是无用的逐行复述，要么是一段没有任何实质内容的摘要；指定真正的读者可以修正解释的高度。
通用提示：plain Convert this to TypeScript.
工程化提示：plain Convert this JavaScript function to TypeScript. Preserve the exact runtime behavior, including existing error handling — don't "improve" it with stricter checks that change what inputs are accepted. Add types only; flag any place the original behavior is ambiguous enough that you had to guess a type, instead of guessing silently.
生效原因：语言转换是模型最常暗中夹带未被请求的行为变更（伪装成类型安全）的地方；要求标记歧义而不是默默猜测，可以让实际的决定权留在你手中。
通用提示：plain Optimize this function.
工程化提示：plain This runs on ~50,000 rows once per day, not in a hot path. Optimize for readability and maintainability, not raw speed — don't introduce caching, memoization, or algorithmic complexity unjustified at this scale. If a genuinely faster approach exists, note it in a comment, don't implement it unless asked.
生效原因：在你说清楚为了什么之前，"优化"是没有定义的；如果不说明规模和频率，模型默认会选择看起来最"厉害"的优化方案，而这对于每天运行一次批处理任务来说往往是不对的权衡。
通用提示：plain Write a regex to match phone numbers.
工程化提示：plain Write a regex matching US phone numbers in these formats: (555) 123-4567, 555-123-4567, 5551234567. Then give me 5 strings that should match and 3 that look similar but shouldn't, so I can verify it against real input before using it.
生效原因：确切的格式作为锚定示例，要求提供真匹配和近似误匹配的测试字符串，可以让一个原本需要在生产数据上调试的正则表达式，变成可以在十秒内验证的东西。
通用提示：plain Why does this test fail?
工程化提示：plain This test fails intermittently, not every run: [test + code]. List your top 2 hypotheses for why it's flaky, ranked by likelihood, with the evidence in the code supporting each. Don't propose a fix yet — I want the cause first.
生效原因：诊断和修复的分离在 bug 是间歇性的时候最为重要，因为"直接修复它"的本能通常意味着加一个 sleep() 或重试，这只是掩盖了竞态条件而不是解决它。
通用提示：plain Add documentation to this code.
工程化提示：plain Add docstrings only to public functions, not private helpers prefixed with underscore. Each docstring: one line on what it does, params, return type, one line on what it raises and when. No inline comments explaining obvious lines.
生效原因：将文档限制在公共表面并命名确切字段，可以防止常见的过度输出——每行都加注释，导致文件更难扫描而不是更容易。
一个从未见过你电子表格的模型仍然会自信地为你写一个公式。解决方案不是更聪明的模型——而是在它猜测之前，告诉它你正在使用的是哪个 Excel 风格的真相版本。
通用提示：plain Write me a formula to calculate commission.
工程化提示：plain Excel formula: commission = 8% of sales in column D, but 12% on the portion above $10,000, for each row. Sales are in D2:D500, some cells are blank (treat as 0, not error). Give me the formula for one cell plus a one-line explanation of how it handles the blank-cell case, since that's where my last version broke.
生效原因："计算佣金"没有固定含义——分级还是固定、空白视为零还是错误、单一税率还是边际税率——而命名确切的层级结构加上空白单元格规则，就是让公式在第 2 行能用在所有 499 行能用的区别。
通用提示：plain Summarize this sales data.
工程化提示：plain Summarize this quarter's sales data for a regional manager who already knows the numbers roughly — she wants what changed and why, not a recap. Three bullets max: the biggest swing, one number that looks fine but isn't (explain why), and one thing you can't explain from this data alone. Don't restate totals she already has in the report.
[data] 生效原因：没有受众的"总结"默认会用句子复述表格内容；指明读者已经知道什么，迫使模型呈现变化而不是数据集本身。
通用提示：plain Clean up this messy data.
工程化提示：plain Before changing anything, list every issue you see in this data: duplicate rows, inconsistent date formats, trailing whitespace, mixed casing in the category column, and anything else. Then propose a fix for each as a numbered rule I can approve or reject — don't apply any fix until I've seen the list. Flag any row you'd delete rather than fix, separately, since deletions aren't reversible.
[data] 生效原因：没有审批步骤的"清理"意味着静默删除，你只在报告短缺时才发现；将诊断与修复分离，把不可逆操作变成你先签字批准的。
通用提示：plain What chart should I use for this data?
工程化提示：plain I have monthly churn rate for 5 customer segments over 18 months. I'm deciding between a multi-line chart and a small-multiples grid (one mini chart per segment). G