近年来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的基本流程如下把企业内部文档切片通过Embedding模型转成向量存入向量数据库。用户提问时将问题也转成向量在知识库中检索最相关的文档碎片。把检索到的文档片段连同问题一起交给大模型。大模型基于给定材料组织回答并可以标注信息来源。在AI办公场景中RAG的实用性非常高。因为企业内部问答往往需要严格依据制度文本或项目材料而不是让模型自由发挥。2.3 自动化流程编排AI办公不只是“问答”还涉及“行动”。流程编排层负责把AI的决策结果转化为系统动作。通用流程包括触发条件例如收到邮件、提交表单、定时任务。AI处理节点例如提取关键信息、判断审批类型、生成回复草稿。业务动作例如写入CRM、推送企业微信/钉钉/如流消息、创建待办。人工审核节点在高风险操作前暂停并征求人工确认。这种编排思路可以类比为传统工作流引擎只不过把“规则判断”升级为“模型判断”从而能处理更多非结构化输入。2.4 百度AI办公生态的布局思路从公开信息和技术产品线看百度在AI办公赛道的布局可以概括为“三层结构”。第一层是模型和算法底座包括百度的自然语言处理积累和文心大模型系列。第二层是AI开发平台提供模型调用、Prompt调试、知识库管理、智能体编排等工具降低开发者落地AI应用的门槛。第三层是办公入口和行业解决方案将AI能力封装到搜索、协同办公、云文档等产品中让最终用户直接使用。这种布局的关键在于“搜索技术”的迁移复用。AI办公中的知识问答、文档检索、信息整合本质上与搜索引擎处理的问题高度一致。一个擅长对海量信息做排序、抽取、摘要的团队在做企业知识库问答时天然具有技术延续性。作为开发者不一定要绑定某个厂商但可以借鉴这个思路你自己的AI办公应用也应该分成底座、平台、应用三层来设计避免把所有逻辑都堆在一个脚本里。3. 一套可落地的AI办公技术框架3.1 总体架构设计综合当前主流实践一个企业级AI办公应用的技术架构可以拆成五层数据源层包括本地文件、数据库、企业网盘、OA系统、IM记录。接入与解析层负责文档解析、格式转换、内容清洗、权限过滤。知识管理层负责文档切片、Embedding向量化、向量索引、知识更新。模型与应用层包括大模型调用的对话服务、Prompt模板、智能体逻辑、问答接口。应用与治理层面向用户的客户端以及日志、审计、反馈、效果评估体系。这个架构并不复杂但它划定了一条清晰的数据流从原始数据到可检索的知识再到可对话的服务最后到有治理的使用。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 src4.3 依赖安装创建requirements.txtfastapi 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.pyimport 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, encodingutf-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.pyimport 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.pyimport 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: fBearer {api_key}, Content-Type: application/json, } payload { model: model, messages: [{role: user, content: prompt}], temperature: 0.2, } resp requests.post(api_url, headersheaders, jsonpayload, timeout60) resp.raise_for_status() data resp.json() return data[choices][0][message][content]需要注意不同平台返回的JSON结构可能在细节上有差异但主流兼容OpenAI协议的平台基本保持了choices[0].message.content结构。如果返回格式不一致以服务商文档为准。4.8 使用示例脚本配合上面的代码我们写一个命令行测试脚本方便验证效果。filepath: test_rag.pyfrom 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_length150)) print(f切分后共得到 {len(all_chunks)} 个文本片段) # 3. 构建向量库 store SimpleVectorStore(embed_model) store.add_documents(all_chunks) # 4. 用户提问 question 年假申请流程是什么 results store.search(question, top_k3) print(检索到的资料片段) for i, (text, score) in enumerate(results): print(fTop{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.pyfrom 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(titleAI办公文档问答助手) # 启动时初始化避免每次请求重复加载 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_length150)) 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_modelQueryResponse) def ask(req: QueryRequest): results store.search(req.question, top_kreq.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(answeranswer, referencescontexts)启动服务export LLM_API_KEYyour-api-key export LLM_API_URLhttps://your-api-endpoint/v1/chat/completions export LLM_MODELyour-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读取。解决思路问题现象常见原因解决思路PDF文字无法选中扫描件/图片型PDF增加OCR能力表格内容缺失解析器不支持复杂表格转成图片后做版面分析或先转Excel再结构化入库打开乱码字符编码不一致统一转为UTF-8后读取5.2 AI回答不准确或者胡编乱造错误现象知识库里有明确答案但模型没有引用反而自己编了一段。常见原因检索到的文档片段不相关上下文被错误资料占据。Prompt没有明确约束“只能依据资料回答”。检索TopK值太小真正包含答案的片段没有被召回。排查与修复先看检索召回结果先确认相关片段是否被搜到。如果检索不到优先优化切分逻辑和Embedding模型。如果检索到了但模型不按材料回答需要在Prompt里写“如果资料中没有答案请明确回答无法确认”。5.3 响应速度太慢错误现象生产环境并发请求后接口响应时间从2秒涨到20秒。常见原因向量检索和文档查询没有加缓存。大模型API串行调用未做并发控制。Prompt里塞入了过多不相关文档片段导致输入Token膨胀。常用做法对高频问题做语义缓存命中缓存就直接返回。控制检索数量TopK建议3到5个不要贪多。回答链路中把向量检索和大模型生成拆开便于单独做性能观测。5.4 权限控制失效错误现象A部门的员工能通过问答系统问到B部门的薪资或绩效信息。常见原因文档入库时没有标记部门归属。检索阶段没有根据当前用户权限过滤数据。问答服务直接放在公网没有接入统一认证。解决思路文档向量化之前先打上权限标签。问答服务接入SSO或企业内部身份体系从请求Token中解析用户身份。在知识库检索阶段同步传入权限条件只检索当前用户有权访问的文档集合。5.5 大模型API选择困难错误现象不同平台的模型在具体任务上表现差异较大团队不知道怎么选。建议判断维度判断维度建议关注点中文场景能力制度问答、公文写作等场景建议优先对比真实业务数据合规与数据安全确认数据是否会被用于模型训练能否私有化部署API稳定性和限流关注并发限制、响应时间、SLA协议成本输入输出Token价格是长期成本主要来源如果你所在公司对数据安全要求很高建议优先考虑支持私有化部署或专用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_KEYsk-xxx export LLM_API_URLhttps://your-api-endpoint/v1/chat/completions export LLM_MODELyour-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办公应用比较通用的骨架。建议读者先把这条链路真正跑通再结合自己的业务场景做扩展。欢迎收藏本文后续动手实践时可以直接按章节对照实现。