企业官网建设流程全解析

第一次用AI Agent写代码的朋友，大概率都经历过这种场面：需求发过去，等了好几分钟，它跑出一个看起来自认为完美、实际上装都装不起来的项目。你让它改，它道歉，再跑，又跑出另一个错误。三五个来回之后，你开始怀疑是不是自己表达能力有问题，或者这模型天生就爱“翻车”。我的看法是：大部分时候都不是你的问题，也不是模型笨，而是你少给Agent配了一套Skills。Skills这个概念最近在AI圈里讨论度极高，Claude Code、Codex、Cursor、OpenCode这些主流工具全都在支持。今天我不讲空话，直接从我自己踩过的坑出发，聊聊Skills到底是什么、怎么装、怎么写，以及怎么用它把一个“动不动翻车”的Agent调教成稳定输出的得力搭档。

1. 先聊AI Agent最常见的“翻车现场”

1.1 新手最容易遇到的三种翻车

第一种：同一个需求，每次跑出来的结果都不一样。上午让它写一个用户登录页，它用了表单校验；下午再问一次，它改成接口直连，连基本的防重复提交都没了。这种“薛定谔的输出”让很多人觉得AI根本不可控，实际上是因为每次对话都在重新“自由发挥”。

第二种：让它调用工具，它自己编造函数名。比如明明项目里只有getUserInfo，它能一本正经地调fetchUserData，然后告诉你“接口报错了”。这种问题不是模型知识不够，而是它没经过工具验证，纯靠训练数据里的“相似记忆”在猜。

第三种：输出格式不稳定。写JSON的时候少个括号，生成代码的时候漏掉import，让它给Markdown表格，它偏偏给你塞进代码块里。这些格式问题单独看都是小事，但在自动化流程里就是致命的，脚本一旦解析失败，整条流水线直接崩。

1.2 翻车的根因：短期记忆差，加上每次都在“临时发挥”

Agent的工作链路是一个“思考—行动—观察—再思考”的循环。每一步它都要依赖上下文窗口里的信息做判断，而上下文窗口是有限的。当对话越来越长、项目文件越来越多，早期交代过的规则就会被“挤”出有效注意力范围。这时候它不是故意犯错，而是真的忘了你之前说过什么。

更关键的是，大模型本身带有随机性。同一个prompt，你在不同时间问，它会给出概率分布里不同的结果。这就好比把一个新来的实习生丢进项目里，不给他任何文档，全靠他自己临场猜。他心情好的时候能蒙对几次，心情不好、信息又乱的时候，交出来的东西就千奇百怪。

所以我才觉得，让Agent稳定发挥的关键不是换个更贵的模型，而是给它配“岗位说明书”：让它一接手任务就知道标准流程、操作规范、避坑要点。这套“岗位说明书”，就是Skills。

2. Skills到底是什么：从“一次性指令”到“可复用技能包”

2.1 一个Skills包长什么样

Skills说白了，就是把一组完成特定任务的指令、示例、代码规范、工作流程，提前写进一个结构化的文件夹里，让Agent在遇到对应任务时自动加载并遵循。目前社区最通用的格式，是在一个目录里放一个SKILL.md文件，文件头部用YAML写元信息，正文用Markdown写具体操作流程。

一个最小的Skills长这样：

my-first-skill/ └── SKILL.md

打开SKILL.md，内容大概是：

--- name: frontend-component-review description: 用于审查React/Vue组件代码，确保符合团队规范。当用户提交前端组件代码、要求代码审查或验收组件质量时使用。 --- # 前端组件代码审查流程 1. 先检查组件是否使用了项目中统一封装的按钮、输入框等基础组件。 2. 再检查样式是否引用了Tailwind配置里的设计令牌，禁止写死颜色值。 3. 如果发现图片资源，必须提示使用CDN地址，不允许本地静态资源。 4. 输出审查结果时，必须标注问题所在文件、行号和修改建议。

这里最关键的部分就是开头的description。Agent不是每时每刻都把技能库里的所有内容加载进上下文，而是根据description判断“当前这个任务跟哪个技能匹配”。描述写得越精准，触发成功率越高。

2.2 Skills、MCP、Prompt之间到底是什么关系

很多人刚接触时容易把这几个概念搞混，我做一个简单区分：

