该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/agent-native-dev-framework

Agent-Native 开发框架设计

原文：Agent-Native 开发框架设计

• 第一层：模块化能力
  • 登录，支付，存储，多语言，SEO，后台这些通用功能如何做成一个低耦合可插拔的模块
• 第二层：流程化工程
  • 初始化项目，加模块，页面，CI/CD，部署等这些开发动作如何抽象成标准的流程（skills）
• 第三层：Agent工程
  • tools，skills，context，memory，workflow怎么设计，怎么运转
• 第四层：平台化视角
  • 如何让别人和agent都能够更高效的开发

离技术越近，离商业越远

原文：离技术越近，离商业越远

核心观点：在AI时代，怎么做出来不稀缺，怎么卖出去更稀缺

• AI的真正价值不是在于帮你多做，而是在于帮你快速证伪
• 对赚钱闭环来说，技术不是起点，对高质量职业发展来说，技术依然是护城河
• AI 时代真正稀缺的，不再只是把功能做出来，而是知道什么值得做，以及怎样低成本验证它。

与 AI 一起做产品的六条原则

原文：与 AI 一起做产品的六条原则

AI时代产品设计，如何做好人和AI的分工边界

1. AI 是放大器，人的判断依旧是核心

2. AI 擅长做加法，人要做减法

   如果页面只能留一个按钮，是什么？

3. AI 擅长平均值，人要提供独特的品味

   • 且要把品味沉淀成可复用的 context（skill，文档）

4. AI 擅长表面功夫，只有人才能共情

   • 很炫酷的动画，页面，但也只是炫酷，无法打动人

5. AI 可以无限生成，但人要保证一致性

   • 同一个按钮出现三次，要把用户适应的心智成本降到最低

ClaudeCode/Codex 节省80%Token

• 总费用 = input token（占60-90%）+ output token（占10-30%）
• 最大黑洞：项目文件自动读取

思路：

减少无效文件读取 → 压缩上下文 → 精简指令 → 选对模型
     ↓                 ↓              ↓            ↓
   省 60%           省 50%          省 40%       省 30%

1. .claudeignore

# .claudeignore
node_modules/
dist/
build/
.next/
__pycache__/
*.lock
package-lock.json
*.log
.git/
.idea/
.vscode/
*.png
*.jpg
*.svg
coverage/

2. 善用 /compact 和 /memory

3. 善用Plan Mode 弄清需求

记忆管理

参考：GitHub - TencentDB-Agent-Memory | 我用了这个工具，Token消耗量降了60%

模拟人脑的分层记忆：

├─ 短期记忆：任务地图（Mermaid）
│  └─ 只保留结构，细节存到外部文件
├─ 长期记忆：分层沉淀
│  ├─ L0：原始对话（兜底）
│  ├─ L1：事件/偏好/约束（原子记忆）
│  ├─ L2：场景聚合（同一话题）
│  └─ L3：用户画像（稳定偏好）
└─ 检索机制：需要时精准召回

两个核心设计：

1. 短期记忆：符号化压缩（解决长任务问题）

任务：调研 AI Infra 领域的最新进展

AI 的工作流程：
1. 搜索 "AI Infra 2024"，原文存到 file_001.txt
   ├─ 上下文只保留："搜索 AI Infra，发现 3 个关键趋势"
   └─ Mermaid 任务地图：[搜索] → [发现趋势]

2. 读文章1，原文存到 file_002.txt
   ├─ 上下文只保留："趋势 1：多模态向量检索"
   └─ 任务地图：[搜索] → [发现趋势] → [深挖趋势1]

3. 需要回顾文章1？→ 去 file_002.txt 读取原文
   └─ 而不是一直占据上下文

优势：
✓ 上下文始终保持轻量（只有任务地图）
✓ AI 能看到完整任务结构（不会迷路）
✓ 需要细节时可以随时找回原文（100% 可溯源）

2. 长期记忆：分层沉淀（解决跨会话问题）

第 1 天对话：
你："我在做简历优化工具，目标用户是大学生。
     核心功能：10 秒诊断简历问题，
     不做编辑器，只做诊断"

Agent Memory 自动沉淀：
├─ L1（原子记忆）：
│  ├─ 事实："项目是简历优化工具"
│  ├─ 事实："目标用户是大学生"
│  ├─ 约束："只做诊断，不做编辑"
│  └─ 偏好："强调 10 秒快速"
├─ L2（场景记忆）：
│  └─ 场景："简历优化项目"
│      ├─ 关联记忆：上述 4 条
│      └─ 时间线：2026-06-12 第 1 次讨论
└─ L3（用户画像）：
    └─ "用户偏好做减法、强调速度、注重用户体验"

第 2 天对话：
你："继续优化简历诊断功能"

