企业档案系统的实施周期，经常卡在与人无关的地方：客户内网连不上外网，pip install 装不上；服务器上不能随便起服务；单位没有专职运维，出了故障没人能定位。功能再全，环境过不去就等于零。
zbook EAMS 1.0（企业电子档案管理系统）在设计上做了一连串「减法」，目标是把上线周期压到一周量级。下面几个取舍值得说一说。
取舍一：不用 Web 框架，只用 Python 3 标准库
系统后端基于 Python 3 标准库的 http.server 与 sqlite3，没有 Flask、Django 这类框架依赖，也没有第三方包。
好处很直接：
- 离线环境不需要准备 wheel 包和内网镜像源，装个 Python 就能跑；
- 依赖树是空的，就没有「版本冲突」这类问题，三年后升级也不会因为某个包废弃而起不来；
- 代码量可控，交付时运维看得懂、改得动。
代价是路由、表单解析、JSON 序列化这些都要自己写。对一个档案业务系统来说，这部分工作量是有限的，换来的是部署环节几乎零失败。
取舍二：前端不打包，原生 HTML/CSS/JS
前端同样是原生技术栈，没有 Node 构建步骤。改一行样式，刷新就是结果，不需要 npm run build。
对交付现场的意义在于：客户想调整一个栏目名、换一张单位logo，改配置文件、刷新即可，不必让我们远程发版。前端资源由后端直接托管，整套系统就是一个进程加一个数据文件。
取舍三：SQLite 单文件，备份就是拷文件
数据存在单文件 archive.db 里。
- 备份：把文件拷走就是完整备份，不需要 mysqldump、不需要定时任务里写一堆参数；
- 恢复：把文件换回来就恢复完成；
- 迁移：换服务器时连数据目录一起搬，路径对上就能用；
- 演练：把文件复制一份到测试机，就有了一个和真实数据同构的演练环境。
档案系统对并发的要求集中在工作时间的著录与检索，不在高并发写入，SQLite 完全够用。用 MySQL 换来的是运维复杂度，而这个复杂度最终要客户自己承担。
取舍四：Docker 一键起站，也可离线
发布物是 Docker 镜像，docker compose up -d 起站。镜像里没有任何需要联网拉取的运行时依赖，导出成 tar 包拷到内网机器 docker load 即可。
需要完全离线运行的场景，也可以直接用 Python 起进程，配合系统的服务管理托管。部署形态不绑定，装在哪由客户的网络条件决定。
取舍五：AI 助手默认走本地规则引擎
档案场景里，把档案正文发给外部大模型，多数单位过不了合规这一关。所以 AI 档案助手默认使用本地规则引擎 local-rule-v1：断网可用、数据不出内网，回答下方会标注所用引擎与判断依据。
需要更强的自然语言理解时，在 config/llm.json 里配置 OpenAI 协议的模型地址即可，内网自建模型同样适用。默认安全、按需增强，比「必须联网才能用」现实得多。
那一周里到底做什么
技术栈只决定了「装得上」，真正占时间的是业务确认。按我们的实施路径：
- 部署与账号：起站，建账号，配角色与数据范围（集团 / 区域 / 法人 / 项目四级粒度）；
- 门类确认：44 个门类通用包按行业裁剪与扩展，确定编码、保管期限、密级规则；
- 存量导入：Excel / CSV 先跑预演校验，逐行看成功、跳过、失败原因，确认后再落库；
- 计划试跑：下达当年归档计划，拆任务到部门与项目，走一遍提交—审核；
- 培训与验收：管理员培训加《使用说明》《运维手册》移交。
功能不复杂、环境不折腾，一周内可以走完。需要提醒的是边界：如果单位要的是档案馆级别的全门类综合管理、复杂工作流与长期运行保障，应该看 zbook DAMS 8.0；EAMS 针对的是企业集团「一群法人统一归档、快速见效」这一类诉求。
需要具体评估，可以联系我们按法人主体与门类清单算一份方案。