文章

有一点说法我觉得是没错的，那就是未来，尤其是现在的 AI 时代，招聘的整个方式和体系都一定会逐渐改变。因为所谓的古法编程，它带来的收益会越来越低...

• ai运用

我之前提到过 基于过程的质量控制 ，其实从 How Anthropic runs large-scale code migrations with Claude Code | Claude by...

• ai运用

谈一下我自己对于「到底要不要看代码」的看法吧。 其实对我来讲，我是主张「不要一行一行去读代码」的立场的，这点在基于过程的质量控制里面就谈到过...

• ai运用

rust本身比较有意思的地方是，他是一个强类型-内存安全的语言，所以说很多东西都会规定的很死，通过一定的动态牺牲，带来了较大的安全性和稳健性...

• 随笔

我最近一直在想rust的特性，这种强编译时验证的语言可以把大部分潜在问题都拦截在编译期，意味着哪怕不写测试，它只要写出来天然就是一个自带测试的语言，这种高度可验证的特性让其非常适合 ai 时代...

• ai运用

分布式的关键问题在于使系统在运作中逐渐收敛到一致，核心有三个因素：设定的预期校准点、观测、误差。我们希望的是缩小贯彻和校准点之间的误差，因此每次测量后就可以得到应该修正的方向，然后不断迭代收敛...

• 设计模式与架构

我对单一职责（SRP）的启发式理解是「能单测，没有副作用，一个函数只做一件事」，当然我知道这不完全严谨。但作为快速判断我觉得是好的。 能单测...

• 设计模式与架构

我现在越来越认为， Agent take 开发需要依赖于一套足够的质量控制过程来保证。这就像制造业中的 QA 一样，对关键部位进行抽样，或者是对整个流程控制进行管控...

• ai运用

将复杂软件设计类比到生物上，确实极有启发性。尤其是复杂系统的自组织原则——既然对于一个大型的生物系统来说，它可以在不需要掌握全局信息的情况下就运作良好...

• 设计模式与架构

level-triggered 跟 edge-triggered 的区分还挺有意思的，这是异步I/O中的重要概念，指的就是触发的模式...

• 设计模式与架构

pnpm workspace 是个很有意思的用法，可以把各个子目录正式化为统一管理的程序模块，让各个模块存在转为可以通过 @xxx/xxx 形式引入的包...

• 设计模式与架构

FROM 的主表一般就是左表，而 LEFT JOIN本质上就是取左表+两表交集的部分，剩下的右表未交集部分则直接为null；而INNER JOIN则是直接取交集，两表都有的才返回...

• 随笔

Andrej Karpathy: From Vibe Coding to Agentic Engineering w/ Stephanie Zhan - YouTube Stop Prompting...

• ai运用

在Al时代，每个程序员都活成了自己最讨厌的那种team leader: 1.半年不写一行代码，编程能力严重退化，还自诩「我也是搞技术的」 2.开会的时候把一线开发干的活全说成是自己的功劳...

• ai运用

抽象是好的，这没错，能隐藏复杂实现背后的细节，而只将结果暴露出来——但这一切是有代价的。对于使用者来说，一般情况下我们希望达到的结果是方便和便捷，不需要理解背后的一切即可用一个调用解决问题...

• 设计模式与架构

这个有点意思，叫做「语言整合查询」（Language Integrated Query），可以在C#里用类似sql的查询方法，只要是枚举类都可以用这个...

• 随笔

这就像一个中间截流管，可以说是Observable的中间件。里面预定义了一些RxJS的处理方法，可以让我们对返回的结果进行截留，然后按我的要求进行一个预处理...

• Angular

Angular有一个地方和React不太一样，这里的属性变动本身就会触发重新渲染，在React那边就必须要状态。而另一个方面则是这里的服务函数，这个是全局单例，所有组件共享状态...

• Angular

这是一个专门用来记录子组件Input变化的类，一般是和ngOnChanges搭配，作为元素传入方法内。里面是嵌套的键值对，分别是属性名：SimpleChange（注意少了个s），下面是结构...

• Angular

Observable的pipe那里说到了供水，但那边只是被动的供水——如果我想要中间往里面加水并让所有吃水者都喝上新的水呢？比如从地下水换成山泉水，带有甘甜的滋味（嗯......）...

• Angular

