企业官网建设流程全解析

前段时间好几个朋友问我同一个问题：大家都在说“skills”，它到底是个什么东西？一开始我以为这就是把常用的prompt模板化、封装成可复用的小工具，真上手折腾之后发现，事情远不止这么简单。Skills背后是一套让AI从“聊天机器”变成“干活专家”的机制，它重新组织了模型调用的方式、知识注入的方式、甚至工作流的执行方式。这篇文章我打算把自己从零接触、踩坑、再到搭建出自己一套Skills的完整经验记录下来，聊聊它解决什么问题、核心怎么设计、实际怎么落地，希望能给正在用AI辅助编程、或者想认真提升AI工作流效率的同行一些参考。

1. 先想明白：Skills到底解决了什么问题

1.1 一个让人崩溃的Prompt现场

先说我记忆里非常典型的一次失败经历。当时我想让AI帮我审一份外包开发的采购合同，我把合同PDF转成文字丢进对话框，然后写了一大段提示词：“请帮我审查这份合同，重点关注交付标准、付款条件、违约责任，要有法律依据，输出中文报告。”听起来没什么问题，对不对？

结果AI给我输出的东西，怎么看怎么像通用鸡汤。它把“注意验收标准”“付款节点要清晰”“违约条款尽量完整”这些正确但毫无用处的废话翻来覆去地讲，真正针对合同条文的具体风险点一个没提，更没有告诉我哪一条应该在签约前找对方确认修改。问题出在哪？出在它确实拥有“合同审查”这个常识，但根本不知道我所在的这类业务里，什么样的条款属于高危雷区，什么样的付款方式必须坚决拒绝，什么叫做一份真的有参考价值的审查报告。它缺的不是能力，是专家经验。

后来我把公司内部沉淀的几十条审查清单、过去项目踩过的坑、供应商常用的谈判话术都整理成一个文档，在每次提问时贴进去再让AI分析，效果立竿见影。但新的问题又来了：那段资料越来越多，从几十行变成几百行，每次对话都要重新粘贴，而且粘贴的位置、顺序稍不一样，AI输出的稳定度就会波动。这就是Skills出现的核心背景：把散落在对话里的知识、规则和流程，固化成可以被反复调用的独立技能单元。

1.2 传统Prompt的两大软肋

顺着前面的故事往下看，传统Prompt模式有两个很难绕开的软肋。

第一个是知识无法持久化。Prompt本质上是一次性的“口述指令”，所有背景知识、行业经验、输出要求都必须在对话开始时临时塞进上下文。今天你粘贴进去的资料，明天换一个会话就归零了。长此以往，每个人都在反复做同一件事——把自己已经整理过的专业内容再粘贴一遍，效率极低。第二个软肋是输出的稳定性完全靠运气。同一个任务，上午问和下午问，措辞稍微改一下，AI给出的答案结构可能就差很远，更不要说多人协作时，每个人写Prompt的口味不一样，产出的内容格式五花八门，后续修改成本直线上升。

Skills在这个背景下出现，解决的就是这两件事：一是让知识沉淀下来、触手可及，二是把“怎么做一件事”的完整套路固定成标准流程，让AI每次调用都能稳定输出接近专家水准的结果。用一句简单的话概括：Prompt是“这次帮我做这件事”，Skills是“以后每次遇到这类事，都按这套专业流程来做”。

1.3 Skills的实质：把专家经验打包成可执行单元

那Skills到底长什么样？以现在主流AI编程助手和Agent框架的做法来看，一个Skills通常是一个独立目录，里面包含技能说明文档、参考资料、脚本和模板等文件。这个目录被放在约定好的位置，当用户在对话中明确要求“使用某某技能做某件事”时，AI会自动读取目录里的技能描述，加载对应知识和执行流程，然后按照预设步骤完成任务。

我把它理解为：Skills就是给AI安装了一个“专业岗位说明书”。岗位说明书里写清楚了这个岗位的职责边界、工作步骤、检查标准和验收规范。AI读完说明书后，做起事来就不再是自由发挥，而是有章法地按规程走。这种从“prompt自由发挥”到“skill规范作业”的转变，本质上就是把人的专家经验结构化成机器可执行的程序，这是它和普通提示词最根本的区别。

2. Skills的核心设计思路与构成要素

2.1 一个好技能应该包含哪四层内容

搞清楚Skills解决了什么，我们再来看它内部是怎么组织的。目前相对成熟的Skills结构，基本可以拆成四层：触发规则、场景知识、执行流程、输出规范。触发规则解决的是“什么时候该用这个技能”；场景知识解决的是“做这件事需要知道哪些专业背景”；执行流程解决的是“按什么顺序一步步做”；输出规范解决的是“最后交出来的东西长什么样”。这四层缺了任何一层，技能都会显得不太对劲。

