企业官网建设流程全解析

最近 agent 圈子里最热闹的关键词，大概就是 skills。你可能已经在各种技术社区刷到过：有人晒自己的 skill 包，有人整理 skills 下载清单，还有人专门做了 agent skill 教程。这个 "agent-skills" 的玩法，其实一点也不玄乎：把过去一遍遍复制粘贴到 prompt 里的指令、规则、检查清单，连同配套脚本和参考资料，打包成一个有统一入口的标准目录结构，让 agent 在需要的时候按需读取，从而稳定完成某一类任务。说白了，这就是给 agent 装"技能包"。

它解决的是一个非常现实的问题：模型越来越聪明，但每次开新对话，你都得把工作流从头教一遍。写周报要重新贴格式要求，审代码要重新贴规范清单，稍微复杂点的多步骤任务，光靠提示词根本锁不住执行质量。skills 把"怎么做事"整体沉淀下来，agent 不再靠临场发挥，而是按一套可复用的方法走。

如果你正在做 agent 开发、重度使用 Claude 或 Codex 这类带 skills 能力的工具，或者只是好奇"为什么别人家的 agent 这么能干"，这篇文章都值得读完。我不会停在概念层，会拆开一个真实的 skill 目录，从头手搓一个能用的技能包，再把触发失败、token 爆炸、跨平台不兼容这些常见坑一个个讲清楚。

1. Agent Skills 到底是什么：它解决的核心痛点和三个关键概念

1.1 提示词工程为什么搞不定复杂任务

早期玩 agent，大家靠的是提示词工程。你把"你是一位资深前端架构师，请按以下规则审查代码..."写在系统提示词或者每次对话开头，然后期待模型老老实实执行。这套思路在 demo 阶段很好使，一旦进入真实工作流，问题就全暴露出来了。

第一个问题是不可复用。同一套审查规则，今天用、明天用、换个项目还要用，但每次都要复制粘贴。粘贴次数多了，总会漏掉某一条——你忘了写"不要编造数据"，这周的报告里就出现了编造的数据。第二个问题是上下文窗口。规则写得越细，占用的 token 越多，留给真正要处理的业务内容的空间就越小。你可以把规则写得极简，但极简的规则又约束不住模型的自由发挥。第三个问题是执行质量不稳定。提示词本质上是一个"建议"，模型读了之后可以照做，也可以发挥，没有任何机制强制它按步骤走。

我自己最直观的体感来自写周报。以前每个周一，我都要在对话框里重新描述一遍：周报要分几个板块、每个板块要哪些数据、语气要克制、不要编造指标。说真的，这种重复性劳动做个三次就会烦。skills 的思路是：干脆把"生成周报"整件事封装成一个带步骤、带模板、带脚本的技能包。agent 不需要"理解"我的周报习惯，它只需要在检测到相关请求时，按技能包里的流程走完即可。

1.2 Skills、Tools、MCP 的关键区别

很多新手一来就问：skills 和函数调用、MCP 有什么区别？这三个概念确实容易被混淆，但它们的定位根本不在一个层级。

工具调用解决的是"这件事 agent 自己干不了，得调个函数"；MCP 解决的是"工具多了，得有个统一协议，不然每个应用都各写一套接口"；而 skill 解决的是"一件复杂事情，该按什么流程、用什么方法，一步步做完"。它们不冲突，实践中常常叠加使用：skill 的执行步骤里完全可以调用一个 MCP 工具，或者调用一个函数。

举一个真实例子。我想让 agent 帮我审查前端代码，我可以给它一个"检查 console.log 残留"的工具函数，那是 Tool；我可以把公司内部的代码规范通过 MCP 暴露给它，那是 MCP；但真正能让它像一位有经验的前端负责人那样，先看改动范围、再按清单逐项检查、最后给出结构化审查报告的，是一个 skill。工具负责"能调用什么"，skill 负责"该怎么做"。

1.3 为什么这个概念现在突然火了

说实话，skills 这种"把方法论打包成目录"的想法并不是最近才出现的。过去有各种 prompt 模板库、工作流模板，本质上都是想解决同样的问题。但为什么偏偏是现在，skills 成了 agent 圈子的中心话题？

