OpenSoul开源框架：构建拥有持久记忆与人格的AI角色

1. 项目概述与核心价值

最近在开源社区里，一个名为“samttoo22-MewCat/OpenSoul”的项目引起了我的注意。乍一看这个标题，可能会觉得有些神秘——“OpenSoul”，开放的灵魂？这听起来更像是一个哲学或艺术项目。但当你点进仓库，看到README里关于“AI角色扮演”和“对话模型”的描述时，一切就豁然开朗了。这本质上是一个专注于构建和驱动AI角色（或称为“数字灵魂”）的开源框架。简单来说，它让你能够创建一个拥有特定性格、背景、记忆和对话风格的AI角色，并与之进行深度、连贯的互动。

这解决了什么问题呢？回想一下我们与大多数通用AI助手的交互：它们知识渊博，但往往缺乏“人设”，对话感觉像是在查询一个聪明的数据库，每次交互都是孤立的。而OpenSoul瞄准的，正是赋予AI一个持续、鲜活的“人格”。无论是想创建一个虚拟的陪伴型伙伴、一个特定领域的专家顾问（比如一位永远有耐心的历史老师），还是一个游戏中的NPC，这个框架都提供了从角色定义、记忆管理到对话生成的一整套工具链。它适合对AI应用开发感兴趣的开发者、想要打造独特交互体验的产品经理，甚至是热衷于此的爱好者。接下来，我将结合自己的实践经验，深入拆解这个项目的设计思路、核心模块以及如何上手实践。

2. 项目整体架构与设计哲学

2.1 核心设计思路：从“工具”到“角色”的范式转变

OpenSoul的设计核心，在于将AI从一个提供信息或执行任务的“工具”，转变为一个拥有内在一致性的“角色”。这个转变背后有几个关键考量：

人格的持久性与一致性：一个角色之所以可信，是因为其行为、语言和反应在长时间跨度内是连贯的。OpenSoul通过维护一个持续更新的“角色记忆库”来实现这一点。这个记忆库不仅存储了角色设定的核心档案（如姓名、性格、背景故事），更重要的是记录了与用户互动的历史。每次对话时，系统会从记忆库中检索相关的上下文，确保AI的回答能“记得”之前聊过什么，甚至基于过去的互动发展出新的“关系”或“认知”。

上下文感知与深度交互：通用大模型虽然有强大的语言能力，但其上下文窗口是有限的，且默认不包含持久的角色状态。OpenSoul在用户与大模型之间充当了一个智能的“上下文管理器”和“提示词工程师”。它动态地构建每次对话的提示（Prompt），将角色设定、当前对话目标和相关的历史记忆巧妙地编织在一起，形成一个高度情境化的指令，从而引导大模型产出符合角色设定的回复。

模块化与可扩展性：项目没有试图打造一个封闭的黑盒系统，而是采用了清晰的模块化设计。这意味着你可以替换其中的组件，比如使用不同的大模型API（OpenAI、Claude、国内合规的各类大模型平台）、采用不同的向量数据库来存储记忆（如Chroma、Weaviate），或者自定义角色的行为逻辑。这种设计使得项目能够快速适配不同的技术栈和业务需求。

2.2 技术栈选型与架构拆解

基于上述思路，OpenSoul的架构通常包含以下几个核心层，这也是我们理解其运作原理的关键：

1. 角色定义层：这是项目的起点。所有内容都始于一个详细的角色定义文件（可能是YAML、JSON或特定DSL）。这个文件需要精心编写，它不仅仅是“你是一个助手”这么简单。一个高质量的角色定义应包括：

   • 基础身份：姓名、年龄、职业、世界观。
   • 性格特质：外向/内向、乐观/悲观、幽默/严肃等，最好用具体的行为例子来描述（例如，“当用户分享好消息时，你总是先给予热情的祝贺，然后再追问细节”）。
   • 语言风格：常用的口头禅、句式复杂度、是否使用特定领域的行话。
   • 知识与能力边界：明确角色知道什么，不知道什么（例如，“你精通中世纪欧洲史，但对现代科技了解甚少”）。
   • 交互目标：角色与用户互动希望达成的目的（如“提供情感支持”、“教授编程知识”、“进行冒险解谜”）。

