企业官网建设流程全解析

导语

GitHub上面有一个名叫Skills的项目，在差不多一周的时间里，涨了一万多的Star。不少人看到这个项目之后，反应也就只有一个字，那就是收藏。这和当年大家收藏Prompt模板的情况，可以说是一模一样的。

但说实话，Skills这个东西，光靠收藏其实没什么太大的用处。倒不是Skills本身没有用，而是“收藏”这个动作本身，其实并没有多少实际的意义。因为Skills并不是一段简简单单的文字内容，而是一整套完整的做事方式。你所缺少的，并不是别人已经整理好的文件，而是你自己其实都没有想清楚，这件事到底应该如何去做。

一、AI 编程现在最烦的地方，不是它不会写代码

我现在越来越怕一种AI。
你刚把需求讲完，它就已经动手去写代码了。这样的场景看起来确实挺爽，但实际上却暗藏着不小的风险。

在真实开展的项目里面，代价最高昂的错误往往不是代码编写的速度不够快，而是从最开始的时候，整个项目的方向就出现了偏差。比如说你让人工智能工具去修复一段代码里的漏洞，它往往只是快速扫了一眼系统弹出的报错信息，就立刻开始着手进行修改。它可能只改动了三个相关的代码文件，然后运行了一次测试程序，接着就告诉你这个漏洞已经被成功修复好了。你去检查的时候会发现，原本的报错确实不再出现了，但原本可以正常运行的旁边一个功能模块，却莫名其妙地出现了故障。

这并非AI不够聪明。是它跳过了真实工程当中最土、最烦、也最要命的一步：先要把问题到底是什么搞清楚，之后再动手去开展相关的工作。

我最近这段时间一直都在留意一个事儿，叫 Skills。

这既不是什么Prompt，也不是MCP，更不是又一个AI圈子里造出来的玄乎词。

我查看了 GitHub 每周热门趋势榜单，mattpocock/skills 这个项目目前总共获得了 143766 颗星标，仅在过去一周就新增了 11784 颗星标。在我这次查询到的当周热门项目榜单里，它是涨幅最为突出的项目。

仓库的描述仅有一句话：Skills for Real Engineers. Straight from my .claude directory.

我先是翻了翻评论区还有Reddit、Hacker News上面的讨论内容，结果发现了一个挺有意思的现象。

不少人在看到这个项目的时候，第一反应往往就是把它给收藏起来。
先把 star 给点上再说。这可是个不错的东西，之后可以慢慢拿来看。等我哪天有空了，就去好好研究一下。

这个反应，跟当年Prompt火起来的时候简直一模一样。2023年还有2024年这两年，大伙都在疯狂地收藏Prompt模板。GitHub上面随便一个叫"Awesome ChatGPT Prompts"的仓库，都能拿到好几万的star。结果到底怎么样呢？大多数人收藏完了之后转头就给忘了。真到了要用的时候，还是随手就打一句"帮我写个周报"。

如今和技能相关的内容算是火了起来，类似的这种情况又一次上演了。

我今天想聊的，并不是Skills具体指的是什么、要怎么去进行安装，又有哪些值得去推荐的相关内容。这些相关的信息你随便去网上搜索一下，都可以轻轻松松地找到。

我想聊的是另外一个问题：为什么你收藏了再多的Skills，也未必就能用得好AI编程？这其中的缘由其实就只有一个，但大多数人并没有真正意识到这一点。

二、Skills 到底是什么？

我们可以先来快速对齐一下相关的概念。
Skills 这一特性，其实是 Anthropic 在 2025 年 10 月份的时候，在 Claude Code 上面所支持的相关内容。等到了同年的 12 月，他们就把 Skills 作为开放标准给推了出来，在这之后各类工具也就陆陆续续地接入了这一特性。

Anthropic 工程博客上的原话是：Agent Skills 是一组有组织的文件夹，当中包含 instructions、scripts、resources，agent 可以动态发现并加载，以此来更好地完成特定任务。