我觉得有三个原因叠在一起。第一，agent 从 demo 阶段进入生产阶段了。过去大家展示的是"你看它自己会写代码"，现在大家关心的是"它能不能稳定地帮我完成每周的代码审查"。一旦要稳定，就需要把工作流固化下来，skills 就是固化的最小单元。第二，模型上下文虽然在不断变长，但"上下文大"不等于"知道每一步怎么走"。长上下文解决的是"能装下更多资料"，但解决不了"流程控制"。skills 用外部文件的形式，把流程从上下文里解放了出来。第三，头部厂商开始推统一规范。Claude 有 agent skills 的官方实践，Codex 也有 skills 仓库，还有一批第三方 agent 工作台把 skills 作为核心能力内置。标准一旦成形，社区就像滚雪球一样，越来越多的人开始写、开始分享 skills，生态就起来了。

现在你再看到"agent-skills"这个标题，脑子里应该是一条清晰的链路：它不是某个神秘框架，而是一套"用目录结构和 Markdown 定义 agent 能力"的方法论。

2. 拆解一个 Skill 的标准结构：从 SKILL.md 到配套脚本

2.1 最小目录结构长什么样

一个 skill 的目录结构并不复杂。以社区里最常见也最通用的形态为例，它长这样：

my-first-skill/ ├── SKILL.md ├── scripts/ │ └── check_frontend.py └── references/ └── coding_standards.md

SKILL.md 是整个技能包的入口，相当于"主脑"。agent 会先读这个文件，判断自己该不该使用这个技能、以及怎么使用。scripts 目录放的是配套的可执行脚本，用来做一些 Markdown 说不清楚的、需要确定性逻辑的事情，比如正则扫描代码、跑测试、处理文件。references 目录放的是参考资料，比如团队编码规范、设计规范、行业标准这类"不一定每次都用，但需要时必须有"的知识文件。

有些 skill 还会带一个 assets 目录，放模板文件、示例输出等。但核心永远只有两个东西：一个 SKILL.md，和一个（或多个）脚本。我见过很多质量很差的 skill，恰恰是目录结构搭得很花哨，相关文件塞了一大堆，核心的 SKILL.md 却写得含糊其辞。目录结构是皮，SKILL.md 才是灵魂。

2.2 SKILL.md 的 frontmatter 和正文怎么设计

SKILL.md 最上面通常是 YAML 格式的 frontmatter，写一些元信息。下面这一段是我自己项目里一个 skill 的缩略模板，你可以直接抄作业：

--- name: frontend-code-review description: 当用户要求做前端代码审查、检查 PR、质量门禁评审、找出代码里的 debug 残留时使用。 --- # 前端代码质量门禁 ## 适用场景 - 用户要求审查前端代码 - 用户要求检查提交的 PR 是否达标 - 用户希望排查 console.log、debugger、TODO 残留 ## 执行步骤 1. 先读取 references/coding_standards.md，了解团队规范 2. 调用 scripts/check_frontend.py 扫描目标目录 3. 按规范中的优先级，分类输出问题清单 4. 对高危问题给出修改建议，对低危问题只做统计 ## 输入要求 - 目标目录必须是本地存在的路径 - 如果没有明确目录，默认认为当前工作目录 ## 输出格式 - Markdown 报告，按"阻断问题 / 警告 / 建议"三级分类 ## 不适用场景 - 后端代码审查请直接说明，不要使用本技能 - 如果只是询问"代码写得怎么样"这种主观评价，不需要走完整流程

frontmatter 里的 name 和 description 是最关键的。description 是 agent 决定"何时激活这个技能"的依据。如果 description 写得模棱两可，agent 要么该用的时候不用，要么不该用的时候瞎用。这里有个很实用的技巧：description 应该写成"当用户做什么事时使用"，而不是"这是一个用于做某事的工具"。前者是触发条件视角，后者是自我介绍视角，对 agent 的语义匹配来说，前者命中率高得多。

