Yano

20260816 随笔

Sun, 16 Aug 2026 00:00:00 +0800

最近几个月完全进入了一个崭新的阶段：

家庭：有了孩子，生活重心从自己转向家庭。
工作：3 月份换了工作，难免会有一些适应过程。
探索：随着 AI 的发展，开始尝试其他的可能性。

我的生活发生了极大的改变。例如在有娃之前，我可以经常玩 Switch，但是在有娃后的两三个月，Switch 我一次都没有打开过；休完陪产假回到公司第一天，同事说我比之前憔悴了……

我是比较喜欢写东西的，不过看这个参考已经有快 1 年没有更新过。外部因素就是工作和家庭都在变动。现在算是到了一个稳定阶段，决定以后按照周总结的形式，每周发布一篇文章，记录自己一周的所见所得、所思所感，包括自己读了什么书、看了什么电影和漫画、看到的新鲜的技术或事情。

今天刚刚搭建好 GitHub 博客：https://ljyyano.github.io/Thinking_in_Java_MindMapping/，下周开始记录。

《塞尔达·王国之泪》-全套装、全收集截图

Sun, 11 Jan 2026 00:00:00 +0800

在之前玩旷野之息时，在 B 站发布了一篇《塞尔达·荒野之息》- 全套装、全收集截图。王国之泪发售了两年半的时间，我的累计时长超过了 400 个小时，现在几乎 100% 通关，全地名、全收集，写篇文章作为记录。

静下心来游玩，能发现游戏中各种细节和美好，能让人会心一笑。以下是我的截图合集 📸。

ZELDA NOTES 截图

入手了 Switch 2 增强版，画面提升非常明显，而且支持 4K 60fps 输出，游戏体验非常流畅。最最最最最重要的是通过 Nintendo Switch APP 的 ZELDA NOTES 能够实时查看游戏中各种未完成的任务、未收集的物品，还有实时语音导航！让我又多玩了 50 个小时，达成了近 100% 的成就。100% 洞穴、100% 井、100% 深穴、100% 克洛格、100% 各种敌人……

实时语音导航太重要了，因为王国之泪地图纵深非常大，使用 ZELDA NOTES 开启语音导航后，不仅能实时语音导航东南西北方位，甚至还能够告诉你是上方还是下方；且在很多特殊位置（例如洞穴中），导航还会根据玩家的当前位置给出行进路线规划。

下面是我的 ZELDA NOTES 截图：

套装截图

说明：

部分套装未升到满级，这里仅展示各种套装及效果
部分头饰外观不太明显（蓝宝石头饰、黄玉耳坠）
“残旧的防寒服”没有截图

收集品截图

Yano 的 2025 观影总结

Wed, 31 Dec 2025 00:00:00 +0800

前言

2025 年马上就要过去了，总结下自己在 2025 年看过的影视作品。

除了漫画和游戏，其他影视作品几乎都是和汪总一起看的，算是两个人兴趣爱好的最大公约数了😁

历年观影总结

电影

《美洲大宝荐：你好美国》

食贫道在 B 站的纪录片，时长 3 小时，用不同美国人的视角，展现了一个更全面的美国。从华尔街精英到街头流浪汉到美国老兵，采访了近十位不同阶层的人物，真实记录了美国各阶层人民的生活片段。看完让人“对美国梦”有了更深的思考。尤其是模仿特朗普的老哥……

《南京照相馆》

和汪坐进电影院后，看了几分钟有些后悔，看到血很难受，我为什么要花几个小时去看一个这么沉重的电影？但是看下去就发现，电影以一个非常好的切入点，讲述了南京大屠杀的故事，通过细腻的情感描写和紧张的剧情发展，展现了人性的光辉与战争的残酷。王传君的演技很强。看完电影后，心情久久不能平复。这样的电影无论是从拍摄还是教育意义上都值得满分。

《因果报应》

虽然之前看过 UP 主的解说，但是看电影的时候还是被结局震撼到了。这部电影以因果报应的主题为核心，通过环环相扣的剧情设计，展现了善恶终有报的深刻道理。影片的叙事结构巧妙，多条线索交织在一起，最终汇聚成一个令人深思的结局……希望陈思诚不要看到这部电影，不要翻拍。

《哪吒之魔童闹海》

超出预期的好，整部电影从内容结构、剧情到音乐都很用心，2 个半小时丝毫不觉得无聊。笑点不突兀，而且拍出了神仙大战的大场面，拍出了社会隐喻。

《年少日记》

这就是东亚模式的家庭，孩子的成长环境有问题，可能需要一生来治愈。

《哆啦A梦：大雄的绘画奇遇记》

每年看一部哆啦A梦剧场版已经成了习惯，这部也不例外。电影以绘画为主题，大雄通过画笔进入画中世界，展开了一段奇妙的冒险。整体剧情在线，故事推进自然流畅，讲述了一个完整的故事。喜欢哆啦A梦剧场版的想象力和童真！

其他

《东瀛大宝荐》纪录片
《何以当归》纪录片
《好东西》
《那个人消失了》
《鬼灭之刃：无限城篇》第一章
《红毯先生》
《完美的日子》
《唐探 1900》

电视剧

《悠长假期》

之前没有看过，在汪总的带领下看了一遍。年轻时的木村拓哉确实……这部剧虽然是 90 年代的经典，但放在现在看依然不过时。故事讲述了钢琴家濑名和模特小南之间的爱情，两个失意的人住在一起，慢慢产生了感情。剧中的节奏很慢，但那种淡淡的温暖感很打动人。“人生不如意的时候，就当是上天给的悠长假期”这句话现在听来依然很有道理。Don't worry, be happy，放慢脚步，享受生活。

《四重奏》

看这种日剧，虽然都是日常对话，但是总是给人一种温馨的感觉。四个性格迥异的音乐家住在一起，每天一起吃饭、一起练琴、一起聊天，那些看似平淡的日常，却充满了生活的温度。每个人都有自己的秘密和故事，但在那个小小的别墅里，他们找到了彼此的陪伴和理解。剧中的台词也很经典，比如“人生有三条道，上坡道、下坡道、没想到”，让人会心一笑的同时也引发思考。这种慢节奏的日剧，没有激烈的冲突，没有跌宕的剧情，但就是能让人静下心来，感受生活的美好。

《重版出来！》

刚开始看的时候，觉得女主角表情、动作太浮夸，但是女主的热情确实感染了剧中的每一个人，有点许三多的感觉。虽然整部剧有夸张的成分，但是也确实了解了漫画家和编辑的流程。

《唐朝诡事录之长安》

虽然前两案有部分情节有水的成分，但是后面几案质量又回来了。最近几年难得的非常用心的古装剧，看的时候都不忍跳过。每个单元剧都很工整，而且很多画面都很对称工整，看得出来导演是有一点强迫症在里面的。

其他

《唐诡奇谭》（追剧中）
《怪奇物语》第一季
《怪奇物语》第二季
《怪奇物语》第三季
《怪奇物语》第四季
《斯特莱克探案集：布谷鸟的呼唤第一季》
《鱿鱼游戏》第二季

动漫

今年看漫画使用 Panels APP。界面简洁，而且可以很好地管理漫画库。在 iPad 上阅读漫画的体验尤其出色，还能模拟正常翻书的感觉 👍🏻

《Bug Ego》漫画

ONE 真的是个天才！

ONE 继《一拳超人》后与設楽清人合作的新作，讲述两个高中男生羊谷和黑堂的故事。一个高一个矮，一个活泼一个孤僻，通过神秘的隐藏技成为好友。44 年后再次相遇时，羊谷意外回到高中时代，由此展开一段奇幻、搞笑又充满悬疑的青春故事。地球 BUG、操场裸舞、千奇百怪的隐藏技…只有你想不到，没有他画不出来！只能惊叹于 ONE 的脑洞 🧠！

《弥留之国的爱丽丝》漫画三刷

不要看 Netfix 真人版！不要看 Netfix 真人版！不要看 Netfix 真人版！

每次出差在飞机上就会用 iPad 看这部漫画（因为 iPad 里只缓存了这一部漫画）。作者想要讲述的故事非常完整，里面每个人都是主角，所谓的男主也只是完成了里面的少数几个游戏而已。在短时间内，大量角色和剧情同时推进，作者的叙事手法和镜头语言也多种多样。

作者想要探讨和传递的主题，结合“弥留之国”这个国度传递出来也非常高明。甚至最终话用了整整一话的内容，用一个记者采访路人的方式，也在采访每个看这部漫画的人：

“你觉得你是为了什么而活着的？”

《JOJO 的奇妙冒险：STEEL BALL RUN》漫画

JOJO 系列的第七部，讲述了 19 世纪的美国，进行的横跨大陆的为期 7 天的赛马比赛，整个故事浑然天成，让我忍不住一直往下看（每次晚上 11 点了，想着再只看一话，然后就……）。荒木飞吕彦在这部作品中重新定义了“替身”的概念，用“旋转”这个物理概念替代了之前的超能力。

主角乔尼·乔斯达从一个自私的残疾人，到最终成长为真正的英雄；杰洛·齐贝林的”黄金精神”贯穿整部作品。整部漫画的节奏把控、分镜设计、剧情推进都堪称完美，每一场战斗都让人紧张不已。看完后不禁感叹，荒木真的是天才。

第七部确实是有魔力，我试图看第八部，但是看了 30 多话实在坚持不下去，放弃了……

《胆大党》第一季、第二季

音乐不错，动画很潮，超能力 + 外星人，脑洞在线。剧情节奏紧凑，战斗场面设计得很有创意。作者是有点才华的，就是有点恶趣味，经常让角色爆衣 🫣

《凡人修仙传》

可以看到动画制作组的用心，每年都有进步，剧情和制作质量都在提升。作为国产 3D 动画，画面质量已经达到了很高的水准。红尘劫、虚天殿、韩立结婴，文戏武戏都是非常高的水准，每帧画面都非常考究符合人物性格和设定，改编也是相当出色。自从看了《凡人修仙传》，《牧神记》、《斗罗大陆》这种制作不怎么用心的动画，已经看不下去了……

其他

《夏日重现》漫画二刷
《炎拳》漫画
《灵笼》第二季
《电锯人》漫画
《我独自升级》漫画

游戏

《斯普拉遁 3》

除了网络问题，其他一切都是满分！任天堂的创意无敌，可爱的鱿鱼角色，新颖的规则，潮流的 UI。

我也累计已经有 300h+ 的游戏时长，打工模式从“熟练打工仔”成为了“传说打工仔” 🏆。在对战模式甚至还会研究各种配装（最爱巴勃罗，小笔刷 S 走位 🐍），对战意识也有了提高。

《塞尔达传说：王国之泪》

入手了 Switch 2 增强版，画面提升非常明显，而且支持 4K 60fps 输出，游戏体验非常流畅。最最最最最重要的是通过 Nintendo Switch APP 的 ZELDA NOTES 能够实时查看游戏中各种未完成的任务、未收集的物品，还有实时语音导航！让我又多玩了 50 个小时，达成了近 100% 的成就。100% 洞穴、100% 井、100% 深穴、100% 克洛格、100% 各种敌人……

附上我的 ZELDA NOTES 截图：

其他

《塞尔达无双封印战记》
《哈迪斯 2》
《咚奇刚蕉力全开》

综艺

《明星大侦探》第十季

一整年几乎没看什么综艺，只是惯例在追《明星大侦探》。已经变成了情怀，什么时候双北还能再聚一次！

豆瓣截图

我的公众号

我的博客地址：博客主页。

coding 笔记、读书笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

Skill：让 Agent 变得可复用、可控、可演进

Mon, 22 Dec 2025 00:00:00 +0800

`Skill`：让 Agent 变得可复用、可控、可演进

前言：为什么要把“提示词经验”升级成 `Skill`

如果你只是偶尔问问 ChatGPT，一个“写得不错的 Prompt”已经足够。

但只要你开始用 Agent 做事（写代码、跑脚本、查资料、写文档、对接系统），很快会撞上三个工程层面的老问题：

不稳定：同一个任务，今天能做对，明天换点上下文就跑偏。
不可控：你知道它“可能会做”，但你说不清它“应该怎么做”，更别提调试。
难复用：每次都要靠“临场发挥”去改提示词，经验沉淀不下来。

我倾向于把这类问题归因到一句话：你把一段“工作方法”塞进了对话上下文，但它并不是一个“可调用的能力单元”。

而 Skill 的目标很朴素：把“会做”变成“可调用”，把“经验”变成“资产”。

相关链接：

Agent 的工程视角定义：AI/Agent 原理.md

一、`Skill` 是什么

1.1 一句话定义：`Skill` 解决了什么问题

Skill 是对某类任务的“稳定做法”的封装：它把你希望 Agent 遵循的步骤、校验点、输入输出规范、以及可用工具边界，做成一个可以复用的能力单元。

你可以把它理解成：

在软件工程里，它更像一个“模块 / 函数”，而不是“临时写在控制台里的命令”；
在团队协作里，它更像一份“可执行的 SOP”，而不是“某个人脑子里的诀窍”。

1.2 `Skill` 的组成：说明、契约、边界、失败处理

一个最小可用的 Skill，建议至少回答四个问题：

它能做什么：适用场景与目标（以及 Non-Goals：明确“不做什么”）。
怎么用它：输入是什么、输出长什么样（可被下游消费）。
它怎么做：步骤、关键决策点、每步的校验标准。
它在什么边界里做：能调用哪些工具，能读写哪些资源，遇到失败怎么处理（重试/降级/请求用户补充信息）。

这里面最“反直觉”的，是 输入输出契约。

很多人写提示词只关注“你要做什么”，但忽略“你要输出什么结构”。结果就是：看起来像在执行，但产物不可用、不可组合、不可验证。

1.3 一张图看懂：`Skill` 的“可验收执行链”

如果只看文字，Skill 很容易被误解成“更长的 Prompt”。其实它更像一条可中断、可回退、可验收的执行链：

flowchart TB
  A[Inputs 输入<br/>必填/选填] --> B[Steps 执行步骤<br/>可拆分/可复用]
  B --> C[Checks 校验点<br/>格式/范围/关键字段]
  C -->|通过| D[Outputs 产物<br/>结构固定/可被下游消费]
  C -->|失败| E[Failure Modes 失败处理<br/>补信息/重试/降级/停止]
  E --> B

1.4 `Skill` 的颗粒度：什么时候拆，什么时候合

我的经验是：把 Skill 的颗粒度控制在“一次对话里可以讲清楚、一次执行里可以验收”。

一个粗糙但好用的判断方式：

该拆的信号：
- 一个 Skill 里出现了多种完全不同的决策路径；
- 产物形态差异很大（时而写报告、时而写代码、时而查数据）；
- 你发现自己想给它加越来越多的“如果……就……否则……”。
该合的信号：
- 拆开后每个 Skill 都依赖前一个 Skill 的半成品；
- 你需要用户频繁“手动串联”多个 Skill 才能完成一个最小任务。

二、为什么需要 `Skill`

2.1 复用：把个人经验变成团队资产

在没有 Skill 的世界里，经验往往以三种形式存在：

某个“写得不错”的聊天记录；
某个人脑子里的“手感”；
一个越写越长、越改越乱的系统提示词。

Skill 的价值在于：它让经验具备可复制性。

维度	普通 Prompt	Skill (能力单元)
主要载体	一段聊天记录 / 临时指令	独立文件 (.md / .mdc)
复用性	依赖复制粘贴	可被路由、可被导入
关注点	“帮我把这个做了”	“按这个标准流程做”
稳定性	随机性强，依赖模型心情	有校验点，输出结构固定
维护方式	每次重写	版本管理 (Git)

一旦你把能力写成 Skill，它就可以：

被别的 Agent 复用；
被同一个 Agent 在不同项目复用；
被团队评审、迭代、版本化。

2.2 可控：让结果稳定，过程可解释

“可控”不是指让模型不犯错，而是指：

你能明确它“应该按哪些步骤做”；
你能定位它“在哪一步偏了”；
你能以最小代价修复（改 Skill 的某个步骤/校验点），而不是重写整段提示词。

这其实就是把 Agent 从“玄学”拉回“工程”的核心手段。

2.3 降低上下文膨胀：按需注入，而不是永久塞进系统提示词

当你把所有经验都塞进系统提示词时，你会得到一个“看起来无所不能”的 Agent，但代价是：

上下文越来越大，模型注意力被稀释；
规则之间开始互相打架；
修改任何一处都可能引入连锁反应。

Skill 的思路是：默认轻装上阵，需要某项能力时再加载该能力的说明与约束。

2.4 团队协作视角：写 `Skill` 像写 `SOP`，用 `Skill` 像调用函数

当你把 Skill 当成团队资产后，很多工程问题会自然出现一套“正确做法”：

需要 review（否则每个人都会写出一套不兼容的输出格式）；
需要版本号（否则你不知道线上用的是哪一版）；
需要验收标准（否则你只是在写“更长的文字”）。

三、`Skill` 和 `MCP` 的区别

一句话概括：

Skill 解决“怎么做”：方法、流程、校验、产物。
MCP 解决“能做什么”：把外部工具/资源用标准协议接进来，让 Agent 可调用。

你可以把它理解成两层：

工具层（MCP）：提供可调用的 Tool / 可读取的 Resource / 可复用的 Prompt。
方法层（Skill）：把工具按某种可靠流程组织起来，形成稳定产物。

graph TD
    User[用户 User] -->|自然语言指令| Agent
    
    subgraph Agent Runtime
        SystemPrompt[System Prompt<br/>(人设、基础约束)]
        Router[决策/路由层]
    end
    
    Agent --> SystemPrompt
    SystemPrompt --> Router
    
    subgraph Skill Layer [Skill 层 (怎么做)]
        S_Write[写作 Skill<br/>(SOP、校验、格式)]
        S_Code[代码 Skill<br/>(重构、测试、Review)]
        S_Search[搜索 Skill<br/>(关键词优化、总结)]
    end
    
    Router -->|匹配场景| S_Write
    Router -->|匹配场景| S_Code
    
    subgraph MCP Layer [MCP 工具层 (能做什么)]
        T_File[文件读写 Tool]
        T_DB[数据库 Tool]
        T_Web[联网搜索 Tool]
    end
    
    S_Write -->|调用| T_File
    S_Code -->|调用| T_File
    S_Search -->|调用| T_Web

相关链接：

如果你想完整理解 MCP：AI/MCP 原理及 Java 开发指南.md

3.1 典型误区：把 `Skill` 当 `Tool`，或把 `MCP` 当工作流引擎

常见的两个走偏方式：

把 Skill 当 Tool：把 Skill 写成“调用某个接口的说明书”，最后得到的是一个脆弱的、只在某个项目里能跑通的流程。
把 MCP 当工作流引擎：以为“把工具接进来”就等于“事情能做好”，但缺少 Skill 的校验点与产物标准，最后输出仍然不可控。

真正的组合方式通常是：Skill 调用 MCP Tool。

3.2 一个直观类比：`Skill` 是“代码结构”，`MCP` 是“依赖注入”

如果把 Agent 当作一个软件系统：

MCP 更像依赖注入：我把数据库、文件系统、内网 API 这些能力“接进来”；
Skill 更像业务代码：我规定“什么时候查库”“什么时候读文件”“什么时候让用户确认”，并把产物结构固定下来。

再用一张图表达“谁依赖谁”会更直观：

flowchart TB
  subgraph L2[方法层：`Skill`]
    S1[Workflow / SOP<br/>步骤编排]
    S2[Contracts<br/>输入输出契约]
    S3[Checks<br/>验收与中断点]
    S2 --> S1
    S3 --> S1
  end

  subgraph L1[工具层：`MCP`]
    T1[Tool<br/>File/DB/API]
    T2[Resource<br/>Docs/KB]
    T3[Prompt<br/>模板/片段]
  end

  S1 --> T1
  S1 --> T2
  S1 --> T3

四、如何设计一个“好用”的 `Skill`

这一节更偏方法论：你不需要任何框架，也不需要先写代码，只要把它当成“写给未来自己的 SOP”。

4.1 先写 `Non-Goals`：不做什么，比做什么更重要

一个 Skill 最容易失控的地方是“贪多”。

建议在开头直接写清楚：

这个 Skill 不处理哪些情况；
这些情况应该交给哪个 Skill / 交给用户补充什么信息；
失败时允许的降级方案是什么。

这会显著减少 Agent 的“自作主张”。

4.2 再写校验点：每一步都可验证、可中断、可回退

好 Skill 的关键不是“步骤多”，而是“每步可验收”：

可验证：每一步输出都能用简单规则检查（格式、范围、关键字段齐全）。
可中断：发现不满足前置条件时，立即停下来问用户，而不是硬编。
可回退：如果某一步失败，有明确的替代路径（例如改用另一种数据源，或先输出 TODO 列表）。

这类“校验点”越明确，Agent 越像工程系统，而不是聊天机器人。

把 4.1～4.2 合起来，其实就是一个“从目标到验收”的设计流：

flowchart LR
  A[Goal 目标] --> B[Non-Goals 不做什么]
  B --> C[Inputs/Outputs 输入输出契约]
  C --> D[Steps 步骤编排]
  D --> E[Checks 校验点]
  E --> F[Failure Modes 失败处理]
  F --> G[Examples & Version 示例与版本化]

4.3 最后写触发条件：什么时候该用这个 `Skill`

一个 Skill 如果没有“触发条件”，最终会变成“每次都想用，但每次都要解释一遍”。

建议写成三段：

适用场景：满足哪些条件时，优先使用它。
不适用场景：哪些情况不要用。
快速自检：用户只要回答 2～3 个问题，你就能判断该不该启用。

4.4 一个可复用的 `Skill` 模板（推荐）

你可以把下面这个模板当成写 Skill 的骨架（放在 SKILL.md 里也好，放在内部文档里也好）：

Skill 名称：

目标（Goal）：

不做什么（Non-Goals）：

输入（Inputs）：
- 必填：
- 选填：

输出（Outputs）：
- 产物格式：
- 验收标准：

工具边界（Tooling Boundaries）：
- 允许调用：
- 禁止调用：
- 权限与安全要求：

执行步骤（Steps）：
1)
2)
3)

校验点（Checks）：
- Step 1 校验：
- Step 2 校验：

失败处理（Failure Modes）：
- 缺信息：
- 工具失败：
- 结果不可信：

4.5 实战案例：Java 代码审查 Skill

这是一个真实的 Skill 定义示例，你可以直接存为 .cursor/rules/java-review.mdc：

---
description: 当用户要求 Review Java 代码时触发
globs: *.java
---

# Java Code Review Skill

## 目标
找出代码中的 NPE 风险、并发问题及不符合阿里巴巴规范的命名。

## Non-Goals
- 不负责重写整个架构
- 不关注缩进和空格（交给 Formatter）

## 审查步骤 (Steps)
1. **安全性检查**：扫描所有入参，检查是否有 `@Nullable` 或未判空的使用。
2. **性能检查**：检查循环中是否有数据库调用或 RPC。
3. **规范检查**：对比变量命名是否符合驼峰，常量是否大写。

## 校验点 (Checkpoints)
- [ ] 每一个指出的问题必须引用具体行号。
- [ ] 每一个修改建议必须提供 `Before` 和 `After` 代码对比。

## 失败处理
- 如果代码依赖缺失导致无法判断类型，请输出 "⚠️ 缺少上下文，假设为..."

五、在 `Claude Code` 和 `Cursor` 上落地 `Skill`

这一节我会尽量给你“可操作”的路径，但不同产品对 Skill 的实现细节会随版本变化：文件放哪里、如何 reload，以你当前环境为准。

5.1 `Claude Code`：把 `Skill` 当成“可发现的能力包”

概念上，你可以把 Claude Code 的 Skill 当成一个目录（一个能力包）：

目录名：skill 的名字（也是它被发现/调用时的标识）
SKILL.md：这项能力的说明与执行规范（建议按上面的模板写）
其他文件：脚本、示例输入输出、测试用例（可选）

一个推荐的组织方式是把它们放进项目内的 skills/ 目录，形如：

your-repo/
  skills/
    blog-writer/
      SKILL.md
      examples/
        input.md
        output.md

当你需要启用某个 Skill 时，核心不是“神秘指令”，而是两件事：

让 Agent 知道这个 Skill 存在（可发现）
让 Agent 按 SKILL.md 的契约输出（可验收）

如果你用的是 Claude Code 自带的 Skill 管理/重载能力（有的版本会提供类似 /reload 的命令），建议把它当成“开发态便利功能”，而不是系统设计的前提：真正重要的是目录结构与契约文本本身。

5.2 `Cursor`：用 `.cursor/rules/*.mdc` 组织“类 `Skill`”

