企业官网建设流程全解析

最近 Claude Code 的开发者圈子里一直流传一个反直觉的说法：Anthropic 工程师在一次内部测试或者技术分享中透露，把 Claude Code 的系统提示词砍掉 80% 之后，模型在真实编码任务中的表现反而更好了。很多第一次听到这个结论的人都会愣一下，因为在传统提示词工程的认知里，提示词写得越详细、规则给得越足，模型的输出就应该越稳定。但在 Claude Code 这种工具链里，事情没有那么简单。

这篇文章会围绕这条社区讨论展开，把 Claude Code 的系统提示词拆开看：它到底由哪些部分组成，为什么规则越多效果不一定越好，以及我们如何通过 CLAUDE.md 做一次真实的“提示词瘦身”。同时也会覆盖 Claude Code 的环境安装、常见报错排查、Skills 与 Agent 的区别，以及团队项目里维护提示词配置的一些工程建议。

如果你正在用 Claude Code 做日常开发，或者刚准备从零开始学习这一类 AI 编程工具，下面这份笔记应该能给你省下不少弯路。

1. 背景：一个关于 System Prompt 瘦身的讨论

1.1 这条讨论是从哪来的

先说明一下背景：目前这个话题主要来自开发者社区的转述和二次讨论，并没有一份可供下载的官方技术报告。所以“砍掉 80%”更像是一个测试结论或者分享案例，而不是一个需要被当成黄金法则的官方指标。但它的传播速度非常快，原因是很多 Claude Code 用户在实际项目中确实遇到了类似的体验：CLAUDE.md 写得很长，规则列了一大堆，结果模型反而开始“过度遵守”，动不动就停下来确认、拒绝执行，甚至把时间浪费在自我约束上。

类似的规律在早期的 Prompt Engineering 社区也出现过：“Less is More”并不是一句鸡汤。当模型的基础能力足够强时，大量重复、冗余、互相矛盾的指令只会增加系统提示词的噪音，并不会带来额外的行为增益。Claude Code 恰好是这种情况的典型样本，因为它本身已经内置了一套非常完整的主系统提示词，用来控制工具调用、文件读写、Shell 执行和安全边界。用户侧再往里面堆一大堆意义不大的“行为准则”，很容易产生干扰。

我在本地复测过几次类似场景，结论和社区里的方向一致：把 CLAUDE.md 里那些“我们要做一个优秀的助手”“你要先思考再回答”“请不要随意修改文件”之类的话删掉之后，模型的行动反而更直接，错误确认的次数也会明显下降。当然，这个体验和具体任务类型有关，后面我会详细解释。

1.2 Claude Code 是什么

Claude Code 是 Anthropic 推出的命令行编程助手，你可以把它理解为跑在终端里的 AI 开发搭档。它不只是聊天，而是能读取项目文件、执行命令、修改代码、运行测试，再根据执行结果决定下一步操作。和普通的 API 调用相比，Claude Code 本身是一个闭环工具，目标和传统 IDE 插件有些接近，但运行方式完全围绕终端和文件系统展开。

它的工作方式和 Agent 类似：模型在每一步可以选择调用工具，比如读取文件、搜索符号、执行 Shell 命令，然后观察工具返回结果再继续。这种“感知—决策—行动—再感知”的循环，决定了 Claude Code 的性能高度依赖系统提示词的设计。因为每多一条规则，模型在真实行动之前都要先处理一层指令约束，而约束和约束之间如果存在冲突，模型还要额外消耗思考资源去调和。

简单说，Claude Code 的系统提示词不是“给模型看的说明书”，它本质上是模型每轮决策的前置上下文，直接影响工具选择、行动速度和安全行为。这也是为什么“提示词瘦身”在 Claude Code 上会比普通聊天场景更敏感。

1.3 为什么“系统提示词太长”会成为负担

为了理解这一点，可以先做一个类比。假设你招了一位经验丰富的工程师，他本身已经知道怎么写代码、怎么跑测试、怎么保证代码质量，这时候你在工位上贴满 100 条“要细心”“要负责任”“不要写出 bug”“遇到问题先深呼吸”的标语，你觉得他的产出会变快吗？

大概率不会。甚至可能因为每条标语都在强调不同维度的要求，导致他在做具体任务时反复犹豫。

