从 CLI 到 Agent：Claude Code 的工程架构拆解从 CLI 到 Agent：Claude Code 的

从 CLI 到 Agent：Claude Code 的工程架构拆解

在这里插入图片描述

很多人把 Claude Code 理解成“终端里的 Claude 聊天框”，但如果真的去看它的官方仓库、配置体系、工作流文档，以及它和 Agent SDK 的关系，你会发现它更像一个面向开发任务的 Agent 外壳，而不是一个单纯的问答工具。

这篇文章不讨论模型本身的内部权重或训练细节，而是从工程结构出发，拆解 Claude Code 作为一个 Agentic Coding CLI，到底是如何组织入口、配置、工作流与可扩展能力的。

一、先说结论：Claude Code 不是“会写代码的聊天机器人”

如果只从表面体验来看，Claude Code 很像一个终端里的 AI 助手：

你输入自然语言
它读取项目代码
它解释实现逻辑
它帮你改代码、写测试、处理 Git 流程

但如果你从工程视角看，它的本质不是“一个会回答问题的模型”，而是一个更完整的系统：

模型能力 + 工具调用 + 会话管理 + 配置系统 + 工作流抽象 + 可扩展组件

这六件事合在一起，才是 Claude Code 真正的产品形态。

也正因为如此，我认为 Claude Code 最值得分析的地方，不是“它回答得有多聪明”，而是：

它是怎么把一个大模型，包装成一个能参与真实开发流程的 Agent 系统的。

二、分析边界先讲清楚：我们能解析什么，不能解析什么

写“Claude Code 源码解析”时，第一件事不是急着画架构图，而是先划清边界。

1. 我们能分析的

我们能分析的，是 Claude Code 官方公开可见的部分，例如：

官方 GitHub 仓库对产品定位和组件结构的呈现
官方文档中暴露出的安装方式、配置层级、工作流设计
skills、hooks、subagents、plugins 等可扩展机制
Agent SDK 与 Claude Code 的能力映射关系

这些内容足够支撑一篇工程层面的架构解析。

2. 我们不能分析的

我们不能真正分析的，是以下内容：

Claude 模型本体的内部实现
完整的私有推理策略
服务端不可见的调度逻辑
Anthropic 内部未公开的执行器或控制平面

所以，这篇文章的“源码解析”，不是去伪装成“拿到了所有内部代码”，而是要老老实实地分析：

Claude Code 在公开边界内，展现出了怎样的 Agent 工程组织方式。

这其实反而更有价值。因为大多数工程师真正能学到的，不是模型权重，而是：

如何设计一个 AI CLI
如何组织配置和权限
如何把问答能力变成任务工作流
如何给 Agent 做扩展机制
如何让上下文和工具真正可控

三、Claude Code 的核心定位：一个“住在终端里的开发代理”

官方对 Claude Code 的描述非常直接：

它 lives in your terminal
它 understands your codebase
它 helps you code faster
它 can execute routine tasks, explain code, and handle Git workflows
它通过自然语言命令工作

这段定位其实信息量非常大。

它至少说明了 3 件事：

第一，它不是 IDE 插件优先，而是 CLI 优先

这点很关键。

很多 AI 编程产品，第一入口是 IDE 补全或侧边栏。而 Claude Code 把自己的核心身份定义在 terminal 上，这意味着它从一开始就不是围绕“编辑器光标补全”设计的，而是围绕“项目级任务执行”设计的。

终端意味着什么？

终端意味着：

更接近真实工程环境
更容易访问仓库结构
更容易接入 shell / git / test / build
更容易成为“开发流程入口”，而不只是“写代码时的辅助提示”

第二，它不是只做代码生成，而是做开发任务代理

注意官方表述不是只有“write code”。

它强调的是：

解释复杂代码
执行 routine tasks
处理 git workflows

也就是说，它关注的不是“生成一段函数”，而是更完整的开发动作：

看懂代码库
搜索和定位问题
修改文件
跑命令
看输出
再修复
再验证
最终把结果组织成开发产物

这已经不是传统意义上的“AI 编程提示器”了。

第三，它天然是 Agent 形态，而不是聊天形态

所谓聊天形态，本质上是：

你问一句，我答一句。

所谓 Agent 形态，本质上是：

你给一个任务，我自己决定要不要看文件、要不要调用工具、要不要分步推进、要不要持续运行直到完成。

