企业官网建设流程全解析

提到“skills”，很多人第一反应是“技能”，但在最近的AI开发圈里，这个词已经变成了一套非常具体的东西——它可以是Codex里的一段指令包，也可以是Claude Agent里的一个能力插件，甚至是一整套“拿来就能用”的工作流。我最早接触“skills”这个概念是在折腾前端开发自动化的时候，发现光靠一段Prompt根本压不住复杂的项目结构，后来看到有人把“让AI处理某项任务”的方法封装成可复用的技能包，才意识到这玩意儿才是Agent真正好用起来的关键。

这篇文不聊虚的，我想把我这段时间摸爬滚打总结出来的东西讲清楚：skills到底是什么、怎么选、怎么自己写一个、怎么测试调试，以及各种坑。不管你是前端、后端、安全研究，还是单纯想用AI写论文、做分析的，都能找到可以“抄作业”的部分。

1. 先理解skills到底是什么——从一杯咖啡的“配方”说起

1.1 一个生活化的类比

你可以把skills想象成一杯拿铁的制作流程：咖啡豆、牛奶、糖浆、温度、比例，这些是材料；而“拿铁做法”就是把材料变成成品的那套步骤和配方。没有配方，你和咖啡师面对同样一堆材料，做出来的东西天差地别。AI模型就是这个咖啡师，它本身知道怎么“做咖啡”，但你如果不说清楚“要什么口味、用什么豆、水温多少、奶泡打到什么程度”，它就只能凭感觉发挥。

Skills的本质，就是一套结构化的“配方”。它把某一类任务的执行方法固化成文件、脚本、说明文档和示例，让AI在遇到相关任务时能自动加载、按步骤执行、输出符合预期的结果。它不是模型本身，也不是一个独立的程序，它是“模型 + 上下文 + 工具 + 工作流”的组合包。

在OpenAI Codex、Claude Agent、各式开源Agent框架里，skills通常表现为一个目录，里面包含SKILL.md说明文件，还有辅助脚本、模板、参考文档等。当Agent发现当前任务和某个skill匹配时，就会按照这个skill定义的流程去处理。

1.2 为什么这个时代突然开始狂提“skills”

因为纯Prompt对话的短板太明显了。你可以让AI“帮我写一个带搜索功能的前端页面”，它能给你代码，但如果让它“按照团队规范、技术栈、目录结构、接口风格来完成这个页面并自动跑测试”，一次对话根本写不清楚，而且每次都要重复描述。

Skills就是把这种“描述”沉淀下来。一次写清楚，之后所有项目都能复用。一个人写好了，团队其他人也能直接引入。GitHub上有大量别人整理的skills包，有前端的、后端的、写论文的、做数据分析的，这就是热词里“skills推荐”“skills大全”出现的原因——大家在互相共享和交换“配方”。

1.3 一个最小可用的skills到底包含什么

我拆解过几个比较流行的skills包，发现它们几乎没有例外地包含这几部分：

• 入口文件，通常叫SKILL.md，用Markdown写，告诉AI这个技能是干什么的、适用什么场景、需要哪些输入、输出什么格式、遵循什么步骤。
• 参考资源，比如代码片段、配置模板、常见问题列表、示例输出。这些内容不需要每次对话都塞进上下文，而是在需要时按需读取。
• 可执行脚本或工具，比如一个处理文件名的Python脚本、一个调用API的Shell命令。Agent可以调用它们来执行实际操作，而不是只能“嘴上说说”。
• 护栏规则，明确指出什么不能做、什么必须验证、什么情况下要停下来问用户。

所以你会发现，skills不只是一个“更长的Prompt”，它是把“知识”和“执行”绑在一起的综合体。这也是为什么很多人说“Skills让AI从聊天助手变成了干活的员工”。

2. 围绕“skills”怎么选、怎么用——热门方向与落地场景

2.1 前端开发skills：最常见的入门场景

热词里“前端开发skills”排得很靠前，确实，前端是skills最能发挥价值的地方。因为前端项目通常有固定的工程化流程：初始化项目、安装依赖、搭建目录、写组件、做类型定义、跑构建、修报错。这套流程如果每次都用一句“帮我做”开头，AI产出的东西往往风格各异、甚至跑不起来。