Cursor 当前更偏“Rules 驱动”：你把一套稳定做法写进 .cursor/rules/*.mdc，它就能在对话/改代码时持续遵循这套约束。

你仓库里已经有一个规则文件：.cursor/rules/yano-blog-writer.mdc，它本质上就是一个非常标准的“写作类 Skill”：

明确流程：先大纲，再正文（强制交互确认）
明确风格：中文与 English 空格、术语用反引号
明确自检清单：输出前过一遍

如果你要在 Cursor 里继续扩展 Skill，我建议的做法是：

一个 Skill 一个 .mdc 文件：命名体现用途（例如 agent-skill-design.mdc）
默认 alwaysApply: false：避免所有对话都被“规则污染”
需要长期生效时再开启：把 alwaysApply 改为 true，或把关键规则复制到当前任务上下文里

5.3 与 `MCP` 的配合：用 `.cursor/mcp.json` 把工具接入作为能力底座

如果你的 Skill 需要“调用外部能力”（读文件、查数据库、访问内网 API），那就让 MCP 来解决“接入工具”。示例：

{
  "mcpServers": {
    "local-dev": {
      "command": "java",
      "args": ["-jar", "mcp-server.jar"],
      "env": {
        "WORKSPACE_ROOT": "${workspaceFolder}"
      }
    }
  }
}

我更推荐的组合方式是：

Skill（规则/流程）写在 .cursor/rules/*.mdc 或 skills/*/SKILL.md
能力（工具/资源）通过 .cursor/mcp.json 接入
让 Skill 去“调用工具并验收产物”，而不是让工具去“替你决定做法”

5.4 `Skill` 的测试与调试

Skill 既然是工程化的，就必须可测试。建议的测试策略：

黄金数据集：保留一组 Input 和期望的 Output。
回归测试：当你修改 Skill 的步骤时，用上面的 Input 跑一遍，看 Output 格式是否崩坏。
调试技巧：在 Skill 中显式要求 Agent 输出 <thinking> 标签，打印它执行每一步时的决策过程。

六、结尾：`Skill` 的本质，是把“工作方法”产品化

我对 Skill 的最短总结是：

把“工作方法”写成可复用的能力单元，让 Agent 从“会聊”走向“会做”，从“能做”走向“稳定地做”。

如果你已经在写 Prompt、写 Rules、接 MCP 工具，那你其实已经走在 Skill 的路上了：接下来只差把它们“模块化、契约化、可验收化”。

相关链接：

Agent 基础：AI/Agent 原理.md

MCP 基础：AI/MCP 原理及 Java 开发指南.md

我的公众号

我的博客地址：博客主页。

coding 笔记、读书笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

Notion AI 初体验

Sat, 20 Dec 2025 00:00:00 +0800

Notion AI 初体验

前言

作为一个 Notion 的重度用户，一直心痒痒想体验一下 Notion AI。虽然它不像 ChatGPT 或 Claude 那样可以让你自由切换各种最新模型，但它最大的杀手锏在于：它就在你的笔记里，而且能读懂你的笔记、操作你的笔记。

最近试着用它来整理我的「书影清单」数据库，体验确实有点“回不去了”。不用在浏览器和 Notion 之间切来切去，这种沉浸式的自动化体验真的很爽。

我的书影清单

我一直在用 Notion 记录我的「书影清单」，包括阅读、观影、游戏等，目前已经积累了 294 条记录。入口在这里：博客主页。

Notion AI 的杀手锏

以前用外部 AI 工具时，最大的痛点就是上下文割裂：

我得先把页面内容复制出来
发给 AI，还要解释半天我的字段定义（什么是“状态”，评分是 10 分制还是 5 分制…）
拿到结果后再复制回 Notion

而 Notion AI 就像是一个住在工作区里的助理。它天生就知道你这个数据库里有哪些字段，也知道你过往的记录习惯。

实战一：一键统计与复盘

在 Notion AI 里，你可以直接选中一个数据库，让它帮你做分析。我试着让它对我的书影清单做个统计：

这种“统计 + 归纳”的场景非常适合懒人：

快速复盘：今年看了多少电影？最常看什么类型？
个性化推荐：从未完成清单里挑 5 个评分高的，按“轻松程度”排序。
内容输出：把一年的观影记录直接生成一篇 Markdown 格式的年终总结（连草稿都不用自己打）。
PS：我确实每年都要写观影总结，之前每次的年度观影总结基本要写 6h 以上，这次使用 Notion AI 看看能多长时间 0_o

实战二：懒人福音，自动补全字段

最近打算看《利刃出鞘 3》，我只在数据库里建了个标题，其他啥都没填。然后直接召唤 AI，让它帮我完善信息。

因为它知道我还没开始看，所以评分、阅读时间这些字段它会留空；而导演、主演、海报、豆瓣链接这些公开信息，它会自动联网搜索并补齐。

以前需要手动去豆瓣搜、复制、粘贴的步骤，现在一句话就搞定了。

进阶玩法：给 AI 写“员工手册”

Notion AI 的设置里有个 Instructions 功能，我觉得这才是长期使用的精髓。你可以把它理解为给 AI 写的“员工手册”。

比如可以专门建一个页面叫「书影清单录入规范」，写清楚：

评分标准是 1-10 分
没看过的电影评分留空
链接优先用豆瓣

然后把这个页面加到 Instructions 里。以后每次让 AI 干活，它都会先看一眼这个手册，输出的结果就非常稳定了。

顺便还能设置一下 AI 的语气和形象，挺好玩的。

碎碎念：关于限制和注意事项

Notion AI 的本质是什么？

是「嵌入在 Notion 里的通用文本 AI 助手」，并不是一个无限制的 ChatGPT。

简单说，它不是一个无限制陪聊的 ChatGPT，而是专门帮你打理 Notion 笔记的私人秘书。它能直接读懂你当前页面、甚至整个数据库的内容，帮你总结、润色、改写。这就比那些需要把内容“复制出去再粘贴回来”的外部 AI 强太多了。

关于次数限制：官方其实没给具体的数字，只说是个「合理使用机制」（Fair Use）。

总结

如果你也是 Notion 的重度用户，强烈建议试一下。

把死数据变活：不用导出 Excel 也能做各种花式统计。
极致的懒人体验：新增记录 + 补全字段 + 生成摘要，一气呵成。

即使是试用版，跑一遍自己的数据库、知识库笔记也能发现很多惊喜。安利！

我的公众号

我的博客地址：博客主页。

coding 笔记、读书笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

如何画好一张架构图

Sun, 14 Dec 2025 00:00:00 +0800

[toc]

架构

架构是什么？

有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

架构的本质

架构的本质是管理复杂性。

架构的基本出发点是为了效率，通过架构的合理切分，让效率最大化。

架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化。
架构的本质就是对系统进行有序化重构，以致符合当前业务的发展，并可以快速扩展。

权衡取舍

内外部需求
- 以改善软件质量为目的的内在结构性变化
- 以满足客户需求为目的的外在功能性变化
系统实现

架构要表达的是什么？

业务架构
应用/系统架构

建模

建模是什么？

为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

如何建模

建模图包括：

业务核心流程图
业务功能模块

如何做：

把文档读厚：大量的信息输入，同时探求可能性。常问自己：我是否已经具备了全局视野？
把文档读薄：归类汇总，形成大图。常问自己：边界是什么？输入输出是什么？

具体问题：

系统一定是给人用的，参与者是谁？
业务主要流程是什么？分支流程有哪些？
进一步归纳、演绎，抽象形成业务描述

建模的好处

业务共识：业务、产品、测试、研发大家讲一样的话，描述一样的事情
统一认识，减少沟通成本

系统建模

系统建模更强调职责，依赖，约束关系。

这张图为什么要这么画？层次如何划分？边界如何确定？

终极武器：所有的设计/逻辑模糊的点，将所有已知场景分别套入，自己讲给自己。

怎么画好架构图

套路

高内聚，低耦合。
每次从一个角度来切，然后换多个角度来审视。
通过组合、拆分来精化、优化模型与设计
关键审视点：
- 耦合性：减少模块间通信量（CTP搜索）
- 内聚性：功能单一化（租户/分销）
- 变化的隔离性：减少信息依赖，建隔离层、虚拟层
建模
- 业务建模，是从小到大，从局部到整体，自底向上的归纳、演绎的抽象过程
- 系统建模，是从大到小，从整体到局部，自顶向下的拆解、切分的抽象过程

架构图是架构在不同抽象层次的表达，是自然而然的过程。不是有图再有业务流程、系统设计和领域模型等

给谁看：

参与项目的各团队各角色（业务、产品、开发、测试、DevOps）
给项目之外的客户（IOC，北京奥组委，评审专家）
给老板（汇报，跨BU，跨团队协作沟通）

画架构图是为了什么？

解决沟通障碍
达成共识
减少歧义
团队内部和团队之间的协作、沟通、愿景和指导

抽象层次

按抽象层次分类：领域—>子域—>模块—>子模块一>包一>类—>方法

较低层次的抽象：应用内部包图、类图；某个领域：实体图、时序图、状态图、用例图等等；
更高层次的抽象：具有一定的复杂性，比如微服务架构，系统间的交互图，领域/子领域架构图，整个系统架构图

组成元素

架构图的组成元素？

方框、各种形状、虚实线、箭头、颜色（不同颜色代表什么意思）、文字
虚实线表达什么？组件类型，模块类型，层，服务，是否已经实现等？
箭头表达什么？数据流或关联关系？
交互类型可以是同步或异步的；关联类型有可能是指依赖、继承、实现
需要考虑内容术语一致性问题、碎片化问题、信息粒度大小的问题，以及图表的外观问题

如何评价架构图的好坏

内容术语一致、信息粒度大小一致，图例清晰，颜色类型统一，美观
图中的信息与相应的抽象级别相关，且满足利益相关者（合作方）的需求
一张好的架构图不需要多余的文字解释！受众有没有准确接收到想传递的信息
如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图
架构图应该帮助每个人看到大局，了解周围的环境，适当的上下文信息
架构图应该避免「只见树木，不见森林」

Agent 原理

Sun, 14 Dec 2025 00:00:00 +0800

Agent 原理

引言：从 ChatGPT 到 Agent

近几年，大模型（如 ChatGPT）已经很好用了：能聊天、能写代码、能总结资料。
但如果你仔细观察，会发现它仍然更像一个「超强的函数」而不是一个真正的「智能体」：

你给它一个提示（prompt），它给你一次性输出；
它不会主动拆解长任务，也不会自己决定「先查资料再算账、最后再写总结」；
它不会持久记住你的目标，也不会自行规划步骤或调用外部系统。

Agent（智能体），就是在大模型的基础上，加上目标、记忆、工具调用、环境交互和长期规划能力，让它从一个「问答机器」进化为一个能在复杂环境中自主完成任务的执行者。

agent-all-in-one 项目，就是一个用来演示各种 Agent 范式的教学/实验仓库：

ReAct 范式
Plan-and-Execute 范式
Supervisor Multi-Agent 范式
Reflection 范式

下面这篇文章，会围绕这几个问题展开：

Agent 是什么？
为什么需要 Agent？
Agent 的通用架构和运行循环是什么样？
Agent 都有哪些典型范式？agent-all-in-one 中各自对应什么实现？
Agent 相关有哪些经典论文/代表性工作值得一看？

一、什么是 Agent？

先给一个工程视角的定义：

Agent 是一个能够围绕给定目标，持续感知环境、做出决策、调用工具并更新自身状态的智能程序。

拆开看，一个典型的 LLM Agent 至少包含几个关键要素：

目标（Goal）
- 例如：「帮我规划 7 天日本旅行」「写一篇技术博客」「做一轮代码 Review」。
- 目标可以是一次性的，也可以被长期持有、拆解为子目标。
感知（Perception / Observation）
- Agent 需要感知外部世界：搜索结果、数据库查询、API 响应、用户的追加指令等。
- 在 agent-all-in-one 里，这就是工具返回值（Observation）。
记忆（Memory）
- 短期：本轮对话历史、当前任务上下文。
- 长期：过往项目、用户偏好、历史工具调用结果等（更高级的系统才有）。
推理与决策（Reasoning & Decision Making）
- 决定「下一步该干什么」：是继续问用户、调用搜索工具、还是直接给出答案？
- ReAct、Plan-and-Execute、Reflection 等范式，本质上都是在设计不同的决策流程。
行动（Action / Tool Use）
- 调用工具：搜索引擎、计算器、数据库、HTTP API、本地代码执行环境等。
- 在 agent-all-in-one 中，对应 search、calculator、get_current_time 等工具。
环境（Environment）
- 包括互联网、文件系统、业务系统、游戏世界（如 Minecraft）、机器人控制系统等。
- Agent 通过工具与环境交互，从环境中获得新的 Observation。

用一个简单的框图来表示：

flowchart LR
  U[用户 / 上层系统] -->|任务/指令| A[Agent]
  A -->|调用| T[工具 / API / 子系统]
  T -->|结果| A
  A -->|中间结果 / 最终答案| U
  A -->|读写| M[记忆 / 状态]

在 agent-all-in-one 里，Agent 本身往往被实现为一个「图（Graph）」，其中每个节点代表一个步骤（如 Planner、Executor、Supervisor、Worker、Reflector 等），这些节点一起实现了上图中的「感知 → 决策 → 行动 → 更新状态」循环。

二、为什么需要 Agent？

如果我们只用「普通 ChatGPT 模式」，会遇到几个典型问题：

无法可靠完成复杂多步骤任务
- 示例：「帮我调研 3 篇最新的 LangGraph 相关技术文章，提取要点，做一个对比表格」
- 这背后其实需要：搜索 → 逐篇阅读 → 提取关键信息 → 汇总成结构化结果 → 写总结。
- 单轮大模型回答，很容易「跳步骤」「幻觉」或遗漏细节。
缺乏与真实世界系统的连接
- 例如：「帮我查当前汇率，并按今天价格估个机票预算」
- 大模型本身看不到实时数据，一定要通过「工具」连接真实世界。
缺少可观测、可调试的执行流程
- 单次回答你很难知道：
  - 它有没有去查资料？
  - 它是怎么做中间推理的？
- Agent + 流程图（如 LangGraph）让整个过程变得可视化、可调试。
无法持续执行长任务
- 比如「帮我持续监控某股票的新闻，重要消息发通知」。
- 这类任务需要长期运行的 Loop，而不仅仅是一次性输出。

因此，Agent 的价值可以概括为：

从「大模型 = 强函数」升级到「大模型 = 可编排的智能子系统」；
让大模型能主动拆解任务、选择工具、调用环境，并在过程中自我修正；
让开发者可以像搭积木一样，将 ReAct / Plan-and-Execute / Multi-Agent / Reflection 等模式组合起来。

三、通用 Agent 架构与运行循环

无论是哪种范式（ReAct / Plan-and-Execute / 等），背后都有一个类似的「总循环」：

接收任务 → 解析任务 → 规划/决策下一步 → 行动（调用工具/子 Agent）→ 观察结果 → 更新状态与计划 → 判断是否结束。

可以用一个伪代码式的循环来描述：

while not done:
  1. 读取当前目标 + 状态 + 观察结果
  2. 大模型做推理（思考）：下一步该干什么？
  3. 得到决策：
     - 直接给出最终回答？ -> done = True
     - 调用某个工具？ -> 调用工具，获取新 Observation
     - 拆分为子任务？ -> 生成子计划 or 分配给其他 Agent
  4. 更新内部状态 / 记忆

简单的流程图示意：

flowchart TD
  S[开始: 接收用户任务] --> P[解析任务 / 理解意图]
  P --> D[决策: 下一步做什么?]
  D -->|调用工具| A1[执行 Action 工具调用]
  A1 --> O[观察 Observation]
  D -->|直接回答| R[生成最终回答]
  O --> U[更新状态 / 记忆]
  U --> D
  R --> E[结束]

在 agent-all-in-one 中，这个循环被用不同方式具体化：

react_agent/agent.py：在思考（Thought）— 行动（Action）— 观察（Observation）的循环中实现；
plan_execute_agent/：把「规划」「执行」拆到不同节点（Planner / Executor）；
multi_agent/graph.py：通过 Supervisor 调度不同 Worker，在图结构中走不同路径；
reflection_agent/：在 Generator ↔ Reflector 之间形成一个「改写—评价—再改写」的闭环。

四、Agent 常见范式总览

围绕 LLM 构造 Agent，目前比较常见的几类范式是：

ReAct 范式：
- Thought（思考） + Action（行动） + Observation（观察）循环。
- 适合工具有限、任务较短的场景。
Plan-and-Execute 范式：
- 先由 Planner 生成一个完整计划/任务分解，再由 Executor 逐步执行。
- 适合复杂、多步骤、可清晰拆解的任务。
Supervisor Multi-Agent 范式：
- 有一个负责「任务分配」的 Supervisor，底下挂多个专长不同的 Worker。
- 适合需要多技能并行协作的场景，如「搜索 + 计算 + 写作」。
Reflection 范式：
- Agent 会「审视自己之前的输出」，根据评审反馈做迭代改写。
- 适合对输出质量要求极高的任务，如技术文章、复杂分析报告。

agent-all-in-one 恰好分别实现了这四种范式，对应目录为：

react_agent/
plan_execute_agent/
multi_agent/
reflection_agent/

五、`agent-all-in-one` 中的四种典型 Agent 范式

5.1 ReAct 范式：推理 + 行动

核心思想：
把大模型的自然语言推理能力（Reasoning）和工具调用能力（Acting）交替结合起来，在「思考—行动—观察」的循环中逐步解决问题。

一个典型的 ReAct 交互日志大概是这样的（简化版）：

Question: 计算 123 * 456 等于多少？

Thought: 这是一个乘法计算，我应该调用计算器工具。
Action: calculator("123 * 456")
Observation: 56088

Thought: 已经得到结果，可以回答用户了。
Final Answer: 123 * 456 = 56088。

ReAct 的通用流程图：

sequenceDiagram
  participant U as 用户
  participant A as Agent (ReAct)
  participant T as 工具

  U->>A: 问题/任务
  loop Thought-Action-Observation
    A->>A: Thought: 推理下一步
    A->>T: Action: 调用工具
    T-->>A: Observation: 工具结果
  end
  A-->>U: Final Answer

在 agent-all-in-one 中：

实现位置：react_agent/agent.py
工具定义：react_agent/tools.py
特点：
- 实现简单、灵活；
- 把中间推理过程暴露为可观察的「Thought」文本，很好调试；
- 更适合「一次性问题」或「工具数量不太多」的场景。

5.2 Plan-and-Execute 范式：先规划，再执行

当任务很复杂时，直接用 ReAct 可能会「想到哪做到哪」，缺乏全局视角。
Plan-and-Execute 范式把整个过程拆为两层：

Planner（规划器）：一次性生成一个较完整的任务计划；
Executor（执行器）：顺着计划一步步执行，每一步内部可以再用 ReAct/工具等。

示意流程：

flowchart TD
  U[用户任务] --> P[Planner: 生成计划 Step 1..N]
  P --> E[Executor: 逐步执行每个 Step]
  E --> R[执行结果 & 总结]
  R --> U2[返回给用户]

一个典型例子：

用户任务：帮我规划一次去日本的 7 天旅行，包括：
  - 机票预估预算
  - 每天的城市安排
  - 必去景点和大致价格区间

Planner 可能生成类似的计划：
  Step 1: 通过搜索获取从用户城市飞往东京/大阪的往返机票平均价格
  Step 2: 估算 7 天的住宿预算，按中档酒店标准
  Step 3: 设计 Day 1-7 的城市和景点安排
  Step 4: 输出包含预算和行程表的总结文档

Executor 按 Step 1 -> 2 -> 3 -> 4 顺序执行，每一步都可以用工具/子 Agent。

在 agent-all-in-one 中：

规划相关代码：plan_execute_agent/planner.py
执行相关代码：plan_execute_agent/executor.py
Agent 入口：plan_execute_agent/agent.py
适用场景：
- 长任务、结构比较清晰的任务（旅行规划、项目 Roadmap 设计、调研报告等）；
- 需要先看整体再细化的情况；
- 便于在 LangGraph Studio 中可视化：你能看到 Planner 节点出一个计划，Executor 节点按计划一步步跑。

5.3 Supervisor Multi-Agent 范式：多智能体协作

有些任务「内含多种技能」，比如：

「搜索今天的天气，计算 256 * 789，然后写一份总结。」

如果全部交给一个 Agent 来做，它当然也能完成，但会变得「又要查资料，又要算，又要写」，逻辑混杂。
多智能体范式把不同职责拆开，让多个专长不同的 Agent 协同工作，由一个上层 Supervisor 负责调度。

在 agent-all-in-one 中，多智能体结构大致是：

Supervisor（主管）：
- 在 multi_agent/supervisor.py
- 负责理解全局任务，决定「什么时候让哪个 Worker 出场」。
Workers（工作者）：在 multi_agent/workers.py 中定义，例如：
- Researcher：使用搜索工具获取信息；
- Calculator：负责准确计算（数学/逻辑计算）；
- Writer：负责用自然语言输出总结/报告。

可以画成这样的结构：

flowchart TD
  U[用户任务] --> S[Supervisor]
  S --> R[Worker: Researcher]
  S --> C[Worker: Calculator]
  S --> W[Worker: Writer]
  R --> S
  C --> S
  W --> S
  S --> U2[最终回答]

一个典型的执行流程可能是：

用户给出复合任务（搜索 + 计算 + 写作）
Supervisor 分析任务，先调用 Researcher 搜集事实
Researcher 用 search 工具查资料，返回 Observation
Supervisor 根据 Observation 调用 Calculator 完成数值计算
最后 Supervisor 把数据交给 Writer 生成自然语言总结
返回综合结果给用户

这种范式的优点：

职责清晰：每个 Worker 专精一类任务，更易于调试和扩展；
容易并行化：多个 Worker 可以并行执行子任务；
贴合现实团队协作：Supervisor 就像项目经理，Workers 像不同专业的工程师。

5.4 Reflection 范式：反思与自我改进

当你希望 Agent 产出高质量内容（比如技术文章、方案设计、代码优化建议），一次性输出往往不够。
Reflection 范式的核心，是让 Agent 拥有「自我审阅、反思并改写」的能力。

在 agent-all-in-one 中，典型角色和流程：

Generator（生成器）：reflection_agent/generator.py
- 根据任务和历史反馈，生成当前版本的答案。
Reflector（反思器）：reflection_agent/reflector.py
- 给当前答案做 Review：指出问题、不足、改进方向。
- 反馈可以从多个维度考虑：准确性、完整性、清晰度、结构等。
迭代闭环：

flowchart TD
  U[任务说明] --> G[Generator: 生成答案 V1]
  G --> R[Reflector: 评审 V1, 给出改进建议]
  R --> G2[Generator: 生成答案 V2]
  G2 --> R2[Reflector: 再次评审]
  R2 -->|直到质量合格或达到最大轮数| F[最终答案]

一个简单例子（写技术文章）：

Round 1:
  Generator 输出一篇「LangGraph 简介」文章
  Reflector 评审：指出缺少使用示例、对比传统流程编排方式、没有提到可视化调试

Round 2:
  Generator 根据反馈扩展：加入代码示例、小项目 demo、图示
  Reflector 再次评审：结构有点松散，可以重构为「概念 -> 使用 -> 示例 -> 总结」

Round 3:
  Generator 重构结构，增加小结和实践建议
  Reflector 认为已达到质量要求 -> 输出最终稿

优点：

易于反复打磨输出质量，尤其适合：技术博客、API 文档、系统设计说明；
天然适配「人类在回路中」的场景：Reflector 也可以是人，而不是模型；
在 LangGraph Studio 中，你能看到每一轮 Generator / Reflector 的中间版本，非常利于调试。

六、Agent 相关经典论文 / 代表性工作

下面按主题列出一些与 Agent、工具增强 LLM、多智能体协作相关的经典或代表性工作，你可以根据兴趣和需要选择阅读。

6.1 工具增强与推理（Tool-augmented Reasoning）

ReAct: Synergizing Reasoning and Acting in Language Models
Yao et al., 2022
- 提出了 ReAct 范式：将「自然语言推理（Thought）」与「行动（Action）」交替结合，用于工具调用和环境交互。
- 对应 agent-all-in-one 中的 react_agent/ 实现。
Toolformer: Language Models Can Teach Themselves to Use Tools
Schick et al., 2023
- 研究如何让大模型通过自监督方式，在预训练阶段就「学会插入合适的工具调用」，而不是只在推理阶段硬编码；
- 更偏向「模型训练策略」，但对实际 Agent 设计有启发：工具调用可以是训练出来的模式，而不是完全手工 Prompt。
PAL: Program-Aided Language Models
Chen et al., 2022
- 提出让模型生成可执行代码片段（如 Python）来完成复杂推理任务，再执行代码获得结果；
- 在 Agent 语境下，可以看作是「把工具 = 代码执行环境」，通过代码而不是纯文本进行严谨推理。
Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
Wei et al., 2022
- 不直接讲 Agent，但给出了让模型显式写出中间推理步骤（思维链）的技巧；
- ReAct 可以看作是在 CoT 基础上，再接了一层「工具行动」。

