Agent Skills 实战：从提示词到可复用技能库，让 AI 稳定交付

如果你最近在用大模型做实际开发，会发现一个尴尬的分界线：会写提示词的人很多，但能稳定交付的人很少。提示词写得再长，换一个项目场景就要推翻重来；Agent 拆任务再灵活，没有可复用的能力模块，每次都是从零开始讲需求。真正把 AI 用成生产力的团队，早已不在“写提示词”上较劲，而是在搭建一套能沉淀、能复用、能自动触发的能力库——这就是 Agent Skills。

Agent Skills 并不是一个玄学概念。它本质上是一种工程化的能力封装方式：把提示词、规则、模板、脚本和验证方式打包成一个标准的技能模块。模型面对匹配的任务场景时，自动加载这套模块，而不是靠用户反复描述需求。你可以把它理解为 AI 的“函数封装”，或者一个岗位的 SOP 手册：一次编写，处处调用，还可以交给版本管理工具去追踪。

这篇文章从 Agent Skills 的核心原理讲起，用三个真实可跑的实战示例带你从零搭建技能：代码审查、周报生成、日志分析。看完你不仅能理解 Skill 的设计思路，还能马上在自己的工具链里面建出第一个可用技能。

先把最关键的一个判断放在前面：Agent Skills 真正降低的是 AI 应用的重复开发成本。它把“教会模型做一件事”从对话行为变成了工程资产。这是每一个做 AI 产品、Agent 开发、甚至只是重度使用 AI 辅助编程的人，都应该尽早掌握的下一站。

1. 这篇文章真正要解决的问题

先说一个很常见的场景。你花了很多时间调提示词，让模型帮你写代码、写文档、做代码审查。某个提示词当天效果很好，但第二天换了一个项目、换了一个技术栈，你发现它又不行了。于是你继续加规则、加示例，最后提示词变得比业务代码还长，模型反而开始丢上下文。

这就是传统提示词工程的天花板。

提示词是“一次性对话资产”。它依附于某一次对话，写在对话框里，换一个会话就要重新粘贴。多问几个问题之后，前面精心设计的角色设定和规则，可能就已经被后面的对话稀释掉了。如果团队里五个人各自调提示词，产出的效果完全不可控。这是工程问题，不是提示词技巧能解决的。

Agent Skills 解决的就是这个工程问题。它把“让模型会做某件事”所需的所有信息，把指令、规则、示例、模板、脚本，全部放进一个文件夹。这个文件夹就是一个标准化的技能包。

当用户提出相关任务时，Agent 会自己判断该用哪个技能，然后把技能内容加载进来执行。技能可以跨会话复用，可以放进 Git 管理，可以跟随项目分发，也可以在团队里共享。从“每次对话都重新教育模型”变成“一次写好，处处触发”，这是整个工作方式的转变。

如果你属于下面这几类人，这篇文章对你最有用：

• 做 AI 应用开发，发现直接调模型 API 不够，还需要一套可复用的 Agent 能力层；
• 重度使用 AI 编程工具，想让工具记住项目特定的代码规范、审查标准、文档格式；
• 做提示词相关教程或团队 AI 赋能，想把个人 Prompt 沉淀成团队共享的技能库；
• 刚开始学习 Agent 开发，想知道 Skill、Agent、工作流这几个概念到底什么关系。

读完这篇文章，你会掌握三个完整的技能示例，每一个都可以直接复制到本机运行。你也会知道技能为什么不触发、脚本为什么调用失败、多个技能冲突时怎么排查。

2. Agent Skills 核心概念与工作原理

先从定义说起。Agent Skills，直译是“智能体技能”，更准确的表述是：给 AI 代理准备的一组可复用能力单元。每个技能包含如何完成某类任务的完整说明，包括任务目标、执行步骤、输出格式、边界条件，以及将要调用的脚本或模板。

2.1 从提示词到技能，到底变在哪

传统提示词解决的是“让模型回答好”的问题。技能解决的是“让模型稳定地完成一类任务”的问题。

一个典型的传统提示词可能是：

你现在是一个资深 Python 工程师，请帮我审查这段代码，注意性能、安全、可读性。

你每次都手动输入。模型每次重新理解你的要求。今天心情好，它就审查得仔细一点；明天问题复杂一点，它的输出可能就跑偏了。

换成 Agent Skills 之后，同样的事情是这样发生的：