Claude Code 的公开材料已经非常清楚地表明，它属于后者。

四、第一层：入口层——为什么一个 Agent CLI 会强调“原生安装”

看 Claude Code 的安装文档，有一个非常值得注意的点：

官方当前推荐的是 Native Install，同时文档专门给出了“从 npm 迁移到 native”的说明。

这个设计信号非常强。

很多人第一次看到会觉得，这不就是“安装方式”吗？有什么好分析的？

其实非常有。

1. 从 npm 包到原生分发，意味着它不想只是一个 Node 小工具

如果一个 CLI 只是一个轻量命令行程序，用 npm 全局安装通常就够了。

但 Claude Code 官方推荐 Native Install，这说明它想控制的东西更多：

二进制分发的一致性
自动更新体验
平台兼容性
权限和依赖问题
更接近“产品”而不是“脚本包”的安装方式

也就是说，它在产品定位上已经不是“给开发者随手装的命令”，而是：

一个需要长期运行、持续更新、跨平台维护的 AI 开发客户端。

2. 终端入口不是表层 UI，而是系统接入点

CLI 在这里不是显示层，而是能力入口。

因为一旦你把 Claude Code 放进终端，它就天然站在了这些能力附近：

当前工作目录
项目文件树
Git 状态
Shell 执行环境
测试与构建工具
本地配置文件
项目约定和团队规则

这和网页聊天框是两个世界。

所以从入口层开始，Claude Code 就已经表达了一个很清楚的产品哲学：

它不是把“模型”嵌进终端，而是把“开发现场”开放给模型。

这就是 Agent 工程和单纯 AI 问答的第一条分界线。

五、第二层：交互层——它为什么不像传统 CLI，而更像一个 REPL Agent

传统 CLI 的交互模式是这样的：

命令固定
参数固定
输入格式固定
程序行为高度确定

例如：

git status
npm test
python main.py

而 Claude Code 的交互逻辑不是这样。

它更接近一种 REPL + 意图驱动 + 工具编排 的形式。

1. 用户输入的是“意图”，不是“低级命令”

例如你可能说：

帮我快速看懂这个仓库
找出导致这个测试失败的原因
帮我重构这个模块，但不要改外部接口
给这个改动补一套测试
帮我整理一个 PR 描述

这些都不是传统 CLI 能直接识别的“命令”。
它们是更高层的任务意图。

这意味着 Claude Code 的中间层必须做一件事：

把自然语言意图翻译成一组工具动作和上下文操作。

这就是 Agent loop 的典型特征。

2. 它不是一次回答，而是多步执行

一个真正的开发任务，通常不可能“一步回答完”。

比如“帮我定位这个 bug”，实际过程通常是：

先看目录结构
找相关模块
搜索报错关键词
打开关键文件
分析调用链
运行测试或命令验证
再提出修复方案
如有需要修改代码
再次验证结果

这意味着 Claude Code 的交互并不是：

用户输入 -> 模型回答 -> 结束

而更像：

用户输入 -> 进入 agent loop -> 多轮工具调用与上下文更新 -> 形成结果

3. 它的“命令系统”本质上是控制平面

Claude Code 文档里有 /config、/agents 之类的命令，但这些命令的意义，不只是“命令行功能”。

它们更像是：

配置入口
能力管理入口
Agent 行为控制入口

所以你可以把 Claude Code 理解成两套交互叠在一起：

一套是任务交互

用自然语言描述开发任务。

一套是控制交互

用 slash commands 管理系统行为、配置、子代理、插件等。

这个分层很重要，因为它说明 Claude Code 并不是“自然语言替代命令行”，而是：

自然语言负责任务层，命令负责控制层。

这是一种很典型的 Agent 产品分层方式。

六、第三层：配置层——Claude Code 最值得学习的工程设计之一

如果你问我，Claude Code 文档里最值得架构师认真看的是什么，我会说：

配置层级设计。

因为这部分非常清楚地暴露了 Claude Code 是怎么从“个人工具”升级成“团队系统”的。

官方文档给出了非常明确的配置优先级与作用域设计。

七、Claude Code 的配置不是一个 settings.json，而是一套“作用域系统”

很多 CLI 工具的配置非常简单：

一个全局配置文件
一个项目配置文件
最多再加几个环境变量