2. 记忆管理层：这是项目的“大脑”。它负责角色的长期记忆和短期上下文。

   • 向量数据库：这是实现长期记忆检索的关键技术。所有对话历史、用户透露的关键信息（如“我最喜欢的颜色是蓝色”）、角色自身产生的关键结论，都会被转换成向量（Embedding）存储起来。当新对话发生时，系统会将当前问题也转换成向量，并在数据库中搜索语义上最相关的记忆片段，将其作为上下文注入本次对话。这解决了传统轮次对话只能记住固定长度token的问题。
   • 记忆摘要与提炼：并非所有对话都值得永久记忆。OpenSoul通常会集成一个记忆摘要机制，定期或根据规则将冗长的对话压缩成精炼的要点存入长期记忆，避免数据库膨胀并提升检索质量。

3. 对话引擎层：这是项目的“心脏”。它接收用户输入，结合角色定义和检索到的记忆，构造出最终发送给大模型的提示词。这个提示词的构造是一门艺术，直接决定了AI的回复质量。一个典型的提示词结构可能如下：

   你正在扮演{角色名}，以下是你的设定： {角色详细定义} 以下是你与用户互动的相关记忆，用于指导你本次的回应： {从向量库检索出的相关记忆片段} 当前的对话上下文（最近几轮对话）： {用户：...} {AI：...} {用户：...} 现在，用户对你说：{用户当前输入} 请严格遵循你的角色设定，并自然地回应用户。你的回应应该： 1. 符合你的性格和语言风格。 2. 考虑到上述相关记忆。 3. 推进对话或达成你的交互目标。

4. 大模型接口层：这是项目的“执行者”。它封装了对不同大模型API的调用，处理token计数、流式响应、错误重试等底层细节。OpenSoul的优势在于通过抽象，使上层业务逻辑不依赖于某个特定模型，便于切换和降级。

5. 前端交互层：提供用户与AI角色交互的界面。这可能是一个Web应用、一个聊天插件或一套API。项目通常会提供一个基础的前端示例，开发者可以基于此进行定制。

3. 核心模块深度解析与实操要点

3.1 角色定义：从模糊到精确的“灵魂雕刻”

定义角色是整个项目中最具创造性也最关键的环节。一个模糊的定义会导致AI行为混乱，而一个精确的定义能创造出令人惊叹的沉浸感。

实操要点：编写高质量角色定义文件

不要只写“友好、乐于助人”。要具体化、场景化。

• 示例对比：
  • 差的定义：“你是一个医生，知识渊博。”
  • 好的定义：

    name: “林医生” profession: “三甲医院心内科主任医师，从业20年” personality_traits: - “专业严谨，但在安抚病人时语气温和” - “习惯用通俗易懂的比喻解释复杂的医学概念（比如把血管比作水管，斑块比作水垢）” - “对生命充满敬畏，从不轻易下绝对结论” - “有轻微的强迫症，喜欢把检查单按时间顺序排列整齐” speech_style: “使用‘您’称呼对方，语句完整，偶尔在轻松时会用‘咱们’这个词。解释病情时语速会放慢。” knowledge_base: “精通高血压、冠心病、心力衰竭等心血管疾病的诊断与治疗。对最新的介入手术方案（如PCI）了如指掌。对骨科、儿科等跨科问题仅了解常识，会建议转诊。” goal: “以专业能力解答用户关于心血管健康的疑问，缓解其焦虑，并提供科学的健康建议。” limitations: “不能代替面诊，不能开具处方药。对于紧急症状（如剧烈胸痛），会强烈建议立即拨打急救电话。”

• 注意事项：
  1. 平衡细节与灵活性：定义要详细，但不要过于死板，限制AI的创造性。给予一些核心原则，而非每句话的脚本。
  2. 处理冲突：如果定义中出现矛盾（如“性格开朗”但“不喜与人交谈”），AI会困惑。确保特质之间逻辑自洽。
  3. 迭代优化：角色定义不是一蹴而就的。在测试对话中，观察AI哪些回复“出戏”，然后回头补充或修改定义。这是一个“训练”角色的过程。

3.2 记忆系统：构建角色的“人生经历”

记忆系统让角色真正“活”了过来，不再是一问一答的复读机。

核心机制解析：向量检索与上下文注入

