企业官网建设流程全解析

说实话，当我在配置目录里数到第33个Skill的时候，我自己也有点懵。前两周给主力AI装技能、分岗位的这段实践，让原本只会“你问我答”的助手，硬生生变成了一个有人事结构的小团队。30多个Skill，8个岗位，听起来很唬人，但真正折腾下来，我发现“装得多”不代表“用得好”，真正的难点在于怎么给这些技能安排合适的岗位，并让它们各司其职。这篇文章我就把完整的选型思路、安装配置过程、岗位划分逻辑，以及翻过车的问题都写清楚，给你一套可以直接照抄的框架。

1. 为什么给AI“安排岗位”，而不是只堆插件

1.1 先把Skill的定义说清楚

很多人第一次听到Skill，以为就是一段“更长的提示词”。我跟团队内部解释的时候，一般会拿“新员工入职”来打比方。一个新员工手里至少要拿到三样东西：岗位说明书、工作手册、常用工具账号。Skill本质上就是这个东西，只是它面向的对象是AI。一个Skill往往打包了角色设定、任务拆解步骤、输入输出格式、示例样本，甚至包括允许AI调用的代码解释器、搜索工具或绘图接口。也就是说，Skill比普通提示词多了“可复用”“可安装”“可被其他Agent调用”三个属性。

我装这30多个Skill的时候，主要来源有三类：一是平台自带的官方技能市场，里面有许多经过审核的高质量技能，可以直接装；二是社区网友分享的技能包，这些技能包的质量参差不齐，但往往很有创意，能覆盖官方没做好的细节；三是自己用Skill Creator这类工具改写的，尤其是针对我手头重复性高的工作，我会把常用的提示词模板变成标准技能，用起来确实顺手很多。

1.2 岗位化设计与散装插件的本质区别

直接塞30个Skill，会出现一个很尴尬的局面：AI不知道什么时候该用哪个，用户也不知道该找谁。我一开始就是散装安装，结果问AI“帮我写个活动方案”，它一会儿调用文案技能，一会儿调用翻译技能，最后连格式都歪了。后来我把技能按照“岗位”进行重组，比如内容岗位、数据岗位、编程岗位。每一步操作前，先由调度员判断这条需求应该派给哪个岗位，再由该岗位下的若干Skill协作完成。

岗位化设计的核心价值在于，把“技能数量”转化为“职责边界”。这就好像一个公司不是靠员工数量多就能运转的，还得有部门、有汇报关系、有接口人。AI Agent也一样，30个Skill如果只是平铺在那儿，它们之间的关系是混乱的。一旦按岗位划分，每个岗位对外只有一个入口，对内可以自由调度多个Skill，整个系统的复杂度就大大降低了。

2. 30多个Skill从哪里来，怎么选

2.1 技能选型：宁可少而精，不要多而杂

30多个Skill听起来很多，但真正好用的，其实也就三分之一。我选技能的时候会按三个标准过滤：输入输出边界是否清晰，维护更新是否活跃，跟已有岗位是否重复。曾经下载过一个功能看着很全的“万能写作Skill”，结果它既管标题，又管正文，又管排版，反而把输出搞得很混乱。最后我把它拆成了三个小技能，分别给文案岗和设计岗用，效果才恢复正常。

所以这里想先给个建议：如果你刚开始接触Skill，不要急着追求数量。先把你最常做的三件事做成“岗位”，每个岗位配一两个核心技能，跑通之后再慢慢扩展。30多个Skill是一个目标，不是起点。

2.2 我的8个岗位和支撑技能清单

下面是我实际在用的岗位清单，覆盖了我工作中高频的需求。你可以作为参考，再根据自己的业务调整。

这8个岗位并不是平均分配技能数量。内容策划和文案写作这两个岗位技能最多，因为它们在日常工作中被调用的频率最高；编程开发岗位需要的技能其实只有几个，但个个都要够专业。整体上30多个Skill围绕这8个岗位，基本覆盖了从“想点子”到“出成品”、从“纯文本”到“可执行代码”的完整链路。

每个Skill启动时，我会在描述里写清楚“这个技能归属哪个岗位、什么时候触发、不做什么”。比如归属“翻译校对”的术语统一Skill，触发条件是用户原文包含专业名词或品牌词，限制条件是不主动改写句式结构。这样岗位之间打架的概率就小了很多。

3. 实战：从安装到排岗的完整流程

3.1 先给每个岗位写一份“岗位说明书”

岗位说明书是我觉得整个流程里最重要的一步。它不需要很长，但必须包含四块：职责边界、常用技能、禁止事项、交付格式。以数据分析助理为例，我写的岗位说明书大概是这样的：只负责处理用户明确提供的表格或数据，不编造数据；如果数据量太大需要抽样，必须向用户说明抽样规则；最终交付格式是“异常点列表+趋势描述+可操作建议”。这段说明看起来像废话，但AI在不同技能之间切换时，就是靠这些边界条件约束自己的。

