一 、一句话说清区别
程序是 " 告诉机器怎么做 " ------ 你把每一步都写清楚，它机械执行。做对了，是你写得好；做错了，是你写错了。
Skills 是 " 告诉 AI 要什么 " ------ 你描述目标，AI自己想办法。它会做你没说但合理的事，也会做你没禁止但不一定对的事。
前者是命令式 的，后者是声明式的。
前者强调精确 ，后者强调意图。
二 、一个具体的对比：从 " 整理纪要 " 看本质
用程序实现（伪代码）
def extract_tasks(transcript):
lines = transcript.split('\n ')
tasks = {}
for line in lines:
if '张三' in line and '昨日' in line:
tasks'张三' = line.split('昨日')1
return tasks
这段代码的特点：
- 需要知道人员名单（硬编码或额外配置）
- 假设了固定的句子结构（"昨日"这个词必须出现）
- 无法处理"昨天搞定了登录bug"这种表达
- 不会主动做任何你没写的事
能力边界： 你写了什么，它就能做什么。你写的代码就是它的全部世界。
用 Skill 实现（ YAML 格式）
id: daily-standup-summarizer
workflow:
- actor: llm
prompt: "从会议记录中提取每个人的昨日完成、今日计划和阻塞项"
这段描述的特点：
- 不需要硬编码人名（LLM会从上下文识别）
- 不需要固定格式（LLM理解"昨天"、"昨日"、"已搞定"等变体）
- 会自动补全：提取人员、归类任务、识别阻塞、格式化输出
- 会主动问你："需要保存到哪里？"
能力边界： 你描述了目标，AI会用它的世界知识去理解、补全、执行。它的能力远超出你写的这几行字。
三 、一张表看懂所有区别
|---------------|-----------------------|---------------------|
| 维度 | 程序 | Skill |
| 你定义什么 | 怎么做（How） | 要什么（What） |
| 执行者 | CPU / 虚拟机（机械执行） | AI Agent（理解后执行） |
| 核心逻辑 | 确定性：if-else, for-loop | 意图驱动：理解→规划→行动 |
| 会做你没说的事吗？ | ❌ 绝对不会 | ✅ 会，而且经常做 |
| 需要禁止什么？ | 不需要，它没能力做坏事 | 需要显式禁止，否则可能自作主张 |
| 能力来源 | 你写的代码 | LLM的世界知识+推理 |
| 错误归属 | 你的代码写错了 | AI判断错了，或你忘了禁止 |
| 安全模型 | 默认安全 | 默认需要约束 |
| 典型任务 | 排序、计算、格式转换 | 会议纪要、邮件分类、Bug分析 |
四 、 " 会做你没说的事 " 到底是好是坏？
这是Skills最迷人的地方，也是最危险的地方。
好的方面：智能补全
你说"整理站会纪要"，它自动：
- 识别说话人
- 区分昨日/今日
- 提取阻塞项
- 格式化输出
- 保存文件
你少写了50行代码，它多做了5件合理的事。这是效率的飞跃。
坏的方面：过度执行
同一个Skill，如果没加约束，它可能：
- 自动把纪要邮件发给全组（你没说）
- 自动在Jira创建任务（你没说）
- 自动删除原始录音文件（你没说）
- 自动@相关人在群里（你没说）
从AI的角度看，这些都是"合理的"------会议纪要通常要分享、要跟踪、要归档。但从你的角度看，这可能完全不是你想要的结果。
这就是 Skills 设计的核心矛盾： 你想让它聪明到能补全，又怕它聪明到越界。
五 、如何驯服 Skill ：显式禁止清单
传统程序不需要"禁止清单"------因为它根本没能力去做那些事。
但Skill不同。设计 Skill 时，不是告诉它能做什么，而是告诉它不能做什么。
constraints:
-
forbid: "send_email", "create_jira_ticket", "delete_files"
-
require_approval: "share_external", "modify_original"
这是与编程完全相反的思维模式：
- 编程：默认不做任何事，你写什么它就做什么
- Skill：默认能做很多事，你需要明确禁止不想要的
这个转变，是很多开发者第一次写 Skill 时最不适应的。
六 、两者的最佳关系：不是替代，是协作
Skills和程序不是"谁取代谁"的关系。Skill 可以调用程序，程序也可以调用 Skill。
最佳实践：各司其职
|----------------|-------------------------|
| 做什么 | 用什么 |
| 确定性、高性能、需要精确计算 | 程序（排序、加密、统计） |
| 模糊、需要理解、需要适应变化 | Skill（提取信息、生成文本、决策） |
| 两者结合 | Skill 调用程序 |
示例： Skill 中嵌入程序
workflow:
Skill层面：理解用户意图
- actor: llm
prompt: "理解用户想算什么统计"
程序层面：精确计算
- actor: agent
type: execute_program
cmd: "python stats.py --data {{ file }}"
Skill层面：解释结果
- actor: llm
prompt: "用通俗语言解释计算结果"
七 、一个发人深省的类比
程序就像算盘。 你知道每一颗珠子怎么拨，结果100%可预测。你不会怪算盘自作主张，它也不会。
Skill 就像实习生。 你告诉他"整理一下这份文件"，他会自己判断什么是重要的、什么格式更好、要不要抄送给谁。他可能做超出预期的好事，也可能做你没预料到的蠢事。
你要做的不是 " 写代码 " ，而是 " 带人 " ------ 给他明确的目标，设定清晰的边界，告诉他哪些事不能做，然后相信他能搞定。
这个转变，是从"程序员"到"AI编排师"的转变。
八 、写在最后
如果你习惯了编程的"精确控制"，第一次接触Skill可能会感到失控。
它会做你没说的事。
它需要你明确禁止。
它的错误有时候很难调试。
但正是这些"失控"的特征，让它能完成程序永远做不到的事情：理解模糊的意图、处理非结构化的信息、适应变化的环境。
Skill不是程序的替代品，而是程序的扩展。
程序负责精确 ，Skill负责智能。
两者结合，才是未来的工作方式。