要把这个事情讲明白：Skills 其实并不是一段 Prompt，它本质上就是一个文件夹。这个文件夹里面不光会有说明文档，说不定还会有脚本，甚至可能还会有一些参考资料。Agent 在真正需要用到它的时候，再去加载就行，并不会一股脑地把所有内容都塞进上下文当中。

这里有个关键设计，叫作progressive disclosure，翻译过来也就是渐进式披露。换个说法就是：不要一口气把所有内容都塞给AI，先给出一个目录，等它觉得用得上的时候再往下翻。你平时点外卖也是这样的——先看商家列表，点进去之后再看菜单，选好菜品之后再看详情。不会有人一打开App就把200道菜全部铺在你面前。

这么设计的初衷其实很直白，也就是为了节省Token。在和大模型进行交互的整个过程里，对话的内容越长，模型的表现就会越差，那些使用过AI进行编程的人，大多都有过类似的使用体感。Token在Agent架构的设计环节当中，真可谓是寸土寸金。

好，关于这个概念的讲解也就到此为止了。
咱们现在来聊聊重点：大多数人其实都是怎么去运用这些技能的呢？

他们打开了GitHub之后，就看到了mattpocock/skills这个仓库，顺手就给它点上了一颗star。接着他们挑了几个看起来比较顺眼的技能，把它们复制到自己的.claude/skills目录里面，之后就没有再进行后续的操作了。
这和当年我们收藏那些Prompt模板的情况，其实并没有什么太大的差别。

二者其实并没有什么本质上的区别。
你换了个格式，换了个目录，换了个名字。行为模式其实都一模一样：把东西收藏起来，放在一边，到最后就落了灰。

问题出在哪？

三、你所缺少的其实并不是Skill文件

我给你讲一个相当具体的例子。
在 mattpocock/skills 这个项目当中，有一项被命名为 diagnosing-bugs 的技能。这项技能具体的执行流程大致是这样的：首先需要去完成问题的重现，紧接着要完成代码或者场景的最小化处理，随后再针对性地提出相关假设，之后再开展工具调试的工作，再之后进行修复操作，最后完成回归测试这一步骤。

我们可以先把这个bug给完整复现出来，接着再把排查的范围给逐步缩小，随后列出与之相关的各项假设，再搭配上对应的观测手段来开展验证工作，之后再去完成修复操作，最后补上回归测试的相关工作。
这套流程土不土？其实挺土的。任何一个拥有丰富经验的工程师，在修复程序漏洞的时候，都是按照这样的步骤来开展工作的。

但其实相应的问题也就跟着出现了。
要是你自己修复bug的习惯是先看一眼报错内容，再去猜测可能出现的缘由，接着修改一行代码，之后运行一下看看有没有报错，要是没报错就直接提交，那把这个技能装上去能起到什么样的作用呢？

并不是说完全没有用处。Agent 确实会按照既定的流程来开展工作，它会先尝试去进行复现，之后再逐步缩小范围，接着再列出相关的假设。但要是你根本不知道什么才算是“好的假设”、什么叫“有效的观测手段”、什么才是“足够小的复现范围”，那么你就连判断 Agent 做得好不好都做不到。你只会看到它运行了一堆步骤，输出了一堆文字，然后告诉你“修好了”。你也不清楚它是不是真的把问题修好了，还是仅仅只是把报错信息给藏起来了。
你甚至不会意识到自己其实判断不了。你以为它已经修好了。这才是最要命的。

Skills 其实是流程的放大器。要是你所搭建的流程足够清楚明白，它就会把这份清楚的流程进一步放大。要是你的流程本身存在着混乱的情况，它就会把这份混乱的流程同样给放大。

它并非是外挂程序。它不会平白无故地给你一套你原本就不具备的工作方法。

四、五个技能，就是五个工程层面的判断

