2026.5.25-2026.6.1

1. 工作内容

本次开发主要围绕智能合同平台中的“风险审查链路完善与修订版本落库”展开。

上一阶段已经实现了风险驱动合同优化：用户可以确认风险、勾选需要处理的问题，并调用大模型生成优化条款。但是，从完整业务流程来看，仍然存在一些不足：

• 风险审查只支持粘贴文本，不支持直接上传合同文件。
• 大模型有时会把一般性完善建议也当成风险，存在过度审查现象。
• 优化结果只能在弹窗中查看，没有真正进入合同台账和版本管理，也无法方便的直接下载。
• 用户切换页面后，当前输入内容和分析结果会丢失。
• AI 生成耗时较长时，容易出现前端提前超时的问题。

因此，本周的重点是继续补齐风险审查业务闭环，让系统从“发现问题、生成建议”推进到“文件审查、定向修订、版本保存、台账联动和导出下载”。

本次完成的主要内容包括：

支持上传 PDF、Word、TXT 文件发起风险审查
复用摘要模块中的 DocumentTextExtractor 统一提取文件正文
升级风险审查 Prompt，减少为了找问题而找问题的情况，允许规范合同返回空风险数组
由后端根据优化条款自动替换原文，生成修订后合同全文
无法精确定位原条款时，将修订内容作为补充条款追加
优化结果使用可拖动、可最小化的独立工作窗展示
支持不保存合同台账，直接将修订稿下载为 Word 文件
支持将修订稿保存到合同台账并生成新版本
首次保存时自动建立原文 v1 和修订稿 v2，后续再次优化时继续生成 v3、v4，保留完整版本链路
保存时从原文中保守提取甲方、乙方、金额和合同期限
风险优化保存成功后自动刷新合同管理页面
使用 keep-alive 保留模块切换前的页面状态
适当延长风险分析和风险优化的请求超时时间
同步更新 README、数据库设计、开发文档、流程图和接口文档

---

2. AI 交互

2.1 关于风险审查过度输出问题

提示词：

风险审查模型在面对相对规范的合同样例时，仍然会输出很多风险。 有些问题更像一般性完善建议，而不是影响合同履行的真实风险。 应该如何优化 Prompt，让模型允许输出零风险或少量低风险？

AI 回应：

AI 建议明确区分“实质风险”和“一般优化建议”，并约束模型只输出可能直接影响合同履行、责任承担或合法性的内容。

对于权利义务基本完整、符合常见交易习惯的合同，应允许返回空数组，而不是为了体现模型能力强行挑出问题。

本次在 Prompt 中增加了以下约束：

• 不得为了凑数量而编造风险。
• 可选附件、业务偏好和文字润色不应直接判定为风险。
• 高风险必须对应核心条款缺失、明显违法违规或严重不公平。
• 中风险应当对应确实存在的履约歧义。
• 没有发现实质风险时，必须返回空数组。

我对这个问题的理解是：风险识别不是输出越多越好。真正有价值的风控系统应该帮助用户筛选重点，而不是让用户重新面对一份更长的“问题清单”。

2.2 关于优化结果如何保存为合同版本

提示词：

风险优化后的合同应该如何保存？ 首次优化时可能没有关联合同台账，后续再次优化时还要继续生成 v3、v4。 怎样设计才能保留历史版本，并避免每次都新建一份合同？

AI 回应：

AI 建议将合同主数据和合同版本分开处理：

• contract_info 保存合同台账信息。
• contract_version 保存每一次正文快照。
• 首次风险优化时，自动创建合同主记录。
• 原始正文保存为 v1。
• 第一次修订稿保存为 v2。
• 再次优化时，根据同一个 contractId 继续生成 v3、v4。
• 每个版本保存 parentVersionId，形成可追溯的版本链。

除此之外，还可以使用正文哈希作为兜底关联手段。如果页面状态丢失，没有传递 contractId，后端仍然可以根据原始正文哈希找到已有版本所属的合同，避免重复建档。

这个设计让我更清楚地认识到：版本管理不能简单地理解为覆盖保存。合同属于需要追溯责任和修改过程的重要业务数据，因此每次修订都应该留下独立快照。

2.3 关于 AI 优化接口超时问题

提示词：

风险一键优化经常超时。模型既要读取风险点，又要返回完整合同全文，响应时间比较长。 应该如何优化？

AI 回应：

AI 建议让大模型只返回选中风险对应的优化条款，不再要求模型重新输出整篇合同。后端收到结构化条款后，再根据原条款进行定位替换并生成完整修订稿。

这个调整降低了模型输出长度，也让结果更容易解析。

我认为这里体现了一个比较重要的大模型应用开发思路：模型应该负责它擅长的语义生成，程序应该负责确定性的文本处理。全文拼接和条款替换属于可控的程序逻辑，没有必要全部交给模型。

---

3. 具体步骤

3.1 增加风险审查文件上传能力

新增接口：

POST /api/risk/analyze-file

该接口接收：

• file：合同文件
• contractId：可选，关联合同台账
• versionId：可选，关联具体版本

