企业官网建设流程全解析

1. 为什么“50个Skill”比“一个大而全的Agent”更值得投入

很多人第一次接触AI生产力系统时，脑子里想的都是“我要做一个超级Agent，什么都能干”。我早期也这么想过，结果折腾了三个月，做出来的东西看起来功能列表很长，实际用起来处处是坑：一个环节出错，整条链路全崩，排查起来像在拆炸弹。后来我彻底换了个思路——把能力拆成独立的Skill，每个Skill只解决一个具体问题，整个系统的稳定性和可维护性立刻上了一个台阶。

所谓Skill，你可以把它理解成“给AI装的一个个专业插件”。它不是一个完整的智能体，而是一段封装好的、有明确输入输出边界的能力单元。比如“把一段会议记录整理成待办清单”是一个Skill，“把一篇长文压缩成三条核心观点”是另一个Skill。它们各自独立，可以单独调用，也可以被更大的Agent编排组合。

为什么是50个？这个数字不是拍脑袋定的。我实际梳理下来，一个覆盖知识管理全流程的生产力系统，大致需要以下几类能力：

• 信息采集类：网页剪藏、PDF解析、语音转文字、图片OCR
• 信息加工类：摘要提取、要点归纳、标签生成、语义去重
• 知识组织类：本体建模、知识图谱构建、语义层映射、双向链接生成
• 检索调用类：语义搜索、关键词召回、上下文拼装、多轮追问
• 输出生成类：周报撰写、方案草稿、演示大纲、邮件回复
• 系统维护类：质量评估、冲突检测、过期清理、版本对比

每一类下面再细分，50个Skill是一个比较自然的收敛结果。少于30个，很多场景覆盖不到；多于80个，管理成本又会失控。

提示：不要一上来就追求数量。先把最高频的5个场景做成Skill，跑通之后再逐步扩展。我见过太多人列了100个Skill的清单，结果一个都没落地。

这里有个关键认知需要先建立：Skill和Agent的区别，不是“小”和“大”的区别，而是“确定性”和“自主性”的区别。Skill的输入输出是相对确定的，你给它什么格式，它返回什么格式，基本可控。Agent则需要在多个步骤之间做决策，自主性更强，但不确定性也更高。一个成熟的生产力系统，应该是“Agent做编排，Skill做执行”。Agent负责判断“现在该用哪个Skill”，Skill负责“把这件事稳稳当当地做完”。

我自己的系统里，Agent层其实很薄，主要就是一个路由和调度逻辑。真正干活的全是下面这50个Skill。这样做的好处是：任何一个Skill出问题，我只需要单独调试它，不会影响整个系统。而且每个Skill都可以独立迭代，今天优化摘要算法，明天改进标签策略，互不干扰。

2. 知识管理类Skill的五个核心分层

2.1 采集层：把散落各处的信息收拢进来

采集层是整个系统的入口。这一层做不好，后面全是垃圾进垃圾出。我踩过最大的坑就是“什么都想采集”，结果知识库里塞满了重复的、过期的、低质量的内容，检索的时候噪音极大。

采集层的Skill设计，核心原则是带上下文采集。什么意思？就是你在采集一条信息的时候，必须同时记录它从哪里来、什么时候来、为什么采集。这三个元数据后面会救你的命。

具体来说，我常用的采集类Skill包括：

• 网页正文提取Skill：输入一个链接，输出干净的正文Markdown，自动去掉导航栏、广告、评论区。这里的关键是正文识别算法，我试过 readability、trafilatura 等几种方案，最后选了一个基于密度和标签权重的组合策略，准确率能到90%以上。
• PDF结构化解析Skill：不是简单地把PDF转成文字，而是要保留标题层级、表格结构、图片位置。很多PDF解析工具转出来的文字是乱序的，段落顺序都乱了，这种数据后面根本没法用。
• 语音转写与分段Skill：录音转文字之后，还要做说话人分离和话题分段。不然一整段几千字的流水账，后面摘要都做不了。
• 图片信息提取Skill：截图、白板照片、流程图，用多模态模型提取其中的文字和结构信息。

