企业官网建设流程全解析

你是不是也有过这样的经历：花了不少时间把 PDF、网页、公众号文章全部导入知识库，然后打开对话框问 AI，结果回答还是空泛得像在“猜答案”，甚至跟你知识库里明明写过的东西完全对不上。

这不是 AI 不够聪明，而是你把知识库当成了一个“网盘”，只完成了“存进去”这一步。在一个真正可落地的知识库项目里，知识库本身只是底座，决定 AI 回答质量上限的，是跑在知识库上面的那一层“技能”，也就是 Skill。这个道理，在我们最近梳理的 BYZB-2026-1091 项目里体现得尤其明显。

这篇文章不打算只给你讲“ima 是什么”，而是聚焦两件事：第一，ima 知识库 Skills 该安装哪几种常用类型；第二，安装之后，怎么对 Skill 做日常管理。文章最后还会给出配置模板、本地管理脚本和常见问题排查表，方便你直接照着落地。

1. 这篇文章真正要解决的问题

先对齐一个基本判断：知识库建得好不好，看的不是文件数量，而是 AI 能不能稳定、准确地用好这些文件。

在 BYZB-2026-1091 这个知识库建设项目里，我们遇到过非常典型的三类问题：

第一类是“知识库有货，AI 不会用”。用户上传了产品手册、技术规范、历史项目文档，但提问时 AI 仍然在说“根据我的理解”，而不是“根据你知识库中的第几份文档”。这说明知识库虽然挂在了对话入口上，但 AI 没有按照正确的处理路径去检索和提取。

第二类是“回答风格不稳定”。同一个问题，上午问和下午问，结果结构完全不一样，有时候给表格，有时候给长段落，有时候甚至直接给一段“正确的废话”。这说明对话缺少一个稳定的输出约束。

第三类是“知识库更新后，回答没有跟着变”。文档明明已经替换了，AI 还在引用旧版本内容。这往往不是知识库同步的问题，而是技能层面没有定义“以哪个版本为准”。

这三类问题的共同根源，是缺少一层“可管理的 AI 处理规则”。而 Skill 要解决的，正是这件事。

如果你属于下面任意一类读者，这篇文章都值得读下去：

• 刚接触 ima 知识库，不知道除了上传文档之外还要配置什么；
• 已经在用 ima，但发现 AI 输出质量不稳定，想通过 Skill 固定处理流程；
• 在企业内部负责知识库落地，需要一套可复用、可管理的 Skill 分类和治理方法。

一句话概括：知识库解决“AI 有什么可用”，Skill 解决“AI 怎么用才可靠”。

2. ima 知识库与 Skill 的基本关系

2.1 ima 知识库是什么

ima 是腾讯推出的一款智能工作台产品，核心能力是“个人知识库 + 智能问答 + 内容创作”。你可以把本地文档、网页链接、公众号文章、碎片笔记等内容统一收进知识库，然后通过对话的方式对知识库进行检索、提问和二次创作。

从技术架构看，ima 知识库本质上是把非结构化的文档，通过嵌入模型转成向量，再基于检索增强生成（Retrieval-Augmented Generation，RAG）的方式，在用户提问时先从知识库中召回相关片段，再交给大语言模型组织答案。理解这一点非常重要，因为 Skill 并不是替代 RAG，而是给 RAG 后的组织过程增加“规则”。

2.2 Skill 在知识库链路中的位置

如果说知识库是“弹药库”，大模型是“士兵”，那 Skill 就是士兵手里的“作战手册”。

没有 Skill 时，大模型会按照它自己的通用习惯回答问题。它当然能读懂你的文档，但它不知道你希望答案以什么形式呈现、优先参考哪份文档、输出前是否需要做数据校验。这也是为什么同一个知识库，不同人问出来的答案质量差异会很大。

有了 Skill 之后，AI 在回答前会先读取技能定义，明确自己的角色、任务、处理步骤、输出格式和边界。它不再是一个“通用聊天机器人”，而是变成“专门处理某类任务的助手”。

从 ima 知识库的管理逻辑来看，知识库提供素材，Skill 提供行为规则，二者配合起来才能形成稳定的 AI 工作流。

