AI办公落地实战：从RAG技术架构到内部文档知识问答系统搭建

近年来，AI办公从一个“锦上添花”的演示功能，逐步变成许多企业真正愿意投入资源去建设的效率基础设施。与此同时，以百度为代表的国内厂商在搜索技术、自然语言处理、大模型平台和协同办公入口上的持续投入，也让“AI办公”这个词不再停留在概念层面，而是开始落到具体的工作流、文档处理和自动化任务中。

本文不打算做厂商站台式的分析，而是从技术视角拆解AI办公的底层能力，梳理一套可以落地到企业内部的AI办公技术框架，并用一个可运行的实战项目带你从零搭建一个“文档知识问答助手”。无论你是在做内部效率工具，还是规划企业AI办公底座，这篇文章都能提供一个清晰的技术参照。

读完后你会掌握：AI办公与传统自动化的本质区别、一套通用AI办公技术架构、基于大模型API的检索增强问答实现方式，以及企业在落地AI办公时的常见坑点和实施路径。

1. AI办公为什么值得提前布局

1.1 AI办公不是“加一个ChatGPT窗口”

很多团队对AI办公的理解是：给员工开通一个大模型聊天入口，让它帮忙写周报、改写邮件、生成PPT大纲。这种做法不是没有价值，但它只停留在“对话式工具”的层面，距离稳定的办公效率提升还有明显差距。

真正的AI办公，应该具备三个特征：

• 能连接业务数据。模型不是空谈，而是能读取你的项目文档、会议纪要、客户记录和内部制度。
• 能嵌入工作流。AI不是独立存在的网页，而是出现在审批、日报、客服、文档协作等真实任务链路中。
• 能沉淀和复用。一次问答产生的知识修正，可以回流到知识库或模型评测集，让系统越用越准。

从这个角度理解，提前布局AI办公的“提前”，本质上是在提前完成三件事：数据资产的结构化、办公流程的标准化、AI能力的接口化。

1.2 企业和开发者分别应该准备什么

从企业视角看，提前布局的核心不是采购多少AI产品，而是把数据和流程准备好。很多企业引入AI办公后发现效果不如预期，常见原因不是模型能力不够，而是内部文档散落在各个系统里，格式不统一，权限不清晰，甚至没有可用的API。

从开发者视角看，AI办公带来的机会集中在三类技能需求：

• Prompt工程与智能体编排。
• 文档解析、知识库构建、RAG（检索增强生成）相关开发。
• AI应用与企业现有系统（OA、IM、HR系统）的集成能力。

提前掌握这些技能，比等到业务方提出需求后再临时学习要从容得多。

1.3 AI办公的典型应用场景

AI办公的可落地场景非常多，下面列举当前企业里落地率较高的几类：

这些场景的共同特点是：高重复、有明确规则、依赖大量存量文本数据。这正好是大模型和搜索增强技术的用武之地。

2. 当前AI办公的技术版图

2.1 从单点工具到办公智能体

AI办公产品早期形态是“单点助手”，比如聊天机器人、翻译工具、OCR识别工具。它们各自解决一个问题，但彼此不连通。

现在正在发生的转变是“办公智能体”。智能体的特点是可以被赋予一个目标，并自主调用工具来完成多步任务。例如你要组织一次部门周会，智能体可以自动查找参会人的空闲时间，生成会议邀请，同时翻出上一期会议纪要和待办事项，放进本次会议资料里。

这背后的技术栈包括：

• 大模型对话与推理能力。
• 意图识别和任务规划。
• 工具调用，也就是Function Calling。
• 连接器，用于访问日历、文档、邮件、IM等系统。

百度提出的AI办公布局思路，本质上也遵循类似逻辑：先拥有底座大模型，再通过搜索引擎积累的文档理解与知识图谱能力做增强，最后在协同办公入口里提供智能应用。对开发者而言，理解这套逻辑比记住某个具体产品更重要。

