从合同修订到
可信的 AI 工作流

Redlining 指在合同谈判中标记、审阅和回应文字修订。实现时，任务对象应是一处有上下文的变更，而不是把整份合同直接交给模型，期待它一次完成所有判断。

阶段名称对应原文；下面的问题与实现建议为教学分析。Phase 表示演进顺序，不代表具体发布日期。[1]

可以把此类系统设计成三层：文档交互、决策工作流、证据与记忆。每层负责不同的失败模式：定位错误、推断错误、证据错误不应混在一起调试。

三类存储，三种生命周期

设计推论：会话状态允许短期变化；规则必须有权威版本；经验需要带范围和时效。只按“向量数据库 / 缓存”划分，容易忽略数据治理上的差异。

检索质量取决于“查询表达”和“入库表达”能否对应。先明确希望找回的是同一条款、同一谈判意图，还是同一适用政策，再选嵌入文本与过滤条件。

原文分别讨论意图向量和原句锚定，未公开统一查询计划。下表是本文建议的教学拆分。[1]

建议的四道检索检查

1. 授权与范围：先限制允许访问的业务、模板和政策数据。
2. 候选召回：向量搜索或条款锚点搜索找回可能相关的证据。
3. 语义重排：检查责任主体、变更方向和约束是否对齐。
4. 上下文选择：在有限预算中保留相关、有效且不重复的证据，暴露冲突。

OpenSearch 提供搜索中过滤以及其他过滤方式；后置过滤可能让返回候选数不足。具体策略取决于所用引擎和版本，不能假设所有过滤位置效果相同。[4]

运行时学习可以改变下一次给模型看的例子，而不更新模型参数。这里的关键是构建有标签、可过滤的经验库，不能把所有历史对话无差别塞入提示词。

{
  "feedback_id": "synthetic-fb-001",
  "template_id": "demo-services-v3",
  "clause_anchor": "liability.cap",
  "policy_version": "demo-2026-10",
  "original_text": "责任上限为约定费用。",
  "counterparty_text": "责任不设上限。",
  "intent": "移除服务方责任上限",
  "ai_action": "ACCEPT",
  "lawyer_action": "MODIFY",
  "lawyer_final_text": "责任上限为双方另行约定的金额。",
  "lawyer_reason": "保留上限原则，金额需要另行确认。",
  "error_type": "wrong_policy_application",
  "created_at": "2026-10-11T00:00:00Z",
  "review_status": "approved_for_retrieval"
}

这些文字只用于演示反馈结构。“最终采用了什么”和“为什么采用”，比一枚赞踩更接近可复用监督信号。

时间衰减：降低旧经验权重

经验库的三个分离

• 当前政策与历史选择分离：旧案例不能覆盖新版本规则。
• 偏好与真值分离：某次谈判接受一项例外，不代表所有客户都可以接受。
• 训练上下文与评测样本分离：按合同或模板族隔离，避免近重复样本泄漏。

示例配比也应受控。如果历史记录几乎都是接受，模型可能把多数动作当成默认策略。采样可以保证动作覆盖，但应另用真实业务分布评估整体效果。

为此类系统设计清晰的优先级：有效的权威规则约束可行解，经验帮助选择可行解，语气只改变表达。让三者在同一次自由生成中相互竞争，很难解释冲突如何解决。

把“修改条款”变成约束求解

程序容易检测未授权的数字变化；模型更适合辅助检查语义变化。但第二次模型调用仍可能犯错，因此应将校验发现作为可审阅证据，而不是把“模型说通过”当作质量保证。

一个可管理的语气提示结构

任务：改写下面的说明，使其直接、专业、简洁。

不可改变：
- action / policy_constraints / numeric_terms
- 责任主体、承诺范围、必要例外
- 不添加事实、承诺或未获授权的让步

风格要求：
- 用清晰陈述解释建议和依据
- 删除无关寒暄、夸张语气和对抗措辞

输出：
- rewritten_comment
- preserved_constraints
- unresolved_questions

实现建议：工程团队维护输入输出契约，领域专家维护风格示例与内容边界。每次提示版本更新都应跑同一组回归案例。

LangGraph 支持把确定性步骤和模型步骤组织在有状态的图中，并提供持久化与人工介入能力。框架提供编排能力；节点契约、证据优先级与业务正确性仍由应用设计承担。[3]

