企业官网建设流程全解析

别只堆 MCP：用高星 Agent Skills 拼一条「研究→交付」闭环

周末手又痒想折腾 Agent 时，最容易做的两件事是：再装一堆 MCP，或者再下一堆「神级提示词」。过两周你会发现，上下文被工具 schema 吃光，模型开始乱点技能，真正重复的脏活还是每次临场发挥。

Agent Native 在 Medium 上那篇20 AI Agent Skills With ~800K GitHub Stars…换了个切法：与其追逐单点神技，不如看 Skills 能不能组成一条真实工作流。文中那句很好记——设计良好的 skill，是把 Agent 本来会即兴发挥的步骤打包成规程；光这一项，就能干掉一整类重复劳动。

他们用五个动作串起来：

看清问题 → 摸清系统 → 把东西做出来 → 检查发生了什么 → 发出下一版。

大约二十个高星 skill（文中合计约 80 万 GitHub stars，是写作时的近似加总，不是单一仓库）被按层塞进这条环里。Daily Digest 和公开页能稳定读到的是这条环的主张；完整 20 项名单在抓取时被截断，下文按「层」解读，并辅以同期公开技能目录里的同层代表，避免把二手名单冒充原文清单。

Skill 到底是什么

在现在的 Agent 生态里，skill 通常是一个可安装的说明书包（常见形态是带SKILL.md的目录）：写清何时触发、步骤、约束、要读哪些文件、成功长什么样。它和「再写长一点的系统提示」不同——技能按需加载，用完可不常驻；也和 MCP 不同——MCP 给的是工具通道，skill 给的是做事方法。

可以粗暴记：MCP 是手和眼睛，skill 是工艺卡。没有工艺卡，手上工具越多越容易乱动。

一条环，五段能力

1. 研究：先看见问题

这一层解决「别凭训练语料硬猜」。公开目录里常见的高星方向包括：限定时间窗的网络/资讯检索（例如 last30days 一类）、学术或深度调研包、把「找技能」本身做成技能的发现器。要点不是搜得更多，而是把检索规程（来源、时效、引用）写死，减少一本正经的过期结论。

2. 映射：先读懂系统再动手

代码库、依赖图、技术债、架构约束——Agent 一上来就改文件，后面的返工往往从这里开始。Graphify 这类「先图化再改」的高星项目，以及各种 codebase / tech-debt 审计技能，做的是同一件事：先有地图，再谈施工。和前文 Harness 的 L1「信息边界」是同一个直觉。

3. 制作：把规程塞进生成过程

UI/UX 约束、幻灯片/可视化说明、框架最佳实践（React/Next、移动端、云成本……）都属于这一层。模型「会写」和「写得像你们团队」之间的差距，多半靠技能里的具体规则补上，而不是靠再骂一句「请写出生产级代码」。

4. 检视：让完成定义离开模型自信

代码审查、测试、可观测、安全检查类技能，对应 harness 的 L5/L6。没有独立检视，环会在「我写完了」处提前断开。好的检视技能会带着可执行检查清单，而不是只输出形容词。

5. 发布：把下一轮迭代接上

SEO、文档人性化（humanizer 一类）、视频/ffmpeg、发布与增长相关技能，负责「做出了」到「送出去」的最后一截。缺了这层，Agent 停在本地仓库里的漂亮 diff，团队仍然要靠人肉搬运。

五段不必每段都装五个技能。更常见的健康状态是：每段 1～2 个你真的会每周用到的，总技能数保持克制。

星数能说明什么，不能说明什么

~800K 是传播数字，有用，但有毒。星数近似「有多少人围观」，不近似「对你的仓库安全」或「和你的模型合拍」。同期整理过技能目录的文章也反复强调：先读SKILL.md和它拉取的脚本，再决定装不装；供应链污染（恶意 skill）已经不是假想敌。

选型时我自己的经验法则更土：

• 只装对应真实重复任务的技能，不装「以后可能用到」
• 优先官方或维护活跃的发布者（Anthropic / Vercel / Cloudflare / 云厂商等目录里能对上的）
• 装完立刻在真实任务上打一发，不好用就卸——技能也占上下文与决策带宽
• 星数用来排序候选，不用来免责

和 MCP、Harness 怎么摆在一起

一张很实用的分层：

• Harness：边界、权限、编排、状态、校验——工作环境
• MCP：文件系统、浏览器、GitHub、文档检索——能力接口
• Skills：研究/映射/制作/检视/发布的规程——行为方式

只堆 MCP，Agent 有手无章法；只堆 Skills，没有工具又走不远；两者都有但不做 harness，权限和上下文会在长任务里一起崩。Agent Native 这篇的贡献，是把「技能收藏夹」扳回「技能流水线」。

你可以怎么组最小栈

若只能装三个：一个研究（带时效）、一个代码库映射、一个审查/测试。跑两周真实需求，看哪一段还在靠即兴发挥，再补那一段。

已经在用 Claude Code / Codex / Cursor 的，优先清点现有 skills 与 MCP 是否重叠：同一件事既挂了浏览器 MCP 又挂了浏览器 skill，往往该合并触发条件，而不是双开。

把「技能清单」写进仓库的AGENTS.md或内部手册：每个技能对应哪类任务、禁止用于什么、失败时人工接管点。这比在群里丢一串 npx 命令更像工程。

安装时我实际会做的检查

拿到一个高星 skill 仓库，先别npx上头。按这个顺序过一遍通常够用：

看SKILL.md的触发描述是否真匹配你的任务，还是营销句。
看它是否要求额外 MCP、环境变量或联网脚本；要求越多，攻击面越大。
在临时目录或容器里试跑一次，观察它读写了哪些路径。
把「允许在什么仓库使用」写进团队约定，避免个人点装污染共享环境。

技能生态现在很像早年的壳脚本收藏夹：复制成本低，审计成本高。星数帮你排序，审阅帮你活下来。

闭环比清单更重要的一个原因

很多人装完 20 个技能，发现 Agent 更忙了，交付却没更快。常见原因是环断在「检视」或「映射」：研究很热闹，一改代码就没有地图；写出了 PR，却没有独立检查。

所以与其追求「凑齐原文 20 个」，不如每两周问一次：我们最重复的三个任务，各自卡在五段里的哪一段？只补那一段的技能。清单文提供的是地图图例；你的仓库流水线才是地形。

怎么读这篇更有用

原文是周末向的高星清单文，完整 20 项在本批抓取中未能无损还原，因此本文强调「闭环分层」与选型原则，不对读者承诺「这就是那 20 个名字的一一对应表」。若你要对照安装，请直接打开 Medium 原文与各仓库的SKILL.md。

它和样本稿里的 Harness²、以及本批的 Harness 工程文是同一光谱上的不同焦距：Harness 讲环境合同，Skills 讲可插拔规程。把规程装进环境，比把规程粘在聊天框里，更接近「能复利的 Agent」。

参考来源

1. Medium 导读（正文名单层抓取不完整）：20 AI Agent Skills With ~800K GitHub Stars That Form a Real Agent Stack — Agent Native
2. 同期公开技能星数整理（二手目录，非原文名单）：AI Agent Skills on GitHub: Top Repos by Stars (2026)
3. Agent Native / BuilderIO 技能与框架入口：https://github.com/BuilderIO/skills · https://www.agentnative.dev/skills

星数随时间变化；安装前务必审阅技能内容与权限。