Jul1en_-CSDN博客

原创【Pi 超轻量插件】让 Jev 去掉无用的工具调用结果，留一个清爽的上下文！

长会话里那些“食之无味”的历史工具输出在使用 AI 进行较复杂的重构或排查任务时，都会遇到上下文过多压缩的情况。在 Pi 中虽然说有压缩命令，但我们可以看看他具体压缩了些什么。如果你用 Pi 跑过时间稍长的任务，大概清楚那个感觉：上下文里堆着几十轮的工具输出，read 读了几百行源码的结果、bash 吐出来的长串依赖树、反复试错时留下的废弃命令……这些东西凑在一起，等到上下文快满、准备压缩时，它们依然原封不动地躺在那儿，等着被一口气扔进去做摘要。

2026-09-23 19:50:15 191

原创 Matt 与 Uncle Bob 的播客访谈有感

在 context window 中，随着上下文不断变长，“lost in the middle“ 现象就会慢慢浮现，即模型对于比较久的和最新的对话的记忆比较清楚，但是在中间的内容却很难记得住。所以你的目标是把自己从代码里抽出来，不靠人工审查，在代码周围搭一层脚手架，自己尽量少碰，还要把 agent 拘在最紧的束缚衣里，让它没法犯错。主管工程师也好、谁也好，那个手里跑着一串 agent，自己当将军的人，应该把你当一个 agent 看：派同样的活，上同样的确定性工具。如果叠的过多显然是有的，甚至比人还慢。

2026-09-08 20:29:00 179

原创【Java 脚手架】OSS 存储 SDK/V4 签名实现上传

OSS（Object Storage Service）是一款海量、安全、低成本、高可靠的云存储服务，多种存储类型供选择，全面优化存储成本。优先使用 OSS 提供的 SDK 发起请求，因为 SDK 已集成复杂的 V4 签名算法。只有在无法使用 SDK 时，才需要参考本文自行实现 V4 签名算法。此实例代码在完成上传功能后都会尝试关闭 OSSClient，不符合此脚手架的业务逻辑，需保持开启。由于官方 SDK 已集成复杂的 V4 签名鉴权，只需传入必要的 sk 与 region 字段即可。

2026-09-02 10:54:57 258

原创做脚手架过程中遇到的自动装配的细节问题

考虑到文件服务是单独存在的，所以应该有一个启动类，那么。我当时的 OSS 文件配置模块既没有启动类，也没有 imports 文件，光存在。这次在文件服务里照抄 bite 项目的 OSS 配置时撞到了这个问题。脚手架里的 Redis、Caffeine、统一异常处理都是后者，所以要用。是 starter 的推荐写法，不做 CGLIB 代理，启动更快。，防止 starter 里的自动配置类被消费方的包扫描误扫进去。文件服务这种独立启动的模块，其实用。，所以他能被启动类扫描到。起到了作用，普通的。

2026-08-31 18:15:25 152

原创【Java 脚手架】封装通用工具类-3

所以引入了本地缓存 [[Caffeine 介绍|Caffeine]]，在脚手架里做成了三层缓存结构：L1 是 Caffeine（本地内存），L2 是 Redis，L3 是 DB。因为我会注册很多的 Bean，有给 Redis 的，有 RabbitMQ 的，还有 Caffeine 的，但是都是怎么将合适的 Bean 来装配到对应的 Template 的呢？业务没跑完锁先过期，另一个线程把锁拿走了，原线程 finally 里直接 DEL，删的就是别人的锁。设长了，服务宕机后锁迟迟不释放，后面的请求全堵着；

2026-08-28 19:06:25 224

原创 Caffeine 介绍

以下介绍基于官方 wiki 解释Caffeine 是一个基于 Java 8 开发的提供了命中率的的缓存库。为了提高集成度，扩展模块提供了和适配器。JSR-107 规范了基于 Java 6 的 API，在牺牲了功能和性能的代价下使代码更加规范。Guava 的 Cache 是 Caffeine 的原型库并且 Caffeine 提供了适配器以供简单的迁移策略。

2026-08-27 18:03:32 245

原创【Java 脚手架】封装通用工具类-2

在 Postman 能看到是被正常捕获的，但是返回的 msg 丢失了，与预期返回的字符串不符合。，因为本身脚手架是 Spring 项目，且 Spring 封装的线程池类能够更方便的对线程池的一些配置进行修改，且设计初衷需要满足 nacos 动态配置的要求，所以用。做成了一个 starter，其他微服务引入依赖，异常处理器就自动生效了。通过 debug 可以看出 retMsg 在经过 ex.getMessage() 后得到的是空值，原本的默认值也被覆盖了。这个文件，里面写了要加载的配置类。