async def analyze(change, scope):
    # 这三个任务都可仅依赖输入快照
    intent, risk, rules = await gather(
        detect_intent(change),
        assess_risk(change),
        retrieve_current_rules(change.original, scope)
    )

    # 依赖 intent，不能提前假装已拿到意图
    examples = await retrieve_feedback(intent, change.anchor, scope)
    evidence = select_valid_evidence(rules, examples)
    if evidence.missing or evidence.conflicting:
        return needs_review("证据缺失或冲突", evidence)

    decision = await decide(change, intent, risk, evidence)
    clause = None
    if decision.action == "MODIFY":
        clause = await draft_clause(change, decision, evidence)

    comment = await style_comment(decision.comment,
                                  locked=decision.constraints)
    checks = await validate(change, decision, clause, comment, rules)
    if not checks.passed:
        return needs_review("校验未通过", checks)

    return reviewable_suggestion(
        decision, clause, comment, evidence,
        source_version=change.document_version
    )

# 人工批准是独立事件；真正写回前再次检查文档版本
# 未通过校验的结果也可展示，但必须标明待处理原因。

延迟优化先看关键路径

把意图、风险与规则查找记为 Tᵢ、Tᵣ、Tₚ，反馈检索记为 T𝒇。上面的示例先等三项结束再检索反馈，其前半段耗时约为：

进一步可以在意图一完成时就启动反馈检索，不必等风险分支；此时近似变为 max(Tᵢ + T𝒇, Tᵣ, Tₚ)。这是一种调度改进，前提是没有隐藏的数据依赖。

把 AI 放入文档工具，真正困难的是保持“模型看到的文本”与“用户正在编辑的文本”一致。模型输出很准确，如果写错条款或覆盖了后续修订，整个任务仍然失败。

理解 Office.js 的同步边界

Office.js 的对象通常是代理对象。读属性前需要排队加载，再调用 context.sync()；多条操作可以批量同步。插件与 Office 应用之间存在异步边界，因此应尽量减少不必要的往返。[2]

await Word.run(async (context) => {
  const selection = context.document.getSelection();
  selection.load("text");
  await context.sync();
  const snapshot = { text: selection.text };
  // 将纯数据快照传给分析服务；不要把代理对象当作业务数据。
});

示例依据 Office.js 的代理与批处理模型编写。真实实现应确认目标 Word 客户端所支持的 API requirement set。

建议的写回协议

1. 读：提取条款快照、范围标识与内容指纹；保留原文和修订后的文本。
2. 析：后台使用快照生成建议，并返回对应版本、证据和校验结果。
3. 审：用户选择接受、拒绝或继续修改，单独保存这个事件。
4. 写：检查目标位置与文本指纹；若发生变化，重新分析或重新确认。
5. 记：确认写回结果后存审阅反馈。重复请求应通过操作 ID 避免重复写入。

另一个重要边界是把合同文本当作待分析数据。对方文本中的指令式措辞不能改变应用规则；检索数据也要受用户权限和业务范围限制。这些应通过工具接口和查询约束实现，不能只靠提示词。

一个总准确率难以回答“系统在哪里有用”。应把证据、决策、改写、表达和业务耗时分开测量，再看它们如何共同影响专家审阅。

怎样审慎阅读 91% 和 >20%

• 核对分析单位：一处修订、一项动作、一份合同是不同的分母。
• 观察错误代价：将违规修改误判为接受，可能比把可接受项交给人工处理代价更高。
• 检查对照：案例难度、专家经验和辅助功能使用情况应尽量可比。
• 要求切片：按模板、条款类型和新旧政策分别看，防止高频简单项掩盖弱项。

这些是对已报告指标的分析问题，不据此推断原文数据无效，也不补造其测试方法或置信区间。

LLM 评分器应怎样使用

将模型评分器用于持续筛查，再用专家标签校准。检查它是否偏好更长的说明、是否被“听起来专业”误导，以及它和生成模型是否共享同一种错误。评分器的判断不能自动转成新规则。

学习实现可以从一个模板族和少量条款类型开始。先让输入、证据与人工纠正形成完整链路，再添加更复杂的生成或框架能力。

三个练习：每次只改变一个因素

从工作流到 Harness，先明确迁移收益

Agent harness 可以承担工具调用、上下文管理和执行控制。是否采用它，应看是否减少适配与状态管理成本，并保留明确的审批、证据与失败边界。更灵活的执行方式，本身不能证明更适合一个有固定审阅流程的任务。

原文把 harness、法律本体与知识图谱列为探索方向；不应把它们描述成已完成部署或已验证收益。[1]

先自行回答，再逐项展开。题目检验对检索、编排、约束和评估的理解。

原文没有提供完整生产代码、统一检索查询计划、全部提示词、完整评测数据或可复现实验配置。本文的架构图、Schema、公式演示、伪代码、失败路径和练习均为教学设计。