企业官网建设流程全解析

同样一款 AI 办公助手，有人装完就变成了“效率外挂”，有人装完只用了一周就扔在角落，最后得出一个结论：这工具也就那样。差距到底出在哪里？大多数情况下，不是模型不够强，也不是软件本身有缺陷，而是装好之后缺少一轮关键设置。很多 AI 办公助手刚部署完毕，默认配置只能保证“能跑”，离“好用”还有很长一段距离。如果你也遇到过回答不贴合业务、知识库检索不到重点、权限混乱、频繁超时这些问题，这篇文章值得完整看一遍。下面围绕 AI 办公助手安装后必须做的 10 项设置展开，从模型接入、参数调优、知识库配置、提示词设计，到工具调用、权限安全、日志监控，逐步讲清楚每一项为什么重要，以及具体怎么做。

1. 为什么 AI 办公助手装完以后还要“设置 10 点”

1.1 先搞清楚 AI 办公助手到底是什么

这里说的“AI 办公助手”，不是简单的网页版聊天机器人，而是集成在个人工作流里的 AI 应用。它通常由几个部分组成：大语言模型 API、知识库、提示词系统、工具调用能力，以及能与办公系统对接的接口。常见的形态包括企业内部的 AI 问答机器人、个人知识库助手、会议纪要生成工具、文档自动处理脚本等。

它的核心价值在于把“通用大模型能力”和“你的私有数据、办公流程”结合起来。比如你问助手“上季度项目总结在哪”，如果它没有接入你的知识库或文档系统，它就只能说一句“我无法访问你的文件”。而配置完善的 AI 办公助手，能检索本地文档、调用日程接口、读取邮件摘要，再基于大模型生成答案。这也解释了为什么同样是 AI 工具，别人用起来像私人助理，你用起来像“复读机”。

1.2 默认配置为什么不够用

安装完成后的默认状态，一般只解决了“能调用模型”这个最基础的问题。此时它的行为特征是：回答依赖模型通用知识、没有业务上下文、不知道你的文档在哪里、无法操作办公软件、对敏感信息没有过滤能力。在真实办公场景中，用户提问往往是模糊的、多轮的，而且涉及大量内部术语和私有数据。默认配置无法处理这些需求，于是你很快会感受到“不好用”。

很多初次接触 AI 办公助手的用户，会把这归因于“AI 技术还不够成熟”。实际上，根源往往是没有做好安装后的初始设置。搜索阈值、知识库切片长度、提示词模板、超时重试参数、权限隔离，每一项都会直接影响最终效果。举例来说，同样一个问题，提示词写得好不好，答案质量可能差一个档次；知识库的切片粒度设置不当，检索出的片段要么太长要么太碎，答案自然不准确。

1.3 10 项设置分别解决什么问题

为了便于理解和落地，我把安装后需要重点处理的设置项划分为 10 项，分别覆盖三个维度：模型与调用、知识与人设、安全与体验。

后面的章节会按照这个清单逐项展开。你可以根据自己的项目阶段挑选设置项，但从整体体验来看，前 6 项属于“提升能力”，后 4 项属于“保障可靠”，建议全部过一遍。

2. 环境准备与基础架构

2.1 运行环境与版本说明

在开始设置之前，先确认运行环境。AI 办公助手的部署方式很多，可以是服务器上的后端服务，也可以是本地运行的脚本工具。本文以“Python 后端服务 + 大模型 API + 向量数据库”这套常见组合为例展开，涵盖配置文件和核心代码。具体版本需要根据你的项目实际情况调整，重点演示配置思路，而不是锁定某一个版本。

建议使用的环境包括：

• 操作系统：Windows 10/11、macOS 或 Linux 均可。
• Python 版本：3.9 及以上，推荐 3.10 或 3.11。
• 大模型 API：任何兼容 OpenAI Chat Completions 接口的服务。
• 向量数据库：Chroma、Milvus 或 Qdrant 均可，本地测试优先选择 Chroma。
• 办公系统对接：以通用 HTTP API 或 Webhook 方式接入企业微信、钉钉、飞书、邮件系统等。

如果你的项目不是 Python 技术栈，例如使用 Node.js 或 Java，也没有关系。本文大部分设置项是思路层面的，代码示例可以直接迁移到相应的 HTTP 调用逻辑中。