1. 记忆的存储：每次有意义的交互结束后，系统会生成一个“记忆点”。例如，用户说：“我下个月要去巴黎旅行了。” 系统可能生成记忆：“用户计划于[下个月]前往[巴黎]旅行。” 这个文本片段会被一个嵌入模型（如text-embedding-3-small）转换为一个高维向量，然后与会话ID、时间戳等元数据一起存入向量数据库。

2. 记忆的检索：当用户新输入“巴黎有什么推荐的吗？”时，系统首先将此查询转换为向量。然后在向量数据库中进行相似度搜索（通常使用余弦相似度），找出与“巴黎”、“旅行”、“推荐”最相关的记忆片段。检索出的不是完整的原始对话，而是提炼后的记忆点，这样效率更高。

3. 上下文的组装：检索到的记忆点，会与最近的几轮原始对话（短期记忆）以及角色定义一起，被组装进最终发给大模型的提示词中。这相当于给了AI一个包含“我是谁”、“我记得什么”、“我们刚才聊了什么”、“你现在问我什么”的完整简报。

实操心得：提升记忆有效性的技巧

• 记忆的粒度：不要存储整段对话。存储客观事实（“用户养了一只叫‘豆包’的猫”）、用户表达的情绪（“用户对工作感到焦虑”）、以及角色做出的重要承诺或结论（“你答应帮用户查找资料”）。
• 记忆的摘要：对于长对话，定期（如每10轮）用大模型对之前的对话进行摘要，摘要结果作为新的记忆点存入。例如：“在过去十分钟的对话中，用户主要咨询了Python装饰器的用法，你通过‘糖纸包装函数’的比喻进行了讲解，用户表示理解了基本原理。”
• 记忆的衰减与清理：可以为记忆设置“强度”或“新鲜度”字段。不常被提及的记忆随时间衰减，在检索时权重降低。也可以定期清理过于久远或无关的记忆，保持数据库的效率和相关性。

3.3 对话引擎：提示词工程的系统化实践

OpenSoul的对话引擎，是将零散的提示词技巧工程化、自动化的体现。

提示词模板的构建逻辑

引擎内部通常有一个或多个可配置的提示词模板。模板中包含了变量占位符，如{{character_profile}}，{{relevant_memories}}，{{conversation_history}}，{{user_input}}。引擎的工作就是根据当前会话状态，用真实数据填充这些占位符。

高级技巧：思维链（Chain-of-Thought）与角色指令

为了让角色表现更复杂，可以在提示词中引入“思考过程”指令。例如，在最终回复前，要求AI先以内部独白的形式思考：

（请先以“思考：”为开头，分析当前情况：用户情绪如何？你的角色此时会怎么想？基于你的记忆，哪些信息是相关的？你的回复应该达成什么目标？思考完毕后，再以“回应：”为开头，给出最终回复。）

这样虽然会消耗更多token，但能显著提升回复的合理性和角色一致性。在OpenSoul的框架下，这种机制可以被封装成一个可选的“推理模块”。

4. 从零开始搭建与配置实战

假设我们想创建一个“资深茶馆掌柜”的角色，我们将以OpenSoul的典型技术栈为例进行实战演练。

4.1 环境准备与依赖安装

首先，确保你的开发环境已安装Python（建议3.9以上版本）和pip。

# 1. 克隆项目仓库（这里以示例结构说明，实际命令需参考项目README） git clone https://github.com/samttoo22-MewCat/OpenSoul.git cd OpenSoul # 2. 创建并激活虚拟环境（推荐） python -m venv venv # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate # 3. 安装项目依赖 # 通常项目会提供requirements.txt pip install -r requirements.txt # 如果没有，核心依赖可能包括： pip install openai langchain chromadb sentence-transformers fastapi uvicorn

注意：大模型API（如OpenAI）和向量数据库（如Chroma）通常有额外的环境配置要求，如API密钥、本地运行或连接地址，请务必提前查阅其官方文档。

4.2 角色定义文件编写

在项目目录下创建character/tea_master.yaml：