采集层有一个容易被忽略的细节：去重。同一个信息可能从不同渠道进来，比如一篇文章你先收藏了链接，后来又保存了PDF。如果不做去重，知识库里就会出现多个版本。我的做法是在采集层就做一个轻量的指纹计算，用内容哈希加标题相似度做初步判断，重复的直接合并元数据，不重复入库。

2.2 加工层：把原始信息变成可用知识

采集进来的还是“原料”，加工层负责把它变成“半成品”。这一层的Skill直接决定了你后面检索和使用的体验。

摘要类Skill是这里面最核心的。但摘要不是简单地把长文变短，而是要根据用途生成不同粒度的摘要。我通常会给同一个内容生成三个版本：

标签生成Skill也很关键。很多人做标签就是让模型随便打几个关键词，结果标签体系混乱不堪。我的做法是先定义标签体系，再让模型在体系内选择。比如我预先定义了“领域”“类型”“重要度”“状态”四个维度，每个维度下面有固定的候选标签。模型的任务不是创造新标签，而是在已有标签里做选择。这样标签的一致性会好很多。

还有一个容易被低估的Skill是语义去重。传统去重看的是文字是否相同，语义去重看的是“意思是否相同”。比如“AI可以提高工作效率”和“人工智能能提升生产力”这两句话，字面不同但语义高度相似。语义去重Skill会计算向量相似度，超过阈值就标记为潜在重复，由人工确认后合并。

2.3 组织层：本体、知识图谱与语义层的落地

这一层是知识管理真正拉开差距的地方。大多数人做知识管理就是“文件夹+标签”，稍微好一点的是“双向链接”。但真正要让知识产生复利，需要引入本体建模和语义层的概念。

先说本体。本体听起来很学术，其实说白了就是定义你知识库里的“概念”和“关系”。比如“项目”是一个概念，“任务”是一个概念，“项目包含任务”是一种关系。你不需要一上来就搞得很复杂，先从最核心的5-10个概念和它们之间的关系开始。

我自己的本体大概长这样：

• 概念：项目、任务、会议、文档、人物、决策、问题
• 关系：项目包含任务、会议产生决策、决策关联问题、人物负责项目、文档支撑决策

有了本体之后，知识图谱的构建就有了骨架。知识图谱Skill的任务是从非结构化文本中抽取实体和关系，然后映射到本体上。比如一段会议记录里提到“张三负责下个月的版本发布”，抽取出来就是：人物(张三) —负责→ 任务(版本发布)，时间属性是下个月。

语义层是本体和知识图谱之上的查询接口。它让检索不再依赖关键词匹配，而是可以按“概念+关系”来查。比如你可以问“所有和张三相关的、还没有完成的、和版本发布有关的任务”，语义层会把它翻译成图查询，返回精确结果。

注意：本体建模不要追求一步到位。我见过有人花两个月设计了一个完美的本体，结果发现实际内容根本对不上，最后全部推翻重来。正确做法是先用最小本体跑起来，在实际使用中逐步扩展。

2.4 检索层：让知识在需要的时候自动出现

检索层的目标不是“能搜到”，而是“该出现的时候自动出现”。这需要几个Skill配合：

• 语义搜索Skill：把查询和文档都转成向量，计算相似度。这里的关键是向量模型的选择和分块策略。我的经验是，中文场景下分块不要太大，300-500字比较合适，太大噪音多，太小上下文丢失。
• 关键词召回Skill：语义搜索有时候会漏掉精确匹配的结果，所以需要关键词召回做补充。两者结合，用RRF（倒数排名融合）做结果合并。
• 上下文拼装Skill：检索到相关片段后，不是直接扔给模型，而是要把前后文、相关文档、元数据一起拼装成合适的上下文。这个Skill决定了最终生成质量的上限。
• 多轮追问Skill：用户第一次搜索往往不够精确，这个Skill负责根据上一轮结果生成追问建议，引导用户逐步收敛。

