如果你最近在用大模型做实际开发会发现一个尴尬的分界线会写提示词的人很多但能稳定交付的人很少。提示词写得再长换一个项目场景就要推翻重来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 之后同样的事情是这样发生的用户在对话中输入帮我看看这段代码有什么问题。Agent 扫描技能目录发现一个 description 里写着“审查代码质量、识别潜在 bug”的技能。Agent 自动加载该技能的 SKILL.md 文件。SKILL.md 里的详细审查标准和输出模板注入当前上下文。模型按照统一标准完成审查输出格式也是固定的。用户并没有手动指定任何技能。整个过程由 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 SkillsAgent本质一段对话指令一个结构化的技能包一个自主决策系统复用性低需要反复输入高一次编写多处触发高但依赖下游工具触发方式每次手动输入按 description 自动匹配自己拆解任务并选择工具形态文本文件夹 Markdown 脚本程序 模型 工具集维护成本难追踪可进入版本管理整体架构复杂度较高简单说提示词是“一句话指令”技能是“一套做工标准”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.py3.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 - 计划事项25.3 模板存在的意义可能有人会问反正模型懂 Markdown为什么还需要模板文件关键在于“标准”。如果技能不提供模板模型每次生成的周报结构都会有细微差异。今天分四节明天分六节后天换一种标题风格。对个人使用没关系但对团队协作就是灾难。有了固定模板任何人都能生成格式统一的周报后续做汇总、做数据分析都顺畅很多。模板还可以持续演进。团队觉得“本周目标”没用可以直接改模板文件不需要改技能正文。这就是资源文件与指令分离的好处。5.4 测试技能向 Agent 提供一小段 git log 输出例如git log --oneline --since2025-06-09 --until2025-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 日志文件路径读取脚本输出的统计结果。结合日志中的具体条目向用户解释当前日志反映了什么问题给出处理建议。注意事项如果日志量很小少于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(?PlevelDEBUG|INFO|WARN|WARNING|ERROR|Exception) ) hour_pattern re.compile(r(?Phour\d{2}):\d{2}:\d{2}) try: with open(file_path, r, encodingutf-8, errorsignore) 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.log2025-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 没有被识别YAML front matter 格式错误检查文件开头是否有---包裹的元数据删除多余字段只保留 name 和 description输出格式不符合要求正文指引不够具体检查 SKILL.md 是否明确要求了输出格式增加固定标题、表格模板和示例脚本执行失败Python 版本不对或依赖缺失在终端手动运行脚本查看报错安装依赖或调整脚本中的解释器路径技能内容太长模型忽略部分指令SKILL.md 正文超过模型上下文承受范围计算正文长度观察模型输出是否丢失后段精简正文将详细规则拆成可引用的资源文件模板没有生效模板路径写错或文件不在指定目录检查 SKILL.md 中的路径与真实目录结构是否一致统一相对路径把模板放到技能文件夹内多个技能同时抢任务技能描述过于宽泛观察模型选择情况收缩每个技能的触发场景让描述更具体其中最常见的两个问题是 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 用成生产力的开始。