version: "1.0" character: name: “老陈” age: 58 appearance: “精神矍铄，总穿着棉麻唐装，手上一串油亮的紫檀木念珠” personality: core: “温和、睿智、富有耐心，信奉‘茶如人生，细品方知真味’” speech_style: “语速平缓，常用比喻和古语，提到茶时眼睛会发亮。称呼客人为‘您’或‘朋友’。” mannerisms: “说话前常先轻嗅一下茶香，喜欢用‘依老夫看’作为开头。” background: “祖传三代经营‘清心茶馆’，自幼与茶为伴，精通六大茶类工艺与品鉴，游历过中国各大茶山。” knowledge: expertise: ["绿茶（如龙井、碧螺春）的制作与冲泡", "普洱茶的陈化与收藏", "茶道礼仪与历史典故"] limitations: “对咖啡、洋酒了解不多，对现代网络流行语时常感到困惑。” goals: primary: “与来访者分享茶文化，通过一杯茶舒缓其心绪，解答关于茶的任何疑问。” secondary: “偶尔会讲述茶馆里听来的世间百态故事。” sample_dialogues: | 用户：今天好累啊。 老陈：（缓缓斟茶）朋友，累是心弦绷得太紧。来，先尝尝这杯正山小种，它的松烟香最是暖胃安神...（开始讲述红茶发酵的故事）

4.3 核心配置与初始化

创建一个主配置文件config.py或直接在主应用文件中配置：

import os from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain_chroma import Chroma from langchain.memory import VectorStoreRetrieverMemory from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder # 1. 配置大模型和嵌入模型 # 请替换为你的实际API密钥和Base URL（如果使用国内合规平台） os.environ["OPENAI_API_KEY"] = "your-api-key-here" # 如果使用其他模型，例如通过OpenAI兼容接口调用国内模型 llm = ChatOpenAI( model="gpt-4", # 或具体模型名 temperature=0.7, # 创造性，0.7对于角色扮演比较合适 streaming=True # 支持流式输出，体验更好 ) embeddings = OpenAIEmbeddings(model="text-embedding-3-small") # 2. 初始化向量数据库（用于记忆存储） persist_directory = "./chroma_db" vectordb = Chroma( collection_name="tea_master_memories", embedding_function=embeddings, persist_directory=persist_directory ) # 创建检索器，用于从向量库查找相关记忆 retriever = vectordb.as_retriever(search_kwargs={"k": 3}) # 每次检索3条最相关的记忆 # 3. 构建记忆系统 memory = VectorStoreRetrieverMemory( retriever=retriever, memory_key="chat_history", input_key="human_input" ) # 4. 定义提示词模板 # 这里融合了角色定义、记忆和对话历史 prompt_template = ChatPromptTemplate.from_messages([ ("system", """ 你是{character_name}，一位{character_background}。 你的性格是：{character_personality}。 你的说话风格是：{speech_style}。 你的知识和能力范围：{knowledge_expertise}。你的局限是：{knowledge_limitations}。 你的目标是：{character_goals}。 以下是你过去与用户互动中记住的一些事情（可能与当前对话相关）： {relevant_memories} 请基于以上所有信息，以{character_name}的身份和口吻进行回应。 """), MessagesPlaceholder(variable_name="chat_history"), # 这里会自动填充最近的对话历史 ("human", "{human_input}"), ])

4.4 构建对话链与运行

将以上组件串联起来，形成一个完整的对话链：

