批量生成重复文案：通知、回复话术、岗位 JD 统一格式一次出

一、问题定义：三类重复文案的共性结构

通知、回复话术、岗位 JD 在业务语境里看似分属三个场景，但把它们放在“批量产出”的视角下观察，会发现高度同构。通知类文本（如系统升级通知、活动规则通知）通常包含时间、范围、动作、影响四个要素；客服回复话术包含场景触发条件、标准答复、兜底方案；岗位 JD 包含岗位名称、职责、任职要求、福利与投递方式。这三类文本的差异主要在字段语义，而非结构形态。

笔者在多个企业内容中台项目中观察到，运营人员手工复制粘贴修改文案时，出错点集中在三处：字段遗漏、格式漂移、版本不一致。字段遗漏指某个通知忘了写生效时间；格式漂移指同一批 JD 里有的用“任职要求”有的用“岗位要求”；版本不一致指话术更新后旧模板仍在被引用。这三类问题都不是“写得好不好”的问题，而是“管得住管不住”的问题。

本文评述：把这三类文案统一处理，本质上是在做“受限自然语言生成”（Constrained NLG）。学术界的 NLG 研究长期关注开放域生成质量，但企业场景的真正痛点是约束满足率与批量一致性。因此本文的分析主线不追求生成文本的“惊艳度”，而追求“可预测、可校验、可回滚”。

从信息论角度看，重复文案的熵值主要来自变量部分，固定骨架部分熵值极低。这意味着把骨架固化、把变量参数化，可以显著降低每次产出的信息处理成本。Reiter 与 Dale 在经典 NLG 架构中提出的“文档规划—微观规划—表层实现”三层结构（Reiter & Dale, 2000），在批量文案场景中依然适用：文档规划对应模板选择，微观规划对应槽位填充，表层实现对应格式渲染。本文评述认为，这套二十多年前的框架之所以仍然有效，是因为它把“说什么”和“怎么说”分离，而批量文案的一致性恰恰依赖这种分离。

二、语料治理：从散落文本到结构化字段

2.1 存量文案的采集与清洗

批量生成的前提是有一批可参考的存量文案。这些文案通常散落在工单系统、客服知识库、招聘平台后台、邮件归档中。第一步是采集，第二步是清洗。清洗的目标不是“让文本变漂亮”，而是“让字段可提取”。常见噪声包括：全角半角混用、多余换行、表情符号、内部代号、临时占位符（如“XXX”“待定”）。

一个实用的清洗规则集可以写成正则管道。以下示例展示如何统一标点与空白（Python 实现，模拟数据）：

import re

def normalize(text: str) -> str:
    # 全角转半角（保留中文标点）
    text = text.replace('　', ' ')
    # 合并连续空白
    text = re.sub(r'[ \t]+', ' ', text)
    # 统一换行
    text = re.sub(r'\r\n?', '\n', text)
    # 去除行首行尾空白
    lines = [ln.strip() for ln in text.split('\n')]
    # 压缩连续空行
    out, prev_empty = [], False
    for ln in lines:
        if not ln:
            if not prev_empty:
                out.append('')
            prev_empty = True
        else:
            out.append(ln)
            prev_empty = False
    return '\n'.join(out).strip()

这段代码本身不复杂，但笔者建议把它固化成团队共享的预处理模块，而不是每次临时写。原因在于：预处理规则一旦不统一，后续字段抽取的准确率会大幅波动，而这种波动很难归因。

2.2 字段抽取与模式归纳

清洗之后是字段抽取。对于通知类文本，可以用“关键词 + 位置”的启发式规则抽取时间、范围、动作；对于话术，可以用“问—答”配对模式；对于 JD，可以用“标题行 + 分节标题 + 列表项”的结构模式。当规则覆盖率不足时，再引入序列标注模型（如基于 BERT 的 Token Classification）作为补充。

这里需要强调一个工程判断：不要一上来就上模型。在字段模式相对固定的场景中，规则抽取的可解释性和可维护性远高于模型，且不需要标注数据。只有当规则维护成本超过模型训练成本时，才值得切换。这个切换点的判断，可以用“规则新增字段的平均耗时”与“模型迭代一轮的平均耗时”做对比。

表 1 三类文案的字段抽取对照（来源：笔者项目实践归纳，模拟整理）

三、模板 DSL：骨架与变量槽位的设计

3.1 为什么需要一层轻量 DSL

