大家好，我是 方圆。如往年一样，对去年进行回顾总结。我觉得 25 年是我技术水平进步最多的一年，也应了年初我在 Github 上给自己写下的寄语：“Practice and protect my eyes”，技术的提升几乎全部来自于主动解决工作中遇到的问题，但为了技术的提升也不要忽视眼部健康。接下来的内容主要关于技术成长，对 AI 落地业务的感受以及生活感悟，希望也能对大家有一些启发。
技术成长
如开篇所讲的，25 年是我工作将近 4 年来技术成长最多的一年。年初因为大部门定下了针对现有应用做技术改造的规划，也恰好部门内核心应用存在痛点，再加上部门 Leader 看好我的潜力，相信我能做好这件事，天时地利人和，所以主持技改这件事情便自然而然落到我的头上。
要被技改的应用承接面向 C 端的查询流量，促销峰值时 QPS 能达到大几十万，而且性能要求极高，在部分 C 端场景要求 TP999 稳定在 10ms 以内，是非常核心的服务。但是这么核心的应用怎么能说技改就能技改呢？
实际上不改还真不行，我先问大家一个问题：如何才能保证在几十万 QPS 下满足 TP999 稳定在 10ms 以内？了解的大家可能会回答，需要多实例部署并且实例内采用本地缓存避免网络开销时间来应对复杂的查询请求，我们正是采用了这个方案。在理论上这的确是解决这种场景下问题的最好方式，但是也伴随着比较难解决的数据一致性问题：如何才能保证数据库数据发生变更后能及时同步到多个查询服务实例的本地内存中？如何才能保证每个服务实例的本地缓存都更新成功？现有服务正是存在这样的数据一致性问题：业务人员上午在系统更新数据，发现数据在下午查询时偶尔查询成功偶尔查询失败，这是因为部分实例本地缓存更新成功部分实例缓存更新失败，那我们研发如何排查这种数据不一致的问题呢？答案是没办法排查，因为链路太长了，即使发现问题也没有快速恢复的办法，快速解决问题的方式是把各个实例分批次重启一遍，让它们重新拉取最新的全量数据。业务压力和难以维护的系统是本次技改的根本原因。
那大家可能要问了，既然要技改了，咱们能不能不用本地缓存了，咱用分布式缓存（如 Redis）行不行？这样是不是也能满足性能要求并且解决数据一致性问题？在不了解业务的情况下，理论上可行，但对于我们的业务来说，是不可行的，因为这个查询接口要用到至少四项缓存，多次与 Redis 的交互产生的网络开销势必会影响查询性能（TP999 10ms）。此外，我们的这个服务是异地多机房部署的，其他服务调用我们的服务会采用同机房垂直调用的方式来提高查询性能，那么如果采用 Redis 的话，是不是也要多机房部署 Redis 才能满足机房垂直调用的性能要求？相应地，如何将现有数据写入 Redis 也是比较难解决的问题，比如某项数据大概有 80w+ 条，该怎么写入到 Redis？这就又涉及到了如何分片的问题，即便是考虑好了 Redis 分片方案，大概率原有接口逻辑中读取缓存的逻辑需要变，那么本次技改可能就属于颠覆式的重构了，如果这样的话大家心里都会有一个问题：“这么大的改动谁能保证安全性？而因此造成的损失又该由谁来承担呢？”，所以本次技改并 不是为系统大刀阔斧的动手术，而是望闻问切，定位系统病灶之后对症下药，这也是本次技改中我们的架构师带给我的启示，解决问题的同时保证改动最小，将风险控制在预期范围内，并做好回滚预案。
为了这次技改能够高质量的完成，阅读了 Caffeine 等一系列本地缓存的源码，为了保证本地缓存更新的高可用，阅读了 Nacos 的源码，也因此成为了 Nacos 开源项目的 Contributor，当然这是意外收获，最初的想法只是想参考 Nacos 是如何保证又稳又快刷新配置的，我觉得这对我们做技改会有帮助。在做方案设计的时候这些内容都给了灵感，并且之前几年学习过的关于分布式系统的知识也泉涌出来，“数据一致性”，“分片”和“高可用设计”等等都不再是空中楼阁而是真正辅助工程落地的理论指导。这次技改大概在 25 年春节前完成了方案设计，3 月下旬上线，期间没有测试工程师介入，我们自己做好了完善的验证和上线方案，上线后也未产生问题，是一次非常振奋人心的经历，对于我而言也是一次难得的技术实践，终于让我自己感受到自己好像真的在技术上懂一些东西了，这也是我在工作这几年内一直苦苦追寻的东西。
后来，为了解决部门内慢 SQL 定位的问题，通过 Mybatis 的拦截器机制开发了 SQL 染色插件，标记业务执行堆栈，能够一眼定位业务场景；为了解决应用启动时接口响应慢的问题，调研并实现了应用启动时流量预热的方案，因为部分框架中的组件是懒加载的，导致启动时接口上线那一刻触发组件的初始化，导致最初进来的流量接口响应耗时很长，如果借助流量预热完成这一系列组件的预加载，再发布接口便能解决这个问题；为了解决 AI IDE 无法跨项目和在 Jar 包中无法读取源码的问题，开发并开源了 MCP Server EasyCodeReader，现在在 Github 上已经有了 105+ Star，如果是 Java 开发者的话，这个 MCP 至少能提高 30% 的开发效率，也因为这个 MCP 也获得了集团的一些 AI 实践奖项...
这一年解决了很多问题，这让我觉得 “从问题中来，到问题中去”是学习技术和技术成长最快速的一条路，技术无法脱离工程实践，脱离工程实践的技术也迟早会被遗忘在记忆的长河中。不断地发现问题、解决问题，这不仅仅会带来技术水平的提升，而且还会赢得部门内同事的尊重。这也让我得到了更多的机会，让我有了更高的技术视野，不再将眼光只放在一段段代码上，而是从更高的角度考虑系统设计和需求的规划，考虑的不再是自己技术的进步，而是如何更好的带着部门内一群人进步，大家的能力提升相比于个人能力的一超多强，对于部门来说价值是更大的。
AI 落地业务实践
在 25 年 11 的时候部门想要在电销场景使用大模型辅助完成客服的话术质检，往往客服为了达成销售，会对商品做一些不实的描述，而顾客因为这些描述购买商品而未达预期会引起强烈的客诉。最初的质检约束是人工抽检，存在着人力成本高，检查不全面和质检效率低的问题，如果采用大模型的话能够很好的解决这些问题。所以我借助集团提供的智能体平台（类似于 Dify），搭建了质检智能体，按照一个个规则维度拆分为工作流，质检时并行运行并会返回 JSON 结果供工程端处理。
但是，这与日常的软件开发有很大的不同：模型给的结果反馈 充满了不确定性，日常开发中调整某段逻辑在没有 bug 的情况下通常都能得到预期的效果，而在搭建智能体或工作流时，提示词的改动不一定会得到预期的结果，而且还可能会影响原有场景的准确性，这是非常考验耐心的，也是最初让我头疼的一点，我该如何保证本次的提示词变更是有效的？保证它既不影响历史用例的质检又能处理新的场景呢？所以 维护用例集非常重要，用例集中包含正向和负向的用例，每次工作流变更都需要重新回归验证所有用例，保证本次改动的有效性，但是集团内又没有提供好用的平台怎么办？所以这部分内容是依靠字节的 PromptPilot 来完成的，其中的用例集管理和提示词智能优化为我们提高质检准确率提供了很大的帮助，唯一痛点是用例集合需要手工录入，不能完成系统间的联动，如果这个平台是我们内部自建的话，在质检系统中发现典型用例之后，通过接口形式自动录入平台的用例集，自动进行提示词优化，形成一种“自学习”的模式，这还会节省部分人力成本。但实际想想这其实是一项工程化的能力，不仅仅是用例集管理存在这个问题，集团提供的智能体平台搭建工作流也存在诸多不便，目前搭建工作流是以低代码的形式，开发起来在页面上拖拖拽拽很不方便，提供的节点能力也非常有限，比如说 Python 代码节点，它会限定导入包的范围，一些常有的库是没办法用的，而且部分代码逻辑也没办法实现统一的管理和复用。
即使是这样，这个项目最终也达成了降本增效的目的，部分规则的质检准确率达到了 70% 以上，大家可能觉得这个指标仍然不高，但是这其中有很多限制条件，比如音转文错误率大概在 20% 左右，因为大模型是依靠音频转文本之后的内容进行质检的，音转文的错误会直接影响质检结果，当然我们可以切换更好的模型去做 ASR 或者质检，但是更好的模型也意味着更高的成本，理论上可行但是实际落地还是需要权衡来达到一个预期的平衡，如果不能为业务带来价值的话，岂不就是空谈了。
感悟
在技术上，做完技改之后想做一下 MIT 的 6.5840 分布式公开课，因为这个课程的 Lab 要求使用 Go 语言完成，所以特意阅读了《Head First Go 语言程序设计》，在我看来 Head First 系列相对来说是能够比较快速了解一门技术的书籍。后来，阅读了国人写的《深入理解分布式系统》，我觉得这个书结合《数据密集型系统设计》一起阅读会更好，之后又阅读了《生产微服务》并重新阅读了《微服务架构设计模式》，这让我对于现有系统的设计有了更深刻的理解。闲暇之余看了《网络是怎样连接的》，小日子写的书的确挺不错的，读完的时候只有一种感想：“什么时候国内也有大佬来写这么硬核的书籍就好了”。最后一本技术书是《从零构建大模型》，这部书阅读得不够深入，而且我打开这本书的预期也仅仅是想了解大模型的工作原理，不再把它当做黑盒来用。
技术之外的阅读我觉得今年给我收获最多的是《芒格之道》，一位富有智慧的理性老头子，读完这本书之后我也会刻意的提醒自己在一些事情上要“反过来想”，逆向思维往往在生活中非常有帮助，之后又阅读了《穷查理宝典》，我觉得这本书的典藏版排版太差，无关内容太多，非常影响阅读体验，如果大家想要阅读的话，可以选择这本书的“口袋版”试一试，价格更便宜阅读体验也更好。
在生活上，与女朋友的关系更加紧密，也开始关注到自己的性格，希望自己能够更加心平气和，同时今年也变得更加关心家人，也更愿意花时间和家人在一起，我也希望我自己未来向上的发展也能更多的带给他们幸福。
祝大家新年快乐，马到成功~
