在 AI 应用开发乃至日常逻辑思考中，我们经常混淆两个看似相似却截然不同的概念：程序与Skill。

有人认为 Skill 是高级程序，也有人视其为调用程序的配置文件。这些理解虽有道理，但未能触及本质。仔细辨析，便会发现：两者的核心分野，在于对 “确定性” 与 “经验性” 的管辖权归属。

若不清晰划定这条边界，系统设计便极易陷入 “AI 幻觉制造灾难” 或 “代码臃肿无法维护” 的双重困境。

一、 本质分野：死命令与活判断

在 AI 语境下，我们必须打破传统的软件工程定义：

程序：是确定性逻辑的忠实执行者。它是写死的指令序列，输入 A，经过预设流程，必然输出 B。它机械、可靠、不知疲倦，但也绝不懂得变通。

LLM + Skill：是经验型逻辑的动态调度者。Skill 本身是一个包含了目标、知识库、工具权限和决策偏好的智能代理配置，而 LLM 则是驱动这个配置的核心引擎。

程序是刻在石板上的律法，不可逾越；Skill 是交到智者手中的权杖，见机行事。

二、 为什么绝对不能搞反？

架构设计的最高心法是：“确定性输出交给程序，经验型处理交给 LLM，绝不能搞反。” 这不仅是原则，更是无数实践后的深刻洞见。

1. 如果把确定性逻辑交给 LLM（让诗人去算账）：

LLM 的本质是概率预测，它擅长 “猜” 下一个词，而非执行精确运算。让它去计算税费、操作退款或校验数据格式，结果只有一个 ——幻觉。它可能会自信地给出错误答案，或在未满足条件时 “大发慈悲” 执行操作。

2. 如果把经验型逻辑写成代码（让计算器去写诗）：

现实世界的语义是无限发散的。试图用 if-else 穷举人类所有的表达方式（如判断用户情绪），代码会迅速陷入难以维护的臃肿困境。今天增加关键词，明天补充正则，永远跟不上语言的变化。

三、 协作之道：脑与手的辩证法

既然不能搞反，正确的协作方式是什么？

我们可以将 Skill 架构抽象为一套 “脑 - 手” 模型 ：

LLM + Skill = 大脑：负责理解模糊意图、规划实现路径、判断何时调用何种工具。它处理的是 “做什么” 和 “为什么做”。

程序 + API = 双手：负责执行具体动作，如读写数据库、计算哈希值、发送 HTTP 请求。它处理的是 “怎么做”。

为确保 “脑” 与 “手” 协同工作，两者间需以结构化输出作为 “翻译官”：

手（程序） 明确接口：“我仅接受 { action: "search", query: "string" } 格式的指令。”

脑（LLM） 理解用户需求（如 “外面热不热”），并翻译为结构化指令：{ action: "search", query: "当前室外温度" }。

手（程序） 执行确定动作，返回确定数据。

如此，程序的确定性便成为 AI 非确定性的安全护栏。LLM 再天马行空，最终也只能输出结构化指令，越权行为在程序执行层被有效隔绝。

设计系统时，请时刻画好这条线：

凡是必须正确的事情（如计算、存储、流程控制），锁死在代码里。

凡是对错难分的事情（如察言观色、遣词造句、策略择优），托付给模型。

别试图让螺丝刀去思考，也别试图让哲学家去拧螺丝。各安其位，方得始终。