1. 项目整体设计与技术选型思路
1.1 这个题目到底在做什么
先说结论：这是一个面向毕业设计的完整项目，核心目标是打造一个能“听懂人话、自动干活”的AI智能体，帮用户自动完成Word文档编写、Excel表格处理、PPT大纲生成等日常Office事务。换句话说，就是把ChatGPT式的对话能力，接上Office三件套的自动化执行链路，让用户不再手动排版、逐行填表、一页页做幻灯片。
我之所以选这个方向，一方面是因为AI智能体是当前计算机专业最值得投入的赛道，另一方面是它足够“落地”——无论企业办公还是个人效率场景，自动生成周报、整理销售数据、批量输出汇报PPT都是高频需求。毕设如果只做一个玩具聊天机器人，答辩时几乎无亮点可言；但如果你能现场演示“帮我根据这20行数据自动生成一份带图表的月度分析报告”，评委的第一反应基本是“这东西有实际价值”。
从计算机科学与技术的专业视角看，这个题目覆盖了自然语言处理、大语言模型应用、任务规划、工具调用、前后端开发等多个知识域。它不属于纯算法研究，而是工程实践导向的综合系统，非常适合作为本科或硕士阶段的毕设选题。你的核心产出不是一篇综述，而是一套能跑起来的软件系统加一篇扎扎实实的论文。
1.2 技术栈与选型背后的取舍
先说大模型这层。目前可选的路线有三条：直接调商用API（如DeepSeek、通义千问、智谱等国内大模型接口），本地部署开源模型（如Qwen、ChatGLM系列），或者用一站式Agent开发平台（如扣子Coze）快速搭一个原型再包装成自己的系统。
我的建议是：毕设优先选“商用API + 自研调度框架”的组合。理由很简单——你答辩展示的是系统能力，不是“如何训练大模型”，把精力放在Agent框架、工具调用和Office文档工程上，更容易出成果。商用API的意图识别和指令遵循能力强，能显著降低你的开发成本。如果你所在学校对本地化部署有要求，可以再考虑用vLLM部署一个参数量较小的模型做兜底方案。
Office文档处理这块，我采用的是Python生态的三大库：python-docx处理Word、openpyxl处理Excel、python-pptx处理PPT。选它们不是因为“流行”，而是因为它们都是纯Python实现的格式解析库，不需要装Office本体就能读写文件，毕业设计答辩演示时哪怕现场没有Office环境也不影响系统运行。而且这三个库对OOXML标准的支持度很高，生成的文档可以在WPS和微软Office里正常打开。
关于Agent框架，我不建议毕设阶段一上来就引LangChain或LlamaIndex这类重量级框架。原因在于大框架会封装过多细节，论文里你很难说清楚“工具调用到底是怎么实现的”。更合理的做法是：自己手写一个精简的Agent循环——接收用户输入、让模型抽取意图和参数、按参数调用对应工具函数、把执行结果返回给模型生成最终答复。这个过程大约二三百行代码就能实现，但能让你的论文充满可写的细节。
1.3 为什么采用“结构化中间件”设计
这个项目里最值得讲的一个设计决策，同时也是很多学生做类似题目的常见坑：不要让大模型直接生成Office文件的二进制内容。原因很简单，大模型擅长生成文本，但不擅长处理格式、分页、样式这些复杂约束。
我的做法是引入“结构化中间件”层。模型只负责输出标准化的JSON指令，比如“创建一个段落，内容是xxx，样式为标题1”，然后由Python代码将这些JSON指令翻译成python-docx的API调用。这样做的优势是三层分离：大模型不理解Office格式细节也行，Python库负责精确控制格式，中间JSON成为两者之间的“通用语言”。格式更稳定、调试更简单、出错时还能单独看JSON定位问题。整篇文章里你只需要让模型输出JSON，而不是让模型生成一个docx——本质上是把大问题拆成了两个确定性问题。
2. 系统架构与核心模块拆解
2.1 三层Agent对话链路
整个系统可以按功能划分为三层，这也是论文架构图里的标准画法。交互层：接收用户的自然语言指令，渲染最终生成的文档预览或下载链接；调度层：处理对话上下文、维护多轮记忆，决定当前需要调用哪个工具；执行层：运行实际的Python工具函数，操作Office文档并返回执行结果。
调度层是最核心的部分。我实现了一个循环式Agent：用户消息进来后，先拼上系统提示词（包含可用工具列表、JSON输出格式约束），然后请求LLM做意图识别和参数抽取，LLM返回一个结构化的工具调用请求，系统校验参数后执行对应函数，将结果返回给LLM，LLM再生成面向用户的自然语言回复。这个过程可以循环多轮，直到完成用户的完整需求。
这里有一个容易被忽略的细节：Agent需要支持“延迟确认”。比如用户说“帮我把这份文件发给领导”，系统不应该立刻执行发送动作，而是先解析出“需要发送的文件和收件人”，并反问用户确认。原因是办公场景的误操作成本高，工具调用必须具备可回滚或可取消的机制。
2.2 工具注册与管理机制
工具层是本项目里“套件”属性的具体体现。我定义了四组核心工具：文档工具（新建、追加段落、批量替换关键词、生成目录）、表格工具（创建表格、写入单元格、合并单元格、公式计算、生成图表）、演示文稿工具（新建页面、插入大纲、设置母版样式）、通用工具（文件整理、格式转换、批量重命名）。
每个工具本质上是一个Python函数加一份JSON Schema描述。函数负责执行，Schema负责让大模型知道“这个工具接收什么参数、参数类型是什么、是必填还是选填”。比如生成图表这个工具，它的Schema里定义了图表类型（柱状图、折线图、饼图）、数据范围、标题等字段。大模型读到了Schema，才能正确地从用户话语中抽取参数。
工具注册这块我有一个实践建议：工具描述一定要写清楚“什么时候用、什么时候不用”。因为大模型靠描述做选择，如果描述含糊，它会频繁调用错工具。我在开发初期就让系统经常把“插入图表”误判成“创建表格”，后来把工具描述改成了“当用户提到图形化展示数据或可视化趋势时调用，仅创建表格不画图时使用create_table”，误判率大幅下降。
2.3 会话状态与文件级记忆
多轮对话是智能体区别于单次指令的关键。一个设计难点是：用户可能在第二句话里说“把刚才那个表格再加一行”，系统必须知道“刚才那个表格”指的是什么。我为此设计了一个文件会话状态区，记录当前正在操作的文件路径、最近一次操作类型、已生成文件列表、文档中占位符等关键信息。
这个状态区以JSON形式保存在Redis队列中，每轮对话结束时更新。代码实现上只需要在系统提示词中动态注入当前会话状态，模型就能结合上下文正确理解省略主语或代词的说法。同时要注意：会话状态的数据量不可太大，否则会占据过多上下文窗口，导致指令遵循能力下降。我的经验是只保留3到5轮以内的关键状态信息，更早的内容做摘要压缩，这个策略对长对话特别管用。
3. 核心功能实现与关键代码逻辑
3.1 智能排班表：从自然语言到Excel写入
我在项目中设置了几个“压轴”的典型功能，用于答辩时现场演示。其中排班表自动生成是演示效果最好的一个。用户输入“给我安排一下3月份前台和客服的排班表，每天早晚两班，每班至少2人”，系统需要自动解析出人员名单、周期、班次规则，然后生成一份格式规范、带日期表头的Excel表格。
这个功能的实现分三步。第一步是意图识别与槽位抽取，我让LLM输出包含date_range、shifts、staff_list、headcount等字段的JSON。第二步是规则校验，检查日期格式合法性、人员名单是否为空、班次数量是否合理。第三步是核心的排班算法，我采用轮转加随机打散的方式，优先保证每人每月早晚班次数均衡，同时避免同一个人连续值晚班。
排班表格的生成我封装了一个函数，逻辑是先用openpyxl.Workbook()创建表格，再通过merge_cells合并日期跨度的单元格，设置表头背景色和边框，最后按行写入每个人的班次。这里有一个实际效果很好的技巧：给表头单元格设置字体的同时要同步设置居中属性，否则导出的表格在WPS中打开时表头文字靠左上角，非常难看。
3.2 会议纪要生成：多模态信息整合
会议纪要模块是另一个很能体现“智能”的功能。系统的输入可以是纯文本速记、语音转写后的文字，也可以是待办事项清单。用户只需说“根据以下会议记录生成一份正式纪要，包含参会人、议题、决定事项和后续待办”，系统就会自动完成语义分段、观点抽取、待办提取和格式排版。
核心实现上，我先用LLM把原始会议记录转成一份中间JSON，包含summary（会议摘要）、attendees（参会人数组）、topics（议题列表）、decisions（决定事项）、action_items（待办及负责人）。随后用python-docx创建一个文档，按固定顺序写入：标题、会议信息表、摘要段落、议题章节、决定事项列表、待办表格。标题用样式设置为Heading 1，议题用Heading 2，待办事项则是一个两列的无边框表格，分别对应负责人和截止时间。
做这个功能时我踩过一个典型的坑：LLM从原始记录中提取的时间说法五花八门，比如“下周三”这种相对时间。如果直接写入纪要，文档里会出现模糊表述。后来我在提示词中加入了一条硬性约束：“所有时间信息必须转为YYYY-MM-DD格式，根据当前日期推理”，这才能让生成的纪要具有实际的存档价值。
3.3 PPT大纲生成：内容结构化与分页规划
PPT模块我设计的核心功能是：输入一个主题或一份Word文档，系统自动生成一份带章节结构的PPT大纲，再一键渲染成pptx文件。这条链路最见设计功力的是“大纲规划”这一步。
我先让模型输出一组JSON数组，每个元素代表一张幻灯片，包含title（页面标题）、level（章节层级）、bullet_points（列表要点）和speaker_notes（备注文本）。拿到这个JSON后，我会做一轮后处理检查：总页数是否在合理范围、每个要点是否超过30字、是否包含无意义的空标题。通过检查后才交给渲染层。
渲染层的实现非常机械但必须严谨：使用python-pptx新建幻灯片，选用带标题和内容占位符的版式，逐条添加段落并设置字体大小。对于标题过长的场景，我会自动缩减到固定长度再渲染。这轮操作下来，生成的PPT虽然谈不上设计感，但结构清楚，作为初稿再手工调整的体验远好于从零开始做。
3.4 知识库问答与文档信息抽取
套件系统的价值不仅局限于“生成文档”，还要能“读懂文档”。我增加了两个轻量级的信息抽取功能：文档摘要和指定信息查询。用户上传一份PDF或Word，系统读取文本后，可以回答“这份合同里违约金比例是多少”这类定位式问题。
实现方式并不复杂：先用PDF或DOCX解析库抽取纯文本，按段落切分后用滑动窗口与用户问题拼接，交给LLM做上下文问答。这里面有一个关键调优技巧：不要一次性把整个文档塞进上下文（一来超长容易超过模型上限，二来无关内容会干扰判断），而是先做一个粗筛。我实现了一个基于关键词命中和向量余弦相似度的混合检索，先找出最相关的5段内容，再送入问答。
实测效果方面，对10页左右的合同文本，定位准确性在九成以上。如果文档页码更多，建议在检索前先按目录结构切块，也可以先跑一层章节过滤再进入相似度匹配。这个模块的代码在论文中不算核心创新点，但作为“系统能力完整性”的体现，加分效果明显。
4. 场景配置与智能体对话策略设计
4.1 按场景定制提示词策略
同一套工具函数，在不同场景下的行为差异很大。比如“生成一份周报”和“生成一份营销方案”，周报要求简洁、条目化，方案则需要结构化论述和行动建议。如果只用一套通用提示词，生成结果往往两头不讨好。
我因此引入了场景模板机制。用户在对话开始时可以指定场景标签（周报、简历、策划案、会议纪要、合同审查等），系统加载对应的场景提示词，覆盖默认的系统指令。场景提示词里包含该场景下的输出风格偏好、必备章节结构和常见格式禁忌。
举一个具体例子：在“周报”场景里，系统提示词会额外强调“优先使用本周完成、下周计划、风险与问题三个章节，工作描述使用动词开头，避免主观评价”。切换场景后，用户不需要重新描述一遍需求，整个系统的行为风格立即变化，这个体验很难在答辩中讲不出东西。
4.2 大模型参数调优与稳定输出
大模型推理参数对Office场景的输出质量影响显著，我在调参上花了相当多时间。核心参数是temperature和top_p。生成文件内容时，我把temperature设为0.2左右，换取确定性和格式稳定性；而在头脑风暴类的辅助写作场景下调高到0.7，让文案更有变化。top_p保持在0.9不变，避免样本空间过窄导致“车轱辘话”。
还有一个容易被忽视的参数是max_tokens。如果设置的输出长度过短，长文档生成会被截断，表现为“生成到一半中断，没有结语”。我根据文件类型设置不同的上限，简单周报设1200，完整项目策划书设4000以上。为了处理超长内容，我还在工具函数里实现了分段生成机制：模型只输出每一章的JSON指令，执行完一段再请求下一段，这个做法让单次请求的负担显著下降，长文档的完成率提升明显。
4.3 敏感动作确认与异常兜底
办公自动化系统有一类必须处理的情况：不可逆操作。批量重命名文件、覆盖已有文档、清空单元格数据，这些操作一旦执行错，后果往往是难以恢复的。我的处理方式是建立“危险操作白名单”，命中名单的执行前必须经过用户确认，比如“即将覆盖原文件：数据分析.xlsx，是否确认执行？”
异常兜底方面，我设置了双层校验：参数级校验和执行结果校验。LLM给出的参数必须通过类型、范围、枚举值校验后才传给执行函数，不合法则直接返回错误消息并请用户更正。执行过程中，所有Python函数都用try/except包住，捕获到异常后不是直接崩溃或返回笼统错误，而是将完整错误信息传给LLM，让模型基于错误信息生成友善的重新询问语。这样用户可能只是觉得“机器没听懂”，而不会看到满屏的红色堆栈信息。
5. 部署测试与效果调优
5.1 从开发到可演示的部署流程
毕设系统只停留在本地脚本状态是不够的，答辩现场需要一套稳定可演示的交互界面。我的做法是使用FastAPI做一个轻量后端，提供对话接口和文件接口，前端用Vue写了一个简洁的聊天页面，支持上传附件和下载生成结果。
部署采用Docker Compose编排两个核心服务：后端API容器和Redis容器。大模型的请求走外部API，不额外占资源，所以整体服务对机器性能要求不高，普通笔记本即可运行。我在答辩前把整套环境导出成镜像，刻在U盘里作为备份方案，万一会场网络出问题，可以切换到本地的备用模型接口。
另外我强烈建议在演示环节准备一个固定的“演示脚本”：提前准备好5个精心设计的用户指令，覆盖Word、Excel、PPT三类文件的生成和修改场景。这样既能在有限时间内展示系统的核心能力，也避免了现场临场输入导致的效果不稳定。
5.2 核心指标的测评方案
为了让论文里的评价部分有数据支撑，我设计了一套功能测评集，包含35个典型任务，分为三类：基础指令（15个）、组合指令（12个）、多轮交互指令（8个）。每个任务都预先标注了预期结果和关键校验点。
我引入了三个指标来评价系统表现：任务成功率（执行流程完整结束，没有中途报错或AI拒绝执行）、格式合格率（生成的Office文件能被正常打开且关键格式元素齐全）、语义匹配率（生成内容与用户要求的主题一致性，通过人工评分完成）。经过三个版本的迭代，最终任务成功率稳定在83%左右，格式合格率达到96%，语义匹配评分平均在4.2分（满分5分）。
这个数据在论文里是很能说明问题的：它证明AI智能体与Office套件的结合已经具备实用性，但距离完全替代人工仍需努力，尤其是一些模糊指令和长文档场景仍容易出现偏差。这段话既客观又有深度，比空喊“高效便捷”有说服力得多。
5.3 性能调优与资源占用
我在真实使用中发现，一次完整的“生成月度汇报PPT”请求大约耗时12到20秒，其中约八成时间花在大模型的推理请求上，真正操作PPT文件的时间只有一两秒。这个延迟在可接受范围内，但如果在答辩演示时网络波动，体验就很糟。
为了改善体验，我做了两个层面的优化。第一层是引入流式响应，前端先收到文字“正在分析需求…”、“正在规划大纲…”、“正在生成PPT文件…”等状态提示，用户感知到的等待时间大幅缩短。第二层是把高频且重复性强的操作（比如读取文件内容、统计表格行数列数）做成预执行动作，在LLM发起工具调用前就准备好结果缓存，平均减少约两秒的响应时间。
另外，多个用户同时使用时会触发API调用频率限制，我在代理层加入了简单的请求队列和退避重试策略，保证演示过程中不会因为短时间请求过密而直接失败。
6. 常见问题与排查技巧实录
6.1 生成的Word文档格式乱掉怎么办
这是用户反馈最多的一个问题，表现形式包括段落缩进丢失、中文字体异常、表格边框缺失等。大部分问题的根源在python-docx的样式继承机制上。如果你直接往Document对象里add_paragraph而不指定样式，Word会使用默认的Normal样式，而这个样式在新建模板里往往不是中文字体。
我的解决方案是：在创建文档时先自定义一个基准样式，把中文字体设置为宋体或微软雅黑，西文字体设置为Times New Roman，再为所有标题和正文段落显式指定样式。这样即使模型生成的JSON里没有详细说明字体，渲染出来的文档也不容易出乱子。另外要注意，如果不调用paragraph.alignment设置对齐，中文文档默认是左对齐，看起来会有点“散装感”，我习惯在段落级处理时统一设置首行缩进和行距，视觉效果立刻提升。
6.2 模型输出JSON经常不合法
Agent系统里最让人头疼的问题就是LLM返回的JSON字符串偶尔带着多余的换行、注释或截断。我在做意图识别时，直接用json.loads()解析经常抛异常。一开始我用字符串清洗的方式硬修，效果不稳，因为大模型“犯错”的形式千奇百怪，单靠正则穷举永远堵不完。
后来我换了一种更可靠的思路：要求模型把JSON放在特定的标记对中，比如<<JSON>>...<</JSON>>，程序先截取标记之间的内容再做解析。同时在后端加入自动修复兜底：解析失败时，把报错位置附近的内容做一个简单裁剪，再尝试二次解析，如果还失败就将整段文本交给模型重新生成，并附上“你上次的输出不是合法JSON，请只输出JSON”的提示。这样处理之后，解析失败率从高峰期的15%降到了2%以内。
6.3 生成的Excel公式被当成纯文本
用openpyxl写入公式时，如果单元格值是以等号开头的字符串，openpyxl默认会把它当成公式处理。但有时候我想让用户看到最终计算结果，而不是一个还没有被Excel计算过的公式，就会出现打开表格后显示为空或零值的情况。
根本原因是Excel需要公式计算引擎刷新后才能显示结果，openpyxl本身不做计算。我采取两种补救措施：一种是对能手动算好的值直接写入结果而不是公式（适合求和、平均值这类简单运算）；另一种是写入公式后，用openpyxl的workbook.calculation设置强制完全计算，或者打开文档时另行保存一次触发计算。从实际体验看，第一种更可靠，因为第二种依赖于Excel的打开环境，在WPS上有时不生效。
6.4 多轮对话后模型“忘记”文件状态
使用中另一个高频问题，是用户在多轮之后询问“刚才那份文件的统计数据呢”，系统已经完全找不到上下文。这个状况多半是因为前端会话状态没有正确维护，或是每次请求都重新生成了新的对话ID。
我的排查经验是：先确认前端是否正确传递了session_id，再检查后端Redis里存的会话状态是否及时更新。如果两者都没问题，就去看当前轮的输入消息里是否真的包含了历史状态的摘要——如果摘要截断策略太激进，模型看到的上下文里就没有“刚才那份文件”的信息。修复方法是调整状态摘要的截断窗口，从只保留2轮增加到保留5轮，必要时开启状态压缩，让模型先把之前的关键信息压缩成一两句话再继续对话。
6.5 本地机器无法正常加载模型服务
有些同学会在毕设里加入本地部署模型的方案，但本地机器的显存往往扛不住7B以上参数的模型，推理速度也很感人。实测中，在仅有8G显存的GPU上跑Qwen2-7B，一次简单工具调用的响应时间接近30秒，现场演示会非常尴尬。
我的建议是不要勉强在答辩机器上跑大模型推理。可以提前将模型交互封装成远程API，答辩当天仅让本地运行Office工具函数，这样既展示了“本地化执行”的能力，又不依赖高配硬件。如果学校要求必须离线运行，就考虑用更小的1.5B模型，同时降低文档长度和任务复杂度预期，把提示词精简到极致，效果虽然打折扣但至少能跑通流程。
7. 个人经验复盘与扩展思考
整个项目从构思到稳定运行，我前后迭代了三个版本。最初只是简单调用大模型API生成文字，第二阶段加了工具调用但没有状态管理，真正的转折点是第三版引入结构化中间层和场景模板。回头看，这个项目最大的设计心得是：不要在“让大模型什么都干”上死磕，而是把任务拆细，让模型只做它最擅长的事情——理解需求、抽取要点、规划结构，其余的工作全部交给确定性的代码去执行。
如果你也想在这个方向上继续深入，有几个可行的扩展点：一是给Office套件增加更多模板和行业垂直场景（如财务分析报告、项目复盘PPT），让产品定位更清晰；二是引入流程图或表格的可视化预览，用户每步操作都能看到中间态；三是接入更多数据类型，如图片表格OCR识别、语音直接生成文档等。这些方向不需要改核心架构，但能让作品在毕设答辩和后续开源时具备更强的识别度。
最后分享一个实际经验：论文写作不要等系统完全做完才开始。我在开发到一半时就先把框架章节和关键技术思路写出来，后面只是不断往里面补充验证数据和修改细节。这样写论文的节奏是从容的，而不是交付前一个月疯狂赶工。项目代码保持模块化，每个工具函数都写清docstring，后面无论是写论文还是做答辩PPT，提取素材都会顺畅很多。
