LLM 文档生成与审阅生产化：从事实到可签发交付物

合同草案、投标书、尽调报告、授信材料、客服工单总结和周报，看起来都属于“让模型写一篇文章”。真正上线后，它们却是不同的业务交付物：有模板、字段、事实来源、必填条款、责任人、审批链、版本和留档要求。模型能否写得流畅只是最后一公里；是否能保证数字正确、引用可追溯、敏感内容不越权、修改不会丢失，才决定系统能否进入生产环境。

本文讨论的是文档生成系统，而不是通用聊天。它与 结构化输出、人工审批与异常交接、多模态输入接入 和 企业 Connector 增量同步与撤权 共同组成一条可交付业务结果的链路。

一、先定义边界：模型负责表述，不是事实系统

一份业务文档至少有四类内容，处理方式不能混在一起：

内容	例子	正确来源与控制
硬事实	客户名称、合同金额、日期、产品型号	CRM、ERP、已审批表单；读取后冻结快照
规则和条款	免责声明、法务模板、品牌措辞	受版本管理的模板或条款库，禁止模型改写
推导结果	合计、税额、期限、风险等级	规则引擎、SQL 或计算工具；模型不得心算替代
可生成表述	摘要、背景、会议纪要、行动建议	模型在明确上下文、语气和长度约束下生成

这张表是系统设计题的第一落点。若把全部输入拼入 Prompt，模型会把缺失字段“补全”，也可能悄悄改写锁定条款。生产系统应把事实、计算、规则和自然语言分别建模，并把模型视为一个受约束的文本变换器。

面试中的一句话版本：我不让 LLM 成为单一事实源。系统先将可信事实与不可改写条款锁定，模型只为允许生成的字段产出候选内容，最终由校验和审批决定是否签发。

二、交付物数据模型：文档不是一段 Markdown

最小可审计模型可以如下拆分：

document_request
  -> business_object_ref / requester / intended_use / retention_policy
document_snapshot
  -> approved source records / source versions / calculation results
template_revision
  -> layout / locked clauses / editable slots / conditional blocks
document_draft
  -> structured sections / generation metadata / citations
review_revision
  -> reviewer comments / redlines / decision / reason
rendered_artifact
  -> docx/pdf/html bytes / checksum / render engine version
publication
  -> approver / signed_at / delivery channel / access policy

document_snapshot 不是优化项，而是可复现性的基础。用户上午发起一份报价单，下午 CRM 中的联系人或价格被修改时，审阅中的草案不能在无提示的情况下跟着变。草案必须指向发起时的事实快照；如需刷新，创建新的 revision，并把变化显式展示给审阅者。

每份对象都要有稳定 ID、版本号、创建者、租户、权限范围、保留期限与内容哈希。渲染后的 PDF/DOCX 也不能只保存文件路径；需要保存字节哈希与渲染器版本，以便在审计时证明“签发的是哪一份”。

三、推荐流程：先装配证据，再生成可编辑槽位

一个可靠的主流程不是“一次大 Prompt”，而是有明确闸门的流水线：

请求校验
  -> 权限与业务对象读取
  -> 事实快照、计算与引用收集
  -> 选择已发布模板 revision
  -> 生成文档计划（sections / slots / evidence requirements）
  -> 逐槽位生成、引用绑定与 schema 校验
  -> 规则校验、敏感信息扫描、渲染预览
  -> 人工审阅 / 修订 / 批准
  -> 生成最终制品、签发、归档与分发

1. 请求校验与授权

请求至少携带用途、业务对象、语言、模板类型和目标受众。系统服务端重新根据调用者身份计算可访问字段，不能相信前端传来的 customer_id 或 include_internal_notes=true。对于导出、外发、合同和财务材料，还应检查操作范围、数据地域、审批策略与限额。

2. 事实包与证据账本

将模型可见的信息整理为一个有类型的 fact_pack，而不是长篇原始资料：