2.2 RAG是AI办公的核心技术底座

RAG，全称Retrieval-Augmented Generation，即检索增强生成。它解决的是大模型“知识过时、容易幻觉、无法访问私域数据”三大问题。

RAG的基本流程如下：

1. 把企业内部文档切片，通过Embedding模型转成向量，存入向量数据库。
2. 用户提问时，将问题也转成向量，在知识库中检索最相关的文档碎片。
3. 把检索到的文档片段连同问题一起交给大模型。
4. 大模型基于给定材料组织回答，并可以标注信息来源。

在AI办公场景中，RAG的实用性非常高。因为企业内部问答往往需要严格依据制度文本或项目材料，而不是让模型自由发挥。

2.3 自动化流程编排

AI办公不只是“问答”，还涉及“行动”。流程编排层负责把AI的决策结果转化为系统动作。

通用流程包括：

• 触发条件，例如收到邮件、提交表单、定时任务。
• AI处理节点，例如提取关键信息、判断审批类型、生成回复草稿。
• 业务动作，例如写入CRM、推送企业微信/钉钉/如流消息、创建待办。
• 人工审核节点，在高风险操作前暂停并征求人工确认。

这种编排思路可以类比为传统工作流引擎，只不过把“规则判断”升级为“模型判断”，从而能处理更多非结构化输入。

2.4 百度AI办公生态的布局思路

从公开信息和技术产品线看，百度在AI办公赛道的布局可以概括为“三层结构”。

第一层是模型和算法底座，包括百度的自然语言处理积累和文心大模型系列。第二层是AI开发平台，提供模型调用、Prompt调试、知识库管理、智能体编排等工具，降低开发者落地AI应用的门槛。第三层是办公入口和行业解决方案，将AI能力封装到搜索、协同办公、云文档等产品中，让最终用户直接使用。

这种布局的关键在于“搜索技术”的迁移复用。AI办公中的知识问答、文档检索、信息整合，本质上与搜索引擎处理的问题高度一致。一个擅长对海量信息做排序、抽取、摘要的团队，在做企业知识库问答时天然具有技术延续性。

作为开发者，不一定要绑定某个厂商，但可以借鉴这个思路：你自己的AI办公应用，也应该分成底座、平台、应用三层来设计，避免把所有逻辑都堆在一个脚本里。

3. 一套可落地的AI办公技术框架

3.1 总体架构设计

综合当前主流实践，一个企业级AI办公应用的技术架构可以拆成五层：

1. 数据源层：包括本地文件、数据库、企业网盘、OA系统、IM记录。
2. 接入与解析层：负责文档解析、格式转换、内容清洗、权限过滤。
3. 知识管理层：负责文档切片、Embedding向量化、向量索引、知识更新。
4. 模型与应用层：包括大模型调用的对话服务、Prompt模板、智能体逻辑、问答接口。
5. 应用与治理层：面向用户的客户端，以及日志、审计、反馈、效果评估体系。

这个架构并不复杂，但它划定了一条清晰的数据流：从原始数据到可检索的知识，再到可对话的服务，最后到有治理的使用。

3.2 为什么要把“知识库”单独拆一层

很多初次搭建AI问答系统的团队，会直接把文档内容塞进Prompt。这种方式在小规模demo时可行，一旦文档超过十页，就会出现问题：

• Prompt长度受限，无法容纳全部内容。
• 无关信息太多，模型回答质量下降。
• 更新文档时，只能修改程序重新部署，维护成本高。

把知识库单独拆出来之后，文档处理和问答逻辑就解耦了。文档更新只需要重新走一遍解析和向量化流程，问答服务不必修改。

3.3 安全与权限必须前置设计

AI办公处理的数据，很多是企业内部敏感信息。因此在设计架构的第一天，就应该考虑权限问题，而不是等功能上线后再补救。

权限设计有两个层次：