我试过把一套“前端页面生成skill”引入Codex，里面定义了标准目录结构（src/components、src/pages、src/utils），规定了必用TypeScript、组件命名用PascalCase、样式使用Tailwind并禁止全局CSS，还要求生成后必须执行pnpm build验证。效果非常直接：同一个任务，使用skill前生成的代码质量参差不齐，使用skill后基本一次通过构建，而且风格和团队手写代码的差异很小。

选择前端skills时，我会重点看几个维度：

• 是否和你的技术栈匹配（React/Vue/小程序等）。
• 是否包含工程化校验步骤（比如lint、build、test）。
• 是否明确了目录结构和命名规范。
• 是否附带了可运行的示例。

GitHub上搜索“codex skills”或者“claude skills”能找到一大堆，但很多质量一般。我建议优先看高星仓库、最近还在维护的，并且下载后先看SKILL.md的内容，别直接跑。

2.2 写论文、写文档、做研究的skills：知识工作者也能用

“codex写论文的skills”“workbuddy skills 写论文”这些热词也说明了大量需求。写学术类内容最大的问题是引文、格式、逻辑结构，AI容易一本正经地胡编。好的论文写作skill会强制要求分步执行：先梳理论文题目和摘要，再生成大纲，然后逐节撰写，每一步都必须基于用户给出的资料，不能凭空编造引用。

我在实际使用中总结出这类skills需要具备的硬性条件：

• 有“事实核查”步骤，标记出哪些陈述需要用户确认。
• 有引用格式模板，比如GB/T 7714或APA。
• 有段落长度与语言风格控制。
• 能输出可编辑的Markdown或LaTeX文件。

有些做法学、社会学研究的朋友也在用这类skills做文献综述和初稿，但记住：AI生成的论文一定要自己改，别直接提交。skill能管住流程，但管不住内容的责任。

2.3 安全研究方向：安卓脱壳skills的前置与边界

热词里有“安卓脱壳skills”“自动挖洞skills”，这两个词比较敏感，但作为技术分享还是可以说清楚的。在移动安全研究、合规的渗透测试、个人App自研调试中，应用加固与脱壳对抗是一个真实存在的技术领域。所谓的“脱壳skill”，其实就是把这个过程的方法论、工具链和步骤固化成Agent可执行的流程，比如检测加固类型、查找脱壳点、dump内存、修复导出表、去重等。

我自己并不建议初学者一上来就搞脱壳。原因很简单：环境非常容易翻车，各种厂商的加固方案差异很大，同一个skill在不同系统版本上表现极不稳定。如果你真的在做合规的安全研究，我的建议是把脱壳skill当成“辅助工作手册”，让它指导Agent帮你准备环境、执行命令行工具、整理脱壳结果，而不是完全自动一条龙。

至于“自动挖洞skills”，很多开源项目里都有，比如把子域名枚举、端口扫描、目录爆破、常见漏洞检测整合进一个skill。我只强调一点：先确认授权，再谈技术。没有授权的扫描是违法的，不管你的skill写得多漂亮。

2.4 Agent Skills测试与工具链

“agent skills测试”这个热词也提醒我们：skills不是写完就能用，是需要测试的。现在主流的方式有两种，一种是在官方市场里直接安装和试跑，另一种是在本地用sandbox环境跑一套自动测试用例。

我常用的测试工具链是一个docker容器，里面装上Codex CLI或Claude Agent SDK，再挂载skills目录，用一组标准任务来验证输出是否命中预期。例如，测试“代码审查skill”，就给它一个故意写了bug的仓库，看能不能定位到问题；测试“生成单元测试skill”，就给它一个带私有方法的类，看生成的测试能不能覆盖。如果你不想自己搭环境，很多开源项目也提供了基于pytest的测试套件，直接把skills包拉下来，运行make test就行。

3. 手把手开发一个自己的skills——从零到可复用

3.1 第一步：确定边界和场景

我刚开始写skills时犯的最大错误就是想“一步到位”，写一个包罗万象的skill，结果AI根本不知道该执行哪一步。后来学乖了：一个skill只解决一个问题。