Claude Code 也一样。模型内置的主系统提示词已经覆盖了基本行为规范。你在 CLAUDE.md 里再写“你是这个项目的高级 AI 编程助手”“你拥有丰富的架构经验”“你必须在行动之前充分思考”这类话，并不会让模型能力变强，只会让系统提示词的总长度进一步膨胀。更关键的是，模型对上下文的注意力是有限资源，指令越多，真正和当前任务相关的关键信息——比如项目路径、技术栈、命令规范、文件结构——被注意到的概率反而可能下降。

所以社区里讨论的“砍掉 80% 系统提示词”，本质上是把用户侧注入的 CLAUDE.md 从一大堆抽象的、重复的、口号式的规则，压缩成几条真正必要的硬性约束和任务元信息。这不是否定系统提示词本身的价值，而是把位置让给更有用的内容。

2. 环境准备与 Claude Code 安装

2.1 前置环境说明

在开始做提示词实验之前，你至少需要准备以下环境：

• 一个可用的终端环境，Windows 建议使用 PowerShell 或 Windows Terminal，macOS/Linux 使用系统自带终端即可。
• Node.js 环境，Claude Code 官方推荐通过 npm 安装，所以 Node.js 版本不能太旧。具体最低版本要求以官方文档为准，建议使用当前 Node.js 的 LTS 版本。
• 一个模型服务访问入口。最直接的方式是 Anthropic API Key；也有一些开发者通过兼容网关接入其他模型服务，这个后面会单独说明。

这里需要多说一句：Claude Code 有可能在某些地区或网络环境下不可用，官方启动时可能出现note: claude code might not be available in your country或者unable to connect to anthropic services的提示。遇到这类情况，应当按照官方支持策略和自己的实际环境处理，不要使用任何绕过访问限制的手段。如果你是开发者，更合理的做法是切换到官方支持的网络环境，或者通过合规的第三方兼容网关对接合法可用的模型服务。

2.2 使用 npm 安装 Claude Code

安装命令非常简单：

npm install -g @anthropic-ai/claude-code

安装完成后，确认版本：

claude --version

如果你的机器提示找不到claude命令，一般是因为 npm 的全局安装目录没有加入系统 PATH。Windows 上通常是 npm 的 prefix 目录，macOS/Linux 上通常是/usr/local/bin或用户目录下的 node 路径，检查一下 PATH 配置即可。

如果不想全局安装，也可以把 Claude Code 安装到项目目录里：

npm install --save-dev @anthropic-ai/claude-code npx claude

使用npx的方式会更适合团队统一版本，但每次启动时会检查包是否存在，速度上不如全局安装。

2.3 登录与认证

在终端里直接运行：

claude

首次启动时，Claude Code 会引导你选择登录方式。如果你有 Anthropic API Key，可以直接选择 API Key 方式，然后粘贴你的密钥。也可以提前在环境变量里配置：

export ANTHROPIC_API_KEY="你的密钥"

需要特别注意，API Key 是敏感信息，不要直接写进项目的 CLAUDE.md 或者提交到 git 仓库。建议使用环境变量、系统密钥管理工具，或者.claude/settings.json这类本地配置来保存。

配置完成后，启动会话，输入一句话让 Claude Code 执行，比如：

查看一下当前项目结构，并告诉我入口文件是哪个。

如果能够正常回复，说明环境基本可用。

2.4 目录结构与关键配置文件

Claude Code 在运行过程中会读取几个不同层级的配置，理解它们的优先级有助于后面做提示词精简。常见的目录和文件包括：

~/.claude/ └── CLAUDE.md # 用户级全局指令 项目根目录/ ├── CLAUDE.md # 项目级指令 └── .claude/ ├── settings.json # 本地设置 └── skills/ # 自定义技能目录

其中，用户级~/.claude/CLAUDE.md会对所有项目生效，适合放一些通用的、稳定的习惯或偏好，比如“默认使用中文回复”“代码注释用中文写”等。项目根目录的CLAUDE.md更合适放项目相关的技术栈、目录结构、构建命令和特殊约束。如果两处同时存在，通常项目级内容会和用户级内容合并后一起进入模型上下文。

理解这个结构之后，你会发现一个很关键的问题：如果你的用户级 CLAUDE.md 和项目级 CLAUDE.md 都写得非常长，那模型每次会话都要背着这一大堆内容干活。这正好是“系统提示词膨胀”最容易发生的地方。