AI 自动召回：
├─ 检索到场景："简历优化项目"
├─ 加载 L1 记忆：项目背景、核心约束
└─ 直接回答："好的，我们继续优化诊断功能。
    根据之前的讨论，核心是 10 秒内给出 3 条最致命问题..."

优势：
✓ 不用重复交代背景（省时间）
✓ 不用手动粘贴历史（省 Token）
✓ AI 能记住你的偏好和约束（保持一致性）
✓ 所有记忆可追溯到原始对话（100% 可验证）

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/harness-engineering-guide

::: link-card href="https://mp.weixin.qq.com/s/Pbhyg8PPHNzhWbMLI732eA" title="Harness 完全指南：harness 是一切工作的核心（1.3万字）" desc="本文内容摘取与李自然老师的文章，写的很好，推荐查看原文" newtab="true"

:::

1. harness 是什么？

Harness是模型之外的一整套运行环境。它决定AI能看到什么、能做什么、不能做什么、做完后如何验证、出错后如何修正、什么时候交还给人。

核心公式：Agent = Model + Harness

• Prompt 是你对AI说什么
• Context 是AI当下看见什么
• Harness 是AI被放进了一个什么样的行动系统

模型是大脑。Harness是大脑之外的一切。

同一个模型，放在不同harness里，可以是两个不同的智能体。 LangChain实验证明：同一个模型不变，只调整模型外面的运行环境，编码智能体在Terminal Bench 2.0上的得分从52.8跳到66.5——13分的差距，完全来自harness那一项。

2. harness 解决了什么问题？如何解决？

问题：AI开始行动后，面对的不再是一个聊天框，而是一个带有不确定性的执行系统。

核心目标：让AI第一次更可能做对；做错后更快知道自己错了。

解决方式：

本质：把非确定性的模型，放进一个尽量可控、可观测、可复盘的系统。

3. harness 的思想是什么？

核心理念

• 围栏是给跑得快的马用的。跑不起来的马，不需要围栏。

  • 早期模型跑不远、跑不稳，不需要harness。当模型能连续跑几小时、跨多个上下文窗口时，能犯的错误也变多了，这时harness才真正必要。

• 能用代码强制的，就不要写成「请记得」。

  • Hook会执行，自然语言会被忘。确定性骨架兜住的地方越多，留给模型自由发挥的空间就越精准。

• 补丁会消失。基础设施不会。

  • 模型变强会吃掉「为弥补模型能力不足而存在的壳」（提示词注入防御、静态命令校验），但反馈层、治理层、上下文层不会消失，只会变得更值钱。

• 自由度只留给真正需要推理的地方。其他地方交给确定性系统。

  • 智能体节点负责需要判断和生成的部分；确定性节点负责检查、提交、测试、拦截。

底层逻辑

这是1948年维纳提出的控制论的核心——前馈给方向，反馈看偏差。AI没有让「控制」这件事过时，只是把它的对象从机器换成了一个比机器更不确定、行动空间更大的系统。

4. harness 的构成是什么？

Harness由六层构成：

层级总览

各层详解

第1层：指令层

• 包括：系统提示词、项目规则文件、AGENTS.md、CLAUDE.md、skills
• 原则：每一条规则都对应一次智能体真实犯过的错，不是「最佳实践大全」，更像踩坑记录
• OpenAI风格：告诉AI「应该做什么」
• Anthropic风格：告诉AI「不能做什么」（更推荐——说清红线，剩下的留给模型发挥）

第2层：上下文层

• 问题：每次模型调用前，要决定塞哪些信息进上下文窗口
• 挑战：信息太少AI不知道情况，信息太多AI被噪音淹没
• 解法：结构化工作状态（如claude-progress.txt），让新会话像接班的工程师一样先读交接记录
• 子智能体的核心价值：隔离噪音——只把干净摘要交回主智能体
• 核心原则：不在上下文里的东西，对AI来说就不存在；不该进上下文的噪音，也会让AI做错判断

第3层：工具层

• 包括：文件读写、命令行、Git、浏览器、数据库、内部API、MCP服务器等
• 反直觉：工具越多，系统提示越长，智能体越容易分心
• 解法：根据任务给AI一组相关工具，不是「以防万一」的全家桶
• 核心原则：工具不是越多越好，而是越清楚越好

第4层：边界层

• 包括：权限、沙盒、网络隔离、文件系统隔离、密钥管理、审批规则
• 设计：拒绝优先（故障即安全）——命中拒绝规则就直接停下，不被其他允许规则覆盖
• 核心原则：爆炸半径要在事故发生前设计好，不要等事故发生后再补救
• 反直觉：边界设计得越清楚，人类越敢把更多事情交给AI

第5层：反馈层

• 包括：测试、类型检查、linter、CI、运行日志、代码review、另一个模型的评估
• 发现：错误消息应该写得像给智能体看的修复提示（不只是「类型不匹配」，要说「应该用 string[]，不是 string」）
• 核心原则：代码质量基础设施，在智能体时代不是锦上添花。它是AI的传感器。
• 没有反馈，AI只能猜。有反馈，他才能修正。