1. 用户在对话中输入：帮我看看这段代码有什么问题。
2. Agent 扫描技能目录，发现一个 description 里写着“审查代码质量、识别潜在 bug”的技能。
3. Agent 自动加载该技能的 SKILL.md 文件。
4. SKILL.md 里的详细审查标准和输出模板注入当前上下文。
5. 模型按照统一标准完成审查，输出格式也是固定的。

用户并没有手动指定任何技能。整个过程由 Agent 根据任务描述自行匹配触发。从用户视角看，他只是在对话里发了一段代码，得到的却是稳定、格式统一、有完整检查项的审查结果。

2.2 SKILL.md 到底是什么

主流 Agent Skills 实现都采用“目录即技能”的组织方式。每个技能就是一个文件夹，文件夹里必须有一个SKILL.md文件。这个文件是技能的入口，通常包含两段内容：

• YAML front matter，也就是文件开头的元数据，用来声明技能的名称和触发条件；
• Markdown 正文，用来描述技能的执行流程和输出要求。

一个典型的最小结构如下：

--- name: grammar_check description: 检查中文文本的语法错误和表达问题。当用户需要对文章、邮件、说明文档进行语言润色时使用。 --- # 语法检查步骤 1. 先通读全文，理解作者原意。 2. 逐段检查语法、标点、用词。 3. 用表格输出修改建议，标注问题位置和修改后文本。

name是技能的标识，建议全小写，用下划线连接。description是最重要的字段，因为它是 Agent 判断“该不该用这个技能”的依据。如果 description 写得模糊，技能可能永远不会被触发；如果写得过于宽泛，又可能和其他技能抢任务。

2.3 Agent Skills 与传统提示词、Agent 的边界

很多人把 Agent Skills、Agent、提示词三者混在一起，其实边界很清楚：

简单说，提示词是“一句话指令”，技能是“一套做工标准”，Agent 是“一个会自己找活干的工人”。技能是 Agent 的武器库，而提示词只是战场上临时递过去的一句话。

3. 环境准备与前置条件

Agent Skills 的学习成本不高。即便你是第一次接触，按下面的步骤准备 10 分钟以内就能完成。

3.1 需要准备什么

环境要求如下：

• 一个支持技能机制的 Agent 客户端或开发工具。目前有一些主流产品已经内置了类似功能，具体入口以你所用工具的官方文档为准。本文的示例按通用目录结构编写，适用于大多数实现。
• 可用的模型服务或 API Key。这是 Agent 能理解任务的基础。
• Python 3.8 及以上版本。本文第三个示例涉及脚本调用，建议提前安装。可以运行python3 --version确认。
• 任意代码编辑器。推荐 VS Code，但不是必须。
• 一个用于存放技能的根目录。例如~/agent-skills。

3.2 创建技能目录

打开终端，执行下面的命令创建目录结构：

mkdir -p ~/agent-skills/code_review mkdir -p ~/agent-skills/weekly_report/templates mkdir -p ~/agent-skills/log_analysis/scripts

执行完成后，目录结构如下：

agent-skills/ ├── code_review/ │ └── SKILL.md ├── weekly_report/ │ ├── SKILL.md │ └── templates/ │ └── weekly_report.md └── log_analysis/ ├── SKILL.md └── scripts/ └── analyze_log.py

3.3 在客户端中接入技能目录

不同客户端添加技能目录的入口不一样。常见做法有两种：

• 在客户端的设置或偏好设置里找到“Skills”或“技能”入口，添加你的技能根目录；
• 或者在项目根目录下创建.claude/skills或类似规定的技能文件夹，让 Agent 自动识别。

如果你使用的是 Claude 桌面端，可以在设置中指定技能目录。如果使用 Claude Code，直接在项目中按官方说明配置即可。核心点是一样的：Agent 会扫描这个目录，读取每个子文件夹中的 SKILL.md，技能启动后自动进入候选列表。

如果你用的工具目前不支持技能目录，也不用着急。原理是通用的，你仍然可以手动把 SKILL.md 的内容粘贴到对话中作为系统指令，体验一下设计思想和执行效果。等到工具支持了，再无缝迁移。

4. 实战一：创建代码审查技能

先从一个最实用的技能开始：代码审查。这个技能本质上是一套审查标准，确保模型在收到代码时，按照统一的维度去分析，而不是随性发挥。

4.1 创建 SKILL.md

在~/agent-skills/code_review/目录下创建SKILL.md，内容如下：

