问问助手

系统架构设计、老系统改造与业务 AI 实战

从新系统的第一版设计,到跑了多年的老系统怎么一步步换掉;也把 AI 助手接进单据、工单和流程,让它答得上你自己业务的细节。

76
篇实战文章
3898
累计阅读
30
万字正文

精选文章

全部文章

按问题找方案

最新更新

全部文章

解决过的难题

更多实战

每个系统都有自己的旧账。这里写当时卡在哪、怎么判断、后来凭什么说判断是对的。数字只是结果,怎么得出这个数字,才是你能带走的东西。

从零搭一套,和在跑系统上重写

架子从空白起,和在跑的系统上换骨架,两件事难的地方不一样:前者难在几十个人同时往里写,后者难在每一次改动都不能让用它的人察觉。

新系统从 0 到 1

二十多个服务仓、三个团队一起写:约定做成骨架,不靠事后评审

当时新系统真正难的不是选哪个注册中心,是几十个人同时往里写:三个月后同一件事会有五种写法,而写在文档上的约定活不过第三个月。

怎么做服务按两个问题分层:要不要独立看几个域要用、进哪一层看有没有业务规则。六个平台服务不带一条规则,财务这种整仓都是规则的留在业务域;每个仓固定六层、新服务从骨架复制;降级统一返回一个能被认出来的失败;全局事务只放在开单、结算这类跨服务写入口;网关路由放进配置中心,接一个新服务不占发版窗口。

20+
服务仓
3
个团队
80
人协作
这段的完整复盘
在跑系统的重写

六周、484 次提交:只借鉴功能,客户那边一个字都不用改

当时一套跑了几年的系统还在赚钱,但业务规则已经和最初那批人的写法长在一起了。整体替换的风险和双轨维护的成本,同时摆在一张桌子上。

怎么做功能照做、代码全重写:平台层沉进一个约 26 万行、带 3438 个测试方法与覆盖率门禁的底座,业务侧只写业务;对外的 URL、字段名、错误码原样保留,前端和第三方系统零改动;端点数 178 对 178,模块之间没有一处越界引用;每一阶段都留一个能核对的数字。

484
次提交
27
个模块
178
端点对齐
这段的完整复盘

能一起做的事

新业务系统的设计与架构

要做一套自己的业务软件,订单、履约、结算、内部平台都算:需求已经清楚,技术架子还没定

把需求变成能开工的设计:模块怎么分、数据怎么存、技术怎么选,交出来的东西能直接排进开发计划

  • 需求梳理与模块划分
  • 数据模型与单据流转
  • 技术选型与依赖边界
  • 接口约定与后续扩展

系统性能与稳定性优化

大促就撑不住、慢查询频发、消息越积越多的系统

找到真正卡住的地方,给出能验证的优化结果,而不是先换一批机器

  • 请求路径与瓶颈分析
  • 中间件与数据库调优
  • 容量评估与应急预案

老系统逐步改造

跑了多年、没人敢大动的 ERP 和内部系统

不用整体推倒重来,按业务优先级一块一块换,每一步都能停下来

  • 现状盘点与旧账清单
  • 分步改造与迁移路线
  • 分批上线与回滚方案

业务系统里的 AI 智能体

已有 ERP、MES、工单这类单据清楚的系统,想让 AI 答得上业务细节的团队

一个读得懂你自己单据的助手:数据怎么接、哪些能查、答不准怎么退回人工,连同评测集与运维交接一起给,不停在演示

  • 数据接入与只读边界
  • 业务动作做成模型能调的工具
  • 标注过的评测集与上线合格线
  • 答不准时退回人工那条路