Claude Code 不是这样。

它把配置明确做成了一套 scope system，也就是“作用域系统”。

从高到低，大致是：

Managed（组织级，最高优先级）
Command line arguments（会话级临时覆盖）
Local（本地项目覆盖）
Project（项目共享配置）
User（个人全局配置）

这个设计非常成熟。

1. User：个人层

这是你自己的默认偏好。

例如：

个人习惯的插件
默认行为偏好
自己常用的体验配置

它作用于所有项目，但优先级最低。

这很合理，因为个人偏好不应该压过团队规范。

2. Project：团队共享层

项目目录中的 .claude/settings.json 是团队共享配置。

这个层级很关键，因为它意味着：

Claude Code 不是只服务“一个人和一个模型”，而是能进入“一个团队和一个仓库”的协作结构。

项目共享配置可以表达：

团队共同启用的能力
项目内统一的插件
代码库特定规则
团队范围内的 Claude 行为预期

这就让 Claude Code 从“个人生产力工具”变成了“团队开发基础设施的一部分”。

3. Local：本地机器覆盖层

.claude/settings.local.json 不进入版本控制，适合机器级、临时性、实验性偏好。

这个层的价值在于：

不污染团队配置
不影响仓库共享规则
可以做个人实验和本地调整

换句话说，它解决了一个非常现实的问题：

团队想统一，但每个人又总会有一些本地差异。

Claude Code 没有粗暴地把它们混在一起，而是单独分层。

4. Managed：组织治理层

这是整个系统最“企业化”的部分。

Managed settings 的意义，是允许组织层做统一治理，并且它有最高优先级，无法被用户和项目层覆盖。

这代表 Claude Code 的定位已经明显超过了“开发者个人工具”，进入了：

企业合规
权限治理
组织策略控制
统一安全边界

也就是说，Claude Code 不是只考虑“怎么更自由”，还考虑“怎么在组织里可控”。

八、为什么这个配置体系很重要：因为 Agent 一旦接触工具，就必须被治理

普通聊天机器人配置错一点，可能只是回答风格不一致。

但 Claude Code 不一样。

它一旦连接到：

文件系统
shell
Git
外部工具
MCP 服务
hooks
插件

配置就不再只是“体验设置”，而变成了：

权限边界、行为边界、组织边界。

所以 Claude Code 的配置体系，本质上不是 UI 设置，而是治理结构。

这一点非常值得所有做 Agent 系统的人学习。

因为未来只要你的系统有以下特征：

能读写文件
能执行命令
能调用外部工具
能在团队项目里使用

那么你迟早都要面对这几个问题：

什么配置是个人的？
什么配置是项目共享的？
什么配置不能被个人覆盖？
优先级怎么定？
哪些能力默认允许？哪些能力必须显式授权？

Claude Code 的回答很清楚：

把配置做成作用域系统，而不是一个扁平的 settings 面板。

九、第四层：工作流层——它真正卖的不是“回答”，而是“开发任务模板”

官方文档里列出的常见工作流包括：

理解新代码库
调试
重构
写测试
创建 PR
管理 session

很多人看到这些，会觉得这不就是“功能列表”吗？

不是。

这些其实是在暴露 Claude Code 的真正产品核心：

它不是在卖单次回答，而是在卖一套可复用的开发工作流。

1. 为什么“工作流”比“功能”更重要

功能是离散的：

读文件
改代码
跑命令
写测试

工作流是连续的：

为了完成一个目标，如何把这些功能按顺序组织起来

真正的开发任务，从来不是一个原子动作，而是一个过程。

例如“理解一个陌生代码库”，这件事不是读一份 README 就完了，它通常包含：

识别目录结构
找入口模块
看依赖关系
理解核心抽象
总结关键数据流
提取重要文件路径
给出阅读建议

你会发现，这本质上已经是一个半标准化流程。

Claude Code 的价值就在于：

它把这些本来散乱的开发动作，组织成了更稳定、更可复用的任务轨迹。

2. 这也是为什么它更像 Agent，而不是 Copilot

Copilot 类产品更偏向“写代码时的局部生成”。
Claude Code 更偏向“围绕开发目标进行全流程推进”。

两者不是谁替代谁，而是分工不同。

如果说传统补全工具是在“光标附近”帮你提效，
那么 Claude Code 更像是在“任务级别”帮你推进。