• 数据入库时的权限隔离。不是所有员工都能索引所有文档，部门文件应该限制在部门知识库范围内。
• 问答结果返回时的二次过滤。即使模型检索到了数据，也要根据当前用户权限决定是否展示。

在大模型私有化部署成本还比较高的背景下，很多企业采用“数据不出内部、模型走专用API”的折中方案。这时候网关卡控、请求审计、敏感词过滤就变得格外重要。

4. 动手实战：搭建一个轻量AI办公知识问答助手

纸上谈兵到这里为止。下面我们用Python从零搭建一个面向内部文档的知识问答助手。

为了降低环境复杂度，我们不用重型框架，核心依赖只选三样：

• FastAPI：提供HTTP查询接口，方便后续集成到IM或Web系统。
• Sentence-Transformers或兼容Embedding模型：做文本向量化。
• 一个兼容OpenAI协议的大模型HTTP接口，本文示例默认使用一种通用兼容调用方式，具体Endpoint和Key请按你使用的平台申请后替换。

大模型服务建议优先选国内有合规备案的平台。不同平台API地址稍有差异，本文示例使用OpenAI兼容格式编写，方便你迁移到不同厂商。

4.1 场景定义

我们的目标是做一个“员工制度问答助手”。知识库里放入三份公司制度文档，员工可以提问：

• “年假申请流程是什么？”
• “报销发票有什么要求？”
• “加班调休怎么规定的？”

助手需要从文档中检索依据，并基于检索结果回答。

4.2 项目结构

建议创建这样一个目录结构：

ai-office-assistant/ ├── data/ │ ├── holiday_policy.md │ ├── expense_policy.md │ └── overtime_policy.md ├── src/ │ ├── doc_loader.py │ ├── vector_store.py │ ├── rag_chain.py │ └── api.py ├── requirements.txt └── README.md

先创建工作目录：

mkdir ai-office-assistant && cd ai-office-assistant mkdir -p data src

4.3 依赖安装

创建requirements.txt：

fastapi uvicorn requests numpy sentence-transformers

安装依赖：

pip install -r requirements.txt

版本需要根据你的项目实际Python环境调整，建议使用Python 3.9及以上。如果安装sentence-transformers比较慢，也可以使用text2vec或m3e等轻量Embedding模型，调用思路一致。

4.4 准备示例文档

为了演示效果，我们在data目录下创建三份Markdown格式的制度文档。

data/holiday_policy.md：

# 年假管理制度 入职满1年且不满10年的员工，每年享有5天年假。 入职满10年且不满20年的员工，每年享有10天年假。 入职满20年的员工，每年享有15天年假。 年假申请流程： 第一步，在OA系统发起年假申请单； 第二步，选择休假起止日期和休假事由； 第三步，提交直属主管审批； 第四步，主管审批通过后，同步抄送至人力资源部备案。 年假原则上应在自然年度内休完，当年未休完的年假不得跨年累积，特殊情况经部门负责人和人力资源部批准后方可延期。

data/expense_policy.md：

# 差旅费用报销制度 报销发票要求： 1. 发票抬头必须为公司全称； 2. 发票内容应与实际业务一致，禁止虚开； 3. 单张发票金额超过5000元时，需额外提供付款流水证明； 4. 电子发票需在报销系统中提交原始PDF文件。 报销流程： 员工在费用报销模块填写申请单，上传发票影像资料； 部门负责人审批，财务审核票据； 审核通过后，报销款项将在5个工作日内发放至员工工资卡。

data/overtime_policy.md：

# 加班与调休管理制度 工作日加班：经审批后，加班时长可按1:1调休； 休息日加班：经审批后，加班时长可按1:1调休； 法定节假日加班：按照国家规定支付加班工资，不折算调休。 加班申请流程： 员工需在加班开始前提交加班申请，写明加班原因和预计时长； 部门负责人审批后生效； 加班结束后，员工需在系统中填写实际工时记录。