2.5 维护层：知识库的“体检”与“保鲜”

知识库不是建好就完了，它会腐烂。过期信息、矛盾信息、孤立信息会越来越多。维护层的Skill就是定期给知识库做体检。

我常用的维护Skill包括：

• 过期检测Skill：根据内容的时效性标签和最后访问时间，标记可能过期的内容。
• 冲突检测Skill：当新入库的内容和已有内容矛盾时，自动标记出来。比如两份文档对同一个决策的描述不一致。
• 孤立检测Skill：找出那些没有任何关联的“孤岛”内容，提示你补充关联或清理。
• 质量评分Skill：根据来源可信度、完整度、被引用次数等维度，给每条知识打分。

3. 从零搭建AI生产力系统的实操路线

3.1 环境准备中最容易忽略的三个细节

搭建这套系统，技术栈的选择其实没有想象中那么重要。我用过Python+LangChain，也用过TypeScript+自研编排，甚至试过用低代码平台搭。工具换来换去，真正影响成败的是下面这三个细节。

第一个细节：向量数据库的选型要看数据规模，不要看benchmark。我一开始用了一个在benchmark上排名很高的向量库，结果数据量到十万条之后，查询延迟飙升。后来换成更朴素的方案，反而稳定了。对于个人知识管理场景，数据量通常在几万到几十万条之间，选择支持增量索引、过滤查询、本地部署的方案就够了。不要为了“先进”而选型。

第二个细节：模型调用的成本控制要提前设计。50个Skill如果每个都调用大模型，成本会很快失控。我的做法是分层：简单的分类、抽取任务用小模型或本地模型；复杂的生成、推理任务才用大模型。另外，所有Skill都要有缓存机制，相同输入直接返回缓存结果。

第三个细节：日志和可观测性要从第一天就做。每个Skill的输入、输出、耗时、token消耗都要记录。不然出了问题你根本不知道是哪个环节的锅。我用的是一个简单的JSONL日志，每条记录包含skill_name、input_hash、output_hash、latency、token_count、timestamp。后面做优化的时候，这些日志就是金矿。

3.2 核心Skill的代码结构长什么样

一个典型的Skill，代码结构其实很简单。以“摘要生成Skill”为例：

class SummarySkill: def __init__(self, model_client, cache): self.model = model_client self.cache = cache def run(self, text, granularity="paragraph"): cache_key = f"summary:{hash(text)}:{granularity}" if cached := self.cache.get(cache_key): return cached prompt = self._build_prompt(granularity) result = self.model.generate(prompt, text) self.cache.set(cache_key, result) self._log(text, result) return result def _build_prompt(self, granularity): # 根据粒度选择不同的提示词模板 ...

关键点在于：每个Skill都是无状态的。它不保存任何上下文，所有需要的信息都通过参数传入。这样做的好处是Skill可以被任意编排、任意复用，也方便测试。

3.3 编排层：Agent如何决定用哪个Skill

编排层的核心是一个路由逻辑。最简单的做法是用规则匹配：如果输入是URL，走采集Skill；如果输入是长文本，走摘要Skill。但实际场景往往更复杂，需要模型来判断意图。

我的做法是两阶段路由：第一阶段用轻量分类模型做粗筛，把输入分到几个大类；第二阶段在大类内部用规则或小模型做精确匹配。这样既保证了速度，又保证了准确率。

编排层还有一个重要职责是错误处理。某个Skill失败了怎么办？我的策略是：可重试的错误自动重试，不可重试的错误降级到备用Skill，备用也失败就记录到待处理队列，不阻塞主流程。

4. 实测中那些文档不会告诉你的坑

4.1 语义分块的边界问题

做语义搜索的时候，分块策略是个大坑。我试过固定长度分块、按段落分块、按标题分块，各有各的问题。固定长度会把一个完整的论述切断，按段落又会导致块太小、上下文不足。

后来我用的策略是递归分块+重叠窗口：先按标题分，标题下面如果太长再按段落分，段落还长就按句子分。每个块之间保留10%-20%的重叠，确保边界信息不丢失。这个策略实测下来，检索召回率比固定分块高了将近20个百分点。

