前言

开篇先聊一个真实案例。作为后端开发，最近接到一个需求：在现有系统中增加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，有几个甚至是我写代码时完全没意识到的隐患。

这篇文章就把完整流程和踩坑经验记录下来，希望对有同样需求的人有所启发。

一、整体开发流程

先对比两种工作方式，更直观感受效率提升：

效率对比非常直观：类似功能以前从开发到提测至少需要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`组件版本不兼容

问题：前端代码里使用了``组件展示文件信息，但Element UI 2.13.0根本不支持这个组件——它是Element Plus才有的组件。

修复：换用``或``替代。

? 踩坑经验：AI生成前端代码时，偶尔会混入Element Plus的组件。一定要确认你项目实际使用的Element UI版本号。

Bug 2：删除线逻辑错误

问题：Word中的删除线（``）转Markdown时，判断逻辑写反了——本应加`~~`包裹的文本没有加，而没有删除线的文本反而被包起来了。

修复：修正条件判断逻辑。

// 错误写法
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`钩子未触发

问题：前端``组件的`: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`方法缺失

问题：``配置了`:limit="1"`和`:on-exceed="handleExceed"`，但`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);

四、踩坑总结

用一张表来更清晰地对比：

最关键的是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 多轮迭代，逐步细化

第一轮生成的代码可能不完美，但这没关系。可以这样操作：

1. 先让AI生成骨架代码
2. 人工调整业务逻辑
3. 让AI审查修正后的代码
4. 针对审查意见逐项修复

这种"人机协作"模式比纯手写或纯AI生成都高效。

5.4 善用WorkBuddy的金融数据查询能力

除了开发，WorkBuddy还内置了金融数据查询能力。有时候需要查行业数据做技术选型参考，比如某个开源库的社区活跃度、竞品对比等，直接用自然语言提问即可。

六、写在最后

WorkBuddy不是要替代开发者，而是把重复性的、容易出错的环节交给AI，让开发者将精力集中在核心业务逻辑上。这次Word转Markdown的开发，最让人受益的不是AI帮忙写了多少代码，而是代码审查环节避免了线上事故——如果删除线逻辑Bug和上传校验Bug流入生产环境，排查成本远大于现在。

如果你也在使用WorkBuddy开发，强烈建议完成后加一轮代码审查，这个习惯的价值会远超预期。