直接使用字符串拼接（如 f-string）在字段少、模板少时可行，但一旦模板数量超过几十个、字段出现可选与嵌套，拼接代码会迅速失控。此时需要一层轻量 DSL（Domain Specific Language），把“模板结构”从“程序逻辑”中剥离出来。DSL 的价值不在于语法多优雅，而在于让非工程角色（如运营、HR）也能读懂和修改模板。

模板引擎的选择上，Jinja2、Mustache、Handlebars 都是成熟方案。它们的共同点是“逻辑与视图分离”，区别在于表达式能力与安全边界。笔者建议在批量文案场景中优先选择逻辑能力较弱的引擎（如 Mustache 风格），因为过强的表达式能力容易被滥用，导致模板里塞进业务逻辑，反而破坏可维护性。

3.2 槽位设计的三条原则

槽位（slot）是模板中可被替换的变量位置。设计槽位时，笔者总结出三条实践原则：

1. 语义单一：一个槽位只承载一个语义。把“时间范围”拆成“开始时间”和“结束时间”两个槽位，比合成一个“时间段”更利于校验。
2. 必填与选填分离：必填槽位缺失应直接报错，选填槽位缺失则走默认分支。混在一起会导致“看起来生成了，其实缺了关键信息”。
3. 类型可声明：槽位应声明类型（日期、枚举、自由文本、数字），以便在渲染前做类型校验。这一步能拦截大量低级错误。

以下是一个通知模板的 DSL 示例（YAML 描述 + Mustache 风格占位）：

id: notice_maintenance_v3
type: notice
slots:
  - name: system_name
    type: string
    required: true
  - name: start_time
    type: datetime
    required: true
  - name: end_time
    type: datetime
    required: true
  - name: impact_scope
    type: enum
    values: [全员, 部分用户, 特定区域]
    required: true
body: |
  【系统维护通知】
  尊敬的 {{system_name}} 用户：
  我们将于 {{start_time}} 至 {{end_time}} 进行系统维护，
  影响范围：{{impact_scope}}。
  维护期间部分功能可能不可用，给您带来不便敬请谅解。

这个模板把结构、槽位、类型、正文放在一个文件里，便于版本管理。笔者建议每个模板文件都带 id 与 type，前者用于引用与回滚，后者用于分组渲染。

本文评述：把模板当作“代码资产”而非“文档附件”，是批量文案工程化的关键认知转变。一旦模板进入版本控制，就可以做 diff、做灰度、做回滚，这与软件工程中配置即代码（Configuration as Code）的思路一致。笔者认为，很多团队批量文案出问题，根源就在于模板长期游离于工程体系之外。

四、批量渲染：数据驱动的产出流水线

4.1 数据源与渲染触发

批量渲染的输入通常是一张表（CSV/Excel/数据库视图），每一行对应一条待产出文案。渲染器读取模板、逐行注入变量、输出结果。这个过程可以用脚本完成，也可以做成服务。选择哪种形态，取决于产出频率与调用方。

如果是运营一次性产出几百条通知，脚本足够；如果是客服系统实时生成话术，则需要服务化。笔者建议先用脚本跑通流程，验证模板与字段设计是否合理，再考虑服务化。过早服务化会把尚未稳定的设计固化进接口，增加后续改造成本。

4.2 渲染管道的五个阶段

一个稳健的渲染管道可以拆成五个阶段：读取数据 → 校验槽位 → 选择模板 → 渲染正文 → 输出与记录。每个阶段都应可单独测试。以下是一个简化的管道实现（Python，模拟数据）：

from datetime import datetime
from string import Template

REQUIRED = ["system_name", "start_time", "end_time", "impact_scope"]

def validate(row: dict) -> list:
    errors = []
    for key in REQUIRED:
        if not row.get(key):
            errors.append(f"missing:{key}")
    # 时间顺序校验
    try:
        s = datetime.fromisoformat(row["start_time"])
        e = datetime.fromisoformat(row["end_time"])
        if s >= e:
            errors.append("time_order_invalid")
    except Exception:
        errors.append("time_format_invalid")
    return errors

def render(tpl: str, row: dict) -> str:
    return Template(tpl).safe_substitute(**row)

def run(rows: list, tpl: str) -> list:
    results = []
    for i, row in enumerate(rows):
        errs = validate(row)
        if errs:
            results.append({"index": i, "status": "rejected", "errors": errs})
            continue
        text = render(tpl, row)
        results.append({"index": i, "status": "ok", "text": text})
    return results

