企业官网建设流程全解析

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。

前言

你有没有想过，2026年的程序员，上班第一件事不是写代码，而是——给AI们开早会。

真的，我现在每天打开电脑，感觉面前坐了一排AI员工。Cursor说"老板我只看.mdc"，Claude Code说"老板我只认CLAUDE.md"，Codex CLI说"老板我的规则在.codex目录下"，Windsurf说"老板我比较简单就一个文件"，Copilot说"老板我……我什么都看，但看完经常忘"。

这哪是编程工具？这分明是五个部门五个章程，每个部门还互相看不起。

一、当AI队友开始"吵架"

上个月我亲身经历了一件离谱的事。我让Cursor写个函数，它给我整了个TypeScript，驼峰命名，类型注解拉满，看着就高级。转头让Claude Code改同一个文件，它给我改成了PHP风格，下划线命名，还加了一句注释：“// 简单点，说话的方式简单点”。

我当时就懵了。我说你们俩能不能统一一下？Cursor回我："我的规则文件里写的是TS规范。"Claude回我：“我的CLAUDE.md里写的是团队2019年的老规范。”

好家伙，AI没学会编程，先学会了搞小团体。

更绝的是，那天我改了一条代码规范，忘了同步给Windsurf。结果Windsurf写的代码像是从平行宇宙来的——变量名全用拼音缩写，注释写的是"此处有坑，深不可测"。我怀疑它是不是偷偷看了我大学时期的代码。

💡 灵魂拷问
你的项目里如果有5个AI工具，每个工具读到的上下文不同，后果是什么？答案是：代码风格比联合国开会还多元。

二、Skills不是"小提示词"，是你的技术房产证

半年前大家还在争论"什么是Skill"。今天答案很清晰了：Skill就是你给AI的工作说明书，而且是带法律效应的那种。

你可以这么理解：以前你请了个程序员，给他口头交代需求，他听懂了算运气，听不懂算常态。现在你请了个AI，给它一本《项目生存手册》，告诉它"我们团队用Vue3、Tab缩进、组件名大驼峰、API错误要统一返回{code,msg,data}"。

这本手册，就是Skill。

但问题是——每个AI工具都有自己的"阅读癖好"。

Cursor说："我要.mdc格式，还要带Frontmatter，还要按globs匹配文件类型。"Claude Code说："我就看CLAUDE.md，简单直接，但我要全局注入。"Codex说："我要专属目录，规则放rules，代理放agents，分门别类。"Windsurf说：“我就一个文件，.windsurfrules，多了我脑容量不够。”

这感觉像什么？像你去五个国家旅游，每个国家的插头标准都不一样。你带了一个万能转换头，结果发现万能转换头本身也需要转换头。

📊 各AI工具的"挑食"清单
Cursor → .cursor/rules/*.mdc（按文件类型挑食）
Claude Code → CLAUDE.md + .claude/（全局灌输型）
Codex CLI → .codex/rules/ + .codex/agents/（分仓管理型）
Copilot → .github/copilot‑instructions.md（GitHub原生型）
Windsurf → .windsurfrules（极简主义型）

三、碎片化Skills = 代码界的"巴别塔"

你知道《圣经》里的巴别塔吗？人类想建一座通天塔，上帝一看"这还得了"，于是让人类说不同的语言，结果大家互相听不懂，塔就塌了。

现在的AI编程工具就是现代版巴别塔。每个工具说不同的"配置语言"，同一个项目，Cursor理解的架构和Claude理解的架构，可能完全是两栋楼。

而且还有一个隐形杀手叫**“上下文轰炸”。有些同学觉得"规则越多越好"，把几十条规范一股脑丢给AI。结果AI在庞杂的上下文里迷失了重点，写出来的代码像是喝醉了——变量名一会儿驼峰一会儿下划线，注释一会儿中文一会儿英文，感觉像联合国代码大会现场直播**。

所以记住：给AI塞规则，就像给女朋友讲理——不是越多越好，而是要说到点子上。

四、解决方案：把Skills当代码来"管"

既然Skills是技术资产，那就该走软件工程的治理流程。别把它当随手写的便签条，要把它当需要Code Review的正式文件。

4.1 单一真相源：建一个"中央厨房"

在项目里建一个_skills/目录（或者.ai‑skills/），这是唯一的规则仓库。Git仓库里只保留这个目录，其他工具的配置目录全部由脚本生成，并且加入.gitignore。

什么意思？就像中央厨房给各分店配送食材，_skills/是中央厨房，各AI工具是分店。分店可以有自己的摆盘方式，但食材必须统一。

📦 your‑project/ ┣ 📂 _skills/ ┃ ┣ 📜 coding‑standards.md # 编码规范 ┃ ┣ 📜 architecture.md # 架构约定 ┃ ┣ 📜 api‑design.md # API 设计原则 ┃ ┗ 📜 git‑workflow.md # Git 提交规范 ┣ 📂 .cursor/rules/ # 脚本自动生成 ┣ 📂 .codex/ # 脚本自动生成 ┗ 📜 CLAUDE.md # 脚本自动生成

4.2 按需分发：别给AI喂"满汉全席"

给每个Skill文件加上Frontmatter，标明它适用于什么场景：

--- description: Vue 3 组件开发规范 globs: "**/*.vue,**/components/**/*.ts" tags: [frontend, vue] --- # 组件命名规范 ‑ 文件名使用大驼峰（如 UserProfile.vue） ‑ 组件名必须多单词，避免与HTML标签冲突

Cursor看到这个globs，就知道"哦，这是Vue组件的规范，我只在写.vue文件时加载它"。Claude Code看到索引，就知道"哦，这是前端规范，我在写后端代码时不用管它"。

