企业官网建设流程全解析

最近有个朋友问我，你整天折腾 AI，到底折腾出什么结果了。我跟他说，我前两天干了一件事，一口气装了 30 多个 Skill，然后给我那台天天写代码的 AI 安排了 8 个岗位。他听完直接愣住，问我什么叫给 AI 安排岗位。我说，就是把 Skill 当作岗位说明书和工作手册，让 AI 像一个小团队一样运转，而不是一个只会聊天的机器人。

这篇文章我就把这件事的完整过程写出来，包括我为什么装这么多 Skill、怎么给 AI 设计岗位、每个岗位到底配了什么技能、实际用起来效果如何，以及我在这个过程中踩过的一堆坑。如果你也在用 Claude Code、Codex、Cursor 这类支持 Agent Skills 的工具，这篇文章应该能帮你少走不少弯路。

1. 先搞明白 Skill 到底是个什么东西

1.1 Skill 不是普通提示词，是"带说明书的工具箱"

很多人在网上看到 Skill 这个词，第一反应是：这不就是预设好的提示词吗？还真不是。普通的提示词是你每次跟 AI 对话时临时输入的一段话，说完就没了，下次还得重新说。Skill 是一个结构化的文件夹，里面通常包含一个 SKILL.md 文件，可能还有模板、脚本和参考文档，AI 会根据你当前的任务自动判断要不要调用它。

我习惯用一个类比来解释，提示词是"口传指令"，你每次都得跟新人交代一遍怎么做。Skill 是"书面作业指导书"，里面不仅有步骤说明，还有参考模板、检查清单、甚至可以直接运行的脚本。AI 拿到指导书之后，能自己照着做，不用你每次都从零开始教。

1.2 Skill 的核心优势在于"自动触发"和"附带资源"

Skill 最关键的设计，是它有一个带元数据的描述头。AI 在处理任务时，会先看你当前的需求跟哪些 Skill 的描述匹配，匹配上的技能才会被激活并加载进上下文。这意味着你不用手动指定"请使用某某技能"，AI 自己能判断该用哪个。

就拿 AI 编程工具来说。一个设计良好的 Skill 可以附带一份项目代码规范、一组可复用的 Golang 或 Python 代码片段、甚至一个代码审查脚本。当 AI 接收到写代码的任务时，它不仅能看到指导书，还能直接调用里面的脚本去检查代码质量。这已经超出"聊天助手"的范畴，更接近一个真正有生产能力的 AI Agent。

1.3 为什么所有主流工具都在往 Skill 方向走

你可能注意到，Claude 有 Agent Skills，Codex 出现了 codex skill，Spring AI 也在做类似的东西，各家都在卷这个方向。原因其实很朴素：大模型本身没有长期工作记忆，每次对话都是"重新开始"，你上次教过它的经验、规矩、写法偏好，它基本全忘了。

Skill 就是用来对抗这种"失忆"的。把经验沉淀成文件，放进项目的固定目录，AI 每次开工前都能重新阅读一遍。换句话说，Skill 是在用工程化的方式给 AI 做"经验持久化"。我自己也是把这个思路彻底想明白之后，才决定系统性地折腾这件事，而不是为了炫耀安装数量。

2. 装 30 多个 Skill 之后，我发现自己被淹没了

2.1 30 个 Skill 堆在一起，AI 根本不知道用哪个

我刚开始装 Skill 的时候，想法很简单：哪个看起来有用就装哪个，装得越多 AI 应该越强。结果用了几天发现，根本不是那么回事。30 多个 Skill 全部放在目录里，AI 面对一个任务时，要在这么多技能描述里做匹配，经常出现两种情况：要么匹配到一个驴唇不对马嘴的技能，要么好几个技能都想触发，上下文一下被塞满了。

有一回我让它写一个 JSON 解析的小工具，它居然先把"测试用例生成"和"代码审查"两个 Skill 都加载进来，白白浪费了大量上下文窗口，产出质量反而下降了。那时候我才意识到，我收集的是一堆工具，但这些工具没有组织，更没有分工。

2.2 真正的瓶颈不是数量，是组织方式

Skill 装得再多，如果它们在 AI 眼里是一堆散件，那 AI 就不会知道在什么场景下该选哪个，以及多个技能一起出现时谁先谁后。这就像你把螺丝刀、扳手、电钻全倒在一个抽屉里，用的时候还得一个个翻，效率反而比只有两三件常用工具更低。

