企业官网建设流程全解析

做 AI 工具分享这一年，我后台和社群里被问到最多的词，已经从 prompt 悄悄变成了 Skill。你要是在开发者社区里待上一阵，应该没少刷到“全网最火 50 个 Skill——已按功能分好类”这种标题。它并不是某个平台的活动专题，而是过去两个月里，社区里集中涌现出来的一大批可复用技能包。我顺着这些热词一个个点进去试，也自己动手写了不少，最后干脆按功能把它们整理成了 10 大类。

这篇文章不打算照着标题罗列名单，而是先把“Skill 是什么、和 Agent 有什么区别”这层窗户纸捅破，再把 50 个热门的 Skill 拆成清单讲清楚，最后给出一套“从零手写一个 Skill”的实操方法，以及我在实际使用中踩过的坑。无论你是写代码的、做研究的、做内容的，还是只是拿 AI 辅助日常办公，都能从中找到能直接搬走的东西。

1. 先搞清楚：Skill 到底是什么，为什么突然这么烫手

1.1 Skill 的准确定义

Skill 直译过来是“技能”，但在 AI Agent 的语境里，它更像是“给 AI 的一份可复用的操作说明书”。一个 Skill 通常由一个文件夹组成，里面有 SKILL.md 主文件、参考文档、脚本、示例数据，用来告诉模型：在遇到某一类任务时，应该按什么步骤做、用什么工具、遵循什么约束、输出什么格式。

你可以把它理解成新员工入职时领到的工作手册。手册不会替员工做决定，但能让员工在遇到“报销”“周报”“客户投诉”这些场景时，不用每次从头猜流程。Skill 干的就是这件事：把经验固化成文件，AI 每次调用都按同一套标准执行，结果自然稳定得多。

现在很多主流工具，比如 Claude Code、Codex、Trae，或者更底层的 LangGraph、OpenClaw，都在用类似机制。定义一个 Skill 往往就是一个文件夹的事：里面有个主说明文件，再塞几份参考材料，AI 在需要的时候自动读取并执行。通俗点说，Skill 就是 Agent 生态里的“插件”，装什么技能，就擅长什么活。

1.2 Skill 和 Agent 到底怎么分工

很多朋友一上来就问“Skill 和 Agent 的区别”，这两个概念确实容易混，因为在多数产品界面里，它们都表现为“帮 AI 加能力”。但实际上分工很清晰：Agent 是能感知环境、自己做规划、循环调用工具直到完成目标的“数字员工”；Skill 更像是这个员工手里的 SOP 和工具包。Agent 决定“要不要做这件事、先做哪一步”，Skill 决定“这件事具体怎么做、做到什么标准”。

举个例子，你让 Agent“把这个项目的代码仓库整理成周报”，Agent 需要自己规划：先看 git log、再分析改动文件、最后生成报告。但“周报格式”“重点看哪些指标”“哪些内容不写进周报”，这些属于经验，交给 Skill 来承载更合适。两者结合，Agent 负责跑流程，Skill 负责告诉它怎么跑得像熟手。

1.3 为什么这半年 Skill 突然火起来

这波热度不是凭空来的，背后有三个直接推力。

第一，终端型 Agent 开始大规模进入日常工作流。Claude Code、Codex CLI、Trae 这类工具让 AI 不再是聊天框，而是真的可以接管终端、文件系统、浏览器。可接管能力越强，越需要“行为规范”——同样一个需求，AI 自由发挥和按 Skill 执行，产出质量能差出一大截。

第二，上下文窗口哪怕再大，也是浪费不起的。把几百页参考文档塞进提示词，既贵又容易让模型“看到后面忘了前面”。Skill 把极少量的引导词放进上下文，大体积资料放在外部文件里按需读取，相当于给模型做了一套“本地外挂记忆”。

第三，社区已经形成了创作和分享的正循环。一方面有 Skill Creator 这类工具帮你脚手架式生成，另一方面大家越来越愿意把自己的工作流打包发布。热词里能看到各种垂直领域的 Skill，从数学建模、日志分析到 PPT 排版、双语翻译，几乎是“万物皆可 Skill”。这种由用户自己贡献能力的生态，一旦跑起来，内容增长速度是惊人的。

2. 全网大热 Skill 盘点：50 个按功能分成 10 类

我整理清单的原则很简单：尽量选社区声量大、我实际试过或看别人复现过、能代表某一类场景的 Skill。数量上凑了 50 个，按功能分成 10 类，每一类我都标了典型代表和适用人群，方便你直接跳到感兴趣的段落。

2.1 编程与工程效能类（8 个）

