很多做销售管理或者带过小团队的朋友，应该都有过这种体验：客户信息散落在每个人的微信备注、Excel 表格、甚至纸质笔记本里。月初统计业绩的时候，要挨个去问、去对、去催，数据还不一定准确。我自己也踩过这个坑，所以在给团队做内部支撑工具的时候，就决定动手写一个桌面端的客户关系管理系统，也就是这个 DeskcommCRM。
所谓 DeskcommCRM，简单来说就是一套跑在本地电脑上的客户管理工具，核心是把客户档案、跟进记录、订单状态和待办事项全部收拢到一个软件里。它解决的问题很直接：不用再依赖一堆随时可能变更格式的表格，也不用担心同事离职把客户资料一起带走。整个项目适合两类人来参考，一类是想给公司或自己的小团队搭建客户管理系统的开发人员，另一类是准备从 Excel 管理客户转向专业工具、但又不想用大而全的线上 SaaS 产品的业务负责人。
这篇文章我会把从需求拆解、技术选型、核心模块开发到数据迁移和日常排障的完整过程讲一遍。里面会包含一些具体的踩坑记录，比如 Excel 导入时的编码坑、SQLite 在高频写入下的锁问题、以及桌面端软件分发时最容易忽略的细节。无论你是打算直接抄作业，还是只想了解一个内部工具是怎么从零长出来的，这篇文章应该都能给你一些参考。
1. 内容整体设计与思路拆解
1.1 为什么不做 Web 端，而要做桌面端
在立项的时候，大家问得最多的一个问题就是：现在随便买一个在线 CRM 不就行了，为什么还要自己写一个桌面软件？这个问题的答案，其实反映了整个项目的核心定位。
市面上成熟的 SaaS 型 CRM 确实功能齐全，从线索管理到营销自动化一应俱全，但对于只有十几个销售、客户量在几千条左右的小团队来说，大部分功能都是冗余的。更重要的是，在线 CRM 意味着客户数据必须上传到第三方服务器，很多业务团队对这一点非常敏感。我们自己对接过的几个合作方，甚至明确把数据不出办公室列为合作前提。
桌面端最大的优势就在本地优先。所有客户资料、跟进记录、文件附件都存储在团队自己的电脑或者局域网服务器上，数据主权完全可控。同时，桌面应用的交互响应速度是网页端没法比的，尤其是大批量录入客户信息、翻查历史跟进记录这些高频操作，原生应用的流畅度体验明显更好。
当然桌面端也有天然的短板，跨设备访问不太方便，多人同时在线协作需要额外设计数据同步方案。不过在项目初期，我们先把核心场景做扎实：固定工位、固定电脑、局域网共享数据库，这就覆盖了大部分业务需求。后续如果真的要上远程访问，再考虑做一套轻量化的 Web 查询端也不迟。
1.2 核心需求拆解：销售团队真正需要什么
在功能设计上，我给自己定了一个原则：不做 CRM 百科全书，只做销售天天要用到的功能。调研了一圈团队的实际使用习惯，最终把需求收敛为四个核心模块。
第一个是客户档案管理。这是最基础的部分，需要记录客户公司名称、联系人、电话、微信、来源渠道、所属行业、客户分级等字段。需要注意的一点是，字段的灵活度非常重要，不同行业的团队对客户信息的关注点差异很大，所以自定义字段功能最好从第一天就做进去，不然后期加字段会非常痛苦。
第二个是跟进记录与时间线。销售每天打了哪些电话、发了什么资料、客户给了什么反馈，这些过程信息比最终成交结果更能反映问题。每次跟进留一条记录，系统自动盖上时间戳，打开客户详情页就能看到完整的互动时间线，这样不管是自己复盘还是管理者抽查，都有据可查。
第三个是商机与订单管理。简单一点的做法是把商机状态做成一个管道视图，比如初次沟通、需求确认、方案报价、商务谈判、成交、流失这几个阶段，每个商机对应一个金额和预计成交日期。管理层可以一眼看到整个团队的业绩预测，销售自己也能清楚接下来该重点推哪几个单子。
第四个是待办与提醒。销售每天的事情很杂，如果不做提醒，很容易漏跟。系统可以自动抓取今天需要跟进的客户、本周过生日的联系人、合同还有几天到期的项目，生成一份每日工作清单。
流程型功能比如审批、工单流转，我们第一期没有做。原因很简单，团队还没有这么复杂的协作流程，先把数据记录和管理做扎实，后面有需要再迭代。
1.3 项目技术栈选型的关键考量
技术选型这件事，我前后纠结了挺长时间，最后确定下来的方案是：前端用 Electron，后端用 Python 加 FastAPI，数据库用 SQLite，本地通过 HTTP 接口通信。
之所以选 Electron，是因为团队里现有成员的前端技能比较扎实，用 Web 技术栈开发桌面应用能最大程度复用已有的能力。虽然 Electron 打包出来的体积偏大，内存占用也比较高，但考虑到用户量只有几十个人，这点性能损耗完全不是瓶颈。如果你更在意安装包体积和内存占用，可以考虑 Tauri 方案，不过 Rust 的部分需要额外学习成本，这个要根据团队实际情况取舍。
数据库选 SQLite 是经过一番计算和对比的。SQLite 的读写性能在单机场景下非常能打，百万级数据量完全无压力，而且它支持完整的 SQL 语法、事务、触发器，开发成本极低。不需要像 MySQL 和 PostgreSQL 那样单独部署服务，直接嵌入应用内部，备份就是一个文件拷贝，对小团队来说极其友好。我们团队目前的客户数据量大约在几万条级别，SQLite 的性能余量是很大的。
Python 在这套体系里承担的是业务逻辑和数据处理任务，尤其是后面要做的 Excel 批量导入、数据清洗、报表统计，用 Python 的 pandas 库处理起来几乎是降维打击。FastAPI 作为 Web 框架，自带 OpenAPI 文档，接口调试非常方便，所有数据操作都统一走 REST API，逻辑清晰也好维护。
这里有一个多线程并发写数据库的踩坑提醒。SQLite 早期版本在并发写场景下会出现 database is locked 报错，虽然新版已经改进了很多，但 Electron 主进程、渲染进程、Python 后端同时操作数据库时仍然可能触发锁异常。解决方法是开启 WAL 模式，把 journal_mode 设置为 WAL，这样读操作和写操作可以并行执行，大幅降低锁冲突，同时在 Python 连接数据库时设置合理的超时时间。
2. 核心细节解析与实操要点
2.1 客户档案管理的字段设计与扩展机制
客户档案是整个 CRM 的地基，字段设计决定了这个系统能用多顺手。我的做法是内置一批高频字段作为默认值，同时留出自定义字段的扩展入口。
默认字段表大概是这样的：公司名称、联系人姓名、联系电话、电子邮箱、微信号、客户来源、所属行业、客户分级（A/B/C/D）、客户状态（潜在/跟进中/成交/流失）、负责人、创建时间、最后跟进时间。其中跟进时间这个字段在 UI 上不需要让用户手动填写，而是每次录入跟进记录时自动更新，这样列表页排序的时候就能默认把近期有互动的客户排在前面。
自定义字段方面，我用了一个 JSON 字段来存储扩展属性。具体来讲，在客户表里留一个 ext_info 字段，格式是 JSON 字符串，用户在界面上添加自定义字段时，前端把字段名和字段类型发到后端，后端统一存进这个 JSON 里。查询的时候如果要按自定义字段过滤，就用 SQLite 的 JSON1 扩展来做，虽然性能不如普通字段，但胜在灵活，对几千条数据来说完全够用。
业务团队对字段的修改需求是非常频繁的，今天想加一个意向产品字段，明天想加一个到访日期字段。如果每次改需求都要改表结构发版本，开发团队会被拖死。用 JSON 扩展字段的方案，前端渲染表格时动态读取字段配置，后端查询时动态拼接过滤条件，整个流程不需要重新发布应用，改动体验会好很多。
2.2 跟进记录时间线的设计思路
跟进记录是销售日常输入频率最高的一块内容，设计的目标是让销售花最少的时间录入，同时让信息在回看时最容易检索。
我采用的方案是把每一条跟进记录设计成可扩展的数据结构。基础字段包括跟进方式（电话、微信、邮件、面谈、其他）、跟进内容、下次跟进时间、关联商机。高级一点的设计，可以在记录里加上情绪标签，比如客户意向程度高、中、低，方便后续按意向程度筛选。跟进内容保存时使用富文本支持换行和简单列表，方便销售写清楚客户的具体反应。
时间线展示的逻辑是按创建时间倒序排列，最新一条记录在最上面。每条记录还会显示创建人的名字和创建时间。这样设计的好处是，打开客户详情页，不只是看到静态的客户档案，还能快速了解这个客户从第一次接触到现在的完整过程。
有一个小细节值得注意，客户详情页旁边最好有一个快速展示窗口，显示所有跟这个客户关联的订单、合同、售后记录。销售在电话里跟客户沟通时，经常需要快速查看这个客户买了什么、上次什么时候续费的、有没有未处理的售后问题。信息聚合展示比来回切换多个页面要高效得多。
2.3 商机管道的状态流转设计
商机管理的核心是状态流转，这里有一个很大的坑：过度设计。最初方案里我参考了一些大型 CRM，设置了十多个状态节点，从线索分配一直到赢单归档，每个节点还有严格的流转校验。结果销售用起来非常抵触，觉得太繁琐，很多单子根本不会按预设流程走。
后来我把状态精简成了六个：新建、需求确认、方案报价、商务谈判、赢单、输单。每个状态旁边显示商机金额和更新时间，状态变化时自动记录一条日志。管理视图上就是经典的漏斗式管道视图，每个阶段的商机数量和总金额一目了然。
为什么要保留新建和输单这样看似简单的状态？因为新建可以让销售快速记录一个还没正式启动的商机，输单则能把丢单的原因沉淀下来，比如价格原因、产品原因、竞争对手关系。这些都值得日后复盘。商机的创建仍然以客户为前提，必须先有客户档案才能创建商机，这样保证数据不会变成无源之水。
2.4 权限控制与数据隔离策略
团队内部使用，权限做得太重反而影响效率，但完全不做又会出问题。我的设计是分三个角色：管理员、销售主管、普通销售。
普通销售只能看到自己名下的客户和商机数据，这是最基础的隔离。销售主管除了自己的数据，还可以查看所辖团队成员的数据，便于把控项目进展。管理员拥有全部权限，包括设置用户、修改系统配置、导出全部数据、查看操作日志。
权限控制的判断逻辑统一放在后端，前端只是根据用户角色控制菜单和按钮的显示。真正要防止越权，必须在后端每个数据查询的接口上校验数据归属权限，比如查询客户列表时自动拼接 WHERE 条件限制只返回当前用户的数据。这类校验在代码里要写成一个装饰器或者公用方法，避免每个接口各自实现导致遗漏。
批量导入客户数据时要特别注意归属问题。如果是管理员导入，可以指定每个客户的负责人；如果是销售导入，客户归属自动设置为导入人自己。归属关系在导入后允许管理员批量转移，以便在员工离职或岗位调整时做数据交接。
3. 实操过程与核心环节实现
3.1 完整的项目搭建与初始化流程
整个项目从零搭建的过程，值得单独记录一下。环境准备阶段需要安装 Node.js（Electron 运行时）、Python 3.9+、以及项目依赖的库。目录结构上，我按照前后端分离的思路分成 client 和 server 两个目录，client 里是 Electron 主进程加渲染页面，server 是 FastAPI 应用。
数据库初始化我用了一个 migration 脚本来管理，通过 SQL 脚本的方式创建表结构和初始数据，每次升级版本就追加一个版本的 SQL 脚本。这样做的好处是开发环境的数据库可以随时重建，生产环境的数据库也能通过脚本平滑升级。第一次建表的脚本包含用户表、客户表、跟进记录表、商机表、自定义字段配置表、操作日志表、系统配置表。
初始化以后，需要创建一个默认管理员账号，同时写入一条系统配置记录，比如公司名称、Logo 路径、客户编号规则等。这里有一个比较实用的做法，把系统配置项做成了一个 key-value 结构，这样增加配置项不需要改表结构。
启动方式上，开发阶段我习惯把 Electron 和 FastAPI 分开启动，方便热更新调试。生产环境则用一个启动脚本先拉起后端服务，再启动 Electron 应用。这个顺序值得注意，如果先启动前端后启动后端，前端请求接口时报连接失败的概率会增大，虽然可以做自动重试，但不如在启动顺序上规避掉。
3.2 核心数据表的结构设计与索引优化
直接上核心表结构，这个可以直接作为参考复现。
客户表（customers）的主要字段包括 id、customer_no（客户编号，唯一）、company_name、contact_name、phone、email、wechat、source、industry、grade、status、owner_id、ext_info（JSON）、created_at、updated_at。索引方面，company_name 建立普通索引，owner_id 和 status 建立联合索引，这样列表页按负责人加状态过滤时能走索引，查询速度会快很多。
跟进记录表（follow_ups）包含 id、customer_id、method（跟进方式）、content（跟进内容）、intention（意向程度）、next_follow_time、关联商机 id、creator_id、created_at。这里 customer_id 一定要建索引，因为所有按客户查询跟进记录的操作都依赖这个字段。
商机表（opportunities）包含 id、customer_id、title（商机名称）、amount（金额）、stage（阶段）、expected_close_date（预计成交日期）、description、owner_id、created_at、updated_at。stage 和 expected_close_date 建议分别建索引，管道视图和到期提醒都会高频使用。
操作日志表（operation_logs）记录用户在系统里做了什么事情，比如新增客户、修改商机阶段、导出数据。字段为 id、user_id、action、target_type、target_id、detail（JSON）、created_at。虽然这个表的数据量增长会很快，但它能提供审计能力，对于内部管理工具来说还是值得保留的。
建表时一个容易被忽略的细节是，所有表都要带 created_at 和 updated_at 字段，并且在后端代码里统一维护这两个值。后续如果要出数据报表、统计活跃度，这两个时间字段几乎是必须的。
3.3 前后端接口设计与 REST API 规范
接口设计遵循简单的 REST 风格。客户模块提供 GET /api/customers（列表分页查询）、POST /api/customers（新建客户）、GET /api/customers/{id}（查询详情）、PUT /api/customers/{id}（更新客户）、DELETE /api/customers/{id}（删除客户）。跟进记录模块提供按客户维度查询和新增两个接口，商机模块类似。
请求和响应统一采用 JSON 格式，响应结构固定包含 code、message、data 三个字段。code 为 0 表示成功，非 0 表示业务错误。这样前端做统一错误处理非常方便，不需要为每个接口单独定义错误格式。
所有接口通过 HTTP Header 传递认证信息，前端在登录后拿到一个会话 token，后续请求都带在 Authorization 字段里。后端用一个中间件统一校验 token 有效性。不用 JWT 而用普通会话 token 的原因很简单：内部工具用户量小，用数据库会话表就行，后续要加 Web 端还方便做会话主动失效。
关于删除操作，我建议用逻辑删除而不是物理删除。客户表加一个 is_deleted 字段，默认 0，删除操作实际是把 is_deleted 改成 1。这样做的好处是防止销售误删数据后无法恢复，配合定时清理逻辑可以保留足够长的数据恢复期。
3.4 Excel 批量导入与数据清洗的实现细节
这是整个开发过程中踩坑最多、也最有料的一部分，值得展开讲。
销售团队手里都有一堆老 Excel 表格，第一版导入功能我直接用了 pandas 的 read_excel，然后扔进数据库，结果很快就翻车了。问题集中在三个方面：编码问题、表头兼容问题、单元格合并问题。
编码问题体现在 CSV 文件上。Excel 默认用 GBK 编码打开文件，但用 pandas 读取时如果用默认 UTF-8，中文内容全都是乱码。解决办法是读文件时先强制指定 encoding=gbk，或者更稳妥的做法是先把文件转成 UTF-8 再读取。我在导入工具里做了一个编码自动检测函数，优先尝试 UTF-8，失败后用 GBK，这样遇到不同来源的文件都能正确处理。
表头兼容问题是指团队的表格五花八门，同一个字段在不同人的表里可能叫客户名称，也可能叫公司名称，或者叫单位名称。解决方案是配置字段映射关系，支持同义词匹配。导入页面左侧显示 Excel 原始列名，右侧选择系统字段，保存一个导入模板。下次导入时如果列名一致，系统自动套用之前的映射关系，省去了重复设置的麻烦。
单元格合并问题是 Excel 表格里最容易遇见的隐藏坑。合并单元格在 pandas 读取后，非首行位置的值为 NaN，如果直接入库会出现大量空数据。处理办法是在导入前做一个向前填充操作，把合并单元格的值填充到每个空行里，这个操作在 pandas 里一行代码就能完成。
数据清洗方面，重点是手机号和金额字段。手机号要统一转成字符串格式，防止科学计数法显示；金额字段要处理千分位逗号和人民币符号；日期字段要统一转换成 YYYY-MM-DD 格式。每一步清洗都有对应的校验，不满足条件的数据进入错误列表，导入完成后用户可以下载错误报告，按行提示具体原因。这个功能极大减少了数据补录的工作量。
3.5 数据安全与备份策略
本地优先的架构设计，数据安全问题必须从第一天就考虑。SQLite 数据库文件默认放在用户数据目录下，我额外做了一个备份机制：每天定时把数据库文件复制一份到备份目录，保留最近三十天的备份。
手动备份功能也做了，管理员可以在设置页面一键备份当前数据，备份文件自动带上时间戳。恢复功能同样保留，选择备份文件后系统会替换当前数据库文件并重新加载数据。这里有一个很重要的提醒：恢复操作会覆盖当前全部数据，操作前务必二次确认，建议在恢复前再自动做一次完整备份。
数据库文件本身建议开启 WAL 模式，这个前面提过。此外要注意 SQLite 文件不能直接放在网络映射盘或者云同步目录下，会引发文件锁冲突和数据损坏风险。正确的做法是数据库放在本地固定路径，如果需要共享给多人使用，应该把后端服务部署在一台局域网服务器上，客户端通过网络访问服务，而不是直接共享数据库文件。
4. 常见问题与排查技巧实录
4.1 SQLite 数据库锁冲突的完整解决方案
日常使用中，SQLite 锁冲突是出现频率最高的问题。典型场景是多人同时录入客户资料，表现为系统提示 database is locked，或者页面长时间卡在等待状态。
我的排查思路分三步。第一步是确认数据库的 journal_mode 是否已经是 WAL，通过 PRAGMA journal_mode 查询。如果不是，执行 PRAGMA journal_mode=WAL 变更。第二步是检查后端的连接池配置，每个 SQLite 连接设置 connection timeout = 10，避免业务高峰时瞬间抛错。第三步是写入操作尽量做成短事务，大批量导入数据时采用批量提交，每几百条提交一次，而不是处理完整个 Excel 再提交。
实际测试下来，WAL 模式配合合理的超时设置，能解决 95% 以上的锁冲突问题。剩余的极端情况，多半是不小心同时跑了多个后端实例，或者有人手动用数据库工具打开了文件导致的。遇到这种情况，先停掉多余实例，再重试即可。
4.2 Excel 导入时数据格式混乱的处理经验
导入成功后销售经常反馈“数据是进来了，但格式不对”，细看之下一般有两类问题。一类是日期字段格式混乱，有的表是 2024/01/05，有的是 2024-01-05，还有的是 Excel 的序列号数字。处理方式是在导入工具里对日期列做统一转换，用 pandas 的 to_datetime 方法，指定 format 参数，或者用 errors=coerce 强制把无法解析的值置空，并归入错误列表。
另一类是手机号被 Excel 自动转成了科学计数法，导入后显示成 1.38E+10 一类的数值。这个必须在前端页面引导用户先设置 Excel 的列格式为文本，同时在导入工具里也要做兜底处理，把读取的数值先去掉小数点还原字符串，再补上前导零。
除了字段格式，还有一类常见问题是重复数据。同一个客户被不同销售各自录进来，系统里出现两条甚至多条重复档案。我加了一个查重功能，导入时按公司名称加上联系人姓名做组合匹配，发现已存在记录时自动跳过并生成重复报告，由管理员决定是忽略还是合并。
4.3 客户端启动失败与白屏排查指南
Electron 应用偶发启动后白屏的问题，排查起来有点绕。第一次遇到时我以为是前端代码报错，打开 DevTools 也没看到有效错误信息。后来发现是后端服务没有正常启动，前端请求登录接口超时，页面一直停在加载状态。
定位过程是这样的：先检查后端进程是否在监听对应端口，再手动用浏览器访问接口地址测试连通性，最后确认 Electron 主进程加载页面时是否传递了正确的服务地址。排查下来，问题出在 macOS 系统的网络权限提醒上，首次启动时系统会弹窗询问是否允许程序接受网络连接，如果没点允许，后端服务虽然启动了但无法监听端口。处理方式是重新触发网络权限授权，或者改用本机回环地址加端口的组合。
白屏问题还有一类原因是应用安装目录权限不足，Electron 无法正常读写用户数据目录。解决办法是把数据目录显式设置为用户主目录下的某个路径，同时创建专门的应用数据文件夹。
4.4 团队日常使用中容易被忽略的三个小问题
第一，客户归属问题。很多 CRM 都有这个烦恼：一个客户被多个销售同时跟进，数据归属一变，过程记录就乱套了。我的策略是先按创建人归属，负责人可以手动转移，但必须在转移时留下操作日志，避免后续说不清。
第二，字段改名的麻烦。自定义字段如果已经录入了数据，再去改名会导致数据看起来像丢了。处理方案是字段配置里做字段停用而不是删除，停用后历史数据在详情页仍然显示，但列表页和录入页不再展示。这样既保留数据完整性，又不会造成界面混乱。
第三，数据导出权限。销售可能会导出自己的客户数据，但如果能导出全公司的数据就需要管理员权限。我和业务负责人对齐过需求，普通销售导出时强制带上水印，里面包含操作者工号和导出时间，方便追溯数据泄露源头。
4.5 实操速查表：高频问题的判断方法
| 现象 | 可能原因 | 快速判断方法 | 标准解法 |
|---|---|---|---|
| 提示 database is locked | SQLite 写入锁冲突 | 查看后端日志中的锁相关报错 | 开启 WAL，设置连接超时 |
| 导入 Excel 中文乱码 | CSV 文件编码不匹配 | 用文本编辑器打开文件查看字符 | 根据文件编码指定读取格式 |
| 合并单元格导致空数据 | pandas 读取后的 NaN | 导入后抽查几条明细记录 | 导入前执行向前填充操作 |
| 手机号显示科学计数法 | Excel 列格式为数字 | 查看导入报告中的格式警告 | 统一转为文本格式处理 |
| 客户端白屏 | 后端服务未启动或端口不通 | 浏览器直连接口地址验证 | 检查后端进程和端口监听状态 |
| 重复客户数据 | 多维度匹配不严 | 执行查重工具扫描 | 按公司名和联系人组合查重 |
| 定期备份失效 | 数据目录路径变化 | 查看备份任务日志 | 重新设置固定备份路径 |
5. 注意事项与实操心得总结
5.1 需求边界控制：如何避免工具沦为摆设
开发这类内部工具，最容易出现的严重问题就是需求失控。业务方今天提一个报表需求，明天提一个审批流程需求，需求越堆越多，但真正每天被高频使用的功能始终是那么几个。我最后自己的把关原则是：任何新功能上线前问两个问题，第一，是否每周至少会被使用一次；第二，是否直接关联客户数据的记录或查询。如果不满足这两个条件，一律放二期。事实证明这个原则帮我们挡掉了至少一半的需求噪音。
另外要多留意实际使用反馈的收集节奏。销售团队填写跟进记录的积极性直接影响系统的数据质量。想让销售愿意用，就要把录入成本降到最低。我的办法是跟进记录的录入框直接放在客户详情页首屏，同时支持快捷键唤起，销售在通话中快速记录几个关键词，结束通话后再补全内容，使用阻力就小很多。
5.2 桌面端离线场景的应对思路
虽然主打局域网使用，但销售外勤拜访客户时经常会遇到没有网络的情况。最初的架构里，后端服务必须在线才能使用，外勤场景就断了。后面做了一个简单的离线模式：客户端在检测到后端服务不可达时，会启用本地缓存，把操作记录存到浏览器 IndexedDB 里，等网络恢复后自动同步到服务端。
这个离线方案实现的复杂度比想象中要高一些，主要涉及操作顺序的冲突解决。为了避免复杂化，我定的策略是离线期间只能做查询和新增操作，不支持修改和删除。新增操作在同步时带上客户端的唯一标识，防止重复提交。如果外勤场景不多，离线功能可以晚点再做，优先级不用太高。
5.3 复盘：如果重新做一次，哪些地方可以优化
项目跑到现在已经稳定运行了一段时间，回头看还是有一些地方当初做得不够好，值得改进。
一是日志模块做得太浅。早期只记录了操作日志，没有记录接口的请求响应日志和性能耗时。导致后期做性能排查时缺乏数据支撑。如果重新做，我会在中间件层统一加请求日志，重点记录耗时超过阈值的慢接口。
二是打包发布的自动化程度不够。每次发新版本都靠人工打包、上传、分发，效率偏低。其实可以接入 CI/CD 流水线，实现代码提交后自动构建安装包并生成更新日志，配合 Electron 的自动更新机制实现静默升级。这个改造建议项目稳定后优先考虑。
三是初始设计时没有计划多语言支持。如果团队后续有海外业务或国际化需求，所有页面的文案都要做国际化改造，工作量不小。虽然目前还不涉及，但前端代码里我一直坚持文案和逻辑分离，为后续改造留了余地。
最后再说一个建议：做内部工具，稳定的优先级永远高于功能丰富。不要一次规划太多功能，把一个核心场景做到极致，让团队真正用它来替代 Excel，是最重要的一步。等大家习惯了这种管理方式，再逐步往系统里加东西，成功的把握会大很多。