后来我换了个角度思考。我在现实里带过项目，团队里每个人的分工是明确的：产品经理负责梳理需求，架构师做技术选型，开发负责实现，测试负责找问题。每个岗位有自己的一套工作方法和产出标准。那我为什么不能把 Skill 也按这个思路，给 AI 安排成一个个岗位的"岗位技能包"？

这样想清楚之后，"装了多少个 Skill"立刻就不再重要了，重要的是每一个 Skill 有没有被放到一个清晰的工作岗位上，它的职责边界是什么，什么时候被触发，产出给谁用。

2.3 岗位化组织给 Skill 带来的三个直接好处

按岗位重新组织 Skill 之后，我明显感受到三个变化。第一个是触发准确性提高了。AI 看到一个需求时，能先判断当前属于"产品阶段"还是"开发阶段"，再决定加载哪个岗位的技能，误触发的情况少了很多。第二个是技能之间有了交接逻辑。前一个岗位的输出，能成为后一个岗位的输入，整个流程顺畅了。第三个是维护成本降低了。我想新增或者修改一个技能时，只需要在对应岗位的目录里操作，不会影响其他职能。

这种组织方式说白了，就是把"AI 个人能力建设"升级成了"AI 团队流程建设"。单点技能再多，也难以形成合力，但只要流程清晰、职责明确，普通的技能组合也能干出很漂亮的工作。

3. 我实际给 AI 安排的 8 个岗位及技能配置

3.1 岗位全景图

下面这张表是我目前实际在用的岗位结构。每个岗位对应了若干个 Skill，负责一个完整工作流里的特定环节。岗位之间通过"交接文档"协作，后一个岗位只认前一个岗位输出的结构化结果。

3.2 产品经理岗：承接模糊需求的第一道关卡

这个岗位是我所有任务的第一站。很多时候我丢给 AI 的需求就是一句话，比如"我想做个工具方便团队内部汇报"，这个描述极其模糊，如果直接让 AI 写代码，最后出来的东西基本不能用。

所以产品经理岗的核心 Skill 是"需求澄清"。它的工作内容是反过来向我提问：这个工具的使用者是谁，汇报的数据从哪来，是按周报还是月报汇总，需不需要权限区分，第一版大概要覆盖哪些核心功能？等需求被追问得足够清楚后，这个岗位才会输出一份结构化的 PRD，带明确的功能列表和验收标准。

以前我总是跳过这个环节，直接让 AI 干活，结果做出来的东西经常返工。现在每个需求先过一遍产品经理岗，后面所有岗位都有了明确依据。如果你做项目时也经常觉得 AI 答非所问，大概率是你跳过了需求澄清这一步，直接进入了实现细节。

3.3 架构师岗：在动手写代码之前先想清楚路线

架构师岗是我加的比较晚但作用很大的一个岗位。它的核心职责，是在产品经理产出 PRD 之后，决定这个需求用什么技术路线来落地。

比如说要做刚才提到的汇报小工具。架构师岗的 Skill 会基于需求分析：这个项目要不要后端，还是纯前端就够了？如果要保存多人数据，localStorage 能不能满足？用户并发量大概多少？如果只是团队内部几十个人用，用一个轻量级方案就行，完全没必要上重型架构。

我自己以前喜欢让 AI 直接"开写"，结果它经常给我写一个过度复杂的系统，明明一个静态页面就能解决的事，它给你引入数据库和微服务。后来架构师岗的 Skill 被我设定了一条基本原则：能用简单方案绝不上复杂方案，同时在方案里写明取舍理由。这个岗位真正解决了"AI 不会选型"的问题，它靠的是 Skill 里固化的判断准则，而不是 AI 随机发挥。

3.4 前端与后端开发岗：把 PRD 翻译成可运行代码

开发和测试岗其实是大多数 AI 编程工具最擅长的领域，但要有好的产出，前提是接受到的输入足够清晰。我的前端岗 Skill 里写明了代码风格要求、组件拆分习惯、以及从 PRD 到界面结构的具体转换步骤。后端岗的技能则聚焦在接口设计、数据模型和异常处理上。

这两个岗位的工作是高度协作的。前端需要的接口字段，必须以后端定义的契约为准。以前它们经常各写各的，前端调用了一个后端根本不存在的方法，调试半天找不到原因。后来我让两个岗位共同读取架构师的接口文档，甚至在 Skill 里明确规定：后端先输出 OpenAPI 规范，前端照着调，这个问题才彻底解决。

给 AI 开发岗用 Skill，最大的价值其实是把你自己偏好的技术栈、代码风格、文件组织方式固化下来。AI 默认写 Java 的代码风格比较笨重，你在 Skill 里告诉它优先用哪几个库、函数命名用什么风格、目录怎么组织，它会一直照做，不会中途跑偏。