它关注的是：

当前目标是什么
下一步该看什么
要不要调用工具
是否需要切换策略
当前会话是否积累了足够上下文

这就是 Agent 工作流。

十、第五层：能力编排层——Claude Code 的关键，不是会聊天，而是会调工具

这是整篇文章最核心的一点。

Claude Code 最重要的不是“语言能力”，而是：

它把语言能力嵌进了一个可操作环境中。

这个“可操作环境”包括什么？

文件读取
代码编辑
命令执行
网络搜索 / 外部信息
项目配置
子代理
hooks
插件
MCP 服务器

而这恰恰就是 Agent 系统和普通对话系统最本质的差别。

1. 传统对话模型的边界

传统对话模型通常是：

你给上下文
它基于上下文生成文本
它本身不直接改变环境

它的输出通常停留在“建议”。

2. Claude Code 的边界向外扩展了

Claude Code 则是：

先理解任务
决定要读什么
决定要不要调工具
通过 agent loop 持续推进
最终交付一个更接近“完成态”的结果

这里模型不再只是“文本生成器”，而变成了“控制器”。

换句话说：

模型的价值，不再只是回答问题，而是决定动作序列。

这就是为什么我一直认为：

Claude Code 的核心不是 prompt，而是 orchestration。

十一、从 Agent SDK 反推 Claude Code：它本质上是“产品化的 Agent Loop”

官方 Agent SDK 的表述非常值得玩味：

它提供与 Claude Code 相同的 tools、agent loop、context management。

这句话其实已经把很多东西说透了。

1. 什么叫“Claude Code as a library”

这句话意味着：

Claude Code 不是一个孤立的应用，而是一套可以被编程复用的能力组织方式。

换句话说，你可以把它理解成两层：

上层：Claude Code 产品

面向终端用户的现成体验。

下层：Agent SDK 能力层

把同类能力暴露给开发者，用来构建自己的 Agent 应用。

这说明 Claude Code 并不是“某个 UI 偶然做出来的 AI 工具”，而是有相对明确的平台抽象。

2. 这也说明 Claude Code 的真正内核是 Agent Loop

如果一个系统最可迁移、最可复用的部分是：

same tools
same agent loop
same context management

那么说明真正重要的不是某个页面或某个命令，而是：

任务如何在多步循环中被执行、观察、修正、推进。

这就是 Agent 的发动机。

所以从架构视角看，Claude Code 可以被理解成：

一个以 agent loop 为内核、以终端为载体、以开发任务为场景、以配置和扩展体系为治理边界的工程化 Agent 产品。

十二、扩展层之一：Skills——为什么 SKILL.md 这个设计很妙

Claude Code 的 skills 机制，是我非常喜欢的一种设计。

它不是强迫你去写插件代码才能扩展系统，而是允许你通过一个目录加一个 SKILL.md，把一组高质量操作说明、模板、示例和脚本组织成 Claude 可调用的能力包。

这件事的价值非常大。

1. 它把“经验”变成了“可执行知识”

一个团队中最宝贵的东西，很多时候不是代码，而是经验：

某类问题应该怎么排查
某套发布流程怎么走
某个项目怎么生成文档
某种改动应该如何自测
某类报告应该怎么写

过去这些经验通常藏在：

Wiki
README
老员工脑子里
零碎脚本里

Skills 做的事情，就是把这些经验包装成 Claude 可调用的执行单元。

2. 它是一种非常轻量的“知识到动作”的桥梁

传统插件扩展往往太重：

要写代码
要走 API
要管理版本
要处理兼容性

但 skill 更轻：

一份主说明文档
可选模板
可选示例
可选脚本
需要时再加载详细资料

这让扩展门槛大幅下降。

3. 它其实是在做“可组合的团队方法论封装”

我觉得这一点特别重要。

未来真正有价值的 Agent 生态，不一定都是 API 插件。
很多场景下，更高频、更高价值的扩展，其实是：

方法论
SOP
模板
约束说明
参考样例
局部自动化脚本

Skills 恰好把这些都容纳进来了。

所以从工程思想上说，skills 并不是“小功能”。
它代表的是一种很成熟的扩展观：

不是所有扩展都要写成程序；很多扩展，本质上是把经验组织成可调用的操作知识。

十三、扩展层之二：Hooks——让 Agent 接入“生命周期自动化”

