AI先报

博客

  • AI接口教程：用JSON结构化输出和函数调用连接业务系统

    一句话结论：让 AI 接入业务系统时，应把“回答问题”和“调用工具”分开设计：结构化输出负责稳定传递数据，函数调用负责请求外部系统执行动作，最终结果必须由程序校验。

    本文参考 OpenAI 的 Structured Outputs 与 Function Calling 官方文档，适合做客服分流、内容发布、订单查询等原型。工具调用不是让模型直接操作服务器，而是由应用定义工具、校验参数并执行。

    两种能力的区别

    能力 用途 程序要做什么
    结构化输出 把回答变成固定 JSON 按 Schema 校验字段和类型
    函数调用 让模型请求查询或动作 校验参数、执行函数、返回结果

    结构化输出示例

    请把用户问题分类为 JSON：
{
  "intent": "article_search | article_feedback | human_help",
  "keywords": ["关键词"],
  "needs_human": true,
  "reason": "不超过 50 字"
}
规则：只能使用列出的 intent；无法判断时使用 human_help。

    生产接口中不要只依靠提示词约束格式，应使用当前 SDK 支持的 JSON Schema，并处理拒答、截断、解析失败和字段缺失。Schema 的键名和描述要有业务含义，不能把所有可能情况都塞成一个字符串。

    函数调用的闭环

    1. 应用把工具名称、参数 Schema 和用户问题交给模型。
    2. 模型返回工具调用请求，而不是直接执行。
    3. 应用验证参数、权限和资源范围，再调用真实函数。
    4. 应用把工具结果回传给模型，让它生成用户可读的答复。
    5. 记录调用日志，并对写入、删除、付款等高风险动作增加人工确认。

    安全设计要点

    工具参数不能绕过权限检查；用户输入不能直接拼接 SQL、Shell 或文件路径；写操作要做幂等、审计和超时；外部结果也要当作不可信数据处理。模型说“已发布”不等于系统真的发布，界面应以工具实际返回的状态为准。

    常见问题

    结构化输出等于函数调用吗？

    不等于。前者约束数据格式，后者建立模型与应用函数之间的交互流程。

    模型会自动执行函数吗？

    不会。应用需要接收调用请求、校验并执行，之后再把结果返回给模型。

    为什么还要做 Schema 校验？

    提示词不是程序级约束，Schema 和代码校验能更早发现类型、枚举和字段问题。

    哪些工具需要人工确认？

    发布、删除、付款、改权限和发送外部消息等不可逆或高影响动作，建议确认后执行。

    如何开始做第一个原型？

    先做只读查询，固定 3 个测试问题，记录成功和失败，再逐步加入写操作。

    \n

    信息来源与说明

    本文参考 OpenAI Structured Outputs 指南和 OpenAI Function Calling 指南整理。接口参数和 SDK 写法应以当前官方文档为准。

  • AI视频分析教程：让Gemini按时间戳提取视频重点

    一句话结论：做 AI 视频分析时，要在提示词里写清时间范围、关注对象和输出格式；需要定位片段时，要求按时间戳给出事件和依据。

    这篇教程依据 Google Gemini 视频理解文档整理，适合课程回顾、产品演示复盘和公开视频内容提要。视频分析结果仍需要抽样回看，尤其是快速动作、画面文字和多人对话。

    时间戳提取模板

    请分析这段视频，输出 Markdown 表格：时间段 | 发生的事件 | 关键人物或物体 | 证据说明。
