Prompt 标准与 Skill 体系
Q：如果让你从零设计一个 Skill 系统，需要实现哪些核心能力？
来源：字节 Agent 开发实习一面 【蚂蚁AI应用开发二面追问：单一 Skill 模块设计思路】【阿里国际AI应用开发二面追问：多Skill可见时如何保证执行顺序 + Plan模式协调机制】【阿里国际大模型应用开发一面追问：Skill自我迭代机制本质 + Skill质量评测方法】【字节火山引擎 Managed Agent 一面追问：按开发、测试、运维组织 Skills】
新手答：“写个插件系统，注册回调函数。”
高手答：
Skill 系统的设计和传统插件系统有本质区别——Skill 不是代码，是知识；调用不是函数执行，是上下文注入。围绕这个核心理念，需要实现三个核心能力：
整体架构
核心能力一：注册（Registration）
基于文件系统的注册，不需要服务器和数据库：
skills/
├── code-review/
│ ├── config.yaml # 名称、描述、触发条件、参数定义
│ └── skill.md # Skill 内容（领域知识 + 执行流程）
├── deploy-check/
│ ├── config.yaml
│ └── skill.md
└── ...config 中定义的关键字段：
- name：Skill 的唯一标识
- description：用于发现匹配的描述（这个字段至关重要，直接决定匹配质量）
- triggers：触发条件（关键词、正则、显式命令）
- args_schema：Skill 接受的参数定义
设计要点：纯文件系统，支持热重载——新增或修改 Skill 文件后立即生效，不需要重启服务。
核心能力二：发现（Discovery）
当用户输入到达时，快速匹配最相关的 Skill：
| 匹配策略 | 实现方式 | 适用场景 |
|---|---|---|
| 显式调用 | 用户输入 /skill-name | 用户明确知道要用哪个 Skill |
| 关键词匹配 | 正则或关键词命中触发条件 | 简单直接，零延迟 |
| 语义匹配 | 用 embedding 计算输入与 Skill 描述的相似度 | 更智能，但有延迟开销 |
发现过程必须快——每条用户消息都要扫描所有 Skill 的触发条件，延迟必须可忽略。所以关键词匹配是首选，语义匹配作为兜底。
核心能力三：调用（Invocation）
匹配到 Skill 后，执行的不是函数调用，而是上下文注入：
- 读取 Skill 的 .md 内容
- 如果 Skill 定义了参数，解析用户输入中的参数值
- 将 Skill 内容注入到模型的上下文中——Skill 的知识变成模型在本次会话中的“专业背景”
- 模型在 Skill 知识的指导下完成任务
关键认知：Skill 调用不是函数调用，是上下文注入。 Skill 不是“执行一段代码然后返回结果”，而是“把一段领域知识注入模型的认知中，影响模型后续的所有行为”。
设计时必须考虑的问题
| 问题 | 解决方案 |
|---|---|
| 命名空间冲突 | 两个 Skill 触发条件相似时，需要优先级机制（权重或显式排序） |
| 多 Skill 组合 | 复杂任务可能需要同时激活多个 Skill，需要定义组合规则和上下文拼接顺序 |
| 生命周期管理 | Skill 的影响何时结束？一次任务后？整个会话？需要明确的作用域定义 |
| Skill 级评测 | 每个 Skill 需要自己的评测集，验证注入 Skill 后模型行为是否符合预期 |
| 上下文预算 | 多个 Skill 同时加载可能撑爆上下文窗口，需要按优先级裁剪 |
差距在哪：新手按照传统插件系统的思路来设计——注册回调函数、执行代码逻辑。高手理解 Skill 系统的本质是基于文件的知识管理 + 触发式发现 + 上下文注入，和传统插件系统（代码注册 + 函数调用 + 返回结果）在架构理念上完全不同。面试官考的是你能不能跳出”一切皆代码”的思维定式，理解 LLM 时代”知识即能力”的新范式。
追问：手撕一个 Skill 系统——实现注册、发现和调用
来源：字节抖音 Agent 开发一面
题目要求：目录结构为 .agents/skills/ 下每个 Skill 一个子目录，包含 .yaml 配置文件和 scripts/*.js 执行脚本。
这道手撕题的关键不是写多少代码，而是设计清晰的三层抽象：
注册（Registration）：扫描 .agents/skills/ 目录，解析每个子目录的 yaml 配置，建立 Skill 注册表
发现（Discovery）：根据用户输入匹配 Skill 的触发条件（关键词/意图/正则）
调用（Invocation）：加载匹配 Skill 的内容（知识注入）或执行脚本（动作执行）yaml 配置文件设计：
name: deploy-checker
description: 检查部署状态并报告异常
triggers:
- pattern: “检查部署|部署状态|上线情况”
type: regex
scripts:
- scripts/check_status.js
- scripts/report.js
context: |
你是一个部署检查专家，擅长分析 CI/CD 管线状态...核心实现思路（伪代码）：
1. 注册：启动时递归扫描 .agents/skills/*/，
解析 yaml → 建立 Map<name, SkillConfig>
2. 发现：用户输入到来时，遍历注册表，
逐个匹配 triggers（正则/关键词/语义相似度）
→ 返回匹配度最高的 Skill（或 top-K）
3. 调用：
- 如果 Skill 有 context 字段 → 注入上下文（知识型 Skill）
- 如果 Skill 有 scripts 字段 → 按序执行脚本（动作型 Skill）
- 两者可同时存在面试官关注的设计细节：冲突解决（多个 Skill 同时匹配时的优先级）、热加载（新增 Skill 不需要重启）、错误隔离（一个 Skill 的脚本崩溃不影响其他 Skill）。
Q：一个好的 Prompt 和一个差的 Prompt 的区别？
来源：腾讯 Agent 应用开发一面
新手答：“好的 Prompt 描述清楚，差的 Prompt 太模糊。”
高手答：
区别不只是“清不清楚”，是五个维度的差距：
| 维度 | 差的 Prompt | 好的 Prompt |
|---|---|---|
| 任务边界 | “帮我写个程序” | “写一个 Python 函数，输入用户 ID 列表，返回每个用户最近 7 天的订单总额” |
| 输出格式 | 不指定 | 明确要求 JSON/代码/表格，给出示例 |
| 约束条件 | 无 | “不要用第三方库”“错误时返回空字典而不是抛异常” |
| 上下文 | 不提供 | 附上相关的类型定义、接口文档、已有代码 |
| 角色设定 | 无 | “你是一个熟悉 SQLAlchemy 的后端工程师” |
更深层的区别：
- 好 Prompt 减少模型的决策空间：模型面对的选择越少，输出越稳定。“写一个函数”有无数种写法，“写一个接收 list[int] 返回 dict[int, float] 的函数”就只有有限的合理写法
- 好 Prompt 提供失败时的指引：不只说“做什么”，还说“做不到时怎么办”——“如果找不到相关信息，回复‘信息不足，需要以下补充：...’”
- 好 Prompt 是可迭代的：不是一次写完，而是根据模型的实际输出不断调整，做版本管理和 A/B 测试
差距在哪：新手只用“清楚 vs 模糊”一个维度。高手从任务边界、输出格式、约束条件、上下文、角色五个维度对比，且点出了“减少决策空间”和“可迭代”两个深层原则。面试官考的是你写 Prompt 的工程化程度。
Q：为什么已经有了 MCP，Anthropic 还要做 Skill？Skill 里面有没有工具？
来源：字节 Agent 开发实习一面
新手答：“Skill 就是 MCP 的升级版。”
高手答：
MCP 和 Skill 不是竞争关系，而是解决两个完全不同的问题：
- MCP 解决的是“Agent 怎么调用外部工具”——它是一个能力协议
- Skill 解决的是“Agent 怎么在某个领域正确地思考和行动”——它是一个知识框架
为什么只有 MCP 不够？
MCP 给了 Agent 工具，但没有告诉它怎么有效地使用这些工具。
举个例子：Agent 有一个“搜索数据库”的 MCP 工具。但如果没有 Skill，它不知道：按什么顺序搜索？搜索结果怎么解读？没有结果时该怎么办？特定领域的工作流是什么？
MCP = 给一个人一套工具箱。Skill = 给他使用工具箱的专业技能。
为什么现在才做 Skill？
| 原因 | 说明 |
|---|---|
| 模型能力提升 | 模型变聪明了，能可靠地遵循复杂指令，基于指令的（Skill）方案变得可行 |
| 工程成本差异 | Skill 是一个 .md 文件，任何人都能写；MCP Server 需要编码、部署、维护 |
| 可组合性 | 多个 Skill 可以自然地同时加载到上下文中；MCP 工具之间的集成更复杂 |
| 领域适配性 | Skill 让领域专家直接编码知识，不需要工程师介入；MCP 必须由工程师实现 |
MCP vs Skill 全维度对比
| 对比维度 | MCP | Skill |
|---|---|---|
| 本质 | 能力协议（工具注册与调用） | 知识框架（领域知识与方法论） |
| 解决的问题 | Agent 能调用什么 | Agent 怎么思考和行动 |
| 载体 | 代码（Server + Client） | 文档（Markdown 文件） |
| 创建门槛 | 需要编程能力 | 只需领域知识 |
| 注入方式 | 注册为可调用的工具 | 加载到模型上下文中 |
| 作用时机 | 模型显式调用时 | 加载后持续影响模型行为 |
| 类比 | 工具箱里的锤子和螺丝刀 | 教你什么时候用锤子、什么时候用螺丝刀的操作手册 |
Skill 里面有没有工具？
这个问题的答案是有引用，但不包含：
- Skill 可以引用工具：“在第三步，执行这条 bash 命令”、“用 Edit 工具修改文件”
- 但 Skill 不包含工具——它包含的是关于何时、如何使用现有工具的指令
- Skill 通过自然语言指令来编排工具，而不是通过工具注册机制
本质上，Skill 是工具的“使用说明书”，不是工具本身。
差距在哪：新手把 MCP 和 Skill 看成竞争关系，以为 Skill 是 MCP 的替代品。高手理解它们服务于不同层次——MCP 提供能力（能做什么），Skill 提供知识（怎么做），两者互补而非互斥。面试官考的是你能不能区分“工具”和“使用工具的知识”这两个抽象层次，以及你对 Agent 系统架构演进方向的理解。
Q：LobeChat 的插件和 Claude Code 的 Skills 有什么本质区别？
来源：字节实习二面
新手答：”都是给 AI 加功能的，只是平台不一样。”
高手答：
表面看都是”扩展能力”，但架构理念完全不同——LobeChat 的插件是传统的代码执行模型，Claude Code 的 Skills 是 Prompt 注入模型：
| 维度 | LobeChat 插件 | Claude Code Skills |
|---|---|---|
| 本质 | 可执行的代码模块（API 调用） | Markdown 文件（知识 + 指令） |
| 触发方式 | 模型输出 function_call → 执行代码 | 用户输入匹配描述 → 注入到上下文 |
| 执行者 | 插件的代码运行时 | 模型本身（按 Skill 中的指令行动） |
| 能力边界 | 取决于代码能做什么 | 取决于模型能理解和执行什么 |
| 开发方式 | 写代码、定义 API schema、部署服务 | 写 Markdown、定义触发条件和步骤 |
| 状态管理 | 插件代码自己管状态 | 无状态，每次重新注入 |
LobeChat 插件的工作流：
用户输入 → 模型判断需要调用插件 → 输出 function_call JSON
→ LobeChat 解析 JSON → 调用插件 API → 返回结果 → 模型组织回答插件是模型的手——模型决定要不要用、怎么用，但执行逻辑是代码写死的。
Claude Code Skills 的工作流：
用户输入 → 匹配 Skill 的触发描述 → 将 Skill 的 Markdown 内容注入上下文
→ 模型按照 Skill 中的步骤指引行动（调工具、写代码、组织输出）Skill 是模型的知识——不执行代码，而是告诉模型”遇到这类任务该怎么做”。模型拥有完整的执行自主权。
核心区别的一句话总结：LobeChat 插件是**”代码做事，模型指挥”；Claude Code Skills 是”模型做事，知识指导”**。
差距在哪：新手把两者等同于”不同平台的同一种东西”。高手从本质（代码 vs 知识）、触发（function_call vs 描述匹配）、执行者（运行时 vs 模型）三个维度做了精确区分。面试官考的是你对 Agent 能力扩展的两种范式的理解——传统的”工具调用”范式和新兴的”知识注入”范式，各有适用场景。