2026-08-15 11:57:54 242

原创【Matt Pocock Skills】全新工作流详解

一切教程与观点都来自本人的实战体验与 Matt 的官方 skill 介绍和直播讲解，欢迎交流讨论！Matt Pocock 的 Skills 是一套给 coding agent 使用的工程工作流。每个 skill 都是边界清楚，大部分都要手动调用 slash command 才能触发，根据实际场景来动态调整。而且 Matt 的思想是将问题先经过不断的挖掘，然后变成spec文档，确定好前进方向后，将问题拆分成多个 issue，然后 issue 中有可能包含多个非常简单的子 issue。以ticket。

2026-08-14 22:39:40 406

原创【工作流更新】从 Superpower 到 Matt Pocock

Matt Pocock 的 skills 走另一条路：不设对话开始时的总入口，直接把 skill 分成两类。一类是主动调用的 slash command 命令，例如grill-meto-specto-ticketsimplementhandoff。它们通常对应一段明确的协作动作：把一个想法问透、把想法写成规格、拆成任务、开始实现、交接上下文。其他的技能例如tddprototyperesearch，只在合适的时候在 Matt 工作流中被调用，平时开发只需要注重主动调用的 slash command 即可。

2026-08-06 21:23:17 211

原创 Agent Harness Engineering Survey 论文所想

这篇文章总结了《Agent Harness Engineering: A Survey》论文的核心内容，系统性地梳理了AI代理控制框架（Harness Engineering）的发展脉络和技术架构。

2026-08-05 00:26:36 293

原创 Codex 降智原因与 system prompt 修复指南

这篇笔记整理了关于这个问题在目前社区里测试有效的几种修复方法。

2026-08-05 00:23:45 713

原创【Java 脚手架】封装通用工具类-1

记录我在学习制作 Java 脚手架项目时遇到的问题和知识点，以便后续复盘学习～

2026-08-03 22:02:29 250

原创【Claude Code】Compact 源码级别的学习上下文压缩

这次是沿着 Open-ClaudeCode 里恢复出来的 Claude Code 2.1.88 源码，专门看了一遍上下文压缩的原理 compact。我把它理解成“对话太长时生成一个摘要”，但顺着调用继续看会发现，摘要只是其中一层。真正让任务在 compact 后还能接着做的，是 summary、最近原文、程序状态、附件、Hooks 和 transcript 一起配合。

2026-08-02 20:52:29 391

原创【Claude Code】Fable 5 提示指南

从这份文档来看，Fable 5 的核心转变是从「单次对话中的强大模型」变成了「能跑几天的自主 agent」。相应地，使用方式也需要从「逐条指令」转向「给目标、给边界、异步检查」。之前为 Opus 4.8 写的很多 prompt 技巧可能不再必要，甚至适得其反——这倒是给了一个机会重新审视并精简现有的框架。

2026-07-04 15:49:21 419

原创【AI】Codex 的工作流更新-v3 [Codex-maxxing for long-running work]

最近 OpenAI 的一篇博客：分享了关于长周期复杂任务的指南，并针对我已有的工作流作出一些更新。长周期的复杂任务通常不是一次 prompt 改完代码就结束。它可能要经历调查、实现、预览、反馈、等 CI、继续修改、准备 PR、后续检查。该博客更像是总结了 Claude Codegoal和loop命令的思想 💭。

2026-06-24 22:15:05 250

原创【SpringCloud】SkyWalking 链路追踪知识详解及部署教程

自动插件主要覆盖框架入口和常见中间件。纯业务方法、自研协议、特殊线程模型可能不会自动出现，这时可以使用 Java Agent Toolkit。

2026-06-15 18:05:30 430

原创【SpringCloud】超详细的 Seata 分布式事务：从全局事务到 AT、TCC、Saga

Seata是 Spring Cloud Alibaba 体系里常用的分布式事务解决方案。它解决的核心问题是：微服务拆分之后，一个业务请求可能跨多个服务、多个数据库，Seata 负责把这些分散的本地事务组织成一个全局事务，让整条业务链路尽量保持一致。Seata学习 Seata 时可以先不展开某个注解或配置，先看这条主线：微服务把一个业务动作拆成多个本地事务，Seata 再用全局事务把这些本地事务协调起来。

2026-06-14 23:31:34 394

原创【AI】Claude Code 迁移至 Codex 的工作流更新-v2