2.3 知识库、Skill、对话入口的关系

可以用一个简单的关系来理解三者的协作：

也就是说，即使用户在对话入口提出完全相同的问题，只要挂载的 Skill 不同，最终回答也可能完全不同。这正是可管理性的来源。

3. 常用 Skill 类型分析

在落地 ima 知识库 Skills 时，第一个问题往往是：到底该装哪些 Skill？

从实际使用场景看，最值得优先配置的常用 Skill 主要有六类，覆盖了大多数个人知识库和企业知识库的高频需求。

下面逐个展开。

3.1 阅读摘要类 Skill

这类 Skill 适合处理“文档太长，没时间看”的场景。它的核心逻辑是：当用户要求对某篇文档或某个知识库目录做摘要时，AI 不是随意发挥，而是按固定结构输出。

一个合格的阅读摘要 Skill 至少应该约束三件事：摘要的长度范围、摘要必须包含哪些要素（如背景、结论、风险、行动项）、是否允许引用知识库外部的通用知识。

比较推荐的做法是让摘要输出四个部分：核心结论、关键论据、数据来源、待确认风险。这样读者拿到摘要后，可以快速判断“要不要读原文”。

3.2 知识整理类 Skill

这类 Skill 面向的是“资料很多但很乱”的痛点。它通常批量处理知识库中的文档，按主题、业务线、时间、重要程度等维度自动归类，并生成标签和检索建议。

知识整理类 Skill 的难点不在于“分类”本身，而在于“分类标准”。不同团队对同一份文档的理解可能完全不同，所以在配置时，一定要把分类规则写清楚，比如“市场部文档按产品线分类，技术文档按模块分类”。

如果没有这类 Skill，知识库很快就会变成第二个“混乱的共享网盘”，文件越多，检索反而越难。

3.3 专业写作类 Skill

专业写作类 Skill 的价值是解决“AI 写出来不能用”的问题。通用大模型写出的方案往往结构完整但缺少行业细节，而知识库里恰好有大量历史方案、模板和规范，写作类 Skill 可以要求 AI 优先参考这些素材，再按照指定的框架输出。

在实际配置时，建议拆细一点：周报 Skill、方案撰写 Skill、宣传文案 Skill 分开建，不要做一个“万能写作助手”。因为职责越单一的 Skill，越容易调优，输出质量也越稳定。

3.4 数据分析类 Skill

如果知识库里有销售数据、产品数据或项目进度表，数据分析类 Skill 就很有必要。它可以在回答“上季度哪个区域增长最快”这类问题时，先定位数据表，再说明统计口径，最后生成结论。

这类 Skill 的核心约束是“口径优先”。一定要在技能定义中写清楚：先确认数据来源，再解释计算方式，最后才给出结论。没有这个约束，AI 很容易拿知识库里几个不同的数据表混在一起算，输出一个“看似合理但不可信”的数字。

3.5 代码开发类 Skill

对于研发团队来说，把内部代码规范、架构设计文档、接口文档接入 ima 知识库后，可以配置代码开发类 Skill，让 AI 在回答代码问题时严格遵循团队约定的技术栈和编码规范。

与通用代码助手不同，基于知识库的代码类 Skill 更擅长回答“我们项目里 xxx 模块是怎么实现的”“这个接口的参数格式是什么”这类问题。它的价值来自知识库的“私有性”，而不是大模型自身的代码能力。

3.6 问答质检类 Skill

最后一种常用于客服或内部支持场景。问答质检类 Skill 会限定 AI 的回答边界，比如“只能回答知识库中存在的业务信息，无法确认的内容必须明确说明”，同时固定回答语气和礼貌用语。

它不追求回答的“惊艳”，而是追求回答的“安全”。在企业对外服务场景中，这种 Skill 往往是刚需。

4. Skill 安装与启用流程

明确要装哪些 Skill 之后，接下来就是“怎么装”。

需要先说明一点：ima 各版本的界面入口和功能名称可能会随版本迭代而调整，所以下面的流程更适合作为通用步骤来理解，具体入口名称建议以你当前客户端的实际界面为准。

4.1 找到 Skills 入口