第6层：治理层

• 包括：成本监控、运行日志、审计记录、人工升级、失败复盘、组织级模板、回归评估
• 核心问题：
  • 每个任务最多允许重试几次？
  • 什么情况必须交还给人？
  • 哪些工具调用要记录？
  • 哪些权限需要审批？
  • 一次harness改动之后，如何确认没有造成退化？
• 核心原则：harness不是一个人的prompt文件。它会慢慢变成组织资产。

5. 如何构建自己的 harness？

最小 harness：四件套

project-root/
├── AGENTS.md / CLAUDE.md  规则
├── init.sh                启动入口
├── feature_list.json      任务状态
├── progress.md            进度日志
└── src/                   代码

核心原则：

• 规则文件控制在50-80行以内，不要一上来写成200行
• 一条规则最好对应一次真实失败
• 不要让AI在坏环境里工作
• 每次会话结束前做干净收尾，不要让下一轮AI替上一轮收拾残局

三层成熟度

Level 1：个人级

• 适合独立开发者
• 核心：四件套 + 常用命令 + 最小反馈循环 + 失败日志 + 干净收尾
• 目标：让AI少犯重复错误，每次会话都能稳定接上

Level 2：团队级

• 适合3到20人团队
• 核心：共享规则 + 统一目录结构 + CI必跑项 + PR模板 + 共享脚本 + 共享子智能体
• 原则：把团队共识变成AI也能执行的工程环境。以前靠口头约定和代码review传递的东西，现在要尽量变成规则、脚本、模板和测试

Level 3：组织级

• 适合大公司或生产级智能体
• 核心：工具注册中心 + 权限系统 + 沙盒环境 + 运行日志 + 成本监控 + 人工升级 + 回归评估
• 目标：让智能体成为组织基础设施的一部分

验证方法：对照实验

做两轮对比：

1. 第一轮：只给普通prompt，不给规则文件、不跑初始化、不准备功能状态表。记录AI花了多久、漏了什么、最后你花了多少时间收拾。
2. 第二轮：给最小四件套，按固定会话流程工作。

比较指标：

• 是否只做了一个功能，没有乱扩范围？
• 是否跑了必要验证？
• 是否留下了清楚的进度记录？
• 是否减少了重复解释和返工？
• 下一轮会话能不能直接接上？

最终原则

Harness不是设计出来的，是迭代出来的。从简单开始，让AI跑，看他在哪里摔，再在那里加护栏。每一次真实失败，都是下一版harness的材料。

6. 为什么需要 harness？

直接原因

当模型能连续跑几小时、跨多个上下文窗口接力完成任务时——他能创造的价值变大了，能犯的错误也变多了。

真正的问题不再是「让他更聪明」，而是：

• 他应该看见什么？
• 他能调用什么工具？
• 他不能碰什么？
• 他做完之后怎么知道自己错没错？
• 他连续失败几次之后，什么时候该交还给人？

这些问题加在一起，就是harness engineering。

深层原因

核心判断

Harness将是一切工作的核心。

• 工程化成熟的团队，AI会放大它的能力
• 工程化混乱的团队，AI也会放大它的混乱

补充视角：Cherny vs Osmani 的争论

最终结论：补丁层会被模型吸收。基础层会变得更重要。Harness不会消失，它在演化。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-13

最近真的蛮糟糕的，好像有一种失去了对生活的掌控感，倒不是有外界对我的打破，而是我总是情不自禁的进入到一种失去秩序的循环中，日复一日，我好像真的需要开始练习冥想了。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/claude-desktop-install-guide

1.前置准备安装包

国内如果非指纹浏览器非严格网络环境很难在官网下载安装包，我这里上传到网盘里了，可以直接下载： 链接：https://pan.quark.cn/s/6bde2ce50085?pwd=Z2BP 提取码：Z2BP

2.安装配置（环境最好是全局+TUN模式）

安装完之后

1. 双击打开，不要登录，如图所示，进入开发者模式
2. Developer → Configure third-party inference
3. 配置中转地址和 key，以DeepSeek为例：选择 Gateway，填写Gateway base URL为：https://api.deepseek.com/anthropic ，Gateway API key 填写你的 DeepSeek API key，模型根据你的选择来，可以选择DeepSeek-V4-Flash

3.使用CC Switch任意切换模型

其实上面就可以愉快使用了，但是为了更方便的，我们使用一下CC Switch来随意切换提供商和模型配置

3.1 CC Switch设置中开启路由，如图

3.2配置本地url和key

进入之前进入过的第三方提供商设置，重新填写一下url和key。

url为CC Switch中显示的服务地址，复制即可，例如我的是：http://127.0.0.1:15721