4.5 编写文档加载与切分模块

filepath: src/doc_loader.py

import os from typing import List def load_markdown_files(data_dir: str) -> List[str]: """加载目录下所有markdown文档内容。 返回一个字符串列表，其中每个元素对应一个文件的完整内容。 """ chunks = [] for file_name in os.listdir(data_dir): if file_name.endswith(".md"): file_path = os.path.join(data_dir, file_name) with open(file_path, "r", encoding="utf-8") as f: content = f.read() # 简单按段落切分，真实场景建议按标题语义切分 paragraphs = [p.strip() for p in content.split("\n\n") if p.strip()] chunks.extend(paragraphs) return chunks def chunk_text(text: str, max_length: int = 200) -> List[str]: """将文本按大致长度切分为片段，避免超过模型输入窗口。 这里做一个保守的边界处理：优先在标点符号附近截断。 """ if len(text) <= max_length: return [text] pieces = [] current = "" for sentence in text.replace("。", "。\n").split("\n"): if len(current) + len(sentence) <= max_length: current += sentence else: if current: pieces.append(current) current = sentence if current: pieces.append(current) return pieces

简单解释一下：

• load_markdown_files负责读取文件并按空行切分成较粗的段落。
• chunk_text用于进一步控制片段长度。在生产项目中，推荐按Markdown标题层级切分，这样检索到的片段在语义上更完整。

4.6 编写向量存储模块

filepath: src/vector_store.py

import numpy as np from typing import List, Tuple class SimpleVectorStore: """最简单的内存向量存储实现。""" def __init__(self, embed_model): self.embed_model = embed_model self.chunks = [] self.vectors = [] def add_documents(self, docs: List[str]) -> None: for doc in docs: vec = self.embed_model.encode(doc) self.chunks.append(doc) self.vectors.append(vec) def search(self, query: str, top_k: int = 3) -> List[Tuple[str, float]]: query_vec = self.embed_model.encode(query) scores = [] for vec in self.vectors: score = self._cosine_similarity(query_vec, vec) scores.append(score) idx = np.argsort(scores)[::-1][:top_k] results = [(self.chunks[i], float(scores[i])) for i in idx] return results @staticmethod def _cosine_similarity(vec1, vec2) -> float: dot = np.dot(vec1, vec2) norm = np.linalg.norm(vec1) * np.linalg.norm(vec2) if norm == 0: return 0.0 return dot / norm

在实际项目中，建议使用专门的向量数据库，比如Milvus、Qdrant、Elasticsearch的向量检索能力。这里的SimpleVectorStore只是为了教学演示，把核心思路说清楚：文档转向量、问题转向量、计算余弦相似度、返回TopK结果。

4.7 编写RAG问答链

filepath: src/rag_chain.py

import requests def build_prompt(question: str, contexts: List[str]) -> str: """根据检索到的文档片段构建Prompt。 关键点是要求模型只依据给定材料回答，降低幻觉概率。 """ context_block = "\n\n".join([f"【资料{i + 1}】\n{c}" for i, c in enumerate(contexts)]) prompt = f"""你是一个企业制度问答助手。请根据提供的资料回答员工问题。 要求： 1. 只能基于资料内容回答，不要自行编造； 2. 如果资料中没有答案，请回答“根据现有资料无法确认”； 3. 回答时尽量简洁，可引用资料编号。 资料： {context_block} 员工问题：{question} 回答：""" return prompt def call_llm(prompt: str, api_key: str, api_url: str, model: str) -> str: """调用兼容OpenAI协议的大模型API。 具体模型名称和URL以你的服务商文档为准。 """ headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json", } payload = { "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": 0.2, } resp = requests.post(api_url, headers=headers, json=payload, timeout=60) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"]

需要注意，不同平台返回的JSON结构可能在细节上有差异，但主流兼容OpenAI协议的平台基本保持了choices[0].message.content结构。如果返回格式不一致，以服务商文档为准。