4.2 标签体系的“熵增”问题

标签用久了一定会膨胀。今天觉得这个标签有用，明天觉得那个标签也需要，最后标签数量失控，检索的时候反而不知道选哪个。

我的应对方法是定期做标签合并。每个月跑一次标签分析Skill，找出使用频率极低、语义高度重叠的标签，合并或删除。同时设置标签准入规则：新标签必须至少关联5条内容才能创建，否则先用现有标签。

4.3 知识图谱的“冷启动”困境

知识图谱最大的问题是冷启动：没有足够的数据，图谱就是空的；图谱是空的，又没人愿意往里录数据。

我的解法是从已有内容反向构建。不要一开始就要求用户手动录入实体和关系，而是先用抽取Skill从已有文档里自动抽取，生成一个粗糙的初始图谱。然后让用户在这个基础上做修正和补充。这样启动成本低很多，而且用户看到实际效果后，更愿意继续投入。

4.4 模型幻觉在知识管理中的特殊危害

在知识管理场景里，模型幻觉的危害比一般场景更大。因为用户会把生成的内容当作“自己的知识”存起来，如果内容是错的，后面会一直错下去。

我的做法是所有生成类Skill都必须带引用。摘要也好，标签也好，实体抽取也好，输出里必须包含“这个结论来自原文的哪一段”。这样用户至少可以快速验证。另外，对于关键决策类的内容，我会加一道人工确认流程，不自动入库。

5. 50个Skill的清单与优先级排序

5.1 必装的15个核心Skill

如果你刚开始搭建，不要贪多。下面这15个Skill覆盖了80%的高频场景，先把它们跑通：

1. 网页正文提取
2. PDF结构化解析
3. 语音转写与分段
4. 一句话摘要生成
5. 段落摘要生成
6. 关键词标签生成
7. 语义去重检测
8. 向量化与索引
9. 语义搜索
10. 关键词召回
11. 上下文拼装
12. 实体抽取
13. 关系抽取
14. 过期检测
15. 质量评分

这15个跑通之后，你的知识管理基本盘就稳了。后面再根据实际需求逐步扩展。

5.2 进阶Skill的扩展方向

核心盘稳定之后，可以从这几个方向扩展：

• 自动化方向：定时采集、自动归档、自动周报
• 协作方向：多人知识库的权限管理、变更通知、评论关联
• 分析方向：知识增长趋势、热点话题追踪、知识缺口识别
• 输出方向：演示文稿生成、方案草稿生成、邮件回复生成

每扩展一个Skill，都要问自己：这个Skill解决的是真实高频需求，还是我想象出来的需求？我踩过最大的坑就是做了一堆“看起来很酷但从来不用”的Skill，白白浪费了大量时间。

5.3 用数据驱动Skill的迭代

Skill做完不是终点。每个Skill都要有明确的评估指标：

这些指标不需要一开始就完美，但必须有。没有指标，你就不知道优化有没有效果。

6. 让系统真正跑起来的三个习惯

6.1 每天花10分钟做“知识入库”

系统再好，你不往里存东西也没用。我的习惯是每天固定花10分钟，把当天看到的、想到的、讨论到的有价值信息过一遍采集Skill。不要攒着，攒着就永远不会做了。

6.2 每周做一次“知识回顾”

每周花30分钟，让系统生成一份本周知识回顾：新增了什么、关联了什么、有哪些待处理。这个过程本身就是在强化知识连接。

6.3 每月做一次“系统体检”

跑一遍维护层的所有Skill，看看有没有过期内容、冲突内容、孤立内容。该清理的清理，该合并的合并。知识库和花园一样，不修剪就会杂草丛生。

这套系统我跑了将近一年，最大的体会是：不要追求完美，要追求持续运转。一个每天在用的粗糙系统，价值远大于一个设计精美但束之高阁的完美系统。50个Skill不是目标，让知识真正流动起来才是。