2.2 项目结构示例

一个结构清晰的项目，能帮助你在后续设置中快速定位文件和配置。这里给出一个最小可扩展的目录结构，你可以根据实际项目增删。

ai-office-assistant/ ├── config/ │ ├── config.yaml │ └── .env.example ├── knowledge_base/ │ ├── docs/ │ └── embeddings/ ├── src/ │ ├── main.py │ ├── settings.py │ ├── prompts/ │ │ └── default_system_prompt.txt │ ├── tools/ │ │ ├── meeting.py │ │ └── mail.py │ └── utils/ │ ├── logger.py │ └── filter.py ├── logs/ └── requirements.txt

config目录保存所有配置，knowledge_base存放知识库文档和向量索引，src里按模块拆分代码。把配置和代码分离，是后续做权限管理、多环境部署、参数调优的前提。

2.3 基础配置文件的统一管理

不管功能多复杂，建议把所有可变参数统一放在一个配置文件中。这样做的好处是：模型升级时不用改代码，办公系统地址变化时不用重新发布服务，不同团队使用不同参数时也只需切换配置。

下面是一个基础的 YAML 配置示例，后续的 10 项设置会围绕它逐步扩展。

# 文件路径：config/config.yaml model: provider: openai_compatible api_base: https://api.example.com/v1 api_key_env: AI_ASSISTANT_API_KEY model_name: gpt-4o-mini temperature: 0.3 max_tokens: 2048 request_timeout: 30 retry: max_retries: 3 backoff_base: 2.0 knowledge_base: chunk_size: 800 chunk_overlap: 100 embedding_model: text-embedding-3-small vector_store: chroma search_top_k: 5 security: sensitive_filter: true log_level: INFO data_retention_days: 30 office: calendar_api: https://office.example.com/api/calendar im_webhook: https://office.example.com/webhook/im

此外，API 密钥这类敏感信息不要直接写在 YAML 文件里，应该通过环境变量注入。项目里可以提供一个.env.example文件，只写键名，不放真实密钥。

# 文件路径：config/.env.example AI_ASSISTANT_API_KEY=sk-your-key-here OFFICE_API_TOKEN=your-office-token

在实际运行时，通过load_dotenv()或系统环境变量把配置项加载到代码中，这样就避免了密钥泄漏到代码仓库的风险。

3. 第 1 项到第 3 项：模型接入、参数调优与调用稳定

3.1 第 1 项：模型接入方式与密钥管理

第一项设置解决的是“助手用哪个模型、怎么连接模型服务”的问题。常见做法是把模型 API 的地址、模型名称、密钥环境变量统一写入配置。为什么强调密钥管理？因为很多初学者喜欢直接把 API Key 写死在代码里，然后代码提交到 Git 仓库，最后密钥泄露产生费用，这是 AI 办公助手项目中最常见的低级事故。

推荐的做法是：代码中只读取配置项，不出现任何明文密钥。下面是一个通过环境变量加载配置并调用模型接口的 Python 示例。

# 文件路径：src/main.py import os import requests from dotenv import load_dotenv import yaml load_dotenv("config/.env") with open("config/config.yaml", "r", encoding="utf-8") as f: config = yaml.safe_load(f) def call_llm(messages, config): """调用兼容 OpenAI Chat Completions 接口的模型服务""" url = f"{config['model']['api_base']}/chat/completions" headers = { "Authorization": f"Bearer {os.getenv(config['model']['api_key_env'], '')}" } payload = { "model": config["model"]["model_name"], "messages": messages, "temperature": config["model"]["temperature"], "max_tokens": config["model"]["max_tokens"], } try: response = requests.post( url, json=payload, headers=headers, timeout=config["model"]["request_timeout"] ) response.raise_for_status() return response.json()["choices"][0]["message"]["content"] except Exception as e: return f"调用失败：{e}" if __name__ == "__main__": messages = [{"role": "user", "content": "你好，请介绍一下你自己"}] result = call_llm(messages, config) print(result)

这个例子里，模型服务地址、模型名、密钥环境变量名都来自配置。换模型时只需要修改config.yaml，不需要动代码。要注意的是，不同模型服务商对接口路径和参数支持程度不同，示例思路需要按实际版本调整。

3.2 第 2 项：生成参数设置

生成参数是影响回答质量最直接的因素。常见的参数包括：

