企业官网建设流程全解析

如果你最近刚开始接触大模型应用开发，很可能已经看过不少“用 LangChain 做一个 PDF 问答助手”“用向量数据库搭建企业知识库”之类的教程。问题是，这些例子离真实生活太远，跑通了也记不住。反过来，如果你是一个动漫爱好者，想给自己喜欢的角色做一个 AI 对话助手，第一步就会被现实泼一盆冷水：角色设定太多太碎，靠一条 system prompt 让模型记住完整人设，既不现实，效果也极不稳定。

这篇文章想用一个经典案例——以《百变小樱》中的知世作为演示角色，带你完整搭建一个“动漫角色 AI 知识库助手”。项目不复杂，但会覆盖角色知识库整理、文本向量化、向量检索、大模型回复、多轮对话记忆这几个关键环节。跑通之后，你再换任何角色、任何垂直领域的私有文档，思路都是一样的。

这里先给出我的判断：这类需求的核心不是“提示词写得多花哨”，而是有没有一套可靠的“知识检索 + 上下文注入”机制。而 RAG（检索增强生成）就是目前性价比最高、最灵活、最容易上手的解决方案。

读完这篇文章，你会得到一个本地可运行的命令行聊天程序。你可以问它“知世是什么性格”“知世和小樱是什么关系”，它会基于角色知识库回答，而不是凭空编造。最后我还会讲清楚：真正用在生产环境时，哪些地方需要优化，哪些坑必须避开。

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

先聊一个实际场景。假设你在做一个同人站点的角色问答机器人，或者单纯想给社群里的朋友做一个“百变小樱知世”的互动入口。第一种做法是把角色设定全部塞进 system prompt：

你是知世。你是一个温柔、细心、喜欢摄影和做衣服的女孩。你最好的朋友是小樱……请用这种语气回答。

听起来挺简单，但用起来问题就来了。

第一，角色设定很难塞全。一个经典作品里的角色，至少涉及性格、背景故事、人物关系、口头禅、剧情经历、服装道具等多个维度，这些信息加起来很容易超过上下文限制，而且硬塞进去会挤出真正用于对话的空间。

第二，模型记不住细节。即使你把设定都写进去了，模型在长对话中也容易“遗忘”前面的人设。它会突然说出不符合角色身份的话，或者把其他角色的经历安到这个角色头上。

第三，不好维护。如果明天你想再加几条新的角色设定，改 system prompt 意味着整个对话上下文都要重新生成。如果项目进一步发展成“多角色可切换”，这种硬编码方式会直接崩盘。

所以，这篇文章真正要解决的问题是：如何用工程化的方式，把角色知识从提示词里解放出来，放到一个可检索的知识库中，让模型在回答问题时按需获取准确的背景知识。

这也回答了另一个问题：为什么做动漫角色助手是一个值得练手的项目？因为它既有明确的知识边界，又有自然语言交互需求，还涉及数据准备、检索、生成、对话管理全流程。把一个角色助手跑通，你就等于掌握了做“企业知识库问答”的核心技能。换掉数据源，把知世换成产品手册、开发文档、售后 FAQ，原理完全一样。

2. RAG 基础概念与角色助手的适用场景

RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。它的核心思想很简单：先到知识库里检索和用户问题相关的内容，再把这些内容作为参考资料交给大模型生成答案。

没有 RAG 时，大模型只能依靠参数里的记忆回答问题，而模型训练数据不可能覆盖所有角色细节。有了 RAG，大模型就不再是“假装什么都知道”，而是变成“带着参考资料回答问题”。

RAG 包含两个关键概念需要先理解清楚。

第一个是 Embedding，也就是文本向量化。你可以把它理解为把一段文字转换成一串数字。因为计算机无法直接比较“两段文字像不像”，但可以比较“两串数字像不像”。把“知世喜欢摄影”和“知世喜欢录像”转换成向量后，它们在向量空间中的距离会比较近，这意味着语义相似。

第二个是向量数据库。普通数据库擅长精确查找，比如查“姓名等于小樱的记录”。但我们要做的是语义查找，比如“谁是摄影爱好者”，这时需要先计算每个文本块的向量，再通过余弦相似度找到最接近用户问题的文本片段。向量数据库就是专门干这件事的。

在实现角色助手之前，先对比一下三种常见方案的优劣势：