这类 Skill 是开发者最关注的，主要解决“AI 写出来的代码能不能直接进项目”的问题。

• Codex 工程化 Skill：面向 Codex 终端场景，把“接受需求→读仓库→改代码→跑测试→提交 MR”整个链路做成标准动作，适合日常用 Codex 提效的团队。
• Claude Code 大仓协作 Skill：专门处理超大仓库，教模型先看 README、再查目录结构、只读相关模块，而不是一次性把整个代码库塞进上下文，实测下来对长任务很有帮助。
• Trae 项目上下文 Skill：在 IDE 内使用，让 AI 理解当前工程的技术栈、目录约定、提交规范，类似“项目级入职培训”。
• 代码评审 Skill：自动按规范检查 MR，包括潜在空指针、安全风险、命名一致性、单测覆盖率，能省掉不少 reviewer 的口舌。
• 日志分析 Skill：遇到线上异常时，指导 AI 先归类日志级别、提取时间线、匹配错误码，再给排查建议。这块在运维和 SRE 场景特别吃香。
• 嵌入式开发 Skill：面向单片机、RTOS、驱动开发场景，包含交叉编译命令、寄存器操作规范、常见外设调试套路，能把嵌入式工程师的重复劳动降下来。
• Allegro 电路设计辅助 Skill：覆盖 PCB 布局检查、约束规则复核、网表比对等工作，适合硬件工程师搭配 AI 做设计审阅。
• GSAP 动效开发 Skill：给前端动效需求用的，包含动画曲线选型、时间轴编排、性能优化点，反正我试过一次之后，再做交互原型基本离不开它。

2.2 内容生产与创作类（7 个）

内容类 Skill 的爆发，本质上是因为大家发现：让 AI“会写”不难，难的是让它“写得有网感、有结构、像真人”。

• PPT 排版 Skill：自动把大纲转成页面结构，统一标题、正文字号、色彩、图标风格，顺带帮你控制每页字数，避免“字多到没人看”。
• DrawIO 绘图 Skill：用 DrawIO 画架构图、流程图、时序图，按约定风格设定节点颜色、连线和分组，再也不用一张张手动调格式。
• 长文写作 Skill：面向深度长文，先做提纲、再扩写、每段落有主题句、结尾给结论，适合公众号、博客、行业报告的写作。
• 新媒体标题 Skill：根据内容生成 10 个不同方向的标题，并解释每个标题的点击心理，是我见过的“小但极实用”的技能。
• Humanizer 去 AI 味改写 Skill：解决“一眼 AI”的问题。它会去掉过度工整的排比、模板化的连接词、多余的“首先其次最后”，让文本更口语、更有人味。
• AI 漫剧分镜 Skill：把小说片段改成分镜脚本，包含景别、时长、台词、画面描述，做短剧和漫剧的朋友应该知道这东西多省时间。
• 双语字幕翻译 Skill：不只是翻译，还会做断句时间轴、口语化处理、文化梗注释，翻译质量明显比直接扔给大模型高。

2.3 数据与科研类（6 个）

科研和数据场景的 Skill 有个共同点：它们不追求“发散”，追求“严谨可复现”。

• 数学建模 Skill：覆盖问题抽象、模型假设、公式推导、代码求解、论文排版的全流程，参加数学建模比赛的学生党反馈最积极。
• 科研论文拆读 Skill：把一篇 PDF 论文拆成背景、方法、实验、结论四块，提取关键公式和数据，并标注可复现性，读文献效率翻倍。
• 数据清洗 Skill：让 AI 按你预设的规则处理缺失值、异常值、重复记录，每一步都记录处理日志，保证数据血缘可追溯。
• 统计图表 Skill：自动判断数据类型，推荐合适的统计方法，输出带解释的图表代码，避免“拿到数据就画折线图”的误区。
• 商业数据分析 Skill：面向业务分析报告，包括指标口径对齐、趋势解读、归因分析和行动建议，适合数据分析师和运营。
• Archify 知识库检索 Skill：面向信息归档和知识库场景，自动整理文档标签、摘要、关键人物和项目时间线，让“存了等于没存”变成“随取随用”。

2.4 浏览器与信息流自动化类（5 个）

这类 Skill 主要在 Browser 类工具里跑，本质上是让 AI 自己会“看网页、点按钮、翻页面”。

