用 Gemini 2.5 Flash 审 8 万字合同：我踩了三次坑，总结出这套「锚定式 Prompt」

你拿到一份 80 页的 SaaS 采购合同，律师事务所报价 8000 元起步，交付周期三个工作日。

你打开 Gemini，把合同文本粘进去，输入一句话："帮我看看这份合同有没有坑。"

然后你得到了一篇 800 字的作文。

结构完整，语气专业，提到了"建议仔细核查违约条款""数据安全需关注"。你读完之后感觉"差不多"，然后合同签了。

三个月后，对方援引第 23.4 条的"单方变更服务条款权"，把你的数据存储从国内节点迁到了海外服务器——而你的合同里没有任何数据主权保护条款。

这篇文章要解决的，就是这个问题。

---

第一章：为什么选「合同审查」来测试长上下文能力？

AI 评测圈有一个惯例：用数学题测推理，用代码题测逻辑，用翻译测语言理解。但这些测试有一个共同的隐患——它们的答案是确定的，模型可以通过"记住答案"来作弊。

合同审查不一样。

一份真实的商业合同有几个让 AI 极度不舒服的特性：

• 条款跨章节引用：第 7 条的违约金计算依赖第 3 条的服务等级定义，而第 3 条的附件在文件第 68 页
• 逻辑链极长：一个风险点可能需要串联 5-6 个条款才能完整描述
• 语言高度压缩：法律文本每个字都有含义，"不得超过"和"不低于"差一个字，赔偿方向完全相反
• 雷区往往在细节里：最危险的条款通常不是标题党，而是藏在第 23.4 条这种不起眼的位置

这是我见过的对长上下文能力最公平的压力测试。

---

第二章：先搞懂模型，再写 Prompt——128k 与 1M 的本质区别

很多人对"百万 Token 上下文"有一个误解：以为它就是"超大的对话记忆"。

• 128k 对话上下文：模型在 Transformer 的注意力机制中完整处理每一个 Token，计算量随长度平方增长，真正的"全文理解"
• 1M 长文档处理：通常结合检索增强（RAG）或稀疏注意力机制，不是每个 Token 都被同等对待，更像是"带索引的文件检索"

理解这个区别，你就能理解为什么会出现注意力衰减现象。

Token 位置 vs 模型注意力权重（示意）

注意力权重
▲
高  │████                                    ████
│     ██                              ██
│        ██                        ██
低  │           ████████████████████
└────────────────────────────────────────→
开头                                    结尾
(中间区域注意力权重最低)

这条曲线有一个通俗的叫法："三明治效应"——开头和结尾被模型记得最清楚，中间夹着的内容最容易被"遗忘"。

对于一份 8 万字的合同，第 4-6 章通常正好落在注意力最低的区域。

这不是 bug，这是当前架构的物理限制。Prompt 设计的核心任务，就是绕过这个限制。

---

第三章：核心方法论——「锚定式 Prompt」四步设计框架 ⭐

这是全文最重要的部分。四个步骤，每步都有可直接复制的模板。

Step 1：角色锚定

不要让模型"自由发挥"。给它一个专业身份和明确的任务边界。

# 角色锚定 Prompt 模板

你是一名有 10 年经验的商业合同律师，专注于 SaaS 服务采购领域。
你的任务是对以下合同进行风险审查，只关注以下三类风险：
1. 数据主权与跨境传输条款
2. 单方变更权与服务等级保障
3. 违约金计算逻辑与上限条款

不要：
给出泛泛的"建议仔细核查"类建议
总结合同的整体内容
评价合同的商业条款合理性

要：
精确定位到具体条款编号
引用原文，不要改写
给出明确的风险等级（高/中/低）和具体修改建议

Step 2：结构切片

8 万字整体粘贴是大忌。按章节编号分批喂入，每批附上章节标签。

# 结构切片 Prompt 模板

以下是合同【第三章：服务等级协议（SLA）】的完整内容，
章节编号范围：第 3.1 条 至 第 3.18 条。