我们可以来聊聊这个仓库里几个最值得好好讲一讲的技能。我并不是打算给你罗列一份清单，而是希望能让你看明白，每一个技能的背后，其实都藏着一项需要结合实际情况去做出的工程判断。

第一个，grill-with-docs：追问，别急着写代码。

我们可以来聊聊这个仓库里几个最值得好好讲一讲的技能。我并不是打算给你罗列一份清单，而是希望能让你看明白，每一个技能的背后，其实都藏着一项需要结合实际情况去做出的工程判断。

它不会帮你写哪怕一行代码。它所做的那些事会让人觉得相当烦人，就是会追着你去不停询问。
这个字段到底包含的意义是什么？这两个概念之间具体存在着什么样的关系？它的边界条件具体又是指什么内容？要是用户发起了退款的申请，我们又该如何去进行对应的处理？

要是你跟普通的AI说一句“帮我做一个用户邀请返利功能”，它马上就会开始动笔编写。像是邀请关系能不能设置成多级？退款之后返利该怎么计算？自己邀请自己的情况该如何处理？老用户补绑邀请人的话又该怎么办？这些问题它全都没有询问到。等到代码写完之后，你再去看，就会发现整体的方向已经出现了偏差。

grill-with-docs 所具备的价值，其实并不是让 AI 的运行速度变得更快，而是要让它慢下来，慢在那些应该慢下来的正确环节当中。

但这里有一个前提：你得清楚什么样的问题是值得去追问的。要是你自己都没有思考过“退款后返利怎么算”这个问题，那你也就不会觉得Agent追问这个问题有什么意义，你只会觉得它有些烦人。

第二个，diagnosing-bugs：别猜，先复现。

前面讲过了。它的流程是 reproduce → minimise → hypothesise → instrument → fix → regression-test。

这项技能背后藏着一个很朴素的工程层面的判断：很多程序漏洞没法顺利修复，并不是因为漏洞本身有多复杂，而是负责修复的人没有搞清楚这个漏洞到底是怎么一回事。

AI修复程序漏洞时，最容易出现的问题就是太过喜欢去做猜测。比如只是扫了一眼报错弹出的信息，立刻就锁定到某一行具体的代码，修改完成后再运行测试一遍，随后就直接告诉对方“漏洞已经修复好了”。但在真正的工程场景之中，这类修复方式往往很容易就会引入新的程序漏洞。

diagnosing-bugs的价值，是把"别猜"这两个字写进了流程。

但同样的，要是你自己在修复bug的时候从来不记录复现的步骤、不去缩小排查的范围，也不补充做回归测试，那么你安装这个skill也很难判断它每一步的输出是否正确。

第三个，tdd：测试根本不是为了给自己找台阶下。

这个技能运用的是red-green-refactor循环，也就是先编写无法通过测试的测试用例，再去实现能够满足需求的最小可用功能，最后再对代码进行重构操作。

TDD 对于人类来说其实都挺反直觉的，更不要说 Agent 了。要是没有流程上的约束，Agent 很有可能一口气就把测试和实现这两件事都做完了。等到做完之后，测试倒是能全部通过，但偏偏就没测到那些关键的风险。说白了，测试其实仅仅只是证明“我写的代码可以正常运行”而已。

tdd这项技能真正限制住的，其实是智能体也就是 Agent 的操作流程。我们得先动手编写测试用例，通过这种方式逼着自己想清楚，这段代码到底应该达成什么样的目标，之后再正式开展代码实现的相关工作。

但这里又存在一个前提：你得清楚什么是好的测试。边界条件具体是什么？异常路径具体是什么？关键业务逻辑具体是什么？要是你自己写测试的习惯只是“跑通了就行”，那么Agent按照TDD流程写出来的测试，你也没办法辨别它的好坏。

第四个，handoff：长上下文不是无限用的。

这项技能所起到的作用，就是将当前正在进行的对话内容，整理压缩成一份可以用于交接的文档，以此方便让另一个智能体接手，继续推进后续的相关工作。

