用 AI 做了一个文档质量检查工具，踩了几个真实的坑 —— WordCraft-Pro 项目复盘

dvdxfv · 2026 年5 月 15 日 05:31

本文首发于 Trae 社区

这个项目从哪来

我工作中长期接触报告类材料——排版、错别字检查、格式核对，都是些重复但必须做的事。

完全靠人工，效率低还容易漏；完全靠自动化，又处理不了文档里那些模糊的判断（比如「这个标题层级合不合理」「这段引用格式对不对」）。

所以我想做一个AI 辅助的文档质量检查工具，人和 AI 各自干擅长的事。这就是 WordCraft-Pro 的起点。
因为文档类产品天然会涉及隐私和信任问题，所以最早的思路是：

但后来真正开发以后，我发现我想做的已经不是一个 Word 查看器了。
我真正想做的是：

也就是说，我后来做的其实是一个“交互式文档 Workflow”。
而这种 Workflow 在 Web 端更容易快速验证，所以后来项目先转成了 Web 原型。
页面小部分展示

我没有让 AI 直接「做一个完整项目」，而是先拆成几个环节：

每个环节单独验证，通了再往下走。

我原以为在 Web 端渲染一个 Word 文档不是什么难事。

后来发现 Word 文件不是普通文本——它有段落、表格、页眉页脚、样式层级、域代码。光是把文档在浏览器里正确显示，就花了不少精力调渲染引擎。

做到排版检查这个环节时，我以为难点是「识别字号不一致」「字体用错」这类问题。

但实际做下来发现，真正难的是理解文档结构——标题层级是否合理、编号规则是否一致、模板规范是否被遵守。这些东西没有硬性的对错标准，是语义层面的判断。

这个环节我觉得目前做得并不成功，但让我对文档类产品的边界有了更具体的认识。

做这个项目之前，我原以为最花时间的是 Prompt 调优或模型选型。

实际做下来，真正耗时间的是解析格式兼容、导出稳定性、异常处理这些工程细节。这些工作不直接出效果，但少了任何一环，产品就用不了。

AI 产品中，模型只是冰山一角，水面以下是大量的工程化工作。

这个项目用来验证我最近的工具组合思路——按任务选工具，不迷信单一模型：

工具	在这个项目里的用途	使用到的 Skill
Trae	初始阶段快速试原型	brainstorming、dogfood
Claude Code	本地代码修改、多文件批量重构、文件分析	superpower 系列、gstack 系列
Codex	把需求拆成可执行任务，推进功能开发	supabase插件、GitHub插件、浏览器插件、chrome插件
Cursor	日常代码补全、小范围改动	—