--- name: code_review description: 系统化审查代码质量。当用户需要检查代码、评估PR/MR、查找潜在bug、优化代码可读性时使用。 --- # 代码审查技能 你是一个严谨的代码审查者。不要只给出“看起来不错”的结论，要逐项检查。 ## 审查范围 1. 正确性：是否存在逻辑错误、边界条件遗漏、并发问题、类型错误。 2. 健壮性：输入校验是否完善，异常处理是否合理，失败时是否容易排查。 3. 可读性：命名是否清晰，函数是否过长，代码结构是否符合常见约定。 4. 性能：是否存在明显的时间复杂度问题、循环内重复调用、内存浪费。 5. 安全性：是否存在注入风险、敏感信息泄露、越权访问、硬编码密钥。 ## 审查流程 1. 阅读用户提供的代码或代码差异。 2. 按照上述 5 个范围逐项对照，逐条记录问题。 3. 如果用户没有指定语言，按代码本身的语言来审查。 4. 输出以下固定格式： ### 问题列表 | 严重级别 | 问题位置 | 问题描述 | 修改建议 | | --- | --- | --- | --- | 严重级别分为：致命 / 重要 / 建议 / 可选。 ### 总体评价 用一段话总结代码质量，说明优点和主要风险点，并给出是否适合合并的判断。

4.2 这个技能设计背后的逻辑

这个 SKILL.md 只有三十多行，但它做对了几件事：

第一，description 覆盖了用户常见的任务表达。用户可能会说“帮我看看这段代码”，也可能说“帮我 review 一下这个 MR”，还可能说“这段代码有什么坑”。这几个说法意思相近，但关键词差别很大。description 把这几类场景都列出来，Agent 匹配触发的能力就强很多。

第二，审查范围是固定的。没有技能的情况下，不同提问方式会让模型产出完全不同的审查结果。技能里把正确性、健壮性、可读性、性能、安全性五个维度固定住，每次审查都按这个标准执行，结果更可控。

第三，输出格式固定。问题列表使用表格，严重级别被明确划分。这方便后续接入自动化流程，例如把审查结果转成 Jira 任务或直接作为 MR 评论。

4.3 测试技能

创建好文件之后，在 Agent 客户端中发送一段有问题的代码，看看效果。例如：

def get_user(username): sql = "SELECT * FROM users WHERE name = '" + username + "'" conn = get_connection() cursor = conn.execute(sql) result = cursor.fetchone() return result

这个例子至少包含 SQL 注入风险、异常处理缺失、资源未释放三个问题。如果技能触发成功，Agent 应该按照表格格式输出审查结果，并明确指出“致命”级别的问题。如果 Agent 没有触发技能，先检查 description 是否包含了用户这次输入的关键语义，再检查技能目录是否配置正确。

5. 实战二：创建周报生成技能

代码审查是纯指令型技能。第二个例子加入资源文件，也就是模板。当技能需要产出固定格式文档时，模板资源能有效减少模型“自由发挥”的空间。

5.1 创建 SKILL.md

在~/agent-skills/weekly_report/目录下创建SKILL.md：

--- name: weekly_report description: 根据git提交记录、任务列表或工作日志，生成结构化的周报。当用户需要总结一周工作成果、撰写周报时使用。 --- # 周报生成技能 你将帮助用户把零散的工作记录整理成一份可读、有重点的周报。 ## 输入方式 用户可以提供以下任意一种或多种信息： - git log 输出 - 任务清单 - 工作日志文本 - 口头描述 ## 处理要求 1. 先提炼本周的关键结果，不要逐行粘贴原始日志。 2. 每个已完成事项用“做了什么事 + 带来了什么结果”的句式描述。 3. 技术细节保留在项目名和关键词中，不要展开大段背景。 4. 如果用户漏掉了某些必要信息，不要编造，使用 TODO 占位符。 ## 输出模板 严格按照 templates/weekly_report.md 文件中的模板输出最终结果。

5.2 创建模板资源文件

在~/agent-skills/weekly_report/templates/目录下创建weekly_report.md：

# 周报：本周（{日期范围}） ## 本周目标 - 重点目标1 - 重点目标2 ## 完成事项 ### 功能开发 - 事项描述 ### Bug 修复 - 事项描述 ### 技术研究 / 文档 - 事项描述 ## 遇到的问题与解决方案 - 问题：简要描述 - 解决：简要描述 ## 下周计划 - 计划事项1 - 计划事项2

5.3 模板存在的意义

可能有人会问：反正模型懂 Markdown，为什么还需要模板文件？