禁止事项尤其值得多写。很多冲突都是因为角色越权导致的。比如客服应答岗位，我明确禁止它给出医疗、法律等专业建议，也禁止过度承诺优惠；文案写作岗位则禁止擅自翻译用户原文。有了这些边界，AI就不会八个岗位同时抢一个活儿。

3.2 安装与配置的5个关键步骤

我每次引入一个新技能，都会走一遍固定流程，保证后续维护成本最低。

1. 建独立目录并规范命名。目录名格式建议是“岗位-技能名-版本号”，比如programming-codex-v1。这样以后搜索和管理会省很多力气。
2. 填写技能描述和触发条件。触发条件不是随便写的，要尽量用用户可能说的原话举例。例如“当用户说『帮我写个方案』时，激活内容策划岗位，优先使用选题脑暴和内容框架两个技能”。
3. 配置角色设定与上下文示例。这一步决定输出质量，示例不要给太多，3到5条典型的就足够；示例太多会让AI过度模仿个别案例。
4. 设定输出模板。是输出纯文本、Markdown，还是JSON，都要明确。尤其是编程岗位和数据分析岗位，我一般要求先用Markdown结构输出，再在代码块里给可执行代码。
5. 冒烟测试。每个新技能安装后，用一条最简单的指令测试它是否被正确触发。如果触发失败，先检查技能描述里的关键词和用户原话是否匹配。

3.3 调度员：给8个岗位排班的总控逻辑

技能多了以后，最怕的不是单个技能不行，而是需求不知道找谁。我的做法是在最外层放一个“调度员”设定，它不负责具体干活，只负责接单和分单。用户提出需求后，调度员先判断属于哪个岗位，是否满足触发条件，然后激活对应的Skill或Skill组合。

我用的调度口诀是“接单-分单-回单-验收”。接单就是先复述用户需求，确认自己没有理解偏；分单是判断由哪个岗位处理；回单是让对应岗位给出结果，并附上涉及了哪些技能；验收是让调度员做最后的格式检查和遗漏提醒。例如用户发来一段英文合同和一个Excel表，调度员会同时派单给翻译校对岗和数据分析岗，但会在输出时分开标注“翻译结果”和“数据摘要”，避免两个岗位的结果混在一起。就是这么简单的规则，让30多个Skill在同一个系统里不再互相踩脚。

4. 核心细节与“为什么这么做”

4.1 技能包里的触发机制，为什么必须设计得够“窄”

很多人喜欢把一个技能写成“全能型选手”，什么都管。但根据我的经验，触发条件越宽泛，AI越容易在错误场景下调用它。比如“通用写作技能”里的示例大多是小红书文案，用户让它写代码注释时它也会套用那些语气，输出就变得很怪。把触发条件改窄以后，它只在特定指令出现时激活，对无关请求一律忽略，反而让整体效果更稳定。

你可以把触发条件理解成马路上的路标：路标太模糊，司机不知道该往哪走；路标指向性明确，导航效率就高。我在技能描述里会故意用“仅当”“如果用户提到”“否则不做任何处理”这类词来控制激活边界。实测下来，上下文长度也能减少不少，因为不需要把30多个技能的完整说明全部塞进每次对话里，省下来的token可以留给真正的输出内容。

4.2 多技能冲突的根因与解法

两个Skill互相打架，是最常见的事故现场。根因通常不是它们都想表现自己，而是它们各自的指令在你的全局设定中互相覆盖。比如“文案润色”技能要求“补充更多细节和修辞”，而“代码Review”技能要求“保留代码原样，不新增逻辑”，当AI面对一段需要同时润色和Review的文本时，就会左右为难。

我的解法有三个层次。第一，给每个技能加上“任务优先级”字段，冲突时先执行高优先级技能的命令；第二，在岗位说明书里写明“本岗位不处理什么”，用负面清单把边界焊死；第三，遇到两个技能确实必须协作的场景，就在调度员层面规定好输出顺序，先由A技能处理，再把结果交给B技能，而不是同时让两个技能生效。这套思路实践下来，效果非常明显，AI输出的稳定性提升了一大截。

4.3 提示词参数设置的经验值

除了技能内容本身，AI的输出参数也会影响岗位表现。不同岗位适合的参数差别很大。我整理了一份自己的经验值，不一定适合所有模型，但可以作为起点：

温度这个参数，通俗讲就是AI“放飞自我”的程度。越高越有创意，但也越容易跑偏。编程、数据、翻译这类追求准确的岗位，温度调低；文案、策划、设计这类追求输出惊喜的岗位，温度调高。很多人的Skill装了不少但效果差，问题往往就出在参数没按岗位差异化配置。