• temperature：控制随机性，值越低回答越保守、越稳定；值越高回答越发散、越有创造性。
• max_tokens：限制单次回答的最大 token 数。
• top_p：核采样参数，通常与 temperature 二选一即可，不建议同时大幅调整。
• presence_penalty 和 frequency_penalty：控制重复内容的惩罚，办公摘要场景可以适当调高。

在办公场景中，我的建议是：知识库问答、数据整理、邮件撰写这类任务，temperature 设置在 0.2 到 0.4 之间较为合适。如果你希望助手有更多“灵感型”输出，例如头脑风暴、文案策划，再把 temperature 提高到 0.7 到 0.9。不要所有任务都使用同一个参数，最好在配置中针对不同场景预置多组参数模板。

# 在 config.yaml 中增加场景参数模板 scenes: qa: temperature: 0.2 max_tokens: 1024 top_p: 0.9 summary: temperature: 0.3 max_tokens: 2048 creative: temperature: 0.8 max_tokens: 2048

为什么强调这一项？因为默认参数往往是通用场景的折中值。如果办公助手负责的是报销政策问答，temperature 太高就可能导致它“自由发挥”，编造不合规的内容。稳定性和可预期性，在办公场景里比创造性更重要。

3.3 第 3 项：超时、重试与降级策略

模型接口不稳定，是办公助手“看起来不好用”的另一个高频原因。模型服务可能因为网络波动、并发过高、参数超限等原因返回错误。如果不做超时和重试，用户使用过程中随时可能看到长时间转圈或者直接报错。

超时和重试的核心思想是：第一次请求失败后，不要立刻放弃，而是间隔一段时间再试；如果多次重试仍然失败，则返回降级提示，而不是把堆栈信息直接抛给用户。前文config.yaml中已经定义了max_retries和backoff_base，下面是基于这个配置的重试逻辑。

# 文件路径：src/main.py（重试部分） import time def call_llm_with_retry(messages, config): url = f"{config['model']['api_base']}/chat/completions" headers = { "Authorization": f"Bearer {os.getenv(config['model']['api_key_env'], '')}" } payload = { "model": config["model"]["model_name"], "messages": messages, "temperature": config["model"]["temperature"], "max_tokens": config["model"]["max_tokens"], } for attempt in range(1, config["retry"]["max_retries"] + 1): try: response = requests.post( url, json=payload, headers=headers, timeout=config["model"]["request_timeout"] ) response.raise_for_status() return response.json()["choices"][0]["message"]["content"] except Exception as e: if attempt == config["retry"]["max_retries"]: return f"服务暂时不可用，请稍后再试。技术原因：{type(e).__name__}" wait_time = config["retry"]["backoff_base"] ** attempt time.sleep(wait_time) return "服务暂时不可用，请稍后再试"

每次重试的等待时间会成倍增加，避免在接口恢复前集中重试导致雪崩。实际项目中还可以把模型调用结果缓存起来，对于相同问题在短时间内直接返回历史答案，进一步降低接口压力。

4. 第 4 项到第 6 项：知识库、记忆与提示词

4.1 第 4 项：知识库文档准备与切片

办公助手好不好用，很大程度上取决于它能不能回答“只有你公司内部才知道”的问题。知识库的作用就是把内部文档、制度、项目资料导入到向量数据库中，让模型在回答前先检索相关内容。

知识库建设的第一个关键动作是文档清理。先梳理现有文档，删除过期版本、临时草稿、敏感密级文件。不要一上来把所有资料都灌进去，否则检索噪声会很大。第二个关键动作是切片。长文档不能直接交给模型，因为模型上下文有限，而且检索粒度太粗。通常先把文档拆成 500 到 1000 字左右的片段，相邻片段保留少量重叠，避免关键信息被切断。

# 知识库相关配置 knowledge_base: chunk_size: 800 chunk_overlap: 100 embedding_model: text-embedding-3-small vector_store: chroma search_top_k: 5

chunk_size表示每个切片的长度，chunk_overlap表示相邻切片的重叠长度。如果你的文档主要是不超过 300 字的制度条款，切片长度可以缩小到 400；如果是长篇项目报告，可以调整到 1000 左右。这个值需要根据实际检索效果反复测试，而不是照搬某一套参数。切片之后，还需要为每个切片生成向量索引，这样用户在提问时，系统才能快速找到语义上最相关的片段。

