AI先报

分类： 31

  • Gemini提示词教程：用示例、分步提示和迭代提高输出质量

    一句话结论：在 Gemini 中，清楚的指令、少量示例、分步任务和连续迭代，是把一次性提问变成稳定工作流的四个基础。

    Gemini 官方文档将提示设计拆成明确描述、提供上下文、使用示例和逐轮改进。下面用一个“从访谈记录生成教程大纲”的场景说明。

    第一步：明确输入和交付物

    请根据<访谈记录>生成一份 AI 教程大纲。
读者：没有技术背景的运营人员。
交付物：10 个小节，每节包含标题、学习目标、操作步骤和一个练习。
限制：只使用访谈记录中的事实；缺失信息标为“需要补充”。
<访谈记录>
在这里粘贴原文
</访谈记录>

    第二步：用示例固定格式

    如果你希望每节都长得一样，可以先给一节示例，明确标题层级、字数和动作动词。示例应代表最终风格，而不是随便写的占位文本。对于分类任务，还应至少展示一个容易混淆的边界例子。

    第三步：拆成连续提示

    1. 让 Gemini 先提取事实和术语，不急着写文章。
    2. 根据事实清单生成大纲，并指出资料缺口。
    3. 只扩写一个小节，检查语气和粒度。
    4. 最后批量扩写，并让模型按清单自检。

    这样做的好处是每一步都有可见产物，出现错误时能知道是资料提取、结构规划还是改写阶段出了问题。

    输出自检模板

    请检查上一版内容：
1. 是否每节都有操作步骤？
2. 是否出现访谈记录没有的事实？
3. 是否有重复小节？
4. 是否能让新手按顺序执行？
请输出“通过 / 问题 / 修改建议”三列，不要直接重写全文。

    常见错误

    把多个目标塞进一句话、不给读者画像、只说“写得生动”、没有说明资料边界，都会让结果不稳定。对于最新产品功能，应该让模型使用当前官方资料或由人提供链接，不能依赖过期记忆。

    常见问题

    Gemini 提示词需要写得很复杂吗？

    不需要。先从清晰短提示开始，只有在结果出现稳定问题时再增加示例和约束。

    什么时候适合分步提示？

    资料提取、分类、写作和审核混在一起时适合拆分；简单改写则不必过度设计。

    示例应放在任务前还是后？

    两种方式都能测试。通常先说明任务，再放示例和待处理输入，更容易读懂。

    模型输出的事实可靠吗？

    不能默认可靠。重要事实应回到官方来源或原始资料验证。

    如何复用一套提示词？

    把角色、固定要求和输出格式保存为模板，把每次变化的输入单独放入变量区。

    信息来源与说明

    本文参考 Google Gemini 官方提示策略文档整理。模型名称、上下文长度和功能支持请以当前官方文档为准。

  • Claude提示词教程：用角色、示例和XML结构处理复杂任务

    一句话结论：处理长资料或复杂任务时，可以用明确角色、少量高质量示例和 XML 标签把上下文分区，让 Claude 更容易区分指令、资料和输出要求。

    这篇教程根据 Anthropic 的官方提示工程指南整理。XML 标签不是语法魔法，而是一种清晰的边界标记；如果内容本身包含 XML 字符，也可以换成其他明显的分隔符。

    四个关键组件

    • 角色：说明 AI 扮演什么职责及专业边界。
    • 任务：用动词描述要完成的动作。
    • 示例：给出 3 个左右输入和理想输出，展示你真正想要的格式。
    • 分区：把资料、要求和待处理内容分开。

    XML 分区模板

    你是企业知识库编辑，只依据提供的资料回答，不确定时明确说明。
<instructions>
请回答用户问题，并输出：结论、依据、下一步。
</instructions>
<reference_material>
这里放政策、产品说明或会议原文。
</reference_material>
<user_question>
这里放用户问题。
</user_question>
<output_rules>
使用简体中文；结论不超过 80 字；不得编造资料中没有的日期和数字。
</output_rules>

    少样本示例怎么写

    示例不要只展示“正确答案”，还要覆盖边界情况。例如一个示例处理正常问题，一个示例处理资料不足，一个示例处理用户要求超出范围。每个示例的输入输出格式保持一致，避免模型学习到无关差异。

    <example>