key填写PROXY_MANAGED即可

3.3 添加映射模型名称，为了设置思考强度

往下滚动翻阅，找到 IDENTITY & MODELS 的 Model llst 部分 添加并设置三个模型：

claude-sonnet-4-6
claude-haiku-4-5
claude-opus-4-7

改完后保存，选择 Apply locally，等待重启即可

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/go

https://www.travellings.cn/go.html

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/moments/2026/04/11/perfect-days

2026.04.11

这是一部好好电影，值得看很多次，因为一次感觉有些意犹未尽，好像品出来些什么，但没有“成品”。

首先，这部电影很对我的审美，每一帧都很清新，整洁，有条不紊，其要表达的内涵我也能get到一点，但想要具体用语言描述清楚，也许我还得再看几遍，也许我还得再在生活中历练几段。

所以就我感悟到一些碎片，支离破碎的写一些，希望日后能将其拼凑完整。

1.主角对待生活的态度是我很喜欢，并且心底里隐约向往的，电影里提到的一句“以后是以后，现在是现在”，这句话我认为想表达的就是“活在当下”，也让我联想到《一句顶一万句》里面的“日子是过以后，不是过从前”。

2.主角是享受工作的吗？答案我认为是否。打扫厕所这件事对主角来说其实只是维持生活秩序的手段，从影片中可以看得出来，主角其实是不图钱不图名甚至不图感情（让其自然发生），这很接近我的“本我”，工作是生活中附带的一笔，它像是缝补衣服的麻线，让一些缺口规整起来。

3.那主角在体验或者说追求的是什么？从剧情中他的姐/妹可以看得出来他本来的物质条件是很不错的，住在乡下，独居，做厕所清洁工，这一切必然是他自己的选择。在这些选择背后，我认为主角追求的是“心灵的自由与平静”，他有善良的内心和善于发现美的眼睛，在生活中他凭借这两点就足以获得自己的追求。

无论今天有什么样的情绪波动，发生了什么事，总是按时睡前看书，到点睡觉，准时起床（加班除外哈哈哈），能做到这一点真的难得，主角不是圣人，他会哭，会笑，或者一边哭一边笑；也许他有自己的遗憾或者烦恼，也许他有自己内心的挣扎或者彷徨，但是这一切都不会阻碍：明早我要给我的小树浇水，出门前要买一罐咖啡，路上要听我喜欢的磁带，别忘了和陌生人的井字格游戏，别忘了给大树朋友拍照，别忘了晚上去喝一杯。

最后，生活充满变数，充满意外，但是也充满日升日落，晴天雨天，可能不确定中的一些确定能够让我们更好的面对这一切，加油。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-12

稳住心态，保证睡眠，坚持锻炼，加油

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-11

要把决定做对，而不是做对的决定

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-10

平常心

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/spring-mvc

我一直感觉SpringMVC的执行过程有些抽象，有些概念有点绕，于是我想着先把很多概念了解清楚，最后再把流程给捋清楚，尝试之后对我的理解还是很有效的，这篇文章经过我的整理输出后由AI润色和修正了格式等内容

1. 什么是 Spring MVC

Spring MVC 是 Spring 体系中的 Web MVC 框架，用来帮助我们基于 Servlet 快速开发 Web 应用。

这里的 MVC 指的是：

• Model：模型数据，或者说业务数据
• View：视图，负责展示页面
• Controller：控制器，负责接收请求、组织调用、返回结果

它的核心思想是把请求接入、参数处理、业务调用、结果响应这些职责拆开，让代码结构更清晰。

需要注意一点：Controller 负责的是请求入口和流程协调，真正的业务逻辑通常应该放在 Service 层，而不是全部堆在 Controller 里。

2. 什么是 Servlet

Servlet 本质上是 Java Web 的一套规范，用来定义服务器如何接收 HTTP 请求、如何处理请求、如何返回 HTTP 响应。

像 Tomcat、Jetty 这样的 Web 容器会实现这套规范，并负责：

• 加载 Servlet
• 管理 Servlet 生命周期
• 在请求到来时调用对应的 Servlet

可以把它理解成：Servlet 提供了 Java Web 最基础的请求处理能力，而 Spring MVC 是构建在这套能力之上的更高层封装。

3. Spring MVC 和 Servlet 是什么关系

Spring MVC 是建立在 Servlet 规范之上的。

它的核心入口是 DispatcherServlet。DispatcherServlet 本身就是一个 Servlet，所以它可以像普通 Servlet 一样被 Web 容器加载和调用。

也就是说：

• Web 容器负责把请求交给 DispatcherServlet
• DispatcherServlet 负责在 Spring MVC 内部完成后续流程

后续这些流程包括：

• 路由分发
• 查找处理器
• 参数绑定
• 调用控制器方法
• 处理返回值
• 视图解析或响应体输出