• Browser 自动化 Skill：通用的网页操作能力，包括打开链接、填写表单、点击元素、处理弹窗，是其他网页技能的基础件。
• 网页内容抽取 Skill：从文章、商品页、公告里提取结构化字段，比如标题、日期、价格、正文，输出成表格或 JSON，做信息收集很顺手。
• 信息聚合与存档 Skill：定时抓取指定站点，按主题去重、摘要、归档，方便做竞品监控和行业情报。
• 表单自动填充 Skill：根据用户提供的信息自动填表单，并做校验确认，适合处理重复性录入工作。
• 网页截图归档 Skill：对指定 URL 做整页截图，加时间戳和描述保存到本地目录，特别适合做版本对比和备份留痕。

2.5 语言与表达类（5 个）

人类交流里最难教的不是语法，而是分寸感。语言类 Skill 就是来解决这个的。

• 语言学习陪练 Skill：模拟对话场景，带发音反馈、语法纠错、词汇拓展，还能根据你的水平自动调整难度。
• Impeccable 措辞打磨 Skill：在邮件、文档、公告里逐句检查用词，替换掉生硬或容易产生歧义的表达，让英语和中文写作都更地道。
• Taste 品味校准 Skill：这个 Skill 比较特别，它主要调整“审美和分寸”，比如内容该幽默还是严肃、该详细还是留白，避免 AI 输出一股“用力过猛”的味道。
• 跨文化沟通 Skill：面向跨国协作场景，了解不同文化的沟通禁忌、汇报习惯、时间观念，减少邮件扯皮和会议冒犯。
• 演讲提纲 Skill：把一个主题拆成开场钩子、三个核心论点、案例、行动号召，并估算每段演讲时间。

2.6 效率与工作流类（5 个）

这类的共同特点是“把琐事标准化”，适合所有每天被消息和排期追着跑的人。

• WorkBuddy 日程安排 Skill：解析邮件、IM 消息里的时间点，自动生成日程草案，并按优先级排序，相当于一个小秘书。
• Skill Recorder 流程录制 Skill：把你自己操作 AI 完成任务的步骤录制下来，导出成标准 Skill，特别适合团队内部做经验沉淀。
• SuperPower 工作流 Skill：一个综合性的效率技能，整合了任务拆解、番茄钟提醒、复盘模板，能直接当成个人效能基线用。
• 软件项目管理个人看板 Skill：针对个人开发者的项目管理场景，帮你维护待办、迭代计划、风险清单，每周末自动生成本周总结和下周计划。
• 邮件/IM 消息处理 Skill：对堆积的邮件和消息做批量分类、提炼待办、拟定回复草稿，能让人从信息洪水里喘口气。

2.7 设计与可视化类（4 个）

设计类 Skill 的目标不是替代设计师，而是把“沟通需求→拿到初稿”这个循环压缩到分钟级。

• 信息图表 Skill：把数据和文字结论变成信息图结构，合理选择图表类型、颜色层级和排版，输出到 PPT 或网页。
• 统一调色 Skill：给定主色后，自动生成整套色板的明暗变体、强调色、中性色，并给出无障碍对比度提示。
• 信息架构图 Skill：把网站、后台、业务流程拆解成层级结构图和交互流转，适合产品经理和架构师画原型前的准备。
• 动效原型 Skill：用代码快速搭建交互动效原型，并给出缓动函数和时间轴建议。

2.8 行业垂直应用类（3 个）

行业类 Skill 看起来小众，但每个都解决一撮人的真实痛点，社区里热度反而很扎实。

• 法律文书审查 Skill：帮忙检查合同和文书的条款缺失、日期冲突、明显风险点，并生成修改意见清单，适合法务和创业者。
• 教育备课 Skill：自动设计教学目标、课堂活动、练习题和评估标准，按不同学段调整语言深度。
• 财务对账 Skill：解析银行流水和业务账单，自动按规则归类、找出差异项、生成对账报告，财务同学应该能看懂这个价值。

2.9 安全与合规检测类（2 个）

安全类 Skill 在使用上确实有门槛，我只推荐在授权范围内使用，比如自己公司的系统、SRC 众测、已获得书面授权的渗透测试。主要的价值是帮安全工程师把重复的扫描和复核工作自动化，而不是让人“一键攻击”。

• 授权渗透测试 Skill：指导 AI 按信息收集、漏洞探测、利用验证、报告输出的标准流程执行，并强调每一步都要有授权依据。
• 漏洞报告复核 Skill：自动核验漏洞描述、影响范围、修复建议是否完整，帮助安全团队统一报告质量。

2.10 扩展与开发类（5 个）

最后这 5 个，严格说是“生产 Skill 的 Skill”，适合你想从使用者变成贡献者的阶段。