3.5 测试岗与 DevOps 岗：为代码质量和发布兜底

测试岗的 Skill 在被开发岗的代码产出触发后，会自动对照 PRD 里的验收标准设计测试用例。它最大的好处是能覆盖开发时容易忽略的边界情况。比如一个日期选择控件，普通需求文档不会提到 2 月 30 日怎么办，但测试岗的 Skill 会把这些极端输入作为必测项列进去，让 AI 在交付前自己先检查一遍。

DevOps 岗负责把所有东西变成可以一键运行和部署的形态。它会在项目末尾生成打包脚本、环境变量说明、以及部署文档。针对不同项目的体量，它会判断是用 Docker 还是直接写一个启动脚本就够了。我是希望 AI 不只给我一堆代码，还要让我能够把代码跑起来，这个岗位解决的就是"最后一公里"的问题。

3.6 数据分析与文档岗：让项目可被理解和可被追溯

数据分析岗不是每个项目都触发，但只要涉及数据统计需求，它就会被启用。它提供了明确的指标口径模板和 SQL 编写规范，避免我自己每次都要解释什么叫"活跃用户"、什么叫"完成率"，直接在 Skill 里定义清楚。文档工程师岗则通常最后出现，负责把所有决策和交付物整理成文档。

一个很实际的现象是，AI 写代码能力很强，但代码入库之后过两周我自己回头看都认不出来。文档岗保证了项目有 README，有接口文档，有部署说明。它把我前面所有岗位的产出串联起来，形成完整的项目档案。对我这种需要同时维护多个项目的人来说，这个价值怎么强调都不过分。

我不建议一上来就照搬这 8 个岗位。因为不同人做不同的项目，岗位序列不完全一样。比如说我故意没有设置 UI 设计师岗，因为我的项目大多以内部工具和数据流为主，设计含量比较低。你应该先观察一下自己平时的开发请求里，哪些环节最容易出问题、最需要模板化，然后按需设置岗位。我的经验是，从 3 到 4 个核心岗位跑起，等流程顺了再加角色，比一步到位要稳得多。

4. Skill 目录结构长什么样，配置文件怎么写的

4.1 一个标准 Skill 的目录解剖

如果你要从零开始做一个 Skill，先理解它的物理结构会很有帮助。我一般把 Skill 放在项目的.claude/skills/或者.codex/skills/目录下，不同工具路径略有差异。每个 Skill 都是一个独立文件夹，例如：

skills/ product-mgr/ SKILL.md templates/ prd-template.md acceptance-criteria.md code-reviewer/ SKILL.md scripts/ check_security.py sql-analyst/ SKILL.md references/ metric-definitions.md

可以看出，每个岗位的技能包里，SKILL. md 是主文件，其他资源文件按需组织。模板文件用于保证输出的格式统一，脚本文件则用来执行具体的自动化操作。

4.2 写好 SKILL.md 的关键是"描述头"和"执行规则"

SKILL.md 最核心的其实是文件开头的 YAML 描述头。这部分决定 AI 什么时候会主动调用这个技能。以产品经理岗的 Skill 为例，我会这样描述：

--- name: demand-clarifier description: 当用户提出模糊需求、需要梳理业务流程、或者希望产出需求文档时使用。特别适合一句话需求、口头描述的场景。不要用于已经非常明确的技术实现任务。 --- # 需求澄清与 PRD 生成 ## 你的角色 你是产品经理，任务是把模糊想法变成可执行的需求说明。 ## 执行步骤 1. 先列出需求中包含的关键角色和使用场景。 2. 自动识别需求描述中的模糊点，并生成问题清单。 3. 基于用户回答，输出 PRD 文档，必须包含功能列表、优先级、验收标准。

这个描述头里的"使用时"和"不要使用"非常关键。很多人写 Skill 只写它能干什么，不写它不能干什么，结果 AI 经常误调用。后来我把每个技能的边界条件写清楚，误触发的概率大幅降低。

4.3 一个有执行清单的 Skill 会比空泛的指导稳定得多

我还发现在 SKILL.md 正文里加入"执行清单"能显著提升稳定性。AI 在长对话里容易遗漏细节，但如果你在 Skill 里明确写"输出前必须检查以下 5 项"，它通常能记住并执行。