比如你先做一个“给React组件生成storybook stories”的skill，不要想着同时覆盖“生成组件+写测试+写文档”。边界越清晰，SKILL.md里面描述的场景匹配就越准确，AI误用其他skill的概率也越低。

确定场景时可以回答这几个问题：

• 这个skill主要给谁用？前端同事、数据分析师还是自己？
• 需要Agent做什么？写代码、跑脚本、整理文档？
• 在什么情况下应该触发它？比如“用户说我要给Button加story”。
• 什么情况下不应该触发它？比如涉及后端接口联调时就别掺和。

3.2 第二步：设计目录结构和核心文件

我的习惯是每个skill一个文件夹，文件夹里至少包含：

my-skill/ SKILL.md references/ template.txt example-output.md scripts/ run.py tests/ test_case_1.txt

SKILL.md是灵魂。我自己写的时候会用这样一套骨架：

--- name: my-skill description: 这个skill用于xxx场景，当用户提出xxx请求时使用 --- # 任务目标 一句话说明这个skill要达成什么目标。 # 输入要求 需要用户提供什么信息，缺少时应该怎么询问。 # 执行步骤 1. 步骤一：... 2. 步骤二：... 3. 步骤三：... # 输出格式 说明最终交付物的格式，比如Markdown、JSON、代码仓库结构。 # 注意事项 - 不要做什么 - 在什么情况下停止并请求帮助

description字段非常重要。在Codex或Claude Agent中，系统就是靠它来匹配任务和skill的。描述得太笼统会导致误触发，描述得太具体会导致该触发时不触发。我推荐写成“当用户需要做X且环境包含Y时，使用此skill完成Z”。

3.3 第三步：让skill“说人话”——把执行步骤写细

很多社区里的skill写得像论文提纲，AI看完还是不知道具体怎么做。真正的skill执行步骤应当像操作手册一样，包含命令、参数、检查项和兜底方案。

拿“前端代码审查skill”举例，我在SKILL.md里会写：

• 先读取package.json，识别项目框架和包管理器。
• 如果使用了pnpm，用pnpm install安装依赖；如果lock文件是npm生成的，不要强行用pnpm。
• 执行eslint .和tsc --noEmit，把报错信息按严重程度分类。
• 审查组件目录时，重点看props类型、事件命名、样式是否“泄露”到全局。
• 审查完成后输出一个分类清单：阻塞问题、建议修改、可忽略。

这里面的关键是“如果…就…”逻辑。AI模型的执行能力很强，但它需要决策依据。你给它明确的分支条件，它就能像一个老员工一样自己判断，而不至于每次卡住都问你要下一步。

3.4 第四步：把参考模板和脚本放进去

如果你的skill涉及重复性的输出格式，一定要放模板。比如“生成周报skill”，模板就是周报的markdown结构；再比如“生成API接口文档skill”，模板里就包含请求路径、参数表、响应示例。

脚本的作用是让Agent能做更“重”的操作。我写过一个小脚本，用来从JSON文件里批量提取字段并生成元组列表，省得AI自己解析字符串时出错。脚本通常都用Python，因为跨平台、依赖少、容易调试。在SKILL.md里要写明“如果需要运行scripts/run.py，请使用python3，并传入参数--input xxx”。

写脚本时记得容错：做个try except，把异常信息返回给Agent，这样就算脚本崩了，AI也能根据错误信息来调整调用方式，而不是呆在那里。

3.5 第五步：自测与迭代

写完skill先别急着发布。我会先在命令行里做一个手工测试：

codex exec --skills my-skill "帮我根据这个模板生成一个Button组件"

看看输出是否符合预期。然后换一种说法：“现在要给Card组件加story文件”，测试触发匹配是否准确。最后再给一个完全不相关的任务：“今天天气怎么样”，确保它不会误触发。

迭代时要特别关注SKILL.md里的描述和步骤。AI不听话，通常不是它笨，而是你的spec有歧义。把“尽快”改成“在10分钟内”，把“检查一下”改成“运行git status并确认没有未提交的变更”，效果会立刻变好。

4. 测试、调试与常见坑——实操经验实录

4.1 为什么skill会不生效