3. 系统提示词的核心原理拆解

3.1 系统提示词到底由哪几部分组成

要聊“砍掉 80%”，首先得知道被砍的是哪一部分。Claude Code 真正发送给模型的系统上下文，通常由几个层级叠加而成：

• 官方内置主系统提示词：由 Anthropic 提供，定义了 Claude Code 的工具使用规则、任务循环、安全边界、错误恢复策略，以及基础输出约束。这一部分你直接改不了。
• 用户级 CLAUDE.md：存放在~/.claude/CLAUDE.md，对你名下的所有会话生效。
• 项目级 CLAUDE.md：存放在项目根目录，对当前项目生效。
• 会话中的额外指令：在对话中通过/add-dir、/clear或者“记住这个信息”等方式动态注入的上下文。
• 工具定义和函数说明：每个可用工具的描述、参数 Schema，也会占用上下文空间。
• 当前任务的动态上下文：比如项目文件内容、Shell 执行结果、代码 diff 等。

平时社区里说的“系统提示词太长了”，通常指的不是官方内置那部分，而是第二层、第三层，也就是你自己控制的 CLAUDE.md 和额外指令合并后产生的体积。

这里就出现了一个很常见的误解：很多人以为 CLAUDE.md 就是系统提示词的全部，其实它只是用户可控的那部分。真正起主要作用的，往往还是官方主提示词。“砍掉 80% 系统提示词”这句话如果理解成“把官方内置提示词砍掉”，那是不可能的；但如果理解成“把用户侧注入的那些冗余规则砍掉”，就是一件完全可行的事。

3.2 提示词长度与模型能力的非线性关系

大模型的上下文长度不断变大，1M token 的上下文窗口也已经出现，但这并不代表系统提示词越长，模型就越聪明。

在超长上下文场景里，模型对中间部分的注意力通常会弱于开头和结尾，研究者把这种现象称为“Lost in the Middle”。系统提示词如果被塞进去大量规则和解释，那些夹在中间的行为要求很容易被模型忽略。尤其是当模型需要把注意力放在工具返回结果和代码文件上时，一段写在 CLAUDE.md 中部的“你要注意代码质量”之类的话，几乎不会产生实际约束力。

换句话说，系统提示词不是越多越好，而是越“准”越好。真正能被稳定执行的指令，通常要满足三个条件：和当前任务直接相关、表述具体可验证、不与其他指令产生冲突。而这三条恰恰是很多团队写 CLAUDE.md 时最不重视的。

3.3 冗余指令如何挤占有效上下文

另一个容易被低估的问题是成本。

每一次 Claude Code 发起请求时，系统提示词都会被完整发送一遍。假设你的 CLAUDE.md 有 2000 个 token，那么每轮对话都会消耗这 2000 个 token 的开销。一次任务如果需要调用 20 轮工具，那仅仅系统提示词部分就会产生 40000 token 的传输成本。把 CLAUDE.md 精简到 400 token 之后，同样的任务可以少支付一大部分 token，响应时间也会跟着下降。

更隐蔽的问题是，冗余指令会稀释有效信息密度。模型在生成下一次行动时，需要在系统提示词里找到“当前项目应该用什么命令跑测试”这样的硬信息。如果这些硬信息被淹没在几十条“你应该”的规则里，模型就必须额外花一次思考来筛选，甚至可能忽略掉关键命令。我在实际测试中就遇到过这种情况：CLAUDE.md 写了很多代码风格要求，结果模型反复调整代码格式，却漏掉了最关键的入口文件路径，原因就是那条信息在规则堆里不够突出。

3.4 指令冲突会引发“过度规范”

把系统提示词写长，还有一个容易忽视的风险：指令冲突。

举个例子，你写了“不要频繁运行 Shell 命令”，又写了“遇到报错时自动尝试修复”，这两条单独看都合理，放在一起就可能形成矛盾。模型遇到一个测试失败时，如果它优先遵守“不要频繁运行命令”，就只会分析，不采取行动；如果它优先遵守“自动尝试修复”，又会不断执行命令。模型为了平衡两条冲突指令，会在每一步决策上消耗额外的思考时间。

