为合同审查与版本控制创建一款 Web 应用

定义问题与核心用例

在你开始绘制界面或选技术栈前，先明确你要解决的具体问题。“合同审查”可能包含从清理一页 NDA 到协调复杂的多方协议并执行严格审批规则的任何事情。明确的用例可以防止产品变成一个泛用的文档工具，没人完全信任它。

定义用户（及其约束）

先列出参与的真实角色以及每个角色需要完成的工作——通常在时间压力下：

• 法务团队：希望一致性、低风险，并且能审计谁在何时为何修改了什么。\n- 销售：需要速度、清晰的下一步和最少的来回沟通。\n- 采购：需要政策合规、供应商可见性和标准化条款。\n- 外部律师 / 对手方：需要受限访问、清晰的评论和简单的共享方式，同时不暴露内部文档。

把这些写下来时，也记录约束条件，比如“必须在移动端可用”、“外部用户不能看到内部备注”或“签字前必须记录审批”。

列出核心待办事项（Jobs to be done）

你的 MVP 应该支持一组重复发生的紧闭环活动：

• 审阅（Review）：阅读最新版本，标注问题，提出问题。\n- 修订（Redline）：建议修改，跟踪更改，并保留可恢复的历史文本。\n- 审批（Approve）：将文件路由到合适的相关方并记录决策记录。\n- 签署（Sign）：在不丢失历史的情况下从“已批准”过渡到“已执行”。\n- 存储 & 检索（Store & retrieve）：快速找到已执行副本，并保留完整上下文。

如果某项工作需要在电子邮件、共享盘和聊天线程之间跳转才能“完成”，那它就是你应用需要解决的关键场景。

决定产品中“版本”的含义

合同在不同阶段可能有多个“真相”。提前定义版本状态以确保所有人有相同心智模型：

• Draft（草案）：早期内部迭代（常常比较混乱、频繁变更）。\n- Revision（修订）：共享给各方的编号变更序列。\n- Executed copy（已执行副本）：已签署的最终协议，应当被锁定。

这些定义将影响权限（谁能编辑）、保留策略（什么可删除）和报告（什么算作“最终”）。

设定与业务目标一致的成功指标

选择可量化且不含猜测的指标。例如：

• 周转时间：从请求 → 批准 → 签署的中位时间。\n- 错误减少：缺失条款、错误主体名称或过期模板减少。\n- 可见性提升：“在哪里？”类的询问减少；更多合同有明确状态和负责人。

这些指标会在后续权衡中做出指导，例如要投资更好的搜索、更清晰的工作流或更严格的 RBAC。

确定 MVP 功能范围

合同审查 Web 应的 MVP 应把少数功能做到极致：将文档组织好，使编辑与反馈易于跟踪，并能把合同从“草案”推进到“已签署”并保留清晰的审计轨迹。如果第一天就试图解决所有法律边界情形，团队仍会退回到电子邮件。

“必须有”的 MVP 工作流

从一个主要流程开始：上传合同、邀请审阅者、捕获更改与评论，然后审批并最终化。

关键 MVP 功能：

• 上传与组织文档（DOCX/PDF）：创建合同记录，附上原始文件，并在审查过程中将每个新版本存储为单独版本。\n- 修订跟踪、评论与 @ 提及：审阅者需要提出修改建议、留下上下文评论并通知特定人员，而无需切换工具。\n- 并排版本比较与变更摘要：一个简单的 diff 视图加上“变更点概述”能减少来回并防止错过修改。\n- 带状态的审批工作流（Draft/Review/Approved/Signed）：使当前状态明显，限制谁能推进状态，并记录每次转换的时间戳。\n- 跨合同与条款的搜索与筛选：按对方、状态、日期和关键条款查找协议；MVP 阶段的基础条款级搜索即可。

有意推迟的功能

暂缓复杂自动化，例如高级条款剧本、AI 辅助重写、复杂集成和多步条件路由。这些有价值，但应在核心协作闭环可靠后再做。

MVP 成功判定标准

定义可衡量的结果：审阅者能在数秒内理解最新版、审批可被追溯、团队能快速定位任一合同或关键条款——而无需依赖电子邮件线程。

为合同与版本设计数据模型

合同审查应用的成败很大程度上取决于它如何把“合同是什么”与“它如何随着时间变化”分离开。清晰的数据模型也使得权限、搜索与审计变得更容易。

以工作区（workspace）为先的结构

把顶层建模为 Workspaces（或“客户/团队”），每个 workspace 下有 Matters/Projects（事项/项目）。在一个 matter 内，支持熟悉的 文件夹 组织以及用于跨切分组的 标签（例如 “NDA”、“续约”、“高优先级”）。

对每个 Contract（合同），存储结构化元数据，用户无需打开文件即可筛选：

• 当事方（对方、内部实体）\n- 生效日、签署日、续约/终止日期\n- 状态（Draft、In Review、Approved、Signed）\n- 所有人、业务单元

通过在 workspace 级别使用一小组固定字段加一个“自定义字段”表（key + type + value）来保持元数据的灵活性。

将合同记录与版本、对话分离

考虑三层：

1. Contract（记录）：身份、元数据与当前状态。\n2. File Versions（文件版本）：每次上传/导入的文档都是一个新版本，带有自己的存储指针（blob ID）、校验和、created_by、created_at 和可选标签（例如 “Vendor draft v2”）。切记不要覆盖，始终追加。\n3. Discussion Threads & Comments（讨论线程与评论）：评论应附着在特定版本（并可选地锚定段落/选区）。这能避免在文档变更时出现“孤立”反馈。

这种分离允许一个合同有多个版本和多个线程，而不会把“文档历史”与“对话历史”混在一起。

使审计事件不可变

创建一个 AuditEvent（审计事件） 日志，将动作作为追加事件记录：谁做了什么、何时、从哪里（可选 IP/UA）以及对哪个实体（contract/version/comment/permission）。示例：version_uploaded、comment_added、status_changed、permission_granted、export_generated。

存储足够的上下文以在争议中站得住脚，但避免在审计日志中复制完整文档。