{
  "snapshot_id": "snap_20260720_01",
  "facts": [
    {"key": "customer.legal_name", "value": "示例科技有限公司", "source": "crm:account/42", "confidence": "authoritative"},
    {"key": "quote.total_cny", "value": 128000, "source": "pricing:quote/81", "confidence": "authoritative"}
  ],
  "citations": [
    {"id": "ev_17", "locator": "proposal-v3.pdf#p12", "permission": "internal"}
  ],
  "unknowns": ["customer.tax_registration_number"]
}

其中 unknowns 很重要。对缺失信息显式建模，系统才会生成待补字段或发起澄清，而不是诱导模型编造一个看起来合理的号码。来源应包含记录版本或内容哈希，引用要能定位到段落、页码或数据行。

3. 生成计划与槽位隔离

先要求模型输出可验证的文档计划，例如需要哪些章节、每一节引用哪些证据、哪些字段只能由模板填入。再分别生成 executive_summary、risk_analysis、next_steps 等允许编辑的槽位。每个槽位规定：最大长度、允许事实键、是否必须引用、是否可使用外部知识、语言与风格。

分槽位的收益是：失败可局部重试、敏感段落可使用更严格模型、评测能精确到字段，审阅者也能仅重生成一段而不是毁掉整篇文档。

四、模板系统：把不可协商的规则从 Prompt 中拿出来

模板应被视作可发布的产品配置，而不是放在代码仓库的一份 Word 文件。一个模板 revision 至少包含：

template revision
  -> metadata: owner / status / effective dates / supported locales
  -> layout: headings, tables, styles, page elements
  -> locked blocks: clauses that LLM and editor cannot change
  -> slots: type, schema, max length, evidence and reviewer requirements
  -> conditional rules: when a section appears or is forbidden
  -> required acknowledgements and approval policy

锁定块应在渲染层合成，不能只靠“请不要改写以下条款”的提示。对于金额、法务措辞、商标和页脚，直接由模板变量或受控组件填充；模型永远拿不到修改其源代码的入口。

条件块由规则引擎决定。例如金额高于阈值时自动增加合规声明，涉及特定地区时切换隐私条款，医疗/金融用途要求额外复核。模型可以解释为什么某个区块存在，但不应决定法律义务是否适用。

五、数值、表格与引用：三类最常见的“看起来对”

数值必须由工具计算

模型输出的“总价 128,000 元”只能当展示候选，不能作为交易事实。金额、日期差、税率、配额、排名和风险分必须通过确定性函数、数据库查询或审批后的上游结果获取。生成前后分别校验：

rendered quote.total == computed quote.total
all required line_items are present exactly once
currency / rounding / timezone follow the template policy

如果展示文本与事实包不一致，系统应阻断签发并记录字段级错误；不要把“让模型再检查一次”当成唯一修复策略。

表格使用结构化中间表示

先生成或组装 JSON 行列数据，再由渲染器填充 DOCX/HTML/PDF 表格。结构包括列 schema、排序、合计行、单元格格式和分页规则。纯文本表格一旦转换为 Word，往往出现列宽溢出、合计错位、分页断裂或复制后不可编辑的问题。

引用绑定到 claim，而非放在文末装饰

每个关键结论保存 claim_id -> evidence_ids 映射。渲染时可在句末显示脚注、链接或内部证据编号。校验器要检查：高风险章节是否无引用、引用是否在当前调用者权限内、证据是否过期、结论是否把“推测”伪装成“事实”。

六、审阅、红线与并发编辑：人不是最后一个按钮

人工审批必须看得见模型做了什么。审阅界面至少提供：

• 与上一个 revision 的字段级和段落级 diff；
• 每一段的来源、生成时间、模型/Prompt/模板 revision；
• 对“保留、重写、人工修改、删除”的明确操作；
• 评论、责任人、截止时间以及拒绝原因；
• 只读事实快照与最终渲染预览的并排查看。

人工编辑后的内容要标记作者和覆盖范围，不能在下一次“重新生成全文”时被静默覆盖。推荐的状态机为：

