AI 应用岗面试必备：Skill 编写核心指南（字节 AI 工程岗深度解析）

标签：#AI 工程 #Agent 开发 #Skill 设计 #面试指南 #字节跳动
阅读时间：15 分钟
适用岗位：AI 应用工程师、Agent 开发工程师、大模型应用开发

---

前言

在 AI Agent 开发领域，Skill（技能）设计能力已成为衡量工程师水平的核心指标。字节跳动、腾讯等大厂在 AI 应用岗面试中，都会重点考察候选人对 Skill 架构的理解和实战能力。

本文基于字节 AI 工程岗面试真题，结合一线实战经验，系统梳理 Skill 编写的核心架构、设计原则、实战技巧，助你轻松拿下 AI 应用岗 Offer！

---

一、Skill 的三层架构设计

Skill 的设计遵循**“分层解耦、按需加载”**的核心思想，采用经典的三层架构：

L1：Frontmatter 层（始终加载）

---
name: writing-commit-messages
description: |
  根据代码变更自动生成符合 Conventional Commits 规范的提交信息。
  适用于：代码提交、版本发布、变更日志生成等场景。
  核心能力：
  - 解析 git diff 输出
  - 识别变更类型（feat/fix/docs/refactor等）
  - 生成符合规范的 commit message
  - 验证并迭代优化输出质量
  输入要求：git diff 输出或代码变更描述
  输出格式：标准 Conventional Commits 格式
---

设计要点：

• 名称简洁：使用小写字母和连字符，如 writing-commit-messages
• 描述精准：100 词左右，涵盖使用场景、核心能力、输入输出
• 始终加载：这部分内容会作为上下文始终提供给模型

L2：SKILL.md Body 层（触发加载）

这是 Skill 的决策中枢，核心是决策树而非流程说明：

## 触发条件

当用户请求涉及以下场景时触发：
- 生成 Git 提交信息
- 编写版本发布说明
- 创建变更日志条目

## 决策树

1. **输入验证**
   - 如果输入为空 → 返回错误："请提供代码变更描述或 git diff 输出"
   - 如果输入超过 5000 字符 → 截断并提示："输入过长，已截断前 5000 字符"

2. **变更类型识别**
   - 包含"新增"、"feature"、"add" → 类型为 `feat`
   - 包含"修复"、"bug"、"fix" → 类型为 `fix`
   - 包含"文档"、"readme" → 类型为 `docs`
   - 包含"重构"、"refactor" → 类型为 `refactor`
   - 无法识别 → 使用 `chore` 并提示用户确认

3. **输出生成**
   - 高风险任务（生产环境）→ 先输出计划，等待用户确认
   - 普通任务 → 直接生成 commit message
   - 验证失败 → 停止并返回错误，不进入下一轮

4. **质量验证**
   - 检查格式是否符合 Conventional Commits 规范
   - 检查描述是否清晰准确
   - 如果验证失败 → 进入迭代优化循环

关键原则：

• ✅ 写决策树，不写流程说明：模型需要的是判断逻辑，不是步骤列表
• ✅ 约束"不做什么"比"做什么"更精确：明确边界比模糊指导更有效
• ✅ ≤500 行：保持简洁，避免过度复杂

L3：资源层（按需加载）

writing-commit-messages/
├── SKILL.md              # 主文件（L2 层）
├── scripts/
│   ├── validate.js       # 格式验证脚本
│   └── generate.js       # 生成辅助脚本
├── references/
│   ├── conventional-commits.md  # Conventional Commits 规范文档
│   └── examples.json     # 优秀示例库
└── assets/
    └── workflow.png      # 工作流示意图

设计要点：

• 零 Token 消耗：这些资源只在需要时加载，不计入上下文
• 按需引用：在 SKILL.md 中通过 @references/conventional-commits.md 引用
• 模块化：每个脚本/文档只负责单一功能

---

二、核心编写原则

原则 1：高风险任务 vs 高自由度任务

不同的任务类型需要不同的设计策略：

高风险任务（降低自由度）

典型场景：

• 数据库迁移
• 生产环境配置修改
• 资金/交易相关操作
• 用户数据删除

设计策略：

## 高风险任务处理流程

1. **先输出计划**
   - 详细描述将要执行的操作
   - 列出可能的风险和影响
   - 等待用户明确确认（"确认执行"）

2. **验证失败即停止**
   - 任何验证步骤失败 → 立即停止
   - 不进入下一轮操作
   - 返回详细的错误报告

3. **限制自由度**
   - 提供有限的选项（2-3 个）
   - 不允许模型自由发挥
   - 强制执行预设的安全检查

高自由度任务（保留灵活性）

典型场景：

• 代码 Review
• 架构设计分析
• 创意内容生成
• 技术方案推荐

设计策略：

## 高自由度任务处理流程

1. **规定框架，不规定细节**
   - 指定分析维度（性能、可维护性、安全性）
   - 不指定具体结论
   - 鼓励模型提出多种方案

2. **鼓励创新**
   - 允许模型提出非常规建议
   - 提供多个备选方案
   - 标注每种方案的优缺点

3. **迭代优化**
   - 支持多轮对话
   - 根据反馈调整建议
   - 持续改进输出质量

原则 2：Skill 判断公式

什么时候需要创建一个 Skill？

Skill = 反复出现 + 足够复杂 + 有专家判断 + 对输出质量有要求

判断标准：

维度	不需要 Skill	需要 Skill
出现频率	一次性任务	每周出现 3 次以上
复杂度	简单指令即可	需要多步骤推理
专业性	通用知识	需要领域专家知识
质量要求	大概就行	必须达到专业标准