4.8 使用示例脚本

配合上面的代码，我们写一个命令行测试脚本，方便验证效果。

filepath: test_rag.py

from sentence_transformers import SentenceTransformer from src.doc_loader import load_markdown_files, chunk_text from src.vector_store import SimpleVectorStore from src.rag_chain import build_prompt, call_llm # 1. 初始化Embedding模型 embed_model = SentenceTransformer("paraphrase-multilingual-MiniLM-L12-v2") # 2. 加载和切分文档 raw_chunks = load_markdown_files("data") all_chunks = [] for c in raw_chunks: all_chunks.extend(chunk_text(c, max_length=150)) print(f"切分后共得到 {len(all_chunks)} 个文本片段") # 3. 构建向量库 store = SimpleVectorStore(embed_model) store.add_documents(all_chunks) # 4. 用户提问 question = "年假申请流程是什么？" results = store.search(question, top_k=3) print("检索到的资料片段：") for i, (text, score) in enumerate(results): print(f"Top{i + 1} (相似度 {score:.4f}): {text[:100]}...") # 5. 构建Prompt并调用大模型 prompt = build_prompt(question, [text for text, _ in results]) # 这里替换为你的实际API信息 api_key = "your-api-key" api_url = "https://your-api-endpoint/v1/chat/completions" model = "your-model-name" answer = call_llm(prompt, api_key, api_url, model) print("\nAI回答：", answer)

先不调用大模型，单独验证检索效果：

python test_rag.py

预期输出中，检索到的资料片段应该与年假申请流程高度相关。如果检索结果不相关，需要检查文档切分逻辑和Embedding模型的中文效果。

4.9 对外提供HTTP查询接口

为了让这个问答能力能被网页或IM工具调用，我们再用FastAPI包一层接口。

filepath: src/api.py

from fastapi import FastAPI from pydantic import BaseModel from sentence_transformers import SentenceTransformer from src.doc_loader import load_markdown_files, chunk_text from src.vector_store import SimpleVectorStore from src.rag_chain import build_prompt, call_llm app = FastAPI(title="AI办公文档问答助手") # 启动时初始化，避免每次请求重复加载 embed_model = SentenceTransformer("paraphrase-multilingual-MiniLM-L12-v2") store = SimpleVectorStore(embed_model) raw_chunks = load_markdown_files("data") all_chunks = [] for c in raw_chunks: all_chunks.extend(chunk_text(c, max_length=150)) store.add_documents(all_chunks) # 从环境变量读取大模型配置 import os API_KEY = os.getenv("LLM_API_KEY", "your-api-key") API_URL = os.getenv("LLM_API_URL", "https://your-api-endpoint/v1/chat/completions") MODEL = os.getenv("LLM_MODEL", "your-model-name") class QueryRequest(BaseModel): question: str top_k: int = 3 class QueryResponse(BaseModel): answer: str references: list @app.post("/ask", response_model=QueryResponse) def ask(req: QueryRequest): results = store.search(req.question, top_k=req.top_k) contexts = [text for text, _ in results] prompt = build_prompt(req.question, contexts) answer = call_llm(prompt, API_KEY, API_URL, MODEL) return QueryResponse(answer=answer, references=contexts)

启动服务：

export LLM_API_KEY="your-api-key" export LLM_API_URL="https://your-api-endpoint/v1/chat/completions" export LLM_MODEL="your-model-name" uvicorn src.api:app --host 0.0.0.0 --port 8000

然后新开一个终端，用curl测试：

curl -X POST "http://localhost:8000/ask" \ -H "Content-Type: application/json" \ -d '{"question": "报销发票有什么要求？"}'

如果一切正常，你会得到一个JSON响应，包含answer和references字段。references字段可以帮助用户追溯答案来源，这在企业场景中非常重要。

