变更风险防控的能力是多样的，除了最传统的告警检测、Metrics曲线对比以及自动化测试能力之外，像变更影响分析、风险降噪以及线上风险RCA等周边能力也是不可少的。有了更多的上下文信息，才能对变更风险做更好的判断。从中台技术视角来看，不论是传统能力还是一些AI加成的能力，如果没有一套稳固的技术基建让这些能力尽情发挥，那么这些能力将难以快速落地，充分兑现其业务价值。
基于此，笔者在今年工作中，交付了一套「能力市场」产品与技术架构，旨在面向不同业务团队的自研能力，提供一套开放式标准化的接入方案，让业务自研的变更防控能力可以快速应用到变更风险质检过程中。虽然这套架构目前还有很多继续扩展和完善的空间，并且也没有蹭到LLM的噱头，但在架构迭代过程中笔者权衡了很多利害关系，主导了很多技术演进判断，最终也成功落实了这个技术结果。
具体一些技术上的设计，其实前面的文章已经聊了很多，包括任务调度、事件状态机以及内置降噪模块嵌入之类的点都有阐述。所以今天这篇文章，不倾向于聊这些具体的技术实现，更倾向于聊下整个产品交付过程中的一些权衡和判断。
在先前的文章中，我们聊到了一个变更观测任务可以通过什么样的方式对不同的变更防控能力做统一调度，达到优越的变更风险拦截效果。但是在实战当中，变更观测任务集成了很多能力，即便风险拦截率很高，但不同能力效果也有差距，因此会有可能出现误报，导致变更观测结论不准确，影响研发发布效率。为此，一套成熟的变更观测系统，是需要嵌入一个决策降噪模块，通过干预变更防控拦截结果，达到在风险召回不劣化的同时，提升准确率，让结果更加置信。
因此，今天笔者决定结合自己的工作经验，简单聊一下变更风险防控架构的宏观体系当中，决策降噪模块应当怎样接入比较合适。需要说明的是，本文不涉及具体降噪的实现，包括算法的许多部分，主要是从后端工程架构角度，聊一下怎样的架构设计，能够让变更观测任务和决策降噪任务完美配合起来。
在变更风险观测任务调度过程当中，如何让一个观测任务在合适的时间点调用合适的变更防控能力，确保在变更过程中及时发现和处理风险，是任务调度模块设计方面比较重要的问题之一。在先前的文章中，也简单提到了变更观测任务调度的基本设计方法。但今天这篇文章，主要关注通过标准化事件的方式，通过事件驱动解决变更检测能力的调度问题。
近来AI大模型发展迅猛，不论是工业界还是生活界都纷纷开始进军AI，了解基于LLM的问答Agent需要如何开发。为了跟风，笔者也粗浅了解了下问答Agent开发的一些基础知识，简单开发了一个主要关注Python问答的Agent，挂在了自己的微信公众号上。
要开发一个问答Agent也很简单，重要的是得清楚一些本质：
接续先前CozeStudio的文章，CozeLoop相对于CozeStudio，更加专注于Prompt Engineering，打磨整个Agent Prompt的效果。因此，本篇文章也分享一下笔者使用CozeLoop的体验，源码可以从这个Repo里面拉取。
近期Coze开源了自己的核心产品CozeStudio和CozeLoop，CozeStudio主要面向AI-Agent产品开发和周边生态，而CozeLoop主要面向Prompt Engineering以及效果评测。借这个机会，笔者也踩坑了下CozeStudio和CozeLoop的源码，在本地做了部署简单玩转了下，也顺带了解了下CozeStudio跟CozeLoop的一些产品原理。
本篇文章就先分享一下CozeStudio的踩坑体验，源码可以从这个Repo里面拉取。
近期做项目时遇到一个场景，是需要在后端任务执行时动态注入策略。具体而言，笔者负责的后端服务，可以理解是会在线上服务发布时，对服务风险做实时扫描，那么这个扫描就需要根据当前线上服务发布上下文，匹配对应的策略。但这里扫出来的策略都是静态持久化的，前端也有产品化的配置，而有些业务则希望能够在任务执行时，动态注入一些业务自己理解需要的扫描策略，不在前端做静态配置。
对于这类定制化需求，笔者想到的一种比较低成本实现的方式是这样的：
《逸剑风云决》算是笔者认为近10年最好的国产游戏之一，不亚于黑神话。从24年开始笔者已经玩了很多个周目，甚至黑神话也没玩，终究还是因为《逸剑风云决》本格的武侠风格确实对到了笔者的胃口，并且用UE4做的效果也还不错。今年新出了2个DLC，也倒逼笔者重新开了一周目，素麟猖獗，打了次极难8+31娜乌线完整结局，204600点数。期间参考了很多攻略，踩了挺多坑，因此笔者今天就简单分享一下自己的攻略整合。
首先先列出笔者参考过的攻略合集，包括：
因工作原因，近期笔者以相对偏IC的身份，牵头一个两个team共建项目的产品研发工作。在这个过程中，笔者也简单积累了一些IC工作的经验，踩了些坑，也有一点阶段性成果。这篇文章就根据自己经验聊聊作为IC角色，怎么去把控整个产品研发的规划和节奏，给一些实战当中的Tips。
整体来看，首要任务是了解自己角色需要做些什么去推动整个项目运作，其次是拆分任务确定哪些先做哪些后做，最后才是做技术实现，每一步都把最关键最优先的成果做出来。
在AI助手时代，OOM的问题排查方法论已经非常烂大街，但在实际工作中，即便我们通过很多方式查到了OOM问题，但修复还是要我们自己手动修。OOM会导致服务不可用、系统不稳定等问题，会直接影响用户体验，所以从稳定性问题解决优先级来看，是属于比较高的。
因此，今天笔者就简单从自身经验出发，聊一下OOM问题的排查和解决经验。从事情上来看，轻排查，重解决。排查的手段很多，但怎么解决，就需要我们自己根据实际情况来决策。