6.2 反思与自我改进（Reflection / Self-Refine）

Reflexion: Language Agents with Verbal Reinforcement Learning
Shinn et al., 2023
- 倡导让 Agent 对自己的行为结果做「语言化反思」，并利用反思来改进后续策略；
- 与 agent-all-in-one 中的 Reflection 范式高度契合：Generator + Reflector 的闭环。
Self-Refine: Iterative Refinement with Self-Feedback
Madaan et al., 2023
- 让模型对自己的回答生成反馈（例如指出模糊、不准确之处），再根据反馈改写答案；
- 对写作、代码生成、翻译等任务非常实用，是很多 Reflection 型 Agent 的灵感来源。

6.3 规划、搜索与决策（Planning / Search）

Tree of Thoughts: Deliberate Problem Solving with Large Language Models
Yao et al., 2023
- 把大模型的推理过程看作在「思维树」上进行搜索，而不是一条线性的思维链；
- 为更复杂的规划型 Agent 提供了搜索框架：可以保留多条候选思路，做回溯和评估。
Plan-and-Solve Prompting（可查阅相关工作）
- 思想与 Plan-and-Execute 很接近：先让模型显式写出计划，再按计划解决任务；
- 在 agent-all-in-one 中，plan_execute_agent/ 其实就是这种思想的工程化实现。

6.4 多智能体与长期任务（Multi-Agent / Long-horizon Agents）

Voyager: An Open-Ended Embodied Agent with Large Language Models
Wang et al., 2023
- 在 Minecraft 环境中构建了一个「会自己探索、记忆、学习技能」的长期 Agent；
- 关键点在于：技能库（技能程序的记忆）、长期目标、与环境的持续交互。
- 对于理解「真正意义上的 Agent（不仅是 QA 机器人）」非常有启发。
Auto-GPT / BabyAGI 等开源项目（虽然不都是论文）
- 把 LLM 装上「目标管理、任务分解、任务队列、执行器、记忆」等模块，形成较完整的 Agent 系统；
- 是许多工程实践中「多轮自动执行、反复调用工具」范式的早期样板。

七、如何选择和实践这些 Agent 范式？

结合 agent-all-in-one，可以给出一个简单的「学习和实践路径」：

从 ReAct 入门
- 先理解 Thought / Action / Observation 循环；
- 在 react_agent/ 中观察：
  - 模型是如何决定「该用哪个工具」的？
  - 工具输入/输出是如何以文本形式被包装起来的？
向 Plan-and-Execute 过渡
- 在 plan_execute_agent/ 里理解 Planner / Executor 拆分后的好处：
  - Planner 只考虑「做什么」和「顺序」；
  - Executor 只负责「一步步把事情做完」。
- 在 LangGraph Studio 中查看这两类节点的执行路径。
尝试 Multi-Agent 协作
- 打开 multi_agent/graph.py 和 workers.py，看看：
  - Supervisor 是根据什么信息决定调用哪个 Worker？
  - Worker 之间有没有共享状态 / 记忆？
- 尝试给系统增加一个新 Worker（比如「翻译专家」），体会可扩展性。
最后玩转 Reflection 范式
- 在 reflection_agent/ 中观察 Generator 和 Reflector 的反复交互；
- 尝试调高/调低「迭代轮数」，看看输出质量和时间的权衡；
- 把你正在写的技术文章交给这个 Agent 打磨试试。

小结

Agent 是什么：在大模型之上，加入目标、记忆、工具和环境交互的「智能执行体」。
为什么需要 Agent：为了解决复杂任务、多工具协同、长时运行以及可观测调试的问题。
常见范式：ReAct、Plan-and-Execute、Supervisor Multi-Agent、Reflection 等，各有适用场景。
agent-all-in-one 的价值：它把这些范式都做了一个最小但完整的工程实现，配合 LangGraph Studio，可以清楚看到 Agent 的内部思考和工具调用链路，非常适合作为你在笔记库《Agent 原理》中的「理论 + 实战」桥梁。

AI 论文资料

Sun, 14 Dec 2025 00:00:00 +0800

Attention Is All You Need

英文原版：Attention Is All You Need.pdf

The Illustrated Transformer

ChatGPT 5.1 Thinking 的两个案例

Sat, 13 Dec 2025 00:00:00 +0800

ChatGPT 5.1 Thinking 的两个案例

AI 统治人类的时间不远了。

案例 1：根据我的 RSS 订阅，推荐高质量 RSS 源

1.0 我的原始问题

我的原始问题是：

先探讨信息输入源的问题，我现在是通过 RSS 订阅，现在订阅的如图。针对我现在关注的这些，帮我找一些高质量的 RSS 源，我可以直接加入订阅的。

我当前订阅非常“克制”，大概是这几类：

虹线、虹线周刊
阮一峰的网络日志
少数派
Computing Life

换句话说，我要的不是“再来一堆信息”，而是 同品类里更优质、更稳定的输入源。

1.1 它先猜你喜欢什么（而不是立刻开始堆链接）

它先根据我的订阅推断偏好，明确我关注的是：

科技与互联网观察
编程与工程师视角
数字生活与效率工具
独立博客（相对少大门户、少噪音）

这一步很关键：推荐这事儿，最怕答非所问。

1.2 它会自己“立规矩”：别太多、要好用

它不断强调两件事：

别推荐太多：控制在 15–20 个左右，避免信息过载
答案要能直接用：除了链接列表，还考虑给你表格、甚至 OPML 片段，方便一键导入阅读器

我挺喜欢这点：它不是在“展示能力”，而是在帮你把事情做完。

1.3 RSS 最容易翻车的地方：它选择不瞎猜

RSS 推荐最容易翻车的地方是什么？不是“站点推荐得不对”，而是“RSS 链接猜错了”，你一导入就 404。

而在思考过程里，它多次出现这种判断（核心意思就是：不确定就别猜）：

由于截断问题，我不想直接提供这个链接，以免出现 404 错误。可以建议用户从首页点击 “RSS” 链接，而不是 guessing。

搜索没有显示 sugarat 的 RSS 路径，因此我不会做猜测……

1.4 输出答案：给到“能导入”的程度

在经过 8m 16s 的思考后，它给出了答案：

案例 2：系统性列出中国历史书籍

第二个问题更典型：

我对中国的历史感兴趣，帮我系统性列举一些书籍。

2.1 它先给“怎么读”，再给“读什么”

它的思路挺清晰：

先把书单分层：通史入门、断代史、专题史、思想/制度/文明、近现代、海外汉学视角、史学方法
再控制数量：大约 25 本左右，覆盖面够但不失控
最后给阅读顺序建议：从“鸟瞰”到“切片”再到“方法论”

这比“给你 100 本书”强多了，因为你拿到的是一条路，而不是一堆名字。

2.2 它会自己做取舍：别太学术，也别太水

在思考过程中，它不断权衡：

书要“经典权威”，但也要“读得下去”
需要覆盖关键转折点（例如制度结构、明清转型、走向现代）
还要补上史学方法书（告诉你怎么读史、怎么判断材料）

这说明它不是在“罗列”，而是在帮你把学习节奏安排好。

2.3 思考过程摘录（节选）

同样摘几段最能体现其思路的片段（原文节选）：

用户喜欢结构化列表，我会按时间顺序及书籍层次/用途分类

先通史概览，再关键断代，再制度/思想/文化，再外部视角与史学方法

控制总量约 25–27 本，避免过多但保证覆盖

给出阅读顺序建议，让书单变成路径

2.4 输出答案

在经过 6m 3s 的思考后，它给出了答案：

我的公众号

我的博客地址：博客主页。

coding 笔记、读书笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

在手机上也能玩到硬核卡牌 RPG：《Dawncaster》安利

Sun, 07 Dec 2025 00:00:00 +0800

一款真正为移动端设计的地牢式构筑卡牌 RPG。

这段时间，我在通勤、排队、睡前的零碎时间里，几乎都在刷《Dawncaster》。作为一个玩了多年构筑卡牌的老玩家，我会把它放进「手机上最值得一买」的那一小撮游戏里——一次买断，干净、纯粹、极度耐玩。

适合谁 / 不适合谁

适合：

想在手机上玩到「一次买断、没有体力和抽卡」的卡牌 RPG 玩家
喜欢《杀戮尖塔》《怪物火车》一类构筑卡牌，但又想要更强世界观和探索感的玩家
能接受基础英文阅读（但不需要特别专业）的玩家
喜欢研究卡组和流派、享受被游戏「教育」的硬核玩家

可能不太合适：

希望免费游玩、靠广告或日常任务慢慢养成的玩家
更喜欢自动战斗、放置挂机的轻度体验
对「经常输、不断重开」这件事非常介意的玩家

一、这是一款什么游戏？

《Dawncaster: Deckbuilding RPG》是一款付费买断制的 Roguelike 构筑卡牌 + 地牢 RPG，平台覆盖 iOS / Android，其中 iOS 版支持 iPhone / iPad。

简单来说，它就是 “能装在口袋里的杀戮尖塔”。

它的玩法核心类似「杀戮尖塔 + 桌游式跑团」，每一局都是全新的地牢旅程：

用卡牌打怪、推进剧情
在地图上走格子，遭遇战斗、事件、商店、精英怪或营火休息
过程中不断获取新卡、升级旧卡、移除废卡，堆叠各种 buff，组合出自己的流派

为什么我这么想安利它？

付费模式：一次性买断（约 4.99 美元），后续 DLC（新职业、新地图）单独卖。没有广告，没有体力限制，没有逼氪，打开就能玩。
纯粹体验：在这个充斥着“每日任务”和“十连抽”的手游时代，能遇到这样一款干净、纯粹、好玩的单机游戏，真的太难得了。
口碑炸裂：美区 App Store 里长期保持高分好评，评论区基本都是夸它耐玩、良心买断的玩家。
语言门槛：虽然只有英文界面，但卡牌描述很规范，关键词长按就有解释。作为一个卡牌老手，这根本不是障碍！

顺带把几个基础信息放在这里，方便你快速判断要不要入：

售价：本体买断价格大约 4.99 美元（不同区略有差异），折合人民币三十元左右，以各区商店标价为准。
付费模式：买断制本体 + 可选 DLC 扩展，没有体力条、抽卡池之类的设计，内购内容主要是新职业、新地图等实质扩展。
存档与进度：iOS 版支持 iCloud 云存档，可以在多台设备之间同步进度；Android 版的存档机制以商店说明和游戏内设置为准。
更新情况：目前仍在持续更新中，不定期加入职业平衡调整、新卡牌和新地图。

二、如何购买？（写给国区玩家）

目前中国大陆区 App Store 暂时搜索不到《Dawncaster》，但好游戏值得折腾一下！游戏在美区、港区、英区等常见外区都可以正常购买和下载。

如果你是 iOS 玩家，通常的做法是：

使用外区 Apple ID：注册一个美区或港区账号，在 App Store 中切换账号后购买。
礼品卡充值：通过正规渠道购买对应区域的礼品卡充值余额。
家庭共享：找个有账号的朋友开个家庭共享（强烈推荐这个，一人买全家玩）。

注：外区账号涉及到地区和支付方式的问题，感兴趣的朋友可以自行搜索相关教程，这里不再赘述。

如果你懒得自己搜索，可以直接用下面这两个链接：

iOS：Dawncaster: Deckbuilding RPG 的 App Store 页面见这里
Android / 其他平台：可以通过官方站点 Dawncaster 官网查看当前可用的版本与下载渠道。

三、世界观与美术：暗黑但不脏乱

游戏背景设定在一个被恶魔侵蚀的黑暗奇幻世界，你扮演一名寻找失踪传奇英雄“黎明使者”的冒险者，一路深入腐化之地，揭开背后的真相。

美术风格真的赞：

手绘暗黑风：整体色调偏暗，但线条干净、配色明确，长时间游玩也不会觉得视觉疲劳。
精致的 UI 质感：金属边框配合暖色光晕，加上卡牌打出时的音效和震动，每一次出牌都像在摔出一张实体卡，那种厚重感真的绝了。
立绘厚重：怪物和 Boss 的设计很有压迫感，配合技能特效，战斗反馈十足。
音乐与音效：背景音乐是偏克制的暗黑氛围，不会一直在你耳边吵闹；关键操作（出牌、打出暴击、Boss 登场）配合清晰的音效和震动反馈，既有「桌面卡牌」那种实在感，又不至于干扰你思考出牌顺序。

四、核心玩法：构筑卡组，征服地牢

1. 经典的 Roguelike 循环

一次完整的冒险大致遵循这样的流程：

选择职业与初始卡组
在地图上「走格子」选择路线
战斗胜利后获取战利品（新卡、金币、升级机会）
遇到随机事件：在此你可以赌运气、交换装备或调整天赋
最终挑战区域 Boss——失败重来，胜利则前往下一层

虽然结构看起来眼熟，但《Dawncaster》引入了武器附魔、复杂的能量系统和职业混搭机制，让每一次构筑都有很大区别。

2. 独特的能量与资源设计

这游戏不像炉石那样只有“法力值”。它有怒气、圣光、暗影、奥术好几种能量。

很多时候你要做的是“资源转化”：比如卖血换怒气，或者把蓝换成暗影。这种在钢丝上跳舞的感觉，比单纯的“按费拍怪”刺激多了。

资源转化：很多卡牌的核心用法是转化资源，例如“消耗生命值获得怒气”、“消耗蓝色法力转化为暗影能量”。
连招机制：有些流派不靠单卡质量，而是靠疯狂的资源循环打出无限连击。

五、职业与构筑：随身携带的卡组实验室

游戏目前提供多个职业（Warrior, Rogue, Hunter, Arcanist, Seeker 等），每个职业都有独立的卡池与天赋树。

比较有意思的几点：

职业混搭（Cross-class）：你在一个职业的冒险中也有机会获得其他职业的卡牌，这让“拿着大剑施放火球”成为可能。
海量卡池：卡牌总量超过 900 张，构筑空间极深。
解锁要素：每次跑图结束（无论通关与否）都会根据评分解锁新的起始卡、头像或挑战难度。

推荐几个爽快的流派体验：

流血战士：疯狂堆叠流血层数，看着 Boss 每回合自动掉血，最后用倍率卡一刀带走。
埋雷贼：在敌人的牌库里塞满“炸弹”，对方抽牌即炸，兵不血刃。优雅！
无限法师：通过减费和抽牌手段，达成单回合无限出牌。虽然手有点累，但看着 Boss 连动都动不了就被轰成渣，这感觉太爽了。

新手推荐：从这里开始玩

如果你是第一次接触构筑卡牌，或者只是偶尔玩过《杀戮尖塔》，可以先从几套容错率更高的思路入手：

耐打型战士（流血 + 护甲）：优先拿能叠护甲、回复生命的牌，其次再慢慢补充施加流血、按层数结算伤害的牌。看到特别贵、特别花里胡哨的 Combo 卡，前期可以先冷静跳过，保证自己「活得久」永远是第一位。
稳健法师（减费 + 抽牌）：以稳定过牌、慢慢堆叠少数几张核心输出卡为主，不必一开始就追求无限连。优先拿「过牌 + 抽 1～2 张」「降低指定卡牌费用」这类牌，看到需要大量特定能量、条件极多的 Combo 卡可以先无视。

一些对新手实用的小建议：

前几局可以刻意保持牌组不那么「花」，同类效果少而精，方便你感受每张牌的价值。
能移除「废卡」（例如基础攻击 / 防御）的时候尽量移除，这游戏的节奏非常看重抽牌质量。
不要害怕失败——每一次翻车基本都能换来新解锁，顺便帮你理解这个职业真正擅长什么。

六、为什么说它特别适合手机玩家？

这是我最想安利它的理由——《Dawncaster》不是简单地从 PC 移植过来的游戏，而是一开始就按 Mobile Cardventure（移动端卡牌冒险）设计的。它太懂手机玩家想要什么了！

1. 竖屏 + 单手操作，地铁神器！

游戏采用竖屏 UI，卡牌都在屏幕下方区域，单手拇指即可完成出牌、查看状态和结束回合。早晚高峰在地铁上挤成沙丁鱼？没事，只要腾出一只手，你就能在地牢里大杀特杀。这体验真的比那些需要双手捧着、还得精准点击小按钮的游戏好太多了。

2. 碎片化时间的“杀手”

节奏紧凑：单场战斗节奏紧凑，通常几分钟解决战斗。
无缝继续：随时可以暂停退出，下次打开无缝继续。
离线游玩：支持离线游玩，飞机上、高铁上信号不好也能玩得开心。

3. 优秀的可读性

虽然屏幕小，但卡牌字号足够大，关键词有清晰的下划线，长按即可查看详细解释。游戏还在苹果无障碍社区获奖，对 VoiceOver 的支持非常完善，细节打磨可见一斑。

如果你在手机上只想要一款真正意义上的「单机卡牌 RPG」，而不是又一个带体力、抽卡和每日任务的手游，《Dawncaster》绝对值得常驻你的手机。

4. 性能、续航与云存档体验

发热与耗电：整体以 2D 卡牌界面为主，战斗特效比较克制，发热和电量消耗大致在中等水平，不会像大型 3D 游戏那样明显烤手。
云存档与多设备：iOS 版支持通过 iCloud 同步存档（在系统设置里可以单独开关 Dawncaster 的 iCloud 使用），iPhone 和 iPad 之间切换非常顺畅；Android 端则以平台说明和游戏内设置为准。
平板适配：在 iPad 上依然采用竖屏布局，可视区域更大、信息密度更高，阅读卡牌和浏览地图都会更舒服。

七、优缺点总结

优点：

玩法扎实：深度构筑，耐玩性极高。
良心买断：无广告，无氪金坑，DLC 也是实打实的内容扩展。
移动体验极佳：竖屏单手，随时随地都能开一把。

门槛：

购买门槛：需要外区账号（iOS）。
语言门槛：全英文 UI，对英文完全苦手的玩家可能体验受限。
硬核难度：这不是一款无脑爽游，高难度下非常考验卡组构建和出牌顺序，容易“翻车”。

八、结语

在当下这个几乎所有手游都绑着「体力条 + 抽卡池」的时代，能遇到《Dawncaster》这样一款干净、纯粹、好玩的游戏，真的很难得。

它就像是一个沉默寡言但内功深厚的老朋友，随时待在你的口袋里。当你想要一段属于自己的、哪怕只有 10 分钟的冒险时光时，它永远在那里等着你。

如果你手机上只能留一款付费卡牌 RPG，我大概率会选它。

如果你已经心动：

iOS 玩家：可以在美区 / 港区 App Store 搜索 Dawncaster: Deckbuilding RPG，或直接通过 App Store 链接购买下载。
Android 玩家：可以前往官方站点查看当前可用的下载渠道（Google Play / 直链等可能因地区而异）。

如果你也是卡牌游戏爱好者，信我，买它！绝对不亏！

我的公众号

我的博客地址：博客主页。

coding 笔记、读书笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

JDK 25 新特性解析

Tue, 11 Nov 2025 00:00:00 +0800

前言

JDK 25 是 Java SE 平台版本 25 的参考实现，预计 2025 年 9 月正式发布。本文将详细解析 JDK 25 的主要新特性。

新特性总览

JEP	特性名称	状态	说明
455	原始类型模式（第二次预览）	预览	增强模式匹配，支持在所有模式上下文中使用原始类型
466	类文件 API	正式发布	提供用于解析、生成和转换 Java 类文件的标准 API
472	为语句准备	预览	引入新的语句形式，允许在条件语句前执行准备操作
475	延迟初始化类	预览	延迟类的初始化，提升应用启动性能
476	模块导入声明	第二次预览	简化模块导入，允许一次性导入整个模块
477	隐式声明的类和实例主方法	正式发布	简化初学者编程体验，无需显式类声明
479	灵活的构造函数体	正式发布	允许在 super() 调用前执行语句
480	结构化并发	正式发布	简化并发编程，将相关任务视为单个工作单元
481	作用域值	正式发布	提供线程内和线程间共享不可变数据的机制
484	类文件 API 增强	预览	增强类文件 API，支持更多字节码操作

详细解析

JEP 455：原始类型模式（第二次预览）

JEP 455（第二次预览）继续增强 Java 的模式匹配功能，允许在所有模式上下文中使用原始类型，并扩展 instanceof 和 switch 以支持所有原始类型。

为什么要引入这个功能：

在 JDK 23 中首次引入后，根据社区反馈进行了改进。原始类型模式匹配使得 Java 语言在处理不同类型时更加统一，减少了类型转换的复杂性，提高了代码的可读性和类型安全性。

目标：

统一类型处理：允许对所有类型（原始类型和引用类型）使用一致的模式匹配语法
增强 switch 表达能力：使 switch 能够更自然地处理原始类型
减少样板代码：消除不必要的装箱和类型转换

简要使用示例：

在 switch 中使用原始类型模式：

int processValue(Object obj) {
    return switch (obj) {
        case Integer i when i > 0 -> i * 2;
        case Long l -> (int) (l / 2);
        case Double d -> d.intValue();
        case int i -> i;  // 原始类型模式
        default -> 0;
    };
}

instanceof 与原始类型：

Object value = getNumberFromDatabase();
if (value instanceof int i && i > 100) {
    System.out.println("Large integer: " + i);
}

JEP 466：类文件 API（正式发布）

JEP 466 在经过多次预览后正式发布，提供了一个标准的、与 JDK 同步更新的类文件处理 API。

为什么要引入这个功能：

随着 JDK 快速迭代，类文件格式不断演进。第三方库（如 ASM、BCEL）可能无法及时跟进，导致兼容性问题。提供官方标准 API 可以确保与最新 JDK 版本的完美兼容。

目标：

提供标准化 API：与 Java 虚拟机规范保持一致
简化 JDK 内部依赖：使 JDK 组件能够使用统一的类文件处理方式
提高可维护性：减少对第三方库的依赖

简要使用示例：

解析类文件：

import java.lang.classfile.*;

Path path = Path.of("MyClass.class");
ClassModel classModel = ClassFile.of().parse(path);

// 遍历类成员
for (ClassElement element : classModel) {
    if (element instanceof MethodModel method) {
        System.out.println("Method: " + method.methodName());
    }
}

转换类文件：

ClassTransform transform = ClassTransform.transformingMethodBodies(
    (codeBuilder, codeElement) -> {
        // 自定义字节码转换逻辑
        codeBuilder.with(codeElement);
    }
);

byte[] transformed = ClassFile.of().transformClass(classModel, transform);

JEP 472：为语句准备（预览）

JEP 472 引入了一种新的语句形式，允许在条件语句执行前进行必要的准备操作，使代码更加简洁和可读。

为什么要引入这个功能：

在实际开发中，我们经常需要在条件判断前进行一些准备工作，如资源获取、变量计算等。现有的语法要求将这些准备代码与条件判断分离，降低了代码的可读性和局部性。

目标：

提高代码可读性：将准备代码与使用代码放在一起
减少作用域污染：准备过程中的变量只在需要的范围内可见
简化常见模式：如资源获取后立即使用的场景

简要使用示例：

// 传统写法
String line = reader.readLine();
if (line != null) {
    process(line);
}

// 使用 prepare 语句
if (String line = reader.readLine(); line != null) {
    process(line);
}

// 在 switch 中使用
switch (String input = scanner.nextLine(); input.toLowerCase()) {
    case "yes" -> System.out.println("确认");
    case "no" -> System.out.println("取消");
    default -> System.out.println("未知输入: " + input);
}

JEP 475：延迟初始化类（预览）

JEP 475 引入了延迟初始化类的机制，允许类的初始化延迟到真正需要时才执行，从而提升应用启动性能。

为什么要引入这个功能：

Java 应用启动时需要加载和初始化大量类，这些类的静态初始化代码会显著影响启动时间。特别是在云原生和 serverless 环境中，快速启动至关重要。通过延迟不必要的类初始化，可以显著减少启动时间。

目标：

提升启动性能：延迟非关键类的初始化
减少内存占用：避免加载不会被使用的类
保持语义一致性：确保延迟初始化不影响程序正确性

简要使用示例：

// 使用 lazy 关键字标记延迟初始化的类
public lazy class HeavyResource {
    static {
        // 这段代码只在首次使用 HeavyResource 时执行
        System.out.println("Initializing HeavyResource...");
        // 执行耗时的初始化操作
    }
    
    public static void doWork() {
        System.out.println("Working...");
    }
}

// 主程序
public class Main {
    public static void main(String[] args) {
        System.out.println("Application started");
        // HeavyResource 尚未初始化
        
        if (someCondition()) {
            // 只有在这里才会触发 HeavyResource 的初始化
            HeavyResource.doWork();
        }
    }
}

JEP 476：模块导入声明（第二次预览）

