痛点：合同躺在文件夹里，日期活在人脑子里
很多中小企业的合同管理现状是这样的：纸质合同锁在柜子，电子版散落在共享盘和邮箱附件里；哪份合同什么时候到期、哪笔尾款该付了，全靠经办人或行政的记性。于是常见的事故接连发生——框架协议到期两个月才发现还在"履行"，供应商趁续签空档涨价；付款节点错过导致违约条款被触发；老板问"我们跟这家客户一共签了几份合同、总额多少"，答案是翻半天文件夹。
问题的本质不是没有存文件的地方，而是合同上的关键信息没有被结构化：相对方、金额、起止日期、付款节点这些字段一旦只存在于 PDF 和扫描件里，系统就没法替你盯着它们。要解决的不是"再买一个文档管理系统"，而是把合同变成一张台账——每份合同是一行可查询、可计算、可提醒的数据记录。
这正是 Inkwell AI 构建器适合干的活：用业务语言描述需求，AI 生成一个包含数据模型、管理页面、审批与预警逻辑的完整模块，PC 端和移动端同步可用。下面按"数据怎么建 → 页面怎么用 → 预警怎么跑 → 上线前查什么"的顺序讲清楚这套合同台账模块怎么落地。
数据怎么建：一张主表加一张节点子表
对 AI 说清楚业务对象，构建器会生成对应的数据模型（可以理解为系统里的"表结构"，决定每条记录能存哪些字段）。合同台账建议拆成两层：
合同主档——每份合同一条记录，核心字段：
- 合同编号、合同名称
- 合同类型：采购 / 销售 / 服务 / 租赁等（用平台的数据字典功能统一维护枚举值，避免有人选"采购合同"有人填"买货的"）
- 相对方名称（可先做文本字段起步，后续想沉淀客户/供应商档案时升级为跨模块引用）
- 合同金额（平台的金额字段按"分"存储，页面上显示为带千分位的元，避免小数误差）、币种
- 签订日期、生效日期、到期日期
- 续签条款说明、负责人（引用公司员工，直接对接组织架构，不用手打名字）
- 合同状态：履行中 / 已到期待续签 / 已续签 / 已终止 / 已归档
- 附件：上传合同扫描件或 PDF，走平台的文件存储能力收付款节点子表——一份合同挂多条计划节点，每条记录：期次、节点名称（如"预付款""验收款""质保金"）、计划日期、计划金额、实际支付/到账日期、状态（未到期 / 已付 / 逾期）。
两张表的关系是"一合同多节点"。这样设计之后，"这份合同还有多少钱没付""下个月有哪些节点要到期"就从翻文件变成了筛选查询。如果贵司合同量大、还需要走用印审批，可以在主档上再挂一个审批状态字段，接平台的工作流引擎（可视化配置的审批流），申请用印、变更、终止都留痕。
页面怎么用：台账列表、合同详情、到期看板
数据模型建好，构建器会自动生成配套的增删改查页面，在此基础上按使用角色组织三块视图：
台账列表页（PC 端，行政/法务的主工作台）：默认按到期日期升序排列履行中的合同，支持按类型、相对方、负责人、状态组合筛选；金额列自动汇总当前筛选结果的合同总额——老板问"跟这家供应商一共签了多少"，两次点击出答案。列表行内直接标色：距到期不足三十天的行高亮为黄色，已过期为红色，规则由数据流引擎（平台内置的"条件触发→自动处理"机制）计算，不依赖人工盯表。
合同详情页：上半部分是主档字段与附件预览，下半部分是收付款节点子表，节点状态一目了然；详情页保留操作记录（谁在什么时候改了哪个字段），审计日志由平台自动留痕，重要合同的要素变更可追溯。
到期看板：把"未来九十日内到期的合同"和"未来三十日内到期的付款节点"做成两个待办清单，负责人打开系统先看到自己名下要处理的事，而不是全量数据。
移动端：PC 端构建的模块会自动同步生成移动端页面。对合同场景来说，移动端主要服务两类人——领导出差时在手机上查某份合同的金额和期限；经办人收到预警后随手点开看详情、转给相关负责人。不需要为手机单独再做一遍。## 预警怎么跑：定时任务 + 站内通知，让系统替你记日期
台账建好只是把信息搬进了系统，真正解决"靠人记"的是自动预警。这一层由两个平台能力拼成：
定时调度：平台内置定时任务引擎（按 Cron 表达式配置的执行计划，可在页面上管理，不用改代码）。给合同模块配两条每日任务：
- 每天上午扫描履行中的合同，对"距到期日九十 / 三十 / 七天"三个阈值的合同各发一次提醒，发给合同负责人；
- 每天扫描未支付节点，对"计划日期在十五日内"和"已过期未付"的节点分别提醒经办人与财务。
通知触达：提醒通过平台的站内信与通知能力发出（支持邮件、短信通道配置），负责人登录后看到待办角标，点开直达那份合同的详情页。阈值天数做成系统配置项，行政想调整提前量时改配置即可，不用重新构建模块。
再往前一步，续签动作本身也可以流程化：从到期提醒里点"发起续签"，生成一条新的合同草稿记录并走审批流（用印审批、金额变更审批），批准后置旧合同为"已续签"、关联新合同编号——整个链条在同一个模块内闭环，不需要跳出去发邮件走纸质签批。
上线前查什么：五件事确认完再发布
Inkwell 的模块发布前有预检环节，但预检只能保证技术正确，业务口径要靠人过一遍。合同台账这个场景，建议逐项核对：
- 字典口径：合同类型、状态枚举是否与法务的实际分类一致？让行政拿三份真实合同试录，看每个字段有没有"没地方填"的信息——有就补字段，别硬塞备注。
- 日期边界：生效日晚于签订日、到期日晚于生效日的校验规则是否生效？故意录一条反的试试，系统应拦下并给出人话提示。
- 金额口径：录入一笔万元级金额，列表、详情、汇总三处显示是否一致且带千分位？节点子表各期金额之和与合同总额的差异是否有提示（分期合计不等于总额是常见录入事故）。
- 预警真跑一遍：把定时任务临时调到几分钟后执行，用一条明天到期的测试合同验证提醒确实发出、点得开、收件人是负责人本人；测完记得调回每日计划并删除测试数据。
- 权限收口：合同金额属于敏感信息，核对角色权限——普通员工能否看到不属于自己的合同？导出操作在审计日志里是否留痕？## 之后怎么延伸
合同台账跑顺之后，同一套数据结构天然可以往外长：相对方字段升级为供应商/客户主档，联动进销存模块看"这家单位的合同额与实际采购额是否匹配"；付款节点接采购申请审批，先审后付；再往上是按部门、按年度的合同统计报表。每一步都是在已有模块上加引用、加流程，而不是推倒重建——这正是 AI 构建器交付方式的实际好处：系统跟着业务的理解深度一起长大。
如果你手头正有一堆到期没人盯的合同文件夹，不妨从最小版本开始：先只建合同主档和到期提醒，两周内让台账跑起来，再逐步补节点子表和续签流程。用业务语言把需求讲给 Inkwell AI 构建器，一个下午就能见到第一版可录入、可查询的合同台账。