V1.0 让客户信息能记下来，V2.0 让客户自己进来、能分群、能触达
解决的问题：销售手里有一堆客户，但记不住、找不到、跟不住。
交付结果：8 轮交付 / 30 笔提交 / 7 个问题闭环，系统稳定运行。
解决的问题：客户数据要手工录，不录就没数据；客户多了分不了群、触达不到。
交付结果：2890 客户 / 2890 联系人实测进库，客户列表分页，智能群发全链路就绪。
发布日期 2026-10-04 ｜ 把客户信息从纸搬到线上
销售手里有客户，但记不住、找不到、跟不住，线索基本靠记忆和微信群维系。客户一多就失控，撞单和漏跟都发生。
客户档案 · 跟进记录 · 商机看板 · 产品开通台账 · 客户群管理
以手工录入为主。独立账号 + 角色权限（管理员 / 主管 / 销售），企业微信扫码 OAuth 登录。
8 轮交付 / 30 笔提交 / 7 个问题闭环，全部已上线运行。
发布日期 2026-10-08 ｜ 客户自动进得来、分得群、发得出去
客户必须手工录入，不录就没数据；客户多了分不了群；群发只能一个个点，效率极低。
企业微信自动同步，实测 2890 客户 / 2890 联系人进库，销售不用再手工录。
12 个 → 30 个，补齐企业全称、客户类型、添加方式、归属销售、最后同步时间。
一个客户可挂多个跟进人，不再只能记一个。适配大客户多人对接的实际场景。
2890 条全量渲染 → 分页 10 / 20 / 50 / 100 条每页，页码带快捷跳转。
10 张表 → 18 张表（标签 3 张 + 群发 5 张），结构化承载新能力。
从「能记」到「能用」，这是 V2.0 的核心增量
客户从企业微信自动进系统。新增 30 个客户画像字段，含企业全称、客户类型、添加方式、归属销售。
关键字段「企业全称」只有自建应用能拿到，转第三方会静默失效——这是盛宏数科坚持用自建应用的原因之一。
标签组 + 标签 + 客户打标 + 批量打标，支持与企业微信标签同步。
可按「行业 + 规模 + 阶段」三维筛出目标客户，为群发选人打底。
完整链路：选人 → 配内容 → 预检 → 推送 → 结果回收 → 未回复自动建待办。
预检含 4 项：归属校验、频率保护、敏感词检查、企微上限提醒。系统默认不擅自推送，需显式开启。
每页可选 10 / 20 / 50 / 100 条，页码带省略号跳转，切换筛选自动回到第 1 页。
顺带解决了原先 2890 条一次性渲染的性能问题。
其中一个是 V1.0 就存在的问题，本次一并根治
现象：销售登录后客户列表为空。
原因：客户归属字段存了系统内部 ID，导致权限校验与群发归属校验全部对不上。
影响：2890 条客户全部受影响，现已全部修正。此问题自 V1.0 起即存在，本次从数据、代码、校验三层同时根治。
改为按收件人逐一映射发送状态，避免出现「张冠李戴」——即 A 客户的状态记到 B 客户头上。
并增加表级唯一约束，群发结果回收不会重复记账。
上线过程零事故：2890 客户一个不少、字段不丢、启动日志零报错。
回滚能力已实际演练验证——用备份加旧代码真实启动一次服务并验证可访问，而不是只备份不验证。
群发默认只存草稿，不会擅自推送消息给任何客户。真实发送需管理员显式开启并指定收件人范围。
单客户每月设发送上限，防止刷屏打扰客户。
几条硬规矩，用之前值得知道
系统默认只存草稿，不会擅自推送消息给任何客户。真实发送需管理员显式开启并指定收件人范围。
企业微信限制：只能推送给该客户的最后互动成员，系统强制拦截这种情况（属平台限制，非系统缺陷）。
单客户每月有发送上限，防止刷屏打扰客户。
管理员 / 主管看全部客户；销售 / 员工只看自己名下客户。
为什么这套系统能长期稳定跑
后端 FastAPI + SQLite，前端单文件原生 JS。后端依赖只有 4 个，不引入构建工具链。
数据库扩展重复执行安全，重启自动补齐缺失的表和字段，不重复建、不丢数据。
管理员看全部、销售看自己名下，判定口径全系统统一，不会出现两套标准。
顶栏一键导出备份，导入恢复，数据始终在自己手里，不被平台锁死。