4.2 第 5 项：对话上下文与长期记忆策略

多轮对话中常见的尴尬是：上一轮你刚告诉助手“我们部门叫市场部”，下一轮它又忘了。这个问题出在上下文管理策略上。不同办公场景对上下文的需求不同：

• 单轮问答场景：例如查政策、查价格，不需要长记忆。
• 连续任务场景：例如帮我整理会议纪要、列待办、发邮件，需要记住本轮前面的意图。
• 长期偏好记忆：例如你希望助手回复时使用简洁风格，这更适合用提示词固定下来，而不是依赖对话记忆。

实现时，一种做法是手动维护消息列表，把最近几轮对话都传给模型；另一种做法是按会话维度存储消息历史，定期清理超过窗口长度的消息。前者适合简单工具，后者适合正式系统。这里给出一个简单的上下文管理思路。

# 文件路径：src/utils/context.py MAX_HISTORY = 10 def build_messages(user_message: str, history: list, system_prompt: str) -> list: """把系统提示词、历史消息和当前问题拼装为完整的 messages""" messages = [{"role": "system", "content": system_prompt}] messages.extend(history[-MAX_HISTORY:]) messages.append({"role": "user", "content": user_message}) return messages

MAX_HISTORY需要根据模型上下文窗口和单次回答长度来定，不是越大越好。如果历史消息太多，会挤占当前回答的空间，还会增加费用和响应时间。办公场景中，保留最近 5 到 10 轮对话通常已经足够。

4.3 第 6 项：System Prompt 与角色模板

很多助手“答非所问”或“语气奇怪”，问题往往出在提示词上。System Prompt 是模型的行为基调，它决定了助手以什么角色、什么语气、按什么结构回答问题。办公场景的 System Prompt 至少需要包含以下信息：角色定位、服务范围、输出风格、禁止行为。

下面是一个适合内部知识问答助手的 System Prompt 示例。

# 文件路径：src/prompts/default_system_prompt.txt 你是公司内部的 AI 办公助手，主要帮助员工完成以下工作： 1. 查询内部制度、流程和项目信息。 2. 整理会议纪要、总结文档、撰写邮件草稿。 3. 查询日程、会议和公共节假日信息。 回答要求： - 用简洁的中文回答，重要信息分点说明。 - 如果知识库中没有对应信息，明确回答“未找到相关信息”，不要编造制度内容。 - 涉及日期、金额、部门名称时，必须和知识库原文保持一致。 - 如果用户提出与办公无关的问题，礼貌说明你只处理办公相关事务。 禁止行为： - 不要输出内部敏感信息，例如个人身份证号、银行账号。 - 不要提供违反公司信息安全规范的建议。

为什么 System Prompt 要单独保存为文件？因为办公助手的提示词会被反复调整，单独保存方便版本管理。后续每次优化提示词，都可以记录改动内容和效果。需要提醒的是，提示词不是写得越长越好，过长反而会消耗 token，且容易让模型困惑。核心是把边界讲清楚，把高频要求固化下来。

5. 第 7 项到第 8 项：工具调用与办公系统集成

5.1 第 7 项：Function Calling 打通办公工具

办公助手的上限，取决于它能做什么，而不仅仅是能说什么。如果助手只能“回答文字”，那它本质上还是个聊天机器人；如果能帮你查日程、发消息、创建审批，那才叫办公助手。

Function Calling 是让模型根据用户意图，输出结构化调用参数的机制。例如用户说“帮我约明天上午 10 点的会议室”，模型经过判断后，返回一个调用函数，而不是直接生成一段“好的我帮你约了会议室”的假响应。你的系统再去调用真实会议室系统的 API，拿到结果后返回给用户。

# 文件路径：src/tools/meeting.py def create_meeting(date: str, duration: int, topic: str) -> str: """模拟创建会议的办公集成接口""" # 实际项目这里应该调用会议室预订系统 API return f"已创建会议：{topic}，日期 {date}，时长 {duration} 分钟" tools_definitions = [ { "type": "function", "function": { "name": "create_meeting", "description": "创建会议日程", "parameters": { "type": "object", "properties": { "date": {"type": "string", "description": "会议日期，格式 YYYY-MM-DD"}, "duration": {"type": "integer", "description": "会议时长，单位分钟"}, "topic": {"type": "string", "description": "会议主题"} }, "required": ["date", "duration", "topic"] } } } ]