如果说 skills 更偏“经验复用”，那 hooks 更偏“生命周期自动化”。

Claude Code 的 hooks 可以在会话生命周期的不同节点自动触发，并把 JSON 上下文传给处理器。

这意味着什么？

意味着 Claude Code 不只是一个“等待用户输入”的系统，
它还具备了在关键事件上自动执行逻辑的能力。

1. Hooks 的本质：把“事件”引入 Agent 系统

事件驱动是成熟软件架构中的经典思想。

而 hooks 让 Claude Code 也拥有了这种能力。

它不再只是：

用户说一句，系统做一次。

而是变成：

当某个事件发生时，自动运行预定义逻辑。

这会带来非常多实用场景，例如：

会话启动时加载团队提醒
工具调用前做安全检查
某类操作后做审计记录
调用某些命令时执行额外校验
自动注入项目级上下文

2. 这代表它已经不只是“AI 助手”，而是“可编排的开发环境组件”

一旦有 hooks，Claude Code 的地位就变了。

它不再只是一个孤立的交互程序，而变成了一个可嵌入到流程中的节点。

这对于企业或团队来说特别重要，因为真正能进生产环境的工具，通常都得回答这几个问题：

能不能自动执行某些规范？
能不能在关键节点做拦截？
能不能接入已有流程？
能不能加审计和防护？

Hooks 的存在，就是在回答这些问题。

十四、扩展层之三：Subagents——为什么它开始认真处理“上下文预算”

Claude Code 的 subagents 设计，也非常值得认真看。

官方文档对它的定义大意是：

subagent 是专门处理某类任务的专用助手
它运行在自己的上下文窗口中
有自己的 system prompt、工具权限和独立权限
当任务匹配时，Claude 会把任务委托给它

这个设计其实直指 Agent 系统最难的问题之一：

上下文怎么管理？

1. 为什么需要 subagents

一个复杂开发任务里，会混进很多不同性质的内容：

大范围搜索
方案规划
局部代码修改
测试验证
文档整理

如果全部塞进一个主会话，问题会越来越明显：

上下文变臃肿
主线被噪声淹没
token 成本上升
不同任务相互污染
权限边界不清晰

subagents 的作用，就是把这些不同类型的任务拆出去，让它们在自己的上下文里完成工作，再把结果带回来。

2. 这本质上是在做“任务隔离”

官方文档里甚至把内建 subagents 直接分成了不同角色，比如：

Explore
Plan
General-purpose

这背后反映的思想非常明确：

不同类型的任务，不应该共享完全相同的上下文与工具集合。

这是一种很成熟的 Agent 工程观。

因为真实系统里，不同任务天然就应该有不同策略：

搜索型任务偏只读、低成本、快速遍历
规划型任务偏分析与组织
修改型任务才需要更高权限和更强执行能力

如果全部混成一个 Agent，就会越来越重，越来越乱。

3. subagent 的真正价值不是“多智能体炫技”，而是“上下文治理”

很多人一提多 Agent，就容易往花哨方向想。

但 Claude Code 的 subagent 设计，至少从公开文档看，不是为了炫技，而是为了解决三个很现实的问题：

上下文隔离
工具权限收缩
任务角色专门化

所以我更愿意把它理解成：

不是“多智能体表演”，而是“单系统内部的任务分工与上下文治理”。

这比空谈 multi-agent 实际得多。

十五、再往下看一层：Plugins 和 MCP 意味着什么

Claude Code 的公开仓库和文档中，还能看到 plugin、MCP server、agents、skills、hooks 这些组件的组合。

这说明它的扩展不是单点的，而是一个组合体系。

1. 插件不是只加命令，而是能加一整套行为单元

从公开说明看，一个插件目录里可以包含：

commands
agents
skills
hooks
MCP 配置
README 和元数据

这说明插件不是“注册一个命令”的老式扩展，而更像一个能力包。

也就是说，一个插件可以同时带来：

新入口
新角色
新知识
新事件逻辑
新外部工具接入

这就是平台化的信号。

2. MCP 的意义：让外部工具以标准方式进入 Agent 世界

这一点你如果本身就做 Agent，会非常有感觉。

AI 系统最怕的不是没有工具，而是：

每个工具接法都不一样
每种集成都得单独适配
权限模型杂乱
上下文注入方式不统一

