yuqei
1d85329a6a
36 KiB
AI 合同平台系统性产品、市场、架构与体验审查报告
审查日期：2026-08-22
审查角色：产品经理、项目经理、技术架构与用户体验联合视角
审查对象：ai-contract-platform当前工作区实现
结论性质：产品与工程决策建议，不构成正式法律意见、等保测评、渗透测试或生产验收签字
1. 一页结论
该项目已经不是一个简单演示原型，而是一个覆盖“合同起草—审查—审批—签署证据—归档—履约—审计”的较完整 AI 合同工作台。其服务拆分、多租户、法律资产、AI 审计、版本与发布治理、CI/CD 和生产配置闸门，明显优于一般早期项目。
但当前最关键的问题不是“功能还不够多”，而是“核心承诺是否可信”。本次真实浏览器审查发现：由模板生成的合同会把未填写的可选字段保留为 【字段名】，并把 CLAUSE-*、RULE-* 以及“系统不得……”等内部护栏文字写入客户合同正文；系统仍允许该正文下载和提交审批。另一个真实问题是：个人租户发起合同审查后，后台 worker 因没有在任务租户上下文中读取合同而失败，界面显示 Contract not found when executing review task.。这两项都会直接破坏用户信任，属于公开上线前必须解决的 P0。
综合判断：
| 上线场景 | 判断 | 前提 |
|---|---|---|
| 内部演示与受控产品展示 | Go | 明确标注演示数据和非正式法律文本 |
| 3–5 家设计伙伴的封闭试点 | Conditional Go | 完成本文 P0，配备人工法务与客服兜底 |
| 面向公众自助注册、生成和下载 | No-Go | 正文质量闸门、异步审查、正式政策和 AI 合规尚未闭环 |
| 公开付费企业 SaaS | No-Go | 还缺商业计量、服务承诺、集成、正式签署链路和生产运行证据 |
| 律所通用业务系统 | No-Go | 律所需要案件/客户/利益冲突/工时计费/工作成果隔离等另一套产品发现 |
建议把未来 12 周目标从“继续扩展模块”改为：让一个中国中小企业的法务、采购或业务人员，在 3 分钟内得到一份可继续编辑的可靠草稿或成功启动一次审查，并能在同一工作台完成协作决策。
2. 审查范围、方法与限制
2.1 方法
本次审查使用了以下证据，而不是只阅读需求文档：
- 盘点四个主要工程根目录、OpenAPI、迁移、工作流、前端页面、代理路由、CI/CD、测试和既有项目审查文档。
- 在隔离的本地 SQLite、文件目录和测试账号中启动 Contract API、AI API、Review Worker 与 Next.js Web。
- 使用真实浏览器走查桌面端和移动端：公开首页、注册、登录、个人空间、模板起草、合同详情、审批、下载、AI 审查、隐私政策和 AI Trace 管理页。
- 下载真实生成的 DOCX 并解析正文，统计未解决占位符和内部代码。
- 执行前端单测、TypeScript 检查、生产构建、Python 测试和 npm 依赖审计。
- 对照当前国内外合同管理/法律 AI 产品和中国现行 AI、数据、电子签名相关监管要求。
2.2 限制
- 本机没有 Docker，因此没有重新完成 Compose、PostgreSQL、Redis、MinIO、多副本、TLS、备份恢复和真实生产密钥的端到端演练。
- 本地 AI Provider 被禁用，未评价真实大模型的法律准确率、成本和时延；但本次审查失败发生在调用 Provider 之前，已能定位为合同 worker 的租户上下文问题。
- 没有真实客户访谈、埋点、漏斗、续费、客服工单或销售输单数据，市场结论仍需通过设计伙伴验证。
- 没有代替公司律师完成隐私、服务、用户、AI 声明的正式法律审查。
- 当前工作区在审查开始前已有未提交修改。本报告把“当前可运行状态”作为基线，未改写这些既有修改。
3. 综合评分
以下分数用于排优先级，不是第三方认证结果。
| 维度 | 评分（10 分） | 判断 |
|---|---|---|
| 产品定位 | 7.0 | 已接近“中小企业合同风险决策与协作工作台”，方向正确 |
| 核心功能覆盖 | 7.0 | 起草、审查、审批、归档、履约、审计覆盖广 |
| 首次价值与易用性 | 5.0 | 起草字段过多、导航过载、注册协议摩擦较大 |
| 合同输出与 AI 可靠性 | 4.0 | 正文污染和跨租户 worker 失败是信任级阻断 |
| 信息架构与角色适配 | 5.0 | 个人空间 owner 被等同系统 admin，后台概念泄露给普通用户 |
| 技术架构方向 | 7.5 | 服务边界、OpenAPI、PostgreSQL/Redis/S3 方向合理 |
| 工程质量与交付 | 7.0 | 测试、迁移、发布与安全扫描较完整，但关键真实旅程未进 CI |
| 安全与多租户治理 | 6.0 | 设计意识强；后台任务的默认租户回退暴露了实现缺口 |
| 合规与信任准备 | 4.0 | 对外政策仍是 draft，模型备案/标识/生产签字未形成证据链 |
| 商业化与运营准备 | 3.5 | 缺计量、套餐、支付、支持承诺、客户证明和关键集成 |
综合成熟度约为 5.7/10：产品广度达到试点前期，核心质量和商业运营仍处于验证期。
4. 市场判断：符合什么需求，不符合什么需求
4.1 市场基线已经提高
当前市场不再把“能用 AI 写一份合同”视为足够差异化。Docusign 的公开产品已经把生成、审查、审批、签署、集中存储、义务提醒、搜索、AI 和连接器放在同一个 CLM/IAM 叙事中；e签宝公开能力覆盖模板、在线编辑、审批、电子签署、存证、履约和分析；法大大 2026 年面向个人的合同助手也已经提供咨询、起草、审查、签署、归档和到期提醒；法天使强调企业规则、知识资产、审查和起草定制；Icertis 和 Juro 则把智能合同库、自然语言问答和大量集成作为基础能力。详见第 16 节来源。
因此，本项目不能用“AI 合同平台”这一宽泛品类参与竞争，应在一个高频、高痛点、有付费人的场景建立楔子。
4.2 推荐 ICP 与定位
第一优先 ICP： 中国大陆 50–1000 人、合同量持续增长但没有成熟 CLM 的科技、专业服务、制造/贸易型中小企业；购买者是创始人、财务/法务负责人或采购负责人；日常使用者是法务、采购和业务团队。
首要场景： 采购、技术服务、SaaS/软件、委托服务等高频合同的“发起—风险审查—协作审批—签署归档—到期/义务提醒”。
一句话定位：
面向中国成长型企业的合同风险决策与协作工作台：用可追溯的法律依据和企业规则，把起草、审查、审批与履约串成一个闭环。
这比“合同生成网站”更有价值，因为客户购买的不是文档，而是降低漏审、错签、失约和跨部门等待的风险。
4.3 三类客群不要同时当主战场
| 客群 | 当前策略 | 原因 |
|---|---|---|
| 个人 | 作为低成本获客和激活入口 | 需求碎片化、付费低、法律责任预期高；适合有限免费额度和转人工咨询 |
| 企业 | 主产品与主收入来源 | 协作、审批、规则、审计、履约和集成能形成持续价值与切换成本 |
| 律所 | 先作为内容/实施/人工复核伙伴，后做专项版本 | 律所还需要客户与案件隔离、利益冲突检查、工作成果、工时计费、私有知识库等 |
4.4 竞争优势与缺口
| 能力 | 当前项目 | 市场判断 | 建议 |
|---|---|---|---|
| 中国法律资产与来源引用 | 已有较深资产和审计设计 | 可形成差异化 | 把“依据、版本、置信度、人工确认”做成用户可感知卖点 |
| 模板起草 | 30 个模板，覆盖广 | 有用但质量门不足 | 先做 6–8 个高频精品模板和场景向导，暂不追求数量 |
| AI 审查 | 流程和结构化结果已具备 | 当前可靠性不足 | 修复租户 worker，建立黄金集、回归、降级和人工兜底 |
| 审批/审计/版本 | 基础完整 | 企业试点所需 | 强化职责分离和工作流状态机 |
| 电子签署 | 目前更多是“证据记录”概念 | 国内客户普遍预期 | 对接 e签宝/法大大等，不自建 CA 与签名基础设施 |
| 集成 | OpenAPI/SDK 基础存在 | 终端集成不足 | 优先企业微信/钉钉/飞书、Word/WPS、邮箱、网盘和 OA |
| 商业化 | 条款提及套餐/配额，系统缺少闭环 | 不可规模收费 | 设计伙伴期先人工开通；有使用数据后再实现计量和账单 |
| 信任证明 | 首页有边界说明 | 缺真实证据 | 增加样例报告、方法说明、数据边界、客户案例、支持入口和合规编号 |
5. 真实用户旅程审查
5.1 公开首页
优点：视觉风格专业，深绿色/金色品牌辨识度较好；核心能力和适用场景表述清晰；桌面与移动端没有明显横向溢出；“免费开始使用”入口明确。
问题：页面主要在描述“我们有什么”，缺少促成信任和行动的证据。用户看不到真实审查报告样例、生成合同样例、数据如何处理、哪些模型被使用、服务响应、客户/专家背书、试用额度、团队试点入口、电子签署与常用办公软件集成。
修改：
- 首屏保留一个主 CTA“免费审查一份合同”，增加次 CTA“预约企业试点”。
- 在首屏下方直接展示一个匿名化“风险卡片—法律依据—建议文本—置信度”的真实交互样例。
- 用可验证事实替代泛化口号：已支持的合同类型、平均处理时长区间、数据保留选项、是否训练模型、可部署方式、支持渠道。
- 将个人入口和团队入口分流，而不是让二者共享同一套功能承诺。
- 在没有完整计量和服务能力之前，不承诺具体价格与 SLA；可以明确“试点申请”和“有限免费体验”。
5.2 注册与协议
注册页有个人/组织切换，但要求用户勾选四个同权重协议，且界面显示版本 2026-08-01-draft。公开隐私页是简短的四段概述，却标记为“当前适用”，没有完整展示处理者身份和联系方式、数据类别、保存期限、第三方/模型提供商、跨境、删除与投诉路径等关键细节。
建议：
- 任何公开注册前，正式发布经法务签字的用户协议、隐私政策、服务协议和 AI 特别说明，版本不得包含
draft。 - 协议版本、摘要、正文哈希、签字文件、发布时间、适用范围和用户同意记录应能形成同一证据链。
- 在法律允许且经律师确认的前提下，将通用条款合并为一个主勾选；AI 特别说明保持显著、独立且可展开，减少四个等权勾选的认知负担。
- 注册后先问“你今天想做什么：审查现有合同 / 起草新合同 / 管理已有合同”，而不是直接把用户投放到完整后台。
5.3 首次进入工作台
工作台自身的信息结构较好，有待办、快速开始和合同生命周期。然而个人空间 owner 被赋予 admin 角色后，会看到资产管理、系统管理、AI Trace、系统健康等约 18 个导航项。移动端虽然适配正常，但同样把庞大后台塞进抽屉。
本地新建个人空间还出现了“采购框架协议履约节点”等演示待办。生产配置有禁用 seed 的闸门，这是优点；但体验上仍应保证真实新空间为空，或明确标记“示例数据，可一键清除”。
建议按“空间类型 + 角色 + 套餐/能力”生成导航，不再仅按 role=admin：
| 用户视角 | 建议主导航 |
|---|---|
| 个人 | 工作台、我的合同、AI 审查、模板起草、文件、提醒、设置 |
| 企业业务/采购 | 工作台、发起合同、合同库、我的任务、文件、搜索 |
| 企业法务 | 工作台、审查队列、合同库、模板与条款、企业规则、法律更新、报告 |
| 企业管理员 | 成员与角色、审批规则、安全、审计、集成、用量/账单 |
| 平台运营 | AI 模型、知识、质量、Trace、运行状态、租户支持；使用独立入口和平台权限 |
5.4 模板起草
当前页面一次展示 30 个模板、多个分类和密集字段。界面显示“类型分组 30”，实际是模板数量，属于指标文案错误。部分模板有 14–24 个必填字段，连“催告函”也需要 14 个必填项，难以实现 3 分钟首次价值。
目标流程应改为：
选择业务场景
→ 回答 5–7 个核心问题
→ 立即生成可编辑预览
→ 系统提示缺失信息和风险
→ 按需展开金额、交付、违约、争议等高级条款
→ 质量检查通过后下载或提交审批
产品措施：
- 首期重点打磨采购、技术服务、SaaS、委托服务、保密、劳动等 6–8 个模板。
- 用业务问句代替法律变量名，如“服务不合格时希望对方几天内整改？”。
- 根据上一步答案动态显示字段；可选字段为空时应删除或选择安全的中性条款，不能留下占位符。
- 支持保存进度、从历史合同预填、企业主体资料复用、对方信息识别和 Word 上传补全。
- 在生成前显示“还需约 2 分钟/7 个问题”，而不是让用户面对未知长度表单。
5.5 合同输出：当前最高风险
本次用“委托服务”模板填写 7 个必填项并留空可选项，生成后下载 DOCX。自动解析结果：
| 检查项 | 结果 |
|---|---|
| 文件大小 | 38,645 bytes |
【…】 未解决占位符 |
9 |
CLAUSE-* 内部条款代码 |
6 |
RULE-* 内部规则代码 |
5 |
| “系统不得/护栏不得”等内部控制文字 | 存在 |
源码也验证了这一行为：contract_templates.py 在可选变量为空时主动替换为 【变量名】，而模板 Markdown 本身含有内部条款/规则编号和系统护栏。系统只校验必填变量，不校验最终正文是否适合交付。
更严重的是，该文档仍可下载和“提交审批”。这意味着系统把内部法律知识工程资产与客户签署文本混在一起。
必须建立三层内容模型：
- 合同正文：只包含当事人最终可能签署的文字。
- 起草说明：缺失信息、适用边界、需要人工确认的事项。
- 法律与系统证据：条款 ID、规则 ID、法条引用、模型与生成记录、护栏结果。
三者可以在 UI 中关联，但下载合同正文时必须物理隔离。
5.6 审查、审批与状态
真实流程表现：
- 个人租户可成功发起审查任务，但 worker 读取合同时返回“找不到合同”。任务对象已有
tenant_id，调用 AI Platform 时也使用该租户；只有repository.get_contract(task.contract_id)等本地读取仍依赖默认租户上下文。这是异步任务多租户实现缺陷。 - 合同在“待审批”时仍可发起审查，状态变为“审查中”，原审批请求没有明确取消、失效或创建新版本。用户无法理解哪个版本正在被审批。
- 个人空间 owner 既可提交，又可看到“审批通过/退回修改”。对于个人用户应叫“确认定稿”；对于企业流程，至少在需要职责分离的规则中禁止同一账号自提自批。
建议使用显式状态机，而不是各模块直接覆盖一个 status：
草稿 v1 → 审查中 → 审查完成 → 待审批 → 已批准 → 待签署 → 已签署 → 履约中 → 已归档
↘ 审查失败（可重试/人工处理）
待审批 + 正文变更/重新审查 → 明确撤销审批 → 新版本 v2
审批对象必须绑定 contract_version_id + content_hash，任何正文修改都使旧审批自动失效并留下审计事件。
6. P0：公开试点前必须完成
| 编号 | 问题与修改 | 验收标准 | 建议责任人 | 粗略工作量 |
|---|---|---|---|---|
| P0-01 | 建立合同正文编译器和发布闸门；移除占位符、内部 ID、护栏话术；正文/说明/证据分层 | 30 个模板分别用“最少必填”和“全字段”生成；DOCX/PDF/页面均为 0 个 {{}}、【】、CLAUSE-*、RULE-* 和系统护栏；失败时禁止下载/审批 |
BE + Legal + QA | L |
| P0-02 | 修复 review worker 租户上下文；repository 后台调用强制显式 tenant_id，取消默认租户回退 |
default、personal、organization 三类租户 E2E 全通过；跨租户 ID 不能读取；任务成功/失败/重试均按租户记录 | BE + Security + QA | M |
| P0-03 | 建立合同版本状态机和审批不变量 | 审批绑定版本与哈希；待审批正文变化会撤销旧审批；审批人不能审批自己的提交（规则要求时）；不合格正文不可提交 | BE + PM + QA | L |
| P0-04 | 发布正式政策和同意证据 | 对外无 draft；公司律师签字；正文、版本、摘要、哈希、发布时间、同意记录可追踪；隐私页信息完整 |
Legal + PM + BE | M |
| P0-05 | 完成生成式 AI 备案/上线披露与内容标识核查 | 页面显著展示实际模型名称及适用的备案/上线编号；用户协议说明标识；导出内容按现行要求带显式/隐式标识；保留生成日志 | Legal + AI + BE | M |
| P0-06 | 把真实关键旅程加入 CI | 每次合并自动运行：最小字段生成、正文净化、个人/企业 worker、审批失效、职责分离、政策非 draft；失败阻断发布 | QA + FE + BE | M |
| P0-07 | 增加试点运行兜底 | 审查失败可见、可重试、可转人工；告警包含 tenant/task/correlation ID；有客服入口和故障响应人 | Ops + PM + BE | M |
P0 完成前应冻结以下扩展：新增低频模板、新的运营后台页面、更复杂的平台特权身份功能、自己建设电子签名 CA、完整计费系统。
7. P1/P2 产品与体验路线图
7.1 P1：提升首次价值和企业试点能力
| 编号 | 修改 | 关键验收 |
|---|---|---|
| P1-01 | 场景式起草向导和渐进表单 | 6–8 个主模板核心问题不超过 7 个；中位首次草稿时间小于 3 分钟 |
| P1-02 | 按空间/角色/能力重构导航 | 个人用户看不到 AI Runtime/Trace/系统健康；每个角色主导航不超过 7 项 |
| P1-03 | 上传即审查 | 支持 DOCX/PDF/图片，展示解析进度、失败原因、来源页码、风险等级和可应用建议 |
| P1-04 | 企业 Playbook | 客户可配置禁用条款、金额阈值、兜底文本、审批规则；结果解释命中哪条企业规则 |
| P1-05 | Onboarding | 新用户目标选择、示例/空状态、3 步导览、主体资料复用、首个结果后的下一步 |
| P1-06 | 电子签署连接器 | 完成一家主流国内电子签约平台集成；签署链接、身份、时间戳、证书/存证回写 |
| P1-07 | 试点运营后台 | 租户用量、激活、成功率、失败任务、人工复核队列，不向普通租户管理员暴露平台运维能力 |
| P1-08 | 首页信任与转化 | 增加真实样例、数据边界、支持入口、团队试点 CTA 和可验证客户证据 |
7.2 P2：规模化与生态
- Word/WPS 插件：在客户原有编辑环境中显示风险、依据、替换建议和版本差异。
- 企业微信/钉钉/飞书/OA：发起、审批、提醒和回写；先做 1–2 个设计伙伴最常用集成。
- 邮箱/网盘/ERP/采购系统连接器：减少重复上传与录入。
- 用量计量、套餐、账单和超额提示：以试点数据决定计费单位，避免先做复杂支付。
- 企业私有知识库、数据保留策略、单点登录和更强隔离；大型客户再评估私有化。
- 律所版产品发现：至少访谈 8–12 位律师/合伙人后，再决定客户/案件/利益冲突/工时等范围。
8. 技术架构评估
8.1 建议保留的部分
当前总体方向合理：Next.js/React/TypeScript Web，FastAPI/SQLAlchemy/Alembic 合同服务，独立 AI Platform 和 SDK，异步 worker，PostgreSQL、Redis、S3/MinIO，OpenAPI，Docker Compose/Nginx。这些边界与合同域、AI 域、异步文件/任务域基本匹配，不建议为了“统一技术栈”进行大重写。
建议继续保留：
- Contract Platform 作为合同事实与工作流的 System of Record。
- AI Platform 作为模型、知识、检索、质量和审计域，不直接拥有合同状态。
- PostgreSQL 作为权威数据，Redis 只作缓存/队列，S3/MinIO 保存原件和导出物。
- OpenAPI/SDK 作为跨服务契约，发布前有迁移和运行配置检查。
8.2 必须优化的边界
A. 多租户上下文必须是强类型输入
后台 worker 不能依赖 Web 请求时设置的 ambient tenant。建议所有 repository/service 写法改为：
TaskEnvelope {
task_id, tenant_id, actor_id, contract_id, contract_version_id,
correlation_id, idempotency_key, attempt, created_at
}
后台读取、写入、完成和失败接口都显式接收 tenant_id；数据库查询同时匹配业务 ID 与租户 ID。可在 PostgreSQL 层逐步增加 RLS 作为纵深防御，但不能用 RLS 代替应用层授权。
B. 统一异步任务语义
Contract Review Worker 与 AI Worker 应共享任务信封、租约、幂等、重试、退避、死信、取消和指标标准。明确谁负责 OCR、谁负责审查、谁写合同状态。通过 outbox 保证“状态变更”和“投递任务”不出现一边成功、一边丢失。
C. 工作流状态机独立建模
审查、审批、签署和归档不应争抢一个可任意覆盖的状态字段。可使用显式 transition service 与不变量测试，不一定要引入新的工作流产品。审批、审查都绑定不可变版本；UI 只通过服务返回的 allowed actions 渲染按钮。
D. 缩小大型模块
当前存在明显的代码集中风险：AI repository.py 超过 5,700 行，合同 identity persistence 超过 3,000 行，前端 contracts.ts 超过 2,400 行，多张管理页接近或超过 1,000 行。建议按 aggregate/use case 拆分 repository、command/query、DTO 和页面 feature；设定单文件新增阈值和 ownership，而不是机械地按行数切文件。
E. 收敛 128 个手写 Next 代理路由
大量重复代理增加鉴权、Header、错误映射和缓存策略漂移风险。建议从 OpenAPI 生成类型客户端和一致的 server-side BFF helper，按合同/身份/AI/文件边界组织；不要改成没有白名单的通用透明代理。
F. 设计系统与前端结构
当前 design-system 包很小，许多复杂页面各自实现布局和状态。优先沉淀表单、步骤器、风险卡、来源引用、空/错/加载态、权限提示、数据表格和移动端抽屉；大型管理页拆为 feature modules。视觉风格本身不需要推倒重做。
9. 测试、CI/CD 与可维护性
9.1 本次实际结果
| 检查 | 结果 |
|---|---|
| 前端单元测试 | 28 passed |
TypeScript tsc --noEmit |
passed |
| Next.js 生产构建 | passed；成功收集/生成 104 个路由页面 |
| Contract API Python | 303 passed，4 skipped |
| AI Platform Python | 151 passed |
| Worker + SDK + Infra Python | 166 passed |
| Python 合计 | 620 passed，4 skipped |
npm audit --omit=dev --audit-level=high |
0 vulnerabilities |
这说明工程基本面较好，但也说明现有测试与用户价值风险没有对齐：620 个 Python 测试和 28 个前端测试全部通过，真实个人租户审查仍失败，含内部代码和占位符的合同仍能进入审批。
9.2 当前质量门缺口
- 主 CI 会执行前端 typecheck/build，但没有执行已经存在的前端单测。
- 没有浏览器 E2E 覆盖个人/组织注册后的核心旅程。
- 现有模板 sweep 会填满全部可选字段，因此没有覆盖普通用户“只填必填”的主路径。
- sweep 只把
{{…}}当未解决占位符，没有识别生成后的【…】；其可读性规则也没有完整阻断CLAUSE-*、RULE-*和系统护栏话术。 - 当前开发机缺少 Playwright 浏览器二进制，脚本不能开箱运行；开发环境中旧
.venv-project还引用了另一台机器的 Python 路径。这反映出本地开发引导和可重复性需要改善。 - 有 Starlette TestClient 对 httpx 未来兼容性的警告，应在依赖升级计划中处理，但不是当前上线阻断。
9.3 推荐 CI 分层
- 每次 PR（<10 分钟）：lint/typecheck、前端单测、核心 Python、OpenAPI diff、迁移、模板静态编译、最小字段正文净化。
- 合并主干：PostgreSQL/Redis/MinIO 集成、三租户 review worker、文件解析、版本审批、浏览器主旅程。
- 每日/发布候选：30 模板双模式 sweep、AI 黄金集、性能、失败注入、备份恢复、依赖/镜像/密钥扫描。
- 生产前人工闸门：Legal、Security、Ops、Product 四方具名签字和可追踪证据。
10. 合规与信任审查
10.1 当前需要闭环的事项
- 根据《生成式人工智能服务管理暂行办法》，确认本产品是否属于向境内公众提供生成式 AI 服务、使用哪个基础模型、谁是服务提供者、采用何种安全措施和投诉机制。
- 2025-09-01 已施行的《人工智能生成合成内容标识办法》要求显式/隐式标识及用户协议说明。合同页面、下载 DOCX/PDF、审查报告、元数据和传播场景都要经律师与技术共同设计，不能只放一个页面免责声明。
- 若直接调用已备案模型 API，应根据属地要求完成登记，并在应用显著位置公示模型名称及备案号/上线编号；必须以真实生产 Provider 为准，不能使用示例编号。
- 隐私政策应覆盖主体、目的、最小必要、保存期限、第三方模型/云服务、委托处理、跨境、用户权利、删除、投诉、未成年人、自动化决策和安全事件。
- 企业合同往往包含商业秘密和个人信息，需要租户可配置保留期、删除、导出、训练使用开关、供应商清单和数据地域。
- 电子签署能力应依照《电子签名法》选择可靠第三方并保存完整签署证据；当前“审批通过后自动创建签署证据”不能被表述为已经完成法律意义上的可靠电子签名。
- 全国标准信息公共服务平台显示“人工智能辅助起草和审核合同服务总则”项目仍为“正在批准”。可以提前把质量控制映射到草案方向，但在正式发布前不应宣传“已符合该标准”。
10.2 信任产品化
合规不应只存在后台和文档中。客户应该在产品里看见：
- 本次使用的模型、知识库版本和数据是否发送到第三方。
- 风险结论的法律来源、来源时间、命中企业规则和置信度。
- 哪些内容由 AI 生成、哪些由用户修改、哪些由法务确认。
- 原件、版本、审批、签署和导出的完整时间线与哈希。
- 数据保留/删除、下载和管理员访问记录。
11. 商业模式与包装建议
现阶段不建议先做复杂定价页和支付。先用设计伙伴回答“客户为什么持续使用、按什么单位愿意付费”。可先定义三种能力包，不承诺具体价格：
| 包装 | 目标 | 核心边界 |
|---|---|---|
| Free / 个人体验 | 获客与首次价值 | 少量起草/审查、有限存储、无企业规则和协作审批 |
| Team / 企业团队 | 主产品 | 成员、审批、企业模板/规则、合同库、履约提醒、基础集成 |
| Enterprise Pilot | 设计伙伴 | SSO、专属知识、数据策略、审计、集成、人工实施和服务承诺 |
候选计费单位包括活跃席位、月审查/生成次数、合同库容量和高级连接器。应先埋点得到成本与价值数据，再决定主计费单位，避免“模型调用次数”这种客户难以理解的定价。
12. 12 周实施路线图
第 0–2 周：可信核心
- 完成 P0-01 至 P0-03：正文净化、租户 worker、版本状态机。
- 将最小字段生成和三租户审查加入 CI。
- 暂停新增模板，法务逐一审查 6 个首发模板的正文/说明/证据分层。
- 明确一次审查失败的客服、告警、重试和人工接管流程。
退出标准： 主路径 0 占位符/内部代码；个人和组织审查技术成功；错误可定位；旧审批不会误认新版本。
第 3–6 周：3 分钟首次价值
- 上线目标选择、场景向导、渐进字段、空状态和主体资料复用。
- 重构个人/企业/平台导航。
- 公开首页增加样例和企业试点入口。
- 完成正式协议、隐私和 AI 合规发布流程。
退出标准： 可用性测试中至少 8/10 名目标用户无指导完成首份草稿或发起审查；中位用时小于 3 分钟。
第 7–12 周：企业设计伙伴
- 招募 3–5 家目标行业企业，每家选 1 个合同场景和 1 位业务 owner。
- 上线企业 Playbook、审批规则、签署连接器 MVP、失败运营后台。
- 每周复盘真实合同、人工复核差异、用户漏斗、响应时间和支持工单。
- 形成首个可公开的匿名案例和 ROI 证据。
退出标准： 至少 3 家连续使用 4 周；每家完成不少于 20 份真实合同流程；没有正文污染事故和跨租户事件；出现明确的续用/付费意愿。
13. 指标体系与实验
13.1 北极星指标
每周完成“可靠合同决策”的活跃空间数。一次可靠决策必须满足：有合同版本、完成起草或审查、关键风险得到用户处理/确认，并进入审批、下载或归档中的至少一步。
13.2 首期指标
以下是启动目标，需在两周真实基线后调整：
| 环节 | 指标 | 初始目标 |
|---|---|---|
| 获客 | 首页 → 注册开始 | 分个人/企业分别统计，不先设虚荣总量 |
| 激活 | 注册后 3 分钟内生成草稿或成功发起审查 | ≥ 60% |
| 起草质量 | 生成成功率 | ≥ 95% |
| 正文质量 | 未解决占位符/内部代码率 | 0 |
| 审查可靠性 | 技术成功率（排除用户取消） | ≥ 99% |
| 审查价值 | 风险建议被接受/修改/忽略的可解释分布 | 持续建立基线 |
| 协作 | 企业试用空间邀请第二位成员 | ≥ 25% |
| 留存 | 14 天内处理第二份合同 | ≥ 35% |
| 运营 | 失败任务首次响应时间 | 试点期工作时间内 ≤ 30 分钟 |
13.3 必做实验
- “免费审查一份合同”与“免费生成合同”两个首 CTA 的分群转化。
- 7 问向导与当前完整表单的完成率、用时和正文返工率。
- 风险卡“先展示结论”与“先展示来源”的理解度和采用率。
- 个人空间简化导航与完整导航的首日任务完成率。
- 电子签署回写是否显著提升“批准→归档”的闭环率。
14. 项目管理与团队机制
14.1 建议工作流
- 每个产品需求必须写“用户结果、风险、不变量、埋点、验收”，不能只列页面和接口。
- P0 缺陷由单一 DRI 负责到生产证据，不以代码合并视为完成。
- 模板发布采用 Legal owner + Engineering owner 双签；正文与内部知识资产分别评审。
- 每周一次设计伙伴评审，以真实合同任务为单位，不以完成页面数量汇报。
- 每两周做一次 release readiness：产品、Legal、Security、Ops 都能否给出 Go。
14.2 建议团队优先级
未来 12 周建议资源大致分配：核心可靠性 35%，首次价值与 UX 25%，试点客户与集成 20%，合规/运营 15%，新功能探索 5%。如果团队较小，应先砍掉新后台功能和低频模板，而不是削减测试和法律复核。
14.3 决策记录
以下决策应写成 ADR/PRD 并有 owner：
- 主 ICP 和首发 6–8 个合同场景。
- 合同正文/起草说明/法律证据三层内容模型。
- 版本、审查、审批、签署状态机。
- 个人 owner、租户 admin、平台 operator 的权限边界。
- 生产模型、备案/上线编号、数据流和内容标识。
- 第一家电子签署与第一家协作平台集成。
- 设计伙伴成功和公开付费上线的量化闸门。
15. 建议的发布检查清单
产品与法律
- 首发模板全部通过最小字段和全字段生成审查。
- 合同正文无内部代码、护栏、占位符和未确认事实。
- 高风险场景能强制人工复核或禁止自动定稿。
- 正式协议/隐私/AI 说明已签字并发布，用户同意证据可回放。
- 模型名称、备案/上线编号、生成标识和第三方处理披露准确。
技术与安全
- personal/organization/default 三租户后台任务通过隔离测试。
- 审批绑定版本与哈希，正文变化使旧审批失效。
- PostgreSQL、Redis、对象存储、迁移、备份与恢复完成演练。
- 生产禁用 demo seed、SQLite、自动建表、弱密钥和公开运维端点。
- 日志不含合同全文/凭据；管理员访问和数据导出有审计。
- 失败队列、告警、重试、幂等和人工接管可用。
运营与客户
- 有真实支持入口、响应人、服务时间和事故模板。
- 试点客户知道 AI 边界、数据处理和人工复核责任。
- 激活、成功率、失败率、处理时长、留存和人工复核差异已埋点。
- 发布回滚和客户通知流程演练完成。
16. 外部市场与法规来源
市场产品（厂商一方资料，用于能力基线，不代表独立效果验证）
- Docusign CLM：生成、审查、审批、签署、存储、义务与 AI/集成能力。
- Docusign Intelligent Agreement Management：协议全生命周期、采购 intake、审批与大量应用集成。
- e签宝产品介绍：国内合同全生命周期、电子签署、存证、模板、审查、履约和分析。
- 法大大 2026 合同助手介绍：咨询、起草、审查、签署、归档与到期提醒。
- 法大大帮助中心：个人与企业产品入口及企业认证、权限、印章、模板等能力。
- 法天使：企业规则、合同审查/起草、知识问答和定制化法律 AI。
- Icertis Platform：AI 合同智能、搜索、摘要、自然语言问答与洞察。
- Juro Intelligent Repository：智能合同库与集成能力。
法规与官方信息
- 国家网信办：《生成式人工智能服务管理暂行办法》。
- 国家网信办：《人工智能生成合成内容标识办法》，2025-09-01 起施行。
- 国家网信办：2025 年生成式人工智能服务已备案信息公告，包含直接调用已备案模型 API 的登记与显著公示要求。
- 国家网信办：生成式人工智能服务备案信息公告汇总。
- 全国人大：《中华人民共和国个人信息保护法》。
- 中国政府网：《网络数据安全管理条例》，2025-01-01 起施行。
- 工业和信息化部转载：《中华人民共和国电子签名法》。
- 全国标准信息公共服务平台：“人工智能辅助起草和审核合同服务总则”项目：审查时状态为“正在批准”。
- 互联网信息服务算法备案系统。
17. 最终建议
该项目最值得保留的是“可追溯的中国法律资产 + 企业规则 + 合同协作工作流 + AI 审计”这一组合，而不是继续扩大功能目录。下一阶段应把团队注意力集中到三个结果：
- 生成的每一份合同都能被放心继续编辑、审批和下载。
- 任何租户、任何后台任务都能可靠完成且绝不串租户。
- 目标客户在 3 分钟内感受到价值，并知道下一步如何协作、签署和履约。
完成这些后，当前架构足以支撑封闭企业试点；在真实客户连续使用、正式政策与 AI 合规、生产运行和商业计量都形成证据后，再开放公众自助与付费。此路径比同时扩展个人、企业和律所功能更容易获得市场接受，也更能把已有工程投入转化为可信产品。