要求：
1. 使用 mm:ss-mm:ss 格式；
2. 只记录能够从视频确认的事件；
3. 对不确定内容写“无法确认”；
4. 最后给出 5 条重点和 3 个需要人工复核的片段。
重点关注：产品演示中的操作顺序、错误提示和最终结果。

    分层分析方法

    1. 先做全片概览，确认视频主题和章节。
    2. 再按时间段提取事件，避免只依赖一段长摘要。
    3. 对关键片段提出第二轮问题，例如“00:35 到 00:52 出现了哪些界面变化”。
    4. 把视频结论与字幕、脚本或产品日志交叉核对。

    静态采样的限制

    视频理解可能按照采样帧分析画面，快速动作可能在采样间隔中被遗漏；声音、字幕、分辨率和画面复杂度也会影响结果。对安全事故、体育细节或快速操作，必须回看原视频，不要仅凭摘要下结论。

    如何写更准确的任务

    不要只说“总结视频”，而要说明读者、时间粒度和输出目的。例如课程复盘要关注知识点和练习，广告审核要关注品牌露出和违规风险，产品演示要关注点击顺序和报错信息。不同目标应使用不同提示词。

    常见问题

    AI 能准确指出每个动作的时间吗？

    不能保证。时间戳通常是近似定位，需要人工回看关键片段。

    视频越长越好吗？

    不一定。长视频应先分章节或缩小问题范围，便于复核和控制成本。

    能同时分析声音和画面吗？

    具体能力取决于模型、文件和当前接口支持，应先用小样本验证。

    如何分析一节课程？

    让模型输出章节、关键概念、示例、练习和时间戳，再由讲师检查术语。

    可以把视频摘要当成事实记录吗？

    不可以。摘要是模型生成结果，关键事实要回到视频或原始记录。

    信息来源与说明

    本文参考 Google Gemini 官方视频理解文档整理。支持的模型、文件方式和长度限制可能变化，请以官方文档为准。

  • AI语音转文字教程：把录音整理成可编辑的会议初稿

    一句话结论：AI 语音转文字最适合先生成可编辑的会议初稿，再用原音频、参会名单和上下文核对专有名词、数字、日期与发言人。

    本文基于 OpenAI Speech-to-text 官方文档，演示如何把录音整理成会议材料。转写不是录音证据的替代品，涉及合同、承诺和责任归属时必须回听原音频。

    推荐的处理流程

    1. 确认参会者已知悉录音和处理用途。
    2. 分割过长音频，并保留原始文件和时间信息。
    3. 先获取逐字转写，再让 AI 生成摘要和待办。
    4. 让模型标注听不清的片段，不要自动补全。
    5. 由会议主持人核对最终版本后再分发。

    会议整理提示词

    请把下面的会议转写整理为：
1. 100 字以内摘要；
2. 已作出的决定；
3. 待办表格：任务、负责人、截止日期、依据原句；
4. 待确认问题；
5. 需要回听的时间段。
规则：不得把建议写成决定；转写中没有负责人或日期时填“待确认”。

    为什么要分两步

    先转写再整理，能把原始文本和总结分开保存。若直接让模型“听完告诉我结论”，很难追溯某条待办来自哪里。对中文姓名、品牌、技术名词和数字，要提供词汇表或在转写后人工搜索核对。

    实时转写和异步转写

    需要字幕或实时提示时，可使用支持流式返回的方案；需要完整会议纪要时，异步处理更容易保存和复核。网络中断、音频质量和说话人重叠都会造成缺字，应用应设计重试和人工补录。

    常见问题

    转写能做到百分之百准确吗？

    不能。口音、噪声、多人抢话和专有名词都会影响结果。

    可以直接把会议纪要发给客户吗？

    不建议未经审核直接发送。先确认事实、措辞、敏感信息和责任归属。

    怎样处理听不清的内容？

    标记时间段并输出“无法确认”，回听原音频或请参会者补充。

    录音中有隐私信息怎么办？

    遵循最小化原则，确认授权、访问控制、存储位置和删除周期。

    多语言会议怎么做？

    先测试语言识别和专有名词表现，必要时按语言分段，并人工检查翻译。

    信息来源与说明

    本文参考 OpenAI Speech-to-text 官方文档整理。模型、文件限制、流式能力和价格可能调整，请以官方当前说明为准。

  • AI图片识别教程：用视觉模型读取图片并输出结构化结果

    一句话结论：让 AI 识别图片时，应同时说明观察目标、输出字段、未知值处理方式和证据要求；如果要交给程序使用，优先要求结构化 JSON 并在程序端校验。

    这篇教程依据 OpenAI 图像与视觉文档整理，适用于票据初步整理、截图分析、产品照片分类和图表读取。视觉模型可能看错小字、遮挡内容和复杂图表，结果不能替代人工审核。

    识图任务的四项说明

    • 目标：是描述、分类、读取文字，还是找出异常。
    • 范围：只看整图，还是指定某个区域。
    • 输出：自然语言、表格或 JSON。
    • 不确定性：看不清时输出 null 或“无法确认”，不要猜。

    可复制的识图提示词

    请分析这张商品图片，只依据可见内容回答。