先说触发规则。触发规则是AI判断“该不该调用这个技能”的依据，也是很多人容易忽视的一层。在Skill的说明文件里，你要明确写清楚这个技能适用于什么场景、不适用于什么场景，甚至给出典型输入示例。否则就会出现你希望它用“合同审查”技能的时候，它以为你在闲聊，或者你只是问一句“今天天气不错”，它却莫名其妙把合同审查流程跑了一遍。

2.2 触发规则怎么写才不会翻车

写触发规则有一个关键经验：优先级和边界，比触发词本身更重要。我早期犯过的错误是，把触发词写得特别宽泛，比如“当用户提到合同时，使用合同审查技能”。结果用户说“我这周末有个合同要签，帮我提醒一下”，AI也傻乎乎去调用审查流程了。这就是边界没划清楚的典型问题。

后来我改成“当用户提供合同条文、协议正文或需求描述，明确要求进行风险审查、条款分析、意见输出时，使用本技能；如果只是询问合同相关的泛泛问题，或没有提供具体文本，不要使用本技能”。这样AI遇到模棱两可的输入时，至少知道该往哪个方向收敛。特别注意一点，触发规则里尽量不要堆砌大量同义词，因为大模型对语义的理解已经足够好，真正重要的是让它理解“这个场景的核心目标是什么”。

2.3 场景知识：技能的专业功底所在

场景知识是整个Skills的核心价值。这部分通常放在references目录下，可以是行业术语表、常见隐患清单、过往项目复盘笔记、成功案例分析、法规摘要。要注意的是，这些知识文件不是把网上的资料往下一丢就完事，而是需要做“知识蒸馏”的。

举个例子，如果你要做一个“SQL优化技能”，直接丢进100篇数据库文档是没用的。你要做的是把高频出现的性能瓶颈、常用的索引设计经验、以及“先用EXPLAIN看执行计划再动手”这类实操判断方法提炼出来，整理成简洁、可检索的条目。我在实践中发现，知识文件尽量用表格和短段落来表达，少写废话，因为AI在读取时对条目化内容的敏感度明显更高。真正的专家经验往往藏在那些“非标准”的内容里，比如“当WHERE条件字段存在隐式类型转换时，索引会失效”这种大家容易忽略的细节，把它写进去，技能的价值一下就出来了。

2.4 执行流程与输出规范

执行流程层就是告诉AI“这件事要分几个步骤，每步做到什么程度”。以技术方案评审为例，一个完整的评审流程可能包括：需求还原、架构合理性检查、性能与安全评估、可维护性审查、风险清单输出。每一步都要写清楚检查重点和需要产出的中间结果，避免AI跳步或自己在某一步上过度发挥。

输出规范直接决定了最终成品的可用程度。同样一份方案评审，没有输出规范的AI可能只给你两百字的“看着还行”，而定义了模板之后，它会输出一个包含总评分、分维度得分、问题清单、严重级别、修改建议逐条对应的完整评审报告。所以我建议每个技能都要内置输出模板，甚至可以提供示例报告作为Few-shot参考，让AI照着葫芦画瓢。

3. 从零搭建一个“技术方案评审Skills”的完整实操

3.1 定义场景边界与输入输出

纸上谈兵扯了这么多，来一个真实案例。我最近在公司内部搭了一套“技术方案评审”技能，这里把它完整拆给大家看。第一步是定义场景边界：使用场景是研发同学提交技术方案文档后，由AI按照团队标准进行预评审；不适用场景是需求讨论、代码审查、项目管理等非技术评审类任务。输入是技术方案文本；输出是结构化的评审报告。

定好边界以后，我会在技能目录下新建一个用来说明技能信息的SKILL.md文件，里面写清楚技能名称、适用场景、触发条件以及使用步骤。这一步是AI理解技能的第一入口，一定要写得准确、克制。我简单列一下SKILL.md的骨架供参考：

--- name: tech-design-review description: 对技术方案文档进行结构化预评审，输出包含整体评估、架构合理性、性能与安全风险、可维护性建议的评审报告。 triggers: - 用户提供技术方案文档或详细需求描述，并要求进行方案评审、技术评审、设计评审时。 - 用户询问方案的可行性、潜在风险、架构改进建议时。 not_trigger: - 用户只是讨论需求功能，没有提供具体技术方案文本。 steps: - 1. 提取方案的整体目标、功能范围、技术选型和架构图描述。 - 2. 从功能完整性、扩展性、一致性三个维度评估架构设计。 - 3. 排查性能瓶颈、单点故障、数据安全、权限控制方面的隐患。 - 4. 评估代码结构的可维护性、依赖关系的清晰度、演进成本。 - 5. 汇总风险清单并给出优先级排序。 - 6. 输出最终评审报告。 output_format: | # 技术方案评审报告 ## 整体结论 ## 分维度评分（功能/性能/安全/可维护性） ## 风险清单（按严重级别排序） ## 改进建议（逐条对应） ## 通过条件（是否满足"

