Harvey 将 GPT-6 Astra 用于法律文书生成，核心变化并不只是“写得更快”，而是模型能够根据案件上下文产出结构更清晰、与材料联系更紧密的初稿。对律师而言，真正有价值的结果，是减少整理事实、搭建文书骨架和反复调整格式的时间，把注意力留给论证策略、风险判断与客户沟通。
强草稿依赖的不是长提示词，而是清晰的上下文
法律文书很少能仅凭一句指令完成。模型需要知道文件类型、司法辖区、程序阶段、已确认事实、争议问题、引用材料以及不能跨越的边界。
一个适合交给模型的“案件上下文包”可以分为几层：
- 任务信息：需要起草什么文书，读者是谁，目标是什么。
- 已确认事实：来自案卷、访谈或证据，并标明出处。
- 待核实信息：尚未确认、不能作为确定事实陈述的内容。
- 法律材料：律师已经筛选的法规、判例或内部知识库片段。
- 写作约束：篇幅、语气、格式、截止时间和保密要求。
- 输出边界：不得虚构引文，不得自行补齐缺失事实，缺口必须显式列出。
这种结构让模型更容易区分“材料中存在的事实”和“为了连贯而作出的推断”。它也使审阅者能够追踪每个结论依赖了什么，而不是面对一段看似完整却来源不明的文本。
把生成拆成可检查的阶段
如果一次请求就要求模型交付最终版本，律师往往只能逐句排查问题。更稳妥的流程是让模型依次完成：
- 整理事实与时间线；
- 列出缺失信息和冲突材料；
- 生成文书提纲；
- 按提纲撰写初稿；
- 对事实、引文和结论执行单独检查。
这里的“更结构化”不应只理解为多几个标题。理想输出还应明确区分事实、法律依据、分析、结论和待确认事项。这样，律师可以在事实层纠错，在论证层调整策略，而不必同时重写整份文档。
模型也不应承担最终法律判断。程序期限、管辖规则、引用是否有效、判例是否仍具约束力，都需要律师或经过批准的检索系统复核。生成速度越快，越需要明确责任边界。
一个可以改造的上下文驱动生成示例
下面是假设性的内部网关示例，并非 Harvey 或 GPT-6 Astra 官方 API 说明。它假设组织提供了兼容常见聊天请求格式的 HTTPS 端点。运行前需要把 LEGAL_LLM_URL、LEGAL_LLM_TOKEN 和模型名称改成组织批准的配置，并且只使用合成数据测试。
先创建 matter_context.json：
{
"document_type": "motion outline",
"jurisdiction": "Example State Superior Court",
"audience": "reviewing attorney",
"objective": "prepare an outline for a motion to compel",
"confirmed_facts": [
{
"id": "F1",
"text": "The request for production was served on 2026-01-10.",
"source": "synthetic docket entry 12"
},
{
"id": "F2",
"text": "No written response appears in the supplied file set.",
"source": "synthetic document index"
}
],
"unverified_points": [
"Whether the parties completed the required meet-and-confer process"
],
"approved_authorities": [],
"constraints": [
"Do not invent citations",
"Mark every unsupported proposition as requiring verification",
"Return an outline, not a filing-ready document"
]
}
再保存以下脚本为 draft.py：
import json
import os
import urllib.request
endpoint = os.environ["LEGAL_LLM_URL"]
token = os.environ["LEGAL_LLM_TOKEN"]
model = os.getenv("LEGAL_LLM_MODEL", "gpt-6-astra")
with open("matter_context.json", "r", encoding="utf-8") as f:
matter = json.load(f)
system_prompt = """You assist with legal drafting under attorney supervision.
Use only the supplied matter context.
Separate confirmed facts, assumptions, legal analysis, and missing inputs.
Never fabricate authorities, quotations, dates, procedural rules, or citations.
When authority is absent, insert [AUTHORITY REQUIRED].
Return these sections: Scope, Verified Facts, Open Questions,
Proposed Structure, Draft Outline, and Attorney Review Checklist.
"""
payload = {
"model": model,
"temperature": 0.2,
"messages": [
{"role": "system", "content": system_prompt},
{
"role": "user",
"content": "Prepare a reviewable draft from this context:\n"
+ json.dumps(matter, ensure_ascii=False, indent=2),
},
],
}
request = urllib.request.Request(
endpoint,
data=json.dumps(payload).encode("utf-8"),
headers={
"Authorization": f"Bearer {token}",
"Content-Type": "application/json",
},
method="POST",
)
with urllib.request.urlopen(request, timeout=90) as response:
result = json.load(response)
print(result["choices"][0]["message"]["content"])
在 macOS 或 Linux 中运行：
export LEGAL_LLM_URL="https://your-approved-gateway.example/v1/chat/completions"
export LEGAL_LLM_TOKEN="replace-with-a-short-lived-token"
export LEGAL_LLM_MODEL="gpt-6-astra"
python3 draft.py
这个示例刻意要求模型输出“待确认事项”和律师审阅清单，而不是伪装成可直接提交的文件。生产环境还应增加访问控制、请求日志脱敏、文档保留策略、供应商数据处理审查，以及对模型输出的版本记录。
用审阅成本衡量效果
评估法律草稿不能只看语言是否流畅。更实用的测试集应来自经过脱敏并获准使用的历史任务，并记录以下指标：
- 文书结构是否完整且符合任务类型；
- 每项事实能否追溯到提供的材料；
- 是否出现虚构引文、错误日期或未经支持的推论；
- 模型是否主动暴露缺失信息；
- 律师修改初稿需要多少时间；
- 高风险错误能否被现有审阅流程稳定发现。
还可以让两位律师在不知道生成方式的情况下分别审阅人工初稿与模型辅助初稿，比较纠错数量、审阅时长和最终可用性。这样测到的是工作流收益，而不是模型文风偏好。
采用前的检查清单
GPT-6 Astra 所代表的方向，是让模型把零散法律上下文组织成更可审阅的草稿，而不是替代律师做最终判断。落地时可以坚持几条边界：
- 从低风险、内部使用的提纲和摘要开始；
- 只接入经过批准的数据源和模型端点；
- 为事实与引文保留可追溯标识；
- 强制展示不确定性、缺失材料和假设；
- 禁止未经律师确认的内容直接对外发送或提交；
- 持续记录修改原因，用真实审阅结果改进提示词和流程。
当上下文经过整理、生成过程可以检查、责任边界足够清楚时，模型节省下来的才不只是打字时间。律师可以把更多精力投入案件策略、证据取舍和风险权衡——这些仍然是法律工作的核心。