← 返回概念解读

Concept Fable精修版

语义函数

Semantic Function · Prompt/function abstraction

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

可以被调用的一段吩咐

老厨房里有两种活。切菜、称盐、点火都有固定手法;写宴席菜单却靠大厨用话讲给学徒听。两类活分开做,勉强也能出菜。

后来宴席越来越复杂。账房想把菜单生成接到订货表,前厅想把客人口味接到菜谱,厨房却只会说:让大厨再讲一遍。

有人把大厨的话抄成一整页贴在墙上。每次要改口味、人数或预算,学徒就手工改几句。贴纸越改越乱,没人知道哪句是变量,哪句是规矩。

又有人把所有菜单都写成硬代码。这样稳定,却失去了语言的灵活性。客人说少油、避辣、适合老人,代码表很快膨胀。

新来的管事把大厨常说的那段吩咐装进一个小木盒。盒子有名字,有输入格:人数、预算、忌口、菜系。给它这些东西,它就按那段吩咐生成菜单。

旁边还有普通工具盒,能查库存、算成本、打印采购单。管事把两类盒子排在一条线上:先用语言盒出方案,再用普通工具盒校验和执行。

学徒发现,语言不再只是贴在墙上的提示,也不是藏在代码里的特例。它变成了可以被调用、组合和复用的厨房能力。

管事仍然限制盒子的用途。菜单盒不能直接下采购单,采购盒也不能擅自改客人口味。每个盒子有清楚的输入、输出和边界。大厨说:当一段自然语言吩咐能像函数一样被命名、传参和组合,它就从口头经验变成了系统部件。后来厨房又做了一个宴席改写盒。前厅给它客人偏好,它只产出菜单建议;账房给采购盒预算,它只算成本。管事不许两个盒子越界,因为一旦菜单盒能直接买菜,错一句话就会变成一车错货。厨房因此既保留了语言的弹性,又让每段吩咐有固定入口、出口和责任范围。后来学徒给每个盒子写了示例输入和错误输出。新厨师接手时,不必猜大厨口气,也能知道这段吩咐该怎样使用。能被调用,也要能被约束。

揭示

这个故事讲的是:语义函数

Semantic Function 是把提示词或自然语言指令包装成可调用单元的抽象,常见于 Semantic Kernel。它像函数一样有名称、输入和输出,可以和 native function、plugin、planner 组合。它的价值在于把提示词从散落文本变成工程化能力,但仍需要版本管理、输入约束、评测和权限边界。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 大厨口头吩咐:自然语言 prompt
  • 墙上的贴纸:不可维护的散落提示词
  • 硬代码菜单:失去语言弹性的纯程序逻辑
  • 有输入格的小木盒:Semantic Function
  • 人数、预算、忌口:函数输入变量
  • 库存、成本、采购盒:native functions 或普通工具
  • 排成一条线:语义函数与代码函数组合编排
  • 最后洞察:Semantic Function 把提示词封装成可调用、可组合的系统能力

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

Semantic Kernelnative functionpluginprompt templateplanner