4. Spring MVC 的几个核心组件

4.1 DispatcherServlet 是什么

DispatcherServlet 是 Spring MVC 的核心调度器，也是整个请求处理流程的统一入口。

浏览器发来的请求，通常会先到它这里，再由它决定后续交给谁处理。

它的职责可以概括为：

• 接收请求
• 分发请求
• 协调各个组件一起工作
• 最终生成响应

4.2 HandlerMapping 是什么

HandlerMapping 可以理解成“请求路径到处理器的映射表”。

当请求到来时，它会根据请求信息去找到对应的处理器。匹配条件通常包括：

• URL
• HTTP 请求方法
• 其他请求条件

在注解驱动开发里，Spring 启动时会解析诸如 @RequestMapping、@GetMapping、@PostMapping 这类映射信息，并建立对应关系。

4.3 Controller 和处理器是什么关系

在日常开发里，我们会写很多 @Controller 或 @RestController 类。

对于注解驱动的 Spring MVC 来说，真正执行请求处理逻辑的，通常是 Controller 中某一个具体的方法。这个方法通常就可以理解为当前请求对应的处理器。

也就是说：

• Controller 是处理请求的载体
• 具体的处理器，通常是其中某个带映射注解的方法

所以 HandlerMapping 最终定位到的，通常不是整个类，而是类中的某个方法。

4.4 HandlerAdapter 是什么

HandlerAdapter 可以理解成“处理器执行适配器”。

DispatcherServlet 找到处理器之后，并不是自己直接用反射去调用，而是交给合适的 HandlerAdapter 来执行。

它主要负责：

• 参数解析与绑定
• 类型转换
• 调用目标方法
• 处理方法返回值

在基于注解的 Spring MVC 中，最常见的是 RequestMappingHandlerAdapter。

4.5 ViewResolver 是什么

ViewResolver 是视图解析器。

当控制器返回的是一个“视图名”时，Spring MVC 会通过 ViewResolver 把这个名字解析成真正的视图对象，比如 JSP 或 Thymeleaf 模板。

4.6 HttpMessageConverter 是什么

HttpMessageConverter 是消息转换器。

当前后端分离接口返回的是对象、JSON、XML 等响应体数据时，Spring MVC 会通过它把 Java 对象转换成 HTTP 响应内容。

最常见的场景就是把 Java 对象转换为 JSON。

5. Controller 执行完之后，会返回什么

这部分要分成两种场景来看。

5.1 传统服务端页面渲染

如果是传统 Web 项目，控制器方法通常可能返回：

• 视图名，比如 "userList"
• ModelAndView

这时 Spring MVC 的处理思路是：

1. 控制器方法执行完成
2. 得到视图相关结果
3. 交给 ViewResolver 解析视图
4. 由视图技术渲染页面
5. 最终把 HTML 返回给浏览器

5.2 前后端分离接口返回

如果是前后端分离项目，控制器方法通常返回：

• 一个普通对象
• ResponseEntity
• 标注了 @ResponseBody 的返回结果

如果类上使用了 @RestController，本质上也等价于默认带有 @ResponseBody 语义。

这时流程就不是“返回视图”，而是“直接返回数据”。

更准确地说，这类返回值会由 Spring MVC 的返回值处理机制配合 HttpMessageConverter 写入响应体，而不是再走视图解析。

所以这里不要简单理解成“HandlerAdapter 返回了 null”，更准确的理解应该是：

• 控制器方法返回的是数据
• Spring MVC 把这些数据写进 HTTP 响应体
• DispatcherServlet 不再进行视图渲染

6. 一次请求在 Spring MVC 中是怎么流转的

把前面的内容串起来，一次典型请求大致会经过下面这些步骤。

1. 浏览器发起 HTTP 请求。
2. Web 容器接收到请求后，把请求交给 DispatcherServlet。
3. DispatcherServlet 调用 HandlerMapping 查找当前请求对应的处理器。
4. 找到处理器后，DispatcherServlet 再交给合适的 HandlerAdapter 去执行。
5. HandlerAdapter 完成参数绑定、类型转换，然后调用目标控制器方法。
6. 控制器方法执行业务流程，并返回结果。
7. 如果返回的是视图名或 ModelAndView，则进入视图解析和页面渲染流程。
8. 如果返回的是对象或 ResponseEntity，则通过 HttpMessageConverter 直接写入响应体。
9. 最终响应返回给客户端。

为了先把主线讲清楚，这里暂时没有展开拦截器、异常处理器、文件上传解析器这些扩展机制，但它们本质上也都是围绕这条主流程工作的。

7. 几个容易混淆的点

7.1 Controller 不等于业务逻辑

Controller 的主要职责是接收请求、做参数承接、组织调用和返回结果。

真正的业务逻辑通常应该放在 Service 层。这样分层才清晰，也更容易维护。

