这两天 Claude Opus 5 的讨论又热了一轮。
原因不是某个跑分截图，也不是某个“秒杀一切”的 Demo，而是一份更容易让开发者好奇的东西：公开报道显示，有开发者整理并发布了 Claude Opus 5 的系统提示词。里面包含很长的上下文、工具说明、安全边界、版权规则、记忆机制和工具调用格式。
很多人的第一反应很自然：
“这不就是官方满血 Prompt 吗？我是不是也应该复制一份放进自己的 Agent？”
这个念头很诱人。毕竟大家都见过 Claude Code、Cursor、Codex 这类 AI 编程工具的效果差异。同一个模型，有的人用起来像高级同事，有的人用起来像刚入职还不看需求文档的实习生。于是大家很容易把差异归因到一句话：
是不是我 Prompt 写得还不够长？
但这次 Opus 5 系统提示词曝光，反而给了一个相反的启发。
强模型时代，很多项目里的 CLAUDE.md、系统提示词和 Skill 文件，真正的问题不是“不够多”，而是“太吵”。
你给模型塞了很多规则，模型也确实读了。但读完以后，它不一定更稳。它可能只是带着更多互相打架的规则、更长的上下文、更高的 Token 成本，去完成一个原本三句话就能说清楚的任务。
这也是为什么 Anthropic 最近在谈 Claude 5 这一代模型的 Context Engineering 时，反复强调一个方向：别把系统提示词写成一本操作手册。模型越强，越需要清楚的边界，而不是密密麻麻的提醒。
这篇文章不复刻泄露提示词，也不讨论怎么“套官方 Prompt”。我们换一个更实用的问题：
如果你正在用 Claude Code、Cursor、OpenCode、Cline 或自建 Agent 接 Claude API，项目里的规则到底应该怎么写，才能让 Agent 更稳、更省、更可控？
一、13 万字符系统提示词，不等于你的项目也需要 13 万字符
先把一件事拆开。
大型模型产品里的系统提示词，和你项目里的 CLAUDE.md，不是同一种东西。
Opus 5 这种公开产品级模型背后的系统上下文，承担的是平台级职责。它要面对极其复杂的使用场景：普通聊天、代码任务、工具调用、联网搜索、文件处理、版权边界、安全策略、长会话记忆、不同地区的合规要求、不同客户端的交互习惯。
所以它长，并不奇怪。
它长，不是因为“长 Prompt 天然更强”。它长，是因为它要服务无数用户、无数任务、无数工具和无数风险。
但你自己的项目完全不是这样。
一个真实代码仓库里的 Agent，其实只需要知道几件事：
- 这个项目是做什么的；
- 哪些目录能改，哪些目录不能碰；
- 代码风格和提交习惯是什么；
- 改完以后用什么方式验证；
- 遇到高风险动作时什么时候停下来问人；
- 哪些任务应该用强模型，哪些任务应该交给便宜模型。
这些东西写清楚，比复制一份十几万字符的系统提示词有用得多。
更关键的是，生产级系统提示词里有大量“为平台兜底”的内容。你把它原样塞进自己的项目，不仅不会变强，反而可能让 Agent 更犹豫。
比如你的项目只是让 Claude Code 改一个前端组件，但上下文里同时出现了版权政策、浏览器工具约束、跨会话记忆规则、长篇安全说明、几十个工具 schema。模型当然能读，但它每一步都要在这些规则里做取舍。
人的脑子也一样。你让一个同事改一个按钮文案，顺手给他发一份 80 页公司制度，他未必更快。
二、强模型最怕的不是规则少，而是规则互相打架
很多团队写 CLAUDE.md，喜欢把所有经验都堆进去。
第一次 Agent 改坏了样式，于是加一句：
不要随便修改样式。
第二次 Agent 没写测试，于是加一句：
每次修改后必须补充测试。
第三次 Agent 写了一堆无用注释，于是加一句：
不要添加不必要的注释。
第四次 Agent 没解释改动，于是又加一句：
每次输出都要详细解释。
这样写一周，CLAUDE.md 就从 30 行变成 300 行。
问题是，这 300 行里经常有冲突。
比如：
- “不要修改样式”与“保持页面视觉一致”冲突；
- “不要添加注释”与“关键逻辑必须解释”冲突；
- “每次都写详细说明”与“输出尽量简洁”冲突；
- “必须自动完成任务”与“涉及风险必须人工确认”冲突；
- “遵循历史实现”与“重构重复逻辑”冲突。
这些冲突不会显式报错。模型不会弹窗告诉你“第 17 条和第 83 条规则打架了”。它只会在执行时变得飘。
有时候过度谨慎，什么都不敢改。
有时候又突然越界，把不该碰的文件一起改了。
有时候你让它“按旧逻辑实现”，它却把旧逻辑里的 bug 也复制了一遍。
这不是模型没读规则，而是它读了太多需要同时满足的规则。
所以 Claude Code 的项目规则，不应该写成“事故备忘录”。不能每踩一次坑，就往文件里贴一条禁令。更好的做法是把事故归类，沉淀成少数几条稳定原则。
比如不要写：
不要改 package-lock.json。
不要改 pnpm-lock.yaml。
不要改 yarn.lock。
不要改 generated 文件。
不要改 dist 文件。
不要改 build 产物。
不要改 package-lock.json。
不要改 pnpm-lock.yaml。
不要改 yarn.lock。
不要改 generated 文件。
不要改 dist 文件。
不要改 build 产物。
可以改成：
默认只修改任务直接相关的源代码与文档。
锁文件、构建产物、生成文件、迁移文件如需修改，必须先说明原因并等待确认。
默认只修改任务直接相关的源代码与文档。
锁文件、构建产物、生成文件、迁移文件如需修改，必须先说明原因并等待确认。
这两句话比六条禁令更容易执行，也更不容易漏。
三、CLAUDE.md 不是许愿池，而是项目合同
很多人的 CLAUDE.md 有一种奇怪的语气：
你必须认真思考。
你必须非常仔细。
你必须像资深工程师一样写代码。
你不能偷懒。
你不能犯低级错误。
你一定要保证代码高质量。
你必须认真思考。
你必须非常仔细。
你必须像资深工程师一样写代码。
你不能偷懒。
你不能犯低级错误。
你一定要保证代码高质量。
这种写法看起来很用力，但对 Agent 帮助不大。
因为它没有告诉模型什么叫“认真”、什么叫“高质量”、什么叫“低级错误”。
好的项目规则应该像合同，不像口号。它要能被检查。
比如把“写高质量代码”拆成：
完成代码修改后，请按顺序检查：
1. 是否只修改了任务相关文件；
2. 是否保留现有公开 API 和数据结构；
3. 是否处理空状态、错误状态和加载状态；
4. 是否运行项目已有测试或说明未运行原因；
5. 是否在最终回复中列出改动文件和验证结果。
完成代码修改后，请按顺序检查：
1. 是否只修改了任务相关文件；
2. 是否保留现有公开 API 和数据结构；
3. 是否处理空状态、错误状态和加载状态；
4. 是否运行项目已有测试或说明未运行原因；
5. 是否在最终回复中列出改动文件和验证结果。
这才是 Agent 能执行的规则。
再比如把“不要乱改”拆成：
以下动作需要先征求确认：
- 删除文件或目录；
- 重命名公开接口；
- 修改数据库 schema；
- 修改认证、支付、权限相关逻辑；
- 引入新依赖；
- 大范围格式化超过 5 个文件。
以下动作需要先征求确认：
- 删除文件或目录；
- 重命名公开接口；
- 修改数据库 schema；
- 修改认证、支付、权限相关逻辑；
- 引入新依赖；
- 大范围格式化超过 5 个文件。
这类规则很朴素，但特别有用。
它不会让模型“更聪明”，但会让模型更像一个可靠协作者：知道什么时候推进，什么时候停下，什么时候把选择权交还给人。
四、把 CLAUDE.md 删到这 6 块就够了
如果你现在有一份很长的 CLAUDE.md，可以先不用急着重写。
直接按下面 6 块整理。
1. 项目是什么
用 5 行以内说清项目，不要写商业计划书。
这是一个面向中小团队的 API 接入与用量管理后台。
前端使用 Next.js，后端使用 Node.js，数据库使用 PostgreSQL。
核心目标是让用户完成模型选择、Key 管理、用量查看和账单核对。
这是一个面向中小团队的 API 接入与用量管理后台。
前端使用 Next.js，后端使用 Node.js，数据库使用 PostgreSQL。
核心目标是让用户完成模型选择、Key 管理、用量查看和账单核对。
这部分的作用是给模型建立方向感。
它不需要知道公司使命，也不需要知道品牌愿景。它只需要知道自己正在什么系统里工作。
2. 目录边界
告诉模型哪里能动，哪里不能动。
常用目录：
- app/：页面与路由；
- components/：可复用 UI；
- lib/：业务逻辑与 API client；
- docs/：文档。
默认不要修改：
- migrations/；
- generated/；
- dist/；
- lock file；
- .env 和任何密钥文件。
常用目录：
- app/：页面与路由；
- components/：可复用 UI；
- lib/：业务逻辑与 API client；
- docs/：文档。
默认不要修改：
- migrations/；
- generated/；
- dist/；
- lock file；
- .env 和任何密钥文件。
Agent 最容易出问题的地方，不是不会写代码，而是不知道“这次任务的边界在哪里”。
目录边界写清以后，很多误改会直接减少。
3. 风险动作
把需要人工确认的动作列出来。
以下动作必须先确认：
- 删除或移动文件；
- 修改数据库结构；
- 修改支付、登录、权限逻辑；
- 更换核心依赖；
- 执行破坏性命令；
- 对超过 5 个文件做批量重构。
以下动作必须先确认：
- 删除或移动文件；
- 修改数据库结构；
- 修改支付、登录、权限逻辑；
- 更换核心依赖；
- 执行破坏性命令；
- 对超过 5 个文件做批量重构。
这部分非常适合团队使用。
因为不同人的风险阈值不一样。有的人觉得“重命名一个字段”很正常，有的人知道这会影响线上报表。不要指望模型猜，直接写出来。
4. 验收标准
每个项目最好写一套通用验收。
完成任务前请检查：
- 代码是否能通过现有 lint / test；
- 新增逻辑是否覆盖错误状态；
- UI 是否保持现有设计语言；
- 是否没有引入无关重构；
- 最终回复需要包含：改了什么、验证了什么、还有什么风险。
完成任务前请检查：
- 代码是否能通过现有 lint / test；
- 新增逻辑是否覆盖错误状态；
- UI 是否保持现有设计语言；
- 是否没有引入无关重构；
- 最终回复需要包含：改了什么、验证了什么、还有什么风险。
这里不用要求“每次必须跑全量测试”。很多项目全量测试很慢，Agent 每次跑反而浪费时间。
更好的写法是：优先运行与本次修改相关的验证；如果无法运行，说明原因。
5. 工具使用方式
如果你有自定义脚本、内部 CLI、部署命令、测试命令，一定要写。
常用命令：
- npm run lint：检查代码风格；
- npm run test -- user：只跑 user 相关测试；
- npm run build：生产构建检查。
不要自行猜测部署命令。
部署、数据库迁移、线上配置变更必须等待人工确认。
常用命令：
- npm run lint：检查代码风格；
- npm run test -- user：只跑 user 相关测试；
- npm run build：生产构建检查。
不要自行猜测部署命令。
部署、数据库迁移、线上配置变更必须等待人工确认。
很多 Agent 事故不是模型推理错了，而是工具用错了。
比如它不知道你的项目用 pnpm，结果自己跑 npm install；不知道测试命令很慢，结果触发一堆无关任务；不知道某个脚本会写线上数据，直接执行了。
工具规则写清楚，收益很高。
6. 成本与模型策略
这部分以前很多人不写，但现在很有必要。
强模型很好，但强模型不适合包办一切。
模型使用建议：
- 简单分类、格式转换、短文本改写：优先轻量模型；
- 代码审查、复杂重构、长链路推理：使用 Sonnet / Opus 级模型；
- 大量并发子任务：优先低成本模型，并限制输出长度；
- 超长文档任务：优先启用缓存或拆分摘要。
模型使用建议：
- 简单分类、格式转换、短文本改写：优先轻量模型；
- 代码审查、复杂重构、长链路推理：使用 Sonnet / Opus 级模型；
- 大量并发子任务：优先低成本模型，并限制输出长度；
- 超长文档任务：优先启用缓存或拆分摘要。
这类规则看起来不像“提示词技巧”，但它直接影响账单。
当团队把 Claude Code、Dify、n8n、自建 Agent 都接到 API 后，成本通常不是被一次大调用打爆，而是被大量“小而重复”的任务慢慢吃掉。
项目规则里写清模型策略，后面做路由、预算和审计会轻松很多。
五、Skill 要保留，但不要把所有 Skill 都塞进上下文
这次 Opus 5 系统提示词讨论里，还有一个容易被忽略的点：工具和 Skill 的信息量非常大。
一个 Agent 系统如果把所有工具说明、所有 Skill、所有历史偏好都一次性塞进去，看上去很完整，实际很浪费。
更好的方式是“按需加载”。
比如你有这些 Skill：
- 写公众号文章；
- 提取公众号正文；
- 生成封面图；
- 优化官网 SEO；
- 改写 CSDN 版本；
- 做合规审查；
- 生成 FAQ。
它们不应该每次都进入上下文。
当任务只是“修一个登录按钮样式”时，公众号写作 Skill 完全没必要出现。当任务是“给官网文章加 FAQ”时，图片生成 Skill 也不用出现。
CLAUDE.md 只需要写一个路由原则：
如果任务涉及内容写作，先使用写作相关 Skill。
如果任务涉及公众号链接，先提取正文再写作。
如果任务涉及官网技术文章，结尾必须补 FAQ。
如果任务涉及配图，先给出图片位置和生成提示词，不要凭空插入不存在的图片。
如果任务涉及内容写作，先使用写作相关 Skill。
如果任务涉及公众号链接，先提取正文再写作。
如果任务涉及官网技术文章，结尾必须补 FAQ。
如果任务涉及配图，先给出图片位置和生成提示词，不要凭空插入不存在的图片。
这比把每个 Skill 的完整说明都贴进去更好。
很多团队后面做 Agent 工作流，会遇到一个问题：单个 Skill 很好用，但 Skill 多了以后，Agent 变慢、变贵、还容易串台。
解决办法不是删掉 Skill，而是建立“入口规则”。让 Agent 知道什么时候该调用哪个 Skill，而不是每次都背着整个工具箱上路。
六、从 Opus 5 到日常开发：一份可直接复制的 CLAUDE.md 基础版
下面这份模板比较适合作为起点。
它不追求酷，也不追求长。目标只有一个：让 Agent 进项目后少犯低级边界错误。
# 项目协作规则
## 项目背景
这是一个面向开发者的 Web 项目，主要包含前端页面、后端接口、文档和配置。
本项目优先保证稳定、可维护和可验证，不追求一次性大范围重构。
## 默认工作方式
- 先理解任务目标，再检查相关文件。
- 默认只修改与任务直接相关的文件。
- 不主动做无关重构。
- 不主动更换技术栈、目录结构或核心依赖。
- 如果需求不明确，先根据现有代码做最小合理修改，并在最终回复中说明假设。
## 需要人工确认的动作
以下动作必须先说明原因并等待确认：
- 删除、移动或批量重命名文件；
- 修改数据库 schema、迁移脚本或生产配置；
- 修改认证、支付、权限、计费逻辑；
- 引入新依赖或升级核心框架；
- 执行可能破坏数据的命令；
- 大范围格式化或重构超过 5 个文件。
## 代码要求
- 保持现有代码风格。
- 优先复用已有组件、工具函数和类型定义。
- 新增逻辑要处理错误状态、空状态和边界情况。
- 不添加无意义注释；复杂逻辑需要用简短注释解释原因。
## 验证要求
- 优先运行与本次修改相关的 lint、test 或 build。
- 如果无法运行验证，需要说明原因。
- 最终回复包含：修改内容、验证结果、未覆盖风险。
## 输出要求
- 回复简洁，但不要省略关键风险。
- 如果有多个方案，给出推荐方案和取舍。
- 如果任务涉及官网技术文章，结尾补充 FAQ。
# 项目协作规则
## 项目背景
这是一个面向开发者的 Web 项目，主要包含前端页面、后端接口、文档和配置。
本项目优先保证稳定、可维护和可验证，不追求一次性大范围重构。
## 默认工作方式
- 先理解任务目标，再检查相关文件。
- 默认只修改与任务直接相关的文件。
- 不主动做无关重构。
- 不主动更换技术栈、目录结构或核心依赖。
- 如果需求不明确，先根据现有代码做最小合理修改，并在最终回复中说明假设。
## 需要人工确认的动作
以下动作必须先说明原因并等待确认：
- 删除、移动或批量重命名文件；
- 修改数据库 schema、迁移脚本或生产配置；
- 修改认证、支付、权限、计费逻辑；
- 引入新依赖或升级核心框架；
- 执行可能破坏数据的命令；
- 大范围格式化或重构超过 5 个文件。
## 代码要求
- 保持现有代码风格。
- 优先复用已有组件、工具函数和类型定义。
- 新增逻辑要处理错误状态、空状态和边界情况。
- 不添加无意义注释；复杂逻辑需要用简短注释解释原因。
## 验证要求
- 优先运行与本次修改相关的 lint、test 或 build。
- 如果无法运行验证，需要说明原因。
- 最终回复包含：修改内容、验证结果、未覆盖风险。
## 输出要求
- 回复简洁，但不要省略关键风险。
- 如果有多个方案，给出推荐方案和取舍。
- 如果任务涉及官网技术文章，结尾补充 FAQ。
这份模板不是终点。
真正好用的 CLAUDE.md，一定要跟着项目长出来。你可以每周复盘一次：哪些规则被反复触发？哪些规则从来没用？哪些规则和真实流程冲突？
留下能降低事故率的，删掉只是在表达焦虑的。
七、接入层也要一起整理：域名、模型和账单别混在一起
如果你是个人开发者，只在本地跑 Claude Code，问题还比较简单。
但如果是团队使用，情况会复杂很多：
- 有人用 Claude Code；
- 有人用 Cursor / Cline / OpenCode；
- 有人把模型接进 Dify、n8n、Open WebUI；
- 有人做内容自动化；
- 有人跑批量文档总结；
- 有人做客服机器人。
这时候项目规则只是第一层。
第二层是接入层治理：Key 怎么发、模型怎么选、用量怎么看、账单怎么核对、异常请求怎么排查。
这也是为什么很多团队会选择通过 apito.ai 做统一接入。它的价值不是让你多写几行配置，而是把模型入口、用量记录、账单管理和团队协作放到一个更容易管理的位置。
如果你之前已经在 Claude Code、Cursor、Cline、Dify 或 Open WebUI 里配置过旧请求地址，迁移时通常只需要做一件事：
把请求地址里的 claudeapi.com 改成 apito.ai。
Key、模型 ID、请求参数和原有调用方式一般不需要跟着改。已经跑通的程序，也不需要为了换域名重写一遍。
当然，具体可用模型、价格和额度以 apito.ai 控制台实际展示为准。它是独立第三方技术服务，不是 Anthropic 官方渠道。对企业来说，最重要的是把“能不能用”升级成“能不能看清楚、管得住、排得出问题”。
这和 CLAUDE.md 的逻辑其实一样。
强模型解决能力问题。
清楚的规则解决协作问题。
统一的接入层解决管理问题。
三件事缺一件，Agent 工作流都会变得不稳定。
八、今天可以立刻做的 10 分钟整理
如果你现在正在用 Claude Code，可以不用等团队开会。
今天就做这几步：
- 打开项目里的 CLAUDE.md；
- 删除重复出现的“不要”“必须”“一定”；
- 把情绪化要求改成可检查的验收标准；
- 增加“需要人工确认的动作”；
- 写清常用测试命令；
- 删除过期路径、旧技术栈、已经不用的脚本；
- 把大段背景资料移到文档里，需要时再让 Agent 读取；
- 给内容、代码、配图、部署分别设 Skill 路由；
- 明确哪些任务用轻量模型，哪些任务用强模型；
- 如果团队统一接入 API，把请求地址、Key 管理、用量查询入口写进内部文档。
这 10 分钟不会让模型能力暴涨，但会让后面每一次协作更顺。
很多人把 Agent 用不稳，问题不是模型不够强，而是人没有给它一个干净的工作台。
Opus 5 的系统提示词曝光，看上去像一次“Prompt 秘籍外流”。
但真正值得学的不是那份 Prompt 有多长，而是它提醒我们：当模型越来越强，项目规则就不能再靠堆字数取胜。
少一点口号。
少一点重复。
少一点把所有事故都贴进上下文的冲动。
把边界写清，把验收写清，把风险动作写清，把工具入口写清。
这才是 Claude Code 进入真实项目以后，最容易被低估的基本功。
FAQ
1. Claude Opus 5 系统提示词可以直接复制到自己的项目里吗？
不建议。公开产品级系统提示词包含大量平台级规则、工具 schema、安全策略和通用兜底逻辑。你的项目通常不需要这些内容。直接复制会增加上下文噪声，也可能让 Agent 在执行简单任务时变得迟疑。
2. CLAUDE.md 是不是越短越好？
不是。短不是目的，清楚才是目的。好的 CLAUDE.md 应该覆盖项目背景、目录边界、风险动作、验证方式和输出要求。能执行的规则留下，表达焦虑但无法检查的规则删掉。
3. Claude Code 项目规则应该写在哪里？
通常写在项目根目录的 CLAUDE.md。如果不同模块规则差异很大，也可以在子目录补充局部说明，但不要把同一条规则在多个地方重复写。
4. Skill 和 CLAUDE.md 有什么区别？
CLAUDE.md 更适合写项目长期规则，比如目录边界、测试命令、风险动作。Skill 更适合写可复用工作流，比如公众号提取、官网文章写作、SEO 检查、图片提示词生成。两者不要混在一起。
5. 哪些任务适合用 Opus 5 这类强模型？
复杂代码重构、长链路 Agent 任务、跨文件理解、复杂推理、深度文档分析更适合强模型。简单分类、格式转换、短文本改写、批量重复任务，优先考虑轻量模型或低成本模型。
6. 团队用 Claude Code 时，为什么要关注 API 接入层？
因为团队场景不只看模型效果，还要看 Key 管理、用量统计、账单核对、异常排查和成员权限。统一接入层能减少“每个人各配各的、出问题没人知道”的情况。
7. 已经配置过旧地址的工具，迁移到 apito.ai 复杂吗？
通常不复杂。已经配置好的程序和软件，一般只需要把请求地址里的 claudeapi.com 改成 apito.ai，其他地方如 Key、模型 ID 和请求参数不需要改。具体以你当前工具配置项为准。