• Skill Creator 脚手架 Skill：通过问答方式收集你的任务、工具、输出要求，自动生成 Skill 目录结构和 SKILL.md 初稿。
• Skill 调试器 Skill：用来定位“为什么 AI 没按 Skill 执行”，包括触发条件检测、上下文截断检查、命令错误定位。
• Skill 批量导出/迁移 Skill：把本地 Skill 在不同工具间转换格式，或者把一批 Skill 打包发布到社区。
• 多 Skill 编排 Skill：当一个任务会命中多个 Skill 时，定义它们的调用顺序和冲突处理规则，避免“几个技能打架”。
• LangGraph 节点注册 Skill：专门讲怎么在 LangGraph 里把 SKILL.md 注册成 Tool Node，让图流程中的 Agent 能调用外部技能。

这个分类只是我个人的整理口径，你不用完全照搬。真正重要的是把“我会用到哪几类”想清楚，然后按类目去搜、去试，比盲目囤一堆 Skill 有用得多。

3. 零基础上手：教你手写一个能稳定复用的 Skill

看了这么多，估计你已经想动手了。这里我拆解一套自己常用的方法，按这套流程写出来的 Skill 不敢说多高级，但至少在“稳定复用”这件事上经过了实战检验。

3.1 动手前先把这三件事想清楚

第一，任务边界。你要解决的到底是一件“频率足够高、步骤足够固定”的事，还是一次性任务？如果是后者，老老实实在对话里写提示词就行，没必要做成 Skill。只有当同一类需求反复出现，且每次都需要 AI 按照特定流程执行时，才值得封装成 Skill。

第二，输入输出。输入是用户的一句话，还是必须附带某个文件、某段日志？输出是表格、Markdown、代码文件，还是要 AI 直接执行命令并返回结果？这些在动笔前就要写清楚，不然 Skill 写出来只能你自己用。

第三，触发条件。Skill 什么时候被激活？是靠用户输入特定关键词，还是靠系统自动判断任务类型？不同工具机制不同，有的支持在 Skill 文件里写 when_to_use，有的需要你在对话里明确引用。提前确认这一点，能避免后来“明明装了却不生效”的困惑。

3.2 SKILL.md 的最小结构长什么样

一个标准的 Skill 目录可以长这样：

reimburse-skill/ ├── SKILL.md ├── references/ │ ├── expense-policy.md │ └── templates/ │ └── reimburse-form.md └── scripts/ └── extract_amount.py

其中 SKILL.md 是最核心的文件，我用下来的经验是，不管复杂程度如何，至少要包含四块：元信息、使用场景、执行步骤、约束条件。

元信息写在最前面，通常用 YAML 格式描述 name、description、when_to_use，这段内容决定 AI 能不能正确识别并触发技能。使用场景要说人话，比如“当用户需要整理差旅报销时使用”，别写得太绕。执行步骤要足够细，宁可分成十步，也别写成两大段，AI 对“明确步骤”的执行力远好于“笼统目标”。约束条件一定要写负面清单，比如“不要修改原始文件”“不要擅自估算金额”，没有约束的 Skill 经常会在边界情况上翻车。

3.3 实战：一个差旅报销 Skill 的完整示例

我拿“差旅报销”做个最小示例，这个场景不涉及复杂技术，但流程典型。

--- name: 差旅报销整理 description: 当用户提供差旅票据、行程记录或报销需求时，整理成标准报销单。 when_to_use: 用户提到“报销”“差旅费用”“发票整理”等关键词时。 --- # 差旅报销整理 ## 任务目标 把用户提供的零散差旅信息整理成一张结构化的报销清单，并输出 Markdown 表格。 ## 执行步骤 1. 收集信息：向用户确认出差日期、地点、交通方式、住宿费用、餐费及其他支出。 2. 分类汇总：按“交通”“住宿”“餐饮”“其他”四类归类。 3. 校验数据：检查日期是否连续、金额是否合理、票据是否齐全。 4. 计算总额：求和并核对分项。 5. 输出模板：按以下格式输出报销单。 ## 输出模板 | 日期 | 类别 | 项目 | 金额 | 备注 | | --- | --- | --- | --- | --- | ## 硬性约束 - 不要修改用户提供的原始凭证编号。 - 不要自行四舍五入或抹零。 - 如果票据缺失，必须在备注中标注“待补充”。

这个示例很短，但已经具备一个可用 Skill 的全部要素：触发条件明确、步骤可执行、输出格式固定、约束兜底。你可以把 references 里再放一份公司报销政策，AI 就会在处理时自动去查，而不是凭空编标准。

3.4 在 Claude Code、Codex、Trae、LangGraph 里怎么加载

写完之后最重要的一步是把它装进你日常用的工具里，不同工具的加载方式差别还挺大的。