created -> assembling -> generating -> validating -> in_review
  -> approved -> rendering -> published -> archived
                    |             |
                    -> revision_requested
                    -> rejected / expired / cancelled

并发情况下采用乐观锁：编辑请求携带 draft_revision，版本落后时返回冲突与差异，而不是“最后写入者获胜”。对于高风险审批，审批人在点击批准时还要二次确认所见 revision 等于当前 revision。

七、渲染与签发：内容正确不等于成品可用

输出到 HTML、DOCX、PDF 需要独立的异步渲染任务。渲染工人只接收已验证的中间表示，运行在受限环境中，禁用任意网络请求和不受信任的宏。应做四层检查：

1. 结构检查：所有必填槽位、签名区、页脚和引用均存在。
2. 视觉检查：表格溢出、孤行、页码、字体替换、图片分辨率和空白页。
3. 内容回读检查：从 PDF/DOCX 再抽取文本，验证关键字段与源 JSON 一致。
4. 制品检查：计算哈希、存对象存储、附带模板/渲染器版本并设置访问策略。

渲染失败通常是独立可重试任务，不能重新调用模型。这样既避免重复付费，也避免同一草案在重试中产生不同表述。最终签发后将制品设为不可变；任何修改都创建新的文档 revision，而非覆盖旧文件。

八、安全与合规：文档分发比生成更危险

文档系统经常汇聚 CRM、财务、法务、工单和知识库数据，风险不止在模型回答。需要至少覆盖：

• 字段级最小权限：模型上下文、预览、下载和外发均分别授权；脱敏字段不因导出恢复。
• 提示注入隔离：外部附件和检索结果是数据，不得改变模板、审批策略或工具权限。
• 敏感信息处理：检测身份证、账户、健康、密钥等内容；按场景遮蔽、阻断或走加签审批。
• 外发控制：收件人白名单、域名策略、水印、下载次数、过期链接和撤回能力。
• 保留与删除：草案、事实快照、日志和最终制品可能有不同保留期限；删除必须传播到索引、缓存和衍生文件。

审计日志要记录“谁以什么权限访问了哪些事实、用哪个模板生成了哪个制品、谁批准和发送给谁”。日志本身也包含敏感元数据，应限制访问并避免写入完整 Prompt 或原始证件号。

九、成本、延迟与可靠性设计

长文档的成本往往来自多次重试、全文重生成和重复读取资料。实践中可做：

• 对事实包、模板编译结果和不可变引用做缓存，缓存键包含权限与 revision；
• 对段落生成设 token 预算，并在超限时保留已完成槽位，提示用户缩小范围；
• 使用任务队列拆分“生成、评测、渲染、病毒扫描、分发”，每一步都可幂等；
• 用 request_id + document_revision + stage 作为幂等键，避免刷新页面重复创建多份文件；
• 为模型调用、渲染和下载设置独立超时、重试上限与死信队列。

不要只监控“接口成功率”。至少记录草案完成率、字段校验失败率、人工修改比例、审批拒绝率、渲染失败率、端到端时延、每份文档 token/成本，以及高风险内容拦截率。人工修改率持续高并不一定是模型差，也可能意味着模板槽位定义不清或事实数据质量差。

十、评测：衡量能否交付，而不是文采

离线评测集应按文档类型和风险分层。每个样本包含输入事实、正确的计算结果、需要的条款、允许引用、预期审批结果和故意缺失/冲突数据。核心指标包括：

指标	含义
factual field accuracy	关键字段与权威快照一致的比例
clause coverage	必填条款和条件块的覆盖率
citation support	关键 claim 有可访问证据支持的比例
unsupported-claim rate	无来源或超出证据的断言比例
render pass rate	成品通过结构与视觉校验的比例
reviewer edit distance	人工修改字数/字段数，按风险加权
approval precision	系统要求人工复核的案例中，真正高风险案例的覆盖情况

线上采用影子生成或小流量灰度，把候选文档与人工基线比较。只有模板、模型、提示、渲染器和策略都版本化，出现回归时才能定位究竟是生成质量、数据、模板还是渲染导致的问题。

