对话式开发与 Claude Code — 第4部分：上下文、子代理与思维的学科
Source: Dev.to
TL;DR — Claude Code 并不是靠完美的提示词驱动，而是依赖精心设计的上下文。要有意图且精准地使用它，你必须了解五大支柱：上下文窗口、子代理、模型上下文协议（MCP）、命令行界面（CLI）以及上下文工程。它们共同阐释了 Claude 的思考、记忆和协作方式——以及如何在不对大型语言模型进行微观管理的情况下构建可靠的系统。
为什么上下文胜过提示
大多数 AI 工具的失败并非来源于模型本身的弱点，而是源于设计不佳的上下文。开发者们追逐那种神话般的“完美提示”，却忽视了真正的杠杆点：系统能够看到、记住以及优先处理的内容。
Claude Code 为系统思维的工程师而设计，而不是为咒语式的提示而生。它奖励结构、引用和意图——而不是冗长的文字。
上下文窗口：Claude 的工作记忆
上下文窗口是 Claude Code 的工作记忆。它包含模型一次可以推理的所有内容：源代码、对话、命令输出以及中间结果。
- 默认大小： ~200,000 令牌
- 可选大小： 适用于大型项目的 1 M 令牌窗口
关键属性
- 同时保存代码、对话和执行结果
- 优先考虑相关性而非时间顺序
- 在空间受限时自动淘汰低价值信息
这不是长期记忆，而是主动认知。当窗口满时，Claude 会进行压缩。你的任务是确保留下的内容都是关键信息。
内存卫生：引用胜于复制粘贴
污染上下文的最快方法是粘贴大量代码块。相反，Claude Code 采用 引用 方式设计：
@path/to/file- 只加载所需内容
- 在启动新会话时显式重新锚定决策
如果 Claude 开始“忘记”，解决办法不是重复——而是 重置并重新聚焦：打开新会话，重新引用关键文件，重新阐述架构约束，然后继续。干净的上下文胜过持续的噪声。
子代理：模块化团队，而非单体
子代理将 Claude Code 从工具转变为团队。每个子代理都有：
- 自己的独立上下文
- 专门的指令
- 专用工具
典型子代理
- 架构代理 — 分析系统结构和约束
- 后端代理 — 设计并实现 API
- 前端代理 — 构建 UI 组件和状态流
- 质量保证（QA）代理 — 验证行为、测试和边界情况
主会话充当协调者，映射真实的工程团队：专业化而不碎片化。
何时调用各子代理
- 后端代理 → 接口、模式、集成
- 前端代理 → 组件、用户体验流程、状态管理
- 质量保证（QA）代理 → 测试、回归、验证
- 架构代理 → 重构、边界、长期决策
如果主对话显得拥挤，那说明你拖得太久才进行委派。
MCP 与 CLI：神经系统
Claude Code 生活在终端中。MCP（模型上下文协议）扩展了它的触达范围。两者共同形成一个紧密的循环：
- MCP 将 Claude 连接到真实工具
- CLI 执行命令并返回真实结果
- Claude 进行解释，而不是猜测
有了 MCP，Claude 可以：
- 查询数据库
- 运行自动化测试（例如 Playwright）
- 检查 GitHub issue 和 pull request
- 与 Figma、Zapier 等工具交互
一旦配置好，这些集成就像原生功能一样——而不是后期拼接。
在不中断流程的情况下使用 CLI
CLI 是执行层，而不是旁路渠道。最佳实践
-
使用
!前缀来执行命令，例如：!git status -
让 Claude 读取并解释输出
角色分配
- 终端 → 执行
- 编辑器 → 编写
- 浏览器 → 验证
Claude 在命令执行 之后 进行推理。这一点非常重要。
上下文工程：设计共享思维
上下文工程并非提示工程；它是塑造共享思考空间的学科。
实用步骤
- 在行动之前定义目的
- 明确陈述约束条件
- 引用文件而不是粘贴代码
- 指定质量标准和反模式
- 积极删除无关信息
避免模糊指令——歧义会产生噪声。精准则带来杠杆效应。
Final Thoughts
Claude Code 并不取代判断——它放大了判断。当你将上下文视为一种架构性产物，而不是副作用时，系统会变得可预测、可组合且值得信赖。停止追逐提示；开始设计认知。