用一个生活化的类比：Prompt是“你今天帮我把这份文件翻译一下”，MCP是“给你开一个能查词典、能访问数据库的权限”，Skills则是“以后凡是翻译任务，按这个格式输出，专业术语先查词典，译文必须保留原文格式”。

三者的关系不是替代，而是互补。MCP解决“能连接什么”，Skills解决“怎么做才好”，Prompt解决“这次具体做什么”。真正稳定的Agent，往往三个都用上。

2.3 为什么Skills能“救场”

Skills最大的价值在于把“隐性经验”变成“显性文件”。你在项目里积累的代码规范、踩坑记录、客户偏好、历史最佳实践，过去分散在文档和聊天记录里，模型每次只能碰运气式地“看到”一部分。现在你把它们固化成一个技能包，每当相关任务出现，Agent就会自动把这一整段经验载入上下文，相当于给模型做了一次“考前划重点”。

我自己试过之后最明显的感觉是：过去让Agent写一个组件，我需要反复强调“用Tailwind”“按钮用Ant Design的”“风格参照现有页面”，写完还要Review三遍。现在技能包里写清楚一次，它每次执行都会遵守。这些规则不是靠模型“记住”，而是靠技能文件“每次喂进去”，所以不会随着对话变长而失效。

3. 从0到1搭建自己的第一个Skills（实操）

3.1 第一步：挑一个值得写成技能的任务

不是所有任务都适合做成Skills。选任务的标准有三个：高频、重复、结果可以标准化。

高频意味着你经常遇到，值得投入时间沉淀；重复意味着每次操作流程大同小异；结果可以标准化意味着你能把“好”和“不好”的边界写清楚。符合这三个条件的例子很多：写周报、生成前端组件、做代码审查、整理会议纪要、跑数据清洗流程、做数学建模的基线实验。

我的建议是，新手不要一上来就做一个月度计划表，先从“下一次马上能用到”的小技能开始。比如你每天都要写日报，那就写一个日报生成Skills，让它按“今日进展—阻塞问题—明日计划”的结构输出，顺便把敏感项目标成只写摘要。

3.2 第二步：动手写你的第一个SKILL.md

拿“写产品周报”举例，新建一个目录，比如weekly-report/SKILL.md，然后往里面写：

--- name: weekly-report description: 根据提供的本周工作记录生成面向团队的产品周报。当用户提到“写周报”“本周总结”“weekly report”时使用。 --- # 周报生成指南 ## 输入要求 - 用户可能提供聊天记录、工作日志、已提交的commit、关掉的issue列表。 - 如果没有提供足够信息，先询问项目的目标、本周重点、下周计划。 ## 输出要求 1. 周报标题格式：【周报】产品组W<第几周>周报 2. 按“本周核心目标与完成情况”“风险与阻塞”“下周关键计划”“需要跨团队协调的事项”四段式输出。 3. 每条内容限制在50字以内，尽量量化：不写“优化了性能”，写“首屏加载从3.2s降到1.8s”。 4. 最后用一行总结本周整体进度，颜色标记：正常/预警/延期。

写完保存，这个Skills就算初步成型了。注意description里我特意写了中英文触发词，这是为了让Agent在不同表达方式下都能识别出来。你还可以在目录里放额外的参考文件，比如template.md存放周报模板，examples/放几个历史优秀周报作为示例。Agent加载技能时，正文里没有提到的细节，可以去参考这些附加文件。

3.3 第三步：测试、迭代、正式使用

写完之后，最重要的环节是测试。把Skills放进Agent的全局或项目技能目录，新开会话，用各种不同的说法去触发它。比方说你直接说“帮我写这周周报”，看它是否主动加载；再说一次“我把这几条工作内容整理成周报”，看它是否也能反应过来。

如果触发失败，先别急着怀疑模型。多数情况下是description写得太窄，或者和任务之间缺少关键关联词。把用户可能用的说法都列一遍，然后扩展描述。

还要注意一个细节：修改SKILL.md之后，一定要新开一个会话再测试。大多数Agent工具是在会话启动时扫描技能目录，修改文件不会热更新到当前会话，不重开会话的话，你会觉得“明明改了啊，怎么还是老样子”。这个坑我踩过不止一次，现在凡是动过技能文件，我都会强制自己重开对话验证。

4. 主流Agent工具里的Skills安装与配置

4.1 Claude Code：手动安装GitHub上的Skills

