企业官网建设流程全解析

1. 这玩意儿到底是个什么：AI 编程助手的“技能弹药库”

先说个我自己的真实场景。上个月我在做一个内部工具的重构，代码库不大，但接口调用关系绕得厉害。我的 AI 编程助手给我生成了一版重构建议，方向是对的，可它明显没搞懂这个项目里“配置中心”和“权限校验”之间的隐式依赖，导致改出来的代码在边界情况下直接崩。当时我意识到一个问题：不是 AI 能力不行，而是它对我的项目上下文“一无所知”。

后来我找到了 Antigravity Awesome Skills 这个技能库，准确说是面向 Antigravity 这类 AI 编程助手的可安装技能集合。它里面收录了 1527+ 个 skill，覆盖从需求拆解、代码生成、测试覆盖、安全审计到提交信息规范的各种场景。所谓“技能”，你可以把它理解成给 AI 助手外挂的“专业手册”，一个技能就是一套结构化的指令包、检查清单和示例集合，装上之后助手在处理某类任务时会自动调用对应的知识和操作流程。

这篇文章我打算讲透三件事：

• Antigravity 的技能机制到底是什么，和普通提示词有什么区别；
• 这 1527+ 个技能分布在哪些赛道，哪些真正值得装，哪些装了纯属浪费；
• 从安装到踩坑，再到自己写一个技能塞进去的完整实操路径。

如果你正在用 AI 编程助手，且觉得它“好像会，但总是差点意思”，这篇应该对你有用。我自己是从“用完就忘”的提示词党，变成了“把知识沉淀成技能”的配置党，这个转变直接改变了我用 AI 的工作方式。

2. 为什么 1527+ 个技能不是“多多益善”：筛选比收藏重要得多

2.1 技能库的本质：把“优秀实践”变成可复用资产

先说说“技能”这个东西在技术上的本质。

大家平时给 AI 写提示词，写的是“给我写一个 Python 函数，实现 xxx”。这句话是一次性的，离开当前对话就失效，换一个任务又要重新写。而一个 skill 文件不是这样，它通常包含三部分：

• 触发器描述：什么时候该用这个技能。比如“当用户要求对代码做安全审计时”；
• 执行流程：AI 拿到任务后应该按什么顺序做什么。比如先读配置文件、再定位敏感操作、最后按风险等级输出报告；
• 输出模板与质量标准：结果应该长成什么样。比如必须包含“风险等级、受影响接口、修复建议”三栏，缺一不可。

这就像你给实习生长篇大论讲了一遍工作流程，然后他每天都能按这个流程干活，不用你每次重新说。Antigravity 的 skill 机制就是这个思路——把一次性的优秀实践固化成文件，需要的时候自动触发。

理解了这个本质，你会发现：技能库的价值不在数量，而在于每个技能是否真的覆盖了一个你经常重复做的任务类型。1527 个听起来很唬人，但其中真正和你日常工作重合的，可能就几十个。装太多反而会让助手在选择技能时纠结，甚至触发错误的技能。

2.2 按工作流给技能分类，比按“技术栈”分类更能提高选择效率

我看了一下这个技能库的目录结构，最开始的分类是按技术栈来的：Python、Java、TypeScript、Rust……但实际用下来，我强烈建议你别这么选。

因为技术栈是“静态的”，而你的工作是“动态的”。你写 Python 不代表你只干一个固定流程的活，你可能今天写数据脚本，明天做接口调试，后天又去排查性能问题。如果只按语言装技能，你会陷入两个困境：要么每个语言都装一堆，技能总数爆炸；要么漏掉跨语言的通用环节，比如需求拆解、测试设计这类和语言无关的底层能力。

我自己的做法是按工作流分类，挑出这几类优先级最高的：

按这个维度选，装 20 个左右就能覆盖我 80% 的日常 AI 使用场景。这个结论不是我拍脑袋想的，是我把过去一个月的 AI 使用记录翻出来统计的——和 AI 的对话里，超过一半都落在这几类任务上。

2.3 技能挑选的四个原则：我反复踩坑后总结出来的

第一，看技能的描述是否“场景化”。好的技能描述会写“当你需要把用户故事拆成开发任务时”，差的只会写“需求分析技能”。前者 AI 能准确匹配，后者大概率触发不了。

第二，看技能的约束是否足够具体。比如一个好的测试生成技能会规定“必须覆盖空值、超长输入、并发调用三种边界”，而不是笼统地说“生成全面测试”。约束越具体，AI 的产出越稳定。