5. 踩坑实录：30多个Skill实际遇到的问题

5.1 高频问题速查表

下面这张表是我这两周故障排查的精华总结。遇到问题先别急着删技能，按表里的思路做一次诊断，通常都能救回来。

5.2 用“固定测试集”给每个岗位打分

想要知道改动一个技能是变好了还是变坏了，靠感觉是不行的。我给每个岗位准备了一个固定测试集，每个岗位5条问题，内容覆盖典型场景和边界场景。每调整完技能，就跑一遍测试集，记录成功率、输出格式正确率、是否出现越权行为。这个做法虽然麻烦，但非常值得。没有测试集的时候，我经常出现“这次感觉还好，过两天又不行了”的情况。有了评分记录，任何一个改动是正收益还是负收益，一目了然。

例如数据分析岗位的测试集里有一条固定问题是：“请检查这份Excel表里有没有异常值，并说明判断依据。”我会把Excel临时替换成同一结构的测试文件，确保对比结果只受系统设置影响，而不受数据内容影响。这个思路借鉴了软件工程里的回归测试，放在Skill维护上同样管用。

5.3 技能版本管理，千万别犯懒

一个人维护30多个技能，最大的敌人不是AI，而是自己。你可能今天觉得某个提示词写得不够好，顺手改了一下，但没存旧版本。结果过了两天新方案效果不好，想退回旧版本却找不到。这个问题我已经遇到不止一次。现在我会在每个技能目录下保留一个versions文件夹，每次修改都按v1.0、v1.1的规则存一份快照。如果技能目录本身在Git仓库里管理，那就更方便了，每次改动提交一次，还能看到历史记录。

这里分享一个很小但很实用的习惯：改技能之前，先在技能描述里加一行“本次改动说明”，把改动原因和时间写清楚。AI虽然不会直接读出这行字，但你之后排查的时候，能省掉大量回忆时间。

6. 从30多个Skill到可复用的能力矩阵

6.1 什么时候该删掉一个技能

装技能让人上瘾，删技能才是真正考验。我给自己定了一个标准：如果一个技能在两周内没有被自然触发过，或者它的功能和另一个技能重叠度超过一半，就需要考虑下架。别担心删掉以后又需要，只要版本管理做得好，随时可以恢复。我在这次实践里，实际删掉了6个技能，都是看起来花哨但使用频率极低，或者职责明确重叠的。删完以后，AI整体反应速度反而更快了，输出也更稳定。

Skill数量从来不是目标，能力闭环才是。所谓闭环，就是你的用户在某个岗位场景提出需求，AI能够完整地完成“理解-拆解-执行-交付-检查”这五个阶段，而不是只扔给你一段看起来不错但没法直接用的文字。

6.2 把一个普通提示词改造成Skill的四个步骤

如果你想自己动手写一个技能，不用一上来就用复杂的开发框架。主力AI或者社区工具里提供的Skill Creator，通常足够用了。我会把改造过程拆成四个步骤：拆触发条件、立角色人设、写步骤清单、定输出模板。触发条件就是“用户说什么话时使用这个技能”；角色人设决定语气和专业深度；步骤清单给AI一个明确的工作顺序，防止跳步；输出模板保证结果长成你想要的样子。

比如我想把一个“周报生成提示词”改造成正式技能：触发条件写“当用户说写周报/汇总本周进展”；角色人设写“你是一名擅长结构化汇报的职场助手”；步骤清单写“先收集本周任务，再按成果/问题/计划三块整理，最后提炼一个数据亮点”；输出模板用Markdown标题和表格呈现。这样一个Skill的骨架就出来了，其他内容都可以在骨架基础上慢慢填充。

6.3 这次实践最有价值的三个认知

第一，AI的真正生产力不在于单个模型有多强，而在于你如何组织它的使用方式。同样一个模型，散装使用和按岗位体系化使用，产出质量差别巨大。第二，技能之间是会发生“化学反应”的，好的调度能让1+1大于2，坏的管理会让系统整体退化。第三，维护成本不可忽视，30多个Skill不是装完就算完，需要持续做测试、版本管理、淘汰冗余，这本身就是一项需要认真对待的长期工程。

最后还是分享一个小技巧：我在所有岗位说明书的末尾都加了一句话——“如果信息不足，必须向用户提问，不要猜测。”这句话看起来不起眼，却帮我避免了至少80%的返工。很多AI输出看起来专业但细节失真，就是因为它在信息不充分时强行“脑补”。定了这条规矩后，整个8岗位系统的可靠性上了一个台阶。如果你也想给AI安排岗位，我建议从3个岗位开始，先跑通流程，再慢慢把技能扩到30个。