比如我的代码审查 Skill，在正文中明确要求：先检查是否有硬编码密钥，再检查异常处理是否完整，然后检查资源是否需要关闭，最后检查命名是否清晰。每一个检查后面都附带一个示例和反例。实测几次后，我发现技能输出的稳定性，比只用"请帮我审查代码"这类提示词强了不是一点半点。

Skill 本质上是一份"操作手册加检查表"。它不会替 AI 思考，但它能保证 AI 的思考是沿着你希望的方向推进的，而且每一步都有章可循。

4.4 从"会回答"到"会执行"：Skill 里塞脚本的真香体验

我以前觉得 Skill 里放模板就够了，直到我发现可以在里面塞可执行脚本，效果完全不同。举个例子，我正在做一个规范的检查 Skill，里面放了一个 Python 脚本，AI 可以调用它来扫描代码文件中是否含有可疑的高风险模式。这么做的话，AI 就不是"根据经验猜测"了，而是真正跑一遍工具再给结论。

Skill 里也可以放参考文档。比如数据分析岗的 Skill 会把所有业务指标的口径定义放在 references 目录里，AI 写 SQL 之前先去查这些口径，就不会再把同一种指标算出不同数字。这样的技能包，从外部来看是一个工作指导书，从运行来看，已经是一个小型的、具备外部辅助能力的智能程序了。

5. 用一次真实任务走一遍 8 个岗位的完整流程

5.1 从"做一个周报统计小工具"到 PRD

为了让你对这套岗位化流程有更直观的感觉，我拿最近一次实际操作举例。我提的需求非常口语化："给团队做一个周报统计小工具，要能按人按周统计工时。"这个需求经产品经理岗的 Skill 处理之后，AI 先反问我：数据需要多人同时录入吗？每个人录完自己的，你只需要汇总，对吗？要不要区分项目维度？统计结果需要导出 Excel 吗？

这些问题回答完后，它产出了一份 PRD，其中明确写了第一版要做三个功能：成员录入每周工时、按周汇总、按项目筛选。验收标准是：录入页能够添加多条记录，汇总页能自动计算人均工时，筛选项目后数字随之更新。这份文档一出来，后面的所有岗位就有了明确的依据。

5.2 架构师定方案，开发和测试并行开工

架构师岗的 Skill 读完 PRD 后给出的技术方案是：完全不需要服务端，用纯前端加 localStorage 就能实现需求。原因是用户量不超过几十人，数据量每周几百条，浏览器本地存储足够，而且部署最简单——直接打开网页就能用。

前端开发岗在工作时，根据架构方案开始搭建页面。此时后端开发岗处于闲置状态，因为它没有收到任何接口契约需求。测试岗没有被跳过，它在前端代码完成后自动生成了一组测试用例。特别针对重复提交、跨周数据隔离、员工姓名特殊字符这些场景设计用例。测试用例可以直接执行，几乎能复现我在手工测试中能遇到的大部分坑。

5.3 DevOps 打包、文档补位，直接交付可用工具

DevOps 岗最后把整个前端工程打包成了一个可分发目录，并生成了一个说明文件，告诉我只要把目录放到静态服务器或者直接双击 index.html 就能用。文档岗生成了一份简短的用户手册，配上截图指引，团队其他人不需要任何培训就能上手。

整个流程走完，我发现自己几乎没有手动写过代码，也没有像以前那样在对话里反复发大段提示词。因为岗位化的 Skill 自己会判断什么时候该做什么。所有环节都有输出、有交接、有验收。更让我意外的是整个交付过程只花了半个多小时。如果让我传统方式开发这个小工具，从写页面到部署可能得花一整个下午，还不包括后来修 Bug 的时间。

6. 30 多个 Skill 是从哪来的，我是怎么筛选的

6.1 白嫖社区资源时，我会注意这三点

我的 30 多个 Skill 有很多不是自己从零写的。GitHub 上有人专门维护了收集 Agent Skills 的仓库，awesome-claude-skills 这类项目里能找到大量现成技能。社区里还有人写了 Skill Creator，专门用来辅助生成新的 Skill，用它自动生成初版结构再自己改，效率挺高。

不过直接拿别人的 Skill 用，有几点你要仔细看。第一是确认它到底是激活什么工具的，不同平台的 Skill 格式不一定通用，Claude 的 Skill 放到 Codex 里经常需要调整描述头。第二是留意会不会有危险操作，很多 Skill 里带着自动化脚本，我之前下载过一个处理 PDF 的 Skill，里面有个脚本会读取用户目录下的所有文件，这种我直接用脚本审查完就删了。第三是别迷信"下载量大"，实用性还是得自己跑一遍才知道。

