企业官网建设流程全解析

1. 当Skill变成员工的“职业技能证书”

最近半年，我一直在折腾一个方向：把AI从“一个能聊天的模型”改造成“一个能干活的下属”。标题里的“装了30多个Skill，给AI安排了8个岗位”，就是这次折腾的阶段性成果。

所谓Skill，你可以理解为给AI额外安装的“职业技能包”。就像给员工发一本岗位说明书加一套工具清单：你告诉AI“你现在的角色是代码审查官，你需要先把diff拉出来，再按这5个维度逐条检查，发现问题要给出修改建议，而不是只丢一句‘看起来不错’”。装完Skill之后，AI在对应场景里的输出质量，跟我裸用默认模型完全是两个水平。

为什么非要这样干？原因很简单：默认的AI是“通才”，什么都懂一点，但不会主动按你的规范去执行。你让它审查代码，它可能只扫一眼语法；你让它写专利交底书，它可能给你编出一堆不符合格式要求的“技术方案”。而Skill做的事情，就是把“行业规范+团队SOP+个人偏好”固化成模型能直接调用的指令资产。装30多个Skill，本质上是在给AI构建一套“岗位能力矩阵”。

这篇文章就围绕这套实践来写，重点拆解三件事：一是8个岗位到底怎么划分、每个岗位挂载了哪些Skill；二是Skill安装、配置、管理的完整实操过程；三是调试过程中踩过的坑怎么排查。适合正在玩Claude Code、Codex、Cursor等AI编程工具，想把AI从“玩具”变成“生产力工具”的同学参考。

2. 从“会聊天”到“有岗位编制”，思路转变是关键

2.1 一门手艺一个Skill：AI能力的颗粒度游戏

刚开始玩Skill的时候，我犯过一个挺典型的错误：想搞一个“万能Skill”，把所有需求都塞进去。结果就是这个Skill的指令文件超过500行，模型加载之后反而变得迟钝，遇到具体任务不知道该调哪条规则。

后来我换了个思路：按“手艺”拆分，不按“岗位”合并。做饭的归做饭，摆盘的归摆盘，切菜的归切菜。每个Skill只负责一件非常具体的事，描述写得精准，触发条件写得清晰，剩下的交给模型自己去组合调用。

举个例子，同样是在“代码审查”这个岗位上，我装了三个Skill，各管一段：

• diff-review：只分析git diff，检查改动本身有没有引入bug、风格是否统一。
• security-scan：专注安全漏洞，比如SQL注入、越权、敏感信息硬编码。
• architecture-check：站在全局视角看这次改动是否破坏了原有架构边界。

这三个Skill分开装，工作时可以按需调用，也可以组合起来一起跑。效果就是：AI审查同一段代码，能从三个完全不同的角度输出意见，覆盖面比单人审查还全。

2.2 30多个Skill怎么管理：没有目录结构一定会翻车

装了30多个Skill之后，第一个现实问题就是：找不到、分不清、改不动。

我的解决方案是建立明确的目录分类，绝对不能把所有Skill平铺在一个文件夹里。目前我的Skill仓库长这样：

skills/ ├── 01-code/ # 编程开发类 ├── 02-docs/ # 文档撰写类 ├── 03-review/ # 审查评审类 ├── 04-data/ # 数据分析类 ├── 05-patent/ # 专利与知识产权 ├── 06-test/ # 测试与质量保障 ├── 07-devops/ # 运维与部署 └── 08-creative/ # 创意与内容生成

分类的逻辑跟公司组织架构对齐——“8个岗位”就是8个一级分类。每个分类下面挂3到5个Skill，对应岗位的具体技能。这样无论是手动管理还是写脚本批量检查，都非常方便。

2.3 Skill和Agent的区别：一个像“技能”，一个像“人”

这个话题在网上讨论得很多，我说说我自己的理解。Skill是“能力包”，它定义了AI能做什么、按什么流程做；Agent是“执行体”，它决定AI什么时候调用什么能力、任务进行中如何决策。