关键在于“标准”。如果技能不提供模板，模型每次生成的周报结构都会有细微差异。今天分四节，明天分六节，后天换一种标题风格。对个人使用没关系，但对团队协作就是灾难。有了固定模板，任何人都能生成格式统一的周报，后续做汇总、做数据分析都顺畅很多。

模板还可以持续演进。团队觉得“本周目标”没用，可以直接改模板文件，不需要改技能正文。这就是资源文件与指令分离的好处。

5.4 测试技能

向 Agent 提供一小段 git log 输出，例如：

git log --oneline --since="2025-06-09" --until="2025-06-15"

输出是一串 commit 记录。技能应该将其整理成周报格式，归入功能开发、Bug 修复等分类。如果 commit 信息缺失，Agent 应该用 TODO 标注，而不是编造内容。

这里有一个细节值得注意：技能允许用户输入 git log，但并没有要求用户提前整理。真正的价值在于，Agent 自动完成了“分类 → 提炼 → 格式化”这一连串动作，而提示词做不到这种自动编排。

6. 实战三：技能与 Python 脚本结合

前两个技能都是纯指令和模板，Agent 本身就能完成。第三个例子加入外部脚本，这是 Agent Skills 真正进阶的地方：技能不仅能指导模型“怎么说”，还能驱动模型“怎么做”。

很多任务是模型不擅长的，比如精确统计日志中的错误数量。模型可以估算，但做不到准确。这时让技能调用脚本，用程序完成计算，是最合理的架构。

6.1 创建 SKILL.md

在~/agent-skills/log_analysis/目录下创建SKILL.md：

--- name: log_analysis description: 对服务日志和错误日志进行统计分析。当用户需要分析应用日志、统计错误分布、查找异常、定位问题日志时使用。 --- # 日志分析技能 使用 scripts/analyze_log.py 脚本辅助分析日志，结合脚本输出给出结论。 ## 使用步骤 1. 如果用户提供的是日志文本，先将其保存到本地临时文件；如果用户提供的是文件路径，直接使用。 2. 运行以下命令： ```bash python3 scripts/analyze_log.py <日志文件路径>

3. 读取脚本输出的统计结果。
4. 结合日志中的具体条目，向用户解释当前日志反映了什么问题，给出处理建议。

注意事项

• 如果日志量很小（少于20行），可以直接阅读，不必运行脚本。
• 脚本只是统计工具，真正的结论需要结合业务场景判断。
• 不要在技能描述中存储敏感信息。

注意：这里出现了嵌套的 Markdown 代码块，在真实文件中用四个反引号包裹内部代码块，或者使用缩进方式处理。在 SKILL.md 中描述命令时，推荐用代码块形式告诉模型“这是一条要执行的命令”。 ### 6.2 创建 Python 脚本 在 `~/agent-skills/log_analysis/scripts/` 目录下创建 `analyze_log.py`： ```python #!/usr/bin/env python3 """ 日志分析脚本：读取日志文件，统计日志级别、小时分布和异常样本。 用法: python3 scripts/analyze_log.py <log_file> """ import sys import re from collections import Counter def analyze_log(file_path: str): level_counter = Counter() error_counter = Counter() hour_counter = Counter() total_lines = 0 level_pattern = re.compile( r'(?P<level>DEBUG|INFO|WARN|WARNING|ERROR|Exception)' ) hour_pattern = re.compile(r'(?P<hour>\d{2}):\d{2}:\d{2}') try: with open(file_path, "r", encoding="utf-8", errors="ignore") as f: for line in f: total_lines += 1 level_match = level_pattern.search(line) if level_match: level_counter[level_match.group("level")] += 1 hour_match = hour_pattern.search(line) if hour_match: hour_counter[hour_match.group("hour") + ":00"] += 1 if "ERROR" in line or "Exception" in line: error_counter[line.strip()[:120]] += 1 except FileNotFoundError: print(f"错误：文件不存在 {file_path}") sys.exit(1) print("=" * 50) print(f"日志总行数: {total_lines}") print("\n日志级别分布:") for level in ["DEBUG", "INFO", "WARN", "WARNING", "ERROR", "Exception"]: if level_counter[level]: print(f" {level}: {level_counter[level]}") print("\n按小时分布（Top 5）:") for hour, count in hour_counter.most_common(5): print(f" {hour} - {hour[-2:]}59 {count} 行") print("\nERROR 样本（Top 10）:") for sample, count in error_counter.most_common(10): print(f" [{count}次] {sample}") print("=" * 50) if __name__ == "__main__": if len(sys.argv) != 2: print("用法: python3 scripts/analyze_log.py <log_file>") sys.exit(1) analyze_log(sys.argv[1])