4.10 效果说明与演示截图

到这里，一个最简单的AI办公知识问答助手就跑通了。你可以把data目录下的三份制度文档换成你们部门的SOP、产品说明书或项目交接文档，它就成为一个小范围内的“部门问不倒”助手。

这个demo的真正价值不在于代码有多复杂，而在于把RAG链路完整跑了一遍。后面无论你接入哪家的大模型API，换成哪种向量数据库，整体链路都是差不多：解析文档、向量化、建索引、检索、注入Prompt、调用大模型、返回答案。

5. AI办公落地中的常见问题与排查思路

在实际落地过程中，遇到的问题往往不是“模型不聪明”，而是工程细节没有处理好。下面是几个高频问题。

5.1 文档解析后乱码或者内容缺失

错误现象：进入知识库的文档在问答时检索不到内容，查看入库日志发现许多段落为空或乱码。

常见原因：

• PDF是扫描件，没有做OCR。
• 文档里有图片或复杂表格，纯文本抽取丢失了信息。
• 编码格式不支持，Markdown或Word文档没按UTF-8读取。

解决思路：

5.2 AI回答不准确或者胡编乱造

错误现象：知识库里有明确答案，但模型没有引用，反而自己编了一段。

常见原因：

• 检索到的文档片段不相关，上下文被错误资料占据。
• Prompt没有明确约束“只能依据资料回答”。
• 检索TopK值太小，真正包含答案的片段没有被召回。

排查与修复：

1. 先看检索召回结果，先确认相关片段是否被搜到。
2. 如果检索不到，优先优化切分逻辑和Embedding模型。
3. 如果检索到了但模型不按材料回答，需要在Prompt里写“如果资料中没有答案，请明确回答无法确认”。

5.3 响应速度太慢

错误现象：生产环境并发请求后接口响应时间从2秒涨到20秒。

常见原因：

• 向量检索和文档查询没有加缓存。
• 大模型API串行调用，未做并发控制。
• Prompt里塞入了过多不相关文档片段，导致输入Token膨胀。

常用做法：

• 对高频问题做语义缓存，命中缓存就直接返回。
• 控制检索数量，TopK建议3到5个，不要贪多。
• 回答链路中把向量检索和大模型生成拆开，便于单独做性能观测。

5.4 权限控制失效

错误现象：A部门的员工能通过问答系统问到B部门的薪资或绩效信息。

常见原因：

• 文档入库时没有标记部门归属。
• 检索阶段没有根据当前用户权限过滤数据。
• 问答服务直接放在公网，没有接入统一认证。

解决思路：

• 文档向量化之前先打上权限标签。
• 问答服务接入SSO或企业内部身份体系，从请求Token中解析用户身份。
• 在知识库检索阶段同步传入权限条件，只检索当前用户有权访问的文档集合。

5.5 大模型API选择困难

错误现象：不同平台的模型在具体任务上表现差异较大，团队不知道怎么选。

建议判断维度：

如果你所在公司对数据安全要求很高，建议优先考虑支持私有化部署或专用API通道的方案，不要直接把核心制度文档发送到公网模型。

6. 企业提前布局AI办公的有效路径

6.1 从高频重复场景入手

AI办公最适合切入的场景，是企业里面“做起来繁琐、但又没有太多创造性”的任务。

比较适合首批落地的有：

• 内部制度问答。
• 新员工入职答疑。
• 日常IT运维客服。
• 销售资料智能检索。
• 会议纪要和待办提取。

这些场景的效果衡量标准也相对清晰，比如问题解决率、平均处理时长、文档检索准确率等。

6.2 先定“人和流程”，再定“模型和产品”

很多项目失败，不是模型不够好，而是责任人不明确。建议成立一个跨职能小组：

• 业务责任人：负责定义场景和验收标准。
• 技术开发人员：负责系统和数据打通。
• AI算法工程师：负责Prompt设计、模型调用和效果调优。
• 法务/安全同事：负责数据合规评审。