但凡使用过AI编程工具的开发者都明白，在一场持续时间较长的对话过程中，所调用的Agent往往会出现性能下滑的情况。当聊天交互进行到两百轮之后，它就会逐渐遗忘掉最开始做出的那些决策，进而使得最终输出内容的质量出现明显的下降。

handoff解决的是一个很现实的问题：怎么把一个快撑爆的上下文，交给下一轮继续干。

但这项技能其实存在一个隐藏的前提，也就是你当下的对话质量需要达到合格的标准。要是当前的对话已经陷入混乱的情况，那么所谓的handoff仅仅只是把这种混乱的状况打包转移而已。下一轮Agent所拿到的将会是一份充满混乱的交接文档，只会让整体的情况变得比之前更加混乱。

第五个，codebase-design：别让 AI 把项目越改越烂。

这个技能聚焦于深度模块，也就是那些在小型接口背后还隐藏着更多操作行为的部分，要是把这些模块安置在边界清晰且规整的环境里，就能够通过接口测试来完成相关验证。

AI最容易产出一类看起来可以正常运行，但模块会越来越浅、文件会越来越碎、逻辑也会越来越散的垃圾。每当需要添加新功能的时候，大多都是在一个已经显得有些杂乱的模块上再额外贴上一块。

codebase-design的价值，是在 Agent 动手改代码之前，先让它想清楚模块边界。

要是你自己从来都没有认真琢磨过“这个模块的边界到底在哪”“什么样的内容应该暴露出来、什么样的内容应该隐藏起来”，那你也就不会真正理解这个技能究竟是在做些什么。

怎么说呢，看完这五个技能之后，你会发现这样一件事。它们都不是在教AI拥有什么新的能力，而是在对AI的行为进行管控。

五、真正用好 Skills 的人，做对了一件事

在把这五个技能都讲解完了之后，你应该能够慢慢察觉到其中藏着的一个规律。

每一项称得上有价值的技能，其实背后并没有什么特别高深的技术。它本质上就是创作者自己平日里一直在使用的工作方法。创作者会把这套方法完整地记录下来，拆分成一个个具体的步骤，再添加上检查环节以及应对失败的相关内容，之后告知智能体，以后再碰到这类任务的时候，就按照这个流程来开展执行。

所以真正能够把Skills用好的那些人，其实做对了一件事：

他们其实并不是在单纯使用Skills，而是在把自己平日里摸索出来的工作方法，仔细地封装成一个个Skills。

这两件事之间所存在的区别，其实还是比较明显的。
“使用 Skills”也就是运用技能的行为，属于消费行为。你看到他人撰写完成的内容，再将其拿过来使用。使用的效果好坏，取决于他人提供的内容是否适宜你自身的需求。

“封装 Skills”其实属于一种生产行为。你完全可以把自己每周重复三次以上的那些任务，把具体的步骤、需要遵循的标准、划定的边界以及应对失败的相关处理内容都写清楚，把它转变成一个Agent能够直接执行的工作包。

前者是收藏。后者是建设。

这其实就是为什么我要跟你讲，你哪怕是收藏了足足一百个skill，也不见得就真的能够把AI编程给用好。

你所收藏的，其实是别人的工作方法、别人的工程习惯、别人的项目结构，还有别人的团队规范。这些内容要是直接放到你的项目当中，大概率会出现水土不服的情况。

六、Prompt、Skills以及MCP，不要再混着来聊了

不少人到现在还在把这三个词混着用。

一句话：Prompt管的是要说什么内容，Skills管的是具体要怎么做，MCP管的是可以去到哪些方向或者范围，Agent管的是具体由谁来执行这项工作。

Skills 其实并不是 Prompt 的替代品。Prompt 还会在很长一段时间里持续存在，只是它并不太适合用来承载那些比较复杂、需要反复执行以及相对稳定的流程。