<question>合同什么时候到期？</question>
<answer>资料显示到期日为 2026 年 12 月 31 日。依据：合同第 3 条。</answer>
</example>
<example>
<question>客户为什么不续费？</question>
<answer>提供的资料没有说明原因，不能确认。</answer>
</example>

    长文档处理步骤

    1. 先给文档用途和回答目标，再放文档正文。
    2. 把多个文档分别放进独立标签，并写清来源或日期。
    3. 要求模型先引用相关段落，再给结论。
    4. 如果上下文很长，先分段提取，再汇总，减少遗漏。

    容易踩的坑

    角色写得过于宽泛会让输出失控；示例过多且质量不一致会产生反效果；标签名称前后不统一会增加歧义。对保密资料，还应确认服务商的数据处理政策，不能因为“只是测试”就忽略合规。

    常见问题

    XML 标签必须叫 instructions 吗？

    不必须。标签名应有语义，关键是前后一致、边界清楚。

    示例越多越好吗？

    不是。优先放少量但覆盖关键边界的高质量示例，通常比大量重复示例更有效。

    可以把系统提示和用户资料混在一起吗？

    不建议。分开写能减少资料被误当作指令，也便于维护和审核。

    如何让回答引用原文？

    要求输出引用的段落、文档名或页码，并在资料不足时拒绝猜测。

    怎样继续优化？

    保存失败案例，逐条修改提示词，并用同一组测试问题比较修改前后的表现。

    信息来源与说明

    本文参考 Anthropic Claude 官方提示工程指南整理。Claude 产品和模型限制可能变化，请以官方当前说明为准。

  • OpenAI提示词教程：把模糊要求改写成可验证的任务说明

    一句话结论：把“想要什么”改写成带有输入、任务、约束、输出格式和验收标准的说明，通常比堆叠关键词更能提升 AI 输出的稳定性。

    本教程参考 OpenAI 的提示工程文档，重点是通用的任务描述方法。不同模型和接口参数会影响结果，教程中的模板适合先做小样本测试，再根据业务数据迭代。

    模糊要求和可验证要求的区别

    模糊写法 可验证写法
    帮我写一篇好的文章 面向首次使用者，写一篇 800 字教程，包含步骤、注意事项和 5 个 FAQ
    分析这批客户 按行业、需求、预算和下一步行动输出表格，不确定字段标为待确认

    五段式提示词

    角色：你是负责内容质量审核的编辑。