第三，看输出格式是否清晰。有些技能定义了精确的输出模板，AI 生成的结果不需要二次整理；有些技能只给了一堆建议，AI 输出的东西还是要你重新加工。我反正优先选前者。

第四，起步求稳，不追求覆盖全。新手期的价值点是确定性：装了 10 个技能，每个都能稳定生效，这比装了 50 个技能、有一半在“间歇性生效”强得多。等你熟悉了 skill 的触发逻辑，再逐步扩大技能面不迟。

3. 动手装一次：从克隆仓库到验证技能生效的完整流程

3.1 环境准备和目录结构说明

Antigravity 这个助手读取技能的方式和读取配置差不多：它有自己的技能目录，你只要把 skill 文件放进指定目录，并确保文件名和后缀符合规定，它就会在启动时自动扫描并加入可调用列表。

我当时的操作路径大概是这样的：

# 1. 克隆技能库仓库（如果只想挑着装，也可以先下载到本地再手动拷贝） git clone https://github.com/example-org/antigravity-awesome-skills.git # 2. 确认 Antigravity 的技能目录路径 # 通常位于用户目录下的 .antigravity/skills cd ~/.antigravity/skills

这里有个特别容易忽略的点：目录路径因系统而异。我同事在 Windows 上装的时候，目录路径就藏在用户目录的 AppData 下面，和 macOS 完全不一样。建议你先在 Antigravity 的配置界面里看技能目录的实际地址，别默认按文档里的路径来。

3.2 推荐安装方式：按需复制，不要一口气全装

1527 个技能如果全部复制进目录，理论上 Antigravity 也能启动，但实际体验会很差——启动扫描变慢不说，AI 在选择技能时还会出现“选择困难”，最典型的表现就是你让它写个排序算法，它居然先触发了“系统架构设计”技能，输出的内容直接跑偏。

我推荐的做法是先筛选后复制，分三步走：

# 1. 在技能库根目录搜索你工作流中需要用到的技能名 # 比如：安全审计、测试生成、提交规范、文档生成… cd antigravity-awesome-skills ls skills | grep -i security ls skills | grep -i test ls skills | grep -i commit # 2. 把这些技能目录逐个复制到 Antigravity 的技能目录 cp -r skills/security-audit ~/.antigravity/skills/ cp -r skills/test-generator ~/.antigravity/skills/ cp -r skills/commit-standard ~/.antigravity/skills/ # 3. 重启 Antigravity，让技能扫描逻辑重新加载

有的小伙伴喜欢直接软链接过去，好处是技能库更新的时候不用重新复制：

ln -s /path/to/antigravity-awesome-skills/skills/security-audit ~/.antigravity/skills/

这个方式我后来也用了，但它有个坑：如果你在技能库里改文件名或者移动目录，软链接会断掉，Antigravity 会静默忽略失效的技能，而且不报错，你只会发现某个技能“不灵了”，排查起来很费时间。

3.3 怎么确认技能真的生效了

装完之后最让人心虚的时刻就是“到底装没装上”。我自己的验证方法有两种。

一种是直接看技能列表。在 Antigravity 的会话界面里，输入斜杠命令查看已加载技能，比如/skills list，如果目录里的技能出现在列表中，说明扫描成功。这里注意：不是所有版本都有这个命令，如果你用的版本没有这个命令，跳过直接看下一条。

另一种是行为验证法，我更推荐这个。你故意触发一个技能对应的场景，然后看 AI 的输出是否带有该技能定义的格式特征。比如我装完 commit 规范技能后，让它为一个改动生成提交信息，如果它输出的 commit message 严格带上了“类型、影响模块、关联需求”的结构，大概率就是生效了。反之，如果你试了两三次都还是它“自由发挥”的样式，那不管列表里有没有，都要查一下是不是没加载成功。

4. 实测记录：这几个技能让我从“能写”变成“写得对”

4.1 代码审查技能：从“看热闹”到“看门道”

以前我让 AI 帮我 review 代码，得到的反馈基本就是“这段代码逻辑清晰，但可以增加异常处理”——正确的废话。装了代码审查技能之后，它的输出完全变了一个层级。

当时我拿一个同事写的支付回调接口做试验，这个技能直接输出了三类问题：

• 表象问题：参数校验不完整，某个字段没有判断空值；
• 隐患问题：回调幂等性只查了本地状态，没有考虑并发下的重复回调；
• 规范问题：错误码不符合项目里“前两位表示模块”的约定。