JEP 476（第二次预览）继续完善模块导入功能，根据第一次预览的反馈进行了优化。

为什么要引入这个功能：

Java 模块系统引入后，使用模块化库需要导入多个包，增加了样板代码。模块导入声明允许一次性导入整个模块的所有导出包，简化了代码。

目标：

简化导入语句：用一条语句替代多条包导入
提高可维护性：当模块添加新的导出包时，无需修改导入语句
降低学习曲线：初学者无需了解模块内部的包结构

简要使用示例：

// 传统导入方式
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import javax.sql.DataSource;

// 使用模块导入
import module java.sql;

public class DatabaseExample {
    public void connect() throws SQLException {
        // 可以直接使用 java.sql 模块导出的所有类型
        Connection conn = DriverManager.getConnection("jdbc:...");
        DataSource ds = ...;
    }
}

JEP 477：隐式声明的类和实例主方法（正式发布）

JEP 477 在经过三次预览后正式发布，极大简化了 Java 初学者的学习曲线。

为什么要引入这个功能：

传统的 Java “Hello World” 程序需要理解类、静态方法、数组等多个概念，对初学者不够友好。通过允许隐式类声明和简化的 main 方法，降低了入门门槛。

目标：

降低学习门槛：使初学者能够专注于编程逻辑而非语言特性
简化小型程序：减少脚本和工具程序的样板代码
保持兼容性：不影响现有代码

简要使用示例：

// 最简单的 Java 程序
void main() {
    println("Hello, World!");
}

// 可以直接使用字段
String greeting = "Hello";

void main() {
    println(greeting + ", World!");
}

// 可以定义其他方法
void main() {
    greet("Java 25");
}

void greet(String name) {
    println("Hello, " + name);
}

JEP 479：灵活的构造函数体（正式发布）

JEP 479 在经过两次预览后正式发布，允许在 super() 或 this() 调用前执行语句。

为什么要引入这个功能：

传统的 Java 要求构造函数的第一条语句必须是 super() 或 this() 调用，这限制了参数验证和准备的灵活性。新特性允许在调用父类构造函数前进行必要的准备工作。

目标：

增强构造函数灵活性：允许参数验证和准备
减少辅助方法：无需创建静态辅助方法来准备参数
提高代码可读性：将相关逻辑放在一起

简要使用示例：

public class User {
    private final String username;
    private final String email;
    
    public User(String username, String email) {
        // 在 super() 前验证参数
        if (username == null || username.isBlank()) {
            throw new IllegalArgumentException("Username cannot be empty");
        }
        if (!email.contains("@")) {
            throw new IllegalArgumentException("Invalid email format");
        }
        
        // 参数标准化
        username = username.trim().toLowerCase();
        email = email.trim().toLowerCase();
        
        // 调用父类构造函数
        super();
        
        this.username = username;
        this.email = email;
    }
}

JEP 480：结构化并发（正式发布）

JEP 480 在经过三次预览后正式发布，提供了管理并发任务的结构化方式。

为什么要引入这个功能：

传统的并发编程容易出现线程泄漏、异常处理困难、取消操作复杂等问题。结构化并发通过将相关任务作为单个工作单元管理，简化了并发编程。

目标：

简化并发编程：提供清晰的任务生命周期管理
提高可靠性：减少线程泄漏和资源泄漏
增强可观察性：更容易监控和调试并发任务

简要使用示例：

import java.util.concurrent.StructuredTaskScope;

public class DataAggregator {
    
    record Response(String userData, List<Order> orders) {}
    
    public Response fetchUserData(String userId) throws Exception {
        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
            // 并发获取用户信息和订单
            var userTask = scope.fork(() -> fetchUser(userId));
            var ordersTask = scope.fork(() -> fetchOrders(userId));
            
            // 等待所有任务完成
            scope.join();
            
            // 如果任何任务失败，抛出异常
            scope.throwIfFailed();
            
            // 获取结果
            return new Response(
                userTask.get(),
                ordersTask.get()
            );
        }
    }
    
    private String fetchUser(String userId) {
        // 模拟从数据库获取用户
        return "User: " + userId;
    }
    
    private List<Order> fetchOrders(String userId) {
        // 模拟从数据库获取订单
        return List.of(new Order(userId, "Order-1"));
    }
}

JEP 481：作用域值（正式发布）

JEP 481 在经过三次预览后正式发布，提供了一种新的方式在线程间共享不可变数据。

为什么要引入这个功能：

ThreadLocal 存在可变性、生命周期管理困难、在虚拟线程环境下性能较差等问题。作用域值提供了更好的替代方案，特别适合与虚拟线程和结构化并发配合使用。

目标：

提供不可变共享：确保数据安全
明确生命周期：数据的作用域从代码结构中清晰可见
优化性能：在大量虚拟线程场景下表现更好

简要使用示例：

import jdk.incubator.concurrent.ScopedValue;

public class RequestProcessor {
    // 定义作用域值
    private static final ScopedValue<String> REQUEST_ID = ScopedValue.newInstance();
    private static final ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();
    
    public void handleRequest(String requestId, User user) {
        // 设置作用域值并执行操作
        ScopedValue.where(REQUEST_ID, requestId)
                   .where(CURRENT_USER, user)
                   .run(() -> {
                       processRequest();
                       logActivity();
                   });
    }
    
    private void processRequest() {
        // 在作用域内获取值
        String requestId = REQUEST_ID.get();
        User user = CURRENT_USER.get();
        
        System.out.println("Processing request " + requestId + 
                         " for user " + user.name());
        
        // 调用其他方法，它们也能访问作用域值
        validatePermissions();
    }
    
    private void validatePermissions() {
        User user = CURRENT_USER.get();
        // 验证权限
    }
    
    private void logActivity() {
        String requestId = REQUEST_ID.get();
        System.out.println("Request " + requestId + " completed");
    }
}

JEP 484：类文件 API 增强（预览）

JEP 484 在 JEP 466 正式发布的基础上，进一步增强类文件 API 的功能。

为什么要引入这个功能：

随着使用经验的积累，发现需要支持更多的字节码操作场景，如更灵活的代码生成、更精细的字节码分析等。

目标：

扩展 API 能力：支持更多字节码操作模式
提高性能：优化常见操作的性能
改进易用性：基于用户反馈简化常用操作

简要使用示例：

import java.lang.classfile.*;
import java.lang.classfile.instruction.*;

public class BytecodeAnalyzer {
    
    public void analyzeMethod(ClassModel classModel, String methodName) {
        classModel.methods().stream()
            .filter(m -> m.methodName().stringValue().equals(methodName))
            .forEach(method -> {
                method.code().ifPresent(code -> {
                    // 分析方法调用
                    code.forEach(element -> {
                        switch (element) {
                            case InvokeInstruction invoke -> {
                                System.out.println("Invokes: " + 
                                    invoke.owner().name().stringValue() + 
                                    "." + invoke.name().stringValue());
                            }
                            case FieldInstruction field -> {
                                System.out.println("Accesses field: " + 
                                    field.name().stringValue());
                            }
                            default -> {}
                        }
                    });
                });
            });
    }
}

发布计划

2025/06/05: Rampdown Phase One
2025/07/17: Rampdown Phase Two
2025/08/07: Initial Release Candidate
2025/08/21: Final Release Candidate
2025/09/16: General Availability

总结

JDK 25 继续沿着简化 Java 编程、提升性能和增强安全性的方向发展。多个重要特性从预览转为正式发布，如隐式声明的类、灵活的构造函数体、结构化并发和作用域值等，标志着这些特性已经成熟稳定。新引入的延迟初始化类和为语句准备等特性，进一步提升了 Java 的表达能力和性能。类文件 API 的正式发布为字节码操作提供了标准化的解决方案。

这些改进使 Java 在保持企业级应用开发优势的同时，也更加适合初学者学习和小型程序开发，进一步巩固了 Java 作为主流编程语言的地位。

公众号

coding 笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

我的博客地址：博客主页。

JDK 24 新特性解析

Tue, 11 Nov 2025 00:00:00 +0800

前言

JDK 24 是 Java SE 平台版本 24 的参考实现，预计 2025 年 3 月正式发布。本文将详细解析 JDK 24 的主要新特性。

新特性总览

JEP	特性名称	状态	说明
467	Markdown 文档注释	正式发布	允许在 JavaDoc 中使用 Markdown 语法，提高文档可读性
469	向量 API	第九次孵化	提供向量计算 API，支持 SIMD 指令优化
471	弃用 `sun.misc.Unsafe` 中的内存访问方法	正式发布	继续推进弃用不安全的内存访问方法
474	ZGC：默认的分代模式	正式发布	分代 ZGC 成为默认模式，提升垃圾回收性能
476	模块导入声明	预览	简化模块导入，允许一次性导入整个模块
477	隐式声明的类和实例主方法	第三次预览	简化初学者编程体验
480	结构化并发	第三次预览	简化并发编程模型
481	作用域值	第三次预览	提供线程间共享不可变数据的新机制
482	灵活的构造函数体	第二次预览	允许在 `super()` 调用前执行语句
483	提前编译工具改进	正式发布	改进 AOT 编译工具，提升启动性能

详细解析

JEP 467：Markdown 文档注释（正式发布）

JEP 467 在经过预览后正式发布，允许在 JavaDoc 文档注释中使用 Markdown 语法。

为什么要引入这个功能：

传统的 JavaDoc 主要使用 HTML 标签进行标记，语法繁琐且容易出错。Markdown 作为一种轻量级标记语言，具有简洁、易读、易写的特点，已在开发者社区广泛使用。引入 Markdown 支持可以显著简化文档编写过程，提高代码的可读性和可维护性。

目标：

简化文档编写：使用简洁的 Markdown 语法替代繁琐的 HTML
提高可读性：Markdown 文档在源代码中也易于阅读
保持兼容性：继续支持传统的 HTML 和 JavaDoc 标签
降低学习成本：开发者无需深入学习 HTML 即可编写文档

简要使用示例：

使用 Markdown 语法的文档注释：

/**
 * 用户服务类，提供用户管理的核心功能。
 * 
 * ## 主要功能
 * 
 * - 用户注册和登录
 * - 用户信息管理
 * - 权限验证
 * 
 * ### 使用示例
 * 
 * ```java
 * UserService service = new UserService();
 * User user = service.createUser("john", "john@example.com");
 * ```
 * 
 * **注意事项：**
 * 
 * 1. 用户名必须唯一
 * 2. 邮箱格式必须有效
 * 3. 密码长度至少 8 位
 * 
 * @param username 用户名
 * @param email 邮箱地址
 * @return 创建的用户对象
 * @throws IllegalArgumentException 如果参数无效
 */
public class UserService {
    // ...
}

Markdown 表格支持：

/**
 * 订单状态枚举
 * 
 * | 状态 | 描述 | 可执行操作 |
 * |------|------|-----------|
 * | PENDING | 待处理 | 确认、取消 |
 * | CONFIRMED | 已确认 | 发货、取消 |
 * | SHIPPED | 已发货 | 签收 |
 * | COMPLETED | 已完成 | 评价、退货 |
 */
public enum OrderStatus {
    PENDING, CONFIRMED, SHIPPED, COMPLETED
}

JEP 469：向量 API（第九次孵化）

JEP 469（第九次孵化）继续改进向量 API，提供更高效的向量计算能力。

为什么要引入这个功能：

现代 CPU 普遍支持 SIMD（Single Instruction, Multiple Data）指令，可以在单条指令中处理多个数据，显著提升计算性能。然而 Java 缺乏直接利用这些硬件能力的标准 API。向量 API 填补了这一空白，使开发者能够编写高性能的数值计算代码。

目标：

跨平台可移植性：编写一次，在不同 CPU 架构上都能高效运行
可预测的性能：向量操作可靠地编译为高效的机器指令
优雅降级：在不支持向量指令的平台上自动降级为标量操作
易于使用：提供清晰简洁的 API

简要使用示例：

向量化数组加法：

import jdk.incubator.vector.*;

public class VectorExample {
    static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;
    
    public static void vectorAdd(float[] a, float[] b, float[] result) {
        int i = 0;
        int upperBound = SPECIES.loopBound(a.length);
        
        // 向量化循环
        for (; i < upperBound; i += SPECIES.length()) {
            var va = FloatVector.fromArray(SPECIES, a, i);
            var vb = FloatVector.fromArray(SPECIES, b, i);
            var vc = va.add(vb);
            vc.intoArray(result, i);
        }
        
        // 处理剩余元素
        for (; i < a.length; i++) {
            result[i] = a[i] + b[i];
        }
    }
}

向量化点积计算：

public static float dotProduct(float[] a, float[] b) {
    var sum = FloatVector.zero(SPECIES);
    int i = 0;
    int upperBound = SPECIES.loopBound(a.length);
    
    for (; i < upperBound; i += SPECIES.length()) {
        var va = FloatVector.fromArray(SPECIES, a, i);
        var vb = FloatVector.fromArray(SPECIES, b, i);
        sum = va.fma(vb, sum);  // Fused multiply-add
    }
    
    float result = sum.reduceLanes(VectorOperators.ADD);
    
    // 处理剩余元素
    for (; i < a.length; i++) {
        result += a[i] * b[i];
    }
    
    return result;
}

JEP 471：弃用 `sun.misc.Unsafe` 中的内存访问方法（正式发布）

JEP 471 正式将 sun.misc.Unsafe 类中的内存访问方法标记为弃用，为未来移除做准备。

为什么要引入这个功能：

sun.misc.Unsafe 是一个非标准的内部 API，其内存访问方法可能导致未定义行为甚至 JVM 崩溃。随着 VarHandle API（JDK 9）和 Foreign Function & Memory API（JDK 22）的引入，已经有了安全且高效的替代方案。

目标：

促进迁移：鼓励开发者使用标准 API
提高安全性：减少不安全内存操作导致的问题
为移除做准备：在未来版本中完全移除这些方法

简要使用示例：

使用 VarHandle 替代 Unsafe：

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

public class SafeMemoryAccess {
    private volatile int value;
    private static final VarHandle VALUE_HANDLE;
    
    static {
        try {
            VALUE_HANDLE = MethodHandles.lookup()
                .findVarHandle(SafeMemoryAccess.class, "value", int.class);
        } catch (Exception e) {
            throw new ExceptionInInitializerError(e);
        }
    }
    
    // 原子性读取
    public int getValue() {
        return (int) VALUE_HANDLE.getVolatile(this);
    }
    
    // 原子性写入
    public void setValue(int newValue) {
        VALUE_HANDLE.setVolatile(this, newValue);
    }
    
    // CAS 操作
    public boolean compareAndSet(int expected, int newValue) {
        return VALUE_HANDLE.compareAndSet(this, expected, newValue);
    }
}

使用 Foreign Memory API：

import java.lang.foreign.*;

public class OffHeapMemory {
    public static void allocateAndUseMemory() {
        try (Arena arena = Arena.ofConfined()) {
            // 分配堆外内存
            MemorySegment segment = arena.allocate(1024);
            
            // 写入数据
            segment.set(ValueLayout.JAVA_INT, 0, 42);
            segment.set(ValueLayout.JAVA_INT, 4, 100);
            
            // 读取数据
            int value1 = segment.get(ValueLayout.JAVA_INT, 0);
            int value2 = segment.get(ValueLayout.JAVA_INT, 4);
            
            System.out.println("Values: " + value1 + ", " + value2);
        } // 内存自动释放
    }
}

JEP 474：ZGC：默认的分代模式（正式发布）

JEP 474 正式将 Z 垃圾收集器（ZGC）的默认模式切换为分代模式。

为什么要引入这个功能：

分代 ZGC 在大多数使用场景下性能优于非分代模式，能够更好地处理不同生命周期的对象。维护两种模式增加了开发和测试成本，统一为分代模式可以集中资源进行优化。

目标：

提升默认性能：大多数应用无需调优即可获得更好的性能
简化维护：专注于分代 ZGC 的发展
降低内存占用：分代模式通常使用更少的内存

简要使用示例：

启用 ZGC（分代模式，JDK 24 默认）：

# JDK 24 中，直接启用 ZGC 即使用分代模式
java -XX:+UseZGC -Xmx4g MyApplication

# 查看 GC 日志
java -XX:+UseZGC -Xlog:gc* -Xmx4g MyApplication

如果需要使用非分代模式（已弃用）：

# 显式禁用分代模式（会收到弃用警告）
java -XX:+UseZGC -XX:-ZGenerational -Xmx4g MyApplication

# 警告信息：
# Warning: Option ZGenerational was deprecated.
# Warning: Non-generational mode is deprecated and will likely be removed in a future release.

ZGC 调优参数：

# 设置并发 GC 线程数
java -XX:+UseZGC -XX:ConcGCThreads=2 MyApplication

# 设置最大堆大小
java -XX:+UseZGC -Xmx8g MyApplication

# 启用详细的 GC 日志
java -XX:+UseZGC -Xlog:gc*=info:file=gc.log MyApplication

JEP 476：模块导入声明（预览）

JEP 476 引入模块导入声明，简化了模块化库的使用。

为什么要引入这个功能：

使用模块化库时，开发者通常需要导入多个包。模块导入声明允许一次性导入整个模块的所有导出包，减少样板代码，提高开发效率。

目标：

简化代码：用一条语句替代多条包导入
降低学习曲线：无需了解模块内部的包结构
提高可维护性：模块添加新包时无需修改导入语句

简要使用示例：

// 传统方式：需要导入多个包
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import javax.sql.DataSource;

// 使用模块导入：一条语句导入整个模块
import module java.sql;

public class DatabaseExample {
    public void queryDatabase() throws SQLException {
        // 可以直接使用 java.sql 模块的所有导出类型
        Connection conn = DriverManager.getConnection("jdbc:...");
        PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users");
        ResultSet rs = stmt.executeQuery();
        
        while (rs.next()) {
            System.out.println(rs.getString("name"));
        }
    }
}

JEP 477：隐式声明的类和实例主方法（第三次预览）

JEP 477（第三次预览）继续简化 Java 程序的编写，特别适合初学者和小型程序。

为什么要引入这个功能：

传统的 Java 程序需要理解类、访问修饰符、静态方法、数组参数等多个概念，这对初学者构成了不必要的障碍。通过允许省略这些样板代码，降低了学习门槛。

目标：

降低入门门槛：使初学者能够快速上手
简化脚本编写：减少工具脚本的冗余代码
平滑学习曲线：随着需求增长逐步引入高级特性

简要使用示例：

最简单的程序：

// HelloWorld.java
void main() {
    println("Hello, World!");
}

使用实例字段和方法：

// Calculator.java
int accumulator = 0;

void main() {
    add(10);
    add(20);
    println("Total: " + accumulator);
}

void add(int value) {
    accumulator += value;
}

逐步扩展到完整的类：

// 初学者版本
void main() {
    println("Hello");
}

// 进阶版本 - 添加字段和方法
String name = "Java";

void main() {
    greet();
}

void greet() {
    println("Hello, " + name);
}

// 最终版本 - 标准类结构
public class Greeter {
    private String name = "Java";
    
    public static void main(String[] args) {
        new Greeter().greet();
    }
    
    public void greet() {
        System.out.println("Hello, " + name);
    }
}

JEP 480：结构化并发（第三次预览）

JEP 480（第三次预览）继续完善结构化并发 API，简化并发编程。

为什么要引入这个功能：

传统的并发编程模型容易出现线程泄漏、异常处理复杂、取消操作困难等问题。结构化并发通过将相关任务作为单个工作单元管理，提供了更清晰、更安全的并发编程模式。

目标：

简化并发代码：提供清晰的任务生命周期管理
提高可靠性：自动处理任务取消和资源清理
增强可观察性：更容易监控和调试并发任务

简要使用示例：

import java.util.concurrent.StructuredTaskScope;
import java.util.concurrent.StructuredTaskScope.Subtask;

public class UserDataService {
    
    record UserData(User user, List<Order> orders, Profile profile) {}
    
    /**
     * 并发获取用户的所有相关数据
     */
    public UserData fetchUserData(String userId) throws Exception {
        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
            // 并发执行多个任务
            Subtask<User> userTask = scope.fork(() -> fetchUser(userId));
            Subtask<List<Order>> ordersTask = scope.fork(() -> fetchOrders(userId));
            Subtask<Profile> profileTask = scope.fork(() -> fetchProfile(userId));
            
            // 等待所有任务完成
            scope.join();
            
            // 如果任何任务失败，抛出异常
            scope.throwIfFailed();
            
            // 所有任务成功，组装结果
            return new UserData(
                userTask.get(),
                ordersTask.get(),
                profileTask.get()
            );
        }
    }
    
    /**
     * 获取第一个成功响应的结果
     */
    public String fetchFromMultipleServers(List<String> serverUrls) throws Exception {
        try (var scope = new StructuredTaskScope.ShutdownOnSuccess<String>()) {
            // 并发请求多个服务器
            for (String url : serverUrls) {
                scope.fork(() -> httpGet(url));
            }
            
            // 等待第一个成功的结果
            scope.join();
            
            // 返回第一个成功的结果
            return scope.result();
        }
    }
    
    private User fetchUser(String userId) {
        // 模拟数据库查询
        return new User(userId, "John Doe");
    }
    
    private List<Order> fetchOrders(String userId) {
        // 模拟订单查询
        return List.of(new Order("Order1"), new Order("Order2"));
    }
    
    private Profile fetchProfile(String userId) {
        // 模拟用户档案查询
        return new Profile(userId, "Premium");
    }
    
    private String httpGet(String url) {
        // 模拟 HTTP 请求
        return "Response from " + url;
    }
}

JEP 481：作用域值（第三次预览）

JEP 481（第三次预览）提供了一种新的方式在线程间共享不可变数据，作为 ThreadLocal 的更好替代方案。

为什么要引入这个功能：

ThreadLocal 存在多个问题：可变性导致的线程安全隐患、不受控制的生命周期、在虚拟线程场景下的性能问题等。作用域值通过提供不可变的、生命周期明确的数据共享机制，解决了这些问题。

目标：

不可变性：确保共享数据的安全性
明确的生命周期：从代码结构中清晰可见
高性能：特别是在虚拟线程场景下

简要使用示例：

import jdk.incubator.concurrent.ScopedValue;

public class WebRequestHandler {
    // 定义作用域值
    private static final ScopedValue<String> REQUEST_ID = ScopedValue.newInstance();
    private static final ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();
    private static final ScopedValue<Locale> LOCALE = ScopedValue.newInstance();
    
    /**
     * 处理 HTTP 请求
     */
    public void handleRequest(HttpRequest request) {
        String requestId = generateRequestId();
        User user = authenticate(request);
        Locale locale = determineLocale(request);
        
        // 设置作用域值并执行请求处理
        ScopedValue.where(REQUEST_ID, requestId)
                   .where(CURRENT_USER, user)
                   .where(LOCALE, locale)
                   .run(() -> processRequest(request));
    }
    
    private void processRequest(HttpRequest request) {
        // 在作用域内可以访问值
        log("Processing request");
        
        // 调用业务逻辑
        var data = fetchData();
        var response = transformData(data);
        sendResponse(response);
        
        log("Request completed");
    }
    
    private Object fetchData() {
        // 可以在任何嵌套的方法中访问作用域值
        User user = CURRENT_USER.get();
        return database.query("SELECT * FROM data WHERE user_id = ?", user.id());
    }
    
    private Object transformData(Object data) {
        Locale locale = LOCALE.get();
        // 根据语言环境转换数据
        return localizer.transform(data, locale);
    }
    
    private void sendResponse(Object response) {
        String requestId = REQUEST_ID.get();
        // 发送响应
        System.out.println("Sending response for request: " + requestId);
    }
    
    private void log(String message) {
        String requestId = REQUEST_ID.get();
        User user = CURRENT_USER.get();
        System.out.printf("[%s] [User: %s] %s%n", requestId, user.name(), message);
    }
    
    private String generateRequestId() {
        return java.util.UUID.randomUUID().toString();
    }
    
    private User authenticate(HttpRequest request) {
        return new User("user123", "John Doe");
    }
    
    private Locale determineLocale(HttpRequest request) {
        return Locale.US;
    }
}

JEP 482：灵活的构造函数体（第二次预览）

JEP 482（第二次预览）继续完善灵活的构造函数体功能，根据第一次预览的反馈进行了改进。

为什么要引入这个功能：

Java 要求构造函数的第一条语句必须是 super() 或 this() 调用，这限制了参数验证和数据准备的灵活性。新特性允许在调用父类构造函数前执行必要的准备工作。

目标：

增强灵活性：允许在 super() 前进行参数验证和准备
减少辅助方法：无需创建静态方法来准备参数
提高代码质量：使构造函数逻辑更清晰

简要使用示例：

参数验证：

public class Email {
    private final String address;
    