2.3 为什么用 Markdown 而不是代码来定义技能

这是很多从传统软件开发转过来的朋友最容易纠结的问题。有人会问：为什么不用 JSON 或者 YAML 把技能定义得结构化一点？为什么不能直接写成一个 Python 类？

原因在于，skills 的使用者不是传统程序，而是大语言模型。LLM 最擅长解析的格式就是自然语言和 Markdown，其次才是 JSON 这类半结构化数据。你用 JSON 定义规则，规则一长，模型读起来反而费劲，而且 JSON 对"流程步骤"的表达非常别扭。Markdown 的优势在于，它既有标题、列表、代码块这样的结构，又保留了自然语言的灵活表达，模型可以快速抓取标题层级，也可以精读细节。

更重要的是，Markdown 支持一种"渐进式披露"的用法。SKILL.md 的主文件只写触发条件、执行步骤和注意事项，尽量控制在几百行以内；深度的参考资料放到 references 目录里，只有 agent 走到某一步才去读。这样既不会在对话一开始就吃掉大量 token，又能在需要时把细节翻开。这很像前端里的懒加载，用不到的资源先不加载，真正要用了再拉回来。

2.4 不同平台的加载与触发机制

目前市面上主流 agent 平台对 skills 的实现细节不完全一致，但核心逻辑高度相似：启动时扫描一个指定的 skills 目录，读取每个 SKILL.md 的 frontmatter，把 name 和 description 注册进可用的技能列表；当用户请求命中某个 description 时，加载对应的 SKILL.md 和相关资源，按里面的步骤执行。

Claude 的 agent skills、Codex 的 skills 仓库，以及一些第三方工作台，本质上都是这个套路。差异主要在于：配置文件放在哪个目录、frontmatter 里要求的字段名、是否支持多级子目录、脚本运行的基准路径是哪里。所以要提醒你：拿到一个新平台的 skill 说明，先看文档，不要凭印象猜路径。我见过有人把 Claude 的 skill 目录结构直接套到别的框架上，结果加载失败,还以为是平台 bug。

这里顺带说清楚一件事：skill 加载不等于执行。加载只是让 agent"知道有这个技能"，真正触发是运行时的语义匹配。同一个 skill，在不同平台上的触达效果可能不一样，因为背后模型的判断方式不同。这也是后面第四章要展开的"跨平台兼容问题"的根源。

3. 手把手开发一个可落地的 Skill：前端代码质量门禁实战

3.1 选题：为什么选代码审查作为示例

理论知识铺垫完了，接下来直接进入实战。我选"前端代码质量门禁"作为示例，有三个原因：第一，这个任务本身是多步骤的，需要先理解规范、再扫描代码、最后输出报告，非常适合展示 skill 的组合能力；第二，它既需要 Markdown 知识（团队规范的描述），也需要脚本逻辑（正则扫描），能完整覆盖 skill 的两种编写方式；第三，前端开发相关 skills 算是目前社区里需求最旺盛的类别之一，实操价值高。

你可以把这个示例理解成一个最小可用的骨架。真正用到自己的项目里时，你完全可以替换成"后端 code review""测试用例生成""发布前检查清单"等等，结构是一样的。

3.2 编写 SKILL.md：一个可直接抄作业的模板

我在 2.2 里给过缩略模板，这里把它扩成一个能直接用的版本。先看完整的 SKILL.md：