遇到最多的情况是：skill已经放进目录了，但Agent就像没看见一样。原因大概率是描述匹配失败。Codex或Claude Agent采用语义匹配，如果你的description里用的词和用户提问差太远，就触发不了。比如你写的是“生成SVG图标”，别人问“给这个按钮加个箭头”，匹配不上很正常。

解决方式：把描述写得更有“召回率”，把同义词、场景词都放进去，但别堆砌。比如“生成或修改前端图标，包括SVG、iconfont、组件内联图标，适用于按钮、状态指示、加载动画等场景”这个描述就能覆盖不少变体。

还有可能是skill目录结构不对。有些框架要求SKILL.md必须放在某个固定位置，或者要求每个skill有唯一的name元数据。如果放错层级，系统在扫描时根本找不到。

4.2 调试技巧：让AI把自己的“思考过程”说出来

我调试skill的时候，会在开头加一句“请先说明你选择了哪个skill以及原因”，然后再执行任务。这样如果选错了，我能第一时间看出匹配问题。比如它选了“数据库设计skill”来处理“帮我写个接口”这种请求，说明描述里的边界不清晰，需要收紧。

还可以为每个执行步骤设置“日志点”，让AI在完成每步后输出一句话的总结。虽然会稍微消耗一些token，但对定位问题非常有帮助。正式使用的时候再让AI只输出最终结果。

4.3 常见的坑与避坑清单

下面这份清单是我踩过之后整理出来的，不一定全，但遇到频率很高：

4.4 多做“对抗”测试

在安全研究类skill上，我额外会做对抗测试：故意给出一段包含恶意执行逻辑的代码，看看skill是否会引导Agent去执行。如果skill没有护栏，它会老老实实地把命令写入自动化流程，这是一个非常危险的信号。做自动化挖洞或脱壳研究的同学特别注意，skill里面至少要有两条硬性护栏：默认禁止对非授权目标执行扫描、默认禁止上传任何敏感数据到第三方服务。

4.5 性能与上下文控制

很多人抱怨“skills让AI变蠢了”，是因为所有参考资料被一股脑塞进上下文，占用了大量token。实际上，按需加载才是正解。现代Agent框架里，SKILL.md本身是一份“目录”，AI读取它之后，再根据步骤打开具体文件。你不需要把所有内容都写进SKILL.md。

比如一个“数据分析skill”，SKILL.md里只要写：“用户提供数据集后，先读取scripts/analyze.py，按其中定义的5个步骤处理数据”。这样上下文占用少，AI的注意力也更集中。

4.6 如何在团队里工程化使用skills

到这一步，我强烈建议在团队仓库中单独建一个skills/目录，并用git做版本管理。每个人都能提交自己的新技能，但合并之前至少要过一遍review，重点看SKILL.md里的安全边界和命令是否可靠。

我团队现在的方式是：主要维护一套“前端基础skills包”，包含页面生成、代码审查、单测生成、组件库文档生成四个skill。新人入职只需要在Agent配置里指向这个目录，立刻就能获得“团队级的AI协作能力”，不用再反复解释项目规范。

还可以给skills加上版本号，在SKILL.md的metadata里写version: 1.2.0，这样当行为变化时，团队可以追踪是谁改的、改了什么。配合自动化测试流水线，每次push后跑set指定的样例，就能防止一个改动把其他业务场景搞坏。

我个人在实际操作中的体会是，不要把skills当成“一次搞完的工程”，它更像一个不断生长的知识库。最开始可能只有一个“代码审查”，用着用着就会觉得“要是它能顺便检查性能问题就好了”，于是迭代出第二个版本；又用一阵子，发现移动端和PC端规范不一样，于是又拆出两个独立skill。这种生长过程才是skills最有价值的地方——它把人和AI之间那些说不清的默契，一步步固化成团队可以持续积累的资产。

最后再分享一个小技巧：找一个你每天都在做的重复性任务，把它写成一个skill，哪怕一开始只有几百字的步骤，也足够了。用一周时间持续修正，你会明显感受到AI的产出从“能跑”变成“靠谱”。Skills的门槛并不高，关键是开始动手的那一刻，别想着一口气做完美，先让它替你干一次活再说。