前言
开篇先聊一个真实案例。作为后端开发，最近接到一个需求：在现有系统中增加Word（.doc/.docx）转Markdown的功能。技术栈已经确定——Java 1.8配合Spring Boot 2.3.12，解析工具使用Apache POI 3.17，前端采用Vue 2.6.10搭配Element UI 2.13.0，Markdown渲染选用marked@4。
以前处理这类任务，惯常流程是：自己埋头写代码，写完提测，测试那边报Bug，再灰头土脸去修，反复折腾几个来回。但这次换了个方式，全程借助腾讯云WorkBuddy，从需求分析到代码生成再到代码审查走了一遍。结果令人意外——AI代码审查一口气揪出6个隐藏Bug，有几个甚至是我写代码时完全没意识到的隐患。
这篇文章就把完整流程和踩坑经验记录下来，希望对有同样需求的人有所启发。
一、整体开发流程
先对比两种工作方式，更直观感受效率提升：
| 阶段 | 传统方式 | 使用WorkBuddy |
| 需求拆解 | 自己琢磨，边界条件容易遗漏 | 自然语言描述需求，AI帮你补全异常场景 |
| 后端代码编写 | 手写Controller/Service/ServiceImpl | 给出框架路径和分层规范，AI生成骨架再微调 |
| 前端UI编写 | 手写Vue组件+Element UI配置 | 描述UI需求，AI生成模板代码 |
| 代码审查 | 等待测试提Bug，或者同事Code Review发现 | AI即时审查，秒级反馈 |
效率对比非常直观：类似功能以前从开发到提测至少需要2-3天，这次从需求到完成开发加代码审查，半天搞定。
二、实战步骤：从需求到代码
2.1 后端：Controller → Service → ServiceImpl分层架构
向WorkBuddy描述项目已有的分层规范时，关键点交代得很清楚：
我的项目是resence-cloud，后端框架路径为： - Controller层继承BaseController - Service层定义接口 - ServiceImpl层实现逻辑 需求：用Apache POI 3.17的XWPFDocument解析Word文件， 转为Markdown格式返回给前端。
WorkBuddy按照规范生成了三个层次的代码骨架。核心逻辑部分需要人工微调，主要是Word内容到Markdown格式的转换——标题层级、列表、表格、粗体斜体等标记的处理。
2.2 前端：Vue+Element UI上传组件
前端需求比较标准：一个文件上传组件加Markdown预览区域。需求描述很具体：
前端使用Vue 2.6.10+Element UI 2.13.0+marked@4 需要一个文件上传区域（支持.doc/.docx） 上传后调用后端接口，返回Markdown文本 用marked渲染预览
AI先生成的前端代码基本可用，手动调整了上传按钮样式和预览区域的布局。
三、重点来了：AI代码审查抓出的6个Bug
这部分是整个开发过程中最让人惊喜的地方。开发完成后，让WorkBuddy对生成的代码进行了一轮审查，一口气发现了6个具体问题。
Bug 1：`el-descriptions`组件版本不兼容
问题：前端代码里使用了`
修复：换用`
? 踩坑经验：AI生成前端代码时，偶尔会混入Element Plus的组件。一定要确认你项目实际使用的Element UI版本号。
Bug 2：删除线逻辑错误
问题：Word中的删除线（`
修复：修正条件判断逻辑。
// 错误写法
if (!run.isStrikeThrough()) {
markdown.append("~~").append(text).append("~~");
}
// 正确写法
if (run.isStrikeThrough()) {
markdown.append("~~").append(text).append("~~");
}
Bug 3：死代码（Dead Code）
问题：ServiceImpl里有一段解析Word图片的代码，但对应的方法从未被调用过，属于死代码。
修复：直接删除，保持代码简洁。
Bug 4：`before-upload`钩子未触发
问题：前端`
修复：修正校验逻辑，确保只允许`.doc`和`.docx`文件。
// 修复前（永远返回true）
beforeUpload(file) {
const isDoc = file.type === 'application/msword';
return true; // 逻辑被跳过
}
// 修复后
beforeUpload(file) {
const isDoc = file.name.endsWith('.doc') || file.name.endsWith('.docx');
if (!isDoc) {
this.$message.error('只能上传Word文件！');
return false;
}
return true;
}
Bug 5：`handleExceed`方法缺失
问题：`
修复：补全方法。
handleExceed() {
this.$message.warning('只能上传一个文件，请先删除已上传文件');
}
Bug 6：`marked@4`的`sanitize`选项已弃用
问题：前端用`marked@4`渲染Markdown时，代码里传了`sanitize: true`选项。但marked v4已经弃用了sanitize，传了也不生效，控制台还会打出警告。
修复：移除`sanitize`，改用DOMPurify等XSS防护方案。
// 修复前
marked(markdownText, { sanitize: true });
// 修复后
import DOMPurify from 'dompurify';
const html = marked(markdownText);
const cleanHtml = DOMPurify.sanitize(html);
四、踩坑总结
用一张表来更清晰地对比：
| 坑 | 严重程度 | 发现方式 | 自己写能发现吗 |
| el-descriptions版本不兼容 | ? 高 | AI代码审查 | 大概率到运行时才报错 |
| 删除线逻辑写反 | ? 高 | AI代码审查 | 可能在测试时才发现 |
| 死代码 | ? 中 | AI代码审查 | 代码review时可能忽略 |
| before-upload未生效 | ? 高 | AI代码审查 | 很难发现，看起来代码"正常" |
| handleExceed缺失 | ? 中 | AI代码审查 | 边界场景测试才能覆盖 |
| marked sanitize弃用 | ? 中 | AI代码审查 | 运行时有控制台警告但不报错 |
最关键的是Bug 4和Bug 1：这两个问题表面看起来代码是"对"的，只有在特定场景下才会暴露。如果是人工Review，大概率会漏掉。
五、WorkBuddy使用技巧
经过这次实践，总结几个能让WorkBuddy发挥最大价值的使用技巧：
5.1 描述需求时，提供充分的上下文
不要只说"帮我写个上传接口"，而是告诉AI：
- 项目分层规范（Controller → Service → ServiceImpl）
- 技术栈版本号（Java 1.8、Spring Boot 2.3.12、Element UI 2.13.0）
- 已有的基类或工具类（继承BaseController）
版本号尤其重要——上面Bug 1和Bug 6都是因为版本差异导致的。
5.2 开发完成后，务必进行AI代码审查
别只把WorkBuddy当作代码生成器。它最强大的能力之一是代码审查——从逻辑正确性、API兼容性、边界处理等多个维度检查代码。
审查指令示例：
请对我刚写的Word转Markdown代码进行审查，重点关注： 1. API兼容性（Apache POI 3.17、Element UI 2.13.0、marked@4） 2. 逻辑正确性（格式转换是否准确） 3. 边界处理（空文件、大文件、异常格式） 4. 前后端联调可能的问题
5.3 多轮迭代，逐步细化
第一轮生成的代码可能不完美，但这没关系。可以这样操作：
- 先让AI生成骨架代码
- 人工调整业务逻辑
- 让AI审查修正后的代码
- 针对审查意见逐项修复
这种"人机协作"模式比纯手写或纯AI生成都高效。
5.4 善用WorkBuddy的金融数据查询能力
除了开发，WorkBuddy还内置了金融数据查询能力。有时候需要查行业数据做技术选型参考，比如某个开源库的社区活跃度、竞品对比等，直接用自然语言提问即可。
六、写在最后
WorkBuddy不是要替代开发者，而是把重复性的、容易出错的环节交给AI，让开发者将精力集中在核心业务逻辑上。这次Word转Markdown的开发，最让人受益的不是AI帮忙写了多少代码，而是代码审查环节避免了线上事故——如果删除线逻辑Bug和上传校验Bug流入生产环境，排查成本远大于现在。
如果你也在使用WorkBuddy开发，强烈建议完成后加一轮代码审查，这个习惯的价值会远超预期。