打个比方：Agent是员工，Skill是员工手里的工具箱。员工决定“这个任务需要扳手还是螺丝刀”，然后从工具箱里取用。如果只有Agent没有Skill，员工就只能赤手空拳上阵；如果只有Skill没有Agent，工具摆了一地但没人知道该用哪个。

在实际落地中，我通常用Agent来定义一个岗位角色（比如“后端开发专家”），然后在Agent的配置里挂载对应的一组Skill（比如python-dev、api-design、performance-tune）。这样分工清晰，职责明确，也方便做权限控制。

3. 8个岗位的岗位说明书：Skill组合实战拆解

3.1 岗位一：代码审查官（Code Reviewer）

这套岗位是ROI最高的。以前我带团队做Code Review，最耗时的就是逐行过diff，现在这部分基本交给了AI预审。

挂载Skill：

这套组合跑下来，AI会先输出一份带风险等级标注的审查清单，标注每个问题的文件位置、行号、问题类型、修改建议。最明显的改善就是团队里那种“低级错误合并进主干”的情况基本绝迹了，因为AI审查的重点恰恰是“语法没问题但逻辑有坑”的隐性错误。

3.2 岗位二：技术方案架构师（Solution Architect）

这个岗位解决的是“拿到需求不知道从哪下手”的问题。挂载的Skill偏向分析和方案设计：

• requirement-analyzer：把模糊的需求描述拆解成功能点、边界条件、非功能需求。
• tech-selector：根据技术栈、团队规模、维护成本给出选型建议。
• api-designer：设计RESTful API的路径、参数、响应结构，直接输出OpenAPI规范。

我常用的工作流是这样：接一个需求之后，先让requirement-analyzer跑一遍，产出一页纸的需求分析；再让tech-selector给出技术选型的对比表；最后让api-designer生成接口草案。这三步跑完，需求评审会的底稿基本就有了，开发团队拿到就能开工。

3.3 岗位三：自动化测试工程师（QA Engineer）

这个岗位帮我补了不少测试覆盖率上的空白。挂载的Skill有：

• test-case-generator：根据代码函数自动生成边界值测试用例。
• selenium-writer：生成端到端测试脚本，输出可直接运行的Python代码。
• coverage-analyzer：分析测试覆盖报告，定位未被覆盖的关键路径。

实际操作中，test-case-generator跑一遍，能覆盖我自己写用例时经常会漏掉的空指针、越界、参数为空等场景。测试用例生成完之后，我只需要做两件事：去重、调节期望结果。省的时间非常可观。

3.4 岗位四：专利与知识产权专员（IP Specialist）

这个岗位比较小众，但价值极高。我在科技企业做过专利挖掘，最大的痛点就是发明人描述技术方案时要么太抽象要么太细节，永远不符合专利代理人的撰写格式。

我自定义了一个patent-draftSkill，内置了一套专利交底书的标准框架：技术领域、背景技术、发明内容、技术方案、有益效果、具体实施方式。同时用Few-shot把两个历史专利作为参考案例写进Skill里。这样AI在生成交底书时，格式和描述口径高度统一，代理人拿过去能直接改，不用推翻重写。

另配一个patent-searchSkill，辅助做前案检索分析，列出潜在对比文件的关键特征，帮发明人初步判断新颖性。

3.5 岗位五：文档工程师（Technical Writer）

程序员讨厌写文档，但文档又是刚需。这个岗位的Skill组合如下：

• readme-generator：扫描项目代码，生成结构清晰的README。
• api-doc-formatter：根据代码注释或OpenAPI文件生成接口文档。
• changelog-writer：对比git commit记录，自动生成版本更新日志。

changelog-writer是最省心的一个：每次发版前跑一条命令，AI把commit message归类整理成“新增/修复/优化/破坏性变更”的结构化日志。以前这个活要花半个多小时手敲，现在20秒搞定。

3.6 岗位六：数据分析师（Data Analyst）

分析类的Skill，重点在于“把脏数据整理成清晰结论”。我挂了这几个：