Claude Code是目前对Skills支持最完善的工具之一。它支持全局技能目录和项目技能目录：全局目录通常是~/.claude/skills/，项目目录是.claude/skills/。全局目录里的技能对所有项目生效，项目目录里的技能只对当前仓库生效。如果你的某个技能包含公司敏感信息或团队特有规范，一定要放项目目录，别手滑放进全局。

手动安装GitHub上的Skills的步骤很简单：

1. 在GitHub上找到目标技能仓库，一般长成skills或者awesome-skills这样的名字。
2. 把仓库clone到本地技能目录，或者下载ZIP解压进去：

git clone https://github.com/<owner>/<repo>.git ~/.claude/skills/<skill-name>

3. 如果只需要其中一个子目录技能，就只把对应的文件夹拷进去。
4. 重启Claude Code，让它在启动时重新扫描技能目录。
5. 新开会话，直接说“你有哪些可用技能”或者在任务里用自然语言描述，看能否触发。

我在实际使用中有一个小技巧：如果电脑上同时装了CodeBuddy和Claude Code，而你想让它们共用一套技能库，可以把技能放到一个公共目录，然后在各自的配置目录里做软链接。这样做的好处是，团队规范只需要维护一份，不用在两个工具里各复制一遍，更新时也不会出现两边版本不一致的问题。

4.2 Codex：让Skills接管命令行Agent

OpenAI的Codex同样可以玩Skills。它的原理和Claude Code类似，都是在一个特定目录里放置技能文件，例如常见的~/.codex/skills/或项目里的.codex/skills/。社区里已经有不少现成的聚合包，比如superpowers、codex-nature-skills，这些包往往把一个完整的工作流拆成多个子技能，装好之后就能在命令行里指挥Agent跑起一套复杂流程。

这里我想多说一句：很多人用Codex跑数学建模类任务，比如“华为杯”这种竞赛场景，常需要做数据清洗、特征工程、基线模型、结果可视化。这类任务非常适合装一套数学建模Skills，把从原始数据到最终图表的完整管线固定下来，Agent每次拿到赛题后就能按标准流程推进，而不是从头拍脑袋。

安装方式同样很简单：把GitHub上的仓库clone到对应技能目录，重启Codex，然后直接在需求里提到“用你的数模技能处理这份数据”。如果你看到Agent主动读取了技能文件，说明安装成功。

4.3 Cursor和OpenCode：编辑器里的Agent同样需要技能包

Cursor的Agent模式现在非常常用，它同样支持Skills。我通常会在项目根目录下建立.cursor/skills/<skill-name>/SKILL.md，把“项目代码规范”“前后端联调契约”“测试用例编写标准”这些内容做成技能包。这样当我用Cursor的Agent写代码时，它会自动了解项目约定，而不是凭训练数据里的通用习惯乱写。

OpenCode的配置逻辑也类似，它支持在项目的.opencode/skill/目录下放置技能文件。如果你经常用OpenCode做AI辅助编程，可以花点时间把团队规范和常用代码模式沉淀成技能，尤其是前端开发场景，页面结构、组件命名、样式方案这些规则写清楚后，Agent产出的代码质量会明显上台阶。

不管是Cursor还是OpenCode，都要注意设置里是否开启了“读取技能目录”的开关。有些工具默认只读项目根目录的配置，没开启的话，技能包放了也没用。

4.4 企业级场景：Spring AI和Jenkins中也能借鉴Skills思路

Skill这个概念不只是在个人开发工具里好用，在企业级AI Agent平台上同样值得借鉴。我自己接触过几个用Spring AI + Spring Cloud搭Agent中台的团队，他们面临的最大问题不是模型能力，而是“每个业务方都在各自为战地写prompt”，导致同一个业务问题在不同团队里有完全不同的处理方式。

这时候可以借鉴Skills的思维方式，把企业内的高频业务任务固化成标准技能包：比如“客户工单分类”“合同关键条款提取”“内部知识库问答”“审批流摘要生成”。每个技能包包含任务描述、输入输出格式、必须调用的服务接口、合规检查项。在Spring AI的框架里，这些技能包可以表现为一组规则模板+决策配置，Agent每次处理业务时先加载对应模板，再结合大模型的判断力。