而 MCP 这类标准化接口的意义就在于：

给工具接入提供统一协议。

Claude Code 支持 MCP，本质上是在说：

它不是只接 Anthropic 自己写死的工具，而是愿意把自己放进一个更开放的工具生态里。

十六、到这里，我们可以把 Claude Code 抽象成一张工程架构图

如果用一句话概括，我会把 Claude Code 画成下面这个结构：

用户意图输入
    ↓
CLI / REPL 交互层
    ↓
任务理解与 Agent Loop
    ↓
上下文管理 / 会话管理 / 权限决策
    ↓
工具层（读文件 / 改代码 / shell / web / git / MCP）
    ↓
扩展层（skills / hooks / subagents / plugins）
    ↓
配置治理层（user / project / local / managed）
    ↓
真实开发环境（代码库 / 终端 / 团队规范 / 企业策略）

请注意，这张图里最关键的不是“模型”两个字。

最关键的是中间那几层：

Agent Loop
上下文管理
工具调用
扩展机制
配置治理

这才是 Claude Code 作为工程产品真正有意思的地方。

十七、我对 Claude Code 架构的三个判断

写到这里，我给出 3 个明确判断。

判断一：Claude Code 的核心竞争力不是模型本身，而是“模型如何进入开发环境”

模型强当然重要。

但对于 Claude Code 这种产品来说，更决定体验上限的是：

能不能稳定读取代码库
能不能合理组织上下文
能不能把工具调用放进正确的流程
能不能让系统在复杂任务里不失控

所以从产品层面看，它真正的壁垒很可能不是“模型智商”，而是：

模型 + 工具 + 会话 + 流程 + 治理 这套集成能力。

判断二：它代表的是“任务级编程代理”，不是“光标级补全工具”

这决定了 Claude Code 和传统 AI coding assistant 的差异。

它最适合的价值场景不是：

补一行代码
自动续写一个函数

而是：

看懂陌生项目
调试复杂问题
执行多步任务
重构模块
组织测试和 PR 工作流

它关注的是任务闭环，而不是局部补全。

判断三：它未来最重要的演化方向，可能不是更会写，而是更会“组织协作”

为什么这么说？

因为一旦它已经能：

分层配置
支持 skills
支持 hooks
支持 subagents
接入 plugins 和 MCP

那么它下一步最自然的演化方向，就是进一步向这些方向走：

团队共享工作流
更强的权限治理
更稳的上下文隔离
多角色协同
企业内部开发流程自动化

也就是说，Claude Code 的未来，不只是“更聪明的写代码”。

而是：

更像一个可以嵌入团队开发流程的 Agent 操作系统。

十八、这篇文章真正想说明什么

如果你只把 Claude Code 当成“终端版聊天机器人”，你会低估它。

如果你把它当成“一个带 AI 的 CLI 工具”，你依然低估它。

更准确的理解应该是：

Claude Code 是一个以终端为入口、以 Agent loop 为内核、以工具调用为行动方式、以配置体系为治理边界、以工作流抽象为产品核心的开发代理系统。

这也是为什么我认为它值得被认真分析。

因为它身上体现出来的，不只是一个产品特性集合，而是一套越来越清晰的工程趋势：

AI 工具会越来越像操作系统组件
上下文管理会成为一等工程问题
工具调用不再是外挂，而是内核能力
配置治理会决定 Agent 能不能进入团队
真正有价值的，不是“回答得像不像人”，而是“能不能在真实环境里稳定完成任务”

十九、结语：未来的开发工具，不会只是“会说话”，而会“会做事”

过去几年，很多 AI 产品都在证明一件事：

大模型可以生成代码。

而 Claude Code 代表的下一步是：

大模型不只是生成代码，而是开始参与开发流程本身。

这是两个完全不同的阶段。

前者解决的是“写出来”。
后者解决的是“做成事”。

从这个角度看，Claude Code 最值得学习的，不是某个具体命令，也不是某个页面交互，而是它背后的那套思路：

把自然语言变成任务入口
把工具调用变成行动能力
把上下文管理变成核心架构问题
把配置治理变成团队可用的基础条件
把扩展机制变成生态接口

如果你也在做 AI Coding、Agent、RAG 系统，或者在思考“下一代开发工具会长什么样”，那么 Claude Code 很值得你从工程结构而不是从“好不好玩”去重新看一遍。