示例分析：

• ❌ 不需要 Skill：“帮我写个 hello world 程序”（简单、一次性）
• ✅ 需要 Skill：“根据 Conventional Commits 规范生成 commit message”（反复出现、有规范、质量要求高）
• ✅ 需要 Skill：“分析微服务架构的性能瓶颈”（复杂、需要专家判断）

---

三、实战案例：writing-commit-messages Skill

完整工作流

关键代码片段

1. 输入验证脚本（scripts/validate.js）

// 验证 commit message 是否符合 Conventional Commits 规范
function validateCommitMessage(message) {
  const pattern = /^(feat|fix|docs|style|refactor|test|chore)(\(.+\))?: .+/;
  
  if (!pattern.test(message)) {
    return {
      valid: false,
      errors: [
        '格式不符合 Conventional Commits 规范',
        '正确格式：type(scope): description',
        '示例：feat(auth): 添加用户登录功能'
      ]
    };
  }
  
  return { valid: true };
}

2. 迭代优化循环

## 迭代优化机制

当验证失败时，启动 A-B 迭代循环：

1. **Claude A（分析者）**
   - 分析验证失败的具體原因
   - 指出当前输出的问题
   - 提出改进建议

2. **Claude B（执行者）**
   - 根据 A 的反馈重新生成
   - 重点改进指出的问题
   - 输出新版本

3. **验证器**
   - 重新运行验证脚本
   - 如果通过 → 输出最终结果
   - 如果失败 → 回到步骤 1（最多 3 轮）

4. **终止条件**
   - 验证通过 → 成功输出
   - 超过 3 轮 → 返回错误并建议人工介入

实际运行示例

用户输入：

git diff 输出：
+ function login() {
+   // 添加用户登录功能
+   return auth.authenticate();
+ }

Skill 输出：

feat(auth): 添加用户登录功能

- 新增 login() 函数
- 集成 auth.authenticate() 方法
- 支持用户身份验证

验证结果：✅ 通过

---

四、常见陷阱与避坑指南

陷阱 1：把 SKILL.md 写成流程说明书

❌ 错误写法：

1. 第一步：读取用户输入
2. 第二步：解析输入内容
3. 第三步：生成 commit message
4. 第四步：验证输出

✅ 正确写法：

## 决策树

- 如果输入为空 → 返回错误
- 如果输入包含"新增" → 类型为 feat
- 如果输入包含"修复" → 类型为 fix
- 否则 → 使用 chore 并提示确认

陷阱 2：过度依赖 L3 层资源

❌ 错误做法：

• 把所有参考资料都放在 L3 层
• SKILL.md 中频繁引用外部文档
• 导致模型需要多次加载资源

✅ 正确做法：

• 核心逻辑放在 L2 层
• 只在必要时引用 L3 资源
• 保持 SKILL.md 自包含

陷阱 3：忽视边界条件

❌ 错误做法：

• 只考虑正常情况
• 不处理异常输入
• 没有错误处理机制

✅ 正确做法：

## 边界条件处理

1. **输入为空** → 返回友好错误提示
2. **输入过长** → 截断并说明
3. **格式错误** → 提供正确示例
4. **验证失败** → 启动迭代循环或终止

---

五、面试高频考点

考点 1：如何判断是否需要创建 Skill？

参考答案：

使用"Skill 判断公式"：反复出现 + 足够复杂 + 有专家判断 + 对输出质量有要求。

例如，"生成 commit message"这个任务：

• 反复出现：团队每周提交数十次代码
• 足够复杂：需要理解变更内容、匹配规范、生成准确描述
• 有专家判断：需要知道什么算 feat、什么算 fix
• 质量要求高：commit message 影响版本管理和变更追踪

因此，这是一个典型的需要 Skill 的任务。

考点 2：如何设计高风险任务的安全机制？

参考答案：

高风险任务需要"降低自由度 + 先计划后执行 + 验证失败即停止"三重机制：

1. 降低自由度：提供有限选项，不允许模型自由发挥
2. 先计划后执行：详细输出执行计划，等待用户明确确认
3. 验证失败即停止：任何验证步骤失败立即终止，不进入下一轮

例如数据库迁移任务，必须先输出迁移方案、影响范围、回滚计划，获得"确认执行"指令后才开始操作。

考点 3：SKILL.md 应该多长？

参考答案：

控制在 500 行以内，核心是决策树而非流程说明。

• 如果超过 500 行，说明逻辑过于复杂，需要拆分多个 Skill
• 优先使用决策树（if-then 逻辑），避免冗长的流程描述
• 复杂逻辑拆分为多个子 Skill，通过资源引用协同工作

---

六、总结与实战建议

核心要点回顾

1. 三层架构：L1 始终加载、L2 决策中枢、L3 按需加载
2. 编写原则：写决策树、约束边界、高风险降自由度
3. Skill 判断：反复出现 + 足够复杂 + 有专家判断 + 质量要求
4. 避坑指南：避免流程说明、合理分配资源、重视边界条件

实战建议

1. 从简单开始：先实现一个完整的简单 Skill（如 commit message 生成）
2. 迭代优化：通过 A-B 测试循环持续改进
3. 文档完善：为每个 Skill 编写清晰的 README 和使用示例
4. 测试覆盖：编写单元测试覆盖各种边界条件

---

本文版权归作者所有，转载请注明出处。
如有问题或合作意向，欢迎通过评论区或私信联系。