请在阅读完本章节后，暂不输出分析结果，
只输出一行确认：「已读取第三章，共 [X] 条，等待审查指令。」

---
[在此粘贴第三章全文]
---

这个设计有一个反直觉的关键点：让模型先"读"再"答"，而不是边读边输出。这能显著减少模型在处理长文本时的"跑偏"概率。

Step 3：问题清单前置

把审查维度放在文档之前，让模型带着问题读文本。

# 问题清单前置 Prompt 模板

在你审查【第七章：保密条款】之前，我需要你重点关注以下问题：

□ Q1：保密义务是否对双方对等适用，还是单方约束？
□ Q2：保密期限在合同终止后是否有明确约定？
□ Q3："合理必要"的信息披露例外是否有具体限制？
□ Q4：违反保密条款的赔偿上限是否有单独约定？

请带着以上四个问题，审查以下【第七章】内容：

---
[在此粘贴第七章全文]
---

审查完成后，按 Q1-Q4 的顺序逐一回答，不遗漏。

Step 4：输出格式约束

强制要求结构化输出，杜绝"作文体"。

# 输出格式约束 Prompt 模板

请将你的审查结果，严格按照以下表格格式输出，
每个风险点占一行，不得合并，不得省略任何列：

| 条款编号 | 风险等级 | 原文引用（≤50字） | 风险说明 | 建议修改方向 |

| X.X 条  | 高/中/低 | "……" | | |

格式要求：
条款编号必须精确，如"第 23.4 条"，不得写"第二十三章某处"
原文引用必须是合同原文，不得改写或总结
风险等级必须三选一，不得写"较高"或"偏中"
如某章节无风险，输出一行：「本章节未发现高/中风险条款」

---

💡 想直接跑这些 Prompt？

Gemini 2.5 Flash 的 API 调用比官网界面稳定得多，文中所有示例代码均基于标准 OpenAI 兼容接口格式编写。

新用户注册即送体验 token。合同审查这个场景输入 Token 量大，建议先用免费额度跑一遍第三章的四步框架感受一下。

---

以下是批量处理合同章节的 Python 调用示例：

from openai import OpenAI

client = OpenAI(
api_key="your_api_key",
base_url="https://api.884819.xyz/v1"
)

def review_contract_chapter(chapter_title: str, chapter_content: str, questions: list[str]) -> str:
"""
使用锚定式 Prompt 审查合同单个章节
"""
# Step 1: 角色锚定
system_prompt = """你是一名有 10 年经验的商业合同律师，专注于 SaaS 服务采购领域。
只关注数据主权、单方变更权、违约金三类风险。
精确引用条款编号，给出高/中/低风险等级，提供具体修改建议。"""

# Step 3: 问题清单前置 + Step 4: 格式约束
question_block = "\n".join([f"□ Q{i+1}：{q}" for i, q in enumerate(questions)])

user_prompt = f"""在审查【{chapter_title}】之前，请重点关注：

{question_block}

带着以上问题，审查以下内容：

---
{chapter_content}
---

请按以下格式输出审查结果：

| 条款编号 | 风险等级 | 原文引用（≤50字） | 风险说明 | 建议修改方向 |

"""

response = client.chat.completions.create(
model="gemini-2.5-flash",
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_prompt}
],
temperature=0.1  # 法律场景要求高确定性，温度调低
)

return response.choices[0].message.content

使用示例
questions = [
"保密义务是否对双方对等适用？",
"保密期限在合同终止后是否有明确约定？",
"违反保密条款的赔偿上限是否单独约定？"
]

result = review_contract_chapter(
chapter_title="第七章：保密条款",
chapter_content="[在此填入第七章原文]",
questions=questions
)
print(result)

---

第四章：实战复盘——三个「翻车时刻」和我怎么救回来的

方法论是干净的，现实是混乱的。以下是三次真实翻车记录。

翻车 #1：模型跳过第 7 章，直接给总结

