在这个系列里，我们已经陆续聊过几样东西，用 CLAUDE.md 把项目背景和协作约束提前讲清楚，用 Slash Command 和 Skill 把反复出现的任务收敛成稳定的工作流，再用 Hooks 在执行的关键节点上守住行为边界。把这些放在一起看，你会发现我们其实一直不断在给 Claude Code 添加各种各样的能力，让它越来越懂你的项目，越来越贴合你的工作方式。但这些东西说到底还是各自为战，就像钢铁侠、蜘蛛侠、雷神，他们单打独斗个个一流，但真正让世界免于毁灭的，是他们组成的复仇者联盟。Claude Code 里有没有类似的东西，能把这些强大能力组成一个整体呢？有，这就是 Plugin，它把 Claude Code 各种能力拧成一股绳，变成一个可分发、可安装的单元，从而让复用和分享变得简单。
上一篇文章里，我们聊了 Slash Command 和 Skill 的关系，看到 Claude Code 正在把原本零散的任务入口，收进一套更完整的结构化体系里。不过当我们把越来越多的能力交给 Claude Code，让它去读代码、改文件、跑命令，甚至调用外部服务时，一个更深层的问题也会跟着浮出水面，我们到底靠什么来控制它的行为边界？CLAUDE.md 可以告诉它应该怎么工作，Skill 可以让它按一套更稳定的流程执行任务，但这些归根到底都还是在引导模型，而不是在真正约束执行过程。你可以在 CLAUDE.md 里写 不要修改 prod.env，但这条规则能不能被稳定执行，最终仍然取决于模型自己的判断。
Hooks 就是 Claude Code 给出的另一种答案，它不是另一种提示词，也不是另一种上下文注入方式，而是一套运行在 Claude Code 执行流程中的程序化控制机制。比如当 Claude Code 准备调用工具、写入文件或执行命令时，Hooks 可以在动作真正发生之前介入，决定是放行、拦截，还是要求人工确认。它的判断不依赖模型是否理解并记住了规则，而是依赖你预先写好的代码逻辑，所以它提供的是一种更稳定的行为边界控制方式。本篇文章会从 Hooks 的基本结构开始，依次梳理它的事件体系、合并与决策机制、不同层级中的行为差异，以及真实插件里的实际用法。
上一篇文章里，我们聊了 Claude Code 的 CLAUDE.md，它告诉我们 Claude Code 在进入一个项目时应该先知道什么，也就是项目背景、协作约束和工作边界该如何被提前说明。不过当这些静态上下文准备好之后，真正进入日常使用，我们很快还会碰到另一个更实际的问题，面对代码评审、提交变更、生成总结这类经常遇到的任务，怎样才能让 Claude Code 每次都用更稳定、更一致的方式进行工作呢？Slash Command 正是为这个问题出现的，它看起来只是一个以 / 开头的命令，背后其实对应的是一套被命名的任务入口和工作流约定，而这也是我们这一篇文章要继续往下展开的主题。
如果把近几年 AI 编程工具的发展画成一条时间线，Claude Code 大概是最值得单独标记的节点之一。Anthropic 在 2025 年 2 月第一次把它带到开发者面前，那时它还处在一个对外开放的早期试用阶段，到了 2025 年 5 月，它开始正式走向更大范围的开发者。它最不寻常的地方，不是又多了一个能聊天的模型界面，而是第一次让一个 AI agent 真正住进 terminal，去读仓库、改文件、跑命令、修问题、推进任务。那一刻开始，软件开发的重心就已经悄悄变了。过去很长一段时间里，开发者的主要工作是亲手实现，IDE 更多只是补全、检索、分析代码的辅助工具。Claude Code 把这件事往前推了一大步，越来越多的时候，我们不再先想下一行代码该怎么写，而是先想目标是什么、约束是什么、哪些文件能改、什么结果才算完成。开发流程正在从手工逐行编码，转向用清晰意图驱动 AI 协作完成实现。这不是一个小功能升级，而是一次工作方式的重排，这也是为什么它会让那么多开发者第一次真切感受到 AI 能自主完成编程任务的那种冲击力。
也正因为这样，我想写一个系列，系统聊一聊 Claude Code 到底该怎么用。其实网上已经有不少优秀文章，官方文档也非常值得读，但我还是想再写这个系列。一方面，Claude Code 更新太快，很多旧经验很容易过时，另一方面，我也想把自己在真实使用中的心得、踩坑和认知上的变化整理下来，同时借这个过程重新梳理自己的学习脉络，让自己对 Claude Code 的理解更扎实一些。作为这个系列的第一篇文章，我会先介绍 CLAUDE.md，因为它是 Claude Code 理解项目的起点，负责为 AI 提供所需的背景和约定，往往会直接影响模型在代码库中工作的准确度和稳定性。
在当今软件开发领域，Git 已成为事实上的版本控制标准。虽然 Git 功能强大，但在日常使用中，我们常常会遇到一些令人头疼的情况：比如正在专注开发功能 feature 时，突然需要处理紧急 bug，不得不手忙脚乱地执行 git stash 保存工作；合并远端分支大量代码时，在复杂的 git rebase -i 操作中一步走错，整个提交历史变得混乱不堪；或者提交了一个庞大的 PR 后，被要求拆分成多个小 PR 再提交。如果这些痛点让你感同身受，那么 Jujutsu 值得你关注。这个基于 Rust 开发的新一代版本控制工具，正在改变开发者对版本管理的思维方式。本文将深入探讨 Jujutsu 在日常的开发中如何优雅地实现 Git 的操作，以及它如何通过创新的设计理念提升我们的开发效率和体验。
在区块链的世界里，交易是一切活动的核心，它记录着价值的转移、状态的变更以及智能合约的执行。对于 Solana 这样一个高性能区块链网络而言，理解交易的结构和机制显得尤为重要。与传统的区块链网络相比，Solana 的交易设计更加复杂和精巧，它不仅支持高并发处理，还提供了丰富的指令类型和灵活的账户模型。无论你是区块链开发者、数据分析师，还是对 Solana 生态感兴趣的技术爱好者，深入了解 Solana 交易的内部结构都是必不可少的技能。本文将带你全面解析 Solana 交易，从多种查看方式到详细的数据结构，从 RPC 调用到浏览器界面，帮助你掌握 Solana 交易分析的各种技巧和最佳实践。
上一期我们介绍了 Solana 程序资源限制中的 Compute Unit（以下简称 CU ）部分，今天我们再来介绍 Solana 程序资源限制中的存储部分。Solana 的存储限制主要是指 Solana 账号中的存储限制，这个限制是为了保障 Solana 网络的稳定性和安全性，同时也是为了防止恶意程序占用过多的存储空间。在这个限制下，如何设计程序的数据结构，如何确保账户的数据不超过限制，这些都是 Solana 开发者关心的问题，我们今天将通过详细的讲解和一些实际案例分析来为大家揭开 Solana 存储限制的神秘面纱。
很多开发人员在开发 Solana 程序（智能合约）时经常遇到这样的问题，明明程序逻辑没有问题，但是在程序运行的时候就会出现奇怪的错误，错误的提示会出现限制或者超出等字眼，这表示你的程序可能落入了 Solana 的资源限制中。Solana 作为高性能区块链，其核心特性之一在于通过并行处理显著提升交易吞吐量，这种高效能背后依赖严格的资源管理机制，开发者需要深刻理解这些限制，才能有效开发和优化 Solana 程序。本文旨在介绍 Solana 开发中的资源限制，并详细介绍其中关于计算单元（Compute Unit，以下简称 CU）的限制，剖析实际场景，探讨优化策略。
对于不熟悉 Web3 的朋友来说，可能会觉得 DeFi (Decentralized Finance，去中心化金融) 是一个充满风险的赌场或骗局。但实际上，DeFi 是一个去中心化的金融体系，在某些方面与投资股票、基金等传统金融产品具有相似性。DeFi 利用区块链技术提供公开透明、无需中介的金融服务，降低了信任成本和交易费用。目前，主流的 DeFi 平台包括 Curve、 Uniswap、Aave 和 Compound 等。今天我们将介绍 Curve 这个平台的基本操作，并探讨其中涉及的智能合约方法，希望通过这篇文章帮助大家更好地理解 DeFi，增强对 DeFi 投资的信心，并找到一种新的财富增长方式。