6.3 脚本承担了什么

这个脚本最关键的价值是精确性。大模型可以读日志，但面对几千行日志时，它容易漏掉重复出现的错误模式。脚本可以精确统计每一类错误出现的次数、按小时分布、错误样本的内容。模型再基于这些统计结果，向用户解释业务上的问题。

这说明了一个重要设计原则：技能里不要什么都让模型做。能交给脚本计算的，就不要依赖模型估算。模型负责理解和表达，脚本负责精确计算，各司其职。

6.4 测试技能

准备一个日志文件app.log：

2025-06-10 10:01:23 INFO User logged in: user_1001 2025-06-10 10:02:11 ERROR Database connection timeout: db-01 2025-06-10 10:02:15 WARN Retrying connection, attempt 1 2025-06-10 10:03:02 ERROR Database connection timeout: db-01 2025-06-10 11:15:44 INFO User logged out: user_1001 2025-06-10 11:18:20 ERROR Payment callback signature mismatch

在 Agent 会话中让 Agent 分析这个日志。Agent 应该调用脚本，然后告诉你：总行数、错误分布、高频错误样本，以及这些错误可能指向数据库连接不稳定和支付回调校验失败。这是纯提示词很难稳定做到的效果。

6.5 安全提醒

技能能调用脚本，也意味着能力边界变大了。使用外部脚本时务必注意：

• 脚本必须来自可信来源，并经过审查，不要随意运行从网络下载的脚本；
• 遵循最小权限原则，脚本只需要读取日志的权限，就绝不给它执行系统变更的权限；
• 不要把 API Key、数据库密码等敏感信息写进 SKILL.md 或脚本中；
• 在正式环境中执行脚本前，先在隔离环境跑通，确认没有破坏性操作。

7. 运行结果与效果验证

很多人创建完技能，就跑一次，看一眼输出，觉得“好像可以了”。这种做法风险很大。技能是会被反复触发和复用的，你需要一套稳定的验证方式。

7.1 三个验证维度

第一，技能是否按预期触发。比如你发送“帮我审查这段代码”，Agent 是否真的加载了 code_review 技能，还是简单回答了一下。可以在输出中观察是否出现了技能定义的固定格式。如果输出没有包含“问题列表”表格，很可能技能没有触发。

第二，输出格式是否合规。周报技能生成的周报，是否严格按照模板结构？章节是否完整？有没有出现模板之外的第三个“完成事项”分类？格式错误通常意味着模板资源没有被正确加载，或者 SKILL.md 中的指引不够强。

第三，脚本调用是否成功。日志分析技能是否真的运行了 Python 脚本？如果 Agent 只是看了日志然后自行总结，你需要检查技能中命令写法和脚本路径是否正确。

7.2 验证步骤

准备一组标准的测试用例，例如：

• 代码审查技能：准备 3 段代码，一段有明显 SQL 注入，一段有边界条件缺陷，一段基本正常。
• 周报技能：准备一段 git log 和一段任务清单。
• 日志分析技能：准备一个 50 行左右的样例日志，包含重复错误。

每次修改技能后，用这套用例重新跑一遍。如果输出与预期不符，优先看技能文件的语法和描述。不要在一个不触发的技能上反复修改正文，先解决“能不能触发”的问题，再解决“质量够不够好”的问题。

如果客户端提供了调试模式、日志输出或技能加载提示，直接开启。观察模型在加载技能时发生了什么，能让排查效率高很多。

8. 常见问题与排查方法

技能文件写好了，但不工作，这是最常见的挫折来源。以下问题都是实际使用中容易遇到的：

其中，最常见的两个问题是 description 不准确和资源路径写错。

description 的问题在于，你写的是你以为的触发场景，不是用户实际会说的话。比如一个技能实际用于“总结会议纪要”，但 description 里写的是“会议记录整理”，用户说“帮我提炼一下今天会议的决定”，模型不一定能联想到这个技能。解决办法是把常见的用户说法都写进 description。

资源路径的问题，多发生在技能文件夹嵌套较深时。SKILL.md 里写的是相对路径，比如scripts/analyze_log.py，但实际文件却放在了别的目录。建议创建技能后，第一时间检查一次完整目录树，确保所有资源文件都在技能文件夹内部。