从对比可以看到，RAG 的定位是“知识型对话”的最佳起点。它既不需要高质量训练数据，也不需要动辄几千元的微调成本，只需要一份结构化文档、一个向量数据库、一个大模型接口，就能解决大部分角色一致性问题。

对于《百变小樱知世》这个案例来说，RAG 还有一个额外好处：知世的资料分散在剧情、设定集、粉丝讨论中，用检索方式每次只取相关片段，比把所有设定一次性塞进模型要可靠得多。

3. 环境准备与项目结构

项目不需要 GPU，普通笔记本即可运行。唯一需要注意的是，嵌入模型第一次加载时会下载文件，请保持网络稳定。

推荐使用 Python 3.10 或更高版本，创建独立虚拟环境，避免污染系统 Python。

conda create -n tomoyo python=3.10 -y conda activate tomoyo

安装依赖：

pip install sentence-transformers chromadb openai

三个核心依赖的作用如下：

• sentence-transformers：负责将文本转换为向量，这里使用 BGE 中文嵌入模型，对中文语义支持较好。
• chromadb：本地向量数据库，用于存储和检索文本向量。
• openai：用于调用兼容 OpenAI 规范的大模型接口。

项目结构建议如下：

tomoyo-assistant/ ├── config.py ├── build_kb.py ├── chat.py ├── requirements.txt └── data/ └── tomoyo_kb.md

四个文件的职责划分很清晰：

• config.py：集中管理路径、模型名、API 地址等配置。
• build_kb.py：读取角色知识文档，分块、向量化并写入 Chroma。
• chat.py：加载知识索引，完成多轮对话。
• data/tomoyo_kb.md：角色知识源文件，所有回答的事实依据都在这里。

这样的拆分有一个好处：当你以后想换一个角色，只需要修改数据文件和配置，不需要改太多代码。

4. 角色知识库：原始数据怎么组织

很多人做 RAG 项目，把注意力全放在代码上，却忽略了最重要的一环：数据质量。RAG 的检索能力再强，如果原始文档本身杂乱无章，检索出来的内容就不会准确。

在构建知识库之前，先说一个现实问题：版权与合规。为角色整理知识卡片时，不要直接复制大段台词、漫画原文或设定集内容，也不要去抓取未授权网站上的长篇文本。更稳妥的方式是基于公开资料做信息摘录和总结，写成自己的话，保留关键事实即可。这既尊重版权，也能避免知识库里塞进大量无用的原文片段。

这里提供一个适合演示用的角色知识文档模板，路径为data/tomoyo_kb.md：

# 角色基础信息 知世是《百变小樱》中的重要角色，是小樱的同班同学和好朋友。她性格温柔，做起事情来非常认真，在学校里很受欢迎。 # 性格特点 知世心思细腻，观察力很强，能注意到别人容易忽略的细节。她说话温柔，经常鼓励身边的人。她最大的特点是愿意默默支持和成全朋友，而不是抢风头。 # 摄影与服装爱好 知世非常喜欢用摄像机记录小樱的日常和战斗过程。她也擅长设计和制作服装，会为小樱准备各种式样的战斗服。这些服装不仅是道具，也体现了她对朋友的用心。 # 与小樱的关系 知世是小樱最好的朋友之一。她的行动准则是希望小樱开心，并尽可能保护小樱。虽然她本人没有直接参与战斗，但她会在精神上和物资上给小樱提供支持。 # 居住背景 知世家境优渥，家里有很好的生活条件和设备，这为她的摄影与服装制作爱好提供了支持。 # 典型对话风格 知世的说话语气温和，常用礼貌的措辞。她在提到小樱时，会不自觉地流露出开心和欣赏的情绪。她不喜欢争执，遇到冲突时更倾向于温和化解。

这份文档的特点是按主题分节，每一节围绕一个维度展开。这种结构非常适合 RAG：用户问“知世是什么性格”，检索系统只需要找到“性格特点”一节；用户问“知世和小樱关系怎么样”，系统就会命中“与小樱的关系”一节。

在实际项目中，你可能不止一个文档。可以把剧情总结、角色关系图、道具说明分别放成多个 Markdown 文件。后续代码只要稍加调整，遍历一个目录下的所有文件即可。

5. 核心代码实现

进入正题。这个项目我特意没有引入 LangChain 这类重框架，而是直接用 Python SDK 编写，原因有三：一是代码逻辑透明，你很清楚每一步在做什么；二是版本兼容问题少，不会因为框架升级导致代码直接报废；三是便于后续按需改造。