通过渐进披露的模式把入口文档作为目录，然后不断建立分层索引的模式来进行逐渐的展现。就像OpenAI这篇文章说的一样，AGENTS.md/CLAUDE.md应该是一份地图，而不是全面的手册...

• ai运用

我最近确实是发现了，全端开发确实能让人洞察到更多东西，尤其是那些前端和后端分别不同的坑和雷点。前端的bug有时候纯粹是后端背锅，比如出错了却只说出错，而完全不提为什么出错，导致前端除错除的寸步难行...

• 随笔

反射在有些地方看上去有点像是委托，但两者的差异还是蛮大的。委托的关键是编译器安全，而反射则是牺牲了编译时的安全检查，而带来了运行时的灵活性：它通过字符串来调用或取到指定的对象...

• 设计模式与架构

angular的设计原则和react最大的差别是，后者基本是state就是一切，但前者会把各种功能包装好，signal虽然很像state，但实践中似乎很少直接操作signal...

• Angular

这里有个坑，这俩是不能并用的，响应式表单内如果要单独加ngModel，就必须给他加上单独模式。因为响应式表单本身就自带双向绑定，都加的话就会冲突...

• Angular

C#的委托，事实上在DI里面就已经在用了。假设我定义了一个func类型，叫A，然后在下面A()，这里虽然我没显示写delegete关键字，这就已经是委托了...

• 设计模式与架构

不懂ioc只会把DI用成臃肿的工厂模式——比如XML,JSON,TXT的格式转换，在里面new了一堆内容，并用枚举switch来判断——但完全可以ioc，定义一个泛型，让外部给入...

• 设计模式与架构

我现在发现，与其将各种状态都耦合在代码内部，不如用资料库做统一的、共用的持久状态管理。这样各个功能模块彼此之间就可以去耦合，而以模块——抽象的单位积木——为存在彼此只关注数据...

• 设计模式与架构

Angular 的这个 Service 看上去用法跟 Hook 是很像的。不过它们最大的差别就是：React 里的 Hook 只能在组件里面共享状态...

• Angular

angular确实是把订阅者-接收者贯彻始终，包括子传父在内也是利用了Observable的机制，子层发布一个事件，而父层则订阅这个事件，等待其触发后来执行相应的回调...

• Angular

Strangler Fig 是一种寄生植物，会逐渐缠绕并吸取宿主的营养，最终让宿主枯萎，自己蓬勃生长取而代之，谓之「绞杀」...

• 设计模式与架构

约束（Harness，或者说缰绳、马鞍，限制马的工具）工程，是个很有意思的概念，看上去更像是上下文工程的延申——核心的关键是把对agent的上下文约束，进展到整个环境约束...

• ai运用

ts这个装饰器从本质上来说仍然是一个高阶函数，和py的装饰器在使用场景上是差不多的：当我需要给某个对象进行一个「包装」，但又不想整个重写这个原有的方法时，那我就要用装饰器...

• TS

双向绑定的模板写法，在Angular里其实算是个一次性的语法糖，本质上就是一次性绑定数据，数据变动触发事件回调并更新的操作，给全部封装在了一起，那就是默认的香蕉盒子写法。 而这个当然是可以自主控制的...

• Angular

CRTP是个很有意思的东西，全称是泛型基类（Curiously Recurring Template Pattern），也就是限定子类输入类型的基类...

• 设计模式与架构

DI的核心点就是定义结构，而这个一般有两种用法 接口 interface 抽象类 abstract class 核心的关键是DI容器需要知道自己处理对象的结构体，这样才能进行后续处置...

• 设计模式与架构

这俩最大的区别其实就是后者多了一个响应式的现代前端框架——以前是控制器去控制页面更新，完全要手操，但现在只要数据变更，框架自动接管，这就是响应式更新...

• 设计模式与架构

A家的最新研究其实已经证明了我之前的想法，尤其是跟学习科学结合在一起，我们就会发现：学习新东西的确需要一些「有效的困难」。如果你完全一帆风顺，说明这个东西可能不在学习区，或者说你根本没在学习...

• ai运用

plan 和 sdd 适合的场景是： 你知道该做什么 或者你相信 AI 会做什么 用akr的话来说的话，就是这种提前决定好情况和流程的ai使用，最适合情况已知而且非常成熟的情况下来做...

• ai运用

这篇研究也挺有意思的，里面表明，就算是agents.md这样的上下文文件，也不总是什么都往里面写就是最好的。这就是典型的上下文污染问题...