过度规范也会带来类似问题。很多 CLAUDE.md 会写“不要删除任何现有代码”“不要重构没有必要的代码”“不要修改你不了解的文件”。这类大量否定式约束看似周全，实际上很容易让模型变得畏手畏脚。它在执行一个简单任务时，可能会停下来反复确认“我是不是不应该动这个文件”，反而偏离了用户真正的需求。

更合理的写法是把否定式约束转成明确的操作标准。比如“不要删除任何现有代码”可以改成“如果必须删除代码，请先说明删除原因和影响范围，等待用户确认后再执行”。这样模型依然有边界，但不会因为规则模糊而陷入犹豫。

3.5 削减 80% 的真正含义

现在再回过头看“砍掉 80% 效果反而更好”这句话，会发现它的本质是去除系统提示词里的无效载荷。

一个精简后的系统提示词通常只保留四类信息：

• 项目身份信息：这是什么项目、用什么技术栈、核心目录在哪。
• 常用命令：测试、构建、启动、格式化的具体命令是什么。
• 硬性约束：哪些操作必须经过确认、哪些文件不能改动、输出格式有什么要求。
• 当前目标：用户本次会话希望模型扮演什么角色、完成什么任务。

其他那些抽象的、重复的、不可验证的“优秀品质宣言”，全部可以删掉。比如“你是一名经验丰富的后端工程师”“请仔细分析问题”“请写出高质量的代码”，这些话对 Claude 模型而言几乎没有任何增量信息。模型本身就具备这些能力，你写不写，它都会按照训练时的标准去生成代码。

所以，砍掉 80% 不是把系统提示词变成空白，而是把系统提示词做成一张“任务卡片”，而不是一本“员工手册”。

4. 实战：为 Claude Code 编写一套精简 System Prompt

4.1 先想清楚 CLAUDE.md 应该放什么

在动手精简之前，先建立一个判断标准。CLAUDE.md 的目标不是告诉模型“你要努力”，而是告诉模型“这个项目是怎么工作的”。

我给自己总结了一个三列表格，每次往 CLAUDE.md 里写内容之前，都要先把内容填进这个表格里检查：

有了这个判断框架，CLAUDE.md 自然会瘦下来。

4.2 Before：一份臃肿的 CLAUDE.md

下面是一份经过“艺术加工”的臃肿示例，但你会在很多真实项目里看到类似内容：

# 项目规则 你是一名拥有十年经验的高级全栈工程师，对代码质量有着极高的要求。 你在回答问题时必须遵循以下规则： 1. 永远不要修改任何你没有充分了解的文件。 2. 永远不要执行危险的 Shell 命令，除非你非常确定。 3. 你必须使用中文回答所有问题。 4. 请务必在修改代码之前先向用户解释你的计划。 5. 编写代码时必须包含完整的注释，至少要说明每个函数的作用。 6. 不要删除任何现有代码。 7. 不要重构没有必要的代码。 8. 要优先考虑代码可读性和可维护性。 9. 在提交代码之前，请记得运行测试。 10. 如果遇到不确定的需求，请先向用户提问，而不是擅自行动。 11. 请尽量使用防御式编程，避免空指针异常。 12. 编写代码时不要引入额外的依赖，除非必要。 # 技术栈 我们使用 Python 3.10、Flask、MongoDB，前端使用 Vue 3。

这份 CLAUDE.md 看起来覆盖很全，信息量却很低。第 1、3、4、9、10 条是真正的行为约束，但其余大部分都是抽象规则或者训练库中已经存在的通用能力。尤其像“不要删除任何现有代码”和“如果遇到不确定的需求，请先提问”放在一起，模型很容易误判：什么时候算“不确定”？是不是每次修改前都要问一遍？

最终效果往往是：模型处理简单任务时过于谨慎，处理复杂任务时又因为规则太多而忽略真正的项目上下文。

4.3 After：把核心信息砍到 20%

精简后的版本长这样：

# 项目：电商后台管理系统 ## 技术栈 - 后端：Python 3.10 + Flask + MongoDB - 前端：Vue 3 + Vite - 数据库连接入口：`app/db.py` ## 常用命令 - 启动后端：`python run.py` - 运行测试：`pytest tests/` - 前端构建：`npm run build` ## 硬性约束 - 修改文件前，先列出修改计划并等待确认。 - 需要删除代码时，必须先说明删除原因和影响范围。 - 危险命令（DROP、rm -rf、格式化磁盘）执行前必须二次确认。 - 代码必须包含类型注解。 ## 沟通偏好 - 使用中文回复。 - 先简述实现思路，再给出代码。

