去年冬天，内部我们组接了个内部需求：给客服团队做一个Q币充值后台。员工原因很直接，充值客服每天要帮用户补发Q币、系统处理退款、内部做活动补偿，员工原先全靠人工登记Excel，充值再由财务统一操作。系统流程慢，内部容易错，员工最要命的充值是没法追溯——谁在什么时候给哪个账号充了多少，翻聊天记录能翻到人崩溃。系统

这个系统说白了就三件事：员工提交充值申请，内部主管审批，员工系统自动调腾讯的充值充值接口完成发放。听起来简单，但真做起来，坑一个接一个。

权限分级不是摆设

第一版设计时，我们只分了“普通员工”和“管理员”两种角色。上线三天就被叫停。原因是有个客服误操作，把本该充50Q币的单子填成了5000。审批流还没走完，钱已经到用户账上了。后来改成三级：申请人、审批人、执行人。执行人只负责点“确认发放”，看不到用户聊天记录，也改不了金额。审批人能看到申请理由和历史充值记录，但没法直接执行。互相卡着，反而安全。

接口调用这块，腾讯那边给的是企业级API，有频率限制。我们一开始没做队列，几个客服同时提交，直接触发限流，系统卡死。后来加了个简单的内存队列，每笔请求间隔200毫秒，超时自动重试三次。再没出过批量失败的情况。

日志比功能重要

内部系统有个特点：用户量不大，但每一笔操作都有人盯着。财务要对账，主管要看团队消耗，安全部门要查异常。所以从第一天起，我们就把日志表设计得比业务表还细。谁提交的、什么时间、充值账号、Q币数量、审批人、执行人、接口返回的流水号，全记下来。连“申请理由”这个字段都单独存了原始文本，防止有人事后改描述。

有个细节值得说：Q币充值接口返回的流水号，我们做了唯一索引。有一次网络抖动，接口超时但实际扣款成功，重试时又发了一笔。幸亏流水号冲突报了错，人工介入才发现是重复发放。要是没这个约束，用户白拿一份，财务月底对不上账，查起来能要命。

别让员工自己填QQ号

最初申请表单里有个“充值账号”输入框，员工手动填用户QQ号。结果有人把QQ号填成自己的，有人多打一位数，还有人复制粘贴带了空格。后来改成从客服工单系统里直接拉取用户ID，申请人只能选，不能改。选完自动带出昵称和最近一次联系时间，防止充错人。

还有个反直觉的设计：充值金额只能选预设档位——10、30、50、100、200。不允许自由输入。客服一开始抱怨不灵活，但财务那边松了口气。自由输入意味着无穷无尽的核对，预设档位至少能把异常值卡在源头。

监控和告警

系统上线后，我们接入了公司内部的告警平台。规则很简单：五分钟内失败超过三笔，或者单笔金额超过500，直接给技术负责人发企业微信。有天凌晨两点，告警响了。爬起来一看，是接口返回“余额不足”——公司预充的Q币池子见底了。赶紧联系财务充值，避免了第二天客服上班后集体卡单。

内部系统不需要花哨的UI，但必须稳。我们没做移动端适配，因为客服都在PC上操作。也没做花哨的图表，主管要看数据直接导Excel。省下来的时间，全花在边界处理上：网络超时怎么办、接口返回“用户不存在”怎么办、审批人离职了单子卡住怎么办。这些破事，才是内部系统真正的日常。

现在这套系统跑了快一年，累计处理了四万多笔充值，最大单笔200Q币，最小10Q币。没出过资金事故。你要问有什么经验，就一句：内部工具别追求功能多，把“谁在什么情况下能做什么”这条线画清楚，比什么都强。