--- name: frontend-code-review description: 当用户要求审查前端代码、检查 PR 或 MR、做代码质量门禁评审、查找 console.log/debugger/TODO 残留，或要求按团队规范检查前端代码时使用。 --- # 前端代码质量门禁 ## 背景 这个技能用于对前端代码进行一轮结构化审查，目标是发现会导致线上事故的高危问题，以及影响可维护性的结构性隐患。 ## 执行步骤 1. 确定审查范围：如果用户给了具体文件路径，只审查这些路径；否则审查当前工作目录下的前端项目。 2. 读取 references/coding_standards.md，记住其中列出的禁止项。 3. 运行 `python3 scripts/check_frontend.py <目标目录>`，获取机器扫描结果。 4. 根据扫描结果，结合 coding_standards.md，将问题分为三类： - 阻断问题：可能泄露密钥、存在明显安全风险、包含 debugger 语句 - 警告：console.log 残留、TODO/FIXME 未清理、明显重复代码 - 建议：风格不一致、命名不规范 5. 输出一份 Markdown 报告，按上述三级分类，每条问题标注文件路径、行号、问题类型和修复建议。 ## 输入要求 - 目标目录必须是本地存在的绝对路径或相对路径 - 用户没有指定路径时，使用当前工作目录 ## 输出格式 - 标题为"代码审查报告" - 开头先给一个统计摘要：总共发现多少问题，其中阻断/警告/建议各多少 - 随后按严重程度从高到低列出问题明细 ## 注意事项 - 不要修改任何代码，只做审查和报告 - 如果脚本执行失败，把错误信息原样附在报告末尾，并说明无法完成机器扫描 ## 不适用场景 - 用户要求的是后端、安卓或 iOS 代码审查 - 用户只是询问代码风格意见，没有要求完整审查流程

这个模板你直接复制就能用。注意最后一段"不适用场景"，这个小节在多数开源 SKILL.md 里都不存在，但它非常有用。加了它之后，agent 误触发的频率明显下降，因为它有了一个"反向边界"，知道什么情况下不要碰这个技能。

3.3 配套脚本：让 Skill 从"讲方法"变成"能执行"

光有 SKILL.md 的话，审查流程里"扫描代码"这一步还得靠模型自己读文件、自己找问题。这当然也能做，但速度慢、token 消耗大，而且容易漏。所以我们要配一个脚本，把确定性最强的部分用代码完成。

下面是我这个示例里的 check_frontend.py，它做的事情很简单：扫描目标目录里所有前端文件，用正则找出常见的 debug 残留和疑似硬编码密钥，输出 JSON 结果。

#!/usr/bin/env python3 """检查前端代码里的常见 debug 残留和疑似硬编码密钥。""" import json import os import re import sys target = sys.argv[1] if len(sys.argv) > 1 else "." issues = [] patterns = { "console.log": re.compile(r"console\.(log|debug|info)"), "debugger": re.compile(r"\bdebugger\b"), "todo": re.compile(r"TODO|FIXME"), "hardcoded_key": re.compile(r"(sk|api[_-]?key|token)\s*[:=]\s*['\"][A-Za-z0-9]{16,}"), } CODE_EXTENSIONS = (".js", ".jsx", ".ts", ".tsx", ".vue") for root, dirs, files in os.walk(target): # 跳过依赖目录和版本控制目录 dirs[:] = [d for d in dirs if d not in ("node_modules", ".git", "dist", "build")] for f in files: if not f.endswith(CODE_EXTENSIONS): continue path = os.path.join(root, f) try: with open(path, "r", encoding="utf-8") as fh: for line_no, line in enumerate(fh, 1): for name, pat in patterns.items(): if pat.search(line): issues.append({ "file": path, "line": line_no, "type": name, "text": line.strip()[:120], }) break except Exception as e: issues.append({ "file": path, "line": 0, "type": "read_error", "text": str(e), }) # 截断到前 50 条，避免输出过大 result = { "issue_count": len(issues), "issues": issues[:50], "truncated": len(issues) > 50, } print(json.dumps(result, ensure_ascii=False, indent=2))

脚本的输出做了两个关键设计：一是结构化，用 JSON，agent 解析起来非常省力；二是截断，最多输出 50 条，避免几千条匹配项把上下文灌爆。脚本只负责"找出问题"，至于"这个问题严不严重、该怎么改"，留给 SKILL.md 和模型去判断。这是 skill 脚本设计的一条核心原则：机器该做的用代码做，判断该做的交给模型做。

3.4 测试与迭代：把 Skill 装进实际 Agent 里跑一遍

写完之后最重要的一步是装进去实测。以多数支持 skills 的平台为例，你要做的是把整个目录放到它指定的 skills 路径下。不同平台路径不同，一般你在设置界面里能看到，或者在启动日志里会打印出来。放好之后，用几种不同说法去触发同一个请求：

