1. 全局提示词到底该写什么从 CLAUDE.md 到 subAgent 的边界划分全局提示词也就是默认加载进所有会话的那份 CLAUDE.md最容易犯的错是把它当成什么都往里塞的收纳箱。我一开始也这样VPS 连接方式、E2E 测试注意事项、启动服务前先检查、遇到问题试两次就停下……全堆在全局里。结果几个月后回头看真正每天生效、每次会话都该带上的其实只剩两条。先说清楚这份东西是什么、能做什么、适合谁。CLAUDE.md 是 Claude Code 在每次会话启动时自动读取的项目/全局上下文文件放在用户目录下的全局版本会对所有项目生效。它本质是一段默认注入的提示词用来约束 AI 的行为习惯、补充它不知道的个人背景。适合谁适合每天用 Claude Code 写代码、并且已经积累了一批每次都要重复交代的偏好的人。如果你只是偶尔用一次全局提示词反而会增加噪音。判断一条规则该不该进全局我用一个很土但有效的标准这条规则是不是跨项目、跨会话、每次都成立。只要有一个项目不适用它就该下沉到项目级 CLAUDE.md只要它只服务于某一类任务比如运维它就该抽成 subAgent。拿我删掉的三条举例「VPS 连接」——这是典型的任务专属知识。后来我写了单独的 ops subAgent所有运维背景和操作规范都收进去了。全局里再写一遍等于让每次前端会话都背着一份用不上的服务器清单。「启动服务前先检查是否已在运行」——同理属于运维 subAgent 的职责范围。「E2E 测试用 waitFor 别用固定延时」——这条本身没错但它不是每次会话都成立。我很多项目根本没有 E2E 测试把它放全局就是纯噪音。它应该进具体项目的项目级提示词。「同一方法试 2 次还卡住就停下求助」——这条方向对属于AI 行为纠偏但内容过时了。以前是让用户介入现在完全可以先让 glm、codex 介入给新视角。规则该更新而不是删掉。删完之后我剩下两条一条补背景一条纠行为# 知识背景 我的背景是「XXX」熟悉的领域是「XXX」对「XXX」领域不熟悉。 沟通时别默认我知道相关技术背景遇到复杂概念先解释。 # 运行时 同一思路试 2 次还不行让 glm、codex 介入给新视角和解法。第一条解决的是AI 默认我懂的问题。我经常让它解释 CVR、PBN 这类缩写PBN 居然是 Paint By Numbers它讲得头头是道却完全没考虑我听不听得懂。把背景写进全局它就会主动降维解释。第二条解决的是AI 死循环的问题。同一个思路反复试不如换个模型换视角。glm 和 codex 的调用习惯不同glm 偏中文语境和快速发散codex 偏严谨推理让它们介入往往能跳出死胡同。这里的关键认知是全局提示词管人和习惯项目提示词管这个项目的规矩subAgent 管这类任务的专属知识。三者边界清晰才不会互相打架。全局越薄越不容易和项目级规则冲突项目级越具体越能覆盖该项目的特殊约定subAgent 越专注越能把某类任务的背景知识一次性讲透。很多人把全局提示词写厚是出于一种怕漏的心理。但提示词不是越多越好注入的每一条都在消耗模型的注意力预算。一条从不生效的规则不只是没用还会稀释真正重要规则的权重。所以我的建议是全局只留跨项目、跨会话、每次都成立的规则其余全部下沉。2. TaoToken 前置把 glm、codex 接进同一套调用入口要让同一思路试 2 次就让 glm、codex 介入这条规则真正跑起来前提是这两个模型得能被方便地调用。如果每次都要切不同的平台、配不同的 Key这条规则很快就会因为麻烦而被放弃。我用的方式是走 TaoToken 的统一入口。官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 这个不加 UTM。它的价值在于glm、codex 以及 Claude 系列都能通过同一套 Base URL 和 Key 调用省掉了多平台来回切换的成本。先说清楚它不是什么它不是编辑器替代品也不是让你绕过任何正常开发流程的东西。它就是一个模型调用的统一入口把多个模型的 API 收敛到一套鉴权体系下。对多 AI 协作这个场景来说这一点很关键——因为你要频繁地在 Claude、glm、codex 之间切换视角入口越统一切换成本越低。具体要准备三样东西也就是常说的三件套配置项值说明Base URLhttps://taotoken.net/api所有模型共用API Key在控制台生成见下方链接Model ID如 glm-4、codex 对应模型名按实际调用填写生成 Key 的入口在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。进去之后创建 API Key复制出来保存好。模型对话的调试入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 可以先用它验证 Key 和模型是否通。如果你用的是 Claude Code接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 里面有环境变量和配置文件的写法。Claude Code 相关的 Anthropic 配置说明在 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。为什么这一步要放在配置之前讲因为让 glm、codex 介入这条全局规则落地时依赖的是调用能力。如果调用链路是断的规则就只是纸面文字。我试过在没配好统一入口之前手动去两个平台复制粘贴问题坚持了不到一周就放弃了——太麻烦。统一入口之后切换模型变成改一个 Model ID 的事规则才真正活了起来。另外提醒一点Key 不要写死在会提交到仓库的文件里。用环境变量或者本地的、被 gitignore 的配置文件。这一点在后面的配置片段里会体现。3. 可复制配置CLAUDE.md 分层模板与 settings 片段这一节给可直接套用的配置。分三块全局 CLAUDE.md、项目级 CLAUDE.md、以及 Claude Code 的 settings 片段。先看全局 CLAUDE.md路径通常在用户目录下比如~/.claude/CLAUDE.md。内容保持极简# 知识背景 我的背景是「后端开发主要写 Go 和 Python」熟悉的领域是「服务端、数据库」 对「前端构建工具链、K8s 运维」不熟悉。 沟通时别默认我知道相关技术背景遇到复杂概念先解释缩写先给全称。 # 运行时 同一思路试 2 次还不行让 glm、codex 介入给新视角和解法。 调用方式见项目级配置模型 ID 用 glm-4 和 codex 对应模型。注意这里我把调用方式见项目级配置写进去了因为全局不该硬编码具体的 Key 和地址那是环境相关的东西。再看项目级 CLAUDE.md放在项目根目录比如./CLAUDE.md。它管这个项目的具体规矩# 项目约定 - 包管理器用 pnpm不要用 npm。 - 提交前跑 pnpm test测试不过不要提交。 - E2E 测试预料到竞态/时序不稳定时用 waitFor别用固定延时。 # 模型调用 - Base URL: https://taotoken.net/api - API Key: 从环境变量 TAOTOKEN_API_KEY 读取不要写死。 - 需要多视角时glm 用 glm-4codex 用对应模型 ID。然后是 Claude Code 的 settings 片段。如果你用 CC Switch 或类似工具管理配置或者直接改~/.claude/settings.json结构大致如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 从环境变量注入不要明文提交 }, model: claude-sonnet-4-20250514 }如果你用 Codex它的鉴权文件通常在~/.codex/auth.json结构类似{ base_url: https://taotoken.net/api, api_key: 你的 Key, model: codex 对应模型 ID }三件套在这里必须齐全Base URL 是https://taotoken.net/apiKey 从控制台生成Model ID 按你要调的模型填。缺任何一个调用都会失败。关于 subAgent 的配置以 ops subAgent 为例它应该有自己的提示词文件把运维专属知识收进去而不是塞进全局# ops subAgent 职责处理服务器运维、部署、日志排查。 # 背景知识 - 主服务器ssh 对外产品服务器 - 备用服务器ssh 个人助手服务器 - 启动任何服务前先检查它是否已在运行。 # 行为规范 - 涉及生产环境的操作先说明影响再执行。这样拆下来全局只留两条项目级管项目规矩subAgent 管任务专属知识。每一层职责单一改起来也不会牵一发动全身。4. 验证请求用 subAgent 任务检验提示词是否越界或遗漏配置写完不算完得验证。验证的核心问题是两个有没有越界全局管了不该它管的事、有没有遗漏该生效的规则没生效。我的验证方法是设计几个 subAgent 任务观察 AI 的行为是否符合预期。第一个任务测知识背景是否生效。随便问一个跨领域缩写比如让它解释 PBN。如果全局提示词生效它应该先给全称再解释而不是默认我知道。实测下来配好之后它会说PBN 是 Paint By Numbers 的缩写意思是……这正是我要的。第二个任务测运行时规则是否触发。故意给它一个会卡住的思路看它试两次后会不会主动说让 glm 或 codex 介入。这里要注意规则写的是同一思路试 2 次还不行所以你得观察它是不是真的在第二次失败后切换而不是无限重试。第三个任务测边界。让 ops subAgent 处理一个运维任务看它是否用了 subAgent 里的服务器信息而不是去全局里找。如果全局里已经没有 VPS 信息而 subAgent 能正常拿到说明边界划分是对的。第四个任务测遗漏。跑一次项目级的测试流程看它提交前是否自动跑了pnpm test。如果没跑说明项目级提示词没被正确加载或者规则写得不够明确。验证时可以用一个简单的请求确认调用链路是通的。比如通过模型对话入口发一条测试消息确认 Base URL 和 Key 没问题。如果返回正常说明三件套配对了。这里有个细节验证越界比验证遗漏更难。遗漏是该做的没做容易发现越界是不该做的做了容易被忽略。我的做法是定期回看全局 CLAUDE.md问自己每一行这条是不是每个项目都成立。只要有一条不成立就下沉。这个习惯比任何自动化检查都管用。验证清单可以固定成几条全局规则是否每条都跨项目成立项目级规则是否覆盖了该项目的特殊约定subAgent 是否拿到了它需要的专属知识三件套Base URL、Key、Model ID是否齐全且可调用触发条件如试 2 次是否真的会被执行把这几个问题过一遍提示词的分层基本就稳了。5. 常见报错排查401、local proxy failed、reading choices、OAuth配置和验证过程中我踩过几个典型的坑这里对照真实报错说清楚。401 Unauthorized。最常见的原因是 Key 没配对或者环境变量没注入成功。先确认TAOTOKEN_API_KEY这类环境变量在当前 shell 里能echo出来。如果用的是 settings.json 里的env字段注意它不会自动继承系统环境变量得确认值真的写进去了。还有一种情况是 Key 复制时带了空格或换行肉眼看不出来重新复制一次。local proxy failed。这个报错通常出现在本地代理配置和实际网络环境不匹配的时候。检查你的 Base URL 是不是写成了https://taotoken.net/api有没有多写或少写路径。如果本地有残留的代理环境变量比如HTTP_PROXY也可能干扰请求先清掉再试。reading choices 相关报错。这类报错一般出现在解析响应时常见原因是 Model ID 填错了或者调用的模型和返回格式不匹配。比如你按 Claude 的格式去解析 glm 的返回就可能出问题。确认 Model ID 和你要调用的模型一致glm 用 glm 对应的 IDcodex 用 codex 对应的 ID。OAuth 相关报错。如果你用的是 Claude Code 并且走了 OAuth 流程报错往往和鉴权方式冲突有关。检查是不是同时配了 API Key 和 OAuth两者选一个。用统一入口的话走 API Key 方式更直接把 OAuth 相关的配置清掉。排查时有个通用顺序先确认三件套齐全再确认环境变量注入最后确认 Model ID 匹配。大部分报错都出在前两步。另外如果报错信息里出现了proxy字样先别急着改代码检查一下是不是本地网络配置的问题。把 Base URL 直接写死成https://taotoken.net/api试一次排除变量干扰。6. 把规则跑起来从模型对话验证到长期 Coding Plan配置和排查都过了之后最后一步是让它真正进入日常。我的做法是先用模型对话入口做一次快速验证确认调用链路通再把它固化到日常编码流程里。模型对话的入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 可以在这里发一条测试消息确认 glm 和 codex 都能正常返回。这一步花不了几分钟但能避免后面在编码时才发现调用不通。如果你每天都要用 Claude Code 写代码并且经常需要多模型协作那 Coding Plan 会更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。它面向的是长期编码和 Agent 场景比按次调用更省心。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。这两个是排障和接入时最常回看的页面。回到提示词本身。全局提示词优化完之后我最大的感受是少即是多。两条规则一条补背景一条纠行为覆盖了我 80% 的重复交代。剩下的都下沉到项目级和 subAgent各司其职。如果你现在全局 CLAUDE.md 里堆了一堆规则不妨做一次清理逐条问这条是不是每个项目都成立不成立的移走。移完之后你会发现真正需要全局的往往就那么两三条。而这两三条恰恰是最该被认真写好的。