ima 的知识库和 AI 能力通常集成在“智能体”或“技能”相关模块中。登录 ima 客户端后，建议先确认你的账号是否具备创建和安装 Skill 的权限。个人账号一般可以直接创建，企业账号可能由管理员统一分发。

如果找不到 Skills 入口，可以先在知识库详情页或对话设置页找“技能”“智能体”“Agent”等关键词。从产品逻辑看，Skill 一定会和知识库、对话这两个模块产生关联，所以入口大概率在二者附近。

4.2 从模板市场安装 Skill

在支持模板市场的版本中，安装 Skill 是最快的入门方式。你可以在模板市场找到官方或社区发布的常用 Skill 模板，确认模板描述和适用的知识库类型后，一键安装。

安装完成后，并不意味着立刻生效。你需要回到 Skill 管理页，把安装好的 Skill 关联或挂载到具体的知识库上。这一步容易被忽略，很多用户装完之后发现对话没有变化，原因就是 Skill 没有和知识库建立关联。

4.3 手动创建自定义 Skill

如果模板市场的 Skill 不匹配，或者团队有特殊要求，就需要手动创建。手动创建的步骤一般包括：

1. 进入 Skill 创建页，填写名称、简介、适用分类。
2. 编写提示词模板，定义角色、上下文、任务、输出格式。
3. 选择适用的知识库范围或指定数据源。
4. 设置触发条件或生效规则。
5. 保存并启用，然后返回对话页验证。

手动创建的关键在第二步。提示词模板写得好不好，直接决定 Skill 的质量。下一章我会给出一个可以直接参考的提示词骨架。

4.4 启用与验证

无论是安装还是手动创建，最终都要做一次“端到端验证”。建议采用“先小后大”的验证思路：

先准备一个最小测试集，里面包含一段确定答案的文档片段。然后挂载 Skill，问一个问题，检查输出是否满足 Skill 定义的格式，是否引用了指定文档。

如果发现 Skill 没有生效，不要急着改提示词，先检查两件事：Skill 是否处于启用状态，以及是否挂载到了当前对话使用的知识库上。

5. Skill 配置模板与提示词骨架

下面提供三个可直接使用的参考示例。第一个是 Skill 配置的通用 JSON 结构，第二个是提示词模板骨架，第三个是本地管理脚本。需要说明的是，这些示例是知识库项目中的通用实践格式，与 ima 特定版本的界面字段不一定完全一致，但设计思路是可以复用的。

5.1 Skill 配置通用模板

{ "skill_id": "doc_summarizer", "skill_name": "文档摘要助手", "version": "1.0.0", "category": "reading", "description": "对知识库中的长文档进行结构化摘要输出", "trigger": ["总结", "摘要", "概括", "太长不看"], "prompt_template": "你是一名资深阅读助理。请基于知识库中的资料，按以下结构输出摘要：\n1. 核心结论\n2. 关键论据\n3. 数据与来源\n4. 待确认风险\n要求：优先引用知识库内容，标注来源；不要输出与知识库无关的信息。", "knowledge_scope": "all", "output_format": "markdown", "enabled": true }

这个模板的要点在于prompt_template字段。它决定了 AI 工作时遵循的规则，而不是简单地把问题丢给大模型。

5.2 提示词模板骨架

如果你想手动创建 Skill，可以把下面的内容当作提示词骨架：

# Skill：研发周报生成助手 ## 角色定义 你是一名研发团队周报助理，熟悉团队知识库中的项目文档和任务记录。 ## 输入信息 - 本周任务列表 - 本周知识库新增内容 ## 任务步骤 1. 将任务按项目模块归类。 2. 提取每项任务的关键结果和数据指标。 3. 关联知识库中相关文档，标注文档名称。 4. 整理风险与阻塞项。 ## 输出格式 - 本周完成 - 关键数据 - 风险与阻塞 - 下周计划 ## 边界与约束 - 只能使用知识库中的数据，不得编造任务内容。 - 如果没有找到对应文档，明确说明“知识库中暂无相关记录”。