在Jenkins这类CI系统里集成AI Agent时，同样可以把“提交信息规范”“代码静态检查规则”“单元测试覆盖标准”做成技能集，让Agent在流水线里的行为有章可循。说白了，企业级应用远比个人开发更需要Skills，因为团队协作的核心就是“统一标准”，而Skills正是把标准从人脑搬到代码里的好办法。

5. 值得收藏的Skills来源与推荐清单

5.1 开源仓库里有哪些好东西

如果你不想从零开始写，最省力的方式是去GitHub上抄现成的。Anthropic官方维护的anthropics/skills仓库里就放了不少官方示例，涉及文档处理、代码分析、信息提取等场景，适合用来理解技能包的标准写法。

社区里知名度很高的obra/superpowers也是一个宝藏仓库，它把一套完整的项目管理、代码审查、任务拆解流程做成了多个Skills的集合，装上之后Agent就像是接受过系统训练一样。还有一个方向是各种“awesome”聚合库，里面整理了某一类场景下的技能清单，前端开发、数据科学、写作助手都有覆盖。你在GitHub搜索关键词skills加上你的领域名，基本能找到一堆现成的。

5.2 垂直场景应该装哪些技能

前端开发场景：装“组件规范”“UI还原流程”“Tailwind样式配置”相关的技能包。这些技能能让Agent写出来的代码风格与项目现有代码一致，而不是每次都“另起炉灶”。

数学建模场景：装“数据探索”“特征工程”“模型基线”“论文图表生成”类技能包。比赛时间紧张时，Agent按固定管线跑通流程，能帮你省出大量调参时间。

AI漫剧场景：漫剧创作经常涉及角色一致性、分镜脚本、画面风格控制、配音节奏，这些环节特别适合做成技能包。把“角色设定表”“分镜模板”“画风关键词库”固化下来，Agent生成的内容就会稳定很多。

Java企业开发场景：在Spring AI或Spring Cloud的Agent平台里，把业务FAQ、API调用规范、数据权限规则、代码提交规范做成技能包，能有效降低多个Agent协作时的混乱程度。

5.3 国内Agent产品里的“Skills影子”

如果你还不想折腾命令行和文件目录，也可以先在成熟的国内Agent平台上理解这个思路。现在主流的智能体平台，比如文心智能体、字节的豆包、月之暗面的Kimi生态、阿里的通义，它们普遍提供“工作流”“知识库”“插件”“技能市场”这些能力。

这些东西本质上就是Skills的平民化版本：工作流把任务步骤固定，知识库把经验资料喂给模型，技能市场则是别人封装好的技能包，你点一下就能用。我的建议是，如果你是完全的新手，先去这些平台把“搭一个工作流”的流程玩一遍，理解清楚“什么时候让模型自由发挥、什么时候固定规则”；等你理解了这套理念，再到Claude Code或Codex里用文件方式管理技能，会顺手很多。两种路径殊途同归，都是在做同一件事：把Agent的行为从“随机发挥”变成“有章可循”。

6. 一场典型翻车的排查复盘：从“反复返工”到“技能包一次过”

6.1 现场还原：一个前端落地页的三小时拉锯战

有一次我需要Claude Code帮我写一个产品落地页，技术栈是TailwindCSS加一个内部组件库。我给了它一个很简单的需求：“做一个包含导航、Hero区、功能特性、轮播图、定价表和CTA的营销页面，风格参考官网。”

它第一次跑出来的页面，导航能看，Hero区能看，但功能特性区域的卡片全部宽度不一致，轮播图直接变成三张静态图片堆叠。我让它改，它说“好的，已修复”，重新跑一遍，卡片宽度正常了，但页面的主题色全变了，按钮从直角变成了圆角，跟我当初给的参考完全不是一回事。

三四个来回之后，我已经不想再看它跑出来的东西了。当时脑子里只有一个想法：这模型怎么回事？明明需求说得很清楚，为什么越改越乱？

6.2 完整排查链路：问题到底出在哪一步

我后来冷静下来，用了排查链路把问题拆开看。

第一步，我打开Claude Code的调试信息，把Agent每一步的Thought、Action、Observation完整展开。结果发现它每次行动之前，确实“思考”了，但思考的依据不是项目里的实际文件，而是它自己记忆中“类似落地页应该长什么样”。