在启动任何AI应用开发之前，先让这些人坐下来对齐一个场景的目标和边界。

6.3 小范围试用，看重“使用率”而不是“惊艳度”

AI办公项目很容易做出Demo很惊艳、上线后没人用的结果。为了避免这种情况，可以在第一批种子用户中找一些愿意反馈的员工，制定每周反馈机制。

重点关注的数据指标不是“AI回答是否完美”，而是：

• 每周活跃使用人数。
• 提问总数与有效回答率。
• 用户手动修改AI结果的次数。
• 高频无法回答的问题类型。

根据这些反馈，迭代知识库内容和Prompt模板。

6.4 建设内部知识库的持续更新机制

AI办公系统的长期价值，取决于知识库的新鲜度。制度文档会改版，项目资料会更新，人员信息会流动。

推荐建立如下更新机制：

文档变更 -> 触发增量导入 -> 重新解析 -> 重新向量化 -> 版本记录 -> 发布到问答服务

对已经索引的文档，要支持定期全量校验，确保删除或失效的文档不会继续被检索出来。

6.5 成本评估要包含隐性成本

企业引入大模型API服务时，团队往往只关注Token单价，而忽略三块隐性成本：

• 数据清洗成本：文档格式五花八门，需要投入人力整理。
• Prompt调试成本：不同场景可能需要几轮迭代才能达到稳定效果。
• 评测回归成本：模型版本更新后，已有问答效果可能发生波动，需要准备一批评测集来验证。

这些隐性成本甚至可能超过API调用费用，在做预算时要提前预留。

7. 给开发者的工程实践建议

7.1 代码层面做到配置与逻辑分离

在本文的demo中，API地址、模型名称和密钥都是直接写在代码里的。生产环境绝不能这么做。

推荐使用环境变量或配置中心管理：

export LLM_API_KEY="sk-xxx" export LLM_API_URL="https://your-api-endpoint/v1/chat/completions" export LLM_MODEL="your-model-name"

配置与逻辑分离的好处是：换模型、换服务商、发新版本时不需要改代码，只需要调整配置。

7.2 Prompt模板版本化管理

Prompt工程在AI办公项目里不是一次性工作。建议把Prompt模板作为独立资源文件管理，不要硬编码在代码里：

prompts/ ├── policy_qa.yaml ├── meeting_summary.yaml └── expense_review.yaml

每次修改Prompt后，使用一套固定的评测问题验证效果，防止“改好了一个问题，弄坏了另外三个问题”。

7.3 日志中记录模型输入输出

大模型应用的一个难点是黑盒问题。当用户反馈“AI回答错了”时，你需要知道当时模型收到了什么材料、生成了什么文本。

建议日志至少记录：

• 用户原始问题。
• 检索命中的文档片段和相似度。
• Prompt完整内容。
• 模型返回结果。
• 用户是否有对结果进行点赞或点踩。

这些日志沉淀下来之后，还可以进一步做成评测集，效果会越来越好。

7.4 安全边界与最小权限原则

最后再强调一次数据安全。处理企业内部文档时：

• 遵循最小权限原则，员工只能访问完成工作所必需的信息。
• 将AI问答与统一身份认证打通，杜绝匿名访问。
• 对导出和批量查询接口做好限流与审计。
• 涉及用户行为数据的采集，要遵循相关法律法规，提前获得必要授权并做脱敏处理。

安全能力和功能迭代是同步关系，不是上线后的补救工作。

技术栈可以不断演进，模型可以不断替换，但这套“文档解析 -> 知识库 -> 检索 -> Prompt -> 大模型生成 -> 权限审计”的链路，是当前AI办公应用比较通用的骨架。建议读者先把这条链路真正跑通，再结合自己的业务场景做扩展。欢迎收藏本文，后续动手实践时可以直接按章节对照实现。