前言：

 function 是 AI 测试 / 质量的“抓手点”，没有 function，就没有可测性。
因为没有 function ，LLM 就相当于黑盒。

因为：没有固定输入输出结构，没有明确责任边界，没有稳定失败模式

你怎么测？
测 prompt？（不稳定）
测模型？（不可控）
测结果？（不可复现）

而 function 一旦立住：
schema = 测试契约
调用条件 = 测试用例
fallback = 异常路径
👉 AI 才第一次“像系统”。

所以在真正动手之前，反而要花了不少时间在一件事上，是一定要：

到底什么样的输入，才“配得上”触发一次 Function Calling？

这个问题如果一开始不想清楚，后面系统一定会乱。

一、确定工作中的输入

首先做一件事：
不写代码，先把我平时真实会对系统说的话列出来。

比如下面这些，都是工作中非常常见的输入：

• 今天写商场项目 0.8 版本用例

• WMS项目 0.6 版本用例执行，提 bug

• 教育系统 0.8 版本用例评审，WMS项目回归测试

• 千佳项目接口测试

• 千佳项目压力测试

• 远程协助编辑器客户使用

也有一些非常真实但更危险的输入：

• 写用例了，烦死了

• 今天好像没干啥呢

• 不知道写什么

• 开发接口不行

• 我写日报了吗，我靠

如果你只在教程里看 Function Calling，这些输入几乎不会出现；
但在实际工作里，它们每天都会出现。

二、一个关键认知：不是每句话都该触发 Function

我一开始也犯过一个典型错误：

看到像“工作内容”的话，就想让系统记下来。

但很快发现不对。

因为 AI 系统里，一旦脏数据进了事实层，后面所有总结、整理、日报都会一起变脏。

于是立了一个非常简单、但很严格的原则：

只有“干净、可复用的事实”，才能触发 Function Calling。

三、最终采用的输入分类方式

我没有做复杂的 NLP 分类，只做了工程可控的几类。

1️⃣ 必须触发 Function 的：事实碎片

这一类输入有一个共同点：
不带情绪、不带评价，只是在陈述“我做了什么”。

例如：

• 今天写WMS项目 0.8 版本用例

• 千佳项目 0.6 版本用例执行，提 bug

• 下午在跑回归

• 远程协助编辑器客户使用

这类输入，我统一认为是：

事实原料（Fragment）

它们的唯一去处，就是触发类似 record_fragment 的 Function。

2️⃣ 看起来像工作，但我选择「不触发」的输入

下面这些句子，非常容易被误判：

• 写用例了，烦死了

• 今天好像没干啥呢

• 不知道写什么

• 开发接口不行

它们的问题不在于“不真实”，而在于：

• 混杂了强情绪

• 或者只是主观评价

• 没法作为稳定、可复用的事实

我在 v1.0 里选择了一个很保守的策略：

宁可不记，也不要记脏。

3️⃣ 查询类输入，不等于“可以生成”

还有一类输入也很常见：

• 我打卡了吗

• 我今天都干了啥

• 我写日报了吗

这类输入，本质是查询或困惑，而不是“生成指令”。

所以我把它们拆得很清楚：

• 查询 → 只查状态 / 事实

• 生成 → 必须显式确认

否则系统很容易“越权”，开始自作聪明。

四、这一步没写一行代码，但决定了系统上限

到这里，其实还一行代码都没写。

但已经明确了三件非常重要的事：

1. 哪些输入 允许 触发 Function

2. 哪些输入 必须兜底

3. 哪些输入 看起来合理，但现在不能做

后面再写代码时，只是把这套分类严格翻译成程序行为，而不是一边写一边猜。

五、小结：Function Calling 真正难的不是“会用”

很多教程会教你：

• 怎么写 schema

• 怎么接 API

• 怎么让模型调用函数

但在实际项目里，更难的是这一层：

什么时候，不该让模型动手。

对我来说，这次最大的收获不是“Agent 跑起来了”，
而是终于把一句模糊的话想清楚了：

AI 系统里，输入边界 = 系统质量的上限。

下一篇要基于现在这份funtion 开始代码实现了！