9. 最佳实践与工程建议

到这里，你已经能创建并运行技能。接下来是工程化的建议，帮助你把技能从“能用”提升到“好用”。

9.1 命名和描述规范

技能名称遵循小写加下划线的命名方式，保持简洁。例如code_review、weekly_report、log_analysis。不要在 name 里使用空格、中文和特殊字符。中文虽然也能识别，但在跨平台迁移时容易出现编码问题。

description 是技能最重要的元数据，建议采用“任务类型 + 触发条件 + 输出形式”的结构。第一句说明“这个技能做什么”，第二句列举哪些请求应该触发它，第三句说明最终输出什么。例如：

description: 根据工作日志生成结构化周报。当用户输入git log、任务清单或工作内容描述时使用。输出周报Markdown文件。

避免出现空泛描述，比如“帮助用户提高效率”。这类描述让 Agent 无法判断何时使用。

9.2 技能内容保持单一职责

一个技能只做一类事。代码审查技能不要顺便做代码格式化建议，周报技能不要顺带做绩效考核分析。职责越单一，description 越容易写，触发越稳定，模型执行时也越不容易混乱。

如果两个技能确实有部分重叠，可以通过描述中的场景限制来区分。例如代码审查技能负责“提交前质量检查”，安全审计技能负责“安全扫描”，两者虽然都会检查安全问题，但触发场景不同，可以共存。

9.3 使用模板和脚本压缩上下文

技能正文不宜过长。把固定的格式放进模板文件，把计算逻辑放进脚本，能显著减少上下文占用。技能正文里只保留模型“必须知道”的执行判断规则。

比如日志分析技能的正文中，不需要写完整的日志格式说明，只需要告诉模型“遇到什么情况要调用脚本、调用后怎么解释输出”。这让技能更轻量，加载更快，执行也更稳定。

9.4 技能纳入版本管理

技能是工程资产，不是个人笔记。把技能根目录纳入 Git 仓库，每次修改技能配置或模板都提交一次。这样能追踪技能演进的完整历史，回滚也更方便。

在团队协作中，技能仓库可以用分支管理。稳定版本合入主干，实验性技能放在独立分支，经过一段时间的验证再合入。这和多分支开发流程是一致的。

9.5 安全边界

技能可以调用脚本，这意味着它是 Agent 能力边界的一部分。要遵循以下安全原则：

• 技能中不存放任何密钥、口令、Token；
• 脚本运行前先审查，确认没有破坏性命令；
• 如果脚本需要访问网络或执行系统命令，必须明确标注，并遵循最小权限原则；
• 在团队共享技能时，注意检查是否有内部信息泄露的可能。

9.6 建设技能测试集

每个技能都配一组标准测试用例，验证技能核心功能是否正常。代码审查技能测试用例是三段不同质量的代码，周报技能测试用例是一份 git log，日志分析技能测试用例是一份样例日志。每当你修改技能时，用测试集跑一遍。十分钟就能完成回归，效果好过临时找人试错。

10. 总结与后续学习方向

Agent Skills 是 AI 应用开发中容易被低估的一个环节。它比提示词工程更有工程价值，比 Agent 框架更容易上手。它本质上是把“如何让模型稳定完成一类任务”的知识，沉淀成一套可复用、可触发、可版本管理的能力资产。

本文用三个实战示例完成了从理论到落地的闭环：

• 代码审查技能，展示纯指令型技能如何规范和约束模型输出；
• 周报生成技能，展示模板资源如何保证格式的统一；
• 日志分析技能，展示 Python 脚本如何与技能结合，让模型负责理解、脚本负责精确计算。

如果你现在只有零散的提示词经验，下一步请创建你的第一个技能目录，挑一个最常做的任务，比如邮件回复、代码审查、日报生成，把它封装成技能。跑通一次之后，你就能直观感受到技能和提示词的区别。

继续深入的方向有三个：第一，学习如何在同一个项目中组合多个技能，让 Agent 根据任务自动调度；第二，研究技能与工具调用的配合，让技能触发外部 API 和数据源；第三，设计技能的量化评测方案，用一组测试集持续追踪技能效果。这三步完成之后，你基本就进入了 Agent 工程化的下一个阶段。

最后提醒一句：技能不是写一次就完事的静态文件。它应该像业务代码一样，持续迭代、持续测试、持续优化。把你最常重复的 AI 任务封装成技能，并让它越来越稳定，这才是一个开发者真正把 AI 用成生产力的开始。