在实际调用时，系统会先判断模型是否要求调用函数，如果要求，则解析参数并执行；执行完成后，再把函数结果追加到消息中，让模型生成最终回复。这个流程能极大扩展助手的实用性。不过要注意，调用办公系统接口前必须确认权限，例如某个用户是否有会议室预订权限，或者某个部门是否能发起审批，不能把接口暴露给所有调用者。

5.2 第 8 项：定时任务与自动触发

优秀的办公助手不应该只会“等待提问”，它还应该具备主动提醒能力。例如每天早上推送当日日程安排，每周五生成周报草稿，项目截止日期前自动提醒相关人等。实现方式可以是系统的定时任务，也可以是消息平台的事件订阅。

定时任务的核心是规则配置。比较简单的做法是使用schedule库或系统cron任务；正式系统建议使用单独的调度服务。下面是一个简单的定时任务示例，展示了如何每天早上 9 点生成当日日程摘要。

# 文件路径：src/tasks/daily_digest.py import schedule import time def send_daily_digest(): """模拟推送当日日程摘要""" digest_content = "今日日程：上午 10:00 项目评审会；下午 14:30 产品周会。" # 实际项目这里调用企业微信 / 钉钉 / 飞书机器人接口推送 print(digest_content) schedule.every().day.at("09:00").do(send_daily_digest) while True: schedule.run_pending() time.sleep(60)

定时任务需要关注失败重试和重复推送问题。比如某个时间段任务执行失败，重新调度时不能重复发送同样内容。建议把每次推送的唯一标识存入数据库，执行前先检查是否已经推送过。

6. 第 9 项到第 10 项：权限、安全与体验优化

6.1 第 9 项：权限隔离与敏感信息过滤

把 AI 办公助手接入企业办公系统之后，安全就是第一优先级。一个常见的错误是：所有员工都能让助手查询所有同事的日程、所有项目的预算、所有客户的信息。这在内部系统中属于越权行为。正确的做法是“最小权限原则”，每个用户调用办公助手时，系统根据其身份和角色限制可访问的数据范围。

权限隔离的实现，通常是在请求处理层获取当前用户 ID、部门 ID 和角色，然后在工具调用时把权限参数一并传入。知识库检索也要做隔离，不同部门的文档需要设置访问级别，不能让所有模型调用都检索全部资料。例如检索 SQL 或向量库时，根据用户角色增加过滤条件。

在多用户系统中，还要注意对话记录的数据隔离。A 员工的对话历史不能让 B 员工看到，日志中不能记录完整的敏感内容。敏感的身份证号、手机号、银行账号在进入模型之前就应该被脱敏处理，最常见的做法是正则替换或调用专用脱敏工具。

# 文件路径：src/utils/filter.py import re def mask_sensitive(text: str) -> str: """对手机号和身份证号做简单脱敏处理""" # 手机号脱敏：保留前3位和后4位 text = re.sub(r'1[3-9]\d{9}', lambda m: m.group(0)[:3] + "****" + m.group(0)[-4:], text) # 身份证号脱敏：保留前4位和后4位 text = re.sub(r'\d{17}[\dXx]', lambda m: m.group(0)[:4] + "***********" + m.group(0)[-4:], text) return text

注意，脱敏并不是万能的。如果大模型本身在训练数据中包含某些公开信息，它仍可能生成这些内容；这里的重点是防止企业内部私有数据通过日志或回答泄露。生产环境部署时，还应对用户提交给模型的内容做安全审计，保留调用记录，并设置数据保留期限。

6.2 第 10 项：日志、反馈与体验优化

最后一项设置经常被忽略，但恰恰是“别人的助手越用越好用”的原因：它们有反馈闭环。建议从第一天就记录两类日志：一类是系统日志，用于排查错误；另一类是业务日志，用于统计哪些问题被高频提问、哪些回答被用户点赞点踩。

系统日志可以使用 Python 自带的logging模块，输出到文件，并按日期滚动。下面是一个基础配置。