十一、系统设计题：设计企业投标书生成平台

面试官问“如何设计自动生成投标书或尽调报告的平台”时，可以按以下顺序作答：

1. 范围和风险分层：先确认文档类型、是否可外发、是否含合同/财务结论、峰值并发与 SLA；高风险文件必须人工批准。
2. 核心对象：请求、事实快照、模板 revision、草案 revision、审阅记录、渲染制品和发布记录分开存储。
3. 主链路：服务端鉴权后拉取字段级授权的数据，调用规则/计算服务，编译模板，分槽位生成和校验，再进入审阅与异步渲染。
4. 正确性保障：金额和日期不用模型计算；锁定条款由模板渲染；关键结论绑定证据；渲染后回读检查。
5. 可靠性与成本：工作流状态机、幂等键、checkpoint、队列、局部重试和缓存；失败任务可从相同快照恢复。
6. 安全审计：最小权限、脱敏、外发策略、审批、不可变制品和全链路审计。

架构图可以概括为：

Web / API
  -> Policy & Authorization
  -> Document Orchestrator ----> CRM / ERP / Knowledge sources
       |          |                    |
       |          -> Rules & Calculator <- Fact snapshot store
       -> Template service -> Slot generation -> Validator
       -> Review service -> Render queue -> Artifact store -> Delivery
                          \-> Audit / metrics / evaluation

关键取舍是：低风险内部周报可以允许自动发布，但对报价、合同、投标与监管材料，应牺牲部分自动化率换取事实校验、审批和可追溯性。系统目标不是“生成得最快”，而是“在可接受时延内生成一份可以被业务责任人签字的文档”。

十二、高频面试追问

1. 为什么不直接把 CRM 内容和 Word 模板发给模型？

因为模型无法替代字段级授权、确定性计算和版式控制，也不能保证不改写必填条款。正确做法是先形成权限受控的事实快照，模板在渲染层锁定，模型只处理受限槽位，并由校验和审批关口兜底。

2. 如何防止模型杜撰客户数据？

schema 中明确允许 unknown/needs_confirmation，生成前提供事实键白名单，生成后用字段抽取或 claim 校验器比对快照。高风险字段不从自由文本抽取，而由模板变量直接渲染；发现不一致时阻断发布并保留错误证据。

3. 用户要求“再生成一次”，如何避免覆盖人工修改？

只重生成用户选定的槽位，新结果作为新的候选 revision；人工编辑区带作者标记和锁，全文重生成需要显式确认。以 revision 做乐观并发控制，批准动作绑定具体 revision。

4. 文档引用的数据后来被撤权或删除怎么办？

按照用途和保留策略处理：对未签发草案，立即使引用失效、阻断继续预览或要求重新生成；对已签发文档，保留必要审计记录但限制访问，并记录撤权时间与影响范围。Connector 的删除墓碑和权限变更必须触发衍生制品检查，不能只删向量索引。

5. 如何证明一次生成可审计？

保存请求身份和策略决定、事实快照版本、模板/Prompt/模型版本、槽位输出、校验结果、人工评论与决定、渲染器版本和最终文件哈希。审计者应能从成品反查到每个关键字段和结论的来源。

十三、60 秒项目讲法

“我做的不是通用文本生成器，而是一个企业文档交付工作流。系统先根据租户和字段权限冻结 CRM、报价与知识库的事实快照，金额等派生值由规则服务计算。模板把法务条款和品牌元素设成不可变区，LLM 只在带 schema、证据要求和长度上限的槽位中生成摘要与建议。随后我们做字段一致性、引用、敏感信息和渲染回读校验；高风险文档进入带 revision diff 的人工审批。最终制品按哈希归档，并记录事实、模板、模型、审阅和渲染版本。这样系统在模型输出不稳定时仍能保证业务文档可复核、可追责、可安全分发。”

这段回答同时覆盖了 LLM 应用开发岗最常被追问的四件事：模型边界、系统正确性、生产可靠性和业务风险控制。