输出 JSON，字段为：
{
  "product_name": "商品名称，无法确认时为 null",
  "visible_text": ["图片中能准确读出的文字"],
  "main_colors": ["主要颜色"],
  "scene": "场景描述",
  "uncertainties": ["看不清或无法确认的内容"]
}
不要臆测品牌、价格、型号或图片外的信息。

    如何提高识别质量

    1. 上传清晰、方向正确的原图，避免反复压缩。
    2. 告诉模型需要读哪一块区域，复杂图片可以裁剪后分别分析。
    3. 先让模型描述可见事实，再做分类或判断，减少一步到位的猜测。
    4. 在代码中校验 JSON 字段和类型，解析失败时记录原始响应并进入人工队列。

    图像识别的边界

    图片里的微小文字、模糊号码、遮挡部分、复杂表格和医学影像都可能被误读。不要让模型单独决定付款、身份、医疗处置或安全告警。涉及个人照片和证件时，先确认授权、保存周期和访问权限。

    常见问题

    为什么要要求 JSON？

    固定字段便于程序消费和批量处理，但仍要在服务端用 JSON Schema 或代码再次校验。

    模型能读取任何图片文字吗？

    不能。分辨率、字体、反光、旋转和遮挡都会影响识别。

    一张图识别不准怎么办？

    裁剪目标区域、提高分辨率、补充任务说明，并让模型列出不确定字段。

    能让 AI 判断图片真假吗？

    不能仅凭一次视觉回答下结论。真伪鉴定通常需要来源、元数据和专业检测。

    是否需要记录模型版本？

    需要。生产系统应记录模型、输入、提示词、时间和人工修正，便于复盘。

    信息来源与说明

    本文参考 OpenAI Images and Vision 官方文档整理。实际支持的图片格式、尺寸和费用以当前 API 文档为准。

  • AI绘图教程：按照Adobe Firefly指南写出更准确的图像提示词

    一句话结论：AI 绘图提示词应优先写清主体、场景、构图和视觉风格；越具体的画面描述，越容易得到可比较、可迭代的结果。

    本教程按照 Adobe Firefly 官方关于有效文本提示的思路整理。不同生图模型对词语的理解不同，下面的结构适合用来建立第一版提示词，不代表每次都能得到完全相同的画面。

    四个维度写画面

    维度 要写什么 示例
    主体 人物、物品或动物 一盏放在木桌上的台灯
    环境 地点、时间、天气 安静的北欧书房，清晨
    视觉 材质、颜色、光线、镜头 暖色自然光，浅景深，产品摄影
    构图 视角、比例和主体位置 正面三分之二构图，留出右侧文案空间

    可直接改写的提示词

    一盏极简白色台灯，放在浅色橡木书桌上，北欧风格书房，清晨的柔和自然光，桌面有一本打开的笔记本和一杯咖啡，产品摄影，细节清晰，背景干净，主体位于左侧，右侧留白，横向画幅。

    从宽泛到具体

    “画一个好看的台灯”只说明了主体和主观评价；改成“白色极简台灯、橡木桌面、清晨自然光、产品摄影、右侧留白”，模型才有足够的画面线索。第一次不要同时塞入十几种互相冲突的风格，先固定主体和构图，再逐项调整颜色、材质和镜头。

    迭代方法

    1. 第一版只确定主体、环境和构图。
    2. 第二版只修改光线或色彩。
    3. 第三版再加入材质、镜头和商业用途。
    4. 保留每一版提示词和结果，比较哪一个词真正改变了画面。

    涉及人物肖像、商标、版权角色或真实客户素材时，要确认使用授权；AI 生成的文字、手指、标志和细小细节仍可能出错，需要人工检查。

    常见问题

    提示词必须写“生成一张”吗？

    不必须。直接描述画面往往更简洁，具体产品可按平台界面测试。

    风格词越多越好吗？

    不是。相互冲突的风格会让结果不稳定，建议一次只调整一组风格变量。

    如何生成适合文章的配图？

    说明横竖比例、主体位置和留白区域，同时要求画面不要出现难以控制的文字。

    为什么生成的字经常不对？

    许多生图模型对小字和长句支持有限。可以留白后用设计软件添加文字。

    能保证每次结果一致吗？

    不能。模型、版本、随机种子和参数都会影响结果；重要素材要保存源文件和参数。

    信息来源与说明

    本文参考 Adobe Firefly 官方有效提示词教程整理。商业使用前请查看具体服务条款和素材授权范围。

  • GitHub Copilot编程教程：从需求拆分到测试验证的提示词方法

    一句话结论：使用 GitHub Copilot 编程时，先给目标和相关文件，再把复杂需求拆成小任务，并要求测试和验证，比只输入一句“帮我写代码”更可靠。

    本文根据 GitHub 官方提示工程建议整理，适用于 Copilot Chat、代码解释和重构场景。代码建议必须经过本地测试、代码审查和安全检查，不能把模型输出直接当成可上线代码。

    一条可复用的编程提示词

    目标：为用户列表增加按邮箱搜索功能。
