2026.5.18-2026.5.25

1. 工作内容

        本次开发主要围绕智能合同平台中的“风险驱动合同优化”功能展开。项目在上一阶段已经完成了合同风险审查模块，能够对合同文本进行风险识别，并在前端展示风险分类、风险等级、风险说明、修改建议和复核状态。但是从业务闭环角度看，风险审查如果只停留在“发现问题”，用户仍然需要手动理解每一条风险并自行修改合同，系统的智能化程度还不够完整。

        因此本次工作的重点，是在已有风险审查结果的基础上，继续向后推进一步：让用户可以选择已经确认的风险点，由系统根据风险说明和修改建议自动生成可替换的优化条款。这样风险审查模块不再只是“合同体检报告”，而是可以进一步联动合同优化能力，形成“发现风险 -> 确认风险 -> 生成修订建议”的处理链路。

本次工作基于现有项目结构，完成了风险驱动合同优化功能的第一阶段落地，主要包括：

在风险审查结果表格中增加风险勾选能力
限制只有“已确认”的风险才能进入一键优化流程
支持用户点击“全选”，快速选择所有已经确认的风险点
优化“确认/忽略”交互，避免点击确认或忽略后清空整张表格的勾选状态
点击忽略后默认隐藏该风险，但不删除数据库记录，保留审查留痕
新增风险驱动优化请求和响应 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 生成合同的工具，而是逐步接近“智能合同全生命周期处理平台”的目标。