    public Email(String address) {
        // 在 super() 前验证参数
        if (address == null || address.isBlank()) {
            throw new IllegalArgumentException("Email address cannot be empty");
        }
        if (!address.contains("@")) {
            throw new IllegalArgumentException("Invalid email format");
        }
        
        // 标准化处理
        address = address.trim().toLowerCase();
        
        super();
        this.address = address;
    }
}

复杂参数准备：

public class SecureConnection extends Connection {
    
    public SecureConnection(Certificate certificate, int port) {
        // 验证证书
        if (certificate == null) {
            throw new IllegalArgumentException("Certificate is required");
        }
        if (certificate.isExpired()) {
            throw new IllegalArgumentException("Certificate has expired");
        }
        
        // 提取和处理证书信息
        var publicKey = certificate.getPublicKey();
        byte[] keyBytes = switch (publicKey) {
            case RSAPublicKey rsa -> encodeRSAKey(rsa);
            case ECPublicKey ec -> encodeECKey(ec);
            default -> throw new IllegalArgumentException("Unsupported key type");
        };
        
        // 调用父类构造函数
        super(keyBytes, port);
    }
    
    private byte[] encodeRSAKey(RSAPublicKey key) {
        // RSA 密钥编码逻辑
        return key.getEncoded();
    }
    
    private byte[] encodeECKey(ECPublicKey key) {
        // EC 密钥编码逻辑
        return key.getEncoded();
    }
}

JEP 483：提前编译工具改进（正式发布）

JEP 483 改进了提前编译（AOT）工具，进一步提升 Java 应用的启动性能。

为什么要引入这个功能：

在云原生和 serverless 环境中，应用的启动时间至关重要。传统的 JIT（即时编译）需要在运行时编译热点代码，导致启动阶段性能较差。AOT 编译可以在构建时完成编译，显著减少启动时间。

目标：

加快启动速度：预编译代码可立即执行
减少预热时间：避免 JIT 编译导致的性能波动
降低资源消耗：减少运行时的 CPU 使用

简要使用示例：

使用 AOT 编译应用：

# 分析应用运行时行为
java -XX:ArchiveClassesAtExit=app.jsa -cp app.jar com.example.Main

# 使用存档文件启动应用（更快的启动速度）
java -XX:SharedArchiveFile=app.jsa -cp app.jar com.example.Main

结合 CDS（Class Data Sharing）：

# 创建应用的类数据共享存档
java -Xshare:dump -XX:SharedClassListFile=classes.lst \
     -XX:SharedArchiveFile=app.jsa -cp app.jar

# 使用共享存档启动
java -Xshare:on -XX:SharedArchiveFile=app.jsa \
     -cp app.jar com.example.Main

性能对比：

# 传统启动
$ time java -cp app.jar com.example.Main
real    0m2.345s

# AOT + CDS 启动
$ time java -Xshare:on -XX:SharedArchiveFile=app.jsa \
       -cp app.jar com.example.Main
real    0m0.856s

发布计划

2024/12/05: Rampdown Phase One
2025/01/16: Rampdown Phase Two
2025/02/06: Initial Release Candidate
2025/02/20: Final Release Candidate
2025/03/18: General Availability

总结

JDK 24 延续了 Java 平台的持续演进，在简化开发、提升性能和增强安全性方面取得了重要进展。

正式发布的特性包括 Markdown 文档注释、弃用 sun.misc.Unsafe、分代 ZGC 默认模式和 AOT 工具改进，这些特性已经成熟稳定，可以在生产环境中放心使用。

持续预览的特性如模块导入声明、隐式声明的类、结构化并发、作用域值和灵活的构造函数体，继续收集社区反馈，为最终正式发布做准备。

向量 API 进入第九次孵化，表明 Java 在高性能计算领域持续发力，为科学计算、机器学习等场景提供更好的支持。

总体而言，JDK 24 在保持企业级应用稳定性的同时，也积极拥抱现代编程实践，使 Java 更加易学易用、高效安全。

公众号

coding 笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

我的博客地址：博客主页。

MCP 原理及 Java 开发指南

Wed, 22 Oct 2025 00:00:00 +0800

为什么需要 MCP？
基本概念
Java Spring AI 集成实践
完整配置示例
MCP Client 配置与使用
最佳实践
典型应用场景
生态系统与工具
常见问题
未来展望
参考资源

目的：帮助 Java / Spring Boot 开发者快速理解 MCP 的设计动机、协议细节、以及如何在 Spring AI 中落地。

为什么需要 MCP？

MCP 助力开发者在 LLM 之上构建智能体和复杂工作流。由于 LLM 需要频繁与外部数据和工具集成，MCP 提供了以下核心价值：

开箱即用的集成能力：提供丰富的预置集成方案，LLM 可直接接入使用
灵活的供应商切换：支持在不同 LLM 服务商之间无缝迁移
安全最佳实践：内置数据安全防护机制，确保基础设施安全可控

MCP 用 JSON‑RPC 2.0 + 能力发现 的模式，把「模型 ↔ 应用 ↔ 工具」之间的交互标准化，实现 一次接入，多处复用。

MCP 协议就好比 USB 接口，USB 设备可以通过 USB Hub 连接到不同的计算机上，而不需要重新设计接口。

我们在电脑上可以同时使用多个 USB 设备（鼠标、键盘、硬盘、游戏手柄），这些 USB 设备有不同的功能，只要实现了标准的 USB 接口协议即可。

电脑可以类比成 LLM，USB Hub 可以类比成 MCP Server，USB 设备可以类比成 Tool、Resource、Prompt 等。

通过 MCP 协议，LLM 可以通过 USB Hub 访问不同的 USB 设备，从而扩展出各种各样的能力（发邮件、打电话、地图旅行规划、订票）。

从某种程度上说，MCP 就像是设计模式中的命令（Command）模式 + 外观（Facade）模式。

基本概念

关键术语

MCP 主机：需要通过 MCP 访问数据的程序，如 Claude Desktop、IDE 或 AI 工具
MCP 客户端：与服务器保持 1:1 连接的协议客户端
MCP 服务器：通过标准化的模型上下文协议暴露特定能力的轻量级程序
本地数据源：MCP 服务器可以安全访问的计算机文件、数据库和服务
远程服务：MCP 服务器可以通过互联网连接的外部系统（例如通过 API）

分层架构

┌────────────────────────────┐

│  Client / Server API 层    │ ← McpClient / McpServer

├────────────────────────────┤

│  Session 会话层            │ ← 会话 & 状态管理

├────────────────────────────┤

│  Transport 传输层          │ ← Stdio / SSE / WebSocket / gRPC

└────────────────────────────┘

MCP 采用分层架构设计，每一层都有其特定的职责：

Client / Server API 层
- 提供 McpClient 和 McpServer 接口
- 处理高层业务逻辑和协议交互
- 负责能力发现和工具调用
Session 会话层
- 管理客户端和服务器之间的会话状态
- 处理会话的生命周期（初始化、运行、关闭）
- 维护会话上下文和状态信息
Transport 传输层
- 提供多种传输机制支持：
  - Stdio：标准输入输出，适合本地进程间通信
  - SSE (Server-Sent Events)：单向服务器推送
  - WebSocket：全双工通信
  - gRPC：高性能 RPC 框架
- 处理底层通信细节和协议转换

这种分层设计使得 MCP 具有：

良好的可扩展性：可以轻松添加新的传输机制
清晰的职责分离：各层专注于自己的功能
灵活的部署方式：支持多种通信场景

传输机制

传输	场景	特点
Stdio	本地 CLI / 子进程	零网络开销，启动快
HTTP + SSE	微服务 / Web 应用	POST 请求 + SSE 推流，部署友好
自定义	WebSocket / gRPC	只需实现 Transport 接口即可

Java Spring AI 集成实践

使用 Spring AI 开发，详细说明可以参考官网文档。

MCP 分为 Stdio 和 SSE 两种传输方式，下面的例子使用 SSE 方式，最简化开发一个发票助手 MCP，并展示如何通过模型自动调用这个 MCP。

POM 依赖

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-server-webflux</artifactId>
</dependency>

配置示例 `application.properties`

spring.main.banner-mode=off
# logging.pattern.console=
spring.ai.mcp.server.name=my-invoice-server
spring.ai.mcp.server.version=0.0.1

详细的配置参数及默认值可以参考官方文档：Spring AI / Model Context Protocol (MCP) / MCP Server Boot Starters。

暴露 Tool

这里就模拟一个非常简单的功能，仅拼装对应参数，返回发票链接。

@Service
public class InvoiceService {

    @Tool(description = "获取发票链接")
    public String getInvoiceUrl(@ToolParam(required = true, description = "发票 id") String invoiceId) {
        return "https://www.example.com/invoice/" + invoiceId;
    }
}

@SpringBootApplication
public class McpServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(McpServerApplication.class, args);
    }

    @Bean
    public ToolCallbackProvider invoiceTools(InvoiceService invoiceService) {
        return MethodToolCallbackProvider.builder().toolObjects(invoiceService).build();
    }
}

启动服务

执行 java -jar mcp-server.jar 启动服务，默认监听 8080 端口。

在 MCP client 中配置 mcp.setting

cursor、VS code 中的 cline 插件都算是 MCP client。本文展示 cline 插件如何配置。

cline_mcp_setting.json 增加如下配置：

{
  "mcpServers": {
    "invoice-local": {
      "url": "http://localhost:8080/sse",
      "autoApprove": [
        "getInvoiceUrl"
      ]
    }
  }
}

我们可以看到对应的 getInvoiceUrl 方法已经被自动注册到 MCP Server 中。

使用 MCP！

在 cline 中输入问题：“我有一个发票 id 是 123456，发票链接是多少？”，可以看到模型会自动判断是否需要调用 MCP Server 中的 getInvoiceUrl 方法，并拼装参数，获取结果。

说明

JDK 版本必须 >= 17
Spring Boot 版本必须 >= 3.2
Spring AI 底层使用 modelcontextprotocol / java-sdk
MCP 协议等都在快速发展中，上面的代码示例仅供参考，具体实现可能会有所不同

完整配置示例

Application.java：

package com.example.mcp;

import org.springframework.ai.mcp.server.tool.ToolCallbackProvider;
import org.springframework.ai.mcp.server.tool.MethodToolCallbackProvider;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.reactive.function.client.WebClient;

@SpringBootApplication
public class McpServerApplication {
    
    public static void main(String[] args) {
        SpringApplication.run(McpServerApplication.class, args);
    }
    
    /**
     * 注册所有 Tools
     */
    @Bean
    public ToolCallbackProvider toolCallbackProvider(
            DatabaseTools databaseTools,
            FileTools fileTools,
            HttpTools httpTools
    ) {
        return MethodToolCallbackProvider.builder()
            .toolObjects(databaseTools, fileTools, httpTools)
            .build();
    }
    
    /**
     * WebClient for HTTP tools
     */
    @Bean
    public WebClient webClient() {
        return WebClient.builder()
            .defaultHeader("User-Agent", "MCP-Server/1.0")
            .build();
    }
}

application.yml：

spring:
  application:
    name: mcp-server-demo
  
  ai:
    mcp:
      server:
        name: "Enterprise MCP Server"
        version: "1.0.0"
        description: "Comprehensive MCP server with database, file, and HTTP capabilities"
        
server:
  port: 8080
  
logging:
  level:
    org.springframework.ai.mcp: DEBUG
    com.example.mcp: DEBUG

MCP Client 配置与使用

Claude Desktop 配置

Claude Desktop 是最早支持 MCP 的应用之一。配置文件位置：

macOS：

~/Library/Application\ Support/Claude/claude_desktop_config.json

Windows：

%APPDATA%\Claude\claude_desktop_config.json

配置示例：