MCP 其实也算不上是 Skills 的竞品。MCP 所要处理的，其实是 AI 能不能够访问你的数据库、文件系统以及第三方 API 这类问题。而 Skills 要解决的，则是当访问到这些资源之后，它应该按照什么样的规矩来开展工作的问题。这二者其实是互补的关系，并不是相互排斥的。

Anthropic 的工程博客其实已经说得很清楚了，Skills 和 MCP 这两者之间，其实是属于互相补充的关系。

七、四个演示场景

下面这几个场景是我设计的演示，并非真实的公司案例，但它们所反映的是真实存在的痛点。

场景一：要是需求还没有彻底想明白的话，就不要让AI直接动手去写代码。

要是打算做一个“用户邀请返利”功能，直接让AI来写的话，普通AI很快就能产出一堆代码。不过像邀请关系能不能设置成多级？退款之后返利该怎么计算？自己邀请自己的情况该如何处理？老用户补绑邀请人的问题该怎么解决？还有风控方面要怎么去处理？这些内容AI全都没有提及。

在使用 grill-with-docs 之后，Agent 并不会直接去编写代码。它会先进行追问，比如邀请关系是单级还是多级，返利是固定金额还是比例，退款场景要怎么处理，以及边界条件是什么。同时还会把这些决策记录进 CONTEXT.md 当中。

优质的AI工作流，其第一步往往并非直接去编写代码，而是要把相关的问题给询问清楚。

场景二：AI 修复 bug 不要靠猜测。

线上出现了报错的情况：有某个接口会偶发地出现500的问题。普通的AI一般会直接去查看报错的内容，以此来修改代码。它会先修改三个文件，接着运行一次测试，之后就会告诉你“修好了”。你去查看之后会发现，这个bug确实不再报错了，但旁边的一个功能却出现了损坏。

在使用diagnosing-bugs之后，Agent首先会去尝试把问题给复现出来，接着会慢慢缩小排查的范围，之后会列出和这个问题相关的一些假设，再去添加日志或者开展测试来进行验证，最后完成修复的工作，还会补上回归测试的这个环节。

在真实的工程场景之中，最让人头疼的其实并不是bug难以被解决，而是有人一边凭借着自己的猜测，一边就去进行修改操作。

场景三：让AI来写测试，其实并不是让它自己去自导自演。

将测试工作交给AI来给支付模块进行补充。普通的AI或许会把实现和测试放在一起完成，到最后测试可以全部通过，但却没有对关键风险进行测试。所谓的测试，仅仅只是能够证明“自己所编写的代码可以正常运行”。

运用 TDD 之后，Agent 会先编写失败测试，再进行最小实现，最后开展重构工作。要是不按照这样的方式来管理开发流程，那么就很容易写出看起来似乎十分完整，但实际上仅仅只是证明自身代码可以正常运行的测试。

测试的价值不是覆盖率数字，是它有没有测到真正会坏的地方。

场景四：长任务中断后，不要让上下文烂尾。

我们已经和AI进行了足足两百轮的聊天，整个项目的修改工作也推进到了一半的进度，要是再这样继续下去，模型就会开始变得模糊不清。

用handoff之后：Agent 把当前状态压缩成 handoff 文档：哪些做完了，哪些没做，关键决策是什么，坑在哪里。下一轮对话直接读这个文档继续。

长上下文不是无限用的资源。知道什么时候该交接，比硬撑更靠谱。

八、泼几盆冷水

写到这里，我泼几盆冷水哈。

第一，所谓的Skills其实并不能替代工程层面的实际能力。

你不会因为装了一个diagnosing-bugs就突然会修 bug 了。你不会因为装了一个codebase-design就突然会做架构了。Skills 帮你执行流程，但判断流程对不对、输出好不好，还是你的事。

第二，Skill 写得烂，Agent 只会稳定地烂。

一个质量欠佳的Skill，要比完全没有Skill来得更加危险。如果只是没有Skill的话，Agent至少还能够自由地发挥自身的空间。可要是拥有了质量并不合格的Skill，Agent就会稳定地依照错误的流程去执行相关的操作。