说实话最后一条是我看完之后才发现项目里真有一份错误码规范文件，只是我和同事都忘了。这就是技能的价值——它把“应该查什么”写成了检查清单，AI 在触发时会按清单逐项过，而不是凭语感给你泛泛而谈。

这个技能给我最大的启发是：审查类技能好不好，取决于它的检查清单够不够细。你看技能内容的时候，别只看开头几句好听话，重点翻它的步骤列表和输出模板。

4.2 测试用例生成技能：边界条件不靠猜

测试用例生成技能是我在技能库里最惊喜的一个发现。装的这个技能要求 AI 在生成用例时必须先列出“输入域分析”，也就是把所有可能输入的类别分出来，再针对每一类写用例。

我拿一个日期格式化函数来试，AI 在分析阶段就列出了：有效日期、闰年 2 月 29 日、非闰年 2 月 29 日、月份 13 日、日期为 0、时间戳为 0、负数时间戳、超大时间戳。一共 8 类。

其中“月份为 0”和“日期为 0”这两类是我自己在平时写用例时最容易漏掉的，因为人下意识觉得“月份不都是 1 到 12 吗”。AI 在技能约束下会机械地执行“列全输入域”的步骤，反而逼着它做了更完备的覆盖。

装了这个技能之后，我做了一个明显的改变：让 AI 生成用例之后，我不会直接复制，而是先看它的“输入域分析”列表，把我觉得还缺的类别补上，再让它按补充之后的类别生成代码。AI 就从一个“写用例的”变成了“按我补充后的思路写用例的”，效果完全不一样。

4.3 文档生成技能：README 终于不是摆设了

项目文档是我最不愿意写的东西，没有之一。但我也清楚，文档缺失的后果是三个月后没人能看懂这个模块在干什么。

这个技能库里的文档生成类技能，触发时会先自动遍历项目的目录结构和关键文件，然后把文档分成“项目简介、快速开始、配置说明、目录结构、常见问题”几个固定板块。最让我意外的是，它会要求 AI 在“快速开始”部分把每个步骤对应的命令都写全，而不是写“安装依赖然后启动”这种假大空。

“常见问题”板块也很有意思，技能要求 AI 根据代码里的 TODO、异常处理分支和注释中的疑点，自动推断出用户可能会问的问题。当时它读到某个模块里有个“临时兼容逻辑”的注释，就在文档里生成了一条“常见问题：为什么这里需要临时兼容？”——这一条比我自己写文档时会想到的还全。

5. 踩坑记录：技能装了没效果，先别急着砸键盘

5.1 技能未生效的排查链路

我自己遇到过最无语的一次：装完测试生成技能之后，怎么触发都没反应。后来排查了一圈发现是技能描述里的触发关键词和我实际表达的场景不匹配。

很多技能在描述里写的是“当用户要求生成单元测试时”，但这个触发条件在 Antigravity 的技能选择器里通常是通过语义匹配来实现的，不是简单的关键词命中。我当时让 AI “给这个函数写测试”，语义上应该能匹配上，但结果就是没触发。

排查链路我是这么做的，分享给大家：

1. 先确认技能文件位置正确。我检查了目录，发现文件确实放进了~/.antigravity/skills/下，而且文件名后缀符合规范。
2. 重启确认扫描加载。重启后我重新检查/skills list，如果在列表里就没加载问题。
3. 观察 AI 的输出是否带技能特征。如果完全不带，说明 Meshidator 在选择技能时没把它选中。
4. 修改技能描述里的触发词。这个是需要你自己动手的地方，把描述改成和你日常表达更接近的说法。比如原来写“当用户要求生成单元测试时”，我改成“当用户要求给函数写测试、搞用例、覆盖测试时”，改完之后触发率一下就上来了。

这里多说一句：触发词不是越多越好。有些人为了保险，把能想到的词全塞进描述里，结果语义匹配器反而因为选项太多而犹豫，最终触发了一个不准确的技能。我的经验是描述保持在两三句话，每句话对应一种常见的表达场景，就够了。

5.2 上下文膨胀：装多了反而影响质量

第二个坑是：技能装多了，AI 在输出时会把多个技能同时激活，导致上下文膨胀，质量问题就来了。

我装完代码审查和测试生成技能后，有一次让 AI 帮我 review 一段 Python 代码，输出里居然同时出现了代码审查意见和测试用例设计，看起来好像很全面，但两边的深度都不够。后来去看了技能加载逻辑，才发现技能系统是按“相关度”激活的，两个技能的相关度都被判得比较高，就同时拉进来了。

