函数调用场景的提示是怎么写的？

让通义千问答天气、查日程，背后多半是函数调用在工作：模型读函数描述，决定调不调、调哪个、参数填什么。函数调用场景的提示，核心就是把函数描述写准，本文拆开它的组成和易错点。

函数调用提示由哪几部分组成

一套完整的函数调用提示通常有三层：系统提示定角色和调用纪律，函数描述列名称、用途、参数结构，用户消息提供当次诉求。模型先理解诉求，再在函数清单里挑匹配项，最后按参数结构填值返回，三层缺一层都会让动作变形。

参数描述怎么写才准

• 类型写死：字符串、数字、布尔，一项一项标清楚。
• 必填可选分明：哪些参数必须有、哪些可以缺省，别让模型猜。
• 取值有枚举就给枚举：比如时间单位只允许「天、小时、分钟」。

在扣子里挂自定义插件时，参数描述含糊是最常见的翻车点，模型只能按自己的理解填，错起来千奇百怪。

调用失败多半卡在哪

• 函数清单太长，模型挑了功能相近但不对的那个。
• 参数描述里有歧义，比如「日期」没说清格式。
• 用户诉求太模糊，模型硬着头皮填了默认值。

系统提示与函数描述的分工

系统提示管纪律：什么情况允许调用、什么情况要先追问用户、解析结果怎么复述。函数描述管事实：函数干什么、参数长什么样。两者别混着写，把「什么时候调」塞进参数说明里，模型反而容易顾此失彼。

结构化结果的解析衔接见结构化输出和后处理解析怎么配合？；JSON 外壳的边界见JSON 模式下还能自然表达吗？；调用前的推演深度见思考预算和提示是怎么配合的？从原理到落地；多步调用怎么防跑偏，见长任务的检查点提示是怎么设的？。

函数描述的语言也有讲究。名称用动宾结构最利于匹配，比如 query_weather、send_email，看名知义；描述里写清「什么时候该用」和「什么时候不该用」，后者常被忽略，却能有效减少误调——比如「仅当用户明确询问过去七天数据时调用，实时数据请用另一个函数」。参数之间有依赖时把依赖写进描述：「传了 start_date 就必须传 end_date」，比让模型事后补错强。多函数场景可以加一个澄清出口：清单里放一个专门的 ask_user，描述写「诉求不匹配任何函数时调用」，给模型一个体面的台阶，硬填错误参数的概率会降下来。清单更新要有节奏，加函数前先评估与现有函数的重叠度，重叠就合并；函数名、参数名在描述与示例里保持一字不差，模型对齐的成本会低很多。

函数提示自检表

• 每个参数都有类型和必填标记吗？
• 函数用途描述会不会互相撞车？
• 系统提示里的调用纪律写了吗？

函数描述是给模型的说明书，说明书清楚了动作才不会变形。

联调阶段建议给每个函数做一次冒烟调用：构造最典型、最边缘各一条用户消息，看模型是否挑对函数、参数是否齐全。两条冒烟通过再放量，函数清单越大的系统越要把这一步做成例行；冒烟记录按函数归档，后续排查时能快速看出哪个函数的描述有先天缺陷。

关于函数调用提示，问得最多的三个

• 模型会自己发明函数吗？：不会，它只能在给定清单里选，清单外它多半选择拒答或追问。
• 函数越多选择越难吗？：是，清单越长越容易挑错，相近功能能合并就合并。
• 参数填错了该怪谁？：先查描述是否有歧义，多数错填源于说明留白而非模型乱填。

一句话收束：调用稳不稳，八成看描述下了多少功夫。