5.1 基础配置文件

先创建config.py，把需要经常修改的参数集中起来：

# 文件路径：config.py from pathlib import Path BASE_DIR = Path(__file__).parent KB_PATH = BASE_DIR / "data" / "tomoyo_kb.md" CHROMA_DIR = BASE_DIR / "chroma_db" COLLECTION_NAME = "tomoyo_kb" # 中文文本向量化模型 EMBEDDING_MODEL = "BAAI/bge-small-zh-v1.5" # 大模型配置，请替换为你实际使用的模型名和地址 LLM_MODEL = "your-model-name" LLM_BASE_URL = "https://api.example.com/v1" LLM_API_KEY_ENV = "LLM_API_KEY"

关于大模型配置，重点提醒一句：不同服务商的模型名称、接口地址、调用限制都不一样。代码中使用了LLM_API_KEY_ENV环境变量，运行前需要先设置：

export LLM_API_KEY="你的API密钥"

在 Windows 环境下对应命令是set LLM_API_KEY=你的API密钥。把密钥放在环境变量里，而不是写死在代码中，是一个基本的安全习惯。

5.2 构建角色知识库向量索引

接下来写build_kb.py。它的任务是把 Markdown 文档按一级标题切分成多个区块，再进行向量化，最后写入 Chroma。

# 文件路径：build_kb.py from pathlib import Path import chromadb from sentence_transformers import SentenceTransformer from config import CHROMA_DIR, COLLECTION_NAME, EMBEDDING_MODEL, KB_PATH def split_markdown_sections(path: Path) -> list[str]: """按一级标题切分 Markdown 文档，每个一级标题下的内容为一个知识块。""" text = path.read_text(encoding="utf-8") sections = [] current = [] for line in text.splitlines(): if line.startswith("# ") and not line.startswith("## "): if current: sections.append("\n".join(current).strip()) current = [line] else: current.append(line) if current: sections.append("\n".join(current).strip()) return [s for s in sections if s] def build_knowledge_base() -> None: if not KB_PATH.exists(): raise FileNotFoundError(f"知识库文件不存在：{KB_PATH}") sections = split_markdown_sections(KB_PATH) print(f"读取到 {len(sections)} 个知识块") model = SentenceTransformer(EMBEDDING_MODEL) embeddings = model.encode(sections, normalize_embeddings=True).tolist() client = chromadb.PersistentClient(path=str(CHROMA_DIR)) collection = client.get_or_create_collection(COLLECTION_NAME) # 每次重建前清空旧数据，防止重复索引 existing_ids = collection.get()["ids"] if existing_ids: collection.delete(ids=existing_ids) metadatas = [ {"source": f"{KB_PATH.name}::section-{i}"} for i in range(len(sections)) ] collection.add( ids=[str(i) for i in range(len(sections))], documents=sections, embeddings=embeddings, metadatas=metadatas, ) print(f"知识库索引完成，共写入 {len(sections)} 个知识块") if __name__ == "__main__": build_knowledge_base()

这段代码有几个细节值得解释。

第一，split_markdown_sections函数根据一级标题切分文档。这样每个知识块都保留了自己的标题和上下文，检索出来的结果不会是一句孤零零的话。

第二，normalize_embeddings=True会把向量归一化到单位长度。归一化之后，向量之间的欧氏距离和余弦相似度在排序意义上等价，检索结果更稳定。

第三，collection.delete保证每次重建索引时不会留下旧数据。如果跳过这一步，重复运行脚本会导致同一个知识块被写入多份，检索结果会被重复片段干扰。

运行构建命令：

python build_kb.py

第一次运行时，SentenceTransformer会下载 BGE 模型，耗时根据网络情况可能在几十秒到几分钟不等。看到下面的输出，说明索引构建成功：

读取到 6 个知识块 知识库索引完成，共写入 6 个知识块

5.3 RAG 查询与回复生成

知识库构建完成后，开始写核心查询程序chat.py。