• "帮我 review 一下这个前端项目"
• "检查一下 PR 里有没有 console.log 残留"
• "按咱们团队的规范过一遍代码质量"
• "找找这个项目里的 debugger"

我在测试时建议开 verbose 或调试日志，观察 agent 是否真的读取了 SKILL.md。如果日志里根本没提到这个技能，八成是 description 里的触发词和你的说法对不上。我第一次测试的时候就栽过一跤：description 里只写了"前端代码审查"，结果我说"检查 PR"它没反应；把"PR""MR""质量门禁""debug 残留"这些变体全部加进 description 之后，命中率才上去。

还有一次，脚本没有设置退出码，即使扫描失败 agent 也把输出当成正常结果拿去做报告了。修复方式很简单，在脚本里根据结果设置退出码，并在 SKILL.md 的"注意事项"里写明"脚本退出码非零时，不要生成报告"。这类问题只有真正跑过一轮才会暴露出来。把 skill 跑通之后，记得把"team standards"这类私有知识写进 references，你的 skill 才真正属于你自己。

4. 常见问题与排查技巧实录

4.1 Skill 不生效或未被触发怎么办

这是最高频的问题，没有之一。百分之八十的情况都出在下面四个地方，按顺序排查基本能解决。

第一，确认 skill 目录被平台识别到了。有些平台需要显式启用某个 skill，或者要放在特定子目录里。你看一眼启动日志，平台通常会列出它扫描已经加载的 skills 列表。不在列表里，那就先解决路径问题。第二，检查 frontmatter 格式。frontmatter 是 YAML，YAML 对冒号、引号、缩进的容错率很低，少一个引号、多一个空格，整个文件可能就被解析成普通正文，name 和 description 全失效。第三，检查 description 的表达方式。如果你的 description 写的是"这是一个代码审查技能"，agent 在语义匹配时不一定能联想到"PR、质量门禁、console.log"这些说法。把它改成"当用户要求审查代码、检查 PR/MR、做质量门禁，或要求查找调试残留时使用"这种触发条件句式，命中率会立刻改善。第四，确认请求里确实传达了"要干活"的意图。很多不触发案例其实是 agent 判断用户只是想聊天，不是要执行任务，这时候 skill 不触发反而是正确行为。

一个我常用的测试技巧是准备一张"触发词矩阵"：把用户可能发出的十几种说法写下来，逐一触发一遍，记录哪些命中、哪些没命中。然后把你实际测试中出现的真实说法不断补充进 description。两三轮之后，这个 skill 在你日常工作场景里的触发率会稳定在九成以上。

4.2 上下文爆炸：SKILL.md 太肥怎么瘦身

另一个高频问题是上下文爆炸。症状是对话刚开始，token 消耗就大得离谱，或者 agent 处理正经任务时频繁"忘事"。原因通常有三个。

第一个原因，SKILL.md 主文件写得太长。我见过有人把整个团队的完整规范直接塞进 SKILL.md，总共两万多字。每次触发都要全文读一遍，token 哪能顶得住。对策是主文件只保留必要部分：触发条件、执行步骤、输入输出要求、不适用场景。满打满算控制在六百行以内，通常两三百行就够用了。第二个原因，references 里的资料被一次性全量读取。规范文件、模板文件、行业标准，agent 一股脑全灌进来。对策是把 references 按子任务拆成多个小文件，并且用更精细的指令，让 agent "只有走到某一步时才去读某个文件"。第三个原因，脚本输出未经截断。脚本把几百个匹配项、几千行日志直接打印出来，全部进入上下文。刚才示例脚本里那种"只输出前 50 条"的做法，就是一个标准解法。

这里顺带解释一下 token 是什么。token 是模型处理文本的最小计量单位，可以粗略理解为"模型眼里的一小段字符"。中文一个字通常对应一到两个 token，英文一个词通常对应一个 token。上下文窗口能容纳的 token 有限，所有从 SKILL.md、reference、脚本输出进来的文本，都在和用户对话、业务数据抢占这个空间。所以瘦身 skill，本质上是把钱（token 预算）花在刀刃上。

