yuqei/ai-contract-platform

Fork 0

Files

T

yuqei a3bb78e06b

Security Quality Gate / npm audit, Bandit, pip-audit, detect-secrets (pull_request) Failing after 16m35s

Details

release: freeze V2 release candidate

2026-07-12 15:32:24 +08:00

6.1 KiB

Raw Blame History

AI 合同平台 V2 对照 V1 功能缺口审计

日期：2026-07-03

对照来源

V1 线上入口：http://contact.yuqei.com/
V1 源码目录：D:\yuqei-project\ai-contract-platform-v1
V2 源码目录：D:\yuqei-project\ai-contract-platform

本次以源码为准，线上 V1 入口用于确认公开产品形态。

总体结论

V2 已经吸收并强化了 V1 的核心合同能力，包括：

模板库、变量 schema、模板树、模板发布/下线/回滚/历史。
标准条款库、审查规则库、条款推荐、规则下线边界。
法律全文库精选迁移、法律版本表、法规变更影响扫描。
AI Trace、质量动作、Prompt/模型/知识库管理。
审查结果结构化、风险项/引用依据只读 API、条款修复。
合同审批、版本、文件、通知、履约、签署证据、归档、统一搜索。
Docker smoke、schema-check、接口压测、安全扫描、CI 质量门。

当前仍值得从 V1 回补的主要不是“合同核心骨架”，而是产品化和交付体验层能力。

建议加入但 V2 尚未完整闭环

优先级	V1 能力	V2 当前状态	是否建议加入	建议方式
P0	审查报告 PDF/报告交付	V2 有审查风险、引用依据和文件系统，但未看到审查报告生成/下载 API 与前端入口	强烈建议	基于 V2 结构化审查结果生成报告，不迁 V1 旧实现；先做 HTML/PDF 模板、报告文件入库、下载事件审计
P1	用户、租户设置、账号管理	V2 有 tenant context 和轻量访问控制，但没有完整用户/租户后台页面	建议加入	做最小管理员后台：用户列表、角色、租户配置、默认配额；先不做复杂组织架构
P1	全局审计日志查看	V2 有合同时间线、审计完整性和 AI Trace，但缺全局 Contract audit log 页面	建议加入	增加管理员审计中心，聚合合同事件、下载事件、审批、模板/法律资产发布事件
P1	法律文书起草体系	V1 有 `legal-document-types`、element schema、draft、generate-from-draft 和移动端入口；V2 主要是合同模板起草	建议分阶段加入	先迁“催告函、解除通知、授权委托书、法律意见书”这类高频非合同文书，沿用 V2 模板/快照/版本化模型
P1	用户侧法律问答/Chat 页面	V2 后端已有 `/api/v1/legal/qa` 代理和 AI Platform legal QA，但前端没有独立用户问答页	建议加入	做轻量法律问答页，支持来源卡、Trace 链接、从合同风险项带上下文进入问答
P2	公开首页、演示申请、试点申请	V1 有 landing、pricing、demo-request、pilot-requests；V2 首页直接进入工作台	若 V2 要对外发布则建议	做公开首页 + 演示申请，先不做完整订单支付；申请数据进入销售/试点队列
P2	商业套餐、计费、订单/发票	V1 有 pricing、billing、commercial plans、order/invoice 模型	可后置	先迁套餐展示和用量概览；真实支付、发票、订单后台等商业闭环等产品上线后再做
P2	销售跟进和试点运营	V1 有 sales-followups、pilot readiness、operation-kpis	可后置但有价值	若要做商业化试点，加入试点看板、跟进事件、试点 KPI；内部交付可暂缓
P2	运营 KPI 看板	V2 有 dashboard 和质量门文档，但没有 V1 `operation-kpis` 运营指标页	建议后置	复用 V2 审查、报告、模板、Trace、知识库指标，做运营看板
P3	移动端 Flutter 客户端	V1 mobile 已覆盖登录、审查、报告、合同生成、法律文书、Chat、版本链、真机 smoke	暂不建议现在加入	V2 Web 收口后单独立项；不要把 V1 Flutter 代码直接塞进 V2 主线
P3	形式化上线治理工作台	V1 有 governance assets/imports/releases/workbench	可按企业交付需要加入	V2 已有 schema governance 和质量门；若做正式客户交付，可做“交付证据/签收/上线门禁”管理页

已加入或基本覆盖，不应重复开发

V1 能力	V2 状态
模板化合同起草	已覆盖，V2 还有发布快照和生命周期管理
30 个 Phase13 合同模板与变量 schema	已覆盖，V1 当前 Phase13 模板数和 V2 迁移资产均为 30
标准条款库和审查规则库	已覆盖，V2 有管理页、diff、校验、发布快照
法律全文库精选与法规影响扫描	已覆盖，V2 已有 `legal_fulltext_versions`
黄金样本与质量评估资产	已覆盖，V2 AI golden gate 已纳入 Docker smoke
Prompt/模型/知识库/Trace 管理	已覆盖，V2 AI 管理后台更完整
文件仓储、审批、合同版本、通知、履约、签署证据、归档	V2 已覆盖
V1 同步 auto-review 体验	不建议迁，V2 异步 worker 更合理
V1 单体后端结构	不建议迁，V2 拆分架构更合理

不建议直接迁移

V1 单体 FastAPI 后端结构。
V1 页面大而全布局。
V1 同步审查调用体验。
V1 旧 PDF 实现本身。应保留“报告交付”产品目标，用 V2 结构化审查结果重建。
V1 商业订单/发票/支付后台的完整实现，除非 V2 确认进入对外商用阶段。

建议下一步

最值得先做的是 P0：审查报告 PDF/报告交付。

原因：

V1 线上产品叙事明确包含“报告交付”。
V2 已有结构化风险、引用依据、条款推荐、文件仓储和下载审计，生成报告的基础数据已经齐。
报告是客户可感知的交付物，比继续扩后台运营更能补齐产品闭环。

建议第一片范围：

GET /api/v1/contracts/{contract_id}/review-report
POST /api/v1/contracts/{contract_id}/review-report
GET /api/v1/contracts/{contract_id}/review-report/download
报告内容包含合同摘要、风险分布、风险项、引用依据、条款推荐、修复状态、免责声明。
报告文件进入 V2 file repository，下载写入审计事件。
前端在合同详情页审查区增加“生成/下载审查报告”入口。

6.1 KiB Raw Blame History Unescape Escape