后端复用了摘要模块中的 DocumentTextExtractor，将 PDF、DOC、DOCX 和 TXT 文件统一转换为文本，再进入已有的风险分析流程。

这样做的好处是避免重复实现文件解析逻辑。摘要提取和风险审查虽然属于不同业务模块，但它们的前置步骤相同：都需要先把文件转换为可供大模型理解的纯文本。

后端代码截图：

前端代码截图：

3.2 升级风险审查 Prompt

本次将风险 Prompt 升级为 risk-v2。

核心调整包括：

• 只识别实质风险。
• 允许规范合同无风险输出。
• 区分风险和一般优化建议。
• 要求风险能够引用对应原文。
• 继续保持 JSON 结构化输出。

代码截图：

这一调整并不能一次性解决所有判断偏差，但已经让风险输出更加符合真实业务需求。后续还可以继续引入合同类型模板和知识库，让审查标准更细致。

3.3 优化修订结果生成逻辑

原本的思路是让模型直接返回修订后的完整合同全文。但是测试中发现，这种方式容易增加 token 消耗和响应时间，而且模型重复输出长文本时更容易发生格式不稳定。

本次改为：

1. 将用户选中的风险点发送给模型。
2. 模型只返回 optimizedItems。
3. 每一项包含原条款、优化条款和修改说明。
4. 后端根据原条款定位正文中的对应位置。
5. 找到原条款时直接替换。
6. 无法精确定位时，以补充条款形式追加到正文末尾。
7. 最终由后端生成修订后合同全文。

代码截图：

这个方案把大模型能力和传统程序逻辑结合起来。模型负责理解风险并生成正式条款，后端负责稳定地合并文本，整体可控性更高。

3.4 增加风险修订版本保存能力

新增接口：

POST /api/contract/save-risk-optimized

保存逻辑如下：

1. 如果已有 contractId，直接在当前合同下追加版本。
2. 如果没有 contractId，根据原文哈希查询是否存在历史版本。
3. 如果能够找到对应合同，继续追加新版本。
4. 如果完全没有关联记录，自动创建合同台账。
5. 首次自动建档时，将原文保存为 v1。
6. 将风险修订稿保存为 v2。
7. 后续再次优化时保存为 v3、v4。

代码截图：

这里使用正文哈希进行兜底关联，是为了处理页面状态丢失或首次保存没有 contractId 的情况。哈希查询不是主要路径，但可以降低重复创建合同台账的概率。

3.5 保存时提取合同基础字段

风险修订稿进入合同台账后，还需要补充合同主体、金额和期限，否则台账页面会出现大量空值。

本次增加了保守提取逻辑：

• 识别明确写出的甲方。
• 识别明确写出的乙方。
• 识别合同总金额、合同价款、项目总价等常见表达。
• 支持 80000 元和 8 万元两种格式。
• 识别明确写出的合同期限日期区间。
• 支持分别写明生效日期和终止日期。
• 只写签订日期时，不自动推断合同期限。
• 没有明确内容时保持为空。

代码截图：

我认为这一部分最重要的原则是“宁可留空，也不要编造”。合同系统中的字段可能用于统计、检索和提醒。如果系统擅自将签订日期当成生效日期，或者误把某个普通数字当成合同金额，后续业务处理反而会受到影响。

3.6 增加 Word 下载能力

本次新增了直接下载修订稿的能力。用户不需要先将修订稿保存到合同台账，也可以直接导出 Word 文件。

新增接口：

POST /api/contract/export-text

后端使用 Apache POI 创建 DOCX 文件，将合同标题和正文写入 Word 文档。

代码截图：

下载和保存属于两个不同操作：

• 下载解决的是用户获取文件的问题。
• 保存解决的是平台内部追溯和版本管理的问题。

将两者分开后，页面业务逻辑更加清晰。

3.7 改造风险优化工作窗

风险优化结果不再使用普通弹窗简单展示，而是改造成独立工作窗：

• 支持拖动位置。
• 支持最小化。
• 支持恢复显示。
• 右上角关闭和最小化按钮样式保持一致。
• 展示修订后合同全文。
• 展示每一条原风险、原条款、优化条款和修改摘要。
• 支持下载 Word。
• 支持保存到合同台账。

前端代码截图：

3.8 保留页面状态并联动刷新合同台账

用户在风险审查页面输入合同内容或得到分析结果后，如果暂时切换到其他模块，再切回来，不应该重新开始操作。

本次在主布局中使用 keep-alive 保留页面组件状态。

风险修订保存成功后，前端还会触发合同列表刷新事件。合同管理页面监听事件后，自动重新加载台账列表。如果当前正在查看同一份合同详情，也会同步刷新版本记录。

代码截图：

这一改动看起来比较小，但会直接影响使用体验。业务系统不仅要实现功能，还要减少用户重复刷新和重复输入的操作成本。

3.9 延长 AI 请求超时时间

风险分析和风险优化都需要等待大模型处理较长文本。此前全局请求超时时间较短，可能出现后端仍在生成结果，但前端已经提示失败的情况。