# 文件路径：chat.py import os import sys import chromadb from openai import OpenAI from sentence_transformers import SentenceTransformer from config import ( CHROMA_DIR, COLLECTION_NAME, EMBEDDING_MODEL, LLM_API_KEY_ENV, LLM_BASE_URL, LLM_MODEL, ) def load_rag_components(): model = SentenceTransformer(EMBEDDING_MODEL) client = chromadb.PersistentClient(path=str(CHROMA_DIR)) collection = client.get_collection(COLLECTION_NAME) return model, collection def retrieve_context(collection, model, query: str, top_k: int = 3) -> str: """检索与问题最相关的知识块，并拼接成上下文。""" query_embedding = model.encode([query], normalize_embeddings=True).tolist() results = collection.query( query_embeddings=query_embedding, n_results=top_k, ) docs = results["documents"][0] return "\n\n---\n\n".join(docs) def build_system_prompt(context: str) -> str: return f"""你是一个角色扮演助手，正在扮演《百变小樱》中的角色知世。 请根据下面的知识库片段回答问题，不要编造知识库中不存在的事实。 知识库片段： {context} 回答要求： 1. 语气温柔、自然，符合知世的角色特点。 2. 不要直接复制知识库原文，要用自己的话回答。 3. 如果知识库中没有相关内容，请如实说“这部分我不太确定”，不要强行猜测。 4. 每次回答控制在 200 字以内。 """ def main() -> None: api_key = os.environ.get(LLM_API_KEY_ENV) if not api_key: print(f"请先设置环境变量 {LLM_API_KEY_ENV}") sys.exit(1) model, collection = load_rag_components() client = OpenAI(api_key=api_key, base_url=LLM_BASE_URL) history = [] print("知世助手已就绪，输入 exit 退出对话。") while True: user_input = input("\n你：").strip() if user_input.lower() in ("exit", "quit"): break if not user_input: continue context = retrieve_context(collection, model, user_input) system_prompt = build_system_prompt(context) messages = [{"role": "system", "content": system_prompt}] messages.extend(history) messages.append({"role": "user", "content": user_input}) response = client.chat.completions.create( model=LLM_MODEL, messages=messages, temperature=0.7, ) assistant_reply = response.choices[0].message.content print(f"\n知世：{assistant_reply}") history.append({"role": "user", "content": user_input}) history.append({"role": "assistant", "content": assistant_reply}) # 控制历史长度，防止上下文无限膨胀 if len(history) > 10: history = history[-10:] if __name__ == "__main__": main()

这里的关键逻辑是retrieve_context。用户输入问题后，系统先把问题转换成向量，再用向量数据库检索最相似的 3 个知识块。这 3 个知识块被拼接到 system prompt 中，大模型在生成答案时就有了“参考资料”。

另一个关键是history列表。普通 RAG 问答只处理单轮问题，但角色对话天然是多轮的。代码把前几轮的用户消息和助手回复追加到 messages 中，保证模型能记住当前话题。history[-10:]则限制了历史长度，避免超长对话导致上下文溢出。

5.4 多轮对话的完整流程

至此，整个对话流程可以概括为四个步骤：

1. 用户输入“知世喜欢做什么”。
2. 系统将问题向量化，到 Chroma 中检索相关知识点。
3. 检索结果拼接进 system prompt。
4. 大模型基于“角色设定 + 知识片段 + 对话历史”生成回复。

这也是 RAG 项目最标准的处理链路：查询向量化、相似度检索、上下文注入、生成回复。理解了这条链路，后面无论换什么框架，核心思想都不会变。

6. 运行效果与结果验证

运行聊天程序：

python chat.py

设置好 API 密钥后，正常启动会进入交互界面：

知世助手已就绪，输入 exit 退出对话。 你：你好，请问你是谁？ 知世：你好，我是知世。很高兴在这里见到你。 你：知世平时喜欢做什么？ 知世：我平时很喜欢用摄像机记录小樱的日常，也会亲手为她设计一些好看的服装。看着她开心，我也会觉得很幸福。 你：谢谢，再见。 知世：谢谢你今天陪我聊天，下次再见哦。

对运行结果，建议从三个维度验证。

第一，回答是否基于知识库。如果程序回答“知世是中国人”或“知世喜欢打篮球”，说明上下文注入有问题，或是知识库文档本身错了。正确表现是“摄像”“服装”“小樱”这些关键词能命中知识库内容。

第二，回答是否有角色感。RAG 负责“知识和事实”，但语气风格主要由 system prompt 控制。如果回答像客服机器人，需要调整“回答要求”部分的措辞，比如增加“说话慢一点”“习惯使用礼貌称呼”。

第三，是否支持多轮记忆。在连续对话中，如果提问和上一轮主题相关，模型应该能接住。比如先问“知世怎么看待朋友”，再追问“那你觉得我应该怎么做”，后者虽然没有“知世”二字，模型也能保持角色视角。