对比一下可以看出，这份精简版 CLAUDE.md 的信息密度高了很多：模型不需要猜测项目是什么，不需要猜测测试命令，不需要猜测哪些命令算危险命令。每一条内容都是可以被验证执行的。

从字数上说，这份内容差不多只有原来的 20%，符合“砍掉 80%”的精神。但更重要的是，它把真正的硬信息保留了下来，同时删掉了态度宣言和抽象规则。

4.4 在项目中加载与验证

将精简后的内容保存到项目根目录的CLAUDE.md中，然后重启 Claude Code 会话。推荐用下面三个任务快速验证：

任务一：查看当前项目结构并指出入口文件。 任务二：运行测试并修复一个已知失败。
任务三：新增一个简单的 API 接口。

观察三个指标：

• 模型是否更少出现“停下来提问”的行为；
• 模型是否更准确地使用了你指定的命令；
• 模型在修改文件前是否按照“先列计划”的约束行动。

如果你发现模型开始乱猜命令或者修改了不该改的文件，说明精简过度了，需要把关键约束补回来。提示词精简是一个迭代过程，不应该一步到位。

4.5 用 /status 和相关命令观察上下文占用

Claude Code 提供的会话内命令可以用来检查当前状态和信息占用。比较常用的是在会话中输入：

/status

它会显示当前会话的一些基础信息。如果你想查看当前系统提示词的上下文占用情况，可以结合claude --debug启动调试模式，观察每次请求发送了多少输入 token。这个数字非常直观：精简前可能每轮都背着 3000 到 5000 个 token 的固定系统上下文；精简后如果不算工具返回和文件内容，固定上下文可能只有几百 token。

每次调整 CLAUDE.md 之后，都跑一次同样的任务，对比输入 token 和任务完成质量，就能形成自己的“提示词精简实验流程”。

4.6 小步迭代：不要一次性砍掉所有规则

“砍掉 80%”这个比例不适用于所有项目。更好的方法是这样操作：

第一次清理，删除所有态度宣言和“你是一个优秀工程师”之类的内容。你会发现这一部分删掉之后，模型几乎没有变化。第二次清理，合并重复规则。比如把“不要删除代码”“不要重构”合并成“删除或重构需要先说明原因”。第三次清理，把那些抽象的安全规则改成具体命令和具体路径，比如“危险命令需要二次确认”改成“rm -rf、DROP TABLE、git push --force 需要二次确认”。

每做完一次清理，运行一组相同的测试任务来回归。如果你发现某条规则删掉后模型表现明显变差，就把这条规则以更明确的形式放回去。推荐使用表格记录每次变更：

5. 常见问题与排查思路

5.1 典型报错对照表

不管你是刚安装 Claude Code，还是已经用了一段时间，下面这些报错信息都很常见：

5.2 连接失败与 API 端点配置

很多用户在第一次启动时都会遇到unable to connect to anthropic services。这个问题本质上和网络环境、API 端点配置有关。

排查顺序建议如下：

先检查 API Key 是否有有效配额，可以在其他工具里用同一个 Key 调用一次 API 试试。再检查环境变量ANTHROPIC_API_KEY是否正确加载。接着检查ANTHROPIC_BASE_URL是否被设置成了某个第三方网关地址，如果设置错误，Claude Code 会把请求发到一个不支持 Anthropic 协议的地方，导致连接失败或者模型路由报错。

如果你确实是通过第三方兼容网关接入模型服务，比如社区里有人将 Claude Code 与 DeepSeek 等模型服务对接，需要关注网关是否兼容 Claude Code 的工具调用协议。这里给出一个通用思路：

export ANTHROPIC_BASE_URL="https://你的网关地址" export ANTHROPIC_AUTH_TOKEN="你的API Key" export ANTHROPIC_MODEL="服务商提供的模型名"

注意，这不是 Anthropic 官方标准配置，每个服务商的接入方式都不一样。模型名、认证方式、请求路径都必须参考服务商自己的文档。用第三方网关时，日志、工具调用格式和 Token 统计口径都可能和官方不一致，遇到问题先去查网关侧的请求日志。

5.3 系统提示词工程和 Skill / Agent 有什么区别

