该做应用还是 Skill?一次本地文档脱敏工具的实践

前段时间，我做了一个本地文档脱敏工具。

最初的想法并不复杂：律师在使用 AI 处理法律文书、合同、扫描件之前，先把文件里的姓名、公司、地址、案号、手机号、身份证号等敏感信息尽量在本地处理掉。

这样，后续再把脱敏后的文本或文件交给在线 AI 做摘要、分析、检索问题生成，就会安全很多。

但做着做着，我发现真正有价值的，并不一定是一个完整的软件。

它一开始其实是一个应用

一开始，按照传统的思路，我想做的是一个完整的可视化应用。有了之前制作案件协作系统的经验，我也是天然认为按照之前的思路做应用（当然，当时还没有出现Skill的概念）。

用户打开网页，上传 PDF 或 Word；后台完成 OCR、识别敏感信息；最后导出脱敏后的 PDF 或 DOCX。听起来很顺，也确实是很多工具产品会选择的路线。我看到网上很多类似的工具也是这样的。

但真正落地以后，复杂度很快上来了。

前端、后端、文件上传、OCR 服务、导出格式、权限控制、部署环境、错误提示、团队分发，每一项都需要维护。工具本身还没真正开始发挥价值，外围工程已经占了很多精力。而且一旦需要调整，工程量也很大 。

后来我重新问自己：这个需求最核心的部分到底是什么？

答案其实很简单：

把文件扔给AI，安全地脱敏出来，然后交给 AI 做后续处理。

逻辑很清晰，目标也很单一，只需要明确处理规则就行，其实我并不需要管处理的过程，是否有必要像传统工具那样，做那么复杂的交互？这么一追问，答案似乎很清晰：一个skill就能解决这个问题了。

于是，这个工具逐渐从一个独立应用，收敛成了一个Skill。

为什么律师场景特别需要这一步

律师使用 AI 时，经常会遇到一个很现实的矛盾。

一方面，我们希望 AI 能帮忙总结案情、整理争议焦点、梳理证据、提炼检索问题，甚至辅助起草文书。

另一方面，原始材料里往往有大量不适合直接外发的信息。客户身份、交易安排、联系方式、公司名称、项目名称、案号、银行账号、票据编号，都可能涉及保密要求。

所以，对我来说，一个更稳妥的工作顺序是：

这个 Skill 的价值就在这里。它不替代律师判断，也不试图直接完成法律分析。它只是把“上传给 AI 之前先处理敏感信息”这件事，变成一个可以反复调用的固定流程。

过程中几个重要取舍

这个 Skill 不是一开始就长成现在这样。

OCR 就调整过几轮。最初我考虑把 OCR 全部放在当前电脑上跑，后来发现更合适的方式，是接入本地或局域网里的 PaddleOCR API。

这样做以后，当前电脑不需要承担太重的 OCR 计算压力。如果以后把 OCR 服务部署到懒猫微服或局域网机器上，Skill 的调用方式也不用大改。

另一个变化是输出格式。

一开始我也希望输出 DOCX。但实践中发现，自动生成 DOCX 很容易出现格式重建不自然、结构不稳定、脱敏结果不好复核等问题。

后来我更倾向于保留两种结果：

这个取舍很现实：PDF 保留版式，Markdown 保留内容。

现在它大概能做什么

目前这个 Skill 可以处理文本型 PDF、扫描版 PDF、DOCX 和图片文件。

它会尽量识别并替换常见敏感信息，比如人名、公司名、项目名、地址、手机号、身份证号、统一社会信用代码、案号、法院名称、银行账号、票据编号、合同编号等。

处理完成后，通常会生成脱敏后的 PDF、Markdown结果，以及实体映射表。

 Skill还是App？应该是根据需求选择

这次实践给我的最大感受是：很多工作问题，不必一开始就做成应用（App）。

如果一件事经常重复，流程相对固定，需要调用本地文件或工具，人工做又很繁琐，那么它就很适合先做成 Skill。

比如文档脱敏、合同关键信息提取、证据目录整理、批量文件重命名、会议纪要清洗、案件材料摘要、法律检索问题生成，都可以从一个小 Skill 开始。

而如果涉及到多人协作、数据沉淀、权限、附件、流程、界面这些边界的时候，再去考虑把它做成应用。

Skill 的价值不是让 AI 凭空变聪明。

它真正有用的地方，是把我们已经知道怎么做的流程固定下来，让 AI 稳定地照着执行。

这比每次重新写一大段提示词更可靠，也更适合团队复用。

最后