光の技术屋

因工作原因，近期笔者以相对偏IC的身份，牵头一个两个team共建项目的产品研发工作。在这个过程中，笔者也简单积累了一些IC工作的经验，踩了些坑，也有一点阶段性成果。这篇文章就根据自己经验聊聊作为IC角色，怎么去把控整个产品研发的规划和节奏，给一些实战当中的Tips。

整体来看，首要任务是了解自己角色需要做些什么去推动整个项目运作，其次是拆分任务确定哪些先做哪些后做，最后才是做技术实现，每一步都把最关键最优先的成果做出来。

在AI助手时代，OOM的问题排查方法论已经非常烂大街，但在实际工作中，即便我们通过很多方式查到了OOM问题，但修复还是要我们自己手动修。OOM会导致服务不可用、系统不稳定等问题，会直接影响用户体验，所以从稳定性问题解决优先级来看，是属于比较高的。

因此，今天笔者就简单从自身经验出发，聊一下OOM问题的排查和解决经验。从事情上来看，轻排查，重解决。排查的手段很多，但怎么解决，就需要我们自己根据实际情况来决策。

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

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

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

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

在先前的文章中，笔者分享了go语言monorepo基本的一套代码架构设计。以这个设计为基础，今天这篇文章就聊一下具体里面的代码怎么编写起来比较舒适。

关于每个微服务自己的代码，其实在wire依赖注入这篇文章有提到过一套比较简洁的用法。如果大仓对应的服务集群有很多三方依赖，有很多错综复杂的模块的话，对三方依赖做一层抽象，加上用wire去解决重复依赖问题，是最为舒适的一套解法。当然在这个基础上，其它各模块，尤其是公有模块（lib）需要如何做代码实现，这部分是需要额外推敲的，今天这篇文章就浅聊一下。

最近玩FPS游戏的时候，发现以前一顿操作超频之后的电脑，有一定概率会出问题。具体表现比如一种是，电脑显示器直接黑屏，所有键盘交互没有响应，只能直接重启电脑，还有一种是偶现卡顿，直接死机或者卡出游戏之外。

经过排查和上网查资料发现，可能是由于超频之后，CPU的电压输出不稳定，导致偶现显示器分配到的电压比较少，最终无法正常工作。对于这类情况，笔者分享下自己的一些解决方案：

近期大模型Agent应用开发方面，MCP的概念比较流行，基于MCP的ToolServer能力开发也逐渐成为主流趋势。由于笔者工作原因，主力是Go语言，为了调研大模型应用开发，也接触到了mcp-go这套MCP的SDK实现。

对于企业内部而言，在这个SDK基础上做封装，基本上就能够完善MCP-Server的开发生态。因此今天就简单看一下这个SDK里面，实现了什么东西。

首先是Client连接的实现，这里可以看到每次连接都需要InitializeRequest、InitializeResult以及InitializeNotification这三次握手。从Client角度看逻辑是这样：

最近在AI大模型领域，MCP这个概念非常火，大大小小的公众号都开始对外炒作这个概念，宣教一种新的大模型Agent开发生态。因为工作原因，近期笔者也对MCP和LLM-Agent开发做了一些接触。因此今天这篇文章就浅聊下笔者对基于MCP的LLM-Agent开发方面，自己粗浅的一些理解。

首先还是聊一下什么是MCP，以及MCP在LLM-Agent开发方面，解决了什么问题。

在先前的文章当中，笔者分享了一套简洁的go微服务monorepo代码架构的实现，主要解决中小团队协同开发微服务集群的代码架构组织问题。但是在实际代码开发过程中，怎么组织不同的业务服务service实例，就成了比较棘手的问题。

为什么会出现这样的场景？首先，不同的业务服务可能会用到相同的底层服务，比如DB、缓存、MQ以及三方Client等等。其次，一个底层服务实例可能会在多个业务服务复用，一个业务服务又可能成为另外一个业务服务的依赖。因此这样下来，不同服务实例之间就存在错综复杂的联系，用代码组织起来就比较困难了。

幸运的是，我们拥有wire工具去做go对象的依赖注入，这样就可以用简单的代码实现解决上述问题。在以前的wire文章当中，也简单提到了wire对于微服务框架的作用，但讲解的不算特别精要。所以今天这篇文章，笔者就分享下在go大仓的场景下，怎么用wire去解决service实例依赖问题的，以及怎样才是更加恰当的打开方式。

首先我们要知道wire工具对外暴露了什么能力，有以下一些：

在研发测试日常工作中，通常会遇到很多琐碎的事情，占用我们工作的时间和精力，从而导致我们不能把大部分的注意力放在主要的工作上面。为了解决这个问题，除了加人之外，我们通常会开发一些日常用的效率工具，比如以pyqt、pyside为主体的桌面应用，一键化我们的日常工作，从而解放我们很多处理琐碎事情的精力，让我们有更多精力打磨主业，创造更好的工作成绩。

因此，本文就分享下笔者在24年下半年调研学习pyside6的一些成果，把自己做的小应用homemade-toolset开源出来，供各位有需要的同学参考学习。

整个项目包含时间转换工具、JSON工具以及类似Postman的Request工具，采用python3.11和pyside6开发，目录结构如下：