7.2 DispatcherServlet 不是“一个类包办一切”

虽然 DispatcherServlet 是统一入口，但它并不是自己完成所有工作。

它更像一个总调度器，会把不同阶段的工作分别交给：

• HandlerMapping
• HandlerAdapter
• ViewResolver
• HttpMessageConverter

7.3 前后端分离场景下，通常不会再走视图解析

如果控制器返回的是 JSON 数据，那么重点就不再是 ViewResolver，而是返回值处理机制和 HttpMessageConverter。

也就是说，前后端分离项目和传统服务端页面渲染项目，后半段流程是不一样的。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-9

AI时代，如何放大凸显自己的长处，变得更加重要

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-8

有时候感觉有那种摇滚精神，反叛精神是十分十分可贵的，那种燥的气息仿佛是生命力的外显，怀念，昔日我曾风华正茂，如今我正苍老。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-6

AI 时代说个小暴论，越是在这种鼓吹人人都可以创造的时代，越要静下心来做一些长期主义的事情。LLM 是一把锋利的刀，你买了这把刀，别人也可以买，这并不能带来什么本质性的差距。所以还是要沉下来，做一些长期主义、有积累的事情。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-5

死亡是每个人必修的课题

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/elasticsearch-guide

1.基础学习

一、 什么是 Elasticsearch？

Elasticsearch（简称 ES） 是一个基于 Lucene 的开源、分布式、RESTful 搜索引擎。它不仅是一个数据库，更是为了解决传统关系型数据库（如 MySQL）在全文检索、海量数据搜索和实时分析方面的不足而设计的。

为什么不用 MySQL 的 LIKE 查询？

• 性能差：LIKE '%关键词%' 无法利用索引，数据量大时查询极慢。
• 结果不精准：无法根据相关性进行排序（比如“最匹配”的内容排在前面）。
• 缺乏分词能力：难以处理复杂的自然语言搜索。

二、 核心概念与实战操作

1. 核心术语对照

2. 基础操作（DSL 语法）

ES 使用 JSON 格式的 DSL（领域特定语言）进行交互，建议配合可视化工具 Kibana 使用。

• 创建索引：需指定字段类型，也就是映射mapping。text 用于全文检索（会分词），keyword 用于精确匹配（不分词）。

• 插入数据：直接发送 POST 请求提交 JSON 文档。

• 搜索数据：使用 match 进行全文搜索，ES 会自动分词并计算匹配度。

3. Java 客户端开发

在生产中，通常使用 Spring Data Elasticsearch。它允许开发者通过定义接口（继承 ElasticsearchRepository）并使用注解（如 @Document）来操作 ES，就像使用 MyBatis-Plus 一样简单。后文会有代码示例

三、 ES 为什么这么快？（核心特性）

1. 倒排索引 (Inverted Index)

这是 ES 的灵魂。它不直接存整行数据，而是记录单词 -> 文档 ID 列表的映射。搜索时，系统先对搜索词进行分词，然后通过倒排索引直接定位包含这些词的文档，无需全表扫描。

2. 分词器 (Analyzer)

• 标准分词器：对中文支持较差（按字拆分）。
• IK 分词器：中文搜索必备，提供 ik_smart（智能切分）和 ik_max_word（最细粒度切分）模式。

3. 相关性评分

ES 默认采用 BM25 算法，通过词频（TF）、逆文档频率（IDF）和文档长度来计算分数（_score），确保用户最想要的结果排在最前面。

四、 生产环境的挑战与方案

1. 数据同步

由于 ES 和 MySQL 是独立系统，需要解决数据一致性问题：

• 定时任务：适合实时性要求不高的场景。
• 双写：代码层面同时写入两端，但需处理写入失败。
• Canal 监听：实时监听 MySQL 的 Binlog 变更并同步，延迟低。

2. 高可用与扩展

• 集群部署：通过多节点（主节点、数据节点）保证服务不宕机。
• 分片 (Shard)：将大索引拆分存放在不同节点，提升存储上限和并发能力。
• 副本 (Replica)：分片的备份，防止节点损坏导致数据丢失。

3. 常见进阶问题

• 深度分页：ES 默认限制查询前 10,000 条。深层次翻页建议使用 search_after。
• ELK 生态：Elasticsearch (存储) + Logstash (收集) + Kibana (展示)，是目前主流的日志分析方案。

建议：学习 ES 最好的方式是动手实践，先在本地搭建一个单机版环境，尝试通过 Kibana 练习各种 DSL 查询。

2.代码实现

我们通常会选择在 Spring Boot 项目中集成 Spring Data Elasticsearch。这是目前 Java 后端最主流、也是最高效的开发方式。

1. 环境准备与配置

首先，在项目的 pom.xml 中引入依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-elasticsearch</artifactId>
</dependency>

在 application.yml 中配置 ES 服务器地址：