6.2 自己写 Skill 的两条实战经验

如果你的需求比较个性化，我建议自己动手写几个 Skill，其实并不难。写的过程只要抓住两个要点。第一个是把你平时反复对 AI 交代的话整理成文字，这就是 Skill 的雏形。你每次写代码前都要叮嘱它"先写测试再实现"，那就把这个要求写进开发岗的 Skill 里。第二个是给 Skill 确定合适的粒度，别做太细。我以前给代码审查单独做了四五个细分技能，什么 Python 安全审查、JS 注释检查，后来发现 AI 根本分不清区别，干脆合并成一个统一的代码审查 Skill，情况改善很多。

自研初期，先用"抄"再"改"的方式比较省力。找结构清晰的社区版本，把里面的知识内容换成你自己领域的术语、流程和标准，然后跑一个实际任务看效果，再调整描述头。反复几轮之后，你就有了一批贴合自己工作习惯的技能库了。

6.3 装得快删得也快，最后留下的不到 20 个

装 30 多个 Skill 的过程中，我同时也在不停地删。删掉的标准有三条：是否与其他技能重复、是否有过实际触发记录、是否带来了稳定产出。一个月下来，实际留存的不到 20 个。但留下来的每一个都在对应岗位上真正发挥过作用。

我拿几个还在用的举例。通用的"需求澄清"来自社区，经我大幅改造后变成了产品经理岗的入口。某个针对 Spring Boot 项目的开发规范 Skill 是我自己写的，来自我在真实项目中总结的要点。还有一个代码审查 Skill，配置了最核心的安全扫描脚本和执行清单，不管什么项目都能复用。这给我最大的启示是：Skill 的价值不在于数量多，而在于匹配度高，能跟你的工作流严丝合缝地配合。

7. 高频踩坑记录：Skill 用了不生效怎么办

7.1 Skill 没有自动触发，问题多数出在描述头上

如果你发现 AI 在面对任务时完全没有调用某个 Skill，先别怀疑 AI 蠢，大概率是你技能描述里的触发词不够具体，或者有多个 Skill 描述太像、让 AI 分不清。我的解决办法是用场景化的句子描述触发条件，不只写"用于代码审查"，还要写"当用户提供了完整代码文件或 Pull Request 时使用，重点检查安全问题与异常处理"。改完之后触发概率明显提升。

还有一种情况是描述头里没有写"不要使用"的场景。比如你想让"数据分析" Skill 只在真正有数据统计需求时启用，就别让它连写普通代码的任务也触发。给触发条件加上负面清单，能有效剔除大部分误触发。

7.2 上下文被浪费、技能间互相打架

装了很多 Skill 的副作用是，AI 启动时把所有候选技能都读了一遍，白白吃掉大量 token。我在排查后发现两个解决办法。一是把不必要的参考文件尽量精简，模板和示例放一两个有代表性的就够了；另一个是在每个项目里只放当前需要的岗位目录，而不是把 30 多个 Skill 全放在同一个全局目录里。

Skill 数量一多，冲突的问题也来了。比如我有"Python 开发规范"和"通用代码审查"两个技能，Python 规范说变量命名用小写下划线，通用审查里却多了一行"保持命名统一即可"，AI 就开始左右摇摆。后来我给 Skill 设了优先级原则：具体语言规范优先于通用规范。这个原则直接写进系统指令里，冲突就平息了。

7.3 更新 Skill 后发现 AI 还在用旧逻辑

还有一次我改完了 Skill 里的流程步骤，结果 AI 执行的时候还是按旧方式来做，我一度以为它缓存了旧文件。后来发现真正的原因是我改的是正文内容，但触发器描述没动，AI 在技能选择阶段直接跳过了我对这个技能的理解。所以我调整完 Skill 之后，一般会开个新会话，在对话里丢一个明显的测试任务，先确认触发成功，再观察它是否按照新内容行动。

下面这个表是我整理的几个典型问题及对应解法，建议截图保存：

如果你是从零开始接触 Skill，我建议你上手时保持克制。先选择一两个你重复次数最多的任务来做实验，比如代码审查、需求澄清，写好 Skill 后连续用几次，再迭代调整。不要像我一开始那样追求数量——我装到 30 多个之后发现核心逻辑没有理顺，等于给 AI 塞了一抽屉没人认领的工具。反倒是在我把它们按岗位安排好之后，这 30 多个技能才真正产生了协同效果。装 Skill 从来不是目的，让 AI 像一位靠谱的同事那样，知道自己的工作、边界和交付格式，才是真正值得花时间的事。