这段代码刻意保持了简单，目的是让校验逻辑显式可见。实际项目中，校验规则会更多（如枚举值合法性、文本长度上限、敏感词），但结构不变。先校验后渲染是必须坚持的顺序，否则会产出大量“看似正常实则缺字段”的文本。

4.3 批量产出的性能考量

纯模板渲染的性能瓶颈通常在 I/O 而非 CPU。万级数据量的渲染，单机脚本在秒级即可完成。真正耗时的是数据读取、模板加载与结果写回。因此优化重点应放在批量读写（如一次性读入、批量写出）与模板缓存上，而不是过早引入并发。笔者在实测中（模拟数据，1 万行通知，字段 6 个）观察到，单进程渲染耗时约 1.2 秒，而 CSV 读写耗时约 0.8 秒，两者处于同一量级。这说明渲染本身不是瓶颈。

五、质量评估：一致性、可读性与合规校验

5.1 一致性指标

批量文案的质量首先体现在一致性上。一致性可以从三个维度度量：结构一致性（同类文案的段落顺序是否一致）、术语一致性（同一概念是否用同一词）、格式一致性（标点、空格、编号风格是否统一）。这三个维度都可以用规则自动检查。

结构一致性可以用“段落指纹”比对：把每条文案按空行切段，对每段取前若干字符做哈希，比较同类文案的指纹序列是否一致。术语一致性可以维护一份术语表，扫描文案中是否出现同义异形词。格式一致性可以检查标点是否全角、编号是否连续。

5.2 可读性评估

可读性评估在中文场景下比英文更复杂，因为缺乏像 Flesch-Kincaid 那样被广泛接受的单一指标。实践中可以组合使用平均句长、平均段长、专业术语密度、被动语态比例等指标。这些指标不追求绝对精确，而追求“批次内可比”。也就是说，同一批通知的可读性指标应落在相近区间，出现离群值就值得人工复核。

表 2 批量文案质量评估维度（来源：笔者实践归纳，模拟整理）

5.3 合规校验

合规校验是批量文案不可省略的一环。通知类文本可能涉及承诺性表述（如“保证”“绝对”），话术可能涉及夸大宣传，JD 可能涉及就业歧视性表述（如性别、年龄、地域限制）。这些都需要在渲染后、发布前拦截。

合规词库的维护是一个持续过程。笔者建议把词库分为“硬拦截”与“软提示”两级：硬拦截直接阻断发布，软提示标记待人工确认。分级的好处是避免误杀导致流程频繁中断，同时保留对高风险表述的强控制。

本文评述：合规校验常被当作“最后一道关”，但笔者认为它应该前移。在模板设计阶段就标注哪些槽位属于高风险槽位（如涉及金额、时间承诺、资格限制），渲染时对这些槽位做重点校验，比事后全文扫描更高效，也更不容易漏。

六、大模型辅助：边界、风险与混合架构

6.1 大模型能做什么，不能做什么

大语言模型在批量文案场景中确实有用武之地，但需要明确边界。它能做的是：从存量文案中归纳模板、对变量做自然语言改写、生成候选话术供人工筛选、对可读性做润色建议。它不适合做的是：作为唯一的事实来源、承担强约束的格式输出、在没有校验的情况下直接发布。

原因在于大模型的输出具有概率性，同一输入可能得到不同输出。而批量文案的核心诉求恰恰是确定性。把概率性组件放在确定性流程的关键路径上，会引入不可控的波动。因此笔者主张采用混合架构：模板引擎负责确定性渲染，大模型负责辅助性生成与润色，两者通过明确的接口衔接。

6.2 混合架构的接口设计

混合架构的关键是接口设计。一个可行的方案是：模板引擎产出“骨架文本 + 槽位清单”，大模型只被允许改写槽位内的自由文本，不允许改动骨架。这样既保留了结构确定性，又利用了模型的自然语言能力。改写结果需要经过长度、敏感词、格式三重校验后才能回填。

# 伪代码：受限改写
skeleton = render_template(tpl, row)        # 确定性骨架
slots = extract_free_text_slots(tpl, row)   # 仅自由文本槽位
for s in slots:
    candidate = llm.rewrite(s.text, style="正式")
    if passes_checks(candidate, s.constraints):
        skeleton = skeleton.replace(s.placeholder, candidate)
    else:
        # 校验不通过则保留原值
        pass
return skeleton

