这段时间 AI 编程工具圈子里有一个很有意思的讨论那个造出 Claude Code 的团队在一次公开分享中被问到“你们的系统提示词到底写了多少东西”答案却出乎很多人意料——他们亲手删掉了系统提示词大约 80% 的内容跑分和实际任务完成率反而更稳定了。这和我们过去几年养成的习惯完全相反。过去我们写提示词总觉得写得越长越细越安全最好把所有规则、所有格式要求、所有禁忌一股脑塞进系统提示词里。但 Claude Code 团队的做法等于把“提示词越长越好”这条路直接堵死了。本文将围绕这个话题展开先聊聊系统提示词为什么要“做减法”再系统梳理 Claude Code 的安装、配置、认证与实战用法最后回到上下文工程这个核心主题给出你可以直接搬到项目里的设计方法。不管你是刚接触 Claude Code 的新手还是已经在用 AI 编程助手、想进一步压榨效率的开发者这篇文章都能给你一套从概念到落地的完整方案。1. 背景一次关于系统提示词的“减法实验”1.1 造 Claude Code 的人为什么删掉 80% 系统提示词Claude Code 是 Anthropic 推出的命令行编程助手能直接读取项目文件、修改代码、运行命令像一个驻留在终端里的 AI 工程师。这类工具天然依赖系统提示词来约束模型行为什么时候该读文件、什么时候该问用户、代码改到什么程度算完成、危险操作要不要拦截。按理说这种约束越多模型应该越听话。但 Claude Code 团队在分享中透露的真实情况是系统提示词堆到一定程度后模型反而不稳定了。指令多了模型不知道该优先听哪一条提示词长了真实代码内容能被分配到的上下文窗口就小了规则之间偶尔互相冲突模型只能随机挑一条执行。于是他们做了一次大瘦身把系统提示词里大量冗余的背景说明、重复示例、历史遗留规则删掉只保留真正不可妥协的行为边界。结果任务完成率没有下降甚至因为上下文更干净模型在复杂仓库里的表现还更好了。具体删除比例在不同场合说法略有出入但核心结论是一致的系统提示词不是仓库而是“宪法”。宪法只写最高原则不需要把每一条实施细则都写进去。1.2 系统提示词不是越长越好为什么更长的系统提示词反而会拖累模型这背后有几个很实际的原因。第一是 Token 成本。每次调用模型系统提示词都会作为固定的输入 Token 被完整计算。假设系统提示词从 2000 Token 涨到 8000 Token每轮对话多消耗 6000 Token一天跑几百轮任务成本差异会非常明显。第二是注意力稀释。Transformer 架构虽然有很强的注意力机制但模型并不会对输入里的每个词一视同仁。指令越多单条指令的“权重”就越低尤其是当多条指令出现在相隔很远的位置时模型很容易在执行中段把前面的要求忘掉。第三是指令冲突。系统提示词写多了难免出现前后矛盾的情况。比如前面要求“不要修改配置文件”后面又写着“可以用标准库读写配置”。模型遇到这种冲突只能猜猜错了就是事故。所以系统提示词的设计目标不是“覆盖所有情况”而是“在最小体积内定义最大边界”。这恰恰是 Claude Code 团队这次改动最值得学习的点。1.3 这则消息对普通开发者的启示很多开发者看到新闻的第一反应是“删的是他们的系统提示词跟我有什么关系”其实关系非常大。你用 Claude Code、Codex、Cursor 这类工具时模型的行为同样受三层上下文影响模型内置的系统提示词、工具自带的指令、你提供的项目上下文。Claude Code 团队删掉的 80%相当于告诉你工具自带的指令已经在做减法那你自己的项目上下文也不该继续堆砌。换句话说上下文工程的新规矩是把知识放到该放的地方而不是全部塞进提示词。项目规范写进 CLAUDE.md任务说明放进对话模型行为约束才交给系统提示词。这个思路正是本文后面所有实战内容的主线。2. Claude Code 是什么定位与核心能力2.1 官方 CLI 编程助手Claude Code 是 Anthropic 官方推出的终端编程助手核心使用方式是命令行交互。你进入项目目录执行一条命令就能在终端里和 Claude 对话让它读代码、改代码、跑测试、查日志。它和网页版 Claude 最大的区别在于“动手能力”。网页版再聪明也只能给你贴代码Claude Code 会直接在你本地文件系统上操作搜索项目结构、定位函数定义、批量替换代码、运行测试并读取报错。它把这些操作封装成了一个个工具比如读取文件、编辑文件、执行 Bash 命令再由模型判断下一步该调用哪个工具。这种能力让 Claude Code 特别适合处理“工作量大但理解成本低”的任务比如补全单元测试、修复特定报错、把某个模块从同步改成异步、批量重命名变量等。开发者只需要描述目标具体路径由工具自己拆解。2.2 与 Codex、Cursor 等工具的边界现在 AI 编程工具不少很多读者会拿 Claude Code 和 Codex、Cursor、GitHub Copilot 做对比。简单梳理一下边界方便你判断自己该用哪个。Cursor 是编辑器形态的 AI 编程工具给 VS Code 系用户提供 IDE 内补全、对话框、Agent 等功能使用体验更偏向“图形界面”。Codex 是 OpenAI 推出的命令行编程助手定位和 Claude Code 很像都是终端 Agent但在模型能力、工具链、权限模型上有自己的差异。Claude Code 的特点在于安装轻量、完全命令行化、和现有 Git 工作流无缝配合、权限模式设计得比较细。它不强制你换编辑器VS Code、Neovim、JetBrains 系都能配合使用。如果你已经习惯终端操作或者想要一个能接入 CI 脚本、能被其他工具调用的编程 AgentClaude Code 会更顺手。2.3 适合的场景从实际使用经验来看Claude Code 比较适合下面几类场景。第一类是“改别人代码”的场景。接手一个陌生项目时让 Claude Code 先扫描项目结构、生成项目说明能大幅缩短理解成本。第二类是“重复性重构”比如统一日志格式、替换废弃 API、给所有文件补充 license 头。第三类是“调试辅助”把报错贴给它让它结合代码上下文定位根因。第四类是“测试补全”让它读现有代码风格生成风格一致的单元测试。需要注意的是Claude Code 并不适合所有编程任务。它处理长链路、多文件、需要频繁人工确认的架构级改造时仍然需要开发者把任务拆小。工具能帮你写代码但“做什么、为什么做、做到什么程度算好”这些上下文还是得由你提供。3. 上下文工程读懂这次变革的关键3.1 上下文窗口与 Token 分配聊到系统提示词瘦身绕不开“上下文窗口”这个概念。上下文窗口是模型单次能接收的全部输入范围包括系统提示词、工具定义、对话历史、用户消息、以及模型读取到的文件内容。很多开发者容易忽略一个事实上下文窗口是共享的。系统提示词多占 5000 Token留给真实代码和文件内容的空间就少 5000 Token。Claude Code 处理大型项目时最贵的资源不是 API 调用次数而是上下文窗口里那 20 万甚至更多 Token 的“预算”。当系统提示词从“肥胖版”变成“精简版”省下来的空间可以用于加载更多相关代码、搜索结果、测试输出。模型看到的有效信息更多回答质量自然上升。这是一笔非常划算的“上下文预算置换”。3.2 信噪比决定回答质量上下文工程的本质是提高模型输入里的“信噪比”。信号是和当前任务直接相关的指令和代码噪声是背景说明、冗余规则、无关历史。系统提示词堆砌过多规则本质上是往模型输入里加噪声。比如你规定了一整套“代码风格九条”但当前任务只是改一个硬编码的端口号这九条风格规则几乎不会对结果产生任何正面影响反而占用了模型注意力。高信噪比的上下文应该满足两个条件第一条所有指令都是当前任务真正需要的第二条任何一条指令都足够具体不需要模型二次猜测。Claude Code 团队删提示词不是删“安全规则”而是删“可能有用但当前不相关的规则”。这正好引出了“按需加载”的思路。3.3 从“大而全”到“够用就好”过去几年社区里写系统提示词的主流风格是“大而全”把自己能想到的场景全部写进去希望模型永远不犯错。这种做法在模型能力早期可能有效因为模型本身理解力弱需要靠提示词补足。但现在的模型理解能力已经很强继续使用“大而全”策略反而会引入矛盾、稀释注意力、增加成本。新的思路是“够用就好”系统提示词里只放不可妥协的边界比如“禁止删除用户文件”“所有修改必须先备份”“涉及数据库操作必须先确认”。项目级规范下沉到 CLAUDE.md 这类项目记忆文件任务级说明放在用户消息里专业领域知识通过 Skills 机制在需要时动态加载。这种分层设计本质上是一次“按需加载”的架构改造。系统提示词是常驻内存的底层系统项目记忆是打包好的业务模块用户消息才是真正驱动当前行为的指令。理解了这三个层次你就能明白为什么删掉 80% 之后效果反而更好。3.4 一套可复用的系统提示词设计原则把 Claude Code 团队的思路抽象出来可以沉淀成一套适用于任何项目的方法论。第一只保留不可妥协的边界。能交给代码规范、静态检查工具解决的事情不要写进提示词。比如“函数必须有 docstring”这类风格要求交给 lint 工具比交给模型更可靠。第二指令越接近执行点越好。系统提示词里的规则离实际执行有很长距离模型很容易在执行中途“忘记”。相比之下把具体要求放在用户消息里或者放在工具描述里效果会明显更好。第三用结构化格式组织指令。模型对 XML、Markdown、JSON 这类结构化格式的解析能力更强。系统提示词如果用大段散文写规则模型还要自己归纳如果用标题、列表、XML 标签组织模型的指令遵循能力会显著提升。第四任何提示词改动都要做回归验证。删掉 80% 提示词不是靠感觉而是靠一整套评估任务不断回归。你改了自己的提示词模板也应该准备一组代表性测试用例每次改完跑一遍对比结果。4. 环境准备安装 Claude Code 与基础认证4.1 环境要求安装 Claude Code 之前先确认你的环境满足基础要求。Claude Code 以 npm 包形式分发因此需要 Node.js 环境。一般建议使用 Node.js 18 或更高版本具体版本要求以官方文档为准因为不同时期的 Claude Code 对 Node 版本的要求会有调整。操作系统方面macOS 和 Linux 是官方最成熟的平台Windows 可以通过原生终端或 WSL 使用。我个人的经验是如果你主要在 Windows 上做开发优先配置好 WSL 环境再安装 Claude Code能避开很多路径和权限问题。查看 Node 版本可以用node -v npm -v如果输出报错说明 Node.js 没有安装或没有加入系统 PATH需要先安装 Node.js LTS 版本。4.2 安装命令确认 Node.js 环境没问题后用 npm 全局安装 Claude Codenpm install -g anthropic-ai/claude-code安装完成后执行claude --version如果能看到版本号输出说明安装成功。这里需要提醒一下Claude Code 的迭代速度非常快版本号会持续更新如果你在文章发布日期后很久才看到记得先升级到最新版再开始使用。升级命令同样很简单npm update -g anthropic-ai/claude-code4.3 登录与 API Key 认证安装完成后需要完成认证才能开始使用。Claude Code 支持两种主流认证方式账号登录和 API Key。账号登录方式执行claude首次运行时工具会引导你完成登录流程可能会跳转浏览器完成授权。这种方式的优点是和 Claude 订阅绑定计费简单适合个人开发者日常使用。API Key 方式的思路是设置环境变量让 Claude Code 通过 Anthropic API 完成请求。你需要在 Anthropic 控制台创建 API Key然后在当前终端会话里导出export ANTHROPIC_API_KEY你的_API_Key之后启动claude就能直接使用。如果你使用 VS Code 扩展也可以在扩展设置里配置环境变量避免每次启动终端都要手动导出。需要特别说明的是Claude Code 的可用性、订阅策略、区域支持都取决于官方当前的政策。启动时如果收到类似“Claude Code might not be available in your country”的提示或者企业内部策略限制的提示请以官方支持列表和组织管理员说明为准不要尝试使用非官方渠道绕过限制。4.4 VS Code 扩展安装虽然 Claude Code 本身是命令行工具但在 VS Code 里使用效果更好因为它可以把终端、文件树、代码高亮放在同一个界面中。在 VS Code 扩展市场搜索 “Claude Code for VS Code”点击安装。安装完成后左侧会出现 Claude Code 的面板入口你可以直接在侧边栏发起对话也可以在集成终端中运行claude。VS Code 扩展的优势是模型修改代码时你能实时看到文件 diff模型运行命令时输出会直接展示在终端模型读到的文件会在编辑器中高亮显示。这套“所见即所得”的体验比纯命令行直观很多。如果你使用 API Key 方式认证可以在 VS Code 的settings.json中配置环境变量。下面是示例配置{ claude-code.environment: { ANTHROPIC_API_KEY: 你的_API_Key } }不同版本的扩展配置键名可能略有差异具体以你安装的版本说明为准。配置完成后重启 VS Code让环境变量生效。5. 实战从零配置一个 Claude Code 项目5.1 初始化项目与 CLAUDE.md现在进入本文最核心的实战环节。我们先创建一个小的 Python 项目再一步步配置 Claude Code并演示一个真实任务。先创建一个项目目录和示例代码文件mkdir demo-api cd demo-api创建processor.py内容是一个简单的 CSV 订单处理函数# 文件路径demo-api/processor.py import csv from pathlib import Path def filter_high_value_orders(input_path: str, output_path: str, threshold: float 1000.0): input_file Path(input_path) output_file Path(output_path) output_file.parent.mkdir(parentsTrue, exist_okTrue) with input_file.open(r, encodingutf-8, newline) as f: reader csv.DictReader(f) rows [row for row in reader if float(row[amount]) threshold] with output_file.open(w, encodingutf-8, newline) as f: writer csv.DictWriter(f, fieldnamesrows[0].keys()) writer.writeheader() writer.writerows(rows)再准备一份测试数据data/orders.csvorder_id,customer,amount 1001,Alice,800 1002,Bob,1500 1003,Carol,1200注意我故意在代码里留了一些隐患如果输入文件为空rows[0]会直接报错金额转换失败时没有明确异常提示编码格式写死了 UTF-8。这些都是后面让 Claude Code 修复的好素材。5.2 编写项目记忆文件 CLAUDE.md这是整篇文章最关键的一步。先不要急着让模型干活而是先写一份精简的CLAUDE.md。这个文件会被 Claude Code 在每次会话启动时自动读取相当于“项目级系统提示词”。# CLAUDE.md ## 项目简介 demo-api 是一个订单 CSV 处理工具输入文件在 data/ 目录处理结果写入 output/ 目录。 ## 技术约束 - 使用 Python 3.10 - 依赖统一声明在 requirements.txt - 优先使用标准库不引入重量级框架 ## 代码约定 - 所有函数必须包含 docstring - 文件读写统一使用 with 语句 - 错误处理必须返回可读的错误信息不允许静默吞异常这份 CLAUDE.md 完全遵循“够用就好”原则不写代码风格十条不写无关背景只写项目真正需要约束的部分。你写得越精炼模型就越容易执行。为什么要把项目规范放在 CLAUDE.md而不是写进系统提示词因为系统提示词对每个项目都是同一份而 CLAUDE.md 是每个项目独立的。项目知识绑定在项目里才能做到多项目切换时不串味。5.3 用 /init 生成项目记忆如果你已经有现成项目但不清楚怎么写 CLAUDE.md可以直接让 Claude Code 帮你生成。在项目目录下启动claude进入交互界面后输入斜杠命令/initClaude Code 会扫描项目结构、读取关键配置文件然后生成一份初始 CLAUDE.md。你不需要从头手工写只需要在生成结果上做删减。这里有一个很重要的经验/init生成的内容往往偏多你要像 Claude Code 团队删系统提示词那样把里面的冗余内容删掉。保留项目硬约束删掉过程性描述最后只留下“真正的边界”。5.4 权限模式与交互方式Claude Code 会执行文件修改、命令行操作所以它设计了权限模式来防止模型乱来。你可以在交互界面中用ShiftTab在几种模式之间循环切换。普通模式是最常用的安全模式模型每次要修改文件或执行命令时都会先征求你的同意。对于新项目和不可信的仓库建议保持在普通模式。自动接受修改模式适合你已经熟悉项目、且改动范围可控的场景。在这种模式下模型编辑文件时不再逐次询问效率明显提升但风险也更高建议只在你完全信任的仓库中使用。规划模式是只读模式模型可以读文件、做分析、输出方案但不能修改任何文件。这个模式非常适合“先让模型做技术方案你确认后再执行”的工作流。另外当模型在执行权限确认界面时你也可以用键盘快速操作。界面上通常会显示编号选项按1、2、3数字键可以快速选择对应动作按Tab可以快速批准当前请求。这个交互细节可以大幅减少重复按键尤其适合长任务批量操作时使用。5.5 运行一个真实任务现在让我们给 Claude Code 布置一个真实任务。在claude交互界面中输入请检查 processor.py 的健壮性修复两个问题输入文件为空时会抛出 IndexError金额字段无法转换为 float 时程序会崩溃。修复后帮我补充一个针对输入文件为空的单元测试。这是一个典型的“上下文工程实战”项目约束已经在 CLAUDE.md 里任务描述放在用户消息里没有堆砌任何多余规则。Claude Code 会先读取 CLAUDE.md再读 processor.py结合你的任务描述给出修复方案。预期它会做这些事情第一步读取processor.py和data/orders.csv理解当前数据结构第二步识别出reader为空时rows[0]会越界提出用显式判断替代第三步修改代码并补上类型检查逻辑第四步新建测试文件然后运行测试验证。如果你不想进入交互界面也可以直接用参数模式一次性发起任务claude 给 processor.py 补充空输入文件的保护逻辑并创建一个 tests/test_processor.py这种模式适合批量执行、对接 CI 脚本但要注意非交互模式下模型缺少你来确认的环节请务必在权限模式上做好限制。5.6 会话管理与上下文压缩Claude Code 在一个会话内会累积对话历史。任务越复杂历史越长上下文窗口占用就越高。当会话变得很长时你可以用/clear清理当前对话历史让模型重新开始避免历史噪声影响后续任务。如果会话很重要又想在不丢失关键信息的前提下压缩上下文可以使用/compact。它会生成一份当前会话的总结然后以总结代替完整历史继续对话。这相当于在上下文中做了一个“有损压缩”牺牲部分细节换回更充足的上下文窗口余量。到这里Claude Code 的安装、配置、基础交互和一次真实任务演示就完成了。接下来我们来处理大家最常遇到的坑。6. 常见问题与排查思路6.1 常见报错对照表我在社区和实际使用中经常看到下面这些报错先整理成一张速查表问题现象常见原因解决思路安装后claude命令找不到Node.js 未安装或 PATH 未配置检查 node -v重新安装 Node.js 并配置 PATH启动报process exited with code 3Node 版本过低、安装包损坏或环境变量异常升级 Node.js重新安装 Claude Code检查环境变量提示模型不被当前版本识别配置了当前版本不支持的模型名升级 Claude Code或检查模型配置名称是否正确提示组织已禁用订阅访问企业管理员关闭了该功能联系组织管理员确认策略提示当前区域不可用官方区域支持限制以官方支持列表为准不要使用非官方方式绕过会话运行到一半上下文耗尽单次会话内容过长使用 /compact 压缩或 /clear 开启新会话6.2 模型无法识别的处理有一个报错在社区里出现频率很高大致错误信息是deepseek-v4-pro is not a model this version of claude code recognizes如果你的模型请求是通过兼容接口、第三方网关或自定义配置发出的而当前 Claude Code 版本不认识你配置的模型名就会报类似错误。它本质上是 Claude Code 对模型名做了一次校验防止配置了不存在的模型。处理思路很直接先确认 Claude Code 是否已升级到最新版本因为新版本通常会扩充模型支持列表再检查模型配置的别名和当前网关提供的能力是否匹配必要时通过环境变量或网关映射改成它能识别的模型名。如果仍然报错就去查看官方文档中该版本的模型支持列表。需要提醒的是使用第三方兼容接口时务必遵守对应模型服务商的条款和你的组织合规要求在生产环境使用前先在小范围验证。6.3 订阅与区域限制很多用户遇到的另一个问题是订阅和区域限制。比如企业环境下管理员可能通过组织策略关闭了 Claude Code 的订阅访问启动时会看到类似 “your organization has disabled claude subscription access for claude code” 的提示。这种限制是管理员故意设置的解决办法是联系组织管理员而不是自行绕过。区域限制类似。Claude Code 的可用区域由官方政策决定如果启动时提示你所在区域不受支持请以官方文档公布的支持清单为准。从工程角度讲用兼容网关、本地模型方案确实存在但它们涉及服务条款、合规和安全问题不能作为默认推荐。7. Claude Code 场景下的上下文工程实践7.1 把项目知识写进 CLAUDE.md 而不是提示词文章开头提到 Claude Code 团队删掉了 80% 系统提示词这个思路落到你的日常使用中第一步就是重新审视你的上下文分层。系统提示词层通常是工具内置的你无法直接修改也不应该去修改。CLAUDE.md 层每个项目一份存放项目特有的硬约束比如技术栈范围、目录约定、不允许触碰的文件。用户消息层存放当前任务的具体指令比如要修什么 bug、要实现什么功能。使用 Claude Code 时项目知识只该放在 CLAUDE.md 里。如果你把项目知识零零散散写进每次对话就是典型的“低信噪比上下文”重复、占空间还可能互相矛盾。一次会话里输入一份精简的 CLAUDE.md比每次啰嗦地复制粘贴项目说明效果要好得多。7.2 保持会话聚焦从上下文工程角度看一个会话天然是一个“上下文单元”。会话里塞的任务越多历史越乱模型就越难抓住重点。我的建议是一个会话只处理一个任务。需要做多个不同模块的改动时用/clear开启新会话让模型重新读取干净的上下文。重要任务开始前先在规划模式里让模型输出执行方案你确认后再切到普通模式执行。这个“先规划再执行”的习惯能避免模型在错误方向上一路狂奔。7.3 显式声明输出格式Claude Code 的上下文工程不只体现在输入质量上也体现在输出格式上。任务描述里如果只写“优化这段代码”模型可能输出一个毫无上下文的代码片段。但如果你把格式要求放进任务里效果会明显不同。更推荐的任务描述是这样请修复 processor.py 中空输入文件导致的 IndexError。要求 1. 先说明根因 2. 给出修改后的完整函数 3. 补充一个 tests/test_processor.py 单元测试。显式声明输出格式本质上是把“用户消息”变成结构化指令降低模型生成阶段的熵。这和 Claude Code 团队删提示词的逻辑一脉相承不是不给指令而是把指令放在正确的位置、用正确的结构给出。7.4 成本与上下文窗口控制上下文工程还有一个容易被忽略的维度成本。Claude Code 每次工具调用都会把当前上下文完整发送给模型Token 消耗非常快。上下文窗口里多出来的每一段无关历史都是真金白银。控制成本可以从几个角度入手。会话超过一定轮次后主动/clear大型文件不要让模型全文读取而是让它先用grep或find定位关键片段能引用文件路径就不要贴文件内容让模型按需读取。这些操作对最终结果影响很小但对 Token 消耗影响巨大。另外Claude Code 的迭代中陆续加入了一些动态指令加载能力比如 Skills 机制和按需加载的工具描述。这些机制可以把“可能用到的专业知识”拆成独立单元等到真正需要时再注入上下文。这比把所有知识堆在系统提示词里要先进得多也是“2026 上下文工程规矩变了”这句话背后最实在的技术趋势。7.5 安全边界最后说安全。让 AI 编程助手直接操作你的文件系统和终端相当于给了一个“能执行命令的实习生”。权限模式再方便也不能替代安全意识。我建议至少做到以下几点API Key 不要提交到 Git 仓库也不要写死在代码里统一通过环境变量或密钥管理服务注入Claude Code 使用最小权限原则普通任务保持在普通模式下自动接受模式只用于临时、可信的场景涉及删除文件、修改数据库、覆盖配置的操作无论模型多么自信都要先备份再执行生产环境不要随意开启自动执行最好先在一个干净的测试仓库里验证。8. 总结与下一步这篇文章从“Claude Code 团队删掉 80% 系统提示词”这个案例出发聊透了上下文工程的核心变化系统提示词从“大而全”转向“够用就好”项目知识从提示词下沉到 CLAUDE.md指令从散文式描述变成结构化表达。围绕 Claude Code你已经掌握了完整链路从 Node.js 环境准备、npm 安装、账号登录与 API Key 认证到 VS Code 扩展配置、CLAUDE.md 项目记忆、/init 生成、权限模式切换、/compact 上下文压缩再到常见报错的排查思路和成本控制手段。这些实操内容放在真实项目里就是一套可以直接上手的 AI 编程工作流。下一步建议你从三个方向继续深入一是研究 Claude Code 的 Skills 机制把专业领域的知识打包成按需加载的技能进一步压缩常驻上下文二是把 CLAUDE.md 写得足够精简做成自己的项目模板新项目直接复用三是给自己维护一组回归测试用例每次调整 CLAUDE.md 或任务模板后跑一遍用数据说话而不是凭感觉判断“这次是不是更聪明了”。编程工具的进化速度很快但上下文工程的核心原则不会变让模型看到更多有效信息更少无关噪声把指令放在正确的位置用最省 Token 的方式表达。你可以先从一个小项目开始给项目写一份足够精简的 CLAUDE.md再让 Claude Code 做一次真实重构亲身感受一下“做减法”带来的稳定性和效率提升。如果本文对你有帮助可以收藏备用后续实际使用中遇到新问题也欢迎回来对照排查思路。
这段时间 AI 编程工具圈子里有一个很有意思的讨论那个造出 Claude Code 的团队在一次公开分享中被问到“你们的系统提示词到底写了多少东西”答案却出乎很多人意料——他们亲手删掉了系统提示词大约 80% 的内容跑分和实际任务完成率反而更稳定了。这和我们过去几年养成的习惯完全相反。过去我们写提示词总觉得写得越长越细越安全最好把所有规则、所有格式要求、所有禁忌一股脑塞进系统提示词里。但 Claude Code 团队的做法等于把“提示词越长越好”这条路直接堵死了。本文将围绕这个话题展开先聊聊系统提示词为什么要“做减法”再系统梳理 Claude Code 的安装、配置、认证与实战用法最后回到上下文工程这个核心主题给出你可以直接搬到项目里的设计方法。不管你是刚接触 Claude Code 的新手还是已经在用 AI 编程助手、想进一步压榨效率的开发者这篇文章都能给你一套从概念到落地的完整方案。1. 背景一次关于系统提示词的“减法实验”1.1 造 Claude Code 的人为什么删掉 80% 系统提示词Claude Code 是 Anthropic 推出的命令行编程助手能直接读取项目文件、修改代码、运行命令像一个驻留在终端里的 AI 工程师。这类工具天然依赖系统提示词来约束模型行为什么时候该读文件、什么时候该问用户、代码改到什么程度算完成、危险操作要不要拦截。按理说这种约束越多模型应该越听话。但 Claude Code 团队在分享中透露的真实情况是系统提示词堆到一定程度后模型反而不稳定了。指令多了模型不知道该优先听哪一条提示词长了真实代码内容能被分配到的上下文窗口就小了规则之间偶尔互相冲突模型只能随机挑一条执行。于是他们做了一次大瘦身把系统提示词里大量冗余的背景说明、重复示例、历史遗留规则删掉只保留真正不可妥协的行为边界。结果任务完成率没有下降甚至因为上下文更干净模型在复杂仓库里的表现还更好了。具体删除比例在不同场合说法略有出入但核心结论是一致的系统提示词不是仓库而是“宪法”。宪法只写最高原则不需要把每一条实施细则都写进去。1.2 系统提示词不是越长越好为什么更长的系统提示词反而会拖累模型这背后有几个很实际的原因。第一是 Token 成本。每次调用模型系统提示词都会作为固定的输入 Token 被完整计算。假设系统提示词从 2000 Token 涨到 8000 Token每轮对话多消耗 6000 Token一天跑几百轮任务成本差异会非常明显。第二是注意力稀释。Transformer 架构虽然有很强的注意力机制但模型并不会对输入里的每个词一视同仁。指令越多单条指令的“权重”就越低尤其是当多条指令出现在相隔很远的位置时模型很容易在执行中段把前面的要求忘掉。第三是指令冲突。系统提示词写多了难免出现前后矛盾的情况。比如前面要求“不要修改配置文件”后面又写着“可以用标准库读写配置”。模型遇到这种冲突只能猜猜错了就是事故。所以系统提示词的设计目标不是“覆盖所有情况”而是“在最小体积内定义最大边界”。这恰恰是 Claude Code 团队这次改动最值得学习的点。1.3 这则消息对普通开发者的启示很多开发者看到新闻的第一反应是“删的是他们的系统提示词跟我有什么关系”其实关系非常大。你用 Claude Code、Codex、Cursor 这类工具时模型的行为同样受三层上下文影响模型内置的系统提示词、工具自带的指令、你提供的项目上下文。Claude Code 团队删掉的 80%相当于告诉你工具自带的指令已经在做减法那你自己的项目上下文也不该继续堆砌。换句话说上下文工程的新规矩是把知识放到该放的地方而不是全部塞进提示词。项目规范写进 CLAUDE.md任务说明放进对话模型行为约束才交给系统提示词。这个思路正是本文后面所有实战内容的主线。2. Claude Code 是什么定位与核心能力2.1 官方 CLI 编程助手Claude Code 是 Anthropic 官方推出的终端编程助手核心使用方式是命令行交互。你进入项目目录执行一条命令就能在终端里和 Claude 对话让它读代码、改代码、跑测试、查日志。它和网页版 Claude 最大的区别在于“动手能力”。网页版再聪明也只能给你贴代码Claude Code 会直接在你本地文件系统上操作搜索项目结构、定位函数定义、批量替换代码、运行测试并读取报错。它把这些操作封装成了一个个工具比如读取文件、编辑文件、执行 Bash 命令再由模型判断下一步该调用哪个工具。这种能力让 Claude Code 特别适合处理“工作量大但理解成本低”的任务比如补全单元测试、修复特定报错、把某个模块从同步改成异步、批量重命名变量等。开发者只需要描述目标具体路径由工具自己拆解。2.2 与 Codex、Cursor 等工具的边界现在 AI 编程工具不少很多读者会拿 Claude Code 和 Codex、Cursor、GitHub Copilot 做对比。简单梳理一下边界方便你判断自己该用哪个。Cursor 是编辑器形态的 AI 编程工具给 VS Code 系用户提供 IDE 内补全、对话框、Agent 等功能使用体验更偏向“图形界面”。Codex 是 OpenAI 推出的命令行编程助手定位和 Claude Code 很像都是终端 Agent但在模型能力、工具链、权限模型上有自己的差异。Claude Code 的特点在于安装轻量、完全命令行化、和现有 Git 工作流无缝配合、权限模式设计得比较细。它不强制你换编辑器VS Code、Neovim、JetBrains 系都能配合使用。如果你已经习惯终端操作或者想要一个能接入 CI 脚本、能被其他工具调用的编程 AgentClaude Code 会更顺手。2.3 适合的场景从实际使用经验来看Claude Code 比较适合下面几类场景。第一类是“改别人代码”的场景。接手一个陌生项目时让 Claude Code 先扫描项目结构、生成项目说明能大幅缩短理解成本。第二类是“重复性重构”比如统一日志格式、替换废弃 API、给所有文件补充 license 头。第三类是“调试辅助”把报错贴给它让它结合代码上下文定位根因。第四类是“测试补全”让它读现有代码风格生成风格一致的单元测试。需要注意的是Claude Code 并不适合所有编程任务。它处理长链路、多文件、需要频繁人工确认的架构级改造时仍然需要开发者把任务拆小。工具能帮你写代码但“做什么、为什么做、做到什么程度算好”这些上下文还是得由你提供。3. 上下文工程读懂这次变革的关键3.1 上下文窗口与 Token 分配聊到系统提示词瘦身绕不开“上下文窗口”这个概念。上下文窗口是模型单次能接收的全部输入范围包括系统提示词、工具定义、对话历史、用户消息、以及模型读取到的文件内容。很多开发者容易忽略一个事实上下文窗口是共享的。系统提示词多占 5000 Token留给真实代码和文件内容的空间就少 5000 Token。Claude Code 处理大型项目时最贵的资源不是 API 调用次数而是上下文窗口里那 20 万甚至更多 Token 的“预算”。当系统提示词从“肥胖版”变成“精简版”省下来的空间可以用于加载更多相关代码、搜索结果、测试输出。模型看到的有效信息更多回答质量自然上升。这是一笔非常划算的“上下文预算置换”。3.2 信噪比决定回答质量上下文工程的本质是提高模型输入里的“信噪比”。信号是和当前任务直接相关的指令和代码噪声是背景说明、冗余规则、无关历史。系统提示词堆砌过多规则本质上是往模型输入里加噪声。比如你规定了一整套“代码风格九条”但当前任务只是改一个硬编码的端口号这九条风格规则几乎不会对结果产生任何正面影响反而占用了模型注意力。高信噪比的上下文应该满足两个条件第一条所有指令都是当前任务真正需要的第二条任何一条指令都足够具体不需要模型二次猜测。Claude Code 团队删提示词不是删“安全规则”而是删“可能有用但当前不相关的规则”。这正好引出了“按需加载”的思路。3.3 从“大而全”到“够用就好”过去几年社区里写系统提示词的主流风格是“大而全”把自己能想到的场景全部写进去希望模型永远不犯错。这种做法在模型能力早期可能有效因为模型本身理解力弱需要靠提示词补足。但现在的模型理解能力已经很强继续使用“大而全”策略反而会引入矛盾、稀释注意力、增加成本。新的思路是“够用就好”系统提示词里只放不可妥协的边界比如“禁止删除用户文件”“所有修改必须先备份”“涉及数据库操作必须先确认”。项目级规范下沉到 CLAUDE.md 这类项目记忆文件任务级说明放在用户消息里专业领域知识通过 Skills 机制在需要时动态加载。这种分层设计本质上是一次“按需加载”的架构改造。系统提示词是常驻内存的底层系统项目记忆是打包好的业务模块用户消息才是真正驱动当前行为的指令。理解了这三个层次你就能明白为什么删掉 80% 之后效果反而更好。3.4 一套可复用的系统提示词设计原则把 Claude Code 团队的思路抽象出来可以沉淀成一套适用于任何项目的方法论。第一只保留不可妥协的边界。能交给代码规范、静态检查工具解决的事情不要写进提示词。比如“函数必须有 docstring”这类风格要求交给 lint 工具比交给模型更可靠。第二指令越接近执行点越好。系统提示词里的规则离实际执行有很长距离模型很容易在执行中途“忘记”。相比之下把具体要求放在用户消息里或者放在工具描述里效果会明显更好。第三用结构化格式组织指令。模型对 XML、Markdown、JSON 这类结构化格式的解析能力更强。系统提示词如果用大段散文写规则模型还要自己归纳如果用标题、列表、XML 标签组织模型的指令遵循能力会显著提升。第四任何提示词改动都要做回归验证。删掉 80% 提示词不是靠感觉而是靠一整套评估任务不断回归。你改了自己的提示词模板也应该准备一组代表性测试用例每次改完跑一遍对比结果。4. 环境准备安装 Claude Code 与基础认证4.1 环境要求安装 Claude Code 之前先确认你的环境满足基础要求。Claude Code 以 npm 包形式分发因此需要 Node.js 环境。一般建议使用 Node.js 18 或更高版本具体版本要求以官方文档为准因为不同时期的 Claude Code 对 Node 版本的要求会有调整。操作系统方面macOS 和 Linux 是官方最成熟的平台Windows 可以通过原生终端或 WSL 使用。我个人的经验是如果你主要在 Windows 上做开发优先配置好 WSL 环境再安装 Claude Code能避开很多路径和权限问题。查看 Node 版本可以用node -v npm -v如果输出报错说明 Node.js 没有安装或没有加入系统 PATH需要先安装 Node.js LTS 版本。4.2 安装命令确认 Node.js 环境没问题后用 npm 全局安装 Claude Codenpm install -g anthropic-ai/claude-code安装完成后执行claude --version如果能看到版本号输出说明安装成功。这里需要提醒一下Claude Code 的迭代速度非常快版本号会持续更新如果你在文章发布日期后很久才看到记得先升级到最新版再开始使用。升级命令同样很简单npm update -g anthropic-ai/claude-code4.3 登录与 API Key 认证安装完成后需要完成认证才能开始使用。Claude Code 支持两种主流认证方式账号登录和 API Key。账号登录方式执行claude首次运行时工具会引导你完成登录流程可能会跳转浏览器完成授权。这种方式的优点是和 Claude 订阅绑定计费简单适合个人开发者日常使用。API Key 方式的思路是设置环境变量让 Claude Code 通过 Anthropic API 完成请求。你需要在 Anthropic 控制台创建 API Key然后在当前终端会话里导出export ANTHROPIC_API_KEY你的_API_Key之后启动claude就能直接使用。如果你使用 VS Code 扩展也可以在扩展设置里配置环境变量避免每次启动终端都要手动导出。需要特别说明的是Claude Code 的可用性、订阅策略、区域支持都取决于官方当前的政策。启动时如果收到类似“Claude Code might not be available in your country”的提示或者企业内部策略限制的提示请以官方支持列表和组织管理员说明为准不要尝试使用非官方渠道绕过限制。4.4 VS Code 扩展安装虽然 Claude Code 本身是命令行工具但在 VS Code 里使用效果更好因为它可以把终端、文件树、代码高亮放在同一个界面中。在 VS Code 扩展市场搜索 “Claude Code for VS Code”点击安装。安装完成后左侧会出现 Claude Code 的面板入口你可以直接在侧边栏发起对话也可以在集成终端中运行claude。VS Code 扩展的优势是模型修改代码时你能实时看到文件 diff模型运行命令时输出会直接展示在终端模型读到的文件会在编辑器中高亮显示。这套“所见即所得”的体验比纯命令行直观很多。如果你使用 API Key 方式认证可以在 VS Code 的settings.json中配置环境变量。下面是示例配置{ claude-code.environment: { ANTHROPIC_API_KEY: 你的_API_Key } }不同版本的扩展配置键名可能略有差异具体以你安装的版本说明为准。配置完成后重启 VS Code让环境变量生效。5. 实战从零配置一个 Claude Code 项目5.1 初始化项目与 CLAUDE.md现在进入本文最核心的实战环节。我们先创建一个小的 Python 项目再一步步配置 Claude Code并演示一个真实任务。先创建一个项目目录和示例代码文件mkdir demo-api cd demo-api创建processor.py内容是一个简单的 CSV 订单处理函数# 文件路径demo-api/processor.py import csv from pathlib import Path def filter_high_value_orders(input_path: str, output_path: str, threshold: float 1000.0): input_file Path(input_path) output_file Path(output_path) output_file.parent.mkdir(parentsTrue, exist_okTrue) with input_file.open(r, encodingutf-8, newline) as f: reader csv.DictReader(f) rows [row for row in reader if float(row[amount]) threshold] with output_file.open(w, encodingutf-8, newline) as f: writer csv.DictWriter(f, fieldnamesrows[0].keys()) writer.writeheader() writer.writerows(rows)再准备一份测试数据data/orders.csvorder_id,customer,amount 1001,Alice,800 1002,Bob,1500 1003,Carol,1200注意我故意在代码里留了一些隐患如果输入文件为空rows[0]会直接报错金额转换失败时没有明确异常提示编码格式写死了 UTF-8。这些都是后面让 Claude Code 修复的好素材。5.2 编写项目记忆文件 CLAUDE.md这是整篇文章最关键的一步。先不要急着让模型干活而是先写一份精简的CLAUDE.md。这个文件会被 Claude Code 在每次会话启动时自动读取相当于“项目级系统提示词”。# CLAUDE.md ## 项目简介 demo-api 是一个订单 CSV 处理工具输入文件在 data/ 目录处理结果写入 output/ 目录。 ## 技术约束 - 使用 Python 3.10 - 依赖统一声明在 requirements.txt - 优先使用标准库不引入重量级框架 ## 代码约定 - 所有函数必须包含 docstring - 文件读写统一使用 with 语句 - 错误处理必须返回可读的错误信息不允许静默吞异常这份 CLAUDE.md 完全遵循“够用就好”原则不写代码风格十条不写无关背景只写项目真正需要约束的部分。你写得越精炼模型就越容易执行。为什么要把项目规范放在 CLAUDE.md而不是写进系统提示词因为系统提示词对每个项目都是同一份而 CLAUDE.md 是每个项目独立的。项目知识绑定在项目里才能做到多项目切换时不串味。5.3 用 /init 生成项目记忆如果你已经有现成项目但不清楚怎么写 CLAUDE.md可以直接让 Claude Code 帮你生成。在项目目录下启动claude进入交互界面后输入斜杠命令/initClaude Code 会扫描项目结构、读取关键配置文件然后生成一份初始 CLAUDE.md。你不需要从头手工写只需要在生成结果上做删减。这里有一个很重要的经验/init生成的内容往往偏多你要像 Claude Code 团队删系统提示词那样把里面的冗余内容删掉。保留项目硬约束删掉过程性描述最后只留下“真正的边界”。5.4 权限模式与交互方式Claude Code 会执行文件修改、命令行操作所以它设计了权限模式来防止模型乱来。你可以在交互界面中用ShiftTab在几种模式之间循环切换。普通模式是最常用的安全模式模型每次要修改文件或执行命令时都会先征求你的同意。对于新项目和不可信的仓库建议保持在普通模式。自动接受修改模式适合你已经熟悉项目、且改动范围可控的场景。在这种模式下模型编辑文件时不再逐次询问效率明显提升但风险也更高建议只在你完全信任的仓库中使用。规划模式是只读模式模型可以读文件、做分析、输出方案但不能修改任何文件。这个模式非常适合“先让模型做技术方案你确认后再执行”的工作流。另外当模型在执行权限确认界面时你也可以用键盘快速操作。界面上通常会显示编号选项按1、2、3数字键可以快速选择对应动作按Tab可以快速批准当前请求。这个交互细节可以大幅减少重复按键尤其适合长任务批量操作时使用。5.5 运行一个真实任务现在让我们给 Claude Code 布置一个真实任务。在claude交互界面中输入请检查 processor.py 的健壮性修复两个问题输入文件为空时会抛出 IndexError金额字段无法转换为 float 时程序会崩溃。修复后帮我补充一个针对输入文件为空的单元测试。这是一个典型的“上下文工程实战”项目约束已经在 CLAUDE.md 里任务描述放在用户消息里没有堆砌任何多余规则。Claude Code 会先读取 CLAUDE.md再读 processor.py结合你的任务描述给出修复方案。预期它会做这些事情第一步读取processor.py和data/orders.csv理解当前数据结构第二步识别出reader为空时rows[0]会越界提出用显式判断替代第三步修改代码并补上类型检查逻辑第四步新建测试文件然后运行测试验证。如果你不想进入交互界面也可以直接用参数模式一次性发起任务claude 给 processor.py 补充空输入文件的保护逻辑并创建一个 tests/test_processor.py这种模式适合批量执行、对接 CI 脚本但要注意非交互模式下模型缺少你来确认的环节请务必在权限模式上做好限制。5.6 会话管理与上下文压缩Claude Code 在一个会话内会累积对话历史。任务越复杂历史越长上下文窗口占用就越高。当会话变得很长时你可以用/clear清理当前对话历史让模型重新开始避免历史噪声影响后续任务。如果会话很重要又想在不丢失关键信息的前提下压缩上下文可以使用/compact。它会生成一份当前会话的总结然后以总结代替完整历史继续对话。这相当于在上下文中做了一个“有损压缩”牺牲部分细节换回更充足的上下文窗口余量。到这里Claude Code 的安装、配置、基础交互和一次真实任务演示就完成了。接下来我们来处理大家最常遇到的坑。6. 常见问题与排查思路6.1 常见报错对照表我在社区和实际使用中经常看到下面这些报错先整理成一张速查表问题现象常见原因解决思路安装后claude命令找不到Node.js 未安装或 PATH 未配置检查 node -v重新安装 Node.js 并配置 PATH启动报process exited with code 3Node 版本过低、安装包损坏或环境变量异常升级 Node.js重新安装 Claude Code检查环境变量提示模型不被当前版本识别配置了当前版本不支持的模型名升级 Claude Code或检查模型配置名称是否正确提示组织已禁用订阅访问企业管理员关闭了该功能联系组织管理员确认策略提示当前区域不可用官方区域支持限制以官方支持列表为准不要使用非官方方式绕过会话运行到一半上下文耗尽单次会话内容过长使用 /compact 压缩或 /clear 开启新会话6.2 模型无法识别的处理有一个报错在社区里出现频率很高大致错误信息是deepseek-v4-pro is not a model this version of claude code recognizes如果你的模型请求是通过兼容接口、第三方网关或自定义配置发出的而当前 Claude Code 版本不认识你配置的模型名就会报类似错误。它本质上是 Claude Code 对模型名做了一次校验防止配置了不存在的模型。处理思路很直接先确认 Claude Code 是否已升级到最新版本因为新版本通常会扩充模型支持列表再检查模型配置的别名和当前网关提供的能力是否匹配必要时通过环境变量或网关映射改成它能识别的模型名。如果仍然报错就去查看官方文档中该版本的模型支持列表。需要提醒的是使用第三方兼容接口时务必遵守对应模型服务商的条款和你的组织合规要求在生产环境使用前先在小范围验证。6.3 订阅与区域限制很多用户遇到的另一个问题是订阅和区域限制。比如企业环境下管理员可能通过组织策略关闭了 Claude Code 的订阅访问启动时会看到类似 “your organization has disabled claude subscription access for claude code” 的提示。这种限制是管理员故意设置的解决办法是联系组织管理员而不是自行绕过。区域限制类似。Claude Code 的可用区域由官方政策决定如果启动时提示你所在区域不受支持请以官方文档公布的支持清单为准。从工程角度讲用兼容网关、本地模型方案确实存在但它们涉及服务条款、合规和安全问题不能作为默认推荐。7. Claude Code 场景下的上下文工程实践7.1 把项目知识写进 CLAUDE.md 而不是提示词文章开头提到 Claude Code 团队删掉了 80% 系统提示词这个思路落到你的日常使用中第一步就是重新审视你的上下文分层。系统提示词层通常是工具内置的你无法直接修改也不应该去修改。CLAUDE.md 层每个项目一份存放项目特有的硬约束比如技术栈范围、目录约定、不允许触碰的文件。用户消息层存放当前任务的具体指令比如要修什么 bug、要实现什么功能。使用 Claude Code 时项目知识只该放在 CLAUDE.md 里。如果你把项目知识零零散散写进每次对话就是典型的“低信噪比上下文”重复、占空间还可能互相矛盾。一次会话里输入一份精简的 CLAUDE.md比每次啰嗦地复制粘贴项目说明效果要好得多。7.2 保持会话聚焦从上下文工程角度看一个会话天然是一个“上下文单元”。会话里塞的任务越多历史越乱模型就越难抓住重点。我的建议是一个会话只处理一个任务。需要做多个不同模块的改动时用/clear开启新会话让模型重新读取干净的上下文。重要任务开始前先在规划模式里让模型输出执行方案你确认后再切到普通模式执行。这个“先规划再执行”的习惯能避免模型在错误方向上一路狂奔。7.3 显式声明输出格式Claude Code 的上下文工程不只体现在输入质量上也体现在输出格式上。任务描述里如果只写“优化这段代码”模型可能输出一个毫无上下文的代码片段。但如果你把格式要求放进任务里效果会明显不同。更推荐的任务描述是这样请修复 processor.py 中空输入文件导致的 IndexError。要求 1. 先说明根因 2. 给出修改后的完整函数 3. 补充一个 tests/test_processor.py 单元测试。显式声明输出格式本质上是把“用户消息”变成结构化指令降低模型生成阶段的熵。这和 Claude Code 团队删提示词的逻辑一脉相承不是不给指令而是把指令放在正确的位置、用正确的结构给出。7.4 成本与上下文窗口控制上下文工程还有一个容易被忽略的维度成本。Claude Code 每次工具调用都会把当前上下文完整发送给模型Token 消耗非常快。上下文窗口里多出来的每一段无关历史都是真金白银。控制成本可以从几个角度入手。会话超过一定轮次后主动/clear大型文件不要让模型全文读取而是让它先用grep或find定位关键片段能引用文件路径就不要贴文件内容让模型按需读取。这些操作对最终结果影响很小但对 Token 消耗影响巨大。另外Claude Code 的迭代中陆续加入了一些动态指令加载能力比如 Skills 机制和按需加载的工具描述。这些机制可以把“可能用到的专业知识”拆成独立单元等到真正需要时再注入上下文。这比把所有知识堆在系统提示词里要先进得多也是“2026 上下文工程规矩变了”这句话背后最实在的技术趋势。7.5 安全边界最后说安全。让 AI 编程助手直接操作你的文件系统和终端相当于给了一个“能执行命令的实习生”。权限模式再方便也不能替代安全意识。我建议至少做到以下几点API Key 不要提交到 Git 仓库也不要写死在代码里统一通过环境变量或密钥管理服务注入Claude Code 使用最小权限原则普通任务保持在普通模式下自动接受模式只用于临时、可信的场景涉及删除文件、修改数据库、覆盖配置的操作无论模型多么自信都要先备份再执行生产环境不要随意开启自动执行最好先在一个干净的测试仓库里验证。8. 总结与下一步这篇文章从“Claude Code 团队删掉 80% 系统提示词”这个案例出发聊透了上下文工程的核心变化系统提示词从“大而全”转向“够用就好”项目知识从提示词下沉到 CLAUDE.md指令从散文式描述变成结构化表达。围绕 Claude Code你已经掌握了完整链路从 Node.js 环境准备、npm 安装、账号登录与 API Key 认证到 VS Code 扩展配置、CLAUDE.md 项目记忆、/init 生成、权限模式切换、/compact 上下文压缩再到常见报错的排查思路和成本控制手段。这些实操内容放在真实项目里就是一套可以直接上手的 AI 编程工作流。下一步建议你从三个方向继续深入一是研究 Claude Code 的 Skills 机制把专业领域的知识打包成按需加载的技能进一步压缩常驻上下文二是把 CLAUDE.md 写得足够精简做成自己的项目模板新项目直接复用三是给自己维护一组回归测试用例每次调整 CLAUDE.md 或任务模板后跑一遍用数据说话而不是凭感觉判断“这次是不是更聪明了”。编程工具的进化速度很快但上下文工程的核心原则不会变让模型看到更多有效信息更少无关噪声把指令放在正确的位置用最省 Token 的方式表达。你可以先从一个小项目开始给项目写一份足够精简的 CLAUDE.md再让 Claude Code 做一次真实重构亲身感受一下“做减法”带来的稳定性和效率提升。如果本文对你有帮助可以收藏备用后续实际使用中遇到新问题也欢迎回来对照排查思路。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
