博客

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

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

两种能力的区别

结构化输出示例

请把用户问题分类为 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 语音转文字最适合先生成可编辑的会议初稿，再用原音频、参会名单和上下文核对专有名词、数字、日期与发言人。

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

推荐的处理流程

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

会议整理提示词

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

为什么要分两步

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

实时转写和异步转写

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

常见问题

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

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

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

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

怎样处理听不清的内容？

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

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

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

多语言会议怎么做？

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

信息来源与说明

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

一句话结论：让 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 文档为准。