这个设计的要点是“失败即回退”。模型改写不通过校验时，保留模板原值，而不是让流程失败。这样即使模型不稳定，整体产出仍然可用。

6.3 关于“模型替代模板”的思辨

随着模型能力提升，一种观点认为可以直接让模型生成整篇文案，模板将变得多余。本文评述认为，这种观点在开放域创作中成立，但在批量强约束场景中不成立。原因有三：其一，批量场景要求可审计，模板的每一步替换都可追溯，模型的黑箱输出难以满足；其二，批量场景要求低成本重复，模板渲染的边际成本趋近于零，而模型推理有显著成本；其三，批量场景要求格式稳定，模型的格式遵循能力虽在提升，但仍不如模板引擎可靠。

因此更可能的演进方向是“模板负责结构，模型负责表达”，而非一方取代另一方。这与软件工程中“声明式配置 + 智能补全”的关系类似。

七、工程落地：目录结构与操作步骤

7.1 推荐的目录结构

copy-factory/
├── templates/          # 模板文件（YAML/Mustache）
│   ├── notice/
│   ├── reply/
│   └── jd/
├── data/               # 输入数据（CSV/JSON）
├── rules/              # 校验规则与词库
│   ├── required.yaml
│   ├── compliance.txt
│   └── terms.csv
├── src/
│   ├── loader.py       # 模板与数据加载
│   ├── validator.py    # 槽位与合规校验
│   ├── renderer.py     # 渲染引擎
│   └── cli.py          # 命令行入口
├── output/             # 产出结果
└── tests/              # 单元测试

这个结构把模板、数据、规则、代码、产出分开，便于协作与版本管理。模板与规则可以交给非工程角色维护，代码由工程角色维护，职责清晰。

7.2 从零到一的操作步骤

1. 收集样本：每类文案收集 30–50 条存量样本，覆盖主要变体。
2. 归纳字段：人工标注样本中的字段，统计字段出现频率，确定必填与选填。
3. 编写模板：按字段编写模板文件，标注槽位类型与约束。
4. 准备数据：把待产出的变量整理成 CSV，列名与槽位名一致。
5. 跑通渲染：用脚本渲染 10 条，人工检查格式与内容。
6. 补充校验：根据检查结果补充必填校验、格式校验、合规校验。
7. 批量产出：全量渲染，输出结果并保留校验日志。
8. 抽样复核：按 5%–10% 比例抽样人工复核，记录问题并回流到模板与规则。

这八步看起来朴素，但每一步都有明确的产出物。笔者建议把每一步的产出物都纳入版本控制，这样当产出质量出现波动时，可以快速定位是哪一步发生了变化。

7.3 可拓展的学习资源

以下资源对理解模板引擎与批量文本处理有帮助：

• Jinja2 官方文档：https://jinja.palletsprojects.com/（模板语法与沙箱机制）
• Mustache 规范：https://mustache.github.io/（逻辑无关模板设计）
• Python string.Template 文档：docs.python.org/3/library/string.html
• 正则表达式在线测试：https://regex101.com/（清洗规则调试）
• NLG 综述（Reiter & Dale, 2000）：aclanthology.org/J00-1002/

八、前沿预判与总结

8.1 三个值得关注的方向

第一，模板与模型的联合优化。当前模板与模型是分离的，未来可能出现“模板感知的生成模型”，即在生成时显式接收模板约束，从而在保持结构的同时提升表达自然度。第二，批量文案的自动评估。目前质量评估仍依赖规则与抽样人工，未来可能出现针对批量文案的专用评估模型，输出一致性、可读性、合规性的综合评分。第三，模板的可视化编辑。让非工程角色通过界面编辑模板、实时预览、一键发布，降低模板维护门槛。

8.2 总结

批量生成通知、回复话术与岗位 JD，表面是“写文案”，实质是“建流水线”。本文提出的“模板骨架 + 变量槽位 + 约束校验”主线，把这项工作从手工劳动转化为可复用、可校验、可回滚的工程流程。核心结论有三：其一，结构确定性与表达灵活性的分离是批量文案一致性的基础；其二，校验必须前移并与渲染解耦，才能拦截低级错误；其三，大模型是辅助而非替代，混合架构比单一路线更稳健。

笔者认为，随着企业内容量持续增长，批量文案工程会从“运营技巧”演变为“基础设施”。越早把模板、规则、校验沉淀为资产，越能在后续的规模化产出中受益。