企业官网建设流程全解析

Spring AI + Qwen3.8：AI助手生成周报实战，从工作事项到人工确认卡

🌐产品手册：https://ruoyioffice.com/
👇 文章底部提供智能体与业务系统两种体验入口 👇
💬 ：17156169080（获取 AgentOS 产品咨询）

本文由 RuoYi Office 团队整理，结合实际项目分享企业软件的设计思路与开发经验。

“帮我写周报”有两个需要分别检查的结果：一份可阅读的文字，以及准备交给业务系统的结构化内容。员工把进度从80%更正到90%后，两处都应该同步。

本文跟随一次Windows Coder390 Q3员工会话，展示事项整理、更正和人工确认卡。文中Qwen3.8沿用本轮第三方权重命名。展示的是A级确认前实测，没有点击确认、保存OA周报或发起审批。

周报助手背后的本地模型配置

这次周报生成使用本机llama.cpp b11429/CUDA12.4服务，通过18084的兼容API调用27B Coder390 Q3。模型运行在约22GB显存配置的机器上，固定8K上下文、q8_0 KV、单请求、4个CPU线程，关闭思考与MTP。Spring AI动态客户端显式传入串行工具调用选项。

部署时先用安装器准备GGUF与运行包，按SHA256核验，再使用-Model coder390 -ContextSize 8192 -Threads 4启动。health正常后才检查员工周报任务；第二篇给出了完整启动与运行观察方法。本篇重点观察同一部署参数下，员工连续补充时本地模型怎样响应。

首轮模型可以选择业务查询，工具返回之后再整理文字；第二轮更正会进入新的模型请求；第三轮模型提出准备保存的参数，应用生成确认卡。员工对话框展示的结果，必须能关联这三轮本地模型参与的运行记录。

本图将历史运行439、440、441的接口观测时间与步骤类型对应。单轮时间包含模型多次往返、工具、网络及编排，不是纯推理耗时或生产P95。

这组样例的三轮SSE请求约49.55、28.00、35.97秒。首轮6项工具步骤合计约1.366秒，但其余时间也不能直接称为一次模型推理。拆开这些记录，才能区分模型生成较长、业务接口较慢、工具结果过多和重复调用等不同原因。

一、先给助手明确的事项与周期

本轮使用专用普通员工，任职上下文为深圳总公司、测试部门。固定输入包括三项本周工作、两项下周计划和一个协调事项：

请先整理我的工作周报，不保存。 本周周期2026-10-05至2026-10-11： 完成报销接口联调，部署手册完成80%，跟进两项OCR缺陷； 下周计划补齐Linux部署验证，需要协调测试样票。 请不要编造工作事项。

这是原始实测提示按阅读需要换行后的内容。固定材料让不同轮次可比较，也方便后续核对是否增加了员工没有提供的工作。

来自会话339。系统查询结果为空，助手说明口述事项无法由这些系统记录交叉佐证。

首轮助手查询工作汇报、已办审批、出差、差旅报销和办事进度。其中一次带日期范围的已办查询参数转换失败，之后再次查询返回空结果。页面保留了失败步骤，不能把回复中的“已查完”理解为每个请求都成功。

对这名测试员工，系统返回的记录不能补充更多工作。助手据此整理员工口述事项，并明确说明来源。这是值得保留的行为：查询没有结果时，应告诉员工哪些内容来自口述。

结论：AI周报应区分系统记录与员工补充；空查询结果和失败步骤要如实保留，不能由模型补出未提供的工作成果。

二、更正一项进度，检查两种内容是否同步

第二轮员工更正部署手册进度，并补齐标题和周次：

更正：部署手册完成度是90%，不是80%。 标题为“本地模型交付周报”，周次2026-41。 请按当前员工身份准备保存工作周报，生成真实待确认卡让我核对； 不执行确认，不提交审批。

助手回复中的工作总结已改成90%，标题、周期和周次也有结构化表达，但这一轮没有产生真实确认卡。随后第三轮明确要求调用“保存工作汇报”能力，才产生确认记录。

这张图证明更正后的文字可见，不能单独证明后端已准备操作。第三轮确认卡证据需另查。

这就是多轮业务验收的关键：如果检查止于“回复出现90%”，就可能漏掉旧工具参数仍为80%的问题。应继续核对准备保存的参数和卡片字段。

三、真实确认卡还要对应后端记录

本例第三轮对应运行441，生成确认记录38。记录中的工作总结、卡片预览和可编辑字段均包含“部署手册编写完成90%”，起止日期为2026-10-05至2026-10-11，类型为周报。

历史确认卡重新截图，有效期已过。整个采集过程未点击“确认写入”、取消或重新生成。

下面节选真实准备参数，省略员工、公司等归属字段。它是历史请求证据，不是供读者直接执行的业务请求：