编写提示词骨架时，最忌讳只有一个角色定义。真正有效的提示词，一定要包含“输入、步骤、输出、边界”四个部分，尤其不能缺“边界”。没有边界的 Skill，容易让 AI 在找不到知识库内容时自行脑补。

5.3 本地辅助管理脚本

对于 Skill 数量较多的团队，强烈建议把每个 Skill 的定义保存为独立的 JSON 文件，统一放在一个目录里，用 Git 管理。这里提供一个轻量级 Python 脚本，用于扫描和查看 Skill 列表：

import json from pathlib import Path def load_all_skills(skill_dir): skills = [] for path in Path(skill_dir).glob("*.json"): try: with open(path, "r", encoding="utf-8") as f: skills.append(json.load(f)) except Exception as exc: print(f"[跳过] {path.name}: {exc}") return skills def list_skills(skill_dir): skills = load_all_skills(skill_dir) if not skills: print("未找到任何 Skill 配置文件") return for skill in sorted(skills, key=lambda item: item.get("category", "")): print( f"{skill.get('category', '未分类'):<10} | " f"{skill.get('skill_name', '未命名'):<16} | " f"v{skill.get('version', '?'):<6} | " f"{'启用' if skill.get('enabled', False) else '停用'}" ) if __name__ == "__main__": list_skills("./ima-skills")

配合 Git，可以为每个 Skill 维护版本历史：

mkdir -p ima-skills/{reading,writing,data,dev} git init git add ima-skills/ git commit -m "chore: 初始化 Skill 定义仓库"

不要把这个脚本当作 ima 的官方管理接口，它的价值是帮你维护一份“Skill 的源文件”。即使未来更换知识库产品，这些配置文件仍然是你的数字资产。

6. 如何管理好你的 Skill

安装 Skill 只是开始，管理 Skill 才是长期工作。一个没有人维护的 Skill 列表，半年之后就会变得和没有目录的共享盘一样混乱。以下几点是我们在知识库项目里沉淀下来最核心的管理方法。

6.1 命名规范

Skill 的名称必须让人一眼看懂它的职责。建议采用“业务域 + 任务类型”的结构，比如“研发-周报生成”“市场-推文撰写”“客服-问答质检”。

同一类型的 Skill 应统一大小写和语言。团队内部如果混用中英文名称，后期检索和管理都会变得很痛苦。

6.2 分类与标签体系

在建立 Skill 时，要同时确定分类。我的建议是：按“任务目标”分类，不要按“来源部门”分类。因为 Skill 是 AI 的行为规则，它和部门没有必然关系，一个销售部门完全可能使用“数据分析”类 Skill，而不是“销售”类 Skill。

一个比较稳的分类方式是：阅读摘要、知识整理、专业写作、数据分析、代码开发、问答服务。分类数量控制在 5 到 10 个之间，太多等于没有分类。

6.3 启用与停用策略

Skill 不应该是“装得越多越好”。每一次增加 Skill，都会增加检索和调用的复杂度。在生产环境的对话中，尽量只挂载当前场景必需的 Skill。

停用 Skill 的标准也应当明确：如果连续一段时间没有使用记录，或者输出质量无法通过测试，就应该先停用再评估，而不是保留在知识库里“以防万一”。

6.4 版本管理与变更记录

Skill 的提示词模板一定会迭代。建议像管理代码一样管理 Skill 配置，每次修改都要有版本号、修改人、修改时间和变更说明。

比如第一次创建是 v1.0.0，调整输出格式后升到 v1.1.0，如果改变了整个技能的执行逻辑，则升到 v2.0.0。没有版本管理的 Skill，一旦改了提示词导致回答质量下降，你几乎无法回滚到可用版本。

6.5 权限与安全边界

在企业场景中，Skill 的可见范围和管理权限必须区分开。建议遵循最小权限原则：普通用户只能使用已经被管理员审核通过的 Skill，只有管理员或 Knowledge Manager 才能创建、修改、启停 Skill。

同时要检查 Skill 是否可能诱导 AI 输出越权内容。Skill 是 AI 的行为规则，如果规则本身写得过于开放，AI 就可能基于知识库之外的信息回答，这在合规要求高的行业里是不可接受的。

6.6 定期复盘与淘汰

