一只叫煤球的猫

我本来不想写这篇文章。 在内容创作上，我一直觉得，真正值得投入精力的，是把文章写好，把观点表达清楚，把技术内容做得更扎实，而不是把时间浪费在和某些毫无原创敬畏心的人纠缠上。 有个叫 「芋道源码」

朋友们，我煤球又回来了。 最近相当高产。 在 2站 和 v站 上都做了自荐，回到掘金上也来推荐一波～ 感兴趣的也可以看之前 2 站发的帖子： 做了个 macOS 99.9% 原生 SSH + SFTP

前言 相信你看到这篇文章的时候，已经对RAG的应用有了一个初步的概念。 无非就是先接个向量库，然后把文档灌进去，再让大模型回答。 看起来似乎很简单。 但是真做起来就会发现，实现确实很简单，但难度在于回

最后，想跟大家说：不要怕被 AI 淘汰。真正的竞争不是你 vs AI，而是会用AI的你 vs 不会用AI的你。

当上下文历史超出阈值时，把更早的部分压缩成一个 summary turn，只保留最近几轮原文。 既能保留连续性，又控制了体积，不会每次都把整段历史原样重发。 不同的方案有各自的取舍。

前阵子我写了一篇文章： 《为什么 Java 里面，Service 层不直接返回 Result 对象？》 没想到那篇文章讨论度很高。 很多人赞同，也有不少人持反对意见意见： “既然 Contro

各位，这里是煤球，遥祝各位新年开工快乐！ 不知道你们拿到开工红包没？反正我是没有的 😭 。 前言 Java 8 引入 Lambda 至今已逾十年，它彻底改变了 Java 的编程风格。然而，很多团队在大

仍然保持 ThreadForge 的目标： 让 Java 能写出更简单、更可推理、更可观测的并发代码。这次版本，重点补齐了并发开发里几个还算常见的能力。

一个简单的「并发调用三个接口」，代码已经写了 50 多行。 并且下次遇到类似场景，还得把这些逻辑再写一遍：超时、取消、异常传播、资源清理……每次都要重新思考一遍边界条件。 传统的 `Execu