4.3 跨平台不兼容：一份 Skill 多端跑的适配思路

同一个 skill 能不能在 Claude、Codex、自研框架里同时跑？答案是：能，但需要一点适配。不同平台的 frontmatter 字段要求不一样，有的要求 name 必须和目录名一致，有的不要求；有的支持多级子目录，有的只扫描一层；脚本运行时的工作目录有的在 skill 目录，有的在用户当前目录，直接会导致脚本里的相对路径失效。

最省事的思路是"通用核心 + 平台适配层"。SKILL.md 本身用最朴素的 Markdown 写，不依赖任何平台的私有语法；脚本调用也写成通用的python3 xxx.py形式，不做平台特定处理。然后在 skill 目录里放一个 README 或 per-platform 文档，记录每个平台的安装路径和需要调整的字段。我自己实践下来，这种写法的 skill 迁移成本最低。

另外要提防一个隐蔽的坑：有些平台会限制 skill 目录里脚本执行时的网络访问，有些不会。如果你的 skill 依赖外部命令（比如调用 eslint），务必在 SKILL.md 的"输入要求"里写清楚环境依赖，否则换个机器就跑不起来。特别是团队共享 skill 的时候，一定要约定运行环境，不然别人拿到你的 skill 只会两眼一抹黑。

4.4 脚本执行与沙箱：别让 Skill 乱跑本地命令

skill 里的脚本默认是在本机真实环境中执行的，这意味着它有真实的文件系统权限，甚至可能是当前用户权限。这里有一条红线要讲清楚：来自不可信来源的 skill，脚本一定不要直接跑。它们的执行步骤可能设计成读取~/.ssh目录、读取环境变量并输出到日志，然后在某个环节把这些信息发出去。

我自己的习惯是，凡是执行完整脚本的 skill，都先放进容器里跑一轮，或者至少用一个没有敏感权限的独立用户运行。脚本里如果涉及写文件，尽量限制在它自己的临时目录，避免用绝对路径覆盖项目文件。SKILL.md 里的步骤也会审查一遍：有没有要求 agent "读取环境变量"“读取 ~/.env”"输出到日志"这类危险动作。这部分在第五章还会展开讲，因为当前 skills 生态里，安全风险被严重低估了。

5. Skills 生态与安全：下载渠道、质量判断与风险防控

5.1 现在去哪找现成的 Skills

自己做 skill 固然好，但社区里已经沉淀了大量现成的技能包，直接拿来改比从零开始省力得多。目前获取渠道主要分三类。

第一类是官方渠道。Claude 有 agent skills 的官方市场，Codex 也有对应的 skills 仓库，平台文档里通常直接能搜到。第二类是基于 GitHub 的社区聚合仓库。搜索 "awesome agent skills" 这类关键词能找到很多人整理的 skill 清单，按用途分好类，比如代码审查、文案生成、数据分析、视频脚本生成、测试用例生成等等。这些仓库往往附带安装说明，质量参差不齐，但作为灵感来源非常不错。第三类是第三方 agent 工作台内置的技能库。社区里一些常用的 agent 工具（名字里带 Hermes、Superpower 的几个，你可能也见过）会提供在应用内浏览和安装 skill 的功能，相当于把 skill 做成了类似应用商店的形态。

不管从哪下载，第一步都是把压缩包或仓库里的文件完整看一遍，尤其是 SKILL.md 和所有脚本。不要嫌麻烦，这一步的重要性会在后面体现。

5.2 如何判断一个 Skill 是否值得安装

我装过不少 skill，也踩过不少坑。现在总结出一套快速判断标准，你可以直接拿来用。

先看 SKILL.md 本身：name 和 description 是否清晰，执行步骤是否具体到"能执行"，有没有写出输入要求和输出格式。一份认真写的 SKILL.md 会让你在读完之后，立刻知道这个 skill 什么时候用、怎么用、产出什么。再看配套资源：有没有示例、有没有测试脚本、有没有维护者的实际使用记录。一个连最基本示例都没有的 skill，多半是随手写出来丢上来的。然后看维护状态：最近一次更新是什么时候，issue 区有没有人在反馈问题，维护者有没有回复。三个月不更新不代表一定不行，但如果是几个月前发布且没有任何互动记录，风险就明显升高。