Claude Code 这类终端型工具，一般是在项目目录下建一个.claude/skills/<skill-name>/文件夹，把整个 Skill 放进去，对话中自然触发即可。它的好处是跟着项目走，换团队、换电脑也不会丢。

Codex 的机制类似，通常会在配置目录里定义技能路径，你可以把 Skill 统一放在一个skills/目录，然后在配置文件里引用。如果你的 Codex 版本支持/import之类命令，也可以用命令直接把文件夹导入对话上下文。

Trae 作为 IDE 类产品，界面里一般有个“技能”面板，支持直接创建或导入 Skill。它更强调“项目级上下文”，所以 Skill 里可以引用项目的技术栈文档，效果比通用提示词更准。

LangGraph 这类框架则不是给终端用户准备的，而是给开发者做流程编排。它加 Skill 的方式一般是写一个工具函数，把 SKILL.md 的内容读成字符串，作为 Tool Node 注册进图里，Agent 在运行到某个节点时就能调用。你可以在节点里预置一句提示：“如果需要处理报销，读取 reimburse-skill 的 SKILL.md 并按步骤执行”，这样 LangGraph 就知道何时去调用。

还有像 OpenClaw 这样的开源个人助理框架，也支持把 Skill 当作插件加载。这些项目各有各的配置规则，但核心逻辑一致：Skill 就是一个文件夹，你把它放到合适的位置，再确保主文件能被读取到，就能跑起来。

4. 我用 Skill 踩过的坑，以及排查思路

说完了怎么做，再讲讲怎么把“不生效”的问题解决掉。我刚开始用 Skill 那阵子，几乎每个坑都踩过一遍，这里挑几个典型的分享。

4.1 装上 Skill 后完全没有反应

这是最常见的问题，十有八九是路径不对。Skill 目录没有放在工具默认扫描的位置，或者目录层级多了一层，工具根本扫不到。排查方法很简单：先确认工具的文档里写了默认扫描路径，再检查目录结构是否严格匹配。如果路径没问题，看一下 SKILL.md 的 frontmatter 是不是写错了，比如当 AI 的触发条件描述过于宽泛或过于狭窄，也可能导致它读了但判断“不适用”，最终没有任何输出。

4.2 同一个任务命中了多个 Skill

当你的 Skill 数量多了以后，经常会遇到两个 Skill 对同一输入都认为“该我上场”。这时候 AI 可能会混着用，结果两边都不讨好。解决办法是在 when_to_use 里写得更精确，进一步区分触发边界。比如“差旅报销”负责单据整理，“费用分析”负责统计趋势，两者明确分开；如果还不行，就用“多 Skill 编排”的思路，在主流程里定义优先级，让 AI 先跑哪个再跑哪个。

4.3 Skill 执行结果不稳定

如果你发现同一个 Skill 在上午跑得很好、下午跑就跑偏，大概率是步骤写得太粗，AI 有太多自由发挥的空间。我的经验是，把步骤拆到足够细，并给每一步配上明确产出。比如不要写“分析数据”，要写“先按时间排序，再按类别聚合，输出每类的小计和总计”。另外，负面约束要写得具体，比如“不要在表格中使用合并单元格”，越具体越好。还有一个小技巧是内置至少一个“示例对话”，让 AI 参照示例的样式输出，稳定性会明显提升。

4.4 上下文被 Skill 文件撑爆了

有些朋友喜欢把几十页文档直接堆进 SKILL.md，结果一次对话就把上下文干爆了。更好的做法是遵循“主文件极简、参考资料外置”的原则，把大量知识放到 references 目录，只在 SKILL.md 里告诉 AI“需要时去查某个文件”。这样既保留了细节，又不占用宝贵的上下文空间。

下面这张表是我常用的排查速查，你可以直接存下来对照。

回头看，我最开始写 Skill 时也走了一段弯路，总想把功能做得又大又全，结果维护成本高，AI 反而不听话。后来我把每个 Skill 都收敛成“一个小场景、一套标准动�作、一个固定输出”，用起来才真正顺手。现在我的本地库里常驻的 Skill 大概二十来个，都是高频、稳定、能明显省时间的场景。

写这个清单的过程中，我自己的体会是，Skill 火起来不只是一阵风，它其实是“AI 从聊天走向干活”这条路上的必然产物。与其追着新出的 Skill 挨个收藏，不如先梳理清楚自己的高频工作流，把最耗时间的那几件事封装成自己的技能包。等你有三五个自己写的 Skill 并持续用上一个月，你就知道这东西到底值不值得投入了。