输入：下面是一篇关于 AI 办公的初稿。
任务：检查事实、结构、重复表达和读者是否能照做。
约束：不得凭空增加数据；发现缺少来源时说明缺口。
输出：先给 5 行总体结论，再按“问题 / 证据 / 修改建议 / 优先级”输出 Markdown 表格。

    实际操作流程

    1. 先给一小段输入，确认模型理解了任务，不要一开始就投喂全部资料。
    2. 要求模型先输出计划或检查清单，再让它执行复杂任务。
    3. 对关键事实要求它标注依据；没有依据就输出“无法确认”。
    4. 用第二轮提示只修改一个变量，例如只改结构、不改事实。
    5. 把表现稳定的提示词和示例保存到团队知识库，定期复测。

    如何设置验收标准

    验收标准要能被人快速检查，例如“必须有 3 个步骤”“每条建议不超过 50 字”“表格不能出现空的负责人字段”。不要只写“高质量”“有深度”，这类词没有统一尺度。

    安全和事实核验

    AI 可以生成看起来合理但不真实的内容。法律、医疗、价格、政策和产品规格都应回到官方页面确认。不要把密码、身份证号或未公开客户信息放入测试提示词。对于需要稳定输出的接口，还要处理拒答、截断和超长输入。

    常见问题

    提示词中应该写模型名称吗？

    只有在任务确实依赖某个模型的特性时才写。通用模板应描述任务，不要绑定一个可能更换的型号。

    要不要把“请一步一步思考”写进去？

    可以要求输出检查清单、依据和结论，但不要把内部推理当作业务交付物。更重要的是给出可验证的中间结果。

    为什么同一提示词结果仍会变化？

    模型版本、上下文、随机性、资料顺序和系统指令都可能影响结果。用固定样例集回归测试，比凭一次体验判断更可靠。

    怎样降低编造？

    限定资料范围、要求引用依据、允许回答“无法确认”，并对关键结论做人工复核。

    适合直接用于生产系统吗？

    先做小流量和失败场景测试，再加入超时、重试、敏感内容过滤与人工兜底。

    信息来源与说明

    本文参考 OpenAI 官方 Prompt Engineering 指南，内容为中文教程化整理。具体 API 参数应以当前官方文档为准。

  • AI提示词教程：用目标、背景、要求和资料写出可执行提示词

    一句话结论：一条可执行的 AI 提示词，至少要交代目标、背景、输出要求和可使用的资料；缺少其中一项，模型就更容易给出泛泛而谈的答案。

    这篇教程把 Microsoft Copilot 官方建议整理成通用方法，同样适用于 ChatGPT、Claude、Gemini 等对话式 AI。它不是“万能咒语”，而是一种让问题更容易被准确理解的任务说明写法。

    先把问题写成四个部分

    部分 要说明什么 例子
    目标 希望 AI 完成什么 把会议记录整理为待办清单
    背景 面向谁、用于什么场景 面向产品团队周会
    要求 格式、长度、语气和限制 按负责人、截止日期、风险分组
    资料 AI 应该依据哪些内容 只使用下面的会议原文

    可直接复制的提示词模板

    目标：请把下面的会议记录整理成可执行的待办清单。
背景：读者是产品和研发负责人，清单要用于周一跟进。
要求：
1. 输出 Markdown 表格，列为任务、负责人、截止日期、依赖和风险。
2. 没有明确写出的信息不要猜测，统一标记为“待确认”。
3. 先给出三行摘要，再给出完整表格。
资料：
---
在这里粘贴会议记录
---

    为什么要写背景和资料

    只写“帮我总结一下”时，AI 不知道总结给谁看、保留哪些信息，也不知道应不应该补充常识。写清背景可以确定取舍，写清资料可以减少模型把外部常识混入结果的机会。涉及合同、财务、医疗或公司内部数据时，要特别注明“仅依据提供的资料”，并人工复核最终内容。

    用追问逐步收敛结果

    第一次输出不是终稿。可以继续要求“保留原表格，但把风险改成高、中、低并说明依据”，或者“只改写语气，不改变事实”。相比把所有要求一次写成很长的提示词，分轮调整更容易定位问题。

    常见错误

    • 把目标、背景和资料混在一段话里，模型难以判断优先级。
    • 使用“写得专业一点”这类无法检查的形容词，却不说明读者和格式。
    • 没有说明不确定信息如何处理，导致 AI 自动补全不存在的事实。
    • 把敏感信息直接粘贴到公共服务中，忽略企业隐私和平台政策。

    常见问题

    提示词一定要很长吗？

    不一定。短任务可以只写目标和输出格式；任务越复杂，越需要补充背景、资料边界和验收标准。

    可以让 AI 自己补充资料吗？

    可以，但应明确允许它查找外部资料，并要求列出来源。涉及事实判断时，仍要人工核验。

    怎样判断提示词是否写得好？

    看结果是否可复现、可检查、少猜测。让同事只看提示词，也能理解任务和交付格式，通常就比较清楚。

    一次只能提出一个要求吗？

    可以有多个要求，但应编号并按优先级排列。相互冲突的要求要先解决。

    这和 AI 搜索优化有什么关系？

    清晰的目标、事实边界和结构化输出同样适合知识库内容。更多实践可参考 AI 写作教程 和 AI 会议整理教程。

    信息来源与说明

    本文依据 Microsoft Copilot 官方提示词教程整理并原创改写。不同模型的能力和界面会变化，发布前请在实际产品中测试。