# 文件路径：src/utils/logger.py import logging from logging.handlers import TimedRotatingFileHandler LOG_FILE = "logs/ai_assistant.log" handler = TimedRotatingFileHandler( LOG_FILE, when="midnight", backupCount=30, encoding="utf-8" ) logging.basicConfig( level=logging.INFO, format="%(asctime)s - %(name)s - %(levelname)s - %(message)s", handlers=[handler] )

业务反馈则是用户在回答下方的“点赞/点踩”按钮，或者“提交纠错意见”入口。每一条负面反馈都应该归档，定期分析，然后倒推到知识库、提示词或检索参数中进行优化。例如发现多个用户反馈“找不到报销流程文档”，你就应该检查报销文档是否已经导入知识库、切片是否合理、检索排序是否靠前。

7. 常见问题与排查思路

7.1 高频问题汇总表

7.2 三个典型排查场景

第一个典型场景是“助手回答的内容和公司制度不一样”。优先检查知识库中的制度文档是否是最新版，然后检查向量检索是否命中了正确片段。可以在排查时增加调试开关，输出命中的文档片段和相似度分数，快速定位是知识库数据的问题还是检索参数的问题。

第二个典型场景是“助手偶尔能用、偶尔报错”。这时候优先看模型接口调用日志，判断报错类型是超时、限流还是参数非法。如果是限流，考虑降低并发、增加缓冲队列或升级 API 额度；如果是超时，则调整超时时间和重试策略。记住不要一上来就换模型，先确认是接口稳定性问题还是代码问题。

第三个典型场景是“权限基本没生效”。排查思路很简单：用一个普通测试账号去调用敏感接口，观察请求日志中是否有权限参数。如果日志里完全没有用户身份信息，说明权限控制在入口请求阶段就没接好。此时需要回到前置过滤器或拦截器，确认认证信息已经透传给下层工具调用。

8. 最佳实践与工程建议

8.1 设置项统一走配置中心

当 AI 办公助手接入的办公场景变多后，建议把配置从 YAML 文件迁移到统一配置中心，例如 Apollo、Nacos 或 Spring Cloud Config。每次调整模型参数、知识库参数、风控阈值时，不需要重新发布服务，可以在线修改并热生效。配置中心还能做环境隔离，区分开发、测试、生产环境，避免把测试环境的参数带到线上。

如果项目规模不大，使用 git 管理配置文件也可以，但要注意密钥和环境变量必须分离。生产环境建议做到“配置可回滚、变更留痕、授权操作”，尤其是涉及模型 API Key、办公系统 Token 这类敏感配置时，应限制可修改人员。

8.2 变更前先备份与灰度

AI 办公助手的很多设置项看起来只是改参数，实际上影响面很大。比如修改知识库切片策略后，可能需要重新生成向量索引；修改 System Prompt 后，所有回答风格都会变化。因此，任何设置变更都建议先在测试环境验证，再逐步灰度到部分用户，观察一段时间后再全量生效。

对于知识库更新，不要直接覆盖旧文档，建议保留历史版本。万一某次导入的文档格式有问题，导致检索结果整体变差，可以快速回滚。对于提示词，建议像代码一样做版本管理，在文件头部记录变更作者、变更时间和变更目的。

8.3 持续收集反馈迭代

AI 办公助手不是安装完成就结束的软件，它更像一个需要持续调校的业务系统。真正好用的助手，背后一定有一组持续优化的数据：哪些问题答得好、哪些问题答得差、哪些功能从来没人用、哪些接口频繁报错。把反馈数据纳入周度或月度复盘，把优化项排入迭代计划，这个闭环才是“别人的助手更好用”的底层原因。

9. 总结：装好之后，这 10 项设置才是分水岭

回到一开始的问题：为什么别人的 AI 办公助手更好用？答案不在于别人用了某个超级模型，而在于别人把安装后的设置当作一项正经工程来对待。模型接入、参数调优、超时重试、知识库建设、提示词设计、工具调用、权限过滤、日志反馈，每一环都影响着最终体验。如果你刚部署好助手，建议从第 1 项到第 3 项开始，先把模型调用层做稳；再处理知识库和提示词，让回答更专业；最后做权限和反馈闭环，让工具能安全地用起来、持续地变好用。按照这 10 项逐一配置，即使你用的是同一款模型，办公助手的使用体验也会明显不一样。下一步可以继续深入学习检索增强生成、多 Agent 协作和复杂工作流编排，这些都是在基础设置完成后值得探索的方向。