{
  "mcpServers": {
    "enterprise-server": {
      "command": "java",
      "args": [
        "-jar",
        "/path/to/mcp-server.jar"
      ],
      "env": {
        "SERVER_PORT": "8080"
      }
    },
    "database-server": {
      "url": "http://localhost:8080/sse",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}

Cursor IDE 配置

Cursor 通过 .cursor/mcp.json 文件配置 MCP 服务器：

{
  "mcpServers": {
    "local-dev": {
      "command": "java",
      "args": ["-jar", "mcp-server.jar"],
      "env": {
        "WORKSPACE_ROOT": "${workspaceFolder}"
      }
    },
    "remote-api": {
      "url": "https://api.example.com/mcp/sse",
      "autoApprove": ["read_file", "list_directory"]
    }
  }
}

Cline/Continue 配置

VS Code 插件 Cline 的配置文件：~/.cline/mcp_settings.json

{
  "mcpServers": {
    "development": {
      "url": "http://localhost:8080/sse",
      "autoApprove": [
        "query_database",
        "read_file",
        "list_directory"
      ],
      "alwaysAllow": ["get_table_schema"]
    }
  }
}

实际使用示例

场景 1：数据库查询

用户: 查询用户表中所有活跃用户的数量

AI: 我会帮你查询数据库。
[调用 query_database]
参数: sql = "SELECT COUNT(*) as count FROM users WHERE status = 'active'"

结果: {"rowCount": 1, "rows": [{"count": 1234}]}

AI: 当前有 1,234 个活跃用户。

场景 2：文件操作

用户: 帮我创建一个 README.md 文件,包含项目介绍

AI: 好的,我会创建 README 文件。
[调用 write_file]
参数:
  path = "README.md"
  content = "# Project Name\n\nThis is a comprehensive guide..."
  create_dirs = true

AI: README.md 文件已创建成功!

场景 3：代码审查

用户: 使用 code-review prompt 审查这段代码

AI: 我会使用专业的代码审查模板。
[调用 code-review prompt]
参数:
  language = "Java"
  code = "public class User { ... }"
  focus_areas = "安全性和性能"

AI: [提供详细的代码审查反馈...]

最佳实践

安全考虑

输入验证

public class SecurityValidator {
    
    public static void validateSqlQuery(String sql) {
        // 防止 SQL 注入
        String lowerSql = sql.toLowerCase();
        String[] dangerousKeywords = {
            "drop", "delete", "update", "insert", 
            "truncate", "alter", "create"
        };
        
        for (String keyword : dangerousKeywords) {
            if (lowerSql.contains(keyword)) {
                throw new SecurityException(
                    "不允许的 SQL 操作: " + keyword
                );
            }
        }
    }
    
    public static Path validatePath(Path basePath, String userPath) {
        Path resolved = basePath.resolve(userPath).normalize();
        
        // 防止路径遍历攻击
        if (!resolved.startsWith(basePath)) {
            throw new SecurityException(
                "路径超出允许范围: " + userPath
            );
        }
        
        return resolved;
    }
}

权限控制

@Configuration
public class McpSecurityConfig {
    
    @Bean
    public McpAuthorizationManager authorizationManager() {
        return new McpAuthorizationManager() {
            @Override
            public boolean canExecuteTool(String toolName, Principal user) {
                // 基于用户角色的权限控制
                return switch (toolName) {
                    case "query_database" -> 
                        user.hasRole("DATA_ANALYST");
                    case "write_file" -> 
                        user.hasRole("DEVELOPER");
                    default -> true;
                };
            }
        };
    }
}

API 速率限制

@Aspect
@Component
public class RateLimitAspect {
    
    private final RateLimiter rateLimiter = 
        RateLimiter.create(10.0); // 每秒 10 个请求
    
    @Around("@annotation(Tool)")
    public Object rateLimit(ProceedingJoinPoint joinPoint) 
            throws Throwable {
        if (!rateLimiter.tryAcquire()) {
            throw new RateLimitException(
                "请求过于频繁,请稍后再试"
            );
        }
        return joinPoint.proceed();
    }
}

性能优化

结果缓存

@Service
public class CachedDatabaseTools {
    
    @Cacheable(value = "tableSchema", key = "#tableName")
    public TableSchema getTableSchema(String tableName) {
        // 缓存表结构,避免重复查询
        return databaseService.getSchema(tableName);
    }
    
    @Cacheable(
        value = "queryResults",
        key = "#sql",
        condition = "#sql.toLowerCase().startsWith('select')"
    )
    public QueryResult executeQuery(String sql) {
        return databaseService.execute(sql);
    }
}

异步处理

@Service
public class AsyncFileTools {
    
    @Tool(description = "异步搜索文件")
    public CompletableFuture<List<String>> searchFilesAsync(
            @ToolParam(name = "pattern") String pattern
    ) {
        return CompletableFuture.supplyAsync(() -> {
            // 耗时的文件搜索操作
            return fileService.search(pattern);
        });
    }
}

连接池管理

@Configuration
public class DatabaseConfig {
    
    @Bean
    public DataSource dataSource() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl(jdbcUrl);
        config.setUsername(username);
        config.setPassword(password);
        
        // 优化连接池配置
        config.setMaximumPoolSize(20);
        config.setMinimumIdle(5);
        config.setConnectionTimeout(30000);
        config.setIdleTimeout(600000);
        
        return new HikariDataSource(config);
    }
}

错误处理

统一异常处理：

@ControllerAdvice
public class McpExceptionHandler {
    
    @ExceptionHandler(SecurityException.class)
    public ResponseEntity<ErrorResponse> handleSecurityException(
            SecurityException ex
    ) {
        return ResponseEntity
            .status(HttpStatus.FORBIDDEN)
            .body(new ErrorResponse(
                "SECURITY_ERROR",
                ex.getMessage()
            ));
    }
    
    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<ErrorResponse> handleValidationException(
            IllegalArgumentException ex
    ) {
        return ResponseEntity
            .status(HttpStatus.BAD_REQUEST)
            .body(new ErrorResponse(
                "VALIDATION_ERROR",
                ex.getMessage()
            ));
    }
    
    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleGenericException(
            Exception ex
    ) {
        log.error("Unexpected error", ex);
        return ResponseEntity
            .status(HttpStatus.INTERNAL_SERVER_ERROR)
            .body(new ErrorResponse(
                "INTERNAL_ERROR",
                "服务暂时不可用,请稍后重试"
            ));
    }
}

record ErrorResponse(
    String code,
    String message
) {}

监控与日志

@Aspect
@Component
public class McpMonitoringAspect {
    
    @Around("@annotation(tool)")
    public Object monitorToolExecution(
            ProceedingJoinPoint joinPoint,
            Tool tool
    ) throws Throwable {
        String toolName = tool.name();
        long startTime = System.currentTimeMillis();
        
        try {
            Object result = joinPoint.proceed();
            long duration = System.currentTimeMillis() - startTime;
            
            // 记录成功的工具调用
            log.info(
                "Tool executed: {} | Duration: {}ms",
                toolName, duration
            );
            
            // 发送指标到监控系统
            metricsService.recordToolExecution(
                toolName, duration, "success"
            );
            
            return result;
            
        } catch (Exception ex) {
            long duration = System.currentTimeMillis() - startTime;
            
            // 记录失败的工具调用
            log.error(
                "Tool failed: {} | Duration: {}ms | Error: {}",
                toolName, duration, ex.getMessage()
            );
            
            metricsService.recordToolExecution(
                toolName, duration, "failure"
            );
            
            throw ex;
        }
    }
}

典型应用场景

1. IDE 智能助手

功能描述： 在 IDE 中提供代码生成、重构、调试等智能辅助功能。

实现示例：

@Service
public class IdeTools {
    
    @Tool(description = "生成单元测试")
    public String generateUnitTest(
            @ToolParam(name = "source_code") String sourceCode,
            @ToolParam(name = "test_framework") String framework
    ) {
        // 分析源代码
        CodeAnalysis analysis = codeAnalyzer.analyze(sourceCode);
        
        // 生成测试代码
        return testGenerator.generate(analysis, framework);
    }
    
    @Tool(description = "代码重构建议")
    public List<RefactoringSuggestion> suggestRefactoring(
            @ToolParam(name = "code") String code
    ) {
        return refactoringService.analyzePotentialImprovements(code);
    }
}

2. 企业数据分析

功能描述： 提供自然语言到 SQL 的转换,支持数据可视化。

@Service
public class DataAnalyticsTools {
    
    @Tool(description = "自然语言查询")
    public QueryResult nlQuery(
            @ToolParam(name = "question") String question
    ) {
        // 将自然语言转换为 SQL
        String sql = nlToSqlConverter.convert(question);
        
        log.info("Generated SQL: {}", sql);
        
        // 执行查询
        return databaseService.executeQuery(sql);
    }
    
    @Tool(description = "生成数据可视化")
    public ChartConfig generateChart(
            @ToolParam(name = "data") List<Map<String, Object>> data,
            @ToolParam(name = "chart_type") String chartType
    ) {
        return chartGenerator.generate(data, chartType);
    }
}

3. 文档生成与管理

@Service
public class DocumentationTools {
    
    @Tool(description = "生成 API 文档")
    public String generateApiDocs(
            @ToolParam(name = "swagger_spec") String swaggerSpec
    ) {
        return apiDocGenerator.generate(swaggerSpec);
    }
    
    @Tool(description = "更新用户手册")
    public UpdateResult updateUserManual(
            @ToolParam(name = "section") String section,
            @ToolParam(name = "content") String content
    ) {
        Path manualPath = docsPath.resolve("user-manual.md");
        return documentService.updateSection(manualPath, section, content);
    }
}

4. DevOps 自动化

@Service
public class DevOpsTools {
    
    @Tool(description = "部署应用")
    public DeploymentResult deploy(
            @ToolParam(name = "environment") String environment,
            @ToolParam(name = "version") String version
    ) {
        return deploymentService.deploy(environment, version);
    }
    
    @Tool(description = "查看日志")
    public List<LogEntry> getLogs(
            @ToolParam(name = "service") String service,
            @ToolParam(name = "lines") int lines
    ) {
        return logService.getTailLogs(service, lines);
    }
    
    @Tool(description = "检查服务健康状态")
    public HealthStatus checkHealth(
            @ToolParam(name = "service") String service
    ) {
        return healthCheckService.check(service);
    }
}

生态系统与工具

官方工具

MCP Inspector - 调试和测试 MCP 服务器
- 网址: https://github.com/modelcontextprotocol/inspector
- 功能: 实时查看工具调用、测试 prompts、监控资源

MCP CLI - 命令行工具

npm install -g @modelcontextprotocol/cli
mcp test http://localhost:8080/sse

社区服务器

访问 mcp.so 浏览 1000+ 社区 MCP 服务器:

数据库: PostgreSQL, MySQL, MongoDB, Redis
云服务: AWS, Azure, GCP
开发工具: GitHub, GitLab, Jira
通信: Slack, Discord, Email
数据处理: Pandas, NumPy, Excel

客户端支持

客户端	支持程度	配置方式
Claude Desktop	✅ 完整支持	JSON 配置文件
Cursor	✅ 完整支持	.cursor/mcp.json
Cline (VS Code)	✅ 完整支持	插件配置
Continue	✅ 完整支持	config.json
Zed	✅ 实验性支持	内置配置

常见问题

Q: MCP 与 OpenAI Function Calling 有什么区别？

A: MCP 是一个开放协议,不绑定特定 AI 提供商。Function Calling 是 OpenAI 特定的实现。MCP 支持更丰富的能力(Tools, Resources, Prompts),而 Function Calling 主要聚焦于函数调用。

Q: stdio 和 SSE 传输方式如何选择？

stdio: 适合本地命令行工具,零网络开销,启动快
SSE: 适合 Web 服务,支持远程访问,易于部署和扩展

Q: MCP 服务器如何处理长时间运行的任务？

A: 建议使用异步模式:

@Tool(description = "异步任务")
public TaskId startAsyncTask(
        @ToolParam(name = "input") String input
) {
    // 返回任务 ID
    return taskService.submit(input);
}

@Tool(description = "查询任务状态")
public TaskStatus getTaskStatus(
        @ToolParam(name = "task_id") String taskId
) {
    return taskService.getStatus(taskId);
}

Q: 如何调试 MCP 服务器？

使用 MCP Inspector 工具
启用详细日志: logging.level.org.springframework.ai.mcp=DEBUG
使用 Postman 测试 SSE 端点
添加监控和追踪

Q: MCP 服务器的性能瓶颈在哪里？

A: 常见瓶颈:

数据库连接池不足
未使用缓存
同步阻塞操作
大数据传输

优化建议见”性能优化”章节。

未来展望

即将到来的特性

细粒度权限控制
- 基于工具的 ACL
- 资源级别的访问控制
- 审计日志
多模态支持
- 图像分析工具
- 音频处理
- 视频内容理解
增强的上下文管理
- 会话状态持久化
- 跨工具上下文共享
- 智能缓存策略
更好的可观测性
- 内置追踪和指标
- 性能分析工具
- 实时监控面板

技术演进方向

协议版本 2.0: 更高效的二进制传输
边缘计算: 在浏览器中运行 MCP 服务器
联邦学习: 跨服务器的知识共享
AI Agent 框架: 与 LangChain, AutoGPT 等深度集成

生态发展

企业采用: 更多企业级 MCP 服务器
标准化: 行业标准和最佳实践
认证体系: MCP 服务器质量认证
市场生态: MCP 服务器市场和交易平台

参考资源

官方资源

MCP 官方网站: https://modelcontextprotocol.io
MCP 规范: https://spec.modelcontextprotocol.io
MCP GitHub: https://github.com/modelcontextprotocol
MCP 服务器目录: https://mcp.so/servers

Spring AI 相关

Spring AI 文档: https://docs.spring.io/spring-ai/reference/
MCP 集成指南: https://docs.spring.io/spring-ai/reference/api/mcp/
示例仓库: https://github.com/spring-projects/spring-ai-examples
Spring AI MCP Server Starter: https://docs.spring.io/spring-ai/reference/api/mcp/mcp-server-boot-starter-docs.html

技术规范

JSON-RPC 2.0: https://www.jsonrpc.org/specification
Server-Sent Events: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events
OpenAPI 3.0: https://swagger.io/specification/

社区资源

MCP Discord: https://discord.gg/modelcontextprotocol
MCP Reddit: https://reddit.com/r/mcp
Stack Overflow: 标签 model-context-protocol
YouTube 教程: 搜索 “MCP Tutorial”

为什么在 2025 年仍然值得学习 Java：一位开发者的 25 年旅程

Sun, 07 Sep 2025 00:00:00 +0800

原文链接：Why Java is still worth learning in 2025: A developer’s 25-year journey

老实说，1999 年我第一次碰到 Java 并不来电。当时在大学上分布式系统课。以我那会儿的汇编和 C 底子，Java 留给我的印象是：笨重、慢，还有点不靠谱。所谓的“自动内存管理”，像是把掌控权交给了不可知的黑箱。多年养成的“精确管理每一块内存”的习惯，让我本能地抗拒把内存交给运行时去打理。

在职业生涯的前 8 年里，我固执地坚持使用 C，确信 Java 只是那些无法处理“真正”编程的开发者的昙花一现。

我错了，而且我很庆幸当年的自己错了。

快进到今天——在写代码超过 25 年之后，Java 不仅成为我职业生涯的地基，更是我在 2025 年依然真诚推荐给开发者的语言。下面是 Java 如何改变我看法的故事，以及为什么我认为它仍然值得你现在投入时间去学习。

从怀疑者到倡导者

我第一次真正“用起来” Java，是在 2000 年代中期加入一家做手机软件的咨询公司之后。iPhone 和第一批 Android 设备刚刚发布，突然之间，我们不需要再用 C 去实现底层协议与应用。平台把我们需要的大部分能力都准备好了——我们可以把精力放在“构建产品”上，而不是与内存管理和手写集合类较劲。

有人告诉我，自从我在 1.0 版本时“一票否决”之后，Java 到了 1.6 已经判若两人。出于好奇（也确实是多年手动内存管理之后想换换口味），我去考了 SCJP 6。

那感觉像是发现了一门全新的语言。很多概念还熟悉，但 Java 的成熟度超乎我的预期：更精致、更周到，而且令人惊讶地——值得信赖。

持续演进：让代码更贴近我们的大脑

真正打动我的，并不是某个单点特性，而是这门语言对“开发者体验”的长期打磨：一版接一版地消灭样板、降低心智负担，让我们把注意力放回业务和建模本身。

一个迁移故事：从 Java 1.4 到 Java 7

我参与的第一个大项目，是把一个企业级系统从 Java 1.4 迁到 Java 7。团队已经升级了 JRE，但代码库仍停留在 1.4 年代的写法——连泛型都没用。

我花了几个月，在系统里给集合逐步补上类型：把“无类型的数组”换成“有类型的 List”，给 Map 补齐键和值。我们不必再在脑子里反复背诵“这个集合到底装的是什么”。简单对比一下：

// 泛型之前：高心智负担
List users = getUserList();
for (Iterator it = users.iterator(); it.hasNext(); ) {
    User user = (User) it.next(); // 但愿不要抛出 ClassCastException
    // 处理用户
}

// 泛型之后：意图清晰
List<User> users = getUserList();
for (User user : users) { // 大脑可以专注在业务逻辑
    // 处理用户
}

这不只是“类型安全”，本质上是在“减负”。有了泛型，代码意图一眼明了。

这种“让代码更顺着人脑思考”的演进，一直贯穿 Java：record、sealed、模式匹配、增强的 switch……都在把注意力拉回到领域模型与数据流。

现代 Java：面向数据、意图驱动

// 传统写法：样板多、信噪比低
public class UserStatus {
    private final String status;
    private final String message;
    private final LocalDateTime timestamp;

    // 构造器、getter、equals、hashCode、toString ...
}

// 现代写法：record 聚焦“数据是什么”
public record UserStatus(
    String status,
    String message,
    LocalDateTime timestamp
) {}

// 用 sealed + record 建模有穷结果
public sealed interface LoginResult permits Success, Failure, MfaRequired {}
public record Success(User user, String token) implements LoginResult {}
public record Failure(String reason) implements LoginResult {}
public record MfaRequired(String temporaryToken) implements LoginResult {}

// 模式匹配 + switch：数据驱动的流程控制
String message = switch (loginResult) {
    case Success(var user, var token) -> "欢迎回来，" + user.name();
    case Failure(var reason) -> "登录失败：" + reason;
    case MfaRequired(var tmp) -> "请输入您的 MFA 验证码";
};

当模型是“封闭”的，编译器会帮你做穷尽性校验；当数据结构表达够清晰，流程自然就顺着数据走。

向后兼容：真正的长期职业投资

还记得上面提到的那个从 1.4 迁到 7 的系统吗？它今天跑在 Java 21 上。近二十年间，代码库在“小步演进”中持续获得性能、安全与生产力的红利，没有一次“推翻重来”的重写。

这不只是工程上的成就，更是“职业上的复利”。你今天学会的 Java 技能，五年后依旧好使——它们会被打磨、被增强，但不会被抛弃。

这种承诺来自语言与生态的共识：

谨慎的弃用周期，给迁移留出充足时间。
模块系统考虑兼容性，不强行“破坏式升级”。
预览特性让大家在不锁定的前提下提前试用。
LTS 版本提供企业级的稳定性。

当你把时间投到 Java 上，本质上是在押注一个可持续演化的平台。

有选择，但不混乱

Java 的一个“隐形优势”，是每一层都有健康的竞争与选择——但整体依然稳定：

JDK 分发：Oracle JDK、Azul Zulu、Red Hat OpenJDK、Amazon Corretto；
框架：Spring Boot、Quarkus、Jakarta EE；
构建工具：Maven、Gradle。

这种“多样性 + 一致性”的生态，让你能按场景取舍，而不必担心被某个厂商锁死，或走进技术死胡同。

在我的团队里，我们会：

用 Quarkus 做需要极快启动时间的容器化微服务；
用 Spring Boot 承载复杂业务域；
按部署目标切换合适的 JDK 分发。

这种灵活性，让我们可以“渐进式采用新技术”，而非“彻底重写”。

一个与你一起成长的社区

Java 社区的气质很特别：既欢迎新人、也尊重经验；既追求创新、也珍视稳定；既全球化、也有人情味。

我的社群之路从本地 JUG 开始：先是紧张地旁听，逐步加入讨论，后来站上了 Devoxx Belgium 那样的大会舞台。一路走来，得到的反馈总是具体、真诚、可操作。

对我帮助巨大的社区资源包括：

foojay.io：及时了解 Java 走向；
本地 JUG：与同好交流、彼此成就；
开源项目：把最佳实践落到真实代码；
技术博客与大会：系统性深入某一主题。

社区不仅“传播知识”，更“创造知识”：优秀的库与框架、清晰的文档与博客、高质量的分享与工作坊、耐心的指导与 Code Review。

2025 年的 Java：为什么依然重要

AI 革命需要可靠的地基

是的，大家都在谈 AI 和机器学习。但总得有人把“可靠、可扩展、可观测”的工程地基打好。Java 在企业开发、微服务、高性能计算上的积淀，让它天然适合承载 AI 应用的“非模型层”：任务编排、数据管道、API 网关、鉴权审计、监控追踪、成本与配额治理……

天生的云原生范式

现代 Java 框架（比如 Quarkus、Micronaut）从第一天就瞄准云原生：

借助 GraalVM Native Image 获得更快启动与更低内存；
容器环境友好，内置可观测性；
与 Kubernetes、Service Mesh 无缝协作；
对配置、密钥与滚动升级有一流支持。

可持续的软件工程

Java 强调可读、可维护、强兼容，这和“可持续软件工程”的理念高度一致。系统越复杂、寿命越长，能在十年尺度上稳定演化的技术栈，越有竞争力。

市场与职业机会

即便到了 2025 年，Java 依然是企业、金融科技、物流零售、政府与公共事业等行业的主力。岗位面广、梯度全：从底层中间件到业务系统，从数据平台到云平台，都能看到它的身影。

给 2025 年的 Java 学习路径（精简版）

如果你打算在 2025 年系统学习 Java，我建议这样循序渐进：

语言与标准库：熟悉集合、并发、I/O、时间 API、Stream；
现代特性：record、sealed、pattern matching、switch 表达式、虚拟线程；
工程化能力：Maven/Gradle、JUnit、Testcontainers、Docker；
Web 与微服务：Spring Boot 或 Quarkus（各选其一深入）；
云原生：Kubernetes 基础、可观测性（OpenTelemetry）、配置管理与金丝雀发布；
性能与诊断：JFR、JIT/GC 基础、常见性能陷阱；
安全与合规：鉴权与授权、密钥管理、审计与合规基线。

结语

学一门语言，既是技术选择，也是职业选择。Java 用二十多年的稳定演进，证明了它的可靠与远见。对今天的你而言，它依旧是值得学习、值得长期投入的“地基型技术”。

我的公众号

我的博客地址：博客主页。

coding 笔记、读书笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

Mac mini 家庭网络设置内网穿透

Wed, 14 May 2025 00:00:00 +0800

前言

在拼多多上花 2899 块钱买了一个 M4 16G 256G 的 Mac Mini，因为手里本来有一个对外提供的 web 服务，还为此买了阿里云 ECS 和云数据库，就想把这个当成一个服务器。

整体步骤

向运营商索要家庭宽带的公网 IP
光猫改成桥接模式
为 Mac mini 分配固定的局域网 IP
Mac mini 设置、加固
路由器做端口映射
内网穿透

向运营商索要家庭宽带的公网IP

检查自己家的网络是否是 10.x.x.x、100.64.x.x、192.168.x.x 这类保留网段，说明被运营商 NAT 或 CG‑NAT，并不是真正的独享公网 IP——此时就算做端口映射也无法从外网直连，需要穿透方案（Tailscale / frp 等）。

检查自己是否是公网方案 1：命令行

最简单的方案，通过命令行获取：

curl -4 ifconfig.co

加 -4 强制获取 IPv4；想看 IPv6 则 curl -6 ifconfig.co。
还可以用 curl https://api.ipify.org 或 curl https://ipinfo.io/ip，效果相同。

动态公网 IP：运营商可能在断电、重新拨号、乃至定期轮换时给你新的 IP。若想域名永久指向家里，需要 DDNS 客户端每隔几分钟检测并更新。

如果不是动态公网IP，需要拨打运营商电话让其开通。动态公网IP是免费的，静态公网IP是要花钱的，大概每个月100块钱。动态公网IP虽然会变，但是配合域名或免费的ddns等方案能够实现和静态公网IP一样的效果。

检查自己是否是公网方案 2：打开路由器设置

也可以打开路由器或光猫的设置界面，一般是 http://192.168.1.1，看互联网的 IPv4 地址。

光猫改成桥接模式

我的宽带光猫并不是桥接模式，在设置的过程中光猫和路由器都要进行nat。但是最终发现如果光猫不是桥接模式的话，双层nat非常麻烦，而且运营商会把端口阉割，导致无法进行内网穿透。需要打电话给联通客服，让其更改，肯定是会给改的。

确认宽带接入方式
- 如果 ISP 给的是 PPPoE 用户名 / 密码，把它填到小米路由器的 上网设置 → 拨号上网 (PPPoE)。
- 光猫改成 桥接 (Bridge) 模式，或者找运营商客服把光猫改桥接。
路由器重新拨号后，WAN IP 应变成 111.194.140.* 这类公网地址。
之前做的 外 3333 → 内 22 映射立即生效，外网 ssh -p 3333 user@<新公网 IP> 就能连。

优点：只有一层 NAT，最干净；端口映射、 DDNS 都在小米路由器里完成。

缺点：需要光猫支持桥接；部分运营商可能不提供拨号账号，需联系客服申请。

为 Mac mini 分配固定的局域网 IP

1 · 在 Mac mini 上开启 SSH 服务

操作	说明
系统设置界面	 > 系统设置 > 通用 > 共享 > 打开远程登录 (Remote Login)，勾选仅允许下列用户并添加自己的账号。
终端命令	`sudo systemsetup -setremotelogin on` （和图形界面作用相同）

检查端口：执行 sudo lsof -iTCP:22 -sTCP:LISTEN，若能看到 sshd 进程，说明 22 端口已监听。

2 · 给 Mac mini 分配固定的局域网 IP

进入路由器后台，找到 DHCP 静态绑定 / 地址保留。
记录 Mac mini 的 MAC address，将其绑定到如 192.168.1.100。
重新获取地址或重启以生效。

固定内网 IP 能确保端口映射永远指向同一台机器。

3 · 在路由器上做端口映射 (Port Forwarding)

选项	建议
外部端口 (WAN)	若 ISP 不屏蔽 22，可直接用 22；否则可改成 2222 或其他高位端口。
内部 IP	你的 Mac mini 内网地址，例如 `192.168.1.100`。
内部端口 (LAN)	22 （Mac mini 上 sshd 默认端口）。

保存后，路由器会把来自公网 <家庭公网 IP>:外部端口 的流量转发到 Mac mini 的 22 端口。

Mac mini 设置、加固（必做）

只用密钥登录

  bash
  复制编辑
  # 在本地电脑生成密钥
  ssh-keygen -t ed25519 -C "your_email@example.com"
    
  # 把公钥拷到 Mac mini
  ssh-copy-id -p 22 user@ssh.example.com
    

禁用密码登录、限制用户

编辑 /etc/ssh/sshd_config：

  conf
  复制编辑
  PermitRootLogin no
  PasswordAuthentication no
  AllowUsers your_user_name
  Port 22            # 如改用 2222，记得同步修改
    

保存后 sudo launchctl stop com.openssh.sshd && sudo launchctl start com.openssh.sshd 重载配置。

安装防暴力工具

  bash
  复制编辑
  brew install sshguard     # fail2ban 的 macOS 替代品
  sudo brew services start sshguard
    

定期打补丁

softwareupdate --all --install --restart

路由器做端口映射

在路由器里设置，如下图所示。我将 Mac mini 的内部 ip 地址固定设置成了 192.168.31.100，对外部的 2222 端口映射到内部的 ssh 22 端口；同时也设置了范围转发规则列表。

每个路由器页面可能有差距，但是这些功能基本都是有的。

内网穿透

说明：其实这里不是必须的，现在已经有了一个动态的公网 IP 地址，只是在路由器重启等情况下会自动分配新的地址。如果只是个人使用，直接拿公网 IP 地址或者免费的 DDNS 提供商即可。不过免费的 DDNS 国内好用的不多，我也没有实际使用过，走国外服务器代理的话速度太慢且不能自定义，就放弃了。

我是在阿里云官网购买了一个 .top 域名，180 块钱 10 年。之后就是在官网配置记录，比如申请的域名是 abc.top，配置一个主机记录 ai，即可访问 ai.abc.top。配置官方文档已经很详细了。

在配置好后，就可以使用域名访问了，还要解决最后一个问题：这里配置的记录值 IP 是固定的，但是我们是动态公网 IP，是会变化的。所以需要在 mac 上使用 aliyun-ddns 脚本，这个脚本会自动检测 mac 本机的 IP 地址是否变化，如果有变化就更新上面截图中的域名主机记录。

aliyun-ddns 的 github 链接：https://github.com/risfeng/aliyun-ddns-shell。官方 README.md 非常详细了，本文不再赘述。

说明

这样就能够通过域名在任意地点、任意网络访问家里的 mac 了，可以当成一个服务器来使用。

Yano 的 2024 观影总结

Tue, 31 Dec 2024 00:00:00 +0800

前言

2024 年马上就要过去了，总结下自己在 2024 年看过的影视作品。

PS：我是用 Cursor 写的，有一些文字可能是 Cursor 自动补全的，不是我写的 0_o

电影

《怪物》

看完电影总能想到《进击的巨人》，每个人都没有错，但是误会就是这么产生了。很深刻。

《时空恋旅人》

之前因为名字以为是烂片，有次高铁上无聊路上看完，男主和爸爸最后的对话过于感人……引用豆瓣的评论：奇怪的是，回到过去这项超能力，最终教会我们的却是头也不回地往前走。

《首尔之春》

我不了解韩国的历史，在等待最后所谓的“正义胜利”，但是事实上并没有。一个国家的命运，也只是在少数人推动的，最后发展到了武装冲突不可回头的道路。

想到播客里有人提到河森堡的微博，大意是　“你以为社会是一台精密仪器，各行精英谨慎周密地维持其运转，但经历越多越发现这个社会就是个草台班子，一小撮精英带一大帮混子，尽最大努力维持着社会的底线而已” 。

其他

《通往夏天的隧道，再见的出口》
《最完美的离婚 2014 特别篇》
《年会不能停》
《从 21 世纪安全撤离》
《蓦然回首》
《飞驰人生 2》
《土拨鼠之日》
《周处除三害》
《春宵苦短，少女前进吧！》
《勿言推理》
《秘密会议》
《关于我和鬼变成家人的那件事》
《沙丘 2》
《名侦探柯南：黑铁的鱼影》
《抓娃娃》
《你想过怎样的人生》

电视剧

《最完美的离婚》

汪总提议看这部剧的时候，我的第一反应是两个人看这部剧是不是不太吉利……但是追剧根本停不下来，为什么日本拍这种剧能这么细腻，结尾两次写信的情感，是十几年后的今天国产剧也拍不出来的吧……

看完这部剧，在脑海中深深记住了其中一句台词：一个人吃的叫饲料，两个人在一起吃的才叫饭。

《9 号秘事》第 9 季

系列的最后一季，因为情怀所以满分。每一集的形式都不一样，虽然是单元剧的形式，五星好评！

《唐朝诡事录之西行》

第二季的质量明显更高了，可以看出编剧的用心，甚至都有点“强迫症”，比如每个案件必须是正好几集，不会出现一集中一半是上一个案件、一半是下一个案件的情况；同时主角 5 人都恰到好处。

《勿言推理》

整部剧的剧情、人物都很细腻，推理深入有反转。但是结局？为什么会这样拍？甚至不如去掉最后两集。

其他

《甜蜜家园》

动漫

《全职猎人》

为了能够坚持运动，在跑步机上用 iPad 看《全职猎人》的动漫……每天在椭圆机或跑步机走 1~2 集（20~40 分钟）的时间~

从鲸鱼岛篇的温馨，到猎人考试篇的冒险，到揍敌客篇的友情，到天空竞技场、友客鑫幻影旅团的惊险，再到贪婪之岛的脑洞大开，蚂蚁篇的黑暗，会长选举篇以及前往黑暗大陆航行。我可太喜欢全职猎人了！五星不解释。

《灵能百分百》第三季

剧情不落俗套，最后将的父亲抱着必死的决心，却因为最后回头看了下将，想到自己的老婆孩子，就放弃了牺牲自我的念头，走的时候将还在担心路人以后的结局会是什么样？师傅和路人两人互相拯救，五星不解释。

《弥留之国的爱丽丝》漫画二刷

在出差路途上二刷的漫画，作者想要讲的故事非常完整，而且没有拖沓。里面每个人都是主角，只不过作者以男主的视角出发去思考。里面很多事件都是同时发生的，男主角也只是完成了其中的一部分事件而已。

《英雄联盟：双城之战》第二季

我没有英雄联盟的背景知识，第一季单纯因为剧情和制作入坑，第二季排上来是因为第一季的滤镜吧……话说第二季政治正确太严重了，女拳要素过多；且最后一集故事体量顶之前三集，结局太太太仓促突兀。

其他

《灵能百分百》
《灵能百分百》第二季
《排球少年剧场版：观念之战》
《排球少年剧场版：才能与感觉》
《排球少年剧场版：胜者与败者》
《排球少年剧场版：结束与开始》
《进击的巨人》最终季完结篇前篇
《进击的巨人》最终季完结篇后篇
《从零开始的异世界》第三季
《进击的巨人》最终季 Part.1
《秘密关卡》第一季
《进击的巨人》最终季 Part.2
《鬼灭之刃》柱训练篇
《超自然武装当哒当》
《葬送的芙莉莲》

游戏

经过我在某个手游抽卡六连歪，写了篇文章分析概率崩铁抽卡五连歪，关于抽卡游戏的一些思考（五连歪后，又歪了一次），然后弃坑了……经过思考得出了一个适合我的结论：手游是个无底洞，不要碰！

今年玩的游戏如下：

《超级马力欧兄弟惊奇》
《塞尔达传说：智慧的再现》
《塞尔达传说：王国之泪》
《杀戮尖塔》
《小丑牌》
《斯普拉遁 3》（废弃）
《女神异闻录 5》战略版（废弃）

综艺

《喜人奇妙夜》
《魔方新世界》
《大侦探》第九季
《名侦探的假期》

APP 截图

豆瓣

B 站年度总结

Apple Music 年度总结

我的公众号

我的博客地址：博客主页。

coding 笔记、读书笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

JDK 23 新特性解析

Mon, 30 Dec 2024 00:00:00 +0800

1. 前言

JDK 23 是 Java SE 平台版本 23 的参考实现，2024 年 9 月 17 日正式发布。本文将详细解析 JDK 23 的主要新特性。

2. 新特性总览

JEP	特性名称	状态	说明
455	模式中的原始类型、`instanceof` 和 `switch`	预览	扩展模式匹配，允许在所有模式上下文中使用原始类型，并在 `instanceof` 和 `switch` 中支持原始类型
466	类文件 API	第二次预览	提供用于解析、生成和转换 Java 类文件的标准 API，简化对类文件的操作
467	Markdown 文档注释	正式发布	允许在 JavaDoc 中使用 Markdown 语法编写文档注释，提高文档的可读性和编写效率
469	向量 API	第八次孵化	提供用于表达向量计算的 API，支持在运行时编译为最优的向量指令，提升数值计算性能
473	流收集器	第二次预览	增强流 API，支持自定义中间操作，使流管道能够以更灵活和富有表现力的方式转换数据
471	弃用 `sun.misc.Unsafe` 中的内存访问方法	正式发布	计划移除 `sun.misc.Unsafe` 中的内存访问方法，鼓励开发者迁移到更安全的替代 API
474	ZGC：默认的分代模式	正式发布	将 Z 垃圾收集器（ZGC）的默认模式切换为分代模式，以提升垃圾回收性能
476	模块导入声明	预览	引入模块导入声明，允许开发者简洁地导入模块导出的所有包，简化模块化库的重用
477	隐式声明的类和实例主方法	第三次预览	允许在没有显式声明类的情况下编写主方法，简化初学者的编程体验
480	结构化并发	第三次预览	通过引入结构化并发，将相关任务视为单个工作单元，简化并发编程中的错误处理和取消操作
481	作用域值	第三次预览	提供一种在线程内和线程之间共享不可变数据的机制，适合大量虚拟线程的场景
482	灵活的构造函数体	第二次预览	允许在构造函数中，在显式的 `super()` 或 `this()` 调用之前出现语句，增强构造函数的灵活性

3. 详细解析

JEP 455：模式中的原始类型、`instanceof` 和 `switch`（预览）

JEP 455（预览版）旨在增强 Java 的模式匹配功能，允许在所有模式上下文中使用原始类型，并扩展 instanceof 和 switch 以支持所有原始类型。

为什么要引入这个功能：

在现有的 Java 版本中，模式匹配主要针对引用类型，限制了对原始类型的处理能力。这导致在处理原始类型时需要额外的类型转换和检查，增加了代码复杂性。通过支持原始类型的模式匹配，Java 语言将变得更加统一和表达力更强，减少开发者在处理不同类型时的心智负担。

目标：

统一数据处理：允许对所有类型（无论是原始类型还是引用类型）使用类型模式进行匹配。
简化类型检查：使 instanceof 操作符能够直接处理原始类型，减少不安全的类型转换。
增强 switch 语句：使 switch 能够处理任何原始类型的值，提升代码的可读性和简洁性。

简要使用示例：

在 switch 中使用原始类型模式：

switch (x.getStatus()) {
    case 0 -> System.out.println("Status: OK");
    case 1 -> System.out.println("Status: Warning");
    case 2 -> System.out.println("Status: Error");
    case int i -> System.out.println("Unknown status: " + i);
}

在这个示例中，switch 语句直接对 int 类型的 status 进行匹配，并在默认情况下使用 int i 模式捕获未明确列出的状态值。

在 instanceof 中使用原始类型模式：

Object obj = ...;
if (obj instanceof int i) {
    System.out.println("Integer value: " + i);
} else {
    System.out.println("Not an integer");
}

此示例展示了使用 instanceof 检查对象是否为 int 类型，并在匹配时直接将其赋值给变量 i。

JEP 466：类文件 API（第二次预览）

JEP 466（第二次预览）旨在提供一个用于解析、生成和转换 Java 类文件的标准 API。

为什么要引入这个功能：

随着 JDK 的六个月发布周期，类文件格式演变的频率增加，现有的第三方库（如 ASM、BCEL 等）可能无法及时跟上这些变化。这导致框架开发者在处理比其捆绑的类文件库更新的类文件时，可能遇到错误或需要进行不安全的假设。因此，需要一个与 JDK 同步更新的标准类文件库，以确保兼容性和可靠性。

目标：

提供标准 API：提供一个与 Java 虚拟机规范中定义的类文件格式保持一致的 API。
支持 JDK 组件迁移：使 JDK 组件能够迁移到该标准 API，减少对第三方库的依赖。

简要使用示例：

解析类文件并收集依赖项：

CodeModel code = ...;
Set<ClassDesc> deps = new HashSet<>();
for (CodeElement e : code) {
    switch (e) {
        case FieldInstruction f  -> deps.add(f.owner());
        case InvokeInstruction i -> deps.add(i.owner());
        // 处理其他类型的指令
    }
}

在这个示例中，CodeModel 描述了一个 Code 属性。通过迭代其 CodeElement，可以匹配感兴趣的指令类型，并收集相关的类依赖项。

生成类文件中的方法：

假设我们希望在类文件中生成以下方法：

void fooBar(boolean z, int x) {
    if (z)
        foo(x);
    else
        bar(x);
}

使用 Class-File API，可以通过构建器模式生成该方法的字节码。

通过引入 Class-File API，JEP 466 使得 Java 开发者能够更方便地处理类文件，确保与最新的类文件格式兼容，并减少对第三方库的依赖。

JEP 467：Markdown 文档注释

JEP 467 引入了在 JavaDoc 文档注释中使用 Markdown 语法的功能，使得文档注释的编写和阅读更加简洁易懂。

为什么要引入这个功能：

传统的 JavaDoc 注释主要使用 HTML 和特定的 JavaDoc 标签进行标记，这在 1995 年是合理的选择。然而，HTML 语法繁琐，手动编写既费时又容易出错，尤其对于不熟悉 HTML 的开发者而言更是如此。Markdown 是一种轻量级标记语言，具有简洁、易读、易写的特点，已在开发者社区中广泛使用。引入 Markdown 语法可以简化文档注释的编写过程，提高代码的可读性和可维护性。

目标：

简化文档编写：允许在文档注释中使用 Markdown 语法，使注释更易于编写和阅读。
保持兼容性：确保现有的文档注释不会受到影响，继续支持 HTML 和 JavaDoc 标签。
扩展编译器 API：增强编译器树 API，使其他工具能够处理文档注释中的 Markdown 内容。

简要使用示例：

传统 JavaDoc 注释：

/**
 * 返回对象的哈希码值。此方法用于支持像 {@link java.util.HashMap} 这样的哈希表。
 * <p>
 * {@code hashCode} 的一般约定是：
 * <ul>
 * <li>在 Java 应用程序的执行期间，当在同一对象上多次调用时，
 *     只要对象上用于 {@code equals} 比较的信息没有被修改，
 *     {@code hashCode} 方法必须始终返回相同的整数。
 *     该整数在同一应用程序的不同执行中不需要保持一致。
 * <li>如果根据 {@link #equals(Object) equals} 方法，两个对象是相等的，
 *     那么对这两个对象中的每一个调用 {@code hashCode} 方法必须产生相同的整数结果。
 * <li>如果两个对象根据 {@link #equals(Object) equals} 方法不相等，
 *     则不要求对每个对象调用 {@code hashCode} 方法必须产生不同的整数结果。
 *     但是，程序员应该意识到，为不相等的对象生成不同的整数结果可以提高哈希表的性能。
 * </ul>
 */

使用 Markdown 的 JavaDoc 注释：

/**
 * 返回对象的哈希码值。此方法用于支持像 {@link java.util.HashMap} 这样的哈希表。
 *
 * `hashCode` 的一般约定是：
 *
 * - 在 Java 应用程序的执行期间，当在同一对象上多次调用时，
 *   只要对象上用于 `equals` 比较的信息没有被修改，
 *   `hashCode` 方法必须始终返回相同的整数。
 *   该整数在同一应用程序的不同执行中不需要保持一致。
 * - 如果根据 {@link #equals(Object) equals} 方法，两个对象是相等的，
 *   那么对这两个对象中的每一个调用 `hashCode` 方法必须产生相同的整数结果。
 * - 如果两个对象根据 {@link #equals(Object) equals} 方法不相等，
 *   则不要求对每个对象调用 `hashCode` 方法必须产生不同的整数结果。
 *   但是，程序员应该意识到，为不相等的对象生成不同的整数结果可以提高哈希表的性能。
 */

通过引入 Markdown 语法，文档注释变得更加简洁明了，减少了对繁琐 HTML 标签的依赖，提高了代码的可读性。

JEP 469：向量 API（第八次孵化）

JEP 469（第八次孵化）旨在引入一个 API，用于表达向量计算，使其在运行时可靠地编译为支持的 CPU 架构上的最优向量指令，从而实现比等效标量计算更高的性能。

为什么要引入这个功能：

向量计算（SIMD）允许在单个指令中对多个数据进行并行处理，显著提高性能。然而，Java 缺乏直接支持向量计算的标准 API，开发者需要依赖平台特定的解决方案或手动优化。引入统一的向量 API，可以使开发者编写的代码在不同硬件平台上具有可移植性，并充分利用底层硬件的向量指令集，提高计算效率。

目标：

清晰简洁的 API：提供一个能够清晰、简洁地表达各种向量计算的 API，使其可在循环和可能的控制流中组合使用。开发者应能够编写与向量大小无关的通用计算，从而在支持不同向量大小的硬件上实现可移植性。
平台无关性：API 应该是 CPU 架构无关的，支持在多个具有向量指令的架构上实现。在平台优化和可移植性冲突的情况下，API 将偏向于可移植性，即使这意味着某些平台特定的习惯用法无法在可移植代码中表达。
可靠的运行时编译和性能：在支持的 x64 和 AArch64 架构上，Java 运行时（特别是 HotSpot C2 编译器）应将向量操作编译为相应的高效向量指令，如 SSE、AVX（x64）和 NEON、SVE（AArch64）。开发者应确信他们表达的向量操作将可靠地映射到相关的向量指令。
优雅的降级：当在运行时无法将向量计算完全表达为向量指令序列时，API 实现应优雅地降级并继续工作。这可能涉及在无法高效编译为向量指令时发出警告。在不支持向量的平台上，优雅的降级将产生与手动展开循环相当的代码，其中展开因子是所选向量的通道数。
与 Project Valhalla 的对齐：长期目标是利用 Project Valhalla 对 Java 对象模型的增强，特别是将当前的值基类更改为值类，使程序能够处理没有对象标识的值对象。

简要使用示例：

以下是使用向量 API 进行向量加法的示例：

import jdk.incubator.vector.*;

public class VectorAddition {
    public static void main(String[] args) {
        // 创建向量规范，指定向量类型和长度
        VectorSpecies<Integer> SPECIES = IntVector.SPECIES_PREFERRED;

        // 初始化数组
        int[] a = {1, 2, 3, 4, 5, 6, 7, 8};
        int[] b = {8, 7, 6, 5, 4, 3, 2, 1};
        int[] c = new int[a.length];

        // 使用向量 API 进行加法运算
        for (int i = 0; i < a.length; i += SPECIES.length()) {
            // 将数组加载到向量
            var va = IntVector.fromArray(SPECIES, a, i);
            var vb = IntVector.fromArray(SPECIES, b, i);
            // 向量加法
            var vc = va.add(vb);
            // 将结果存储回数组
            vc.intoArray(c, i);
        }

        // 输出结果
        System.out.println(Arrays.toString(c));
    }
}

在这个示例中，VectorSpecies 定义了向量的类型和长度。通过将数组的数据加载到向量中，执行向量化的加法操作，然后将结果存储回数组，实现了高效的并行计算。

JEP 473：流收集器（第二次预览）

JEP 473（第二次预览）旨在增强 Stream API，以支持自定义的中间操作，从而使流管道能够以现有内置中间操作难以实现的方式来转换数据。

为什么要引入这个功能：

Java 8 引入了 Stream API，提供了一组固定的中间和终端操作，如映射、过滤、归约、排序等。然而，对于某些复杂任务，这些固定的中间操作可能不足以表达所需的流处理逻辑。例如，假设需要对字符串流进行去重，但基于字符串长度而非内容的唯一性。现有的 distinct 操作基于对象的相等性，无法满足这一需求。为此，需要引入自定义的中间操作，以实现更灵活的流数据转换。

目标：

提高流管道的灵活性和表达能力：允许开发者定义自定义的中间操作，以满足特定的数据处理需求。
支持对无限大小的流进行操作：确保自定义的中间操作能够有效地处理无限流。

简要使用示例：

假设我们希望对字符串流进行基于字符串长度的去重操作。通过引入自定义的中间操作 distinctBy，可以实现如下功能：

var result = Stream.of("foo", "bar", "baz", "quux")
                   .distinctBy(String::length) // 假设的自定义操作
                   .toList();

// result ==> [foo, quux]

在这个示例中，distinctBy 是一个自定义的中间操作，基于提供的键提取函数（此处为 String::length）来确定元素的唯一性。这样，结果列表中将包含每个长度的第一个字符串。

通过引入自定义的中间操作，JEP 473 使得开发者能够以更直观和可维护的方式来表达复杂的流处理逻辑，提升了代码的可读性和灵活性。

JEP 471：弃用 `sun.misc.Unsafe` 中的内存访问方法

JEP 471 提议将 sun.misc.Unsafe 类中的内存访问方法标记为弃用，计划在未来的 JDK 版本中移除这些方法。这些不受支持的方法已被标准 API 所取代，主要包括在 JDK 9 中引入的 VarHandle API（JEP 193）和在 JDK 22 中引入的外部函数与内存 API（JEP 454）。我们强烈建议库开发者从 sun.misc.Unsafe 迁移到受支持的替代方案，以便应用程序能够顺利迁移到现代 JDK 版本。

为什么要引入这个功能：

sun.misc.Unsafe 类于 2002 年引入，旨在让 JDK 内部的 Java 类执行低级操作。然而，其内存访问方法可能导致未定义行为，包括 JVM 崩溃。因此，这些方法并未作为标准 API 暴露。随着时间的推移，已经引入了安全且高效的标准 API 来替代这些不安全的方法。因此，现在是时候弃用并最终移除 sun.misc.Unsafe 中的内存访问方法。

目标：

为未来的移除做准备：为在未来的 JDK 版本中移除 sun.misc.Unsafe 中的内存访问方法做好准备。
提高开发者意识：帮助开发者意识到他们的应用程序何时直接或间接地依赖于 sun.misc.Unsafe 中的内存访问方法。

简要使用示例：

以下是使用 VarHandle API 替代 sun.misc.Unsafe 的示例：

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

public class VarHandleExample {
    private int value;

    public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
        VarHandleExample example = new VarHandleExample();
        VarHandle varHandle = MethodHandles.lookup().findVarHandle(VarHandleExample.class, "value", int.class);

        // 使用 VarHandle 读取字段值
        int currentValue = (int) varHandle.get(example);
        System.out.println("Current value: " + currentValue);

        // 使用 VarHandle 更新字段值
        varHandle.set(example, 42);
        System.out.println("Updated value: " + example.value);
    }
}