请审查这份合同的第 5 章到第 9 章，找出所有风险条款。
[粘贴 5-9 章全文，约 3 万字]

# 修复后的两步走 Prompt

[第一条消息]
以下是合同第 7 章全文，请阅读后只输出：「已读取第七章，共 X 条款」
---
[第七章原文]
---

[第二条消息，等模型确认后发送]
现在请审查第 7 章，重点关注保密义务的对等性和期限约定，
按格式输出风险表格。

---

翻车 #2：风险等级全给"中等"，毫无区分度

# 风险等级评级标准（加入 Step 4 格式约束中）

风险等级定义：
【高】：条款可能导致重大财务损失（>合同总额 10%）或数据主权丧失，建议拒签或要求修改后再签
【中】：条款存在模糊地带，可能在争议时对己方不利，建议谈判优化
【低】：条款略有瑕疵但风险可控，可接受但建议备注说明

---

翻车 #3：引用条款编号对不上原文

第 15.3 条规定："乙方数据存储不得超出中华人民共和国境内……"

实际上，合同里根本没有"第 15.3 条"，这段文字出现在第 16.1 条。

def normalize_contract_numbering(raw_text: str) -> str:
"""
简单预处理：将中文编号转换为阿拉伯数字编号
实际使用时建议用正则表达式处理更复杂的格式
"""
import re
# 将"（一）""（二）"等转换为"1.""2."
cn_num_map = {"一": "1", "二": "2", "三": "3", "四": "4", "五": "5",
"六": "6", "七": "7", "八": "8", "九": "9", "十": "10"}
for cn, ar in cn_num_map.items():
raw_text = re.sub(f"（{cn}）", f"{ar}.", raw_text)
return raw_text

加上一句 Prompt 提示：

注意：合同原文中存在编号格式不统一的情况。
引用条款时，请严格使用原文中出现的编号，
如原文写"第十六条第一款"，你必须写"第十六条第一款"，不得换算为"16.1"。

---

第五章：最终交付物展示 + 横向对比

经过四步框架处理后，最终输出的审查报告部分示例（脱敏版）：

---

三款模型横向对比

⚠️ 以下对比基于相同合同文本、相同 Prompt 框架下的实测体感，不代表模型的绝对能力上限。

• Gemini 2.5 Flash 最优场景：合同超过 5 万字、需要批量处理多份合同、对速度和格式服从度要求高
• Gemini 2.5 Flash 的短板：在没有明确 Prompt 框架的情况下，输出质量下降明显；对法律术语的细微差异有时不如 Claude 敏感

---

📌 本文横向对比测试均通过 [api.884819.xyz](https://api.884819.xyz) 完成

同一套代码切换模型，账单统一管理，适合需要频繁对比多模型的读者。新用户注册即送体验 token，无月租，按量付费。

---

给你的行动建议

如果你现在手里有一份合同，不知道从哪里开始，先只用这一个 Prompt 试试：

你是一名商业合同律师。
请审查以下合同第 [X] 章，
重点关注：①单方变更权 ②数据存储地点 ③违约金上限。
按「条款编号 | 高/中/低风险 | 原文引用 | 修改建议」格式输出。
不要总结，不要评价，只找风险。

[粘贴章节原文]

这个简化版已经包含了四步框架的核心逻辑：角色锚定 + 问题前置 + 格式约束。跑通这一章，再把完整框架应用到全文。

---

合同审查只是开始。

>

长上下文真正的「地狱难度」测试，是让模型同时处理一个项目的全部代码库——几十个文件、相互引用的函数、跨文件的 Bug 溯源。

>

下一篇，我会用同样的「锚定式 Prompt」框架，挑战一次真实开源项目的 Code Review，看看 1M Token 上下文在代码场景下的天花板在哪里。

>

关注博客，下周见。

---

#AI工具 #Gemini #合同审查 #Prompt技巧 #长上下文 #8848AI #AI实战 #法律科技