第二步，我发现它反复在做同一件事：设计按钮样式。第一轮它没用组件库，而是自己定义了按钮类；我让它改，它把Tailwind的默认样式和组件库样式混着用，导致颜色和圆角对不上。这一步暴露了一个真相：没有人告诉过它“这个项目的按钮组件是已经封装好的，应该直接引用，而不是每次重新发明”。

第三步，轮播图的问题更典型。它把轮播图做成静态图，是因为它在项目里压根没找到可用的轮播组件。它没有去翻阅依赖包里的组件列表，也没有去看项目的入口文件，而是选择“简化处理”。

第四步，我翻看整个对话的上下文窗口，发现模型确实在前几轮被反复“教育”，但到了后面，规则已经挤出了有效注意力范围。它并不是态度不好，是真的没“记住”我最初提的参考风格。

排查到这里，结论已经清楚了：问题不在模型，在于整个执行过程中缺少一个“稳定加载”的规范文件。我每一次的修改反馈都是临时的，用完即丢，模型下次又要重新猜。

6.3 技能包入场：把项目规范变成强制加载项

我先在项目根目录建了.claude/skills/frontend-policy/SKILL.md，把这个项目从零开始执行就必须遵守的规则写进去：

--- name: frontend-policy description: 项目级前端开发规范。所有涉及页面开发、组件修改、样式调整的任务都必须加载本技能。 --- # 前端开发强制规范 1. 按钮、输入框、卡片等基础组件必须直接引用项目封装的UI组件，禁止在页面内重写样式。 2. 颜色一律使用Tailwind配置中的设计令牌，不允许出现硬编码的十六进制颜色值。 3. 页面中的轮播图、弹窗、表格必须优先使用依赖包内已有组件。 4. 页面整体间距参考官网现有页面的间距体系，比例为4的倍数。 5. 完成开发后，必须检查页面在移动端宽度下的显示效果，并给出去掉横向滚动条的处理方案。

然后我重新开启了一个会话，只给了一句话：“用frontend-policy技能，按官网风格做这个落地页。”

这一次它没有“重新发明”任何东西：按钮用了组件库，颜色来自设计令牌，轮播图从依赖包里找到了现成组件，页面间距和官网保持了一致。最重要的是，整个开发过程我只沟通了一轮，它交出来的页面基本能直接进入微调阶段。

6.4 前后效果对比：差距并不是一点半点

这次经历给我的触动很大。过去我总觉得“让AI干活”的重点是“提示词写得细”，但这次之后我明白了，一次性的“提示词写得细”远不如“让正确技能自动加载”靠谱。临时交代会随上下文滚动被遗忘，技能文件则每次任务开始时都能稳稳地注入上下文。

7. 新手避坑清单与我的调教心得

7.1 五个最容易踩的坑

7.2 新手该怎么安排学习顺序

先别急着写自己的技能。第一步是“抄”，去GitHub找几个口碑好的技能包，装进工具里用两周，感受一下一个“正确”的技能长什么样；第二步是“改”，把别人的技能改成适合你自己项目的规则；第三步是“写”，从你最熟练、最频繁的小任务开始，独立写第一个SKILL.md；第四步是“沉淀”，每隔一段时间把你踩过的新坑补进对应技能文件里，让技能包跟着项目一起迭代。

要注意的是，技能数量不是越多越好。我见过有人一口气装了四五十个技能，结果Agent每次启动都要扫描一遍目录，响应变慢，而且因为技能之间相互重叠，触发经常混乱。我个人的经验是，一个项目里保持10到20个高质量的技能包，已经能覆盖绝大多数日常需求。与其贪多，不如把几个核心技能打磨到“扔给任何人用都不会出错”的程度。

7.3 一点个人体会

我搭自己的Skills库到现在差不多有快一年的时间，最大的体会是：AI Agent其实不太怕“能力不行”，反而很怕“没规矩”。你给它的规则越明确，它发挥得越稳定；你让它全靠临场理解，它就把随机性全还给你。Skills这个东西，本质上是把你脑子里的“项目常识”外化成文件，让模型每次开工前先读一遍。它不是魔法，但它是把AI的“超能力”真正落到项目里的基础设施。

所以，别在“换哪个模型更好用”这件事上无限纠结。花一个下午，把你那个最容易翻车的任务整理成一份SKILL.md，装上，重开会话，再跑一次。你会回来感谢那个愿意动手写技能包的自己。