自研 CRM/ERP，用以取代臃肿的现成门户：试点中
- 之前
- 销售、仓储、服务和文档都在一个附加组件不断增多的门户里；任何改动都要修改这些组件。
- 我做了什么
- 我独立完成分析、设计并构建了模块化系统——客户与交易、合同、仓储、采购、配送、邮件、聊天；代码由 AI 智能体在我的掌控下编写。
- 之后
- 经过 5.5 周开发，系统核心已完成并部署试点；试点在公司的一个独立业务方向——金属加工机床销售——运行（3 名用户）。
模块化 CRM/ERP 平台：借助 AI 智能体独立设计与开发
为一家医疗设备分销商设计、用以取代现成门户的模块化 CRM/ERP。需求分析、架构、实现与打磨由我完成；大部分代码由 AI 编程智能体在我的掌控下编写。已部署在客户服务器上试点运行。
45个 Django 应用构成的模块化单体
5.5 wk359 次提交，单一作者
72个测试文件，覆盖 1C 与移动端 API
背景与规模
2026 年 6–8 月。约 14 万行 Python、约 220 个数据模型、约 110 个 API 视图、26 个后台任务；Flutter 移动端、Electron 桌面端和 1C 扩展。自 8 月起在客户服务器上试点：3 名用户，已导入客户数据（约 150 家公司），实际交易为个位数。
问题
销售、仓储、服务和文档分散在定制化的 Bitrix24、约 30 个门户应用和若干独立服务中；与 1C 的数据交换已停止（见 Bitrix24 案例）。企业依赖于自己无法掌控的代码。
分析与方案选择
方案：继续扩展 Bitrix24（1C 连接器封闭、依赖外包模块、工作流负载不断增长）；购买另一款现成 CRM（集成问题依旧）；或自建拥有自有源代码的平台，并提供从 Bitrix24 的迁移路径。最终选择自建——同时并行稳定 Bitrix24，保证业务不中断。
架构
用户
销售、仓储、服务人员
外勤工程师（移动端）
系统
Web 应用Django · HTMX · REST · WebSocket
后台任务Celery · beat
数据库PostgreSQL 16
消息代理与通道Redis 7
文档服务器OnlyOffice
移动与桌面客户端Flutter · Electron
外部系统
1C（会计）
Bitrix24（迁移来源）
电子文档运营商
LLM API
邮件、推送
主要数据流
- 领域事件在同一事务中写入发件箱；1C 通过 REST 拉取并逐条确认。
- Bitrix24 数据通过 REST 或直接读取其数据库一次性导入，借助 ID 映射保证幂等。
- 工作流规则与“秘书”编排器把领域事件转化为各角色的任务。
- 移动端通过平台自带的 OIDC 提供方（PKCE）登录，并同步离线变更。
关键决策与取舍
- 模块化单体，而非微服务. 一位作者、一个事务边界、一次部署。45 个边界清晰的应用保留了日后拆分的可能。
- 面向 1C 的事务性发件箱. 由 1C 拉取并确认事件，门户从不盲目推送。代价：1C 端需要单独的扩展。
- 流程即数据. 带触发器和机器人的工作流引擎，流程变更无需发布新版本。
- AI 助手须经评审（开发中）. 任何写操作前进行评分、事实核查和试运行；权限由核心强制执行，而不是交给模型。
具体工作
- CRM 核心：公司、联系人、线索、交易、看板、角色与组织架构、多组织、变更历史。
- 合同、任务、日历；带序列号和批次的库存、采购、收货、发货、配送路线、生产。
- 邮件、WebSocket 聊天、通知、BI 看板、docx 打印模板、导入。
- 包含规则、路线图、交接说明和规格的 .ai/ 目录，让 AI 智能体在 359 次提交中保持一致。
成果
一个可运行的试点平台，已部署并完成全部迁移，尚未投入日常使用；下一步是把第一个实际业务流程从 Bitrix24 迁移过来。
经验与改进
我会在铺开功能之前，先与用户确定试点范围和第一个上线流程：借助智能体 5.5 周做出 45 个应用并不难，难的是让人用起来。