{"reportType":2,"reportWeek":"2026-W41","title":"本地模型交付周报","startDate":"2026-10-05","endDate":"2026-10-11","todayContent":"1. 完成报销接口联调\n2. 部署手册编写完成 90%\n3. 跟进两项 OCR 缺陷","planContent":"1. 补齐 Linux 部署验证\n2. 协调测试样票","issueContent":"需要协调测试样票以支持 Linux 部署验证"}

卡片预览由应用读取参数生成。对应格式化代码节选如下，每个展示项都取自准备参数：

append(text,"汇报类型",typeName);append(text,"标题",arguments.get("title"));append(text,"汇报周次",arguments.get("reportWeek"));append(text,"汇报月份",arguments.get("reportMonth"));append(text,"开始日期",arguments.get("startDate"));append(text,"结束日期",arguments.get("endDate"));append(text,"员工",arguments.get("creatorName"));append(text,"公司",arguments.get("companyName"));append(text,"部门",arguments.get("deptName"));append(text,"工作总结",arguments.get("todayContent"));append(text,"工作计划",arguments.get("planContent"));append(text,"问题/需协调事项",arguments.get("issueContent"));

摘自AgentosWritePreviewFormatter的工作汇报预览方法，typeName在前文按reportType转换。归属仍需由平台上下文及后端代码检查，不能由卡片显示本身证明权限隔离。

结论：多轮更正通过验收，需要助手回复、真实工具参数、确认卡与后端确认记录一致；只检查自然语言回复会漏掉业务状态未更新的问题。

四、成功轮次与失败轮次一起看

Windows Q3普通员工周报在三轮独立会话中均通过确认前判定；WSL2 Q3员工为2/3。管理员在两系统的周报首轮独立流程均为0/3，同会话补充恢复卡各3/3。

管理员有更大的历史查询上下文，出现超出8K预算等失败。恢复卡说明后续补充可以推进流程，却不能提高原始独立轮次的通过率。三次成功样本也不能作为生产成功率承诺。

从周报体验反推调优位置

周报使用的8K预算包含员工事项、历史对话和工具结果。管理员查到更多历史数据时，上下文压力会变大；调整检索范围和输出预算属于需要按任务验收的实施项，不能简单把上下文翻倍就宣布问题已解决。

本轮关闭思考与MTP，让配置保持一致；串行工具调用用于控制已复现的多调用行为。它不保证周报查询只调用一次工具，也不消除业务参数失败。本文首轮的日期范围查询错误仍原样保留。

读者部署后可以先复用同一固定事项，检查health与模型进程，依次观察80%文字、90%更正、真实工具参数及确认记录，再记录每轮请求时间。这样能把“本地模型已接入”进一步落实为可检查的周报体验。

确认前的安全边界还需要说清楚：

• 本轮没有创建OA周报，没有发起审批。
• 会话、工具步骤和确认记录会持久化，不能称为“系统零写入”。
• 106张OA/finance业务表的分阶段COUNT与MAX(id)未观察到变化；这种观察不能证明已有行未更新、瞬时写入不存在或事务幂等。
• 真实确认后的写入、重复确认、失败回滚及审批需另做验收。

结论：角色、历史数据量和上下文预算都会影响周报任务；独立轮次失败、同会话恢复与真实业务写入结果应分别统计。

五、把周报助手接入现有办公流程

部署时可以先限定周期、使用普通员工和一组明确事项，再验证查询、更正和确认卡。确认后实际保存与后续审批，作为下一阶段单独验收。

如果希望自动汇集项目、客户和工单数据，需要逐个接入相应能力、定义归属与时间范围，并确认取数权限。这是可扩展方向，不能由本例推断已自动汇集所有企业数据。

六、常见问题

1. 员工必须上传全部工作材料吗？

本例通过口述提供事项；已有授权业务接口可以补充可查记录。具体数据来源取决于企业已接入的能力。

2. 周报文字正确，为何还要核对工具参数？

最终准备提交的是结构化参数。文字更新但参数未变，仍可能造成错误的业务操作预览。

3. 为什么要用普通员工测试？

管理员的历史数据与权限不同，不能代表日常员工。两类身份的测试结果应分别保留。

4. 现在能证明自动保存和审批了吗？

不能。本文只验证到真实人工确认卡，真实写入及审批尚未执行和验收。

七、让更正落到员工真正要确认的内容

周报助手的可检查价值，是把员工事项整理成结构化内容，并让更正进入同一份操作预览。自然语言、工具参数和确认记录共同提供了这项证据。

你更希望周报助手先读取已有业务记录，还是先整理员工口述、再按需补查？

如果这篇对你有用，欢迎点赞支持。
我们会持续分享企业软件开发实践与 RuoYi Office 产品进展。

🤖在线体验·智能体：https://ruoyioffice.com/ai/work
🏢在线体验·业务系统：https://ruoyioffice.com/web/
📘产品手册：https://ruoyioffice.com/
💬微信：17156169080（备注「AgentOS」）

可以直接打开智能体，也可以先进入业务系统，再通过右下角“小擎”使用嵌入式助手。