这样一个文件，AI读到就会明白：这个技能是干什么用的、什么情况触发、做事的先后顺序、最终要产出什么。但仅有这个文件还不够，还需要把团队内部的检查经验注入进去。

3.2 注入团队知识，让技能“懂行”

我用一到两天的零碎时间把团队过去评审中最常出问题的点整理成了一个references/checklist.md文件。里面全是具体条目，比如：

• 技术选型是否引入团队无人熟悉的新框架；如果引入了，是否有备选方案和回退计划
• 数据库表设计是否考虑数据量在千万级时的查询效率，索引设计是否覆盖高频查询场景
• 缓存使用是否明确Key的过期策略和缓存击穿、雪崩的应对方式
• 接口设计是否做了幂等处理，超时和重试机制是否合理
• 上下游依赖是否有降级预案，依赖故障时主链路能否做熔断隔离
• 日志规范是否支持问题追踪，关键路径是否有traceId贯穿

这些东西在教科书里全有，但每一条都是团队踩坑踩出来的。把它们结构化写进技能里，AI评审时的“经验水平”就直接从应届生跳到了老工程师。

3.3 给技能写脚本：自动生成评分矩阵

除了知识和流程，Skills通常还允许放一些辅助脚本。我写了一个非常简单的Python脚本，用来根据风险数量自动生成评分矩阵，它的作用是把评审报告中的风险点映射为功能、性能、安全、可维护性四个维度的得分，避免AI在打分时凭感觉走。

def compute_scores(risks): # risks: [{"dimension": "performance", "level": "high"}, ...] base = {"function": 90, "performance": 90, "security": 90, "maintainability": 90} penalty = {"high": 20, "medium": 10, "low": 5} for risk in risks: dim = risk["dimension"] level = risk["level"] base[dim] = max(0, base[dim] - penalty.get(level, 5)) return base risks = [ {"dimension": "performance", "level": "high"}, {"dimension": "security", "level": "medium"}, ] print(compute_scores(risks))

脚本的价值在于把“评分”这件本身容易主观的事情，变成了一套可校验的确定性规则。AI在输出风险清单后，可以直接调用这个脚本算分，而不是自己拍脑袋定个85分。分数背后有明确的扣分依据，评审的公正性会好很多。

3.4 实际调用：效果对比

搭完技能之后，我做了一次对照测试。用同一份微服务拆分方案，分别走“直接让AI评审”和“调用技术方案评审技能”两条路径。直接评审时，AI输出的是泛泛而谈的小作文，指出了服务拆分要关注数据一致性、调用链变长会增加延迟，但完全没有提到团队最关心的权限模型设计。而走技能路径时，AI先根据SKILL.md的步骤梳理架构图，再对照checklist逐条排查，给出的报告里明确标记出：“当前方案缺少限流降级策略，流量高峰时核心服务存在雪崩风险”、“交易流水表未设计按月分表，一年后单表数据量预计达到亿级，写入性能将明显恶化”等具体条目。

这就是Skills的威力：它不改变大模型的基本能力，也不给AI加一个“外接大脑”，它做的是把组织里的隐性知识变成一套可以被反复调用的标准动作。知道什么场景该查什么，查到了该怎么定性，最后该输出什么样的结论，每一步都有章法。

3.5 几个决定成败的操作细节

再补充几个实操中容易被忽略的细节。第一，SKILL.md文件里的描述一定要亲测迭代，不要指望一遍写好。我前后改了七八版才让AI在绝大多数场景下做出正确的触发判断。第二，references里的知识文件命名要清晰，最好按用途区分，比如checklist.md、examples.md、glossary.md，这样AI能更快定位。第三，技能目录文件名不要用中文和空格，尽量用短横线连接的英文命名，兼容性更好。第四，建议给技能准备至少一个示例输入和示例输出文件，作为Few-shot参考，AI的表现会更加稳定。

4. 常见问题与排障技巧实录

4.1 技能不触发，问题出在哪

这是新手遇到最多的问题，我一开始也差点被逼疯。技能文件写得好好的，但实际对话时AI完全无视它。逐层排查后发现，绝大多数原因出在描述文件里的“触发条件”写得太窄或太含糊。比如只写“当用户要求评审时触发”，AI理解的是“必须有‘评审’这个动词出现”，但用户实际说得可能是“帮我看下这个方案有没有坑”“这版设计能上线吗”。所以触发描述不能只依赖关键词，应该把用户可能的意图描述完整，最好给出一到两个典型的触发示例句。

还有一种情况是技能文件本身没有被正确加载。不同平台对技能目录的命名和放置位置有严格要求，不是放在任意路径都能被识别。我建议搭建初期先用最简单、最标准的目录结构来测试，确认技能被正常加载后，再逐步增加复杂功能，否则很容易出现“文件改了但没生效”的诡异问题。