之前做了一版工作流更新的博客，现有新的体会，故花时间思考重新整理了一下个人开发的工作流，发现还是有不足的地方：原有的项目维护过于笨重，需要有两套不同的工作流来适应不同的项目开发 : )这次主要是在整理 Codex / Claude Code / 其他 Agent 之间的项目初始化工作流。之前有两个入口，一个是偏 Claude 的setup，主要维护CLAUDE.md；另一个是偏 Codex 的，主要维护AGENTS.md。

2026-06-04 23:10:08 274

原创【Redis】事务详解、WATCH 实现思想

乐观锁的想法是：我先假设冲突不会发生，所以不提前把资源锁死；等真正提交时，再检查有没有被别人改过。悲观锁是：我觉得一定会有人抢，所以我先加锁。别人想操作，必须等我释放锁。乐观锁是：我觉得大概率不会冲突，所以大家都可以先操作，提交时再检查有没有冲突，如果冲突了，我就失败重试。

2026-06-04 23:01:19 354

原创【Redis】Docker 部署集群补充说明

上一节的Redis部署集群还有些不太清楚的地方，这里做补充说明，这次我们用 docker 部署 11 个 redis 节点，九个用于部署集群，两个用于扩容练习，集群的结构类似于如图，由于 redis 部署集群时内部的随机性，可能节点的静态 ip 所属的角色都不太一样，无伤大雅～

2026-06-04 22:54:26 240

原创【Redis】一文讲透缓存更新策略与缓存预热、穿透、雪崩、击穿

当 MySQL 发生新增、修改、删除时，缓存也要跟着处理。如果倒过来，先删缓存再改 MySQL 会出现什么情况呢？单一线程下一般是没有问题的；这导致 Redis 里留下的还是旧数据，这类问题后续处理起来会比较麻烦。

2026-06-04 22:50:46 353

原创【Redis】主从复制局限性与哨兵概念、Docker 部署教程

Redis的主从复制模式下，一旦这个主节点不能提供服务，就需要人工进行主从切换，这是非常麻烦的。通常哨兵也不会只设置一个，而会部署一个哨兵集群，防止哨兵挂了或单个哨兵误判。要么给云服务器加代理，要么配置镜像源。这里使用 Docker 做多个 Redis 的部署练习，结构是一个主节点、两个从节点、一个哨兵集群（三个 sentinel）。不过，一个哨兵节点发现主节点挂了还不够，需要多个哨兵节点共同认同这件事，才会进行接下来的操作，主要是为了防止误判。正常运行状态时，哨兵集群中的每个节点都是单独的。

2026-05-31 23:48:22 213

原创【Redis】集群概念

其实集群的概念很广泛。广义上，只要多个机器共同组成一个分布式系统，都可以叫集群。之前的主从复制、哨兵模式，也可以看成广义集群。Redis 这里说的集群，一般指 Redis Cluster。它主要解决的是存储空间不足的问题：把数据拆到多台机器上，每台机器只保存一部分数据。哨兵模式解决的是可用性问题，但本质上还是主从节点都保存完整数据。只要数据全集超过单机能承受的内存，就需要引入分片。Redis Cluster 的核心是分片。主从复制和哨兵主要解决可用性，集群模式进一步解决单机存储容量限制。

2026-05-31 23:44:55 323

原创【SpringCloud】微服务 Sentinel 详解

授权规则关注的是“谁可以访问我”，对请求来源进行白名单放行 / 黑名单拦截。在微服务里，不同来源的请求优先级可能不同。比如某个接口只允许内部服务调用，不允许外部来源直接访问；或者同一个资源，对某些来源放行，对另一些来源拦截。Sentinel 的授权规则一般会基于origin来做判断。你可以把origin理解成请求来源标识。规则的本质就是，对资源设置白名单或黑名单，让不同来源得到不同处理。当请求被 Sentinel 拦住时，如果直接把原始异常栈丢给前端，用户体验会很差，前端也很难统一处理。

2026-05-21 17:27:14 480 2

原创【Redis】Sentinel 哨兵支持，附带 Docker 部署教程

Redis的主从复制模式下，一旦这个主节点不能提供服务，就需要人工进行主从切换，这是非常麻烦的。

2026-05-20 23:33:45 492

原创【Spring Cloud】Spring Cloud Config详解

Spring Cloud Config 的知识链路可以从“配置管理”一路推到“自动刷新”和“安全加密”。最开始的问题是微服务配置太分散，所以引入 Config Server 和 Config Client。Config Server 统一读取配置，Config Client 启动时拉取配置。配置集中之后，又会遇到运行时变更不生效的问题，所以引入刷新机制。手动刷新在多实例场景下成本高，于是使用 Webhook 发现配置仓库变化，再通过 Spring Cloud Bus 把刷新事件广播给所有相关客户端。

2026-05-15 15:40:07 572

空空如也

空空如也