第三，安全风险不能忽略。

Skills 是文件夹，里面可以有脚本、命令、文件操作。那些来路不明的 skill 可不要直接拿去运行。你其实并不是在收藏壁纸，而是在给 AI 提供一个可以执行特定动作的工作包。

有意思的是，这次 GitHub weekly trending 里还有一个项目叫NVIDIA/SkillSpector，描述是Security scanner for AI agent skills. Detect vulnerabilities, malicious patterns, and security risks.连 NVIDIA 都在做 Skills 安全扫描了。说明这个问题不是杞人忧天。

第四，工具兼容性不要替读者做承诺。

mattpocock/skills的描述里写了.claude directory。那些来路不明的 skill 可不要直接拿去运行。你其实并不是在收藏壁纸，而是在给 AI 提供一个可以执行特定动作的工作包。

第五，团队没有流程，Skills 救不了。

这可以说是最根本的一条。所谓Skills，其实只能用来固化已经存在的流程，没办法凭空生成出新的流程来。要是你的团队连代码审查的规范都还没有建立起来、连测试策略都没能达成统一的对齐、连需求文档都没有人专门来负责撰写的话，就算装上再多的Skills，其实也发挥不了什么实际的作用。

第六，Skill 不是写完就扔。

你的工作方法在变，项目在变，工具也在跟着升级，那么Skill也得跟着做出相应的调整。你可以把它当成代码的一部分，该进行重构的时候就进行重构。Skills所固化的其实是你当前的工作方法，如果你的方法本身需要进行迭代，记得定期回头去修改Skill，别把它当成一成不变的圣旨。

九、普通人到底该怎么开始？

不要去收藏一百个。每天只做这一个。

找一个你每周重复 3 次以上的任务。怎么判断值不值得做？三个标准：你每周做 3 次以上、步骤基本固定、做错了有后果。符合两个就值得封装。不符合的，临时 Prompt 够了。

像修复程序漏洞的具体流程、整理每周工作进展报告的框架、审核代码时需要关注的检查要点、编写项目说明文档的标准模板，还有在开展需求评审之前需要提前准备好的各项清单。

把你的要求、步骤、输出格式、失败处理写下来。不用写得很复杂。5 个步骤，3 个检查点，1 个输出模板，够了。

然后放进你的 Skills 目录。跑几次。看它有没有真的减少你的返工和废话。

做完这一个，当它运行起来的那一瞬间，你就会懂。

Skills 的价值，不在收藏，在复用。

明天你会开始想做第二个。后天你会想把所有重复的流程全都搬进去。

到那一步，你就不是在"使用 Skills"了。你是在把自己的经验，变成 Agent 能执行的资产。

十、别收藏了，今天就来实实在在做一个。

Prompt 时代，大家所比拼的，其实是谁更能够去提出问题。
在Skills时代当中，大家开始比拼谁更会去整理自己的工作流。
这件事可比单纯收藏Prompt要难上不少，而且它的价值也要更高一些。

其实Prompt说白了就是一句话。Skills呢，则是一整套用来把事情做好的具体方式。
模型的能力确实会变得越来越强，这一点可以说是确定无疑的。不过话说回来，模型越是强大，也就越容易暴露出来另一个值得我们思考的问题：你到底是不是真的清楚自己想要什么，又到底该怎么做才行。模型固然可以帮你写出任何一段代码，但它没办法替你决定，到底什么样的代码是值得去写的。

往后在AI编程这一领域，双方之间所存在的差距，可能不只是停留在模型这个层面上的差距，更有很大概率是在整体的流程层面所存在的差距。

能够把自身所拥有的经验拆解成智能体可以执行的具体步骤的这类主体，也就更容易将人工智能当作一种实用工具来加以使用，而不是把它当成一个话比较多的实习生。
别再忙着收藏了。今天就来实实在在做一个。