如果回答效果不理想，请优先检查原始知识文档，而不是急着调代码。RAG 有一句经验法则：检索结果的质量上限，由知识库的质量决定。文档本身写得模糊、互相矛盾，后续工程手段很难弥补。

7. 常见问题与排查思路

在实际运行过程中，读者最容易遇到下面几类问题：

一个容易被忽视的操作是，每次修改了data/tomoyo_kb.md，都要重新运行python build_kb.py重建索引。很多人在文档里改了内容，却忘了重建，于是程序永远用旧数据回答，排查半天也找不到原因。

另外，Chroma 使用本地存储目录chroma_db。如果向量数据结构异常，可以直接删除该目录后重新构建，索引过程本来就是可重入的。

8. 工程优化与安全边界

当前版本是一个最小可行示例，适合学习和二次开发。如果要把这个项目发布给更多人使用，或迁移到生产环境，下面这几个方向必须考虑。

第一，嵌入模型的选型。本地 BGE 模型方便、免费、无外部调用延迟，但它的维度、效果和深度语义理解能力，通常不如云端专用 Embedding 模型。如果知识库很大，或对检索准确率要求高，可以把 Embedding 替换成云端 API。但要注意，嵌入模型一旦更换，必须重建整个索引，不能让新旧向量混在一起。

第二，检索策略的精细化。目前固定top_k=3，在知识库很小时够用。可一旦知识库膨胀到几十上百个区块，top_k=3会漏掉重要信息。更好的做法是按相关度阈值过滤，比如只保留相似度得分高于 0.6 的结果；如果所有结果都低于阈值，则直接告知用户“未找到相关知识”。这能显著降低大模型胡编乱造的概率。

第三，回答来源追踪。生产环境中，用户有权利知道答案来自哪里。建议在返回文本时，同时返回命中的知识块元数据，例如source字段。以后做成 Web 界面时，可以把“参考了哪个知识块”显示在答案下方。这既增加了可信度，也方便人工审核。

第四，安全边界不能忽略。角色对话程序本质上也是一个生成式 AI 应用，需要明确设定“拒绝规则”。如果用户输入涉及违法、暴力、诈骗等敏感内容，system prompt 中应当加入明确的安全约束。本文的知识库只是演示，真实部署时还需要结合内容安全审核服务，对上下游的输入输出做检测。

第五，成本与性能平衡。如果你使用了云端大模型 API，每个问题都会消耗 token。对于高频重复问题，可以在 RAG 检索之前加一个“缓存层”，用问题原文做键、答案做值。命中缓存时直接返回，既省钱又降低延迟。同时要注意，不要在没有必要的情况下，把整个历史全部发给模型，过长的消息列表会快速耗掉 token 预算。

第六，不要忽略评测。判断角色助手做得好不好，不能只看一次回答。建议准备一份“评测问题集”，覆盖基础知识、人物关系、性格推测、拒绝回答四类问题，然后在每次修改系统 prompt 或知识库后，统一跑一遍，对比回答是否变好。这本质上就是大模型应用里的回归测试，越早建立越省心。

9. 总结与后续学习方向

回到最初的问题：为什么“给动漫角色做 AI 助手”这个项目值得动手？因为它把大模型应用开发里最重要的一环——知识管理——完整地串了起来。表面上看，你只是做了一个“百变小樱知世”的问答机器人；实际上，你已经掌握了一个可以套用到任何垂直领域的方法：整理领域资料、做知识分块、向量化存储、检索增强生成。

我建议的实践路径是：先不要急着加复杂框架，把这一版命令行的最小项目彻底跑通、改坏、修好，直到你能流畅地解释“为什么需要向量化”“为什么检索结果要拼接进 prompt”。然后再逐步加 Web 界面、多角色切换、缓存、权限控制。

如果你打算继续深入，可以重点关注这几个方向：文本分块策略的优化、混合检索（关键词检索与向量检索结合）、重排序模型、流式输出、Agent 记忆机制。它们都会直接影响辅助工具在真实场景中的可用性。

最后提醒一句：做这类角色同人项目时，请务必注意数据来源的合规性，不要直接复制大段原文，尽量自己整理和摘要。技术本身可以玩出很多花样，但尊重版权、保障内容安全，永远是大模型应用开发不可忽视的底线。