在这个示例中，VarHandle API 提供了一种安全且高效的方式来访问和修改对象的字段，而无需使用不安全的 sun.misc.Unsafe 方法。

JEP 474：ZGC：默认的分代模式

JEP 474 提议在 Java 23 中将 Z 垃圾收集器（ZGC）的默认模式切换为分代模式，并弃用非分代模式，计划在未来的版本中移除。

为什么要引入这个功能：

维护非分代 ZGC 会减缓新特性的开发。正如 JEP 439 所述，分代 ZGC 应该在大多数用例中优于非分代 ZGC。因此，最终用分代 ZGC 取代非分代 ZGC 可以降低长期的维护成本。

目标：

聚焦分代 ZGC 的未来开发：通过将默认模式切换为分代模式，表明未来的开发将专注于分代 ZGC。
减少维护成本：支持两种不同模式会增加维护成本，切换默认模式并弃用非分代模式有助于降低这些成本。

简要使用示例：

在此更改之前，启用 ZGC 的默认模式是非分代模式，需要显式指定分代模式：

java -XX:+UseZGC -XX:+ZGenerational ...

在应用 JEP 474 后，默认模式将是分代模式，因此只需启用 ZGC 即可：

java -XX:+UseZGC ...

如果仍需使用非分代模式，可以显式禁用分代模式，但会收到弃用警告：

java -XX:+UseZGC -XX:-ZGenerational ...

请注意，使用 -XX:-ZGenerational 将启用非分代 ZGC，并会收到以下警告：

警告: 选项 ZGenerational 已被弃用，将在未来版本中移除。警告: 非分代模式已被弃用，计划在未来版本中移除。

因此，建议迁移到分代 ZGC，以确保未来版本的兼容性和性能优化。

JEP 476：隐式声明的类和实例主要方法（第三次预览）

JEP 476 提议在 Java 编程语言中引入模块导入声明，使开发者能够简洁地导入模块所导出的所有包，从而简化模块化库的重用。

为什么要引入这个功能：

随着 Java 平台的发展，许多关键类和接口（如 List、Map、Stream 和 Path）并不位于 java.lang 包中，因此需要手动导入多个包。这增加了代码的复杂性，特别是在使用模块化库时。通过引入模块导入声明，开发者可以一次性导入模块所导出的所有包，减少样板代码，提高开发效率。

目标：

简化模块化库的重用：允许一次性导入整个模块，减少多个包导入声明的冗余。
降低学习曲线：使初学者无需深入了解包层次结构即可使用第三方库和 Java 标准类。
无需模块化自身代码：使用模块导入功能的开发者不需要将自己的代码模块化。

简要使用示例：

假设我们需要使用 java.sql 模块中的功能，传统方式需要导入多个包：

import java.sql.*;
import javax.sql.*;

使用模块导入声明，可以简化为：

import module java.sql;

这将导入 java.sql 模块导出的所有包中的公共顶级类和接口，简化了代码编写。

JEP 477：隐式声明的类和实例主方法

JEP 477 提议在 Java 编程语言中引入隐式声明的类和实例 main 方法，旨在使初学者能够编写简洁的程序，而无需理解为大型程序设计的语言特性。

为什么要引入这个功能：

Java 语言以其丰富的特性在构建大型、复杂的应用程序方面表现出色。然而，对于初学者而言，这些特性可能显得过于复杂。通过引入隐式声明的类和实例 main 方法，初学者可以在不涉及复杂概念的情况下编写简单程序，从而降低学习曲线。

目标：

提供平滑的 Java 编程入门途径：使讲师能够逐步引入概念，帮助学生以简洁的方式编写基本程序，并随着技能的提升，优雅地扩展他们的代码。
减少编写小型程序的繁琐：例如脚本和命令行工具，无需引入为大型程序设计的构造。
避免引入独立的 Java 方言或工具链：小型 Java 程序应使用与大型程序相同的工具进行编译和运行。

简要使用示例：

传统的 “Hello, World!” 程序需要包含类声明和静态 main 方法：

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

使用隐式声明的类和实例 main 方法，可以简化为：

void main() {
    System.out.println("Hello, World!");
}

在此示例中，省略了类声明和静态方法修饰符，使代码更简洁，便于初学者理解。

JEP 480：结构化并发（第三次预览）

JEP 480 提议在 Java 编程语言中引入结构化并发的 API，以简化并发编程。结构化并发将一组在不同线程中运行的相关任务视为一个工作单元，从而简化错误处理和取消操作，提高可靠性，并增强可观察性。

为什么要引入这个功能：

在传统的非结构化并发模型中，开发者需要手动管理线程的生命周期、错误处理和取消操作，这增加了代码的复杂性和出错的风险。结构化并发通过将相关任务作为一个整体进行管理，确保任务的启动和终止具有明确的结构，减少了线程泄漏和取消延迟等常见问题，提高了代码的可维护性和可靠性。

目标：

推广结构化并发编程风格：通过引入新的 API，鼓励开发者采用结构化并发的方式编写代码，减少并发编程中的常见错误。
提高并发代码的可观察性：提供更好的工具和方法来监控并发任务的执行状态，便于调试和性能优化。

简要使用示例：

以下是使用结构化并发 API 的示例代码：

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Future<String>  user  = scope.fork(() -> findUser());
    Future<Integer> order = scope.fork(() -> fetchOrder());
    scope.join();           // 等待所有子任务完成
    scope.throwIfFailed();  // 如果有子任务失败，则抛出异常
    // 所有子任务成功，获取结果
    String theUser  = user.resultNow();
    int    theOrder = order.resultNow();
    return new Response(theUser, theOrder);
}

在这个示例中，StructuredTaskScope 用于管理并发任务的生命周期。fork() 方法用于启动子任务，join() 方法等待所有子任务完成，throwIfFailed() 方法在任何子任务失败时抛出异常。这样，相关的并发任务被作为一个整体进行管理，简化了错误处理和资源管理。

需要注意的是，结构化并发 API 是一个预览特性，默认情况下是禁用的。要在 JDK 23 中使用此功能，需要在编译和运行时启用预览特性。

JEP 481：作用域值（第三次预览）

JEP 481 提议在 Java 编程语言中引入作用域值（Scoped Values），使方法能够在同一线程内与其被调用的方法以及子线程共享不可变数据。与线程局部变量相比，作用域值更易于理解，并且在与虚拟线程（JEP 444）和结构化并发（JEP 480）结合使用时，具有更低的空间和时间成本。

为什么要引入这个功能：

在传统的 Java 并发编程中，线程局部变量（ThreadLocal）用于在同一线程内共享数据。然而，线程局部变量存在一些缺点，例如可变性、不受限制的生命周期以及在多线程环境下的性能开销。作用域值通过提供不可变且受限生命周期的数据共享机制，解决了这些问题，提高了代码的可维护性和性能。

目标：

易用性：使数据流更易于理解。
可理解性：共享数据的生命周期应从代码的语法结构中清晰体现。
健壮性：调用者共享的数据应仅能被合法的被调用者获取。
性能：应能够在大量线程之间高效地共享数据。

简要使用示例：

以下是使用作用域值的示例代码：

import jdk.incubator.concurrent.ScopedValue;

public class Example {
    // 定义一个作用域值
    private static final ScopedValue<String> USER_ID = ScopedValue.newInstance();

    public static void main(String[] args) {
        // 设置作用域值并调用方法
        ScopedValue.where(USER_ID, "user123").run(() -> {
            process();
        });
    }

    public static void process() {
        // 在作用域内获取值
        String userId = USER_ID.get();
        System.out.println("Processing for user: " + userId);
    }
}

在此示例中，USER_ID 被定义为一个作用域值。在 main 方法中，通过 ScopedValue.where 方法设置 USER_ID 的值，并在作用域内调用 process 方法。在 process 方法中，可以通过 USER_ID.get() 获取设置的值。

JEP 482：灵活的构造函数体（第二次预览）

JEP 482 提议在 Java 编程语言中允许构造函数体中的语句可以出现在显式构造函数调用（如 super(..) 或 this(..)）之前。这些语句不能引用正在构建的实例，但可以初始化其字段。在调用其他构造函数之前初始化字段，使得在方法被重写的情况下，类的构造函数更加可靠。

为什么要引入这个功能：

在 Java 中，构造函数的首条语句必须是对另一个构造函数的显式调用（如 super(..) 或 this(..)）。这种限制有时会导致代码不够灵活，特别是在需要在调用父类构造函数之前进行参数验证或字段初始化的情况下。通过允许在显式构造函数调用之前添加语句，开发者可以更自然地编写构造函数逻辑，而无需依赖辅助静态方法或中间构造函数。

目标：

提供更大的构造函数表达自由度：使开发者能够更自然地编写构造函数逻辑，减少对辅助方法的依赖。
保持构造顺序的保证：确保在类实例化过程中，构造函数仍然按照从上到下的顺序执行，子类构造函数的代码不会干扰父类的实例化过程。

简要使用示例：

以下是使用灵活构造函数体的示例代码：

public class PositiveBigInteger extends BigInteger {

    public PositiveBigInteger(long value) {
        if (value <= 0) throw new IllegalArgumentException("Value must be positive");
        super(value);
    }
}

在此示例中，在调用父类构造函数 super(value) 之前，先验证了参数 value 是否为正值。这在以前的 Java 版本中是不允许的，但通过 JEP 482 的引入，这种模式现在是合法的。

公众号

coding 笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

我的博客地址：博客主页。

《任天堂传奇：游戏产业王者归来》

Sun, 01 Dec 2024 00:00:00 +0800

1. 百年企业的成长历程

1889 年，山内房治郎在京都创立了 Nintendo Koppai（任天堂骨牌），最初专注于制作日本传统纸牌花札。在创立之初，山内房治郎就确立了对品质的极致追求，这成为了贯穿任天堂百年历史的核心价值观。

二战后的日本百业待兴，此时年轻的山内溥接任社长之位。在他的带领下，任天堂开始了多元化的探索。从玩具制造到出租车服务，从爱情旅馆到食品行业，山内溥带领团队在不同领域寻找机会。这段探索虽然大多以失败告终，但为任天堂积累了宝贵的经验。

1966 年是任天堂发展史上的重要转折点。公司成立玩具部门，开发了 Ultra Hand 等创新玩具，获得了不错的市场反响。这次成功坚定了山内溥进军娱乐产业的决心。1975 年，任天堂获得了 Magnavox Odyssey 在日本的代理权，由此正式进入电子游戏领域。

电子游戏为任天堂带来了新生。1980 年推出的 Game & Watch 开创了便携式游戏的先河，1983 年发布的 Family Computer（红白机）更是奠定了任天堂在游戏产业的霸主地位。值得一提的是，正是在市场最低迷的 1983 年，任天堂反其道而行之推出了 FC，这个决策的成功挽救了整个北美游戏市场。

在游戏主机领域站稳脚跟后，任天堂又于 1989 年推出了革命性的 Game Boy 掌机。搭配《俄罗斯方块》等经典游戏，Game Boy 系列统治掌机市场近 20 年。2006 年，体感游戏机 Wii 的推出再次证明了任天堂的创新能力，它成功实现了”扩大游戏人口”的战略目标。到了 2017 年，Switch 的发布又一次改变了人们对游戏主机的认知。

2. 铸就传奇的关键人物

山内溥：铁腕社长的远见

山内溥担任任天堂社长长达 53 年（1949-2002），是任天堂现代化转型的关键人物。他以强势的领导风格著称，但同时也以敏锐的商业直觉和慧眼识才闻名。正是他力排众议，坚持进军电子游戏产业；也是他招募了宫本茂等天才创意人才。

山内溥建立的品质管理制度至今仍在影响着任天堂。”宁可延期，也要保证品质”的理念，让”任天堂品质”成为了业界标杆。他的经营理念可以总结为：重视创新、注重品质、尊重人才。

宫本茂：游戏界的创意天才

如果说山内溥为任天堂指明了方向，那么宫本茂就是在这条道路上不断创造奇迹的人。作为《超级马里奥》《塞尔达传说》等传奇游戏的缔造者，宫本茂将游戏设计提升到了艺术的高度。

他的设计理念看似简单：游戏必须有趣。但在这个简单的理念背后，是对游戏本质的深刻理解。宫本茂认为，一款好的游戏应该容易上手但需要时间精通，这样的设计理念在他的每部作品中都得到了完美体现。

岩田聪：程序员出身的新时代领袖

2002 年，岩田聪成为任天堂首位非山内家族的社长，也是首位程序员出身的社长。他带来了更开放的企业文化，创立了”社长提问”栏目，加强了与员工和玩家的沟通。在他的领导下，任天堂推出了 DS 和 Wii 两款现象级产品，成功开拓了全新的市场。

在任天堂遭遇困境时，岩田聪选择主动降薪也不裁员，展现了对员工的责任感。他的理念是：游戏应该让所有人快乐，而不是仅仅服务于硬核玩家。

3. 主机与游戏的进化史

主机发展历程