解决方法是给技能配置“互斥提示”。在技能的描述或约束里写明“本技能只专注于代码审查，不涉及测试用例生成；如果用户同时要求测试，请分两步执行”。加了这句话之后，AI 的“串味”现象明显减少。

5.3 同名覆盖：你以为装了，其实是白装

还有一个特别隐蔽的坑：同名覆盖。技能库里有不少跨语言、跨框架的同名技能，比如都叫code-review的就有好几份。如果你先后把两个同名技能都复制进目录，Antigravity 一般使用目录扫描机制，后扫描到的同名技能会覆盖先扫描到的，而且没有任何提示。

我一开始完全没注意到这个问题，后来发现审查风格时好时坏，才意识到目录里有两个code-review文件夹。排查的时候你可以这样看：

# 搜索技能目录里的同名文件（macOS/Linux） find ~/.antigravity/skills -name "*code-review*" -type d # 如果出现两个目录，保留你真正想要的那个，另一个删掉或改名

这是我实际踩过的坑，属于那种“不让你报错、只会让你怀疑人生”的类型。

6. 装得再多也是别人的：自己动手写一个技能，比想象中简单

6.1 技能的最小文件结构

用了一段时间之后，我最大的一个感受是：你真正用得顺手的技能，往往是按自己的项目习惯调过的。与其等技能库里出一个完全合心意的版本，不如自己做一个小小的。

Antigravity 的技能文件格式不复杂，一个 skill 通常就是一个目录下一份描述文件外加可选的规则文件。最小的完整技能结构大概是这样：

my-review-skill/ ├── SKILL.md # 技能描述，包含触发条件和执行流程 └── rules.md # 详细规范和检查清单（可选）

SKILL.md是灵魂。我自己写了一个针对“项目接口文档一致性”的审查技能，内容大概是：

--- name: api-doc-consistency-review description: 当用户要求审查接口文档与代码实现的一致性时触发。 --- ## 执行步骤 1. 读取当前项目的接口定义文件（如 OpenAPI 配置）。 2. 扫描代码中对应的路由和控制器实现。 3. 逐项对比接口定义与代码实现，找出不一致项。 4. 输出差异清单，每项包含：接口路径、文档定义、代码实现、差异说明、修改建议。 ## 输出格式 | 接口路径 | 文档定义 | 代码实现 | 差异说明 | 建议 | | --- | --- | --- | --- | --- |

你编译完这个文件，放进技能目录，重启一下，它就变成一个可以在需要时自动触发的技能了。第一次写的时候我有点忐忑，结果跑通之后觉得比想象中简单太多。

6.2 写技能时容易被忽略的三件事

第一，执行步骤要拆到“可机械执行”的粒度。不要说“分析接口一致性”，要说“对比接口定义中的路径参数与代码路由中的路径参数是否一致”。前者需要 AI 自己判断怎么做，后者是明确指令，输出的稳定性完全不同。

第二，输出格式的约束一定要具体。我之前写过一个技能，只写了“输出审查结果”，结果 AI 输出的是大段散文，根本没法直接用来提工单。后来我把输出格式强制改成表格，AI 每次都会规规矩矩填表格，虽然少了点自由发挥，但实用性直接翻倍。

第三，要先小范围验证再推广。新技能写完先自己在几个典型场景下试，确认输出符合要求后再考虑拷给别人。我之前写了个需求拆解技能，自我感觉很好，结果给同事用了一次，他跑过来说“这个技能拆得太啰嗦了，25 分钟的任务能拆成 8 个步骤，我看着都累”。后来我把步骤合并成了 4 个，才勉强能用。

7. 最后再分享一点我自己的使用心得

Antigravity Awesome Skills 这个技能库的价值，不在于那 1527+ 这个数字，而在于它给你提供了一套“把 AI 调教成团队老手”的范式。装技能不是目的，筛选技能、调整技能、最终能自己写技能，才是我觉得真正有意义的一条路径。

我现在的工作流已经固定下来了：用完一个任务，凡是重复超过三次的，我就考虑能不能把它写成一个技能；写完先用一个月，期间不断调整触发描述和执行步骤。到现在，我的技能目录里大概常驻 30 个技能，这 30 个是经历了“装了删、删了改、改了再装”之后留下来的。

这篇文章写到这里，我不是想说服你把这个技能库全装一遍，恰恰相反，我想说的是：别管它有 1527 个还是 15270 个，先挑 10 个能解决你当下最大痛点的，装上、试用、调整，然后再决定要不要继续加。工具是死的，怎么让 AI 和你配合得越来越顺手，这个探索的过程才是你真正会长期受益的东西。