项目背景：这是一个已有的 TypeScript Web 项目，搜索结果需要分页。
相关文件：请先阅读 src/users、src/api/users.ts 和现有测试目录。
要求：
1. 先说明修改计划，不立即改动无关文件。
2. 保持现有 API 返回格式兼容。
3. 为空输入、大小写和分页边界增加测试。
4. 完成后列出修改文件、运行的测试和仍需人工确认的风险。

    推荐工作流

    1. 先问项目：让 Copilot 解释目录、入口和现有约定。
    2. 再拆需求：把接口、数据层、界面和测试分成独立任务。
    3. 限定范围：明确允许修改的文件，避免无关重构。
    4. 边写边测：每完成一个小任务就运行对应测试。
    5. 最后审查：检查鉴权、输入校验、错误处理和依赖变化。

    如何减少歧义

    告诉 Copilot 现有框架、语言版本、命名约定和不能破坏的兼容性。遇到报错时，附上完整错误、触发步骤和相关代码片段，不要只说“它坏了”。如果模型给出多个方案，先让它比较取舍，再选择一个实现。

    测试提示词示例

    请为刚才的搜索函数补充测试：
- 正常匹配一条和多条结果；
- 无匹配结果；
- 大小写差异；
- 空字符串和超长输入；
- 第 1 页、第 0 页和超出总页数。
只修改测试文件，并说明每个用例验证的行为。

    常见问题

    Copilot 能替代代码审查吗？

    不能。它可以辅助解释和生成测试，但安全、权限、性能和业务正确性仍需开发者审查。

    提示词要把整个项目都贴进去吗？

    不需要。先指定相关目录和文件，提供完成任务所需的最小上下文。

    遇到连续错误怎么办？

    停止重复生成，回到最小复现，提供错误日志和当前实现，让模型先定位原因。

    如何避免无关重构？

    明确“只修改这些文件”“保持公共接口不变”，并要求先输出计划。

    AI 写的依赖能直接安装吗？

    不能直接信任。检查许可证、版本、漏洞和是否真的解决问题。

    信息来源与说明

    本文参考 GitHub Copilot 官方提示工程文档整理。具体快捷键和产品能力会随 IDE 与版本变化。

  • 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 官方提示词教程整理并原创改写。不同模型的能力和界面会变化，发布前请在实际产品中测试。