光の技术屋

近来AI大模型发展迅猛，不论是工业界还是生活界都纷纷开始进军AI，了解基于LLM的问答Agent需要如何开发。为了跟风，笔者也粗浅了解了下问答Agent开发的一些基础知识，简单开发了一个主要关注Python问答的Agent，挂在了自己的微信公众号上。

要开发一个问答Agent也很简单，重要的是得清楚一些本质：

今天水一篇博客「如何用Python打开一个文件？」，原因是今天问到AI这个问题，但发现AI的回答不是特别符合预期。或者说，对于「打开」这个词语，AI的理解更加倾向于程序意义上的「打开」，而并非产品意义上的「打开」。所以第一感问下来，没有问到预期的答案。

最后琢磨了一下，这个问题的正确问法是这样：

接续先前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问题的排查和解决经验。从事情上来看，轻排查，重解决。排查的手段很多，但怎么解决，就需要我们自己根据实际情况来决策。

近期笔者因为工作原因，开始启动team内部部分技术项目的重构。在事情启动的过程中，内部对于这件事情的定性和投入有一些争论，但最终还是敲定了下来。其中部分争论点主要在于产品形态，因为事情涉及到跨部门合作，所以产品形态怎么符合双方的利益是比较重要的。在这个前提下，然后才是技术设计上面，怎么能够迎合长久合作的需要。

因此，今天笔者就简单聊一下，怎么去做到让技术架构设计和预期产品形态能够做到有效平衡。

在先前一篇文章中，笔者给大家提到了go语言后端编程可以用wire依赖注入模块去简化单例服务的初始化，同时也可以解决服务单例之间复杂依赖的问题。但实事求是来讲，用wire也是有一些学习成本的，wire在帮助解决复杂依赖的问题同时，也会限定你去用一些特定的编程方式来满足wire的需要，尤其需要你interface给用的更加灵活。

因此今天这篇文章，笔者结合自己的经验，就和大家浅分享下，wire和interface配合的一些经验，让大家以后用wire的时候避免一些坑。