使用场景
文档表单能力最适合“标准文档 + 可变信息 + 结果输出”这类业务。下面列举一些更贴近企业真实落地的用法。
除了文档生成，它还特别适合“边填写、边收集结构化数据”的场景，例如登记、申报、审批录入、问卷采集、病历采集、访谈记录等。
阅读建议
你可以按三类目标来读这一页：
- 想做模板与填写：优先看场景 1、3、4、10、11、12
- 想做程序出文：优先看场景 1、2、5、8、14、15
- 想做展示、归档与协同：优先看场景 7、9、13、14
场景 1：合同 / 协议生成
适用于劳动合同、采购合同、保密协议、服务协议等场景。
常见痛点：
- 合同骨架固定，但甲乙方、金额、周期、签署日期等字段反复变化
- 业务人员直接改 Word，容易误改条款或漏改字段
- 后端直接拼合同 HTML，条款排版维护成本高
推荐做法：
- 模板制定人先用
design模式制作合同模板 - 用变量定义公司名称、签约主体、金额、日期、附件说明等字段
- 固定条款用内容锁定保护
- 批量出合同时优先通过
autofill + form.values自动生成 - 最终结合导出输出 Word / PDF
场景 2：人事入转调离与证明开具
适用于 offer、入职承诺书、在职证明、离职证明、岗位调整通知等场景。
常见痛点：
- HR 高频生成同类文档，字段来源分散在 HR 系统
- 同一份文档需要多部门审核，格式要求严格
推荐做法：
场景 3：采购、报销、审批类业务单据
适用于采购申请、付款申请、费用报销说明、立项申请等场景。
常见痛点：
- 单据正文既有固定说明，也有动态字段
- 需要校验金额、日期、单选项、说明项是否完整
推荐做法：
- 用文本、数字、日期、单选、多选等变量描述业务字段
- 在
fill模式下由申请人手工填写 - 通过规则约束金额、日期、联系方式等格式
- 在
form.onSubmit中拿到结构化变量值，接入审批流、后端保存或业务统计
场景 4：登记、采集与信息上报
适用于报名登记、信息采集表、问卷、调研记录、回访问卷、随访记录、电子病历采集等场景。
常见痛点：
- 既需要一份可读、可归档的文档结果，又需要把字段值回收到系统
- 传统在线表单只能收集数据，不适合承载复杂文档结构和最终归档文本
推荐做法：
- 用文档模板定义固定说明、填写规范和变量区
- 用
fill模式让用户完成录入 - 在
form.onSubmit中直接拿到结构化变量值 - 同时保留文档结果，用于展示、归档或继续导出
场景 5：项目交付与客户报告
适用于周报、月报、验收报告、巡检报告、项目总结等场景。
常见痛点：
- 文档排版复杂，既有固定章节，也有项目差异内容
- 同类报告经常需要替换表格、说明、截图、签章
推荐做法：
- 固定章节做成模板
- 项目名、客户名、时间范围、负责人等做成变量
- 报告中的复杂说明区用富文本变量承接程序生成内容
- 图片、二维码、签名、印章等通过图片类变量接入
- 最终导出为 PDF/Word 对外交付
场景 6：通知、公告、制度确认单
适用于公司通知、培训签到确认、制度签收、活动须知等场景。
常见痛点：
- 标题和正文大部分固定，但签收人、部门、确认时间等信息需要填写
- 既要避免正文被误改，又要保留少量可填区域
推荐做法：
- 模板正文固定部分用内容锁定保护
- 仅开放变量区供填写
- 需要电子签收时，使用签名或印章变量
场景 7：法务 / 合规 / 风控模板维护
适用于长期维护的制度模板、法务条款模板、外部通知模板。
常见痛点：
- 模板会持续迭代，但改动过程缺少审阅留痕
- 发布出去的版本和草稿容易混在一起
推荐做法：
场景 8：后端批量生成个性化文档
适用于批量发函、批量通知、批量证明、批量协议生成。
常见痛点：
- 同一模板面向不同人员、不同组织、不同业务单生成不同文档
- 前后端各自维护一份模板，最终总会漂移
推荐做法：
- 统一使用文档模板作为唯一来源
- 后端只提供变量值，不再维护独立的字符串模板
- 通过
autofill + form.values生成最终文档 - 富文本变量仅在需要生成表格、复杂段落时使用
- 对每份生成结果继续串联 Umo Editor Next 的导出能力，批量输出 Word、PDF 等正式文件
这类场景特别适合：
- 批量生成劳动合同、报价单、告知函、授权书
- 批量生成项目报告、客户通知、结算确认单
- 批量生成需要归档或对外交付的 PDF / Word 正式稿
场景 9：多人协作编制模板
适用于产品、法务、运营、人事等多个角色共同维护模板。
常见痛点：
- 不同角色会同时修改模板说明、字段文案、填写规范
- 模板维护与上线边界不清晰
推荐做法：
场景 10：系统预填后人工补录
适用于审批发起、客户建档、住院登记、项目立项、售前建单等场景。
常见痛点：
- 一部分字段系统里已经有了，另一部分仍需要人工补充
- 如果完全从空白开始填写，重复录入很多基础信息
- 如果直接生成最终文档，又缺少人工确认和补录环节
推荐做法：
- 在
fill模式下通过form.values预填已有字段 - 让填写人只补充系统中没有的数据
- 提交时通过
form.onSubmit一次性回收完整结果 - 需要重置时，字段会回到这份预填默认值，而不是全部清空
这类场景特别适合：
- 先由 CRM、HR、HIS、ERP 等业务系统预填基础信息
- 再由业务人员补充备注、说明、补充材料、签名等字段
场景 11：驳回补填、草稿恢复与续填
适用于审批退回重填、登记表补充、病历续写、调查问卷中断后继续填写等场景。
常见痛点：
- 用户提交失败或被驳回后，需要从历史结果继续修改
- 已填写内容如果不能回填，用户需要重复录入
- 重置、重开、续填之间的默认值边界容易混乱
推荐做法：
- 把历史提交结果或草稿值重新写入
form.values - 继续使用
fill模式承接补填 - 在
form.onSubmit中回收本次更新后的完整字段值 - 如需保存模板或当前文档，也可在
onSave中同步拿到form.values和form.definitions
这类场景的优势在于：
- 用户可以基于已有结果继续填写，而不是从零开始
- 表单重置会回到当前这份回填值，便于做“驳回后修改”而不是“全部清空”
场景 12：模板发布前预演与字段核对
适用于法务模板发布、行政通知上线、制度模板更新、业务单据上线前检查等场景。
常见痛点：
- 模板制定人在设计态下只能看到变量占位，难以判断填写体验是否合理
- 字段顺序、说明文案、必填规则、右侧表单布局容易在上线前漏检
推荐做法：
- 在
design模式下完成模板设计 - 通过工具栏中的预览能力切换到填写态预演
- 重点检查字段顺序、提示文案、必填规则、表单面板布局是否符合预期
- 确认无误后再发布模板或交给业务系统接入
场景 13：生成结果在线只读展示
适用于审批查看、归档查阅、通知结果展示、病历浏览、客户结果确认等场景。
常见痛点：
- 业务页面只想展示最终结果，不希望用户继续修改
- 传统表单页能看到字段值，但看不到完整文档语义和版式
- 直接展示模板正文，又会混入占位变量或填写控件
推荐做法：
- 当变量值已经准备好时，使用
form.mode = 'result' - 让页面直接展示结果态文档，而不是继续进入填写态
- 需要对外查看、归档查阅时，可继续结合导出能力输出 PDF / Word
这类场景特别适合：
- 审批节点查看最终成文效果
- 业务系统中的只读详情页
- 电子病历、知情同意书、确认单等结果浏览页
场景 14：导出前确认与在线预览
适用于合同签发前确认、报告交付前复核、通知发布前审查、批量出文抽检等场景。
常见痛点：
- 导出前需要先确认结果版式、字段值和局部内容是否正确
- 直接导出后再返工，效率低且容易产生错误版本
推荐做法：
- 先通过
result模式或程序填充后的结果文档进行在线确认 - 核对变量值、富文本区域、签名/印章/二维码等内容是否完整
- 确认无误后再进入 Word / PDF / 图片导出链路
这类场景特别适合：
- 正式签发前的人审确认
- 批量生成后的抽样检查
- 需要“先看结果、再导出正式件”的业务流程
场景 15：程序生成后转普通文档继续编辑
适用于自动生成初稿、批量生成后人工润色、系统成文后补充说明、标准模板生成后个别调整等场景。
常见痛点：
- 程序已经生成了一份接近最终结果的文档，但仍需要人工做少量调整
- 如果始终停留在表单态，后续编辑会受到变量链路约束
推荐做法：
- 通过
fillFormValues(values, { disableForm: true })先生成结果文档 - 生成后关闭表单能力，把结果直接写回编辑器正文
- 后续按普通文档继续编辑、保存、评论或导出
这类场景特别适合：
- 系统先自动生成合同、报告、函件初稿
- 业务人员再补充个性化说明、附件文字或局部润色
- 最终再保存、归档或导出为正式文件
与其他功能的联动说明
- 模板管理：文档表单负责“模板内部如何定义变量和填写规则”，模板管理负责“模板如何被业务系统读取、列表化、维护和下发”。
- 内容锁定：当模板中既有固定条款又有变量区时，建议把固定段落锁定，只给填写人暴露变量填写入口，避免误改正文结构。
- 评论：评论适合承载“填写说明、异常沟通、审批意见、补件要求”；文档表单负责承载“最终应填什么值”。
- 修订：修订更适合模板维护期，而不是最终填写期。模板条款更新、字段文案更新、填写说明调整，都建议在修订开启状态下进行。
- 历史版本：对于长期维护的模板，建议把每次上线的模板保存为一个版本；对于关键生成结果，也可以在流程节点保存版本，便于回溯。
- 文档导出：表单填写或程序填充完成后，通常都会进入导出链路：
- Word：继续线下流转或归档
- PDF：固定版式对外交付
- 图片：海报式通知、结果快照、移动端分享
- 批量导出：如果你的业务是批量生成文档，推荐把“程序填充 + 导出”作为统一流水线：
- 根据业务数据循环生成不同变量值
- 将变量值批量填充到同一份模板 3 对每份结果继续导出为 Word、PDF 或图片