考察点
这道题看似琐碎，实际是工具调用准确率的胜负手，面试官想听你把「写描述」当成一门有方法论的活，而不是随手填一句注释。追问方向：描述里能不能写示例、多个相似工具怎么区分、怎么验证描述效果。
参考答案
先明确描述写给谁看
模型在选工具时能看到的信息只有三样：工具名、描述、参数 schema。它不看你的代码，不看你的 wiki。所以 description 的本质是一行给模型的路由指令，评判标准只有一个：在正确的场景被选中，在错误的场景被跳过。
四段式写法
我评审团队工具描述时要求覆盖四个要素，通常两到四句话：
- 干什么：动词开头，说清动作和对象。「按订单号查询订单的当前状态、金额和物流单号」。避免「订单相关接口」这种什么都没说的写法。
- 何时用：给出触发线索，这是提高命中率的关键。「当用户询问订单进度、是否发货、要退款时使用」。
- 何时不用：划清和相邻工具的边界，这是降低误调率的关键。「不负责修改订单；用户要取消或改地址时用
update_order」。相似工具多的时候，这句话比前两段都重要。 - 参数与返回的硬约束：格式（「order_id 为 16 位纯数字，不含前缀」）、缺省行为（「不传 days 默认查最近 7 天」）、返回内容概要。
一个合格示例：
按订单号查询订单状态、金额与物流信息。
适用：用户询问订单进度、发货状态、退款前确认订单情况。
不适用：修改或取消订单（用 update_order）；批量导出（用 export_orders）。
order_id 为 16 位纯数字；返回包含 status、amount、tracking_no。
容易踩的坑
写得太短：「查询订单」四个字，模型只能靠名字猜，和相似工具的区分度为零。写得太长：几百字的使用手册塞进 description，几十个工具累积起来上下文成本可观，而且关键信息被稀释。写实现细节：「内部调用 ERP 系统的 /v2/query 接口」对模型决策毫无帮助。近义工具不互提：get_order 和 query_order 同时存在且描述雷同，模型基本掷硬币，要么合并要么在描述里明确分工。
参数复杂时上示例
对参数结构复杂的工具（嵌套对象、多种组合），在描述或参数说明里加一个简短调用示例效果显著，比如一个 JSON 样例。但要控制长度——示例每次都进上下文，一个就够，别把 schema 文档复述一遍。
用数据迭代，不靠感觉
上线后埋点统计每个工具的命中率：该调没调（漏召）、不该调调了（误召）、参数填错（填参失败）。误召高就加强「何时不用」，漏召高就补充触发线索，填参失败高就收紧参数约束或补示例。描述迭代几次，准确率能肉眼可见地涨。改描述等于改接口行为，每版描述变更都要过一遍评测集再放行。
可能的追问
- 描述写进 system prompt 一样的规则有用吗？ 部分有用，但优先级低于 system prompt。全局规则（比如「涉及金额必须二次确认」）放系统提示，工具局部规则放描述，别混。
- 模型老是在两个工具间选错，除了改描述还能干什么？ 先检查是不是该合并成一个工具；不能合并就把决策差异做成参数（一个工具加 mode 枚举）；还可以用 few-shot 对话示例演示区分场景。
- 多语言场景描述用什么语言写？ 用模型的主要训练语言（通常英文）写描述往往更稳，中文触发线索可以作为补充写进去，实测对比再定。