“系统提示词工程”“Skill”“Agent”这三个概念经常被放在一起讨论，但它们其实处于不同的层级。

系统提示词工程（System Prompt Engineering）指的是在每次会话开始前，把任务要求、项目背景、行为边界注入到系统上下文中。它的特点是常驻：模型从一开始就知道这些规则。缺点是如果内容太多，会长期占用上下文窗口。

Skills 则是按需加载的技能包。你可以把一组提示词、脚本、参考文档打包成一个 Skill 目录，模型只有在需要处理对应类型的任务时才会加载它。它的优点是“即插即用”，不会让每轮对话都背上完整的大段提示词。在 Claude Code 中，Skills 通常放在.claude/skills/目录下，每个 Skill 包含自己的描述文件和辅助资源。如果你有大量领域知识需要让模型掌握，把它们做成 Skill 会比全部塞进 CLAUDE.md 更划算。

Agent 则是一个更上层的概念，指模型根据任务目标，自主决策调用哪些工具、按什么顺序执行、如何应对中间结果。Claude Code 本身就是一个 Agent 形态的工具。系统提示词是 Agent 的“初始配置”，Skills 是 Agent 的“工具箱”，而 Agent 是整套执行框架。

用一个表格来对比会更清晰：

结论：如果你的 CLAUDE.md 越写越长，你可以优先考虑把其中一部分内容拆到 Skills 里，让 CLAUDE.md 只保留那些无论如何都必须存在的规则。

5.4 第三方模型接入的注意事项

把 Claude Code 接到非官方模型上，是社区里很常见的做法。使用它没有问题，但有几件事需要提前明确。

第一，工具调用兼容性不是必然的。Claude Code 依赖模型返回结构化的工具调用结果，第三方模型如果不能稳定输出正确的工具调用格式，Claude Code 会出现“执行了命令但无法解析结果”的情况。

第二，系统提示词长度的影响在第三方模型上往往更明显。不同模型对长上下文的敏感度差异很大，本身就用不惯长提示词的模型，再背上 3000 token 的规则，效果会更差。

第三，安全边界需要自己兜底。当你修改ANTHROPIC_BASE_URL指向第三方服务时，数据会发送到对应服务商，敏感代码和密钥的管理需要格外谨慎。不要在 CLAUDE.md 中写入任何真实密钥，不要关闭官方默认的确认机制，尤其是那些不可逆的操作。

第四，模型名和服务条款都要看服务商的文档。不同模型的上下文长度、费率、并发限制都不一样，不要照搬某个教程里的环境变量值。

6. 最佳实践与工程建议

6.1 把 CLAUDE.md 当成“给 AI 看的 README”

如果你想让 CLAUDE.md 保持精简，一个很好的心理模型是：它是给 AI 看的 README，不是给员工看的规章制度。

README 的特点是信息密度高、结构清晰、只说关键信息。规章制度则往往包含大量“应当”“必须”“不能”的抽象条文。模型处理 README 性质的内容时更容易抓取到重点，处理规章制度时会花更多精力去判断某一条规则适不适用于当前场景。

所以在写 CLAUDE.md 时，建议采用“标题 + 列表 + 代码块”的方式组织内容，而不是一大段连续的自然语言。命令放在代码块里，约束放在短列表里，背景介绍控制在两三行以内。

6.2 把复杂约束放进 Workflows 和 Skills

系统提示词应该轻量化，不代表复杂任务不需要约束。复杂约束的正确存放位置是 Workflows 和 Skills。

比如你的项目有一套完整的发布流程：跑检查、跑测试、构建、打标签、推送镜像。这些步骤如果全写进 CLAUDE.md，会让它变得很臃肿。更好的做法是把发布流程封装成一个 Skill 或 Workflow，让模型在用户提出“发布”这个动作时按需加载这套流程。

判断标准很简单：如果一个规则只在特定任务中出现，它就不应该常驻在系统提示词里。它应该放在一个只有在触发该任务时才会被加载的地方。CLAUDE.md 只保留那些每次会话都必须生效的内容，比如项目语言、常用命令、危险操作边界。

6.3 用“如果—那么—否则”结构写约束

在精简 CLAUDE.md 时，我推荐把所有行为约束改写成“如果—那么—否则”的形式。例如：

