Dikaya Pro 长文档对照：保留版本、冲突与判断依据

最小 API 示例

此 Python 代码仅作说明，并非真实模型回答。密钥从环境变量读取，自动重试已关闭。断线可能让结果和费用都无法确认，不应盲目重试。

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro",
    max_tokens=512,
    messages=[{"role": "user", "content": "为我的任务列出检查清单。将原始事实与假设分开。"}],
)
print(response.choices[0].message.content)

先写清楚这次到底比较什么

设备租赁文件可能同时包含主合同、维修附件和报价说明。比较前限定问题，例如只核对归还期限、维修责任和提前终止条件，不请求模型自行判断整份合同是否值得签。把需要负责人确认的判断与能够逐字核查的文字变化分开，可以避免一篇漂亮结论越过材料实际提供的依据。

Dikaya Pro 是一个品牌模型档位，公开资料没有在此指定其基础模型。也不要因为其他条目提供推理强度控制，就给 Pro 套用 low、high、max。这里选择它讨论长文档工作流，是读者任务的组织方式，不是与 Pro 2 或其他模型进行过同条件测试后的性能排名。

冻结原文、日期和适用关系

将旧版命名为 LEASE-A，新版为 LEASE-B，段落分别使用 A-01 和 B-01。记录文件日期、批准状态与是否包含签署附件；文件名中的最终版不能替代真实批准信息。模型可以列出日期差异，但不能仅凭文件排列顺序宣布后一份已经取代前一份，除非材料明确写出这种关系。

把页眉、脚注和表格标题一并保留，因为一个费用表的单位可能只出现一次。导出文本后检查段落是否错序、列是否交错，防止模型面对损坏输入却仍给出确定比较。若是图片，Pro 采用另行付费的文字桥接，先确认描述是否完整；它不是原生图片模型，也不是任意办公文件解析器。

制作双向证据矩阵而非单边摘要

矩阵中每行放一个义务：旧版原句与编号、新版原句与编号、变化类型、可能影响和待确认问题。旧版要求五个工作日内归还，新版写五日内归还，不能直接说期限相同。工作日与自然日的差别需要指出，同时核对其他定义条款是否已经解释日的含义。

双向检查意味着既找新版增加了什么，也找旧版哪些条款没有对应项。未找到不一定代表删除，可能是条款移动或拆分。要求模型提供它搜索过的章节范围，自己再对照索引。对于金额、责任主体、例外条件和否定词逐项复核，比只比较段落相似度更符合实际审阅需求。

大上下文之外仍有输入与输出边界

模型声明的上下文说明一种输入容量边界，不等于浏览器会把所有旧消息和附件原样发送。浏览器还有消息数量与序列化字节限制，输出也有独立上限。中文文本的字符、UTF-8 字节和模型 token 不可互换，不能用页面数估算所有文档都能一次完整处理。

材料超过客户端限制时，按主题拆成保留原编号的分块，并维护全局目录。每块先提取局部证据，再把证据表连同关键原文汇总。只把上一轮的摘要继续摘要，会失去例外条款；因此最终合并时应列出哪些章节尚未检查，而不是因为输出写完就宣告全文完成。

对冲突保留问题，不替负责人拍板

若主合同写维修由出租方负责，而附件写常规保养由承租方承担，先核对维修与保养是否有定义，再判断是否真的冲突。把能够解释两句同时成立的条件写成假设，并明确没有获得确认。模型生成的合理解释不能自动成为双方已经同意的条款。

需要外部背景时，把付费浏览器显式搜索取得的网页与合同原文分列；外部解释不能证明这份合同有何约定，也不是专业法律意见。公共 API 不因此获得浏览器的互联网搜索功能。最后把问题整理为可回答的确认项，例如请指出哪条定义约束日的计算，而非泛泛要求再检查一次。

留下能够复查的比较记录

保存输入版本、问题范围、使用的公开模型标识、实际输出及人工修改。价格表用于查看当前配置，账户权限和个人费用条件要另外确认。为比较设置明确输出上限，先请求最关键的三类条款；不要让模型在一次被截断的答案中声称已经审阅完整文件。

API 客户端应关闭 SDK 自动重试；官方 Python SDK 的重试说明解释了相应设置。MDN 指出 Fetch 收到 HTTP 错误时仍可能得到响应对象，网络异常则另行处理。已知拒绝与连接结果未知必须分开记录，网络中断不证明没有费用或记录；核对后再决定是否人工重发。

常见问题

Dikaya Pro 是否就是某个公开基础模型的别名？

不能这样推定。Pro 的基础模型在本指南依据的公开说明中未指定，品牌名称、上下文数字和价格都不能证明其来源。Pro 2 有单独获准的基础说明，但不应反向套用到 Pro。实际接入时使用 seller-pro，并查看当时的目录、权限和文档。

两个文件都放进上下文，就能保证不漏条款吗？

不能。输入能够容纳，不代表每个定义、脚注和例外都被正确关联。应维护章节覆盖清单，要求双方原文与编号，并人工检查高影响字段。浏览器可能另有限制，全文是否实际发送也需要确认，不能把声明的上下文当作完整历史传输保证。

找不到旧条款的对应位置，应该直接标记删除吗？

先标记未定位，并记录已经检查的范围。旧条款可能移动到附件、换用不同词语或拆成多条，只有复核全文后才能确认删除。保留原文和检索线索，让负责人区分材料缺失与真正的义务变化，不用一份顺畅的摘要掩盖这两种情况。

图片合同能否像纯文本一样直接交给 Pro 核对？

Pro 的图片处理使用另行计费的文字桥接，不是同等的原生图像输入。先检查桥接描述是否保留页码、表头、单位和例外条款，关键内容最好自行导出并核对文本。图片可上传也不意味着所有办公格式受支持，更不代表每一处条款已经可靠识别。

参考来源

本文由 AI 辅助编写。示例用于说明方法，不是真实模型回答或对比测试。外部来源不能替代服务条款。

• Dikaya 中文文档：请求格式与客户端接入
  dikaya.cc
• Dikaya 中文模型目录：公开标识与能力声明
  dikaya.cc
• Dikaya 中文价格说明：配置价格与实际使用条件
  dikaya.cc
• OpenAI Python SDK 官方说明：关闭自动重试
  github.com
• MDN Fetch 使用指南：HTTP 状态与网络异常
  developer.mozilla.org