问问助手

架构设计 · 系统改造 · 业务里的 AI 智能体

从一套新系统的第一版架构,到跑不动、改不动的遗留系统:模块边界怎么切、微服务怎么拆、消息与存储怎么调;也能把一个智能体接进你的单据、工单和流程里,让它答得上你自己业务的细节。

67
篇实战拆解
3609
累计阅读
25
万字实战正文

精选内容

全部文章
推荐阅读 AI 试点那笔账,铺开之后翻几倍 AI 试点那笔账,铺开之后翻几倍 试点那三个月的账单,和全员铺开之后每一个月的账单,不是同一张纸上的数。这一篇讲清楚三件事:为什么一个任务不是一次问答、为什么单价降九成而账单还在涨、为什么员工个人省下的时间进不了公司的账。附一张铺开之前要填满的三栏表、一张把账单压回去的五层… 2 20 分钟 推荐阅读 平台要下线,你的数据拿得走吗 平台要下线,你的数据拿得走吗 「服务中断」和「服务终止」是两件事:前者会修好并回来,后者不回来。这一年公开报道里出现了不少后一类公告——老平台定日子永久下线、运营二十年的站点宣布关停、模型厂商在帮助站开出一页「停止服务须知」。这一篇不谈要不要换供应商,只算另一笔账:真要… 5 14 分钟 推荐阅读 员工把客户资料贴进了公网 AI,要不要全禁 员工把客户资料贴进了公网 AI,要不要全禁 禁止员工用公网 AI 这件事,多数公司输在执行上:需求不会消失,规避成本比执行成本低得多,禁令最后只把使用推进地下。这篇不讨论该不该用,只拆三件能落地的东西:贴出去的内容分几类、四条路各自的真实代价、以及不花钱今天就能做的三件事。 5 12 分钟 推荐阅读 系统越来越慢,是加服务器还是该重构了 系统越来越慢,是加服务器还是该重构了 系统变慢不一定意味着要重构。先分清慢的是哪一种:一直慢、偶尔慢、还是只有某个动作慢,三种的解法完全不同。加服务器能买来多少时间、重构什么时候才值得,这篇算的是这笔账。 6 4 分钟 推荐阅读 外包还是自建,这笔账怎么算才不后悔 外包还是自建,这笔账怎么算才不后悔 技术需求来了,是找外包做,还是自己招人做?外包便宜但不可控,自建可控但贵。怎么算这笔账? 5 5 分钟

按问题找方案

解决过的难题

更多实战

每个系统都有自己的历史包袱。这一段讲的是当时卡在哪、怎么下的判断、凭什么说这个判断是对的——数字只是结果,怎么得出这个数才是能搬走的东西。

从零搭一套与在跑系统的重写

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

新系统从 0 到 1

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

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

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

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

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

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

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

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

能一起做的事

新业务系统的设计与架构

要做一套自己的业务软件——订单、履约、结算、内部平台——产品口径有了,架子还没有

从产品口径走到能开工的设计:模块边界、数据模型、技术选型一起定下来,交出来的方案能直接进开发排期

  • 产品口径到模块边界
  • 数据模型与单据流转
  • 技术选型与依赖边界
  • 接口约定与演进空间

系统性能与稳定性优化

大促宕机、慢 SQL、消息积压频发的系统

定位瓶颈并给出可验证的优化结果

  • 链路与瓶颈分析
  • 中间件与存储调优
  • 容量与预案

遗留系统微服务改造

单体要拆分、老 ERP 要续命的企业

比整体替换更低成本、更短周期完成升级

  • 现状与技术债盘点
  • 拆分与迁移路线
  • 灰度与回滚方案

业务系统里的 AI 智能体

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

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

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

最新更新

全部文章
  • 谁能进你的系统,这份名单谁签过字

    能进系统的东西,今年大半不是人。人走了有流程,机器账号走了没有流程——它不离职、不请假,也不回那封"请确认权限仍然需要"的邮件。本文给一份四类身份的归类表、一张按"无主乘高权限"排的盘点次序表,以及拿去问 IT 与供应商的那七句话。

  • 不按人头按次数,采购前要问哪几句

    企业软件正在把收费单位从"多少人用"换成"跑了多少次"。这一格最贵的那笔钱不是单价,是闲置的额度按月作废。本文给两张能自己填的表:有效单价随利用率怎么变,缺口为什么只能整包填。

  • 自建还是按次买,先算那些空着的卡

    这一格的决定通常是被一句问话推出来的:「我们一个月在模型上花四万,买一排卡回来是不是便宜一半?」它没法当场回答,因为答案不在单价里,在三个数上:你的调用画像、你一天里有多少小时是真的有流量、以及那台机器背后站着几个人。往下是一次可以照着算的…

  • 改一个数字,比发一个版本更危险

    把最近十四个月里那些有名有姓的全球事故复盘摊开,出现频率最高的词不是"漏洞",是"配置"。微软那一次是"一次无意的租户配置变更",Cloudflare 那一次是一个清理任务删掉大约一千一百个客户网段前缀、六个多小时,GitHub 一个月报里…

  • 补丁排不下去,你先补哪一个

    今年公开的报告里出现了一个排序变化:入侵者进门用的第一招,从"猜你的密码"变成了"打你没补的那个洞"。而同一批报告给的另一个数是——一个已经被人在野利用的漏洞,从被发现到被彻底修掉,中位时间从三十二天涨到四十三天。这两句放在一起就是这篇的全…

  • 备份天天在跑,恢复试过一次吗

    备份这件事的验收标准不是「任务有没有跑成功」,是「最近一次真的把数据还原出来、并且业务能用,是哪一天、谁做的」。这一篇把三格分开算:副本有没有跟生产同生共死、恢复要花多久这段时间值多少钱、以及恢复演练一年做一次算不算做过。再摊开今年那一路公…