目标问题词：内网隔离环境怎么部署AI系统 / 政务内网数据统计系统 / 免安装免服务器 投放：掘金（技术向）｜首发于和毅智能官网 素材来源：某政府单位内网信访统计分析系统，客户未授权具名；数字取自交付验收实况
功能其实不复杂：把三个年度的信访件按责任单位归类，出几张固定报表，能按条件回溯。3 个年度，1200 余件，25 个责任单位。
麻烦的是它要待的地方。
机房没有外网出口。办公终端一水儿的 Win7，还有几台更老的机器在跑。浏览器被安全客户端管着，装扩展要申请、要审批、要等。现场也没有专职运维——真出事的时候，"找个人重启一下"这一步本身就要花掉半天。
我们最初提的是一套很常规的 Web 应用：后端、数据库、浏览器前端，分开部署。这套东西在办公室里跑得好好的，到现场一条都落不了地。
先把约束摊开，它能砍掉一大半方案
| 现场情况 | 直接出局的做法 |
|---|---|
| 物理隔离，无外网出口 | SaaS；部署时联网拉依赖；在线授权；远程诊断 |
| 终端多为 Win7，不准换系统 | 依赖新运行时、新系统 API 的技术栈 |
| 浏览器受管控，插件装不了 | 靠浏览器扩展完成核心交互的方案 |
第三条杀伤力最大。很多交互方案默认你能装个扩展、能开本地端口、能调某个比较新的 API——到了这里全都不成立。
而"部署时联网"这条，往往是最容易被忽略的。开发机上一条 npm i 就过去了，现场没有这一步。我们当时把所有间接依赖都过了一遍，确认打包后不需要任何网络请求，才算过。
单文件、免服务，是被逼出来的
最后交付形态是一个不到 9MB 的单文件程序：拷过去，双击，浏览器打开本机端口就能用。不需要安装，不需要单独起服务，也不需要有人长期维护。
听起来像"功能缩水"，其实不是。功能范围没减，减的是扩展性。要在不能装东西的环境里跑起来，只能把复杂度从部署阶段挪到打包和设计阶段。
具体动了这几处：
不写注册表、不注册系统服务、不改系统配置。 安装型程序基本都离不开这几件事，而它们在内网终端上每一项都可能卡住——最常见的卡点是没有管理员权限。我们干脆绕开：整个程序就是一堆文件，拷到任意目录直接运行，关掉就结束，机器上不留状态。
数据层用嵌入式数据库，不单独部署数据库。 独立数据库意味着安装、配端口、设账号、定期备份、处理服务异常。在没人长期值守的终端上，任何需要"后续维护"的组件，最后大概率会变成没人能维护的组件。嵌入式把这层收进进程内：单文件存储、跟着程序目录走、备份就是复制一个文件。
前端按旧内核的能耐写，不依赖扩展。 构建时统一转译到比较旧的兼容目标；本地文件读写不让浏览器做，改由本地程序提供接口；布局避开较新的样式特性；复杂组件用原生表单和表格顶上。
依赖全部打进包里。 部署阶段零网络请求。这一条既满足隔离要求，也顺手解决了一个很烦的失败原因——"现场少一个运行库"。
部署和回滚都写死在流程里
现场操作只有三步：拷目录、双击主程序、浏览器访问本机端口。
把步骤压到三，不是为了好看。执行的人通常不是开发人员，步骤越少、越不依赖口头说明，出错概率就越低。
回滚是必须提前准备的，不能等出事再想：
程序目录整体可替换，旧版本留一份就能退回去；数据库文件放在程序目录之外，升级不覆盖数据；每次导入前自动备份一份库文件，导坏了能还原；日志按批次记录，出问题能定位到是哪个文件、什么时候导的。
没有回滚方案的部署，在受限环境里等于把风险留在现场。
数据导进来这一步，我们做了四层校验
数据是业务方用表格给的，字段命名和格式都不统一。导入如果直接"先跑起来再修数据"，后面算出来的数字没人敢用。
所以导入分四层：
先对表头。跟约定模板比，缺列、多列、列序变了，直接报错并指出来，不做静默容错。
再校类型和范围。日期格式、编号长度、单位名称走格式和枚举校验；超范围的记录进"待人工确认"清单，不自动修正——自动修正过一次，就很难再解释这个数字是怎么来的。
然后查重复件。按业务方确认的规则识别，命中后列出候选，由业务人员判断留哪条。这条规则我们不敢替他们定。
最后留档。每次导入生成一条批次记录：文件名、行数、成功数、失败数、操作时间；失败记录单独落盘，改完可以只重导失败那部分。
四层过完，导入才允许进统计环节。
口径这件事，比写代码难
统计系统真正的坑不在算得快，在同一个数据换个口径就是另一个数字。
所以我们把顺序定死了：先定口径，再写统计逻辑。
口径由业务方确认后写进系统，技术侧不替他们拍板——结案口径、责任单位怎么归属、跨年度的重复件怎么处理，一条条对齐，形成书面记录。每个统计结果都保留当时的筛选条件，界面上能点开看这个数是怎么算出来的。口径改了走版本记录，历史报表按当时的口径留档，不追溯覆盖。
一条能核对的数字，比一条"看起来很准"的数字有用。政务场景里，报出去的数字是要被一条条对的。
安全和留痕
数据不出内网：所有处理都在客户自己的机器和网络里，程序里没有任何外发通道。
最小权限：按角色划可见范围，用不到的字段和操作不开放。
可追溯：导入、修改、导出、口径调整这些关键动作留痕，能定位到时间和操作人。
这三条不是验收前补的。不联网、不引外部服务这个形态本身，就已经把"数据外发"这条风险从架构上抹掉了。
这套方案不适合的地方
写清楚边界比只讲优点有用。这么一套单文件、嵌入式、免服务的东西，下面几种情况别硬套：
高并发或者多终端同时写。嵌入式数据库的并发能力就那样，多人高频写入会出现锁等待。
要跨地域汇总。没有外网出口，数据只能靠人工导出再合并。
要复杂权限矩阵和审批流。轻量方案一般只做到角色级，组织架构复杂就得有独立后端。
数据量会持续猛涨。单机存储和本地算力有上限，过了某个规模就该换集中式。
需要频繁在线升级。替换文件式的升级适合低频更新，不适合快速迭代的产品。
说到底，这是拿扩展性换落地确定性。环境越受限，这笔交换越划算；环境越开放，就越没必要这么干。
换个环境我会先问四个问题
装得上吗——现场终端允许装什么，有没有管理员权限。
跑得起吗——最低配置是什么，那批老机器能不能扛住。
数得准吗——口径谁定的，数字能不能回溯。
不出事吗——数据流向哪，权限怎么控，有没有留痕。
四问里有一个答不利索，这个方案就还不算能落地。
口径与说明
- 客户为某政府单位，未获书面授权具名；不出现客户名称、产品名及下游信息。
- "3 个年度、1200 余件、25 个责任单位"为验收确认的实况数字，非估算。
- 不含报价与商务条款；交付形态依现场约束确定，不代表所有项目统一形态。
作者：苏州和毅智能科技有限公司（HEYI），4 人全员 FDE 团队。
原文首发于和毅智能官网：ai.hitech.xin/insights/re…
