当前使用的《合同与付款管理表》以 Excel 为载体，包含四大模块：合同登记、请款登记、开票登记、收款登记。这一方式在业务量较小时可以勉强应对，但随着合同数量增长和多人员协作需求的出现，以下痛点日益突出：
| 痛点 | 具体表现 | 系统化后的改进 |
|---|---|---|
| 数据孤岛 | 合同、请款、开票、收款分散在不同行区域，无法自动关联 | 以合同 ID 为主键建立关联关系，一键查看某合同的全生命周期 |
| 手工易错 | 金额计算、开票状态核对、回款率统计全靠人工 | 系统自动计算待收金额、回款率、账龄，减少人为错误 |
| 缺乏提醒 | 付款节点到期、发票逾期无人提醒，容易漏收 | 系统自动监控时间节点，提前推送提醒 |
| 文件管理缺失 | 请款报告、合同扫描件无法与记录关联，散落各处 | 附件上传与记录绑定，随时可查可追溯 |
| 无数据分析 | 无法快速回答"今年回款率多少""哪个客户拖欠最久"等问题 | 实时仪表盘 + 多维度报表，数据驱动决策 |
| 协作困难 | Excel 文件来回传递，版本混乱，权限无法控制 | 多用户在线协作，角色权限分级管理 |
基于现有 Excel 的四大模块，提炼出以下核心实体。每个实体对应数据库中的一张表，通过外键关联：
注：一个合同可包含多个付款节点（如预付款、进度款、竣工款、尾款），独立建模以支持灵活的分期场景。
采用敏捷迭代策略，每个阶段可独立交付并产生业务价值。后续阶段依赖前期成果，但不阻塞业务使用。
技术选型遵循成熟稳定、社区活跃、人才易招的原则，同时为未来 AI 集成预留空间。
系统从工具到智能体的演进分三个层级，每层都在前一层的信任基础上解锁更多自主权：
AI 作为查询和录入的助手。用户提问，AI 查询数据并返回答案；上传发票，AI 提取数据但需人工确认。所有操作由人执行。
自主度：10% · 仅提供建议和信息
AI 可自主完成内部操作（数据录入、状态更新、报告生成），但涉及对外操作（催收邮件、通知发送）需人工审批后执行。
自主度：50% · 内部自主 + 外部需审批
AI 在预设规则范围内自主完成完整业务闭环：监控 → 判断 → 执行 → 反馈。人工从"操作者"转变为"监督者"，仅处理异常和策略调整。
自主度：80% · 规则内自主 + 异常人工介入
现有 Excel 数据可能存在格式不统一、缺失字段、历史数据错误等问题。如果迁移质量不高，后续所有分析和 AI 功能都会受影响。
应对：阶段一前安排专项数据清洗工作，制定数据规范文档，迁移后进行数据校验报告。
团队已习惯 Excel 操作方式，新系统的学习成本可能导致抵触情绪。
应对：系统界面设计尽量贴合现有 Excel 的操作习惯；保留 Excel 导出功能作为过渡；分批培训 + 提供操作手册。
OCR 识别准确率、LLM 查询结果准确性不可能 100%，直接使用可能导致错误数据入库或误导决策。
应对：所有 AI 操作保留人工确认环节；设置置信度阈值，低于阈值的自动转人工处理；建立 AI 错误反馈机制持续优化。
五阶段总周期 10–14 个月，如果开发资源不足，可能延期或功能缩水。
应对：优先保障阶段一、二的交付（核心业务价值最大）；阶段三、四可根据资源情况调整节奏；阶段五为长期目标，不阻塞前期使用。
| 时间节点 | 里程碑 | 交付内容 | 业务价值 |
|---|---|---|---|
| 第 1–2 月 | MVP 上线 | 四大模块 CRUD + Excel 导入 + 基础看板 | 替代 Excel，数据结构化 |
| 第 3–5 月 | 协作平台上线 | 多用户 + 审批流 + 智能提醒 + 附件管理 | 多人协作，减少漏收 |
| 第 6–8 月 | 数据分析上线 | 财务看板 + 账龄分析 + 现金流预测 + API | 数据驱动决策 |
| 第 9–12 月 | AI 助手上线 | 自然语言查询 + OCR 录入 + 智能报告 | 效率提升 50%+ |
| 第 13 月+ | 智能体迭代 | 自动催收 + 风险预测 + 多系统联动 | 从工具到智能体 |