• ai运用

依赖注入（DI）真的蛮有意思的，本质上来说就是一种更加抽象的封装，把整个类变得更加通用化或单纯化。比如我需要一个转换器，比起把那些数据直接写死在里面，不如从外面传入——但这里还只是数据...

• 设计模式与架构

目前来看静态构造函数就是比较好的办法了，单例和基类的操作目前有点用不太到，毕竟也没什么共享的变动数据，基类的话，只有一个服务，强行去写反而有点过度设计。综合来看，下周的优化方向就是静态构造函数的方式...

• 设计模式与架构

这个有点意思，本质上也是一种高阶函数的运用，即将自己的对外接口暴露为接受一个key和func\<key,V>。这里的key即是当前func的元素，V是C#类型声明定义下的输出类型...

• 设计模式与架构

组合优于继承的关键因素是去耦合，或者说，就像积木一样的模块，而状态则通过外部因素给入——大部分情况下采用静态方法就足够了，但少数情况下可能需要的是一个组合类，下面许多方法共享同样的状态——但是...

• 设计模式与架构

能用「有一个」描述就用组合，只有「是一个」才用继承。 我对这句话的理解是，如果彼此之间没有实际意义上的继承关系和依赖关系，而只是为了代码复用，那么直接采用组合是最好的方法...

• 设计模式与架构

这个地方有点意思，那就是继承和约束，似乎有一点相通的意思，而且说到底，继承本身也意味着对结构体本身的继承，本质就是一种约束...

• 设计模式与架构

依赖注入这种设计哲学的核心依然是围绕着一个关键词——解耦。接口简单，内核复杂。抽象对外暴露的就是简单，而具体的过程则被封装在实现之中...

• 设计模式与架构

响应式页面主要指的是数据流的响应，但是对于前端的整个页面展示来讲，它其实是静态网页。 像现在比较知名的 SPA（单页面应用），基本上都是静态页面...

• 随笔

\<T>泛型对象应该是静态语言中比较难以理解的一个概念。但就其本质而言，它就像是一个占位符：通过告诉编译器这里未来会有某个类型——它既可以是已有的类型，也可以是自定义的类型...

• TS

如果要取得某方法返回值的类型，这里有一个快速的解法。 typeof A指的就是：获取后面 A 值的类型。前面那个 ReturnType 是 TypeScript 内置的一大堆类型推断工具之一...

• TS

解构赋值一般是对某个对象进行使用的。简单来说，就是将其中的属性拆分出来，然后将其赋值给局部变量。这个在函数中，有时会写成一个不是很好读的形式，但也是使用比较多的，这里要记录一下...

• TS

有点意思，claude code用的应该是agent team，而不是单个agent。上层会先梳理需求，然后产生中间 prompt和todo list，最终在将任务分工下去，然后最终汇总...

• ai运用

确实有一种观点认为全栈工程师虽然很好，但问题是知识只有广度而没有深度，不够专业化。从某种程度上我其实赞同这一点，但另一方面，我认为这种看法只侧重了表象，而忽略了其他核心因素： 存在一个职业叫作架构师...

• 随笔

我知道洋葱模型：请求全部进来之后，出去时也会从这里走一段。 中间件的话，用我的理解，有点像是 Python 里面的 @ 装饰器。在所有函数被调用之前都会先走一遍这里...

• 随笔

一般的话，微服务之间都有一些相应的微服务框架，其核心点是通过 RPC 通信进行来回的调用。 目前比较成熟的框架有： gRPC 还有阿里家的Apache Dubbo-这个可能更好用...

• 随笔

我觉得运用LLM的关键点是让自己跳脱出单纯的写代码这样的固化思维——将自己作为一个规划任务的主管，或者是微操大师去监察任务，而不是单纯的让自己成为一个局外人...

• ai运用

当时用agno主要目的就是实现agent功能： 实际上一开始我们的技术方案里面没有这个，最早设想的是单纯prompt工程加基于ragflow的知识库 但客户突然需求变更，提出了更复杂的查找和储存需求...

• 随笔

防抖很重要，尤其是在前后端有网络IO的情况下，如果用户每次操作都要往后端发一个请求，那流量费和后端服务器压力就会很大。标准处置方法就是加个延迟，用户在这个时间段内的连续操作...

• 随笔