本次将风险模块前端请求等待时间统一调整为 300 秒，并将后端 AI 调用超时时间调整为 240 秒。

代码截图：

配置截图：

3.10 更新项目文档

本次同步更新了以下文档：

README.md 02-数据库设计.md 03-开发文档设计.md 04-项目流程图设计（需求分析）.md 05-接口文档.md

文档补充了风险文件上传、风险判断标准、风险优化保存、Word 导出、合同版本关联和超时配置等内容。

---

4. 测试效果

本次使用一份带有明确合同主体、金额和期限的软件开发服务合同进行测试。

测试文本：

办公设备采购合同

甲方：济南远航文化传媒有限公司
乙方：青岛新锐办公设备有限公司

第一条 采购内容
甲方向乙方采购办公电脑、显示器和打印机一批。设备品牌、具体型号、技术参数和数量由双方后续沟通确定。

第二条 合同金额
本合同总金额：人民币12.8万元。
甲方应先支付部分货款，剩余款项在设备交付后支付，具体付款比例和时间由双方协商确定。

第三条 合同期限
合同期限：自2026年6月10日起至2027年6月9日止。

第四条 交付
乙方应尽快将设备送至甲方办公地点。运输费用由乙方承担，具体交付日期另行通知。

第五条 验收
设备送达后由甲方进行验收。如甲方未及时提出问题，视为设备符合要求。

第六条 质量与售后
乙方应保证设备能够正常使用。如设备出现故障，乙方应及时处理。

第七条 违约责任
如乙方未按时交付设备，应承担相应责任。甲方逾期付款的，双方另行协商处理。

第八条 合同解除
如果甲方认为设备不符合要求，可以要求退货并解除合同。乙方已经发生的运输、安装等费用由乙方自行承担。

第九条 保密
双方对合作过程中获知的商业信息承担保密义务。

第十条 争议解决
双方发生争议时，应首先友好协商；协商不成的，依法处理。

第十一条 其他
本合同一式两份，甲乙双方各执一份，自双方签字盖章之日起生效。

甲方代表签字：____________
乙方代表签字：____________
签订日期：2026年6月1日

主要验证结果：

• 文本输入可以正常发起风险审查。
• PDF、Word、TXT 文件可以上传并解析正文。
• 模型能够识别付款比例不明确、交付时间模糊、验收标准缺失等风险。
• 用户确认风险后可以勾选并一键优化。
• 优化工作窗可以拖动和最小化。
• 修订稿可以直接下载为 Word。
• 首次保存后，合同台账中生成同一份合同的 v1 和 v2。
• 再次优化并保存后，最新版本更新为 v3。
• 合同主体显示为杭州星云商贸有限公司和上海启明信息技术有限公司。
• 合同金额显示为 80000.00。
• 合同期限显示为 2026年6月1日至2026年9月30日。
• 保存完成后，合同管理页面可以自动刷新。
• 切换模块后返回风险审查页面，原有输入和结果仍然保留。

运行截图：

---

5. 本次开发总结

本次开发让我对智能合同平台中的业务闭环有了更完整的理解。

风险审查不是单独存在的功能。合同进入系统后，用户需要能够上传或输入正文，识别真实风险，人工确认风险，生成优化条款，保存修订版本，查看历史记录，并在需要时下载文件。

本次开发中比较关键的技术点有四个。

第一，风险审查需要控制输出质量，而不是单纯追求风险数量。允许规范合同返回空风险，是提高系统可信度的重要一步。

第二，大模型不应该承担所有逻辑。模型适合生成优化条款，后端适合进行确定性的文本替换、版本保存和字段抽取。两者结合后，系统更加稳定。

第三，合同修改必须保留历史版本。风险优化后的正文不能直接覆盖原文，而应该继续生成 v2、v3 和 v4，并通过 parentVersionId 保留修改路径。

第四，数据抽取需要保持保守。甲方、乙方、金额和期限只有在正文明确写出时才保存。对于合同管理平台来说，错误数据往往比空数据更危险。

整体来看，本次开发让风险模块从“发现问题”继续推进到“完成修订并进入合同管理”。系统已经初步形成：

合同输入或文件上传 -> 风险审查 -> 人工复核 -> 勾选风险 -> AI 生成优化条款 -> 后端生成修订全文 -> 保存新版本或下载 Word -> 合同台账自动刷新

---

6. 后续优化方向

当前版本已经完成基础闭环，但仍有进一步优化空间。

第一，引入标准合同模板和合同类型知识库。软件开发合同、租赁合同、采购合同和劳动合同的审查重点不同。后续可以根据合同类型加载不同规则，进一步减少过度审查。

第二，增加版本对比视图。系统已经能够保存 v1、v2、v3，后续可以将两个版本并排展示，并高亮新增、删除和修改内容。

第三，完善条款定位方式。目前后端优先使用原文匹配进行替换，找不到时追加补充条款。后续可以增加条款编号匹配和分段解析，提高自动替换准确率。

通过这些优化，智契通可以逐步从“AI 辅助合同处理工具”发展为更完整的智能合同全生命周期管理平台