2026.5.18-2026.5.251. 工作内容本次开发主要围绕智能合同平台中的“风险驱动合同优化”功能展开。项目在上一阶段已经完成了合同风险审查模块能够对合同文本进行风险识别并在前端展示风险分类、风险等级、风险说明、修改建议和复核状态。但是从业务闭环角度看风险审查如果只停留在“发现问题”用户仍然需要手动理解每一条风险并自行修改合同系统的智能化程度还不够完整。因此本次工作的重点是在已有风险审查结果的基础上继续向后推进一步让用户可以选择已经确认的风险点由系统根据风险说明和修改建议自动生成可替换的优化条款。这样风险审查模块不再只是“合同体检报告”而是可以进一步联动合同优化能力形成“发现风险 - 确认风险 - 生成修订建议”的处理链路。本次工作基于现有项目结构完成了风险驱动合同优化功能的第一阶段落地主要包括在风险审查结果表格中增加风险勾选能力限制只有“已确认”的风险才能进入一键优化流程支持用户点击“全选”快速选择所有已经确认的风险点优化“确认/忽略”交互避免点击确认或忽略后清空整张表格的勾选状态点击忽略后默认隐藏该风险但不删除数据库记录保留审查留痕新增风险驱动优化请求和响应 DTO新增风险优化 Prompt 构造逻辑复用已有 AiChatService 调用大模型生成优化条款新增 /api/risk/optimize 接口前端 risk.ts 增加风险优化 API 封装前端 RiskView.vue 增加“一键优化”按钮和优化结果弹窗优化结果展示原条款、风险说明、AI 优化条款和修改摘要将风险驱动优化记录写入历史记录模块2. AI 交互2.1 关于风险审查和合同优化是否重叠提示词合同优化和风险评估这里会不会有功能重叠优化本质不就是对风险的改进优化吗AI 回应AI 将两个模块区分为风险评估负责“发现问题”合同优化负责“改写文本”。风险评估更像合同体检报告输出的是风险清单合同优化更像修订助手输出的是可以替换进合同的条款文本。这个解释让我对本次功能的定位更清晰。风险审查回答的是“哪里有问题、为什么有风险、风险等级是什么”合同优化回答的是“这条内容应该怎么改”。如果把两者完全混在一起用户可能只看到一堆修改后的文本却不知道原来风险在哪里如果只做风险审查用户又需要自己手动修改合同。因此本次开发采用了中间方案保留风险审查的结构化结果同时允许用户选择其中部分风险点进行优化。这样既保留了风险定位和人工复核过程也让系统能够进一步生成可执行的修订建议。2.2 关于风险驱动优化功能如何拆分提示词我想在风险审查结果中增加勾选功能用户勾选风险点后一键优化并且忽略的风险默认从表格中隐藏。请帮我分析这个功能应该如何拆分讲一下业务逻辑和开发步骤。AI 回应AI 将功能拆分为几个关键环节前端风险表格勾选、复核状态控制、已忽略风险隐藏、风险优化请求 DTO、风险优化 Prompt 构造、大模型调用、优化结果结构化返回、前端弹窗展示和历史记录保存。这个拆分比较符合实际开发流程。因为一键优化并不是简单地把合同文本发给 AI而是需要把“用户选中的风险点”作为上下文传给模型。模型需要知道原条款是什么、风险说明是什么、修改建议是什么才能生成更贴合问题的优化条款。本次我没有让系统自动优化所有风险而是让用户先确认、再勾选、再优化。这样做的原因是大模型审查结果不一定全部适用尤其是之前测试中发现模型有时会偏保守可能把一般性优化建议也识别成风险。因此在进入优化前增加人工选择可以减少不必要的自动改写。3. 具体步骤3.1 新增风险优化 DTO新增文件字段结构本次没有直接把前端选中的表格行原样传给大模型而是单独设计了风险优化请求 DTO。RiskOptimizeRequest 用于承载合同 ID、版本 ID、合同全文和选中的风险点列表RiskOptimizeItemRequest 用于描述单条待优化风险包括条款编号、风险分类、风险等级、原条款、风险说明和修改建议。响应部分同样没有直接返回一段纯文本而是设计了 RiskOptimizeResponse 和 RiskOptimizeItemResponse。这样前端可以清楚展示每一条优化结果对应的原风险条款也方便后续继续扩展“保存为新版本”“应用到正文”等能力。DTO 的作用是隔离接口层和业务实体层。风险优化结果目前不直接落到新的数据库表中而是作为一次 AI 修订建议返回给前端并写入历史记录。单独设计 DTO可以让接口结构更加明确也避免为了前端展示强行改动已有的风险结果实体。3.2 扩展风险 Prompt 构造器核心方法风险优化 Prompt 中明确要求模型只能根据原合同条款和风险说明进行修订不得新增与选中风险无关的业务内容optimizedClause 必须是可以直接替换原条款的正式合同文本changeSummary 用一句话说明本次修改解决的问题必须只返回 JSON这里和普通合同润色最大的区别在于普通润色可能关注语言是否正式、表达是否通顺而风险驱动优化更关注“是否解决了指定风险”。因此 Prompt 中必须把原条款、风险说明、修改建议都作为输入让模型围绕具体问题生成修订条款。3.3 新增风险驱动优化服务逻辑核心方法这里的重点是复用已有的 AiChatService而不是重新写一套 AI 调用逻辑。项目中已经有统一的大模型调用服务风险审查、摘要提取、合同生成都可以围绕它做业务 Prompt 封装。这样做可以保持 AI 调用入口统一后续如果模型地址、模型名称或鉴权方式变化只需要改 AiChatService 或配置层。本次优化结果暂时没有直接替换合同正文也没有直接生成新版本。这是有意控制范围。因为“自动替换全文”需要处理条款定位、文本替换、版本保存、用户确认等更多问题容易一下做得太大。第一阶段先生成可替换条款并展示给用户既能体现业务闭环又保留后续继续开发空间。3.4 改造风险 Controller新增接口本次在 RiskController 中新增了 /api/risk/optimize 接口。Controller 仍然保持较薄的写法只负责接收请求、调用 RiskAnalysisService并统一包装 ApiResponse。这里没有在 Controller 中直接拼 Prompt 或调用大模型是为了保持分层清晰。Controller 负责接口入口Service 负责编排业务流程PromptBuilder 负责 Prompt 文本AiChatService 负责模型调用。这个分层和前面摘要、风险审查模块保持一致。3.5 新增前端风险优化 API代码截图这样做的好处是页面组件不需要关心接口路径和请求结构只需要调用 optimizeRisks。后续如果后端接口路径调整或者请求字段增加只需要集中修改 risk.ts不需要在页面中到处找请求代码。这也延续了项目中已有的前端工程化风格页面负责 UI 和交互api 文件负责请求封装类型定义负责约束数据结构。3.6 改造前端风险审查页面代码截图前端页面新增能力包括已确认风险可以勾选待复核风险不能勾选已忽略风险默认隐藏点击“显示已忽略”可以查看被忽略的风险点击“全选已确认”可以快速勾选当前可见的全部已确认风险点击“一键优化”后调用后端接口生成优化条款优化结果以弹窗展示原条款、风险说明、AI 优化条款和修改摘要在实现过程中我还遇到了一个比较典型的前端交互问题。最初使用 Element Plus 表格自带的 selection 列来处理勾选但点击确认或忽略后表格数据更新会触发 selection-change导致整张表的勾选状态被清空。后来我改成普通复选框列并用 selectedRiskItemIds 自己维护勾选状态。这个调整让我意识到复杂表格交互中不能完全依赖组件内部状态。尤其当表格行会被更新、隐藏或过滤时勾选状态最好由业务代码按主键维护。这里使用 resultId 作为风险行的唯一标识点击确认不会影响已勾选项点击忽略时只移除当前行的勾选状态其他行保持不变。这样交互更符合用户预期。3.7 测试效果本次测试先使用一份存在明显风险的软件开发服务合同。系统完成风险审查后用户先对部分风险点击“确认”然后勾选其中几条风险点击“一键优化”。后端根据原合同文本、选中的风险条款、风险说明和修改建议生成了对应的优化条款。测试合同文本软件开发服务合同甲方杭州星河贸易有限公司乙方上海云启科技有限公司第一条 项目内容甲方委托乙方开发一套客户订单管理系统系统包括客户管理、订单录入、订单查询和数据统计等功能。具体功能以双方沟通为准。第二条 合同金额本合同总金额为人民币 100000 元。甲方在合同签订后支付部分款项项目完成后支付剩余款项具体付款比例和时间由双方另行协商。第三条 开发周期乙方应在合同签订后尽快完成开发。如因甲方需求变化、资料提供不及时或其他原因导致延期双方协商处理。第四条 交付与验收乙方完成系统开发后向甲方提交系统。甲方收到系统后进行验收如甲方认为系统存在问题乙方应继续修改直至甲方满意为止。甲方未提出异议的视为验收通过。第五条 知识产权系统开发完成后项目成果归甲方所有。乙方可以继续使用开发过程中形成的技术成果和相关代码。第六条 保密双方应对合作过程中获知的商业信息承担保密义务未经对方同意不得向第三方披露。第七条 违约责任如乙方未按期完成项目应承担违约责任。若甲方未按期付款双方另行协商解决。第八条 合同解除甲方认为乙方开发结果不符合要求的有权随时解除合同并要求乙方退还全部已收款项。乙方不得无故解除合同。第九条 争议解决双方发生争议的应友好协商解决协商不成的依法处理。第十条 其他本合同自双方签字盖章之日起生效一式两份双方各执一份。甲方杭州星河贸易有限公司乙方上海云启科技有限公司签订日期2026年5月25日运行截图测试结果主要验证了以下几点待复核风险不能直接勾选已确认风险可以勾选点击确认不会清空已有勾选点击忽略只会影响当前行点击“全选”可以勾选当前可见的全部已确认风险点击“一键优化”能够生成优化建议优化弹窗能够展示原条款、风险说明和优化条款从测试效果看风险驱动优化已经完成了第一阶段闭环。用户不需要手动复制风险说明给 AI也不需要重新整理上下文只要在风险审查结果中选择需要处理的问题系统就能自动生成修订建议。4. 本次开发总结本次开发让我对“风险审查”和“合同优化”的关系有了更清楚的理解。风险审查负责发现问题合同优化负责给出修改后的文本两者不是简单重复而是一个完整业务流程中的前后两个环节。在风险驱动优化场景中用户不是让 AI 随意润色全文而是基于已确认的风险点进行定向修订。这样生成的优化条款更有针对性也更容易解释每一条优化建议都能追溯到某个风险点、某段原条款和某条修改建议。本次开发中比较关键的技术点有三个第一前后端继续使用 DTO 和 API 封装保持结构清晰。后端通过 RiskOptimizeRequest 和 RiskOptimizeResponse 明确风险优化的数据输入和输出前端通过 risk.ts 统一封装接口。第二Prompt 设计从“发现风险”扩展到“修订风险”。风险审查 Prompt 关注识别和分类风险优化 Prompt 关注根据原条款和风险建议生成可替换文本。第三前端勾选状态需要按业务主键维护。表格自带 selection 在数据刷新时容易丢失状态因此最终改为自定义复选框并使用 selectedRiskItemIds 保存勾选风险提升了交互稳定性。整体来看本次功能让风险审查模块从“展示风险清单”进一步发展成“支持风险处理”。用户可以确认风险、选择风险、生成优化条款系统也会记录优化历史为后续保存新版本和全文替换打下基础。5. 后续优化方向当前版本完成的是风险驱动合同优化的第一阶段重点是生成优化条款并展示给用户。后续还可以继续从以下方向完善第一支持将优化条款应用到合同正文。目前系统只是展示优化后的条款后续可以增加“应用修改”按钮让用户确认后替换原合同正文。第二保存为新的合同版本。风险优化后的合同不应该覆盖原文而应该生成新的合同版本继续保持合同版本追溯能力。。第三继续优化模型判断标准。风险审查阶段仍然可能出现过度审查问题后续可以引入标准合同模板、风险等级规则和合同类型知识库让系统先更准确地识别风险再更精准地生成修订建议。通过这些优化系统后续可以形成更加完整的合同处理闭环合同生成或导入后进入合同台账用户发起风险审查确认风险后生成优化条款确认修改后保存为新版本最后支持版本对比和历史追溯。这样智契通就不只是一个 AI 生成合同的工具而是逐步接近“智能合同全生命周期处理平台”的目标。
2026山东大学软件学院创新项目实训博客(六)
2026.5.18-2026.5.251. 工作内容本次开发主要围绕智能合同平台中的“风险驱动合同优化”功能展开。项目在上一阶段已经完成了合同风险审查模块能够对合同文本进行风险识别并在前端展示风险分类、风险等级、风险说明、修改建议和复核状态。但是从业务闭环角度看风险审查如果只停留在“发现问题”用户仍然需要手动理解每一条风险并自行修改合同系统的智能化程度还不够完整。因此本次工作的重点是在已有风险审查结果的基础上继续向后推进一步让用户可以选择已经确认的风险点由系统根据风险说明和修改建议自动生成可替换的优化条款。这样风险审查模块不再只是“合同体检报告”而是可以进一步联动合同优化能力形成“发现风险 - 确认风险 - 生成修订建议”的处理链路。本次工作基于现有项目结构完成了风险驱动合同优化功能的第一阶段落地主要包括在风险审查结果表格中增加风险勾选能力限制只有“已确认”的风险才能进入一键优化流程支持用户点击“全选”快速选择所有已经确认的风险点优化“确认/忽略”交互避免点击确认或忽略后清空整张表格的勾选状态点击忽略后默认隐藏该风险但不删除数据库记录保留审查留痕新增风险驱动优化请求和响应 DTO新增风险优化 Prompt 构造逻辑复用已有 AiChatService 调用大模型生成优化条款新增 /api/risk/optimize 接口前端 risk.ts 增加风险优化 API 封装前端 RiskView.vue 增加“一键优化”按钮和优化结果弹窗优化结果展示原条款、风险说明、AI 优化条款和修改摘要将风险驱动优化记录写入历史记录模块2. AI 交互2.1 关于风险审查和合同优化是否重叠提示词合同优化和风险评估这里会不会有功能重叠优化本质不就是对风险的改进优化吗AI 回应AI 将两个模块区分为风险评估负责“发现问题”合同优化负责“改写文本”。风险评估更像合同体检报告输出的是风险清单合同优化更像修订助手输出的是可以替换进合同的条款文本。这个解释让我对本次功能的定位更清晰。风险审查回答的是“哪里有问题、为什么有风险、风险等级是什么”合同优化回答的是“这条内容应该怎么改”。如果把两者完全混在一起用户可能只看到一堆修改后的文本却不知道原来风险在哪里如果只做风险审查用户又需要自己手动修改合同。因此本次开发采用了中间方案保留风险审查的结构化结果同时允许用户选择其中部分风险点进行优化。这样既保留了风险定位和人工复核过程也让系统能够进一步生成可执行的修订建议。2.2 关于风险驱动优化功能如何拆分提示词我想在风险审查结果中增加勾选功能用户勾选风险点后一键优化并且忽略的风险默认从表格中隐藏。请帮我分析这个功能应该如何拆分讲一下业务逻辑和开发步骤。AI 回应AI 将功能拆分为几个关键环节前端风险表格勾选、复核状态控制、已忽略风险隐藏、风险优化请求 DTO、风险优化 Prompt 构造、大模型调用、优化结果结构化返回、前端弹窗展示和历史记录保存。这个拆分比较符合实际开发流程。因为一键优化并不是简单地把合同文本发给 AI而是需要把“用户选中的风险点”作为上下文传给模型。模型需要知道原条款是什么、风险说明是什么、修改建议是什么才能生成更贴合问题的优化条款。本次我没有让系统自动优化所有风险而是让用户先确认、再勾选、再优化。这样做的原因是大模型审查结果不一定全部适用尤其是之前测试中发现模型有时会偏保守可能把一般性优化建议也识别成风险。因此在进入优化前增加人工选择可以减少不必要的自动改写。3. 具体步骤3.1 新增风险优化 DTO新增文件字段结构本次没有直接把前端选中的表格行原样传给大模型而是单独设计了风险优化请求 DTO。RiskOptimizeRequest 用于承载合同 ID、版本 ID、合同全文和选中的风险点列表RiskOptimizeItemRequest 用于描述单条待优化风险包括条款编号、风险分类、风险等级、原条款、风险说明和修改建议。响应部分同样没有直接返回一段纯文本而是设计了 RiskOptimizeResponse 和 RiskOptimizeItemResponse。这样前端可以清楚展示每一条优化结果对应的原风险条款也方便后续继续扩展“保存为新版本”“应用到正文”等能力。DTO 的作用是隔离接口层和业务实体层。风险优化结果目前不直接落到新的数据库表中而是作为一次 AI 修订建议返回给前端并写入历史记录。单独设计 DTO可以让接口结构更加明确也避免为了前端展示强行改动已有的风险结果实体。3.2 扩展风险 Prompt 构造器核心方法风险优化 Prompt 中明确要求模型只能根据原合同条款和风险说明进行修订不得新增与选中风险无关的业务内容optimizedClause 必须是可以直接替换原条款的正式合同文本changeSummary 用一句话说明本次修改解决的问题必须只返回 JSON这里和普通合同润色最大的区别在于普通润色可能关注语言是否正式、表达是否通顺而风险驱动优化更关注“是否解决了指定风险”。因此 Prompt 中必须把原条款、风险说明、修改建议都作为输入让模型围绕具体问题生成修订条款。3.3 新增风险驱动优化服务逻辑核心方法这里的重点是复用已有的 AiChatService而不是重新写一套 AI 调用逻辑。项目中已经有统一的大模型调用服务风险审查、摘要提取、合同生成都可以围绕它做业务 Prompt 封装。这样做可以保持 AI 调用入口统一后续如果模型地址、模型名称或鉴权方式变化只需要改 AiChatService 或配置层。本次优化结果暂时没有直接替换合同正文也没有直接生成新版本。这是有意控制范围。因为“自动替换全文”需要处理条款定位、文本替换、版本保存、用户确认等更多问题容易一下做得太大。第一阶段先生成可替换条款并展示给用户既能体现业务闭环又保留后续继续开发空间。3.4 改造风险 Controller新增接口本次在 RiskController 中新增了 /api/risk/optimize 接口。Controller 仍然保持较薄的写法只负责接收请求、调用 RiskAnalysisService并统一包装 ApiResponse。这里没有在 Controller 中直接拼 Prompt 或调用大模型是为了保持分层清晰。Controller 负责接口入口Service 负责编排业务流程PromptBuilder 负责 Prompt 文本AiChatService 负责模型调用。这个分层和前面摘要、风险审查模块保持一致。3.5 新增前端风险优化 API代码截图这样做的好处是页面组件不需要关心接口路径和请求结构只需要调用 optimizeRisks。后续如果后端接口路径调整或者请求字段增加只需要集中修改 risk.ts不需要在页面中到处找请求代码。这也延续了项目中已有的前端工程化风格页面负责 UI 和交互api 文件负责请求封装类型定义负责约束数据结构。3.6 改造前端风险审查页面代码截图前端页面新增能力包括已确认风险可以勾选待复核风险不能勾选已忽略风险默认隐藏点击“显示已忽略”可以查看被忽略的风险点击“全选已确认”可以快速勾选当前可见的全部已确认风险点击“一键优化”后调用后端接口生成优化条款优化结果以弹窗展示原条款、风险说明、AI 优化条款和修改摘要在实现过程中我还遇到了一个比较典型的前端交互问题。最初使用 Element Plus 表格自带的 selection 列来处理勾选但点击确认或忽略后表格数据更新会触发 selection-change导致整张表的勾选状态被清空。后来我改成普通复选框列并用 selectedRiskItemIds 自己维护勾选状态。这个调整让我意识到复杂表格交互中不能完全依赖组件内部状态。尤其当表格行会被更新、隐藏或过滤时勾选状态最好由业务代码按主键维护。这里使用 resultId 作为风险行的唯一标识点击确认不会影响已勾选项点击忽略时只移除当前行的勾选状态其他行保持不变。这样交互更符合用户预期。3.7 测试效果本次测试先使用一份存在明显风险的软件开发服务合同。系统完成风险审查后用户先对部分风险点击“确认”然后勾选其中几条风险点击“一键优化”。后端根据原合同文本、选中的风险条款、风险说明和修改建议生成了对应的优化条款。测试合同文本软件开发服务合同甲方杭州星河贸易有限公司乙方上海云启科技有限公司第一条 项目内容甲方委托乙方开发一套客户订单管理系统系统包括客户管理、订单录入、订单查询和数据统计等功能。具体功能以双方沟通为准。第二条 合同金额本合同总金额为人民币 100000 元。甲方在合同签订后支付部分款项项目完成后支付剩余款项具体付款比例和时间由双方另行协商。第三条 开发周期乙方应在合同签订后尽快完成开发。如因甲方需求变化、资料提供不及时或其他原因导致延期双方协商处理。第四条 交付与验收乙方完成系统开发后向甲方提交系统。甲方收到系统后进行验收如甲方认为系统存在问题乙方应继续修改直至甲方满意为止。甲方未提出异议的视为验收通过。第五条 知识产权系统开发完成后项目成果归甲方所有。乙方可以继续使用开发过程中形成的技术成果和相关代码。第六条 保密双方应对合作过程中获知的商业信息承担保密义务未经对方同意不得向第三方披露。第七条 违约责任如乙方未按期完成项目应承担违约责任。若甲方未按期付款双方另行协商解决。第八条 合同解除甲方认为乙方开发结果不符合要求的有权随时解除合同并要求乙方退还全部已收款项。乙方不得无故解除合同。第九条 争议解决双方发生争议的应友好协商解决协商不成的依法处理。第十条 其他本合同自双方签字盖章之日起生效一式两份双方各执一份。甲方杭州星河贸易有限公司乙方上海云启科技有限公司签订日期2026年5月25日运行截图测试结果主要验证了以下几点待复核风险不能直接勾选已确认风险可以勾选点击确认不会清空已有勾选点击忽略只会影响当前行点击“全选”可以勾选当前可见的全部已确认风险点击“一键优化”能够生成优化建议优化弹窗能够展示原条款、风险说明和优化条款从测试效果看风险驱动优化已经完成了第一阶段闭环。用户不需要手动复制风险说明给 AI也不需要重新整理上下文只要在风险审查结果中选择需要处理的问题系统就能自动生成修订建议。4. 本次开发总结本次开发让我对“风险审查”和“合同优化”的关系有了更清楚的理解。风险审查负责发现问题合同优化负责给出修改后的文本两者不是简单重复而是一个完整业务流程中的前后两个环节。在风险驱动优化场景中用户不是让 AI 随意润色全文而是基于已确认的风险点进行定向修订。这样生成的优化条款更有针对性也更容易解释每一条优化建议都能追溯到某个风险点、某段原条款和某条修改建议。本次开发中比较关键的技术点有三个第一前后端继续使用 DTO 和 API 封装保持结构清晰。后端通过 RiskOptimizeRequest 和 RiskOptimizeResponse 明确风险优化的数据输入和输出前端通过 risk.ts 统一封装接口。第二Prompt 设计从“发现风险”扩展到“修订风险”。风险审查 Prompt 关注识别和分类风险优化 Prompt 关注根据原条款和风险建议生成可替换文本。第三前端勾选状态需要按业务主键维护。表格自带 selection 在数据刷新时容易丢失状态因此最终改为自定义复选框并使用 selectedRiskItemIds 保存勾选风险提升了交互稳定性。整体来看本次功能让风险审查模块从“展示风险清单”进一步发展成“支持风险处理”。用户可以确认风险、选择风险、生成优化条款系统也会记录优化历史为后续保存新版本和全文替换打下基础。5. 后续优化方向当前版本完成的是风险驱动合同优化的第一阶段重点是生成优化条款并展示给用户。后续还可以继续从以下方向完善第一支持将优化条款应用到合同正文。目前系统只是展示优化后的条款后续可以增加“应用修改”按钮让用户确认后替换原合同正文。第二保存为新的合同版本。风险优化后的合同不应该覆盖原文而应该生成新的合同版本继续保持合同版本追溯能力。。第三继续优化模型判断标准。风险审查阶段仍然可能出现过度审查问题后续可以引入标准合同模板、风险等级规则和合同类型知识库让系统先更准确地识别风险再更精准地生成修订建议。通过这些优化系统后续可以形成更加完整的合同处理闭环合同生成或导入后进入合同台账用户发起风险审查确认风险后生成优化条款确认修改后保存为新版本最后支持版本对比和历史追溯。这样智契通就不只是一个 AI 生成合同的工具而是逐步接近“智能合同全生命周期处理平台”的目标。