这就对了。AI不是垃圾桶，别什么规则都往里倒。

4.3 自动化脚本：让机器去"当传话筒"

写个Node.js脚本scripts/sync‑skills.js，做三件事：读取Skills目录、解析Frontmatter、按工具分发。

核心逻辑就几行：

files.forEach(file=>{const{frontmatter,body}=parseFrontmatter(file);// Cursor：按 globs 生成 .mdcwriteFile(`.cursor/rules/${name}.mdc`,`---\ndescription:${desc}\nglobs:${globs}\n---\n${body}`);// Claude Code：生成索引目录agentIndex+=`- **${desc}**: 参阅 skills/${name}.md\n`;});writeFile('CLAUDE.md',agentIndex);

这脚本一跑，各AI工具的配置文件自动更新。你改一次Skills，所有AI同步接收。从此告别"我忘了同步给Windsurf"这种低级失误。

当然，如果你连脚本都懒得写，那……那你还是继续手动复制粘贴吧，反正浪费的时间也是你自己的，AI又不会心疼你。

4.4 Skills也要走"生命周期"

既然Skills是代码，那它就得有代码的待遇：

• Code Review：每条Skill的变更加PR，经Tech Lead审核。别觉得"就改个提示词而已"，一条错误的Skill能让AI写出灾难级代码。
• 版本化管理：Skills也要打Tag、写Changelog。回滚到v1.2时发现"原来我们以前不用下划线命名"，这种感觉就像翻出十年前的QQ空间。
• 定期淘汰：每个季度清理一次过时规则。React 16的防坑指南在React 19时代可能是误导，就像你2026年还在教AI怎么用jQuery。
• 可测试：给Skill写单元测试，验证它的输出效果。比如测试"组件命名规范"这条Skill，看看AI生成的组件名是否真的符合大驼峰。

🎯 核心思想
AI工具只是载体，真正的资产在_skills/里。脚本是分发层，任何新工具加入生态，只需要在脚本里加一行——就像给新员工发工牌，格式统一，流程规范。

五、企业级玩法：MCP + 角色模型

上面说的都是单人/小团队场景。到了企业级，就得升级装备。

5.1 MCP Prompts：Skills的"云同步"

MCP的Prompts能力正在成为Skills的标准化层。简单说，就是把Skills放在远程服务器上，AI工具通过MCP协议动态拉取。

这意味着什么？意味着你不用再在每个项目里复制粘贴Skills文件了。团队Skills集中管理在MCP Server上，每个开发者只配置一个MCP连接，Skill的增删改查由后端完成，前端零配置。

就像公司统一发了云办公软件，你不用自己装Office了，打开浏览器就能用。这才是企业级该有的样子。

5.2 多Agent + 角色模型：让专业的人做专业的事

企业级场景下，Skills不只是编码规范，还涉及代码审计、架构评审、部署规则等。这些不该由同一个Agent承担，就像你不会让财务去写前端代码。

更好的模式是多Agent + 角色模型：

🎭 AI团队编制表
👨‍💼 架构师Agent → 负责系统设计评审，持有architecture.md
🔒 安全Agent → 负责代码安全审查，持有security‑rules.md
🧪 测试Agent → 负责测试覆盖率和边界检查，持有testing‑guide.md
💻 开发Agent → 负责日常编码，持有coding‑standards.md

每个Agent持有自己的Skills集，互不干扰。架构师不会乱改你的代码风格，安全员不会瞎指挥你的架构设计。这才是真正的"AI小队"——有编制、有分工、有纪律。

Antigravity和Codex Agents正在做的，就是把Skills从一条提示词，升级为一套角色化的工作流引擎。以后你的AI团队，可能比你的真实团队还专业。

六、Skills正在变成"可交易的产品"

最有意思的变化不在技术层面，而在商业层面。

Skill不再是开发者的个人笔记，它正在变成一种可分发、可交易的产品。就像以前你写了个jQuery插件放到GitHub上，现在你可以写个"瑞幸点单Skill"放到市场上卖。

想象一下：你告诉AI"帮我点杯生椰拿铁"，AI通过Skill调用瑞幸的API，自动选择你常喝的规格、甜度、温度，甚至还能用优惠券。这背后就是一个精心设计的Skill在运作。

GitHub上Skills仓库的Star数正在追赶传统开源项目。2026年，不会写Skill的程序员，可能就像2016年不会写jQuery插件的前端一样——不是不能活，但活得不够精彩。

💰 商业趋势
Skills正在从"配置项"变成"插件市场"。一个生态一旦形成，它的演化速度会远超想象。也许明年，你能在某个AI应用商店里看到"爆款Skill排行榜"。

写在最后：三条铁律

Skills工程化听起来很重，但核心原则只有三条，记住就行：

**第一，别把Skills当提示词，当代码。**治理流程走软件工程标准，该Review的Review，该测试的测试。别因为它是"给AI看的"就降低标准——AI会把你写的烂规则，执行得淋漓尽致。

**第二，单一真相源。**自己建一个_skills/目录，童叟无欺。其他工具的配置全部由脚本生成，杜绝"这个改了那个没改"的悲剧。

**第三，按需分发。**别给AI塞一堆它不需要的上下文。就像你去餐厅点菜，不会把菜单上所有菜都点一遍——AI也一样，吃撑了会吐。

2025年我们学会了"提示词工程"，2026年我们要学会的是**“Skills工程”**。从一个人写提示词，到一支团队治理AI工作说明书——这跨度，就是过去一年AI编程工具演化的缩影。

最后送大家一句话：未来属于那些会管理AI团队的人，而不是只会对AI说"帮我写个函数"的人。

毕竟，能带团队的人，才能当老板。对吧？

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。