• >--- name: sql-writer description: 根据自然语言需求生成SQL查询，要求附带解释和边界条件提示。 version: 1.2.0 author: your-name tags: [sql, database, analysis] --- # SQL Writer ## 功能 将用户的自然语言问题转换为可执行的SQL查询，并输出执行计划说明。 ## 使用时机 - 用户希望通过数据分析回答业务问题时 - 用户需要快速获取某个数据指标时 ## 执行步骤 1. 明确用户的业务问题和数据口径（时间范围、指标定义、维度拆分）。 2. 查看数据库Schema，确认涉及的表和字段。 3. 生成SQL，注意： - 使用JOIN时明确关联键 - 涉及聚合时按业务口径正确使用GROUP BY - 时间字段先明确时区 4. 输出格式： - SQL代码块 - 执行逻辑说明 - 潜在坑位提示（如NULL值处理） ## 禁止事项 - 禁止在未确认Schema的情况下直接生成SQL - 禁止将生产库表直接暴露在输出中

  重点说一下YAML front-matter里的description字段，这个字段非常关键——模型靠它来判断“当前这个Skill该不该触发”。如果description写得太泛，比如“处理各种问题”，那模型在几乎所有任务里都会尝试加载这个Skill，既费token又容易干扰主任务；如果写得太窄，则容易漏触发。我吃过的亏是description写得太长，模型无法快速抓取要点，后来统一格式改成“做什么+什么时候用”，匹配率提升非常明显。

  4.3 在Claude Code中安装并运行Skill：真实命令全流程

  以用户级目录的安装为例，完整流程如下：

  # 1. 创建用户级Skill目录 mkdir -p ~/.claude/skills # 2. 将Skill文件复制到目录中 cp -r /path/to/downloaded/sql-writer ~/.claude/skills/ # 3. 检查目录结构是否正确 tree ~/.claude/skills/sql-writer # 确认存在 SKILL.md 文件 # 4. 在当前项目中测试Skill是否被加载 cd /your/project claude # 然后在对话中输入： # /skill list

  如果在对话中执行/skill list能看到sql-writer，说明加载成功。接下来可以直接提一个需求测试效果，比如“统计上周每天的新增用户数，按渠道拆分”，看输出的SQL是否符合预期。

  4.4 在Codex中配置Skill：同样是用目录扫描机制

  Codex这边的配置逻辑类似，但目录名是skills，位置略有差异：

  # Codex全局Skill目录 mkdir -p ~/.codex/skills # 复制Skill cp -r sql-writer ~/.codex/skills/ # 在项目里启用 cd /your/project codex # 在对话中可以直接描述任务，模型会根据description自动加载对应Skill

  提示：如果你同时在用Claude Code和Codex，建议维护一份Skill源仓库，然后通过符号链接（symlink）或者拷贝脚本同步到两个工具的目录里，避免两边手动维护造成版本不一致。

  5. 开发自定义Skill：把“知其所以然”变成AI的肌肉记忆

  5.1 提炼SOP，而不是堆砌规则

  写自定义Skill，最核心的不是会YAML语法，而是能把日常工作流程“结构化”。我开发patent-draft这个Skill的过程值得展开讲讲。

  第一步，我找了一份已经授权的高质量专利交底书，逐段拆解它的结构，标注出每个段落的意图和常见写法。第二步，把公司研发团队描述技术方案的常见混乱点列出来，比如“把背景技术写成产品宣传”“把发明点堆在具体实施方式里”。第三步，把这两部分整理成“结构模板+正误对比+补充提示”，写入SKILL.md。

  这样AI拿到一份研发人员自述，能自动按专利交底书框架重新组织语言，把“这个技术通过一个模块实现”改写成“一种xxx方法，其特征在于包括：步骤一……步骤二……”。写出来的初稿基本达到了能交给代理人改稿的级别。

  5.2 用Few-shot让Skill“一次就懂”

  Skill里的reference目录就是用来放Few-shot样例的。我给大多数Skill都配了1到3个参考案例，每个案例包括“输入-输出”对照。

  以changelog-writer为例，我在reference里放了三种commit风格的输入，以及对应的changelog条目写法。这样模型生成的日志风格稳定，不会出现“修复了一个问题”这种模糊表达，而是“修复订单模块在并发场景下重复创建记录的竞态条件”。

  5.3 版本控制与变更记录：Skill也是代码

  严重建议给每个Skill加version字段，并且用git管理整个Skill仓库。我踩过的一个坑：有一次给security-scan更新了检测规则，结果发现某些正常代码被误报为“潜在注入风险”，捉了半天才发现是规则写得太激进。后来回滚版本就恢复正常。有了git历史，每次改完Skill都能做对比测试，确认没引入回归再发布。

  6. 常见问题速查表与排查心法

  6.1 典型问题一览：没生效、乱触发、上下文爆掉

  问题现象	可能原因	解决方法
  Skill装了但没反应	目录路径不对，或SKILL.md缺失	用/skill list检查加载状态，确认文件在正确目录
  模型不按Skill流程执行	description写得太泛或太窄	重写description，明确触发场景和预期输出
  多个Skill同时被触发	description重叠严重	重新界定各Skill的边界，用否定句式排除
  生成内容质量不如预期	缺少Few-shot参考样例	在reference目录添加1到3个高质量示例
  上下文窗口不够用	每个Skill都被加载，token开销大	精简SKILL.md，把详细内容移到reference按需读取
  生产环境执行了错误操作	Skill缺少安全护栏	在配置文件里加“禁止事项”列表，并增加二次确认流程

  6.2 排查Skill不生效的三个步骤

  步骤一：确认Skill真的被加载。

  用命令/skill list或者查看对话启动日志，看有没有“Loaded skill: xxx”的记录。如果没加载，九成是目录放错或者文件名不对。

  步骤二：确认模型读取到了SKILL.md。

  把Skill里的description原样复制到对话里问“你觉得这个描述适合触发吗”，看模型是否理解正确。如果模型答非所问，大概率是front-matter格式有误，重点检查YAML缩进和冒号。

  步骤三：确认执行路径有没有被用户指令覆盖。

  有时候用户直接给了一个非常具体的指令，优先级高于Skill的默认流程。这种情况下Skill里的规则会被“绕过”。解决办法是在Skill里写明“即使收到其他指令，也务必保留以下环节”。

  6.3 上下文爆炸问题：Skill是耗token大户

  Skill加载本身就要消耗至少几百个token，如果每个任务都把所有Skill加载一遍，上下文很快就会被撑爆。我的经验是：

  • 按岗位启用：同一个会话只加载一个岗位的Skill集合，不要跨岗位混用。比如“今天只做代码审查”，就只带代码审查相关的Skill。
  • 善用reference目录：SKILL.md只保留指令概要，长文档放reference里，模型按需读取。
  • 定期清理：每次会话结束时看一眼加载了哪些Skill，如果某个Skill从来没有真正被用到，就检查它的description是不是形同虚设。

  7. 一套可以“直接抄作业”的Skill管理清单

  折腾了几个月之后，我把这套流程沉淀成了一份清单，分享出来供大家参考。

  7.1 安装新Skill前的检查清单

  1. 这个Skill解决的是不是一个“重复出现3次以上”的问题？
  2. 它的边界是否与已有Skill重叠？
  3. description是否按“做什么+何时用”格式写清楚？
  4. reference目录是否放了至少1个高质量样例？
  5. 是否加上了version和author元信息？
  6. 放在项目级还是用户级目录？

  7.2 引入团队协作时的注意事项

  如果要把这套玩法推广给团队，有几个坑一定要提前避：

  • 人员培训成本：不是所有人都习惯“用指令跟AI协作”，先挑两三个对AI工具熟悉的同事做试点。
  • Skill的版权与保密：如果Skill里内置了公司内部的最佳实践，切记不要直接推到公开仓库，自建私有仓库管理。
  • 质量回退机制：每个Skill发布之前，用一套固定的测试用例做回归，防止“升级反而变笨”。

  7.3 Skill后续还能怎么扩展

  目前我在尝试的方向是：把团队历史代码评审记录清洗成数据集，微调一个针对性的审查偏好注入到Skill里。另外也在研究如何让Skill自动调用外部API，比如通过scripts/目录里的Python脚本拉取监控数据，再基于数据生成分析报告——这一步能做通的话，“AI员工”就能从“靠脑子干活”升级成“手脚并用”干活了。