4.2 多个技能互相“打架”

当技能多起来以后，冲突就出现了。我同时装了技术方案评审、接口设计审查、数据库设计审查三个技能，它们的场景高度重叠。经常出现用户只是想评一下数据库表设计，AI却把技术方案评审和接口设计审查的流程都串进来跑了一遍，输出的报告结构混乱，完全没法用。

解决这个问题有两种思路。一是给每个技能划分更明确的适用边界，在触发规则里写明“本技能覆盖数据库设计相关内容，技术方案层面的内容交由tech-design-review技能处理”。二是主动在对话中指定技能名称，AI就会以指定的技能为主，不再自己风扇式选择。我的经验是两条腿走路，边界写清楚，调用时也尽量指名道姓。

4.3 知识文件“污染”导致输出漂移

这个坑比较隐蔽。references目录里放了大量知识文件后，AI在读取时会把一些不相关的内容也混进推理过程，导致输出“看起来更专业，但实际上跑偏了”。比如我在数据库设计审查技能里放了一个很详细的“分库分表最佳实践”文档，结果AI在评审一个只有几千数据量的小系统时，也强行推荐分库分表方案，理由还头头是道。

问题出在知识文件没有标明适用范围。后来我在每份知识文档顶部加了一段“适用前提”说明，比如“本文档适用于单表数据量千万级或以上场景，数据量较小或业务复杂度低时不建议采用”。这一下就解决了很多误用问题。知识不是越多越好，关键是每份知识都要有清晰的能力边界和适用条件。

4.4 过度封装，反倒降低效率

最后一个要提醒的是不要陷入“万物皆可Skills”的冲动。早期我什么场景都想做成技能，甚至连“周报生成”都单独写了个技能文件，结果发现直接用一段prompt效果反而更好。因为技能的价值在于“知识密度高、流程稳定、值得反复调用”，如果一个任务足够简单、上下文携带的知识很少，强行封装只会增加调用成本和出错概率。

我的判断标准是：如果一个任务你已经用同样的方式执行过三次以上，而且每次都依赖一段固定的领域知识，那才值得做成Skills；如果是一次性任务或纯自由发挥任务，直接对话就好。技能不是越多越体面，而是越精准越好用。

5. 从个人技能到团队资产：Skills的复制与进化

5.1 让每个成员的“手艺”变成团队标准

个人搭好一套技能后，更大的价值在于把它复制到团队里。传统模式下，资深工程师的评审经验存在脑子里，新同学只能靠“多踩几次坑”来慢慢领悟。有了Skills机制之后，这些经验可以直接沉淀为一个技能文件放进项目仓库，团队成员无论谁处理同类任务，都能调用同一套标准，输出风格也保持一致。

我们团队现在把评审技能放在一个独立的代码仓库里，用Git做版本管理，每次经验更新都走CR流程。比如一次线上故障复盘后发现“接口超时时间需要分级配置”这条经验，我们就把它补充到checklist.md中，合并到主分支后，后续所有评审结果都会带上这条检查项。这种模式下，技能不只是一个工具，它在慢慢变成团队的“数字制度手册”。

5.2 技能的回流迭代机制

还要说一点，技能不是写一次就永久生效的死文档。大模型在不断发展，业务场景也在变化，技能内容必须持续进化。我们为每个技能配置了“使用记录日志”，每次AI调用技能时会生成一条记录，包含输入请求、输出结果和用户反馈标记。每隔一两周整理一次这些记录，就能发现哪些检查项是高频命中、哪些知识文件基本没用、哪些输出模板让用户反复修改。

根据这些数据做一轮针对性调整，比闷头看文档去猜效果要靠谱得多。我自己的经验是：技能每迭代一轮，质量和易用性都会有肉眼可见的提升，这也是Skills这种“文件即程序”形态最大的优势——它天生就适合版本化管理和持续改进。

6. 写在后面的一点大实话

做了一轮Skills的深度实践下来，最大的感受是：它本质上是把“AI聊天”变成“AI干活”的那层壳。没有Skills时，AI是一个什么都知道一点但什么都不精的通才，你问它什么都能接几句；有了Skills之后，AI才能在特定领域带上你的行业积累、你的团队经验、你的输出标准，才能把一个任务从头到尾负责起来。这个东西的门槛其实不高，难的是你愿不愿意把自己脑子里那些“理所当然”的经验，认认真真写成条目、理成流程、装进文件里。我花在整理知识上的时间，远比想象中的多，但换来的是后续无数次稳定、高效的调用，这笔账怎么算都划算。如果你也正准备尝试，建议直接挑一个你日常做得最多、最拿手的任务动手，第一个技能别追求宏大，小而实用才是王道。