Spring 团队开发者布道师 Josh Long，从 2011 年起每周二坚持写 This Week in Spring https://spring.io/authors/joshlong，大概 15 年半从未间断，到现在大概写了 800 期以上😱 大佬在采访里他说，写博客不是额外负担，而是逼自己整理每周所学的「强制机制」——反正本来就会刷社区动态，写出来既方便自己，也帮到别人。更重要的是 Spring 一直在变：微服务、AI……永远有新东西可聊，停一周就容易掉队。一旦养成习惯，坚持往往比重新开始更容易。 这种级别的大佬都还在用周更逼自己不掉队，我更没理由再拖了。还有之前左耳朵耗子大佬说的 ARTS 打卡，我老实说只撑了两周，真的需要捡起来了，加油✊

试了下 Grok CLI：curl -fsSL https://x.ai/cli/install.sh | bash 虽然功能不如 Claude Code 全，但能免费用 Grok 4.5 啊😍。一行 prompt 大概 3 分钟就生成出来了而且没有报错：" Three.js UMD 构建。正在实现完整的太阳系模拟（含自定义轨道控制，兼容本地打)"。 大伙可以访问试试：https://solar-system-seven-mocha.vercel.app/

彻底搞懂 Spring AI Tool Calling：从底层协议到源码执行全流程

别用 JWT 管理用户会话

没想到 Bot 占全球 HTML 流量的 50% 以上了，被这个比例给震惊到了。还有开发者在评论区说自己的网站「每天」访问量 250k 但是 Cloudflare 显示真实的用户只有 150 个😱 数据来源：https://radar.cloudflare.com/traffic#bot-vs-human

最近看到一篇文章，讲的是大模型的 context window（上下文窗口）。 作者把上下文分成两个区域：大约 10 万 token 以内是「智能区」（smart zone），模型表现更敏锐；超过之后进入「愚钝区」（dumb zone），注意力开始衰减，容易忘记较早的内容。作者强调，这个分界线和厂商宣传的 context window 有多大，关系不大！ 这一点也有研究侧面支持，https://arxiv.org/abs/2404.06654、https://research.trychroma.com/context-rot：有效可用上下文往往只是宣传值的一小部分，而且窗口越满，性能越容易逐渐下降。 作者原文里有一段话说得很直白：「大上下文窗口在很大程度上只是营销数字。背后的架构确实能工作，但它们掩盖了一个底层注意力机制并未真正解决的问题：包装盒上的数字每一代都在变大，真正可用的部分却没有跟上。」 作者的应对方式也很有意思：开一个新会话，把一份自己写的 spec 传进去。这比自动摘要信息密度更高、交接更有效，因为「接下来什么才重要」由自己决定，而不是交给已经退化的模型去猜。这相当于把「留面包屑」的思路用在 Agent 上——留下一份清晰的交接物，让下一个会话，或下一个人，都能顺顺当当接上来。 原文：https://garrit.xyz/posts/2026-05-06-dont-trust-large-context-windows

今天看到一篇文章，主要讲的是关于 Claude Fable 的”黑箱操作“，因为 Fable 他有一个安全机制，检测到预训练流水线、分布式训练基础设施、ML 加速器设计等的时候会自动降级，并且「不会告知用户」，如果一直是这种趋势进行下去的话，那么以后你问 Claude 某个方案是否可行，Claude 说不可以，你不知道是不是真的不可以，还是因为触发了这个安全机制导致的降级。 作者的核心观点如下： 1、静默降效：Fable 5 模型卡写明，针对“前沿大模型开发”（预训练流水线、分布式训练基础设施、ML 加速器设计等）的请求，会通过 prompt 修改、steering vectors、PEFT 等方式悄悄降低 Claude 的有效性，且不会告知用户，也不会切换到其他模型。 2、边界模糊：作者认为，许多曾只属于 AI 实验室的技术（embedding、reranker、小模型微调等）如今已广泛用于普通软件公司。Anthropic 给出的例子不够清晰，“前沿 AI 研发”与“正常产品开发”的界线越来越难以划分。 3、供应链风险：当 Claude 给出错误或糟糕建议时，开发者无法判断是模型能力不足、上下文有问题，还是被隐藏的政策限制暗中削弱。开发工具若能在不告知的情况下停止为你优化，就难以完全信任这套基础设施。 4、影响范围争议：Anthropic 称仅影响约 0.03% 的开发者，但作者认为“AI 公司”的定义在变——今天不训练前沿模型，明天产品里也可能包含自研/微调模型，受影响人群可能随时间扩大

LangChain4j 调用 DeepSeek 工具时报 400？用 pi 抓包定位，同包覆盖修复 reasoning_content

今天在本地跑通 Qwen3.6 了！ 使用的工具是 llama.cpp https://github.com/ggml-org/llama.cpp 还踩了一些坑，比如识别不到 GPU 只能由 CPU 跑的情况（有没有识别到可以在对话的时候看一下 GPU 系统占用就知道了） 查看自己 cuda 版本 nvidia-smi 就可以看到自己的版本，后面下载的时候下载相同的版本即可，比如我运行的结果是这样的 CUDA UMD Version: 13.3 所以需要下载 CUDA 13 C:\Users\leikooo>nvidia-smi Mon Jun 1 16:30:40 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 610.47 KMD Version: 610.47 CUDA UMD Version: 13.3 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Driver-Model | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA GeForce RTX 4060 ... WDDM | 00000000:01:00.0 On | N/A | | N/A 52C P0 15W / 95W | 1205MiB / 8188MiB | 1% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ 下载的时候需要下载对应自己 cuda 的版本 Windows x64 (CUDA 13) 和 CUDA 13.3 DLLs（一定要下载），两个下载完成之后需要把 CUDA 13.3 DLLs 解压的内容放到 Windows x64 (CUDA 13) 解压的里面才可以正确识别到 GPU 。下载链接 Github Releases https://github.com/ggml-org/llama.cpp/releases/tag/b9442 最后附上系统占用的情况，因为跑的是 35B 的所以占用几乎全都满了 PS 启动命令 llama-server.exe -m "xxx.gguf" -ngl 999 -c 20000 --cache-type-k q4_0 --cache-type-v q4_0 --host 127.0.0.1 --port 8080 --jinja （执行这段命令可以在下载完模型的 gguf 文件的文件夹执行，只需要把这个 xxx.gguf 改成真实模型的名字即可）

记录一个 Idea 配置文件解析的问题，最近更新了 Idea 发现打开之前的项目的 application.yml 全部飘黄，更新之前是不存在的 key 飘黄，现在是全部都票黄了，看着非常难受。 解决：File | Settings | Languages & Frameworks | Schemas and DTDs | Remote JSON Schemas 取消勾选 Use schemastore.org JSON Schema catalog