spring:
  elasticsearch:
    uris: http://localhost:9200

2. 定义实体类（Mapping 映射）

通过注解将 Java 对象映射为 ES 的索引结构。text 类型用于搜索，keyword 用于精确过滤。

@Data
@Document(indexName = "article") // 指定索引名称
public class Article {
    @Id
    private Long id;

    // type = Text 表示支持全文检索，analyzer 指定分词器
    @Field(type = FieldType.Text, analyzer = "ik_max_word", searchAnalyzer = "ik_smart")
    private String title;

    @Field(type = FieldType.Text, analyzer = "ik_max_word")
    private String content;

    // type = Keyword 表示不分词，直接匹配
    @Field(type = FieldType.Keyword)
    private String category;

    @Field(type = FieldType.Date, format = DateFormat.basic_date_time)
    private LocalDateTime createTime;
}

3. 编写 Repository 接口

这是 Spring Data 的精髓，你只需要定义方法名，框架会自动帮你生成 DSL 查询语句。

public interface ArticleRepository extends ElasticsearchRepository<Article, Long> {
    
    // 自动解析：根据标题全文检索
    List<Article> findByTitle(String title);
    
    // 自动解析：根据分类精确匹配
    List<Article> findByCategory(String category);
    
    // 复合查询：标题匹配且分类一致
    List<Article> findByTitleAndCategory(String title, String category);
}

4. 高级搜索：使用 ElasticsearchTemplate

如果 Repository 的方法名无法满足复杂的业务逻辑（如高亮、聚合、复杂的布尔过滤），可以使用 ElasticsearchTemplate。

示例：带高亮和过滤的复合搜索

@Autowired
private ElasticsearchRestTemplate elasticsearchRestTemplate;

public void complexSearch(String keyword) {
    // 1. 构建查询条件（类似 SQL 的 WHERE）
    NativeSearchQuery searchQuery = new NativeSearchQueryBuilder()
            .withQuery(QueryBuilders.boolQuery()
                    .must(QueryBuilders.matchQuery("title", keyword)) // 必须匹配标题
                    .should(QueryBuilders.matchQuery("content", keyword))) // 内容匹配可加分
            .withHighlightFields(new HighlightBuilder.Field("title")) // 设置高亮字段
            .withPageable(PageRequest.of(0, 10)) // 分页
            .build();

    // 2. 执行搜索
    SearchHits<Article> searchHits = elasticsearchRestTemplate.search(searchQuery, Article.class);

    // 3. 处理高亮结果
    searchHits.getSearchHits().forEach(hit -> {
        Article article = hit.getContent();
        List<String> highlightTitle = hit.getHighlightField("title");
        if (!highlightTitle.isEmpty()) {
            article.setTitle(highlightTitle.get(0)); // 替换为带 <em> 标签的内容
        }
        System.out.println("搜索结果: " + article);
    });
}

5. 核心逻辑总结

在实际开发中，代码流程通常是：

1. MySQL 写入：文章发布成功。
2. 触发同步：通过 articleRepository.save(article) 同步到 ES。
3. 用户搜索：调用自定义的 search 方法，获取经过分词和评分排序后的结果。

注意：
在本地调试时，请确保已经安装了 IK 分词器 插件，否则代码中的 analyzer = "ik_max_word" 会导致 ES 报错。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/message

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/about

一个正在成长的大三学生

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-4

如果思考的页面可以插入图片就好了

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/mysql-mvcc

首先，什么是 MVCC

MVCC 的中文是多版本并发控制，它是 InnoDB 在处理普通 SELECT 这类快照读时实现一致性读的核心机制，主要服务于读已提交（RC） 和 可重复读（RR） 这两个隔离级别。

并发事务里常见的冲突主要有两类：

• 读写冲突：事务 A 在读一行数据，事务 B 同时修改这行数据
• 写写冲突：两个事务同时修改同一行数据

写写冲突仍然需要依赖锁来保证串行化；MVCC 主要解决的是读写并发时，如何让读操作尽量不阻塞写操作。

需要注意，MVCC 主要用于快照读，不适用于所有读操作。像 SELECT ... FOR UPDATE、SELECT ... FOR SHARE、UPDATE、DELETE 这类当前读，仍然要结合锁来工作。

MVCC 的三个核心点

1. 隐藏字段

   • trx_id：最后一次修改该记录版本的事务 ID
   • roll_pointer：指向该记录上一个历史版本的 undo log 指针

2. undo log 版本链

   一行记录每次被修改时，旧版本不会立刻消失，而是被写入 undo log，再通过 roll_pointer 串起来，形成一条从新到旧的版本链。

3. Read View

   Read View 可以理解为事务做快照读时拿到的一份“可见性规则”。事务会基于这份规则，从版本链上判断哪个版本对自己可见。

Read View 中几个关键字段