from langchain.chains import LLMChain from langchain.memory import ConversationBufferWindowMemory # 加载角色定义（这里简化处理，实际应从YAML文件读取） with open("character/tea_master.yaml", 'r', encoding='utf-8') as f: import yaml char_config = yaml.safe_load(f) char = char_config['character'] # 短期记忆：保存最近几轮对话，确保上下文连贯 conversation_memory = ConversationBufferWindowMemory( memory_key="chat_history", k=5, # 保留最近5轮对话 return_messages=True ) # 创建LLMChain，它是LangChain的核心抽象，将提示词、模型、记忆组合在一起 chain = LLMChain( llm=llm, prompt=prompt_template, memory=conversation_memory, # 注意：这里我们主要用短期记忆，长期记忆通过`relevant_memories`变量在prompt中手动注入会更清晰。更复杂的集成需要自定义Chain。 verbose=True # 调试时打开，可以看到链的思考过程 ) # 模拟一次对话 # 首先，处理长期记忆：将当前用户输入转换为向量，并检索相关记忆 query = “我上次来你说要教我泡龙井，今天有空吗？” relevant_docs = retriever.get_relevant_documents(query) relevant_memories_text = "\n".join([doc.page_content for doc in relevant_docs]) # 准备输入，这里需要手动将长期记忆和角色定义填入变量 input_variables = { "character_name": char['name'], "character_background": char['background'], "character_personality": char['personality']['core'], "speech_style": char['personality']['speech_style'], "knowledge_expertise": ", ".join(char['knowledge']['expertise']), "knowledge_limitations": char['knowledge']['limitations'], "character_goals": char['goals']['primary'], "relevant_memories": relevant_memories_text, "human_input": query } # 注意：`chat_history`变量会由ConversationBufferWindowMemory自动从memory中加载 response = chain.invoke(input_variables) print(f"老陈：{response['text']}") # 对话结束后，将本次交互的关键信息存入长期记忆向量库 # 这是一个简化示例，实际应用中需要更智能的记忆提炼 memory_text_to_save = f"用户曾表示想学习冲泡龙井茶。" vectordb.add_texts( texts=[memory_text_to_save], metadatas=[{"session_id": "session_001", "type": "user_intention"}] ) vectordb.persist() # 持久化到磁盘

4.5 搭建简易Web接口（可选）

为了让角色能通过网络提供服务，可以使用FastAPI快速搭建一个API：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import uvicorn app = FastAPI(title="OpenSoul - 茶馆掌柜API") class ChatRequest(BaseModel): message: str session_id: str = “default” class ChatResponse(BaseModel): reply: str session_id: str @app.post("/chat", response_model=ChatResponse) async def chat_with_tea_master(request: ChatRequest): try: # 这里应集成上述完整的对话链逻辑 # 1. 根据session_id加载或创建对应的记忆和对话历史 # 2. 处理用户输入，检索记忆，调用LLMChain # 3. 保存新的记忆和对话历史 # 4. 返回AI回复 # 此处为模拟逻辑 processed_reply = f“（老陈）嗯，{request.message}... 此事说来话长，且听老夫慢慢道来。”（此处应替换为真实chain调用） return ChatResponse(reply=processed_reply, session_id=request.session_id) except Exception as e: raise HTTPException(status_code=500, detail=str(e)) if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0", port=8000)

运行后，你就可以通过http://localhost:8000/docs访问交互式API文档，并通过POST请求与你的AI茶馆掌柜对话了。

5. 常见问题、调试技巧与优化实录

在实际部署和调试OpenSoul这类项目时，会遇到一些典型问题。

5.1 角色“人设崩塌”或回复不符合预期

这是最常见的问题，表现为AI突然用官方助手口吻说话，或者做出不符合角色设定的行为。

排查思路与解决方案：

1. 检查提示词注入：首先，打开链的verbose=True模式，查看实际发送给大模型的完整提示词。确认角色定义、记忆、历史对话是否被正确格式化并包含在内。常见错误是特殊字符（如引号、换行）未正确转义，导致提示词结构混乱。
2. 审视角色定义：定义是否过于宽泛或存在内在矛盾？尝试将定义写得更具体、更具场景化。例如，将“善良”改为“看到受伤的小动物会想办法帮助，但自己怕猫”。
3. 调整Temperature参数：temperature控制输出的随机性。值太低（如0.1）会导致回复机械、重复；值太高（如1.0）会导致角色不稳定、胡言乱语。对于角色扮演，0.7~0.9是一个不错的起点。
4. 系统指令的强度：有些大模型对系统指令（systemmessage）的遵循程度高于用户指令。确保你的角色定义放在系统指令中。如果模型支持，可以尝试设置system_fingerprint或使用角色专用的模型变体。

5.2 记忆检索不准确或无关

表现为AI“忘记”了之前的重要信息，或者检索到的记忆风马牛不相及。

排查与优化：