## 修改约束 - 如果修改文件，先列出修改点，等待确认。 - 如果需要删除代码，说明原因和影响范围。 - 如果执行危险命令（rm -rf、DROP TABLE），必须二次确认。

这种结构的好处是模型容易执行。它不需要自己判断“什么是危险命令”，因为你已经给出了具体的触发条件。相比之下，“谨慎执行 Shell 命令”这类表达就没有给出操作标准。

每一条规则都应该能被一个外部观察者验证。如果一条规则写出来，你自己都没法判断模型是否遵守了，那这条规则对模型来说也大概率是模糊的。

6.4 权限最小化原则

Claude Code 在执行任务时通常有比较高的权限，尤其是当它以管理员权限在终端里运行时，它可以读写文件、执行命令。为了控制风险，建议在settings.json或对话中明确限制工具的权限范围。一个最小权限的配置思路包括：

• 只允许模型在指定目录下创建和修改文件；
• 对于rm、git push、数据库变更等操作，强制要求用户确认；
• 不要把最高权限的 Shell 命令直接交给模型；
• 会话结束后检查模型执行过的历史命令，尤其是在不可逆操作之后。

如果你的项目里有生成环境地址、数据库连接串、生产密钥，这些信息也不要写进 CLAUDE.md。模型读取所有项目文件后，一旦日志被上传或者会话被共享，敏感信息就可能泄露。

6.5 团队协作中的 CLAUDE.md 版本管理

当 CLAUDE.md 成为团队基础设施之后，它就应该像代码一样被管理。

建议把 CLAUDE.md 纳入 Git 仓库，和代码一起变更。每次修改 CLAUDE.md 都提交一个清晰的 commit message，说明改动原因。如果团队里有多个项目，可以在根目录维护一份模版，在新建项目时复制一份最小可用的 CLAUDE.md。

我的建议是每季度做一次 CLAUDE.md 清理活动：查看当前文件里还有多少条规则，逐条问三个问题——这条规则是否被模型真正执行？删掉它会不会影响最近的任务质量？它能不能被 Workflow 或 Skill 替代？如果答案是否定的，就直接删掉。

6.6 不要迷信某一个“最佳比例”

最后提醒一下：“砍掉 80%”是一个启发式的方向，不是严格的最优解。不同模型版本、不同项目类型、不同任务复杂度，对应的最优系统提示词长度可能完全不同。

你真正应该维护的不是“一定保持 20% 长度”这个指标，而是一套可复现的测试流程。建立几个日常任务作为回归用例，每次修改 CLAUDE.md 之后跑一遍，对比结果。这样无论是增加规则还是删除规则，你都能清楚地看到对实际任务的影响。

7. 总结与学习路线

关于 Claude Code 的系统提示词，你现在应该掌握了几件事。

第一，Claude Code 的系统提示词由官方内置提示词、用户级 CLAUDE.md、项目级 CLAUDE.md、工具定义和动态上下文共同组成。用户真正能控制的是 CLAUDE.md 部分。

第二，提示词越长不一定越好。冗余规则会挤占有效上下文，增加 token 成本，还可能带来指令冲突和过度规范问题。社区讨论的“砍掉 80%”本质上是一个瘦身测试，目的是把抽象规则转成具体可验证的信息。

第三，CLAUDE.md 应该保持低频、高密度的信息结构，只保留项目技术栈、常用命令、硬性约束和沟通偏好。复杂的流程和知识库，应该放到 Skills 或 Workflows 里按需加载。

第四，如果你想在项目里真正落地这套思路，关键是建立自己的回归测试任务。每改一次 CLAUDE.md，就跑一遍相同的任务，观察模型的行为变化。

我自己的实践建议是：先完全删除 CLAUDE.md，用官方默认提示词跑一轮日常任务作为基线。然后把 CLAUDE.md 从最核心的几条硬约束开始慢慢加，而不是一开始就写一篇“完整”的规则文档。这个过程会让你更清楚地看到，哪些规则是真正被模型需要的，哪些只是你在给自己增加工作量。

后续你可以在学习路线上继续深入：研究 Claude Code 的官方文档中关于 Skills 与 Agent 的部分，在项目里尝试把测试流程封装成 Workflow，或者动手把团队已有的开发规范改写成“如果—那么”结构的约束。这些方向都比继续往 CLAUDE.md 里堆规则更有价值。