• m_ids：创建 Read View 时，系统中活跃的读写事务 ID 集合
• min_trx_id：m_ids 中最小的事务 ID
• max_trx_id：创建 Read View 时，系统将要分配给下一个事务的 ID
• creator_trx_id：创建这个 Read View 的事务 ID

这里要特别注意：

• 记录上的 trx_id，表示“这个版本是由哪个事务生成的”
• creator_trx_id，表示“当前正在读取数据的事务是谁”

这两个不是同一个概念。

可见性判断算法

当事务进行快照读时，会从版本链的最新版本开始判断可见性。这里参与判断的 trx_id，指的是“当前正在检查的那个记录版本的事务 ID”，不是当前读请求所属事务的 ID。

判断规则可以概括为：

1. 如果版本的 trx_id == creator_trx_id，该版本可见

   原因：这是当前事务自己生成的版本，当前事务当然可以看到。

2. 如果版本的 trx_id < min_trx_id，该版本可见

   原因：说明生成这个版本的事务，在 Read View 创建前就已经提交了。

3. 如果版本的 trx_id >= max_trx_id，该版本不可见

   原因：说明这个版本对应的事务，是在 Read View 创建之后才开始的。

4. 如果 min_trx_id <= trx_id < max_trx_id

   • trx_id 在 m_ids 中：不可见，说明该事务在创建 Read View 时仍然活跃，尚未提交
   • trx_id 不在 m_ids 中：可见，说明该事务在创建 Read View 前已经提交

如果某个版本不可见，就顺着版本链继续找更老的版本，直到找到第一个可见版本为止。

RC 和 RR 的本质区别

1. RC（读已提交）

   每次执行快照读时，都会创建新的 Read View，所以同一个事务里两次普通 SELECT，可能看到不同的已提交结果，这就是不可重复读产生的原因。

2. RR（可重复读）

   默认情况下，事务中的第一次快照读会创建 Read View，后续快照读复用同一个 Read View，因此同一个事务里的多次普通 SELECT 通常会看到同一份快照。

这里的表述要稍微严谨一点：

• RR 下“保持一致”的是普通快照读看到的历史快照
• 如果当前事务自己更新了数据，那么它仍然可以看到自己更新后的结果
• 如果执行的是当前读，也不走这套快照可见性逻辑

另外，InnoDB 中 RR 并不是“事务一启动就一定创建 Read View”。通常是第一次执行快照读时才创建；如果显式使用了 START TRANSACTION WITH CONSISTENT SNAPSHOT，则会在事务开始时创建一致性视图。

举例说明版本选择过程

假设有三个事务并发执行：

• 事务 101：较早启动，修改了某行数据，但还没有提交
• 事务 102：稍后修改了同一行数据，并且已经提交
• 事务 103：当前事务，正在执行一次快照读

假设这行数据原本的最后已提交版本是 trx_id=100。

之后：

• 事务 102 修改该行，生成一个新版本，trx_id=102
• 事务 101 又基于更新后的数据生成更“新”的版本，trx_id=101，但它尚未提交

于是版本链可以表示为：

(101) -> (102) -> (100)

其中 (101) 是当前记录上最新的版本。

现在事务 103 在执行第一次快照读时创建 Read View。此时：

• 活跃事务只有 101，所以 m_ids = {101}
• min_trx_id = 101
• max_trx_id = 104，表示下一个将被分配的事务 ID 是 104
• creator_trx_id = 103

事务 103 读取这行数据时，会这样判断：

1. 先看最新版本 (101)

   trx_id=101 落在 min_trx_id <= trx_id < max_trx_id 区间内，并且 101 在 m_ids 中，说明该版本对应的事务在创建 Read View 时仍然活跃，因此不可见。

2. 顺着版本链看下一个版本 (102)

   trx_id=102 也还是落在min_trx_id <= trx_id < max_trx_id 区间内，但 102 不在 m_ids 中，说明它在 Read View 创建前已经提交，因此这个版本可见。

3. 返回版本 (102) 的数据

所以，事务 103 读到的是事务 102 提交后的值，而不是事务 101 尚未提交的值。

如果隔离级别是 RC，那么事务 103 每次执行快照读都会重新创建 Read View：

• 只要事务 101 还没提交，新的 Read View 中仍然会把 101 视为活跃事务，因此看不到版本 101
• 一旦事务 101 提交，下一次快照读重新生成 Read View 时，101 不再出现在活跃事务列表中，此时就可能读到版本 101 ::: link-card href="https://www.bilibili.com/video/BV1Yc411N7tK" title="10分钟带你深刻理解MySQL中的MVCC机制" desc="参考引用" newtab="true"

::: ::: link-card href="https://www.bilibili.com/video/BV1Kr4y1i7ru" title="MySQL数据库入门到精通" desc="参考引用" newtab="true"

:::

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-2

Life, the Universe and Everything.