家用主机

主机名称	发售时间	主要特点	代表作品
FC/NES	1983	• 8位主机时代的王者 • 挽救了北美游戏市场 • D-pad 十字键的创新设计	• 超级马里奥兄弟 • 塞尔达传说 • 恶魔城
Super Famicom/SNES	1990	• 16位主机的标杆 • Mode 7 图形技术 • 优秀的音效芯片	• 超级马里奥世界 • 星之卡比 • 最终幻想 6
Nintendo 64	1996	• 首个 3D 游戏主机 • 坚持使用卡带存储 • 创新的手柄设计	• 超级马里奥 64 • 塞尔达传说：时之笛 • 黄金眼 007
GameCube	2001	• 首次采用光盘介质 • 性能强大但销量一般 • 独特的紫色外观	• 银河战士 Prime • 皮克敏 • 生化危机 4
Wii	2006	• 革命性的体感控制 • 开创休闲游戏市场 • 全球销量破亿	• Wii Sports • 超级马里奥银河 • Wii Fit
Wii U	2012	• 创新的双屏游戏体验 • 支持向下兼容 • 市场表现不佳	• 马里奥赛车 8 • 喷射战士 • 超级马里奥制作器
Switch	2017	• 家用机与掌机的结合 • 可分离式手柄设计 • 持续热销的现象级产品	• 塞尔达传说：旷野之息 • 超级马里奥奥德赛 • 集合啦！动物森友会

掌机系列

主机名称	发售时间	主要特点	代表作品
Game & Watch	1980	• 最早的便携式电子游戏 • LCD 显示屏 • 简单但耐玩的游戏性	• Ball • Donkey Kong • Mario Bros
Game Boy	1989	• 开创掌机时代 • 超长续航时间 • 经济实惠	• 俄罗斯方块 • 精灵宝可梦红/绿 • 超级马里奥大陆
Game Boy Color	1998	• 彩色显示屏 • 向下兼容 GB 游戏 • 体积小巧	• 塞尔达传说：不可思议的果实 • 精灵宝可梦金/银 • 超级马里奥大陆 DX
Game Boy Advance	2001	• 32 位处理器 • 横向设计 • SNES 级画质	• 马里奥卡丁车 • 火焰之纹章 • 宝可梦红宝石/蓝宝石
Nintendo DS	2004	• 创新的双屏设计 • 触控操作 • Wi-Fi 联机功能	• 新超级马里奥兄弟 • 脑力训练 • 精灵宝可梦钻石/珍珠
Nintendo 3DS	2011	• 裸眼 3D 显示 • 内置陀螺仪 • AR 游戏功能	• 马里奥卡丁车 7 • 怪物猎人 4 • 精灵宝可梦 X/Y

经典游戏 IP

IP 名称	首作时间	系列特点	主要作品	全球影响
马里奥	1985	• 跳跃平台玩法的标杆 • 简单易上手难精通 • 创新不断	• 超级马里奥兄弟 • 超级马里奥 64 • 超级马里奥奥德赛	• 全球销量超 3.8 亿份 • 多个吉尼斯纪录 • 衍生多个子系列
塞尔达传说	1986	• 探索解谜为核心 • 开放世界的先驱 • 剧情与玩法结合	• 时之笛 • 黄昏公主 • 旷野之息	• 影响众多开放世界游戏 • 多次获得年度游戏 • 深受欧美市场欢迎
精灵宝可梦	1996	• 收集培养玩法 • 社交对战元素 • 完整的商业生态	• 红/绿 • 金/银 • 剑/盾	• 全球文化现象 • IP 价值超 1000 亿美元 • 动画、周边等产业链
火焰之纹章	1990	• 策略 RPG 玩法 • 角色间羁绊系统 • 永久死亡机制	• 封印之剑 • 觉醒 • 风花雪月	• SRPG 类型代表作 • 在日本市场特别受欢迎 • 动画及手游改编
星之卡比	1992	• 可爱画风 • 复制能力系统 • 适合全年龄段	• 超级豪星 • 重返梦幻岛 • 星之盟友	• 深受儿童喜爱 • 衍生动画作品 • HAL 研究所代表作
大金刚	1981	• 街机游戏起源 • 平台动作玩法 • 经典角色设定	• 大金刚 • 大金刚国家 • 热带急冻	• 任天堂最早的成功作 • 奠定马里奥系列基础 • 多次成功重启

4. 任天堂的产业影响

任天堂对游戏产业的影响是全方位的。在硬件方面，从 D-pad 十字键到体感控制，任天堂创造了诸多行业标准。在软件方面，从《超级马里奥》确立的平台跳跃类游戏标准，到《塞尔达传说》开创的开放世界玩法，任天堂一直在引领游戏设计的潮流。

在商业模式上，任天堂建立了硬件与软件协同发展的典范。通过第一方工作室的精品游戏支撑硬件平台，再通过硬件创新反哺游戏开发，形成了良性循环。任天堂还深谙 IP 经营之道，将游戏 IP 延伸到动画、主题乐园等领域。

与索尼、微软等竞争对手相比，任天堂始终坚持自己的道路。不盲目追求硬件性能，而是专注于创新玩法；不一味迎合成熟玩家，而是致力于扩大游戏受众。这种差异化策略让任天堂在激烈的竞争中保持了独特的市场地位。

5. 启示与思考

任天堂的成功給我们带来了深刻的启示。首先是坚持长期主义的重要性，百年老店的成功不是靠短期利益最大化，而是通过持续创新和品质保证赢得用户信任。其次是差异化战略的价值，在竞争中保持自我，往往比盲目追随对手更容易成功。

人才培养方面，任天堂的经验也值得借鉴。公司既重视创意人才的培养，给予充分的创作自由，又建立了严格的品质管理体系，这种平衡保证了创新与品质的统一。

展望未来，任天堂仍面临着来自移动游戏、云游戏等新形态的挑战。但正如其历史所证明的，只要坚持创新、注重品质、以用户体验为先，任天堂就能继续引领游戏产业的发展。

后记

今年去日本旅游，特意去了京都的任天堂总部打卡~~~

coding 笔记、读书笔记、点滴记录，以后的文章也会同步到公众号（Coding Insight）中，大家关注 ^_^

我的博客地址：博客主页。

JDK 22 新特性解析

Sat, 03 Aug 2024 00:00:00 +0800

前言

JDK 22 是 Java SE 平台版本 22 的参考实现，2024 年 3 月 19 日正式发布。本文将详细解析 JDK 22 的主要新特性。

主要特性

1. Statements before super(…) (预览功能)

目标: 允许在构造函数中调用 super(...) 之前执行语句。

背景:

一个类继承另一个类时，子类继承父类，并且子类可以通过声明自己的字段和方法进而添加新的功能。子类声明字段的初始值可以依赖父类字段的初始值，因此在子类初始化之前，必须先初始化父类的字段。

按照顺序初始化字段，意味着构造函数必须从上到下执行：超类中的构造函数必须在子类中的构造函数运行之前完成字段初始化。这也意味着，某个类的构造函数在超类构造函数完成前，不能访问自身或任何超类中的字段。

为了确保构造方法能够从上到下执行，Java 语言规定 super(...) 必须是构造函数的第一条语句。这样做的目的是确保在子类构造函数执行之前，父类构造函数已经完成。如果没有显式地调用 super(...)，Java 编译器会自动插入 super()。

为了确保构造函数不能访问未初始化的字段，Java 语言要求如果给出了显式构造函数调用，参数不能以任何方式访问当前对象。但是上述要求有些过于严格：

示例：验证超类构造函数参数

我们可能需要验证传递给超类构造函数的参数。

public class PositiveBigInteger extends BigInteger {

    public PositiveBigInteger(long value) {
        super(value);               // Potentially unnecessary work
        if (value <= 0)
            throw new IllegalArgumentException("non-positive value");
    }

}

如果我们可以在这段代码中，校验逻辑放在前面，那么就不需要调用 super(value) 了，而且也更容易理解。希望能改成下面这样：

public class PositiveBigInteger extends BigInteger {

    public PositiveBigInteger(long value) {
        if (value <= 0)
            throw new IllegalArgumentException("non-positive value");
        super(value);
    }

}

示例：准备超类构造器函数

我们可能需要在调用超类构造函数之前，准备一些数据。下面的代码，由于超类构造函数必须是子类构造函数的第一条语句，所以我们只能声明辅助方法 prepareByteArray 来准备该调用的参数。

public class Sub extends Super {

    public Sub(Certificate certificate) {
        super(prepareByteArray(certificate));
    }

    // Auxiliary method
    private static byte[] prepareByteArray(Certificate certificate) { 
        var publicKey = certificate.getPublicKey();
        if (publicKey == null) 
            throw new IllegalArgumentException("null certificate");
        return switch (publicKey) {
            case RSAKey rsaKey -> ...
            case DSAPublicKey dsaKey -> ...
            ...
            default -> ...
        };
    }

}

如果我们可以在调用超类构造函数之前，准备参数，那么就不需要声明辅助方法了，而且也更容易理解。希望能改成下面这样：

public Sub(Certificate certificate) {
    var publicKey = certificate.getPublicKey();
    if (publicKey == null) 
        throw new IllegalArgumentException("null certificate");
    final byte[] byteArray = switch (publicKey) {
        case RSAKey rsaKey -> ...
        case DSAPublicKey dsaKey -> ...
        ...
        default -> ...
    };
    super(byteArray);
}

2. Foreign Function & Memory API

目标: 高效、安全地调用外部函数和访问本机的堆外内存。

背景：

Java 打造了一个跨平台的虚拟机，无论是访问远程数据（JDBC）、调用 Web 服务（HTTP 客户端）、为远程客户端提供服务（NIO 通道），还是与本地进程通信（Unix 域套接字）都很方便。但是 Java 开发人员访问本机对外内存时却很麻烦。

堆外内存的重要性：

在 Java 中，使用 new 关键字创建的对象存储在 JVM 的堆中。当不再需要时，这些对象可能会被垃圾回收。然而对于性能关键的库（如 TensorFlow、Ignite、Lucene 和 Netty）来说，垃圾回收的成本和不可预测性是无法接受的。这些库需要将数据存储在堆外内存中，这些库自己分配和释放这些内存。访问堆外内存还允许通过直接将文件映射到内存，例如通过 mmap 来对数据进行序列化和反序列化。

Java 之前已经提供了 2 个用于访问堆外内存的 API：

ByteBuffer API：提供了 direct 字节缓冲区，这些是由固定大小的堆外内存区域支持的 Java 对象。区域的最大大小仅限于 2GB，而且用于读写内存的方法很基础且容易出错，仅提供对原始值的索引访问。直接字节缓冲区的内存只有在缓冲区对象被垃圾回收时才会被释放，而开发人员无法控制这一过程。
sun.misc.Unsafe API：提供了对堆内、堆外内存的底层访问。

希望给 Java 开发人员提供一个更好的 API，能够灵活且安全分配、操作堆外内存。

使用方法:

JDK 22 引入了 Foreign Function & Memory API，下面的例子获取 C 库函数 radixsort 的方法句柄的 Java 代码，并使用它对四个起源于 Java 数组的字符串进行排序（省略了一些细节）。简要示例如下：

// 1. Find foreign function on the C library path
Linker linker          = Linker.nativeLinker();
SymbolLookup stdlib    = linker.defaultLookup();
MethodHandle radixsort = linker.downcallHandle(stdlib.find("radixsort"), ...);
// 2. Allocate on-heap memory to store four strings
String[] javaStrings = { "mouse", "cat", "dog", "car" };
// 3. Use try-with-resources to manage the lifetime of off-heap memory
try (Arena offHeap = Arena.ofConfined()) {
    // 4. Allocate a region of off-heap memory to store four pointers
    MemorySegment pointers
        = offHeap.allocate(ValueLayout.ADDRESS, javaStrings.length);
    // 5. Copy the strings from on-heap to off-heap
    for (int i = 0; i < javaStrings.length; i++) {
        MemorySegment cString = offHeap.allocateFrom(javaStrings[i]);
        pointers.setAtIndex(ValueLayout.ADDRESS, i, cString);
    }
    // 6. Sort the off-heap data by calling the foreign function
    radixsort.invoke(pointers, javaStrings.length, MemorySegment.NULL, '\0');
    // 7. Copy the (reordered) strings from off-heap to on-heap
    for (int i = 0; i < javaStrings.length; i++) {
        MemorySegment cString = pointers.getAtIndex(ValueLayout.ADDRESS, i);
        javaStrings[i] = cString.reinterpret(...).getString(0);
    }
} // 8. All off-heap memory is deallocated here
assert Arrays.equals(javaStrings,
                     new String[] {"car", "cat", "dog", "mouse"});  // true

上面这段代码比任何使用 JNI 的方法都清晰，因为原本隐藏在 native 方法调用背后的隐式转换和内存访问现在直接使用 Java 代码表达。

3. Unnamed Variables & Patterns

目标:

声明但不使用的变量可以使用 _ 代替，以提高代码可读性。

背景:

无论是出于代码风格的考虑，还是在某些特殊情况下，开发者可能会声明一些他们并不打算使用的变量。在编写代码时，开发者明知道这些变量不会被使用，但是没有办法明确记录这一点，后面的维护者可能会意外使用这些变量。希望能引入一种机制，让开发者明确地表达这些变量不会被使用，使代码更具有信息性、可读性，并且跟不容易出错。

一个未命名变量通过使用下划线字符_（U+005F）来代替局部变量声明语句中的变量名。

例如之前在循环中计算 total，但是不实用循环变量 order：

static int count(Iterable<Order> orders) {
    int total = 0;
    for (Order order : orders)    // order is unused
        total++;
    return total;
}

可以改成：

static int count(Iterable<Order> orders) {
    int total = 0;
    for (Order _ : orders)    // Unnamed variable
        total++;
    return total;
}

另一个例子是，表达式的副作用比其结果更重要的情况，以下代码出队数据，但只需每三个元素中的两个即可，第三次调用 remove() 具有期望的副作用 — 即使其结果未分配给变量，也会出队一个元素，因此可以省略声明 z。

Queue<Integer> q = ... // x1, y1, z1, x2, y2, z2 ..
while (q.size() >= 3) {
   int x = q.remove();
   int y = q.remove();
   int z = q.remove();            // z is unused
    ... new Point(x, y) ...
}

可以改成：

Queue<Integer> q = ... // x1, y1, z1, x2, y2, z2 ..
while (q.size() >= 3) {
   int x = q.remove();
   int y = q.remove();
   int _ = q.remove();            // Unnamed variable
    ... new Point(x, y) ...
}

发布计划

2023/12/07: Rampdown Phase One
2024/01/18: Rampdown Phase Two
2024/02/08: Initial Release Candidate
2024/02/22: Final Release Candidate
2024/03/19: General Availability

总结

JDK 22 引入了多个新特性和预览特性，旨在提升 Java 的性能、简化开发流程并增强代码安全性。。

关于抽卡游戏的一些思考

Sat, 20 Jul 2024 00:00:00 +0800

前言

最近《崩坏：星穹铁道》抽卡五连歪，想写点文字吐槽一下。

我的抽卡情况

五连歪，几乎每次都是大保底，而且每次必歪杰帕德。因为我之前就是游戏服务端开发工程师，也会去做抽奖相关的功能，所以对抽卡逻辑实现有一定的了解。要说崩铁抽卡概率完全是按照游戏抽卡界面文字描述实现的话，那是不可能的。

抽卡概率分析

我的实际情况是：

抽花火 110 抽，35 抽歪了姬子。
抽黄泉 153 抽，74 抽歪了杰帕德。
抽流萤 1+0，一共花费 266 抽，分别 77 抽和 76 抽歪了两次杰帕德。
补阮梅，一共花费 132 抽，76 抽歪了杰帕德。

每次都歪的概率

不算姬子歪的概率，只算黄泉开始的 4 连歪普通池的概率：

如果每次歪的概率是 ( p )，则连续 ( n ) 次都歪的概率可以用以下公式表示：

[ P = p^n ]

其中，( p ) 是单次歪的概率，而 ( n ) 是连续歪的次数。每次歪的概率是 0.5，连续四次都歪的概率计算为：

[ P = (0.5)^4 = 0.0625 = 6.25\% ]

4 次连续歪杰帕德的概率

五星角色，除了当期 up 外，还有 7 位角色，且每次的事件都是相互独立的。不讨论歪的角色是杰帕德，只讨论连续四次歪同一个角色的概率：

如果每次抽中特定角色的概率是 ( \frac{1}{7} )，则连续 ( n ) 次都抽中特定角色的概率可以用以下公式表示：

[ P = \left(\frac{1}{7}\right)^n ]

其中，( p = \frac{1}{7} ) 是单次抽中特定角色的概率，而 ( n = 4 ) 是连续抽中特定角色的次数。

但是第一次其实抽什么都无所谓，我们要看的是后三次抽中的结果和第一次一致，因此 n = 3，连续四次都抽中同一角色的概率计算为：

[ P = \left(\frac{1}{7}\right)^3 = 0.002915 = 0.2915\% ]

连续 4 次大保底，且是杰帕德的概率

因为歪与歪的角色是独立事件，所以连续 4 次大保底，且是杰帕德的概率计算为：

[ P = 0.0625 \times 0.002915 = 0.000182 = 0.0182\% ]

就这概率，我难道不是万里挑一吗……买彩票啥时候能有这运气。

崩铁抽卡的吐槽

抽卡定价高

一个 up 角色综合各种保底率，大概 110 抽左右，这个只算 0+0 的情况。每个大版本不氪金估计 60 抽吧，大小月卡 90 抽。至于氪金除开首充，人民币 648 块钱才 40 抽，平民玩家太高了。

抽卡体验差

至少对于我的抽卡体验来说，每次都是大保底，而且每次都歪。我充了大小月卡，充了 648 块钱，辛辛苦苦攒了两三百抽都不如别人欧一下，这种体验真的很差。

游戏体验不完整

一个角色有 6 命，还有专武，专武最高还有 5 阶。有的角色 0 命机制不完整，需要 1 命或 2 命，辛辛苦苦做任务攒一个月跳一个角色池，抽到的角色还是个残疾人。明明知道这个角色下一命会很强，机制不一样，但是就是用不了。

与其他游戏的对比

米家游戏基本都是 PVE，42 天更新一个大版本，其余时间吃草。虽然崩铁每日任务已经非常非常简化了，但是还会有如果不登录就会错过一些芝麻奖励的焦虑。

相比之下，即使原价买的《塞尔达传说：王国之泪》也比不过这个游戏的 30 抽，甚至连一个角色的一个命座或一个专武都抽不出来（数学期望 110+ 抽）。

思考及叠甲

米家抽卡机制

我明白米哈游抽卡是为了挣钱，这些游戏氪金都是有上限的，且比很多 PVP 游戏氪金上限低很多。但是现在抽卡已经是拖累游戏体验的一部分了。玩 ZZZ 的时候我就想，如果这个游戏没有抽卡，而是每个角色都明码标价或角色是租赁模式（一个角色每个命座 1 天 5 块钱这种），我会不会玩得更开心？

崩铁游戏性

崩铁剧情还是很好的，也做到了文化输出，而且游戏确实更轻量化、一直优化。

我想要玩什么样的游戏？

如果一个角色能够明码标价就好了，比如 100 块钱或 10000 星穹一命。也许是我太非了，反正我现在游戏体验不好，我最近一直大小月卡，但是现在因为抽卡体验太差已经不开了。我是一个普通玩家，这就是我玩这个游戏的心路历程，肯定不是个例。

叠甲

上面的概率分析并不是 100% 准确，只是基于游戏抽卡界面文本给出的信息。
我只是因为五连歪吐槽一下，每个月大小月卡攒了很久跳卡池最终抽卡体验是这样，肯定是会变得佛系的。
星铁我还是会玩，但是会佛系，不会再氪金了。甚至会连每日任务都不做，只是偶尔玩玩剧情。
对于抽卡，可能的建议是：
- 不要全勤连续登录，不要全任务肝完，这样系统会判定为高活跃度玩家，抽卡概率会变低。
- 不要在角色池刚出的前两天抽卡，系统会为了流水降低概率，等到最后几天再抽。
从我个人的情况来看，单机游戏也许更适合我。玩几个手游每天都跟打卡上班一样，而且也不是完整的游戏体验。

Yano

20260816 随笔

《塞尔达·王国之泪》-全套装、全收集截图

ZELDA NOTES 截图

套装截图

收集品截图

Yano 的 2025 观影总结

前言

历年观影总结

电影

《美洲大宝荐：你好美国》

《南京照相馆》

《因果报应》

《哪吒之魔童闹海》

《年少日记》

《哆啦A梦：大雄的绘画奇遇记》

其他

电视剧

《悠长假期》

《四重奏》

《重版出来！》

《唐朝诡事录之长安》

其他

动漫

《Bug Ego》漫画

《弥留之国的爱丽丝》漫画 三刷

《JOJO 的奇妙冒险：STEEL BALL RUN》漫画

《胆大党》第一季、第二季

《凡人修仙传》

其他

游戏

《斯普拉遁 3》

《塞尔达传说：王国之泪》

其他

综艺

《明星大侦探》第十季

豆瓣截图

我的公众号

Skill：让 Agent 变得可复用、可控、可演进

Skill：让 Agent 变得可复用、可控、可演进

前言：为什么要把“提示词经验”升级成 Skill

一、Skill 是什么

1.1 一句话定义：Skill 解决了什么问题

1.2 Skill 的组成：说明、契约、边界、失败处理

1.3 一张图看懂：Skill 的“可验收执行链”

1.4 Skill 的颗粒度：什么时候拆，什么时候合

二、为什么需要 Skill

2.1 复用：把个人经验变成团队资产

2.2 可控：让结果稳定，过程可解释

2.3 降低上下文膨胀：按需注入，而不是永久塞进系统提示词

2.4 团队协作视角：写 Skill 像写 SOP，用 Skill 像调用函数

三、Skill 和 MCP 的区别

3.1 典型误区：把 Skill 当 Tool，或把 MCP 当工作流引擎

3.2 一个直观类比：Skill 是“代码结构”，MCP 是“依赖注入”

四、如何设计一个“好用”的 Skill

4.1 先写 Non-Goals：不做什么，比做什么更重要

4.2 再写校验点：每一步都可验证、可中断、可回退

4.3 最后写触发条件：什么时候该用这个 Skill

4.4 一个可复用的 Skill 模板（推荐）

4.5 实战案例：Java 代码审查 Skill

五、在 Claude Code 和 Cursor 上落地 Skill

5.1 Claude Code：把 Skill 当成“可发现的能力包”

5.2 Cursor：用 .cursor/rules/*.mdc 组织“类 Skill”

5.3 与 MCP 的配合：用 .cursor/mcp.json 把工具接入作为能力底座

5.4 Skill 的测试与调试

六、结尾：Skill 的本质，是把“工作方法”产品化

我的公众号

Notion AI 初体验

Notion AI 初体验

前言

我的书影清单

Notion AI 的杀手锏

实战一：一键统计与复盘

实战二：懒人福音，自动补全字段

进阶玩法：给 AI 写“员工手册”

碎碎念：关于限制和注意事项

总结

我的公众号

如何画好一张架构图

架构

《弥留之国的爱丽丝》漫画三刷

`Skill`：让 Agent 变得可复用、可控、可演进

前言：为什么要把“提示词经验”升级成 `Skill`

一、`Skill` 是什么

1.1 一句话定义：`Skill` 解决了什么问题

1.2 `Skill` 的组成：说明、契约、边界、失败处理

1.3 一张图看懂：`Skill` 的“可验收执行链”

1.4 `Skill` 的颗粒度：什么时候拆，什么时候合

二、为什么需要 `Skill`

2.4 团队协作视角：写 `Skill` 像写 `SOP`，用 `Skill` 像调用函数

三、`Skill` 和 `MCP` 的区别

3.1 典型误区：把 `Skill` 当 `Tool`，或把 `MCP` 当工作流引擎

3.2 一个直观类比：`Skill` 是“代码结构”，`MCP` 是“依赖注入”

四、如何设计一个“好用”的 `Skill`

4.1 先写 `Non-Goals`：不做什么，比做什么更重要

4.3 最后写触发条件：什么时候该用这个 `Skill`

4.4 一个可复用的 `Skill` 模板（推荐）

五、在 `Claude Code` 和 `Cursor` 上落地 `Skill`

5.1 `Claude Code`：把 `Skill` 当成“可发现的能力包”

5.2 `Cursor`：用 `.cursor/rules/*.mdc` 组织“类 `Skill`”

5.3 与 `MCP` 的配合：用 `.cursor/mcp.json` 把工具接入作为能力底座

5.4 `Skill` 的测试与调试

六、结尾：`Skill` 的本质，是把“工作方法”产品化

五、`agent-all-in-one` 中的四种典型 Agent 范式