1. 嵌入模型选择：不同的嵌入模型对中文、专业术语的语义理解能力差异很大。如果主要处理中文，可以考虑使用专门针对中文优化的嵌入模型，如BAAI/bge-large-zh。
2. 记忆文本的预处理：存入向量库的记忆文本质量至关重要。避免存入过长的、包含无关信息的句子。在存入前，可以先用大模型对原始对话进行一轮摘要和提炼，只存储核心事实和情感。
3. 检索策略调优：
   • 调整k值：search_kwargs={“k”: 3}中的k是检索数量。太小可能遗漏关键信息，太大会引入噪声。根据场景调整。
   • 使用MMR（最大边际相关性）：在检索时使用MMR算法，可以在保证相关性的同时，增加记忆的多样性，避免返回三条几乎一样的记忆。
   • 元数据过滤：为每条记忆添加丰富的元数据，如memory_type（fact,user_emotion,character_promise）、timestamp、importance_score。检索时，可以结合语义搜索和元数据过滤，例如：“只检索memory_type为fact且importance_score大于0.5的记忆”。
4. 记忆的“遗忘”机制：实现一个简单的衰减机制。每次记忆被成功检索并用于生成回复后，可以增加其“强度”或“新鲜度”分数。定期运行一个后台任务，降低所有记忆的分数，并删除分数低于阈值的记忆。这模拟了人类的遗忘曲线。

5.3 响应速度慢或成本过高

随着对话历史增长，提示词会越来越长，导致API调用慢、token消耗大、成本激增。

性能优化实战：

1. 记忆摘要的常态化：不要无限制地存储原始对话。实现一个摘要触发器。例如，当一轮对话的token数超过500，或者对话轮次达到10轮，就自动触发摘要。用大模型生成一段简洁的段落总结核心信息，然后将这段摘要作为一条新的记忆存入，并可以考虑清空或归档对应的原始短时对话历史。
2. 分层记忆系统：设计短期、中期、长期三层记忆。
   • 短期：保存在对话缓冲区内，用于维持当前会话的连贯性（最近5-10轮）。
   • 中期：存入向量数据库，保存几天或几周内的重要交互事实和情感。
   • 长期：存储角色核心设定和用户最关键的身份信息（如用户名、长期偏好），这些信息不常变动，可以放在普通数据库或配置文件中，无需每次检索。
3. 选择性上下文注入：不是所有检索到的记忆和所有历史对话都需要放入提示词。可以设计一个“相关性评分”阈值，只注入评分高于阈值的记忆。对于历史对话，可以只保留最近几轮，或者用摘要代替完整历史。
4. 模型的选择与降级：在非关键路径上使用更小、更快的模型。例如，用gpt-3.5-turbo来处理记忆摘要生成、用text-embedding-3-small来生成向量。只有在最终生成角色回复时，才使用能力更强但也更贵的gpt-4。

5.4 扩展性与定制化

当你想为角色增加更多能力时，OpenSoul的模块化设计就显现出优势。

为茶馆掌柜增加“知识库查询”功能：

假设我们想让老陈不仅能聊天，还能准确回答不同茶叶的具体冲泡水温、时间。

1. 创建知识库：整理一个结构化的茶叶知识CSV或JSON文件。
2. 集成检索增强生成（RAG）：
   • 将知识库文档切片并向量化，存入另一个专门的向量集合（Collection）中。
   • 在对话链中，当检测到用户问题可能涉及具体知识（例如包含“水温”、“克数”、“冲泡时间”等关键词）时，同时触发对这个知识库向量集的检索。
   • 将检索到的专业知识片段，作为额外的上下文，与角色定义、记忆一起注入提示词。可以在提示词中明确指示：“以下是关于茶叶冲泡的专业知识，请参考并融入你的回答：[检索到的知识片段]”。
3. 处理信息冲突：如果角色设定中的常识与知识库中的专业信息冲突，需要在提示词中设定优先级。通常可以指定“当涉及具体数据时，以提供的专业知识为准”。

通过这样的扩展，老陈就从一位“泛泛而谈”的掌柜，变成了一位拥有精准数据库的“茶博士”。这种将角色扮演与RAG结合的模式，非常适合打造专业的虚拟顾问、客服或教师角色。

整个项目实践下来，最大的体会是，创造一个生动的AI角色，技术只占一半，另一半是精心的“人设”雕刻和持续的“调教”。它就像在数字世界养育一个孩子，你需要通过清晰的规则（角色定义）、丰富的经历（记忆系统）和正确的引导（提示词工程）来塑造它。OpenSoul这类框架的价值，在于将其中可工程化的部分标准化、自动化，让我们能把更多精力投入到创造角色灵魂本身这件更有趣的事情上。