当大厂产品经理扎堆热门赛道时，一款深耕公文处理十年的Word/WPS插件却提供了更纯粹的样本。它从排版按钮集合演进为AI Agent可调用的文档处理引擎，其五层功能架构与“开放问题封闭化”的AI化路径，为所有垂直场景工具提供了可复用的方法论。

产品经理的研究对象往往集中在大厂产品和热门赛道，但一些深耕垂直场景的小产品，反而在需求拆解、功能架构、用户工作流理解上提供了更纯粹的样本。

本文复盘的对象是公文处理助手，一款持续迭代超过十年的Word/WPS文档自动化插件。它在没有融资、没有团队、没有投放的情况下，靠功能本身在文秘、行政、标书、法务、高校等人群中存活至今，并在2025至2026年完成了AI化改造。它的功能架构如何从一个“排版按钮集合”演进为“AI Agent可调用的文档处理引擎”，对所有垂直场景工具都有参考价值。

第一步：需求洞察——找到“不能不做但极不想做”的工作

垂直工具的第一性原理是：不要找用户“想做”的事，要找用户“不得不做”的事。

公文处理助手锁定的需求有四个特征：

1. 规则刚性：党政公文必须符合GB/T 9704-2012，论文必须符合各校模板，标书必须符合招标格式——没有“差不多就行”的空间；
2. 操作重复：同一套格式设置要在每份文档、每个章节、每一级标题上反复执行；
3. 错误成本高：页码错误、编号混乱、字号不符，在正式场合是实打实的工作失误；
4. 技能门槛低但耗时高：操作本身不难，新人也能学会，但学会后仍然要消耗大量时间。

这是一个典型的“高确定、低创造、高重复”场景——自动化的价值密度最高。相比之下，“帮用户写一篇好文章”这种需求规则模糊、结果主观、难以标准化，反而不适合作为工具的核心切入点。

产品给垂直PM的启示：评估一个场景值不值得做工具，先问三个问题——规则能否写成明确的清单？执行步骤能否被无歧义地重复？错误结果能否被客观判定？三个问题都是“能”，才是自动化的好土壤。

第二步：功能分层——一个值得借鉴的五层架构

把它的功能体系拆开看，实际上是一个清晰的五层架构，自下而上层层抽象：

第一层，原子操作层。

最底层是对Word/WPS对象的原子级操作：设置字体、设置字号、设置行距、设置缩进、设置页边距、全选、选中标题、移动光标、插入页码、删除空行。每个操作只做一件事、参数明确、结果确定。这一层的设计原则是“高内聚、可组合、无副作用”。

第二层，流程模块层。

原子操作组合成带业务含义的流程模块：批量设置所有节页面参数、通配符批量选择（用正则匹配多级标题）、手动编号转自动编号、所有节插入页码、图片按版心宽度缩放、文本转表格。这一层开始承载领域规则——比如“公文标题用‘一、（一）、1.’三级编号”的知识。

第三层，脚本方案层。

流程模块排列成完整的解决方案，产品内置118个现成方案，如“一键规范公文格式”“自动生成多级目录”“批量导出文档图片”“Excel数据批量生成文档”。用户也可以保存、分享自己的方案。这一层对应的是“用户任务”，而非“软件功能”。

第四层，AI规划层。

2025年6月引入AI，用户用自然语言描述需求，AI在数百个模块构成的受限空间中选择、配置、排列，自动生成脚本方案。这一层解决了长尾需求的“最后一公里”——用户的任务千变万化，118个现成方案不可能覆盖全部，AI让系统从“有限预设”变成“无限组合”。

第五层，Agent接口层。

2026年8月把能力封装成9个命令行开关，供豆包、OpenClaw等外部AI Agent调用。这一层让产品从“人直接使用的工具”变成“AI能力生态中的一个执行服务”，使用入口从插件界面迁移到了AI对话。

这个架构的精妙之处在于：每一层都为上一层服务，但每一层都可以独立使用。不会用AI的老用户可以直接点按钮；会用AI的用户可以自然语言生成方案；有Agent生态的用户可以让外部AI统一调度。这种“分层兼容、渐进智能化”的路径，比一次性推倒重来的AI重构风险低得多。

第三步：AI化的关键设计——开放问题封闭化

很多产品接入AI时的做法是“加一个聊天框，让AI生成内容或代码”，效果往往不稳定。公文处理助手的AI化提供了一个更值得借鉴的范式：不改变底层能力，只改变能力的“编排方式”。

它没有让AI直接写VBA代码（开放空间生成，成功率不可控），而是让AI在预定义模块库中做规划（受限空间规划，每个模块都经过验证）。这一设计在产品层面带来三个好处：

• 可靠性：模块经过十年验证，AI的错误只可能出现在“选错模块、配错参数”，而不是“代码本身有Bug”，错误可枚举、可提示、可纠正；
• 低成本：对大模型的能力要求大幅降低，便宜的DeepSeek模型就能胜任，用户单次任务成本通常不到1元；
• 可审计：AI输出的是纯文本脚本，人可以检查、修改、复用，结果透明而非黑盒。

配套的系统提示词长达1.1MB，本质上是把领域专家的工作流（十三种编写流程、参数换算规则、模块选择约束）显式地教给AI。这给所有垂直产品的AI化提供了方法论：AI能力的上限，取决于你对自身领域知识的结构化程度，而不是模型参数规模。

第四步：交互设计——为“人机协作”而非“全自动”设计

值得注意的是它没有过度承诺“全自动”。官方建议对复杂脚本先单步执行验证，保留了方案的查看、编辑、回放能力。这是一种诚实的人机协作设计：

• AI负责：理解需求、生成方案初稿、处理标准结构、批量重复劳动；
• 人负责：确认目标、处理非标准特例、验证关键结果、承担最终责任。

同时，“后台执行”开关解决了自动化工具的一个核心体验问题：过程不打断用户。Agent操作全程隐藏窗口，用户可以并行工作，这让工具从“占用你注意力的前台任务”变成“静默运行的后台服务”。

第五步：商业模式与增长设计

增长上，它采用了两个零成本机制：一是免费基础功能最大化获客，高级功能赞赏制（12元/2月、36元/半年、66元/年、180元永久）筛选重度用户；二是“发布介绍作品换授权”，把用户转化为内容推广者，形成UGC增长飞轮，这是其在抖音、快手、B站获得自然传播的重要原因。

但从产品经理视角看，它的商业化也暴露了垂直工具的典型短板：定价过低（180元永久，相对WPS AI 599元/年的锚点明显低估价值）、缺乏企业级产品形态（批量授权、发票、私有化部署）、缺乏用户规模的公开度量（竞品不坑盒子公开了34万+用户，建立了可验证的社会证明）。这些都是垂直工具从“好用”走向“好生意”需要补齐的产品能力。

复盘总结：垂直工具的三条方法论

第一，需求选择上，锚定“规则刚性、执行重复、结果可判定”的场景，这类场景的自动化确定性最高、用户价值最可量化。

第二，功能架构上，构建“原子操作—流程模块—任务方案—AI规划—Agent接口”的分层体系，每一层可独立使用、向上组合，为渐进式AI化留足空间。

第三，AI化路径上，把开放问题封闭化、把领域知识结构化、把人机分工显式化，让AI在受控边界内发挥组合规划能力，而不是追求不可控的“完全自动”。

在AI Agent时代，垂直工具的竞争壁垒不再是“有没有AI”，而是“你对具体行业工作流的理解深度，能否被结构化地封装成AI可以可靠调用的能力”。这才是这款十年老插件留给产品从业者的真正启示。