每个季度做一次 Skill 健康度检查。指标可以很简单：每个 Skill 的调用次数、平均评分、知识库引用准确率。对于评分持续偏低的 Skill，直接淘汰，不要试图通过反复修改提示词来“救活”一个定位本身就有问题的技能。

7. 常见问题与排查思路

在使用 ima 知识库 Skills 的过程中，下面这些问题是出现频率比较高的，按“现象-原因-排查-解决”整理如下：

如果你遇到了上面没有列出的问题，第一步不是去反复修改提示词，而是先“减配”到最简状态：一个知识库、一个 Skill、一个测试问题，逐个环节验证。很多时候，问题出在多技能并行调用时的相互干扰，而不是某个技能本身写错了。

8. 最佳实践与工程建议

前面几章解决了“怎么装、怎么配、怎么管”的问题，这一章沉淀几条经过验证的工程建议，适合刚起步的团队直接采纳。

8.1 先跑通最小闭环，再横向复制

不要一上来就把公司所有文档导入知识库，也不要一次性创建十个 Skill。我的建议是：选一个业务部门、选一个高频场景、建一个知识库、配一个 Skill，先跑通完整链路。

确认效果稳定后，再复制到其他部门。横向复制时也要警惕“文件结构相同但业务规则完全不同”的情况。知识库和 Skill 从来不是复制粘贴就能通用的。

8.2 知识库质量决定了 Skill 的上限

Skill 再强，也补不了知识库本身的烂数据。如果知识库里的文档版本混乱、格式不统一、甚至包含大量重复或过时内容，Skill 只能放大这些质量问题，而不是消除它们。

建议每次配置新 Skill 前，先对目标知识库做一次文档健康度检查，至少完成三件事：删除明显过期文档，统一文档命名格式，为重要文档补全标题和描述信息。

8.3 Skill 的职责要单一

一个 Skill 只做一类任务。不要试图做一个“全能助手”，又能写周报、又能查数据、又能做客服问答。

职责单一的 Skill 有三个好处：提示词容易写清楚，测试容易做充分，问题容易排查定位。反过来说，一个职责宽泛的 Skill 往往会让 AI 的输出变得不可预测。

8.4 提示词模板必须包含边界约束

这是最容易踩坑的地方。很多人在写 Skill 提示词时，只写了角色和任务，没有写“不能做什么”。结果 AI 在知识库找不到答案时，会本能地调用自己的通用知识来“圆场”，这在专业场景下是非常危险的。

边界约束至少要覆盖两点：一是“不编造”，二是“不越权”。前者是说找不到内容时应该主动说明，后者是说不要回答与当前任务无关的敏感问题。

8.5 建立 Skill 质量评估机制

建议为每个重要 Skill 建立一套评估问题集。这个评估问题集可以很小，比如每个 Skill 配 10 到 20 个有确定答案的测试问题，每次修改 Skill 后都跑一遍，作为回归测试。

不要依赖“感觉回答变好了”这种主观判断。把评估问题集的通过率作为 Skill 是否可上线的标准，这是让知识库项目长期可维护的关键习惯。

9. 总结与后续学习方向

回到文章开头的问题：知识库建好了，AI 为什么还是不够好用？答案在于，大多数知识库项目只完成了“存”的动作，没有认真设计“取出来怎么用”的规则。ima 知识库 Skills 的核心价值，就是把“怎么用”变成一套可以被测试、被管理、被复用的配置。

如果你现在的知识库项目正好卡在“上传了文档但回答质量不稳定”的阶段，下一步可以按这个顺序去实践：先梳理出一个高频业务场景，配置一个职责单一、包含边界约束的 Skill，再用固定测试集去验证效果，最后把留下有效版本的 Skill 纳入 Git 管理。等这套流程跑顺了，再逐步扩大覆盖场景。

更长远看，知识库产品的竞争正在从“存储能力”转向“技能分发能力”。谁能把业务经验沉淀成高质量、可管理、可调用的 Skill，谁的知识库才真正具备生产力价值。这也是我建议你尽早掌握 Skill 管理和版本化方法的原因，它不会只用于 ima 这一个产品。