社区里那些"万能 skill"要特别警惕。一个声称什么都能干的 skill，往往什么都干不好。真正高质量的 skill 都是"窄而深"的：解决一个明确的问题，解决得特别好。我自己的经验是，一个 star 数不高但专注解决单个痛点的小 skill，往往比 star 数很高的大而全 skill 好用得多。

5.3 恶意 Skill 的常见套路与防护措施

2025 年的供应链攻击早已经不局限于 npm 包和 Docker 镜像了，skill 正在成为新的攻击面。它的危险之处在于隐蔽：一份 SKILL.md 看起来只是文字，但它能诱导 agent 去执行一连串动作，而这些动作可能远超你的预期。

恶意 skill 的套路通常有几类。一类是在执行步骤里塞入"读取环境变量""读取 ~/.env 文件并作为参考资料"，然后配套脚本把这些信息拼进正常输出。另一类是让 agent 访问某个外部地址，把环境信息作为请求参数发出去。还有一类更隐蔽：表面上做正经任务，但脚本里内置了删除文件、修改全局配置等破坏性操作，只等某个条件满足就触发。

防御措施其实不复杂，但需要变成习惯。第一，只安装可信来源的 skill，安装前把 SKILL.md 和每个脚本逐行过一遍，重点关注它要求 agent 访问的路径和域名。第二，用 git 管理你的 skills 目录，每次更新都看 diff，别让"某个依赖更新了"悄悄带进恶意内容。第三，给 agent 配置最小权限，不要用管理员账号跑 agent，脚本执行尽量沙箱化，网络访问默认禁止，需要时单独放行。第四，定期回看 agent 运行日志，观察有没有异常的网络请求和文件访问。安全测试类的 skill 有它存在的价值，但只应该在明确授权的范围里使用，这点没有任何商量余地。

5.4 下一步：把 Skills 变成个人或团队的能力资产

最后一个话题，我想聊聊 skills 的上限。很多人把 skill 当成一个"高级 prompt 模板"，装完就完了。但真正用好 skills 的人，是把它当成能力资产来经营的。

对个人来说，skill 可以和 agent 记忆形成互补：记忆负责"记住你和它的历史",技能负责"把重复的工作流固化下来"。当你的 skills 库积累到一定量级，你会发现启动新任务的速度完全不一样了：不用再一遍遍解释背景，一句"按项目规范出周报"就够。对团队来说，skills 应该像代码一样被管理：放进共享仓库，走 review 流程，维护语义化版本号，更新时写 changelog。我见过有的前端团队把编码规范、发布检查清单、回滚预案全部做成 skill，新人入职后直接让 agent 按团队流程带跑一遍，效率提升非常明显。

再往下走，单一 skill 的堆积会逐渐形成"技能编排"的需求。一个开发任务可能需要依次触发代码审查 skill、测试生成 skill、发布检查 skill，它们像流水线一样串联起来。这种组合方式，其实已经摸到了多 agent 协作的门槛。从单 skill 到技能组合，再到多 agent 编排，这条进化路径，值得你花时间认真走一遍。

我自己现在的习惯是"先写 skill，再开始干活"。一个任务只要重复出现两次，我就会琢磨把它沉淀成技能包。因为从第三次开始，省下的时间和注意力，远超当初写 skill 投入的那点功夫。

踩过最深的坑，是早期比较迷信社区里那些"万能 skill"，装了一堆之后发现，真正稳定有用的反而是自己按业务场景写的三五个。所以我的建议很朴素：先动手做自己的第一个 skill，再考虑批量试用别人的。

最后分享一个小技巧：写 SKILL.md 的时候，在末尾加一段"本技能不适用场景"，能显著降低误触发概率。就这一句，让我的 skill 误触发率降了不少，实测下来很值。