本阶段主要聚焦于 AI 助手 Office 插件 的开发与接口调试工作,从前端交互设计到后端接口适配,再到调试过程中遇到的问题与解决方案,都让我收获颇多。本文将从「功能开发」、「体验优化」和「调试技巧」三个维度,对过去这段时间的开发过程做一次全面的总结与复盘。
一、主要工作内容概览
Office 插件开发(基于 Office.js)
-
使用 Office.js API 构建插件界面,包含输入框、按钮、输出区域等基本结构。
-
接入后端 AI 接口,通过
fetch请求实现AI 文案生成功能。 -
因 Kimi 的生成PPT功能限制,仅能在其官网使用,当前方案调整为:“复制内容并跳转至 Kimi 网页”,提升功能可用性与操作效率。
-
深入学习 Office.js,理解其如何桥接 JavaScript 与 Word/Excel/PPT 等 Office 应用的交互逻辑。
二、交互体验优化实践
为了让插件的“文案生成”功能更贴合用户使用习惯,我对用户交互体验进行了如下几项关键优化:
打字机效果(Typewriter Effect)
为了增强生成内容时的视觉反馈,我为输出区域 #output 添加了打字机式的“逐字输出”效果。
实现方式:
function typeWriterEffect(text, element) {
element.innerHTML = '';
let index = 0;
const interval = setInterval(() => {
if (index < text.length) {
element.innerHTML += text.charAt(index++);
} else {
clearInterval(interval);
}
}, 40); // 控制打字速度
}
这个小细节显著提升了用户等待时的参与感和期待感,也避免了页面“瞬间刷屏”的生硬感。
等待状态指示(Loading Spinner)
用户点击“生成文案”后,我加入了一个中间位置旋转的 Loading 动效,提示用户正在生成中。
核心技术点:
@keyframes spin {
0% { transform: rotate(0deg); }
100% { transform: rotate(360deg); }
}
.spinner {
border: 3px solid #ccc;
border-top: 3px solid #0078D4;
border-radius: 50%;
width: 24px;
height: 24px;
animation: spin 1s linear infinite;
}
加载动效能够有效避免“页面无响应”的误判,为用户提供清晰的状态反馈。
按钮状态管理
为了防止用户频繁点击触发重复请求,我加入了按钮状态控制逻辑:
-
点击后按钮文字变为「生成中…」并禁用。
-
请求完成后,恢复为「生成文案」并解锁点击。
简单而有效的状态切换逻辑,提升了整体操作流畅性。
三、接口调试与排查实践
接口基本信息
-
地址:
http://10.2.8.77:3000/v1/chat/completions -
模型:DeepSeek-R1
-
请求方式:
POST -
鉴权方式:Bearer Token(由指导老师提供)
遇到的问题
❗ 问题1:接口请求失败,报错提示「网络问题或接口地址错误」
分析过程:
-
起初怀疑是网络中断或接口不可用;
-
使用
Postman、curl测试发现接口正常; -
使用浏览器 F12 开发者工具 → Network 查看具体错误信息。
最终定位原因:
Office 插件运行在 HTTPS 环境,而接口使用的是 HTTP 地址,触发浏览器的「混合内容阻止」策略,导致请求被拒绝。
解决方案:
-
将后端接口部署到支持 HTTPS 的服务器;
-
或使用 Nginx 反向代理将 HTTP 接口转发为 HTTPS 请求。
四、开发中的感悟与收获
这阶段可以说是“挑战不断,收获连连”。尤其是在接口调试过程中,从最初的「请求失败无从下手」,到最后的定位到协议不兼容,每一步都让我更深刻理解了调试的本质:
-
调试不是瞎蒙,是有逻辑地逐步排查问题本质;
-
善用工具(如 DevTools、Postman、curl)是程序员的核心竞争力;
-
查阅文档与社区讨论也是解决问题的重要渠道。
五、下阶段工作展望
-
等待将后端服务迁移至 HTTPS,或通过 Nginx 添加反向代理解决安全协议问题。
-
优化前端交互体验:添加 loading 效果、错误提示信息等。
-
引入接口路径与 API Key 的管理功能,增强插件通用性与配置灵活性。
-
编写使用说明文档,同时整理开发过程中的“踩坑记录”。

被折叠的 条评论
为什么被折叠?



